我在一场跑批慢的恩怨纷争中学会了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进行原存储IBMDS5100和IBM V7000存储的虚拟化整合后，本地存储资源的管理将更加简单、有效，系统将具有更高的性能和更高的可靠性。
此处需要提醒一下：
由于SVC是基于SAN的虚拟化解决方案，那么实现SVC虚拟化的环境，必须满足如下几个前提条件：
•具备SAN网络；
•交换机具备足够的端口数；
•主机设备、操作系统、SAN光纤交换机以及存储设备必须在SVC支持兼容列表中。

东西是好东西，可规划不好，好东西未必发挥价值喔。美好的愿望必须落地了后才可以找到真正的幸福感！文中看到了这里的同志是否有同感？
先看看俺们的SVC配置需求

（1）微码需求

（2）基本配置定义
                       

（3）IP地址配置（示例）                  

还有这个规划也蛮重要的！

光纤交换机端口规划

SVC加入到SAN环境之后，存储和主机之间的数据访问度需要通过SVC进行，主要包括Host Zone和StorageZone两类，如下图所示：

    后期添加主机访问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 portzones

主机zone配置中，在一个zone中必须包含相似的HBA卡和相似的主机类型。例如AIX和NT服务器必须在各自单独的zone，Qlogic和EmulexHBA卡在单独的zone。

•HBA toSVC port zones

Host的每个HBA port与2个SVC port放在一个zone，这2个SVC port分别来自2个SVC节点。不要将2个以上的SVCport与HBA在一个zone中，因为这样导致超过推荐路径数。

•每个LUN的最大路径数

从SVC节点到主机的路径数不能超过8个，对大多数配置，host到I/O组提供的卷为4个路径就足够了。

•BalancedHost Load across HBA ports

为了获得最佳性能，确保每个主机口与单独的一组SVC口在一个zone中。

•BalancedHost 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端口，从而提高整体带宽的使用率。   

如果前面的你都会了，我还得分享一点血得教训，你该注意的事项：
尽可能用最小数量的路径来满足足够的冗余级别。所有的路径必须使用主机的多路径驱动来管理，假设一个主机连接4个口到SVC，每个卷是8个路径，125个卷映射到这个服务器的话，多路径驱动不得不支持处理1000个活动路径，这样会严重浪费系统性能。

前面的都讲完了，我得给领导总结一下，我们采用了神奇的SVC的目的是什么？
•用来做存储虚拟化，整合行里的存储设备使之方便管理。
•用来做存储之间的复制迁移，用SVC做存储迁移AIX和LINUX系统只需要很短的停机时间，VMware环境可以不停机。
•为以后的容灾做准备，使用VDM可以做到RTO和RPO均为0。

但真正的目的只有一个，让我们跟业务部门之间跑批慢这场纷争早点结束：）

看看我最后上报的总结：其实也说的是实话，没有掺水。

首先是对SVC的看法总结：

第一条：存储虚拟化产品具有通用性强、实施简单的特点，透明地加入原有SAN 环境是SVC的基本功能。

第二条：SVC是整个SAN 网络的控制器，在SAN的分区上，逻辑上主要划分为Host Zone和Disk Zone，从而解除主机与存储设备的紧密耦合。

 第三条：它将整个SAN中的存储设备整合成一个巨大的存储池，可以充分利用所有的存储资源（包含第三方存储设备）并按业务的需求分配存储空间、性能和功能。

我是个技术粉，好东西还需要夸一下，

总结一下，通过SVC可以很方便的将目前的存储设备进行整合，建立统一的灾备管理和资源分配平台，可以按照应用/业务不断变化的需求来动态配置存储。这也是我行上线SVC，通过SVC做存储整合的最终目的。

写完此文，我颇有点感触，我们经常会因为某些问题不解，而陷入到多个部门的恩怨纠纷中，在纠纷中的每一个人都是痛苦的。也许我们做技术的多往前走一步，多看看新东西，多敢于尝试一下，就可以让有些恩怨胎死腹中，我们可以多清闲的喝杯咖啡了：）

仅以此文与同行兄弟们共勉！