WSFC2016 On Azure

本篇文章，老王将为你们介绍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虚拟机在其每一个虚拟磁盘上都有独占锁，基于Azure Blob存储的磁盘将不支持永久保留，也不支持虚拟机里面直接跑ISCSI Server给WSFC用，所以在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支持添加Server，自动加入SMB负载轮询，例如当前有两个节点负责三个share的SOFS UNC路径提供，这就意味着会有一个节点要负责两个share，这时候若是再添加进来一个节点，就会由三个节点，每一个节点负责一个share的请求提供，以实现负载均衡横向扩展功能

基本上咱们使用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服务，可是身份验证每次都须要×××回到本地域控验证，不只有安全隐患，并且影响性能，能够选择云端部署一台域控，这样云端用户访问都是使用云端域控验证，本地用户访问都是使用本地端域控验证

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能够是公有云，或打通×××给本地私有云
   

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创建链接，那个节点就能够获胜继续提供服务，只要云见证在咱们的群集就能够支撑到最后一个节点

若是说您的 WSFC on Azure 群集不须要遵循最佳实践，能够正经常使用就行，那么您也能够选择经过一台其它的Azure机器，例如DC，来构建一个文件共享，用于WSFC on Azure的共享见证

与云见证相似的，还有一种看起来可行的方案，Azure File Services，不少朋友也会想到使用一个Azure File路径来为群集作文件共享，但实际操做你会发现群集会拒绝一个Azure File Services的Azure文件共享见证，由于使用Azure File Service 必需要输入Azure分配的特定身份验证信息，因此若是要借助Azure技术实现WSFC见证，只有云见证技术能够选择

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

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

实验验证，云见证一样没法处理时间分区，缘由是云见证blob里面不会有群集数据库

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