System Management and Maintenance

Caution: Use care when upgrading a supercluster

We strongly recommend upgrading a supercluster only during a system-wide maintenance window when there are no calls or conferences on the system and all clusters can be taken out of service. This makes the process significantly faster and easier.

If you must upgrade incrementally, be aware of the limited capacity available at any given point in the process. It’s advisable to ensure that there is little or no conferencing activity in any given territory until after the new supercluster has been created and territory responsibilities for that territory have been reassigned to a cluster in the new supercluster.

To minimize the time required for an upgrade:

If the upgrade requires a new license, obtain the license keys ahead of time.

Download a recent backup and upload the upgrade package file to all clusters in the supercluster ahead of time.

See also:

Upgrading the Software

Basic Upgrade Procedures

Simplified Supercluster Upgrade (Complete Service Outage)

Complex Supercluster Upgrade (Some Service Maintained)

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, 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.

Polycom, Inc.

397

Page 397
Image 397
Polycom 7000 manual Factors to Consider for an Incremental Supercluster Upgrade