+86 135 410 16684Mon. - Fri. 10:00-22:00

云环境下的容灾

云环境下的容灾

云环境下的容灾

  • 什么是容灾?
    简单的说是对灾难的而应对策略。比如火灾,盗窃,人为损坏,火山,地震,洪水,战争,飓风等自然灾害或者人为灾害。
  • RTO/RPO
    RPO(Recovery Point Objective): 指灾难后可能恢复到的时间点。涉及丢失业务数据的多少。
    RTO(Recovery Point Time): 指灾难发生后,业务恢复所需的时间。
    revover
  • 容灾的分类
    按RTO分:cold, warm, standby
    按RPO分:同步同步,异步同步,离线同步
    按业务数据同步技术:基于主机复制,基于阵列复制,基于存储网络,基于虚拟机内代理,基于应用本身能力(如数据库复制能力)
  • HA与容灾的区别
    HA主要处理单组件的故障,DR则是应对大规模的故障。
    也有一些从网络视角区分两者的,LAN尺度的认为是HA的范畴,WAN尺度的任务是DR的范围。
    从云的角度看,HA是一个云环境内保障业务持续性的机制。DR是多个云环境间保障业务持续性的机制。

AWS容灾方案

AWS的方案从用户场景看有如下几类:

  • cold
    是三种方案中费用最低,RTO最长(>1 day)的方案。
    使用S3做数据备份,灾难发生时,重新申请虚拟机,利用备份数据恢复。
    数据备份可以使用普通的http, vpn, aws directconnect等链接,快照/备份技术进行业务数据的同步。
    687474703a2f2f63646e2e626c6f672e63656c696e676573742e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30332f4177734261636b7570526573746f7265312d353132783238312e706e6 687474703a2f2f63646e2e626c6f672e63656c696e676573742e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30332f4177734261636b7570526573746f7265322d353132783338302e706e6
  • pilot light
    相对经济的一种容灾方案,RTO时间(<4hrs)一般。
    使用replicate/mirror方式进行业务数据同步。
    容灾端虚拟机在灾难发生后启动。
    687474703a2f2f63646e2e626c6f672e63656c696e676573742e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30332f41777350696c6f744c696768744f66662d353132783333362e706e6 687474703a2f2f63646e2e626c6f672e63656c696e676573742e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30332f41777350696c6f744c696768744f6e2d353132783332362e706e6
  • standby
    相对较贵的一种容灾方案,RTO时间(<1hrs)最好。
    使用replicate/mirror方式进行业务数据同步。
    容灾端虚拟机一直运行中,但是不提供服务。
    这种方案分两类,一类是容灾端虚拟机与生产端虚拟机等量,切换后所能提供的业务容量相同。另一种是容灾端保持较小的容量,切换后能提供业务能力但是业务容量较小,需要再进行扩展。 687474703a2f2f63646e2e626c6f672e63656c696e676573742e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30332f46756c6c79576f726b696e674c435374616e6462792d4e6f726d616c2d353132783332362e706e6 687474703a2f2f63646e2e626c6f672e63656c696e676573742e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30332f46756c6c79576f726b696e674c435374616e6462794661756c74794c4f572d353132783332362e706e6 687474703a2f2f63646e2e626c6f672e63656c696e676573742e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30332f46756c6c79576f726b696e674c435374616e6462794661756c747946554c4c2d353132783332362e706e6

Openstack容灾

  • 整体架构
    Openstack的DR整体架构如下图。
    至于是否会是一个新的项目,目前并没有规划。目前主要关注于在nova/cinder/补齐功能,编排主要通过heat实现。
    后续可能成为一个独立项目甚至独立与openstack的项目。
    68747470733a2f2f77696b692e6f70656e737461636b2e6f72672f772f696d616765732f652f65382f44522e706e6
  • 功能
    fail over(灾难后切换备节点)
    fail back(主站点故障恢复后切换会主站点)
    test(容灾演练)
  • 方案介绍
    目前没有详细的方案。只有一个hight level的设计。
    现在还在gap识别,补齐阶段。
  • 现状
    目前主要集中在用例分析、整体框架设计阶段。
    具体的实现主要集中在cinder侧元数据、业务数据同步相关。但是进展不乐观。

参考

  1. https://wiki.openstack.org/wiki/DisasterRecovery
  2. https://wiki.openstack.org/w/images/4/49/Openstack_disaster_recovery_-_openstack_meetup.pdf
  3. http://redhatstackblog.redhat.com/2013/11/26/disaster-recovery-enablement-in-openstack/
  4. http://blog.celingest.com/en/2013/03/05/disaster-recovery-in-aws/
  5. http://blog.celingest.com/en/2013/03/19/disaster-recovery-aws-high-availability-architectures/