WSFC2016 On Azure

Posted 2020-10-07

本篇文章，老王将为大家介绍WSFC在Azure上面跑的一些执行操作，以及操作过程中需要注意的地方

之所以要写这篇文章有几个原因

1.为大家破除群集能否在公有云平台跑的迷思

2.为大家带来群集在公有云平台跑的思考

3.为大家介绍WSFC 2016 借助于Azure实现的云S2D，云仲裁

首先，WSFC群集能不能在公有云平台跑呢，答案是可以的，理论上来说，只要可以满足建立群集的要求，我们可以在私有云，公有云，混合云任何一个平台上面部署群集

思考一下，当我们建置一个群集时有哪些最基本的先决条件要准备

1.确保可以得到已激活，正常的操作系统

2.确保节点与节点之间网络质量良好

3.确保可以节点间可以看到共享存储，或使用第三方复制以实现类似于共享存储的效果

实现这点要求第三方插件可以和群集配合，利用第三方插件复制磁盘做出来的磁盘能被群集承认为群集磁盘，其次如果要在公有云或其它云平台上面跑，要确保第三方复制插件可以被平台支持。

确认了必备条件后，我们就可以来监视各种公有云平台了，看看对于群集的需求，公有云平台是否可以支援

首先，操作系统，群集要求可以得到一个已被激活，健康稳定的OS，因此需要确保公有云提供的OS，足够健康，不会因为系统问题而导致群集的不稳定

确保公有云群集节点更改机器名，更改为静态IP，不会影响OS的正常运行。

网络

群集节点可以接受没有多块网卡，但是至少要有一块网卡，这块网卡会被用来承担业务流量，CSV流量，群集通信流量，群集需要进行运行状况检测。

所以，在我们思考公有云平台部署群集时，最主要的一点，公有云上面虚拟机与虚拟机要可以通过网卡正常通信，且网络质量应该是稳定高效的，因为所有流量都压在一块卡上，最佳实践还是建议能使用多块网卡则为公有云群集节点使用多块网卡。

存储

在之前的传统概念中，群集就是一定要访问共享存储的，应用一定要数据写入共享存储中，随着应用和第三方插件的更新，应用开始可以支持使用本地磁盘+复制，以实现群集磁盘，或高可用效果。

在公有云上面跑群集很重要的一点:  我们是在人家的平台上面，跑 VM 的 Guest Cluster

这意味着我们没有FC,FCOE,ISCSI,JBOD,RBOD这些存储底层架构的访问权，我们没有权利去控制存储的分配，所以虚拟机能使用什么样子的共享存储，完全取决于公有云厂商公开到什么程度，但通常并不会很高，一些有良心的厂商maybe会开放类似于share vhdx的技术，通过底层虚拟化的技术同时把一个虚拟磁盘挂载到多个节点，或者可以提供ISCSI网关，通过一个安全的方式来提供ISCSI target给虚拟机节点。

如果厂商没提供方案，我们之前就需要借助一些第三方厂商来实现一种，跨节点本地磁盘的复制，让群集以为这是群集磁盘，但正如之前所说，这要求群集支持，公有云平台支持部署这种插件

身份验证

如果计划部署群集为工作组模型，则不需要考虑公有云平台对于AD域的支持

如果计划部署群集为AD域模型，则请确认公有云厂商支持安装AD类型虚拟机，确保安装出来的AD域可以在公有云环境可以正常提供域服务，确保不会因为公有云平台的磁盘缓存设置，网络原因，而导致AD域控制器的不正常运行

一旦群集部署为AD域模型，将需要写入群集CNO对象，VCO对象的，因此需要确保公有云支持虚拟机跑AD域架构，AD域虚拟机可以和群集节点虚拟机在公有云上面正常通信，群集节点虚拟机对于AD域的身份验证请求，CNO，VCO读取写入请求可以正常进行。

以上四条基本要求如果公有云平台可以满足后，则意味着群集在公有云上面跑，就是可行的，那么我们就可以思考下一步，我们是否真的有必要在公有云部署群集，什么场景下，我们应该在公有云上面部署群集，对于群集而言，如果部署在公有云我可以获得那些好处

首先先来看下，我们已知的公有云可以给我们带来的好处

1.规模足够大，可用资源足够多，我们可以部署足够多的节点

2.使用上我们只需要为使用了的资源付费，未使用的资源不会产生费用

3.公有云平台会负责为我们维护服务器，存储，网络，等底层设施，我们不需要为维护这些设施而花费精力财力

4.公有云平台通常会定义Region机制，可以帮助我们确保如果资源的，存储，VM，网络都在同一个Region，那么同一个Region下的VM，存储，网络等资源会尽可能的靠近，以获得更好的性能。

