转载

每月只需1美元:利用Amazon AWS实现灾难恢复

我曾经亲身经历过一次突发事件,某家电子商务网站近七天内的数据遭遇丢失、站点整体也在八天当中彻底陷入瘫痪(而且很明显,工作人员在这八天中一直在努力寻找最新的备份内容,并希望借此执行恢复操作)。这一事件发生之后,我开始研究如何才能构建起一套永久性的灾难恢复(简称DR)环境。这套环境需要具备成本较低、且能够在出现设施出现故障时以最低程度时间/精力投入实现恢复等能力。在今天的文章中,我们将共同了解如何利用AWS构建起这样一套灾难恢复解决方案。根据我的当前状况,其每月运行成本不足1美元。如果需要,整个恢复周期只需要30分钟,而且能够涵盖最高24小时之内的数据丢失问题。

该电子商务网站基于LAMP(即Linux Apache MySQL加PHP)。这里介绍的步骤共分为两个部分——准备步骤与恢复步骤。准备步骤包括首交在AWS当中设置环境及数据副本。恢复步骤则包括在尝试上线这套灾难恢复环境时的各项“待办事宜”。

准备步骤:

1)利用Amazon Linix AMI启动一个新的EC2微实例,随后安装PHP、Apache以及MySQL。复制网站代码及数据。测试并确保其运行状态与预期相符。创建镜像快照,这将成为该环境恢复过程当中的重要依据。

2)创建一套规程,并将全部日常数据库备份复制到Amazon S3存储桶当中。要完成这项任务,我们需要在生产环境下安装AutoMySQLBackup工具,而后添加一个cron任务以调用 automysqlbackup 脚本、从而在每天午夜时段创建数据库备份。大家可以通过以下URL获取该工具:

http://sourceforge.net/projects/automysqlbackup/

3)在备份完成之后,cron任务会将该备份文件复制到一套Amazon S3存储桶当中。要实现这一目标,我们需要在生产服务器上安装AWS PHP SDK,同时创建一套php脚本(利用S3客户端)以保证系统每天午夜时刻将数据库备份文件复制到S3存储桶内。如果大家希望了解与AWS PHP SDK安装相关的指令以及S3客户端编写方法,请查看以下AWS链接:

http://aws.amazon.com/developers/getting-started/php/

以上第二与第三步旨在确保日常数据库备份副本始终存在于远程高可靠性站点(也就是AWS S3)当中。

恢复步骤:

接下来的各个步骤阐述了如何在AWS当中构建辅助环境。

  1. 通过之前在准备步骤中创建好的Gold AMI启动EC2实例。
  2. 从S3上下载对应数据库备份文件,并将其导入至MySQL。AWS提供能够调用S3存储桶当中下载文件(即对象)的命令行API。举例来说,以下3行用于从S3存储桶处下载数据库备份并进行导入:

    • aws s3 cp s3://bucket-name/db_backup.sql.gz db_backup.sql.gz
    • gunzip db_backup.sql.gz
    • mysql -u username -p database-name < db_backup.sql

    其中db_backup.sql.gz部分为我们在负责将副本交付至S3存储桶的上传脚本内所使用的S3对象名称。

  3. 为AWS Route 53中的域创建托管区。AWS利用该托管区将流量路由至EC2实例处。
  4. 将域名注册供应商的名称服务器指向该AWS名称服务器。为了找到该AWS名称服务器,点击对应托管区记录,其中名称服务器的值将被显示在AWS控制台的右侧。在完成名称服务器更新之后,系统可能需要耗费约30分钟到数小时进行全局DNS更新。在DNS更新完成之后,网络流量的路由走向将由此发生变化。

上述方案的总体使用成本为每月1美元到10美元之间。以下表格提供的是本示例的基本或者最低使用成本(每月0.95美元)。

每月只需1美元:利用Amazon AWS实现灾难恢复

这套解决方案的起效关键在于保证核心AMI镜像始终得到更新。如果相关应用程序代码一直在频繁变更,那么建议大家准备一套永久保留实例。整套方案能够用于预生产环境,不过其运行成本将增加到每月5美元,具体如下:

每月只需1美元:利用Amazon AWS实现灾难恢复

在本示例中,AWS发挥了巨大的实践价值。保存在任意给定Amazon S3存储桶中的数据会在跨地理区域的多座数据中心之间往来复制,而这正是我们实现高可用性水平的必要手段。

每月只需1美元:利用Amazon AWS实现灾难恢复

原文链接: https://www.linkedin.com/pulse/using-amazon-aws-dr-from-just-1month-devesh-gupta

正文到此结束
Loading...