如何将HA和DR引入Amazon EC2上的SQL Server

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

从纯私有云到公共云和混合云的成功迁移大大提高了IT管理员对云的信心。 根据其久经考验的安全性和可靠性，Amazon Web Services是管理员选择的顶级云服务提供商之一。 但是，为关键任务SQL Server数据库提供足够的高可用性和灾难恢复保护仍然面临挑战。

本文为负责保护运行在Amazon Elastic Compute Cloud（EC2）中的关键任务SQL Server的系统和数据库管理员提供了一些实用指南，从通常如何配置这些数据库开始。

[Amazon Web Services，Google Cloud Platform或Microsoft Azure？ 了解它们如何在InfoWorld上堆叠： Azure击败AWS的12种方法 。 • Google Cloud击败AWS的11种方式 。 • AWS击败Azure和Google Cloud的11种方式 。 | 通过InfoWorld的云计算新闻通讯了解云计算的最新发展。 ]

Amazon EC2实例存储与EBS

冒着过于简化的风险，AWS有两个通常用于SQL Server数据库的EC2存储选项：实例存储和弹性块存储。 实例存储是一种使用本地连接的媒体（SSD或HDD）的临时存储或非永久存储。 默认情况下，数据存储是不复制的，并且此选项不支持快照。 对于临时数据库，实例存储是一个不错的选择，当对持久性和保护数据进行单独的补充时，实例存储对于超大型数据库或需要高事务吞吐量的数据库也是一个不错的选择。

弹性块存储（EBS）是针对随机I / O优化的块级存储。 EBS保留并复制数据，提供本机冗余，并且支持快照。 其他优点包括支持写缓存和加密EBS卷中的静态数据。 对于需要高吞吐量性能的应用程序，AWS建议使用分条。 除了提供通用存储，EBS还提供了卷类型的选择，以实现预配置的IOPS性能或吞吐量优化。

尽管EBS似乎是保护SQL Server数据库的更好选择，但是实例存储能够提供远远优于EBS的性能，其吞吐量高达EBS的10倍，并且最多支持48 TB的存储。 尽管EC2不包含任何高可用性（HA）或灾难恢复（DR）条款，但可以通过其他方式为任务关键型数据库提供全面保护。

对于实例存储和弹性块存储，有两种最适合在数据库应用程序中使用的EC2计算实例：针对I / O的内存优化或存储优化。 尽管配置的这一方面超出了本文的讨论范围和意图，本文的重点是保护数据，但这里是适合那些有兴趣了解更多信息的计算实例：X1，X1E，R5，R5d和Z1d。内存和I3（在优化存储I / O时）。

值得注意的是，AWS还提供了完全托管的关系数据库服务（RDS），可以选择六个不同的数据库引擎。 但是，请注意，RDS对SQL Server的支持不像对其他数据库（如Amazon Aurora，MySQL和MariaDB）那样强大。 以下是管理员对于将RDS用于关键任务SQL Server应用程序时应注意的一些常见问题：

• 仅支持单个镜像备用实例
• 代理作业未镜像，必须在备用实例中单独创建
• 不支持灾难恢复所需的多区域配置
• 不支持性能优化的内存数据库实例
• 根据可用区分配，性能可能受到不利影响，客户无法控制这些分配
• 需要更昂贵的企业版及其“永远在线可用性组”功能来复制数据

Amazon EC2 SLA警告免责声明

在介绍适用于SQL Server的HA / DR选项之前，请务必了解Amazon EC2服务级别协议中的某些限制。 当使用多个可用区时，AWS SLA保证正常运行时间为百分之九或99.99。 SLA是一项退款保证，每当每月的服务水平降至四个九点以下时，可提供10％至100％的退款，而当服务水平降至95.0％以下时，将提供全额退款。

问题是，SLA对于什么是正常运行时间的看法很狭窄。 明确排除的是由以下原因引起的任何停机或不可用状态：“我们无法合理控制的因素”（例如自然灾害）； “您或任何第三方的作为或不作为”（即人为错误）； 和“您的设备，软件或其他技术和/或第三方设备，软件或其他技术”（例如SQL Server）。 实际上，AWS仅保证“拨号音”，即至少一个EC2实例将具有外部连接。 换句话说，数据库本身的任何故障或访问数据库的任何应用程序都不会被覆盖，甚至无法检测到。

因此，尽管利用AWS云中可用的各种服务是有利的，但还需要其他规定来确保在数据库和应用程序级别对SQL Server进行足够的HA和DR保护。 这些都是从SQL Server本身开始的。

SQL Server的Always On选项

SQL Server提供了两个自己的选项来保护数据：“永远在线的故障转移群集实例”和“永远在线的可用性组”。 自SQL Server 7以来，始终处于故障转移状态的群集实例（FCI）一直是标准功能。FCI具有两个主要优点：包含在SQL Server标准版中以及对整个SQL Server实例（包括系统数据库）提供保护。 一个明显的缺点是需要支持群集的共享存储，而该存储在AWS云中不可用。 相反，在前提下，共享存储可以并且经常存在，FCI是可行且流行的选择。 实际上，它们是自SQL Server 7以来主要的HA解决方案。

