Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
In environments where automatic failover is desired, it is possible to enhance automatic failover to monitor for additional events via a Hardware Management Console (HMC) using cluster monitors. See Advanced Node Failure Detection for additional information.
...
PowerHA uses the Power Virtual Server API to manage and control resources in IBM Power Virtual Server.
Configuring PowerHA to Accept Digital Certificates from IBM Cloud Services
All communication between PowerHA and the IBM Cloud uses TLS for communication. This communication uses digital certificates to both encrypt and protect the communication.
Create a *SYSTEM certificate store to hold the digital certificates
To create the *SYSTEM certificate store, use the following steps:
Expand | ||||
---|---|---|---|---|
| ||||
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Tip: The system certificate store must be created on all nodes in the cluster. Ensure the *SYSTEM certificate store is created on all nodes in the cluster before continuing. |
Trusting the IBM Cloud Certificate Authority
There are two options for trusting the IBM Cloud Certificate Authority:
Recommended: Populate digital certificate manager with well known CAs.
Expand | ||||
---|---|---|---|---|
| ||||
Open the *SYSTEM certificate store in Digital Certificate Manager
Populate the *SYSTEM certificate store in Digital Certificate Manager with CAs
|
Bypassing strict-certificate checking in PowerHA using a PowerHA Policy
Expand | ||
---|---|---|
| ||
Add a PowerHA policy to bypass strict certificate checking in PowerHA. For example, the following policy would bypass strict certificate checking for any configuration description:
This step only needs to be performed on one node as the policy applies to the entire PowerHA cluster. |
Creating an API Key
The API key at a minimum must have the following access levels to the Workspace for Power Virtual Server service:
...
In the IBM Cloud console, go to Manage > Access (IAM) and select Service IDs.
If you don’t have a service ID created, create the service ID.
Click the Actions icon > Manage service ID.
Click API keys.
Click create
Add a name and description to easily identify the API key.
Click Create.
Save your API key by copying or downloading it to a secure location.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
For security reasons, the API key is only available to be copied or downloaded at the time of creation. If the API key is lost, you must create a new API key. |
...
For this example, a configuration description for DAL10 is created using the following command, followed by selecting the appropriate workspace from the list:
ADDHACFGD NAME(PVSWSDAL) TYPE(*STGCTL) SUBTYPE(*PVS) PVSHOST('apikey')
...
For example, a configuration description for WDC07 is added using the following command followed by selecting the appropriate workspace from the list:
ADDHACFGD NAME(PVSWSWDC07PVSWSWDC) TYPE(*STGCTL) SUBTYPE(*PVS) PVSHOST('apikey')
Configuring Global Replication Services (GRS)
PowerHA requires GRS to be configured outside of PowerHA. This includes performing the following actions:
Actions on the primary site:
...
...
Enabling replication for the IASP volumes by setting the volumes to be replication-enabled
...
Creating a new volume group
...
Placing the replication enabled volumes into the volume group
Actions on the target workspace:
Onboard the auxiliary volumes by using the IBM Cloud CLI or API.
Attach the a auxiliary volumes to the target virtual server
See the IBM Cloud documentation on getting started with GRS for additional information.
Adding Copy Description
A copy description gives PowerHA the information it needs to describe and manage a single copy of an IASP. With GRS, because the IASP is replicated, there are two copies of the IASP. Therefore, PowerHA requires two copy descriptions.
...
Info |
---|
Note: When using the command in batch mode, volume IDs must be specified in the command rather than the *SELECT option. The Volume IDs for a volume can be found in the IBM Cloud console. |
Configuring Global Replication Services (GRS)
While GRS can be configured outside of PowerHA, it is possible to also configure GRS using the Configure PVS Mirror (CFGPVSMIR) command:
CFGPVSMIR ASPDEV(MYIASP) ACTION(*CREATE)
This command will do the following:
Validate various configuration
If the target copy description has not yet had the *ADDNODE operation performed for the node at the target site with the lowest backup sequence (called the mirror site primary node), it will prompt to select the appropriate Power Virtual Server Instance to associate with the target node.
Ensure the IASP volumes are all in the same storage pool.
Enable replication for the IASP volumes by setting the volumes to be replication-enabled
Create or update a volume group
Place the replication enabled volumes into the volume group
Onboard the auxiliary volumes
Attach the auxiliary volumes to the target virtual server
Add volumes to the target copy description
If a failure occurs while performing the CFGPVSMIR command, such as a network communication failure during the operation, the CFGPVSMIR command can be run again, and it will check and confirm which steps need to be performed.
Expand | ||
---|---|---|
| ||
While the CFGPVSMIR command will handle many of the steps in an automated fashion, GRS can also be manually configured. This includes performing the following actions: Actions on the primary site:
Actions on the target workspace:
See the IBM Cloud documentation on getting started with GRS for additional information. Adding Volumes to the Backup (Target) Copy DescriptionVolumes are added to the target copy description in the same way that they are added to the source copy description, using the CHGPVSCPYD command. In this instance, the volume IDs must be obtained from the target Power Virtual Server workspace in the IBM Cloud. For example, the copy description for the backup copy can be added using the following command:
|
Starting a PowerHA Session
...
This command specifies to start a session called MYSSN that is of type Global Mirror. PowerHA uses Global Mirror to represent asynchronous replication as is used with Global Replication Services. In addition, the command specifies that this session references the CRG named MYCRG. PowerHA automatically pulls together the CRG information and Copy Description information from the copy descriptions that describe sites in the CRG.
Starting the CRG
Once everything is configured, the cluster resource group can be started. Starting the cluster resource group starts regular PowerHA monitoring and health checks of the environment. These health checks run at 15 minute intervals and will post messages to the QSYSOPR upon a failure that would prevent a switchover or failover.
In addition to posting a message to QSYSOPR, the status of the node in the CRG recovery domain status field is updated to reflect the combined status of the last healthcheck and the status of the node. This status field can be displayed by going to taking option 6=Recovery Domain on the Work with Cluster Resource groups menu from within the WRKCLU menu.
The following command in this example starts the cluster resource group:
STRCRG CRG(MYCRG)
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
The cluster resource group must be restarted if clustering is ended on all nodes. |
Results
PowerHA management of GRS is now configured between the nodes in the CRG. To verify and monitor the status of replication, use one of the following:
...