作者mxin·2017-11-06 09:54

资深工程师·上海宝信软件股份有限公司

某证券公司存储双活扩容方案

字数 11081阅读 6658评论 3赞 8

摘要：包括具体行业、具体场景及解决方案特点
由于全球海啸、龙卷风、地震等自然灾害，以及恐怖主义、网络攻击等的不断升级，企业对业务连续性管理的要求越来越高！如何通过灾备保证系统安全及业务连续性成为企业关注的重点，而双活数据中心则是热门的解决方案。真正的双活，要在数据中心的从上到下各个层面，都要实现双活。存储、服务器、网络、数据库、应用，各层面都要有双活的设计，这样才能真正意义上实现数据中心层面的双活。
灾备技术涉及的领域很多，有很多厂商提供了多种技术解决方案，当前比较常见的数据复制技术有几大类，例如基于传统存储的复制技术，技术数据库的复制技术，基于存储虚拟化网关的复制技术，基于主机卷管理的复制技术，基于备份的复制技术等等。
关于传统存储复制的痛点，大家主要关心如下几个方面：
1. 生产中心与同城灾备中心采用同步复制遇见的痛点
2. 存储复制中的复制链路上的痛点。
3. 存储和主机密切相关的多路径软件的痛点
4. 基于存储复制技术的两地三中心解决方案的痛点
5. 双活数据中心中仲裁技术的痛点
6. 数据复制所带来的数据完整性，一致性的痛点
7. 数据复制的安全性的痛点
8. 灾难恢复演练中关心的问题

1.背景描述：包括具体行业、具体业务场景现状及面临的存储问题和挑战（不少于500字）
某证券核心交易系统现状
某证券公司核心交易系统存储平台前期项目通过SVC存储虚拟化网关已进行了池化整合。除老综合业务系统IBM ESS800由于太老（微码不兼容）无法接入，其他存储均通过SVC进行管理。SVC存储虚拟化之后提高了存储可用性、可维护性，但随着而来SVC也成为了整个存储平台的关键节点。本项目通过增加SVC节点提高其高可用性及性能。
现有主机系统存储平台连接示意图如下：

现有SVC型号为2145-CG8，微码版本为7.1.0.5。SVC两个节点组成一个I/O GROUP的集群，两个节点双活，对于vdisk来讲为主备，任意节点故障会自动完成切换，切换时间小于10秒。

2解决方案：包括使用的技术决策、技术方案和关键技术（不少于2000字）
2.1 SVC Hyperswap技术介绍
说到HyperSwap技术，在没有SVC存储虚拟化方案之前，HyperSwap技术主要用于IBM高端DS8000系列存储当中，达到应用和存储的高可用和双活需求，但是当时DS8000系列存储成本高昂，适用于核心类或者关键类应用的跨站点双活需求，不利于整体性的双活数据中心规划和建设，更别谈异构存储的跨中心双活建设了。但到了SVC 7.5版本，SVC和V7000都可以支持HyperSwap技术了，中端存储的地位瞬间提升了一个档次，异构的各类中端存储，结合SVC HyperSwap，都可以实现跨中心的双活高可用了，那么究竟SVC HyperSwap是什么技术？先来看看下面这张官方架构图：

