问题
In my work I need to move some existing Enterprise Java applications to AWS. I have gone through many pages on aws.amazon.com and also googled enough. Also, I have tried to go through all the related questions at stackoverflow. All these things made many things clear, however, I am still having some confusion. Here is our application structure:
- It is a Spring based application which uses Spring MVC as its presentation layer and plain Java Interfaces and Classes for handling business and data logic.
- MySQL is used for persistence.
So, the application architecture is simple enough. However, the catch is that we need to deploy many instances of this application. This count is currently 15 and can go beyond 30. One more point is that all these instances share a common database.
Now here is what we need to achieve by moving to AWS:
- Higher fault tolerance for the application. Recently we faced a server/power failure in dedicated hosting causing some hours of down time.
- Higher performance for all instance of the application in terms of response time and throughput.
- Higher fault tolerance for MySQL. Application instances went down on one of our servers recently due to some hardware(Hard Drive) which basically caused MySQL to stop unexpectedly. The whole file system on the hard drive went read only causing malfunctioning of the application instances hosted on that server.
- Obviously reducing the total cost and overhead of infrastructure management.
As far as I am able to understand AWS infrastructure till now, here is what we would need in AWS for our setup:
- 4 instances, each hosting about 10 application instances, of some EBS based LINUX AMI with Tomcat and MySQL installed on that.
- I am guessing that we would also need 1 instance for fault tolerance for each of those 4 instances totaling 8 instance in all.
- All of the server instances would have about 160GB of EBS.
- 4 Elastic IPs
- 4 Elastic Load Balancers
- Other stuff like snapshot etc
Now here are my questions:
Do I really need to have that extra server instance(for fault tolerance) for each main server instance, considering the face that EBS are automatically backed up by AWS and they would provide new EBS with same data in case of hardware failure?
How would I share database among all server instances (4x2) in above scenario? One option I am seeing is to implement MySQL clustering among those server instance. Lets say, the MySQL cluster would contain 1 Management Node, 3 SQL nodes and 4 Data Nodes. However, in this case maintaining the cluster would be an additional overhead for us and this may not be accepted as we would like get rid of infrastructure management.
Do I need to have RDS instead for database and remove MySQL instances from all server isntances (4x2)? If yes, would I need to buy RDS instances in addition to EC2 instances (I think, if I need to buy separate instances for RDS then cost of total infrastructure would increase at least by 75%.) or the RDS instances also gives compute units for application development thus reducing the total number of instances for application deployment?
In case of RDS implementation, does one really need EBS based EC2 instances? If we can some how remove EBS requirement from EC2 instances with RDS instances in place, we can reduce the total cost.
Any help would be appreciated and please let me know if I am not clear to specify my problem and need more clarification for any point.
回答1:
I am no infrastructure expert, but I have some experience on AWS, and I hope I can help with at least some of your questions. My background does not allow me to give you any advice about sizing of your infrastructure, but I can help advising on the kind of infra.
First of all, I would definitely go with EBS. Besides being physically separate from your application server, it is also has high reliability and high availability. I can tell you it saved me a couple of times. Although I said I would not tell you anything about sizing, I don't think you would need the extra 4 "fault tolerance" instances, but maybe you could keep some 2 instances ready to take off traffic, just in case.
Regarding your DB, you should definitely go ahead and use RDS for MySQL (http://aws.amazon.com/rds/mysql/). They give you pre-configured nodes, auto-patching, auto-backup, auto-replication and one-click scaling, at a (IMHO) small price. All of these features are ready, out-of-the-box, for MySQL. You can also use metrics and monitoring, it is all included. RDS do not give you computing units, but it is a good practice to keep them separate in AWS. You can also have a setup with 4 EC2 Tomcat nodes + 2 RDS nodes. It is just a matter of sizing :)
If you have already read about Amazon Elastic Load Balancing, it looks perfect for your solution. You can attach some EC2 nodes to each of your ELB nodes, and forget about load balancing. It just works, and you can also configure sticky sessions if you want. I don't know, though, how many ELB nodes you should choose, but be aware of one problem: you can only add EC2 nodes from the same geographic region (e.g. US east coast) to the same ELB. It is not possible to balance traffic between, for example, a Tomcat in West Coast and another one in East Coast. If you choose to distribute your nodes across multiple regions, you will need to come with another LB solution outside of Amazon.
My final advice: go ahead with ELB + EBS-based EC2 + RDS. It will simplify a lot your monitoring, deployment and maintenance, and the cost tends to be much lower. You are probably more aware of how many of each kind of node you will need, but don't be afraid to miss, because it is very easy to upscale or downscale your infra on AWS.
来源：https://stackoverflow.com/questions/7219720/amazon-cloud-configuration-for-java-ee-web-app-with-mysql