CDP:Multi-Server Pattern

From AWS-CloudDesignPattern
Jump to: navigation, search

Server Redundancy


Problem to Be Solved

You can improve availability in a variety of ways and in various different layers. On the disk layer, for example, you may use a RAID configuration, and on the network layer you may provide spare lines.

The same is true for servers as well, where you can use multiple physical servers to provide redundancy. Understand, however, that simply increasing the number of servers does not necessarily create a redundant structure. Because the materials required for providing redundancy, such as server machines and load balancers, involve considerable expense, sometimes when you take cost effectiveness into consideration, the best action is no action.

Explanation of the Cloud Solution/Pattern

Provide multiple virtual servers in parallel, using the Load Balancer provided by the AWS Cloud service to distribute the load appropriately. This is known as a "Multi-Server." While you can achieve this in an on-premises system, you can structure this environment substantially more easily in the AWS Cloud than ion-premises.

While n the past the load balancer itself has been an expensive appliance, with the AWS Cloud you do not need to go through the expense of purchasing or maintaining the load balancer. With the AWS Cloud, the Load Balancers are also on a pay-as-you-go basis. In consideration of redundancy, you can also switch the configuration from a single high-performance server to a Multi-Server arrangement, with each server having somewhat lower processing capacity.


Use the AWS Load Balancer service, "Elastic Load Balancing" (ELB). Once the ELB has received a processing request for an EC2 instance, the ELB distributes processes appropriately to the instances bound thereto. You can use the ELB health check function (a function for confirming whether or not an EC2 instance is operating properly), so as to not distribute a process to an EC2 instance that is not operating properly. As a result, you can make sure that the processing can continue using the remaining EC2 instances even if there is a failure in one EC2 instance.


  • Launch an EC2 instance and set up the operating system, and the like.
  • Apply the Stamp Pattern, to launch multiple EC2 instances.
  • Launch ELB and bind the multiple EC2 instances.
  • Set up the options so as to use the health check function to check the bound EC2 instances.




  • Even if there is a failure in one EC2 instance, the system as a whole can continue to operate.
  • The combination of ELB and Auto Scaling makes it possible to run a constant number of virtual servers (EC2 instances), even when a failure occurs. For example, if the setup is so as to have a minimum of three virtual servers operating, then if one virtual server were to fail, another virtual server would be added automatically to always ensure three virtual servers. In this case, you must specify the Amazon Machine Image (AMI) in advance, and specify that the EC2 instance is to be launched from that AMI. <ref group="Related Blog"> Template:Related Blog </ref>


  • Because multiple EC2 instances are used in ELB, the cost is more than for a single-EC2 configuration.
  • Use caution when there is data that must be shared on the middleware level or the application level. For example, because you have to share session information between multiple EC2 instances, you have to share sessions using a session database, or to use StickeySession. See the StateSharing Pattern.
  • Always use an N+1 configuration (where one spare virtual server is always available). For example, if you need three virtual servers for the required processing capacity, add one spare server to use a four-server configuration to be able to handle one of the virtual servers going down.
  • Note that when you provide redundancy in databases, you may have issues with data synchronization. See the DB Replication Pattern.

The Multi-Server pattern increases availability through providing a structure that always has redundancy, but there is also a technique where you can use the Floating IP pattern rapid recovery when there is a failure.

Personal tools