5.公有云平台通常会置备完整的故障转移，灾难恢复方案，在我们购买服务时，会为我们保证SLA，如果SLA得到违反，我们作为使用者可以得到赔偿。对于公有云平台的存储磁盘，通常会得到多个副本的复制，这个复制可能是同Region，或跨Region的机制，针对于网络，默认情况下网络会尽可能的和VM，存储靠近，使用同Region下面的优化网络链路，如果同Region下面的网络链路出现问题，公有云厂商通常可以帮我们把网络链路进行快速的切换，针对于虚拟机资源，如果我们选择虚拟机到不同的Region FaultDomain，或不同的Rack FaultDomain，当公有云平台维护时，能够确保不会同时维护不同Rack或Region下的资源。

那么，既然公有云本身经具备了对于存储的复制能力，网络链路的冗余能力，虚拟机的FaultDomain能力，已经这么完美了，我们直接在虚拟机上面跑应用就好了，何必再在公有云上面跑WSFC呢

其实非也，从最根本来说，公有云厂商站在的角度，他们是需要保证IAAS架构的SLA，确保您的订阅不会违背SLA原则，他们不会被要求赔偿，这就是公有云厂商的角度，他们只是站在运维保证他们云平台的硬件可以正常服务，维护不会导致停机，就OK了，对于你虚拟机上面跑了应用，你应用的高可用性，是和公有云厂商没有关系的，需要你自己去在乎，自己去选择合适的方案。

这里，老王说的只是IAAS的场景，如果说，云平台提供PAAS级别的服务，可以满足您的需求，例如，云平台如果提供SQL paas服务，那么您可能就不需要在公有云上面部署WSFC了，因为我们之所以要部署WSFC，是因为我们care vm里面的应用持续提供服务，我的应用如果是有状态的，那么我只部署在一台，如果我这台坏了，上面运行的状态和应用如何迁移到其他节点运行，iaas级别，公有云厂商是不管你的，公有云厂商只保证，网络，存储，服务器不会出现故障，维护或故障不会影响SLA，但如果您的VM里面跑了有状态的应用，您希望应用可以持续提供服务，一旦一台VM故障，应用依然可以提供服务，那么IAAS您一定是需要部署群集架构来实现。

如果说您觉得公有云厂商提供Paas服务可以满足我的需求，您接受这种新的思维，例如SQL paas，这是个应用级别的云服务，因此公有云厂商会负责从底层硬件，再到系统，到应用的高可用，这是他们应该是care的，例如，通常公有云厂商如果提供数据库的paas服务，他们通常会置备分片，群集，高可用组，等技术来帮我们保证应用的高可用性

如果您觉得信不过paas，这种paas 我又看不到，不知道到底怎么切换的，我也不熟悉，您希望选择一种熟悉的模型，那么您care应用的持续可用，iaas情况下，只好部署WSFC

因此，WSFC在公有云平台跑，以下两种情况是有必要的

1.购买了公有云的IAAS服务，但是虚拟机里面跑了应用，您care应用的连续性

2.您不愿意接受云平台的PAAS服务，希望获得更高的Control权，使用自己熟悉的方式管理应用的高可用

WSFC在公有云平台上面跑还有几种典型的云优化场景

1.开发测试，本地部署生产的WSFC，上传云端跑一套同样环境的WSFC用作开发测试调试

2.灾难恢复，WSFC本地部署一部分节点，云端部署一部分节点，正常运行在本地端，云端节点无投票，本地端出现故障，直接failover到公有云，此场景，对于本地端与公有云端网络链路质量要求高

3.云爆发：本地部署少数节点WSFC以备日常使用，一旦使用发生暴增的情况，本地节点已经无法hold，可以利用云爆发，直接扩展节点至公有云节点，仅在爆发时使用，爆发后再回到本地节点，计费应仅在爆发时使用

通过上面的介绍，相信大家应该知道了

1.WSFC 部署到公有云的好处

2.WSFC 什么场景有必要再公有云上面部署

3.WSFC 在公有云上面跑的典型场景

4.WSFC 在公有云部署时需要关注的点

没有全明白也没关系，下面我们将实际以WSFC on Azure公有云平台为例，在实验中讨论上面说到的内容

WSFC On Azure 可行性评估

1.操作系统

Azure上面内置了很多虚拟机模板，虚拟机部署后为已激活，机器名可更改，且是得到优化的模板，可以得到信赖

2.网络

Azure上面对于网络采用VNET架构，同一个VNET下的云虚拟机可以正常通信，支持为虚拟机固定IP，但有一点需要注意，Azure虚拟机默认创建出来都是一块网卡，我们出于对群集的最佳实践考虑，可能希望可以使用多块网卡，在Azure上面对于已创建在运行的虚拟机要添加网卡极为麻烦，因此如果希望使用最佳实践置备WSFC节点多块网卡，最好在规划阶段规划好，这样创建出来的Azure虚拟机就带有多网卡

