WSFC 来宾群集架构

来宾群集是老王WSFC系列前面遗漏的一个章节，本篇老王将探讨来宾群集的架构，并对其中一些概念进行演示，之前老王和一些朋友探讨来宾群集，发现有一些朋友对于来宾群集概念的理解，存在着一些误区，因此希望通过这篇文章帮助大家正确理解来宾群集架构

首先老王先来个来宾群集下一个定义：基于虚拟化主机或虚拟化群集中虚拟机里面的应用群集

当我们说虚拟化群集，其实我们说的不是来宾群集，我们目前在现实生活中探讨的虚拟化群集通常指的是主机级别的群集，我们可能把几台物理机做成虚拟主机群集，在上面跑了很多虚拟机，但是虚拟化群集实质上是物理主机级别的容错，当一台物理机宕机，上面所承载的虚拟机会全部转移到其它活着的节点上

而来宾群集，则说的是我们在两台虚拟机之间，做成了群集，有人会问，做虚拟化群集不就好了吗，为什么还要做来宾群集呢，实质上是虚拟化之后带来的正常需求，举个例子，我们当前完成了公司虚拟化的迁移，将原来大部分物理机都已经转换成了虚拟化群集资源池，上面的所有业务都已经迁移到虚拟化环境，那么好了，我原有业务是群集架构，保证了高可用，迁移到虚拟化群集之后你怎么帮我解决我的应用高可用问题，这是应用管理员应该对群集管理员提出的问题

传统情况下 群集管理员可能会想到 备份虚拟机 ，或者在虚拟化群集级别对用户多台虚拟机进行控制，例如使用反相关性，保证用户的应用虚拟机始终被分布到不同主机上，从这一级别保证用户虚拟机的高可用，但这这种配置仅适用于前端虚拟机，如果是有状态的应用虚拟机，数据库虚拟机，则需要配置成复制架构，这样当一台宕机后，另外一台才可以正常使用，但如果应用管理员处于一些原因并不愿意将虚拟机设计成复制架构以配合主机群集层面的反相关性，则就需要另想办法，答案就是部署来宾群集

允许应用管理员在两台虚拟机之间部署群集，以解决应用高度可用问题，通过部署来宾群集，在这个场景中，用户将获得和以前物理机管理群集一样的体验，虚拟机里面的应用将获得高可用，当一台虚拟机宕机，虚拟机里面的应用会故障转移至另外一台虚拟机提供服务

来宾群集的使用场景如下

1. 单机物理机，公司可能资源有限，只能提供一台性能充足的物理机，管理员就在这上面部署虚拟机给业务使用，业务需要保证虚拟机高可用，最小RTO，于是采用来宾群集方案，为虚拟机部署群集，同时结合安全手段控制用户访问虚拟机

2. 虚拟化群集+来宾群集，应用管理员希望拥有自己对于自身应用系统群集的完全管理权限，希望应用维持和以前一样的高可用架构方案，确保从主机到虚拟机应用的端到端高可用

对于应用管理员来说，部署来宾群集是对自己应用可用性的又一道保障，举个例子，如果不部署来宾群集，可能用户是两台虚拟机，部署在Hyper-V群集上面，假设Hyper-V主机检测到一台虚拟机蓝屏，会把虚拟机重启，或者执行迁移到其它主机操作，但其实从应用角度我们需要的不是这个，需要的是被蓝屏这台虚拟机上面的应用快速转移到其它虚拟机上，主机级别的群集是看不懂你应用的，它最多只能知道你这台虚拟机蓝屏了，或者那个服务停了，我应该把你这台虚拟机迁移到其它主机上面试试看能不能启动起来，而不会去操控虚拟机里面应用的故障转移，如果我们没有为虚拟机设计自动故障转移的复制架构，这时候虚拟机里面的应用就面临着宕机

如果是部署了来宾群集架构，会发生的就是 一台虚拟机蓝屏了，上面应用肯定挂了，来宾群集其它虚拟机通过运行状况检测，检测到有虚拟机宕机，自动会将它上面的应用转移过来，提供服务，这就是有没有来宾群集的区别

