Building a highly available infrastructure for 3-tier web application in VPC

Virtual Servers

Servers in each of the 3-tiers have different requirements. When you provision your virtual servers, you have multiple options for virtual server profiles: Balanced, Compute, and Memory. The vCPU-to-memory ratio varies across the different profiles, but within the profile the ratio is constant. Within a profile, the number of vCPUs and memory increases along with the bandwidth performance. Use the following information when you are provisioning your servers.

Load balancers

You can order two types of load balancers from IBM Cloud®. While both load balancers can distribute both HTTP/HTTPS and TCP traffic, each provides different capabilities that might be more suited for different deployment types.

1. You can deploy IBM Cloud® Load Balancer either in public or private scenarios. For a public scenario, the load balancer has a public interface to take incoming traffic from the internet and distribute the traffic through its private interface connecting to the virtual servers as shown in Scenario 1 - deploying in single zone. For a private scenario, the incoming and distributed outgoing traffic goes through private subnets, such as the traffic between the application tier and the data tier.

   IBM Cloud Load Balancer also provides horizontal scaling to better handle increased traffic load.

   You can configure the Load Balancer back-end listener across multiple zones. When you use this configuration, a secondary load balancer is automatically provisioned and deployed in an active-active fashion for better availability. See Scenario 2 - deploying in multiple zones with IBM Cloud Internet Services.

2. IBM Cloud® Internet Services is a global load balancer that acts as a public load balancer only. Typically, it is deployed for global applications across multiple regions. Cloud Internet Services (CIS) is geo-aware and steers the traffic to the zone that is closest to the requester.

3. IBM Cloud® DNS Services is a global load balancer that acts as a private load balancer within IBM Cloud. IBM Cloud® DNS Services provides Virtual Private Cloud (VPC) users with private DNS zones that are resolvable only on IBM Cloud. Only explicitly permitted networks can access the private DNS zones.

In Scenario 2 - deploying in multiple zones with IBM Cloud Internet Services, Cloud Internet Services (CIS) distributes traffic between zones. Cloud Internet Services (CIS) allows you to create multiple server pools and origins to allow a 1:N type of deployment – one application to multiple server pools and origins. One application that is deployed across multiple server pools is helpful for DevOps management.

Storage

Storage can be a virtual server with block volumes or IBM Cloud® Object Storage. If your application requires lower latency and higher IOPs, use a virtual server with block volumes. You need a 3rd-party tool to provide replication or snapshots. For unstructured data and high data volumes, use Object Storage. The IBM Cloud Object Storage service has different tiers where replication varies such as within a zone, across multiple zones, or across regions. The replication is not instantaneous, but occurs over time.

Security

IBM Cloud provides both security groups and firewall access control lists (ACL). For host-based security, consider using security groups to preserve the firewall ACLs. Firewall ACLs are best used when they are applying the same security rule at a subnet level rather than at the host level.

Placement groups

Creating multiple instances of the same type gives you 2 things:

1. Removes a single point of failure. If one instance goes down, then other instances are available to pick up the work and continue the service.
2. Increases capacity. Parallelism allows multiple workers for higher output.

When you create multiple instances, the VSI scheduler makes every effort to place the VSIs on different hypervisors. And all hypervisors are installed on highly available servers (for example, redundant power supply, redundant network connections). Even with all of these guard rails in place, there is still a possibility for a single point of failure if somehow all your VSIs are deployed on the same hypervisor. A system crash will take down all your VSIs. So, creating multiple VSIs may not improve your resiliency as much as you would like or hope.

Spreading the VSIs across the zones does address this risk but what about multiple VSIs that are in the same zone? For example, suppose you have 5 VSIs that are dedicated to your web tier and are spread across three zones; 2 of the 3 zones have 2 VSIs. You want to ensure that the zones that have 2 VSIs are set up for the best availability. Granted you have other zones to protect you against failure in a zone, but it would be better to ensure the 2 VSIs are created on different hypervisors. That way, if the system or hypervisor goes down, the impact is smaller than if the 2 VSIs that were placed on the same hypervisor.

To avoid placing VSIs on the same hypervisor, placement groups come into play. Placement groups guarantee a group of VSIs are not placed on the same hypervisor.

2 different placement algorithms are available for you to choose from:

• Hypervisor spread - Ensures the VSIs are distributed across different hypervisors. There can be up to 12 VSIs in the placement group.
• Power spread - Ensures the VSIs are placed not only different hypervisors but also the hypervisors are placed on different power and network, essentially on different racks. There can be up to 4 VSIs in the placement group.

Of the 2 options, the second option provides a better resiliency over the first option.

If you have several VSIs, such as the web or applications, then hypervisor spread is sufficient. If you have a smaller set of VSIs, such as a database, where there are multiple masters or read replicas in the same zone, then power spread a better choice.

For more informationon Placement group, see About Placement groups.

Auto scale

When it comes to availability, customers tend to focus on failed or maintenance events because their services need to be available during any resource loss, whether the event is expected or unexpected. An often overlooked factor of resource availability is capacity. Capacity tends to be hard to plan for, as deployed resources need to meet the current demands while also handling spikes or seasonal load increases. The capacity must cover a wide range of load conditions while also balancing the economics for the workload.

If the current resources cannot handle the increased workload demands, then incoming transaction requests are at risk of being ignored or dropped, which in turn creates an availability problem.

Auto scale through instance group helps address these challenges by scaling resources up and down based on different load conditions. Not only that, Auto scale can be a cost optimization. With scaling policy, you save money by only paying for virtual servers when you need them and deleting them when you don’t.

Placement group can be used with auto scale. If at any point the (min or max) number of VSI is greater than 3, then placement group is recommended with auto scale.

Auto scale adjusts resources in an automated and orchestrated fashion and is available in both compute and cloud load balancer configurations.

• Compute – Scaling the virtual server instances is determined by the average target load utilization across all of the virtual server instances in the Auto scale group. Target load utilization can be based on CPU, memory, network, or a combination of these resources. If the virtual server instances load is not at the wanted target load, then instances automatically scale - up or down - to meet the average target load utilization. The number of virtual server instances that are being added or deleted will exceed the minimum or maximum virtual server instances for an Auto scale group. More information on Auto scale can be found here.

• Cloud load balancers – Auto scale for the cloud load balancer has two parts. The first part is the horizontal scaling of the cloud load balancer. The cloud load balancer scales depending on load so that it does not become the bottleneck. This process is managed by the IBM cloud controller. The second part is making the cloud load balancer aware of membership changes to the backend server pool. In a non-Auto scale environment, this adjustment is made by the customer manually; the customer must add or remove virtual instances from the backend server pool. With Auto scale, this adjustment is an automated process and removes the need for customer intervention.