Upgrade options in large critical deployments

[Patrick Lloyd]

I work with large financials and one of the largest questions one of them has is the concern around upgrades and ensuring that major disasters don't occur.  As a result, they split their deployment when doing upgrades and rejoin the deployments back together post upgrade when both deployments have been successful.  An additional option of upgrading through CLI and having nodes subsequently upgraded but a manual rolling upgrade or individual nodes being on either the pre or post upgrade version has also been asked about.

Is there a preferred way that the ISE BU recommends when dealing with >20 PSN's in critical financial environments?

[kthiruve · Accepted solution]

Hi Patrick,

It would be good to know the following

What is the ISE version the customer is on, size of deployment(locations)?

Are there any critical reasons for upgrade?

What are the services/features turned on in ISE?

Yes we have seen a split upgrade in large customers having number of PSN’s, so that they upgrade part of the deployment first and test it then upgrade the rest.

It would be good to know further information before any recommendation.

Thanks

Krishnan

[Patrick Lloyd]

Hi Krishnan,

This could be a number of versions, but we'll assume that it's a 1.4 or 2.2 deployment for long lived support.  Typically most of the financials I work with have 24 PSN's and are upgrading minor versions to remain within support, or are upgrading due to PSIRTs or bug fixes.  Without splitting the deployment, we would need to factor in about 24-28 straight hours of upgrades to upgrade all of the PAN's, MNT's and PSN's, but splitting can at least lead to a burn in type test capability.  Features would vary across customers, but for the sake of argument, my main customer has Auth, a large number of custom profiles, Guest, and would be looking to add Posture capabilities at some time in the future if this hangup was addressed.