使用文件共享来托管系统装载目录是在几个月前引入的，从那时起，实现变得非常简单。不再手动编辑配置文件参数文件–现在所有内容都反映在系统配置过程中。最近我又经历了这个过程，我觉得变化太大了，值得重温我过去的帖子。由于Azure方面也有一些改进，我决定编写一个全新的指南，并包含有关使用AlwaysOn可用性组保护SQL服务器的附加信息。文件共享仍然使用Windows Server 2016中存储空间直接和横向扩展文件服务器功能的组合进行配置。为了简化设置并避免构建大型和昂贵的环境，我将所有必需的组件部署到一个两节点故障转移群集上。
MICROSOFT AZURE中的资源调配
在调配虚拟机的过程中可以注意到第一个创新。之前我解释了可用性集的概念，以保护系统免受意外硬件故障的影响。目前，选定的Azure区域由多个数据中心组成–例如，我在本指南中使用的西欧区域，被划分为三个物理位置，分别提供电源、冷却和网络。当虚拟机部署在单独的可用性区域时，潜在故障的概率要低得多—Microsoft提供99,99%的正常运行时间SLA。更高的可用性伴随着服务器之间稍高的网络延迟，特别是在区域之间距离较长的情况下。始终检查这是否会对您的环境造成负面影响–我建议在同一区域中运行数据库和应用程序服务器，并将它们一起故障转移。
（来源：微软网站)
我的集群基于部署在西欧两个独立可用区的两个DS4泷v2虚拟机。我的网络中已经有一个Windows域，我不会描述配置active directory所需的步骤，但是你可以使用几乎任何来自internet的指南。
每个VM都有三个数据磁盘。存储空间直接功能至少需要两个磁盘，第三个磁盘将用于存储应用程序和数据文件。
部署到故障转移群集的每个组件使用单独的虚拟IP进行通信。这种方法需要一个具有三个前端IP的内部负载均衡器来将流量定向到正确的地址。您只能使用标准负载平衡器将流量分发到部署在可用性区域中的虚拟机。
两个群集节点正在形成后端池：
我创建了三个运行状况探测器来监视服务的可用性和分发。
最后需要的资源是我用作云的存储帐户见证：
故障转移群集配置
存储空间直接使用所有未分配的磁盘形成一个存储池，然后托管SAP装载目录。应用程序和数据库文件应该驻留在一个单独的磁盘上，该磁盘不属于存储群集，因此在启用S2D功能之前，我在所选磁盘上创建了一个分区
下一步，我正在使用PowerShell脚本将计算机添加到域并安装所需的功能：
（来源：Internet）
我决定在形成群集之前检查配置：
结果是一个很好的报告，返利app下载，其中说明哪些驱动器将直接用于存储空间。我在其中一个磁盘上创建的分区将其从存储池中排除。
报告中没有错误，因此我准备构建集群。使用负载平衡器IP地址作为群集IP。稍后我们将配置负载平衡规则，将流量定向到活动节点。
我使用之前创建的存储帐户作为云见证
当集群运行时，我可以启用存储空间定向功能：
四个磁盘（每个虚拟机两个）形成一个存储池。以下命令创建一个新卷并将其装载到C:\ClusterStorage\
有关存储池和卷的详细信息也在服务器管理器中可见：
今天使用的最后一个PowerShell命令将启用群集上的横向扩展文件服务器角色：
我在storage Spaces Direct上创建了SAP装载目录卷：
可以在故障转移群集管理器中创建文件共享：
部署了高可用性文件共享，可用于安装Central Services实例。
SQL SERVER AlwaysOn可用性组
下一章介绍如何部署Microsoft SQL SERVER并启用AlwaysOn功能。我只包括了第一个节点的重要安装步骤，但这个过程必须在第二个虚拟机上重复。
作为准备，我在Active Directory中创建了两个用户来运行数据库进程：
然后在软件安装过程中，我把它们分配给数据库引擎和服务器代理：
我差点忘了更改排序规则？
在数据库引擎配置中，我选择了混合模式认证并配置了数据目录：
安装不需要太多时间：
安装完成后，我们在集群的两个节点上安装了两个独立的SQL Server。下一步，我们需要启用AlwaysOn功能并配置复制。在SQL Configuration Manager中选择"Enable AlwaysOn Availability Groups"
System account需要其他权限来管理可用性组：
（来源：微软网站)
在我继续激活AlwaysOn之前，我需要创建一个空数据库并执行完整备份：
您可以按照向导创建可用性组：
在第一个窗口中，我被要求提供可用性组名称：
然后我选择要复制的数据库：