从图中可以看到的是，先从架构上：
SVC HyperSwap采用了hyperswap的拓扑架构，最少需要两个I/O Group，同一I/O Group需要两个节点，并在同一个站点，而且很惊喜的发现，每个站点均有VDISK，主机映射了四个SVC节点，存储路径更多了，冗余性更高了。
而SVC Stretched cluster采用的是stretched的拓扑架构，一个站点一个SVC节点，最大可达4个I/O Group，但是同一I/O Group的两个节点被分割到两个站点。两个站点的存储通过SVC虚拟化后只有一个VDISK，主机还只是映射两个SVC节点。
再从性能上：
SVC HyperSwap利用了更多的资源（包括SVC节点，线路和SAN交换机端口等），每个站点均含有完全独立的SVC读写缓存，一个站点失效，另一站点也能提供完全的性能，因为读写缓存在一站点失效后，不会被DISABLE，两个站点的读写缓存是独立的两套，这点特别重要。
而SVC Stretched cluster占用了相对较少资源，能提供更多的VDISK（同一SVC I/O Group VDISK划分有上限），但是当一站点SVC节点失效后，另一站点的读写缓存会被DISABLE，进入写直通模式，性能相对来说会下降，在某些情况下，比如后端存储性能不够强，缓存不够大等。而且主机的存储访问路径会减少一半。
另外一个主要不同点是，SVC HyperSwap有了Volume Groups这样概念，它能够将多个VDISK组合，共同保持高可用和数据的一致性，这对于需要映射多个VDISK的主机来说会有很大帮助，假设以下场景（主机映射多个VDISK）：
1、站点2失效。
2、应用仍然从站点1进行读写，只在站点1进行数据更新。
3、站点2恢复。
4、站点1的VDISK开始同步至站点2的VDISK
5、站点1在VDISK同步时突然失效。
如果主机的多个VDISK没有配置Volume Groups，主机将很大可能无法通过站点2的数据恢复业务，因为站点2的多个VDISK正在被同步，尚未同步完成，它们的数据并不在同一时间点，挂在起来无法使用，那么这样的话只能寄希望于站点1。
但是如果主机的多个VDISK配置成Volume Groups，主机是能通过站点2的数据进行恢复的，虽然数据尚未同步完成，但多个VDISK间的数据一致性是可以保证的，仍然属于可用状态，只不过数据不完全而已。
与SVC Stretched cluster类似的是，SVC HyperSwap中的主机、SVC节点和存储均被赋予了站点属性，同时也需要配备第三站点作为防范脑裂的仲裁站点。
接着看下面这张图：

可以看见，一个hyperswap卷是由以下几个部分组成：
1、4个VDISK（可以是THICK/THIN/COMPRESSED,也可以被加密）
2、1个ACTIVE-ACTIVE的REMOTE COPY RELATIONSHIP（系统自己控制）
3、4个FLASH COPY MAPS（FOR CHANGE VOLUMES）（系统自己控制）
4、额外的ACCESS IOGROUP（方便IO GROUP FAILOVER）
另外，在hyperswap的卷复制ACTIVE-ACTIVE关系中，我们可以看到依然存在MASTER或者AUX的标签，对于主机来说，两个站点的其中一个I/O Group的VDISK是作为PRIMARY，提供读写，所有读写请求必须经过该I/O Group，然而hyperswap会自动决定是本站点的I/O Group的VDISK作为PRIMARY，还是主要承担I/O流量的I/O Group的VDISK作为PRIMARY。在首次创建hyperswap卷和初始化后，被标签为MASTER的VDISK作为PRIMARY，但是如果连续10分钟以上主要I/O流量是被AUX的VDISK承担，那么系统将会转换这种MASTER和AUX的关系，从这点上也可以看出与SVC Stretched cluster的不同，虽然SVC节点一样被赋予站点属性，但SVC hyperswap在另一站点仍然活动时，不局限于只从本地站点读写，它会考量最优存储访问I/O流量，从而保持整个过程中主机存储读写性能。另外需要注意的是主要的I/O流量是指扇区的数量而不是I/O数量，并且需要连续10分钟75%以上，这样可以避免频繁的主从切换。
上面讲了这么多，那么SVC hyperswap的读写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。
4、SVC节点1、3、4回复节点2的响应。
5、两个站点的SVC节点分别将缓存写入各自站点的存储当中。
2.2具体项目SVC升级扩容概述
 新增SVC型号为2145-DH8，微码版本为7.5.0.1。扩容SVC集群变成四个节点后要达到提高可用性及同时提高部分性能的要求，则需采用SVC Local Hyper Swap集群模式构建。普通的分裂式集群只在同一个I/O组的两个节点间确保高可用性，无法跨I/O组确保高可用性，意味着如果一个I/O组的两个节点同时故障的华，挂在这个I/O组上的卷将无法提供存储服务，也无法在I/O组故障的情况下切换到别的I/O组。通过实验室的两台2145-CF8与新增两台2145-DH8构建的Local Hyper Swap集群环境验证测试，采用SVC 的Local Hyper Swap集群模式可确保SVC集群高可用性，具体验证内容如下：
