一种容灾系统的管理方法和装置与流程

本申请涉及互联网技术(internettechnology，it)领域，尤其涉及一种容灾系统的管理方法和装置。

背景技术

容灾系统用于灾难发生时接替生产系统运行。在日常运维过程中，生产系统新产生的数据要及时复制到容灾系统。如果生产数据不能及时复制到容灾系统，那么容灾系统数据将无法满足恢复目标点(recoverypointobject，rpo)，导致容灾系统无法保证数据的安全。其中，rpo是衡量容灾数据完整性的指标，代表生产数据完整的复制到容灾系统的时间点要求。

现有技术的方案是对容灾数据复制状态做监控：通过设置定时任务执行容灾同步操作，当数据同步失败时，发送告警给管理员定位处理。

但是，直接通过同步结果状态做监控无法反映容灾系统数据是否满足各系统的rpo指标；并且告警分散，不同的同步类型监控机制不统一，从而导致容灾系统管理维护的效率低。

技术实现要素：

本申请实施例提供一种容灾系统的管理方法和装置，能够提高容灾系统管理维护的效率。

第一方面，本申请实施例提供一种容灾系统的管理方法，包括：监控平台从容灾节点获取n个待同步数据的同步结果；其中，n为大于0的整数；若监控平台确定n个待同步数据中的m个待同步数据的同步结果不满足rpo，监控平台生成告警信息；其中，m为大于0且小于或等于n的整数。

相比现有技术中直接对容灾数据的复制状态做监控，无法反映容灾数据是否满足各系统的rpo指标；且告警分散，不同同步类型的容灾数据的监控机制不统一。本申请实施例中，若监控平台确定n个待同步数据中的m个待同步数据的同步结果不满足rpo，监控平台生成告警信息，即本申请实施例可以统一监控多个待同步数据(容灾数据)的同步结果，能够提高容灾系统管理维护的效率。

并且，监控平台可以判断每个待同步数据的同步结果是否满足rpo，相比对容灾数据复制状态做监控，根据待同步数据的rpo指标(即待同步数据是否满足rpo)作监控能够更好的衡量待同步数据的完整性。

在一种可能的实现方式中，多个待同步数据可以采用不同的同步机制，从而可以统一监控不同的同步类型的待同步数据。

在一种可能的实现方式中，监控平台生成告警信息包括：监控平台确定告警信息的类型；监控平台生成告警信息；其中，告警信息包括告警信息的类型，告警信息的类型包括至少两个告警等级中的一个告警等级。

举例来说，告警等级可以包括普通等级和严重等级。监控平台可以根据待同步的数据对应的告警等级，选择通过短信息或电话的方式及时通知管理员对告警信息进行处理。例如，重要等级的告警信息通过电话通知，普通等级的告警信息通过短信息通知。

在一种可能的实现方式中，监控平台确定告警信息的类型包括：监控平台根据以下至少一项确定告警信息的类型：不满足rpo的待同步数据的数目、不满足rpo的待同步数据对应的应用的重要程度和待同步数据不满足rpo的次数。

其中，不满足rpo的待同步数据的数目和待同步数据不满足rpo的次数可以反映容灾系统的同步异常的影响范围，不满足rpo的待同步数据对应的应用的重要程度可以反映容灾系统重要性，即监控平台可以根据同步异常的影响范围和容灾系统重要性制定监控告警规则(例如确定告警信息的类型)，能够更好的保障容灾系统运行的稳定性。

在一种可能的实现方式中，该方法还包括：监控平台获取配置清单，配置清单包括容灾节点和容灾节点对应的生产节点的待检查的参数；监控平台根据配置清单获取配置信息，配置信息包括待检查的参数的取值；监控平台根据配置清单和配置信息生成检查报告，检查报告用于指示容灾节点和生产节点的配置是否一致。

基于该方案，监控平台以配置清单的格式维护容灾节点和容灾节点对应的生产节点的待检查的参数，通过对配置清单和配置信息做较对确定容灾节点和生产节点的配置是否一致。可以避免管理员人工维护容灾节点和生产节点的配置时，由于管理员的疏漏产生的容灾节点和生产节点的配置不一致的问题。