对于来宾群集而言，从应用的角度，应用是不知道我这是来宾群集，还是物理机群集，应用只知道我底层是一个操作系统，这个操作系统有没有部署群集，如果有部署群集，那么我就可以完成在来宾节点之间完成故障转移。

部署来宾群集是对虚拟机内部应用的保护，它防止的是这台虚拟机操作系统的崩溃，一旦这台虚拟机的操作系统崩溃，我的应用可以快速转移到其它虚拟机节点工作

部署虚拟化群集是对虚拟机对象和主机的保护，它防止的是某一台物理机的崩溃，一旦一台物理机崩溃，或发生硬件故障，则上面所有虚拟机可以转移到其它节点工作

虽然我们上面说部署了来宾群集之后，可以保障应用的可用性，除了防止主机故障，也可以防止操作系统故障，但是如果我们是虚拟化群集+来宾群集的架构，仍然需要应用管理员与群集管理员的配合，以完善端到端的高可用性，举例来说，如果不经过配合，虚拟化群集通常会由专门的资源管理系统负责调度，很有可能会把用户的来宾群集所有节点都放在一个宿主机节点上，那么一旦这台宿主机宕机，则来宾群集所有节点也就宕机，部署来宾群集也就失去了意义，因此，为了确保来宾群集应用的高可用，必须要求群集管理员为来宾群集配置维护策略，最好的解决办法是配置反相关性，让两台来宾群集虚拟机不在相同物理机上运行，除非只剩下最后一台物理机。这样配置之后不论是WSFC还是SCVMM都会遵循反相关性策略，这样就真正达到了主机高可用，虚拟机操作系统高可用，即便是一台物理机坏了，也绝不会影响虚拟机里面的应用

如果是四个节点的来宾群集，则可以参考这样的策略，宿主机群集配置两台虚拟机的首选节点为第一台物理机，两台虚拟机的首选者节点为第二台物理机，这样在群集评估放置策略的时候也会遵循首选所有者策略，确保两两虚拟机分别在两台物理机上，如果一台物理机宕机，来宾群集仍在另外物理机上面可用

虽然部署来宾群集的方案看起来很好，能够为虚拟机里面的应用带来更多保障，但也有它随之带来的问题

对于群集来说，群集是不管你是虚拟机或是物理机的，WSFC支持全虚拟化群集，全物理机群集，虚拟机物理机混合的群集，只要群集各节点满足群集部署的先决条件即可，那么最重要的一点来了，共享存储，我们说部署群集就需要共享存储，应用需要把数据存放在共享存储里面，才可以把应用无缝的进行故障转移

如果我们部署来宾群集，存储怎么办呢，就需要管理员想办法，把物理环境中的磁盘公开给来宾群集，让来宾群集完成群集的建立

通常情况下来宾群集的存储分配大体有以下几种方案

1. ISCSI，这个最常见了，随着网络速率的提高，ISCSI已经被用于很多现实企业环境，如果要提供给来宾群集，如果设备或超融合产品支持，可以直接在物理环境上面分配一个target给虚拟机，或者部署iscsi server ，可以是微软的或者starwind，最好是高度可用的ISCSI 提供呈现，如果没有环境，那么部署一台单独的虚拟机，或者直接在物理机上面安装ISCSI提供给虚拟机使用也是可以的

   
   

2. 直通磁盘，也是一种可行的方案，简单来说，直通磁盘就是我们将物理磁盘不通过创建虚拟磁盘的方式，直接在虚拟化主机磁盘管理脱机，传递给虚拟机中使用，由虚拟机直接使用磁盘，在WSFC中直通磁盘仅限于来宾虚拟机群集使用，且存在一定的限制，从WSFC 2008开始，微软支持为群集添加直通磁盘，理论上我们可以部署一个虚拟化群集，但是不给群集分配共享存储，而让虚拟机使用直通磁盘

WSFC 2008时代为群集添加直通磁盘步骤如下

1. 脱机物理机磁盘 

2. 脱机来宾群集虚拟机

3. 新增SCSI控制器，选择被脱机的物理机磁盘

4. 虚拟机开机，内部看见物理机分配的直通磁盘

5. 在主机群集管理器刷新虚拟机配置，看见直通磁盘成为虚拟机依赖磁盘

   
   