3.存储

在WSFC2016之前，如果WSFC要上Azure，那么至少08R2以上的，WSFC上了Azure后，对于Guset VM级别的WSFC，Azure不支持公开存储，不支持ISCSI,SAS,SCSI等方案，没办法让底层的存储直接分配到虚拟机，share vhdx技术也暂时没看到可以使用的地方，即是说，Azure本身没有支持Guest VM WSFC共享存储的方案，基于Azure Blob存储的磁盘不支持永久保留，也不支持虚拟机里面跑ISCSI Server，因此在WSFC 2016之前，如果要在Azure上面build群集，那么存储只有这几种方案选择

> 在Azure上面跑WSFC，但是只跑不需要共享存储的群集appllication，可以在application级别使用附加虚拟机本机磁盘复制以达到HA的，例如SQL AG

> 使用第三方方案，为WSFC节点安装插件，通过第三方插件各个节点本地磁盘进行复制，包裹一层形成群集可以认到的群集磁盘，类似产品有Sios DataKeeper，Starwind

> 使用Express Route，打通本地和公有云，实现能够把本地端的ISCSI通过安全通道公开给公有云WSFC节点

因此，大家可以看出，之前在Azure上面跑WSFC，场景很有限，因为毕竟大多数群集应用还是需要一个共享存储来写入数据，达到failover的效果，像是SQL AG这样的还是在少数，第三方方案，也不见得每个人都熟悉，Express Route 又超级贵，不是所有公司都用得起，因此，对于公有云能不能跑WSFC不确认的放弃一批，在Azure上面跑了WSFC，但是因为共享存储无法公开给虚拟机，群集应用不能跑，又放弃一批，所以实际上在WSFC 2016之前，在Azure上面跑WSFC的人很少很少

到了WSFC 2016新出了很多云优化的功能，使WSFC on Azure有了新的可能，WSFC 2016 可以和Azure配合使用的技术有Storage Space Direct，Storage Replica，Cloud witness，其中对于WSFC On Azure 帮助最大的是Storage Space Direct，以下简称S2D，这是一项让人振奋人心的功能，简单来说，有了S2D之后，群集不再必须需要共享存储了，您可以使用各节点本地磁盘，把各节点本地磁盘贡献出来，形成一个基于群集的存储池，这个存储池可以做SSD HHD NVME的分层存储，或全SSD ,全NVME的存储池，构建出来的群集存储池，上面再构建群集存储空间，即虚拟磁盘，每个虚拟磁盘都可以有自己的容错策略，简单，镜像，奇偶校验，可以基于节点级别，磁盘级别定义存储的QOS，这是微软进军软件定义存储的新里程碑。

既然提到了S2D，就不得不提存储池，存储空间，群集存储池，JBOD，SOFS这些概念，正好也借机会为大家补一补群集存储的课

传统意义上的群集存储已经不用我多讲，我们通过SAN,ISCSI等技术，使用多路径，把目标分给多个节点服务器，确保所有节点都可以认到磁盘即可

那么什么是存储池和存储空间呢，简单来说，老王认为这是微软对于存储虚拟化的一个基本实现，通过OS层面的功能，以及和硬件设备的配合，实现可以通过廉价的Share SAS，或JBOD，RBOD方案，来构建可靠应用存储，甚至是群集存储，整个过程完全是在Windows 软件层面进行定义。

设想一下传统SAN上面的架构，首先底层也会是一个磁盘集合，然后由上层带CPU的控制器层对物理磁盘进行集中管理，在控制器层通常存储设备可以控制磁盘容错策略，去重，精简模式，存储分层，缓存设置，等一系列存储管理调整操作，最终最前面是连接适配器，将存储分配给节点后，节点通过ISCSI,FC,FCOE方式，使用多路径连接进来存储

微软的存储池和存储空间，提出的概念就是要在Windows Server 2012开始，就内置在系统级别支持可以定义所有的，磁盘集合，存储控制，最终交付，我们说过的传统存储上面的功能，2012都可以实现，磁盘集合对应到存储池，存储控制对应到存储空间，连接适配器对应到SMB，2012开始SMB协议得到优化，可以得到SMB多通道技术，自动聚合多路径，SMB传输过程也可以利用RDMA,RSS等硬件技术实现传输性能优化，因此微软推出存储池和存储空间的愿景，是为了替代掉传统存储昂贵的价格，只需要使用share sas，廉价的jbod，rbod，就可以在系统上面实现存储上面的高级功能。

