CN108234482A - 一种无中断灾难恢复测试的自动网络隔离方法及系统 - Google Patents

Abstract

本发明公开了一种无中断灾难恢复测试的自动网络隔离方法及系统，在主站点和辅助站点之间创建网络隔离，网络隔离允许辅助站点上的测试不破坏站点的正常操作，包括在测试期间进行故障转移的能力，这种非中断网络隔离允许某些连续通信，特别是具有复制数据能力的端口之间的通信，网络隔离可以以各种方式进行定制，并在允许某些通信连续的同时防止其他通信进行。本发明可以用于验证应用程序就绪性以及验证各个层的数据正确性，并且可以用于包含多个层的系统，并且包括物理主机、虚拟主机和两者的组合。

Description

一种无中断灾难恢复测试的自动网络隔离方法及系统

技术领域

本发明涉及灾难测试技术领域，特别是一种无中断灾难恢复测试的自动网络隔离方法及系统。

背景技术

随着近年来电子商务的增加，对数据中心更加强大和复杂的需求也随之而来。传统上，企业通常能够在单个物理服务器上托管所有的在线服务的组件。例如，包括Web服务器，应用程序和底层数据库的在线服务通常都被托管在同一物理服务器上。然而，随着这些在线服务的规模和复杂程度的增长，这种传统方法在最好的情况下变得不那么优化，有时甚至在最坏的情况下完全不可用。

因此，许多实体已经开始将托管的在线业务的数据中心或实体的在线业务的其他方面，以优化这些数据中心的组件。优化这些数据中心的一个常见方法是以单独的层级部署每个组件，通常会为每个层产生不同的硬件和软件要求。因此，这种优化往往会导致额外的复杂性。例如，每个层都可以被优化以使用不同的操作系统，并且可以部署在不同的物理机器上。作为一个示例，可以使用虚拟机（例如， VMware虚拟机）将web组件部署在web层中，应用组件可以使用企业应用，并且可以使用针对数据库功能进行优化的软件平台将数据库组件部署在数据库层中。从以上的例子可以看出，一个多层应用可以包括各种类型的组件，例如物理计算环境、虚拟计算环境和混合计算环境。

发明内容

本发明的目的在于克服现有技术的不足，提供一种无中断灾难恢复测试的自动网络隔离方法及系统，解决了传统数据中心无法应付日益增长的电子商务的需要，本发明可以用于验证应用程序就绪性以及验证各个层的数据正确性，并且可以用于包含多个层的系统，并且包括物理主机、虚拟主机和两者的组合。

本发明的目的是通过以下技术方案来实现的：

一种无中断灾难恢复测试的自动网络隔离方法，该方法应用于跨物理和虚拟主机之间的多层应用程序，所述方法包括：

将数据从生产站点复制到辅助站点，所述辅助站点配置有次级多层应用程序，并且次级多层应用程序是在生产站点上执行的主要多层应用程序的副本；

配置防火墙，用以在主要多层应用程序和次级多层应用程序之间提供网络隔离，允许网络隔离正在进行时在生产站点和辅助站点之间进行复制；

测试应用程序的多个节点，测试包括复制正在进行的次级多层应用程序。

优选的，所述方法包括：配置防火墙还包括配置允许所述辅助站点在测试期间执行一个或多个操作时，执行不属于所述测试的一个或多个操作。

优选的，所述方法包括：获取生产站点的一个或多个守护进程的参数，并将获取的参数用于配置防火墙。

优选的，在配置防火墙之前，还包括提供一个或多个参数到辅助站点的一个或多个守护进程上。

优选的，所述方法包括：更新主机映射表，并将主机映射表存储在辅助站点上，并在测试时调取主机映射表。

优选的，所述方法包括：在测试过程中，创建一个或多个服务组的克隆体，每个所述克隆体对应一个主站点或辅助站点上的一个服务组。

优选的，所述方法包括：当检测到与生产现场相关的故障时，则执行停止操作，并根据检测到的故障激活辅助站点。

一种计算机系统，包括一个处理器和一个耦合到处理器的内存；

所述内存用于存储处理器执行的指令，所述指令用于将数据从生产站点复制到辅助站点；所述辅助站点包括次级多层应用程序，且所述次级多层应用程序为主要多层应用程序在生产站点上执行时的副本；

所述辅助站点同时配置一个用于对主要多层应用程序和次级多层应用程序起到网络隔离作用的防火墙，所述防火墙允许复制操作发生在网络隔离生效的主要多层应用程序和次要应用程序之间。

本发明的有益效果是：本发明在主站点和辅助站点之间创建网络隔离，网络隔离允许辅助站点上的测试不破坏站点的正常操作，包括在测试期间进行故障转移的能力，这种非中断网络隔离允许某些连续通信，特别是具有复制数据能力的端口之间的通信，并在允许某些通信连续的同时防止其他通信进行；本发明可以用于验证应用程序就绪性以及验证各个层的数据正确性，并且可以用于包含多个层的系统，并且包括物理主机、虚拟主机和两者的组合。

附图说明

图1是本发明实例1主要站点、辅助站点和防火墙构成的多层计算系统的框图；

图1A是本发明主要站点的附加细节的框图；

图1B是本发明辅助站点的附加细节的框图；

图2是本发明灾难恢复测试的一部分执行的动作流程图；

图3是本发明用于执行灾难恢复测试的方法流程图；

图4是本发明用于停止灾难恢复测试的方法流程图；

图5是本发明的计算设备的框图；

图6是本发明的联网系统的框图。

具体实施方式

下面结合附图进一步详细描述本发明的技术方案，但本发明的保护范围不局限于以下所述。

