IBM容灾解决方案Global Mirror 在DS8000/DS6000/ESS上的实现

copyking

   2004年中，IBM 推出了基于企业存储服务器ESS的全球镜像（Global Mirror, GM,也称为Async PPRC）容灾解决方案，该模式采用异步方式工作，同时利用同步的数据一致性优势和异步的性能/距离优势，并且采用一系列机制保证数据一致性，彻底解决了数据保护/距离/性能之间的矛盾。2004年底推出的DS8000/DS6000系列也支持Global Mirror, 同时，它们还可以同ESS一同交互操作，进行容灾。
   该方案是一个三个卷的解决方案，即PPRC-XD A->B , FlashCopy B->C,即可保证卓越的异步容灾能力。同时我们也建议客户使用一个D卷，对于平时进行容灾测试、复制质量测试、备份、数据挖掘、应用测试等，它带来极大的方便和易用性，以及对生产卷最小的干扰性。


下面简单解释一下起工作方式（其中绿色 [第一组] 为生产站点磁盘，橙色［第二组］ 和蓝色 [第三组] 为容灾站点磁盘）：


1. 绿色和橙色磁盘之间进行PPRC-XD异步操作
2. 绿色磁盘组根据预先设置的时间，生成“一致性组”（Consistency Group），并记录状态
3. 采用PPRC-XD异步操作方式，将且只将“一致性组”记录下来的数据传递从绿色磁盘组传递到橙色磁盘组
4. 3完成后，立刻将橙色磁盘组数据FlashCopy到蓝色磁盘组，进行一致性数据保留
5. 4完成后，回到步骤1
由于有“一致性组”的保护，虽然采用异步方式，一旦每一个“一致性组”数据包传递成功的那一时刻，橙色磁盘组的数据是一致的；由于步骤4，蓝色磁盘组将能够保留最近一次“完全一致性”的数据。一旦出现灾难，客户丢失的是两次生成“一致性组”间隔之间的数据。
ESS/DS8000/DS6000能够每3～5秒生成一次“一致性组”，意味着客户即使采用异步方式，也有可能只丢失3～5秒的数据。一般的异步方式，客户会丢失几个小时以上的数据，并且操作十分繁琐。
2 Global Mirror规划
Global Mirror需要十分仔细地规划，详细内容请参考DS8000 Series Copy Services in Open Environments sg246788. 本文示例的环境及其拓扑图如下,我们用ESS和DS8000分别作为Global Mirror的源和目标，充分展示了Global Mirror的灵活性：


在本文中我们将使用DScli 方式来管理　copy service,我们在图中的Primary Server 和Secondary Server 上都安装了与存储微码相对应的DScli:
2.1 最低要求（微码及其他）：
ESS800: 2.4.3.65
DS8000: 6.0.500.52(code bundle)
ESS/DS8000上都要有PPRC license以及fiber channel卡。不可以用ESCON卡。
2.2 在ESS和DS8000上建立相符的ID/PASSWORD
我们在ESS和DS8000建立一个具有admin组权限的ID/PASSWORD： admin/passw0rd
方法：
ESS800: GUI: ESS Specialist->User tab-> Modify Users
DS8000: DScli: mkuser -pw passw0rd -group admin admin

Document #: 8893627F08013
Body:
2.3 网络连接：
安装了DScli的server必须跟ESS的copy service server 及DS8000的hmc有网络连接。
生产中心和容灾中心之间的数据连接可以使用多种选择。如下的链路在以前的项目通过了测试，可供我们参考：
FC-ATM连接方式：
ESS-->CISCO9509-->CNT UltraEdge-->ATM(40Mb/s SVC 1000KM)
-->CNT UltraEdge-->CISCO9509-->ESS
FCIP连接方式：
ESS-->CISCO9509-->FC/IP Module-->IP Router-->ATM(40Mb/s SVC 1000KM)
-->IP Router-->FC/IP Module -->CISCO9509-->ESS
i FCP连接方式：
ESS-->SAN Router Eclipse 1620-->IP network-->SAN Router Eclipse 1620-->ESS
2.4 PPRC卷大小的考虑问题：
由于在ESS和DS8000中缺省状态下对GB的解释不同:
ESS方式：1GB=109 B=1,000,000,000B
DS缺省方式：1GB= 230 B=1,024*1024*1024B
所以我们要特别小心定义卷：
1．在ESS 上察看 ESS卷大小:
ESS Specialist->Storage Allocation->Open System Storage->Modify VolumesAssignments
2．以该卷大小为准定义在DS8000上卷的大小，使用特殊参数-type ess
dscli> mkfbvol -extpool p4 -cap 40 -type ess 0600-0605
Date/Time: 2006年10月24日 下午02时54分49秒 IBM DSCLI Version: 5.1.600.278 DS: IBM.2107-7547491
CMUC00025I mkfbvol: FB volume 0600 successfully created.
CMUC00025I mkfbvol: FB volume 0601 successfully created.
CMUC00025I mkfbvol: FB volume 0602 successfully created.
CMUC00025I mkfbvol: FB volume 0603 successfully created.
CMUC00025I mkfbvol: FB volume 0604 successfully created.
CMUC00025I mkfbvol: FB volume 0605 successfully created.


