Polycom 3725-76302-001O Factors to Consider for an Incremental Supercluster Upgrade, Simplified Supercluster Upgrade (Complete Service Outage)

Polycom, Inc. 387

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.