现代数据中心通常包括多层应用，这种多层配置可能相当复杂，并且辅助站点的配置也必须模拟主要站点的多层配置。尽管具有这些复杂性，但是无论其结构配置如何，都能够充分测试辅助站点，并且不会中断主站点的正常运行。同样重要的是，测试辅助站点的能力，而不会中断辅助站点本身的功能。特别是测试过程中主站点失败时，辅助站点的上线能力。

为了解决这些问题，需要一种在不中断主站点、辅助站点本身或连接到任意一个站点的其他站点功能情况下，可以测试辅助站点准备情况的解决方案。在本申请的详细讨论中，提出了对这些需求的解决方案。准备测试的解决方案可以自动创建和移除定制的网络隔离（例如，防火墙），在辅助站点上配置和运行测试（例如，防火演习）或其他操作，并且可以停止测试（或其他操作），并删除网络隔离，而不会中断主站点、辅助站点本身或连接到任一站点的任意站点的正常功能。在网络隔离的其它方面，本申请公开的发明允许主站点和辅助站点之间完全隔离，但是能够选择性地允许在某些层、主机、节点或端口之间传输数据。此外，本文公开的网络隔离不需要在主站点上进行任何配置更改，并且不需要主站点进行任何停机操作。此外，辅助站点上的网络隔离和测试（或其他操作）都不会妨碍辅助站点的测试或其他操作期间出现的实际故障转移的能力。

本申请描述用于执行灾难恢复准备测试的方法和系统，本领域也称为灾难恢复“消防演习”。更具体地，本申请公开的方法和系统提供对具有多层应用的站点进行灾难恢复准备测试。本申请公开的方法和系统进一步提供了执行测试而不中断在测试期间主要（例如，生产站点）站点或辅助（例如，灾难恢复或“故障切换”）站点正常工作的能力。此外，尽管这里讨论的内容的一个实例涉及灾难恢复准备测试，但是本发明的其它实例也是存在的，作为替代实例的一个示例，本申请公开的内容也可以应用于虚拟“沙箱”，其可以用于训练新员工或测试和配置新系统。

图1包括初级站点110和通过网络150耦合的辅助站点130的多层计算系统的框图。一般而言，生产站点110是当前托管多层应用程序的站点。因此，在正常操作过程中，生产地点生产、接受和消耗用户数据（例如，网络交易中影响金融或零售数据库中的数据）的生产现场。生产站点110包括生产多层应用程序120，在一个实例中，生产多层应用程序120包含三个层--- web层121、应用层122和数据库层123。这些层中的每一个都可以包括在图1A中所示的生产站点110的增强版。本发明中描绘的守护进程或脚本（诸如守护进程128（1）、128（2）和（3）），的使用将在本文的其他部分进行讨论。此外，尽管在图1中未示出，但是每个层都可以在一个节点集群上实现，或者在单个节点上实现。如本领域所理解的，“节点”可以在任何具有IP地址的物理或虚拟机器（例如，计算机，笔记本，台式机，工作站，服务器，智能电话或任何其他计算设备）上实现。如图1A所示，每层都可以包括一个或多个服务组，并且可以被认为是“虚拟容器”，用于管理运行应用程序所需的资源。在一个实例中，例如，Web服务组（WEB_SG）124用于管理web层121的资源，应用服务组（APP_SG）125用于管理数据库服务组122的资源，数据库服务组（DB_SG）126用于管理数据库层123。WEB_SG 124，APP_SG125和DB_SG 126用于管理运行生产多层应用程序120所需的资源。

与生产现场110相比较，生产现场110是用于为用户提供服务的“实时”站点，灾难恢复站点130处于“随时待命”状态，即，如果生产场所110出现故障，如崩溃、脱机或由于任何其他原因变得不可用时，灾难恢复站点130准备随时接管生产现场。如果生产站点110“失败”，将流量流转换到灾难恢复站点130的过程被称为“故障转移”。在某些情况下，故障转移可能会导致生产站点110和灾难恢复站点130切换角色，尽管不一定是这种情况（例如，如果生产站点不再能够成为灾难的方式发生故障恢复站点）。

因此，如果生产站点110“失败”，灾难恢复站点130必须能够上线或进行“故障转移”。同时，灾难恢复站点130应该能够模拟主站点110的基本功能，特别是生产多层应用程序120的功能。灾难恢复站点130还包括灾难恢复多层应用程序140，其应该配置为模拟生产多层应用程序120。

如图1A中所示为复制数据127，其在该示例中是从生产数据库层123中复制的数据。在其他实例中，任何生产站点层应该具有与其相关联的复制数据。

如图1B所示的实例，灾难恢复多层应用程序130还包含三层（即相同数量的层是生产站点110）---web层141、应用层142和数据库层143。如生产地点110的情况一样，灾难恢复站点130上的每层还包括守护进程或脚本，诸如守护进程148（1）、148（2）和148（3）。每层还包括与生产多层应用程序120相关的服务组相对应的服务组。在具有不同层级和配置的其他实例中，辅助（例如，灾难恢复或“沙盒”）站点上的服务组将对应于主要（例如，生产）站点上的任何服务组。

如图1B中所示为复制数据147，在该示例中是从生产数据库层123复制的数据。在其他实例中，任意辅助（例如，灾难恢复或“沙箱”）站点层可以具有与其相关联的复制数据，其中每组复制数据是从相应的主要（例如生产）站点层复制而来的数据。另外，图1B还描绘了每个灾难恢复服务组的克隆以及复制数据149的快照（例如，时间点的复制）。

