云计算让开发人员和 IT 部门可以全身心投入最有价值的工作，避免采购、维护、容量规划等无价值的工作分散精力。云计算已经日渐普及，并拥有了几种不同的模型和部署策略，以满足不同用户的特定需求。每种类型的云服务和部署方法都提供了不同级别的控制力、灵活性和管理功能。理解基础设施即服务、平台即服务和软件即服务之间的差异，以及可以使用的部署策略，有助于根据需求选用合适的服务组合。

云计算模型

云计算的模型主要有三种。每种模型代表着云计算堆栈的一个独特部分。

基础设施即服务 (IaaS)

基础设施即服务有时缩写为 IaaS，包含云 IT 的基本构建块，通常提供对联网功能、计算机（虚拟或专用硬件）以及数据存储空间的访问。基础设施即服务提供最高等级的灵活性和对 IT 资源的管理控制，其机制与现今众多 IT 部门和开发人员所熟悉的现有 IT 资源最为接近。

平台即服务 (PaaS)

平台即服务消除了组织对底层基础设施（一般是硬件和操作系统）的管理需要，让您可以将更多精力放在应用程序的部署和管理上面。这有助于提高效率，因为您不用操心资源购置、容量规划、软件维护、补丁安装或与应用程序运行有关的任何无差别的繁重工作。

软件即服务 (SaaS)

软件即服务提供了一种完善的产品，其运行和管理皆由服务提供商负责。人们通常所说的软件即服务指的是终端用户应用程序。使用 SaaS 产品时，服务的维护和底层基础设施的管理都不用您操心，您只需要考虑怎样使用 SaaS 软件就可以了。SaaS 的常见应用是基于 Web 的电子邮件，在这种应用场景中，您可以收发电子邮件而不用管理电子邮件产品的功能添加，也不需要维护电子邮件程序运行所在的服务器和操作系统。

云计算部署模型

云
-

基于云的应用程序完全部署在云中且应用程序的所有组件都在云中运行。云中的应用程序分为两种，一种是在云中创建，另一种是从现有基础设施迁移到云中以利用云计算的优势。基于云的应用程序可以构建在基础设施组件上，也可以使用较高级别的服务，这些服务提供了从核心基础设施的管理、架构和扩展要求中抽象提取的能力。

混合

混合部署是一种在基于云的资源和非云现有资源之间连接基础设施和应用程序的方法。混合部署最常见的方法是在云和现有内部基础设施之间将组织的基础设施扩展到云中，同时将云资源与内部系统进行连接。有关 AWS 如何帮助部署混合云的更多信息，请访问混合页面。

本地

使用虚拟化和资源管理工具在本地部署资源往往被称作“私有云”。本地部署无法提供云计算的诸多优势，但有时采用这种方案是为了能够提供专用资源。大多数情况下，这种部署模型与旧式 IT 基础设施无异，都通过应用程序管理和虚拟化技术尽可能提高资源利用率。

zabbix也可以监控VMware虚拟化，支持VMware vCenter或vSphere版本最低为4.1。

以下配置文件参数可用于调整虚拟机监控：

StartVMwareCollectors - 预先启动Vmware collector收集器实例的数量。
此值取决于要监控的VMware服务的数量。在大多数情况下，这应该是：
servicenum < StartVMwareCollectors < (servicenum * 2)其中 servicenum 是 VMware 服务的数量。例如：如果您有1个VMware服务，请将 StartVMwareCollectors 设置为 2，那么果您有 3 个 VMware 服务，请将其设置为 5。请注意，在大多数情况下，此值不应小于 2，不应大于 VMware 数量的 2 倍服务。还要记住，此值还取决于 VMware 环境大小和 VMwareFrequency 和 VMwarePerfFrequency 配置参数。
VMwareCacheSize - 用于存储VMware数据的缓存容量，默认为8M，取值范围：256K-2G。
VMwareFrequency - 接到VMware服务收集一个新数据的频率，默认为60秒，取值范围：10-86400。
VMwarePerfFrequency - 连接到VMware服务收集性能数据的频率，默认为60秒，取值范围：10-86400。
VMwareTimeout - VMware collector等待VMware服务响应的时间，默认为10秒，取值范围：1-300。

1，配置服务器

vi /etc/zabbix/zabbix_server.conf

修改如下：

StartVMwareCollectors=20
VMwareFrequency=60
VMwarePerfFrequency=60
VMwareCacheSize=2G
VMwareTimeout=60

然后重启服务

systemctl restart zabbix-server

查看日志，确定VMware监控相关组件是否启动：

cat /etc/zabbix/zabbix_server.conf

2，添加vcenter

填写主机名称，群组选择Templates/Virtualization，IP地址即为vcenter 的IP，端口写80

单击模板，在链接指示器中选择Template VM VMware，添加到链接的模板

单击宏，填写如下内容

{$USERNAME}：vcenter超管
{$PASSWORD}：vcenter超管密码
{$URL}：https://vcenterip/sdk

单击添加，vcenter主机添加成功

3，配置自动发现

点击自动发现

可以看到默认的监控模板每隔一个小时扫描一次，这里我们可以修改间隔

也可以点击现在检查，立即发现虚拟化资源

此时到主机里，可以看到，已经自动扫描到了esxi主机和集群内所有的虚拟机

4，配置图形界面

从上图可以看出，自带的模板是一个图形界面都没有。

a，创建主机监控图形界面

点击 配置--模板，选择Template VM VMware Hypervisor，单击图形，点击右上角的创建图形
填写名称：Esxi Resource information，宽、高可以默认也可自定义，监控项根据需求自行选择，我这里全选了

单击添加，esxi主机的图形界面创建完毕

b，创建虚拟机监控图形界面

点击 配置--模板，选择Template VM VMware Guest，单击图形，点击右上角的创建图形
填写名称：VM OS information，宽、高可以默认也可自定义，监控项根据需求自行选择，我这里全选了

单击添加，虚拟机资源监控图形创建完毕。

5，查看图形界面监控资源

主机资源

虚拟机资源

zabbix很强大，自定义功能更是厉害。如果花点时间研究一下，我觉得可以满足大部分的使用场景。

模拟的hpc环境需要用户在集群内漫游登录。

一，配置NIS服务器

此处mgmt为nis server，node1-node4为nis client，并确保 /etc/hostname的名称和/etc/hosts映射的名称一致

1，配置selinux

在集群内所有机器上执行下面命令然后重启。

sed -i '/SELINUX/s/enforcing/disabled/' /etc/selinux/config

确保selinux 的状态为disabled

2，关闭防火墙

systemctl stop firewalld
systemctl disable firewalld

3，安装nis服务端软件

yum -y install ypserv rpcbind

4，配置nis域名

nisdomainname mgmt
echo "nisdomainname mgmt"  >> /etc/rc.local
chmod +x /etc/rc.d/rc.local
echo "NISDOMAIN=mgmt" >> /etc/sysconfig/network

5，配置nis端口

echo 'YPSERV_ARGS="-p 1011"' >> /etc/sysconfig/network
echo 'YPPASSWDD_ARGS="--port 1012""' >> /etc/sysconfig/network

重启ypserv服务并加入开机自启

systemctl restart rpcbind
systemctl restart ypserv
systemctl restart yppasswdd
systemctl enable rpcbind
systemctl enable ypserv
systemctl enable yppasswdd

6，查看ypserv服务

rpcinfo -p localhost
rpcinfo -u localhost ypserv

出现以上信息，则服务端配置正常。

7，初始化ypserv数据库

/usr/lib64/yp/ypinit -m

输入ctrl+d，然后输入y

8，新建用户

新建4个用户

adduser user1
adduser user2
adduser user3
adduser user4

修改用户的密码

echo user1 | passwd --stdin user1
echo user2 | passwd --stdin user2
echo user3 | passwd --stdin user3
echo user4 | passwd --stdin user4

如果需要实现普通账户在其他主机免密登录，则需要如下操作：

登录普通账户，

ssh-keygen -t rsa
cd /home/user1/.ssh/
cat id_rsa.pub >> authorized_keys
chmod 600 authorized_keys

8，更新NIS账户和资料库

make -C /var/yp

每次新建账号都需要执行此命令

二，配置nis客户端

1，安装nis客户端软件

yum install -y rpcbind yp-tools ypbind

2，设置nis域名

nisdomainname mgmt
echo "nisdomainname mgmt"  >> /etc/rc.local
chmod +x /etc/rc.d/rc.local
echo "NISDOMAIN=mgmt" >> /etc/sysconfig/network

3，修改/etc/nsswitch.conf

sed -i '/passwd:/s/sss/nis/' /etc/nsswitch.conf
sed -i '/shadow:/s/sss/nis/' /etc/nsswitch.conf
sed -i '/group:/s/sss/nis/' /etc/nsswitch.conf
sed -i '/hosts:/s/dns myhostname/nis dns/' /etc/nsswitch.conf

4，配置nis认证

输入setup

选择 Authentication configuration，然后回车

选择Use NIS，Use Shadow Passwords，Local authorization is sufficient，然后选择Next

配置domain和server，选择OK，然后退出即可。

5，启动nis服务并加入开机自启

systemctl restart rpcbind
systemctl restart ypbind
systemctl enable rpcbind
systemctl enable ypbind

6，测试

输入yptest

出现了我们在mgmt管理节点新建的4个用户，表示nis配置正常。

7，测试登录

su - user1

正常登录，但是提示warning: cannot change directory to /home/user1: No such file or directory，未在node1上找到user1的home 家目录，user1的home在mgmt的/home下，如何在登录user1的的时候，home也能正常使用呢。
有两种方法：

a，把mgmt 的/home 共享，然后在node1-node4上永久挂载
b，把mgmt 的/home共享，在用户登录的时候自动挂载用户的目录

显然，第二种方法更高效，使用的时候会自动挂载，一定时间范围内不用的话，会自动卸载，下次使用再次自动挂载。

三，安装配置autofs

1，安装autofs

yum install -y autofs

2，编辑/etc/autofs配置文件

vi /etc/auto.master

添加以下一行

/home   /etc/auto.nfs --timeout=60

autofs 的配置文件有三部分
第一部分/home 表示挂载点为/home，第二部分指定该挂接点的配置文件为/etc/auto.nfs，第三部分指定所挂接的文件系统在空闲60秒后自动被卸载。

vi /etc/auto.nfs

编辑如下

*   -fstype=nfs mgmt:/home/&

*是什么，&就是什么，后向引用，比如，把user1的家目录/user1挂载到/home/user1下

3，开启autofs服务并加入开机自启

systemctl start autofs
systemctl enable autofs

4，测试用户登录

测试之前先df -h 以下

su - user1

df -h

su - user2

df -h 自动挂载了user2的目录。

登录四个用户以后

可以看到自动挂载了4个用户的目录,60秒内，账户不活动的话，会自动卸载。

一，添加RHEL/CentOS主机

此处以CentOS7.4为例

1，配置zabbix YUM

rpm -ivh https://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-1.el7.noarch.rpm
yum clean all
yum makecache

2，安装配置agent

yum install -y zabbix-agent
systemctl start zabbix-agent

编辑/etc/zabbix/zabbix_agentd.conf 修改如下