需要说明的是，监控平台可以获取不同平台、不同中间件对应的待同步数据的同步结果，以及对应不同平台、不同中间件的容灾节点和生产节点的待检查的参数，即监控平台可以兼容不同平台(如linux、unix、windows)、不同中间件(如oracle、sqlserver、was、mongodb)等各种监控场景，适用性强。

并且，监控平台进行管理维护时，例如调整待同步数据的rpo值时，或者调整告警级别时，或者调整配置清单中的相关参数时，可以直接修改监控平台上相关的配置项值，相较通过管理员分别对各个容灾节点和生产节点进行人工维护，本申请实施例提供的方案在管理维护时更加方便。

基于上述方法，一方面通过对多个待同步数据的同步结果统一监控，可以保证待同步数据的有效性；另一方面通过配置清单的格式维护容灾节点和生产节点的待检查的参数，保证了容灾系统在灾难场景下的有效性。

在一种可能的实现方式中，配置清单还包括映射关系清单和检查规则清单和白名单清单中的至少一个；其中，映射关系清单包括生产节点和容灾节点的映射关系；检查规则清单包括待检查的参数对应的检查规则；白名单清单用于指示生产节点和/或容灾节点的可忽略的参数。基于映射关系清单，在新上线或下线主机(主机可以是指生产节点或容灾节点)时，直接修改映射关系清单即可，使容灾节点和生产节点间的映射关系更容易维护。基于检查规则清单，可以确定检查项对应的检查规则，也可以直接修改检查规则清单中检查项对应的检查规则，使检查项和检查规则之间的对应关系更易维护。基于白名单清单，可以不校对生产节点和容灾节点之间无需保持一致的参数，能够减少不必要的校对以节约运行资源。

第二方面，本申请实施例提供一种容灾系统的配置方法，包括：监控平台获取配置清单，配置清单包括容灾节点和容灾节点对应的生产节点的待检查的参数；监控平台根据配置清单获取配置信息，配置信息包括待检查的参数的取值；监控平台根据配置清单和配置信息生成检查报告，检查报告用于指示容灾节点和生产节点的配置是否一致。

现有的容灾配置过程中，并未对容灾系统的配置和生产系统的配置做较对，而是依赖管理员在生产系统做变更时，对容灾系统也做相应操作。如果管理员没有同步实施容灾系统的变更，就会导致容灾系统与生产系统不一致。如图1所示的现有技术的容灾配置方案，当生产系统的相关配置变更后，各个管理员对相应的容灾系统也进行相应的操作(如打补丁、配置参数修改等)。其中，生产节点1对应容灾节点1，生产节点2对应容灾节点2。由于人工管理可能会出现疏漏，例如管理员可能漏掉对容灾节点2的变更，导致了生产节点2与容灾节点2的配置不一致。

举例来说，若生产系统的cpu、内存、网络升级后(如系统硬件扩容、平台搬迁、带宽由千兆升级为万兆)，容灾系统没有进行对应调整，那么在突发事件、紧急状态、或灾难发生期间，会导致应用启动后，只能满足少部分用户同时在线使用，无法满足业务对最小业务连续性目标(minimumbusinesscontinuityobjective，mbco)的要求。其中，mbco是指在突发事件、紧急状态、或灾难发生期间，为完成业务目标所能接受的最低服务水平及生产水平，是衡量容灾业务支撑能力的指标。若生产系统软件变更升级(如系统os升级搬迁、软件版本升级、补丁升级或app环境配置)，而容灾系统没有进行对应调整，会导致应用无法启动或启动后异常，需要在启动期间临时进行参数调整，拉长了容灾系统的启动时间，影响业务对恢复时间目标(recoverytimeobjective，rto)指标的要求。其中，rto是业务功能从中断点恢复到其最低业务持续目标所能承受的最大时间，从而使中断对业务所带来的冲击最小化，是衡量容灾恢复及时性的指标。