可以看到新定义的卷是在 cap (10^9B) 列中存在的。通过这种方式我们可以保证参加Global Mirror的卷大小是完全一致的。
以下是我们在生产中心ESS800和容灾中心DS8000的上LSS和A/B/C/D卷的定义，容量均为40G：
盘 LSS 卷标
A 16/17 1600 1700
B 06/07 0600 0700
C 06/07 0601 0701
D 06/07 0602 0702


3 配置ESS Copy Service Server
启动ESS Specialist：


点击Tools：



Document #: 8893627F08015
Body:
4.1 建立Global Mirror环境
要建立Global Mirror环境,要做一下几步:
1. 确定PPRC link可用的光纤端口：
下图展示了DS8000光纤卡端口对应ioport的定义，我们使用了I0030 和I0130作为 PPRC path:


下图展示了ESS800光纤卡端口对应ioport的定义，我们使用了I0024 和I00A4作为 PPRC path:


2. 建立从LSSA到LSSB的PPRC PATH
3. 建立从卷A到卷B 的Global Copy 对
-建议等到从卷A到卷B的初始拷贝完成再进行下一步。
4. 建立从卷B到卷C 的FlashCopy 关系
5. 在每个LSS 上建立 Global Mirror session （要使用相同的session ID，这里我们设为1）
6. 在每个LSS 上把所有的卷A 加到 session 中
7. 启动 Global Mirror
4.2 清除Global Mirror环境
1. 终止 Global Mirror session
2. 从 Global Mirror session中删除所有原卷（A）
3. 关闭 Global Mirror session.
4. 在容灾中心DS8000上去掉 B 和 C 卷的FlashCopy关系
5. 在生产中心ESS800上去掉 A 和 B 卷的Global Copy 关系
6. 去掉 PPRC paths.
4.3 生产中心故障或维护,切换到容灾中心
（注意，灾难发生后，我们将用B 卷，如果测试用的D 卷 也是在同一台host上，请先将其umount 文件系统，varyoffvg等等，这样将会避免由于B和D都是来源于A，其pvid相同带来的问题）
1. 终止 Global Mirror session
2. 在容灾中心DS8000上去掉 B 到D 卷的FlashCopy关系（如果我们曾在演习中使用过B 到D 卷的 FlashCopy关系的话）
3. Fail over B -> A. (让B可以被host访问)
4. 检查B 卷的状态是否为revertible(验证 Consistency Group 是否有效)
通常情况下是不会出现Revertible的，所以不用采取额外的步骤，但是如果有的话，请并参照下表采取相应的步骤：