另外，虽然在图1和图1B中未示出，但辅助（例如，灾难恢复）站点的每一层都可以在节点集群上实现，或者在单个节点上实现。然而，尽管辅助站点（特别是灾难恢复站点）必须包含与辅助站点备份的主站点（例如，生产站点）相对应的层，但是每个灾难恢复层都可能包含更多或更少的主要（例如生产）站点的相应层中的节点。此外，辅助站点还可能具有其他目的，除了作为备用站点之外，还能作为不同主站点的备份站点，并且用作多层应用程序的主站点。因此，辅助站点可能具有不存在于主站点上的附加层。

再次返回到图1，网络150将生产现场110耦合到灾难恢复站点130。网络150允许生产站点110和灾难恢复站点130之间的通信（或在其他实例中，允许除灾难恢复站点130之外的第二站点，并且包括这些站点之间的数据传输。网络150还允许任意主站点和辅助站点之间的通信，而忽略其特定配置、用途和目的如何。因此，网络150允许通过网络连接的任意两个站点之间进行复制（以及其他动作）。尽管图1将网络150描述为仅直接连接数据库层，但是来自其他层的流量仍然可以流经网络150，并且在某些实例中，其他网络（类似于网络150）可以连接不同的层。此外，在某些实例中，生产站点上的层/节点与辅助站点上的层/节点（例如，灾难恢复站点130）之间可以存在多个网络，并将在其他地方更详细讨论。图1还描绘了防火墙160，其可以用于创建网络隔离并且规范主站点（例如，生产站点110）和辅助站点（例如，灾难恢复站点130）之间的数据传输。

生产站点110可以托管网页、应用程序、数据库和其他内容（统称为“内容”）。在一个实例中，生产地点110的一个或多个层可以包含由一个或多个用户计算机（例如，例如，用户计算机170（1）-170（N））经由因特网或内联网180下载的内容。使用生产多层应用程序120作为示例，生产web层121包含用户计算机可以下载的内容，诸如用户计算机170（1）-170（N）。生产web层121可以包含下载到用户计算机然后在该机上运行的网页或应用程序。任何具有因特网/内部网连接的用户通常都可以访问生产网络层121，或者仅可以访问具有访问生产站点的许可用户（例如，通过密码、IP地址、所需凭证或任何其他验证方法）。

字母N用于表示可变数量的设备或组件，例如，在上述系统中实现可变数量的用户计算机。尽管字母N用于描述各种不同的设备或组件的可变数量的实例，但是重复使用字母N并不全然指示每个设备和组件具有在任意给定系统中实现的相同数量的N个实例。

一个或多个生产站点110可以包含用于促进用户计算机与多层应用的其他层之间的通信内容。使用生产多层应用程序120作为示例，web层121可以包含可由用户计算机170（1）-170（N）访问的内容，并且可以与用户计算机170（1）-170（N）进行通信。在一个实例中，应用层122可以是在生产站点110上运行的应用服务器，web层121可以由一个或多个用户计算机170（1）-170（N）经由因特网/内联网180直接访问，并且与应用层122以期望的内容提供给用户计算机170（1）-170（N）。应用层122还可以促进从一个或多个用户计算机170（1）-170（N）接收的数据的接收和处理。另外，应用层122和数据库层123包括与这些层中的任一层相关联的内容之间的通信。在某些实例中，应用层122还用于促进用户计算机170（1）-170（N）和数据库层123之间的通信。

此外，生产地点110还包含一个或多个不能由用户直接访问的层。然而，这些层包含从用户计算机（例如用户计算机170（1）-170（N））接收、传送到或以其他方式交互的内容。在一个实例中，数据库层123将包含数据库以及相关的软件和功能。数据库可以是任意类型的数据库，并且相关软件是能够与数据库一起使用的任何类型。在一个实例中，数据库层123将直接与应用层122进行通信，用于向Web层121提供数据以及从Web层121接收数据。然而，在该实例中，数据库层123可能不会直接与web层121通信（即，不通过应用层122）。

辅助站点（例如，灾难恢复站点130）通常不适用于计算机170（1）-170（N）。然而，如果主要站点（例如，生产地点110）出于任何原因故障（例如，“崩溃”或以其他方式脱机），则辅助站点（例如，灾难恢复站点130）被用于提供给用户计算机170（1）-170（N）。例如，如果生产现场110发生故障，则系统可能被设计为“故障转移”到灾难恢复站点130。当系统“故障转移”到灾难恢复站点130时，所有流量将被路由到灾难恢复站点130。从诸如用户计算机170（1）-170（N）的最终用户的角度来看，该转换应该是无缝的（或者在该情况下尽可能接近无缝）。因此，灾难恢复站点130必须能够提供生产地点110的功能，并且至少包括生产多层应用程序120的功能以及其中包含的每个层级的功能。因此，灾难恢复站点上的多层应用层对应于生产现场的多层应用层次，并能够执行其功能。在一个实例中，灾难恢复站点130构成辅助（或灾难恢复）多层应用程序140，并且包含web层141，应用层142和数据库层143。在该实例中，这些层与生产地点110上的相应层级对应。灾难恢复站点130通过网络150耦合到生产站点110进行通信。其中，网络150是能够传输数据的任意类型的网络。

重要的是，可能会存在生产多层应用的许多其他配置。本文给出的示例仅作为帮助本文所讨论的问题使用。在实践中，生产多层应用可以包含比三层更多（或更少）层，也可以只包含一个未在此明确讨论的层，并且可以排除本文中讨论的一个或多个层。这些层包含了在生产多层应用中可以以不同于本文具体描述的方式进行直接或间接通信的方式。虽然这些变化也适用于辅助（例如，灾难恢复）多层应用，但辅助（例如，灾难恢复）多层应用程序仍应以与生产多层应用程序相同的方式运行。因此，辅助（例如，灾难恢复）站点可以具有与本文所描述的不同的层级和配置，但是应当具有与主要（例如，生产）站点相同的层级和配置。该要求有助于确保生产多层应用程序在辅助（例如灾难恢复）站点进行“故障切换”，而不会在功能上发生任何重大变化。

