我在一场跑批慢的恩怨纷争中学会了SVC划Zone !
作者：
徐睿
某城商行
系统架构师
搞存储的同志们，遇到跑批慢，被业务部门责备过的存储架构师肯定不止我一个人吧，俺行的这场恩怨纷争也来源已久了：）
下面是我行的历史情况：
我行除了核心业务和一些新上线的业务分别跑在DS8000上和V7000上，剩下一些上线时间长的比较重要的二级、三级业务(例如客服呼叫中心、CRM等等)都跑在DS5100上。现在DS5100的压力比较大，业务人员总是抱怨跑批很慢。
早就在AIX专家俱乐部社区中听同行们说过神奇的SVC 可以解决这个问题，所以想上一套SVC用来做存储虚拟化试试，一是用来做DS5100存储到V7000存储之间的数据迁移；二来是为两地三中心的数据复制做准备。
首先给大家谈谈方案设计我们是怎么考虑的。
先大概介绍一下方案：
首先，本项目中采用了IBM的虚拟化存储产品——SAN Volume Controller，这么拽的名字你肯定疑惑是什么？其实它就是大家熟悉的简称为SVC的东东。
买它的目的就是来实现整体的“基础架构”。同时新购一台新存储作为核心业务使用，将原有核心业务迁移至新购存储。
神奇的SVC的工作原理其实理解起来很简单，每一个单位不得多个存储品牌都买点啊，可它可以都管理起来：）
意思就是将原本属于磁盘阵列的系统控制功能集成于SAN网络层次，可以将包括IBM、EMC、SUN、HP、HDS、Dell等不同厂商的磁盘阵列进行统一的系统管理，并以统一的格式展现给不同的主机平台。说到这里，它可以管这么多异构的东东还是挺刺激的！
大家注意看这个地方是亮点之一喔：
此处需要提醒一下：
由于SVC是基于SAN的虚拟化解决方案，那么实现SVC虚拟化的环境，必须满足如下几个前提条件：
• 具备SAN网络；
• 交换机具备足够的端口数；
• 主机设备、操作系统、SAN光纤交换机以及存储设备必须在SVC支持兼容列表中。
东西是好东西，可规划不好，好东西未必发挥价值喔。美好的愿望必须落地了后才可以找到真正的幸福感！文中看到了这里的同志是否有同感？
先看看俺们的SVC配置需求
1） 微码需求
2） 基本配置定义
3） IP地址配置（示例）
还有这个规划也蛮重要的！——
光纤交换机端口规划
SVC加入到SAN环境之后，存储和主机之间的数据访问度需要通过SVC进行，主要包括Host Zone和Storage Zone两类，如下图所示：
后期添加主机访问SVC的存储，则需要根据实际情况划分host到SVC的zone即可。
我又要在这里说个重点啦！
为了保证SVC至SAN网络连接的高可用及冗余性，SAN交换机采用双Fabric架构，SVC共计2个Node，各4个端口，分别连接每个Node的2个节点至两个交换机。SVC每个Node的两个端口分别连接至2个光纤交换机，其中Node1的P1和P3口连接至sw1的两个口，Node2的P1和P3连接至sw1的两个口，其中Node1的P2和P4口连接至sw2的另外两口，Node2的P2和P4口连接至sw2的另外两口。SVC连接拓扑如下：
如果上面是重点，接下来的部分就是我和同事们的心血了：）
请看－》》》光纤交换机Zone规划
首先是SAN设置是这样子的：
在SAN fabric中SVC支持3个interswitch link（ISL），意味着服务器到SVC能跨越5个FC链路，采用长波SFPs的话每个链路可以达到10KM。SVC节点必须采用短波SFPs，因此与SAN交换机距离最大为300m。
为了大家可以更明白，我真是连图都给大家画出来了，够有诚意吧：
关注到这个细节了吗？
如图所示，SVC节点1与host2距离超过40KM。
对于高性能服务器，原则上避免ISL hops，也就是将服务器与SVC连接到相同的SAN交换机。当连接服务器到SVC按照以下规则：
每个I/O组至多256个host，每个集群为1024个
每个I/O组至多512个唯一的主机WWPN号
Host zone配置规则是这样子的：）
同质HBA port zones
主机zone配置中，在一个zone中必须包含相似的HBA卡和相似的主机类型。例如AIX和NT服务器必须在各自单独的zone，Qlogic和Emulex HBA卡在单独的zone。
HBA to SVC port zones
Host的每个HBA port与2个SVC port放在一个zone，这2个SVC port分别来自2个SVC节点。不要将2个以上的SVC port与HBA在一个zone中，因为这样导致超过推荐路径数。
每个LUN的最大路径数
从SVC节点到主机的路径数不能超过8个，对大多数配置，host到I/O组提供的卷为4个路径就足够了。
Balanced Host Load across HBA ports
为了获得最佳性能，确保每个主机口与单独的一组SVC口在一个zone中。
Balanced Host Load across SVC ports
每个SVC口有相同数量的主机口。
我的图大家看明白了吗？
图中每个服务器包含2个单口的HBA，为4路径方案。
每个I/O组均匀的分布主机，每个主机集的主机连接到相同的一组SVC口。
主机集1总是与I/O组2个节点的P1和P4口在一个zone中，主机集2则是与P2和P3口在一个zone中。Port group为每个SVC节点的一个port。
为每个I/O组的port group创建别名
Fabric A：IOGRP0_PG1→NI_P1;N2_P1,IOGRP0_PG2→N1_P3;N2_P3
Fabric B：IOGRP0_PG1→N1_P4;N2_P4,IOGRP0_PG2→N1_P2;N2_P2
用主机WWPN与PG别名来创建主机zone
心血中的绝对亮点出现了！
看当前SVC设置：
根据最佳实践，按如下原则规划host 和SVC和主机的zone
1，在每个交换机上，将一个主机端口和一个SVC IO Group的两个端口划入一个ZONE中。
如上图所示：从Host到strage的四条path如下：
HBA1—Switch1－SVC_N1－Storage
HBA1－Switch1－SVC_N2—Storage
HBA2—Switch2－SVC_N1－Storage
HBA2－Switch2－SVC_N2—Storage
此方案优势是这样子的：
1） 每个硬盘通过一个SVC IOGroup，两个交换机映射到主机，四条路径可以做到充分的冗余和负载均衡。
2）可以避免由于路径过多造成路径切换效率低，响应缓慢，以致业务中断；
3）因为主机比较多，可以将多个主机分摊到各个节点的FC 端口，从而提高整体带宽的使用率。
如果前面的你都会了，我还得分享一点血的教训，你该注意的事项：
前面的都讲完了，我得给领导总结一下，我们采用了神奇的SVC的目的是什么？
• 用来做存储虚拟化，整合行里的存储设备使之方便管理。
• 用来做存储之间的复制迁移，用SVC做存储迁移AIX和LINUX系统只需要很短的停机时间，VMware环境可以不停机。
• 为以后的容灾做准备，使用VDM可以做到RTO和RPO均为0。
但真正的目的只有一个，让我们跟业务部门之间跑批慢这场纷争早点结束：）
看看我最后上报的总结：其实也说的是实话，没有掺水。
首先是对SVC的看法总结：
第一条：存储虚拟化产品具有通用性强、实施简单的特点，透明地加入原有SAN 环境是SVC的基本功能。
第二条：SVC是整个SAN 网络的控制器，在SAN的分区上，逻辑上主要划分为Host Zone和Disk Zone，从而解除主机与存储设备的紧密耦合。
第三条：它将整个SAN中的存储设备整合成一个巨大的存储池，可以充分利用所有的存储资源（包含第三方存储设备）并按业务的需求分配存储空间、性能和功能。
我是个技术粉，好东西还需要夸一下，
总结一下，通过SVC可以很方便的将目前的存储设备进行整合，建立统一的灾备管理和资源分配平台，可以按照应用/业务不断变化的需求来动态配置存储。这也是我行上线SVC，通过SVC做存储整合的最终目的。
写完此文，我颇有点感触，我们经常会因为某些问题不解，而陷入到多个部门的恩怨纠纷中，在纠纷中的每一个人都是痛苦的。也许我们做技术的多往前走一步，多看看新东西，多敢于尝试一下，就可以让有些恩怨胎死腹中，我们可以多清闲的喝杯咖啡了：）
仅以此文与同行兄弟们共勉！
长按下图二维码关注
也可以直接搜索公众号名称“AIX专家俱乐部”或微信号“AIXChina”关注