5. 在 B 卷上恢复一致性数据 (B 到 C的反向快速 FlashCopy-FRR ). 并等待它结束
6. 重新建立从卷B到卷C 的FlashCopy 关系（在上一步中会自动去掉卷B到卷C的关系）
7. 在容灾中心的卷B上开始恢复生产。
4.4 生产中心恢复,从容灾中心切换回来
现在将备份站点的数据复制回主站点。注意，如果是容灾演习，请停止主站点的host对A 卷的访问（如umount 文件系统，varyoffvg等等）。
1. 建立从LSSB到LSSA的PPRC PATH
2. Failback Global copy B->A（开始从B到A复制数据）
3. 查询状态：B->A 的增量数据（Global Copy first pass）是否拷贝完成
4. 停止容灾中心的卷B上的应用
5. 查询状态：B->A 的增量数据（Global Copy Out Of Sync Tracks）是否拷贝完成
6. 建立从LSSA到LSSB的PPRC PATH，如果它们不存在的话
7. Fail over A-> B. (让A可以被host访问)
8. Failback Global copy A->B（开始从A到B复制数据）
9. 启动 Global Mirror.
10.在生产中心启动应用
4.5 容灾演习并在容灾中心获得测试用的D卷
Global Mirror的机制允许你快速在如何在备份站点获得计划内的复本（D 卷），它是生产卷（A 卷）的一个快照，可以用来进行容灾测试、复制质量测试、备份、数据挖掘、应用测试等等。在我们的实践中充分体会到它的重要性和易用性，以及对生产卷最小的干扰性。在我们的测试环境中可以在1分多钟的时间内获得一组D 卷组，并恢复Global Mirror 的进程。
我们可以通过执行以下的任务达到此目的：
1. 查询Global Mirror环境并检查环境是否健康
2. 暂停 Global Mirror并等待暂停执行完毕
3. 暂停 Global Copy A -> B.
4. Fail over B -> A. (让B可以被host访问)
5. 在容灾中心去掉 B 到D 卷的FlashCopy关系（如果我们曾在演习中使用过B 到D 卷的FlashCopy关系的话）
6. 在 B 卷上恢复一致性数据 (B 到 C的反向快速 FlashCopy-FRR ).
7. 等待FRR结束
8. 重新建立从卷B到卷C 的FlashCopy 关系（在上一步中会自动去掉卷B到卷C的关系）
9. 重新建立从卷B到卷D 的FlashCopy 关系
10. Failback Global copy A->B（开始从A到B复制数据）
11.恢复 Global Mirror.
12. 在容灾中心的D卷上测试刚才获取的生产数据。
5 实现Global Mirror 的脚本
由于在上节说述各个场景中需要执行多个命令来达到所需要的结果，实现起来比较复杂，作者编写了脚本来实现这些任务，将实现Global Mirror的复杂程度大大降低。
脚本以Windows2003为例，在安装了DScli 后，只要把所附的脚本拷贝到DScli安装目录下的profile目录，并按Global Mirror规划要求修改相应的ESSsource.profile， DS8Ksource.profile， GMconfig.cmd定义文件后， 执行“GM_main_menu.CMD GMconfig.cmd”，GM_main_menu.CMD主程序将会根据选项调用所有其他程序完成Global Mirror环境的建立、清除、生产中心故障或维护,切换到容灾中心、生产中心恢复,从容灾中心回切、容灾演习并在容灾中心获得测试用的D卷等任务。
受篇幅所限，我们将相关脚本放置于IBM技术支持中心的网站上，请在以下网站上
http://www-900.ibm.com/cn/support/viewdoc/knowledgebase
搜索“Global Mirror”,可以找到本文相关的脚本。