图1中也给示出了防火墙160。防火墙160不需要在任何时候都是活动的和可操作的，但是当需要时可以被调用（例如，在灾难恢复站点130的测试期间，或者在辅助站点被使用时作为虚拟的“沙箱”（例如，用于培训个人，测试新软件、硬件、配置等））。它防止在辅助站点的测试或其他使用期间在主站点（例如，灾难恢复站点130）之间传送某些数据，并且可以选择性地允许某些数据在主要站点（例如，生产站点110）和辅助站点（例如，灾难恢复站点130）之间传送。除此之外，还能防止在辅助站点（例如，灾难恢复站点130）的测试或其他使用期间在主要站点（例如，生产站点110）上的数据被意外地损坏、改变或删除。

图1还描绘了集中式操作管理器190，它可以在一个实例中用于执行与本文公开发明相关的各种功能，包括收集、存储和推送从生产地点110到灾难恢复站点130（或任何其他次要站点）的网络参数。其本身可以包括用于收集、存储和推送网络参数并用于执行其他功能的守护程序、脚本和其他进程（例如守护进程191）。并且还可以包括附加或备用软件（例如，服务器640A）；或者直接在包括系统存储器517的硬件（例如，任意类型的计算机或计算设备，任意类型的计算机芯片等）中实现。在一个实例中，集中式操作管理器190可以分成硬件组件的各种硬件设备，例如服务器640A，第二服务器（例如，服务器640B）和系统存储器517。并且在一个实例中，可以使用多个集中式操作管理器。

此外，附图中所示的连接仅用于说明的目的，所以其它形式的配置也是可能的。例如，尽管在生产地点110，灾难恢复站点130和用户计算机170（1）-170（N）之间显示了连接图，但是这些连接仅用于说明的目的，并且其他形式的连接配置也是可能的。

例如，一个或多个生产层可以在物理外部与生产地点110表示的主要位置进行耦合；同理，灾难恢复层（或辅助站点上的其他层，例如“沙箱”层）也是如此。类似地，复制数据147和快照数据149也可以在逻辑上和物理上与辅助站点（例如，灾难恢复站点130）分离。

图2示出了在灾难恢复准备测试（即“消防演习”）期间执行的动作，并且还将其用于实现其它目的（例如，“沙盒”测试训练）。因此，尽管在本文中解释了本发明主要涉及其对灾难恢复测试的适用性，但是本发明不应被视为仅限于用于灾难恢复测试。如上所述，本发明的网络隔离（例如，防火墙）方面可以应用于许多其它的目的，包括在此引用的虚拟“沙箱”测试或训练。虽然这些步骤可能不具有相同的名称，但一般的功能将保持大体相同（例如，沙盒服务组可以用于代替灾难恢复服务组）。除非另有说明，否则下面讨论的步骤可以在不妨碍本发明所描述的功能的情况下被应用（例如，训练或其它测试）。

在关注于本发明的灾难恢复测试方面的一个实例中，灾难准备测试开始于配置灾难恢复站点以在210进行测试。如210所示，配置灾难恢复站点130（或另一个辅助站点）以执行一个从生产站点110收集网络参数开始的测试（例如，定义主站点（例如生产站点110）的不同层或节点如何与其他层或节点通信的参数）。例如，网络参数可以包括生产多层应用120的节点的入侵IPS参数、IP地址、虚拟IP地址、主机名、虚拟主机名以及其他潜在的网络参数。

在一个实例中，网络参数可以被诸如集中式操作管理器190之类的集中式操作管理器收集和存储。收集网络参数的过程包括使用守护进程或脚本（例如守护进程128（1）、128（2）、128（3）），或者在将这些网络参数发送到辅助站点（例如，灾难恢复站点130）之前将其提供给集中式通信模块。一旦收集了网络参数，则可以将网络参数推送或以其他方式提供给在辅助站点（例如，灾难恢复站点130）上运行的守护程序（例如，守护进程148（1）、148（2）和148（3））。

一旦将网络参数提供给辅助（例如，灾难恢复站点）站点，操作230将配置并运行测试（例如，防火演习，训练中的其他测试等）。在测试期间或测试完成后，测试软件可以直接在240处向用户（例如，系统管理员，数据库管理员，参与培训的人员，参与测试和配置（或重新配置）站点或其部分的人员等）提供反馈或直接向系统提供反馈。测试完成后，操作250停止并取消配置消防演习（或沙箱、其他测试或其他应用）。操作230、240和250将结合本文包括的示图的其它部分进行更详细的讨论。

图3所示，是方法300的流程图，其包括在配置和运行测试或其他操作（例如灾难恢复准备测试230）时执行的动作。在一个实例中，测试（或其他操作）通过在310创建复制数据（“快照数据”）的时间点快照，复制数据本身是与主要站点相关联的数据副本，例如作为生产站点110，对于具有复制的任何生产站点层级将存在复制数据。可以使用同步、异步或周期性技术执行复制过程。在一个实例中，可以使用市售的存储复制器来执行复制过程。

