SQL Server AlwaysON从入门到进阶(1)——何为AlwaysON?

186 篇文章 6 订阅
130 篇文章 241 订阅
本文属于SQL Server AlwaysON从入门到进阶系列文章


本文原文出自 Stairway to AlwaysOn系列文章。根据工作需要在学习过程中顺带翻译以供参考。系列文章包含:
本文为第一节。即SQL Server AlwaysON从入门到进阶(1)——何为AlwaysON?

前言:


AlwaysOn是经常被误解的一系列复杂技术的集合。本系列将介绍关于AlwaysOn的技术,并且如何把它用在高可用策略中,及如何用好AlwaysOn。在本节中,会先介绍一下几个概念:AlwaysOn、Failover Cluster Instance(FCI)和Windows Server Failover Cluster(WSFC)。理解这些基础概念能够在日常运维过程中起到很大的作用。


Windows Server Failover Cluster(WSFC):


WSFC(windows 故障转移群集)是微软高可用技术(HA)的核心组成部分。WSFC跟FCI、AlwaysOn相比,它更多的是Windows Server的一个功能,而后面两个则是SQL Server的功能,同时,WSFC更加底层,在创建SQL Server Failover Cluster Instance(FCI,SQL Server故障转移群集实例)、SQL Server AlwaysOn 高可用组、其他如Exchange等高可用技术之前,都需要部署和配置WSFC。
WSFC可以把多台计算机节点(纯物理机、纯虚拟机、物理机混合虚拟机)组合在一起并对外部应用程序提供高可用服务。服务器上的一个应用如SQL Server,可以运行在cluster的任何一个节点上,这种运行方式是通过cluster提供一个虚拟访问点(由一个唯一IP地址和一个唯一机器名组成,或者“虚拟网络名”)给客户端程序作为链接方式。地址和虚拟名作为一个应用程序的“资源组”,在多个参与节点之间像令牌形式地被传输。当活动节点出现严重故障时,会使得活动节点停止对外服务。这时候集群服务会自动尝试重启当前节点或伙伴节点的资源组。
从高层次的角度来说,客户端的访问点是沿着故障转移伙伴节点中的所有硬盘和服务起源传输的。一个已集群的实例在发生故障转移时,会引发客户端连接的断开,然后在其他节点可用之后马上重连。常见的引发故障转移的故障有以下几个:
  • 公用网卡或网络故障
  • 电源故障
  • 主板故障
  • CPU故障
在WSFC中,已集群的应用程序被安装在独立的组或者“应用程序”中,这些组包含了一系列如硬盘、服务、IP地址等的资源。组及其资源在某个时刻只能属于一个节点,除非发生计划或突发故障转移,否则其他伙伴节点不能访问这些资源。
典型的WSFC如下图所示,通过网络把所有节点互连,然后Domain Controller(域控)和DNS服务器用于实现客户端通过虚拟IP或者虚拟网络名去访问节点,而不需要知道当前哪个节点是活动的。


对于FCI部署,计算机节点“ 必须”使用共享存储,而对于常规的AlwaysOn可用组的部署,节点可以使用本地存储,而不是必须使用共享存储。虽然集群节点允许使用完全不同的硬件,但是最好还是统一配置,避免在故障转移过程中发生负载不均衡从而无法承受故障节点的压力使得转移失败。
但是,各节点必须使用相同的OS及补丁版本、网络配置。另外对于集群最大节点数,根据不同的Windows Server版本不同而不同(2003 为8节点,2008为16节点,2012为64节点)。
稳定、健壮的Windows Server Failover Cluster需要严谨的设计、足够的硬件支持和合适的操作系统版本。如果使用跨公网的集群也会增加集群设计、计划和资源方面的开销。
需要 重点提醒的是,WSFC仅提供故障转移功能,没有提供负载均衡和横向扩展功能,每个服务只能运行在一个节点上。
通常情况下,在大型多节点集群中,应用可能是跨子网的部署。在后续会看到,如果忽略了一些设置,会引起非必要的故障转移,同时不要违反AlwaysOn可用组的限制策略。
WSFC需要某些形式的中介来控制集群资源所属方。这个中介就是集群的仲裁。从Windows 2003 SP1开始,这个仲裁以节点投票并按多数服从少数的原则来维护。也可以使用如集群本地盘或多站点集群共享的远程文件形式来添加额外的仲裁资源。从Windows Server 2012 开始,仲裁开始使用一个成为动态节点权重配置的功能来平衡集群在计划内停机中避免不必要的故障切换过程,这部分在后续会继续深入介绍。



