超融合（Hyper Convergence）
对于边缘计算来讲，实现应用分布式部署和数据持久化保存是某些关键业务在生产环境部署必须要解决的问题。这并非是一个类似镜中花、水中月的虚幻需求，在例如能源、运输、制造业的某些场景下，这甚至是必须要具备的能力。传统方案中的全冗余备份、或外挂NAS的方式，在小规模部署中尚可堪用，但是对于复杂边缘应用和大规模环境下就不堪重负。
另一方面，数据中心和云计算中广泛采用的超融合架构已经在服务器级别上很好地解决了基础设施层面的这个问题。将分布式存储与虚拟化融合在一起形成的架构，给了在边缘计算中以较低成本满足上述需求的一个新思路。
设备级别的计算机硬件资源与服务器相比更有限、无法展开复杂的本地管理、且希望从云里管理的方式，给实现超融合架构提出了很多挑战。本篇介绍的是在设备级别上利用VMware 的vSphere Hypervisor（ESXi）和vSAN实现超融合集群的具体实践。
安装环境
数据节点：Eurotech BoltCOR 30-17 x 2 (vSphere 6.7认证)
- CPU: Intel Pentium D1519, 1.5GHz, Quad Core
- 内存: 24GB DDR4 ECC
- 存储: mSATA SSD 60GB x 1, SATA SSD 100GB x 1, SATA SSD 500GB x2
- 网络: 1Gbps Intel I210 NIC x 2, Wifi, LTE x 2
Witness节点：Eurotech ReliaGate 20-25 x 1
- CPU: Intel Atom E3845, 1.91GHz, Quad Core
- 内存: 4GB DDR3L ECC
- 存储: mSATA SSD 100GB x 1
- 网络: 1Gbps Intel I210 NIC x 2, Wifi, LTE
这里的实践是基于如下架构：
从设备硬件规范来看是两大一小，将会部署2+1的架构：2个数据节点和1个witness节点。
安装的软件是VMware vSphere 6.7和vSAN 6.7。2020年3月VMware发布了vSAN 7.0 (https://www.virtualizationhowto.com/2020/03/vmware-vsan-7-0-new-features-and-capabilities/)，其中原生文件系统功能提供了对NFS 3和4.1的支持。但对于一个不大规模的设备集群来讲，边缘应用对NFS的需求并不强烈，所以本篇介绍的还是块存储的实现方式。
需要注意的是本篇介绍的环境仅是代表技术上可实现的PoC平台，与提供商业支持的vSAN兼容硬件列表(https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsanio)不同。
安装步骤
配置网络
如系列文章（三）丨云管理虚拟化设备所述，在三台设备上都安装好vSphere Hypervisor之后，规划网络设置如下：
- Witness 设备：10.117.169.119/22
-Witness 虚机节点：10.117.169.29/22 (witness traffic), 10.117.170.6/22 (vSAN network)
- 数据节点（preferred fault domain)：10.117.169.105/22
- 数据节点（secondary fault domain)：10.117.171.128/22
需要确保以上四个IP地址都在同一个3层子网和2层网段里。
注意要以较小的设备为Witness设备，在此之上部署Witness 虚机节点。
准备设置
在正式开始安装vSAN之前：
- 四个vSphere Hypervisor（包括witness 虚机节点，实际上是nested
ESXi）内的时间设置要完全同步，建议统一配置NTP来确保这一点。
- 打开所有Hypervisor的SSH服务，以进行如下以esxcli命令行为主的设置。
- 确保清除之前设置的任何vSAN集群。
安装集群
在一台数据节点上，执行如下命令以创建集群：
esxcli vsan cluster new
会产生一个随机UUID来标识Sub-Cluster，本节点也会直接加入这个新集群。
在另一个数据节点上，执行如下命令以加入新集群：
esxcli vsan cluster join -u <cluster-uuid-created-before>
此时这两个节点还互相不可见，因为unicastagent还没有设定。
接下来要在这两个数据节点上声明vSAN的存储硬盘，通过如下的命令完成：
esxcli vsan storage add -d <hdd-id> -d <hdd-id> -s <ssd-id>
该命令将空白未分区的HDD或SSD分别赋予vSAN作为持久层和缓冲层。
在witness 虚机节点内部（注意不是witness 设备）执行如下命令，将其加入vSAN集群：
esxcli vsan cluster join -u <cluster-uuid> -t -p <preferred-fault-domain-uuid>
类似的，需要为witness 虚机声明vSAN存储硬盘（实际上是虚拟硬盘）：
esxcli vsan storage add -d <hdd-id> -s <ssd-id>
接下来是非常重要的一步：为两个数据节点设置unicastagent，witness虚机节点内不需要执行此步骤。
esxcli vsan cluster unicastagent add -a <another-data-node-ip-addr> -i vmk0 -p 12321 -U true -t node -u <another-data-node-fault-domain-uuid>
esxcli vsan cluster unicastagent add -a <witness-node-ip-addr> -i vmk0 -p 12321 -U true -t witness -u <witness-node-fault-domain-uuid>
注意witness-node-ip-addr不是witness虚机节点在管理网络里vmk0的IP地址，而是为vSAN witness流量增加的vmk1的IP地址。
在witness虚机节点内不需要执行unicastagent操作，因为上面并没有unicast服务。
如此，包含2个数据节点和1个witness节点的超融合设备集群就建成了。
管理与除错
在没有连接高级管理功能vCenter情况下，依然可以获取vSAN集群相当多的状态信息。
可以在任何一个数据节点的ESXi UI上看到vsanDataStore的状态信息，以及所连接网卡的设置。
除此之外，esxcli和VMware Power CLI都提供了相当多管理vSAN集群的功能，详细信息可以参阅相关的用户手册。
比如可以通过esxcli或Power CLI来检查vSAN集群的健康状态：
esxcli vsan health cluster –w
有时会看到一些红色警告，可以通过执行如下命令来获取详细信息。
esxcli vsan health cluster -t key (e.g. limit1hf)
和应用运行的状态。在本实验环境里只有两台数据节点，所以N-1失效情况下就无法保证数据的高可用性。如果有更多数据节点加入集群，这将不会是大问题，同时数据持久化的存储效率也会明显改善。
没有连接到vCenter，这并不意外，因为在先前配置超融合设备集群的过程中完全没有用到或连接vCenter。
现在就可以在这个超融合设备集群上部署基于虚机的边缘应用，例如Ubuntu镜像内基于EdgeX Foundry开源框架的边缘应用，并且不用担心单点设备故障会影响数据可用性了。如果辅以合适的watchdog监控，还可以实现一定程度的高可用性。和第三篇介绍的云管理虚拟化设备方式结合，就可以从云里管理超融合设备集群了。
- 未完待续 -
系列文章（六）预告
超融合设备集群可以实现数据持久化和虚机级别的高可用性，而容器级别的高可用性需要应用框架层面上的保证。下一篇将介绍超融合设备集群上利用持久化存储的Kubernetes。