LogFileSize=5
Server=192.168.80.112
ServerActive=192.168.80.112
Hostname=linux-001

systemctl restart zabbix-agent
systemctl enable zabbix-agent

参数说明：

PidFile=/run/zabbix/zabbix_agentd.pid 
LogFile=/var/log/zabbix/zabbix_agentd.log
LogFileSize=5 （设置zabbix日志当到达5M时自动回滚，0表示disabled）
Server=<zbx-server的ip>
ListenPort=10050
ServerActive=<zbx-server的ip> 在这里可以改变端口号
Hostname=<本机的名字>
Timeout=30
AllowRoot=1 （设置是否允许以root用户启动，值有1和0，0表示禁止以root用户启动）
UnsafeUserParameters=1 （设置是否允许自定义监控，值有1和0，0表示disable）
EnableRemoteCommands=1 （设置是否允许来自zabbix server端的远程命令，值有1和0,0表示不允许）
LogRemoteCommands=1 （设置是否允许日志文件以warning级别记录来自zabbix server端的远程命令，值有1和0,0表示disabled）

3，开放防火墙端口，如果彻底禁用了防火墙，则不需要

firewall-cmd --zone=public --add-port=10050/tcp --permanent
firewall-cmd --reload

3，登陆zabbix-server Web界面

点击 配置——主机——创建主机，填写主机名称，选择群组Linux servers，填写主机的IP地址

点击模板，在链接指示器中选择Template OS Linux，点击添加，单击添加

ZBX变为绿色，即正常

二，添加Ubuntu/Debian主机

此处以Ubuntu18.04为例

1，安装agent

sudo apt-get install zabbix-agent

安装完会自动启动，且开机会自动启动

2，编辑agent配置文件

sudo vi /etc/zabbix/zabbix_agentd.conf

LogFileSize=5
Server=192.168.80.112
ServerActive=192.168.80.112
Hostname=ubuntu-001

sudo service zabbix-agent restart

3，添加主机

添加Ubuntu过程和RHEL/CentOS无差别。

三，添加Windows主机

此处以Windows10为例

1，下载安装agent

打开https://www.zabbix.com/cn/download_agents，根据zabbix server版本下载对应的agent

安装过程中配置zabbix server 的IP地址

2，配置防火墙，在入站规则添加开放10050的规则，如果防火墙彻底被禁用，则不用操作

3，添加主机

群组选择Templates

点击模板，链接指示器选择Template OS Windows，点击添加

点击下面的添加，提示添加主机成功

监控界面

所有的主机

浅入的研究了下，zabbix能监控的项目非常多，但是自带的模板可能无法满足不同的客户需求，这时候就需要自己定义模板，并建立报警机制，个人精力有限，这些就不做尝试了。

具体的配置教程参考这里https://www.zabbix.com/documentation/4.0/zh/manual

RAS - Reliability, Availability and Serviceability

本文转载自网络

Reliability: 可靠性。指的是系统必须尽可能的可靠，不会意外的崩溃，重启甚至导致系统物理损坏，这意味着一个具有可靠性的系统必须能够对于某些小的错误能够做到自修复，对于无法自修复的错误也尽可能进行隔离，保障系统其余部分正常运转。

Availability：可用性。指的是系统必须能够确保尽可能长时间工作而不下线，即使系统出现一些小的问题也不会影响整个系统的正常运行，在某些情况下甚至可以进行 Hot Plug 的操作，替换有问题的组件，从而严格的确保系统的 downtime 时间在一定范围内。

Serviceability：指的是系统能够提供便利的诊断功能，如系统日志，动态检测等手段方便管理人员进行系统诊断和维护操作，从而及早的发现错误并且修复错误。

RAS 作为一个整体，其作用在于确保整个系统尽可能长期可靠的运行而不下线，并且具备足够强大的容错机制。这对于像大型的数据中心，网络中心如股票证券交易所，电信机房，银行的数据库中心等应用环境是不可或缺的一部分。

ECC内存技术

ECC (Error Detection Code) - 错误检查和纠正。在数据位上额外的位存储一个用数据加密的代码，称为ECC码。ECC码将信息进行8比特位的编码，采用这种方式可以恢复1比特的错误。每一次数据写入内存的时候，ECC码使用一种特殊的算法对数据进行计算，其结果称为校验位（check bits）。然后将所有校验位加在一起的和是“校验和”（checksum），校验和与数据一起存放。当这些数据从内存中读出时，采用同一算法再次计算校验和，并和前面的计算结果相比较，如果结果相同，说明数据是正确的，反之说明有错误，ECC码则会被解码，以确定数据中的那一位是不正确的。然后这一错误位会被改正过来不影响系统运行。

ChipKill技术

ECC内存技术虽然可以同时检测和纠正单一比特错误，但如果同时检测出两个以上bits数据有错误，则无能为力。IBM的Chipkill 技术是利用内存的子结构方法来解决这一难题，弥补ECC的不足。Chipkill内存控制器所提供的存储保护在概念上和具有校验功能的磁盘阵列类似：在写数据的时候，把数据写到多个DIMM内存芯片上。这样，每个DIMM所起的作用和存储阵列相同。如果其中任何一个芯片失效了，它只影响到一个数据字节的某一比 特，因为其他比特存储在另外的芯片上。出现错误后，内存控制器能够从失效的芯片重新构造“失去”的数据，使得服务器可以继续正常工作。

Memory ProteXion / RBS

Memory ProteXion（内存保护，也称“冗余位迁移(RBS)”）是IBM的一项内存纠错技术，最初是为IBM大型机所开发的。它相对前面介绍的Chipkill内存技术在保护能力上更强些。它的工作方式与Windows NTFS 文件系统中热备用磁盘扇区有些类似，如果操作系统检测到磁盘上有坏扇区，它将把数据写到备用扇区以实现这一目的。

SDDC 和DDDC

英特尔提供了与ChipKill类似的功能，叫做单设备数据校正(Intel x4 / x8 SDDC) 。可修正单个DRAM设备上的多比特位错误，将单个 DRAM 从内存映射中删除，并将 DRAM 数据恢复至新设备，以快速修复整个 DRAM 设备的故障。在出错的DRAM从内存映射中被删除后，还可以继续进行单比特位数据校正。

DDDC是双设备数据校正。允许纠正双位硬件内存错误。确保当一个DIMM上的二个DRAM芯片发生多比特位错误时也能修复产生的错误，将出错的DRAM从内存映射中删除，并将修复好的数据恢复至新设备。 在出错的DRAM从内存映射中被删除后，还可以继续进行单比特位数据校正。

Memory Scrubbing

ECC只有在写入数据时才会产生，并且只有当从内存读取数据的时候，ECC模块才会去读取ECC校验码，并对照相同与否来发现出现的错误。但是，错误可能发生在还没有被访问到的内存位置，如果这种错误累积，就会导致无法修复的多比特位错误，进而导致数据损坏甚至系统崩溃。内存检查（Memory Scrubbing）是Intel的内存检查技术，引入一个嵌入式硬件引擎，不断地监测并修复出现的内存错误，从而可确保不会造成错误积累到不可修复的程度。

Memory Mirroring 内存镜像

内存镜像(Memory Mirroring) 采用两组DIMM互为镜像的方式形成一种备份机制，工作原理与RAID1硬盘类似，内存镜像是将内存数据做两个拷贝，分别放在主内存和镜像内存中。

正常工作情况下，内存数据读取只从活动内存卡中进行。只是当活动内存出现故障，内存保护和Chipkill修复技术都不能完全修复，才会从镜像内存中读取数据。如果一个内存中有足以引起系统报警的故障，系统会报告系统管理员；同时服务器就会自动地切换到使用镜像内存卡，直到这个有故障的内存被更换。镜像内存允许进行热交换（Hot swap）和在线添加（Hot-add）内存。

因为镜像内存采用的的两套内存中实际只有一套在使用，另一套用于备份，所以对于软件系统来说也就只有整个内存的一半容量是可用的。

Memory Sparing 内存备用

内存备用(Memory Sparing) 可以实现以DIMM为单位或是以Rank为单位的内存备用。当一个Rank或是DIMM将要失效（错误超过阈值）时，就会启动备用的Rank或DIMM，同时对出错的和备用的Rank或DIMM写入数据，当所有数据全部转移至备用Rank或DIMM后，将出错的Rank或DIMM关闭，切换至备用的Rank或是DIMM上，以避免系统的停机。内存备用(Memory Sparing)不能与内存镜像(Memory Mirroring)同时使用。

LockStep技术

内存通道的访问可分为独立通道模式（Independent Channel Mode）和精确同步模式（LockStep Channel Mode）。独立通道模式是指每个通道（Channel）独立运行，一个内存通道对应CPU的一个高速缓存行（Cache-line）。而LockStep技术使用相同的、冗余的硬件组件在同一时间内处理相同的指令，从而实现一个CPU高速缓存行（Cache-line）上的数据被分布到几个内存通道上。LockStep技术可以保持多个CPU、内存精确的同步，在正确的相同时钟周期内执行相同的指令。该技术保证能够发现任何错误，即使短暂的错误，系统也能在不间断处理和不损失数据的情况下恢复正常运行。LockStep也称锁步，或高级ECC。

Memory Interleaving 交叉存取技术

Memory Interleaving交叉存取技术是加快内存速度的一种技术 。 在典型的服务器系统中，大量连续的内存访问可能是性能瓶颈，因为内存访问时延会带来等待时间。 交叉存取技术是一种并行操作的内存存取，内存被分为一系列的簇，有多少个簇就叫做几路交叉存取。它的原理类似于RAID0技术。在交叉存取方式中，相邻位置的内存数据是被分在不同的块中，只要读写操作是要在两个块中进行的，它们就可以同时进行，从而有效地提高系统性能 。

Memory Hemisphere Mode

Hemisphere模式是一种高性能的交错模式。CPU内两个内存控制器之间的内存交错存取，处理器的Caching Agent 1不会访问其Home Agent 2，从而达到降低内存延迟(Latency)，提高内存呑吐量，提高性能的目的。Hemisphere模式要求两个内存控制器之间的内存配置在DIMM规格和DRAM大小上完全一致。

UMA和NUMA

一致存储器访问（UMA）结构体系有时也被称为SMP(Symmetric Multi-Processor )模式。SMP模式将多个处理器与一个集中的存储器和I/O总线相连。所有处理器只能访问同一个物理存储器。一致性意指无论在什么时候，处理器只能为内存的每个数据保持或共享唯一一个数值。SMP的缺点是可伸缩性有限，因为在存储器和I/O接口达到饱和的时候，增加处理器并不能获得更高的性能。

NUMA（non-uniform memory access）是一种分布式存储器访问方式，处理器可以同时访问不同的存储器地址，大幅度提高并行性。 NUMA模式的基本特征是具有多个CPU模块，每个CPU模块由多个CPU组成，并且具有独立的本地内存、I/O槽口等。由于其节点之间可以通过互联模块(如称为Crossbar Switch)进行连接和信息交互，因此每个CPU可以访问整个系统的内存(这是NUMA系统与MPP系统的重要差别)。访问本地内存的速度将远远高于访问远地内存(系统内其它节点的内存)的速度，这也是非一致存储访问NUMA的由来。

预测故障分析