本申请实施例中，容灾节点和容灾节点对应的生产节点的待检查的参数以配置清单的格式维护，通过对配置清单和配置信息做较对确定容灾节点和生产节点的配置是否一致。可以避免管理员人工维护容灾节点和生产节点的配置时，由于管理员的疏漏产生的容灾节点和生产节点的配置不一致的问题。进一步的，可以避免容灾系统与生产系统的硬件或软件配置不一致产生的一系列问题。

在一种可能的实现方式中，配置清单还包括映射关系清单和检查规则清单和白名单清单中的至少一个；其中，映射关系清单包括生产节点和容灾节点的映射关系；检查规则清单包括待检查的参数对应的检查规则；白名单清单用于指示生产节点和/或容灾节点的可忽略的参数。基于映射关系清单，在新上线或下线主机(主机可以是指生产节点或容灾节点)时，直接修改映射关系清单即可，使容灾节点和生产节点间的映射关系更容易维护。基于检查规则清单，可以确定检查项对应的检查规则，也可以直接修改检查规则清单中检查项对应的检查规则，使检查项和检查规则之间的对应关系更易维护。基于白名单清单，可以不校对生产节点和容灾节点之间无需保持一致的参数，能够减少不必要的校对以节约运行资源。

在一种可能的实现方式中，该方法还包括：监控平台从容灾节点获取n个待同步数据的同步结果；其中，n为大于0的整数；若监控平台确定n个待同步数据中的m个待同步数据的同步结果不满足rpo，监控平台生成告警信息；其中，m为大于0且小于或等于n的整数。

相比现有技术中直接对容灾数据的复制状态做监控，无法反映容灾数据是否满足各系统的rpo指标；且告警分散，不同同步类型的容灾数据的监控机制不统一。本申请实施例中，若监控平台确定n个待同步数据中的m个待同步数据的同步结果不满足rpo，监控平台生成告警信息，即本申请实施例可以统一监控多个待同步数据(容灾数据)的同步结果，能够提高容灾系统管理维护的效率。进一步的，多个待同步数据可以采用不同的同步机制，从而可以统一监控不同的同步类型的待同步数据。并且，监控平台可以判断每个待同步数据的同步结果是否满足rpo，相比对容灾数据复制状态做监控，根据待同步数据的rpo指标(即待同步数据是否满足rpo)作监控能够更好的衡量待同步数据的完整性。

基于上述方法，一方面通过对多个待同步数据的同步结果统一监控，可以保证待同步数据的有效性；另一方面通过配置清单的格式维护容灾节点和生产节点的待检查的参数，保证了容灾系统在灾难场景下的有效性。

在一种可能的实现方式中，监控平台生成告警信息包括：监控平台确定告警信息的类型；监控平台生成告警信息；其中，告警信息包括告警信息的类型，告警信息的类型包括至少两个告警等级中的一个告警等级。

举例来说，告警等级可以包括普通等级和严重等级。监控平台可以根据待同步的数据对应的告警等级，选择通过短信息或电话的方式及时通知管理员对告警信息进行处理。例如，重要等级的告警信息通过电话通知，普通等级的告警信息通过短信息通知。

在一种可能的实现方式中，监控平台确定告警信息的类型包括：监控平台根据以下至少一项确定告警信息的类型：不满足rpo的待同步数据的数目、不满足rpo的待同步数据对应的应用的重要程度和待同步数据不满足rpo的次数。

其中，不满足rpo的待同步数据的数目和待同步数据不满足rpo的次数可以反映容灾系统的同步异常的影响范围，不满足rpo的待同步数据对应的应用的重要程度可以反映容灾系统重要性，即监控平台可以根据同步异常的影响范围和容灾系统重要性制定监控告警规则(例如确定告警信息的类型)，能够更好的保障容灾系统运行的稳定性。

第三方面，本申请实施例提供一种监控平台，包括：获取单元，用于从容灾节点获取n个待同步数据的同步结果；其中，n为大于0的整数；处理单元，用于若确定该n个待同步数据中的m个待同步数据的同步结果不满足恢复目标点rpo，生成告警信息；其中，m为大于0且小于或等于n的整数。

