如何将SQL Server 2008应用程序迁移到Azure

Dave Bermingham是 SIOS Technology的 技术 推广员 。

随着对SQL Server 2008和SQL Server 2008 R2的扩展支持于2019年7月结束，六个月后，到2020年1月对Windows Server 2008和2008 R2的扩展支持结束，紧接着就要对某些传统进行更改应用程序。 始终可以选择升级到最新版本，但是当升级不可行时， Microsoft将提供替代方案 ：将应用程序迁移到Azure云，以获得三年的免费扩展安全更新支持。

微软的提议：“将工作负载迁移到Azure虚拟机的客户将在支持终止期限后的三年内，可以访问SQL Server和Windows Server 2008和2008 R2的扩展安全更新，并且不包含标准VM定价的额外费用。 。” 为了协助迁移，Microsoft允许将现有的本地许可证转移到Azure云，并且还提供180天的过渡期，在此期间内，一个许可证可以同时在本地和云中同时应用。

[IDG研究： 云的状态：企业采用的方式正在形成 。 | 通过InfoWorld的云计算新闻通讯了解云计算的最新发展。 ]

对于那些仍然至关重要的旧版SQL Server 2008 / R2应用程序，将需要某种形式的高可用性或灾难恢复保护来保持业务连续性。 当然，可以在最新的Azure云中完全保护这些旧应用程序，但这需要了解并正确配置必要的规定。 对于使用了十年之久的软件，正确地进行安装可能会有些挑战。

本文概述了Azure云中可用于SQL Server 2008 / R2的高可用性（HA）和灾难恢复（DR）条款，并重点介绍了两种常见的HA / DR配置。 重要的是要注意，此处讨论的规定也适用于更高版本的SQL Server和Windows Server，从而使其适用于其他应用程序，包括任何正在升级的旧应用程序。 不同版本之间的任何差异都将被注意。

Azure中的高可用性选项

Azure云在数据中心内，区域内以及跨多个区域提供冗余。 数据中心内的冗余由可用性集提供，该可用性集将服务器分布在不同的故障域中。 每个故障域都位于不同的机架中，以防止服务器和机架级别的故障，使Microsoft能够提供99.95％的正常运行时间保证。 服务级别协议（SLA）确保如果在可用性集中部署了两个或更多服务器，则至少一个服务器将具有外部连接。 但是，SLA不能保证应用程序级别的可用性，并且它也无法保护站点范围的故障，例如2018年9月在Azure的美国中南部地区发生的故障。

为了防止单个站点范围的故障，Azure推出了可用性区域（AZ）。 每个支持可用区的区域都至少具有三个数据中心，这些数据中心通过能够支持同步数据复制的高带宽，低延迟网络互连。 当将多个服务器部署在不同的可用区中时，Microsoft提供99.99％的SLA，从而保证其中至少一台服务器具有外部连接性。

为了获得更大的弹性，Azure提供了区域对，其中区域与同一地理区域（例如美国，欧洲或亚洲）中的另一个区域相隔至少300英里。 从战略上选择了配对，以防止普遍的电源或网络中断以及重大自然灾害。 Microsoft还利用该安排来最大程度地减少基础结构更新期间的停机时间，并在发生广泛故障时加快恢复时间。

数据库和系统管理员应充分意识到，即使可用区和区域对提供了更高的正常运行时间保证，也可以将停机时间排除在应用程序级别的许多常见故障原因上。 这只是Azure服务级别协议中明确排除的常见失败原因的部分列表：Microsoft合理控制范围之外的因素； 使用Microsoft未提供的服务，硬件或软件； 客户的未经授权的行动或在需要时不采取行动； 以及错误的输入，指令或参数。 实际上，Microsoft的SLA保证了服务器的“拨号音”，仅此而已。 客户应确保应用程序级别的正常运行时间。

在Azure云的服务级别保证中排除了导致停机的许多常见原因之后，要为关键任务应用程序提供令人满意的HA保护，就需要第三方故障转移群集解决方案，如SIOS DataKeeper。 对第三方解决方案的需求源于以下事实：由于缺少存储区域网络或其他共享存储，传统的HA故障转移群集无法在Azure云中进行。 Microsoft通过引入虚拟共享存储解决方案Storage Spaces Direct（S2D）来解决此限制。 但是S2D从Windows Server 2016开始，并且仅支持SQL Server 2016和更高版本，因此对于SQL Server 2008 / R2来说不是一个选项。 同样，也不是随SQL Server 2012引入的更强大的“永远在线可用性组”功能。

Azure中的灾难恢复选项

使用Azure备份或Azure站点恢复，可以为某些应用程序提供足够的业务连续性或DR保护。 通过Microsoft的灾难恢复即服务（DRaaS）产品Azure备份和Azure Site Recovery，可以将应用程序的关键数据分别例行备份或复制到远程站点，并且在本地化的情况下可以还原。灾害。 两种服务均旨在满足不同需求。 Azure备份具有文件级粒度和更长的数据保留期。 但是备份代理仅支持SQL Server 2012及更高版本，使其无法作为SQL Server 2008 / R2应用程序的选项使用。

相比之下，Azure Site Recovery旨在保护整个工作负载，并且确实支持SQL Server 2008 / R2。 Azure Site Recovery自动将配置和活动实例上的所有数据复制到另一个数据中心中的另一个实例。 作为DRaaS解决方案，Azure Site Recovery协调活动实例和备用实例之间的复制以及故障转移/故障回复过程。 Azure Site Recovery能够适应从几分钟到几秒不等的恢复点目标（RPO），对于发生故障的实例，恢复时间目标（RTO）不到一小时，而经过特殊安排则只需几分钟。

