现在当务之急是要考虑SQLServer服务不能故障停止的问题，也就是说不能出现中断工作业务的情况。SQLServer的AlwaysOn数据同步模式一共有两种，分别是同步提交模式和异步提交模式。最终要实现的效果，就是当任意一个节点故障时，另一个节点能提供正常的SQLServer服务。而当故障节点恢复后，两个节点之间又能正常同步更新数据库。前者是SQLServer的默认服务端口，而后者是群集的默认服务端口。
网管小贾 / sysadm.cc
公司里有一台安装了 SQL Server 的老爷机服务器已经跑了整整三年。
无人问津、尘封多年的它最近状况不断，系统运行不是卡顿就是死机，难不成快了？
这就和人一样一样的，就算是台机器，虽固有一死，但这一天谁也不希望盼着它早点来不是？
呃，除非它有病！
哎，它可不真是有病！
这有病就得治，至少药不能停！
就算暂时不考虑更换服务器凑合着用，那后续的解决方案还是要提前研究一下啊！
首先严正声明一下哈，这台服务器可不是我安装的，最早先是相关部门找的不知道哪个供应商给弄的。
现在当务之急是要考虑 SQL Server 服务不能故障停止的问题，也就是说不能出现中断工作业务的情况。
那如何预防 SQL Server 服务中断呢，我想到的就是冗余服务，也就是高可用。
于是就有了我后面踩坑的经历。
话说以前倒也研究过 MySql 的主从复制，并不是非常复杂，但是这个 SQL Server 的没整过啊。
关于 SQL Server 的高可用实现，网络上倒有不少文章，可是我找了几篇看得我头大了好几圈。
不过还好，花了好几天的时间，最后还真被我给折腾出来了。
但是说实话，虽然 Windows 的图形操作都是点点点和下一步，但这里面坑是真的多，于是我整理下来与各位小伙伴们一起分享。
由于内容繁多、篇幅较长，为让大家看得清楚学得扎实，故分为上、中、下共三篇。
好，且听我细细道来！
原理简介及实现目标对面复杂难办的事儿，我们肯定不能一上来就着急动手，还是要来先简单地熟悉一下原理以及我们最终想要实现的效果和目标。
SQL Server 的 Always On 数据同步模式一共有两种，分别是 同步提交模式 和 异步提交模式 。
同步提交模式与异步提交模式的主要区别在于，同步提交模式数据可靠性高一些，但切换时因要保证同步会有一定的延迟，而异步提交模式下数据服务的性能会高一些。
如果你要保证数据更可靠，而且允许牺牲一些服务性能（其实也没那么夸张），那么就选同步提交模式。
同步提交模式原理图。
详细具体的原理内容，请参考网友的文章。
文章链接：https://www.cnblogs.com/xuliuzai/p/9847301.html
本文就以同步提交模式来展开具体的创建和测试等操作。
最终要实现的效果，就是当任意一个节点故障时，另一个节点能提供正常的 SQL Server 服务。
而当故障节点恢复后，两个节点之间又能正常同步更新数据库。
OK，清楚了吧，让我们开始吧！
准备工作工欲善其事，必先利其器。
准备工作做得好，快乐收获少不了！
1、各系统命名、IP地址及功能备注这里啰嗦几句，为了保证系统的可靠性（域名解析、故障转移和身份验证等），我们直接采用域环境的方式来搭建 SQL Server 高可用系统。
至于网上还有使用证书验证的方式，虽然我最后也成功做成了，但因其设定较为复杂麻烦又容易出错，而且牵连着其他多处设置，所以我还是真心建议小伙伴们通过AD域环境来实现高可用。
- A89230 192.168.89.230 SQL Server 节点一（主）
- A89231 192.168.89.231 SQL Server 节点二（辅）
- A89219 192.168.89.219 文件共享服务器（共享见证）
- A89220 192.168.89.220 AD 服务器（域名服务器）域名：sysadm.local
- MSSql_Cluster 192.168.89.232 群集名称（虚拟 IP 地址）
- MSSql_Listener 192.168.89.233 SQL Server Always On 可用性组侦听器（虚拟 IP 地址）
看过上面的清单列表，我再简单补充几句。
a. 本例共两台服务器节点，一主一辅。
b. 共享服务器和 AD 服务器已是事先架设好的，为保证高可用稳定性，两者均独立于节点服务器之外。
c. 群集和侦听器的 IP 地址都是虚拟地址，这些虚拟地址均用于直接访问管理。
d. 高可用创建好后，应该使用侦听器的 IP 地址作为服务地址，而不应该直接用任何节点的 IP 地址。
2、安装 .Net Framework 3.5和 故障转移群集管理器操作对象：主辅两台服务器
打开 服务器管理器 ，选择菜单项 管理 > 添加角色和功能 。
在选择功能界面勾选 .Net Framework 3.5 和 故障转移群集 。
在确认安装所选内容界面中，点击 指定备用源路径 。
输入以光盘盘符为开头的安装路径，比如 D:\Sources\SxS\ ，同时将 Windows 2016 的安装光盘放入光驱。
一切就绪后开始安装即可。
3、系统服务操作对象：主辅两台服务器
确保以下系统服务是否正常启用并处于运行之中。
- 网络共享服务器 Server
- 远程注册表服务 Remote Registry
- WMI 服务 Windows Management Instrumentation
操作对象：主辅两台服务器
使用命令 gpedit.msc 打开组策略编辑器。
在窗口左侧依次找到 计算机配置 > Windows 设置 > 安全设置 > 本地策略 > 安全选项 。
在窗口右侧找到 网络访问：本地帐户的共享和安全模型 ，确保设定为 经典 - 对本地用户进行身份验证，不改变其本来身份 。
通常这个默认值即是预期设定值。
5、防火墙操作对象：主辅两台服务器
开启 Windows Management Instrumentation (WMI) 应用访问。
在防火墙的高级设置中添加入站规则，开启 1433 和 5022 端口。
前者是 SQL Server 的默认服务端口，而后者是群集的默认服务端口。
除以上开放的防火墙规则或端口外，可能还有诸如 Server 服务或远程管理等多项规则的开启。
虽然通常它们在默认情况下就是开放的，但还是要注意检查一下，以免接下来会出现不可描述的问题。
6、DNS 解析操作对象：主辅两台服务器
务必要保证各个系统之间都能正常通讯，那么 DNS 的正常解析就显得万分重要了。
本次实践我们是在域环境中实施的，只要 DNS 是指向域中的域名服务器， DNS 解析一般不会有问题。
但有一种情况，即非完全域名（就一个主机名）的解析，有可能会出现问题。
所以可以的话别偷懒，建议小伙伴们在 C:\Windows\System32\Drivers\etc\hosts 文件中手动追加相应系统的域名解析记录。
# hosts 域名解析记录示例192.168.8.88 yourhost192.168.8.88 yourhost.sysadm.local
节点之间最简单而行之有效的见证方法，就是通过共享来传递和验证。
这个群集见证共享其实就是普通的共享文件夹，但为了保证其可靠性和稳定性，建议将这个共享建立在独立于各个节点的第三方。
这样即便某一台群集节点服务器故障也不会影响到共享的访问。
本例中将 A89219 设定为共享服务器，并建立一个共享文件夹 \\A89219\ClusterSharing 。
为保证各节点都能正常访问它，应该将这个共享文件夹的权限放开。
那么具体这个权限如何放开，又放开到什么程度呢？
经过我找资料并多次测试，得出的结论是，这个共享权限应该开放 Everyone 的修改权限。
没搞错吧，肯定有小伙伴会问，那这个共享岂不是谁都可以访问了？
是的，所以为了保障系统安全，只能通过其他一些折中的办法来达到屏蔽非法访问的目的，比如限制只能节点服务器的 IP 访问等等。
具体的如何安全加固，那就看小伙伴们自己的需求了，这里就不再一一举例了。
以上准备工作完毕，开始本文的重点，小伙伴们打起精神来哦！
建立群集及故障转移群集是我们实现高可用的基础，因为要保障高可用，肯定是要用到两台甚至是更多台服务器的。
将这些服务器整合在一起就叫建立群集，而这些服务器在群集中就叫作节点。
故障转移则是在某台节点服务器发生故障后，可以顺利切换到其他正常服务器的功能。
而要实现故障转移，必须将某项具体服务设定为群集的角色来实现。
比如 SQL Server 的故障转移功能，就是通过做为群集的一个角色来实现的。
实现故障转移功能的角色设定我们需要在后面 SQL Server 中详细说明。
现在我们先来说一说群集的建立，具体怎么做呢？
1、建立群集操作对象：主服务器（A89230）
打开 服务器管理器 ，依次点选 工具 > 故障转移群集管理器 。
在 故障转移群集管理器 界面中，右击左侧项，在右键菜单中选择 验证配置 。
根据你需要添加多少个节点服务器，依次输入服务器的名称，然后再点击 添加 。
注意，不要点击 浏览 ，那个没有任何作用。
添加完毕，运行所有测试，一路下一步。
如果测试中存在错误，请参照前面的准备工作所涉内容，务必保证通讯及权限的设定正确。
测试成功完成后，即可直接创建群集，只要在测试结果界面下方勾选 立即使用经过验证的节点创建群集... 并点击完成按钮即可。
在创建群集向导界面中，输入你喜欢的群集名称，比如 MSSql_Cluster 。
然后在下方表格中填写群集 IP 地址，这个 IP 地址必须是空闲的、虚拟的，但须保证与各节点在同一网段，比如 192.168.89.232 。
注意，这个群集名称是一个 DNS 名称，也就是它必须解析为你设定的 IP 地址，并且同时它的完全域名也应该能正常解析为这个 IP 地址。
比如本例的 MSSql_Cluster.sysadm.local 也应该可以解析成 192.168.89.232 。
一切 OK 后，点击下一步开始创建群集。
稍等一会儿，创建群集即可初步完成。
哎，怎么叫初步完成呢？
小伙伴们也应该能注意到，在最后的完成画面中有一项警告，系统无法为见证磁盘找到合适的磁盘。
这是什么意思呢？
其实简单的说，就是当故障发生需要故障转移时，系统需要一个判断，这个判断就叫作仲裁。
为啥要这个仲裁？
因为如果没有这个判断，那系统就不知道是谁故障谁正常，也就无法完成故障转移等一系列动作。
好，我们接下来就来搞定仲裁配置。
2、仲裁配置操作对象：主服务器（A89230）
右击刚才创建的群集名称，依次选择 更多操作(M) > 配置群集仲裁设置(Q)... 。
仲裁配置选项中，选择 选择仲裁见证 。
选择仲裁见证中，选择 配置文件共享见证 。
输入文件共享路径（准备工作中已建立的共享文件夹），比如 \\A89219\ClusterSharing 。
点击下一步，完成仲裁设置。
系统会在共享文件夹中创建一些随机文件，用于分析和测试等动作。
最终完成后应该是这个样子。
两个节点服务器状态正常。
而此时，角色一栏内仍然是空的，因为涉及到具体的某个服务，就是我们需要到某个服务中来添加实现。
所以接下来我们就要转战 SQL Server ，来聊一下具体如何实现高可用功能。
小结由于文章整体篇幅较长，所以在下一篇文章中，我们将继续和小伙伴们详细探讨 SQL Server 的 Always On 高可用的具体创建和使用方法。
最后说句题外话，在此衷心祝贺高考考得比较好的同学们和屏蔽生同学们能尽早收获喜报，预祝你们前程似锦，将来造福社会，为祖国和人民多多贡献自己的力量！
网管小贾 / sysadm.cc
