在之前的“诺曼底登陆”系列第一季中，潭主为每个云厂商写了一篇“专访”，虽说各方反应不一，但文章整体效果不错。
去年底有同行跟潭主咨询灾备事宜，当时就想自己搞灾备这么多年其实可以写个灾备回忆录。
恰巧这次PoC潭主负责灾备领域专项测试，本期就以灾备为题写个回忆录的“前传”，算作第二季的开篇。
高台跳水秀灾备
跳水比赛分为有难度系数限制的自选动作和没有难度限制的自选动作，通常后者更有看头。
本次新云PoC跟跳水类似，其他领域测试是规定动作，而灾备测试属于厂商自选动作。
相对于RTO和RPO这样的灾备指标，客户平时挂在嘴边的更多是灾备和双活，但需求又过于模糊，比如双活到底是应用双活还是全栈双活。
客户想没想明白不好说，但厂商肯定是揣着明白装糊涂。
反正云厂商的这场高台跳水秀，难度系数是一回事，压不压得住水花是另一回事。
单元化的星型模型
京东云的底座基于K8S体系，属分布式系统范畴。
大多数行业用户其实是没有实力搞同城对等三中心的，所以同城双活架构需要引入仲裁站点，当然伪仲裁也不是不行。
技术架构上京东云支持实现同城“双活”，其实对于分布式系统架构换个角度看双活就应该是单体免切换的。
因为没有成形的灾备产品做演示，所以京东安排了他们的单元化多活产品。
虽说单元化属于用户高阶需求，一般系统配不上，不过京东的戏码在这儿，体验一下也没坏处。
产品脱胎于京东真实的业务实践，在潭主看来京东的单元化还是有些特色的，称之为星型模型，分中心单元和普通单元。
测试过程中对京东的业务体系架构也有了些了解，从某种程度上讲京东的单元化架构跟潭主早期的灾备实践颇有相似之处。
所以，看上去蛮顺眼。
久违的厂商套路
这次新云PoC玩法不同，变成了厂商自选动作，以至于潭主一时有些不适应。
直到第一场测试结束时才Get到阿里的灾备逻辑。
就是不管你有没有需求，最终的测试内容就是ASR和ASR-DR两个产品。
ASR（Apsara Stack Resilience）是阿里基于自身平台构建的，可以白屏支持相关技术组件的切换。
ASR用于同城容灾，ASR-DR用于异地灾备。
潭主测了OSS对象存储和RDS数据库，产品支持自定义及组合场景，但更适合计划内切换演练。
因为阿里的方案是阿里云的IaaS+蚂蚁的PaaS，所以又追加了PaaS的测试，受限于环境，没做SOFAStack的异地测试。
此外，潭主还做了一个云底座切换测试，MiniRDS上共涉及218个实例，切换时间1分多。
总体上，阿里的ASR相对较完善。
但ASR有个前提，就是云上的应用都得依托阿里云组件实现，这样ASR才能派上用场，客户原来在VM上的那套玩法行不通。
显然当下用户不可能做到，而且上面PaaS用的又是蚂蚁的SOFAStack，也存在同城容灾被PaaS接管的问题。
总之方案过于复杂，估计最终应用系统的灾备部署只能需求明确后再一一定夺。
如有雷同，纯属巧合
有了阿里灾备测试的前车之鉴，潭主调降了对腾讯的预期。
相对于阿里ASR和ASR-DR两个产品，腾讯的容灾管理产品统一为DRMS。
腾讯选了一个同城三站点的环境做DRMS的功能演示，受限于条件也没有提供异地测试环境。
干的都是灾备的买卖，所以DRMS和ASR有不少雷同之处。
相比阿里的ASR，腾讯的DRMS就显得不够成熟。
除了界面较糙外，操作也不如ASR简便，但该有的核心功能好像也都有。
腾讯跟阿里的云灾备架构差别较大，阿里的ASR是跟云底座一体的，每朵云都有自己的ASR模块。
在异地灾备场景下，阿里的ASR-DR灾备架构属于多云多Region，而腾讯的DRMS是一个脱离云底座的独立产品，DRMS需要定期同步云的CMDB信息，属于一云多Region架构。
相比阿里，腾讯的测试略显单薄，最后只能拿备份来凑数。
最开放的生态军团
华为演示了CSHA和CSDR，二者都属于VM层面的高可用和容灾场景，符合传统企业容灾建设需求，但需要集中存储支持，其他厂商或暂无类似服务，或正在研发中。
这个点不是技术问题，而是存量的现实需求。
云底座ManageOne的架构更贴合两地三中心设计要求，可实现一云多Region。
不过华为云也有不少局限性，比如同城双活建需要双AZ一次成形，同时面对客户两地四中心的需求，由于产品设计问题需要额外多占用一个AZ。
售前方案测试过程中也会出现厂商说辞前后不一的情况，最终方案只能先敲定需求，感觉中间变数较多。
对于华为云自身的灾备管理工具，号称有个叫MAS的产品，应该尚未正式Release，反正华为PoC没测，而是找了生态伙伴救场。
新云灾备回忆录
由于每个厂商的灾备测试不到两天，再加上环境受限导致测试局限性。
测试的最大收获是对一线云厂商的灾备建设能力有了一个概览。
相比之下，阿里的测试最全面，产品功能也最完善，但技术栈复杂，门槛较高，从整体灾备管理的角度看局限性也很明显。
华为招数较多，一边现场突击“发布”新产品，一边联合伙伴搞生态。
不过他选了同创永益搭伙，算是弥补了自身灾备管理和混沌工程能力的缺失。
京东和腾讯则需要各自再多点修行。
目前看灾备架构上厂商分两类，华为和阿里算一类，京东和腾讯属于另一类。
写回忆录时感觉有些内容已经变得模糊了，总体而言，潭主觉得华为的灾备方案在设计思路上更贴合客户的实际需求。
此外，对那些总想着自主可控的客户来说，除了现有的双模IT外，在云灾备建设上未来很可能会面临一云两吃的尴尬境地。
总之，在同城双活和异地灾备的整体架构上厂商给出的方案可以说是大同小异。
条条大路通罗马，关键是哪条道坑少呢？
- END -
感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