WSFC 2012时代为群集添加直通磁盘步骤如下

1. 脱机物理机磁盘

2. 将直通磁盘添加至群集磁盘

3. 关闭来宾虚拟机，新增SCSI控制器，选择直通磁盘

4. 虚拟机开机，内部看见物理机分配的直通磁盘

5. 在主机群集管理器看见直通磁盘成为虚拟机依赖磁盘
   

可以看到，虽然我们说直通磁盘可以被添加到虚拟化群集，但实质上，并不是说使用直通磁盘来作为群集共享磁盘，而是在虚拟机配置中，把直通磁盘作为一个依赖项目，添加进来，达到的是一个什么效果，当发生计划外故障转移的时候，虚拟机会被转移至其它节点，依赖的直通磁盘，也将转移过去，因为Hyper-V主机实际上并未安装存储。是guest虚拟机直接执行直通磁盘IO，这意味着所有节点无法同时访问存储，因此当发生故障转移时，直通磁盘将在当前物理节点脱机，再到其它节点挂载联机，之后才能完成虚拟机的迁移，这将大大增加故障转移时间，实时迁移时直通磁盘将必须从当前的Hyper-V主机卸载然后安装在新的Hyper-V主机上，此过程将减慢VM的迁移速度，并可能导致客户端明显暂停，甚至断开连接。

除此之外，直通磁盘会与单台虚拟机绑定，例如我们如果将一块磁盘分配给虚拟机，那么这块直通磁盘将不能再用作其它用途

因此实际环境中使用直通磁盘做来宾群集几率并不大，曾经在2008时代，直通磁盘效率与VHD有明显差距，而且那时候单个VHD有2TB的限制，通过部署直通磁盘，在那时可以帮助我们解决性能问题，虚拟机磁盘大小问题，同时将底层的FC或其它架构存储直接交付给虚拟机。

即便是使用直通磁盘，通常情况下企业也不会单独使用，一个宿主机群集里面会有多台来宾群集，这些来宾虚拟机的操作系统，还是会被存放在共享存储里面，而直通磁盘更多的是一种专用存储的概念，我们可以把一些类似于数据库文件等数据存放在直通磁盘，这样混合使用

直通磁盘群集架构的利弊

1. 支持映射Hyper-V物理环境连接的SAN，ISCSI，NAS，本地硬盘至虚拟机

2. 在没有Hyper-V增强会话模式之前支持映射USB存储

3. 不支持快照，差异磁盘，动态磁盘，Hyper-V副本
   

4. 主机备份无法备份传递磁盘，需要在来宾虚拟机里面安装代理进行备份

5. 计划内维护迁移会有宕机时间

6. 管理不够灵活，不如管理VHD方便，提供的直通磁盘管理接口很少
   

到了2012开始，虚拟机磁盘文件进行了优化，VHDX格式的磁盘，已经和直通磁盘的性能差距接近，同时达到了单个磁盘64TB的大小限制，来宾群集架构也更加灵活，提供了虚拟光纤通道，ShareVHDX等交付存储的架构，因此在群集中使用直通磁盘的案例已经越来越少，少数场景下用户仍然会延续习惯，在单机上面为虚拟机增加直通磁盘。

3.虚拟光纤通道

在2012之前，如果想要将SAN提供给虚拟机，我们只有通过在FC中实施ISCSI网关，或者采用直通磁盘，2012开始微软推出虚拟光纤通道功能，让虚拟机也能像物理机一样使用虚拟HBA拥有虚拟光纤通道，拥有自己的WWN，VM直接连接到FC SAN中的LUN

这项技术能够得以实现主要依赖于三项技术

NPIV - Hyper-V guest虚拟机的虚拟光纤通道使用现有的N_Port ID虚拟化（NPIV）T11标准将多个虚拟N_Port ID映射到单个物理光纤通道N_port。每次启动配置了虚拟HBA的虚拟机时，都会在主机上创建新的NPIV端口。当虚拟机在主机上停止运行时，将删除NPIV端口。

虚拟SAN - 定义了一组连接到同一物理SAN的命名物理光纤通道端口。

