InfoScale™ 9.0 Storage Foundation and High Availability Configuration and Upgrade Guide - Linux
- Section I. Introduction to SFHA
- Section II. Configuration of SFHA
- Preparing to configure
- Preparing to configure SFHA clusters for data integrity
- About planning to configure I/O fencing
- Setting up the CP server
- Configuring the CP server manually
- Configuring CP server using response files
- Configuring SFHA
- Configuring Storage Foundation High Availability using the installer
- Configuring a secure cluster node by node
- Completing the SFHA configuration
- Verifying and updating licenses on the system
- Configuring Storage Foundation High Availability using the installer
- Configuring SFHA clusters for data integrity
- Setting up disk-based I/O fencing using installer
- Setting up server-based I/O fencing using installer
- Manually configuring SFHA clusters for data integrity
- Setting up disk-based I/O fencing manually
- Setting up server-based I/O fencing manually
- Configuring server-based fencing on the SFHA cluster manually
- Setting up non-SCSI-3 fencing in virtual environments manually
- Setting up majority-based I/O fencing manually
- Performing an automated SFHA configuration using response files
- Performing an automated I/O fencing configuration using response files
- Section III. Upgrade of SFHA
- Planning to upgrade SFHA
- Preparing to upgrade SFHA
- Upgrading Storage Foundation and High Availability
- Performing a rolling upgrade of SFHA
- Performing a phased upgrade of SFHA
- About phased upgrade
- Performing a phased upgrade using the product installer
- Performing an automated SFHA upgrade using response files
- Upgrading SFHA using YUM
- Performing post-upgrade tasks
- Post-upgrade tasks when VCS agents for VVR are configured
- About enabling LDAP authentication for clusters that run in secure mode
- Planning to upgrade SFHA
- Section IV. Post-installation tasks
- Section V. Adding and removing nodes
- Adding a node to SFHA clusters
- Adding the node to a cluster manually
- Adding a node using response files
- Configuring server-based fencing on the new node
- Removing a node from SFHA clusters
- Removing a node from a SFHA cluster
- Removing a node from a SFHA cluster
- Adding a node to SFHA clusters
- Section VI. Configuration and upgrade reference
- Appendix A. Installation scripts
- Appendix B. SFHA services and ports
- Appendix C. Configuration files
- Appendix D. Configuring the secure shell or the remote shell for communications
- Appendix E. Sample SFHA cluster setup diagrams for CP server-based I/O fencing
- Appendix F. Configuring LLT over UDP
- Using the UDP layer for LLT
- Manually configuring LLT over UDP using IPv4
- Using the UDP layer of IPv6 for LLT
- Manually configuring LLT over UDP using IPv6
- About configuring LLT over UDP multiport
- Appendix G. Using LLT over RDMA
- Configuring LLT over RDMA
- Configuring RDMA over an Ethernet network
- Configuring RDMA over an InfiniBand network
- Tuning system performance
- Manually configuring LLT over RDMA
- Troubleshooting LLT over RDMA
CP server requirements
SFHA 9.0 clusters (application clusters) support coordination point servers (CP servers) that are hosted on the following VCS and SFHA versions:
VCS 7.3.1 or later single-node cluster
SFHA 7.3.1 or later cluster
Upgrade considerations for CP servers
Upgrade VCS or SFHA on CP servers to version 9.0 if the current release version is prior to version 7.3.1.
You do not need to upgrade CP servers to version 9.0 if the release version is 7.3.1 or later.
CP servers on version 7.3.1 or later support HTTPS-based communication with application clusters on version 7.3.1 or later.
You need to configure VIPs for HTTPS-based communication if release version of application clusters is 7.3.1 or later.
Make sure that you meet the basic hardware requirements for the VCS/SFHA cluster to host the CP server.
See the Arctera InfoScale Installation Guide.
Note:
While Arctera recommends at least three coordination points for fencing, a single CP server as coordination point is a supported server-based fencing configuration. Such single CP server fencing configuration requires that the coordination point be a highly available CP server that is hosted on an SFHA cluster.
Make sure you meet the following additional CP server requirements which are covered in this section before you install and configure CP server:
Hardware requirements
Operating system requirements
Networking requirements (and recommendations)
Security requirements
Table: CP server hardware requirements lists additional requirements for hosting the CP server.
Table: CP server hardware requirements
Hardware required | Description |
---|---|
Disk space | To host the CP server on a VCS cluster or SFHA cluster, each host requires the following file system space:
|
Storage | When CP server is hosted on an SFHA cluster, there must be shared storage between the nodes of this SFHA cluster. |
RAM | Each CP server requires at least 512 MB. |
Network | Network hardware capable of providing TCP/IP connection between CP servers and SFHA clusters (application clusters). |
Table: CP server supported operating systems and versions displays the CP server supported operating systems and versions. An application cluster can use a CP server that runs any of the following supported operating systems.
Table: CP server supported operating systems and versions
CP server | Operating system and version |
---|---|
CP server hosted on a VCS single-node cluster or on an SFHA cluster | CP server supports any of the following operating systems:
For the list of operating systems that CP server supports, refer to the Software Compatibility List (SCL). Review other details such as supported operating system levels and architecture for the supported operating systems. See the Arctera InfoScale Release Notes for that platform. |
Following are the CP server networking requirements and recommendations:
Arctera recommends that network access from the application clusters to the CP servers should be made highly-available and redundant. The network connections require either a secure LAN or VPN.
The CP server uses the TCP/IP protocol to connect to and communicate with the application clusters by these network paths. The CP server listens for messages from the application clusters using TCP port 443 if the communication happens over the HTTPS protocol. TCP port 443 is the default port that can be changed while you configure the CP server.
Arctera recommends that you configure multiple network paths to access a CP server. If a network path fails, CP server does not require a restart and continues to listen on all the other available virtual IP addresses.
When placing the CP servers within a specific network configuration, you must take into consideration the number of hops from the different application cluster nodes to the CP servers. As a best practice, Arctera recommends that the number of hops and network latency from the different application cluster nodes to the CP servers should be equal. This ensures that if an event occurs that results in an I/O fencing scenario, there is no bias in the race due to difference in number of hops or network latency between the CPS and various nodes.
For information about establishing secure communications between the application cluster and CP server, see the Cluster Server Administrator's Guide.