有人问到了这篇文章中，为什么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
计算完成。
比较早的时候，在这里写过一篇存储虚拟化的文章，这里再把主机的虚拟化简单的总结一下。
虚拟化的概念在 20 世纪 60 年代首次出现，虚拟化技术是未来的发展方向，在存储中如此，在主机中也是一样。在以前，主机虚拟技术基本上大型机上的专利，利用它可以对属于稀有而昂贵资源的大型机硬件进行分区。不过，现在终于走向小型机甚至是PC构架的服务器上了。
虚拟化是一个抽象层，它将物理硬件与操作系统分开，从而提供更高的 IT 资源利用率和灵活性。分区技术就是虚拟化技术的一个重要体现，主机的虚拟化也可以大致分为4个层次。
1、主机之上的虚拟化，也就是说，可以将多个主机虚拟成一个真实的主机，对于用户来说，其实就是一个主机，资源（主要是CPU与内存）可以在不同的主机上共享，实现分布计算。不过，目前的小型机与PC Server还没有实现这样的技术，因为分布计算的技术难度太大。最好的也仅仅是IBM的Power6+AIX6+虚拟IO技术，可以实现在不同的主机上平滑的迁移资源，有点类似HA，所以实际使用用途不大。
2、主机之下，硬件之上的虚拟化，如HP的电路板方式的硬分区，IBM的静态与动态分区(LPAR）。在同一个物理主机上，可以把硬件隔离成几个部分，每个部分运行不同的OS并且互相没有影响。更高级别的主机内部虚拟化，如动态逻辑分区，可以实现资源在不同的分区之间的动态迁移。
3、硬件层之内的虚拟化，这个是更细粒度的虚拟化，一个分区中，可能只拥有5%或者是10%的物理CPU，以及完全虚拟化的IO子系统。如一个主机只有1张硬盘，或者是1个网卡，但是可能虚拟化出来10个OS，每个OS都可以看到虚拟化过后的自己独立硬盘或者是网卡。Vmware的虚拟化也是采用类似的方法实现，但是，这种虚拟化技术是改变不了CPU指令的，也就是说，intel构架服务器虚拟化以后还只是intel构架，不能在上面装AIX（Power体系构架）。
4、OS之内的虚拟化技术，如solaris 10的zone技术，AIX6以后也支持类似的技术。这类的虚拟化计划是在一个OS中再克隆出来很多不同的子系统，他们有自己的用户系统，文件系统，程序等。他们的内核是一样的，所以，这种虚拟化出来的OS必须是一样的OS，如果内核问题，可能导致所有的OS都有问题。
随着现在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，一个新型的容灾计划，即可以实现高可用与负载均衡，又可以实现容灾的方案，也有公司在考虑使用了。
orion，一款由Oracle公司提供，专门用于模拟数据库运行机制来测试存储的优秀IO存储测试软件，可以在不运行oracle数据库的情况下，仿真OLTP随机操作（测试IOPS）或者是OLAP连续性操作（测试吞吐量）。
先看看此软件的下载地址与说明：
ORION is the Oracle I/O Numbers Calibration Tool designed to
simulate Oracle I/O workloads
- Without having to create and run an Oracle database
- Using the Oracle database's I/O libraries
- Using small I/Os to simulate OLTP workloads
- Using large I/Os to simulate data warehouses
ORION is useful for understanding the performance capabilities of a storage system,
either to uncover performance issues or to size a new database installation.
The Users Guide contains a Getting Started section, detailed usage documentation,
and trouble-shooting tips. Please note that ORION is not supported by Oracle.
Download the files:
·orion_AIX64.gz (11,670,726 bytes)
·orion_solaris64_sparc.gz (898,929 bytes)
·orion_solaris_x8664.gz (655,975 bytes)
·orion_linux_em64t.gz (767,380 bytes)
·orion10.2_linux.gz (630,354 bytes)
·orion10.2_windows.msi (7,865,856 bytes)
·Users Guide
可以见到，此软件已经支持多个OS环境，遗憾的是，Oracle并不对该软件提供服务支持，不过，这并不影响该软件的正常使用，从我的测试结果来看，该软件真的是很不错的存储测试软件。
下载到的软件，已经分别编译好，不需要任何编译即可以在各自的OS环境中运行，这个比很多压力测试软件需要另外重新编译好多了，也方便多了，如，在AIX环境下，在解压的目录下，运行./orion -help，即可以看到该软件的详细帮助。
该软件支持三种运行方式
Simple：简单的测试随机的小IO（默认8k）以及大IO（默认1024K），这个方式对初次运行该软件，或者大致了解存储基本特性比较有用。
Normal：可以组合不同的IO类型，但是还是不能自定义IO大小
Advanced：可以支持多种高级选项，如IO大小，压力大小，IO类型，测试方式等等
以及两种不同的压力方式
典型的OLTP环境：选择随机的小IO，测试存储所能支持的最大IOPS以及响应时间
典型的OLAP环境：选择顺序的大IO，测试存储所能支持的最大吞吐量以及响应时间
该软件的运行只需要一个配置文件，<testname>.lun，配置了测试所需要用到的磁盘信息，而分别返回如下信息：
<testname>_iops.csv：不同压力类型的IOPS值
<testname>_mbps.csv：不同压力类型的吞吐量
<testname>_lat.csv：不同压力类型下的响应时间
<testname>_summary.txt：测试结果的汇总信息
我在分别运行load runner+oracle模拟数据库活动以及仅仅是运行该软件模拟数据库的活动中，可以明显的发现该软件的优势所在：
1、不需要运行load runner以及配置大量的clinet
2、不需要运行oracle数据库，以及准备大量的测试数据
3、测试结果更具有代表性，如随机IO测试中，该软件可以让存储的命中率接近为0，而更仿真出了磁盘的真实的IOPS，而load runner很难做到这些，最终的磁盘IOPS需要换算得到。
4、可以根据需要定制一定比例的写操作（默认没有写操作），但是需要注意，如果磁盘上有数据，需要小心数据被覆盖掉。
当然，也有其缺点
1、到现在为止，无法指定自定义的总体的运行时间以及加压的幅度，这里完全是自动的
2、无法进行一些自定义的操作类型，如表的扫描操作，装载测试等等，不过可以与oracle数据库结合起来达到这个效果
下面，我就给出几个具体的例子说明其操作
1、数据库OLTP类型，假定IO类型全部是8K随机操作，压力类型，自动加压，从小到大，一直到存储压力极限
#nohup ./orion -run advanced -testname mytest -num_disks 96 -size_small 8 -size_large 8 -type rand &
2、数据库吞吐量测试，假定IO全部是1M的序列性IO
#nohup ./orion -run advanced -testname mytest -num_disks 96 -size_small 1024 -size_large 1024 -type seq &
3、指定特定的IO类型与IO压力，如指定小IO为压力500的时候，不同大IO下的压力情况
#nohup ./orion -run advanced -testname mytest -num_disks 96 -size_small 8 -size_large 128 -matrix col -num_small 500 -type rand &
4、结合不同的IO类型，测试压力矩阵
#nohup ./orion -run advanced -testname mytest -num_disks 96 -size_small 8 -size_large 128 -matrix detailed -type rand &
因为其测试结果是csv文件，所以可以很方便的根据结果在excle中绘制压力曲线，如某存储的压力测试，根据Orion的测试结果绘得的IOPS与响应时间关系表：
其中，横轴是响应时间，纵轴是IOPS值，表示了在不同的IOPS情况下，单个IO的平均响应时间分别是多少。
今天，与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的开发人员了。
如果以后买服务器的时候，仅仅是问这个机器支持多少个CPU，也就是processor，可能就需要小心谨慎了，因为你有可能买一个cpu，结果要支付几个cpu的license。
不是没有可能，实际上，已经就有这样的情况了，那就是SUN CMT的出现，使得processor，也就是cpu，开始成为一个模糊的概念，而core（核）有可能取代cpu成为新的检查标准。
SUN CMT其实还是一个好东西，在一个芯片中，集成了多个Core，目前为止，可以在UltraSPARC构架上支持8个core，但是，SUN认为这个芯片是一个CPU，也就是一个processor，如一个UltraSPARC T1 CPU，可能有8个core。
但是，其它的厂商，如IBM，ADM/Intel等等，如果在一个CPU模块上同样集成多个Core，但是他们认为这个是多个CPU，也就是多个processor，如IBM的Power5的多核CPU模块，如果包含多个core，IBM则认为他是多个CPU。
影响最大的，应当就是按cpu收费的软件厂商了，如Oracle，所以，Oracle就开始不按照cpu来收费，而是按照core来收费，不同的是，不同厂商的可能折扣比例不一样，以下是一个公开的折扣比例
Oracle Processor Licensing Cores Processor Factor
UltraSPARC T1 8 0.25
AMD/Intel 2 0.5
All other Multi-core Chips (IBM Pseries, SM USIV, etc.) 2 0.75
Single Core Servers 1 1.00
按照这个标准，一个UltraSPARC T1的cpu，对外宣称是一个cpu，虽然折扣很低了，但是，但是需要购买8*0.25=2个cpu license，一个双核的AMD/Intel芯片，包含2个core，对外也是2个cpu，但是也只需要购买2*0.5=1个cpu license。
另外，IBM虽然也支持多核，如8-way的CPU模块，但是从内部结构来看，也是等于4个双核。所以，多路的IBM的power cpu的收费可以简单的把cpu数量*0.75来购买license。
最后，可能看到的情况是，SUN一个cpu怎么需要买几个license，而别人几个cpu才买一个license。不要奇怪，这个，就是新的标准。