Failover Cluster Instances(故障转移群集实例):

Failover Cluster Instance of SQL Server(FCI)在过去很长时间都是SQL Server的常用高可用技术。SQL Server FCI可以在集群的任何可用节点之间进行故障转移。其唯一缺点就是存储。由于需要使用共享存储,所以存储子系统就成了单点故障的风险点。
FCI是一个安装在WSFC上的SQL Server 实例,不管是默认实例还是命名实例。这个实例最少需要下面的资源:
  • IP地址
  • 网络名
  • 共享硬盘(N个)
  • SQL Server 服务
  • SQL Server 代理服务
上面的资源对于单独的实例而言也一样,只是IP地址和网络名是来自于本机,硬盘也属于本机,而FCI则不同。


上图所示,一个两节点的FCI中,SQL Server实例会使用WSFC节点都能可用的共享存储作为SQL Server的存储。通常这次存储是在SAN中划出来的LUNs,FCI的部署粗略分为两步,后续将会深入介绍,这里只做简介:
  1. 在FCI的第一个节点上运行SQL Server安装向导,并选择“新的SQL Server 故障转移群集安装”。完成第一步之后,就可以开始第二步。
  2. 在WSFC的其他参与节点上运行SQL Server安装向导并选择“向SQL Server故障转移群集添加节点”并完成安装。
注意:虽然标准版限制了2节点的FCI,但是它不影响WSFC,仅在SQL Server层面限制。FCI有点像团队接力过程。一个计算机节点运行这已群集的SQL Server应用程序及其配套资源,并向客户端提供服务(持有接力棒)。一旦活动节点发生故障(接力棒掉了),伙伴节点会启动并承接任务继续(捡起接力棒)。




AlwaysOn Availability Groups(AlwaysOn可用组):


多年以来,故障转移群集是SQL Server高可用的主要技术。当一个节点发生故障,其他节点会承接对客户端的服务。AlwaysOn 继承了WSFC技术,并提供更加弹性的高可用平台。但是群集是在实例层面运作,而AlwaysOn是在库层面运作。从SQL 2012开始引入的AlwaysOn可用组技术,通过预定义一组数据库集合(可用组)并复制到只读伙伴实例或副本中。每个节点都有AlwaysOn数据库的同步副本,并且通过侦听器进行访问。
AlwaysOn可用组(下称AG)需要1到多个次要副本来存放高可用数据库的副本。这些次要数据库要么是可读的,要么是不可读的。也可以同步或异步形式更新。异步副本仅支持手动强制故障转移,而同步副本支持自动或手动故障转移。
次要只读副本可以配置成只支持只读查询,也可以使得次要副本成为成备份、维护操作的地方,从而减少主副本的压力。
AlwaysOn依赖WSFC的核心功能来完成AO(AlwaysOn)的高可用功能,但是相对于FCI,它又在下面部分有所区别:
  • 共享硬盘
  • 共享IP地址
  • 共享网络名
  • 共享的SQL Server和SQL Server代理资源
但是当使用了AlwaysOn侦听器之后,会创建一个共享给AO组各个副本的IP地址和网络名资源。正如上面提到的,FCI的缺点是共享存储,虽然有很多方式可以缓解这种单点故障的风险,但是通常都带有明显的开销(不管是配置还是费用),并且通常很难配置和管理。另外前面也说了,FCI是迁移服务器硬件,不提供单个或多个数据库的迁移。需要搭配数据库镜像,但是镜像是“单库”、不可读,AlwaysOn可用组是可以以多个库为一个单位迁移,备库可读。
AlwaysOn也使用SQL Server端点来进行实例之间的通讯。端点会在使用可用组部署向导过程中自动配置。也可以创建高可用侦听器服务,用于接收入站连接,侦听器包含唯一IP地址和唯一虚拟网络名。这是目前为止其中一个关于使得在组内数据库高可用方面最大的改变之一。
在创建AlwaysOn可用组过程中,会在WSFC中创建一个群集角色,并且包含独立资源。这个资源会在故障转移过程中同步转移,并且标识主副本的位置。