虚拟HBA - 分配给虚拟机来宾的硬件组件，并分配给特定的虚拟SAN

实现虚拟光纤通道的条件与限制：

支持NPIV的FC SAN

主机必须运行Windows Server 2012/2012R2

主机必须具有带有支持Hyper-V和NPIV驱动程序的FC HBA

无法使用虚拟光纤通道适配器从SAN引导VM; 虚拟光纤通道仅用于数据LUN

唯一支持虚拟光纤通道的客户机操作系统是Windows Server 2008，Windows Server 2008 R2和Windows Server 2102。

WWPN:提供给类似于MAC地址的光纤通道HBA的唯一号码，用于允许存储结构识别特定的HBA

WWNN(即全球节点名称)：每台虚拟机都能够分配到自己的专有WWNN，并以此为基础直接与SAN相连接

为了虚拟机如何从一个主机移动到另一个主机而不破坏从VM到存储的IO流，Hyper-V设计了每个虚拟HBA两个WWN的架构，虚拟机使用WWN A连接到存储。在实时迁移期间，目标主机上的虚拟机的新实例是用WWN B设置的。当实时迁移在目标主机上时VM可以立即连接到LUN，并且不间断地继续IO，对于原始主机或任何其他主机，每个后续的实时迁移都将导致虚拟机在WWN A和WN B之间交替。虚拟机中的每个虚拟HBA都是如此。在Hyper-V集群中可以有多达64个主机，但是每个虚拟光纤通道适配器将在两个WWN之间交替。

配置步骤如下

1. 为Hyper-V创建虚拟SAN

2.关闭虚拟机，为虚拟机添加光纤通道适配器，接入虚拟SAN

3.为虚拟机WWNN分配存储，虚拟机开机使用，创建来宾群集

虚拟光纤通道是hyper-v 2012的技术，利用虚拟HBA NPIV等技术将虚拟机直接接入物理SAN，解决了以往的局限性，但这项技术仍然不少限制，例如只能用于Windows操作系统虚拟机，如果是linux虚拟机则不能使用，后面2012R2的sharevhdx相对来说支持的操作系统更多一些，技术配置也没有虚拟SAN这么繁琐

4.ShareVHDX

ShareVHDX是2012R2推出的一项技术，看着像是虚拟化里的技术，但主要还是依赖WSFC，主要用于提供给来宾群集共享存储使用，通过这项技术实现了对于对于来宾群集屏蔽底层物理存储结构，虚拟机将不会直接和物理存储相联系，而是通过虚拟主机提供的ShareVHDX来实现来宾群集

2012R2时代，这项技术实际呈现效果，我们为来宾群集虚拟机依次添加同样SCSI虚拟磁盘，在磁盘高级选项中选择启用虚拟磁盘共享即可，这样选择之后，我们就可以把一个虚拟磁盘，同时给两台虚拟机使用，对于来宾群集来说，这就是一个共享磁盘，可以被群集使用，但前提条件是这个虚拟磁盘必须存放在群集CSV卷或SOFS路径下

这项技术非常好用，老王曾经在山东做过一个项目，该项目通过2台linux虚拟机做oracle rac群集，但是需要共享磁盘，又不便将底层存储公开给虚拟机，于是采用ShareVHDX技术，将磁盘同时挂接给两台虚拟机，虚拟机内部就可以正常创建rac使用，效果很好

对于来宾群集来说，无疑这是最佳最方便的方案，但一个很重要的前提就是底层必须要有虚拟化群集的支持，ShareVHDX的磁盘文件必须存在虚拟化群集的CSV或SOFS路径下，或者说有专门的一个存储群集提供给虚拟化群集使用，所有的ShareVHDX都存放在存储群集，前端的虚拟化群集不配置共享存储，所有的虚拟机都指向存储群集的SOFS路径以存储sharevhdx，但实际效果来看，老王认为在2012R2时代，ShareVHDX直接存放在自身虚拟化群集CSV中效果更好

ShareVHDX技术最大的一个好处是对于底层存储架构的屏蔽，你虚拟机不用管我底层是SAN，JBOD，S2D，ISCSI，只要交付给VM一个CSV或SOFS路径，VM就可以利用这个路径来完成ShareVHDX的创建，进而交付给来宾群集共享存储