那么，虽然我们有了存储池和存储空间，这很好，我们把机器插到JBOD上面，在系统层面配置存储的Raid，去重，分层，精简模式，这看起来很酷，但是只是在单机上面跑，我们还看不到这种场景的价值，真正要想看到存储池，存储空间的应用价值，我们最佳还需要在群集中构建这种架构，在WSFC 2012开始，我们可以在群集上面部署群集存储池，再基于群集存储池构建存储空间，其实所谓的存储空间，对应到落地就叫做虚拟磁盘的概念了，当我们创建每个虚拟磁盘的时候，可以选择虚拟磁盘的容错方案，是否精简等设置。

一旦我们部署了群集存储池和群集存储空间的架构，那我们这个存储架构就变了，相当于，我们把存储里面，控制器这个level给群集化了，我们在群集上面配置的存储池和存储空间，配置磁盘容错策略，去重，精简模式，存储分层，即便当其中一个节点宕机，群集存储池，群集存储空间，以及我们配置过的策略依然会存在，我们实现了存储控制器的高可用。

同时，基于群集存储池，构建出来的存储空间虚拟磁盘，被创建完成后，是直接可以在群集磁盘里面看到的，因为控制器被群集化了，所以创建的虚拟磁盘可以被所有节点磁盘管理器看到，可以支持作为群集磁盘

这样我们就可以完成一个场景，即Cluster in a Box，我这个群集就部署在一个Box里面，这个box里面有两个计算节点，还有两个share sas，或一个JBOD绑定，我们不用共享存储，就在一个box里面，使用JBOD，或share sas，就可以构建一个群集启动起来，群集磁盘是通过节点的群集存储池-群集存储空间构建出来，然后最好有RDMA，实现一个SMB3 RDMA 多通道的架构，或者您也可以独立出来单独使用一个JBOD，然后上面接入两个群集节点，这样我们就实现通过廉价存储，结合2012的存储虚拟化技术，配合实现群集。

那么SOFS是什么呢，很多人会以为SOFS就是存储空间，存储池的一套，其实听完老王的介绍，您就会发现它们根本不是同一样东西

存储池，存储空间最终交付的就是一个磁盘，一个可以在群集磁盘中看到的磁盘，意思就是说，你群集不用在乎我底层是什么存储架构，不用管底层架构是ISCSI,SAN,还是群集存储池，反正我分给你一块盘，一块可以被所有节点看到的，合格的群集磁盘就够了。

而对于SOFS来说，SOFS是不管你是通过什么途径提供来的磁盘的，因为SOFS是直接要在CSV上面跑一个共享，SOFS只认CSV，你的底层可以是SAN,ISCSI,存储空间，SOFS根本不Care，SOFS只Care，你是否提供了一个正常的CSV，换句话说，即便我们是传统SAN架构，我们也可以有SOFS

那么SOFS到底干嘛的呢，说白了，这是SMB技术配合群集技术，CSV技术，DNS轮询技术实现的一种存储持续可用方案，当我们构建一个群集文件服务时，如果选择应用程序数据的横向扩展文件服务器，那么我们就可以得到一个SOFS，得到SOFS后，我们会创建新的共享得到一个UNC路径，如果支持UNC的群集角色则可以使用SOFS，目前Hyper-V和SQL可以使用SOFS的UNC路径，把应用数据写入SOFS路径内，如果在应用感知SOFS的情况下，我们可以得到持续可用的存储连接

因为SOFS是透明故障转移的，我们使用SOFS时，并不会使用一个传统虚拟的群集IP，SOFS的UNC路径名称会对应到各个节点的本地IP，当应用访问SOFS路径时，实际上是基于DNS轮询的，这样即是说，SOFS UNC路径对应的文件服务器是AA模式的，所有节点都可以承载连接，每次自动挑选最合适的节点提供存储服务，2012R2开始可以基于SOFS里面的不同share实现负载均衡，例如针对\\SOFS\Share1由NODE1提供，\\SOFS\Share2由NODE2提供

基本上我们使用SOFS的核心意义，就是为了利用SOFS的透明故障转移能力，在WSFC 2012时代，SOFS还没有得到优化，那时如果我们尝试把虚拟机存在一个SMB路径下，这时把提供SMB路径的文件服务器节点直接断电，上面所有虚拟机将会崩溃。后来SOFS改变了这一点，因为应用每次对于SOFS的访问，会通过SOFS特有的wintess service来确认用户访问的是哪台节点，然后跟踪应用的SMB客户端会话，一旦发生应用当前所在节点宕机，直接透明的把应用的会话转入到另外一个节点，对于Hyper-V和SQL来说，用户不会感觉到中断，这是最核心的部分，SOFS在DNS轮询之上，群集之上，实现了基于群集的见证检测引擎，以确保用户的SMB客户端会话可以始终得到保持。

