确保Amazon Web Services上的SQL Server高可用性

Date: 1月 30, 2019

标签：sql server的高可用性

确保Amazon Web Services上的SQL Server高可用性

数据库和系统管理员长期以来拥有广泛的选项来确保任务关键型数据库应用程序保持高可用性。公共云基础架构（如Amazon Web Services提供的基础架构）提供了自己的，由服务级别协议支持的其他高可用性选项。但是在公共云中可能无法在私有云中很好地工作。使用的AWS服务中选择不当和/或如何配置这些选项会导致故障转移规定在实际需要时失败。本文概述了可用于确保AWS云中SQL Server高可用性的各种选项。

选项

对于数据库应用程序，AWS为管理员提供两种基本选 每个都具有不同的高可用性（HA）和灾难恢复（DR）规定：Amazon Relational Database Service（RDS）和Amazon Elastic Compute Cloud（EC2）。

RDS

RDS是一种完全托管的服务，适用于任务关键型应用程序。它提供了六种不同数据库引擎的选择，但它对SQL Server的支持并不像Amazon Aurora，My SQL和MariaDB等其他选择那样强大。以下是管理员关于将RDS用于关键任务SQL Server应用程序的一些常见问题：

• 仅支持单个镜像备用实例，
• 代理作业不是镜像的，因此必须在备用实例中单独创建，
• 未检测到数据库应用程序软件导致的故障，
• 不支持性能优化的内存数据库实例，
• 根据可用区分配（客户无法控制），性能可能会受到不利影响，
• 仅具有Always On Availability Groups的数据镜像功能需要SQL Server更昂贵的Enterprise Edition。

弹性计算云

另一个基本选择是Elastic Compute Cloud，它具有更强大的功能。这使得它在HA和DR至关重要时成为首选。EC2的一个主要优点是它为管理员提供了完整的控制配置，并为管理员提供了一些额外的选择。

选择操作系统

也许最重要的选择是使用哪种操作系统：Windows或Linux。Windows Server故障转移群集是Windows标配的功能强大，经过验证的流行功能。但是WSFC需要共享存储，而这在EC2中是不可用的。由于强大的HA / DR保护需要多可用区，甚至多区域配置，因此需要单独的商业或定制软件来跨服务器实例群集复制数据。Microsoft的Storage Spaces Direct（S2D）不是一个选项，因为它不支持跨可用区的配置。对于缺乏WSFC等基本集群功能的Linux，对Linux的额外HA / DR规定的需求更大。Linux为管理员提供了两个同样糟糕的高可用性选择：为更昂贵的SQL Server企业版支付更多费用以实现Always On Availability Groups;或者努力制作复杂的自助式使用开源软件的HA Linux配置运行良好。

比较

这两种选择都破坏了在公共云服务中使用商用硬件上的开源软件的成本节约理由。SQL Server for Linux仅适用于2017年开始的更新（和更昂贵）版本。对于大多数组织而言，DIY HA替代品可能过于昂贵。实际上，在所有可能的故障情况下，使分布式复制块设备，Corosync，Pacemaker以及可选的其他开源软件在应用程序级别按需工作可能会非常困难。这就是为什么只有非常大的组织才有必要的资金（技能和人员）才能考虑承担这项任务。由于在实施Linux的任务关键型HA / DR规定时遇到困难，AWS建议结合使用Elastic Load Balancing和Auto Scaling来提高可用性。但是这些服务有其自身的局限性，与托管的关系数据库服务中的局限性相似。所有这些都解释了为什么管理员越来越多地选择使用专为确保云环境中的HA和DR保护而设计的故障转移群集解决方案。

故障转移群集专用于云

