深入剖析Clustered Metro Cluster双数据中心存储方案

      Clustered Metro Cluster(简称MCC)是Netapp Data Ontap提供的存储双活解决方案，当初的方案是把1个FAS/ V系列双控在数据中心之间拉远形成异地HA Pair，每站点只有单控制器节点，数据中心两站点之间通过额外的FC/VI集群适配器相连，数据中心间SAS磁盘框通过SAS转FC的FibreBridge相连。在500米以内、同一个机房采用直接光纤通道交换机连接；在500米以上(最远100km)采用光纤通道和DWDM交换机相连。

      MetroCluster在此架构上也进行了演变。通过在站点A、B两个站点分别放置两套FAS/ V双控阵列，阵列A的A控和阵列B的A控，阵列A的B控和阵列B的B控分别形成集群，这样可以充分把A、B站点数据中心资源充分利用，同时对外提供存储服务；但阵列内的A、B不是集群。如果站点间形成集群Pair的任意一个控制器节点故障，故障站点的主机都需要远程访问远端控制器节点；如何站点间形成集群Pair的两个节点同时故障，就会发生业务中断。

      Netapp Data Ontap8.3版本推出了4控双活解决方案，最远支持200公里距离，4控Metro Cluster方案首先由2个HA Pair组成2个本地集群，然后再从2个集群上做4节点集群。集群控制器之间内存日志通过存放在NVRAM里面，NVRAM对没有下盘的日志做了镜像，保证节点故障以后，HA Pair集群的Partner节点能够接管业务；或者站点故障以后，远端HA Pair集群能够接管业务。当日志到达一定水位或者发生系统操作刷盘时，下盘数据同步通过SyncMirror实现主从站点双写，从而确保一个站点磁盘故障以后，另外一个站点磁盘还能提供系统访问，实现站点故障切换，保证业务不中断。

      MetroCluster使用两个不同地点的镜像和集群来保护数据，每个集群把数据和Storage Virtual Machine (SVM) 配置都镜像同步另一个集群。当某个站点发生灾难时，管理员可以激活远端SVM并在另一站点接管业务。此外，每个集群在本地节点均配置为HA Pair，从而提供了本地故障转移能力。

      NetApp MetroCluster是以NetApp SyncMirror是配合Cluster_remote和控制器Cluster Failover的功能实现的。

• Clustered Failover – 在主存储和容灾存储间提供高可用性失败恢复能力，故障接管的决策是由管理员通过单一命令行决定的。

• SyncMirror – 为远端存储提供即时的数据拷贝，当故障接管时，数据可以仅通过远端的存储进行访问。

• ClusterRemote – 提供管理机制用以判断灾难的发生并初始远端存储进行接管。

      MetroCluster里面涉及几类数据同步，包括两个集群配置同步，NVRAM的日志同步，以及后端磁盘同步，系统里面这3类数据同步采用不同的网络。

• 1）两集群配置同步网络：通过专用冗余TCP/IP网络，由CRS (Configuration Replication Service)服实时同步两个集群的配置数据，确保集群一端修改的配置，如新增IP，SVM或者新增，删除用户共享等配置操作，能够自动同步到远端HA Pair集群。

• 2）NVRAM日志同步：使用冗余FV-VI，FC-VI支持RDMA，支持Qos等功能，用于两个集群间的NVRAM同步和心跳，既能保证心跳的优先级，同时又能减少数据的写IO的传输次数，因为RDMA支持批量获取一组地址空间技术，批量获取一组地址以后，后面就直接传输数据，讲FC协议2次写优化成接近1次。