ESS Global Mirror（异步级联PPRC）简介
早期的IBM企业存储服务器ESS已经可以支持两种不同的远程拷贝功能来保证应用系统不间断的运行, 分别是PPRC和XRC。随着IBMY正式公布ESS-800 PPRC V2的新功能，现在对于异步PPRC,包括对级联PPRC的支持，统称的Global Mirror（异步PPRC）。Global Mirror的一项新功能就是异步级联PPRC功能，这一功能允许您将同步PPRC和PPRC-XD组合在一起，将多台企业存储服务器ESS级联，从而提供了另一种灾难恢复方法。下面，我们首先将对PPRC的相关背景加以介绍，然后，着重分析ESS800的相关拷贝复制功能的原理。
背景介绍
早期的IBM企业存储服务器ESS已经可以支持两种不同的远程拷贝功能来保证应用系统不间断的运行, 分别是PPRC和XRC。2003年，IBMY又正式公布了ESS-800 PPRC V2的新功能。现在对于异步PPRC,包括对级联PPRC的支持，统称的Global Mirror（异步PPRC）。下面，我们就分别加以介绍。
PPRC: Peer-to-Peer Remote Copy
PPRC本身是同步远程镜像的解决方案，可以保护数据和提供灾难恢复功能。IBM企业存储服务器ESS PPRC是继承了S/390磁盘系统的的功能，而且，它还提供了对UNIX和Windows NT的支持。PPRC作为数据存储的容灾方案，可实施远程的数据高速同步镜像，把数据损失的可能性降低到最低。
应用IBM企业存储服务器ESS的PPRC功能，S/390和开放系统(UNIX)现在可实现远程灾难恢复方案来保护可能被破坏的数据。PPRC可将选定的数据进行拷贝的距离远至103公里。PPRC的管理是通过Web浏览器界面实现的，IBM的StorWatch企业存储专家为开放系统而设，ICKDSF为S/390而设。应用PPRC无需特别的软件。使用ESCON光纤线缆连接IBM企业存储服务器ESS系统。在写操作完成报告操作系统之前，本地与远程拷贝写操作都完成了。
PPRC是一种同步协议，它允许数据从一个逻辑单元(Logical Unit)到另一个逻辑单元进行实时的镜像。PPRC是与应用无关的。由于该复制功能是在磁盘系统级发生的，应用根本不知道PPRC的存在。
PPRC协议的步骤为：
主机服务器(S/390、Unix或者Windows NT服务器)对主IBM企业存储服务器ESS(本地的IBM企业存储服务器ESS)发出一个写的I/O请求。该写操作将写入IBM企业存储服务器ESS的NVS缓存(Cache)中。
PPRC将该请求发往(dispatch)另一个IBM企业存储服务器ESS(备份中心的IBM企业存储服务器ESS)，主IBM企业存储服务器ESS等待远端的写完成信号。
数据写入备份中心的IBM企业存储服务器ESS的NVS缓存中。
写完成的信号发到主IBM企业存储服务器ESS。
主IBM企业存储服务器ESS通知主机服务器写操作完成。
一旦主IBM企业存储服务器ESS接收到备份IBM企业存储服务器ESS写完成信号，主IBM企业存储服务器ESS与备份IBM企业存储服务器ESS将有选择地将写操作写(destage)到物理磁盘。由于IBM企业存储服务器ESS具有高可靠性的数据保护功能，因此从NVS缓存写物理磁盘的过程是主IBM企业存储服务器ESS和备份IBM企业存储服务器ESS非同步的，这样保证了两个IBM企业存储服务器ESS的工作性能。
一旦在一段时间内没有收到远端写信号，写操作被认为失效。此时，应用会收到一个I/O错误。
IBM企业存储服务器ESS在使用PPRC时，其中的卷会有以下四种状态：
Simplex：该状态是卷在使用PPRC之前的初始状态；
Simplex pending：当建立了PPRC之后，会有一段时间目标卷与源卷不同步。此时，数据需要从源卷中复制到目标卷或者PPRC对。这通常会出现在PPRC刚刚建立，或者在存储系统失效后PPRC重新建立卷对。
Duplex：这是两个卷对完全同步。此时，源卷与目标卷存储着同样的数据。
Suspended：当源系统与目标系统无法通讯，因而PPRC对无法保持同步时，卷处于此状态。此时，主IBM企业存储服务器ESS卷会保持记录所有对源卷的更新，一旦PPRC重新建立连接，更新也同样进行。
XRC
XRC是异步远程镜像的解决方案。因为它需要S/390的IBM System Data Mover(SDM)模块，所以它只能工作在S/390环境中。XRC的强大功能表现在它只会将主数据中心的改变的数据拷贝到远程镜像IBM企业存储服务器ESS中，这样可以加快备份时间，提高备份效率。
IBM已经为S/390的许多客户安装了远程备份系统。尽管有些厂商在UNIX系统上宣布可以实现远程备份功能，但却不可避免地存在着数据完整性的问题。这也许是为什么越来越多的厂商购买IBM远程备份的标准和技术的原因了。


2003年5月8日，IBM正式公布了ESS-800 PPRC V2的新功能。
PPRC V2增加了异步级联功能（Asynchronous Cascading PPRC）。即同步PPRC的目标卷可以作为另一个PPRC对的源卷。此功能提供了长距离更好的灾备解决方案。同步PPRC保证了数据的一致性，而PPRC-XD保证了数据的远程备份。此功能适用于任何可连接的操作系统，zSeries, Linux, Unix and Windows 环境等。如下图，我们可以选择两地或三地的解决方案。同时，PPRC V2保留了PPRC V1 现有的功能。



Global Mirror（异步级联PPRC）的运行和卷的状态
当使用Global Mirror（异步级联PPRC）时，允许一个卷同时作为PPRC主卷和PPRC辅助卷，因而能够将3个卷组合为2个PPRC对。


在这一配置中，我们拥有2个PPRC卷对：A–B和B–C。卷B同时扮演两个角色：它在PPRC关系A–B中是辅助卷，但在PPRC关系B–C中中是主卷。与任何PPRC关系一样，卷A和卷B以及卷B和卷C必须位于不同的LSS(在同一或不同ESS)上。在一个Global Mirror（异步级联PPRC）关系中，必须存在至少2个不同的ESS，或最多3个不同的ESS。下图显示了一个ESS的卷控制面板，其中的LSS 16为本地LSS，LSS 17为中间LSS。卷700-18767拥有2个状态图标：红色图标代表作为本地PPRC关系中的辅助卷，蓝色图标代表作为远程PPRC-XD关系中的主卷。


在实际中，这3个卷经常在放在不同的地点——分别被称为本地 （local）、中间（intermediate） 和远程（remote）站点。 相应地，我们将A–B称为本地对 （local pair） ，将对B–C称为远程对 （remote pair ）。当考虑到整个数据传输链时，可以将卷A看作主卷，将卷B看作辅助卷，将卷C看作第三级（tertiary ）卷。
这两个PPRC对的状态的维护是相互独立的。您可以挂起A–B对，而不会影响到B–C对的状态，反过来也是如此。需要指出的是，卷B拥有2个PPRC状态——具体取决于您当时考虑的是哪一个关系。下图显示了以上示例中中间卷的卷信息面板，显示该卷既是PPRC主卷，也是PPRC辅助卷。


