3par peer persistence与XP7双活在RAC环境下的比较

3par不支持严格意义的存储双活，但是它的PeerPersistence功能在存储双数据中心的配置中，非常有意思。在此我们以RAC应用为例对其做一个分析。

先上一张架构图，看明白这个架构是怎么回事。

这个架构里面有两个模块：一个是上面的服务器+ORACLE RAC构成的，由RAC向外提供服务，并管理服务器集群应对可能的物理设备故障，还实现了负载均衡分配；另一个是由3par存储和SAN网络交换机以及运行在虚拟机之上的仲裁服务器构成，存储空间通过peer persistence展现给服务器和RAC软件。

如果看过我之前的文章，会有一个感觉：它和HP XP7的双活方案很像耶！XP7的虚拟磁盘阵列是存储到主机的中间层，3par Peer Persistence也是中间层，而且都有仲裁机制。为什么它不是双活呢？

这就要谈到3par Peer Persistence与HP XP7对主机IO路由的分配了：

l  XP7的虚拟磁盘阵列中的会把接收到的IO根据一定的（比如本地存储优先）把IO发送到两个磁盘阵列中去。一个LUN在两个磁盘阵列的镜像可以同时处理主机发来的IO，没有主从的区别。XP7实际是LUN在两个阵列上的镜像都可以处理主机IO，但是它们的WWN是一样的，那么主机是如何知道哪个LUN在本地的呢？

l  3par Peer Persistence设置的LUN存储有主从区别，主机来的IO都会先到主存储，再由主存储同步到从存储。对于主机，存储路径的管理和切换，通过ALUA协议来实现。

下面这张图显示了两者在IO路径上的不同，对于3par，两条×××IO路径在正常状态下是非激活状态的，没有IO流过；对于XP7则不然，两条×××路径处于激活状态，分担部分绿色路径上的IO。

3par的peer persistence没有了×××路径，又是如何管理阵列的呢？它通过ALUA （AsymmetricLogical Unit Access异步逻辑单元访问）协议，把主阵列设置为主动/优化（active/optimized）状态，把从阵列设置为主动/非优化（active/unoptimized）状态。这样主机自然把IO都发送到主阵列上去了。当主阵列出现故障时，peerpersistence又会反过来把从阵列设置为主动/优化（active/optimized）状态，把主阵列设置为主动/非优化（active/unoptimized）状态。图示如下：

至此，是否可以说XP7的双活是否一定优于3par的peer persistence呢？表面上看是的，原因如下：

1.        由于两个阵列同时处于激活状态，切换会很快，理论上主机和RAC软件无感知。

2.        在XP7的双活情况下，两个阵列同时处理主机IO，均衡负载。

 

现在，我们对两种情况分别作更深入的分析：

1.        存储切换速度问题，需要分两种情况讨论

l  正常情况下的手工切换：两者双活切换速度都非常快，业务应用软件不会有感知。

l  非正常情况下的自动切换：我们在3par拷贝大文件的时候做过暴力测试，在使用了远端仲裁服务器仲裁的情况下，拷贝操作暂停了2~5秒的时间，然后继续进行，操作没有中断。这个延时是由仲裁服务器需要对两个存储状态进行判定必须的代价。所有仲裁服务器为了防止误判，都会需要一段时间延时来判定存储状态。XP双活也不例外。

2.        两个阵列同时处理主机IO，均衡负载问题：

l  虽然两个阵列可以同时处理主机IO，但是为了保持数据一致，这些IO中的写操作必须同步到另外一个阵列上。也就是说下图中的第2和第3步骤无法节省。只有第1和第4步骤节省了传输时间。但是，双活因为复杂的锁机制带来了阵列内部软件处理时延。这个时延是否能够抵消第1和第4步骤的传输时间节省，值得商榷。还有一点需要特别注意的是：随着系统负荷增长，IO流量越大，处理时延越长。

l  一般而言，一个阵列上往往存有多个应用的数据，把这些应用数据分组，分别设置不同主存储可以达到手工负载均衡的效果。但是要注意：一个应用的数据必须设置到一个组里面，不可以通过分组设置不同的主存储。