以上老王简单为大家复习了下群集存储在2012之后涉及到的新东西，接下来开始就是我们的重头戏了，S2D，也是我们实作WSFC On Azure之前，所需要了解的最重要的东西

简单来说，大家可以这样理解，S2D架构，是2012时代 JBOD+存储虚拟化+群集的升级版，你2012不是说使用JBOD架构构建群集廉价吗，但是也还需要买一个JBOD是吧，我2016比你更廉价，我直接就可以用每个节点本地磁盘来做群集，这个就厉害了，也更加好用，因为JBOD这东西，国内比较还是用得少，如果你说，你支持本地磁盘贡献的架构，那可能就更多的人愿意尝试

S2D架构呢，基本上就是我们群集时指定NoStorage参数，创建完成群集后，开启S2D，开启S2D会去扫描，每个群集节点，当前除了C盘系统启动盘，还有那些是一样大小的磁盘，磁盘可以是SCSI ,SCSI ,SATA都可以，被扫描到的合格的磁盘，会被加入群集的S2D机箱，之后我们就可以继续做群集存储池，群集存储空间，CSV , SOFS这些东西了，所以说S2D这个东西，并不是说替代掉原有的存储池，存储空间，它只是一种：能够在群集中，把各个节点上面的非系统磁盘聚合起来形成可用存储池的一种技术。

有了这样的一个技术，我们玩WSFC on Azure，就可以有更多花样了，为什么呢，因为我们care wsfc 能不能跑在azure上面，无非是care共享存储怎么办，现在有这种S2D技术了，那我直接启动几台虚拟机，虚拟机我附加数据磁盘，然后在虚拟机里面启动群集，然后开S2D，认到各节点附加数据磁盘可以作为可以存储池了，然后我们就可以玩花样了，群集存储池，群集存储空间，到存储空间这里，群集磁盘里面就可以看到我们创建的虚拟磁盘了，已经可以认到群集磁盘，这个群集磁盘底层是经由S2D构建，HA的群集存储控制器，且存储空间创建出来的虚拟磁盘-群集磁盘，可以是镜像的，或校验的。

当然，这种在云端上面使用S2D的先决条件，底层的虚拟化主机要和我们的Guest VM能够相配合，目前根据老王发现，只有底层是Hyper-V主机或ESXI主机，可以通过附加磁盘的方式来实现Guest S2D Clsuter。

OK，最主要的S2D介绍完了,后边我们一会会通过一系列的实验，来为大家看清上面老王说的这些S2D的架构，帮助大家在脑袋里构想出这样的架构

对于我们部署WSFC on Azure，除了S2D这一项关键技术，我们还可以借助存储复制，云仲裁技术，优化我们的群集。

存储复制，是Windows Server 2016上面退出的一项基于Valume Manager 下，Partition manager上面插入的一层复制技术，可以帮助我们完成控制存储的同步复制，或异步复制，复制的级别可以是本地磁盘，跨服务器磁盘，多站点群集各站点磁盘，跨群集磁盘。

有一个典型的场景我们可以在Azure上面利用到这项存储技术

即我们有一套应用环境，当前基于S2D跑起来在中国，我们希望在欧洲也有个备份，那么我们就可以分别在中国和欧洲架起来两座S2D Cluster群集，然后两个region下的S2D群集磁盘做存储复制，这样一旦S2D群集在中国跑，跑失败了，我们还可以使用欧洲的S2D Cluster，存储数据都会同步过去

因为Azure本身的磁盘已经可以是本地复制，或异地复制，因此我们再Guest内使用存储复制功能，那一定是因为，对于应用来说，我们需要可控的复制管理，不论是群集对群集，节点对节点，我们使用存储复制都是希望能够在故障情况下，快速保证依赖应用的运行。

云见证技术，是WSFC 2016和Azure配合新增的一项功能，简单来说，就是把文件共享见证移动到Azure上面，当我们使用云见证技术，实际上我们会在Azure上面创建个存储账户，然后我们获取到存储账户的名称，主访问键值，服务终结点名称，之后我们在WSFC 2016里面选择云见证，填写入这些信息后，会通过HTTPS REST连接到Azure的存储账户中，在我们输入的存储账号下生成一个blob，然后利用这个blob作为本地WSFC，或Azure上面WSFC的云见证，每注册一个群集使用云见证后，会在仲裁blob下面带有ClusterInstanceID，以帮助我们标识当前blob被那个群集所使用

