Netapp 两节点双活VS本地HA

介绍一些Netapp存储涉及双活架构时的经验。

标准架构-四节点MCC

这是Netapp的四节点Metro Cluster（MCC）架构，也就是标准架构。

每个站点是由一台双控的存储组成。实现双活，需要用到4个交换机（可以是FC光纤交换机，也可以是IP以太网交换机）。其中如果使用到FC光纤交换机的话，还需要额外磁盘转接器，需要的组件会更多，如下图。

PS：这套交换机（4台）最好是专用于双活复制。但实际项目中，也见过和其他业务复用交换机的情况，对业务运行没有影响。

介绍几个小知识。

MCC切换时间

aggr的plex0和plex1是完全镜像的数据，但平时只有0是活的，1是备用的，平时看不到状态信息，除非发生切换。因此，MCC的双活是有方向的。切换时，会发生从备变主这个动作，**而这是需要时间的，对业务的容忍度有要求。**而有些存储双活技术能做到几乎无感。这是技术原理上的不同导致。

磁盘聚合Aggregate

Netapp存储的每个节点都可以像一台独立的存储一样单独工作。磁盘从聚合层开始就会分开。 A1，A2、B1、B2 4个节点都有属于自己的磁盘聚合，相当独立。而更常见的存储做法，首先是把所有的同类型硬盘做成统一的池。

高可用性

FC MCC：

A1/A2 互相可以接管，B1/B2 互相可以接管；A1故障，A2可以接管，A1和A2故障，B1和B2接管；A1,A2,B1 都故障，B2 接管所有业务。

IP MCC：

最多可以允许两个节点损坏。A1、A2两个节点同时损坏，此时A1、A2业务由B1、B2接管。此时B1不能再损坏。

两节点MCC架构

可能正是由于节点之间高度的独立性，还有一种总共由两个节点构成的MCC方案，如下图。一个站点的存储只由一个控制器构成，即单控存储，没有HA。

这种架构的神奇之处在于，中间的4台交换机和其他组件都不需要了。直接用SAS线就可以把两台存储连起来。

同样可以组成一套MCC双活，性能和标准的MCC一样。详细的连线图如下：

一个有趣的问题

因为两节点MCC方案的存在，带来一个问题。如果想购买Netapp存储，且只打算买两台控制器节点的话，会出现两种预算相近的方案。

两节点MCC
普通HA（可以再配低端存储做备份）

这两者该怎么对比呢？

技术本身差异

HA（High Availability）是存储本地两个控制器之间的高可用切换功能，是最基本的存储功能，哪怕是最低端的企业存储都会提供。

双活是分别位于两个站点（不同的数据机房或者同一个数据机房）的两台存储间的切换，相比于HA，需要额外处理的环节和内容增多，至少包含以下内容：

管理仲裁服务器
站点间的peer心跳机制
链路状态

等等。

MCC切换时间

双活站点的切换时间随着距离站点之间的距离变远，也会变长。需要注意的是，它的预估切换时间下限比较高。按官方说明，最低是60秒，最高是120秒。而我在实验室本地部署的双活环境中见过的最长切换时间是47秒。

一套MCC站点的切换具体需要多少时间只有在生产中测试才能知道，而应用能够容忍多长时间的断开而不影响业务连续性是因应用而异的。

HA切换时间

尽管Netapp的官方承诺切换时间是0~120秒。但从我实际操作过的多次本地控制器切换（takeover/giveback），时间会快不少，有时或许10秒内就完成了。

影响HA的切换时间的因素主要是当时业务的负载。

成功率

HA的切换成功率是非常高的，印象中没有遇到过无法接管的情况，（不仅仅是Netapp，其它品牌存储表现也类似。）

而双活不同，下表是我在数次双活测试中遇到过的切换不成功的案例（针对在SAN上部署的Oracle业务，涉及多种不同品牌）

测试场景名称	测试方法	失败现象
服务器到主存储FC路径失效-光纤链路断开	拔线	3分钟后oracle主机重启
主存储故障-光纤链路断开	拔掉主存储所有光纤线	3分钟后oracle主机重启
主存储故障-光纤链路断开	主存储shutdown关机	3分钟后oracle主机重启
备存储故障-光纤链路断开	拔掉备存储所有光纤线	3分钟后oracle主机重启
备存储故障-光纤链路断开	备存储shutdown关机	3分钟后oracle宕机

除了测试，生产中也遇到过关键时刻双活存储没能完美切换的例子，甚至包括了相当特殊的情况，例如：光纤损坏了，但又没完全损坏，业务处于时断时续状态，同样导致双活切换不成功，同时还有性能衰减。

可以断言，双活切换的成功率相对HA，一定是要低的。

总结

	两节点MCC双活	HA
描述	单控双活，会损失控制器的切换速度和稳定性。从单站点内的切换，降级成站点切换效果	双控单台，会损失存储级故障的防灾能力。
对应故障域	站点存储整体故障互联链路仲裁等	单存储控制器磁盘聚合
切换成功率	非100%，有些情况下切换不成功	几乎100%
磁盘聚合划分	每节点至少2个，1个是自己的，1个是双活对端节点的镜象	每节点至少1个
数据保护	所有数据均为双份且内容一致	单份，通常地对特定卷进行Snapmirror异步备份，生成副本
磁盘可用空间	因两站点要求配置完全一样。可用空间为物理配置的50%	和实际一致，若对部分业务做备份，综合可用空间大于50%，不做备份则为100%
RTO	官方60_{120s，实测47s}70s，对业务容忍度要求较高站点距离远近有影响（带宽、延时）	官方0~120s 与负载状况有关，明显比MCC快
RPO	0	5分钟基于Snapmirror实现异步复制，最短同步间隔为5分钟若决定将备份卷拉起作为生产使用，需要按照一定的操作步骤进行

最终的结论，自然是没有标准答案。

条件有限的情况下，能确定的是不可能各个层面都兼顾。一方面结合业务需求，或许会出现应用层解决方案能和存储架构协同配合，另一方面，用户势必要做出权衡取舍——筹码压在哪里，更重要的是数据安全性、实时性，还是业务连续性，又或者是有更多空间，从而提供更大的灵活性呢？

经过思维洗礼，道路终会浮现的。

备注

RTO：Recovery Time Objective，复原时间目标，是企业可容许服务中断的时间长度

RPO：Recovery Point Objective，复原点目标，是指当服务恢复后，恢复得来的数据所对应的时间点