（1）同一个I/O组两个节点故障后自动切换，切换时间小于10秒。
（2）不同I/O组间，在一个I/O组的两个节点都故障的情况下自动切换，切换时间约20秒。
（3）四个节点的三个节点故障情况下仍可用。
（4）四个节点任意两个节点正常的情况，集群可以启动。
SVC Local Hyper Swap集群架构及工作原理如下：
SVC Local Hyper Swap集群架构读I/O示意图：

读I/O在各站点就近读取。
SVC Local Hyper Swap集群架构写I/O示意图：

SVC升级扩容主要步骤：
（1）两套SVC均升级到次新微码7.7.1.6。
（2）调整SAN网络ZONE配置。
（3）将新SVC加入老SVC集群。
（4）映射V7000、F900新增存储到SVC集群存储分别构建存储资源池v7K_B_pool1,v7K_B_pool1,FS900A_pool,FS900B_pool。
（5）修改SVC集群架构为Local Hpyer Swap架构，修改存储池属性V7000a_pool1(SITE1),V7000b_pool1(SITE2)，F900A_pool1((SITE1)，F900_pool1((SITE2)。
（6）调整普通卷为hyperswap卷。
（7）主机端cfgmgr扫描设备路径新增，lspath、pcmpath query devcie确认多路径。

SVC升级扩容后存储平台逻辑架构：

上图为构建某证券公司存储平台的主要设备，也是本次实施相关的设备，后续某证券公司将逐步淘汰老的设备并将存储数据迁移到此平台。黄色设备为现有设备，蓝色设备为新增设备，黄色线需要修改的连线，黑色线保持不变，蓝色线为新增。

1.准备工作
序号	准备工作	实施人	完成状态	计划完成时间
1.	新SVC设备上架，上电；                                                                       	李霞	完成	
2.	光纤连接；管理网线连接；                                                                      	李霞	完成	
3.	SVC管理IP配置，并完成初始化	李霞	完成	
4.	SVC升级微码下载，7.4.0.11，7.7.1.6 ； 	辛旻	完成	
5.	确认光纤交换机划分正确的zone ；                                	王戎		9.15
6.	新的SVCfirmware从7.5.0。1升级到7.7.1.6                                	辛旻	完成	
7.	SVC Local Hpyer Swap集群验证测试   	辛旻	完成	
8.	老SVC里的压缩卷，通过镜像方式解除。  	李霞		升级前
9.	排查SVC里的错误，全部修复，升级前全部完成。	李霞		升级前
10.	SVC 配置文件备份  	辛旻		升级前
1.	调整SAN网络ZONE配置。                                                                      	王戎		升级前
11.	运行环境所有LUN与V7000新划分的LUN组成VGmirror,以便在升级失败后由V7000直接提供服务。 并将quorun数字设置为1。 	辛旻、李霞、王戎		升级前
12.	运行环境、测试环境完成整体备份工作（包括操作系统、数据库、中间件、通讯软件）	辛旻、李霞、王戎		升级前
2.实施主要步骤列表
序号	实施工作	实施人	是否停机	停机时间
1.	切换保驾（运维对口相关人员）                                                                      	周蓉（运维经理）；李霞、王戎（二线）；沃春峰（一线）；宝信调度	否	
2.	老的SVC微码升级，需要分两段升级，7.4.0.11，7.7.1.6                                                                      	辛旻	否	
3.	调整SAN网络ZONE配置。                                                                      	王戎	否	
4.	新SVC加入原来SVC集群	辛旻	否	
5.	配置hyperswap架构 	辛旻	否	
6.	修改原来的卷为hyperswap卷                                	辛旻、李霞、王戎	否	
7.	主机检查确认                              	李霞、王戎	否	
8.	应用验证确认                              	业务方	否	
3.SVC微码升级步骤
1)登陆SVC
2)进入SVC系统界面