复制过程需要确保辅助站点（例如，灾难恢复站点130）总是处于与生产站点一致的状态（即在生产站点实际存在或的状态）。因此，复制数据本身不能通过测试过程进行更改，并且还必须在测试期间由复制过程提供。特别是在灾难恢复准备测试（或在灾难恢复站点上执行的其他测试或培训）的背景下，如果在测试期间需要从生产现场进行“故障切换”，这些措施有助于确保灾难恢复站点提供准确和最新的复制数据。因此，创建复制数据的快照数据（例如，复制数据的时间点副本，其本身是生产站点的数据副本）用于测试（包括沙盒测试或培训，或使用本文讨论的任何方面的其它应用）。使用快照数据进行测试有助于保护生产站点上的“实时”数据和辅助（例如，灾难恢复或沙箱）站点上的复制数据的完整性。在一个实例中，复制数据的快照由辅助（例如，灾难恢复或沙箱）站点层（例如，守护进程148（1）、148（2）和148（3））上的后台驻留程序创建。

复制数据和快照数据可以存储在辅助（例如，灾难恢复）站点或耦合到辅助（例如灾难恢复）站点130的任何存储介质中，也可以存储在物理上或逻辑上不同于辅助站点（例如，灾难恢复站点130）的非瞬时数据存储介质中。此外，复制数据和快照数据不会存储在相同的非瞬态数据存储介质中，也不需要彼此存储在相同的物理或逻辑设备上。同时，可以使用的非瞬态数据存储介质有许多不同类型，诸如硬盘驱动器，RAM，ROM，闪存，固态存储器，RAID设备和光学存储设备等。

除了在测试期间保护复制的数据免受任何无意的修改外，另一个关键是，致力于提高主站点（例如，生产站点110）和辅助站点（例如，灾难恢复场地130）之间的“串扰”风险。“串扰”可以被认为是一个站点（例如，灾难恢复站点130）上的层或节点与另一站点（例如，生产站点110）上的层或节点之间的无意通信。例如，在测试期间，各种模拟客户端（例如，下面讨论的WEB_FD_SG 144）可以执行涉及修改快照数据149的交易。为了保持主要（例如，生产地点110）和辅助（例如，灾难恢复站点130）站点的完整性，任何一个事务都不应影响任何数据，而是只能影响需要受影响的数据，例如快照数据149。为了实现这一点，防火墙应该防止任何测试活动被无意地传达到主要站点（例如，生产地点110）。

为了消除在主要（例如生产站点）站点层级和作为灾难恢复站点的消防演习测试（或其他测试，培训或使用）层级之间的这种“串扰”风险，网络隔离320将在主要（例如生产站点）站点和辅助站点（例如，灾难恢复）站点之间被创建。该网络隔离可以通过调用防火墙（例如防火墙160）来实现，并且防火墙160可以由任意现有的网络实用程序或其他适当的软件创建。

在一个实例中，防火墙160可以由辅助（例如，灾难恢复）站点上的守护程序或脚本调用，例如守护进程148（1）、148（2）和148（3）。此外，防火墙160可以由集中式操作管理器（诸如集中式操作管理器190）来调用。如上所述，集中式操作管理器190可以以软件实现，或者被直接植入硬件中，诸如计算设备或计算机芯片以及其他硬件部件可以驻留在主（例如生产站点）站点上、辅助（例如灾难恢复站点）站点或作为物理上不同于这些站点的计算机系统上运行。网络隔离（例如，防火墙160）在主站点层和辅助站点层级之间使用二级主机上（例如，防火演习应用程序的网站将在线）的基于主机的防火墙规则进行创建。

防火墙160可以被配置为防止在测试期间主要（例如，生产站点）站点层和辅助（例如灾难恢复站点）站点层级之间的任何通信，这将导致测试期间影响主要（例如，生产站点）站点，或者防止来自其他（例如，生产站点）站点的任何影响测试的通信。然而，为了确保在消防演习期间不会影响生产多层应用的故障切换能力，防火墙160通常被配置为允许在测试期间（或辅助站点上的其他操作）中的主要站点（例如，生产站点110）和辅助站点（例如，灾难恢复站点130）之间继续进行复制操作---此复制操作不应影响在测试期间要使用的快照数据。以上内容可以通过确保在网络隔离/防火墙（例如，防火墙160）使用过程中保持打开的任何必要的复制端口来实现。因此，即使在测试期间，网络隔离/防火墙（例如，防火墙160）也可以被配置为允许在辅助站点（例如，灾难恢复站点）和主要（例如，生产站点）站点使用的任何复制端口之间传送数据。通常，可以定制网络隔离/防火墙（例如，防火墙160）的配置，以允许所选数据在防火演习（或其他测试或使用）期间通过防火墙（例如，防火墙160）进行传送，同时禁止其他数据通过防火墙传输（例如，防火墙160）。该定制配置可以基于通过防火墙（例如，防火墙160）传送数据的各种标准，例如特定节点、特定端口、数据的始发位置（例如，web层121，应用层122或数据库层123）、数据类型以及创建数据的时间。

此外，还可以配置防火墙（例如，防火墙160），使得网络隔离仅应用于正在运行的辅助站点（例如，灾难恢复站点）的那些节点上（作为给定的灾难恢复层的一部分）的测试（或培训等）应用程序。例如，如果灾难恢复（或沙箱）数据库层143是四节点集群，则网络隔离更改为应用于数据库消防演练服务组上（DB_FD_SG，在下面将更详细地讨论或其克隆）正在运行的主机。尽管在图3中并未示出，但“消防演习服务组”也可以是不同类型的服务组，例如“沙箱服务组”，具体的命名约定对于本文所述的功效或功能并不重要。