Predictive Failure Analysis预测故障分析。其关键任务目标是最小化非计划宕机时间。PFA(预测故障分析)会监控系统自身健康情况，并在失效实际发生前产生告警的能力。

Machine Check Architecture

Intel RAS集中解决三个方面的问题：一是数据保护，利用CRC、ECC等硬件机制来对传输的数据进行校验、纠错，如果无法纠正，就将损坏的数据进行隔离，以保证不造成更大的数据，避免系统的重启和宕机。二是高可用性，包括各种主要部件的备、镜像和热切换等，以保证系统的高可用性。三是计划宕机时间最小化，包括系统分区管理技术、CPU和内存的热添加和热移除等，将系统维护时间降低到最小。

除此之外，Intel建立了一个CMCI架构，以保证纯硬件的数据纠错，在硬件层保障信号传输的正确性。

当发生硬件无法完全纠正的错误的时候，Intel 进而提供了一系列需要联合OS/firmware进行的错误隔离以及错误恢复。对无法纠正的数据，使用一个Poison（毒药）标记，OS/firmware可以知道这些数据在硬件层次上无法恢复，从而可以决定进行Retry或者丢弃。

这些特性形成了一个完整的MCA架构（Machine Check Architecture）。MCA功能可以在不关机的情况下检查和纠正处理器、内存或者IO中的错误，在OS配合的情况可以对系统进行热维护，保障系统的不间断运行。微软Windows Server、RedHat、SUSELinux以及VMware等平台都已经支持这一功能。

性能影响问题是存储双活方案的突出问题，因为双活系统在写入数据时，会写两次数据，尤其是通过复制功能写到远端存储的过程，传输链路的性能也会影响整体性能。因此，存储双活不可避免要遇到性能问题，这也是各大厂商存储双活方案标明最大支持 RTT 或者站点间距的原因之一。相比单存储直接提供读写来说，存储双活一定会增加读写响应时间，更别说存储还是跨两个不同数据中心的，随着距离的增加，理论上每增加 100KM ，会增加 1MS 的 RTT （往返延迟时间），通常单个 I/O 总耗时在 1-3MS 左右，就会认为单个存储 I/O 时延处于比较高性能的模式（最大支持的 IOPS 也是存储选型的重要考虑因素），如果加上其他因素，如“数据头处理”和“并发”， 1MS 的“理论”时延增加的影响会成倍增加，将原本处于高性能模式的 I/O 响应时间拉高，对应用或者数据库来说，“变慢”了。所以存储双活的初衷是只是为了高可用性和提高总体并发、吞吐量，并不是为了降低读写响应时间。然而，我们在选型存储双活方案时，依旧需要考虑如何尽量降低双活的存储所带来的性能降低影响，哪种方案会带来较小的性能影响。因此，笔者现就目前国内主流的五种存储双活方案在双活性能上的特点进行解析。

本文转载自微信公众号： talkwithtrend

一、华为 HyperMetro

1 、读 I/O ：针对数据读场景， 华为 HyperMetro 方案架构下， 双活数据中心的业务主机只需要读本数据中心对应的双活存储阵列即可，如下图所示，这样可以有效避免主机跨数据中心读取数据，提升整体读 I/O 访问性能。

2 、写 I/O ：针对数据写场景，业务主机直接写本数据中心对应的双活存储阵列，避免主机跨数据中心转发数据（在转发写模式下，区分主从 LUN ，从 LUN 的写 I/O 将被控制器转发到主 LUN 的控制器处理写 I/O ，并将数据回同步至从 LUN ），充分利用 HyperMetro AA 双活能力，如下图左所示， AA 集群的每个控制器都能够接收写 I/O ，由本地控制器处理本地主机的写 I/O 请求，减少跨数据中心的转发次数，提升方案整体性能。数据写 I/O 过程如下图右所示：

假如数据中心 A 的存储阵列收到写 I/O ，写 I/O 处理流程如下：

（ 1 ）申请写权限和记录写日志：数据中心 A 存储阵列收到主机写请求，先申请双活 Pair 的写权限。获得写权限后，双活 Pair 将该请求记录写日志（保证断点续传）。日志中只记录地址信息，不记录具体的写数据内容。该日志采用具有掉电保护能力的内存空间记录以获得良好的性能。

（ 2 ）执行双写：将该请求拷贝两份分别写入本地 LUN 和远端 LUN 的 Cache 。

（ 3 ）双写结果处理：等待两端 LUN 的写处理结果都返回。

（ 4 ）响应主机：双活 Pair 返回主机写 I/O 操作完成，完成一次写 I/O 周期。

从整个写 I/O 流程可以看出， HyperMetro 为了保证两个数据中心存储的数据实时一致，写操作都需要等待两端存储写成功之后再返回主机“写成功”。双活 I/O 性能因为实时双写导致了一定的时延增加，该写 I/O 流程相较于本地写 I/O 而言，额外增加了以下四个时延点。

（1） 写权限申请时，等待分布式锁产生的时延；

（2） DCL 机制（数据变化记录）产生的时延；

（ 3 ）跨站点将写 I/O 拷贝至远端 LUN Cache ；

（ 4 ）远端 LUN Cache 收到写 I/O 后，将处理结果返回至本地。

这四个时延点中最主要的还是 3 和 4 中组成的 1 倍跨站点往返时延（ RTT ），此外，华为 HyperMetro 设计了一系列 I/O 性能优化方案，以减小对写时延的影响，提升整体双活的业务性能。

（ 1 ）数据零拷贝：在双活镜像数据的初始同步或者恢复过程中的增量同步过程中，差异数据块通常有大量的零数据块，无需逐块复制，该功能叫数据零拷贝。例如，虚拟化场景下，新建虚拟机时会产生大量的零数据块，一个数十 GB 的操作系统盘，实际非零数据块仅 2-3GB 。HyperMetro 零页面识别技术的实现方法如下：通过硬件芯片，对数据拷贝源端进行快速识别，找出零数据，在拷贝过程中，对全零数据特殊标识，只传输一个较小的特殊页面到对端，不再全量传输。相比全量同步，该技术可有效减少同步数据量，减少带宽消耗，缩短整体 I/O 同步时延。

（ 2 ） FastWrite 技术：HyperMetro 通过 FastWrite 功能对阵列间数据传输进行了协议级优化，应用 SCSI 协议的 First Burst Enabled 功能，将写数据的链路传输交互次数减少一半。正常的 SCSI 流程中，写 I/O 在传输的双端要经历“写命令”、“写分配完成”、“写数据”和“写执行状态”等多次交互。利用 FastWrite 功能，优化写 I/O 交互过程，将“写命令”和“写数据”合并为一次发送，并取消“写分配完成”交互过程，将跨站点写 I/O 交互次数减少一半。该技术将单次写 I/O 的 RTT 控制在 1 倍，避免无效交互产生的 RTT 。

（ 3 ）智能的锁预取和缓存策略：本地写 I/O 时，需对主机 I/O 访问的 LBA 区间加分布式范围锁进行并发互斥，通过分布式范围锁，可以避免频繁的锁请求交互，减少跨站点交互交互频率。当 HyperMetro 的分布式锁技术在写权限本地无缓存（范围锁）的情况下，会通过较小的控制报文，向锁权限缓存节点申请写权限，并多预取部分区间的写权限缓存到本地，如下图左所示。后续的连续写 I/O 可快速在本地命中写权限，不需要再跨站点申请写权限，这样将进一步减少交互频率，如下图右所示。

二、 EMC VPLEX

1 、读 I/O ：EMC Vplex 具有读缓存，可以通过写 I/O 的独特机制，实现读 I/O 的加速。Vplex Local/Metro/Geo 架构的读 I/O 流程如下：

（ 1 ）读 I/O 的时候先读 Local Cache ，如命中则直接读取，相较于直接读后端存储阵列，内存较机械硬盘的读取性能有着显著提升，因此，从 Cache 内存中直接命中读 I/O ，将大幅提升读 I/O 性能；

（ 2 ）如果没有命中 Local Cache ，将继续在 Global Cache 中查找，如果命中，则从对应的 Vplex 引擎 Cache 中将其读取到 Local Cache ，因此，两引擎的 VplexMetro/Geo 架构存在 1 倍的跨站点往返时延；

（ 3 ）如果在 Global Cache 中没有命中，则从本地后端的存储阵列中读取到 Local Cache 中，并同时修改 Local 和 Global Cache 中的信息与索引信息（表明其他引擎可以从该引擎 Cache 读取数据），本次读 I/O 加速无效果。

（ 4 ）无论有没有命中 Cache ，最后都将反馈主机读 I/O 结果，本次读 I/O 周期结束。

从整个读 I/O 流程可以看出，相较于常见的后端存储直接读取，由于读 Cache 的存在，对读 I/O 性能的提升是有积极意义的，命中 Local Cache 将提升数倍读响应时间，没有命中 Local Cache 几乎和直接后端存储读取性能一致，在实际联机型应用读写比例大致为 7 ：3 的情况下，提升读 I/O 的效果是显而易见的。

2、 写 I/O ：EMC Vplex 同样也具备“写缓存”， Vplex Metro 没有真实的“写缓存”，实际上是读缓存，用于加速读 I/O ，模式采用的是写直通缓存；Vplex Geo 具有真实的写缓存，模式采用的是回写缓存。其中 Vplex Metro 写 I/O 流程如下图所示：

Vplex Metro/Geo 的写 I/O 步骤如下：

（1） 写 I/O 时先判断是否在 Local 、 Global Cache 中有对应的旧数据，如果没有，则直接写入本地 Local Cache ；

（2） 如果有旧数据，需先废除旧数据再写入 Local Cache 。若通过 Global Cache 查询到 旧数据存在于其他站点 Vplex 引擎中，则需要跨数据中心查询和废除旧数据，通讯具有 1 倍的跨站点往返时延；

（3） 写入 Local Cache 后， Vplex Metro 和 Geo 的处理方式有所区别， Vplex Metro 通过写直通缓存模式将写 I/O 刷入两套后端存储阵列，刷入跨站点的后端存储将引入 1 倍的跨站点往返时延；而 Vplex Geo 通过回写缓存模式将写 I/O 写入引擎控制器的缓存，并异步镜像至另一套 Vplex 集群的引擎控制器的写 Cache 中；

（4） Vplex Metro 待两套存储全部写反馈完成，最后将反馈主机写 I/O 周

期完成，同时 Global Cache 中的索引做相应修改，并在所有引擎上共享该信息，实现分布式缓存一致性；而 Vplex Geo 在镜像异步写发起后，直接反馈主机写

I/O 周期完成，并待两个引擎的 Cache 达到高水位后刷入后端存储。

从整个写 I/O 流程可以看出， Vplex Metro 为了加速读 I/O ，引入了读 Cache ，

为了保证读 I/O 的数据一致性（ AccessAnyWhere ），又引入了 Global Cache ，造成写 I/O 必须要查询本地和其他引擎的 Local Cache 是否有旧数据，以及时废弃旧数据，更新和同步所有引擎的 Global Cache 。这样的机制原理势必牺牲了一定的写 I/O 性能，相较于后端存储直接写，引入了两倍的 RTT 和更新同步 Local 、 Global Cache 过程的时延。其应用场景更适合于查询比例远高于更新比例的联机型应用。