在一种可能的实现方式中，该处理单元用于：确定告警信息的类型；生成该告警信息；其中，该告警信息包括该告警信息的类型，该告警信息的类型包括至少两个告警等级中的一个告警等级。

在一种可能的实现方式中，该处理单元用于：根据以下至少一项确定该告警信息的类型：不满足rpo的待同步数据的数目、不满足rpo的待同步数据对应的应用的重要程度和待同步数据不满足rpo的次数。

在一种可能的实现方式中，该获取单元还用于获取配置清单，该配置清单包括容灾节点和该容灾节点对应的生产节点的待检查的参数；该获取单元，还用于根据该配置清单获取配置信息，该配置信息包括该待检查的参数的取值；该处理单元还用于根据该配置清单和该配置信息生成检查报告，该检查报告用于指示该容灾节点和该生产节点的配置是否一致。

在一种可能的实现方式中，该配置清单还包括映射关系清单和检查规则清单和白名单清单中的至少一个；其中，该映射关系清单包括该生产节点和该容灾节点的映射关系；该检查规则清单包括该待检查的参数对应的检查规则；该白名单清单用于指示该生产节点和/或该容灾节点的可忽略的参数。

第三方面及其各种可能的实现方式的技术效果可以参见第一方面及其各种可能的实现方式的技术效果，此处不再赘述。

第四方面，本申请实施例提供一种监控平台，包括：获取单元，用于获取配置清单，该配置清单包括容灾节点和该容灾节点对应的生产节点的待检查的参数；该获取单元，还用于根据该配置清单获取配置信息，该配置信息包括该待检查的参数的取值；处理单元，用于根据该配置清单和该配置信息生成检查报告，该检查报告用于指示该容灾节点和该生产节点的配置是否一致。

在一种可能的实现方式中，该配置清单还包括映射关系清单和检查规则清单和白名单清单中的至少一个；其中，该映射关系清单包括该生产节点和该容灾节点的映射关系；该检查规则清单包括该待检查的参数对应的检查规则；该白名单清单用于指示该生产节点和/或该容灾节点的可忽略的参数。

在一种可能的实现方式中，该获取单元还用于从容灾节点获取n个待同步数据的同步结果；其中，n为大于0的整数；该处理单元还用于若确定该n个待同步数据中的m个待同步数据的同步结果不满足恢复目标点rpo，生成告警信息；其中，m为大于0且小于或等于n的整数。

在一种可能的实现方式中，该处理单元用于：确定告警信息的类型；生成该告警信息；其中，该告警信息包括该告警信息的类型，该告警信息的类型包括至少两个告警等级中的一个告警等级。

在一种可能的实现方式中，该处理单元用于：根据以下至少一项确定该告警信息的类型：不满足rpo的待同步数据的数目、不满足rpo的待同步数据对应的应用的重要程度和待同步数据不满足rpo的次数。

第四方面及其各种可能的实现方式的技术效果可以参见第二方面及其各种可能的实现方式的技术效果，此处不再赘述。

第五方面，本发明实施例提供了一种装置，该装置以芯片的产品形态存在，该装置的结构中包括处理器和存储器，该存储器用于与处理器耦合，保存该装置必要的程序指令和数据，该处理器用于执行存储器中存储的程序指令，使得该装置执行上述方法中监控平台的功能。

第六方面，本发明实施例提供了一种监控平台，该监控平台可以实现上述方法实施例中监控平台所执行的功能，功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个上述功能相应的模块。

在一种可能的设计中，该监控平台的结构中包括处理器和通信接口，该处理器被配置为支持该监控平台执行上述方法中相应的功能。该通信接口用于支持该监控平台与其他网元之间的通信。该监控平台还可以包括存储器，该存储器用于与处理器耦合，其保存该监控平台必要的程序指令和数据。

第七方面，本发明实施例提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行第一方面提供的任意一种方法。

