SQL Server 2016标准版现在支持一个企业版级别的特性-可用性组! 当然, 你在企业中得到的东西有一些限制, 我稍后会讲到. 我很兴奋，因为必威app在哪里下载的一个客户想开始在生产中使用这个特性, 所以我想我最好能近距离接触这个新产品，建立一个测试环境，在真正实现它之前熟悉其中的陷阱. 但首先，我需要一个至少能容纳3个vm的环境. 我有什么选择?
我决定是时候深入了解Azure VM并打开我的MSDN订阅Azure积分的封印了. 我以前使用过Azure存储和备份，但还没有使用过VM. 凭借我丰富的VMware经验，我很容易上手并开始工作. 我在短时间内创建了三个虚拟机——一个域控制器和两个SQL server. 我意识到你可以创建SQL 2016 AGs没有域, 但是因为客户将使用域, 我想熟悉一下这个方法. 我使用Windows Server 2012 R2，因为这也是客户正在使用的. 我还需要记住，他们使用的是链接services器, 所以我需要确保启用选项WITH DTC_SUPPORT = PER_DB或在GUI设置中等效的复选框，以及安装KB3090973补丁Windows Server 2012 R2. 参考: http://blogs.technet.Microsoft.com/dataplatform/2016/01/25/sql-server-2016-dtc-support-in-availability-groups/
对Azure缺乏经验, 完成三个虚拟机的创建, 创建域, SQL虚拟机加入域, 在两个虚拟机上安装SQL, 我尝试创建集群. 正如墨菲所预言的那样，它失败了. 的原因? 在Azure中有一个叫做可用性集(Availability Set)的构造，你需要在创建虚拟机之前设置它，以便集群工作. 如下链接所定义: http://docs.Microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-portal-sql-alwayson-availability-groups-manual?toc=%2fazure%2fvirtual-machines%2fwindows%2ftoc.json
在创建虚拟机之前，您需要创建可用性集. 可用性集减少计划或计划外维护事件的停机时间. Azure可用性集是Azure放置在物理故障域和更新域上的一组逻辑资源. 故障域确保可用性集的成员具有独立的电源和网络资源. 更新域确保可用性集的成员不会同时停机进行维护."
所以我不需要手动挖掘，用我现有的知识来建立这些, 我读了一些之前链接的文章, 哪个是手册设置版本的说明. 它状态:
完成本教程需要几个小时，因为您必须构建和配置几个Azure虚拟机. 您还可以自动构建整个解决方案. 在Azure Portal中，为Always On可用性组设置了一个库和一个监听器. 图库设置自动配置可用性组所需的一切."
听起来不错，所以我选择了5个vm和一个侦听器的模板. 它会提示您输入域名, 公司名称, 侦听器的细节, 而其他的一切你可以手动设置，并在比几个小时更短的时间内为你生成. 它确实花了一些时间来显示和配置(可能一个小时?)，但经过一些耐心的等待，它终于完成了.
然而，当这一切都在建立的时候，我有一个会议要参加，所以我让它继续运行. 会议是在一天结束的时候举行的, 所以我很快就跑回家，忘记了跑步的环境，直到
第二天早上. 我登录到Azure，发现我的MSDN当月分配的资金已经被这个仅运行几个小时的环境耗尽了. 认真? 微软通过订阅MSDN给你足够的积分，让你稍微享受一下Azure的棒棒糖, 然后把它拿开，换成了刷卡器. 可惜的是，我一直没能继续测试，直到当前的每月计费周期结束.
而不是等待, 我决定看看我能否在我只有8GB内存的笔记本电脑上运行VirtualBox. 我最初使用Azure是因为我不认为我能在一台拥有这么多资源的机器上成功运行一个三个vm的环境, 但令我惊讶的是, 它实际上是成功的. 也, 因为网络都是在我的本地环境中运行的, 不像Azure那样需要担心可用性集类型的构造.
对于1GB RAM的虚拟机来说并不理想，但它们适合!
在将所有三个虚拟机设置为各自的角色，同时将网络配置为NAT后，我可以获得所有必要的Windows Server和SQL Server更新, 我把网络改成了Host-Only，这样我就可以在我的笔记本电脑里私有地运行了. 我还在VirtualBox中创建了一个额外的主机专用网络，这样我就可以将单个机器切换到另一个网络，以测试大脑分裂的情况.
我在每个虚拟机上安装了故障转移集群特性，包括DC. 我在域控制器上安装此角色的原因是，我希望仅从这台机器的控制台集中管理集群. 出于同样的原因，我还在域控制器上安装了SQL Server Management Studio. 我启动了故障转移群集管理器并启动群集验证向导. 我验证了一个集群配置，并使用新的SQL1和SQL2机器创建了集群. 然后在验证成功后创建集群.
它还活着!
然后，我在域控制器上创建了一个共享，用作集群的见证. 这使得集群更加可靠，因为这有助于在主节点故障时避免脑裂. 如果没有第三次投票, 如果主services器失败, 票数下降了50%还不是多数. 我配置了完全控制
SQL1$和SQL2$机器帐户的权限，因为SQL在这些机器上的默认services帐户下运行. SQLservices帐户需要对这些共享具有完全的读写权限，才能使文件共享见证正常工作. 然后，我使用故障转移集群管理器修改仲裁配置，以使用文件共享见证.
我能找个证人吗?
为什么是的. 是的,我能.
请选择文件共享路径，但请谨慎选择. 因为当真正的文件共享路径将在验证屏幕上为您带来绿色的复选标记, 错误的道路会把它们从你身边带走.
现在 见证 这个全副武装的作战基地的火力! 我的意思是,集群……
现在已经设置了Windows Server故障转移集群, 是时候创建可用性组了. 但在此之前，可以在SSMS中完成, 为了在每个实例上启用AGs，我必须执行一个奇怪的技巧. 我必须访问我的老朋友SQL Server配置管理器，并在实例级启用AlwaysOn可用性组.
打勾相当于吃红色药丸
当然, 我看到了许多令人愉快的微软对话框中的一个，它让我知道“您知道您将不得不为这个返回实例”, 正确的?"
这样我有空的时候就可以取消services了? 不错的交易!
单击OK并没有为我弹出实例. 然而, 如果我想禁用这个实例的AGs, 如果我想保存设置，它将不仅需要services重启, 但如果我点击Yes，它会立即重启. 当心!
所以我想，你是要强迫我放弃services? 这对最初的人来说是很清楚的. 但对于外行来说，这可能会让你措手不及. 小心打人是的!
现在我已经为AGs启用了两个实例, 是时候开放SSMS了, 右键单击新建的AlwaysOn高可用性节点，选择“新建可用性组向导”. 啊，终于回到了温暖舒适的管理工作室. 向导告诉我的第一件事是，我需要对有问题的数据库进行备份. 在向导的第一步中，它清楚地说明了“需要完全备份”. 我使用的是微软的Wide World进口商罐头数据库，我刚刚恢复了它, 但我还没有备份, 所以我手动创建了一个备份. 回到AG安装向导, 然后显示“满足先决条件”，并允许我单击Next. 下一个屏幕要求提供几条信息, 第一个是我想要使用的复制实例. 已经选择了SQL1，因为这是数据库最初驻留的地方. 有一个添加副本按钮，以及一个添加Azure副本按钮，这是一个引人注目的部署选项，我想尝试，当我再次有MSDN信用. 目前，我选择Add Replica并选择SQL2实例.
需要考虑的其他选项有自动故障转移、同步提交和可读辅助. 自动故障转移就像它听起来的那样. 我脑海里的第一个问题是，为什么我不想要这个? This is a high availability feature; why would I not want this to happen automatically? 不是每个人都用AGs来表示HA. 在企业版, 你可以将它设置为一个可读的Secondary，这意味着你可以对它执行select和备份，这样你就可以从主副本拉出读取和备份工作负载. 也, 两个副本之间的网络可能不适合来自主站点的生产流量, 所以这个AG可能只是某种温暖的备份. 因为标准版AGs不允许可读secondary, 事实上，这个功能应该消除老化的数据库镜像功能, 我想说的是，大多数标准版AGs都可能用于HA目的. 同步提交意味着每次更新、插入、删除、修改等. 在向客户端应用程序报告事务完成之前，将事务提交到所有辅助services器. 不选择此选项意味着事务在提交到主副本时将被报告完成，而辅助副本将尽快提交. 对于高可用性场景，我希望检查同步提交.
聚会上!
Endpoints选项卡用于管理AGservices端点主机名, 港口, services负责副本之间的内部通信. 微软建议为AG内部通信使用一个单独的网络, 类似于故障转移集群管理流量. 我可以在VirtualBox的secondary Host-Only网络上为每个SQL虚拟机添加第二个网卡，并修改绑定到这些网卡的主机名或IP地址，以使用这个私有网络, 但是我没有. 我也可以因为不透明或其他原因改变两边的端口. 如果我是多实例化的(请不要)，我将需要为每个实例使用一个单独的端口. 我保留了默认值.
Backup Preferences选项卡是我选择备份路由方式的地方. 如果次要副本可用，则“首选次要”将尝试备份到次要副本. 否则，将在主副本上进行备份. “仅从”将不允许备份到主副本，即使没有可用的从副本. 主services器只在主副本上进行备份. 任何副本不会优先选择主副本或辅助副本. 在这些选项下面, 有一个区域，我可以给所有副本的相对权重，并排除特定的副本. 当然, 所有这些选项都只能在企业版中使用，因为主副本只能在标准版中备份. 在标准版中，下面的屏幕通常是灰色的.
GUI非常棒. 这就是一个例子.
侦听器选项卡可用于在此向导中创建可用性组侦听器, 或者我可以选择稍后执行这个单独的步骤. 可用性组监听器是DNS名称, IP地址, 以及AG将用于客户端连接的端口. 我为侦听器提供了唯一的DNS名称和IP地址. 端口号可以是1433或其他.
通过在下一个屏幕上选择Full选项, 我可以让向导自动备份和恢复数据库到每个副本，通过网络共享，所有副本SQL Server帐户都有读写访问权. 或者，我可以手动将数据库恢复到辅助副本services器，并选择“仅加入”来初始化同步，或者如果您还没有准备好执行此步骤，则跳过初始数据同步. 我选择了full，并使用我之前创建的已经拥有所有必要权限的File Share Witness共享进行欺骗.
最后, 您可以验证您的AG配置没有错误，然后创建可用性组. 万岁!
请参阅本博客的第2部分，我将详细介绍这个设置的各个方面，看看它是多么健壮.