三、 IBM SVC

1、 SVC ESC 方案读 I/O ：针对数据读场景，两个站点的主机对本站点 SVC

节点和底层存储节点的读 I/O 可以实现就近本地读能力，如下图所示，无需跨站点读其他 SVC 节点和存储节点，避免了跨站点往返时延消耗，性能较单站点存储节点直接读取，性能几乎一致；当某个站点的存储出现故障时，该站点的 SVC 节点将激活和另一个站点的存储路径，切换读取该存储的数据。

、 SVC ESC 方案写 I/O ：针对数据写场景， SVC ESC 的方案和 SVC Local 方案略有区别， SVC Local 由一组 I/O Group ，两个 SVC 节点组成，对于存储 LUN 而言，其必然从属于其中一个 SVC 节点，称为优先节点。存储 LUN 的访问只能由优先节点提供；而 SVC ESC 同样是一组 I/O Group ，其两个 SVC 节点的角色是一致的，摒弃了优先节点的概念，主机、 SVC 节点和底层两个存储 LUN 具备站点属性， LUN 优先从属于本站点的 SVC 节点，优先被本站点主机访问。这样则实现了两个站点主机并行写本站点的 SVC 节点和对应的底层存储节点，即本地写的能力。其写 I/O 流程步骤如下：

（ 1 ）本地 SVC Local Cluster 写 I/O ：

a 、主机发送写 I/O 请求至 SVC I/O Group ， SVC 优先节点反馈主机写已就绪，随后主机将写数据发送至优先的 SVC 节点（图示步骤 1 ）；

b 、优先的 SVC 节点将 I/O 写入缓存，并镜像同步至同一 I/O group 的另一个 SVC 节点（图示步骤 2 ）；

c 、该节点收到写 I/O ，将其写入本地缓存，并回反馈至优先的 SVC 节点（图示步骤 3 ）；

d 、优先的 SVC 节点收到反馈后，向主机回反馈，主机端的写 I/O 周期结束（图示步骤 4 ）；

e 、待优先的 SVC 节点缓存达到一定高水位，将所有写 I/O 刷入后端存储 LUN （图示步骤 5 ）。

（ 2 ） SVC ESC Cluster 写 I/O ：

a 、主机发送写请求至本地 SVC 节点， SVC 节点反馈主机写已就绪，随后主机发送写数据至本地 SVC 节点（图示步骤 1 、 2 、 3 ）；

b 、本地 SVC 节点将 I/O 写入缓存，并将写缓存数据镜像到远端 SVC 节点（图示步骤 4 ）；

c 、远端 SVC 节点反馈本地 SVC 节点写完成标识（图示步骤 5 ） ;

d 、本地 SVC 接收到远端反馈后，反馈写完成标识给本地主机（图示步骤 6 ） ;

e 、待本地和远端 SVC 节点写缓存达到高水位，开始刷数据至后端存储，首先发送写请求给后端存储，后端存储反馈 SVC 节点写已就绪， SVC 开始发送写数据（图示步骤 7 、 8 、 9 ）；

f 、待写数据全部刷入，后端存储分别反馈写完成标识给本地和远端 SVC 节点（图示步骤 10 ）；

从整个 SVC ESC 方案的写 I/O 流程可以看出，步骤 1 至 6 对主机写 I/O 时延有影响，但写 I/O 仅传送一次数据到远端，相比本地直接写 I/O ，增加了 1 倍的跨站点往返时延。另外，步骤 7 至 10 是异步操作，对主机时延无影响。

3 、 SVC HyperSwap 方案读 I/O ：假设初始化后， Site1 的卷为 Master 卷，

Site2 的卷为 Aux 卷，这种情况下 Site1 和 Site2 卷的读 I/O 流程是不一样的，如下图所示，其流程步骤如下：

（ 1 ） Site1 主机读 I/O （本地 =Site1, 远端 =Site2 ）：

a 、 Site1 主机向本地 SVC I/O Group1 的任意一个 SVC 节点发送读请求；

b 、本地 SVC I/O Group1 将读请求透传至本地 Storage Pool1 ；

c 、本地 Storage Pool1 反馈读请求，并将读数据传至本地 SVC I/O Group1 ；

d 、本地 SVC I/O Group1 将数据结果反馈至 Site1 主机；

（ 2 ） Site2 主机读 I/O （本地 =Site2, 远端 =Site1 ）：

a 、 Site2 主机向本地 SVC I/O Group2 的任意一个 SVC 节点发送读请求；

b 、本地 SVC I/O Group2 将读请求转发至远端 SVC I/O Group1 ；

c 、远端 SVC I/O Group1 将读请求透传至远端 Storage Pool1 ；

d 、远端 Storage Pool1 反馈读请求，并将读数据传至远端 SVC I/O Group1 ；

e 、远端 SVC I/O Group1 将数据结果反馈至本地 SVC I/O Group2 ；

f 、本地 SVC I/O Group2 将数据结果反馈至 Site2 主机。

从整个 SVC HyperSwap 方案的读 I/O 流程来看， Site1 主机是本地读，直接透穿 SVC I/O Group 读本地底层存储，读性能几乎和主机直接读后端存储一致；Site2 主机的读 I/O 需要通过本地 SVC I/O Group 跨站点转发至 Site1 的 SVC I/O Group ，再读远端的后端存储，因此额外增加了 1 倍的跨站点往返时延。

4 、 SVC HyperSwap 方案写 I/O ：假设初始化后， Site1 的卷为 Master 卷，

Site2 的卷为 Aux 卷，这种情况下 Site1 和 Site2 卷的写 I/O 流程也是不一样的，如下图所示，其流程步骤如下：

（ 1 ） Site1 主机写 I/O （本地 =Site1, 远端 =Site2 ）：

a 、 Site1 主机向本地 SVC I/O Group 节点发送写 I/O 请求和数据；

b 、本地 SVC 节点将写 I/O 写入本地写缓存；

c 、本地 SVC 节点将写 I/O 同步至同 I/O Group 的另一 SVC 节点缓存，并通过 SVC Metro Mirror 发送写 I/O 至远端 SVC I/O Group 节点；

d 、本地和远端所有 SVC 节点陆续反馈写 I/O 同步已完成；

e 、本地 SVC 节点反馈 Site1 主机写完成；

f 、待本地和远端 SVC 节点写缓存达到高水位，分别将写缓存数据刷入各自站点的后端存储中。

（ 2 ） Site2 主机写 I/O （本地 =Site2, 远端 =Site1 ）：

a 、 Site2 主机向本地 SVC I/O Group 节点发送写 I/O 请求和数据；

b 、本地 SVC 节点将写 I/O 转发至远端 SVC I/O Group 节点；

c 、远端 SVC 节点将写 I/O 写入写缓存中；

d 、远端 SVC 节点将写 I/O 同步至同 I/O Group 的另一 SVC 节点缓存，并通过 SVC Metro Mirror 发送写 I/O 至本地 SVC I/O Group 节点；

e 、本地和远端所有 SVC 节点陆续反馈写 I/O 同步已完成；

f 、远端 SVC 节点反馈本地 SVC 节点的转发响应；

g 、本地 SVC 节点反馈 Site2 主机写完成；

h 、待本地和远端 SVC 节点写缓存达到高水位，分别将写缓存数据刷入各自站点的后端存储中。

从整个 SVC HyperSwap 方案的写 I/O 流程来看， Site1 主机是本地写，直接写 SVC 节点缓存，并同步至两个站点所有 SVC 节点。相比直接存储写 I/O ，增加了一倍的跨站点往返时延；Site2 主机的写 I/O 需要通过本地 SVC I/O Group 跨站点转发至 Site1 的 SVC I/O Group ，该步骤增加了一倍的跨站点往返时延。写到 Site1 的数据必须同步回 Site2 ，来保证两个站点数据一致性，这个步骤又额外增加了一倍的跨站点往返时延，因此，相比直接存储写 I/O ，总共额外增加了 2 倍的跨站点往返时延。

四、 HDS GAD

HDS GAD 的读写 I/O 流程受 GAD 卷的状态所影响， GAD 卷由 PVOL 和 SVOL 成对组成，其状态分为已镜像、正在镜像、暂停、阻塞。在不同状态下，两个站点的主机对 PVOL 和 SVOL 的读写 I/O 步骤和性能是不一样的。

1 、主机写 I/O （ GAD 状态为：Mirrored ）：当 GAD 卷的状态为已镜像时， PVOL 卷和 SVOL 卷的 I/O 模式为镜像。主端和从端都可以进行写操作，正常情况下，任意端存储接收到写 I/O 请求后，都执行双写，待两端存储全部写入成功后，再回复主机写成功，完成写 I/O 周期。如下图所示，其详细写 I/O 步骤如下：

（1） 主机可通过 HDLM 多路径软件来配置优选路径为本地的存储卷，首先发起写 I/O 请求，对 GAD 卷的写数据将写入本地存储卷；

（2） 本地存储卷将接收到的写 I/O 同步镜像至远端存储卷；

（3） 远端存储卷收到写 I/O 后，完成写 I/O ，并反馈结果至本地存储卷；

（4） 两端存储卷全部双写完成后，由本地存储卷反馈主机写完成。

其中，步骤 2 、 3 将引入 1 倍的跨站点往返时延。

2 、主机读 I/O （ GAD 状态为：Mirrored ）：针对读 I/O 场景，两个站点主机可分别读取本站点的主存储和辅助存储系统的数据，主机服务器通过优选路径读取本地存储卷，然后发送到服务器。该场景下，主存储系统和从存储系统之间没有任何通信发生。

3 、主机写 I/O （ GAD 状态为：Mirroring ）：当 GAD 卷状态为正在镜像同步时， PVOL 的 I/O 模式为镜像， SVOL 的 I/O 模式为阻塞。写请求被写入两个对卷，然后写完成的反馈返回到服务器。因为 SVOL 的 I/O 模式是阻塞的，所以它不接受来自服务器的任何 I/O ，但是写入 PVOL 的数据也会由主存储系统同步写入 SVOL ，待 SVOL 写入完成反馈后，才反馈服务器写周期完成，因此本地主机的写 I/O 引入了 1 倍的跨站点往返时延，如下图所示。而远端主机在 SVOL 阻塞时，需要通过多路径跨站点访问 PVOL ，额外又引入了 1 倍的跨站点往返时延。

4 、主机读 I/O （ GAD 状态为：Mirroring ）：正在镜像的主从存储系统，从 SVOL 无法提供访问 I/O 服务，读取请求全部由 PVOL 提供，然后将读取结果反馈到主机。该场景下，主存储系统和从存储系统之间也没有任何通信发生。远端主机需要跨站点访问 PVOL ，引入 1 倍的跨站点往返时延。

5 、主机写 I/O （ GAD 状态为：Suspended ）：当 GAD 卷的状态为暂停时，并且 PVOL 上有最新的数据时， PVOL 的 I/O 模式为本地， SVOL 的模式为阻塞；当 SVOL 上有最新的数据时， PVOL 的 I/O 模式为阻塞， SVOL 的模式为本地。当 PVOL 上有最新的数据时，写入请求被写入 PVOL ，然后写入完成后反馈返回到主机，如下图所示。此时， SVOL 的 I/O 模式是阻塞的，因此它不接受来自服务器的 I/O ，而 PVOL 的 I/O 模式是又本地的，因此写入 PVOL 的数据也不会同步写入到 SVOL 。该状态下，本地主机是本地写，远端主机需要跨站点写，引入了 1 倍的跨站点往返时延， PVOL 和 SVOL 间的数据差异也将累积变大。