尽管使用网络隔离来防止主要（例如生产站点）层次和辅助（例如，灾难恢复站点）站点层次之间的串扰，但辅助（例如灾难恢复站点）站点层必须能够在消防演习期间或其他测试/使用次要（例如，灾难恢复站点）站点之间进行通信。辅助（例如，灾难恢复站点）站点层必须能够在可能出现的其他情况下进行彼此通信，例如在灾难恢复站点的测试期间出现故障切换时，通过将主机更新为虚拟IP /虚拟主机名映射表（“映射表”），使得辅助（例如，灾难恢复站点）站点层在330可以使用主机名来启动该通信。使用此映射表消除了对辅助（例如，灾难恢复站点）站点外部的域名服务器（DNS）的任何依赖性，反过来又减少了影响测试（或其他用途）的相似性，或受到主要（例如生产现场站点）站点正在进行的操作的影响。

作为如何使用映射表的一个示例，考虑生产站点110和灾难恢复站点130所使用的主机名。例如，生产web层121可以具有web.prodsite.synitalent.com的主机名，生产应用层122可以具有app.prodsite.synitalent.com的主机名，并且生产数据库层123可以具有db.prodsite.synitalent.com的主机名。映射表可用于将这些主机名映射到适用于灾难恢复层对应的名称。在此示例中，此映射包括将生产站点子域（在本示例中为“prodsite”）映射到灾难恢复站点的子域（在本示例中为“drsite”）中。因此，使用相同的示例，映射表可以用于指示灾难恢复web层141具有web.prodsite.synitalent.com的主机名，灾难恢复应用层142可以具有app.drsite.synitalent.com的主机名，并灾难恢复数据库层143可以具有db.drsite.synitalent.com的主机名。通过相应地映射主机名，消除了对外部DNS的潜在依赖。反过来，通过防止灾难恢复层和生产之间的任何“意外”通信（例如，旨在用于app.drsite.synitalent.com的通信），有助于保护灾难恢复站点的完整性和测试本身。

为了进一步保护生产现场以及被测试站点的完整性（例如灾难恢复站点），可以使用服务组的克隆来防止对实际应用配置的修改。操作340在辅助（例如，灾难恢复站点）站点130上创建多层应用配置的克隆（例如，相同或基本相同的副本）。在一个实例中，辅助（例如，灾难恢复站点）站点层上的守护程序（例如，守护进程148（1）-（3））将在辅助（例如，灾难恢复站点）站点层上创建服务组的克隆。如图1B所示，这些克隆的服务组可以命名为例如WEB_FD_SG克隆144（1），APP_FD_SG克隆142（1）和DB_FD_SG克隆143（1）。

克隆的服务组提供与辅助（例如，灾难恢复站点，沙箱或其他）站点上的每个层级相同的功能，并且在测试期间不必使用辅助服务组本身。通过这种方式执行测试将防止对实际辅助（例如，灾难恢复）服务组的任何意外修改。为了进一步确保在测试期间不会无意访问或修改实际的辅助（例如灾难恢复）服务组，本文的一个实例可以确保克隆的辅助（例如，灾难恢复）服务组不会运行（或而在实际的次要（例如，灾难恢复）服务组正在运行（或以其他方式运行或正在使用）中）。在测试期间，辅助（例如，灾难恢复）服务组本身不能更改，用以确保测试的有效性和准确性，并确保如果需要故障转移生产时，在灾难恢复站点（例如，灾难恢复站点130）的测试期间服务组可以使用。

一旦已经建立了网络隔离并且创建了克隆的服务组，则克隆服务组会以适当的顺序启动。在一个实例中，该顺序是通过解决灾难恢复多层应用程序130之间的依赖关系来确定的。例如，在该示例中将首先启动DB_FD_SG克隆146（1），因为应用层142和web层146依赖于数据库层143（包括快照数据149），但数据库层143却不依赖于其他任何一个层级。在同一示例中，APP_FD_SG克隆145（1）将在DB_FD_SG克隆146（1）之后启动，因为应用层142依赖于数据库层143。然而，由于WEB层141依赖于应用层142，因此APP_FD_SG克隆145（1）将必须在克隆WEB_FD_SG 144（1）之前启动。确定多层应用程序层之间的依赖关系应确保相应服务组以正确的顺序启动，从而确保数据完整性能够得到维护，并进一步确保系统能够正常工作。

在启动克隆的服务组之后，用户（或自动进程）可以执行辅助（例如，灾难恢复）站点在需要故障转移的情况下进行响应的准备，或者由于任何原因而将辅助（例如灾难恢复）站点另行上线。这种测试将使用克隆服务组和快照数据执行，并且以这种方式执行测试将不会对实际的辅助（例如，灾难恢复）站点或复制数据进行更改。因此，需要确保测试的有效性以及测试方法对主要（例如，生产）和任何辅助（例如，灾难恢复）站点都是无中断的。如果在测试期间需要故障切换，则需要确保辅助（例如，灾难恢复）站点仍然可以使用。

如图2所示，无论是在测试期间还是完成测试之后，可以使用240进行反馈。在一个实例中，结果可以直接报告给用户（例如，站点管理员），如果测试的任何部分失败，可以对灾难恢复站点的配置进行任意必要的更改。在一个实例中，在测试期间检测到的任何错误都可以被提交到自动化过程，如果测试的任何部分失败，可以对灾难恢复站点配置进行任何必要的更改。在其他实例中，可以报告不同类型的结果。例如，如果本发明被用作培训新员工的“沙盒”，则可以报告该员工在“测试”上的表现结果。或者，如果将本发明用作“沙箱”来测试新配置（例如，在将该配置推广到生产站点之前的主要站点的新配置），则可以报告该测试的结果。如这些示例所示，根据情况和本发明的用户的需求和要求，可以以各种各样的格式报告测试结果。

