SIOS SANless clusters High-availability Machine Learning monitoring
2016年6月21日 – 更新。自从我发布这篇文章以来，一位可靠的消息来源告诉我，有一个更新的PowerShell脚本可以更可靠地更改现有Azure VM的可用性集。我还没有尝试过。但我相信来源和Microsoft Premiere Support指导他阅读本文。https://gallery.technet.microsoft.com/Azure-RM-Availability-Set-39e19d01我有点惊讶地发现，在创建虚拟机后，更改VM所在的可用性集并不容易。Azure门户没有将现有VM添加到可用性集的机制。幸运的是，我偶然发现了这个巨大的资源。设置Azure资源管理器VM可用性集通过利用该文章中可供下载的PowerShell脚本，我能够将两个现有VM添加到我创建的内容中。最后，我可以更改现有Azure VM的可用性集 – 真正的救命！
在本文中，我们将详细介绍在Azure Resource Manager中部署SQL Server故障转移群集所需的特定步骤。我将假设您熟悉基本的Azure概念以及基本的SQL Server故障转移群集概念。使用Azure资源管理器在Azure的单个区域中部署双节点SQL Server故障转移群集并不是一门火箭科学。我将在本文中关注的是在Azure Resource Manager中部署SQL Server故障转移群集的独特性。如果您仍在使用Azure Classic并且需要在Classic中部署SQL Server故障转移群集，请阅读我的文章“STEP-BY-STEP：如何在MICROSOFT AZURE IAAS中配置SQL SERVER FAILOVER群集实例（FCI）#SQLSERVER #AZURE＃ SANLESS“在开始之前，让我们熟悉Azure虚拟机中SQL Server的Windows Azure文章，高可用性和灾难恢复。在该文章中概述了所有HA选项。这包括AlwaysOn AG，数据库镜像，日志传送，备份和还原以及最终故障转移群集实例。假设由于与SQL Server企业版相关的成本或缺乏功能而忽略了其他选项，我们将重点关注最终选项 – SQL Server AlwaysOn故障转移群集实例（FCI）。当您阅读该文章时，很明显Azure中缺少群集感知共享存储是部署SQL Server故障转移群集的障碍。但是，该文章中描述了一些替代方案。我们将专注于使用SIOS DataKeeper，以提供要在群集中使用的存储。图1 Microsoft对SQL Server故障转移群集的支持策略https://azure.microsoft.com/en-us/documentation/articles/virtual-machines– windows-classic-sql-dr / [/ caption]使用DataKeeper Cluster Edition，您可以获取本地连接的存储，无论是Premium还是标准磁盘，并在两个磁盘之间同步，异步或混合或同时复制这些磁盘或更多群集节点。此外，DataKeeper Volume资源在Windows Server故障转移群集中注册，该资源取代了物理磁盘资源。DataKeeper Volume不是像物理磁盘资源那样控制SCSI-3保留，而是控制镜像方向，确保活动节点始终是镜像源。就SQL Server和故障转移群集而言，它的外观，感觉和气味就像物理磁盘一样，其使用方式与物理磁盘资源的使用方式相同。
如果您熟悉Azure资源管理器，您就会发现其中一项重要的新功能是能够使用部署模板快速部署由相互关联的Azure资源组成的应用程序。其中许多模板都是由Microsoft开发的，并且可以在Github上的社区中以“快速入门模板”的形式获得。社区成员也可以自由扩展模板或在GitHub上发布自己的模板。SIOS Technology发布的一个名为“带有SIOS DataKeeper Azure部署模板的SQL Server 2014 AlwaysOn故障转移群集实例”的模板完全自动化了将2节点SQL Server FCI部署到新的Active Directory域的过程。要部署此模板，只需单击模板中的“部署到Azure”按钮即可。图2-访问https://github.com/SIOSDataKeeper/SIOSDataKeeper-SQL-Cluster以快速配置双节点SQL群集[/ caption]
虽然自动Azure部署模板是一种快速简便的方法，可以快速获得双节点SQL Server FCI，但存在一些限制。首先，它使用SQL Server的180天评估版本，因此除非升级SQL eval许可证，否则不能在生产中使用它。此外，它构建了一个全新的AD域，因此如果要与现有域集成，则必须手动构建它。要在Azure中构建一个双节点SQL Server故障转移群集实例，我们假设您有一个基于Azure资源管理器（而不是Azure Classic）的基本虚拟网络，并且您至少有一个虚拟机已启动并运行并配置为域控制器。配置虚拟网络和域后，您将配置两个新虚拟机，它们将充当群集中的两个节点。我们的环境将如下所示：DC1 – 我们的域控制器和文件共享见证SQL1和SQL2 – 我们的SQL Server群集的两个节点
使用Azure门户，我们将以完全相同的方式配置SQL1和SQL2。有多种选择可供选择，包括实例大小，存储选项等。本指南并不是在Azure中部署SQL Server的详尽指南，因为有一些非常好的资源，每天都有更多的资源发布。但是，在创建实例时要记住几个关键事项，尤其是在群集环境中。可用性集 – SQL1，SQL2和DC1都位于同一可用性集中非常重要。通过将它们放在相同的可用性集中，我们确保每个群集节点和文件共享见证驻留在不同的故障域和更新域中。这有助于确保在计划维护和计划外维护期间，群集将继续能够维持法定人数并避免停机。图3 – 确保将两个群集节点和文件共享见证添加到同一个可用性集[/ caption]
配置每个VM后，您将需要进入设置并更改设置，以使IP地址为静态。我们不希望更改群集节点的IP地址。图4 – 确保每个群集节点都使用静态IP [/ caption]
就存储而言，您将需要参考Azure虚拟机中SQL Server的性能最佳实践。在任何情况下，您至少需要为每个群集节点添加至少一个额外的磁盘。DataKeeper可以使用基本磁盘，高级存储甚至是存储池中包含多个磁盘的存储池。只需确保为每个群集节点添加相同数量的存储并以相同方式对其进行配置。图5 – 确保为每个群集节点添加额外的存储空间[/ caption]
假设已按上述方式配置了两个群集节点（SQL1和SQL2）并将其添加到现有域中，我们就可以创建群集了。在创建群集之前，需要启用一些功能。这些功能是.Net Framework 3.5和故障转移群集。需要在两个群集节点上启用这些功能。图6 – 在两个群集节点上启用.Net Framework 3.5和故障转移群集功能[/ caption]一旦启用了这些功能，您就可以构建您的集群。我要向您展示的大多数步骤都可以通过PowerShell和GUI执行。但是，我将建议您在第一步中使用PowerShell创建群集。如果您选择使用故障转移群集管理器GUI来创建群集，您会发现群集正在发出重复的IP地址。在不详细介绍的情况下，您会发现Azure VM必须使用DHCP。通过在Azure门户中创建VM时指定“静态IP”，我们所做的就是创建一种DHCP预留。它不完全是DHCP保留，因为真正的DHCP保留会从DHCP池中删除该IP地址。相反，在Azure门户中指定静态IP只是意味着如果在VM请求它时该IP地址仍然可用，Azure将向其发出该IP。但是，如果您的VM处于脱机状态且另一台主机在同一子网中联机，则可能会发出相同的IP地址。Azure实施DHCP的方式还有另一个奇怪的副作用。在主机使用DHCP（必须使用DHCP）时使用Windows Server Failover Cluster GUI创建群集时，无法指定群集IP地址。相反，它依靠DHCP来获取地址。奇怪的是，DHCP将发出重复的IP地址，通常与请求新IP地址的主机具有相同的IP地址。群集通常会完成，但您可能会遇到一些奇怪的错误，您可能需要从其他节点运行Windows Server Failover Cluster GUI才能运行它。一旦运行它，您将需要将群集IP地址更改为网络上当前未使用的地址。只需通过Powershell创建集群并指定集群IP地址作为PowerShell命令的一部分来创建集群，就可以避免这种混乱。您可以使用New-Cluster命令创建集群，如下所示：
New-Cluster -Name cluster1 -Node sql1，sql2 -StaticAddress 10.0.0.101 -NoStorage
群集创建完成后，您还需要运行以下命令来运行群集验证：
测试群集
图7 – 集群创建的输出和集群验证命令[/ caption]
由于没有共享存储，因此您需要在与两个群集节点相同的可用性集中的另一台服务器上创建文件共享见证。通过将其置于相同的可用性集中，您可以确保在任何给定时间仅从您的法定人数中失去一票。如果您不确定如何创建文件共享见证，可以查看本文http://www.howtonetworking.com/server/cluster12.htm。在我的演示中，我将文件共享见证放在域控制器上。我已经在https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-上发布了对群集仲裁的详尽解释。在窗口服务器-2012-R2 /在
创建集群后，就可以安装DataKeeper了。在创建初始群集后安装DataKeeper非常重要，这样可以向群集注册自定义群集资源类型。如果在创建群集之前安装了DataKeeper，则只需再次运行安装并执行修复安装。图8 – 创建集群后安装DataKeeper [/ caption]在安装过程中，您可以使用所有默认选项。 您使用的服务帐户必须是域帐户，并且位于群集中每个节点上的本地管理员组中。图9 – 服务帐户必须是每个节点上Local Admins组中的域帐户[/ caption]一旦安装DataKeeper并获得许可您将需要重新启动服务器的每个节点。
要创建DataKeeper Volume Resource，您需要启动DataKeeper UI并连接到这两个服务器。
连接到SQ
L1连接到S
QL2连接到每个服务器后，您就可以创建DataKeeper卷了。右键单击Jobs并选择“Creat
e Job”为作业命名和描述。
选择源服务器，IP和卷。IP地址是复制流量是否会传播。
选择目标服务器。
选择你的选择。对于两个VM位于同一地理区域的目的，我们将选择同步复制。对于更长距离的复制，您将需要使用异步并启用一些压缩。
通过在上次弹出窗口中单击“是”，您将在故障转移群集中的可用存储中注册新的DataKeeper卷资源。
您将在可用存储中看到新的DataKeeper卷资源。
您现在可以安装第一个节点了。群集安装将像您构建的任何其他SQL群集一样继续。我没有复制每一个屏幕截图，只是为了引导你一路走来。
您会看到DataKeeper Volume Resource被识别为可用磁盘资源，就像它是共享磁盘一样。
记下您在此处选择的IP地址。它必须是网络上唯一的IP地址。我们稍后在创建内部负载均衡器时将使用相同的IP地址。
第一个节点成功安装后，您将使用“将节点添加到SQL Server故障转移群集”选项在第二个节点上开始安装。再一次，安装非常简单，只需使用标准的最佳实践，就像使用任何其他SQL群集安装一样。
以下是Azure中的故障转移群集与传统基础结构的不同之处。Azure网络堆栈不支持免费ARPS，因此客户端无法直接连接到群集IP地址。相反，客户端连接到内部负载平衡器并重定向到活动群集节点。我们需要做的是创建一个内部负载均衡器。这可以通过Azure门户完成，如下所示。首先，创建一个新的Load Ba
lancer如果您的客户端通过公共Internet连接，您可以使用公共负载均衡器。但假设您的客户端位于同一个vNet中，我们将创建一个内部负载均衡器。需要注意的重要一点是，虚拟网络与群集节点所在的网络相同。此外，您指定的专用IP地址将与用于创建SQL群集资源的地址完全相同。
创建内部负载均衡器（ILB）后，您需要对其进行编辑。我们要做的第一件事就是添加一个后端池。通过此过程，您将选择SQL Cluster VM所在的可用性集。但是，当您选择要添加到后端池的实际VM时，请确保不要选择文件共享见证。我们不希望将SQL流量重定向到您的文件共享见证。
接下来我们要做的就是添加一个Probe。我们添加的探针将探测端口59999。此探针确定群集中哪个节点处于活动状态。
最后，我们需要一个负载平衡规则来重定向SQL Server流量。在我们的示例中，我们使用了一个使用端口1433的SQL默认实例。您可能还希望根据应用程序要求添加1434或其他规则。在下面的屏幕截图中需要注意的重要事项是直接服务器返回已启用。确保你做出改变。
在Azure资源管理器中部署SQL Server故障转移群集的最后一步。 在其中一个群集节点上运行以下PowerShell脚本。这将允许群集IP地址响应ILB探测并确保群集IP地址和ILB之间不存在IP地址冲突。请注意;您需要编辑此脚本以适合您的环境。子网掩码设置为255.255.255.255，这不是错误，保持原样。这将创建一个特定于主机的路由，以避免与ILB发生IP地址冲突。
＃定义变量
$ ClusterNetworkName =“”
＃群集网络名称
（在更高版本的Windows Server 2012上使用Get-ClusterNetwork查找名称）
$ IPResourceName =“”
#IP地址资源名称
$ ILBIP =“”
＃内部负载均衡器的IP地址（ILB）
导入模块FailoverClusters
＃如果您使用的是Windows Server 2012或更高版本：
Get-ClusterResource $ IPResourceName | SET-ClusterParameter
-Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask =“255.255.255.255”;
网络= $ ClusterNetworkName; EnableDHCP时= 0}
＃如果您使用的是Windows Server 2008 R2，请使用以下命令：
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999
子网掩码= 255.255.255.255
您现在应该具有正常运行的SQL Server故障转移群集实例。面临在Azure资源管理器中部署SQL Server故障转移群集的问题？在Twitter @daveberm上联系我，我很乐意提供帮助。如果您需要DataKeeper评估密钥，请填写http://us.sios.com/clustersyourway/cta/14-day-trial上的表格，SIOS将发送一封发送给您的评估密钥。
对于那些仍然不时使用IE 11的人，您可能已经注意到，在最近的更新中，您的默认搜索提供程序可能已更改为Bing。如果您想了解如何将Internet Explorer 11从Bing更改为Google，请继续阅读。微软已经进行了安全性增强。它希望通过更改默认搜索引擎和主页来阻止恶意软件劫持浏览器。我是两个十几岁的“游戏玩家”的父亲，他们总是处于下载最新恶意软件的边缘。因此，虽然我很欣赏增加的安全性，但仍有一点点担心。此安全更新的一个“好处”是默认搜索提供程序现在是Bing。将其切换回Google并不像1-2-3那么容易。Microsoft在其文章中发布了有关如何将Bing Explorer 11从Bing更改为Google的步骤：http：//windows.microsoft.com/en-us/windows-10/internet-explorer-11-settings-protection不要请记住我 我喜欢微软的产品。但不幸的是，Bing对我所做的搜索类型并不友好，因为它通常会寻找一些非常具体的技术内容。我认为Bing可能对消费者友好。然而，谷歌在给我答案的过程中赢得了搜索引擎大战
要将Internet Explorer 11从Bing更改为Google，请按照本文中的这些步骤操作。下面的屏幕截图显示了步骤。
今天，我学到了一些新东西 – Azure门户GUI上的不同名称。我试图帮助客户在Azure Classic中部署一些具有两个NIC卡的VM。没问题我说，自从我使用Azure Classic以来已经有一段时间了。 我记得这很简单，虽然它必须通过PowerShell完成，因为门户网站中没有用于部署两个NIC的GUI选项。基本方向可以在这里找到。https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-multiple-nics/然而，在我的头撞墙几个小时之后，我偶然发现了这个信息。https://thelonedba.wordpress.com/2015/07/17/new-azurevm-badrequest-the-virtual-network-foo-does-not-exist
看起来Azure门户GUI关于虚拟网络名称的说法有时可能与运行Get-AzureVMNetSite时返回的实际名称完全不同。选择名称。从本质上讲，Azure门户GUI上有一个不同的名称。为什么会这样呢？请参阅下面的屏幕截图。我创建的名为“Public-Azure-East”的虚拟网络实际上称为“Group Group Azure Public East”。如何发生这种情况以及为什么Azure门户GUI上有不同的名称是我无法理解的。如您所见，我在创建虚拟机时的微弱尝试失败了。它说“BadRequest：虚拟网络Public-Azure-East不存在。”我确信它与我使用的多个订阅有关。但事实证明，这是一个在Azure门户GUI上显示不同名称的错误。
为什么像创建具有两个NIC的VM这样简单的事情无法通过GUI实现完全是另一个故事。经Clusteringformeremortals.com许可转载
使用SIOS DataKeeper Cluster Edition可以对SQL Server Standard Edition进行灾难恢复。就是这样。由于SQL Server Enterprise Edition的成本，许多人发现自己已经开始使用SQL Server Standard Edition。SQL Server标准版具有许多相同的功能，但它有一些限制。一个限制是它不支持AlwaysOn可用性组。此外，它仅支持群集中的两个节点。由于数据库镜像已被弃用且仅支持标准版中的同步复制，因此您实际上具有有限的灾难恢复选项。
其中一个选项是SIOS DataKeeper Cluster Edition。DataKeeper将与您现有的共享存储群集配合使用。该软件允许您使用同步或异步复制将其扩展到第3个节点。如果您使用的是SQL Server Enterprise，只需将该第3个节点添加为真正的多站点群集的另一个群集成员即可。但是，由于我们讨论的是SQL Server Standard Edition，因此无法将第3个节点直接添加到群集中。好消息是DataKeeper将允许您将数据复制到第三个节点，以便您的数据受到保护。SQL Server Standard Edition的灾难恢复意味着您将使用DataKeeper将第3个节点作为镜像源联机。接下来，使用SQL Server Management Studio装载复制卷上的数据库。您的客户还需要重定向到第3个节点。但它是一种非常具有成本效益的解决方案，具有出色的RPO和合理的RTO。SIOS文档讨论了如何为SQL Server Standard Edition执行灾难恢复。在这里，我总结了一些客户最近的步骤。
上述步骤假设您在所有三台服务器（PRIMARY，SECONDARY，DR）上安装了SIOS DataKeeper Cluster Edition。PRIMARY和SECONDARY是一个双节点共享存储集群。您正在将数据复制到DR，这只是一个独立的SQL Server实例（不是群集的一部分），只有本地附加存储。灾难恢复服务器将具有与共享群集卷大小和驱动器号相同的卷。这项工作相当不错，如果您没有配置自己的灾难恢复站点，甚至可以让您复制到云中的目标。如果要完全消除SAN，还可以使用所有复制存储构建相同的配置。这是一个很好的短视频，演示了SQL Server Standard Edition的灾难恢复的一些可能配置。 http://videos.us.sios.com/medias/aula05u2fl经Clusteringformeremortals.com许可转载