Feb 14th, 2022

Machine translation is used partially for this article. See the Japanese version for the original article.

Introduction

We introduce a best practice configuration of HA cluster based on VIP control on Amazon Web Services (hereinafter called "AWS").

In this blog,  we have introduced many ways to build HA clusters on AWS.
Some of the articles we've introduced include how you can combine AWS services with HA clusters built on your AWS to create a more user-friendly configuration.

For example, it was not possible to access an HA cluster based on VIP control built in Amazon Virtual Private Cloud (hereinafter called "VPC") from an on-premises environment before. However, by using the AWS Transit Gateway (hereinafter called "Transit Gateway"), it is possible to access the HA cluster based on VIP control using VIP from clients outside the VPC, such as those in on-premises environments.

This time, we will introduce the HA cluster configuration that combines the following three as a best practice configuration for HA clusters based on VIP control on AWS.

For more information about an HA cluster configuration on AWS and how to select an HA cluster configuration, please refer to here.

Contents

1. Best Practice Configuration of HA Clusters on AWS

The best practice configuration for HA clusters based on VIP control introduced is as follows:

By building an HA cluster of this configuration, the following will be possible:

2. Limitations and Precautions for HA Clusters on AWS

There are some limitations and precautions for the HA cluster based on VIP control configuration introduced in the HA Cluster Configuration Guide on AWS.

Limitations and precautions include the following:

2.1 Impossible to Access VIP from Outside VPC

In an HA cluster configuration based on VIP control, clients outside of VPC (on-premises environments or different VPC) cannot access the HA cluster using VIPs, so clients must be located in the same VPC as the HA cluster.
This is because HA cluster uses an IP address outside the CIDR of the VPC where HA cluster is built for VIP.

For example, if the CIDR of VPC is 10.0.0.0/16 and the IP address for the VIP is 20.0.0.100, HA cluster is accessible from only the clients (IP address: 10.0.x.x/32) in the same VPC using the VIP.

On the other hand, clients outside the VPC cannot access the HA cluster using the VIP, due to AWS specifications.

2.2 Access Route to the Internet from HA Cluster is Required

In an HA cluster configuration based on VIP control, the instances for the HA cluster use AWS Command Line Interface (hereinafter called "AWS CLI") when switching VIP. Each instance accesses the AWS endpoints via the Internet when executing the AWS CLI.
For this configuration, it is necessary to secure an access route to the Internet by preparing an Internet gateway or NAT gateway/NAT instance in the same VPC as the HA cluster.

2.3  Both-System Activation May Occur

In EXPRESSCLUSTER, Heartbeat resources and Network partition resolution (hereinafter called “NP resolution”) are settable as a method to prevent both-system activation.

In an HA cluster configuration on AWS, we set kernel mode LAN heartbeat resources as heartbeat resources. Also, in the recommended configuration, we configure the Witness heartbeat resources or HTTP NP resolution in addition to the kernel mode LAN heartbeat resources.
In the case, we prepare a web server separately from the servers for the HA cluster and the server for HA cluster checks the survival of the other server by access information to the web server.

Another way is to set PingNP resolution for NP resolution.
For example, when connecting the on-premises environment to the AWS using AWS Direct Connect (hereinafter called “Direct Connect”), you can specify the gateway on the on-premises as the target of PingNP resolution.

However, if there is no appropriate target for NP resolution, or if the OS stalls, both-system activation may occur for HA cluster.
For example, a network partition can occur when the communications between Availability Zones (hereinafter called "AZs") that build the HA cluster are disconnected. In Ping NP resolution, if NAT instances in the same VPC as the HA cluster are specified as the target of Ping NP resolution, communications between AZs will be disrupted, but ping communication to NAT instances in the same AZs will be possible.

Therefore each instance will judge that "a problem has occurred on the other server" and try to start the failover group.
As a result, the both-system activation that the failover group is activated on each instance will occur.

3. Building Best Practice Configuration for HA Clusters on AWS

We can solve each challenge of Chapter 2 by linking HA cluster with AWS services.

By using and setting up the following three, it is possible to access the HA cluster using VIP from clients outside the VPC, secure a private network route of the HA cluster itself and prevent both-system activation when a network partition occurs.

3.1 Using Transit Gateway

As for "2.1 Impossible to Access VIP from Outside VPC", by using the Transit Gateway, clients outside the VPC (on-premises environment or different VPCs) can also access the HA cluster using VIP.

In addition, if using Transit Gateway for an existing HA cluster based on VIP control, the HA cluster can be accessible from clients outside the same VPC as the HA cluster without changing EXPRESSCLUSTER's configuration. For procedures to build an HA cluster using Transit Gateway, please refer to the following: 

For access to HA cluster from an on-premises environment, refer to  here.

3.2 Using VPC Endpoints

As for "2.2 Access Route to the Internet from HA Cluster is Required", you can secure an access route that does not go through the Internet for AWS endpoints by using VPC endpoints.
However, in the case of an HA cluster based on DNS name control, this cannot be used because AWS Route 53 does not support VPC endpoints.

For procedures to build  an HA cluster using VPC endpoints refer to  here.

3.3 Setting up a Script for Forced Stop

As for "2.3 Both-System Activation May Occur", you can prevent both-system activation by setting a script for forced stop.

For procedures to build an HA cluster with a script for forced stop, refer to  here.

Conclusion

This time, we introduced the best practice configurations of HA cluster based on VIP control on AWS.
This configuration allows clients on on-premises environments and different VPC to access HA clusters using VIPs and ensure a private network route for the HA cluster in operation.
In addition, both-system activation can be prevented when a network partition occurs.

If you consider introducing the configuration described in this article, you can perform a validation with the trial module of EXPRESSCLUSTER. Please do not hesitate to contact us if you have any questions.