有人问到了这篇文章中，为什么RAID5写进去是4个IO。认为根据xor算法，只读出来原始数据以及校验数据还不能计算出新的校验数据。其实是可以的。
如，假定就是4块盘
- p=a xor b xor c xor d
再假定
- m=a xor b xor c
那么上式可以简写为
- p=m xor d => m=p xor d
写入新数据d1，读出原始数据p与d
- p1 = m xor d1 = p xor d xor d1
计算完成。
评论 (7)
有人问到了这篇文章中，为什么RAID5写进去是4个IO。认为根据xor算法，只读出来原始数据以及校验数据还不能计算出新的校验数据。其实是可以的。
如，假定就是4块盘
再假定
那么上式可以简写为
写入新数据d1，读出原始数据p与d
计算完成。
随着现在IT技术的飞速发展，信息与数据的快速膨胀，导致信息管理任务越来越重。存储阵列，在现在的企业数据管理中，发挥着举足轻重的作用，而且其技术也在飞速的发展之中，如更大更快的硬盘，更快速的光纤通道，重要的cache技术与算法，方便的IP存储技术，快速的备份与同步方式，更可靠的体系结构，方便的管理功能等等。
不过，它们最主要的一个目的就是，就是消灭信息孤岛，完成信息存储与共享，为了实现这个目的，现在最主要的做法就是信息集中管理与存储，用大型的存储或者设备，或者建立大型的数据中心。其实，除了这些技术以外，还有一个重要的技术，可以解决这个问题，那就是虚拟化，虚拟化也可以分为如下几个方面：
1、虚拟网格存储技术，不再关心存储放在哪里。如光纤技术无疑是现在存储中最成熟，最稳定的技术，但是缺点就是远距离分布比较困难。IP存储解决了随时随地可以存储的问题，但是可靠性与速度还值得进步。如果这两个技术能完美统一，那么存储网格就指日可待了。
2、虚拟扩展技术，不要关心使用什么存储。如现在很多高端存储都推出了这样的产品，典型的就是HDS的USP，可以在主存储后面外挂很多其它的存储，而用户只需要访问主存储即可，根本不用关心其它的存储需要有什么样的访问规则。除了存储之外，该虚拟化也可以在其它地方完成，如光纤交换机上也有类似的解决方案。
3、存储内部虚拟化，不要关心数据保护与分布的细节。如果你知道Oracle的ASM，那么，你就很能明白这种虚拟化是指什么了。通过存储内部的虚拟化，用户可以不用关心RAID怎么做，不用关心数据分布，不用关心数据保护。你的任务就是把磁盘交给它，它帮你搞定一切。
技术1还需要等待，技术2已经存在，但是，大规模的使用还没有看见。技术3，就是我们马上要介绍的HP的eva存储阵列，一款很有个性的中端存储阵列。它在存储端实现了磁盘管理虚拟化，其内部原理跟Oracle ASM简直是一模一样。其宗旨可以这么简单的描述：把磁盘给我，把规则给我，我帮你搞定其它的东西。
1、没有RAID的概念，只需要把磁盘放入一个池(pool)中，磁盘即实现了统一管理。系统自动将所有的数据分布在不同的磁盘上，首先实现类似RAID 0的数据分布。如果想做数据保护，如类似RAID1，RAID5，没有关系，告诉它哪些数据实现怎么样的保护级别，存储自动把镜相数据或者是校验数据分布在不同的磁盘上。
注意，这个raid是逻辑上的，也就是一个磁盘可能有一些数据块是raid1的保护模式，另外一些数据块则是raid5的保护模式。
2、自动增加硬盘，并重新完成数据分布。如果需要增加硬盘，传统的存储需要增加新的raid组，但是，这个新的RAID组想要跟以前的磁盘实现重新分布是比较困难的事情了。EVA类似ASM，新增加的硬盘会自动进行负载均衡，数据会自动分布到新的硬盘上来，不需要人为关注。
netapp通过改良的raid4实现了可以动态的扩充硬盘，并不影响任何性能，其原理可以参考以前的我文章。但是，EVA的做法与netapp的做法还是大不一样的，而与ASM算法一致，它需要一个自动重新分布的过程。不过，EVA这个虚拟化与ASM到底谁早谁晚，我没有去考察，反正天下都是一大抄，只要对用户好就成。
3、没有特定的hot spare。这个不是表示没有hot spare，而是没有特定的hot spare。什么意思呢，就是说，如果现在有60块盘，你指定了4块盘为hot spare，但是系统还是使用60块盘，不过整个空间中，会预留4块盘的空间下来（每个磁盘一部分空间）。如果发生了磁盘损坏，需要接管的时候，只需要把这个磁盘上的数据重新分布到其它盘上即可（也就是只要有足够的空间即可）。这样的好处是很明显的，充分利用每一块磁盘，大大提高了rebuild的速度。另外，只要剩余空间足够，理论上可以坏更多的硬盘也没有关系（大于指定的hot spare的个数）。
看起来的确是一个非常好的东西，极大的减少了管理成本与维护成本。但是，任何东西有优点，也还是有缺点的，对于这个虚拟化技术，我相信更多人担心的是其稳定性与成熟度。另外，就是自动负载均衡的时候，到底对系统有多大的性能冲击？
EVA除了以上存储虚拟化的特点以后，还有一个特点也是做的非常好的，那就是交换式光纤构架。在传统的存储阵列中，基本上都是环路结构，这个环路结构导致一个环上面可能接很多的磁盘，一定程度上可能形成瓶颈，如高IOPS的环境中，一个环路就不适合接太多的硬盘。EVA中改变了这个情况，这里通过交换构架，可以让每个后端卡直接访问到每一块硬盘。这个也算是一个非常大的进步，因为需要修改2个比较大的地方，一个是后端卡到盘阵的交换，另外一个是盘阵到磁盘的交换。
上一篇文章，我介绍了远程SAN的一个解决方案——DWDM，一种光纤复用技术。其实，除了DWDM，还有FCIP,IFCP,ISCSI，他们都在致力于解决远程存储的访问以及整合问题。在这三个解决方案中，ISCSI又是发展最迅速，未来最美好的一个发展方向，但是，他的未来到底怎么样，能改变我们的FC-SAN存储结构，能改变我们的未来吗？
先说说大家为什么这么热衷于远程存储，其实，说简单点，就是为了解决信息孤岛的问题，说深入一点，主要还是为了容灾与安全，再说白一点，也是不同的厂家在角逐利益，想在这里更多的分一杯羹，建立自己的标准。想当初，SCSI主导存储标准的时候，brocade为了建立FC协议标准，结果没有几个大公司加入的，最典型的就是IBM，就是非弄一个SSA，也不愿意使用FC协议。
时过境迁，现在FC协议成了存储上使用最广泛的存储协议标准了，IBM的ds系列存储，如ds 8000也不得不接受FC协议，这也并不代表他们放弃了SCSI，这不，由IBM，Cisco等巨头共同发起的技术标准ISCSI，就是对FC的一个大的挑战。其实，他们从来就没有放弃过SCSI，现在还弄了一个能上网的SCSI。
那么，ISCSI到底是怎么回事呢？如果说DWDM是光纤复用，还是在远程传输FC协议，组建一个广域的SAN环境，而FCIP与IFCP都是为了解决在TCP/IP协议上传输FC信息，那么ISCSI则是彻底希望能放弃FC协议，直接通过网络来访问存储。那么，理想中的世界就是，不管存储在哪里，我只要网络能访问到它，我就能使用它。
多美好的前景，而且，还还有一个致命的优势——成本低廉。想想看，网络无初不在，只要有网络，网络条件好，我就可以使用这个存储，不象FC协议，我必须用光纤线，组建一个SAN存储网络。让我想起了电源，只要插上插头，就可以使用了，原来Oracle 10g数据库的grid的最终理想也不就是这个样子末，共产主义社会啊。
所以，ISCSI一出来，就受到了众厂商的青眯，纷纷推出了自己的支持ISCSI的产品，不过，细细看来，原来都是支持而已，真正的内部还是使用光纤协议（光纤硬盘），主要支持光纤协议，ISCSI只不过是额外支持而已，表示从存储端到存储端可以使用ISCSI。而且，大部分的使用者，也没有使用这个ISCSI接口，一个是因为网络条件，GbE(Gigabit Ethernet)的网络环境足够既跑业务，又跑数据吗？另外一个问题，业务与数据都跑在一个TCP/IP网络上面，安全性怎么保证？ACLs，VLAN，私有网络？
因此，ISCSI出来也有4年多了吧，市场份额一直上不去，起码现在还是FC的天下，而且，同是使用网络的另外一个存储方式——NAS，还具有跨平台的优越特性，管理性而言，甚至比ISCSI更方便。ISCSI最终的梦想，就是NAS架构和SAN架构完全融和，但是，能否取代SAN与NAS，这个将是一个长期的话题。
战争才开始，FC已经开始普及4Gb的传输标准，看齐10Gb的传输标准，而网络也开始出现10GbE（万兆网）的网络环境。FCIP,IFCP有待建立标准，还有更多的标准，如FCoE，也在酝酿之中，不管怎么样，最终受益的只要是我们最终用户，也就行了。
下面，我们看一个简单的典型的SAN环境，我们有2台主机，2台SAN交换机，2台存储，他们可能是HA，也可能是RAC环境，或许是单机，这个现在并不重要。重要的是，这个SAN环境，我们一般都配置在本地，类似一个本地局域网，我们采用一般的光纤线连接就可以搭建这样的一个SAN的环境。
现在，因为业务需求，你必须考虑容灾了，你希望把这两台机器，2台存储分布在不同的机房，而这两个机房相距了10KM以上，如果强行拉开，我们将看到的是这个样子了。
可以看到，有很多光纤需要被拉的很长，而这样长的光纤，不依靠运营商，一般是自己没有办法拉的。而且，越多的光纤，将带来越大的成本。那么，我们难道就没有一个好的解决办法了吗？还是有的，这个就是DWDM（DenseWavelength-Division Multiplexing，高密度多工分波器）光纤复用技术，根据WDM发展过来的DWDM技术已经被广泛使用多年了，采用DWDM后的SAN结构图将变成这个样子。
由于采用了光纤复用技术，所以长距离的光纤线现在只需要一根了，就是考虑冗余，也只要2根就可以了。而采用了这样的方式以后，整个结构并没有发生变化，你可以认为在那一根光纤线上跑的就是多根你需要的光纤。
那DWDM是怎么实现的呢？我们先看一个原理图
简单的说，DWDM其实就是在一根光纤线上采用不同的波长来传递不同的数据，模拟不同的通道，实际看起来就象是不同的光纤在通信，因为只要波长不一样就可以，所以DWDM可以在一根光纤线上随便复用出几十个信道（channels），实验室甚至可以复用出几千个信道。
那么，有了这个东西，通过SAN访问远程存储，就变的很容易了，远程RAC也不再是梦想。实际上，通过这种DWDM技术，然后用卷复制来容灾的技术在国内某银行机构已经正式在使用了。而且，远程RAC，一个新型的容灾计划，即可以实现高可用与负载均衡，又可以实现容灾的方案，也有公司在考虑使用了。
今天，与EMC工程师一起解决了一个DMX3前端口通讯故障问题，问题的解决是出人意料的，不过也发现，实际生活中，什么样的可能都会出现，所以，思考问题的思路一定要开阔。
一、发现问题
在一台EMC DMX3安装完成后，在其中一台主机做DD测试，发现写速度非常慢，通过powermt watch可以发现，每秒的IO个数，每个通道才8个，写速度每秒钟不到10M。
dd命令格式如下，其中，rlv_test是裸设备
#time dd if=/dev/zero of=/dev/rlv_test bs=1024k count=10000
powermt watch的观测结果如下：
==============================================================================
----- Host Bus Adapters --------- ------ I/O Paths ----- ------ Stats ------
### HW Path Summary Total Dead IO/Sec Q-IOs Errors
==============================================================================
0 fscsi0 optimal 191 0 8 1 0
1 fscsi1 optimal 191 0 8 0 0
2 fscsi2 optimal 191 0 8 0 0
3 fscsi3 optimal 191 0 8 0 0
故障问题报上去以后，EMC工程师赶到现场，然后通过dd到文件系统，做了一个类似的测试，如
#time dd if=/dev/zero of=/u01/test.dat bs=1024k count=10000
通过powermt watch的观测结果如下：
==============================================================================
----- Host Bus Adapters --------- ------ I/O Paths ----- ------ Stats ------
### HW Path Summary Total Dead IO/Sec Q-IOs Errors
==============================================================================
0 fscsi0 optimal 191 0 4 2 0
1 fscsi1 optimal 191 0 130 1 0
2 fscsi2 optimal 191 0 132 1 0
3 fscsi3 optimal 191 0 131 1 0
这个时候，EMC工程判断，其中有一个链路有问题，就是以上的fscsi0连接的链路1，因为才8个IO的时候，队列中就有一个等待，做文件系统测试的时候，基本没有IO。这里可以看到EMC工程师判断还是很准确的，没有把问题定位在文件系统与裸设备的差别上，甚至说裸设备有问题，而是定位在链路上面。
于是，我们查看了这台主机连接到存储的拓扑结构图，如下：
switch sw0
server fcs1 <----------> port 17 <---> port 16 <-----------> fa-7b0 ==>zone1
server fcs0 <----------> port 25 <---> port 24 <-----------> fa-8b0 ==>zone2
switch sw1
server fcs3 <----------> port 17 <---> port 16 <-----------> fa-9b0 ==>zone3
server fcs2 <----------> port 25 <---> port 24 <-----------> fa-10b0 ==>zone4
因为有问题的链路是fcs0，而这个链路通过光纤交换机的25/24 port，连接到存储的8b0前端口，于是，我们登陆到该交换机，disable这个通道：
admin>portdisable 25
然后，再做测试，可以发现速度正常：
==============================================================================
----- Host Bus Adapters --------- ------ I/O Paths ----- ------ Stats ------
### HW Path Summary Total Dead IO/Sec Q-IOs Errors
==============================================================================
0 fscsi0 failed 191 191 0 0 191
1 fscsi1 optimal 191 0 510 0 0
2 fscsi2 optimal 191 0 510 0 0
3 fscsi3 optimal 191 0 510 0 0
至于为什么4个通道不正常，三个通道就为什么正常了呢，这里还与powerpath的分配策略有关系，在写裸设备的时候，powerpath尽量让每个通道的IO均衡，结果，因为通道1的IO上不去，所以把大家的速度都降下来了。
二、解决问题
问题是找到了，于是，我们来到机房，开始试着解决问题，先是判断问题点在哪里，问题判断过程如下：
1、我们把光纤交换机上的25/24口换到15/14口，问题依旧，判断光纤交换机没有问题
2、我们把主机fcs0连接到光纤交换机的光纤线换掉，问题依旧，判断主机端的光纤线没有问题
3、我们把存储8b0连接到光纤交换机的光纤线换掉，问题依旧，判断存储端的光纤线没有问题
这个时候，问题很明显，要么是主机fcs0的HBA卡有问题，要么是存储的前端口fa-8b0有问题，EMC的一个工程师甚至建议我找IBM换fcs0光纤卡，说他们的前端口基本不可能坏的。本着继续测试的精神，我们一定要找到到底谁有问题，于是，弄了一个新的方案，就是把fcs0从通道中去掉，把fcs1接到7b0与8b0，新的拓扑结构如下：
switch sw0
server fcs1 <----------> port 17 <---> port 16 <-----------> fa-7b0
server fcs1 <----------> port 17 <---> port 24 <-----------> fa-8b0
switch sw1
server fcs3 <----------> port 17 <---> port 16 <-----------> fa-9b0
server fcs2 <----------> port 25 <---> port 24 <-----------> fa-10b0
当时我们认为，如果这样速度还有问题的话，基本可以判断是EMC前端口8b0有问题，测试结果发现，速度依然还是上不去，于是，我们只好断定EMC的前端口有问题了。
EMC联系了他们的硬件工程师，远程登陆到存储，没有发现任何硬件错误信息，不能判断硬件有问题，我们看到的结果也是，这个硬件没有报任何错误，其实是可以使用，不过是速度慢。那问题到底在哪里呢？EMC先是申请硬件配件，也就是前端卡，然后一边做测试，因为他们不相信前端卡有问题。
其实，他们的相信还是正确的，通过我们后来的一系列测试看来，的确不是硬件问题。
三、陷入迷茫
因为还是测试阶段，所以没有加急，2天后，他们的备件到场，这次来了一个硬件工程师，在机房，负责检查硬件以及随时更换硬件，另外一个软件工程师，在公司，与我一起做检测。我们把测试环境改成单个链路，也就是fcs1（肯定是正常的光纤卡）连接存储的8b0（怀疑有问题的前端口），如
server fcs1 <----------------> port 17 <---> port 24 <-----------------> fa-8b0
dd的结果还是不行：
==============================================================================
----- Host Bus Adapters --------- ------ I/O Paths ----- ------ Stats ------
### HW Path Summary Total Dead IO/Sec Q-IOs Errors
==============================================================================
1 fscsi1 optimal 191 0 26 1 0
但是，如果是fcs1连接7b0，速度则正常
server fcs1 <----------------> port 17 <---> port 16 <-----------------> fa-7b0
dd的速度为：
==============================================================================
----- Host Bus Adapters --------- ------ I/O Paths ----- ------ Stats ------
### HW Path Summary Total Dead IO/Sec Q-IOs Errors
==============================================================================
1 fscsi1 optimal 191 0 901 4 0
于是，我们开始如下的新的检测过程
1、硬件工程师先换了8b0的前段口，问题依旧
2、硬件工程师更换了8b0的所在的板卡，但是不包括cpu模块，问题依旧
3、硬件工程师更换了整个前端板卡，包括cpu模块，问题依旧
在更换整个前端板卡前，EMC的那个软件工程师说，他们最担心的是更换了硬件之后问题依然存在，因为硬件看起来是没有问题的，其实，他说到这里，我也隐约感到不妙，可能这就是预感吧。前端卡更换上去，问题果然没有解决。我们都晕了，问题在哪里？看起来前端卡并没有问题。
看样子不能乱说话，说不定我们不说那句话，前端卡换上去了就好了呢。。。哈哈
四、离奇的故障
开case吧，emc工程师的速度还是非常快的，但是case要等到老美上班，而老美上班一般都是晚上12点以后了。让他们（老美）登陆过来看看，我于是先回家了，EMC工程师继续加班。第二天，上班的时候，EMC软件工程师也过来了，回答是，老美确认硬件没有问题，把问题丢给了OS。
但是，连接这个存储的有多台主机，为什么只有这一个主机有这个问题呢，而且是这个端口，但是，既然这样说了，我决定，让EMC工程师把这个8b0连接到另外一个主机上做测试。也就是拿另外一个主机的fcs1与8b0连接，把这个机器的硬盘认到另外一个机器上。同时，EMC的工程师对我说，他想测试一下跟8b0相同CPU接口的8b1，但是光纤交换机上没有显示8b1在线。
fa-8b1我们是接光纤线了的啊，虽然没有在用（仅仅是一根备用线），但是光纤线我们是要求EMC给我们接了的，怎么会没有显示呢？我再检查了一下交换机的连接信息，就是这个fa-8b1没有连接进来，其它的口都是正常的。
因为这个光纤连接是前几天另外一个EMC安装工程师做的，我还没有来的及做交换机的check，线是肯定接了的，那么，是那个工程师还没有把这个线配通，难道这个线有故障，我也是隐约觉得这里肯定有问题，可能还是预感，哈哈，可见我的预感有多准确。我打电话给机房的一个管理员，让它换了一根连接8b1到光纤交换机的光纤线，这个时候，emc的工程师也把8b0的盘认到了另外一台主机。测试
正常。。。。。。。
难道真是OS问题？不对。。。我突然想到，我们原来的主机也应当好了，我说，再把盘挂会原来的主机，问题应当好了，EMC软件工程师把盘挂回原来的主机，测试
果然好了。。。。。。
我再通知机房的管理员，干脆把这根线拔了，现在还是正常的，问题居然就这么解决了。
晕的，可以判断了，问题就是出在那个出问题的光纤线上，虽然这个光纤线没有在使用，而且光纤交换机上也看不到这个线是通的，但是，他就是能影响到我们。
想了想，估计，那根出问题的光纤线，虽然谁都没有在使用它，可能它本身有问题，导致存储的8b1一直在试着跟它通讯，耗费了8b1端口的cpu，而8b1跟8b0是同一个cpu，所以，8b0性能怎么也上不去，因为cpu被消耗了。。。。。。
我也仅仅是猜测。。。
不过，从这个case看来，EMC工程师解决问题的方式与速度还是不错的，就是我们回家了，他还一直坚持加班解决问题，比有些厂商总是喜欢把问题推到别人身上要强多了。但是，也暴露出来他们一个问题，如安装工程师没有把所有的线都配通，估计是因为那根线是备用线，觉得通不通关系不大，结果导致了问题的出现。
上篇说了一个cx700与powerpath的故事，既然写了，那么也把另外一个故事写下来，个人感觉，这个故事或许比上一个故事更有意思，也更有借鉴意义，因为在实际工作中，可能会经常遇到。
故事的起源就在于我们的HA的aix主机，以前只有一块光纤卡通过一个光纤交换机连接到cx700。现在，找IBM再买了一块光纤卡，准备安装上去，通过另外一个光纤交换机连接到cx700，把双通道路径扩展成为4通道路径。
既然是HA的机器，停机问题不大，找一个晚上，约上IBM的工程师，Dell的工程师，恩，就是我上篇说到的那个很会电话的工程师，这次他表现一样不错，我们一起去了机房。
我们的想法是感觉比较容易的，不就是如下步骤末：
1、在IBM主机里面插上新卡
2、IBM主机认到卡，并状态正常
3、光纤交换机那里认到卡，能获得WWN
4、把光纤交换机的zone配置一下，加入新的卡的WWN或者是port，并enable配置
5、检查cx700的连接状态，现在是不是4个连接
6、主机上重新认盘，应当就是从以前的2个路径变成4个路径了
当然，有这么简单，就没有下面的故事了。
1与2都很正常，3的时候，如果是先认卡，再接的光纤线，主机这里需要再执行cfgmgr，其实就是给光纤交换机发一个信号，否则，光纤交换机认不到卡的WWN，这个也没有费什么时间就过了。步骤4我配置通过，步骤5，我与dell的工程师都检查了，连接状态那里的确是4个路径，都正常了，那么，开始步骤6。
我们先用rmdev -dl删除了以前的阵列上认到的盘，用cfgmgr -v去认，发现只有2条路径，甚至下了狠招，rmdev -Rdl fcs(x)，把整个光纤卡都删除了，重新认，还是只有2条路径。我们就开始郁闷了，于是dell的工程师开始打电话，我们开始继续检查。
·光纤交换机肯定正常，可以看到所有的光纤卡。
·zone的配置肯定也没有错，配置都enable了
·路径肯定正常，cx700上可以看到4条通道都正常
dell的工程师电话的同时，还不忘记问IBM的工程师，“我们那里都正常，应当是你们的问题”
IBM的工程师说，“盘都认不到，应当是你们哪里的问题”
时间就这么过去了，我在想是哪里出了问题呢，其实，也就是突然间，想到会不会是cx700的store group那里有问题，正常来说，store group只是决定了哪个主机能访问哪些lun，应当不会有问题，但是，现在能与主机扯上关系的，只有他了。立即行动，我先把主机上所有的阵列盘删除，然后我把HA的主机从store group中踢了出来，确定一下。再放进去，确认，主机上重新认盘，正常了。
dell的工程师还在电话呢，我与ibm的工程师于是一起叫道，“兄弟，别打电话了，已经好了”。
这个问题是好了，发现了一个新的问题，因为我们删除的太猛，认出来的硬盘都没有PVID以及VG信息了，而这个是HA的机器，这些硬盘其实都是正在使用的，无法使用常规的方法获得PVID与VG信息，也就是说，我们不能使用正常的importvg来导入VG，也没有办法使用chdev -l hdiskpower(x) -a pv=yes的方法获得PVID与VG信息。
怎么办？这下好了，dell的与ibm的工程师都去寻求帮助去了。
寻求帮助没有什么成果，那我只能来狠的了，因为HA的机器不能执行importvg的原因，就是因为主节点也正在使用这个VG，那么临时解除这个锁不就可以了。
主节点：varyonvg -b -u vgname ###解锁
HA的机器：importvg -L vgname hdiskpower(x) ###读入信息
主节点：varyonvg vgname ###加锁
注意，以上的操作具有风险性，特别是并发系统，如RAC上是不能随便解锁的，就是单节点，解锁操作也要小心谨慎。因为我们这里在晚上，压力小，而且时间短，关系就不大了。
经过以上的操作，HA也终于正常了。再仔细想想整个经过，其实，我们就是忽略了store group那里，我估计是store group把路径信息给记录进去了（或者是缓存起来了），因为它才是最终决定什么主机可以使用什么LUN，但是他不应当决定路径个数的。而第二个问题的出现，则是因为我们急于解决第一个问题，采用了一些非常规的操作才出现的。
其实，这个问题，也不仅仅是dell的工程师没有现场解决能力，在今年的cx3-80的测试上，emc的工程师遇到同样的问题时，一样束手无策。这里说到cx3-80，其实就是cx700的一个乘以2的翻版，把前后带宽，cache容量，磁盘最大连接个数都翻了一倍，但是后端的环路并没有增加，所以，如果追求高带宽的话，是一个不错的产品，如果追求IOPS，则需要考虑一下。
这次的测试，我们中途需要更换一个光纤卡（准确的说，是4台机器的RAC，每个机器要换一张光纤卡），我徒弟与2个EMC的工程师就过去了，到下午快下班的时候，我问我徒弟进度怎么样，他说EMC卡在那里了，已经2个小时了，我问什么原因，他说新换的卡，光纤路径认不到，emc的工程师正在向总部寻求帮助。后来知道，这两个工程师是比较年轻的工程师，还没有什么经验。
我晕，同样的问题，在cx3-80上同样存在。
我说，你让他们别打电话了，我知道怎么回事。
之后，我让他们把主机从store group中拿了出来，确认后再放进去，之后，他们告诉我，有2台主机正常了，但是2台主机不正常，ft，确认他们的操作也没有问题以后，我说，你们把ip给我，我登陆进去看看。
登陆到cx3-80，我检查了一下连接状态，才发现，原来他们这台cx3-80已经给N多人做过测试，连接状态里面全是乱七八糟的主机光纤卡，我看了看那两台不正常的主机，连接状态都不对，存在一定冲突，当然改store group是没有效果了。我先把那些乱七八糟的，以前注册进来的光纤卡，先全部删除，然后重新注册这两台机器的光纤卡，OK，正常了，为了确保没有问题，我把store group再操作了一次，让他们在主机上认一下，不久，他们告诉我，都正常了。
问题其实并不复杂，知道的人都简单，不知道的人都复杂，就是这样，往往是你觉得最不容易出现问题的那里，出现了问题。
应IT168编辑的盛情邀请，我最终还是决定写一篇我的存储故事，不象别人恢复多少多少数据那么紧张，那明显就是管理问题与规划问题，我这里也肯定没有这样的故事，因为不允许出现这样的故事。那么，我就把故事定位在了一个很小的故障解决上，这个事情不大，但是拖了我很长时间，也最终直接导致了我对EMC CX系列操作的非常熟练，包括上架、连接、升级存储的软件版本、改变任何配置等等操作。
本文既然投稿给了IT168，那么版权就归IT168所有，转载需要注明IT168的版权。
故事起源
在早先的时候，公司大量使用过EMC的Cx系列，不过，这些设备都是从dell那里买进的，也叫Dell EMC。那是一个什么样的时代啊，我们基本上对san与存储是一无所知，而Dell呢，虽然服务是好的，技术则是一般的，所以，第一个来给我们安装配置san的dell工程师，据说因为3天都没有配置成功，被fire掉了。
而正式开始重视san，还是在一次事故以后，有几台san环境中的机器，需要搬迁，之前我们把光纤线都做了标记，但是，可能是标记出了问题，真正再插入光纤线的时候，认不到原来的硬盘了。
痛定思痛，我们决定自己掌握存储技术，从一无所知，到现在能在san，存储产品上了解这么多的东西，很多都是自己经验的积累。下面我就描述我的经历中的，一个cx700软件版本与powerpath版本之间的小故事。
1、发现问题
问题的起因是我们安装了一台cx700的存储到一个新的aix主机上，dell的工程师直接在主机上安装了当时最新的powerpath版本，PP4.5，据说是一个比较稳定的版本，而之前我们用的都是PP4.2。当一却都做好之后，我开始测试存储的速度了，发现一个问题，存储的写速度怎么也上不去，最多每秒只有60M左右。
这个速度不是cx700的表现，然后，我们就开始找问题，最初的时候，怎么也没有想到powerpath，我们先检查硬件设备，如存储，光纤连接，光纤交换机。然后检查软件配置，如主机上的配置，光纤卡的参数，都没有发现任何问题。最后，甚至重新安装powerpath，问题依旧。这个时候，已经是晚上很晚了，我们都很郁闷，现场dell的一个销售说了声，会不会是powerpath的问题，我们换回老版本看看，于是换老版本，速度也就正常了，问题居然就这么解决了。
2、查找原因
设备是可以正常用了，但是，我们谁都不知道是什么原因，之后与dell交互过几次，基本怀疑是cx700的软件版本太老，其实就是cx700的flare operating environment，当时是2.14的版本。
直到我们要安装另外一台cx700到aix主机上的时候，才发现问题不是那么简单。我们先做了raid，发现软件版本是2.14，于是就升级到了当时最稳定的版本，2.19.030，在主机上安装了PP4.5，结果发现问题依旧。
因为这次的时间比较充足，决定要求dell查找一下原因，dell于是派了一个工程师过来，这个工程师技术一般，却有一个特长，就是能打电话，他可以不停的电话别人，从中国到新加坡，甚至到更远的澳洲。原来的问题不仅是没有解决，反复的安装测试，反而导致了另外的问题，如powerhdisk盘出现了混乱，pvid也出现了严重错误。因为新的错误的出现，他的电话不得不变的更多了。
我郁闷了，决定结束这次检查，我先是删除干净，再安装回PP4.2，凭借OS的经验解决了powerhdisk与pvid的问题，因为我害怕再弄下去，我也解决不了OS上的这些问题了。
问题依旧是没有解决，这样看来不是软件版本的问题。
3、柳暗花明
我已经习惯PP4.2了，就这么用着吧，后来，新采购了新的cx700，软件版本买过来就是2.19的，这次尝试安装了PP4.5，居然一切正常，又勾起我想解决前面的问题的欲望。于是，我拿这个正常的cx700与前面性能有问题的cx700反复测试，也没有发现哪里有不同，但就是在PP4.5上速度有差别。
问题的最终解决我也没有想到，一台软件版本从2.14升级到2.19的CX700，正好要重做，于是我重做了raid，本着找问题的精神，我还是装了PP4.5，居然这次正常了。
晕，对照以前的做法，唯一不同的就是，以前是先做raid，再升级软件，就不可以用PP4.5，现在是升级软件以后，再做RAID，居然就可以了。为了确定其正确性，我找了一个软件版本还是2.14的机器，先升级到2.19，连接PP4.5，就是速度有问题，但是重做raid后，速度就正常了。
问题最终是知道怎么回事了，但是，我也是一直郁闷着过来的，这样的问题，谁能想得到呢，难道Raid跟cx700的软件也挂上关系了。我也不想调查最终原因了，如果调查，可能只能问CX700的开发人员了。
我在前面介绍了现在比较流行的三款高端存储的基本体系结构，包括IBM的ds8000系列，hds的usp系列以及EMC的dmx3系列。我在这里将三款高端存储再做一个简单的对比。
1、体系结构
hds与emc都采用了多点冗余的复合式体系结构，有多个专用的存储控制器，如专用的前端控制器，专用的后端控制器，并且以以专用的 cache 控制器为核心，CPU集成在前/后端控制器中，操作系统以微码方式集成在硬件中，并可以方便的升级维护。在这种结构中，前端，cache，后端均可实现系统均衡，并多点冗余。所以，失败一个点的时候，影响量比较小。不过，还有一点差别的是，hds前后端连接到核心cache，是采用交换方式，而EMC是采用直连方式，所以也叫直连矩阵。
至于IBM，采用的是传统的对称体系结构，采用其强大的570 pserver作为存储的控制器，所以，存储的管理OS运行在控制器内，CPU与内存也都在控制器内。这一种体系结构是应当是说与现有的中端存储的结构很相似，IBM的这种方式的体系结构在可靠性方面是比上面的体系结构要欠缺一些的。
2、后端连接与RAID
IBM采用交换方式连接磁盘与后段卡，而HDS与EMC采用环路结构，在交换结构中，每个磁盘都有自己的线路连接到后端卡（口），所以，不容易产生后端瓶颈。
至于环路设计，则是现在的流行设计，但是，一个环路上的盘不能太多，否则，容易产生性能瓶颈。如，一个2Gb的光纤环路，一般接到50-60颗盘，已经都达到负载极限了。而一个4Gb的环路，如果考虑翻倍的话，也就最多可以接100-120颗磁盘。
不过，上面评估磁盘个数的时候，是根据流量，也就是带宽来考虑的，如果在OLTP环境中，我们还需要考虑IO个数，因为光纤通信的规则，在同一个时间，一个环路中只能有一个通信量，也就是一个IO。不过幸好的是，光纤传送的速度是非常快的，在比较慢的磁盘面前，一般都不会有性能问题存在。我们可以想象为光纤环路是一个运行非常快的传送带（但是这个传送带很奇怪，每个时间最多只能送1个任务），而磁盘则是这些传送带旁边的工人，负责从传送带上面拿到自己的工作，把工作完成以后，再把结果放到传送带上，工人在工作期间（类似磁盘寻道时间），传送带是不需要等待的，可以传送别的工人的任务。
因为考虑到环路的可靠性与性能问题，HDS与EMC的高端存储都是双环路设计，每个磁盘都有2个环路可以达到，而且，这两个环路可以负载均衡的工作。另外，为了避免一个环路，或者一个磁盘太忙，RAID组的设计也有特殊的要求，一个RAID组中的磁盘，必须跨越在不同的环路上面。
为了扩大容量，又不影响性能，存储厂商只好不断的增加环路的个数，一般情况下，典型的OLTP环境中，一个2Gb的环路中，磁盘个数最好也不要超过32颗，如果想增加更多的磁盘，最好也增加环路个数。
不过，怎么来说，交换结构是要优于环路设计的，所以，这里IBM更好一些。
3、cache设计
HDS与EMC都是以cache为核心，并且cache size一般比较固定，如64K，256K等等，如果这样的cache size在运行很离散的OLTP数据库应用的时候，因为数据库的block size一般都比较小，如8k、16K，所以，容易引起cache size的浪费。因为存储的一个cache size单元中，一定要保存相临的磁盘连续空间。
而IBM因为采用OS的内存来做存储的cache，所以，cache size就是页面大小，默认为4K，这样的cache size对小的IO是很适合的，但是对大型的IO操作，或者是太大的cache size，可能会有额外的管理负担。
比较大的cache size，如64K的cache size，一般是因为考虑到高效的算法设计以及满足大部分应用需求而设计的，如根据概率统计的数据，满足99%的应用等等，个人觉得，在一些特定的非常小的，离散的应用上，则不一定适合。
至于cache算法，HDS与EMC基本都是LRU算法，而IBM则采用改进的ARC算法。在cache保护中，IBM与HDS都是写cache镜相+电池cache保护，而EMC则是读写全局cache的全镜相+电池cache保护。在写cache镜相的规则中，读写cache是分离的，写cache镜相，读cache不镜相，一份数据可能同时存在与读/写cache中；而全局cache，没有读写之分，cache公用，只有不同的链表来决定那些数据是写cache，这点很类似Oracle的data buffer。
相关讨论，也可以参考：
假定给你一台存储，这个存储上面有16个raid组（就假定是raid10），现在，将要有4台不同应用（Oracle数据库）的主机连接到这台存储，我们又假定4台应用的负载相差不大，数据量也相差不大，你会怎么分配这16个raid组？
一般来说，想到的是以下2种常见的分配方法：
规则一：4个数据库都可以访问所有的raid组，但是每个数据库只能访问其中的1/4。
规则二：因为有16个RAID组，最简单，每个数据库分4个RAID组，互不干涉。
如图：
支持规则1的人说，因为每个数据库都可以访问到所有的RAID组，数据打散到所有的磁盘上，当一个数据库忙的时候，就可以充分利用所有的资源。
支持规则2的人说，太打散不好，看不到热点，数据不集中，不利于存储的cache有效命中，一个库会拖累其它的数据库，造成大家都慢。
可能上面有点难理解的就是不利于存储cache命中了，不过我这里可以稍微解释一下，现在的存储产品，本身是存在一定大小的cache的，如有些高端存储可以配置到512G的cache，其实也就是一个数据缓冲池，类似Oracle的data buffer，一般才采用LRU算法（IBM是ARC算法）管理cache单元，cache单元有可能大于数据库的block大小，如64K，甚至256K。
或许，我们还要假定，如果是同样的应用，两种方式下都能跑，但是，谁更优一些，也就是响应会更快一些？
这是一个疑问题，不好意思，现在没有答案，只想听听你的看法，或者你也可以参考该帖：
前面我介绍了IBM的ds 8000系列与HDS的usp系列，这里我介绍最后一个高端系列，EMC的dmx3系列。
DMX3是在早先SYMMTRIX 2000/3000系列上发展过来的，基本的体系结构没有改变，但是cache算法却做了一个比较大的改动，在以前的高端系统中，EMC是不采用写cache镜相技术的，而别的厂商基本都采用写cache镜相、读cache不镜相、读写cache分离这样的技术。那么，他们分别采用什么样的方式来保证写cache数据的正确性呢？
第一，因为cache肯定都是电池或者ups保护的，可以保证不掉电，或者是掉点以后系统还能维持一定时间，如果在一定时间内还没有供电，再把数据写到硬盘上，防止丢失。
第二，因为写cahce镜相保护数据也很简单，就是防止cache损坏，如果坏掉一个cache，还有另外一个，只要马上把坏的cache标记起来不用，镜相到新的地方即可。
第三，早先的SYMMTRIX系列采用了一种类似raid5的电极校验法来对cache进行校验，保证数据的可靠性，提高cache的利用率。但是，在新的dmx3中，又采用了一种完全不一样的镜相方法，读写全局cache全镜相，也就是说，如果100Gcache，有效cache是50G。
那么，“全局读写cache全镜相”与“读写cache分离，写cache镜相技术”谁好谁差，我不做评论，不过有些关键点大家还是要知道
1、全局cache中，读写是混在一起的，类似oracle的buffer，读可以直接在一个cache中命中。
2、读写分离中，如果一个要读的数据在写cache中存在，需要先从写cache拷贝到读cache，可能存在多份。
3、读cache一般远远大于写cache。
除了cache算法差别，我们从体系结构图中，还可以发现，emc一样以cache为核心，有前段卡有后端卡之分，如一个前端卡上有8个光纤接口，可以连接主机，一个后端卡上同样有8个后端口，用来连接磁盘。磁盘与hds一样采用光纤环路方式。
不过，emc前端与后端卡连接cache的方式与hds有很大差别，hds是通过内部交换方式连接，而EMC是直接连接，每个卡与每个cache板之间都有数据通道，所以，emc的连接方式又叫直连矩阵。
另外，emc的raid方式与hds也很不一样，hds的raid方式很死板，如raid10就支持2D+2D，其实所谓的4D+4D不过是把2个2D+2D简单的连接在一起。而emc中，raid方式比较奇特，如做10，他们先是把磁盘划成很多道（叫split，如8split，10split，16split等等），每一split可以镜相到一个磁盘。如一个磁盘有16个split，则3.8G/split，那么这个磁盘最多可以镜相到其它16块磁盘上，同样，其它的盘也可以交错镜相到这里，形成一个比较大的磁盘pool。之后，emc在每个split上做strip，形成metalun，这才是主机最后使用的LUN，对应到一个pv。