私有云，公共云和混合云的日益普及导致了针对云环境专门构建的故障转移群集解决方案的出现。这些HA / DR解决方案完全由软件实现，如名称所暗示的那样，创建具有自动故障转移的服务器和存储集群，以确保应用程序级别的高可用性。这些解决方案中的大多数都提供了完整的HA / DR解决方案，其中包括实时块级数据复制，连续应用程序监控和可配置的故障转移/故障恢复恢复策略。一些更复杂的解决方案还提供了高级功能，例如，对于Windows和Linux，在较便宜的SQL Server标准版中支持Always on Failover Cluster Instances。它们还提供WAN优化，以最大化多区域性能。还可以手动切换主服务器和辅助服务器分配，以便于计划维护。包括在不中断应用程序的情况下执行定期备份的功能。大多数故障转移群集软件都与应用程序无关，使组织能够拥有单一，通用的HA / DR解决方案。同样的功能还为整个SQL Server应用程序提供了保护。这包括数据库，登录，代理作业等，所有这些都是以集成的方式进行的。虽然这些解决方案通常也与存储无关，使它们能够与共享存储区域网络一起使用，但通常优先考虑无共享SANless故障转移群集，因为它能够消除潜在的单点故障。在较便宜的SQL Server标准版中支持Always On Failover Cluster Instances（FCI），不会影响可用性或性能，这是一个主要优势。在Windows环境中，大多数故障转移群集软件都通过利用内置的WSFC功能来支持FCI。它使数据库和系统管理员的实现非常简单。Linux在SQL Server和许多其他企业应用程序中越来越受欢迎。现在，一些故障转移群集解决方案通过提供特定于应用程序的集成，可以像实现Windows一样简单地实现HA / DR规定。

典型的三节点SANless故障转移群集

图中的示例EC2配置显示了典型的三节点SANless故障转移群集，该群集配置为虚拟私有云（VPC），其中所有三个SQL Server实例位于不同的可用区中。为了消除影响整个区域的本地灾难中断的可能性，其中一个AZ位于不同的AWS区域。

三节点SANless故障转移群集提供运营商级HA和DR保护。对于Windows或Linux，LAN和/或WAN的基本操作是相同的。服务器＃1最初是主要或活动实例，它将数据连续复制到服务器＃2和＃3。它遇到了问题。然后它会触发到服务器＃2的自动故障转移，服务器＃2现在成为服务器＃3的主要复制数据。

检测到故障

如果故障是由基础架构中断引起的，则AWS工作人员将立即开始诊断并修复导致问题的任何问题。一旦修复，它就可以作为主服务器恢复，或服务器＃2可以继续以该容量将数据复制到服务器＃1和＃3。如果服务器＃2在服务器＃1恢复运行之前失败，如图所示，服务器＃3将在手动故障转移后成为主服务器。当然，如果故障是由应用程序软件或配置的某些其他方面引起的，则由客户来查找并解决问题。当然，SANless故障转移群集只能配置一个备用实例。但是这种最小配置确实需要第三个节点作为证人。需要证人才能达到确定主要任务的法定人数。 此重要任务通常由单独的AZ中的域控制器执行。将所有三个节点（主节点，次节点和见证节点）保存在不同的AZ中可以消除在任何区域脱机时丢失多个投票的可能性。在混合云配置中还可以具有用于HA和/或DR目的的两节点和三节点SANless故障转移群集。一个这样的三节点配置是位于企业数据中心的双节点HA集群，其中异步数据复制到AWS或另一个云服务以进行DR保护 – 反之亦然。在单个区域中的数据复制同步的群集中，故障转移通常配置为自动发生。对于具有跨越多个区域的节点的群集，其中数据复制是异步的，通常手动控制故障转移以避免数据丢失的可能性。无论使用何种区域，三节点集群还可以促进所有三台服务器的计划硬件和软件维护，同时为应用程序及其数据提供连续的DR保护。

最大化SQL Server的高可用性

通过在18个地理区域提供55个可用区域，AWS全球基础架构通过配置具有多个地理位置分散的冗余的SANless故障转移群集，为最大化SQL Server高可用性提供了巨大的机会。这种全球覆盖范围还使所有SQL Server应用程序和数据都能够位于最终用户附近，以提供令人满意的性能。通过专用解决方案，运营商级高可用性并不意味着支付类似运营商的高成本。由于专用的故障转移群集软件能够有效和高效地使用EC2的计算，存储和网络资源，同时易于实施和运行，因此这些解决方案可最大限度地降低任何资本和所有运营支出，从而使高可用性更强大，更经济实惠。以往。转载自TheNewStack