生产和同城存储容灾架构下，同城站点非存储层数据 配置如何与生产站点保持一致性？|《迈向YB数据时代》

本期为大家带来《迈向YB数据时代》2022年春季刊“持续运维”栏目中的议题三

邓毓 江西农信运维技术经理

为什么要保持生产和同城非存储层数据 配置的同步？

关于生产端与同城灾备端数据一致性的问题，通过存储块复制 者数据库逻辑复制技术仅可以解决存储层数据的一致性，但非存储层数据 者配置数据的同步和一致性问题，却是很多企业在建设同城灾备时会遇到的难点和痛点问题。该问题倘若不能得到有效解决，在生产切到同城灾备环境之后，灾备端的配置层数据在某些方面如果和生产不一致，则会出现很大的问题，甚至是灾备端不可用。因此解决生产和灾备站点间非存储层数据 者配置数据的同步和一致性问题是灾备建设和切换演练的必要环节。

生产端哪些非存储层数据 配置需要同步至同城灾备？

非存储层数据 配置同步包括了存储块复制技术和数据库逻辑复制技术无法解决的数据同步项，通过存储卷的复制有时不但可以同步文件 者数据库数据，也可以同步存放于存储卷上的配置文件，这需要结合IT基础架构和运行环境来综合评估所需同步的项目。而数据库逻辑复制技术是将逻辑日志数据传输到灾备端然后进行日志回放来保证两端数据的同步，仅涉及数据库数据。结合这两点，该问题所涉及的数据同步是非存储层的数据 配置的同步，和非数据库数据的同步，主要包括以下七个同步项

• 操作系统配置

• 中间件配置（不在存储卷上的配置文件

• 数据库配置（不在存储卷上的配置文件

• 应用版本（不在存储卷上的应用

• 应用配置（不在存储卷上的配置文件

• 作业任务配置（不在存储卷上的配置文件和脚本

• 网络访问权限

针对上面提到的七个同步项的同步方案 保证一致性的机制，下面进行分类说明

• 操作系统配置 包括操作系统版本及各项参数配置。

• 中间件配置 包括中间件版本及各项参数配置。

• 数据库配置 包括数据库版本、实例配置、运行环境参数配置、数据库配置等。

同步机制 方案 制定操作系统、中间件和数据库版本、安全加固、基线配置等基础软件标准规范，规范落地的方式可分为三种，第一种是依靠云平台，基础软件的版本和参数随着IAAS层资源部署而落地。生产端和灾备端保持云平台镜像和脚本仓库的同步，两端部署出的基础软件配置则完全一致；第二种是依靠自动化运维平台，一方面是生产和灾备端可以批量进行版本升级和实施基线配置来保证基础软件配置的一致性，另一方面生产和灾备端可以实施配置自动化比对来校验同步效果和预警；第三种是依靠流程机制，生产端的相应变更也要体现和应用于灾备端。这三种方式相辅相成，依靠云平台保证生产和灾备端基础软件上线时符合一致的基线规范，依靠流程机制和自动化运维平台保证生产和灾备端基础软件上线后变更的同步和一致性。

• 应用版本 包括应用 产的版本。

• 应用配置 包括应用运行环境配置、参数配置等。

• 作业任务配置 包括定时作业和调度作业的脚本、配置等。

同步机制 方案 第一种方案是采用传统方案。搭建应用软件、作业脚本等企业级版本库，利用流程机制和自动化 产平台来保证应用软件版本、配置、作业脚本等变更后，生产和灾备端各应用节点的同步和一致性。应用配置同步的第二种方案是采用敏捷方案。生产和灾备端建立两套应用系统配置中心，这两套配置中心保持配置的同步，应用系统的配置存放于配置中心，生产端应用启动时通过接口调取生产配置中心对应的配置加载至内存中，灾备端同理，应用启动时加载的配置和生产端是同步的，以此保证了应用配置的一致性。作业任务配置的方案是采用敏捷方案。生产和灾备建立两套应用系统作业调度中心，这两套作业中心保持调度配置和脚本的同步，应用系统的作业由传统的定时 触发式作业替换成统一调度作业，由作业中心调度完成。在生产切至灾备后，生产和灾备作业中心的角色也相应转换，由灾备作业中心调度灾备端节点完成作业任务。从这两种方案来看，第一种方案较为常见，运用较广，而第二种方案正在兴起和流行，是未来的趋势。

