CAUTION:
Thin Image snapshot operations default to
Provisioned using floating device. In versions prior to 6.5, this
setting would automatically fallback to Fully provisioned if the
hardware storage device did not support floating devices. With the introduction of Cascade mode snapshots in version 6.5 (now the default mode), this
automatic fallback has been removed. Consequently:
- Data flows created in versions prior to 6.5 that contain Thin Image snapshot operations, with cascade mode is enabled, will now fail if the underlying hardware does not support floating device. These data flows must be manually reconfigured to use the correct provisioning type. Please note that if these data flows also contain replication operations, then these will be re-evaluated when the modified data flows are re-activated.
- Data flows created in versions prior to 6.5 that contain Thin Image snapshot operations, with cascade mode enabled, will now fail if the P-VOLs have any pre-existing non-cascade mode snapshots. If cascade mode is to remain enabled then any non-cascade mode snapshots must be deleted.
- For data flows created in version 6.5 or later, if the hardware storage device on which Thin Image snapshot operations are performed does not support Floating device and Cascade mode, then Thin Image operations will fail, unless the appropriate settings are selected in the respective data flows.
Note:
- The Manage Software Updates RBAC activity must be assigned to users who perform upgrades. It is recommended that this activity is restricted to administrative users only.
- Upgrade of a Microsoft failover cluster node needs to be done locally, following a similar procedure to that described in How to install a Protector master or client on a Windows cluster. It's not possible to upgrade remotely because the standby nodes in the cluster are not available. Attempting a remote upgrade will place the clustered Protector service in a failed state, taking it offline.
- Before upgrading unmount any mounted snapshots.
- DO NOT upgrade while replications are in the process of pairing. Any active replications must be in the paired state before upgrade is carried out.
An upgrade can be performed if the existing installation has become corrupted or a newer version of Ops Center Protector is available.
If upgrading, obtain the upgrade installer files from your Hitachi Vantara support representative.
When an upgrade starts, the Ops Center Protector services are shutdown, causing the upgrading OS Host node and any nodes for which it serves as a proxy, to go offline in the Nodes Inventory. Any active data flows using those nodes will be temporarily interrupted. These nodes will come back online again when the services are automatically restarted on the OS Host node, after the upgrade process is completed, and the affected data flows will resume operation.
Note: We recommend upgrading Ops Center Protector only after current backups have been completed.
Note:
When upgrading, it is highly recommended (and often necessary) to upgrade all nodes to the same version. The recommended order in which to upgraded is:
- Internet Connected Nodes. If ICNs are not upgraded first, they may not be able to be 'push upgraded' through the UI. ICNs may appear to go offline until the master is upgraded.
- Master Node(s).
- Clients acting as ISMs, controlling Hitachi Block and File storage devices.
- Clients acting as Data Destinations, such as Repositories.
- Clients acting as Data Sources, such as application servers.