|
|
51CTO旗下网站
|
|
移动端

如何确保SQL Server在云端的高可用性

云计算让那些提供关键性服务的SQL Server部署方案获得了高可用性(HA)和灾难恢复(DR)能力。本文介绍云端文件共享如何确保SQL Server及其云端数据具有高可用性。

作者:陈峻编译来源:51CTO.com|2020-03-18 09:00

【51CTO.com快译】不知您是否意识到,云计算让那些提供关键性服务的SQL Server部署方案获得了高可用性(HA)和灾难恢复(DR)能力。据此,Azure、AWS和Google都在全球范围内部署了最先进的分布式数据中心,并以各种SLA的形式,向用户承诺99.95%或更高的虚拟机(VM)可用水平。当然,针对HA或DR的SQL Server配置,往往涉及到建立Windows服务器故障转移群集(Windows Server Failover Cluster,WSFC)。通过此类群集,SQL Server不仅能够保证其本身在不同主机上的高可用性,更重要的是那些与SQL Server交互的不同存储设备上数据也具有极高的可用性。

在传统的WSFC中,数据通常被存储在存储区域网络(SAN)或SMB3(译者注:Server Message Block是一种能够被用于Web连接,以及客户端与服务器之间进行信息沟通的协议)中,并以共享的方式供WSFC中的所有服务器节点访问。但是,云存储无法以与传统SAN相同的方式实现共享。为了克服这种局限性,人们不得不使用第三方的方法,或Windows原生的方法来克服此类共享存储的限制性。

HA的数字意义

如果我们将HA反映到数字上,其实就是99.99%或更高的在线保证率。在数据中心的构建过程中,我们可以将两个或多个虚拟机(VM)群集配置到Azure数据中心的单独机架中(常被称为“可用性集合”),以保证在99.95%的时间里至少有一个VM可用。同时,Azure和AWS也能够让您在多个数据中心间(常被称为“可用区间”)实现VM的群集。通过此类SLA,您会在99.99%的时间内拥有至少一个可用的VM。

不过,这些SLA保障的是VM本身的可用性,而不是SQL Server及其数据的可用性。也就是说,当主VM出现故障,业务转移到群集中的备用VM上时,为了让服务能够以最小的中断状态继续进行,备用VM必须能够继续运行SQL Server,并能够访问到各种基础数据库的文件。可见,我们需要通过进一步的配置,才能确保SQL Server及其基础数据的可用性。

在云端配置可用性

那么,我们该如何确保SQL Server和云端数据的高可用性呢?如果您主要使用的是Windows Server的原生服务(而不是第三方提供的产品),那么您有两种选择:您既可以在Windows Server 2016或更高的企业版上使用直接存储空间(Storage Spaces Direct),也可以在SQL Server 2012或更高的企业版上创建AlwaysOn可用性组。

上述两种方法各有优缺点。Storage Spaces Direct(S2D)主要是在软件中创建虚拟的存储区域网络(SAN),以方便Windows Server故障转移群集(Windows Server Failover Clustering,WSFC)中的任意VM进行访问。这种方式貌似针对传统故障转移群集的云端升级版本,但是由于我们必须将该群集配置为可用性集合,因此其中的所有VM都需要位于同一数据中心。

在极端情况下,整个数据中心可能会由于破坏性事件而关闭,那么所有的VM及其存储数据将随之掉线。这就是为什么使用S2D的配置方式,是永远不会获得超过99.95%可用性的原因。

此外,S2D对于单个数据中心的要求,还消减了那些横跨多个数据中心,并且部署在Azure、AWS、甚至是Google云平台区域内的SQL Server故障转移群集实例(FCI)的高可用性。

表1:Windows Server选项的优缺点

与直接存储空间相反,AlwaysOn可用性组(AG)能够支持地理位置不同的数据中心之间的AG拷贝。在位于不同数据中心的副本完成了适当配置之后,与AG关联的SLA会上升到99.99%。毕竟,AG的配置并不像SQL Server FCI那样重度依赖共享式的存储。

AG提供的服务可以自动在各个副本之间同步SQL Server数据。也就是说,如果当前active的SQL Server实例失败了,那么被指定的副本服务器将接管,并开始主导已复制到该实例中的数据库。当然,这种方法也有着一定的缺点:AG虽然会复制用户定义的数据库,但是它不会复制关键的系统数据库,例如:Master和MSDB。这些关键系统数据库包含了各种agent jobs、登录名和密码等。可见,如果由于故障导致SQL Server的主实例掉线,那么这些数据库均无法受到保护。另外,值得一提的是:Microsoft尚未测试超过100个SQL Server数据库或10个AG的AlwaysOn可用性组。也就是说,如果需要同时保护大量的数据库,那么AG可能会面临着某种限制。

新一代共享云存储

在上述各种原因的基础上,基于云端的文件共享应运而生。您一定迫不及待地想知道:它是否可以超越Windows Server固有的限制,带来高性能的基于云端的HA和DR解决方案呢?

我个人认为:从长远来看,答案是肯定的。AWS最近表示,用户企业可以使用Amazon FSx(译者注:Amazon基于Windows Server的文件系统)来配置某个WSFC。由于WSFC中的所有节点都可以访问文件共享,因此主节点一旦掉线,那么即便它在另一个数据中心,群集也会自动转移到备用节点上,以继续使用在Amazon FSx文件共享中存储着的SQL Server数据。Azure同时也表示:用户企业可以使用Azure的高级文件共享在FCI中配置SQL Server。据此,我认为:一直以来故障转移群集的本地数据中心模式会逐渐切换到云端模式。

不过在短期看来,答案也可能是否定的。其原因在于:当今基于云端的共享文件产品主要存在着一个显著的缺陷,即:现有云端文件共享服务的基本SLA只能保证99.9%的读、写操作可用性,而且远低于我们在谈论高可用性时所要求的99.99%的SLA基准线。至于其他方面的问题,我们客观性地总结在了下表之中。

表2:基于云的共享文件产品中的问题和潜在结果

我们可以预测:基于云端的文件共享方式将成为S2D和AG有效的替代方案。在不久的将来,所有云服务提供商都能够通过此类方案,针对SQL Server及其基础数据可用性,提供99.99%或更高的SLA。让我们拭目以待吧!

原文标题:Ensuring SQL Server High Availability in the Cloud,作者:David Bermingham

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

【编辑推荐】

  1. SQL Server 2014使用资源调控器对IOPS控制
  2. SQL Server 2014 三大特性打造高性能平台
  3. 微软智能云Azure SQL Database Managed Instance 开启SQL Server到PaaS服务无缝迁移时代
【责任编辑:未丽燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

 敏捷无敌之 Gitlab CI 持续集成

敏捷无敌之 Gitlab CI 持续集成

打破运维与研发壁垒
共5章 | KaliArch

74人订阅学习

秒杀高并发白话实战

秒杀高并发白话实战

主流高并发架构
共15章 | 51CTO崔皓

59人订阅学习

网络排障一点通

网络排障一点通

网络排障及优化调整案例
共20章 | 捷哥CCIE

465人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微