• 网络访问权限 包括应用节点间、互联网链路、外联链路等的网络访问权限。

同步机制 方案 生产和灾备端网络访问权限的同步较为复杂，需要全面梳理应用间、节点间的关联关系，形成网络拓扑，录入CMDB，CMDB根据这些关联关系，自动生成网络访问关系，再落地至各个网络安全分区的防火墙策略中。为了保证生产和灾备节点网络访问策略的一致性，在梳理关联关系时，灾备节点也应纳入梳理范畴，形成生产和灾备整个网络拓扑关系。在变更网络策略时，也就是关联关系的变更，生产节点和灾备节点和其他节点的关系也同步发生变更，最后也同步体现至网络防火墙相应策略中。 

雷智 某农信资深技术经理

容灾配置同步和数据一致性验证是确保容灾体系发挥成效的前提条件，是确保应用级灾备能否顺利接管和正常运行的关键环节。有研究机构调查数据显示，72%的容灾高可用功能失效是由于配置管理所致，操作系统、数据库、中间件、应用版本及网络权限等配置不同步一直是容灾体系运维管理所面临的重大难题。

从容灾管理实践来看，生产与容灾端配置不同步的主要原因是维护管理期间配置管理不规范。要解决此问题，需从管理措施和技术手段双管齐下，尽量降低配置不同步的风险概率，确保容灾体系可用性。

管理措施

容灾体系的日常管理工作不到位，就会出现容灾中心的数据和生产中心不一致现象，难以保证在切换时能够正常接管工作。因此，在容灾管理中需落实配置管理规范、加强容灾测试演练及培训，才能进一步实现容灾配置的一致性。

• 建立并严格落实容灾配置管理制度规范

日常管理工作的核心是保证容灾系统的应用、软硬件平台持续可用，可以随时进行应用切换及业务接管，包括数据审查、系统维护、系统监控、软件版本管理、容灾变更管理等内容。

数据审查保证容灾系统在必要的时候能够及时接管生产系统。容灾系统与生产系统的数据须保持一致性、完整性，应在容灾系统中建立起与生产系统的数据同步审查机制，并通过数据核对帮助生产系统发现可能出现的问题，进一步完善和优化生产系统和容灾系统。容灾中心业务组人员通过手工 者程序脚本的方式，定期与生产系统进行数据的核对，根据预定义的指标检查数据的一致性、完整性，及时发现问题、分析原因、编写报告，必要时发起容灾测试流程。

系统维护是为了保证容灾系统接管生产系统时，不会因为IT因素、基础设施问题而发生接管失败，是对生产系统与容灾系统运行的IT基础设施所进行的日常例行检查、维护工作。

系统监控的目的是帮助系统组、业务组成员对生产系统及其容灾系统的运行情况进行监控，对故障进行快速准确定位。

软件版本管理是指在生产系统运行过程中，由于功能完善、增加等原因需要对软件版本进行更新、变换，所以应对生产系统及其容灾系统的软件版本进行管理，保证容灾系统按既定目标顺利接管业务，避免由于版本不一致造成的数据错误、业务接管失败。

容灾变更管理的目的是控制、管理容灾系统中的变更行为，确保容灾变更平稳实施。一般步骤包括 发起、影响及资源评估、接受、执行、变更总结等。

• 加强容灾测试及演练

稳定的容灾架构是信息系统安全生产的重要保障。开展常态化容灾切换演练及测试，是充分保证容灾机制的有效性，检验灾备流程的可操作性，提高容灾演练的实战能力的前提条件。

• 容灾演练

