好 那个大家好 因为我们刚才的话就是我特别感觉到有意思的就是刚才讲Kamala的时候呢我们这个同学问了这个融灾的问题那接下来呢就是我这边的话呢就是包括我们的这个联合创始人和架构师永杰我们一块呢跟大家刚好要讨论的就是这个融灾的话题那简单介绍一下呢就是我自己呢是这个技补科技的创始人我们技补科技呢核心的团队呢是IBM以前做原生存储的团队然后呢我们目前呢非常专注在原原生的业务连续性的解决方案包括说备份 融灾 迁移这些场景这是我们公司非常专注的这个领域那刚好来讲的话呢就是我想这个很快做一个调研就是咱们来这儿的同学现在有多少在咱们公司的环境里边已经在生产环境把KBS跑起来的想问一下有多少同学是这样ok ok 好谢谢那就是第二个问题刚才举手这些同学里边咱们有哪些公司已经去采用了一些业务连续性的方案比如说备份啊 融灾 或者双活这样的一些方案已经采用了ok 这位同学呢我们下来其实可以多聊一聊那确实来讲的话从我们在国内的情况来看的话整个的话KBS上生产这个速度还是会非常快的包括我们的客户也会包括说像金融这边的银行保险证券然后也会有些大型的制造业的企业呢其实这块KBS上融气上KBS然后到生产环境其实有很多的一些案例那接下来讲到一旦我们的这些工作负载核心的工作负载上到融气的环境之后我们就要去解决的业务连性的问题包括说备份 融灾 这样的刚才来讲的话就是我们KAMADA同学也分享利用KAMADA 当然除了KAMADA之外还有其他的这种多云管理的这样的一些组建或者多机型管理的组建我们通过应用的多发布或者是多个占点的机群的接管是可以去实现这个部分的融灾的功能但是这里边会有一些场景比如说如果我们的用户现在还没有用这样的一些多云管理的软件那我们也有这个生产的机群在上面我们怎么样去做融灾那第二块来讲的话当我们在融气上不光光是这样一些无状态的应用而当我们有了比如说我有一些数据库MySQL PGA Manga还有我一些挂的一些数据券NFest我的一些应用跑在上面之后我的数据怎么样来去做同城或异地的融灾那这块来讲的话其实包括我们在看全球来讲的话这块还是一个比较新的领域那在这里今天我们也是希望说记住我们公司过去两年多在国内帮客户做这个融灾方案的实施的这样一些经验跟大家做一些分享好 我们今天这三个部分我会来去讲一下就是我们看到来讲的话这Kumris 融灾的一些挑战我们在设计的时候需要去考虑哪些方面的因素那接下来讲的话就是会有永结然后来去跟大家分享一下就是说一些比较干货的内容就是说我们在真正在去做这样的融灾方案的时候会采用哪些技术的方案包括说我们在改善RPORTO这两个融灾最重要的指标的上面的话在Kumris 环境下有哪些最佳的一些实践包括说我们的一些案例的一些分享那第一块来讲我确定就是有多少同学知道这个网站qbs.af那这个的话如果是咱们有是做QBS运为的同学我觉得这个网站的话其实大家建议大家去看一下它是蛮有意思的它是把最近几年来公开的QBS集群故障的事故都给收集起来包括说围绕这些事故的原因的分析以及是说后面的话怎么样来去改进有很多是非常知名的这种超大集群的或者是公有云的这上面的一些故障这个是一方面然后另外来讲的话我们其实看下来来讲的话就是从Kumris集群来讲它本身是有很强的建装性格高可用内建在里边的一般我们看到的Kumris集群的故障多数会出现在比如说我做集群的升级或者说我做一些集群的一些配置变更特别是网络相关的变更的时候有很多人为引入的那些原因包括集合会触发一些软件故障导致说Kumris集群的一些荡机当然来讲的话从业务联系的角度来讲我们可能就考虑的不光是单集群软件的环境而且可能会有比如说我们的集房的故障自然灾害包括说这种区域性的断网我们就是包括这样公有云的这种可能区的网络故障我觉得其实也都不至说没有发生过所以说就是从保证我们的核心的业务能够正常运行的角度我要讲我们还是要去去构建我们的业务连续性从包括我们自己的实践以及我们看全球的最佳实践的角度来讲一般来讲我们建设路线图会分从一到难会分这样三个步骤最简单的来讲就是我去做备份不管是说这个比较简单我可以做KBS集群的EDCD的备份我们能够实现一个本地的高可用然后如果说我有英文在上面包括有数据我可能会去引入像Volero这样的一些工具来去帮我去实现这种英文的这些备份当然来讲的话就是说如果说我们会有更复杂的这样一些场景我们可能会去结合平台或者是专业的一些商业化的方案来去做完整的这样的备份的方案整体上来讲的话备份是一个比较基础的这样的一个应联性的一个保障它的适用性也会比较强基本上我们看到的这种商业化的方案对于主要部署的我们的意思工作负载都能够去实现一个比较好的一个备份同时它的成本也是比较低的当然来讲它的问题来讲的话就是说一般从备份的角度我们都是一个小时机或天级的所以说对于我们一些特别关键的业务的话它没办法去做到这种秒击或者分钟击的业务连运性那这个时候的话我们就会去考虑引入这个容灾的话题那容灾来讲的话就是大家可以认为它的原理来讲的话跟备份其实是类似的就是我会把在一个占点的QBG群本身或者说我的这个群里面的应用的配置还有我的数据都会及时的捅不到另外一个占点上面去所以说这也是一个相对通用型的方案那很多时候我们看到就是客户不愿意去修改自己的这个应用的发布流程比如说因为比如我们像Kamada我觉得还是比较好的就是说大多数的这个你的API是不需要去更改的那我们看到有一些这个多晶晶方案来讲它其实对用户的这个应用发布流程这些其实还是有很大的一个这个修改的那这块来讲对很多用户来讲就会有一些障碍那从一般的总在的这个方案设计的角度来讲的话我们通过这种资源和数据的复制的方式来去实现的话基本上会对用户的原来的发布流程或者说它的主战点的管理流程不会有太多的一些干扰相对也会是一个通用性的方案然后在最后的话就会说那有些用户我提到基本上是领导一般会去拍这个我就是要这个双活零RTO就是我的这个一个占点故障对我业务完全没有影响很多时候领导会去拍这样的一个需求那这个来讲的话在传统的层面来讲要去实现一个真正的双活方案成本是非常高的那我自己在IBM的时候曾经全程参与过工商银行的这个双活的这个方案的这个整个的设计和实施历史很多年花了很多钱成本非常的高当然来讲的话工商之后的效果也非常好它却能够做到一分钟以内就是说我的业务从它的这个生产单点到这个这个当时上海的这个这个高可用的占点的一个切换在这个过程中的话就是我只是交易会停一分钟左右但是我的查询的业务是不受任何的影响所以那个是做到真正的这种双活的这种场景我们到了渔岩生的环境的话就是我相信大家去搜这个渔岩生加双活这样的一些关系去搜的话就会感觉到就铺天盖地的说我好像到了渔岩生的环境有了Krumines有了这样的多精英管理我就天然我就可以实现这个双活的这样的一个场景那我觉得这里边的话其实可能还会有些误区那如果是说我们比如说我们的应用比较比如说本身已经是一个分布式的一个应用它本身就是可以适合这种跨机群的部数并且是无状态的这种场景形态的话我们不管是说通过多机群的这种方式或者说通过我们自己的应用双发布然后加上我们自己的流量管控基本上来讲你确实是可以实现一个双活的效果但是从真正的端到端的方案上来看的话双活依然是一件比较复杂的事情因为你不光是说我的流量层的流量切换包括说我应用层面的这个应用逻辑我能够做到一个分布式两边的话能够去并行处理还有包括说你的中间键你的数据库还有你的Magic Cure这些的话能不能够去实现这个两个赞典的这个双活的配置那还有呢包括说我们的成储你的数据在两个赞典是不是能够做到双活所以说呢它还是一个端到端的一个比较复杂的方案那目前来讲的话呢就说很难说在这个基础设施层面有一个通用的方案能够去做到针对所有应用的双活那我们一般的最佳实践来讲的话呢就是说我们会建议用户会从基础的这个原生的备份和容灾来去建立你的业务联系性然后呢针对个别的关键应用我们可以针对应用来去做端到端的这样一个双活的方案这个是我们一般推荐的这样的一个业务联系的一个建设路线图那回来来讲的话那今天的话我们会比较专注在容灾就中间的这个这个高可用的这个方案上那容灾的角度来讲的话呢就是跟传统的容灾相比的话到了Kromaze环境还是会有很多的一些不一样那第一个来讲的话呢就是说因为Kromaze它是一个完全服务应用的这样的一个生态所以说呢我们包括说容灾的设计的时候像传统的容灾大家都要去做这个比如说这个两地三中心这个机器要对称然后呢主要来做机器和基础设施的这样一个容灾切换但是到Kromaze环境来讲的话呢我们容灾的颗粒度或者说我容灾的这样一个对象很多时候是以应用来去做这个完整的这样一个容灾切换为目的的那这里的话可能会包括单个应用或者说一组应用或者说我的集群或者多个集群里面的应用的同时的切换那这个是一个非常不一样的地方那在这个过程中的话呢我们讲到既然以应用为东西我们都知道我在Kromaze里面又要去问情一个完整的应用我会包含说我应用的DockerImage我会有自己的经向然后我们会有应用的压毛File我们的一些配置文件然后呢我们会有这个我们应用的数据PoC的data那这里边的话呢就相对你从容灾的流程上你要去协调我跟这个应用相关的所有资源它的夸占点的同步以及我在切换的时候所有的资源都在那边能够端到端的切换过去能够完成我的应用的端到端的拉起随时说呢这个过程如果在别家上我们在Kromaze上你可能会有几十上百个应用你需要同时来去做这样的切换我的应用之间可能还会有些依赖性那这里呢就会带来很多的一些复杂性所以这是这个在Kromaze的容灾设计上其实会有更复杂的一个要求那当然来讲的话对于多数的容灾方案来讲的话呢最难的地方永远都不是Good Pass而是说在容灾的环境里面你会遇到像Rolling Disaster你的不是所有的东西都一块坏的你可能是比如有的时候是网络线坏有的时候我是神主线坏有的时候是服务器线坏在这种场景下你只能够处理这种异常的这样些场景然后第四个我觉得也是说到了原生时代一个新的一个挑战就是我们传统做容灾对应户来讲一定是对称的左边Waymer右边一定是Waymer然后你如果是左边的话比如说是以前的这种小鸡大鸡右边一定是小鸡大鸡它是这种非常同购的这种架构但是我们现在做的很多一些客户的场景的话比如我一边的话我可能是说我用的这个社区版Cornace或者是这个自建的然后我在另外一边容灾当然我可能就逐渐开始引入商业化的这样的一些Cornace平台然后也有可能的话就是我一边是Silver一边是公共云或者说我们见过就在两座公共云之间来做这样容灾的一些场景所以说从容灾方案的设计角度来讲你需要能够去做这种一购的这样的一个容灾的设计这里也是它的一个很重要的挑战这里的话就是说从我们过去的经验的角度来讲一般来去做这样的方案的话会有一些痛的原则首先第一个来讲就是呼应我们一定是以应用为中心来去考虑整个的容灾所以说我们一般很少会去讲Cornace集群的恢复容灾恢复因为这件事情我们觉得在Cornace環境没有意义九地四来讲你在本地利用现在的一些自动化的工具或者如果你在公共云上可能十分钟你就一条命令拍下去就一套Cornace集群就起来了这个时候对用户来讲的话其实更有意义的来讲是我的应用和我的数据怎么样能够完成这样的容灾期划所以这块来讲的话会是一个设计的原则第二块来讲的话就是说流程化和自动化其实是连在一块的这里边的话就是特别在多数的灾难发生的场景下其实对于很多的运萎的团队来讲的话它的压力非常大的这个时候的话如果是你的容灾流程是一个实业的容灾的我们叫Manual那你这个时候的话很多时候的话在很大的压力的情况下大家很多时候的话很容易会出现人工的错误所以说在Cornace容灾的这种场景下和传统容灾一样我们都希望能够你构建的一个方案要去把它流程化出来然后相对于我在特定的一个环境下我只能去做若干个动作这些动作非常的明确来去方便我们的运萎人员有一个准确的判断他要去做出这个决定并且去执行这样的一个操作在这个过程中的话就是说一定是需要自动化来去辅助比如说我们刚才讲过的就是说我们希望大家的容灾方案来讲的话是说我不改变用户现有的发布流程那我在生产战典可能会持续的来做应用的发布那我们有很多时候的话我可能会针对一些应用作为条我会打一些label我会做一些config map的调整那这些信息我需要能够自动化的补货下来然后布置到远端的战典这样我在远端战典恢复的时候能够自动把它恢复回来然后这个数据的话当然也是很重要的一块然后最后的话就是标准化标准化的话其实来讲对于我们在这种一个环境下来讲其实是非常重要的一个非常重要的一件事情这个里边就会提到我们前面有些用户的再如何容灾的时候会用etcd的这种方案我把一边的etcd背下来然后我希望在另外一边把etcd导入通过这种方式来去实现容灾基本上都是不成功的因为呢就说etcd的话它对于本地的这样的一个恢复来讲的话我觉得是一个还是一个比较有效的方案在你的机组设施都不变的情况下如果是集群纸是一个节点挂了或者说我改错了或者是配置的问题那我通过重建机群把etcd导入回来我觉得这个来讲的话也是一个常规的操作但是如果是我换了一个环境然后你去把原来的etcd导入的话会有很多的一些问题举个例子来讲的话比如说它跟很多节点相关比如说no name或者我的一些IP的一些配置或者很多这些相关的问题你都需要去做很多的一些处理我们自己经历过的基本上没有一个客户通过这样的方式做融带是成功的所以说这块来讲的话就是我们从标准化的角度来讲的话我们希望就是说你可能会去用一些更标准的方式从KBS的APS Solar里面去extract你的应用相关的一些配置然后再做另一边去做恢复而不过直接来去做etcd的这样的一个简单的这种档扑也导入那我们下面的话再去介绍一下这是具体的因为融带的它的这个方案的话很难说是一个单一的产品或者组建就是我能够我把产品晾出来大家把产品一步上去就把那个融带的方案就可以解决掉了所以说在这里的话我们今天的话更多还是来去分享我们在融带设计的时候你需要去考虑的不同层面我们可以用哪样的一些技术来去解决它到最后一定是一个solution我会用不同技术的组合来去根据客户它对rpurtu的要求还有客户的业务的情况然后来去给它打造一个合适的一个融带的方案那就是流量切换的这一层我就不讲太多了因为这块来讲会跟每个客户它的这个环境实际上是非常不一样的也有非常多的一些方案那就是相对来讲通用的话我们一般会去看这个三个层面就是包括说这个应用层面应用层面的同步来讲的话就是包括说我们用这个divose的方式然后在双击群同时来去做应用的发布这是一种那这种的话它的问题的话就是说它一定要求我们的企业这个divose的流程要非常的严格也就是说我们对这个应用层面后续的任何的变更比如打label或者我做一些tent这些所有的一些操作你都必须进到你的这个github里边去就说我要一定把这些东西都拆回来这样来确保这些变更不会丢失然后还有来讲的话就是可以用Volero这样的一些方案Volero来讲的话是基本上社区唯一的一个开源的几个方案那目前也是一个事实上的一个标准那它来讲的话会有一个非常完善的去capture我们在这个pumace里边的话所有的应用和应用变更相关的一些信息我们可以用Volero的这个备份恢复的机制然后来去把所有的应用的信息给补货下来然后这是应用的部分然后再到数据院的部分数据院的部分来讲的话就是目前来讲的话其实这个社区还没有说有特别标准或者通的方案那这里的话我们自己的实践下来的话会我们会有这样几种不同的配置会根据客户它的环境或者RPO、RTU的情况会去做调整那第一种来讲然后我们叫Restig那包括Volero它其实也有封装Restig来去做一些数据院的备份恢复那这个它它的好处是说它基本上不挑环境比如一边是R0一边是腾讯它两边的存储是完全不一样的没问题或者说我的网络没法是直通的我在中间比如说我只能连到一个这个中短的这个备份神组它们去那这种也OK那随说Restig它的好处是说它这种灵活性特别的强但是它的缺点来讲的话因为它是通过我备份然后在另一边做恢复的这样的方式来去实现而且它的恢复是没法去做增量恢复所以说在RPO、RTU方面的话是有它的劣势然后第二类来讲的话就是我们会通过像Rsync、Rcon包括说像国内像Juice、JuiceFS也会有些文念同步的一些工具我们可以做文念同步的这样一方式那它的这个缺点来讲的话我们就知道要在两个壳媒集群之间打通过的直连的网络这个是对很多用户来讲是有挑战的当然不排除我们有些客户就是他一开始就是大尔城的网络他在脸都打好了这种的话就可能会相对比较简单一些但是对于一般的客户来讲如果你的环境比较复杂你想要能够去直接的话跨两个赞点的口媒集群的网络去做数据传输还是会有一些挑战然后第三个来讲就是如果是说我们客户的环境的话对RPU、RTO有很高的要求比如说我一定要零出去RPU等于零或者说我的RPU要做到这种秒击那这种情况下的话就是我们一般推荐的方案还是会你就要两边用一样的程度设备然后会利用程度设备的它的同步控制和异步控制的能力然后通过我们在口媒上的一些框架的集成能够去实现这样的一个DRPU和DRTO的方案然后这是应用和数据的部分是非常夸的部分然后在底下还有镜像镜像来讲的话相对来讲也比较简单因为目前来讲私有的银的环境大家基本都用Huber如果两边都Huber那就是变成你的网络可通那就Huber的Replication就可以了我们也遇到一些情况就是公银和私有银这样的场地比如你公银很有公银的Registry然后那私有银的话你出门Huber那这种情况下你可能要自己去写个脚本然后去通过把镜像然后先拉下来然后再通过来那还好的话就是说它对RPU-RTU的影响不大因为我们一般用法物我们见到客户最频繁大概是两天做一次就是不太或说有我几分钟就要去发一个新的镜像这种情况所以说就是你通过这种线下的话我通过一些脚本然后来去做镜像导出那这种其实可能也是可以的那这个大概是一些技术手段我就在做不同层次的融灾切换我会有这样的一些丰富的技术手段那你把这些技术手段可以串起来我做成一个完整的融灾方案的时候这里面就会牵着到两个方面的规范化一个就是说流程的规范化那从融灾切换的流程的角度来讲我们会有这个计划内切换就是说我这边的话我会要做占点的维护所以说我会有确定的时间点我可以去把这个伸占点停下来然后切到这个融灾占点去然后包括说故障的切换就是我一边的占点真的挂了或者网络不通了我需要去切到另外的这个融灾占点去然后还有非常重要的就是融灾演练那融灾演练就包括说我的这种实战的演练也包括说我杀箱的这样的演练你需要把这些流程的帮用户都定义出来然后在每个流程中就是我们刚才提到了一定要去规范化它的动作跟方向的动作的话比如说左边的话是我们的发射器的这样的一个逻辑的状态机状态机的话它有一个很重要的地方就是我在一个状态下比如说我是在正常的A到B占点已经保护的状态下我允许用户做的操作一定是固定的你要么就是只能做融灾的切换因为在这种情况下我是最大程度的减少用户在真正遇到问题的时候它需要去做决定的选项以及它要去做的这个操作一定要非常的明确和简单然后就是用户选择做切换之后整个的切换的流程包括像我们刚才讲的镜像怎么切然后我的数据怎么样在目标端准备好然后怎么样在应用的目标全部拉起来这些过程全部都是由我们的自动化的流程来去完成好 那时间关系的话我这边的话就是从一些比较粗的概要和方法论的角度来讲介绍到这儿接下来我把时间交给永杰他会跟大家分享一下就是说在一些比较具体的技术层面我们怎么来去改善这个融灾的RP的话题好 多谢大家下午好我是来自上海计务科技的公勇杰那接下来我会去介绍一下我们在实际跟用户的场景里面跟用户交流里面还有我们自己的一些思考里面总结出来一些具体的一些最佳实践以及我们后面分享两个真实的用户的一个场景的一个技术方案那个我们知道就是在那个融灾里面就是最重要两个指标一个是RTO一个是RPURTO就是Recovery Time Point它其实通书来讲就是我的一个我准备用户系统挂了那我多快的时间把这个系统恢复回来那这个来讲其实对用户来说就是我们肯定希望越快越好或者说压根用户就体会不到这个中间的这个故障处理那这一块的话我们要根据就是用户的环境来去看这个怎么样能缩短这样的一个就是整个过程那特别针对我们的就是容器化的这个环境里面那我们应用起来的话一开始会需要做这个比如说资源的部署之后我们要做这个进行的拉取再之后还有跟数据券比如绑定关系就是我们如果有这个有状态应用那这几个环节是我们一个应用正常起来这样的流程那我们从这个缩短这个RTL的这个角度来讲那这一块的话我们针对每一个环节都会有一些对应的一个处理那第一块第一块来讲就是我们再去部署或者同步这个用资源的时候我们一般会有两种手段第一个就是我们在生产占点这个应用部署完我们会定期的把这个资源都会去我们说同步到我们的生产占点同时是直接是把它给部署在我们的生产集群上那这样的话我们在应用切换的时候其实不需要再去做一些利税可不可不可不可不可不的这样的操作那这个会降低我们中间的这个KBS的这个应用上启动时间那这块来讲的话我们也会细节上来讲会分两种情况如果我们的应用同时支持我们在生产占点跟这个融在占点都同时运行起来那这个是有些应用是可以支持这种情况那我们就直接在这个融在占点就把这个应用就是相当于运行起来它只是没有去就是收到我们的业务请求去处理那这个是一个最佳的情况那很多时候应用在一开始设计的时候没有考虑到融在那它的实力有有可能就没法说我同时在两个占点或对应的共享的数据库上起两份我的应用那这个时候我们会把它的Rapica比赛成零那我们在融在切换的时候可以通过这个Rapica, Stateful Rack或Department把它快速起起来那这块是针对应用的一个准应用资源准备的这样的一个方式那第二个其实我们看到很多业务系统特别加压系统它整个进向包含比较大就大于计级别的这样的进向文件其实还是在这个切换里面还是挺常见的那我们在融在切换的时候再去起这个进向再去拿这个进向其实这个速度就会很慢特别是我如果整个占点一个集群去做整个Feel World的话我可能有上千个破的同时要去拿进向那我们一般的Harbor其实扛不住这样的流量那在这种情况下我们需要预先去优化我们这个进向的这样的一个拉取这样的一个操作那这一块来讲我们有一些技术手段说像刚才提到的这个应用可以跑起来那我们就事先把这个应用就写在我们的融在这个集群里面那第二种就是我们可以做一些预判就是对一些特别一些有些我们的一般的生产集群的经验会规划一些这个我们叫节点池或漏的组那会把我们的业务区和这个节点有一个亲和性的这样的一个绑定关系那我们可以在融在这点事先去把这个进向这个 warmup然后它的一个效果是我在搭起这个应用的时候我进向其实已经在我的这个本地节点的一个开始里面所以就很秒急的就可以把这个应用写起来那另外一种就说我们也知道社区会有些进向加速的方案那像 Dragonfly 这样的方案其实也是可以考虑在我们的这个环境里面去使用那这一块的话我们在实际的用户环境里面除了这些方式以外我们还会去监控它每次这个应用起来的整个的时间流程去做一个这个实时监控的测算我们找到一个最短最长的这样一个路径让它去定点去优化这一块的这个时间消耗那第三点来讲的话就是如果有数据的话特别有装应用像message像一些这个卡夫卡那这个在容器里面用的比较多那它在起整个应用的时候它需要先去跟这个pvc绑定那这一块我们其实在整个就是正常的同步的这个阶段我们会优先的在后台去把这个最新的可用数据跟它的pv做一个准备关系就相当于我在切换之前我一定是在我中在那里有一个可用的pvc那我在做整个应用拉起的时候我是很快的可以把这个pv跟pvc做一个绑定关系保证我的pvc是一个ready状态那我这个时候就不会去整个这个应用起来在它中间的一些这个动态绑定关系和分配的一些时间那这个整个是我们整个就RTO的一个优化速度那可以给一个数字就是我们在如果按k8s原生的这个切换后应用拉起的时间一般我们可以测下来在10到15分钟但是我们通过整个这个几个环节优化我们很多时候对一些核心应用基本可以在秒击和分钟起的速度可以把它切起来所以这个会很大程度上对整个用户的这个容在切换时候RTO有一个非常大的这样一个优化那第二块的话其实就是容在里面另外一个非常重要指标就是前面我们把应用很快的能起起来那这个是相对我们能提供服务那但是这个启动起来的这个应用的这个当前的这个数据状态是什么时候的那比如说我们可能是这个故障发生前5分钟或者故障发生前发生前一个小时的数据对用户来讲它肯定是期望我这个数据是没有丢失的就是我故障前是一个什么状态那我现在重新起来后也是同样状态但是这个是一个就是大家的目标但这个目标其实就跟我们的整个基础环境是有很大的关系就比如说我中间的这个容在战典跟这个就是我们传统讲的同城两地三中心为什么有两地为什么同城又为一地那它的中间的网络带宽数据复制的效率等等这些来讲的话都是一个会对我们的整个的RPU会有一个限制那因此我们今天分享主要从这个数据卷或存储这一车来去把我们总结的一些方案来去做一个呈现那第一块来讲的话就是我们有很多用户其实它是比如说像金融行业的用户它其实已经是有这个金融设施我有同城的这样的站点独立机房底层的存储网络也都是在虚拟及时代其实也都是已经可用的那在容器的这个环境里面那我们可以利用一忧的这个基础环境比如说共享的存储这个延展的同城的这个分布式存储或者说我们一些高端的这个同城的NAS这样的一些方案那在这个方案里面其实数据的本身它是已经是跨站点的在分布在我们的存储之上那我们需要做的事情就是在容栽切换的时候把这个容栽站点上的数据能够很快跟我们容器里面的这个应用能对起来其实这里主要是一个比如说我们PPCT跟BIPING关系那做到这个以后我们就很快的可以把这个数据能够在这个容器里面应用起起来的时候它还是就是呈现是当时故障前的状态那这个呢就是方案限制也是有的说我一定是这个环境里面是同购的这个存储并且存储是支持这个同城的这个就是跨机房的分布这样的一个要求那另外一类就是在我们的这个技术环境里面比较常见的就是说还是同购存储但是那我因为中间的这个就是网络的限制它没法做到说严格这种双活的这样的标准那一般会做这个异布的或者同购数据复制那在这个这样的一个技术设施上那我们所做的事情就是说我们要去我们的有状态应用比如说我们买三口我们要去把这个数据卷的这个就是复制关系利用存储的复制关系对接起来那我们要做的事情就是我们在这个整个这个方案里面我们开发了一套整个的数据复制的这样框架那它对上来承接我们容器环境里面数据卷那对下来讲去承接这个数据库对下来讲我们去承接这个存储我们利用一些标准接口比如说我们在存储里面找这个数据卷复制关系建立复制卷的数据暂停开始然后反向同步等等把这样的一些标准接口定义出来来对接到我们的这个这个技术设施里面那通过这种方式呢其实我们整个效果上也可以达到这个RPU凝获到一个分钟起到这样一个比较高的这样一个水平上那假设我们的这个环境因为这两个还是跟环境有一定的这个强榜定那在我们的环境里面比如说用户其实没有这样的同购系统或者用的比较新的这个原来没有考虑到这个原来的农倉占点那它的一个方案来讲就是很难说有的时候受经费的限制我很难说再采购一套相同级别的生产存组那可能是一购的比如说我的这个生产环境用这个商用的存组那我的农倉环境可能就是一个自建的这样的一个NAS或自建的NFS环境那在这个时候呢其实来讲我们没法利用一有旅游设施那这里我们推荐的方案来说我们通过文件级的方式来去做这个整个的数据券或数据的复制那我们常见的就Rsync或者说Rclone这样的一个一些开源的机制方式来做这些事情那这个方式里面呢就是我们刚才提到就是它需要对整个的环境比如网络需要能够Rsync中间可以做一个这种Channel然后打通两边的KBS那另外来讲的话就是说它其实对这个网络要求很高那这块来讲我们其实也可以达到一个分钟级比如说5分钟是5分钟根据用户的数据量来看在这样的效果那最后一个程度就是说那这种网络环境也没有那用户可能只能通过中间的中转的方式我们通过一个比较常见的备份恢复我们来达到这样的一个数据同步的效果那一般我们可以在小时级来去做这个跨站点的这个数据同步那这个就是要根据应用的业务的情况来看那我们可能就是比如10%的核心业务需要在上面的这种分钟级的RPU、RTO要求那一般的一般业务其实在很多社区可以去容忍这样的一个小时级的这样一个数据的一个差别那这块是我们一个RTO优化里面我们从这个数据卷的角度来去列举那些我们常用的方案那接下来的话其实我这边就分下两个技术方案那我们在这个真实的用户环境里面所使用的方案那第一个是我们在这个一个国内保险公司里面来设计的这个同城的这个容忍方案那么在它的方案在它的环境里面他们一开始这个应用室都跑在容器里面他们利用已有的这个同城的两个站点然后去搭建这样的一个容栽的KBS容栽站点那希望达到效果来讲就是说我们可以容忍这个站点级别的故障或整个集群级别的故障那这里呢就说它的一个就是特点是它原来一开始大家上线的时候没有考虑到容栽那我整个应用发布整个应用管理其实都围绕着这个主机群的这个KBS来的那在这个容栽的需求里面就是它没法说因为我们要去提高这个整个这个应用的高可用性我要去修改原来整个工作流程那因此呢我们这个方案里面来讲就是我们会使用我们的这个容栽转件来去达到这个效果那从技术上来讲的话我们会在这个容栽站点部署一个这个容栽控制器那它本身呢就是一方面提供这个介面给用户来去做这个容栽配置另外一方面呢它会去在两个这个生产跟容栽站点区部署我们的这个我们叫容栽引擎那通过这样的一个方式我们会去定时或者通过API接口去把整个这个应用在生产站点的这些API资源都补货下来同时会更新到我们的这个就是容栽站点上那根据它的这个不同应用的配置我们可以去把这个就是应用设置成这个RIPECAT0的这个下档的模式或者说有些应用它是无状态的我们就可以让它去保持在这个容栽站点的一个我们叫House安排就热背的这样的一个状态那数据这一块呢因为它是利用同成的这样的一个就是存组复制可以达到这个把数据去同步到我们的栽备站点那我们这一块来讲就是通过这个流程上的对接我们来去对接下面的数据券的这个复制的管理包括这个数据券的复制状态监控那在总在切换的时候我们会去和下面这个存组中间会做一个这样的一个联动去把整个的应用和数据都切换到我们的容栽站点那在这个方案里面其实最后的效果是我们可以达到这个用户要求的分钟级的这样一个容栽切换那同时那对它的整个原有的生产的这个流程和体系是没有任何侵入的那它应用本身也其实不需要做改造好嘞 那下面这个是另外一个我们的一个就是生物医药检测公司的一个同成的一个容栽方案那在这个里面呢其实整个这个应用场景也是蛮有代表性的就是用户的应用系统它其实把这个应用部分会放在容器里面但是呢它的这个数据部分比如数据库或者说这些数据服务它还是放在原有的仪有的这个这个这个旧有设施比如说蓄益机 雾机上那这个其实很多用户在去做容器化改造的时候都会有类似的一个倾向对仪有的这个应用的改造我会逐步的去改造把我的核心业务还是留在比较稳定的旧有设施因为毕竟它运行了很多年这个整个经验都是表丰富的那我一些无状应用或者说一些新的这个业务把它给发布在我们的这个容器环境里面那在这个环境里面它还有一个特点是就是它的生产环境它原来是有两套K8S一套比较旧一套比较新但在做整个容栽规划的时候从管理性角度它在容栽占点其实它就有一套大一点的这个K8S那它这个需求是我需要容栽的时候把多级群的这个应用都可以切换到同一个这个集群上那所以呢这个是它的一个特点那另外呢它的整个占点容栽它需要考虑我容器里面依赖的容器之外的服务数据库和这个NFS那所以呢整个占点切换从流产党讲的话我需要去梳理这个依赖关系先去做技术设施比如说虚拟机数据库和这个虚拟机面服务的这个容栽切换这个准备好了之后我们再把这个应用上的这个资源配置去做一个我们叫合并的这样的一个方式把它给容栽到同一个这个K8S上那整个这个方案其实也是一个就是比较典型的这样的方案最后的效果也是说我们可以做到这个分钟级的RTO好嘞我这边就是介绍部分就这些我们把剩下的时间就交给大家看有些问题我们可以快来讨论谢谢老师两位老师的那个分享然后我们现在抽取一位这个大家我问一下吧这那个我看你那个容栽有那个就是同步的时候有有应用同步数据同步还有那个镜像同步就刚开始讲那这个同步嗯因为传统的我们可能就立为就那个容栽的话就数据容容容容容容容容容容像你的那个应用同步的话同步的是哪一东西应用同步的话举个例来讲在KBS里面我们有很多压谋就比如说Department Confirmation Secret那这些是我们主要同步的目标还有Service这一类的这些配置信息相当于还是一些应用的一些数据是吧对你看这位是应用的配置还有那个镜像同步我理解我理解和数据同步应该是一种就是说为什么要单独把它给拿出来这一块这个是因为就是就是镜像属于应用的一部分但比如它是它的二进制文件那这一块来讲其实很多这个用环里面它的就是镜像仓库都是独立部署和管理的因为它和DepartmentDepartment属于这个研发测然后它的生产测的这个Hobber一般是说我的这个整个测试完了没问题吧推到这个机架公器那我们在这个融灾的这个占点其实它还会有可能会有另外一个独立的这个Hobber那这个时候你需要根据上面应用同步的时候同时我们要需要解决下面这个镜像的同步的问题不知道这个有没有对这里来讲的话就另外一个考虑来讲的话还是说这个我刚才讲到就是从这个融灾的角度很重要的是我们在考虑不同的组建它的RPO-RTO属性是不一样的比如像镜像来讲的话其实就是因为我们应用应用发布的频率其实没那么高但是我上面为什么应用我这边要单独来做同步呢因为我们除了应用发布之外的话我们很多时候会有对应用的一些修改比如说我会去打这样的一些去改一些Coffee Map或者打一些Label或者做Nose Tender这些很多时候我们在这个用户的实际环境里有看到就这些的话就是说把大多数用户它其实没有严格到说我对我们应用的所有的修改我都能够用我的发布流程来去跟东西来所以这种时候的话我们就必须以一个更高的频率来去把这些修改也都统不过去那我还有一个就比较就是老的问题就是在KBi这块做龙代的话就是它还是就是手动切换好还是自动切换好因为这个东西可能我看到的一般是手动就切换虽然它有自动切换的功能可能这一块可能是条件条件出发的时候可能会误判或者导致什么东西也会导致错误的切换去这会导致就是引发一些的问题对我可以这么说以我这十几年的经验来讲包括传统的包括现在的在真正的客户的生产环境基本上都是手工来去触发的因为那就是从一个龙栽的角度来讲的话它解决的就真的是说我发生了一些非常诡异口的一些问题的时候那这些问题的话往往环境会非常的复杂就是说你用自动触发的情况下的话你很难把所有的条件都考虑到所以说我们一般的设计原则就是我给用户的话就是我的切换流程和切换的决定都会非常的简单非常的简洁自动化但是这个龙栽决定的切换的决定一定是用户自己来做因为用户它才会真正的会知道比如我真正发生一个故障的时候我是说做原地的恢复更有利就是说我真的要切到容带站点去做更有利这种时候这个决策权一定是放在用户就按button的权力一定是放在用户这儿对我应该的合理也是一次我要这么认为的因为自动的话确实不太好控制是还有一个就是你没在会去做数据同步的时候是每个机群会有一个代理码然后到每个note里边去拉数据还是每个note上都有一个init您是说数据的这一块对因为你其实代理码最重要的就是数据同步其实像kbar还是直接拉过去数据都存在的话其实拉起来服务是一样的一个也没那么一样其实最重要的还是数据同步所以同步这一块的话我看上海s5也做在一块它是有init去到每个階段去同步对这里的话其实我们提到来讲的话其实你是有不同的数据同步的方案就是像您提到如果是像s5的话我们认为它底层的实现是怎么样的但是我觉得很可能会非常类似于restake这种方式就是我装agent的目的就是说我会要把数据卷你的数据做一个备份然后再融在占点再去做恢复只不过来讲对融在来讲我可能会这持续的自动化的备份恢复备份恢复那这种情况下的话你就需要在每个节点至少有一个demonside这样的一个机制然后来确保就是我在每个节点上的这些数据卷大家做一个备份恢复这些方式去实现那如果是说举例再讲像我们如果是用这种存储跟存储底动存储方案对接的这种形式的话我们就可以因为我们会可以非常清楚的去定位到每个应用你使用到这些PVC它对应穿透到物理的存储设备上它是哪个数据卷我这时候我就可以直接调用存储的接口然后来去在数据卷层面来去做复制就跟这个就不需要再去在每个节点里面在针对PVC层面这种手法它就是一个Azient类似的这种方式