3个月以来,豆子把AWS核心的基本服务都上手过了一遍。在了解各个服务功能的基础上,现在终于整合ELB,Auto Scaling,RDS,CloudFront等功能实现一个高可用(High availabilty)的WordPress网站了。相对于豆子最开始创建的那个WordPress Blog,所有的LAMP stack都在一台虚拟机上,如果挂了又没有及时备份,就会丢失很多数据。这些都是血的教训啊。(参见博文 http://beanxyz.blog.51cto.com/5570417/1535770 )



下面这张很NB的截图来自AWS,很详细直观的解释了AWS的高可用结构。



AWS - 创建一个高可用的WordPress 博客 (一)_第1张图片

里面每一个单块服务豆子都尝试过,现在要把他们整合在一起。


用户通过Route53 DNS解析 CloudFront的Edge Server 地址实现快速访问,Orgin Server地址则指向 S3 bucket(参见 博客 http://beanxyz.blog.51cto.com/5570417/1532813)


然后指向我们的Elastic Load Balancer,这里会自动分流到不同AZ,通过Auto Scaling的功能自动根据CPU负荷增加或者删除服务器。(参见博客 http://beanxyz.blog.51cto.com/5570417/1536261 )


然后Web Server可以指向中间层,Application Server 或者直接指向我们的数据库服务器 。

RDS 实例通过Multiple AZ实现自动同步和Failover (参见博客 http://beanxyz.blog.51cto.com/5570417/1531843 )



比照上面的结构图,我们的高可用的WordPress 网站基本需求是这样:


  1. 用户通过DNS解析Elastic Load Balancer的URL,ELB转发请求到其中任何一台Word Press的EC2实例,该Web Server通过3309端口访问远程的MySQL RDS实例;


  2. MySQL通过Multiple-AZ实现高可用;


  3. Web Server通过ELB实现高可用;


  4. 根据CPU或者其他负荷标准,ELB里面可以自动增加,删除EC2实例;


  5. Auto Scaling 创建的服务器必须自动更新到最新版本;


  6. 博客涉及的所有的图片和视频必须保存在S3 Bucket上面,并通过CloudFront实现CDN加速,博客的媒体资源URL自动重定向指向CDN的地址进行解析。


豆子的参考设计主要来自Linux Academy的培训视频。下面一篇博客我们来一一实现以上的配置要求。


传送门