AlwaysOn Listener(AlwaysOn侦听器):


当配置了侦听器之后,会在故障转移群集中的应用程序\角色看到创建了一些资源:
  • 虚拟IP地址
  • 虚拟网络名
侦听器使用TCP端口接收入站连接,默认连到主副本(Primary replica)。如果配置了只读路由(read only routing),那么指定使用“仅意向读”的连接会被路由到次要副本而不是主副本。从很大程度上分流了对主副本的压力。
在AlwaysOn组发生故障转移时,已群集的应用程序及其资源会被转移到群集的其他节点上。群集应用会跟踪主副本的节点位置然后按需把群集服务在底层节点中移动。在这个过程中,侦听器由FCI\AlwaysOn的活动节点持有。

结论:


本节介绍了三种SQL Server相关的核心高可用技术。我们使用WSFC作为基础,并在此之上部署FCI或者AlwaysOn可用组。接下来会介绍使用FCI作为SQL Server的高可用技术演示,然后就是AlwaysOn可用组搭建。
下一节会介绍关于SQL Server高可用中存储方面的内容。


术语表:


AO(AlwaysOn availability group)

AlwaysOn 高可用组

FCI(Failover cluster instance of SQL Server)

SQL Server故障转移集群实例

TCP/IP

传输控制协议/因特网互联协议。

OS/NOS

网络操作系统

WSFC(Windows Server failover cluster)

Windows故障转移群集

LAN(Local area network)

局域网

WAN(Wide area network)

广域网

DNS(Domain name system)

域名系统

DHCP

动态主机设定协定

IP Address

IP地址

AD(Active Directory)

Windows活动目录

DR(Disaster recovery)

灾难恢复

SPF(Single point of failure)

单点故障

SCSI(Small computer systems interface)

小型计算机系统接口

iSCSI(Internet Small computer systems interface)

互联网小型计算机系统接口

FC(Fibre channel)

光纤

Replica

副本,SQL Server AlwaysOn可用组中,参与到AlwaysOn的SQL Server实例



SQL Server AlwaysOn是一种高可用性和灾难恢复解决方案,它基于SQL Server数据库引擎的一组功能和技术。 要简单搭建SQL Server AlwaysOn,需按以下步骤进行操作: 1. 确保已安装SQL Server数据库引擎,并且在所有参与AlwaysOn的服务器上安装了相同的版本和服务包。 2. 创建一个Windows Server故障转移集群,该集群将作为AlwaysOn配置的基础。确保集群中的每台服务器都满足Windows Server故障转移集群的最低要求。 3. 在每台服务器上打开SQL Server配置管理器,启动SQL Server对应的服务。 4. 在主服务器上创建一个数据库并设置为全同步恢复模式。将该数据库设置为复制到其他参与AlwaysOn的服务器。 5. 在主服务器上进行AlwaysOn的配置,右键点击数据库,选择"属性",然后选择"AlwaysOn高可用性"选项卡。勾选"启用AlwaysOn可用性组"和"自动故障转移"选项。 6. 单击"向导"按钮,按照提示创建可用性组。设置虚拟名称和监听器,选择其中一个服务器作为主服务器,配置备机的读取访问。 7. 在从属服务器上重复步骤6,将其添加到可用性组中。 8. 在主服务器上启动可用性组。 9. 在从属服务器上验证可用性组的配置。确保数据库在主服务器上运行,并且从属服务器显示为已同步。 10. 测试故障转移功能。分别关闭主服务器和从属服务器,观察数据库是否能够自动切换到其他服务器上,并保持数据的一致性。 以上简单搭建SQL Server AlwaysOn的步骤仅是基本流程,具体配置和设置可能因环境和需求的不同而有所差异。建议参考官方文档或咨询专业人员以获取更加详细的指导。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值