6 、主机读 I/O （ GAD 状态为：Suspended ）：当 GAD 卷的状态为暂停时，从 SVOL 无法提供访问 I/O 服务，读取请求全部由 PVOL 提供，然后将读取结果反馈到主机。该场景下，主存储系统和从存储系统之间没有任何通信发生。远端主机需要跨站点访问 PVOL ，引入 1 倍的跨站点往返时延。

7 、主机读写 I/O （ GAD 状态为：Blocked ）：当 GAD 状态为阻塞时， PVOL 和 SVOL 的 I/O 模式全部为阻塞。两个卷都不接受读 / 写处理，主机存储 I/O 中断。

8 、 HNAS+GAD 写 I/O ：如下图所示， HAS 的两个节点 Node1 与 Node2 组成一个 HAS 集群， HNAS 需结合 GAD 双活实现文件系统双活，且 HNAS 节点只有一个主节点提供文件系统读写，其写 I/O 步骤如下：

（ 1 ）本地 HNAS 客户端将 I/O 写入到本地 HNAS 节点的 NVRAM 中；

（ 2 ）本地 HNAS 节点将 NVRAM 中的写 I/O 镜像到远端 HNAS 节点的 NVRAM 中；

（ 3 ）远端 HNAS 节点反馈本地 HNAS 同步完成；

（ 4 ）本地 HNAS 反馈本地客户端写 I/O 完成，完成本次写 I/O 周期；

（ 5 ） 1-6 秒内，本地 HNAS 节点将 NVRAM 里的数据刷到本地后端 GAD 存储， HNAS 节点通过多路径优先选择 PVOL 下盘，实现本地直接下盘操作；

（ 6 ）本地存储通过 True Copy 同步将数据镜像到 SVOL ；

从整个 HNAS+GAD 写 I/O 流程来看，本地站点的 HNAS 客户端能够读写本地 HNAS 和底层 GAD 双活存储，且写 I/O 会引入 2 倍的跨站点往返时延， 1 倍为两个 HNAS 节点 NVRAM 镜像所引入， 1 倍为 PVOL 和 SVOL 的双写 I/O 所引入。而远端站点的 HNAS 客户端则需要跨站点访问 HNAS 节点，并下盘到 PVOL 所在存储，因此将引入 3 倍的跨站点往返时延。

五、 NetApp MetroCluster

1 、读 I/O ：针对数据读场景， NetApp MetroCluster 架构下，站点 A 的主机会优先从本地 Plex0 （ A_LOCAL ）中读数据，远端的 Plex1 （ A_REMOTE ）的读权限需要命令打开（切换场景），默认情况下，远端 Plex1 （ A_REMOTE ）不提供读业务；站点 B 的主机会优先从本地 Plex0 （ B_LOCAL ）中读数据，远端 Plex1 （ B_REMOTE ）默认时不提供读业务。如下图所示：

1、 写 I/O ：针对数据写场景， MetroCluster 使用 SyncMirror ，它可以对集群的两端进行同步写入。作为写入过程的一部分， NVRAM 还在集群互连上进行镜像，以确保不会丢失数据，并且所有写入都将提交到磁盘，以确保在中断期间不会丢失数据。由于该机制， MetroCluster 提供真正的同步写入。这两次写入均由一个控制器执行，它不会将写入传递给远程节点以在该站点执行写入。因此，可以理解为 NetApp MetroCluster 分以下两个同步动作分别实现两个站点控制器和后端存储阵列的写数据一致性：

（ 1 ）第一个同步动作是所有控制器的 NVRAM 数据同步。每个控制器的 NVRAM 都分成 4 个区域，当新请求写操作时，先写到本地 NVRAM ，再同步到本地 HA Pair 的 NVRAM ，以及远端的 DR Pair 的 NVRAM 后，返回成功。对本站点主机而言，同步 NVRAM 将引入 1 倍的跨站点往返时延，对于远端主机而言，远端相同的 Plex 不提供写业务，需要跨站点写至本地 NVRAM ，再同步至 HA/DR Pair 的 NVRAM 中，因此需额外再引入 1 倍的跨站点往返时延。

（ 2 ）第二个同步动作是通过 SyncMirror 在 NVRAM 日志下盘时，实现主从站点的盘的双写。SyncMirror 工作在 Aggregate 层上，镜像的 Aggregate 由 2 个 Plex 组成，来自本地 Pool0 的 Plex0 和远端的 Pool1 的 Plex1 。当有 NVRAM 日志开始刷盘时，写请求会同时写到本地的 Plex0 和远端的 Plex1, 两边同时写成功以后，返回成功。另外值得注意的是，控制器 NVRAM 下盘需通过独特的 FC-to-SAS 设备实现，带来了额外的协议转换开销，也影响了一定的性能，增加了时延。这是由于控制器与磁盘间，由于 SAS 后端存储不能拉远，为弥补该缺陷引入了新的协议转换设备，数据刷盘时会间接影响控制器一定的工作性能。

为了更好地了解 MetroCluster 如何将数据写入磁盘的整个工作原理。如下图所示中，列举出了写 I/O 请求进入站点 1 中的存储节点的整个步骤过程：

（ 1 ）本地站点主机发起写请求，并开始将数据写入本地控制器中；

（ 2 ）主机的写请求被写入控制器的 NVRAM 中；

（ 3 ）本地控制器将写 I/O 同步至远端集群互连的控制器 NVRAM ，以确保没有数据丢失，该方式由本地控制器驱动，而不是远端控制器驱动，提升了些许性能（第一个同步动作）；

（ 4 ）本地控制器确认 NVRAM 同步完成，反馈写入的主机写周期完成；

（ 5 ）一旦在本地控制器 NVRAM 中写入了足够多的块，并创建了数据一致性点，数据就会同时写入本地 Plex 中的本地卷和远程站点上的 Plex 镜像，待双刷盘动作完成时，将反馈本地控制器完成写同步（第二个同步动作）。

从整个 MetroCluster 方案的写 I/O 流程来看，当 NVRAM 缓存充足时，两个同步动作中，只有 NVRAM 同步过程会对主机写 I/O 性能产生影响（ 1 倍 RTT ），但两次同步也带来写数据需要在站点间同步 2 次、数据同步效率不高的影响，并且将占用更大网络带宽；当 NVRAM 缓存出现瓶颈时，两次同步的性能影响将被放大，造成主机写 I/O 2 倍 RTT 以上的性能影响。另外值得一提的是，本地两个 HA Pair 控制器间是走的外部 FC 网络（控制器拉开都是该方式），而不是两个控制器物理封装在一起时，通过高速 PCIE3.0 通道通讯，在极限并发时， FC 网络的带宽将被受考验。

一直以为zabbix安装比较简单，就几条命令的事，心血来潮想测试体验，安装了一下，并不是想象的几条命令就能完事的。环境基于CentOS7.6，Zabbix 4.0.10，操作系统可以访问外网。

一，准备系统环境

1，禁用Selinux

vi /etc/selinux/config

将SELINUX=enforcing改成SELINUX=disabled

2，禁用防火墙

systemctl stop firewalld
systemctl disable firewalld

3，安装zabbix依赖的lamp环境

yum install -y httpd mariadb-server mariadb php php-mysql php-gd libjpeg* php-ldap php-odbc php-pear php-xml php-xmlrpc php-mhash  php-bcmath php-mbstring 

4，启动mariadb和httpd 并加入开机启动项

systemctl start mariadb
systemctl start httpd
systemctl enable mariadb
systemctl enable httpd

5，配置mariadb数据库

mysql_secure_installation

根据提示配置mariadb 的root 密码

配置mariadb 的root密码以后登录

mysql -uroot -p

创建mariadb 用户及数据库并授权。

create database zabbix character set utf8 collate utf8_bin; 
create user 'zabbix'@'localhost' identified by 'zabbix';
grant all on zabbix.* to 'zabbix'@'localhost';
flush privileges;

查看zabbix 数据库

mysql -uzabbix -pzabbix
show databases;

6，安装zabbix二进制yum文件

rpm -ivh http://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-1.el7.noarch.rpm
yum install -y zabbix-server-mysql zabbix-web-mysql zabbix-get
systemctl start zabbix-server
systemctl enable zabbix-server

7，使用mysql导入 Zabbix server 的初始数据库 schema 和数据

zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -pzabbix

提示没有选择数据库。

gunzip /usr/share/doc/zabbix-server-mysql*/create.sql.gz
cd /usr/share/doc/zabbix-server-mysql*/
vi create.sql

在create.sql最上面加入 use zabbix;，即使用zabbix数据库。

cat create.sql | mysql -uzabbix -pzabbix

无任何报错提示 则正常。

8，编辑/etc/php.ini，修改

date.timezone = PRC

9， 编辑/etc/httpd/conf/httpd.conf

Zabbix默认页面为index.php，添加index.php

<IfModule dir_module> 
DirectoryIndex index.html index.php
</IfModule>

10，编辑/etc/httpd/conf.d/zabbix.conf，修改如下

php_value date.timezone Asia/Shanghai

然后重启apache服务。

二，初始化zabbix系统

1，输入http://hostip/zabbix 然后回车

2，下一步

确定所有状态都为OK

3，下一步

4，下一步

5，下一步

6，登录，用户名是Admin密码是zabbix

7，上图中提示Zabbix服务器端没有运行，查看日志，没有配置密码

cat /var/log/zabbix/zabbix_server.log

vi /etc/zabbix/zabbix_server.conf

编辑如下内容：

DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=zabbix

然后重新启动zabbix-server 服务

systemctl restart zabbix-server

8，解决图形界面中文字体乱码

复制出操作系统的微软雅黑字体，改后缀为ttf，然后把字体上传到/usr/share/zabbix/assets/fonts文件夹下

编辑/usr/share/zabbix/include/defines.inc.php 修改如下

define('ZBX_GRAPH_FONT_NAME','msyh'); // font file name

刷新浏览器界面

回过头来再仔细看看，其中有几个地方是因为我的个人习惯而导致出错，当然这也是我的经验。
至此，zabbix服务端已经初始化配置完成。

双活数据中心解决方案指两个数据中心均处于运行状态，可以同时承担生产业务，以提高数据中心的整体服务能力和系统资源利用率，实现RPO（Recovery Point Objective），RTO（Recovery Time Objective）严苛的要求，将企业业务系统连续性提升至一个更高的台阶。

本文转载自微信公众号： talkwithtrend

目前，端到端双活数据中心解决方案中最核心的技术当属存储双活技术，这也是备受企业关注的双活技术之一，而现有关于存储双活的内容中，普遍都是对存储双活方案的整体概述，以厂商自带的产品为出发点来组织方案内容，很难对企业的存储双活项目实际落地提供有利支持，从而导致项目实施后，容易被厂商绑定。因此，在本次存储双活方案解析的内容中，笔者将从方案特点、第三站点仲裁、两地三中心扩展、读写性能、故障转移、双活能力等多个角度，公正客观地对业界主流存储双活方案进行整体性详细的解析和对比，涉及华为、EMC、IBM、HDS、NETAPP等五种不同存储厂商的存储双活方案，来帮助企业真正解决存储双活建设的落地难题。本文将从五种业界主流存储双活方案的方案特点展开解析。

