Date: 2月 14, 2021
使用Amazon FSX进行SQL Server故障转移群集实例-您需要了解的知识！
如果您正在考虑在AWS EC2中部署自己的Microsoft SQL Server实例，则需要就解决方案的弹性做出一些决策。 当然，如果您在不同的可用区域中部署两个或更多实例，AWS将为您的Compute资源提供99.99％的SLA。 但不要上当，在计算真正的应用程序可用性时，还需要考虑许多其他因素。 我最近在博客上发表了有关如何在云中计算应用程序可用性的博客。 在继续之前，您可能应该快速阅读该文章。
在确保Microsoft SQL Server实例高度可用时，实际上可以归结为两个基本选择：始终可用性组（AG）或SQL Server故障转移群集实例（FCI）。 如果您正在阅读本文，则假定您对这两个选项都非常了解，并正在认真考虑使用SQL Server故障转移群集实例而不是SQL Server Always On AG。
Microsoft SQL Server故障转移群集实例的好处
以下列表总结了AWS所说的是SQL Server FCI的优点：
当以下是您使用案例的优先考虑因素时，对于SQL Server高可用性部署，FCI通常比AG更可取：
许可证成本效率：运行AG所需的是SQL Server的企业版许可证，而运行FCI的仅需Standard Edition许可证。 它通常比企业版便宜50–60％。 尽管您可以从SQL Server 2016开始在Standard Edition上运行AG的基本版本，但它的局限性在于每个AG仅支持一个数据库。 在处理需要多个数据库（例如SharePoint）的应用程序时，这可能成为一个挑战。
实例级保护与数据库级保护：使用FCI，可以保护整个实例-如果主节点不可用，则将整个实例移到备用节点。 这将照顾存储在系统数据库中的SQL Server登录名，SQL Server代理作业，证书等，这些数据库实际上存储在共享存储中。 另一方面，使用AG，只能保护组中的数据库，并且不能将系统数据库添加到AG中-仅允许用户数据库。 数据库管理员负责将更改复制到所有AG副本上的系统对象。 这留下了人为错误的可能性，导致数据库无法被应用程序访问。
DTC功能支持：如果您使用的是SQL Server 2012或2014，并且您的应用程序使用分布式事务处理协调器（DTC），则您将无法使用AG，因为它不受支持。 在这种情况下，请使用FCI。
云中FCI面临的挑战
当然。 建立跨越可用性区域的FCI的挑战是缺少通常需要的共享存储设备。 因为群集的节点分布在多个数据中心，所以传统的SAN对于共享存储来说不是可行的选择。 这为集群存储留出了两个选择：第三方存储类资源，例如SIOS DataKeeper或新的Amazon FSx。
让我们来看看您做出选择之前需要了解的内容。
服务水平协议
正如我在如何计算应用程序可用性中所写的那样，您的整体应用程序SLA仅与最弱的链接一样好。 在这种情况下，FSx SLA为99.9％。
通常99.99％的可用性代表着“高可用性”的起点。 这是当两个或多个部署在不同的可用区域中时，AWS向您承诺的计算资源。
万一您不知道三个九与四个九之间的区别…
- 99.9％的可用性每月允许停机43.83分钟
- 99.99％的可用性每月仅允许停机4.38分钟
尽管您具有99.99％的计算可用性，但是通过将群集存储托管在FSx上，您的整体应用程序可用性将达到99.9％。 相比之下，跨越可用性区域的EBS卷（例如在DataKeeper部署中）在存储和计算层均符合99.99％的SLA。 这意味着您的整体应用程序可用性为99.99％。
存储位置
为高可用性配置FSx时，您将需要启用多可用区支持。 通过启用多可用区，您可以有效地拥有“首选”可用区和“备用”可用区。 部署SQL Server FCI节点时，您将希望将这些节点分布在相同的可用区中。
现在，在正常情况下，您将需要确保活动群集节点与首选FSx存储节点位于相同的可用区中。 这是为了最大程度地减少存储距离和延迟。 而且还可以最大程度地减少与跨可用区进行数据传输相关的成本。 根据FSx价格指南中的规定，“标准数据传输费适用于AZ之间或区域间对文件系统的访问。”
在不幸的情况下，如果您遇到SQL Server FCI故障，但没有FSx故障，则没有将存储和计算结合在一起的机制。 如果FSx进行故障转移，它将自动故障恢复到主要可用性区域。 但是，最佳实践指示SQL FCI仍在辅助节点上运行，直到执行根本原因分析并且通常计划在维护期间进行故障回复。 这使您处于存储位于其他可用区的情况，这将产生额外的费用。 当前，跨可用区和入口的数据传输成本为$ 0.01 / GB。
如果不密切关注FSx和SQL Server FCI的状态，您甚至可能都不知道它们在不同的区域中运行，直到您在月底看到数据传输费用为止。
相反，在使用SIOS DataKeeper的配置中，存储故障转移是SQL Server FCI恢复的一部分，从而确保存储始终通过SQL Server实例进行故障转移。 这样可以确保SQL Server始终在读写直接连接到活动节点的EBS卷。 请记住，DataKeeper将产生与在AZ或区域之间复制的写操作相关的数据传输成本。 通过使用DataKeeper中可用的压缩，可以将这种数据传输成本降到最低。
控制故障转移
在FSx多子网配置中，存在首选的可用性区域和备用可用性。 如果首选可用性区域中的FSx文件服务器出现故障，备用AZ中的文件服务器将恢复。 AWS报告说，使用标准共享时，此恢复时间大约需要30秒。 通过使用连续可用的文件共享，Microsoft报告此故障转移时间可以接近15秒。 在此故障转移时间内，将在读取和写入暂停的情况下发生电源不足，但是一旦恢复完成，该电源将继续。
FSx多站点已启用自动故障回复。 这意味着，对于FSx的每个计划外故障转移，您还将具有计划外的故障回复。 相反，通常，当SQL Server FCI经历计划外的故障转移时，您要么只是使其在辅助服务器上运行，要么计划在几个小时后或下一个维护期间进行故障回复。
FSX不支持SQL Server Analysis Services群集
如果要群集SSAS，则需要群集磁盘资源，例如SIOS DataKeeper。 如何群集SQL Server Analysis Server白皮书明确指出无法使用SMB，并且必须使用带驱动器号的群集驱动器。 相反，DataKeeper卷资源将其自身显示为群集磁盘，并且可以与SSAS一起使用。
概括
虽然FSx对于Windows用户文件和其他非关键服务等典型的SMB使用肯定是有意义的，其中SLA满足99.9％的可用性，但如果您的应用程序要求高可用性（99.99％）或还具有高可用性的HA / DR解决方案，则FSx是一个不错的选择区域，SIOS DataKeeper是正确的选择。