云见证可以有很多场景，例如，一个多站点群集的场景，例如北京，上海都有群集节点，两边的群集数据磁盘都通过存储复制功能进行复制，但是见证磁盘由于里面有群集数据库依赖于时间戳，因此不能够使用复制技术，所以，我们要不就把见证磁盘放到一个远程站点，别是北京，也别是上海，最好放在一个公平的地方，两个站点正常都可以访问到，这样一旦发生分区后，那个站点可以访问到见证磁盘，就可以被优先启动，但是如果企业真的就没有这种第三个站点怎么办呢，或者说在第三个站点部署个见证磁盘划过来的代价很高，那么通常您可以选择使用文件共享见证的方式来处理这种多站点群集，但使用文件共享见证需要注意老王之前提到过的时间分区问题，文件共享见证在帮忙处理群集分区的场景下可以很好的工作，但对于时间分区则处理不如磁盘见证优秀，云见证就是适用于这种，企业没办法做第三个站点的磁盘见证或共享见证，那么云见证就可以作为您的第三个站点，只要付费就可以使用云见证帮助您遵循多站点仲裁的最佳实践，只要确保您的WSFC节点443端口可以和Azure通，能够正常联网，那么就能够使用云端见证。

OK，理论准备部分已经基本结束，下面我们直接进入WSFC On Azure的实战部分，本次我们以国内版Azure为例，在构建WSFC On Azure时，我们需要在Azure上准备以下内容

1.一个规划好的VNET，VNET地址空间，预先在子网中规划好DNS

2.一个标准的存储账号，用于云见证使用

3.确保正常运作情况下，VM,存储，网络，在同一个Region下面运作

4.一个规划好的云服务，确保所有WSFC 虚拟机在同一个云服务下面

5.针对于WSFC节点，利用同一个服务下面的可用性集技术

6.为每个WSFC节点，至少新增至少两块数据磁盘

除了以上六点外，还有一点需要考虑的，WSFC 2016 的部署模型，要采用工作组模式，还是基于AD域的模型，在 WSFC 2016时代开始支持使用完全工作组架构来部署群集，但是部署出来的群集，能够适用的应用很少，其中最为典型的是基于SA验证的SQL Server群集，后面老王也会专门发博客讲解这种部署模型。

本文我们还是主要专注于传统的群集模型，即使用AD的群集，使用AD做身份验证，这样可以确保大部分应用都可以支持

那么如果我们决定了要在Azure上面部署AD则又有一些需要需要注意的地方

1.尽量为虚拟机使用静态IP

2.AD数据库不要存放C盘，Azure的虚拟机Wndows C盘是经过缓存优化的，而AD数据库不能和这种缓存协同工作，一定要单独附加一块无缓存的磁盘用做AD数据库

3.如果确认Azure的虚拟机要使用域控制器，那么需要实现在规划VNET的时候规划好，域控制器应该是那个DIP，然后把这个DIP保留，并配置为VNET的DNS服务器，这样所有同VNET下的WSFC节点，安装好了后就能看到DNS是域控的IP，可以正常加入Azure上面的IAAS域。

DC On Azure 有几个典型的场景

1.使用Azure上面虚拟机安装DC，然后和本地AD网络打通，使用Azure作为AD站点的远程站点

2.Azure上面跑了一些虚拟机，这些虚拟机需要为用户提供Web服务，但是身份验证每次都需要VPN回到本地域控验证，不仅有安全隐患，而且影响性能，可以选择云端部署一台域控，这样云端用户访问都是使用云端域控验证，本地用户访问都是使用本地端域控验证

3.只是纯粹为Azure上面虚拟机使用而需要部署一台域控制器提供集中身份验证，确保最大control度

实验验证

创建规划虚拟网络，选择位置在中国北部地区

编辑虚拟网络访问空间，对应到VMM的概念这里应该是VM Network与VM Subnet

规划虚拟网络DNS服务器统一为10.0.0.4，这里注意，如果我们希望在Azure上面部署WSFC，虚拟机务必要使用手动规划的虚拟网络，否则默认的话，每个虚拟机都会单独自动创建虚拟网络，不会在同个子网下面

完成第一步网络规划后，我们创建一个存储账号，用于后期做云端见证，但是在中国版Portal门户上面我们可以发现已经不能操作存储账号，操作存储账号会被重定向到新的portal上面

创建存储账号，选择标准，复制保持默认，位置选择中国北部，确保资源尽可能得到靠近

创建china16dc，node1，node2虚拟机，三台虚拟机都选择同一个云服务下面，确保使用相同虚拟网络，虚拟网络子网，相同存储账号，针对于node1，node2 WSFC节点，我们可以创建设置可用集，利用Azure云平台提供的rack faultdomain能力，保证我们的两台机器始终位于不同机架，不会同时被维护

针对于Node1 ，Node2 WSFC节点，需开启443终结点，以便后期节点可以联系到云端见证

在新portal上面可以手动选择三台机器IP地址为静态，我们选择为静态，对于域控制器我们按照规划设置为10.0.0.4，其它两个节点5和6

打开域控制器虚拟机可以看到IP地址已经按照我们的规划进行了配置

