Date: 2月 18, 2018
标签：SQL Server 2012, Windows Azure, 高度可用
停机时间！谁应该承担责任？
确保高可用性选项对于SQL Server，始终可能是我们使用云服务的主要原因。但是，防止与云中断相关的停机时间是任何在任何云服务上部署的人都需要解决的问题。只需在“云端”部署您的应用程序并假定现在管理其他人的问题很容易。云提供商可能拥有更多资源和专业知识，以确保您的服 但确保您的关键应用程序可用的最终责任完全在于您。
SQL Server的高可用性选项并不像ABC那么容易
信不信由你，只需在Windows Azure中部署你的SQL Server就不会使它“高度可用”。为了使其高度可用，您必须使用您可能在自己的数据中心中使用的传统工具和技术。虽然对此主题有不同意见，但我认为SQL Server 2012/2014的高可用性选项如下：
无论您选择哪个选项，您都希望熟悉Windows Azure故障域，如下所述：
“尽管如此，在Windows Azure中，一台计算机确实被确定为故障域。并且在部署时由Windows Azure确定故障域的分配。服务所有者无法控制故障域的分配，但可以通过编程方式找出服务在哪个故障域中运行。Windows Azure计算服务SLA仅在部署服务的每个角色的两个或多个实例时才保证已部署服务的连接正常运行时间级别“
让您的SQL Server驻留在不同的故障域中
在您开始部署Windows Azure VM时，请确保每个SQL Server和任何“见证”服务器驻留在不同的故障域中。通过将所有虚拟机置于相同的“可用性集”中来实现这一点。本质上，同一个可用性集中的每个服务器都驻留在不同的故障域中，希望能够消除故障。
将所有虚拟机置于不同的故障域中，并配置SQL Server故障转移群集或可用性组，以防止可能本地化为单机架服务器，即AKA故障域的常见故障类型。我已经写了一篇文章，题为在Windows Azure IaaS中使用DataKeeper创建SQL Server 2014 AlwaysOn故障转移群集（FCI）实例，这应该有助于您在Azure云中为您的SQL Server构建灵活性。
但是，如果Windows Azure发生重大中断并导致整个地区发生什么？
自然灾害或人为错误可能是导致此类停电的原因。不幸的是，在这一点上，无法在两个不同的Azure区域之间拉伸Azure虚拟专用网络。这包括东南亚。但是，Azure虚拟专用网络可以支持与有限数量的VPN设备进行站点到站点VPN连接。这些设备来自思科，瞻博网络甚至微软RRAS。
如何在Azure之外的某个地方？
这让我们想到了Azure之外的其他位置，甚至是我们自己的私人数据中心。我最近编写了一篇分步说明文章，介绍如何将您的内部数据中心扩展到Azure Cloud。将数据中心连接到Windows Azure，配置AlwaysOn可用性组或AlwaysOn故障转移群集（多站点），以防止发生灾难性Azure故障。我以前写过关于多站点群集的优势与 可用性组。 因此，在我的实验室中，我决定在Azure中创建一个双节点SQL故障转移群集实例，然后在我的主数据中心添加第三个节点。我在我的博客文章中写了详细的配置步骤，名为“在Windows Azure中创建多站点群集以进行灾难恢复”。
如果您更愿意使用AlwaysOn可用性组，则可能需要访问Windows Azure中的AlwaysOn可用性组（GUI）和Windows Azure中的AlwaysOn可用性组的Listener配置教程。如果您使用的是SQL 2008 R2或更早版本，我相信您可以配置数据库镜像。此时，如果您正在转向Azure，那么我假设您可能正在部署SQL Server 2012或2014。日志传送和复制等其他技术是移动数据的选项，但我不认为它们是高可用性解决方案。
经https://clusteringformeremortals.com/2014/01/15/windows-azure-high-availability-options-for-sql-server-azure-cloud-iaas/许可转载