Always On可用性组替换了SQL Server 2012 Enterprise Edition中的数据库镜像，并且此功能也包含在Linux的SQL Server 2017中。 这是SQL Server的更强大的HA / DR产品，能够提供快速，自动的故障转移而不会丢失HA的任何数据，并通过利用异步复制以最小的数据丢失来保护免受广泛的灾难。 可用性组的另一个优点是支持可读的辅助副本（具有适当的许可）。 但是，此选项需要许可更昂贵的企业版，从而使它对于许多应用程序来说都是成本高昂的，并且缺乏对整个SQL Server实例的保护。 SQL Server 2016的标准版中添加了一个功能较弱的基本可用性组功能，但每个可用性组仅支持单个数据库，并且不允许可读的辅助数据库。

应用程序专用选项（如始终在线的可用性组）的显着缺点是管理员需要为所有非SQL Server应用程序实施其他HA或DR解决方案。 拥有多个HA / DR解决方案不可避免地会增加复杂性和成本（用于许可，培训，实施和正在进行的操作），这就是为什么许多组织更喜欢使用第三方，通用或与应用程序无关的解决方案的原因。

SQL Server的第三方HA / DR选项

将AWS云配置为关键任务HA / DR保护时可能遇到的最大挑战是，传统的故障转移群集解决方案（例如Windows Server故障转移群集（WSFC））使用共享存储，并且没有可用的共享存储。 Microsoft通过Windows Server 2016和SQL Server 2016中的Storage Spaces Direct（S2D）的出现解决了此问题。但是，由于S2D不支持跨越可用区的配置（这是HA配置中的关键要求），因此对于AWS而言，这不是一个可行的选择。

Linux面临的挑战更大。 由于Linux缺乏与WSFC相当的基本群集功能，因此管理员一直在努力使用开放源代码软件可靠地使自己动手做的HA Linux配置可靠地工作。 但是，完整的HA堆栈的复杂性使这项艰巨的工作成为现实，破坏了在公共云服务中在商品硬件上使用开源软件的节省成本的原理。 结果，对于大多数组织而言，DIY HA项目的成本过高。 仅使分布式复制块设备，Corosync，Pacemaker和其他可选的开放源代码软件在单个故障情况下按应用程序级别正常工作可能非常困难。 出于这个原因，只有最大的组织才具有考虑进行任务所需的资金（技能和人员配备）。

第三方故障转移群集解决方案（例如SIOS DataKeeper和SIOS Protection Suite）已针对Windows Server和Linux进行了各种挑战，这些解决方案专门针对私有，公共和混合云环境而构建。 这些解决方案完全以软件实现，从而无需共享存储即可创建服务器和存储群集，并具有自动故障转移功能，以确保应用程序级别的高可用性。 一些更复杂的解决方案还提供高级功能，例如WAN优化以最大化多区域性能，以及手动切换活动和备用服务器分配以促进计划的维护。

Windows Server的版本旨在与WSFC无缝协作，从而在本地SAN或基于云的SANless环境中提供实时的块级数据复制。 一个主要优点是，在价格不昂贵的Windows Server标准版SQL Server中支持FCI，而无需牺牲可用性或性能。

Linux版本必须提供完整的HA / DR解决方案，其中包括数据复制，连续的应用程序级监视以及可配置的故障转移/故障回复恢复策略。 Linux在SQL Server和许多其他企业应用程序中正变得越来越流行，并且第三方故障转移群集解决方案现在使实现HA / DR设置几乎与Windows Server一样容易。

尽管特定于操作系统，但大多数故障转移群集软件都是与应用程序无关的，从而使组织可以拥有一个通用的HA / DR解决方案。 这种相同的功能使以集成方式保护整个SQL Server实例（包括数据库，登录，代理作业等）成为可能。

无论是对于Windows Server还是Linux，SANless故障转移群集都为实例存储和EBS提供数据复制，克服了前者的局限性并替换了（或补充了）后者提供的复制。 对于位于单个AWS区域内的群集，数据复制是同步的，并且故障转移可以自动进行。 对于跨多个区域的群集，数据复制是异步的，以避免对吞吐量性能产生不利影响，并且手动进行故障转移以最大程度地减少数据丢失的可能性。

下图显示了一种流行的EC2配置，该配置在虚拟私有云（VPC）中提供了HA和DR保护，该私有云将三个SQL Server实例分布在多个可用区和区域中。 该配置可实现针对局部故障的快速自动故障转移，并有助于进行全面的（尽管是手动的）灾难恢复。 请注意，此配置还克服了另一个限制（在SQL Server标准版中是一个限制），即在故障转移群集中只能有两个FCI节点。

SIOS技术

无SAN故障转移群集的这种常见配置包括一个跨两个AWS可用区的两节点HA群集以及一个部署在提供灾难恢复保护的单独AWS区域中的第三个实例。

当然，无SAN故障转移群集只能配置有一个备用实例。 但是，这种最小的配置确实需要第三个节点作为见证方。 需要见证人来实现确定活动实例分配的法定人数，而这一重要任务通常由Windows Server实例在单独的可用区中执行。 将所有三个节点（活动，备用和见证）保持在不同的可用区中，可以避免在任何可用区脱机的情况下丢失多票的可能性。

出于HA或DR的目的，在混合云配置中还可以具有两节点和三节点的无SAN故障转移群集。 一种这样的三节点配置是位于企业数据中心中的两节点HA集群，该集群具有异步数据复制到AWS云以进行灾难恢复保护的功能，反之亦然。

From: https://www.infoworld.com/article/3410756/how-to-bring-ha-and-dr-to-sql-server-on-amazon-ec2.html