您的位置:新葡亰496net > 服务器网络 > 新葡亰496netAWS灾难恢复白皮书,从支付宝故障看

新葡亰496netAWS灾难恢复白皮书,从支付宝故障看

发布时间:2019-09-23 02:38编辑:服务器网络浏览(61)

    BKJIA独家特稿】我们在上一篇文章讲述了服务器扩容的事前准备注意事项,这点非常重要,因为如果准备充分,相关的部署也会一帆风顺。但是有时候,服务器扩容还是会出现意想不到的事情,这就需要我们在实施过程中时刻保持警觉,并注意相关规则。我们今天就来讲述一下服务器扩容注意事项中的事中实施篇。

    BKJIA独家特稿】2009年10月29日15:30分很多淘宝网的淘友们突然发现支付宝不能使用了,官方的解释是“系统紧急维护”,但是很多人对这个公告并不买账,因为按照淘宝的惯例,维护多在凌晨进行,不会选择交易量疯狂的下午,更严重的是很多买家付款后系统仍显示“待付款”,于是很多人都纷纷猜测淘宝网已被黑客光顾?

    BKJIA独家特稿】我们在上一篇文章中介绍了服务器扩容的事中实施,详细介绍了服务器扩容的过程。不过服务器扩容完毕,事情结束了吗?NO,扩容的结果只是证明我们目标达成了,至于这个服务器扩容是否真正的完美无瑕,我们还需要做一系列的评估与验证。

    高可用

    服务器扩容事中实施篇A、保留原始服务

    17:00以后,淘宝网的交易流程陆续恢复正常,淘友们账户中的money也没有缩水。对于众淘友们来说,钱没少就已经皆大欢喜了,而仅仅一个多小时的中断时间也是无关痛痒的,而对于我们这些每天管理服务器的IT人士来说,这个事件给我们一个大大的警示。

    服务器扩容事后评估篇A、数据验证


    最近在做一个容灾方案,了解到AWS有一个容灾的白皮书。

    说个简单的例子,原本使用的Windows平台DNS服务不能满足现实需求,扩容时我们需要切换到新的Linux平台的DNS服务。这是很容易的工作,但是一旦切换失败,整个网络的域名解析任务将全告失败,网内所有的用户将不能通过域名来访问网络,这个损失不可谓不大。这是一个简单的服务,如果涉及到ERP、Web、VPN这个影响将更广,直接和间接的损失将不可估量。

    淘宝网给我们的最终解释是:2009年10月29日下午15时30分左右,支付宝方面发现系统运转缓慢,采取服务器紧急扩容来应对这些流量不足。我们不禁要问流量不足的问题为什么IT部门没有事先预判到?为什么要采取紧急扩容?在扩容前以及扩容后我们都需要注意哪些事项?我们不妨说一说。由于这方面所涉及的点比较多,我们把服务器扩容的注意事项分成三个篇章来讲述,首先说说事前准备篇。

    关键的一步!服务器扩容是为了满足当前日益增长的信息与数据要求,而如果因为服务器扩容而造成数据的流失这还不如不进行扩容改造!所以我们在扩容完毕后首先要验证数据的完整性和正确性,一个数据也不能丢失,这是唯一的要求,也是必须的要求。

     

    于是,今天粗略把 AWS 的容灾白皮书读了一遍,白皮书中介绍了基于 AWS 的几种容灾方案。这些方案不仅仅适用于基于 AWS 的系统,也适用于通用系统。现将其关键点摘要下来,感兴趣的同学可以读一遍原文。

    所以在进行服务器扩容时,我们不要拆除老旧服务,而是要让其离线使用一段时间,当服务完全过渡完毕,新服务能够平稳运行时我们方可拆除旧服务,这样可以保证实施过程的绝对安全。

    我们知道,不管是暴露在网外的,诸如电子商务、OA、邮箱等公用服务,还是置身于内网的活动目录、DNS、ERP等专属服务,它们的存在都是一个机构正常运行的保证,任何时候都不能出现中断的情形。而如果服务器所营造的平台不能满足当前的应用需求而必须要做出更换或者扩容的时候,我们必须做好充足的准备工作。

    服务器扩容事后评估篇B、服务验证

    高可用(High Availabiltity)

    容灾两个术语

    服务器扩容事中实施篇B、数据的存储

    服务器扩容事前准备篇A、扩容实施的时间

    假如我们这次扩容增加了5块SAS硬盘,前期工作我们已经验证了这次增加的有效性和可行性,但是这并不意味着此次增加就完全高枕无忧,我们还需要在扩容完毕后在功率上、使用效率上、整体性能上作出综合的评价,扩容是否给我们带来实质性的提高?需求我们是不是得以满足?都需要验证。

    • 应用提供持续不间断(可用)的服务的能力
    • 系统高可用性的评价通常用可用率表示

    白皮书中提到了两个关于容灾的术语( industry terms)

    防止数据丢失是服务器扩容的重中之重,哪怕是一条DHCP的保留地址也是不容有任何闪失的,因此在服务器扩容时先要做好数据的备份工作,这需要有一整套完善的、系统的备份方案,要充分考虑到数据的冗余问题,以及出现问题后的解决方案。

    每一个服务都有存在的价值,即便是短暂的停歇也会造成重大的损失,所以我们在做服务器扩容时要选择合适的时间。最佳的时间段应该在凌晨2:00~5:00之间,这个时间段使用的用户较少,服务器的短暂维护不会造成太大的影响。而如果是跨国企业,我们还要考虑到时差的因素,维护的时间最好安排在周六的凌晨进行,这基本上算是公用的休息时段。

    服务器扩容事后评估篇C、数据中心整体评估

    新葡亰496net 1.png)

    • Recovery Time Objective
    • Recovery Point Objective

    服务器扩容事中实施篇C、空间与压力

    服务器扩容事前准备篇B、冗余服务器

    这是一个全面考量的过程,如果增加了10片刀片,数据中心所需要的电力消耗必然会大幅提升,成本是一个方面,我们需要关注,但是我们更关注的是UPS的动力、支撑能力,一旦出现UPS负载过高的情形,增加UPS将是必不可少的,整个增加过程自然是前期工作,但是也需要我们后期验证作保证。

     新葡亰496net 2

    恕我孤陋寡闻,之前也参与过容灾的设计,但是关于这两个术语还是第一次知道。这两个术语在维基百科有定义,不确定是 AWS 开发者添加的词条还是很早就存在。话说我司每个产品也都有容灾方案,但是还没有人能总结出这么精准的 industry terms。所以说亚马逊作为这个领域的leader还是有道理的。

    众所周知,空间分布不均匀会造成热量不能有效散发,冷空气又不能及时的到达,纵向和横向的温度很难把握,如果将多个大功率的服务器集中放置在同一个区域,它的周边必定会有高热量出现。

    如果某一项服务只有一台服务器,那么我们必须考虑到它的冗余问题,在升级、扩容之前,我们必须为其准备一台冗余服务器,以防止扩容失败造成服务不可用的情形,因为这个冗余服务器只是临时使用,所以为了不增加成本我们可以在其他服务器上建立一个虚拟化服务器作为冗余,待扩容平稳结束,未出现任何问题时,我们即可拆除这个虚拟化冗余。

    另外,我们还需要借助无线红外热感系统来监控整个数据中心的温度变化,一旦出现居于温度过高的现象恐要危及到其他的服务器,这也是我们在扩容完毕后需要监测与改造的。

     

    1. RTO 恢复耗时

    另一方面,服务器的重量也是要考虑的,如果标准的19寸机架装满3U的机架式服务器,它的自重是非常大的,质量稍差的防静电地板或许承受不了这个大家伙。

    服务器扩容事前准备篇C、软、硬件的综合考评

    服务器扩容结语:

    造成不可用的原因

    主站点故障后,备站点恢复到达到OLA(operational level agreement )所耗费的时间。

    终上所述,服务器的摆放因素也是在实施时需要注意的。

    一个新的应用系统比如:OA、FMS)诞生往往要经过很多版本的测试,呈现给最终用户手中的必定是最稳定的正式版,但是这个新系统是不是完美无暇了呢?它和我们现行系统的兼容性如何?能否平稳过渡?这都是需要我们在正式实施前做出正确的评估和相应的测试的。

    服务器扩容不仅仅是考查IT运维团队的技术水平,也在验证这个团队的细致程度。在这个过程中,我们一定要在前期做足功课,在部署过程中胆大心细,不要担心问题的发生,遇到问题解决问题,当所有的case都完成后,做出近乎苛刻的测试,在用户发现问题前搞定它,呈现给最终用户的必须是最好的。

    • 硬件故障(各种)
    • 预期中的系统软硬件维护
    • 软件缺陷(应用代码,服务程序都可能存在bug)
    • 攻击,泄露,认为失误...等安全事件
    • 对于系统来说,不可用时间是各关键组件不可用时间的总和.....

    用另外一句话就是主站点故障后,备站点恢复到正常提供服务状态所需要的时间。

    服务器扩容事中实施篇D、其他小细节

    而增加硬件我们则要充分评价其兼容性和动能指标,对某台服务器需要大的改动比如增加多块硬盘)则需要详细计算它的最大输出功率是否满足需求,其散热是否能达到相应指标,它采用的是何种RAID技术,同其他硬盘的RAID是否能完美的融合在一起。

    如果能注意到这些服务器扩容的问题将不再是问题。

     

    站在用户视角,RTO是系统服务中断时间。

    电子设备都会害怕“静电”这个物质,如果数据中心没有防静电活动地板时我们在扩容维护时还需要释放身体的静电。举个例子:当触碰金属物质可以看到放电火花时,人体的静电电压其实已经超过3000伏,而硬盘只需1000伏左右的静电就有可能造成数据丢失,这个小细节不容忽视。

    服务器扩容事前准备篇D、数据中心的承压能力

    1. 从支付宝故障看服务器扩容一:事前准备篇
    2. 从支付宝故障看服务器扩容二:事中实施篇
    3. 支付宝服务器扩容系统瘫痪一个半小时

    提高可用性的主要手段

    举个例子,如果主站点在12:00 故障了,系统容灾的RTO时8小时,那么系统必须在20:00前恢复并正常提供服务。

    另外,我们还要说一下,服务器的扩容是一件系统的工程,如果我们准备充分又有一系列灾难恢复措施,那么就不用有任何思想上的顾虑,所有的工作只需要按部就班的进行就可以了。扩容时不要有压力,不要有负担,胆大心细!这也是实施过程中要注意的。

    如果当前数据中心不能满足日益增长的信息需求,那么仅仅是对一台服务器进行扩容改造有时是杯水车薪的,所以我们看到最多的就是多台服务器的更换或者是大量增加。

    ...

    • 冗余,Redundancy
    • 关键软硬件通过备用冗余避免故障时长时间的不可用
    • 数据软件,硬件,存储的数据,都需要通过冗余确保故障时可替换

    2. RPO 恢复时间点

    1. 从支付宝故障看服务器扩容一:事前准备篇
    2. 从支付宝故障看服务器扩容二:事中实施篇
    3. 支付宝服务器扩容系统瘫痪一个半小时

    这种部署是IT运维人员最喜欢的,因为搞IT的都迷恋于追新,况且这种部署可以有充分的实施和测试过程,相对比较容易。但是我们不要忽略一个重要问题,那就是大量的增加服务器破坏了整个数据中心的电力、散热等恒定因素,我们需要重新计算UPS的供电能力,精密空调系统的恒温恒湿能力,这也是前期准备阶段不容忽视的。

    新葡亰496net 3.png)

    主站点故障后,备站点能够恢复到过去哪个时间点的数据。

    ...

    服务器扩容事前准备篇E、通告

    新葡亰496net 4

    换句话说,备站点恢复后,与主站点相比,有多少数据丢失。

    隶属于本网的所有用户都有信息知情权,在作出服务器扩容之前我们要通过Web公告或者邮件群发等形式告知所有用户,哪个时段做维护,哪些服务不能使用,并建议用户做好相关文件的备份等工作。

    mysql高可用常见方案:

    站在用户视角,RPO时数据丢失的量。

    OK,注意到这些事项后我们即可进去正式的实施阶段,我们在下一篇文章将会讲述服务器扩容的具体实施注意事项。

    • 数据库服务在冗余实现上有其特殊性
      • 数据:服务"有状态"与数据冗余
      • 数据库可用性考虑两部分:数据可用性,服务可用性;
    • 实现方式多种多样,同一种数据也会有多种实现方案

    • 可用性目标循序渐进
      • 任何故障都不会造成数据丢失->可以较快速恢复服务(高可用)

    举个例子,如果主站点在12:00故障了,系统容灾的RPO是1小时,那么系统恢复后,其数据必须是到11:00的。也就是说允许丢失12:00~11:00 之间的数据。

    1. 从支付宝故障看服务器扩容二:事中实施篇
    2. 从支付宝故障看服务器扩容一:事前准备篇
    3. 支付宝服务器扩容系统瘫痪一个半小时

     

    所以以后在评判或设计一个容灾方案时候,先问这两个问题:

    ...

    高可用方案

    • RTO 值是多少
    • RPO 值是多少

    如果回答不上来,那么这个方案肯定是没想明白的。

     

    容灾方案

    1.mysql--基于共享存储的单活方案(不常用)

    白皮书中将容灾方案按照RTO以及成本排序,称为容灾方案图谱。

    新葡亰496net 5.png)

    新葡亰496net 6

     新葡亰496net 7

    Backup and Restore

    • SAN,方案比较昂贵;因此不常用;
    • 且数据库备用机,只是机器活着,但是没有没有起mysql服务;
      • 因为大部分共享存储或数据库是不允许同一份数据被不同数据使用的;
    • 本地数据通过RAID等手段保证数据安全

    备份恢复是最常见的一种容灾手段,将主站点数据备份到与主站点隔离的存储设备。当生产环境故障后,能够在备站点将数据恢复。

     

    AWS提供了一系列的高可靠存储服务:

     

    • Amazon S3,简单对象存储,11个9可靠性
    • Amazon Glacier,如果觉得S3太贵的话
    • Amazon VTS,虚拟磁带存储,如果要保存巨大且时间长的数据的话

    新葡亰496net,2.基于存储复制的数据冗余单活(不常用)

    使用Amazon的这些存储服务,加上备份恢复工具,就可以实现一个容灾系统。

    新葡亰496net 8

    备份示意图

    新葡亰496net 9.png)

    新葡亰496net 10

    • 存在一定浪费,备用机器一直不在用,等待主机挂掉,才会使用备用机;
    • 而且DRBD(两台机器间通过网络,备份数据),不是100%的保证数据不丢失;

    恢复示意图

     

    新葡亰496net 11

     

    Pilot Light

    3.基于集群提交通信协议的多主复制(一定场景适用)

    Pilot Light 是一个装置,这个是一个类似点火器的装置,如煤气灶的点火器,通过点火器可以把煤气灶点燃,然后就可以做饭了:)

    新葡亰496net 12.png)

    Pilot Light用到容灾系统中,要表达的意思是,在备站点部署一个服务,通过这个服务可以将整个系统运行起来。

     新葡亰496net 13

    准备

     

    备站点安装数据库服务,并建立与主站点之间的数据复制关系

     

    主站点的操作系统或文件做成 AMI ,在备站点恢复时候直接加载为EC2

    基于主从复制的高可用方案

    定期测试备站点的恢复[5]


    新葡亰496net 14

     

    恢复

    4.基于Mysql主从复制(常用,普适)

    • 使用 AMI 创建 EC2
    • 根据情况加大数据服务器的配置
    • 增加额外的数据服务器(如果有需要)
    • 配置系统(一些配置不是通过 AMI 导入就可以生效的)
    • 将 DNS 映射为备站点IP地址

    新葡亰496net 15.png)

    新葡亰496net 16

     新葡亰496net 17

    Warm Standby

     

    Warm Standby 是在备站点复制了主站点,但是它们还是有差别的:

    • 备库,在线上也会提供服务,避免浪费;
    • 而主从复制,也保证了数据不会丢失。
    • 备站点服务运行但是不对外提供服务
    • 备站点的服务器配置是最小配置(These servers can be running on a minimum-sized fleet of Amazon EC2 instances on the smallest sizes possible) ( fleet of Amazon EC2 好霸气~~)

     

    准备

    mysql主从复制高可用方案需要改进的问题

    • 备站点安装数据库服务并同步数据
    • 备站点申请最小配置的EC2安装并app
    • 定时执行app的升级和补丁,保持与主站点一致
    1. 主从服务器各自有IP地址,发生主从切换后应用需要修改重启;
      • 新葡亰496netAWS灾难恢复白皮书,从支付宝故障看服务器扩容三。如何让应用快速找到从库;VIP/DNS
    2. 人工判断主库是否故障再发起切换需要花较多时间
      • 如何自动探知;监控探知并自动VIP/DNS;
    3. 主从复制存在客观延迟,切换后可能造成事务数据丢失。
      • 由于网络延时,如何避免数据丢失。

    新葡亰496net 18

     

    恢复

    1.为了避免应用人工修改切换IP,引入VIP(virtual ip)漂移方案:

    • 增加EC2数量(横向扩展)(扩成与主站点一致)
    • 增加EC2配置(纵向扩展)(扩成与主站点一致)
    • 增加数据库实例数(扩成与主站点一致)

    新葡亰496net 19.png)

    切换 DNS 映射到备站点

    新葡亰496net 20.png)

    新葡亰496net 21

    新葡亰496net 22

    Multi Site

     

    Multi Site 指的是 active-active 的容灾方案。主备站点同时对外提供服务,由DNS根据负载决定将请求转发到哪个站点。

    新葡亰496net 23

    准备

     

    • 将主站点系统复制到备站点,服务器和配置都相同
    • 在DNS上配置路由策略

    方案二:

    新葡亰496net 24

    DNS,应用服务器,使用域名;

    恢复

    平时,将域名注册在主库上,而主库挂掉,将域名注册到从库就可以了;

    • 手动切换(DNS上切换)
    • 或者配置DNS failover

     

    新葡亰496net 25

     

    Fail Back

    2.为了减少人工介入处理的时间开销引入自动探活处理机制

    当主站点故障修复后,我们还需要将服务切换到主站点,这个过程称为 fail back 。

    新葡亰496net 26.png)

    不同的容灾方案,fail back的方法不一样。

     新葡亰496net 27

    Backup and Restore

    高可用中间层与RDS

    • 冻结备站点的修改操作
    • 备份数据
    • 恢复到主站点
    • 切换DNS指向主站点
    • 解冻
    • VIP/DNS解决 应用切换问题
    • 监控和管理服务器解决自动判断故障切换和VIP/DNS漂移
    • VIP/DNS管理 探活 主从关系切换 = 高可用中间层
      • 透明切换管理 靠谱数据探活 使用切换 = 高可用中间层
    • 云环境 高可用中间层 底层数据库=一种PaaS=基本RDS、

    Pilot light, warm standby, and multi-site

     

    • 冻结备站点的修改操作
    • 将数据复制方向改为从主向备
    • 切换DNS指向主站点
    • 解冻

    高可用中间层

    【编辑推荐】

    • MHA
      • 自动选择复制延迟最小的从节点并试图补全日志(但大部分主机故障下行不通)
      • 通常要求两从以上,会进行主从关系切换
      • 不提供VIP管理方案
    • MMM

      • 提供了基本的VIP管理功能
      • 适合双主配置的一对主机,不会主动切换主从关系
      • 不支持主从数据延迟判断和补全

     

    一般使用MHA,开源;

     

     

    3.mysql主从复制延迟

    为什么日志传输延迟

    为什么主从复制,主从库会数据不一致;

    新葡亰496net 28.png)

    新葡亰496net 29

     

    解决方案:

    mysql半同步技术:

    主库一次commit,要等到主库持久化完成,以及从库也持久化完成,才给主键放回commit成功。

     

    但是问题:

    主库等待从库的时间是不可控的;

    主库发现从库写不进去了,可以等待几秒,之后主库复制自动降级成异步复制;但这也可能导致数据不一致;

    新葡亰496net 30.png)

     新葡亰496net 31

    较完善的mysql高可用方案

    • 半同步复制 高可用中间层 VIP管理方案
    • 高可用中间层=靠谱探活 主从切换 使用VIP管理的接口

     

    例如:

    • 半同步复制 MHA(高可用中间层) Keeplive(VIP管理方案)
    • 半同步复制 RDS

     

     

    总结


     

    • 高可用指标至少3个9目标4个9
    • 高可用核心就是使用冗余
    • 数据库高可用两个部分
      • 数据可用性--数据有状态
      • 服务可用性
    • 高可用方案

      • 基于共享存储SAN的单活方案
        • SAN,设备昂贵
        • 单活,备用机浪费,因为同一份数据不能被不同mysql实例使用;
        • 本地数据可以通过RAID等手段保证
      • 基于DRBD存储复制的数据冗余单活

        • 基于SAN方案的改进,不使用SAN设备
        • 单活,备用机浪费
        • DRBD基于两台机器间通过网络备份数据,数据不能100%保证
      • 多主复制--mysql cluster

    • 基于mysql主从复制(常用,普适)

      • 备份,在线上可提供只读服务,避免浪费;
      • 主从复制,也保证了数据不会丢失
    • 基于mysql主从复制的问题

      • 主从服务器各有IP地址,发生主从切换后应用需要修改重启;
        • 使用VIP(virtual IP)/DNS管理方案,当发生切换是,只需要将VIP从主库漂移到从库,对应用来说是透明的。
      • 人工判断主库是否故障,在发起切换需要时间长

        • 使用监控服务器,自动靠谱探知 自动主从切换
      • 主从复制存在客观延迟,切换后可能造成事务数据丢失

        • 使用半同步复制技术,但也要考虑到从库宕机,主库应该自动降级成异步复制;
      • 解决问题后的mysql高可用方案

        • VIP管理方案 高可用中间层 半同步复制
    • 高可用中间层

      • VIP/DNS管理 靠谱探活 主从关系切换=高可用中间层
      • 云环境 高可用中间层 底层数据库=一种paas=基本RDS
      • MHA/MMM
    • MHA

      • 自动选择复制延迟最小的从节点并试图补全日志(主机故障下行不通)
      • 自动探活
      • 自动主从切换
      • 不提供VIP管理方案,但提供使用VIP方案的接口

     

     

     

     

    本文由新葡亰496net发布于服务器网络,转载请注明出处:新葡亰496netAWS灾难恢复白皮书,从支付宝故障看

    关键词: