云中SQL Server高可用性最佳实践

相比于本地部署的数据库，云数据库可以为用户提供更多的灵活性和可扩展性，而且价格也更加的低廉。但是云系统经常会出现问题，所以我们必须要时刻关注高可用性和灾难恢复。 SIOS技术公司的高级技术推广人员David Bermingham在SQL Server集群管理软件公司举办的网络研讨会上，详细介绍了一组针对云用户的SQL Server高可用性最佳实践，同时还对比了Microsoft Azure、AWS和Google云提供的高可用性功能。 Bermingham表示，可靠的高可用性策略可以帮助为基于云的SQL Server系统创建高效的工作流程、正常的运行时间和有效的灾难恢复程序。如果替代方案不是那么理想，那可能就会发生数据库停机，数据丢失和其他令SQL Server数据库管理员(DBA)头痛的问题。 以下是Bermingham对SQL Server高可用性最佳实践的一些建议。 在使用云平台之前阅读细则 Azure的服务级别协议(SLA)承诺每月只有22分钟的数据库停机时间。但是，Bermingham表示，只有当SQL Server的两个或多个实例被分组到一个由多个虚拟机(VMs)组成的可用性集中时，才会出现这种情况。如果你自己只设置了一个实例，你可能最终得到的只是“a dial tone”，它可以ping，可以在线，但并不能保证存储空间可用。” 而在AWS针对SQL Server系统的SLA中，其承诺每月有4.5分钟的停机时间，或者是99.99%的正常运行时间。不过，与Azure的SLA类似，正常运行时间保证仅适用于两个或多个彼此配对的数据库实例。 谷歌云平台同样承诺每月只需4.5分钟的数据库停机时间。但谷歌SLA中停机时间的定义有所不同，指的是“所有运行实例的外部连接或持久磁盘访问的丢失”，部署时将实例放置在同一计算区域的两个或多个区域之间。 为系统中断做好准备 云虽然是一种非常有用的资源，但是更重要的是我们也要认识到云服务并非绝对可靠，其有失败的可能性。也正是因为此，Bermingham才会分享SQL Server高可用性最佳实践，以及在发生中断时，应该做出哪些应急计划。 Bermingham表示，首先你要确保有冗余的互联网接入，以及有应用程序如何连接到SQL Server以及客户端如何连接到应用程序的计划。意外丢失互联网服务是用户需要找到应对或解决方法的单点故障。 除此之外，还需要用户考虑的一件事是在云中部署SQL Server要使用多个可用区。因为可用区域可能会完全不可用，所以Bermingham建议跨区域部署数据库来弥补完全中断。 Bermingham强调了实施灾难恢复计划的重要性，因为云中的数据可能会以各种方式丢失，火灾和洪水等自然灾害可能会破坏持有重要数据的物理服务器，不过，现在我们所看到的大部分中断都是由于某种人为错误造成的。 利用高可用性工具 在基于云系统实施SQL Server高可用性最佳实践时，必须要确保重要数据无论在何种情况下都可以使用。 Bermingham表示，即使你是在云端运行SQL Server，那么你也需要管理它，确保它时刻在线。而SQL Server中的高可用性功能也可以帮助DBA在云中管理数据库，例如Always On Availability Groups和Always On Failover Cluster Instances。 SQL Server 2012中，Always On Availability Groups将一组主数据库绑定到多达八个相应的辅助数据库集，这些辅助数据库配置为在发生中断时一起进行故障转移。Bermingham表示因为SQL Server是在每个实例上运行，因此该技术可以实现非常快速的故障转移。 他补充道，页面修复可以在不使用第三方产品的情况下自动完成，并且DBA能够在辅助系统上进行备份和运行报告。不过，Always On Availability Groups仅保护用户数据库，并不保护用于管理和维护SQL Server的系统数据库。 Always On Failover Cluster Instances使用了微软Windows Server Failover Clustering (WSFC)的功能为整个SQL Server实例提供高可用性保护。故障转移集群实例跨多个WSFC节点部署，以便在出现故障时实现冗余。因此，DBA不需要管理可用性或在多个实例中维护密码和用户名。 每个云平台提供商还提供了管理SQL Server系统中存储可用性的功能。例如，微软提供了Azure Managed Disks，这个软件程序发布于2007年，通过在不同存储单元之间传输数据，减少Azure VMs的潜在存储中断。