Option 1: Architecting Web/App Availability-Using HAProxy + AWS Elastic IP
HAProxy is attached with an AWS Elastic IP(example:50.19.82.183) since it is the
entry point to your Web Application. The Elastic IP is assigned to your account
and will not change when the Amazon EC2 instance is terminated. We can reuse
the same AWS Elastic IP to any other EC2 instance or another HAProxy EC2 in
future. The HAProxy Elastic IP is registered Route53 for DNS resolution.
The Web/App EC2’s (imagine Apache EC2 servers) are attached
with another series of AWS Elastic IP’s (example:23.23.174.252-255). These Elastic IP’s are configured in
the HAProxy configuration file. In case anyone
of the Web/App Apache EC2 goes down, we can manually or automatically spawn a
new Web/App EC2 from the Base Golden Image and assign the same Web/App Elastic
IP to it again. No Need to change the HAProxy configuration in event of any Web/App
EC2 instance failure.
Frequent Sync of Apache Logs and User Uploaded files (if
any) to S3 is highly recommended. This will improve the Recovery Point
objective and fault tolerance levels of the overall system.
Disadvantages:
- Re Mapping an AWS Elastic IP will take around 120 seconds (or more sometimes more depending upon the Region-AZ), some users who have been using the particular Web/App EC2 through that Elastic IP will face problems for few seconds.
- Additional cost and Data charges incurred for maintain Elastic IP’s
- This model not suggested for highly scalable systems running hundreds/thousands of Web/App EC2 because of the scarce nature of Elastic IP’s.
- Fractionally (negligible) slower because of Elastic IP -> Private IP translation
- No change in HAProxy Configuration required during Web/App EC2 instance failure.
Option 2: Architecting Web/App Availability-Using HAProxy + EC2 Private IP's
HAProxy is attached with an AWS Elastic IP(example:50.19.82.183) since it is the
entry point to your Web Application. The Elastic IP is assigned to your account
and will not change when the Amazon EC2 instance is terminated. We can reuse
the same AWS Elastic IP to any other EC2 instance or HAProxy EC2 in future. The
HAProxy Elastic IP is registered Route53 for DNS resolution.
The Web/App EC2's (imagine Apache EC2 servers) are accessed with
private IP of the Amazon EC2. These private IP's(example:10.62.186.90-93) are configured in the HAProxy
configuration file. In case the Web/App
Apache EC2 goes down, we can manually or automatically spawn a new Web/App EC2.
Whenever a new EC2 instance is launched their public and private IP’s will
change, so we need to hot reconfigure HAProxy file in event of failure with new
Web/App Apache EC2 Private IP address assigned.
Frequent Sync of Apache Logs and User Uploaded files (if
any) to S3 is highly recommended. This will improve the Recovery Point
objective and fault tolerance levels of the overall system.
Disadvantages:
- Hot reconfigure of HAProxy has to be done whenever the private IP address of Web/App EC2 changes.
- No additional cost incurred for accessing through Elastic IP.
- Fractionally faster because of access using Private IP
HAProxy is attached with an AWS Elastic IP since it is the entry
point to your Web Application. The Elastic IP is assigned to your account and
will not change when the Amazon EC2 instance is terminated. We can reuse the
same AWS Elastic IP to any other EC2 instance or HAProxy EC2 in future. The
HAProxy Elastic IP is registered Route53 for DNS resolution.
The Web/App EC2’s (imagine Apache EC2 servers) are grouped
into two farms –Active and Backup. X web/app EC2’s are launched in the
Active farms. Y more web/app EC2’s are launched in the backup farms. In
event of Web/App EC2 failure in the active farms, requests are automatically
diverted to the Web/App Apache EC2's in the Backup farms. Backup farms can have lesser EC2 servers
compared to the active farms in case manual/automated recovery can be done faster. For website outages caused by heavy load traffic, it
is better to have both Active and Backup farms in same size to avoid backup failing quickly. All the Web/App
EC2 servers in Active and Backup are accessed with private IP's of the Amazon EC2.
This private IP is configured in the HAProxy configuration file. In case an Web/App Apache EC2 goes down, we
can manually or automatically spawn a new Web/App EC2. Whenever a new EC2
instance is launched their public and private IP’s will change, so we need to
hot reconfigure HAProxy file in event of failure with new Web/App Apache EC2
Private IP address.
Frequent Sync of Apache Logs and User Uploaded files (if
any) to S3 is recommended. This will improve the Recovery Point objective.
Disadvantages:
- It is prohibitively costly to run passive Web/App EC2 in the HAProxy backup mode-You are running a backup farm,keeping it in idle state, paying by hour and using it only when needed( not advisable for clouds). Though this model does not fit the cloud architecture paradigm, i have seen some customers have deployed their Web/App EC2 farm in this fashion. Instead one can adopt Active-Active Web/App EC2 model itself discussed in the next section.
- Architecture has High availability built in Web/App EC2 layer. Instant switch between EC2 in Active to Backup farms. Ops have sometime to breathe.
- RTO and RPO can be efficiently addressed.
- Only minor advantage i see is version rollouts can be propagated easily. Code rollout first to the Backup farms, Kill the EC2’s in Active Farms and Switch the Active-Backup farms through HAProxy Hot reconfigure. (Note: This scenario can be heavily negated if we start using Puppet /Chef for deployment)
Option 4: Architecting Web/App Availability-Using HAProxy and AWS Multi-AZ
This is the Recommended architecture for deploying Web/App EC2 under HAProxy inside Amazon for High Availability.
We all know Amazon Web Services Global infrastructure consists of Amazon EC2 Regions. Every Region is designed to be completely isolated from the other Amazon EC2 Region. Every Amazon Region is further sub divided into Availability Zones. By launching EC2 instances in separate Availability Zones (AZ), we can protect our applications from the failure of a single location. To know more about AWS Regions and Availability Zones click here
In this architecture HAProxy is attached with an AWS Elastic IP and launched in AZ-1.The HAProxy Elastic IP is registered Route53 for DNS resolution.
The Web/App EC2’s (imagine Apache EC2 servers) are launched in 2 or more Availability Zones in the AWS EC2 region. The Private IP addresses of these Web/App EC2 instances are configured in the HAProxy Configuration file. Bringing the Multiple Availability zones into the architecture does not add any extra configuration effort in the HAProxy.
In event of an Web/App EC2 failure, requests are automatically diverted to the healthy Web/App Apache EC2's in the same or other AZ's (based on LB algorithm). We can manually or automatically spawn a new Web/App EC2 and hot configure their new private IP address into HAProxy.
In event of an entire AZ failure, requests are still automatically diverted to the healthy Web/App Apache EC2's in the other available AZ's (based on LB algorithm). This helps us protect our application from the failure of a single location (Data center) itself and design much more robust HA architecture.
In event of an entire AZ failure, requests are still automatically diverted to the healthy Web/App Apache EC2's in the other available AZ's (based on LB algorithm). This helps us protect our application from the failure of a single location (Data center) itself and design much more robust HA architecture.
Frequent Sync of Apache Logs and User Uploaded files (if any) to S3 is recommended. This will improve the Recovery Point objective.
Disadvantages:
- Data charges between AZ
- Little complex to maintain because of Multiple EC2 running in active mode
- No constant NW latency between AZ's makes Web/App EC2 distribution little painful
Advantages:
- Architecture has recommended levels of High availability built in Web/App EC2 layer.
- RTO and RPO can be efficiently addressed.
Sample HAProxy Config (Private IP + Multi-AZ):
4 comments:
To make it even more highly available, instead of running a single HAPRoxy
Option 5:
Similar to Option 4 but run HAProxies in multiple regions/az and use ELB to route traffic to all the available HAProxies servers.
This way you don't have a SPoF in your HAProxy.
I Agree with @mxx.
As an another alternative, why not use Option 5 but using iELB (internal ELB) in multiple regions/az instead of HAProxies?
Thanks!
When I want to dynamically scale how do I hot configure(Add the IP of the newly created server for load / remove the IP when a server is removed from the farm) the haproxy? Is it a good idea to hot configure the haproxy from the startup script of the newly created server?
Hi prasanna,
i first assume you are talking about HAproxy and web/App servers IP scaled out under it. In this context we can follow these approaches
Approach 1) If your scale out is between 2-8 web/app servers in the NON VPC cloud of AWS, you can assign the 8 EIP and pre configure them in HAProxy. When you remove a web/app ec2 server, HAProxy marks that as unhealthy and does not pass the request. When a new web/app EC2 is launched you can attach this to EIP again, where HAproxy will identify it is healthy and start using them again. You will have to pay for the EIP unnecessarily.
Approach 2) Run a separate discovery service, which maintains every Web/App EC2 IP address and HAProxy will periodically discover and update their entries thru Hot reconfiguration.
Note: Since you will be doing DNS RR, 1 HAproxy need not identify the existence of another HAproxy
Post a Comment