容灾系统建设完成后，必须不定期进行容灾演习。根据在演习过程中是否真正进行系统的切换，容灾演习可以分为模拟演习与真实演习。模拟演习主要是为了检验在发生实际灾难后，参与灾难恢复的相关人员是否能够根据规划好的灾难恢复流程，有序可控地进行灾难恢复工作。真实演习不仅要检验灾难恢复流程的有效性，而且要验证容灾系统是否能够实现正常的切换和回切。演习主要步骤包括 制定演习计划、审批演习计划、演习启动、消息发布、演习切换、验证、演习回切、总结。演习是灾难恢复计划和容灾配置一致性的最好验证手段。演习过程中，应详细记录各个重要环节的时间点，用于考核容灾系统和生产系统的各项指标。演习后应及时总结经验，对发现的问题应及时解决，需要修改 优化的流程要限期进行修改和完善。

• 容灾测试

如果对容灾系统的数据、功能、性能等方面没有测试验证，难以保证容灾系统可实现数据保护和业务接管。容灾测试是对容灾系统的数据、功能、性能等方面进行验证，保证容灾系统的建设和变更能够实现数据保护和业务接管。测试方式尽可能采用测试脚本，避免人为误操作。测试环境尽可能与生产系统隔离。在不发生系统变更时，最好每月测试一次，否则须即时测试。

• 容灾培训

如果没有做好培训，难以保证相关人员及时学习到相关的知识和技能并及时更新。通过容灾培训，可确保相关人员及时准确地了解系统结构，熟悉测试、演习、灾难恢复流程，明确自身职责，沟通、协作顺畅，提高工作技能和灾难应对能力。培训计划由执行组与人力资源部门共同制订和执行。培训内容主要包括 容灾基础培训、容灾流程培训、容灾技术培训。遵照灾难恢复计划中的切换和回切流程，在不影响正常生产情况下，严格按照事先制定的培训教材，开通容灾中心全部设施及模拟测试终端。如果把以上六个方面比作一个链条上的六个环节，那么任何一个环节的缺少都可能导致容灾中心形同虚设。俗话说，养兵千日，用兵一时。任何一个细节的忽视，都可能导致容灾中心在关键时刻不能发挥应有的作用，到那时后悔就晚了。 资巨大的容灾系统，在关键时刻起到作用才是值得的。

技术手段

技术手段是对管理措施的重要补充，自动化工具和有效的容灾规划设计可以有效地提高容灾配置管理效率，降低配置不同步风险。

• 技术工具

容灾体系中各维度产品配置不同步，从本质上说是配置管理问题。因此，可以利用CMDB类工具来对容灾配置进行管理。CMDB工具是ITIL最佳实践工作的基本项目，业界有很多类似工具，如iTop、OneCMDB等开源产品，ManageEngine IT360、BMC Remedy、HP Configuration Management System等商业工具。

在容灾管理工具中，也有部分专业厂商提供了相关工具，如S厂商作为专业容灾厂商，提供了Symantec Disaster Recovery Advisory（DRA 和VirtualBusiness Service（VBS ，分别应对容灾管理中的配置检查和容灾演练这二个关键运维节点的需求。DRA可以针对容灾系统进行信息收集和分析，并给出体检报告的工具，DRA能够有效提示HA/DR系统中的配置错误，及时提醒管理员进行修正，显著提高容灾系统的有效性。

由于容灾体系涉及技术众多，配置管理场景广泛，特色各异。因此，容灾运维管理员可以在上述工具的基础上，针对不同场景和需求，编写脚本 开发对应工具，实现容灾配置同步功能，提高容灾配置管理效率。

• 容灾规划设计

业务在发展、系统在运转，容灾体系是动态的、不断完善的过程，可以通过系统双活架构来检查容灾功能的可用性和配置的一致性。如在容灾规划设计中，对重要系统进行双活架构设计，在容灾端配置5%左右业务流量，通过正常业务流量动态检测操作系统、数据库、中间件及网络配置的一致性，既能够提高业务连续性的RTO和RPO，也可以实时验证容灾体系的可用性。

总结

