When using PRIMECLUSTER on public clouds, connectivity between the cluster node and the API endpoint must be ensured for network takeover or to deal with split-brain. Use the API endpoint to control the power of instances or to change the settings of network components such as a virtual router.
PRIMECLUSTER provides architectural patterns for ensuring the connectivity between the cluster node and the API endpoint. For smooth design of a cluster system, choose from these architectural patterns.
The following are the architectural patterns for ensuring the connectivity between the cluster node and the API endpoint and the appropriate scenarios for each pattern.
Architectural pattern | Appropriate scenario | Note |
|---|---|---|
Ensuring connectivity with NAT gateway | Ensuring low cost and secure connectivity | Operation management is not required by the user since a NAT gateway is an AWS managed service. |
Ensuring connectivity with NAT instance | Ensuring secure and flexible connectivity | Operation management is flexible for the user since a NAT instance is not an AWS managed service. |
Ensuring connectivity with Elastic IP address | Ensuring connectivity of front-end servers with a simple architectural pattern |
|
Ensuring connectivity with PrivateLink | Ensuring connectivity of back-end servers with a simple architectural pattern |
|
This is an architecture pattern with a NAT gateway that can block access from public sites outside the VPC, and ensure connectivity between the cluster node and the API endpoint.
Place one instance that configures the cluster system of back-end servers in a private subnet. This instance is not given a public IP and has no direct connectivity with the Internet. Use a NAT gateway for connectivity with the endpoint since the API endpoint that forcibly stops PRIMECLUSTER or enables the network takeover exists over the Internet. A NAT gateway is a service managed by AWS and the user does not have to operate it.
See
For details on NAT gateways, refer to the official AWS documentation.
Figure 20.4 Ensuring connectivity with NAT gateway
To control traffic forwarding when using this architectural pattern, set the following entries for the main route table and the custom route table.
Destination CIDR | Forward to |
|---|---|
CIDR of VPC | Network in the VPC |
0.0.0.0/0 | NAT gateway |
Destination CIDR | Forward to |
|---|---|
CIDR of VPC | Network in the VPC |
0.0.0.0/0 | Internet gateway |
In this configuration, the traffic from the private subnet to the Internet is forwarded as follows and the NAT gateway blocks the traffic from public sites to the private subnet. This provides one-way connectivity from the private subnet to the Internet.
According to the entries of the main route table, the traffic from an instance in the private subnet to the Internet is forwarded to the NAT gateway by the virtual router.
According to the entries of the custom route table, the traffic forwarded to the NAT instance is forwarded to the Internet gateway by the virtual router.
This is an architectural pattern with a NAT instance that can block access from public sites outside the VPC, and ensure connectivity between the cluster node and the API endpoint. This architectural pattern is identical to the NAT gateway architectural pattern, except that the NAT gateway is replaced by the NAT instance in the placement of components.
Unlike the NAT gateway, the NAT instance is not a service managed by AWS. The user can freely manage operations. When building the cluster system in the back-end servers and for flexible operations, select this architectural pattern.
Figure 20.5 Ensuring connectivity with NAT instance
To control traffic forwarding when using this architectural pattern, set the following entries for the main route table and the custom route table.
Destination CIDR | Forward to |
|---|---|
CIDR of VPC | Network in the VPC |
0.0.0.0/0 | NAT instance |
Destination CIDR | Forward to |
|---|---|
CIDR of VPC | Network in the VPC |
0.0.0.0/0 | Internet gateway |
In this configuration, the traffic from the private subnet to the Internet is forwarded as follows and the NAT instance blocks the traffic from public sites to the private subnet. This provides one-way connectivity from the private subnet to the Internet.
According to the entries of the main route table, the traffic from an instance in the private subnet to the Internet is forwarded to the NAT instance by the virtual router.
According to the entries of the custom route table, the traffic forwarded to the NAT instance is forwarded to the Internet gateway by the virtual router.
The architectural pattern with the Elastic IP address is accessible from public sites. It is suitable for the cluster system of front-end servers. This architectural pattern is simpler than architectural patterns with the NAT gateway or the NAT instance. However, since the cluster node is accessible from public sites, the access control (ACL) or security rules of security groups must be firmly established.
When using this architectural pattern, you only need to give the instance an Elastic IP address.
Figure 20.6 Ensuring connectivity with Elastic IP address
The architectural pattern with the PrivateLink can ensure connectivity with the end point without preparing the public subnet by creating a VPC endpoint. This architectural pattern is simpler than the architectural patterns with the NAT gateway or the NAT instance. Also, unlike the pattern with the Elastic IP address, this pattern is securer since access from public sites can be blocked. However, the VPC endpoint of Amazon Route 53 (domain name system web service) cannot be created and if the architectural pattern of the network takeover by replacing the DNS records is selected, this architectural pattern cannot be selected.
Figure 20.7 Ensuring connectivity with PrivateLink