注意 ：没有额外的卷涉及到中间的LSS。在总拥有成本方面，与基于中间站点上一个附加FlashCopy卷的解决方案相比，这种方式可以节省磁盘空间和许可费用。
Global Mirror（异步级联PPRC）任务和选项
为维持Global Mirror（异步级联PPRC）关系，您需要执行相同类型的ESS拷贝服务任务，独立地创建、挂起和终止这两个PPRC对中的每一个。可用选项取决于您在指定卷对上使用的运行模式。唯一的区别在于您在创建B–C对时必须选择Global Mirror（异步级联PPRC）（Cascading PPRC） 这一选项：
· Cascading PPRC 选项允许该关系中的PPRC主卷同时作为另一个PPRC关系中的辅助卷。
级联对的创建可使用任何次序。我们建议使用以下步骤：
1. 使用Do not copy volume（不拷贝卷） 选项建立远程对。
2. 使用Copy entire volume（拷贝整个卷） 选项创建本地对。
这样可以避免不必要地将无效数据从辅助卷传输到第三级卷。如果您首先使用Copy entire volume（拷贝整个卷） 选项建立了本地对，那么您必须也为远程对选择Copy entire volume（拷贝整个卷） 选项。此外，还可以为现有的对添加级联关系。
Global Mirror（异步级联PPRC）模式组合
下表显示了在一个级联关系中可支持的PPRC模式的各种组合。
Global Mirror（异步级联PPRC）模式组合
本地卷对
远程卷对
同步PPRC
PPRC-XD


同步PPRC
PPRC-XD
PPRC-XD
PPRC-XD不能支持到同步PPRC的组合，因为如果本地卷对采用PPRC-XD，那末中间卷是一个失真的拷贝，不能作为第三级卷一致拷贝的源卷，
同步PPRC到PPRC-XD的组合是典型的组合，主要用于灾难恢复。PPRC-XD到PPRC-XD的组合允许您维护数据的多个拷贝，而不会对应用I/O性能产生明显的影响。与此形成对比的是，两个同步PPRC关系的组合将会对应用I/O产生严重的影响，因为每一次写操作都必须等待两次PPRC数据传输的完成。如果写I/O很少而且整个数据传输距离对于同步PPRC来说过长的话，那么这一组合可用于确保在远程站点能够提供一份一致的数据拷贝。
虽然我们所使用的本地、中间和远程ESS的术语给人的感觉是Global Mirror（异步级联PPRC）需要3个ESS，但还有其他可能的变种。唯一的一个要求是，构成基本关系A–B或B–C的两个卷必须位于不同的逻辑子系统（LSS）上。这些LSS可以在同一ESS上，也可以在不同的ESS上。因此，存在着以下的Global Mirror（异步级联PPRC）变种：三个LSS在同一ESS上、在两个ESS上以及在一个ESS上。从实用的角度看，只有两种变种是有价值的：
· 3个ESS，每一ESS上有1个卷。

当本地对运行在同步模式下时，您应该使本地和中间ESS之间的距离尽可能地短，以最大程度地减少对性能的影响。中间ESS应位于一个与本地ESS相分离的安全环境中，而且使用独立的电源，以减少断电同时影响到两个地点的可能性。远程ESS通常放在一个不同的城市，与中间ESS之间的距离不受限制。如果远程PPRC对与本地PPRC对之间的运行是异步的，那么将能够最大程度地减少长距离对主机响应时间的影响。
· 2个ESS，卷A和卷B位于同一本地ESS上，卷C位于远程ESS上。

如果远程对运行在PPRC-XD模式下，那么这一配置与单一PPRC-XD关系非常类似。由于拥有一个中间卷，所以可以创建一个一致的远程时间点拷贝，同时减少对应用的影响。




