Polycom 3725-76302-001O manual Factors to Consider for an Incremental Supercluster Upgrade

Factors to Consider for an Incremental Supercluster Upgrade

Before deciding to attempt an incremental supercluster software upgrade, be aware of the following:

●An incremental upgrade can easily take five times as long as the simplified method.

●As clusters are removed from the existing supercluster and upgraded, its capacity is reduced. As the new supercluster is being built, it won’t be at full capacity until all clusters are upgraded. Both the existing supercluster and the new one will have limited capacity for a significant period of time, with the following possible consequences:

Some endpoints may be unable to register.

The MCUs remaining in the supercluster may not have the capacity to handle all the conferences.

Some endpoints may not successfully redirect their registrations and may not be able to make/receive calls.

●As the old supercluster is deconstructed, the territory associations have to be changed each time a cluster leaves. As the new supercluster is built, the territory associations have to be changed each time a cluster joins.

●As the clusters for some endpoints are removed from the existing supercluster and join the new one, the video network becomes partitioned with separate islands of endpoints.

●Some endpoints don’t respond well to a gatekeeper change (such as a signaled alternate gatekeeper). To successfully redirect these endpoints to a Call Server in the new supercluster, one of the following may be necessary:

Managed endpoints may be re-provisioned by the Polycom RealPresence Resource Manager system, CMA system, or third-party endpoint management system responsible for them.

Unmanaged endpoints may be manually reconfigured and if necessary restarted (in some cases, restarting an endpoint may be sufficient).

●Any configuration changes to the old supercluster (once the first cluster has left) may be lost when the new supercluster is created.

●History records for calls and conferences that cross from the old supercluster to the new one (and vice versa) will not be merged into a single call/conference after the upgrade.

●If embedded DNS is enabled, the enterprise DNS can only point to one supercluster. The other supercluster will not have territory fail-over capability.

●If Conference Manager is enabled, during the time that the supercluster is split into two, each supercluster could host separate conferences on the same VMR.

●The site topology bandwidth specifications will be duplicated in both the old supercluster and the new supercluster. Without significant changes to the site topology’s bandwidth configuration, this can lead to bandwidth overloading during the upgrade.

See also:

Upgrading the Software on page 380

Basic Upgrade Procedures on page 382

Simplified Supercluster Upgrade (Complete Service Outage)

If it’s possible to schedule the upgrade for a maintenance window during which there is no service, we strongly recommend doing so, as described below. This greatly shortens and simplifies the process.

Polycom, Inc. 387