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