ShareVHDX技术还可以用于后端存储群集，前端多台Hyper-V主机的场景，虚拟机在其中两台主机上，分别指向存储群集SOFS路径，这样做了之后来宾群集可以获得高可用性，但是主机没做群集，同样会带来隐患，因此最佳还是应该虚拟化群集+来宾群集

在2012R2时代，ShareVHDX还是技术有所限制，经过勾选启用硬盘共享的磁盘

不支持调整Share VHDX的大小和迁移

不支持创建Share VHDX的备份或副本

Windows Server 2016里面这项技术进行了更新，升级为ShareSet，取消了这些限制，但是要求GuestOS必须为Windows server 2016才可以使用，该技术一直延续到2019

在2016中，ShareSet的添加方式如下

1.为虚拟机创建VHD Set格式磁盘，存放在CSV或SOFS路径下

2.为虚拟机添加SCSI 控制器下的Share Drive

3.为Share Drive挂载存在VHD Set

被创建的VHD Set将产生两个新的文件格式

一个.avhdx文件，包含实体数据，此文件是固定的或动态的。

一个.vhds文件，包含用于协调来宾群集节点之间信息的元数据。该文件的大小几乎是260KB。

对于已经使用了ShareVHDX的技术的虚拟机，可以使用Convert-VHD将ShareVHDX文件离线转换到VHD Set格式，再添加至ShareDrive

如果您的环境中当前使用的是linux来宾群集，但是使用了2012R2 ShareVHDX，建议先不要升级为2016 ShareSet，可能会存在不支持的情况。

对于来宾群集老王建议首选2012R2 ShareVHDX或2016 ShareSet作为来宾群集共享存储架构，这种方案对于现有环境的改变最少，不需要改变物理存储拓扑，其次是ISCSI/虚拟光纤通道/直通磁盘

总结一下，经过写这篇博客，老王也随着思考了下实际场景的应用，企业也并非一定要部署来宾群集，尤其是已经有虚拟化群集的情况下

对于虚拟化群集来说，本身你的一个个虚拟机，对于WSFC来说就是一个群集角色对象，节点检测宕机我按照策略正常故障转移

但是随着WSFC和Hyper-V团队的配合，现在仅在宿主机级别就能够对Guest虚拟机里面的应用进行一些保护

例如，蓝屏检测，针对我们部署的虚拟机，WSFC可以检测到虚拟机OS是否蓝屏，如果蓝屏是要在当前节点或是转移到一台其它或者的节点上

应用检测，WSFC2012开始针对于虚拟机还可以检测到虚拟机里面的某个服务，一旦超过限定的失败次数就在当前节点重启，或转移到其它节点

来宾网卡保护，可以做到检测虚拟机连接的网卡，一旦失去连接，则将虚拟机故障转移到其它节点上。

其实如果不部署来宾群集，我们也可以在这几个级别来保障虚拟机对象，虚拟机OS，虚拟机网络连接，虚拟机里面应用的健康，但如果应用确实很关键，则仍需要部署来宾群集架构，以获得最高的可用性，一旦单个节点虚拟机OS崩溃，应用可以故障转移到另外的虚拟机里面运行，大大减少宕机时间，如果是仅部署一台虚拟机结合宿主群集，则会带来重启的宕机时间。

level1级别的虚拟机应用保护：部署单台虚拟机，结合蓝屏检测，应用检测，网卡检测，防止除主机宕机外这三个因素导致的应用宕机

level2级别的虚拟机应用保护：部署多台虚拟机，但是不部署来宾群集，虚拟机之间采用应用复制技术，配合宿主群集实现反相关性，让虚拟机始终不在同一节点，单台宕机，利用复制技术自动或手动切换应用至其它虚拟机

level3级别的虚拟机应用保护：部署来宾群集+宿主群集，结合反相关性，确保来宾群集的节点始终处于不同宿主，不论是单个主机宕机，或单个虚拟机宕机都不会影响应用

各位企业管理员或顾问可以根据实际场景，虚拟机应用所需要的保护级别，选择合适的方案，希望可以通过这篇文章为大家带来思考！