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级别的虚拟机应用保护：部署来宾群集+宿主群集，结合反相关性，确保来宾群集的节点始终处于不一样宿主，不管是单个主机宕机，或单个虚拟机宕机都不会影响应用

各位企业管理员或顾问能够根据实际场景，虚拟机应用所须要的保护级别，选择合适的方案，但愿能够经过这篇文章为你们带来思考！