3)选择更新系统

4)先进行测试

5)用升级目标微码验证测试

6)测试通过后再进行测试并更新

4.Local Hyper Swap实施方案
4.1 SVC规划
4.1.1网络配置
序号	设备名称	安装微码	管理IP
1.	2145-CG8(老SVC)	7.1.0.5-> 7.4.0.11->
7.7.1.6	Node1：192.168.11.2
Node2：192.168.11.3
管理地址：192.168.11.1(在四节点之间漂移)
2.	2145-DH8(新SVC)	7.7.1.6	Node3：192.168.11.72
Node4：192.168.11.73
管理地址：1192.168.11.1
4.1.2存储池规划设计
V7000扩容的磁盘容量，按照每个vdisk为500GB分别映射给SVC组成低速存储池v7K_B_pool1,v7K_B_pool1。
F900的磁盘容量，按照每个vdisk为500GB分别映射给SVC组成高速存储池FS900A_pool,FS900B_pool。
Pool Name	Mdisk Name	受管存储	用途
v7K_A_pool1	v7K_B_01
v7K_B_02
v7K_B_03
v7K_B_04
v7K_B_05
v7K_B_06
v7K_B_07
v7K_B_08
v7K_B_09
v7K_B_10	V7000A：
（1）新增24块900GB盘
（2）新增v7000A_pool，3个mdisk（8+8+7），raid5,1hotsphere
（3）可用容量约17T	低速存储池，用于开发测试、应用服务等低I/O需求的服务
v7K_B_pool1	v7K_B_01
v7K_B_02
v7K_B_03
v7K_B_04
v7K_B_05
v7K_B_06
v7K_B_07
v7K_B_08
v7K_B_09
v7K_B_10	V7000B：
（1）新增24块900GB盘
（2）新增v7000A_pool，3个mdisk（8+8+7），raid5,1hotsphere
（3）可用容量约17T	低速存储池，用于开发测试、应用服务等低I/O需求的服务
FS900A_pool	F900A_01
F900A_02
F900A_03
F900A_04
F900A_05
F900A_06
F900A_07
F900A_08
F900A_09
F900A_10	F900A：
可用容量约17T	高速存储池，用于数据库服务等高I/O需求的服务
FS900B_pool	F900B_01
F900B_02
F900B_03
F900B_04
F900B_05
F900B_06
F900B_07
F900B_08
F900B_09
F900B_10	F900B：
可用容量约17T	高速存储池，用于数据库服务等高I/O需求的服务

4.1.3光纤交换机规划设计
光纤交换机管理IP地址
交换机名	管理IP地址	备注
F48A	192.168.11.4	现有
F48B	192.168.11.5	现有
F96A	192.168.11.14	新增
F96B	192.168.11.15	新增
zone配置规则
SVC环境中需配置三种类型的zone，分别如下：
（1）SVC节点间通讯zone:按照本方案SAN连接方式，F48A,F48B,F96A,F96B四台SAN交换机上分别接入了SVC的四个节点，每个节点上的四个主机端口口分别接入四台SAN交换机。则zone的划分方法为每台SAN交换机划一个内部连接ZONE,如第一个SAN交换机：SVC_INTERNAL(SVC_NODE1_PORT1,SVC_NODE2_PORT1,SVC_NODE3_PORT1,SVC_NODE4_PORT1)
（2）存储到SVC间zone:主要存储V7000A,V7000B,F900A,F900B每台两个控制器，每个控制器上有四个主机端口分别连接四台SAN交换机。则zone的划分方法为每个阵列控制器在一台SAN交换机上划一个zone,如第一个SAN交换机：SVC_V7000A_C1_P1(V7000A_C1_P1,SVC_NODE1_PORT1,SVC_NODE2_PORT1,SVC_NODE3_PORT1,SVC_NODE4_PORT1)
（3）SVC到主机间zone:每个分区到SVC至少有2块HBA卡，分别连接到一对F48或一对F96 SAN交换机上，则要划分至少2个zone,如第一个SAN交换机：HOSTNAME_PORT1(HOSTNAME_FCS0,SVC_NODE1_PORT1,SVC_NODE2_PORT1,SVC_NODE3_PORT1,SVC_NODE4_PORT1)
4.2 Local Hyper Swap topology规划
4.2.1 sites配置
cluster_name:Cluster_MEIG
site1(老SVC):I/O GRP0
Node1：192.168.11.2
Node2：192.168.11.3
管理地址：192.168.11.1
site2(新SVC):I/O GRP1
Node3：192.168.11.72
Node4：192.168.11.73
仲裁:ip_quorum01（位于x86虚拟化平台上）
192.168.16.159
4.2.2 nodes配置
site1：
node1、node2/IO GROUP0