一、华为HyperMetro

1、双活方案概述
华为存储层双活方案基于OceanStor融合存储系统的HyperMetro特性实现。HyperMetro采用AA双活架构将两套存储阵列组成跨站点集群，实现数据实时镜像。两端阵列的双活LUN数据实时同步，且两端能够同时处理应用服务器的I/O读写请求，面向应用服务器提供无差异的AA并行访问能力。当任何一台磁盘阵列故障时，业务自动无缝切换到对端存储访问，业务访问不中断。

2、方案特点
（1）免网关设计：Hyper Metro双活架构无需额外部署虚拟化网关设备，直接使用两套存储阵列组成跨站点集群系统。最大支持32个存储控制器，即两套16控存储阵列组建双活关系。

（2）I/O访问路径：Hyper Metro在应用主机侧，通过UltraPath主机多路径软件，将两台存储阵列上的双活成员LUN聚合为一个双活LUN，以多路径Vdisk方式对应用程序提供I/O读写能力。应用程序访问Vdisk时，Ultrapath根据多路径模式，选择最佳的访问路径，将I/O请求下发到存储阵列。

根据双活站点部署距离，Hyper Metro提供了两种I/O访问策略供选择。一是负载均衡模式：该模式下可实现 I/O的跨阵列负载均衡，即I/O以分片的方式在两个阵列上下发。分片大小可配，例如分片大小为128M，即起始地址为 0-128M的I/O在A阵列下发，128M-256M在B阵列下发，以此类推。负载均衡模式主要应用于双活业务部署在同一数据中心的场景。在该场景下，主机业务访问两套双活存储设备的性能几乎相同，为最大化利用两套存储设备的资源，将主机I/O按分片方式下发到两套阵列上。

另一种是优选阵列模式：该模式下，由用户在OceanStor UltraPath上指定优选访问阵列，主机业务访问时，I/O只会在用户设置的优选阵列路径上进行负载均衡下发，不产生跨阵列的 I/O 访问。只有当优选阵列出现故障时，才切换到非优选阵列下发 I/O。优选阵列模式主要应用于双活业务部署在距离较远的双数据中心场景。在该场景下，双活数据中心的跨站点访问的代价较高，假如两个数据中心的链路距离为100km，一次往返传输通常需要消耗约 1.3ms 时间。优选阵列模式可以减少跨站点交互次数，从而提升 I/O 性能。针对数据读场景，双活数据中心的业务主机只需要读本数据中心对应的双活存储阵列即可，避免主机跨数据中心读取数据，提升整体访问性能。针对数据写场景，业务主机直接写本数据中心对应的双活存储阵列，避免主机跨数据中心转发数据，充分利用 HyperMetro AA双活能力，AA集群的每个控制器都能够接收写 I/O，由本地控制器处理本地主机的写I/O请求，减少跨数据中心的转发次数，提升方案整体性能。

（3）存储层组网：下图为Hyper Metro双活方案典型组网架构。可搭建阵列与主机、双活镜像、同城互联等三类网络，数据网络与业务网络分离；两套双活存储阵列间通信支持FC或IP链路，推荐使用FC链路，但需满足站点间RTT（往返延迟）小于2ms要求。另外，存储阵列和仲裁服务器之间的链路采用普遍的IP链路。

（4）一体化双活：该方案下的一套双活设备既支持文件数据服务（File Service），也支持块数据服务（Block Service），能够以NFS文件系统和SAN块存储两种方式提供双活功能；SAN与NAS共用一套仲裁，能够确保两个站点间链路故障时，文件存储和块存储由同一站点提供服务，保障仲裁一致性；SAN与NAS共用一种网络，站点间心跳、配置、数据物理链路合一，一种网络即可满足SAN与NAS传输，并且支持业务网络、站点间网络、仲裁网络全IP部署，组网简单。

（5）存储层数据一致性：通过I/O双写确保数据一致性，系统正常情况下，任意应用IO数据下发，都要同时写到两台阵列才返回主机，确保两台阵列数据实时一致；具备分布式锁机制（DLM），确保主机对同一存储地址的数据访问时，由其中一台写入，确保数据一致性；单存储不可用时,具备数据差异处理机制，其中一台存储不可用时，仅写正常存储，同时数据变化记录到DCL（Data Change Log）空间，待阵列修复好后，HyperMetro 将自动恢复双活Pair关系，并通过DCL记录的信息，将数据增量写入修复好的存储。这样的好处是无需全量同步所有数据，整个过程对主机“透明”，不会影响主机业务。

（6）FastWrite技术：传统通用方案两个站点间的写I/O在传输过程要经历“写命令”和“写数据”两次交互，理论上两站点间距100KM时，将带来2次RTT（往返延时），见下图左；为了提升双写性能，FastWrite技术将“写命令”和“写数据”合并为一次发送，跨站点写IO交互次数减少一半，理论上100KM传输链路仅1次RTT，提升整体写IO性能，见下图右。

（7）跨站点坏块修复技术：为了提升数据可靠性，Hyper Metro具备跨站点自动修复坏块技术，无需人为干预，自动完成修复，业务访问不受影响。流程如下（见下图）: 生产主机读取存储A数据-->存储A通过校验发现坏块-->尝试通过重构修复坏块，修复失败（若修复成功，则不进行下述流程）-->存储A检查与远端状态“完整”并发起到远端B阵列读取数据-->读取数据成功，返回生产主机正确数据-->使用远端数据修复本端坏块对应的数据。

（8）RAID2.0技术：存储阵列能够支持多种RAID保护技术，并在此基础之上进一步优化升级，当RAID组中任意硬盘故障，通过RAID2.0技术，能够快速重建RAID，并恢复数据至热备盘，速度相对传统技术大幅提升， 降低了多盘失效风险概率。

二、EMC Vplex

1、双活方案概述
EMC Vplex存储双活方案是基于Vplex网关产品实现，能够将EMC和其他厂商存储异构整合，虚拟化为统一的存储资源池，实现异构存储双活。Vplex双活方案有Vplex Metro和Vplex Geo两种方案，方案由两个站点的两套Vplex集群系统组成，每个站点的Vplex集群都有自己专属的本地存储阵列，通过创建分布式镜像卷为跨集群的镜像卷，提供Vplex Access Anywhere功能，两个站点的Vplex集群各有一个卷，两个卷的ID一样。

2、方案特点
（1）集群配置：如下图所示，每个Vplex集群均包含Vplex Management Console，一个、两个、四个或八个引擎，每个引擎包含一个备用电源。Vplex Local用于使用单个Vplex集群管理数据中心内的数据移动和访问。支持单、双或四配置(分别包含一个、两个或四个引擎)，本地Vplex组成Local集群(4引擎8控制器)，两站点Local集群再组成Metro/Geo远程集群(最大8引擎，16控制器)，形成16个控制节点的AA集群。

（2）同/异步方案：如下图所示，Vplex Metro使用两个包含独特功能的Vplex集群，通过采用写直通缓存（透写）的方式在两个集群之间实时镜像数据，保持后端存储数据的一致性，由于采用实时同步复制，Vplex Metro方案需满足站点间RTT（往返延迟）小于5ms的要求。Vplex Geo用于两个远距离应用集群节点异步使用Access Anywhere访问存储数据，Vplex Geo分布式卷使用回写缓存的方式支持Access Anywhere分布式镜像，该方案最大可支持的站点间RTT（往返延迟）为50ms。另外，Vplex Metro和Vplex Geo方案下部署的集群不要求站点间引擎数量完全一致。

（3）存储层组网：下图为Vplex Metro双活方案主机跨集群连接组网架构。主机与Vplex集群间访问、Vplex集群与后端存储数据传输、Vplex集群间通信网络全部隔离，为保证最高级别的高可用性，每个Vplex Director前端I/O模块和一对SAN光纤交换机之间必须保证2个以上的物理连接，每个主机和每个Vplex引擎的A Director和B Director都需要保持一个以上的路径连接，因此主机和一个Vplex引擎间具有8条逻辑路径。对于每个站点2个、4个引擎的Vplex集群来说，主机连接需要覆盖所有引擎；另外，当主机与本地Vplex集群连接中断时，为保证主机能够跨站点访问另一端Vplex集群，主机需要和其他站点的Vplex集群建立连接，可通过PowerPath多路软件来配置ACTIVE/PASSIVE路径来保证主机优先访问本地的Vplex集群；后端存储阵列通过SAN交换机或者直接连接Vplex引擎的后端IO模块，不需要配置到其他Vplex集群的跨站点连接路径；根据需要选用Witness作仲裁，Witness需部署于两个Vplex集群不同的故障域中(第三方站点)，且只能部署于VMware的虚拟化环境，通过IP的方式连接到两个Vplex集群。

（4）分布式一致性缓存技术：EMC Vplex是一个集群系统，提供分布式缓存一致性保证，能够将两个或多个Vplex的缓存进行统一管理，从而使主机访问到一个整体的缓存系统。当主机向Vplex的一个缓存区域写I/O时，Vplex缓存将锁定这个缓存区域，同一时刻其他主机是无法向这个缓存区域写入I/O的。但是，当主机读取I/O时，Vplex缓存允许多个主机访问一个缓存区域，尤其是主机访问其他Vplex集群中其他Vplex节点所管理的数据时，统一缓存管理会将这个I/O的具体缓存位置告知主机，主机直接跨Vplex集群访问。分布式一致性缓存技术在实现上面，并没有强求所有的Cache都保持统一，而是基于卷缓存目录的形式来跟踪细小的内存块，并通过锁的粒度来保证数据一致性。每个引擎的cache分为本地Cache(Cache Local)和全局Cache(Cache Global)，每引擎的本地Cache只有26GB，其余为全局Cache，见下图。

5）分布式缓存模式：Vplex Local和Vplex Metro采用了写直通缓存模式，当Vplex集群的虚拟卷接收到了主机的写请求时，写I/O直接透写到该卷映射的后端存储LUN（Vplex Metro包含两套后端存储LUN）中，后端阵列确认写I/O完成后，Vplex将返回确认信号至主机，完成本次写I/O周期。写直通缓存模式需要等待后端存储阵列落盘完成，对写I/O时延要求较高。这种写直通缓存模式并适合Vplex Geo方案，该方案最大支持50ms的跨站点往返延迟，采用该缓存模式将对主机产生非常大的性能影响，对于大多数应用而言显然是无法接受的。因此，Vplex Geo采用了回写缓存模式，在该模式下，Vplex收到了主机的写请求后，直接写入引擎控制器的缓存，并将写I/O镜像至引擎另一个控制器和另一套Vplex集群的引擎控制器的内存中，然后向主机确认本次写I/O周期。最后再将数据异步转储到引擎后端的存储阵列中。当出现电源故障时，Vplex引擎自带的备用电源能够保证缓存中的所有未持久化的数据暂存到本地SSD存储上。回写缓存模式无需等待后端存储阵列落盘，即可回响应主机，大幅提升了Vplex双活方案的距离和时延要求。