• 3）后端数据下盘双写网络：数据传输采用FC网络，需要进行FC和SAS转换(FibreBridge)，用指定思科和博科型号专用交换机连接两个站点后端磁盘，并完成协议转换。

      MetroCluster的4节点集群还是AP模式，同一时刻，文件系统还是只能提供给组成集群HA pair集群的一个节点，只有当这个节点故障以后，HA pair的Partner节点才会接管提供业务，或者当整个站点故障以后，从站点HA pair集群才会接管业务，站点切换可以通过手动执行CFOD命令或者通过TieBreak仲裁软件触发自动切换。

      MetroCluster内存数据镜像方式(如下图所示)，每个节点的NVRAM会被分成4个部分，分别用于存取节点自己的日志，HA Pair Partner日志，以及远端HA Pair的日志信息。当本地控制器故障后，优先将业务切换到HA Pair节点上，只有当整个站点故障后，业务才切换到远端站点运行，即当发生站点切换以后，主节点全部切换到从站点里提供业务。

      两个站点各自的集群有各自的RDB(Replicated Database)，用于存放集群的配置日志数据，如果系统有新的配置修改产生，会生成新的配置日志，首先会存放到MDV(Metadata Volume)里面，然后由系统的CRS将MDV里面配置日志同步到主从站点的RDB里面。

      由于日志写完MDV以后才会更新到RDB中，链路从中断恢复后，可以通过重放最新日志的MDV日志卷将差异配置进行同步。在链路中断的状态中，允许发生主从切换，切换以后，通过存活站点的MDV日志重放来获取更改的配置。

• MDV(Metadata Volume)用于存放配置修改日志，创建在非root aggregate的上的卷，在配置Metacluster的时候生成，每个集群一个，容量默认10GB。  

• CRS(Configuration Replication Service)每个集群都运行一个CRS服务，CRS服务负责将主站点的Metadata配置日志，也就是存在MDV里面的日志复制到从节点的RDB里面。

      SyncMirror是Netapp双活的核心数据同步技术，在NVRAM日志下盘时，实现主从站点的盘的双写，SyncMirror工作在Aggregate层上(镜像的Aggregate由两个Plex组成，分别来自本地Pool的Plex0和远端Pool的Plex1)，当有日志刷盘时，SyncMirror会写完本地的pool 的plex0和远端pool的plex1以后，才返回写结果。

      Plex在站点内单边故障的时候，通过Aggregate的快照来进行增量恢复，默认Aggregate里面预留空间用于做Aggregate的快照，作为Aggregate重新同步的基准数据。如果没有做快照，一个Plex故障以后恢复，需要做全量同步。

      MetroCluster的仲裁软件TieBreak支持装在linux的主机上，通过检查对节点Ssh的session对HA pair和集群进行状态监控。TieBreak 软件能够在3到5秒内检查到ssh session的故障，重试的时间间隔为3秒。

      实际上MetroCluster集成了NetApp Cluster、SyncMirror、RAID DP等多重数据保护能力，这些数据保护功能在整体方案中负责保障不同级别数据安全和可靠，下图显示了该方案能提供的故障容忍能力。再加上上层业务层的集群保障，如Oracle RAC、VCS/MSFC、vMSC等，在集群主机一半故障时，也能正常提供业务。

      为了更好理解上文提到的Aggregate，这里简单介绍下NetApp FAS系列产品Data Ontap底层结构。首先基于不同RAID组成组成Pool(Plex)，基于Plex形成Aggregate和基于ROW技术和WALF技术的FlexVol，再基于FlexVol和Qtree实现NAS和SAN语义。利用NVRAM用来保存日志，并把进行合并后满分条下盘，提升系统性能。

      MetroCluster底层以Aggregate为粒度进行数据同步，以SVM为单位进行业务切换，天然支持SAN和NAS的存储双活方案。但是ROW和WALF的碎片和SAN性能一直被诟病。聚焦存储双活本身，MetroCluster在网络架构上可能是所有双活方案最复杂的，但是NAS和SAN一体化双活却能很好地契合应用对RTO和RPO约为零的要求，如SAP HANA集群部署应用等。

温馨提示：
请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号，获取更多精彩内容。

听说点赞和分享的朋友都已走上人生巅峰