site2：
node3、node4/IO GROUP1

4.2.3 topology模式配置
topology: hyperswap
4.3.4 quorum配置
从SVC下载日志的地方（设置-支持）下载ip_quorum.jar文件到quorum01上。
4.3 Local Hyper Swap配置
4.3.1 SVC初始化后配置
4.3.1.1 site配置
通过笔记本连接网线到SVC管理口，默认ip:192.168.11.1
用户名：superuser,
密码：passw0rd

登陆

点击中间空白框，添加新加的SVC节点

完成

关闭

普通集群配置完成后的状态，可以看到有两个I/O GROUP。

4.3.1.2 配置hyperswap topology架构
1、选择操作，然后”修改系统拓扑”

2、下一步

3、分配站点名称

4、分配站点

5、将主机分配到站点

6、将主机分配到站点，可通过操作修改默认站点配置

7、将外部存储分配到站点

8、设置站点之间的带宽

9、摘要

10、点完成，完成hpperswap集群配置

11、配置完成集群状态图

4.3.1.3配置quorum服务器
1、设置标签，点“系统”

2、在IP定额标签，下载IPv4应用程序

IP定额配置说明

3、点击下载IPv4应用程序后，将自动运行生成ip_quorum.jar

4、在本地选择目录保持ip_quorum.jar
5、在quorum服务器(Redhat Enterprise server Linux6.5/7或Suse linux Enterprise server11m3/12)上安装java（推荐版本7.1或8）
6、在quorum服务器上运行   nohup java -jar ip_quorum.jar &
4.3.2磁盘划分步骤
4.3.2.1登录系统
    启动浏览器，输入SVC集群管理IP地址192.168.11.1,输入系统管理员的用户名和密码。
4.3.2.2新建POOL信息
SVC受管V7000A:
V7000a_pool1
SVC受管V7000B
V7000b_pool1
SVC受管F900A:
F900A_pool1
SVC受管F900B:
F900B_pool1
4.3.3.3划分MDisk并分配到存储池

1.外部存储划分vdisk并映射给SVC
2.选择左侧菜单“池”=>“外部部存储器”,打开存储器配置界面。

3.按照规划，将相应外部盘分配给存储池

4.3.3创建主机映射
4.3.3.1创建主机 
1.在左侧菜单中选择“主机”。

2.选择左上角的“添加主机”，在跳出的窗口中选择“光纤通道”，填写“名称”，“站点”“主机端口”，确认后点“添加”。

2.重复步骤，直到所有添加完所有主机。

4.3.4创建hyperswap卷并映射给主机
4.3.4.1创建卷
1.在左侧菜单中选择“卷”，进入卷配置界面。

2.点击左上角“创建卷”，在跳出的窗口中选择“Hyperswap”，然后选择希望提供卷的存储池。

输入“容量”与“名称”

3.填写卷名称后点击“创建”按钮创建卷。