第八方面，本发明实施例提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行第一方面提供的任意一种方法。

附图说明

图1为现有技术中的一种容灾配置方案示意图；

图2为本申请实施例提供的一种容灾管理系统架构示意图；

图3为本申请实施例提供的一种数据复制监控模块的架构示意图；

图4为本申请实施例提供的一种配置一致性监控模块的架构示意图；

图5为本申请实施例提供的一种容灾系统的管理方法的信号交互示意图；

图6为本申请实施例提供的一种一个待同步数据的同步过程的示意图；

图7为本申请实施例提供的一种容灾系统的配置方法的信号交互示意图；

图8为本申请实施例提供的一种监控平台的结构示意图；

图9为本申请实施例提供的一种监控平台的结构示意图。

具体实施方式

本申请实施例提供一种容灾系统的管理方法和装置，应用于各种需要进行数据复制的场景。其中，数据可以包括生产数据或业务数据。例如，本申请实施例可以应用于生产数据的复制过程中。进一步的，本申请实施例可以应用于需要进行数据校对的场景。例如，可以应用于容灾系统和生产系统的配置一致性的管理，或系统搬迁过程中新老环境的配置一致性检查。

如图2所示，为本申请实施例提供的一种容灾管理系统架构示意图，包括监控平台、容灾基础数据平台、生产系统(productionsystem)和容灾系统(disasterrecoverysystem)。其中生产系统可以包括p个生产节点(生产主机)，容灾系统可以包括p个容灾节点(容灾主机)，m为大于1的整数。每个生产节点与每个容灾节点一一对应，例如，生产节点1对应容灾节点1。监控平台和容灾基础数据平台可以运行在第三方的节点上。第三方的节点指除生产节点和容灾节点之外的节点。需要说明的是，节点也可以称为模块、设备、或系统等，本申请不做限定。

监控平台用于从容灾系统中的至少一个容灾节点获取n个待同步数据的同步结果；其中，n为大于0的整数，m为大于0且小于或等于n的整数。若确定n个待同步数据中的m个待同步数据的同步结果不满足rpo，生成告警信息。

容灾基础数据平台用于生成配置清单。配置清单可以包括检查项清单，进一步的，还可以包括映射关系清单、检查规则清单和校对忽略白名单。

生产系统：正常情况下支持业务运作的信息系统，包括多个生产节点。生产节点用于产生生产数据。

容灾系统：用于灾难发生时接替生产系统运行进行数据处理和支持关键业务功能运作的系统，包括多个容灾节点。容灾节点用于复制生产数据。

在一种可能的设计中，监控平台可以包括数据复制模块和配置一致性监控模块。

如图3所示，为数据复制监控模块的一种架构示意图，数据复制监控模块包括数据采集层、网络应用程序(webservice)层、业务逻辑处理层和监控结果处理层。其中：

数据采集层用于从容灾节点获取n个待同步数据的同步结果。

网络应用程序层用于为n个待同步数据的同步结果提供接口，以便同步结果被传输至业务逻辑处理层；同时提供监控计划(如某个同步的rpo指标)录入接口，为业务逻辑层的较对提供参考数据。

业务逻辑处理层用于确定所述n个待同步数据中的每个待同步数据的同步结果是否不满足rpo。

监控结果处理层用于确定n个待同步数据中的m个待同步数据的同步结果不满足rpo时，生成告警信息。

如图4所示，为配置一致性监控模块的一种架构示意图。配置一致性监控模块可以用于(从容灾基础数据平台)获取配置清单，根据配置清单获取(收集)配置信息。而后，利用一致性校对工具根据配置清单和配置信息生成检查报告，检查报告用于指示容灾节点和生产节点的配置的一致性和/或不一致性。其中，配置清单可以包括映射关系清单、检查项清单、检查规则清单和校对忽略白名单。配置信息包括生产配置信息和容灾配置信息。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请的描述中，除非另有说明，“部分”或“全部”是指一个或多个，“多个”是指两个或多于两个。另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。

