InfoScale™ 9.0 Storage Foundation Cluster File System High Availability Configuration and Upgrade Guide - AIX
- Section I. Introduction to SFCFSHA
- Introducing Storage Foundation Cluster File System High Availability
- Section II. Configuration of SFCFSHA
- Preparing to configure
- Preparing to configure SFCFSHA clusters for data integrity
- About planning to configure I/O fencing
- Setting up the CP server
- Configuring the CP server manually
- Configuring SFCFSHA
- Configuring a secure cluster node by node
- Verifying and updating licenses on the system
- Configuring SFCFSHA clusters for data integrity
- Setting up disk-based I/O fencing using installer
- Setting up server-based I/O fencing using installer
- Performing an automated SFCFSHA configuration using response files
- Performing an automated I/O fencing configuration using response files
- Configuring CP server using response files
- Manually configuring SFCFSHA 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 SFCFSHA cluster manually
- Setting up non-SCSI-3 fencing in virtual environments manually
- Setting up majority-based I/O fencing manually
- Section III. Upgrade of SFCFSHA
- Planning to upgrade SFCFSHA
- Preparing to upgrade SFCFSHA
- Upgrading the operating system
- Performing a full upgrade of SFCFSHA using the installer
- Performing a rolling upgrade of SFCFSHA
- Performing a phased upgrade of SFCFSHA
- About phased upgrade
- Performing a phased upgrade using the product installer
- Performing an automated SFCFSHA upgrade using response files
- Upgrading Volume Replicator
- Performing post-upgrade tasks
- Planning to upgrade SFCFSHA
- Section IV. Post-configuration tasks
- Section V. Configuration of disaster recovery environments
- Section VI. Adding and removing nodes
- Adding a node to SFCFSHA clusters
- Adding the node to a cluster manually
- Setting up the node to run in secure mode
- Adding a node using response files
- Configuring server-based fencing on the new node
- Removing a node from SFCFSHA clusters
- Adding a node to SFCFSHA clusters
- Section VII. Configuration and Upgrade reference
- Appendix A. Support for AIX Live Update
- Appendix B. Installation scripts
- Appendix C. Configuration files
- Appendix D. Configuring the secure shell or the remote shell for communications
- Appendix E. High availability agent information
- Appendix F. Sample SFCFSHA cluster setup diagrams for CP server-based I/O fencing
- Appendix G. Changing NFS server major numbers for VxVM volumes
- Appendix H. 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
Generating the key and certificates manually for the CP server
CP server uses the HTTPS protocol to establish secure communication with client nodes. HTTPS is a secure means of communication, which happens over a secure communication channel that is established using the SSL/TLS protocol.
HTTPS uses x509 standard certificates and the constructs from a Public Key Infrastructure (PKI) to establish secure communication between the CP server and client. Similar to a PKI, the CP server, and its clients have their own set of certificates signed by a Certification Authority (CA). The server and its clients trust the certificate.
Every CP server acts as a certification authority for itself and for all its client nodes. The CP server has its own CA key and CA certificate and a server certificate generated, which is generated from a server private key. The server certificate is issued to the Universally Unique Identifier (UUID) of the CP server. All the IP addresses or domain names that the CP server listens on are mentioned in the Subject Alternative Name section of the CP server's server certificate
The OpenSSL library must be installed on the CP server to create the keys or certificates.. If OpenSSL is not installed, then you cannot create keys or certificates. The vxcps.conf file points to the configuration file that determines which keys or certificates are used by the CP server when SSL is initialized. The configuration value is stored in the ssl_conf_file
and the default value is /etc/vxcps_ssl.properties.
To manually generate keys and certificates for the CP server:
- Create directories for the security files on the CP server.
# mkdir -p /var/VRTScps/security/keys /var/VRTScps/security/certs
- Generate an OpenSSL config file, which includes the VIPs.
The CP server listens to requests from client nodes on these VIPs. The server certificate includes VIPs, FQDNs, and host name of the CP server. Clients can reach the CP server by using any of these values. However, Arctera recommends that client nodes use the IP address to communicate to the CP server.
The sample configuration uses the following values:
Config file name: https_ssl_cert.conf
VIP: 192.168.1.201
FQDN: cpsone.company.com
Host name: cpsone
Note the IP address, VIP, and FQDN values used in the [alt_names] section of the configuration file are sample values. Replace the sample values with your configuration values. Do not change the rest of the values in the configuration file.
[req] distinguished_name = req_distinguished_name req_extensions = v3_req [req_distinguished_name] countryName = Country Name (2 letter code) countryName_default = US localityName = Locality Name (eg, city) organizationalUnitName = Organizational Unit Name (eg, section) commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 40 [v3_req] keyUsage = keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = cpsone.company.com DNS.2 = cpsone DNS.3 = 192.168.1.201
- Generate a 4096-bit CA key that is used to create the CA certificate.
The key must be stored at
/var/VRTScps/security/keys/ca.key
. Ensure that only root users can access the CA key, as the key can be misused to create fake certificates and compromise security.# /opt/VRTSperl/non-perl-libs/bin/openssl genrsa -out /var/VRTScps/security/keys/ca.key 4096
- Generate a self-signed CA certificate.
# /opt/VRTSperl/non-perl-libs/bin/openssl req -new -x509 -days days -sha256 -key /var/VRTScps/security/keys/ca.key -subj \
'/C=countryname/L=localityname/OU=COMPANY/CN=CACERT' -out \
/var/VRTScps/security/certs/ca.crt
Where, days is the days you want the certificate to remain valid, countryname is the name of the country, localityname is the city, CACERT is the certificate name.
- Generate a 2048-bit private key for CP server.
The key must be stored at
/var/VRTScps/security/keys/server_private key
.# /opt/VRTSperl/non-perl-libs/bin/openssl genrsa -out \
/var/VRTScps/security/keys/server_private.key 2048
- Generate a Certificate Signing Request (CSR) for the server certificate.
The Certified Name (CN) in the certificate is the UUID of the CP server.
# /opt/VRTSperl/non-perl-libs/bin/openssl req -new -sha256 -key /var/VRTScps/security/keys/server_private.key \
-config https_ssl_cert.conf -subj \
'/C=CountryName/L=LocalityName/OU=COMPANY/CN=UUID' \
-out /var/VRTScps/security/certs/server.csr
Where, countryname is the name of the country, localityname is the city, UUID is the certificate name.
- Generate the server certificate by using the key certificate of the CA.
# /opt/VRTSperl/non-perl-libs/bin/openssl x509 -req -days days -sha256 -in /var/VRTScps/security/certs/server.csr \
-CA /var/VRTScps/security/certs/ca.crt -CAkey \
/var/VRTScps/security/keys/ca.key \
-set_serial 01 -extensions v3_req -extfile https_ssl_cert.conf \
-out /var/VRTScps/security/certs/server.crt
Where, days is the days you want the certificate to remain valid, https_ssl_cert.conf is the configuration file name.
You successfully created the key and certificate required for the CP server.
- Ensure that no other user except the root user can read the keys and certificates.
- Complete the CP server configuration.
More Information