Filter
Top Products
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.
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.