Storage Foundation 7.2 Configuration and Upgrade Guide - Solaris
- Section I. Introduction and configuration of Storage Foundation
- Section II. Upgrade of Storage Foundation
- Planning to upgrade Storage Foundation
- About the upgrade
- Supported upgrade paths
- Preparing to upgrade SF
- Using Install Bundles to simultaneously install or upgrade full releases (base, maintenance, rolling patch), and individual patches
- Upgrading Storage Foundation
- Performing an automated SF upgrade using response files
- Upgrading SF using Boot Environment upgrade
- Performing post-upgrade tasks
- Optional configuration steps
- Recovering VVR if automatic upgrade fails
- Resetting DAS disk names to include host name in FSS environments
- Upgrading disk layout versions
- Upgrading VxVM disk group versions
- Updating variables
- Setting the default disk group
- Upgrading the Array Support Library
- Converting from QuickLog to Multi-Volume support
- Verifying the Storage Foundation upgrade
- Planning to upgrade Storage Foundation
- Section III. Post configuration tasks
- Section IV. Configuration and Upgrade reference
- Appendix A. Installation scripts
- Appendix B. Configuring the secure shell or the remote shell for communications
- About configuring secure shell or remote shell communication modes before installing products
- Manually configuring passwordless ssh
- Setting up ssh and rsh connection using the installer -comsetup command
- Setting up ssh and rsh connection using the pwdutil.pl utility
- Restarting the ssh session
- Enabling and disabling rsh for Solaris
Planning an upgrade from the previous VVR version
If you plan to upgrade VVR from the previous VVR version, you can upgrade VVR with reduced application downtime by upgrading the hosts at separate times. While the Primary is being upgraded, the application can be migrated to the Secondary, thus reducing downtime. The replication between the (upgraded) Primary and the Secondary, which have different versions of VVR, will still continue. This feature facilitates high availability even when the VVR upgrade is not complete on both the sites. Veritas recommends that the Secondary hosts be upgraded before the Primary host in the Replicated Data Set (RDS).
See the Veritas InfoScale™ Release Notes for information regarding VVR support for replicating across Storage Foundation versions.
Replicating between versions is intended to remove the restriction of upgrading the Primary and Secondary at the same time. VVR can continue to replicate an existing RDS with Replicated Volume Groups (RVGs) on the systems that you want to upgrade. When the Primary and Secondary are at different versions, VVR does not support changing the configuration with the vradmin command or creating a new RDS.
Also, if you specify TCP as the network protocol, the VVR versions on the Primary and Secondary determine whether the checksum is calculated. As shown in Table: VVR versions and checksum calculations, if either the Primary or Secondary are running a version of VVR prior to 7.2, and you use the TCP protocol, VVR calculates the checksum for every data packet it replicates. If the Primary and Secondary are at VVR 7.2, VVR does not calculate the checksum. Instead, it relies on the TCP checksum mechanism.
Table: VVR versions and checksum calculations
VVR prior to 7.2 (DG version <= 140) | VVR 7.2 (DG version >= 150) | VVR calculates checksum TCP connections? |
|---|---|---|
Primary | Secondary | Yes |
Secondary | Primary | Yes |
Primary and Secondary | Yes | |
Primary and Secondary | No |
Note:
When replicating between versions of VVR, avoid using commands associated with new features. The earlier version may not support new features and problems could occur.
If you do not need to upgrade all the hosts in the RDS simultaneously, you can use replication between versions after you upgrade one host. You can then upgrade the other hosts in the RDS later at your convenience.
Note:
If you have a cluster setup, you must upgrade all the nodes in the cluster at the same time.