自动完成格式化

4.右键点击已创建的卷，选择“映射到主机”，在跳出的窗口中选择希望映射的主机，并点击“映射卷”，卷映射完成。

4.3.4.2修改基本卷为hyperswap卷
选中需要修改的普通卷，点击右键，选择“添加拷贝”

SVC自动建议选择对应站点的存储池，确认正确，点击“添加”，如下：

自动完成同步：

4.3.5配置完成后页面如下
pool信息：

卷信息：（空间划分需预留5%的容量保存双活切换日志）

MDISK信息：

主机映射关系：

flashcopy：

一致性组：

flashcopy映射：

远程copy：

伙伴关系（local）：

1.2.3.4.5.5.紧急预案

故障内容	紧急预案	预计时间
老SVC（7.1.0.5-> 7.4.0.11）微码升级第一阶段故障	svc升级微码第一阶段仅先复制微码，仍以老微码运行，升级失败自动回退并重新启动	节点存储服务恢复时间20分钟,系统不宕机。
老SVC（7.1.0.5-> 7.4.0.11）微码升级第二阶段故障	svc升级微码第二阶段需应用新微码并做fast_reset，此时发送故障的概率较小，若发生了故障，则由镜像的V7000的卷提供服务，，期间存在I/O切换，而镜像超时默认15分钟，并且无法在线修改，因此在机器负荷高的情况下可能需要重启，SVC重装老版本微码，并要用备份的svcconfig文件恢复配置。	预留1-2小时应急处理时间
老SVC（7.4.0.11->
7.7.1.6）微码升级第一阶段故障	svc升级微码第一阶段仅先复制微码，仍以老微码运行，升级失败自动回退并重新启动	节点存储服务恢复时间20分钟。
老SVC（7.4.0.11->
7.7.1.6）微码升级第二阶段故障	svc升级微码第二阶段需应用新微码并做fast_reset，此时发送故障的概率较小，若发生了故障，则由镜像的V7000的卷提供服务，期间存在I/O切换，而镜像超时默认15分钟，并且无法在线修改，因此在机器负荷高的情况下可能需要重启，SVC重装老版本微码，并要用备份的svcconfig文件恢复配置。	预留1-2小时应急处理时间
6.升级扩容后
1、删除各MES运行系统通过V7000阵列映射的LUN镜像盘。
2、清理V7000阵列上的无用LUN。
7.注意事项
1、为控制升级风险，甲方协调重要系统定修时间进行在线升级操作。
2、SVC通过在线进行升级扩容，通过两级紧急预案确保系统平滑升级，当出现最坏情况即SVC两个节点升级时均出现故障，这时候需要又镜像V7000的卷提供服务，由于操作系统的镜像盘默认部分超时参数15分钟而又无法在线修改，因此在I/O写比较繁忙的情况，部分系统将在切换过程中由于超时太长无法使用，需要重启。甲方考虑协调1-2小时应急处理时间，以备突发事件发生。

总结：解决方案亮点和行业可参考性（不少于500字）
本方案基于该SVC hyperswap卷技术，实现了两个站点VDISK的ACTIVE-ACTIVE。站点1的MASTER VDISK写入变化时，被写入站点1的Change Volume中（基于FLASH COPY，变化数据写入快照目标卷，原卷数据不变）,站点2的AUX DISK写入变化时，同样被写入站点2的Change Volume中。一段时间后，系统自动停止VDISK与Change Volume间的快照关系，Change Volume将回写变化数据至VDISK，VDISK将通过SVC PPRC（REMOTE COPY）同步变化数据至另一站点的VDISK中，之后，站点VDISK又将重新与Change Volume建立快照关系，与根据这一原理，不断往返变化数据，保持四份COPY数据的同步的关系，当然这些都是SVC hyperswap系统自动完成的，用户无需干预。
方案实施已顺利完成，整个过程完全在线实施，系统没有影响。

SVC hyperswap 双活软件定义存储

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！