需要说明的是，本发明实施例中，“的(of)”，“相应的(corresponding，relevant)”和“对应的(corresponding)”有时可以混用，应当指出的是，在不强调其区别时，其所要表达的含义是一致的。

本申请实施例提供一种容灾系统的管理方法，如图5所示，包括：

501、监控平台从容灾节点获取n个待同步数据的同步结果。其中，n为大于0的整数。

n个待同步数据可以对应至少一个生产节点。监控平台可以存储至少一个生产节点对应的至少一个待同步数据的rpo。每个待同步数据可以包括预设时间间隔内一个生产节点产生的生产数据。预设时间间隔可以根据该生产节点的配置确定，例如可以是4小时。

举例来说，假设生产节点a在12个小时内产生了3个待同步数据，每个待同步数据包括4个小时内该生产节点产生的生产数据，3个待同步数据对应的rpo都为5小时。即，若每个待同步数据在5小时内被复制到相应的容灾节点，该待同步数据的同步结果满足rpo，否则待同步数据的同步结果不满足rpo。

对于每个待同步数据，如表1所示，监控平台存储有该待同步数据的监控规划(plan)信息，监控plan信息包括该待同步的数据对应的源主机、目标主机、应用、同步类型、实例名、该待同步数据的rpo和该待同步的数据对应的管理员。监控平台可以根据待同步的数据对应的源主机、目标主机、应用、同步类型和实例名识别该待同步的数据，而后确定该待同步的数据的同步结果是否符合该待同步数据的rpo，若不符合，可以通知该待同步的数据对应的管理员。需要说明的是，表1内各字段仅为示例，其它内容可根据需求做调整。

表1

表1所示的内容可以通过人工和自动化两种方式录入。其中：人工录入主要是针对少量且监控内容不尽相关的同步类型：如少量的robocpy或dataguard同步类型。自动录入主要针对同步类型相同、变化大、数量多的同步需求：如大量的nas卷、notes库等同步需求。

对于每个待同步数据，监控平台可以通过表2所示的监控记录(log)来监控该待同步数据的同步过程和同步结果。需要说明的是，表2内各字段仅为示例，其它内容可根据需求做调整。

表2

在一种可能的设计中，获取表2中的待同步数据的同步状态的方式可以是：通过定时调度在各生产节点上部署的脚本(如sh、js、python、java等脚本)，获取监控日志。而后，将采集到的监控日志组成jason格式，通过超文本传输协议(hypertexttransferprotocol，http)调用webservice层上传到监控平台。上传过程可以包括两步，第一步：在数据同步开始时进行插入(insert)操作将待同步数据的状态设置为运行(running)，并标记开始时间。第二步，在数据同步结束时对待同步数据的状态做更新(update)操作，update的字段可以为结束时间(endtime)、syncstatus、remark等。例如，可以将running修改为endtime。

502、若监控平台确定n个待同步数据中的m个待同步数据的同步结果不满足rpo，生成告警信息；其中，m为大于0且小于或等于n的整数。

在一种可能的设计中，监控平台可以按照业务逻辑对表1所示的待同步数据的监控plan信息和表2所示的监控log做较对。具体的，在待同步数据规定的rpo内，检查该待同步数据是否包括同步状态为success的log信息，如果有，则该待同步数据的同步结果满足rpo要求，如果没有，则该待同步数据的同步结果不满足要求。

当监控平台确定n个待同步数据中的m个待同步数据的同步结果不满足rpo时，监控平台确定告警信息的类型。监控平台可以根据以下至少一项确定告警信息的类型：不满足rpo的待同步数据的数目、不满足rpo的待同步数据对应的应用的重要程度和待同步数据的同步结果不满足rpo的次数。而后，监控平台生成告警信息。其中，告警信息包括告警信息的类型，告警信息的类型包括至少两个告警等级中的一个告警等级。例如，至少两个告警等级可以包括普通等级和严重等级，即告警等级可以分为普通等级和严重等级。示例性的，当1个待同步数据的同步结果不满足rpo时，可以生成普通等级的告警信息；当20个待同步数据的同步结果不满足rpo时，可以生成严重等级的告警信息。若1个待同步数据对应的应用的重要程度高时，当该待同步数据的同步结果不满足rpo时，可以生成严重等级的告警信息。当1个待同步数据的同步结果不满足rpo的次数为1次时，可以生成普通等级的告警信息。当1个待同步数据的同步结果不满足rpo的次数为5次时，可以生成严重等级的告警信息。