正常安装DC On Azure IaaS，创建用于安装WSFC群集的cluadmin账户，加入DomainAdmins组

确保活动目录数据库在E盘，总之，一定要是个非C盘，非D盘的无缓存的数据磁盘！

正常把Node1，Node2加入DC on IAAS的ha.com域

到这里我们已经迈出第一大步，构建了一套Azure上面可以正常提供服务的iaas域环境，我们再通过远程登录时可以通过ha.com\cluadmin，直接管理WSFC节点虚拟机

接下来我们准备部署S2D Cluster On Azure，为Node1，Node2分别附加两个相同大小的数据磁盘

对于S2D节点的数据磁盘，我们可以使用默认的的存储账号，我们也可以单独再创建一个高级性能类型的存储账号，然后在里面创建SSD类型的数据磁盘附加给虚拟机，以获取更高的性能，如果您的群集应用需要获取更高的性能，那么您有必要这样做。

上面我们讨论过S2D 让WSFC on Azure有了很多可能，那么现在Azure具体有那些WSFC场景呢

1. 使用Express Route打通本地ISCSI Server到Azure WSFC群集

2. 使用第三方插件构建复制节点本地存储为群集磁盘

3. 不使用S2D的SQL AG(AG本身并不一定需要共享存储，可在应用级别完成复制)

4. 基于S2D的SQL群集

5. 基于S2D的SQL AG 

6. 基于S2D提供SOFS，并公开给同VNET下的SQL群集，实现SQL文件存SOFS(或本群集)

7. 基于S2D提供SOFS，用于RDS UPD存放路径，RDS可以是公有云，或打通VPN给本地私有云
   

8. 基于S2D的WSFC群集，用于其他群集负载，例如传统文件服务器，通用程序，通用服务等

9. 基于S2D的WSFC群集，实现跨Region群集对群集的存储复制
   

接下来老王将为大家大家实作第四种场景出来，我们通过在WSFC on Azure上面构建一个S2D的存储模型，然后上层提供一个SOFS路径，这个SOFS可以被用于本群集，或交付给同VNET下的其它群集。

接下来我们要在WSFC on Azure上面启S2D了，根据实验，老王发现Azure上面启动S2D和本地端不太一样，我们不能使用Enable-ClusterStorageSpacesDirect命令来构建，但可以使用Enable-ClusterS2D，此外对于每个S2D节点，需要执行winrm /quickconfig

针对于Node1，Node2执行winrm /quickconfig

为Node1，Node2安装故障转移群集功能，然后执行以下命令，创建群集

New-Cluster –Name sofs –Node Node1,Node2  -StaticAddress 10.0.0.12 –NoStorage

创建完成后我们得到了一个正常的WSFC on Azure，但现在群集没有存储，除非使用SQL AG等不需要共享存储的应用。

接下来我们需要为群集开启S2D，让群集去收集各节点本地磁盘，汇集成可用的群集存储池

如果是使用Enable-ClusterStorageSpacesDirect创建S2D，你会发现一个83页VPD的警告，随后SDS报错无法找到合适磁盘

这时使用Enable-ClusterS2D命令则可规避此问题，由于我们都是HDD环境，所以不需要进行缓存设置

Enable-ClusterS2D -CacheState disabled -Autoconfig 0 -SkipEligibilityChecks

创建完成后提示警告，打开所属htm，可以看到只是我们执行的结果，2块系统磁盘无法被收集进入可以存储池，各节点两块数据磁盘，共计四块，已被添加至群集可以的存储池。

打开群集机箱可以看到已有的机箱信息

点击池，新建存储池，输入名字后，可以看到S2D收集上来的可用磁盘组，这和2012R2 JBOD的显示还不太一样

2012R2 JBOD架构构建群集存储池直接显示为Clustered Storage Spaces

选择可用物理磁盘，如果这里磁盘少于3块，则会提示无法进行下一步创建存储池。

创建完成后，我们现在有了群集存储池，点击新建虚拟磁盘，构建群集存储空间

创建结果如下，大家可以看到，我们可以为每一个虚拟磁盘，选择存储数据布局，简单，镜像，校验

一般情况下，创建完成的群集存储空间虚拟磁盘，就可以直接在群集存储中看到磁盘，应该是群集和存储存储空间达成了一些合作，一旦检测到存储空间分出来的虚拟磁盘，那就是分配给所有节点的，那就是应该用做群集磁盘，所以自动拿了过来

添加磁盘为CSV，注意，可用存储需要被格式化为NTFS格式，才可以被用于CSV

最终，我们要交付一个SOFS路径，通过群集添加角色即可，需要注意，由于SOFS需要在CNO同OU下产生VCO，所以需要赋予CNO对象对于OU的管理权限，以及对于DNS区域可以创建DNS记录的权限，否则SOFS不会创建成功