如何确保生产与容灾端操作系统、数据库、中间件及网络配置的一致性是容灾管理中必须面临的关键问题。从实践经验来看，可以从管理措施和技术手段两方面着手。管理措施方面，可以通过落实配置管理规范、加强容灾测试演练及培训来实现容灾配置的常态化管理；技术手段方面，利用成熟工具、自研工具及双活架构设计来提高容灾配置管理效率。通过管理措施和技术手段相互协调配合，可以有效降低容灾配置的不同步概率，提高容灾体系的可用性。

陈明福 宁夏银行技术经理

需求分析

在进行两地三中心容灾体系建设过程中，要保障灾难发生后灾备中心的信息系统能够正常运行，业务能够连续运行，一般情况下，需要多个数据中心之间的保持同步的数据主要包括 数据库、中间件、操作系统、应用版本、crontab等其他配置信息等，不仅涉及到使用技术 者工具/软件来实现同步，还需要制定相关的同步规范制度来实现多个数据中心之间数据同步管理。

两地三中心配置同步是一个建设难点，最主要的是灾备端经常处于standby 者停止状态，难以验证当前的配置是否完全一致。

同步机制及手段

基于存储复制容灾架构可以较好地实现数据库的复制保护，但对于配置及参数文件等不存放在存储设备中的配置层文件，存储复制技术就显得无能为力，只能增加其他辅助工具手段进行同步，可依据灾备管理系统、应用、数据库、中间件、OS的配置和CMDB，尝试建设了一个两地三中心一致性比对工具，确定关键配置，逐个建立检查和比对机制，逐步完善比对项，随时进行比对并生成报表，尤其是生产环境变更之后和灾备演练前，及时进行检查。另外，应用发布和基础软硬件变更工单中依据CMDB自动关联灾备环境，确保灾备端完成变更，不至于遗漏。具体可采用如下方法

• 操作系统、数据库和中间件参数配置

操作系统、数据库和中间件参数一般在系统集成部署后很少会发生变更，变更频率较低，且该类型配置文件具备很多个性化参数，故该类型参数配置建议采用“手工更新”的方式实现同步，即 通过变更流程制度来严格控制该类型参数的手工更新同步，当生产中心发生参数变更时，手工对灾备中心参数进行同步变更。

如若操作系统、数据库和中间件参数发生变更的频率较高，可考虑采用“自动化同步工具”保持灾备中心应用版本及参数与生产中心的一致性，如若具备条件，可考虑采购商业版同步工具，否则可采用Rsync等开源同步工具实现应用版本及参数同步。

• 应用版本及参数配置

为适应业务的快速发展，应用版本及参数发生变更的频率较高，几乎每周都会发生变更，故针对该类型的可考虑采用“自动化同步工具”保持灾备中心应用版本及参数与生产中心的一致性，如若具备条件，可考虑采购商业版同步工具，否则可采用Rsync等开源同步工具实现应用版本及参数同步；另外，当前一些应用系统已经实现了较为完善的分布式架构及多数据中心下分布式应用版本快速部署工具，针对该类型的应用程序，建议使用厂商自带版本发布工具进行灾备中心应用版本及参数同步。应用的共享数据文件，可以采用随存储复制技术保持同步。

其次，灾备中心的应用版本及参数需要定期进行测试验证，以确保同步后的版本及参数是可用状态，当出现灾难后，灾备中心可立刻启动应用接管业务。

• 定时任务配置

定时任务一般在系统集成部署后很少会发生变更，变更频率较低，故该类型参数配置建议采用“手工更新”的方式实现同步，即 通过变更流程制度来严格控制该类型参数的手工更新同步，当生产中心发生参数变更时，手工对灾备中心参数进行同步变更。

如若发生变更的频率较高，可考虑采用“自动化同步工具”保持灾备中心应用版本及参数与生产中心的一致性，如若具备条件，可考虑采购商业版同步工具，否则可采用Rsync等开源同步工具实现应用版本及参数同步。

• 网络策略权限配置

网络策略权限涉及信息安全防护且影响面较广，建议采用“手工更新”的方式实现配置同步，即 通过变更流程制度来严格控制网络策略的手工更新同步，当生产中心发生网络策略权限变更时，评估后手工对灾备中心网络策略权限进行同步变更。

总结

