摘要:包括具体行业、具体场景及解决方案特点
由于全球海啸、龙卷风、地震等自然灾害,以及恐怖主义、网络攻击等的不断升级,企业对业务连续性管理的要求越来越高!如何通过灾备保证系统安全及业务连续性成为企业关注的重点,而双活数据中心则是热门的解决方案。真正的双活,要在数据中心的从上到下各个层面,都要实现双活。存储、服务器、网络、数据库、应用,各层面都要有双活的设计,这样才能真正意义上实现数据中心层面的双活。
灾备技术涉及的领域很多,有很多厂商提供了多种技术解决方案,当前比较常见的数据复制技术有几大类,例如基于传统存储的复制技术,技术数据库的复制技术,基于存储虚拟化网关的复制技术,基于主机卷管理的复制技术,基于备份的复制技术等等。
关于传统存储复制的痛点,大家主要关心如下几个方面:
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.准备工作
序号 准备工作 实施人 完成状态 计划完成时间
3)选择更新系统
4)先进行测试
5)用升级目标微码验证测试
6)测试通过后再进行测试并更新
4.Local Hyper Swap实施方案
4.1 SVC规划
4.1.1网络配置
序号 设备名称 安装微码 管理IP
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系统自动完成的,用户无需干预。
方案实施已顺利完成,整个过程完全在线实施,系统没有影响。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞8
添加新评论3 条评论
2018-12-18 14:25
2017-11-10 14:02
2017-11-06 19:20