1. AWS
1.1 AWS 地理组件概况
AWS 提供三种地理性组件:
- Regions:区域,即AWS提供云服务的一个区域,其目的是为了用户能就近接入,降低网络延迟。
- Availability Zones:一个 region 内至少两个通常三个可用区。其目的是为了搭建高可用架构。一个 AZ 通常是一个数据中心,拥有独立的基础设施。AZ 之间利用低延迟光纤网络互联。
- Edge Locations:AWS 提供的CDN 服务 CloudFront 提供给用户的分布在全球的接入点。Edge POP 点独立于region 和 AZ。
图1:AWS 区域与可用区之间的关系
图2:AWS region 与 Edge POP
1.2 AWS 各服务与地理性组件的关系
AWS 少量服务是全局性的,也就是不限于特定region,比如下图中的 IAM、SES、S3 和 CloudFront;部分服务是区域性的,也就是其作用范围在某个特定区域内,比如下图中的S3、AMI;部分服务是可用去性的,也就是其作用范围在某可用区内,比如下图中的 EC2和EBS。
服务 | 子服务 | 全局性 | 区域性 | 可用区 | 备注 |
IAM(AWS Identity and Access Management) | Users, Groups, Roles, Accounts | Y |
|
||
Key Pairs | Y | Amazon EC2 created key pairs are specific to the region | |||
RSA key pair | Y | RSA key pair can be created and uploaded that can be used in all regions | |||
Virtual Private Cloud | VPC | Y |
|
||
Subnet | Y | Subnet can span only a single Availability Zone | |||
Security groups | Y | A security group is tied to a region and can be assigned only to instances in the same region. | |||
VPC Endpoints | Y | You cannot create an endpoint between a VPC and an AWS service in a different region | |||
VPC Peering | Y | VPC Peering can be performed across VPC in the same account or different AWS accounts but only within the same region. They cannot span across regions | |||
Elastic IP Address | Y |
|
|||
EC2 | |||||
Resource Identifiers |
Y |
|
|||
Instances | Y |
|
|||
EBS Volumes | Y |
|
|||
EBS Snapshot | Y |
|
|||
AMIs (Aamzon Machine Images) | Y |
|
|||
Auto Scaling | Y |
|
|||
ELB(Elastic Load Balancer) | Y |
|
|||
SSH Public Keys | Y | 保存在region内,AWS不跨region复制或同步keys。 | |||
Placement Groups | Y |
|
|||
S3 | Y |
|
|||
Glacier | Y | 要迁移 Glacier 中的数据的话,需要经过几个步骤:1. 将 Glacier 中的数据restore到 S3 中。2. 利用 S3 Copy 功能将数据拷贝至另一个region 3. 利用 S3 lifecycle policy 将 S3 中的数据转移到新的region的 Glacier 内 4. 将原region的 Glacier 中的数据删除。 | |||
EFS(Elastic File System) | Y | 有两种数据在region间的迁移途径。1. 将EFS中的数据拷贝至 EBS,然后利用 EBS Snapshot Copy 功能将数据拷贝至另一个region内,再将数据从 EBS 拷贝到 EFS 内。 2. 将 EFS 中的数据拷贝到 S3 中,然后将利用 S3 Cross-region Replication 功能将数据拷贝至另一个region,再从S3 拷贝到EFS。 | |||
Route53 | Y | Route53 services are offered at AWS edge locations and are global | |||
RDS | Y | Y |
|
||
ElastiCache | Y |
|
|||
RedShift | Y |
|
|||
EMR | Y |
|
|||
Elasticsearch | Y | 为 ES domain 创建一个 snapshot,它会被保存到 S3 内。再利用 S3 做跨region 复制。再在新region内将数据从S3 恢复到 Elasticsearch 中。 | |||
SQS(Simple Queue Service) | Y | SQS queues 位于region内。需要利用应用,将消息从源region 的 queues 中导入目的 region的 queues 内。 | |||
SNS(Simple Notification Service) | Y | SNS topics 位于region 内 | |||
Auroa | Y | 在另一个region 内创建一个 Aurora Cluster 作为 Read Replica。一旦创建后,Amazon RDS 对原 Aurora cluster 做snapshot,然后将 snapshot 发送只 Read Replica。 | |||
DynamoDb | Y |
|
|||
WAF | Y | Web Application Firewall (WAF) services protects web applications from common web exploits are offered at AWS edge locations and are global | |||
CloudFront | Y | CloudFront is the global content delivery network (CDN) services are offered at AWS edge locations | |||
Storage Gateway | Y | AWS Storage Gateway stores volume, snapshot, and tape data in the AWS region in which the gateway is activated | |||
SES(Simple Email Service) | Y | SES 有 regional endpoint。你的应用既可以使用与它相同region内的 SES服务,也可以利用其它region内的SES服务。当然了,这里面需要考虑跨region延迟问题。 |
1.3 区域性和可用区性的实例的跨区域复制
AWS S3 的数据位于某个区域内,但是可以进行跨任意区域迁移。因此,很多区域性和可用区性的数据都利用S3该功能做跨区域数据迁移。
1.3.1 S3 跨区域复制
当数据发送到S3 以后,数据会以对象形式在区域内的多个可用区内保存。但是,每个区域的S3依然有单点故障风险。当一个region故障后,该区域的S3服务将变得不可用。要避免该问题,AWS提供了 Amazon S3 Cross-Region replication (CRR) 功能。它能够在不同的可用区之间异步地同步S3 bucket 中的数据。
1.3.2 区域之间的数据复制
下图中的 AMI、EBS snapshot 和 RDS snapshot 都是保存在 S3 之中,因此都能够利用 S3 的跨区域复制能力复制到其它区域。
1.3.2.1 EBS 的跨区域迁移
EBS 是可用区性的。要将某个 EBS 实例拷贝到另一个region,需要利用 S3 的跨区域复制能力。
(1)为 EBS 创建 snapshot,它会被保存在 S3 内。
(2)利用 EBS snapshot copy 功能将 EBS 快照拷贝到另一个region中
(3)在新的region 中从该snapshot 上创建一个新的 EBS 实例
1.3.2.2 EC2 实例的跨可用区迁移
(1)为 ECS 实例创建 AMI。AMI 在整个区域内可见,因此肯定可以在另一个可用区内使用
(2)在另一个可用区内,利用该 AMI 创建一个新的实例。
1.3.4 数据库跨区域复制数据
AWS 的数据库服务提供了区域内跨可用区容灾和跨区域容灾能力。以 AWS Oracle 和 MSSQL 服务为例:
1.4 灾备
AWS 把灾备分为四种场景:
1.4.1 Backup & Restore 备份和恢复
将数据备份到AWS上:
1. 利用 S3 和 Glacier 组成多级别的备份环境
2. AWS Storage Gateway 能够将本地环境中的数据备份到 S3 中。
3. AWS EBS 卷、RDS 实例、Redshift 的快照(snapshot)会被保存到 S3 中。
4. 恢复时,利用从 AMI 创建EC2 实例,从S3中恢复数据来快速恢复运行环境。
1.4.2 Pilot Light 最小环境
上述的备份和恢复方案往往会花费较长时间。Pilot Light 则在AWS上创建最小运行环境,它包含业务系统中最核心部分,比如数据库。这会节省恢复时间,因为系统中最核心部分已经在运行,而且数据是最新的了。而不经常更新部分,比如操作系统和应用,则可以定期打包到AMI中。
恢复时,可以从AMI 中创建EC2实例,可以按需对最核心部分进行扩容以支撑生产环境。
1.4.3 Warm Standby Solution in AWS 热备环境
该场景中,一个小规模的完整业务环境会运行在AWS中。这环境虽然规模不够大,但功能全面。
而在恢复阶段,只需要对灾备环境扩容(包括水平扩容和垂直扩容)和切换DNS(手工的或者利用智能DNS自动的)即可:
1.4.4 Multi-Site Solution Deployed on AWS and On-Site 本地和AWS上active-active部署
准备阶段:
- 做法是在AWS上建立一套环境复制你的本地环境
- 考虑数据同步方式,是异步的还是同步的
- 考虑 RTO 和 RPO 的要求
- DNS 可以两边不同比率分配流量
- 成本取决于在AWS上环境的配置
恢复阶段:
- 更新DNS,使得AWS上的环境支持所有流量
- Application Server 需要能够在切换后使用本地的数据库
- 考虑扩容要求
1.4.5 多站点部署需要考虑的因素
1. 数据同步:当向远端同步数据时,需要考虑到:
- 站点间的距离 - 距离越远,往往延迟越高
- 可用的带宽
- 应用所需的数据同步速率 - 这速度需要低于可用带宽
- 同步技术 - 同步需要是并行的,以提高效率
- 同步方式 - 同步的和异步的。AWS RDS 在可用区之间是同步的;
- 同步目标 - 是往一个目标站点同步,还是往多个目标站点同步
2. Failing Back from a Disaster 从灾备站点回到主站点
当主站点恢复以后,你往往需要将运行环境从灾备环境切换到原来的主环境,此成为 fail-back。对于不同的灾备场景,有不同的做法。
备份和恢复:
- 冻结向 DR site 的数据更新
- 做备份
- 将备份 restore 到主 site
- 将用户引流到主site
- 解冻数据更新
Pilot light, warm standby, and multi-site:
- 从 DR site 往主site 做数据同步,直到主site数据一致
- 冻结向 DR site 的数据更新
- 将用户引流到主site
- 解冻数据更新
1.4.6 灾备计划
需要有完整的灾备计划。除了实现上述某种灾备方案外,还需要考虑到以下几点:
- 测试:一旦DR site 准备就绪,需要有完整的测试来验证
- 持续的监控和告警:对 DR site 做持续监控,并及时处理问题
- 备份:即使切换到DR site,还是要做常规备份
- 用户访问:要保证用户访问 DR site 的安全性