DNS正常添加了DNN记录

SOFS文件服务器也经可以正常基于CSV添加，随之我们创建一个路径，给SQL群集使用，现在我们得到了一个SOFS On S2D Cluster On Windows Azure！

通过实验，相信大家已经了解了云平台上面跑WSFC群集的S2D架构流程

云平台级别附加虚拟机磁盘 -> 创建WSFC群集  -> 开启S2D功能收集磁盘  -> 创建群集存储池  -> 创建存储空间 -> 得到群集磁盘 ->构建群集共享卷 -> 交付SOFS

虽然有点复杂，但只要理清了思路，并不难，关键还是思维的转变，说简单些，我们只是找到了一种新的群集存储架构模式，利用一整套存储虚拟化带来的好处，通过S2D可以为群集构建群集磁盘，而不再需要提供商公开存储。通过使用S2D技术为我们在公有云上面部署WSFC带来了很多新的可能，未来也希望微软推出更多方便好的技术，帮我们在各种云平台部署WSFC，把WSFC带到任何地方

相比之下，云见证技术并不如S2D在WSFC on Azure上面发挥了那么重要的作用，但是云见证技术也可以帮我们优化群集，不论是本地WSFC，或是WSFC On Azure，本地WSFC节点打通到Azure的443端口就可以使用云见证，WSFC on Azure，虽然我们可以通过S2D构建起来群集，但是我们需要考虑群集的见证磁盘，如果就是WSFC本节点通过S2D启一个见证磁盘，也可以启，但是这不是最佳实践，我们可以利用完全独立于WSFC S2D之外的云见证技术来完成群集的见证，利用Azure上面的存储blob来帮助我们保证群集见证。

对于云见证，我们不需要准备太多，确保WSFC节点443端口得到正常开放，可以和Azure存储通信，之后准备一个标准的存储账号即可

复制事先准备好存储账号的主键值

打开群集仲裁向导，选择高级仲裁配置

选择仲裁见证为，配置云见证

输入存储账户名，复制的存储账户主访问键，如果是Global Azure，服务终结点保持默认即可，国内版Azure 需要更改为core.chinacloudapi.cn

点击下一步，WSFC 2016节点会通过443端口去联系Azure存储账号，follow 服务终结点去寻找一个可以被写入的存储路径，之后把WSFC的ClusterInstanceID记录下来，生成一个块blob，我们WSFC的云见证仲裁就是由这个blob提供

配置成功后可以在群集上面看到当前见证已经变为云见证

云见证很好，是一项很好的技术，在我们没有第三个站点的情况下，可以帮助本地多站点架构遵循最佳实践，使用公有云作为见证仲裁，由Azure存储帮我们保证见证的可用性，唯独要求打通443端口，对于WSFC on Azure来说，第三个站点见证也不便于部署，所以可以利用云见证技术

在面对一个集群网络分区的时候，例如两个节点之间不通时，那个节点可以和云见证通过443建立连接，那个节点就可以获胜继续提供服务，只要云见证在我们的群集就可以支撑到最后一个节点。

与云见证类似的，还有一种看起来可行的方案，Azure File Services，很多朋友也会想到使用一个Azure File路径来为群集做文件共享，但实际操作你会发现群集会拒绝一个Azure File Services的Azure文件共享见证，因为使用Azure  File Service 必须要输入Azure分配的特定身份验证信息，所以如果要借助Azure技术实现WSFC见证，只有云见证技术可以选择

那么之前文章里面挖过的坑，也是时候该填上了，云见证到底能不能处理时间分区

时间分区即是说其它节点不在线的的情况下，我修改群集信息，新增资源，之后shutdown，之前群集信息修改不在线的节点再开机，是否可以继续提供服务，2012R2时代，磁盘见证可以，因为磁盘见证里面有一份群集数据库，即便其它节点修改资源时我不在线，我也可以从磁盘见证里面捞回来最新的群集数据库，而文件共享见证则不可以，文件共享见证在这种情况下，之前修改群集信息时不在的节点，再开机，会发现群集无法启动，因为没有最新的群集数据库，只有等待之前之前修改信息的节点启动才行。

实验验证，云见证同样无法处理时间分区，原因是云见证blob里面不会有群集数据库

能处理时间分区的只有磁盘见证，因此如果您担心会发生时间分区场景，那么您需要想办法让群集使用磁盘见证，可以是S2D构建或express route打通，或者您可以选择在Azure上面部署奇数节点的群集，这样有百分之66左右的几率可以支撑到最后一个节点！

本文出自 “老王的微软技术研究乐园” 博客，请务必保留此出处http://wzde2012.blog.51cto.com/6474289/1966022