结合最佳实践，两地三中心架构下，能够实现自动同步的内容相对局限，大部分需要人工手动同步校验，这时就需要制定严格的同步制度，规范的同步步骤，细致的同步流程，以有效杜绝多个数据中心间参数配置的不一致风险。必要时，需要梳理所有需同步的配置项，通过统一的同步软件 者工具，来实现自动化比对和变更 产，比如自动化 产工具，在流程审批过后，自动化 产工具，将按照自定义的脚本，自动在所有节点运行相同的命令，保持所有配置项的一致性。最重要的是多开展灾备中心业务接管切换演练，把演练过程中碰到的问题积累起来，经过解决之后再进行推广，经过多轮切换演练后，数据中心间配置一致性的问题基本上能解决。 

董立国 哈尔滨银行架构师

生产端与容灾端参数配置

同城容灾环境涉及生产端与容灾端参数配置核对，但并不是所有参数都要求与生产端强一致，有一些类型参数是要求生产端与容灾端不同的，为了保证同城容灾端的参数配置正确，满足容灾切换的要求，需要制定基线版本、标准架构、 产制度以及检查监控方案等。

• 操作系统参数

同城环境搭建完成后，操作系统参数变更的频率并不大，所以主要强调在同城容灾环境搭建过程中，就要保证同城的操作系统相关参数满足容灾需求。如果有变更参数需要通过 产变更流程控制。

• 数据库参数

数据库基础参数在同城搭建完成后，变更的频率不高，所以在同城容灾环境搭建过程中，就要依据数据库安装基线，保证同城的数据库相关参数满足容灾需求。其他参数一般建立共享存储中，同步到容灾端。

• 中间件参数

中间件基础参数在同城搭建完成后，基础参数与配置参数变更的频率不高，所以在同城容灾环境搭建过程中，就要保证同城的相关参数满足容灾需求。数据源配置可根据容灾架构，建议选择解析的方式，不建议选择使用IP地址。

• 应用程序

在同城搭建完成后，应用程序变更是最频繁的，保证应用程序的生产与容灾环境版本同步与适用是重中之重。有些架构应用程序放置到共享存储同步到容灾环境，但是大部分应用程序尤其是多活应用都将应用程序部署到本地。

• 其他配置

容灾端的环境还涉及一些其他配置，如监控、备份、网络以及定时任务等。为保障容灾环境可用、健壮，需要将其他配置配备完全。

容灾配置管理机制

• 产制度

制定 产制度，当生产端进行 产时，需要同时 产容灾环境，并且配置容灾 产包。

• 配置管理

配置完善的CMDB，将生产端与容灾端相关配置项，全部更新到CMDB中，如果 产有变更，CMDB中同步变更相关配置项包括每次 产情况。

• 监控管理

生产与容灾端均需要配置完备的监控策略，包括配置文件的监控，例如根据生产端与容灾端的配置文件修改时间进行监控，如果时间差距大于24小时，告警提示容灾端配置文件是否同步 产更新。

• 基线管理

生产端与容灾端基础配置一致的基础为基线版本的管理，无论生产端与容灾端基础环境版本与配置一定要按基线版本配置，同时上线之前进行基线配置安全漏洞扫描，保证上线系统的基础环境与基线版本要求一致。

总结

完成同城容灾的建设后，为保证同城容灾环境在出现灾难的时候能够真正的接管业务，不仅要用技术手段完成生产与容灾端配置的校验，同时要在制度运维手册中规定相应的操作规范。如果每年的容灾演练都提前几周 几个月去检查环境准备容灾演练的工作，则同城的容灾环境只是一个昂贵的花瓶。

阅读更多《迈向YB数据时代》精彩内容，请识别以下二维码

• 2022年春季刊【持续运维】议题一 生产和同城存储双活架构下，发生链路抖动影响业务性能，如何快速发现问题、分析问题和解决问题？

• 2022年春季刊【持续运维】议题二 生产和同城存储双活架构下，发生脑裂问题影响数据库读写，如何快速分析问题和解决问题？

点击 ，到社区原文下与更多同行交流探讨↙↙↙

*本 所发布内容仅代表作者观点，不代表社区立场