（6）读I/O加速能力：具有读Cache，写I/O的机制能对读I/O实现加速。为了提升读I/O性能，写I/O的时候先判断是否在Local、Global Cache中有对应的旧数据，如没有直接写入本地Local Cache；如有旧数据，先废除旧数据再写入Local；再通过写直通缓存模式将写I/O刷入两套后端存储阵列（见下图）；最后反馈主机写I/O周期完成，同时Global Cache中的索引做相应修改，并在所有引擎上共享该信息，实现分布式缓存一致性。另外，Vplex该机制下的写I/O额外需增加2次跨站点往返延迟（官方宣称引入1-1.6ms延时），在Vplex Metro方案下，写直通缓存的基础上，额外又牺牲了一定写I/O性能。

读I/O的时候先读Local Cache，如命中直接读取，读I/O加速效果明显；如果在Global Cache中命中，则从对应的Vplex引擎Cache中将其读取到Local Cache，再反馈主机读I/O结果，读I/O加速效果次之；如果在Global Cache中没有命中，则从本地后端的存储阵列中读取到Local Cache中，并同时修改Local和Global Cache中的信息与索引信息，读I/O加速无效果。

（7）支持CDP技术：Vplex只提供存储异构虚拟化和镜像两项功能，快照、复制等特性需要添加EMC自身的RecoverPoint实现，所以Vplex的组网方式常常会考虑配合RecoverPoint一起使用。此外Vplex内部集成I/O分流软件，Vplex将每个主机写I/O同步复制到RecoverPoint，RecoverPoint将每个IO记录下来，采用CDP实现任意时间点恢复。下图为Vplex双活和Vplex双活+RecoverPoint CDP方案的写I/O流程对比，后者将增加写I/O时延，写I/O放大，影响一定的性能。

三、IBM SVC

1、双活方案概述
IBM在SVC存储双活技术上提供了两套不同的方案：Enhanced Stretch Cluster和HyperSwap，均是基于虚拟化存储平台之上的Active-Active数据中心的存储双活解决方案，为上层应用提供存储A-A双活或高可用架构，确保存储层的任一组件故障不会对上层应用产生中断影响。SVC Enhanced Stretch Cluster也就是SVC拉伸式集群架构，就是把同一SVC I/O Group内互为保护模式的双节点跨站点进行拉伸，分散在不同的两个数据中心，它们之间通过光纤链路连接，数据通过Vdisk Mirror技术实时镜像到两个站点上的两个存储上。SVC HyperSwap相较于SVC ESC，它出现的主要目的在于消除本地SVC节点单点隐患，增加主机存储冗余路径，进一步提升SVC双活的高可用性。通过Metro Mirror技术实现数据在两个I/O Group和两套存储之间的实时同步，同时解决单SVC节点故障引起的性能问题及双节点故障导致数据卷无法访问的问题。以上两种方案架构均为对称式架构，在第三站点可配置仲裁，以防止脑裂现象发生。

2、方案特点
（1）整体架构：SVC ESC采用Stretched的拓扑架构（下图一），每个站点最少1个节点，两个站点各1套存储，通过SVC VDM保持实时同步，对主机来说只看到一个Vdisk，主机与两个站点的SVC节点均建立连接路径，实现两个站点主机各自读写本地SVC节点和存储，达到存储Active-Active的目的，两个站点的存储网络通过DWDM间的裸光纤级联；SVC HyperSwap采用HyperSwap的拓扑架构（下图二），每个站点最少1个I/O Group，每个I/O Group配置两个SVC节点，提升了本地SVC节点的冗余度，两个站点各1套存储，通过SVC Metrol Mirror保持实时同步，对于不同站点的主机来说，看到的是不同的LUN，主机与跨站点的两个I/O Group均建立连接路径，提升了路径冗余度。

（2）光纤链路组网和仲裁：两种方案均可通过建立Private和Public两种FC网络进行访问隔离，Private网络用于两个SVC节点间或者两组SVC I/O Group Cache间的数据同步和心跳，Public网络用于主机与SVC节点间、SVC节点与存储间的数据传输，两个站点的FC存储网络通过两对跨站点DWDM（波分复用）间的裸光纤进行级联。仲裁方式上，支持仲裁盘和仲裁服务器两种模式，仲裁盘方式使用FC链路，仲裁服务器方式使用IP链路。

3）I/O访问路径：在SVC ESC方案下，主机需配置到本站点SVC节点和远端站点SVC节点的I/O路径，以保证在本站点节点出现故障时，主机路径可立即切换至远端站点，访问同一I/O Group下的其他SVC节点；而在SVC HyperSwap方案下，跨站点的主机访问节点路径属于可选配置，为避免站点所有存储路径失效（APD）场景下RTO过长，推荐配置跨站点的主机访问节点路径。主机端通过SDDPCM多路径软件，并配置基于ALUA的路径策略，来指明哪个SVC节点是主机的本地节点，避免主机跨站点访问其他SVC节点。当本地路径未全部失效时，主机将优先访问本站点SVC HyperSwap I/O Group的Preferred Node。当本地路径全部失效时，主机将跨站点访问远端SVC HyperSwap I/O Group，但基于ALUA的路径策略并不能识别远端哪个是SVC Preferred Node，因此ALUA策略将变为Round-Robin，轮询访问远端所有SVC节点的端口。

（4）SVC ESC站点感知功能：两个站点的所有对象均具备站点化属性，包括SVC节点、主机、存储等，淡化了SVC Local集群下的I/O Group Preferred Node概念，I/O Group中的两个节点均是平等的，两个站点的主机对同一Vdisk的访问，可通过同一I/O Group的两个SVC节点并行访问。即本地读I/O优化，本地写I/O优化，确保I/O本地化，避免远程I/O访问带来的性能影响。

（5）SVC ESC缓存机制特性：SVC每个节点包含若干容量的缓存，用于实时存放主机I/O数据，减轻了I/O物理落盘带来的性能影响。SVC放置于主机和存储之间，并没有因此加大主机对存储访问的I/O时延，SVC具有扩展低端存储缓存的效果，一定程度上增强了低端存储的性能；SVC ESC的I/O Group的某个节点故障，另一节点接管，写缓存Disable，进入写直通模式，性能略有下降（对比SVC HyperSwap在站点故障场景下，远端I/O Group仍有完整的写缓存保护机制，可避免直接进入写直通模式带来的性能下降）；SVC ESC的一个I/O Group，采用一套缓存表，所以能够实现写I/O的锁互斥机制，实现同一Vdisk的两个SVC节点和存储真正双活,并具有主机读写亲和性；当任意SVC节点的电源出现故障时，SVC内置的电池或者外置的UPS模块可持续供电，直至SVC节点内的缓存数据全部刷入后端存储阵列后，再关闭SVC节点。

（6）SVC HyperSwap主从卷机制：在建立好HyperSwap卷的关系后，两个站点的主机分别映射了Master卷和Aux卷，表示哪个卷正在作为主卷，提供所有I/O服务；具有Master卷的SVC I/O Group，两个站点所有的读写请求必须经过该I/O Group，若Master卷的I/O Group和主机在同一个站点,该站点的主机可以本地读写I/O Group和后端存储阵列。若Master卷的I/O Group和主机不在同一个站点，该站点的主机通过本站点的SVC I/O Group将请求转发至Master卷所在的I/O Group，由它来处理读写请求；HyperSwap会自动比较本地读写的I/O流量和读写转发的I/O流量，来决定是否反转Master和Aux的属性。I/O流量是指扇区的数量而不是I/O数量，在首次创建HyperSwap卷和初始化后，系统自动决定哪个卷为Master。如果连续10分钟以上，AUX卷的I/O流量（读写转发的I/O流量）大于所有I/O流量的75%，Master和Aux卷的属性将反转，通过该方式可避免频繁反转。综上特性，在HyperSwap主从卷的机制下，两个站点的主机可以实现本地I/O Group本地读写，但两套跨站点的存储为ACTVIE-STANDBY模式，Master卷所映射的后端存储阵列为主存储，Aux卷所映射的后端存储阵列为热备存储。

（7）SVC无缝卷迁移技术（NDVM）：能将虚拟卷迁移到不同的I/O Group，实现对节点故障做出迅速反应，将面临单点故障的虚拟卷进行批量自动化迁移，使不同I/O Group不再孤立存在于集群当中，形成多I/O Group之间的冗余保护（下图上、中），会对迁移操作的产生的各种风险进行智能分析，保证迁移过程安全可靠。该技术通过SVC中内置的一个轻量级的应用实现，部署简单，使用方便，系统开销小。另外，可以通过温备节点快速替换故障节点的方式，快速的将集群恢复正常状态（下图下）。

四、HDS GAD

1、双活方案概述
HDS VSP系列存储的Global-Active Device解决方案使用独特的Hitachi存储虚拟化操作系统（SVOS）实现，该方案在G系列（G1500、G1000、G800、G600、G400、G200）和F系列（F1500、F800、F600、F400）存储都得到了支持，能够实现全局存储虚拟化、分布式连续存储、零恢复时间和零恢复目标、简化的分布式系统设计和操作。全局存储虚拟化提供“全局活动卷”。这些存储卷能够在两个存储或站点对同一份数据的两个副本同时读取和写入。这种Active-Active的存储设计在Local或metro集群配置中允许两个存储系统同时运行生产工作负载，同时保持完整的数据一致性和保护。

2、方案特点
（1）I/O访问路径：如下图所示，GAD采用Active-Active架构，支持主从阵列同时读写，所有I/O写操作都是先写主LUN后写从LUN；通过原厂HDLM多路径软件来配置优选路径，可以支持本地优先读写策略，G1000之后版本支持ALUA功能，自动识别本地站点的优选路径，同时也兼容主流OS的第三方多路径；当本地路径全部故障时（APD场景），主机将通过StandBy路径继续跨站点访问远端存储。通常主从站点支持100KM距离，支持FC/IP复制链路，支持8条物理路径和阵列主机交叉组网。在VSP G1000、VSP G1500、VSP F1500之后的版本，最大支持500KM（RTT往返时延20ms）的SAN双活；最大支持32仲裁盘（存储或服务器磁盘），不支持虚拟机或物理机IP仲裁的方式。

（2）存储层组网：GAD的组网相对比较灵活，单机双阵列组网是用在数据中心内，只能实现存储层的双活能力，服务器主机是单点，只能防止存储故障，这种组网方式常用在不支持集群的应用中；双机双阵列组网是比较常见的组网方式，这种组网需要服务器安装集群软件，来实现业务的切换。这种组网在存储层和应用层都可以实现业务双活；交叉组网类似于双机双阵列组网方式，但在网络层实现了交叉冗余，这种方式是推荐的组网方式，也就是服务器都可以看到所有的存储，服务器同时采用集群软件和多路径软件来完成故障的切换，切换的方式更加合理，比如存储故障，服务器集群可以不切换，只需要多路径软件切换存储就可以了；下图为本地模拟跨站点的GAD组网拓扑图，主机访问存储网络、存储间镜像往返网络、主机跨站点存储访问网络、第三站点仲裁网络全部隔离。站点1的主机通过红色路径写站点1的VSP存储，通过站点间ISL的网络将镜像数据同步至站点2的VSP存储。站点2的主机通过蓝色路径写站点2的VSP存储，通过站点间另一对ISL网络将镜像数据同步至站点1的VSP存储。