举例来说，如图6所示，是一个待同步数据的同步过程的示意图。假设监控log每一个小时上传一次(即待同步数据每小时同步一次)、该待同步数据的rpo是4小时、当该待同步数据不满足rpo的次数为5次时生成紧急告警。根据图6可知，待同步数据在4点第一次同步失败，在7点第四次同步失败，且该待同步数据的同步结果在7点第一次不满足rpo，此时监控平台生成普通等级的告警信息。该待同步数据的同步结果在11点第二次不满足rpo，此时监控平台生成普通等级的告警信息。该待同步数据的同步结果在15点第三次不满足rpo，此时监控平台生成普通等级的告警信息。该待同步数据的同步结果在19点第四次不满足rpo，此时监控平台生成普通等级的告警信息。该待同步数据的同步结果在23点第五次不满足rpo，此时监控平台生成严重等级的告警信息。

503、监控平台将告警信息发送给管理员。

监控平台可以根据待同步的数据对应的告警等级，选择通过短信息或电话的方式及时通知管理员对告警信息进行处理。例如，重要等级的告警信息通过电话通知，普通等级的告警信息通过短信息通知。管理员处理完事件后，监控平台可以生成一条success状态的log。容灾系统可以从该success状态的log的时间点开始复制新的待同步数据，该新的待同步数据的rpo从该时间点开始计算。

另外，监控平台可以汇集历史监控结果，以便在后续过程中进行数据统计分析或看板展示等。例如，对各种同步类型的成功率进行统计。或者，对预设时间(例如，一个月)内同步异常次数最多的生产节点进行统计，以便进行优化改进等。

相比现有技术中直接对容灾数据的复制状态做监控，无法反映容灾数据是否满足各系统的rpo指标；且告警分散，不同同步类型的容灾数据的监控机制不统一。本申请实施例中，若监控平台确定n个待同步数据中的m个待同步数据的同步结果不满足rpo，监控平台生成告警信息，即本申请实施例可以统一监控多个待同步数据(容灾数据)的同步结果，能够提高容灾系统管理维护的效率。进一步的，多个待同步数据可以采用不同的同步机制，从而可以统一监控不同的同步类型的待同步数据。

并且，监控平台可以判断每个待同步数据的同步结果是否满足rpo，相比对容灾数据复制状态做监控，根据待同步数据的rpo指标(即待同步数据是否满足rpo)作监控能够更好的衡量待同步数据的完整性。

本申请实施例提供一种容灾系统的配置方法，如图7所示，包括：

701、监控平台获取配置清单，配置清单包括容灾节点和容灾节点对应的生产节点的待检查的参数。

在一种可能的设计中，监控平台可以从容灾基础数据平台获取配置清单，配置清单可以包括检查项列表，检查项列表可以包括容灾节点和该容灾节点对应的生产节点的待检查的参数。举例来说，检查项列表可以包括硬件层参数：例如，中央处理器(centralprocessingunit，cpu)、内存、输入/输出端口(input/output，i/o)、网络时延(例如mbco指标信息)等；以及软件层参数：例如，软件包管理器(rpm(revolutionsperminute)packagemanager)版本、用户身份证明(useridentification，uid)/群体身份(groupidentification，gid)、网络附加存储(networkattachedstorage，nas)挂载路径等。当待检查的参数有变更时，可以直接修改、增加或删除检查项列表中的参数。