使用PPRC-XD创建一个一致拷贝来作为远程对
同步PPRC和PPRC-XD的组合再次带来如何在远程站点创建一个一致拷贝的问题。PPRC-XD关系中的辅助卷并不是一个一致的数据拷贝，而且通常不能用于灾难恢复——除非同一时间点的所有数据都被拷贝。必须定期使PPRC-XD辅助卷（与主卷）保持一致，而且保留数据的一份附加拷贝。
在以下假设条件成立的前提下，我们来描述如何在远程创建卷A的一个一致备份拷贝：
· 卷A和卷B上的数据是一样的（卷处于full-duplex状态）。
· 卷A和卷B在PPRC同步模式下建立。
· 卷B和卷C在PPRC-XD模式下建立。
在这些假设条件下，通过以下步骤可在远程地点创建一个一致的时间点拷贝：
1. 在本地ESS：
向A–B卷对发出一个Freeze 操作指令。这样可以确保不再对卷B进行更新，并允许完成对卷C的更新。卷A和卷B（同步PPRC对）现在被挂起，处于一致的状态。
2. 在中间ESS（双ESS配置中：本地ESS）：
a. 将卷B和卷C转换到同步模式，允许将更新的数据送到远程站点。
b. 监视卷B和卷C的拷贝过程是否进入到全双工状态。当卷B和卷C处于全双工状态时，您可以在远程ESS创建一份与冻结时间点一致的拷贝。
3. 在远程ESS：
在卷A和卷B处于挂起状态而且卷B和卷C之间的同步过程完成之后，使用FlashCopy创建一个PIT（时间点）一致拷贝（使用卷C和卷D）。
4. 在中间ESS（双站点配置中的本地ESS）：
a. 挂起卷B和卷C。
b. 在卷B和卷C处于挂起状态时，重建卷B和卷C为PPRC-XD对。选择Copy out-of-sync cylinders only 选项。
5. 在本地ESS：
a. 在冻结之后恢复操作。当您向卷A发出冻结指令时，两个LSS之间已经建立的路径将被禁用。您必须重建这些路径。
b. 对挂起的A-B卷对执行再同步，这样会将所有被改变的数据从卷A拷贝到卷B。选择Copy out-of-sync cylinders only 选项。


仔细检查这些步骤，您会注意到以下细节：
· 为建立同步PPRC关系，需要以标准方式实现同步PPRC一致群组（以上步骤中的第一步）。
· 一旦执行了PPRC冻结操作，中间站点卷将处于静态和一致状态，因此只要带宽允许，远程站点也将到达这一静态和一致点。因此，上面的步骤2实际上并非是一个动作，它只是一个等待和监视的过程。
· 通过in-band的方式在远程ESS发出FlashCopy指令（第3步）。
Global Mirror（异步级联PPRC）的停机假定情况
Global Mirror（异步级联PPRC）的停机假定取决于是双ESS配置还是三ESS配置：
· 本地和中间卷都在同一ESS上的Global Mirror（异步级联PPRC），在发生停机时的情况与单一PPRC配置发生停机的情况相同。在失去对本地ESS的访问之后，如果远程对处于一个PPRC-XD关系之中，远程ESS可以提供一份存在失真的拷贝。
在远程ESS上，必须使用最新的一致时间点拷贝进行恢复。

因此，当我们比较运行Global Mirror（异步级联PPRC）的双ESS配置和单一PPRC时，并在远程站点创建一个一致时间点拷贝时，Global Mirror（异步级联PPRC）对应用的影响较小（与单一PPRC-XD相比）。
· 使用3个ESS的Global Mirror（异步级联PPRC）可提供更多的选择：
n 如果本地ESS发生停机，中间ESS可提供一个一致和最新的数据拷贝。您可以通过执行故障切换，将工作运行切换到中间ESS，避免交易处理过程的中断。



不久以后（具体所需时间取决于带宽），中间ESS向远程ESS发送所有更新的过程将完成。通过这种方式，远程站点将自动实现更新。
n 如果中间ESS发生停机，本地ESS上的数据将不会受到影响。

