正品自然堂多少钱一套
2022年12月28日发(作者：初中副校长述职报告(精选20篇))
大总结：双活数据中心建设系列之---
基于SVC的三种主流双活数据中心架构
深入探讨
作为业务系统的最后一道防线，IT数据灾备中心必须在极端状况下确保重要业
务系统稳定运行。灾备方案的出现给业务系统提供了完备的数据级保护。然
而，传统的灾备方案中存在着资源利用率低、可用性差、出现故障时停机时间
长、数据恢复慢、风险高等问题。数据是否安全、业务是否连续运行无中断成
为用户衡量灾备方案的关键。作为灾备方案中的高级别的双活数据中心解决方
案，成为应对传统灾备难题的一把利剑。
传统的数据中心环境下，灾备生产中心长年处于休眠状态，并不参与前端应用
的数据读写工作。如果数据中心环境良好，没有突发性灾难的发生，灾备中心
资源就一直处于闲置状态，造成用户投资浪费。而在双活解决方案中，分布于
不同数据中心的存储系统均处于工作状态。两套存储系统承载相同的前端业
务，且互为热备，同时承担生产和灾备服务。这样不仅解决了资源长期闲置浪
费的大问题，还能使数据中心的服务能力得到双倍提升。
在这样的背景下，传统的数据灾备中心越来越不能满足客户的要求，用户希望
在成本可控的同时，建立高可靠性、高可用性、高可切换性的双活数据中心。
IBMSVC在双活数据中心建设的虚拟化存储解决方案中，有三种主流的双活基
础架构可以满足我们搭建新形势下高要求的双活数据中心，值得我们深入探
讨，分别为：SVCStretchCluster、SVCHyperSwap和SVCLocalVDM+SVC
PPRC。这三种架构方案针对不同的企业需求均能发挥最大的效用，本期专题讨
论会就是要把这三种架构方案聊透彻，讲明白，让企业在选择时有所依据，有
的放矢，并充分挖掘自身企业的思维方式，选择最适合自身企业发展的双数据
中心虚拟化存储解决方案。
在本期讨论会上，大家针对“基于SVC的三种主流双活数据中心架构”的话题
踊跃发言，提出了许多宝贵的观点和意见，现在我将分享、各类议题观点和各
类问题及回答进行梳理总结，如有疏漏，还请不吝赐教。
主要分为以下五个方面：
一、三种SVC双活数据中心虚拟化存储解决方案的架构与特性方面
二、多种SVC双活数据中心建设方案与非SVC方案的对比方面
三、双活数据中心间链路与带宽方面
四、虚拟化云时代，是采用分布式还是集中式管理方面
五、SVC同城容灾与异地容灾方面
六、私有云建设与双活建设架构、案例方面
总结格式为：
【方面】
【分享】
【议题】
【观点】
【问题】
【疑问】
【问题解答】
一、三种SVC双活数据中心虚拟化存储解决方案的
架构与特性方面
【分享】SVCStretchCluster
SVCStretchCluster也就是SVC拉伸式集群架构，就是把同一SVC集群中的
SVC节点分散在不同的两个数据中心，它们之间通过光纤链路连接，并且需要
第三地的仲裁设备。为了帮助大家深入理解SVCStretchCluster，先来理解
下SVCLocalCluster：
一套SVC集群最少包含2个节点，最大8个节点，两两节点组成一个I/O
group，因此一套SVC集群最大可以包含4个I/Ogroup，如下图所示：
每一个存储LUN都分配给一个I/Ogroup，你也可以手动转换存储LUN的I/O
group，比如说LUN1属于I/Ogroup0，当I/Ogroup完全不可用时，需要手动
转换至I/Ogroup1，因为每一个I/Ogroup均由两个SVC节点组成，所以每个
存储LUN均分配给一个优先的节点和一个非优先节点，如下图所示：
不同的存储LUN的优先节点可以不一样，这是SVC集群系统自动负载和分配
的，同一SVCI/Ogroup节点均衡负载着存储LUN，对于读I/O请求来说，来
自于优先的SVC节点，而写I/O请求在同一I/Ogroup的两个节点间同步，一
次SVCI/O写请求，分解为以下5个步骤：
1.主机发送写I/O请求至SVCI/Ogroup
2.优先的SVC节点A写入I/O至缓存，并发送I/O至同一I/Ogroup的另一
SVC节点B
3.节点B将写入I/O至缓存后，并回响应至节点A
4.节点A收到节点B的回响应后，向主机回响应
5.节点A将缓存写I/O写入LUN当中
写I/O流转图如图所示：
有人会说了，第5步最后才将缓存数据写入LUN当中，那么当还没有写LUN
时，SVC节点突然断电了怎么办？这种情况SVC也是考虑了，每个SVC节点均
配备了UPS电源，可以维持供电，可以保证缓存数据正常写入LUN当中。
基于以上这种机制，同一I/Ogroup的两个SVC节点是实时同步的，当I/O
group中的主节点故障时，另一SVC节点将接管，并进入写直通模式，并禁止
写缓存，也就是说只有1、5、4三个步骤。
以上是SVC的I/Ogroup在一个数据中心的情况，而SVCStretchCluster则
是将一套SVC集群下的同一I/Ogroup的两个节点拉开，分别放在两个数据中
心，之前连接SVC的一套存储，拉开后各放置一套存储，通过SVC做vdisk镜
像同步。说白了还是同一套SVC集群，同一个I/Ogroup，SVCLocal
VDM(vdiskmirror)拉开成SVCStretchVDM，映射给主机的volume还是同一
个，这样一来就不难理解了。SVC、存储、主机及第三站点光纤连线下图所示：
对于SVCStretchCluster来说，为了防范脑裂，仲裁站点是必需的。首先是
configurationnode，配置节点，是配置SVC集群后，系统自动产生的保存着
所有系统配置行为的节点，不能人工更改配置节点，当配置节点失效后，系统
会自动选择新的配置节点，配置节点十分重要，它对SVC节点仲裁胜利起着决
定性作用，仲裁胜利的排序规则如下：
1.配置节点
2.距离仲裁站点近的节点
3.距离仲裁站点远的节点
下图为SVCStretchCluster两个站点的仲裁配置示意图：
当两站点间光纤链路中断，第三站点仲裁节点活动时，脑裂发生，将通过投票
仲裁选举获胜的站点，按照上述的仲裁胜利规则，configurationnode位于节
点2，选举站点2优先赢得仲裁，通过站点2恢复业务的正常存储访问。
当第三站点仲裁节点不活动时，不影响主机的正常存储访问，但是此时，两站
点间光纤链路也中断了，发生脑裂，这时因为节点2为configurationnode，
它所拥有候选的Quorum将变为activeQuorum，该Quorum选举站点2为仲裁
胜利站点，通过站点2恢复业务的正常存储访问。
另外，SVC版本到了7.2时，又出了一个新功能，叫做EnhancedStretched
Cluster，这又是什么呢？增强版拉伸集群增强点在哪？之前的Stretched
Cluster看似实现了双活，实则只为数据级双活(SVCVDM)，主机访问SVC实则
只访问了一个I/Ogroup优先节点，另一非优先节点则只是完成了写缓存同步
的任务而已，无论是localcluster还是Stretchedcluster，实际的读写卷
操作并未通过非优先节点进行，通俗的说就是主备模式（ACTIVE-PASSIVE），
由于优先节点是SVC系统自动分配的，可能会出现一种情况是，主机在站点
A，但是存储卷的优先节点却在站点B，主拷贝的存储却在站点A，主机一直访
问了站点B的SVC节点，再访问站点A的存储，这样的存储路径完全不是最优
的，对主机I/O性能造成影响，但是这些在EnhancedStretchedCluster中均
得到改善，实现了SVC双节点双站点读写双活，在该版本，元素均赋予site属
性，如SVC节点、主机、存储等，不同站点的主机对各自站点的SVC节点和存
储进行读写操作，对同一volume来说，站点A的主机访问站点A的SVC节点，
站点A的存储，站点B的主机访问站点B的SVC节点，站点B的存储，存储访
问路径最优，两个站点的SVC节点、主机、存储都同时活动，实现应用级双活
（ACTIVE-ACTIVE）,在site模式中，SVC优先节点概念不起作用了，配置了
site模式的主机，优先访问活动的同site的SVC节点和同site的存储。如下
图所示为读写模式下的EnhancedStretchedCluster流转图：
绿色的箭头为优先的读I/O流转，红色箭头为站点2的存储失效后的读I/O流
转。
绿色的箭头为优先的写I/O流转，红色箭头为站点1/2的存储失效后的写I/O
流转。
需要注意是，在写操作时，两个站点的SVC节点的缓存是保持同步的，但是不
同于SVCLOCALCLUSTER，整个写操作的过程中，SVC节点的写操作响应在写入
缓存后就发生了，而不需要等待另一SVC节点写缓存完成并回复响应，这样一
来，优化了整个写性能，具体过程如下：
1.主机向SVC写I/O请求。
2.同站点的SVC节点将写I/O写入缓存，并向主机回复响应，同时将写I/O同
步至另一站点的SVC节点。
3.另一站点的SVC节点将写I/O写入缓存，并回复响应。
两个站点的SVC节点陆续将缓存写入各自站点的存储当中。
【分享】SVCHyperSwap
说到HyperSwap技术，在没有SVC存储虚拟化方案之前，HyperSwap技术主要
用于IBM高端DS8000系列存储当中，达到应用和存储的高可用和双活需求，但
是当时DS8000系列存储成本高昂，适用于核心类或者关键类应用的跨站点双活
需求，不利于整体性的双活数据中心规划和建设，更别谈异构存储的跨中心双
活建设了。但到了SVC7.5版本，SVC和V7000都可以支持HyperSwap技术
了，中端存储的地位瞬间提升了一个档次，异构的各类中端存储，结合SVC
HyperSwap，都可以实现跨中心的双活高可用了，那么究竟SVCHyperSwap是什
么技术？先来看看下面这张官方架构图：
从图中可以看到的是，先从架构上：
SVCHyperSwap采用了hyperswap的拓扑架构，最少需要两个I/OGroup，同一
I/OGroup需要两个节点，并在同一个站点，而且很惊喜的发现，每个站点均
有VDISK，主机映射了四个SVC节点，存储路径更多了，冗余性更高了。
而SVCStretchedcluster采用的是stretched的拓扑架构，一个站点一个
SVC节点，最大可达4个I/OGroup，但是同一I/OGroup的两个节点被分割到
两个站点。两个站点的存储通过SVC虚拟化后只有一个VDISK，主机还只是映
射两个SVC节点。
再从性能上：
SVCHyperSwap利用了更多的资源（包括SVC节点，线路和SAN交换机端口
等），每个站点均含有完全独立的SVC读写缓存，一个站点失效，另一站点也
能提供完全的性能，因为读写缓存在一站点失效后，不会被DISABLE，两个站
点的读写缓存是独立的两套，这点特别重要。
而SVCStretchedcluster占用了相对较少资源，能提供更多的VDISK（同一
SVCI/OGroupVDISK划分有上限），但是当一站点SVC节点失效后，另一站
点的读写缓存会被DISABLE，进入写直通模式，性能相对来说会下降，在某些
情况下，比如后端存储性能不够强，缓存不够大等。而且主机的存储访问路径
会减少一半。
另外一个主要不同点是，SVCHyperSwap有了VolumeGroups这样概念，它能
够将多个VDISK组合，共同保持高可用和数据的一致性，这对于需要映射多个
VDISK的主机来说会有很大帮助，假设以下场景（主机映射多个VDISK）：
1.站点2失效。
2.应用仍然从站点1进行读写，只在站点1进行数据更新。
3.站点2恢复。
4.站点1的VDISK开始同步至站点2的VDISK
5.站点1在VDISK同步时突然失效。
如果主机的多个VDISK没有配置VolumeGroups，主机将很大可能无法通过站
点2的数据恢复业务，因为站点2的多个VDISK正在被同步，尚未同步完成，
它们的数据并不在同一时间点，挂在起来无法使用，那么这样的话只能寄希望
于站点1。
但是如果主机的多个VDISK配置成VolumeGroups，主机是能通过站点2的数
据进行恢复的，虽然数据尚未同步完成，但多个VDISK间的数据一致性是可以
保证的，仍然属于可用状态，只不过数据不完全而已。
与SVCStretchedcluster类似的是，SVCHyperSwap中的主机、SVC节点和存
储均被赋予了站点属性，同时也需要配备第三站点作为防范脑裂的仲裁站点。
接着看下面这张图：
可以看见，一个hyperswap卷是由以下几个部分组成：
1.4个VDISK（可以是THICK/THIN/COMPRESSED,也可以被加密）
2.1个ACTIVE-ACTIVE的REMOTECOPYRELATIONSHIP（系统自己控制）
3.4个FLASHCOPYMAPS（FORCHANGEVOLUMES）（系统自己控制）
4.额外的ACCESSIOGROUP（方便IOGROUPFAILOVER）
基于该hyperswap卷技术，实现了两个站点VDISK的ACTIVE-ACTIVE。站点1
的MASTERVDISK写入变化时，被写入站点1的ChangeVolume中（基于FLASH
COPY，变化数据写入快照目标卷，原卷数据不变）,站点2的AUXDISK写入变
化时，同样被写入站点2的ChangeVolume中。一段时间后，系统自动停止
VDISK与ChangeVolume间的快照关系，ChangeVolume将回写变化数据至
VDISK，VDISK将通过SVCPPRC（REMOTECOPY）同步变化数据至另一站点的
VDISK中，之后，站点VDISK又将重新与ChangeVolume建立快照关系，与根
据这一原理，不断往返变化数据，保持四份COPY数据的同步的关系，当然这些
都是SVChyperswap系统自动完成的，用户无需干预。
另外，在hyperswap的卷复制ACTIVE-ACTIVE关系中，我们可以看到依然存在
MASTER或者AUX的标签，对于主机来说，两个站点的其中一个I/OGroup的
VDISK是作为PRIMARY，提供读写，所有读写请求必须经过该I/OGroup，然而
hyperswap会自动决定是本站点的I/OGroup的VDISK作为PRIMARY，还是主要
承担I/O流量的I/OGroup的VDISK作为PRIMARY。在首次创建hyperswap卷
和初始化后，被标签为MASTER的VDISK作为PRIMARY，但是如果连续10分钟
以上主要I/O流量是被AUX的VDISK承担，那么系统将会转换这种MASTER和
AUX的关系，从这点上也可以看出与SVCStretchedcluster的不同，虽然SVC
节点一样被赋予站点属性，但SVChyperswap在另一站点仍然活动时，不局限
于只从本地站点读写，它会考量最优存储访问I/O流量，从而保持整个过程中
主机存储读写性能。另外需要注意的是主要的I/O流量是指扇区的数量而不是
I/O数量，并且需要连续10分钟75%以上，这样可以避免频繁的主从切换。
上面讲了这么多，那么SVChyperswap的读写I/O又是如何流转的呢？
读I/O见下图：
可以看到，每个站点第一次HyperSwp初始化后，先各自从各自站点的SVC节点
读操作，绿色线为读操作I/O流转。
写I/O见下图：
可以看到，图中显示为站点1的主机一次写I/O全过程：
1.主机向本站点1的其中一个SVC节点发送写I/O请求。
2.该SVC节点2将写I/O写入缓存，并回复主机响应。
3.该SVC节点2将写I/O写入节点1缓存，并同时发送写I/O至站点2的节点
3和节点4。
节点1、3、4回复节点2的响应。
5.两个站点的SVC节点分别将缓存写入各自站点的存储当中。
【分享】SVCLocalVDM+SVCPPRC
上面通过大量篇幅介绍了SVCStretchedCluster和SVCHyperSwap，这两种
存储虚拟化双活数据中心解决方案均为ACTIVE-ACTIVE模式SVC方案，那么
SVCLocalVDM+SVCPPRC又是什么？SVCLocalVDM即本地SVCVDISK
MIRROR，跟StretchedCluster方案采用了类似的存储复制技术，只不过是本
地非跨站点的VDM，又跟SVCHyperSwap方案采用了相同的SVCPPRC远程复制
和Consistency一致性组技术，而且对SVC的版本没有很高的要求，SVC6.4
版本就可以实现，可以说是另外两种技术的爸爸，另外两种技术均是由它演变
升级而来，既然是较老的技术，为什么还要再这里谈呢？还不是ACTIVE-
ACTIVE，只是ACTIVE-STANDBY。
当然有必要，有以下几个必要点：
1.利用SVCLocalVDM+SVCPPRC可以实现本地双同步数据保护+灾备同步数据
保护，还很容易实现异地异步数据保护。充分保护本地级存储数据，和本地可
靠性。
2.结合PowerHAEXTENDDISTANCE(PowerHAXD)很容易实现本地双主机+灾备主
机热备。本地主机故障，本地主机互相切换，本地双主机故障，主机和存储均
切灾备主机和存储，十分灵活，可将不同系统的主机分别布署在两个数据中
心。两个数据中心均各自承担些许业务。
3.无需第三站点仲裁，第三站点对于大部分企业来说，都基本相当于虚设，怎
么说呢，第三站点基本都放置于本地站点，本地站点故障时，第三方站点和本
地站点相当于全部故障，需要人为干预，才能在灾备站点恢复业务，复杂度
高。如果真正建立第三站点，又需要增加大量成本。
4.无需担心双中心间光纤光衰、线路延时、抖动甚至中断，充分保护本地站点
系统的可靠性。发生脑裂时，基于HACMPXD，生产端的主机数多于灾备站点，
发生脑裂仲裁时，生产站点总是会赢得仲裁胜利，将自动关闭灾备站点主机，
生产站点不受任何影响。对于这种情况来说，如果是ACTIVE-ACTIVE方式的脑
裂情况，特别是在将所有各类异构存储均接入SVC，通过两站点间SVC复制，
脑裂现象的影响面将扩大至整个数据中心业务层面，而不是仅仅小部分业务造
成中断。
那么，有人会说，题目是双活数据中心建设，SVCLocalVDM+SVCPPRC不应该
算是一种双活建设方案，只是实现了数据级存储双活。其实不然，利用该架
构，实则实现了双活中心的基础架构，应用层双活可以通过配合软件架构的方
式来实现，具体内容将在“双活数据中心建设系列之---基于软件架构的双活数
据中心建设方案深入探讨”主题中详细探讨。先来看下该SVC方案的架构，如
图所示：
可以看到，该方案需要两套SVC集群，最少需要2个I/OGroup，4个节点，本
地和灾备各一套SVC集群，一个I/OGroup，两个节点。该架构与HyperSwap
架构有点类似，不同的是该架构本地站点的存储有两个，灾备站点存储为1
个，本地站点两个存储通过SVC做VDM，本地站点和灾备站点存储通过两套SVC
做SVCPPRC，实现了三份存储数据实时同步。本地站点两主机挂载本地站点的
存储，灾备站点主机挂载灾备站点的存储，三台主机通过HACMPXD（基于SVC
PPRC）实现跨站点高可用，当本地站点的主机故障时，自动切向本地备机，业
务中断时长5分钟以内，具体根据HACMP切换时长；当本地站点主备机全部故
障时，本地存储和本地主机均自动切向灾备主机，业务中断时长5分钟内，具
体根据HACMP切换时长；本地一台备存储故障时，完全不受影响；本地一台主
存储故障时，自动切往本地备存储，业务I/O中断1分钟以内。
另外，该架构的数据读写流转在上面的SVCLOCALCLUSTER中已经详细介绍，
只是多了在SVCI/OGroup节点间写同步后，再同步一份写I/O至灾备I/O
Group的两节点，这里不再赘述。
【议题1】SVCHyperSwap和SVCStretchCluster做为A-A模式的SVC虚拟化
存储解决方案，有何缺陷或者风险？
【观点1】hyperswap不适合rac这种跨站点读写的双活
【观点2】据我了解到ESC模式下的iogroup并不是真正的冗余模式。比如我
有两个iogroup，所有的业务都在iogroup1上，当第一个iogroup的两个节点
都宕机的话前端业务也就中断了，业务并不会自动切换到iogroup2上。
【观点3】对的，SVCESC只有两个节点，两个节点同时故障时，需要手动干预
才能恢复业务，所以为了更高、更苛刻的冗余时，出现了SVCHYPERSWAP，但
是实际情况两个SVC节点同时故障的情况还是非常少。
【观点4】还是需要看业务类型，比如oraclerac，dg，vmware等，不一样的
业务要求不同。
【议题2】SVCLocalVDM+SVCPPRC作为A-S模式的SVC虚拟化存储解决方
案，有何缺陷或者风险？
【观点1】SVCLocalVDM是作为本地高可用的解决方案，缺陷或者风险来讲如
果同SVCPPRC只是作为本地数据高可用，无法做到容灾级别。
SVCPPRC是解决站点级别的灾备解决方案,所谓的缺陷是要跟谁去对比。比如
作为存储复制解决方案跟数据库复制方案比，各有优缺点。
【观点2】SVCLocalVDM+SVCPPRC做为数据级本地保护和容灾，结合HACMP
只是ACTIVE-STANDBY，像数据库级别的复制，主要还是事物级别的TCPIP同
步，性能和效率当然没有SVCVDM和PPRC高，但是一致性从事物层得到了保
证，但是数据库复制技术也是有限制的，它主要是通过事物日志复制和对端重
写来实现，但日志有时候也不能覆盖全部数据库操作，比如XML和LOB格式的
字段，是没法通过日志复制传输的，有些应用为了执行效率高，对数据库采取
了不记日志操作。
【问题1】
【疑问一】SVC的ESC拉伸双活模式Lun是否可以就近读写？hperswap模式是
否可以就近读写？SVC的ESC拉伸双活模式Lun是否可以就近读写？hperswap
模式lun是否可以就近读写？还是只能读对端lun？造成这个问题的原因是什
么？
【问题解答一】SVCStretchCluster与SVCHyperSwap的最大特性就是SVC节
点“站点化”，主机节点“站点化”，存储节点“站点化”，所以这两种模式
都是同一站点的主机读写同一站点的SVC的节点，SVC节点读写同一站点的存
储节点。
所以这两种ACTIVE-ACTIVE存储双活方案，是就近读写的，另外SVC
HyperSwap不仅仅是就近读写，如果本地站点的IO流量连续10分钟低于25%，
而对端站点的IO流量连续10分钟高于75%，那么SVCHyperSwap将反转读写
关系，优先读写对端站点。
【疑问二】感谢解答，但我认为hyperwap双活模式下，不可以就近读写。两个
站点都要去找该lun的owner站点去写，然后镜像到另一端缓存。因SVC与
vplex的全局一致缓存不同SVC的hperswap是两套缓存表。正式因为这种情
况，导致会有主机频繁写对端lun的情况出现，导致lunowner关系反转。不
知道我的看法是否正确？谢谢
【问题解答二】不对，rswap虽然是两套缓存表，但是缓存与缓存的
同步是在SVC节点间进行的，与主机无关，主机只是读写同站点的SVC节点和
存储，不会去读写另一站点的SVC节点，当主机写同站点的SVC节点后，SVC
立即返回响应，表明已经完成写操作，剩余的缓存同步和落盘的事情由SVC内
部完成。
rswap架构，每个站点都有各自的MASTER和AUXVDISK，主机优先读
写MASTERVDISK，直到主机出现连续10分钟75%以上的I/O读写在AUXVDISK
上，AUX和MASTER的关系将反转，基于这样一种机制，MASTER和AUX的关系不
会不停的反转，而是既控制住了反转频率，又在MASTERVDISK站点出现性能问
题时，能够及时反转关系，提升性能。
【问题2】
【疑问一】数据不完全，如何实现数据可用？
请问："但是如果主机的多个VDISK配置成VolumeGroups，主机是能通过站点
2的数据进行恢复的，虽然数据尚未同步完成，但多个VDISK间的数据一致性
是可以保证的，仍然属于可用状态，只不过数据不完全而已。"既然数据不完
全，然后和实现可用？
【问题解答】1.多个VDISK配置成了VolumeGroups的形式，那么两个站点的
多个VDISK的一致性是同时的，也就是说站点1的多个VDISK同时写，站点2
相应的多个VDISK写也是同时写的，这样一来，每次站点2的多VDISK写入
后，从存储视角来说，多VDISK是数据一致性的，站点2的主机是能利用这一
致性的多个VDISK的，在允许数据一定丢失的情况下，即使同步没有完成，还
是可以利用的。而如果是主机拥有多个VDISK，但是这多个VDISK不配置成
VolumeGroups的话，两个站点仅仅是单个VDISK是一致性的，站点2的多个
VDISK的同步时间戳不一样，不能保证多VDISK同时是一致性的，如果同步没
有完成，那么站点2可能无法利用这些VDISK。
2.存储的一致性组是建立在存储视角的，假如是数据库的话，更好的办法是从
数据库事物的层面保持一致性，但是当今存储没有谁能做到这一点。
【疑问二】还是没太明白，数据不完全跟数据可用如何理解？
【问题解答】主机对文件系统的一次写是对多个PV分别写，对吧？该站点的
PV与站点2的PV同步时，如果没有配置同步卷组是不是同步有先有后？有可
能这个卷已经同步了，那个卷还没有同步，那这时，站点1故障了，站点2的
这些存储卷是不是得有逻辑错误了？是不是不可用了？那如果配置了同步卷
组，站点2的的多个PV是一起同步的，本地站点的多个卷一次写操作，站点2
的多个卷也是一起写的，是不是就是一致性卷组了？当站点1故障了，即使站
点2还没有完全同步完，这些一致性卷组是不是没有逻辑问题了？是不是可用
的？
【问题3】
【疑问一】IBMsvcESC和hyperswapcache工作模式和lun的读写访问方式区
别？EMCvplex的显著区别是什么？IBMsvcESC和hyperswapcache工作模式
和lun的读写访问方式区别？我们都知道EMCvplexmetro是全局一致性缓
存，缓存形式的不同，SVC和vplex在双活特性上带来了哪些不同？
【问题解答一】缓存形式的不同，VPLEX没有写缓存，这就意味着写性能会有
一定的影响
【问题解答二】ESC是SVCLOCALCLUSTER的跨站点拉伸版，主要
是利用了VDM的技术和原理，而SVChyperswap主要利用了FLASHCOPY和SVC
PPRC技术和原理；SVCESC缓存同步是在同一I/OGROUP的两个节点进行，而
SVCHYPERSWAP既有同一I/OGROUP又有不同I/OGROUP的两个节点缓存同步
ESC和SVChyperswap读写方式均是就近原则，本站点读写本站点
的SVC节点和存储。但SVChyperswap较高级的地方在于，它会判断两个站点
的读写I/O流量，如果某个站点I/O流量连续10分钟占比75%以上，那么它将
反转MASTERVDISK和AUXVDISK的角色。
exmetro是全局一致性缓存，但它没有写缓存，虽然都是各自站点
就近读写，但是增加了后端存储压力，写性能上可能会受影响。举例来说，像
SVC+FLASH存储，在关闭了SVC写缓存的情况下，整个性能没有打开SVC写缓
存高。
【疑问二】据我了解到ESC具有就近读写功能，HyperSwap没有这个功能吧？
【问题解答】两个都有就近读写功能，HYPERSWAP所需的SVC版本还比SVCESC
高，把SVC节点、存储和主机都站点化了，有更多的节点冗余和更多的性能优
化。
【疑问三】PPRC是啥玩意？
【问题解答】point-to-pointremotecopy，也就是metro-mirror
【问题4】
【疑问一】SVCHyperSwap和SVCStretchedCluster适合哪些场景？
SVCHyperSwap和SVCStretchedCluster适合哪些场景？哪些场景选择SVC
HyperSwap更有优势？二者的性价比如何？
【问题解答一】首先这两者都是高可用解决方案中的两个技术代表
SVCHyperSwap可以说是对SVCesc技术灵活性的补充或者说是增强
具体来说V7KV5K是无法做到的ESC的，同样IBMV9000也无法做到ESC.
而hyperswap技术对V7KV5KV9000开启了大门，使这些产品也有高可用的特
性。
【问题解答二】楼上正解，如果是没用SVC，仅仅用hyperswap技术，那么性
价比肯定是V7KV5KV900之类的更高，只用存储就实现了跨中心存储双活。
如果用了SVC，hyperswap用了4个以上的SVC节点，StretchedCluster只用
了两个，但是hyperswap的性能和可靠性较StretchedCluster有所增强，但
StretchedCluster又能扩展到今后的异地灾备，如果简单的以价格来区分两
者的化，那么首选StretchedCluster，如果要综合比较的话，两者真的不相
伯仲，要看你的需求。
如果你不关心价格，就是要最好的高可用，最好的性能优化，对划分的卷上限
1024也可以接受的，不要求将来实现扩展同城或者异地灾备的，运维技术也能
保障，那就推荐hyperswap，如果你关心价格，对性能和高可用要求不那么苛
刻，将来想实现异地或者同城灾备扩展的，那么推荐StretchedCluster，但
是SVChyperswap和SVCStretchedCluster都要求有第三站点仲裁，而且对
两个站点间的链路的稳定性、可靠性、性能要求很高。
【疑问二】你好，esc用两个节点就够了吗，我看了一个文档，esc也推荐最少
4个节点，2个为1个iogroup。4个节点比两个节点的优势有哪些呢？
【问题解答三】ESC最少两个节点，在主机较多、SVC节点负载较大的情况下，
推荐4节点，甚至6节点、8节点，将I/O读写分散于不同的I/OGROUP上，
如果仅仅是1个I/OGROUP，那么所有主机均通过这个I/OGROUP读写存储，
是否负载能满足，是需要考虑的。从冗余上来说，1个I/OGROUP和2个I/O
GROUP都是一样的。都是靠同一I/OGROUP的两个SVC节点来冗余的。
【问题5】
【疑问】V7000HYPERSWAP实施请教
HyperSwap中如何保证数据的一致性吗？是如何配置的呢？
看到论坛里面说到SVChyperswap通过VOLGRP数据的一致性，但是我在实施
V7K（7.7.1.3）hyperswap时候，GUI中没看到volumegroup。
【问题解答】建议从CLI中配置HYPERSWAP
1.创建一致性组
例如：mkrcconsistgrp–namehsConsGrp0
2.创建mastervdisk
例如：mkvdisk–namehsVol0Mas–size1–unitgb–iogrp0–
mdiskgrpsiteA-ds8k-accessiogrp0:1
3.创建AUXvdisk
例如：mkvdisk–namehsVol0Aux–size1–unitgb–iogrp1–
mdiskgrpsiteB-ds8k
4.创建Changevdisk
例如：mkvdisk–namehsVol0MasCV–size1–unitgb–iogrp0–
mdiskgrpsiteA-ds8k-rsize0%-autoexpand
例如：mkvdisk–namehsVol0AuxCV–size1–unitgb–iogrp1–
mdiskgrpsiteB-ds8k-rsize0%-autoexpand
5.创建relationship
例如mkrcrelationship–masterhsVol0Mas–auxhsVol0Aux–cluster
testCluster-activeactive–namehsVol0Rel
6.开始同步
例如：mkrcrelationship–masterhsVol0Mas–auxhsVol0Aux–cluster
testCluster-activeactive–namehsVol0Rel–sync
或者7.创建relationship并加入一致性组
例如：mkrcrelationship–masterhsVol0Mas–auxhsVol0Aux–cluster
testCluster-activeactive–namehsVol0Rel–consistgrphsConsGrp0
或者8.创建relationship并加入一致性组同步
例如：mkrcrelationship–masterhsVol0Mas–auxhsVol0Aux–cluster
testCluster-activeactive–namehsVol0Rel–consistgrphsConsGrp0-
sync
9.建立master和AUX的VDISK与对应changevdisk的relationship
chrcrelationship–masterchangehsVol0MasCVhsVol0Rel
chrcrelationship–auxchangehsVol0AuxCVhsVol0Rel
完成
【问题6】
【疑问】SVC主流双活方式之一StretchCluster的实现方式
StretchClustr，也叫拉伸式集群，在该模式下，本地的A，B站点是双活的，
远程C站点可以用GlobalMirror实现两地三中心，请专家通过实例讲解这种
双活方式实现双活的原理以及这种方式有没有风险？
【问题解答】1.实现双活原理：
svcstretchcluster是SVCLOCALCLUSTER的拉伸版，其实现原理和技术主
要是SVCVDM，它需要最少一套I/OGROUP，两个SVC节点作为需求，每个站点
的主机均读写各自站点的SVC节点和存储，对于写操作来说，先写某个SVC节
点的缓存，再将该缓存同步至另一站点的SVC节点中，最后分别落盘，在另一
站点的主机写操作也是同样，为了保证两边存储写数据的一致型，不导致脏
读，SVC用了锁排斥技术。另外SVC利用在双活的基础上，利用GlobalMirror
技术可以将SVC的数据异步地同步至异地站点的V7000、SVC等中。
2.风险
伴随着双活，风险也是当然的，没有哪一种技术是十全十美的，按照企业的需
求都有用武之地，SVCStretchcluster的风险在于同一I/OGROUP只有两个
SVC节点，本地一个，灾备一个。本地SVC节点故障，则切往了灾备SVC节
点，冗余度来说，本地有点单点的感觉；另外SVCStretchcluster对两个站
点间的链路要求很高，需要稳定度高，时延和抖动尽量小，如果两中心间链路
中断，那么两个中心的SVC节点读写将HOLD住，直到第三站点仲裁选举出胜利
站点，如果所有业务主机均通过SVC节点访问存储，所有业务将有一段时间被
中断，中断时间取决于两个站点间距和仲裁时间。
【问题7】
【疑问】在一套SVC集群的，节点之间的缓存数据同步是通过什么途径进行
的？是管理网络？是san存储？是fc链路？
【问题解答】通过fc链路。节点间通信走clusterzone内的端口，或者通过
cli限定只走某些端口。
【问题8】
【疑问】关于lun和raidgroup的问题
划分lun时，一个lun可以来自不同的raidgroup吗？
【问题解答】可以
1.如果划LUN是通过普通存储化，没有经过SVC，那么每个LUN和POOL是对应
的，POOL又跟RAIDGOUP是对应的，只有RAIDGROUP的RAID形式是一致的才
能放到同一个POOL中（一个RAIDGROUP对应一个MDISK），所以该LUN划分
出来后，该LUN是经过了多个MDISK虚拟化之后的产物，BLOCK分布于多个
MDISK上，所以可以来自多个相同RAID形式的RAIDGROUP，但无法来自多个不
同RAID形式的RAIDGROUP
2.如果划LUN是通过SVC划出来的，但是底层存储通过IMAGE模式透穿至SVC
的，也就是说底层存储LUN--->SVCLUN是一一对应的，这时SVC上的LUN在底
层存储上的分布也是来源于相同RAID形式的RAIDGROUP
3.如果划LUN是通过SVC划出来的，但是底层存储通过MANAGE模式映射给SVC
管理的，如底层存储RAID5组成如下一个逻辑关系：MDISK--->RAID5POOL--
->存储LUN1--->SVCMDISK1，底层存储RAID10组成如下一个逻辑关系：
MDISK--->RAID10POOL--->存储LUN2--->SVCMDISK2，再通过SVCMDISK1和
SVCMDISK2划出一个新的SVCVDISK，这时的SVCVDISK的BLOCK是分布于不
同RAID形式的RAIDGROUP的。
【问题9】
【疑问】SVCLocalVDM和SVCPPRC数据同步的粒度是？是实时更新数据吗？
【问题解答】都是实时同步的，因为每次的写SVC节点的操作，都会要等待另
一SVC节点的写响应，才会认为是一次完整的写操作周期。补充一点，同步的
颗粒度是bitmap（位图）
【问题10】
【疑问】SVC管理的存储扩容，SVC会不会出现瓶颈？
目前的环境下面一套svc有一个IOGROUP，下面挂载了不同的存储，现在相对
下面的挂载的存储扩容，担心随着后面存储容量的扩大，SVC会不会出现瓶
颈？怎么判断？
【问题解答】上面这个问题来说，如果仅仅从后端挂载的存储容量扩容，SVC
是会不出现性能瓶颈的，SVC最大支持4096个VDISK，如果后端存储扩容，划
分出来的卷的数量也越来越多，甚至需要超过4096个VDISK，那么SVC仅仅是
不再支持划分而已，性能不会出现问题。如果从SVC映射的主机数量角度来
说，如果SVC映射的主机数量越来越多，那么均分至每一个SVCI/OGroup优
先节点的主机数量也越来越多，这时就需要考虑SVC节点的性能瓶颈，因为
SVC节点的缓存容量有限，主机数量的增加意味着所有主机平均每次需要写入
的IO量增多，假如增大至单个SVC节点缓存不足够容纳时，这时就会开始出现
性能瓶颈，就需要开始新增SVCI/OGroup了。
其实SVC的性能很不错，借用一下前人测试的结果：
“”单论SVC的节点性能，在前两代的CF8节点上做过SPC-1测试，16个
V7000在8个CF8节点管理下，SPC-1性能达到50多万IOPS。现在最新的DH8
节点，性能是CF8的3-4倍，那么性能可达到150-200万IOPS，每个I/O
Group可达到50万IOPS。“”
我们可以利用监控来判断SVC节点是否已饱和，如TPC软件，也可以用SVC自
身WEB界面上的监控来初步判断。
二、三种SVC双活数据中心建设方案与非SVC方案
的对比方面。
【分享】三种SVC双活架构详尽对比
在上面的章节中，我们已经深入探讨了基于SVC的三种主流双活数据中心架
构，详细的介绍了每种架构的基本模式、特性、原理和I/O读写等方面内容，
为了更方便与直观的展示三种架构的区别和特性，列表如下：
上面的列表很直观的展示了三种SVC架构的区别和共同点，可以看到，三种架
构在不同的场景和不同的高可用要求下，均有用武之地。SVCStretched
Cluster和SVCHyperSWAP架构实现了双站点ACTIVE模式，但这两种模式有两
个弊端，一是对数据库双活的实现，依旧需要配合数据库软件层的方案解决。
二是对两个站点间的线路要求非常高，一旦线路中断（这种情况并非不可能，
尤其在当下各种修路、修地铁，多家运营商的裸光纤都在同一弱电井，同时断
的可能性大增），将对两个站点的所有主机均造成一段时间的影响，所有业务
被中断，影响时间取决于仲裁时间和两站点间距离。而且还需要忍受站点间线
路的时延和抖动的可能造成的影响，站点间距离越大，这种影响会被不断放
大，影响读写性能，甚至造成线路中断。这种情况下反而不如用SVCLocal
VDM+SVCPPRC架构，从分保护了本地资源，排除了可能的不可抗拒的影响，而
且如果采用了SVCLocalVDM+SVCPPRC架构，虽然存储架构层作为ACTIVE-
STANDBY方式，但仍旧可以配合软件层实现双活数据中心建设；另外SVC
HyperSWAP架构看似很高级，无论从双站点的读写性能优化、单一站点失效后
的全面保护能力方面还是双活架构后的高可用方面均优于Stretched
Cluster，但却无法继续进行两地三中心扩展，实施复杂性也更高，运维成本也
提高，而且总的VDISK数量较少等等；SVCLocalVDM+SVCPPRC充分保护了本
地，但是灾备的实施却又局限于AIX系统下的HACMP，6.1之前的AIX版本和
linux、windows系统均无法实现跨站点高可用，只能从数据层同步，并利用软
件层的方式实现高可用和双活。而且SVCLocalVDM+SVCPPRC的一套SVC集群
下的两个IOGroup间无法自动切换，这点SVCStretchedCluster也是如此，
也就是说如果SVCStretchedCluster配置为2个I/OGroup，I/OGroup间是
无法实现自动切换的，需要人为手动切换；SVCStretchedCluster实现了
ACTIVE-ACTIVE，又可以扩展两地三中心，但是读写性能优化方面做得又不如
SVCHyperSWAP，而且本地冗余度做得也不大好，本地一个SVC节点故障，本地
就没有冗余保护，只能利用灾备站点的SVC节点，这点在SVCLocalVDM+SVC
PPRC和SVCHyperSWAP都得到了冗余度提升；另外还有一点共同点得我们关
注，我们知道SVCStretchedCluster、SVCLocalVDM+SVCPPRC和SVC
HyperSWAP均使用了同步复制技术，但有没有想过如果真的因为站点间距离
长，时延比较大，导致两个SVC节点同步缓慢，以致最后影响双数据中心整个
业务系统的写I/O缓慢。SVC还考虑到了这一点的，在SVC节点同步的参数中
有mirrowritepriority属性，可以设置为latency，当同步响应时间大于5秒
时，放弃同步，保证主站点/主存储的写I/O性能。基于此，三种方案针对不同
的企业需求，不能说哪种方案通吃，也不能说哪种方案一定不行，都有使用优
势和劣势。
【问题1】
SVC存储网关与友商类似产品的对比优劣势是什么？
【问题解答】
【问题2】
针对有些厂商的存储阵列自身带有双活+复制的功能，SVC的ESC的优势如何体
现？现在有厂商存储阵列自带双活+复制功能，例如：A中心和B中心之间双
活，B中心存储和C中心存储做复制，完全通过存储阵列自身实现。目前，IBM
DS8000和SVCESC+复制能够实现。但是ESC的IOGROUP中单节点故障严重影
响性能，如何应对？
【问题解答】1.自带双活功能的存储算是少数，如DS8000+HYPERSWAP，即使
有，也需要LICENSE，有的MM也要LICENSE，GM也要LICENSE，中低端存储就
没办法了，像SVC这样把高中低端存储均融合后，用SVCESC和SVC
HYPERSWAP都实现了双活或者双活+异地。
的IOGROUP单节点故障，将引发节点切换，站点的主机将会访问另
一站点的SVC节点，只是造成了短暂时间的访问中断而已，另一站点SVC节点
接管后，性能不会出现明显的下降。这种方式并没有不妥，只是本地站点只有
1个SVC节点，冗余性来说，有点不够。另外，SVCESC的IOGROUP单节点故
障后，由于一个IOGROUP是同一套缓存，会造成写缓存DISABLE，这样对于中
低端存储来说，可能会出现性能些许下降，但不明显和致命。
3.对于SVChyperswap的IOGROUP单节点故障，则好了许多，两站点都有双节
点保护，站点与站点间的写缓存均独立，而且还有读写性能优化方式，如连续
10分钟读写I/O占比75%以上则改变主从VDISK方式等。
【问题3】
SVC存储网关双活形式与控制器双活（HDSNETAPP华为）间有何优劣
【问题解答】单单从双活形式来说，一个IOGROUP的两个SVC节点的双活和存
储控制器双活实现原理都是类似的，都是两个节点间的缓存同步和锁排斥机制
实现的，但是SVC先进的地方是两个节点可以拉伸至两个站点，存储控制器两
个节点是实现不了的。
三、双活数据中心间链路与带宽方面
【议题1】双活数据中心建设过程中，最大的难点是双中心间链路带宽，时延
和抖动，各位有什么深入的见解？如何更充分地考虑，需要注意的点有哪些？
应如何尽量避免该问题，高可用的链路该如何设计？各位专家对此有何深入见
解？
【观点一】链路带宽，时延，抖动，这是由运营商线路质量设备决定的，用户
对这块只能加大监控，束手无策，没法改变
【观点二】建议两个数据中心距离不要超过100km，同时采用至少两条以上的
不同运营商线路
【观点三】考虑到运营商的光缆质量问题，使用双运营商的链路，且距离不宜
超过60KM
【观点四】链路的抖动我深有体会！
在一个客户现场～两个双活数据中心～夸中心做的hacmp.～需要同时访问两
个中心的存储～中间运营商的链路有比较大的衰减——12到14吧好像！这
种衰减都tcpip这种传输没有什么影响但是对光纤的传输就影像大了～主
机访问存储时好时坏！Vg被锁影像业务！
所以我觉得在硬件层面做灾备双活不是很可靠尤其是光纤的！
还是做数据库那种dataguard好像更靠谱
【观点五】dataguard据我所知是数据库事物日志的复制技术，如果采用同步
的方式，TCPIP效率较低，跨中心同步复制可能会影响性能，而且数据库日志
复制技术并不能覆盖数据库的全部操作，像XML和LOB格式的字段数据的增删
改操作，是不会记日志的，有些应用为了效率的提升，采用了不记数据库日志
的方式。但是数据库日志复制技术可以从事物层面保证数据库一致性，而通过
存储链路作为数据传输通道的存储复制技术是从存储BLOCK层保证数据一致性
的，差距可想而知。
【观点六】1、取决于运营商，应该选不同的两家运营商。
2、距离不宜过远。（50km以内比较好）
3、分业务，不是特别重要的，做主备即可，特别重要的可以考虑双活。
【观点七】从大家描述中，基本都是选择了不同的两家运营商，距离姑且不
谈，毕竟仁者见仁，智者见智，但是两家运营商的裸光纤基本都在同一弱电井
中，即使两家都采用了各自裸光纤的冗余，但是当前丢地铁啊，修路啊，改造
啊，建设啊非常常见，两家运营商的裸光纤同时断，或者几条衰减很大，几条
又断了的情况屡见不鲜，而在双活建设当中，中间链路是重中之重。
【观点八】链路问题不可预估，也很难改善，做好监控，想办法降低RPO，这
样双活才有意义
【议题2】如何实时监控双活数据中心链路状况，避免因链路突发性故障或者
性能衰减导致重大故障，如何应急？
如果采用了双活数据中心架构，该采用哪种技术或者软件监控双数据中心链路
状况？遇到突发状况，该采取哪些措施应急处置？
【观点1】监控链路本身还不如去监控业务本身，比如交易响应时间，峰值
等，出现交易堵塞失败，毕竟一切都是为了业务应用服务的，必要的应急预案
应该是在是建设双活数据中心上线前，需要做的大量的场景测试，编写应急手
册。遇到类似的问题，根据业务和技术评估，采取如何的应急方案.
【观点2】链路监控是必须的，但是链路监控一般运营商决定的，我们在我们
的出口上可以监控到带宽情况，这样来推理，可以看出带宽是否满足需求，是
否有抖动。
【观点3】链路监控一般是运营商去做的，客户自己可能做不到，但客户自己
的应用运行状况，存储运行状况可以监控到的
【问题1】
双活数据中心建设过程中，双中心间链路带宽的选择，链路采用的形式等方
面，从用户的角度那些更好一些？
比如采用那种方式，多少带宽可以基本满足双活中心的要求？
链路采用的形式，是采用用户全部租用运营商的链路+传输设备？还是只租用运
营商的链路，而双中心的传输设备按用户要求来实现配置等？希望各位专家和
同仁共同探讨，给一些建议。
【问题解答一】个人意见
1.双活数据中心”所需网络的最低带宽取决于两个方面，一是存储SAN网络，
二是IP网络。SAN网络带宽取决于本地存储+同城存储写入I/O吞吐量，这个
吞吐量在建设双活数据中心时，会同步写至另一站点，这个可以在本地和同城
进行监控和评估；IP网络带宽取决于你双活的形式，如果是数据库双活，就需
要评估和监控跨站点两个数据库间数据传输的网络吞吐，如果是应用双活，就
需评估跨站点间两个应用间数据共享的网络吞吐，还应该考虑应用是就近站点
读写本地数据库，还是跨站点读写，还有应用间交互是就近站点读写，还是跨
站点交互读写，根据双活数据中心“双活”的等级进行提前规划、监控和整体
评估，这是个浩大的工程。
2.链路采用的形式一般是只租用运营商的链路，双中心的传输设备自己购买和
配置，这样更灵活又控制成本。
【问题解答二】这个问题我觉得还是主要看双活中心存储和应用的需要了，存
储双活，存储之间同步链路需求最低带宽多少，应用如果是oraclertt时间
是多少，而且中间链路延迟等等，得综合考虑
【问题解答三】第一，双活中心建立起来，基础数据同步完成
第二、计算所有业务每天的数据量有多大。
第三、测试运营商带宽速度和稳定性
第四、计算比如千兆网络把，一秒最多100m出头，总数据量去除就得出你的
带宽，然后要考虑抖动，延迟，和高峰期，适量的加点富裕即可
保证以上4点，我认为比较合理，不是拍脑袋上。
【问题2】
SVC双活时FC交换机中间链路问题
有实施过程中关于生产中心与灾备中心间链路，是否有最佳实践。
FC交换机间链路最多支持几条？
自建光缆需注意哪些问题？
【问题解答】1.链路最佳实践，目前没有，我已列议题，希望各位专家提出自
己的见解：双活数据中心建设过程中，最大的难点是双中心间链路带宽，时延
和抖动，各位有什么深入的见解？
交换机之间的级联线建议是2条，做绑定，并且提升带宽。
3.一般是租用用运营商的光缆，多家运营商互备，自建的也太有钱了吧。
四、虚拟化云时代，是采用分布式还是集中式管理
方面
【议题1】虚拟化云时代，民主还是集权，如何在集权过程中，进一步加强稳
定性和高可用？在虚拟化云时代，集中化、虚拟化、资源池和弹性动态伸缩等
都成为其代名词，但是我们感觉到业务系统越来越集中，使用的资源全部来自
虚拟化过后的资源。如存储通过SVC虚拟化，单台物理机资源集中化，GPFS文
件系统NSD格式化等等，越来越多的鸡蛋都集中在一个篮子里了，各位专家对
此有何看法和观点，欢迎共同探讨！
【观点一】建议一般对资源池进行集中管理比较稳妥，业务系统需要直接申请
资源就可以了，而且集中管理，，统一监控，同时对设备的生命周期，运行状
况都能实时观察到！
【观点二】我觉得不能拍脑袋上，具体还得看业务类型，有得业务不适合集
中，该分散就分散，不然中心压力过大，但是总路线肯定是重视中心，弱化分
支
【观点三】集中便于管理，但带来故障影响的风险会增高，根据业务来找到平
衡点，另外开始就需要考虑高可用的问题，否则后期会有巨大隐患
【观点四】这里的集中或分散主要是从物理设备的使用角度来考虑的，集中会
带来管理方便和效率的提高，分散看起来分散了物理设备故障带来的风险。但
我认为并不尽然，我们的非功能性业务目标一般有提高效率目标和实现客户需
求的可用性目标两方面。集中虚拟化毋庸置疑能够提高效率，而良好的可用性
管理也可以实现在集中虚拟化环境下的业务可用性目标，例如业务系统的可用
性架构、物理设备的配置使用策略、恢复管理等等都影响着是否能达到客户需
求目标。同时，集中虚拟化后，我们可以用更经济更有效的手段来协助可用性
管理。因此，我认为我们需要从业务目标出发，通过可用性管理来实现可用性
目标，物理设备集中化只是其中的一个因素，需要考虑但并非一个硬的限制。
【观点五】民主还是集权，永恒的话题。鸡蛋到底是放在一个篮子里？还是多
放几个篮子？真的很难选择，但是在虚拟化云时代，集中化、虚拟化、资源池
和弹性动态伸缩等都成为其代名词。但是我们也有担忧，也有忧虑，比如说
SVC虚拟化，之前主机访问各自存储，分门别类，部分主机访问高端存储，部
分主机访问中端存储，部分主机访问低端存储，SVC虚拟化上了之后，所有异
构、高中低端存储均挂在至SVC，被SVC管理，再通过SVC虚拟化成VDISK，映
射给所有主机使用，鸡蛋基本全在一个篮子里了，SVC集权后，核心地位无可
比拟。而且在私有云建设当中，存储挂载至SVC并不是通过IMAGE模式（透穿
模式），而是manage模式，说白了这种模式下存储全是SVC的LUN资源，SVC
再在这些LUN资源上再虚拟化一层，再映射给主机使用，在这种模式下，主机
只能识别SVC的vdisk,存储的上的卷已经完全无法单独供主机使用，这也是一
种集权，地位又提升一大截，风险提升了。再比如说资源池，之前主机分散至
不同的物理机中，为了动态弹性伸缩扩展，为了快速部署，快速迭代等，一台
物理机资源容量越来越大，放置多个主机在一台物理机中，主机不再拥有自己
的I/O卡，主机不再拥有自己的硬盘，所有的网络访问和I/O访问均需要通过
虚拟I/O主机进行，主机拥有的只不过是其他主机虚拟化之后的产物，这台物
理机也是一种集权，地位也提升了，风险也提升了；再比如说GPFS共享文件系
统，利用该软件搭建应用系统，可以在应用端实现应用读写双活。但是GPFS软
件将主机识别的盘格式化了，成了GPFS本身拥有的NSD格式盘，不属于该
GPFS集群架构的主机，是无法识别NSD格式盘的，该数据盘脱离GPFS软件、
脱离GPFS集群架构的主机也无法单独使用，这也是一种集权。
以上种种情况说明，我们的企业在构建双活数据中心、私有云平台的过程中，
是不断集权过程，不断提升了便利性、灵活性和高可用性同时，也提升了集权
者的地位，加剧了风险。为了防范风险，SVC版本不断更新，增加新的功能，
新的理念，新的架构，渐渐的有了SVCLocalVDM来防范存储单点风险，有了
SVCStretchedCluster来防范站点风险，有了SVCHyperSWAP来防范站点单
SVC节点风险，同时缔造了基于存储虚拟化方案的SVC双活架构方案；为了防
范主机过于集中的风险，我们不断利用软件层的双活方案和可靠性方案，如
WAS集群、TSA+GPFS、HACMP、DB2HADR+TSA等等，主机端利用动态迁移、
vmotion等技术共同来缓解主机的集中风险压力，并不断提高资源池高可用，
不断提高资源池网络及存储I/O性能等；为了防范GPFS的风险，我们将GPFS
NSD数据盘通过SVCPPRC复制至灾备，并在灾备端新增了GPFS集群主机，加
固该架构的冗余性和可靠性，减轻了GPFSNSD格式化后的风险压力。
可以预见的是，随着资源池不断云化，主机不断集中化，虚拟化技术不断叠
加，技术不断更新，我们的高可用理念和双活架构不断更新，集中还是民主这
个话题会被渐渐遗忘，在集中化中民主，在民主化中集中。
五、SVC同城容灾与异地容灾方面
【问题1】
【疑问一】双活数据中心+灾备模式的方案有哪些可以落地的？
假如客户没有异构存储需求的前提下，需要在同城建设基于存储的双活以及在
异地还要做远程存储复制，IBM除了DS8000(成本较高）以外，还有可选方案
吗?
【问题解答一】如果没有异构存储，可以通过存储自身的镜像软件来实现，也
可以通过系统的lvm方式来实现，或者如果客户采用了gpfs那就更好了
【疑问二】相关厂商存储本身就能实现，无需GPFS之类的；而且只是要求存储
实现，不要求通过数据库实现，好像IBM的方案不多吧。没有虚拟化的要求，
为何提供SVC或VPLEX呀？
【问题解答二】高端存储DS8000系列+hyperswap+GM实现要求，排除DS800系
列的话，可以结合存储数据级容灾和软件层应用双活来实现你的要求，如
MM+GM实现数据级同城容灾和异地灾备，应用双活可以用应用负载+GPFS或者应
用负载+WAS集群等实现，数据库双活可以用GPFS+ORACLERAC或者DB2
PURESCALE+GPFS等，数据库异地可以用DB2HADR或者ORACLEDG
【问题解答三】除去软件层的解决方案、存储虚拟化的解决方案，这种存储的
双活+异地只能是高端存储了，IBM不就是DS8000系列高端吗，那么只能是通
过DS8000+HYPERSWAP实现同城双活，但是既然是用了HYPERSWAP，就无法用存
储实现容灾了，只能又配合软件层的方案实现异地了。其他存储厂商高端系列
估计也有方案，接触不多。
【问题2】
【疑问】灾备系统建设在满足监管要求的RTO、TPO外，有哪几种建设方式的初
期成本投入最少？
【问题解答】这个问题比较泛，要看你现有的架构和设备情况，还要考虑你的
可靠性、性能、扩展等要求。
最小投入的话，那么只能实现数据级灾备。
1.用备份的方式可能会最少投入，如将生产数据库、操作系统、文件通过备份
至存储中，然后用异步的方式传输至灾备中心，比如说NAS与NAS间IP异步传
输的方式。这个可以是初步的方式。但是RPO和RTO可能是达不到要求的，因
为要采用备份恢复的方式，数据必然存在丢失，恢复时间也有点长。
2.要么是用存储的异步复制方式（需要看存储型号，还有LICENSE等）
3.要么就上SVC，将本地的异构存储整合，再利用本地SVC与灾备的
V5000/V7000/SVC采用异步复制的方式
4.上SVC与SVC间的PPRC实时同步方式，实现所有异构存储的数据级同步方
式。
5.假定只实现数据库级灾备，在灾备买个存储和主机，如ORACLE可以用
ORACLEDG，DB2可以用HADR等实现。
个人建议和想法，供参考。
【问题3】
【疑问】如何利用svc进行异地容灾建设？
目前，数据中心内包括EMC、DELL、IBM等厂家存储，用于不同的生产系统，每
套生产系统都是独立的SAN架构网络。如果采用SVC进行异地容灾建设，对于
数据中心现有系统架构岂不是改动很大，并且系统还需要停机时间对吧。对于
这种情况，方案应该怎样设计才能使得数据中心内现有架构改动最小，除了利
用svc还有其他解决办法吗？
【问题解答】1.用SVC等存储虚拟化方案是改动最小的方案，用其他方案更复
杂，要么用存储的异地复制功能（可能还需要买专门的LICENSE），要么用CDP
先进行架构改造，再用本地和异地两套CDP的异地复制功能实现，有的存储型
号可能还不能都实现异地灾备。
2.用SVC等存储虚拟化方案对以后架构的提升最明显的方案，对你企业架构云
化转型最便捷的方案，新购两台SAN交换机，再利用SVC整合全部的异构存
储，利用两地的SVC与SVC进行异步复制，或者用本地的SVC与异地的V7000
等进行异步复制，均能实现异地灾备。
3.无论你采用哪种方案，停机肯定是要的，用SVC改造的方式你可以理解为：
改造前为：各异构存储---->HOST
改造后为：各异构存储---->SVC---->HOST，中间只不过是加了一道SVC而已，
改造后你之前所有的不同SAN网络也进行了统一整合，整个架构清晰明了。
【问题4】
【疑问】云技术和云服务越来越普遍，灾备如何结合云及传统的方式进行实
施，既保证安全便捷又节省初期费用投入？
【问题解答】云架构下无非这么几种：
云资源：
1.软件定义网络：目前来说，有点困难，难以落地，看今后技术进步。
2.软件定义计算节点：POWERVM，VMWARE，KVM。
3.软件定义存储：SVC和VPLEX为代表。
4.软件定义存储+计算节点：超融合架构。
云管理：
POWERVC，ICM，ICO，VCENTER，统一监控，统一备份，统一流管，自动化投产
等
灾备要落地云，可参考上面的技术实施。
六、私有云建设与双活建设架构、案例方面
【议题1】双活数据中心复杂性也大大提升，有无必要？难点在哪？复杂性在
哪？适用哪些企业？
双活数据中心进一步提升了业务系统的RPO和RTO，提升了双中心资源利用
率，但相应地系统复杂性也大大提升，有无必要？难点在哪？复杂性在哪？适
用哪些企业？
【观点1】双活的难点不是有一个厂商的技术产品就能完成的，往往需要太多
技术的协同配合完成，这就会造成了技术兼容性成熟度的考验。既然不是一个
技术，那就会增加管理和运维的难度，对于一些IT技术力量的不足的企业，遇
到问题，往往会很棘手，毕竟双活的数据中心本身，需要业务，IT，多部门联
合才能更好地完成的,如何问题如何应急，在完美的双活都很难尽善尽美，最终
还是要靠人去处理那些技术本身无法处理的问题。
【观点2】数据大集成项目（包含物理链路，硬件，系统，存储，甚至软
件），难度很高。
1、重点是网络架构设计，也是难点，因为网络的架构设计合理，可以减少延
迟，抖动等。
2、很有必要
3、大企业都有这个需求吧，只是看投入大小，金融行业，国庆扛得住，民企就
选择性了，比如重要业务可以做，非重要业务备份即可。
现在还一个好处就是公有云可以减少一定的成本，形成双中心或者多中心。
【议题2】双活数据中心资源池中包括各类异构的存储、各类异构的X86服务
器，各类异构的Power服务器，资源池，不同的虚拟化实现技术，那么如何分
门别类统一进行资源池管理，跨中心的资源池又该如何统一管理呢，希望各专
家提出自己的独特见解！
【观点1】目前来说采用最多的还是虚拟化技术，存储通过svc或者emcvplex
实现，主机一般采用vmvare或者powervm来实现
【观点2】vmware做类是项目比较多
近两年流行的超融合技术也可以。
【问题1】
【疑问一】能给出几个双活数据中心部署架构图吗？
【问题解答】给几个应用双活的吧
统一私有云平台：
MQ灾备+JAVA应用双活：
JAVA应用双活：
WAS应用双活：
【疑问二】看得出来，都离不开负载均衡，这些负载均衡是按什么分类的呢？
【问题解答】对，应用双活，负载均衡少不了的，按网络安全分区分类的
【问题2】
【疑问】
双活可以有应用级双活和数据库级双活，目前有没有数据库级双活的银行应用
案例？对于两地三中心的建设环境下，如何进行双活建设呢？
【问题解答】1.据我所知，数据库双活还是有案例的
如前几年的山东移动的GPFS+ORACLERAC双活
还有民生银行和交行的DB2PURESCALE+GPFS双活
2.如果是两地三中心的话，基于SVC的的方案，HYPRESWAP是不能用的，只能
用SVCStretchCluster实现同城存储层的双活，再加SVCGM实现异地灾备，
或者用SVCLOCALVDM+SVCPPRC+SVCGM实现本地双存储高可用+同城灾备数据
级灾备+异地灾备，同城应用双活只能用软件层的双活架构，如应用负载+GPFS
跨中心双活，应用负载+跨中心WAS集群等等，数据库的话DB2PURESCALE很不
错。
-全文完-