由于Azure的正常运行时间被排除在外，再加上自2008年以来就无法利用许多增强功能和新服务，管理员发现，对保护SQL Server 2008 / R2应用程序充满信心的最佳方法是使用第三种方法，第三方故障转移群集解决方案，专用于高可用性和灾难恢复。

SQL Server 2008 / R2的第三方故障转移群集解决方案

在Azure中为SQL Server 2008 / R2实施HA或DR设置所涉及的最大挑战来自对故障转移群集实例（FCI）使用某种形式的共享存储（通常以SAN形式）的需求。 由于Azure云中唯一可用的共享存储是虚拟品种的（具有仅支持SQL Server 2016及更高版本的S2D），因此需要支持无SAN故障转移群集的第三方，基于软件的解决方案。

Microsoft认识到需要第三方故障转移群集技术来为许多应用程序提供HA保护。 该公司在其文档中包含有关配置SIOS DataKeeper的这些说明：“ 使用WSFC，Azure ILB和第三方软件SIOS DataKeeper的文件共享具有高可用性 。”

第三方故障转移群集解决方案至少包括实时数据复制，能够在应用程序级别检测到任何故障的连续监视，以及用于故障转移和故障回复的可配置策略。 Windows的大多数解决方案旨在与Windows Server故障转移群集（WSFC）无缝集成，以帮助简化实施。 许多解决方案还提供了其他高级功能，这些功能通常包括选择同步或异步复制，WAN优化以最大化性能，以及手动切换活动和备用任务分配，以执行计划内的维护和例行备份而不会中断应用程序。

无需SAN的故障转移群集软件通过使用本地连接的存储来构建SQL Server FCI（使其看起来似乎在成员实例之间共享）来工作。 这些虚拟卷实际上创建了一个抽象层来代替物理存储资源。 集群不像共享存储那样控制磁盘锁定或SCSI保留，而是控制虚拟卷之间或虚拟卷之间的镜像方向。 这种方法可确保将在活动实例上发生的写入复制到故障转移群集中的所有备用实例。 块级数据复制在同一Azure区域中的实例之间或之间同步发生，并且跨区域异步发生。 由此产生的无共享的无SAN故障转移群集配置消除了所有潜在的单点故障，从而确保了可靠的HA或DR保护。

大多数第三方故障转移群集解决方案都完全在软件中实施，以提供跨私有，公共和混合云基础架构的几乎无限的可伸缩性。 大多数还被设计为与应用程序和平台无关。 应用程序不可知论性支持几乎所有应用程序软件（包括SQL Server的所有版本）的支持，从而提供了通用的通用HA / DR解决方案。 这种相同的设计还使得可以在所有版本的SQL Server的标准版中支持FCI，以及在SQL Server 2012中引入的企业版中更高级的Always On Availability Groups功能。

平台不可知论使利用而不依赖于Azure云内部和针对Azure云的各种功能和服务（包括不同的虚拟机管理程序）成为可能。 尽管直到SQL Server 2017才支持Linux，但仍有适用于所有Linux应用程序的第三方故障转移群集解决方案。

无需SAN的故障转移群集专为实现高可用性和灾难恢复而设计，能够立即在应用程序级别检测故障，而不管其原因如何，并且没有Azure SLA中引用的异常。 因此，与标准Azure HA / DR相比，无SAN的故障转移群集可以容纳更严格的RPO和RTO，使其甚至适用于最关键任务的应用程序。

Azure中SQL Server 2008 / R2的HA / DR配置

由于旧版SQL Server 2008 / R2应用程序的HA设置在Azure云中存在问题，因此唯一可行的选择是第三方故障转移群集解决方案。 对于灾难恢复，管理员可以选择对高可用性和灾难恢复使用Azure Site Recovery或故障转移群集。 本节重点介绍了两种配置，并概述了实现每种配置所需的基本步骤。

重要说明：若要在Windows Server 2008 R2或Windows Server 2012上的Azure中的故障转移群集上运行SQL Server应用程序， Microsoft提供此修补程序以使FCI和可用性组都可以使用侦听器。 根据配置，可能需要其他修补程序。 如果可能，使用Windows Server 2012 R2或更高版本可以消除对任何修补程序的需求。

HA的故障转移群集和DR的Azure Site Recovery的结合为许多SQL Server应用程序提供了一种经济高效的解决方案。 FCI所需的共享存储由无SAN HA的故障转移群集中的虚拟卷提供。 Azure Site Recovery将群集中的一对VM映像（活动和备用）复制到区域对中的另一个区域，以防止发生广泛的灾难。

将现有的SQL Server 2008 / R2故障转移群集“从本地迁移到Azure云”非常简单：它涉及用虚拟卷替换物理磁盘资源，并用文件共享见证替换磁盘见证。 在迁移期间，Azure Site Recovery可用于将现有的本地活动VM复制到Azure云中的活动VM和备用VM。 最后一步涉及为客户端重定向配置Azure内部负载平衡器（ILB），并在本地节点上运行PowerShell脚本以更新SQL Server群集IP资源以侦听ILB探针。 由于群集实例的IP地址和子网可能会在迁移过程中发生更改，因此此步骤可能还需要对相关IP地址和作业终结点进行其他更改。

From: https://www.infoworld.com/article/3357721/how-to-migrate-sql-server-2008-applications-to-azure.html