应用继续正常运行。
在中间ESS得到修复之前，将只有一份可用的数据拷贝。
n 如果远程ESS发生停机，本地和中间ESS上的数据将不会受到影响。应用继续正常运行。中间ESS可维护一个一致的最新拷贝。
您可能会提出这样一个问题，如果三ESSGlobal Mirror（异步级联PPRC）配置中的本地和中间ESS都发生了停机，那么将会出现什么情况呢？答案是您可以用远程ESS上存放的最新时间点拷贝进行恢复。换句话说，这种情况将与双ESS PPRC配置中主ESS停机的情况相同。如果停机属于灾难性的，足以导致主ESS和中间ESS的停机，那么很可能将会出现能够影响整个地区和业务的各种故障。在这种情况下，即使恢复数据所需的时间较长，也不会成为业务连续性的限制因素。
PPRC数据一致性
在拷贝操作中需要特别关注数据一致性需求。我们将在这里讨论一致性的类型，并介绍用于控制一致性的更多ESS功能。
一致性类型
我们需要根据运行环境和范围对一致性的不同类型进行区分。在PPRC运行环境中，需要考虑三种类型的一致性保证：
No guarantee（无保证） 是最弱的类型。我们能够得到的保证只是，如果主卷有足够长的时间没有被更新，那么辅助卷将最终与主卷一致。
Power-failure consistency（电源故障一致性） 可以确保辅助卷与主站点发生电源故障并实现恢复后的状态一致。
Application consistency（应用一致性） 可以确保辅助卷与主站点上的应用有机会正常关机后的状态一致。
PPRC-XD属第一种类型：我们只知道所有的更新都将被传输（到辅助卷上），但我们不会去设想相关写操作的次序或完成更新所需的时间。
在电源故障一致性的描述中，您可以包括其他类型的硬件故障，如失去光纤连接。同步PPRC的情况就是如此。一致性可以确保独立写操作的次序：如果主站点上的写操作W1 在写操作W2 发起之前就已经完成，那么辅助站点在完成来自W1 的修改之前，永远不会执行来自W2 的修改。
在典型情况下，当使用了具有这种一致性类型的辅助卷时，需要进行软件恢复。通过使用日志文件，数据库能够以启动例程一部分的形式自动完成这一处理。因为这样的日志文件记录了成功完成的交易处理和已经被提交的交易处理（任何部分被提交的交易处理都将被重新处理），所以这种方式可以实现交易处理级的一致性。
文件系统的行为与此不同，所以您在开始使用所有的PPRC辅助卷之前需要对其进行一次文件系统检查。当然，重新引导主机将会取得同样的效果。
在保证电源故障一致性时，您仍然可能面临着所谓写丢失（lost writes） 的风险——这是指在途中尚未被提交的交易处理。您可以想象的是，未提交的交易处理将会丢失。另一方面，已经被传输到ESS并确认已被写入到NVS（在PPRC的情况下是指辅助ESS的NVS）的数据将被转储到磁盘。
应用一致性的恢复时间最短。但是，为获得一个应用一致拷贝，您需要停止应用的更新并通过一次（卷）更新操作创建一个FlashCopy。这是一个不能反映当前状态的时间点拷贝，但是能够反映截至最近一次（卷）更新之前的任何更新。
至于一致性的范围，我们可以将其划分为卷一致性和全局一致性：
卷一致性 意味着确保某一特定辅助卷具有某些类型的一致性。
全局一致性 意味着确保应用进行过更新的所有卷都具有某些类型的一致性。
要求保证的一致性范围将取决于应用写操作的特点，以及数据文件在工作站点上的分布。
当所有的卷对都处于全双工状态时，同步PPRC仅能确保电源故障全局一致性。当故障影响到某些卷对（或在不同的时间影响不同的卷对）时，可能会失去全局一致性。例如，如果一个辅助卷由于路径故障而不能被更新，那么相应的主卷在正常情况下将进入到挂起状态，但仍然允许对其进行更新。不过，这些更新将不能被传输到辅助卷上。这样就失去了跨多个卷的全局一致性——虽然其他辅助卷仍然可以确保正确的写操作次序。
下面描述的一致群组可以帮助控制全局一致性。
PPRC一致群组
为能够在恢复站点维持跨多个卷的数据一致性，可以将属于一个PPRC关系的多个卷组织为一个PPRC一致群组（PPRC consistency group） 。一个PPRC一致群组是拥有相同主LSS和相同辅助LSS的一组卷对——而且这些LSS上的PPRC consistency group（PPRC一致群组） 选项已经被激活。可以通过以下两种可能的方式来激活这一选项：
· 在建立从主LSS到辅助LSS的路径期间激活这一选项。您可以选中路径选项面板上的PPRC consistency group（PPRC一致群组） 复选框。

如果使用这一方式激活这一选项，那么在一个PPRC关系中所有从这一主LSS到这一辅助LSS的卷对（共享相同路径）都将属于一个一致群组。其他卷对将不会受到影响。
· 在LSS级激活这一选项。您可以选中LSS属性面板上的PPRC consistency group（PPRC一致群组） 复选框。

如果使用这一方式激活这一选项，那么在一个PPRC关系中所有从这一主LSS到这一辅助LSS的卷对（使用任何路径）都将受到影响。