在消防演习（或其他测试或使用）期间，主要站点（例如，生产场所110）发生故障的情况下，用户可以停止辅助站点上的活动（例如，测试，培训等），然后使用灾难恢复多层应用程序130的在线灾难恢复站点130。本发明还允许进行“主动---主动”的灾难恢复准备测试。因此，在消防演习（或其他测试或使用）正在辅助站点（例如，灾难恢复站点130）上执行时，该辅助站点（例如，灾难恢复站点130）可以同时执行其他多层应用程序（不在本文中讨论或描绘），而不需要与主要站点（例如，生产地点110）进行通信。因此，在一个实例中，灾难恢复站点130可以同时用作其他主要站点的灾难恢复站点（不在此讨论或描绘），甚至用作另一多层应用程序的生产站点。在本文讨论的测试过程中，这些生产场所的运行能力以及必要时故障切换到辅助站点（例如，灾难恢复站点130）的能力将不会受到影响。

图4为方法400的流程图，其公开了停止和取消配置元件240中消防演习（或其他测试或其他用途）的动作。方法400通过在410中按照适当的顺序停止克隆的服务组来开始。作为一般消费者，服务组应该按照其开始的顺序停止。因此，参考上面给出的示例，WEB_FD_SG克隆144（1）将首先停止，然后是APP_FD_SG 145（1），最后DB_FD_SG克隆146（1）。如按照正确顺序启动和停止克隆的服务组有助于确保数据完整性，还有助于某些层被被错误停止（直接或间接）。

一旦克隆的服务组在410中被停止，方法400就可以撤销网络隔离420。重要的是，直到所有克隆的服务组在410中被停止为止，才能够撤消网络隔离。以此顺序执行这些步骤有助于防止克隆服务组的节点有机会在无意间与生产位置的任何服务组与复制站点的原始服务组进行通信。因为无意间的通信可能会导致生产和灾难恢复站点的许多问题，包括数据损坏，甚至可能导致生产和灾难恢复站点崩溃。

然后，方法400进行到步骤430，其中克隆的服务组将被去除。最后，方法400以步骤440得出结论，其中复制数据的快照可以被清除。然而，在某些实例中，复制数据的快照也可以被保留（例如，用于将来的测试），而不会对本文所述的整个过程和系统产生负面影响。步骤430和440有助于确保主要站点和辅助站点都处于其预测试状态（或者如果复制的数据保持在当前期望的状态），并准备继续其正常的功能（或未来的测试）。

如上所示，本文描述的系统可以使用各种计算机系统和网络来实现。以下参考图5和图6来描述这样的计算和网络环境。

图5描绘了适于实现本文描述的计算机系统510的框图。计算机系统510包括总线512，其将计算机系统510的主要子系统进行互连。诸如中央处理器514，系统内存517（通常为RAM，但也可以包括ROM，闪存RAM等）的，I / O 控制器518，经由音频输出接口522的扬声器系统520，经由显示适配器526的显示适配器524，串行端口528和530，键盘532（与键盘控制器533连接），存储接口534，用以操作软盘538的软盘驱动537，用于连接光纤网络590的主机总线适配接口卡535A，用于连接SCSI总线539的主机总线适配接口卡535B，用于操作光盘542 的光盘驱动器540，还包括了鼠标546（或其他点对点设备，经由串行端口528耦合到总线512上），调制解调器547（通过串行口530连接到总线512上），以及网络接口548（直接连接到总线512上）。

总线512允许中央处理器514和系统存储器517之间的数据通信，其可以包括只读存储器（ROM）或闪速存储器（未示出）以及随机存取存储器（RAM）（未示出），如前所述。RAM通常是加载操作系统和应用程序的主内存，ROM或闪存包含控制基本硬件操作的BIOS，例如与外围组件的交互。集中操作管理器190可以被嵌入、编码或以其他方式存储在系统存储器517中。驻留在计算机系统510上的应用程序通常存储在计算机可读存储介质上，并且可访问诸如硬盘驱动器（固定盘544），光驱（光驱540），软盘单元537或其他计算机可读存储介质。与计算机系统510的其他存储接口一样，存储接口534可以连接到用于存储和检索诸如固定盘驱动器544的信息的标准计算机可读介质。固定磁盘驱动器544可以是计算机系统510的一部分，或者是通过其他接口系统分离和访问。调制解调器547可以经由电话链路或因特网服务提供商（ISP）直接连接到远程服务器。网络接口548可以经由POP到因特网的直接网络链路向远程服务器提供直接连接。网络接口548可以使用包括数字蜂窝电话、蜂窝数字分组数据（CDPD）以及数字卫星数据等的无线技术来提供这种连接。

许多其他设备或子系统（未示出）可以以类似的方式连接（例如，文档扫描器，数码相机等）。相反地，图5中所示的所有设备都不需要存在于本文描述的系统中进行实施。设备和子系统也可以以不同于图5所示的方式互连。诸如图5所示计算机系统的操作在本领域中是众所周知的，但在本文中没有详细讨论。用于实现本文描述的系统模块的代码可以存储在诸如系统存储器517，固定盘544，光盘542或软盘538之类的可再利用的存储介质中。计算机系统510上提供的操作系统可以是MS-DOS、MS-WIN-DOWS、UNIX、Linux、AIX或其他作系统。

