多AZ的高可用方案

来源:互联网 发布:标准型矩阵 编辑:程序博客网 时间:2024/03/29 18:03

AWS在每个Region都有多个AZ(Availability Zone)多个AZ之间物理隔离,供电也是独立的,这样部署业务时,可以充分利用多AZ实现高可用方案,避免亚马逊底层机房事故导致业务中断。

(1)前端ELB层,可以将ELB设置成跨多个AZ,即将需要的子网(Available Subnet)添加进ELB就行,(点击Available Subnet前面的绿色加号按钮),这个时候,每个AZ至少选择一个Subnet,ELB就可以将流量分发到不同AZ上的实例。有一点需要注意的是,ELB是将流量均分到不同AZ中的,而不会考虑哪个AZ中实例多哪个少,因此部署的时候尽量在不同AZ均匀分布计算资源。实质上,ELB服务包含多AZ后,会在不同AZ创建不同LB实例,其私网IP是不同的,access日志中能看到,只不过这些LB会使用一个统一的url(endpoint)。因此可以在Route53中将域名CNAME或者Alias到ELB的endpoint上。

(2)web server服务层,添加到ELB中的实例,也可以均分到不同的AZ,这是一个高可用方案的基本措施。如果实例已经运行在同一个AZ中了,可以通过将线上服做成AMI(注意勾选No reboot),然后基于此AMI再在别的AZ中创建同样的实例,并加入到ELB实例组中。你可以随时将实例退出或加入ELB实例组。

(3)缓存层,ElasticCache服务不管是Memcached还是Redis,目前都不支持Node节点跨AZ,因此需要在不同AZ中创建单独的ElasticCache实例和节点,同事需要程序代码上做点改动。允许配置多个缓存实例,例如redis-master,redis-slave。相信不久AWS就会推出自动跨AZ的ElasticCache(即统一的endpoint,可以在不同AZ创建node)。

(4)DB层,读写分离是一个比较好的方案,一写多读,多个读实例用内网ELB做负载均衡。但是写还是单点的,建议在不同AZ创建一个热备,作为DB slave(EC2做DB的方案);如果使用RDS服务的话,就更方便一些,你可以使用跨AZ的replica(创建RDS实例的时候可以选择Multi-AZ),好像最近有添加了跨Region的“Multi-AZ”,还可以使用RDS的读写分离功能,创建多个读实例,然后这些读实例可以加入到一个内网的ELB中实现负载均衡。

(5)周边,Route53服务提供4个nameserver,基本不用担心单个nameserver宕机导致域名解析故障(前提是你把域名解析迁移到AWS Route53上);S3据说提供12个9的高可用,数据和日志等放在上面不同担心丢失问题,唯一需要担心的是数据安全(控制好访问权限);CDN(CloudFront + S3)可靠性也比较高。ELB后端的实例,如果只允许通过ELB访问的话,EIP完全是可以不要的,卸载EIP减少安全隐患。

0 0
原创粉丝点击