当发生的一个故障影响到这些卷中的任何卷时，这一属性将改变这些卷对的行为。
· 如果没有PPRC consistency group（PPRC一致群组） ，ESS会使检测到故障的卷进入挂起状态，但仍然允许对该卷进行更新。
· 如果激活了PPRC consistency group（PPRC一致群组） 选项，那么该卷将被挂起并进入一种长时间忙状态，在这种状态下不可能对其进行更新。
长时间忙状态（long busy state） 是为S/390定义的，意指使用特殊代码进行单元检查，该代码通知主机故障恢复程序停止当前的I/O操作并在控制单元恢复连接或两分钟过去之后重新确定I/O操作的次序。然后I/O将重新开始。如果控制单元仍然处于忙的状态，那么将重复执行单元检查。
对于开放系统（通过SCSI或FCP连接）来说，这一状态将以队列满（QUEUE FULL，QF ）状态字节代码的形式通知主机。在每一SCSI命令完成后的STATUS阶段，将发送一个状态字节（除非该命令被某一特殊事件终止）。QF状态向主机发出信号，显示标签SCSI命令队列满以及I/O请求尚未被放在队列之中。主机系统随后将试图在逻辑单元的设备队列中重新对请求进行排队。因此，当群组中的一个卷发生故障，或主LSS和辅助LSS对之间的连接完全失效时，卷的一致群组功能可以（在主机级别上）临时将对所有PPRC一致群组卷的后续写操作以队列的形式保存在一个单一LSS对上。
通过操作系统和主机总线适配器的设置，可以修改QF处理的细节。例如，在某些Unix类型的系统中， scsi_ifsetcap 工具提供了各种选项，可以在一个QF状态返回时启用或禁用SCSI命令重试。 某些HBA工具也允许进行类似的修改。例如，基于Windows的Emulex FC端口启动器工具可以提供一个设置，能够将QF状态转换为BUSY（忙）状态，从而绕过磁盘级驱动器。
注意：在使用PPRC-XD时，不需要启用PPRC一致群组选项。PPRC-XD总是在远程站点维护一份存在失真的拷贝。只有当使用更新（catch-up）操作将所有更新传输到辅助卷，而且应用写操作处于静默状态时，PPRC-XD卷对才会处于一致状态。当在PPRC-XD辅助卷上创建一个一致时间点拷贝时，您将需要使应用写操作处于静默状态，而这会使QF超时窗口失去意义。
当一致群组中的第一个拷贝卷对被挂起并进入QF状态时，ESS故障恢复程序(ERP)将会发出一个SNMP通知（中断200）。当一致群组中的后续卷对被挂起（在发生全面路径故障期间）时，这一信息将被记录在一个数据表中。当其他卷对被挂起时，它们将会被添加到这一表中。在第二对被挂起5秒钟以后，ERP会发出一个SNMP通知（中断202），列出被进一步挂起的卷对。
在故障拷贝卷对处于QF状态期间，由上述通知触发的一个自动程序会向所有与该应用相关的LSS对发出一个freeze 命令，从而影响到一致群组中的其他主卷组。冻结操作导致主卷挂起，进入QF状态，并终止与其相关的路径。因此，恢复站点的所有更新都将停止，从而导致一个一致的检查点。需要指出的是，这样的自动程序并非是ESS软件中的一个组成部分，而是必须由用户提供。

注意：需要指出的是， QF状态只是为受到影响的主卷提供的（在发生路径故 障时，经常会有多个卷受到影响）。但是如果在LSS级执行一次冻结操作，会 导致该LSS中的所有卷进入挂起状态（使用QF条件），并终止所有相关的路 径。

因此，不要在作为一致群组一个组成部分的LSS对上将与不同应用相关的卷混 合在一起，因为非相关的卷也将会被冻结。
一致群组定时器功能可以帮助上述自动软件确定发出这些自动执行命令的时间。QF超时值可以被显示，而且可以从ESS拷贝服务Web用户界面的逻辑子系统面板中对其进行修改——选中所希望的LSS，然后点击Properties（属性） 按钮。随后将显示逻辑子系统属性面板，您可以检查PPRC consistency group time out（PPRC一致群组超时） 字段并修改超时值。这一参数的缺省值为2分钟。

1. Error detected, trap 200 raised.：检测到故障，执行中断200
2. Primary volume in error is suspended and goes into Queue Full condition.：

发生故障的主卷被挂起并进入队列满状态
3. Other volumes unaffected.：其他卷未受影响
4. Record suspends of subsequent pairs.：记录后续卷对的挂起
NetView Console：NetView控制台
Trap-200：中断200
FREEZE：冻结
1. Automation issues freeze to consistency group.：

自动执行程序向一致群组发出冻结命令
2. All volumes in consistency group suspended.：

一致群组中的所有卷都被挂起
3. All volumes in consistency group go into Queue Full.：

一致群组中的所有卷都进入队列满状态
4. All paths for the consistency group terminate.：

一致群组中的所有路径都被终止
5. Five secs after the second pair suspends, trap 202 is raised listing the subsequent suspended volumes.：

第二个卷对挂起后5秒钟，执行中断202，列出随后被挂起的卷

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/66684/showart_1755631.html