（3）Virtual Storage Machine(VSM)：HDS在一台物理存储内允许用户按照业务和应用的要求定义多个VSM，VSM与一台存储类似，具备自己的存储ID、设备序列号和端口WWN。通过VSM的定义，能够有效提高存储资源利用率，并实现架构、业务灵活性最大化。VSP最大支持8个VSM，但可以支持63231对双活的GAD卷。HDS GAD技术通过设置SVM的方式使两台存储使用相同的虚拟序列号，让主机把两台物理存储(可能包含多个SVM)看成一台存储。在一台物理存储内允许用户按照业务和应用的要求定义多个VSM。VDKC是VSP上虚拟出来的一个虚拟控制器，它可以将多台存储底层的物理控制器虚拟成同一个控制器，这样主机通过虚拟控制器访问后端磁盘资源时，始终和一个控制器ID交互，无论后台存储如何变化主机都不会有感知，从而实现了双活等特性。

（4）微码实现数据一致性：HDS GAD基于微码实现双活，主机、交换机、存储整个I/O路径不需新增任何设备。HDS GAD技术在主机写I/O过程中不会增加任何的多余步骤，实现方式就是增强的同步复制技术TrueCopy，两边写I/O完成后才返回给主机，全程确保数据完整性，两台主机同时写同一个存储块时，HDS会对写存储块加锁，保证数据的一致性。主机读I/O通过多路径保持站点亲和性，从本地读。

5）HDS 3DC技术：HDS支持“双活+复制”的3DC模式，即HDS GAD+存储异步复制，并且支持SAN和NAS的3DC的三角增量复制。主站点和异地站点的异步复制通过日志方式记录数据差异，双活主从LUN都记录与容灾站点差异数据，差异记录开始时会对齐日志ID ，某个双活节点故障后，另一个节点继续与异地灾备站点继续复制，差量数据可通过查询日志ID获取。

（6）硬件实现支持快照和克隆：HDS的快照和克隆功能基于专用硬件实现，性能高，并且快照对主从节点都可见。

（7）HNAS+GAD双活：HDS通过HNAS网关配合VSP GAD来实现NAS双活，见下图，对外提供SAN块存储服务和NAS文件系统服务。但是NAS双活依赖SAN双活，HNAS目前支持2个HNAS网关集群绑定GAD组成拉远的Active-Passive双活。数据读写在主端完成，但是从端也可以通过配置Cache和CNS情况下，通过Cache支持部分读。整个HNAS文件系统数据保存在GAD双活设备上，HANS节点的主要工作是完成站点间元数据、状态和控制数据同步。

（8）HNAS+GAD双活组网：如下图所示，NAS集群NVRAM数据复制支持100KM 10GE组网，GAD主从站点宣称支持500公里FC组网，最多支持8条物理链路。HNAS节点与GAD支持交叉组网，在APD场景下仅切换I/O路径，不切换HNAS网关；NAS采用仲裁服务器模式，支持GE组网，SAN采用仲裁盘模式仲裁，主从站点与仲裁的连接采用FC链路，SAN和NAS采用独立的两套仲裁系统。网络复杂性上，HNAS需要独立的仲裁网络、管理网络、镜像网络和NAS服务访问接入网络，GAD也需要独立的仲裁网络、管理网络、数据镜像网络和SAN存储服务接入网络，一共需要8类网络，对网络接口需求多，架构和配置比较复杂。

五、NetApp MetroCluster

1、双活方案概述
Clustered Metro Cluster(简称MCC)是Netapp Data Ontap提供的存储双活解决方案，能够增强NetApp硬件和ONTAP存储软件的内置高可用性和无中断运行功能，为整个存储和主机环境提供一层额外保护。通过将1个FAS/V系列存储的双控，利用光纤或光纤交换机将控制器距离拉远，形成异地HA Pair，控制器间通过SyncMirror实现Aggr级别的数据镜像，存储镜像物理分离。为进一步提升本地控制器的冗余度，在本地和异地分别放置两个控制器，本地两个控制器组成一对HA Pair，本地和异地两对集群再形成四节点集群，互相保护。

2、方案特点
（1）存储层组网：Metro Cluster存储层组网非常复杂，主从站点支持300公里FC组网；SAN Cluster最大支持12控，NAS Cluster最大支持8控；在下图的4控制节点组网中，需要同时配置3种网络互联设备，6种网络类型，12套网络设备：包含4套FC-to-SAS转换设备、4套FC交换机、4套10GE交换机；引擎内双控间不支持PCI-E互联，需通过外部10GE/4GE以太网络互联；第三站点仲裁可选择IP链路，可以将TieBreaker仲裁软件直接安装Linux主机上。

Metro Cluster里面涉及几类数据同步，包括两个集群配置同步，NVRAM的日志同步，以及后端磁盘同步，系统里面这3类数据同步采用不同的网络。两集群配置同步网络：通过专用冗余TCP/IP网络，由CRS (Configuration Replication Service)服务实时同步两个集群的配置数据，确保集群一端修改的配置，如新增IP，SVM或者新增、删除用户共享等配置操作，能够自动同步到远端HA Pair集群；NVRAM日志同步网络：使用额外冗余的FC-VI集群适配器连接两个跨站点的主控，FC-VI支持RDMA，支持Qos等功能，用于两个集群间的NVRAM同步和心跳，既能保证心跳的优先级，同时又能减少数据的写I/O的传输次数，因为RDMA支持批量获取一组地址空间技术，批量获取一组地址以后，后面就直接传输数据，将FC协议2次写优化成接近1次；后端数据下盘双写网络：控制器与存储阵列间采用了独特的FC-to-SAS设备，控制器数据传输采用的是FC网络，而后端磁盘阵需要通过SAS进行连接组网，因此需要先进行FC和SAS转换(Fibre Bridge)，用指定思科和博科型号专用交换机连接两个站点控制器与后端磁盘，并完成协议转换。

（2）Metro Cluster集群：Metro Cluster每个控制器的NVRAM都分成4个区域，分别用于存取节点本地日志、HA Pair Partner日志、远端HA Pair Partner日志以及远端HA Pair auxiliary日志（用于切换）。当新请求写操作时，先写到本地，再同步到本地HA Pair的NVRAM，以及远端的DR Pair的NVRAM后，返回成功；当本地控制器故障以后，优先将业务切换到HA Pair节点上；控制器恢复以后，自动切换回来，只有当整个站点都故障时，业务才会切换到远端的站点运行。切换时间控制在120s以内完成，不影响上层业务。

（3）SyncMirror同步：SyncMirror是Netapp双活的核心数据同步技术，在NVRAM日志下盘时，实现主从站点的盘的双写。SyncMirror工作在Aggregate层上，镜像的Aggregate由2个Plex组成，来自本地Pool0的Plex0和远端的Pool1的Plex1。写流程：当有NVRAM日志开始刷盘时，写请求会同时写到本地的Plex0和远端的Plex1, 两边同时写成功以后，返回成功。读流程：数据会优先从本地Plex0读数据，远端的Plex1的读权限需要命令打开，默认情况下，远端Plex1不提供读业务。

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

（4）AP架构：NetApp MCC方案是基于磁盘镜像的架构，对上层应用只看到一个LUN/文件系统，通过镜像Aggregate实现双活，正常情况下，读从本地Plex读取数据，写会将数据同步到本地和远端两个Plex。无论是2节点还是4节点的MetroCluster集群，同一时刻，LUN/文件系统还是只能提供给组成集群HA Pair集群的一个节点，只有当这个节点故障以后，HA pair的Partner节点才会接管提供业务，或者当整个站点故障以后，从站点HA pair集群才会接管业务，站点切换可以通过手动执行CFOD命令或者通过TieBreak仲裁软件触发自动切换。因此从其本质上来说，为一套阵列的不同引擎间的双活，并非同一LUN的双活，因此仅仅是Active-Passive模式下的阵列双活。

（5）异构虚拟化：能够接管现网异构存储，但不支持FAS系列本地磁盘与异构存储间双活，支持相同厂商、相同型号，相同FirmWare的两套异构存储之间实现双活；接管异构存储时将破坏原来阵列数据，接管前需要将原阵列数据迁移至别处，接管之后将原来的数据迁移回来。

（6）丰富的增值特性：FAS全系列产品（FAS3240, FAS3210, and FAS3270 ,FAS2xxx除外 ）均支持MetroCluster，且无需单独license，产品基础包已包含该功能；能够同时支持SAN和NAS双活，实现块存储和文件存储一体化双活；其他增值功能支持SSD加速，快照，复制，数据压缩，精简配置，重删等特性。

需求：
storage 作为共享存储，mgmt和node1-node4为NFS客户端。

1，格式化并正确挂载存储，编辑fstab，实现开机自动挂载。

查看挂载目录

实现开机自动挂载

2，安装NFS软件包，RHEL7和Centos7已经默认安装nfs和rpcbind。

yum install -y nfs-utils rpcbind

3，配置NFS目录的导出策略

用于配置NFS服务程序配置文件的参数

编辑 /etc/exports

/data 192.168.80.1/23(rw,sync,no_root_squash)

4，禁用防火墙，启动rpcbind和nfs服务，并加入开机自启。

由于在使用NFS服务进行文件共享之前，需要使用RPC（Remote Procedure Call，远程过程调用）服务将NFS服务器的IP地址和端口号等信息发送给客户端。因此，在启动NFS服务之前，还需要顺带重启并启用rpcbind服务程序，并将这两个服务一并加入开机启动项中。

如果操作系统禁用了IPV6，还需要如下操作：

编辑/etc/systemd/system/sockets.target.wants/rpcbind.socket，用#注释掉ListenStream=[::]:111这一行，rpcbind默认一起监听ipv4和ipv6，我在系统下禁用了ipv6，不删除的话，rpcbind不会启动

systemctl daemon-reload
systemctl start rpcbind
systemctl start nfs
systemctl enable rpcbind
systemctl enable nfs
systemctl stop firewalld
systemctl disable firewalld

如果有要求，不能禁用防火墙，那么就需要固定NFS使用的端口

echo -e "fs.nfs.nlm_tcpport=30002\nfs.nfs.nlm_udpport=30002" >> /etc/sysctl.conf
echo -e "MOUNTD_PORT=30003\nSTATD_PORT=30004" >> /etc/sysconfig/nfs
systctl -p

查看下端口使用情况

rpcinfo -p

在防火墙的TCP和UDP规则中放行 111 2049 30002 30003 30004

如何在Linux下放行端口，参考我的这篇文章CentOS7使用firewalld打开关闭防火墙与端口

5，查看nfs目录是否导出成功
storage服务器查看

showmount -e

客户端上查看

showmount -e 192.168.80.146

6，客户端挂载NFS目录并测试

systemctl start nfs
systemctl enable nfs
mkdir /data
mount -t nfs 192.168.80.146:/data /data

7，开机自动挂载

编辑 /etc/fstab

说明： defaults后面的“_netdev”说明只是限制网络设备，只挂载一次。