High Availability @ Web/App Layer
To avoid Single Point of Failure in the Web/App layer it is a common practice to launch the Web/App layer in minimum two or more EC2 instances. This is fault tolerant than the single EC2 instance design and offers better application stability. Usually the Web/App Servers are designed either with Stateless or State full models. Following are some of the common stateful architecture options for HA in Web/App Layer :
Following points needs to be considered while designing Highly Available and State full App Layer on AWS:
- Since AWS Infrastructure currently does not support Multicast protocol currently, the application layer software should synchronize data using Unicast TCP mechanism. Example: Java based App servers can use JGroups or Terracotta NAM to synchronize the cluster sync data information in AWS.
- In case the Web/App servers are written on PHP, .Net, Python etc then all the user and session data can be stored on centralized systems like MemCached EC2 or ElastiCache or Amazon DynamoDB .Deploy redundant ElastiCache Clusters in different Availability Zones for HA in AWS.
- ElasticIP based App Server switch will take ~120 seconds, not recommended for mission critical environments
- Session and User data can be stored on Database as well, this methodology should be carefully evaluated for response latency before implementing.
- Uploaded User files and documents should be stored on common NFS or Gluster Storage Pool or Amazon S3
- Enable Session Sticky Policy in Amazon ELB or Reverse Proxies if Session Synch is not configured. This approach offers HA but not fail over transparency in App layer.
Related Articles : AWS High Availability Patterns Series
1 comment:
windows High Availability solution in the cloud is an interesting topic and something that all enterprise customers can learn something about.
Post a Comment