在一种可能的设计中，配置清单还可以包括映射关系清单、检查规则清单和白名单清单中的至少一个。其中，映射关系清单包括生产节点和容灾节点的映射关系。在新上线或下线主机时，直接修改映射关系清单即可。检查规则清单包括不同的待检查的参数分别对应的检查规则。检查规则与检查项的类型相对应。例如，对于字符串(string)类型的检查项，可通过包含(contain)、开始(beginwith)、结束(endwith)、相等(equal)等方式做较对；对于数字(number)类型的检查项，可通过equal、小于(lessthan)、大于(greaterthan)等百分比范围的方式做较对，以检查容灾端配置是否满足要求。白名单清单用于指示生产节点和/或容灾节点的可忽略的参数，即生产节点和容灾节点之间无需保持一致的参数。

702、监控平台根据配置清单获取配置信息，配置信息包括待检查的参数的取值。

监控平台可以根据配置清单在各生产节点和容灾节点上采集配置信息(配置数据)，并将这部分信息集中上传。监控平台可以通过安全外壳协议(secureshell，ssh)，或通过在生产节点上和容灾节点上安装代理(agent)方式与各主机连接。而后，针对不同的操作系统(operatingsystem，os)平台，下发不同类型的脚本(命令)以获取采集结果(配置信息)。例如，不同类型的脚本可以包括linux的sh脚本、windows平台的js脚本或powershell脚本等。并且，针对不同检查类型，使用不同信息收集脚本。而后，监控平台将采集结果统一存放，方便对数据读取。

703、监控平台根据配置清单和配置信息生成检查报告。

监控平台对数据采集完成后，将配置清单和配置信息作较对，生成检查报告，检查报告用于指示容灾节点和生产节点的配置是否一致。举例来说，假设生产节点1对应容灾节点1，生产节点1和容灾节点1对应的检查报告可以如表3所示：

表3

检查报告可以是表格(例如excel)清单，可以通过浏览器(例如ie)页面访问检查报告，以便管理员根据检查报告进行相应的处理。例如，当管理员查看如表3所示的检查报告时，可以对容灾节点1的rpm包版本进行升级，以便和生产节点1的rpm包版本保持一致。

本申请实施例中，容灾节点和容灾节点对应的生产节点的待检查的参数以配置清单的格式维护，通过对配置清单和配置信息做较对确定容灾节点和生产节点的配置是否一致。可以避免管理员人工维护容灾节点和生产节点的配置时，由于管理员的疏漏产生的容灾节点和生产节点的配置不一致的问题。进一步的，可以避免容灾系统与生产系统的硬件或软件配置不一致产生的问题。

需要说明的是，如图5和图7所示的方法流程可以进行结合，组成一个新的方法实施例，本申请不做限定。基于图5和图7所示的方法，一方面通过对多个待同步数据的同步结果统一监控，可以保证待同步数据的有效性；另一方面通过配置清单的格式维护容灾节点和生产节点的待检查的参数，保证了容灾系统在灾难场景下的有效性。

上述主要从监控平台的角度对本申请实施例提供的方案进行了介绍。可以理解的是，监控平台为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对监控平台进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，图8示出了上述实施例中所涉及的监控平台8的一种可能的结构示意图，监控平台包括：获取单元801和处理单元802。获取单元801用于支持发送装置执行图5中的过程501，图7中的过程701；处理单元802用于支持监控平台执行图5中的过程502和503，图7中的过程702和703。其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

在采用集成的单元的情况下，图9示出了上述实施例中所涉及的监控平台的一种可能的结构示意图。该监控平台9包括：处理器901、收发器902、存储器903以及总线904。其中，收发器902、处理器901以及存储器903通过总线904相互连接；总线904可以是外设部件互连标准(peripheralcomponentinterconnect，pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，eisa)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(randomaccessmemory，ram)、闪存、只读存储器(readonlymemory，rom)、可擦除可编程只读存储器(erasableprogrammablerom，eprom)、电可擦可编程只读存储器(electricallyeprom，eeprom)、寄存器、硬盘、移动硬盘、只读光盘(cd-rom)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于asic中。另外，该asic可以位于核心网接口设备中。当然，处理器和存储介质也可以作为分立组件存在于核心网接口设备中。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请的保护范围之内。