此外，关于本文描述的信号，本领域技术人员将认识到，可以将信号从第一区域直接发送到第二区域。同时，信号可以在区域之间被修改（例如，被放大，衰减，延迟，锁存，缓冲，倒置，过滤或以其他方式修改）。尽管上述实例的信号被表征为从一个区域传输到下一个区域，但是除了在区域之间传输信号的信息和功能方面之外，其他实例可以包括替代这种直接发送的信号的修改信号。在某种程度上，由于所涉及电路的物理限制，第二区域的信号输入可以被概念化为从第一区域输出的第一信号导出的第二信号（例如，将不可避免地会有一些衰减和延迟）。因此，如本文所使用的，从第一信号导出的第二信号包括第一信号或对第一信号的任何修改：无论是由于电路限制还是由于通过不改变信息或最终功能的其他电路元件的第一个信号。

图6是描绘网络架构600的框图，其中客户端系统610、620和630以及存储服务器640A和640B（其中任何一个都可以使用计算机系统610,620和630来实现）被连接到网络650，并且与互联网180和网络150具有相同作用。存储服务器640A为直接连接的存储设备660A（1） - （N），存储服务器640B为直接连接的存储设备660B（1） - （N）。此外，存储设备640A包含集中式操作管理器190。虽然在图6中没有明确描述，但是应当理解，集中式操作管理器190包括在诸如存储服务器640B的任何存储服务器上，并且还可以被拆分在诸如存储服务器640A和640B之类的一个或多个服务器之间。尽管与存储区域网络的连接不需要操作，但存储服务器640A和640B也连接到SAN结构670。SAN结构670支持由存储服务器640A和640B访问存储设备680（1） - （N），并且由客户端系统610、620和630经由网络650访问。智能存储阵列690还给出了可通过SAN结构670的特定存储设备。

参考计算机系统510，可以使用调制解调器547，网络接口548或一些其它方法、装置或设备来提供从客户端计算机系统610、620和630中的某一个到网络650的连接。客户端系统610、620和630能够使用例如web浏览器或其他客户端软件（未示出）来访问存储服务器640A或640B上的信息。这样的客户端允许客户端系统610、620和630访问存储服务器640A、640B或存储设备660A（1） - （N），660B（1） - （N），680（1） - （ N）或智能存储阵列690。图6描绘了诸如因特网之类的用于交换数据的网络，但是本文描述的系统不限于互联网或任何特定的基于网络的环境。

本文描述的系统很好地适应于本文所提及的优点。虽然已经对此进行了描述，并且通过参考特定描述定义了这样的系统，但是这样的引用并不意味着对声明的限制，并且不会推断出这种限制。本文描述的系统能够在形式和功能方面进行相当大的修改和改变，如在本公开内容中相关领域的技术人员将会想到的那样，所描述的实例仅是示例，并不是穷举声明的范围。

前面描述了包括在其他组件（例如，被显示为计算机系统510的组件的各种元件）内的组件实例。这样的架构仅仅是示例，实际上许多其他架构也可以实现相同功能。在抽象但仍然确定的意义上，组件的任意配置都可以实现相同的功能。实现相同功能的组件的任意布置被有效地“关联”，使得能够实现期望的功能。因此，这里以实现特定功能的任何两个组件可被视为彼此“相关联”，从而使得期望的功能被激活，而忽略架构或中间组件。同样地，如此相关联的任何两个部件也可以被看作是彼此“可操作地连接”或“可操作地耦合”，以获得所需的功能。

以上所述实施例仅表达了本发明的具体实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。

Claims (8)

1.一种无中断灾难恢复测试的自动网络隔离方法，该方法应用于跨物理和虚拟主机之间的多层应用程序，其特征在于，所述方法包括：

将数据从生产站点复制到辅助站点，所述辅助站点配置有次级多层应用程序，并且次级多层应用程序是在生产站点上执行的主要多层应用程序的副本；

配置防火墙，用以在主要多层应用程序和次级多层应用程序之间提供网络隔离，允许网络隔离正在进行时在生产站点和辅助站点之间进行复制；

测试应用程序的多个节点，测试包括复制正在进行的次级多层应用程序。

2.根据权利要求1所述一种无中断灾难恢复测试的自动网络隔离方法，其特征在于，配置防火墙还包括配置允许所述辅助站点在测试期间执行一个或多个操作时，执行不属于所述测试的一个或多个操作。

3.根据权利要求1所述一种无中断灾难恢复测试的自动网络隔离方法，其特征在于，获取生产站点的一个或多个守护进程的参数，并将获取的参数用于配置防火墙。

4.根据权利要求1所述一种无中断灾难恢复测试的自动网络隔离方法，其特征在于，在配置防火墙之前，还包括提供一个或多个参数到辅助站点的一个或多个守护进程上。

5.根据权利要求1所述一种无中断灾难恢复测试的自动网络隔离方法，其特征在于，更新主机映射表，并将主机映射表存储在辅助站点上，并在测试时调取主机映射表。

6.根据权利要求1所述一种无中断灾难恢复测试的自动网络隔离方法，其特征在于，在测试过程中，创建一个或多个服务组的克隆体，每个所述克隆体对应一个主站点或辅助站点上的一个服务组。

7.根据权利要求1所述一种无中断灾难恢复测试的自动网络隔离方法，其特征在于，当检测到与生产现场相关的故障时，则执行停止操作，并根据检测到的故障激活辅助站点。

8.一种计算机系统，该计算机系统用于权利要求1-权利要求7所述方法，其特征在于，包括一个处理器和一个耦合到处理器的内存；

所述内存用于存储处理器执行的指令，所述指令用于将数据从生产站点复制到辅助站点；所述辅助站点包括次级多层应用程序，且所述次级多层应用程序为主要多层应用程序在生产站点上执行时的副本；

所述辅助站点同时配置一个用于对主要多层应用程序和次级多层应用程序起到网络隔离作用的防火墙，所述防火墙允许复制操作发生在网络隔离生效的主要多层应用程序和次要应用程序之间。