最新SQLServerAlwaysOn高可用性解决方案.docx

最新SQLServerAlwaysOn高可用性解决方案.docx

《最新SQLServerAlwaysOn高可用性解决方案.docx》由会员分享，可在线阅读，更多相关《最新SQLServerAlwaysOn高可用性解决方案.docx（13页珍藏版）》请在冰点文库上搜索。

最新SQLServerAlwaysOn高可用性解决方案

SQL-Server-2022-AlwaysOn高可用性解决方案

MicrosoftSQLServer2022AlwaysOn

高可用性解决方案

编制人：

***

审批：

****

编号：

Q/DF-XX.2.01-2022

当前版本：

V1.0

发布日期：

2022年7月8日

反响对象：

市场中心销售中心融资中心人资中心财务中心研发中心

1.术语定义

1）高可用性：

HA〔HighAvailability〕

通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其效劳的高度可用性

2）灾难恢复：

DR〔DisasterRecovery〕

指自然或人为灾害后，重新启用信息系统的数据、硬件及软件设备，恢复正常商业运作的过程

3）故障转移群集：

WSFC〔WindowsServerFailoverCluster〕

微软操作系统针对效劳器提供的一种效劳，该效劳用于防止单台效劳器故障导致效劳失效。

2.公司数据库使用现状及问题瓶颈

其他部门对应用开发部负责的融资管理系统性能提出以下问题：

1）数据部：

a）效劳器不稳定

b）数据库性能配置低

2）市场部：

a）查询效率太低

3.

4.SQLServer高可用技术简介

1）故障转移群集（FailoverCluster）

共享存储，效率高，但某一个时间点只有一个节点处于活动状态，造成硬件资源浪费。

2）数据库镜像（DatabaseMirror）

提供几乎是瞬时的故障转移，以提高数据库的可用性。

但其最大弊端在于镜像数据库处于不可读状态，同样造成硬件资源浪费。

3）日志传送（LogShipping）

复原作业之间的间隔时间内的只读访问权限，可用做报表查询。

一般用于远程的异步容灾，存在局部数据丧失的可能性。

4）复制（Replication）

基于数据库对象级别，灵活性较高，但弊端在于，它不支持DDL命令，不便维护。

5）AlwaysOn

AlwaysOn是SQLServer2022中提供的一种全新的高可用性技术，其集中了上述4种高可用性技术的优点，以确保企业无需增加本钱和提高复杂度，即可实现最高级别的可用性和数据保护。

可在数据中心内部以及跨数据中心实现数据冗余，快速地实现应用程序故障转移，保护现有硬件资源，同时简化了其配置过程。

AlwaysOn可以实现效劳器实例级和数据库级配置高可用性，所对应的技术就是AlwaysOn故障转移群集实例和AlwaysOn可用性组。

以下列图1展示了使用Alwayson可用性组的HA和DR解决方案

图1

5.AlwaysOn高可用性技术介绍

1）AlwaysOn故障转移群集实例

一般来说，在单效劳器情况下，当效劳器上出现硬件或软件故障时，连接到该效劳器的应用程序或客户端将会停机。

在AlwaysOn故障转移群集实例环境中，SQLServer实例的高可用性受到冗余节点的保护。

在群集环境中，一次只能有一个节点拥有群集的资源组。

在出现故障（硬件故障、操作系统故障、应用程序或效劳故障）或进行方案的升级时，该资源组的所有权就会转移至另一个群集节点。

此过程对于连接到SQLServer的客户端或应用程序是透明的，可以最大限度地缩短出现故障时应用程序或客户端的停机时间。

因此AlwaysOn故障转移群集实例必须由一组物理效劳器节点构成，这些效劳器节点推荐使用类似的硬件配置以及相同的软件配置，如操作系统的版本、SQLServer版本、修补程序级别、组件以及实例名称。

相同的配置是确保群集在节点间进行故障转移时能够正常运行的前提条件。

　　SQLServer2022在原有SQLServer故障转移群集的根底上功能得到了进一步的增强，支持跨越子网实现多站点群集，此技术一般用于两个或两个以上的数据中心，以同时提供本地高可用性和远程的灾难恢复。

其中，每个故障转移群集节点都连接到其他子网或其他子网组。

这些子网可以处于同一位置中，也可以位于地理上分散的站点。

跨地理上分散的站点进行群集有时又被称为扩展群集。

因为没有供所有节点都可以访问的共享存储，所以在多个子网上的数据存储之间应该复制数据。

因此，多子网故障转移群集除了具备高可用性之外，还提供了灾难恢复解决方案。

下面以图例说明：

图2

在上图中共有两个数据中心并且处于不同子网，本地数据中心subnet1使用的IP地址是10.168.0.10，当本地数据中心发生故障时，SQLServer效劳会转移到远程数据中心，远程数据中心subnet2所使用的是不同IP地址，为192.168.0.10来继续提供数据库效劳，这两个IP地址之间是OR的关系，也就是说这两个IP地址任意一个在线的话，虚拟网络名称SQLClus都可以正常的向客户端提供效劳。

在此需要使用到存储级别的复制技术，将本地数据中心数据库中的数据文件及日志文件复制到远程数据中心，当本地数据中心发生故障时，Windows群集检测到故障，远程数据中心存储软件可以检测到复制失效，会将存储转换为读写状态，接下来Windows群集会将远程站点可读写的存储设备挂接到远程的Cluster节点上，此时存储复制的方向就从远程数据中心向本地数据中心复制。

也就是说，故障转移群集实例成功启动后，Windows群集效劳将监视根底群集的运行状况和SQLServer实例的运行状况。

SQLServer2022中允许群集效劳使用专用连接来轮询活动SQLServer实例，以便通过系统存储过程获取详细的组件诊断信息。

好处是，利用与SQLServer实例的专用连接，能够对组件诊断信息进行可靠轮询，即使在故障转移群集实例负荷较重时也是如此。

利用详细的组件诊断信息，可以配置更灵活的故障转移策略，由此用户能选择哪些故障条件将触发故障转移以及哪些故障条件将不触发故障转移。

用户利用产生的诊断信息，还可以通过追溯方式更好地对自动故障转移进行故障排除。

此诊断信息将存储到与SQLServer错误日志并置的日志文件中。

可以将这些日志文件加载到日志文件查看器中以检查导致出现故障转移的组件状态，从而确定导致该故障转移的原因。

2）AlwaysOn可用性组

AlwaysOn可用性组是SQLServer2022中提供的全新功能，确保了应用程序数据的可用性，实现零数据丧失。

AlwaysOn可用性组技术融合了数据库群集和数据库镜像的优点，此技术的一大好处是提供非共享存储，可以防止因为存储的单点故障而造成的整个可用性方案失效。

　　AlwaysOn可用性组基于数据库（组）级别，是将一组用户数据库（可以是一个或多个）划到一个组中。

每组可用性数据库都由一个可用性副本承载。

可用性副本包括一个主副本和一到四个辅助副本〔2022最多支持8个〕。

主副本用于承载主数据库，辅助副本那么承载一组辅助数据库并作为可用性组的潜在故障转移目标。

主副本使主数据库可用于客户端的读写连接，实现对数据库的更改操作。

同时在数据库级别进行同步。

主副本将每个主数据库的事务日志记录发送到每个辅助数据库。

每个辅助副本缓存事务日志记录，然后将它们复原到相应的辅助数据库。

主数据库与每个连接的辅助数据库独立进行数据同步。

因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。

　　此外，用户可以借助辅助数据库来实现近实时的报表查询，将查询的负载分担到只读副本。

相对于数据库群集及镜像来说，可以更好的利用硬件资源，从而提高IT效率并降低本钱。

下面看一下AlwaysOn可用性组架构，如以下列图3所示：

图3

　　部署AlwaysOn可用性组需要一个WindowsServer故障转移群集（WSFC）群集。

给定可用性组的每个可用性副本必须位于相同WSFC群集的不同节点上。

部署AlwaysOn可用性组时，系统会为每个可用性组创立一个WSFC资源组。

WSFC群集将监视此资源组，判断节点间的状态，以便评估主副本的运行状况。

当发生失败时实现故障的转移，针对AlwaysOn可用性组的仲裁基于WSFC群集中的所有节点，而与某一给定群集节点是否承载任何可用性副本无关。

　　用户可以通过创立一个可用性组侦听器来提供到给定可用性组的主副本的客户端连接。

“可用性组侦听器〞采用DNS名称的方式连接给定可用性组的资源，以便将客户端连接定向到相应的可用性副本。

　　对于每个可用性副本，AlwaysOn所支持的事务提交模式分为同步提交模式或异步提交模式。

在异步提交模式下，主副本无需等待确认异步提交辅助副本已强制写入日志，便可提交事务。

异步提交模式可最大限度地减少辅助数据库上的事务滞后时间，但允许它们滞后于主数据库，因此可能会导致某些数据丧失。

此可用性模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况。

所谓同步提交模式是指在提交事务之前，同步提交主副本要等待同步提交辅助副本确认它已完成强制写入日志。

同步提交模式可确保在给定的辅助数据库与主数据库同步时，充分保护已提交的事务。

这种保护的代价是延长事务滞后时间。

此可用性模式相对于性能而言更强调高可用性和数据保护，当主副本和辅助副本距离较近时可以使用此方法，解决时时同步的问题。

　　正因为AlwaysOn可用性组集现有高可用性技术的优点于一身，不得不说，它是SQLServer2022新特性中最为璀璨的一个。

6.东方融资网可实施的AlwaysOn测试部署方案

1）宿主机

宿主使用工作站〔HYPR-V〕，其根本配置如下：

a）处理器：

Intel（R）Core（TM）i5-4470CPU@3.20GHz3.20GHz

b）内存（RAM）：

8.00GB

c）Windows版本：

WindowsServer2022R2Standard

2）虚拟机配置

数据库效劳器根本配置：

4个逻辑cpu，1G内存，100G硬盘（C:

70G;D:

30G）

HostName

IP配置

OS版本

SQL版本

功能介绍

ADServer

IP：

192.168.1.110

WindowsServer2022R2Standard

NULL

域控制器

Server01

IP：

192.168.1.111

WindowsServer2022R2Standard

SQLServer2022R2企业版

群集节点01

Server02

IP：

192.168.1.112

WindowsServer2022R2Standard

SQLServer2022R2企业版

群集节点02

3）AlwaysOn可用性组安装配置架构图

如以下列图所示，一个windows群集clustest01中包含三个节点〔server01，server02〕节点01和节点02组成SQLServer群集，实现实例级别的自动故障转移和AlwaysOn可用性组，可用性组添加侦听IP[192.168.1.130]，用于客户端的连接，以实现可用组切换而不用修改客户端连接配置。

图4

4）Windows群集安装

将三个效劳器都参加域环境中；并安装.Net3.5和故障转移群集功能后，开始创立新群集。

第一步：

配置主域控效劳器ADServer

a）在仪表板效劳器角色中添加ActiveDirectory效劳器及DNS效劳，并配置域名为。

b）配置本机IP为192.168.1.110。

c）建立域账户sql@，账户属性设置为密码永不过期

第二步：

配置三个数据库效劳器Server01，Server02

a）设置IPServer01〔192.168.1.111〕，Server02〔192.168.1.112〕

b）关闭防火墙

c）参加域

d）在仪表板功能中添加.Net3.5和故障转移群集

第三步：

创立新群集Cluster01

a）在数据库效劳器Server01上创立新群集Cluster01。

b）将server01、server02添加到该群集中。

c）Cluster01群集IP配置为192.168.1.120。

d）测试验证通过后，域中自动生成Cluster01$域账户。

e）在ADServer上创立仲裁共享文件夹ClusterShare，并共享给Cluster01$域账户，设定其读写权限。

第四步：

Server01，Server02安装SQLserver2022R2

a）分别安装SQLserver2022R2

b）网络配置效劳中SQLServer数据库效劳启用AlwaysOn高可用性组。

c）SQLServer数据库效劳及SQLServer代理登录设置为域账户sql@

第五步：

仲裁配置

为配置简单且在资源有限的情况下，该测试环境中AlwaysOn群集仲裁配置为多数节点和文件共享的模式。

配置过程见以下截图：

a）更多操作配置群集仲裁

图5

b）进入配置群集仲裁向导界面

图6

c）选择多数节点和文件夹共享仲裁模式

图7

第六步：

创立测试数据库

a）在Server01数据库实例上创立测试数据库testDB1和testDB2

b）testDB1和testDB2做好完整备份

c）在Server01D盘创立共享文件夹AlwaysOnShare〔Alwayson添加可用性数据库时用到该共享目录〕，并设置域账户sql@对该共享目录可读写权限。

第七步：

创立测试可用性组

a）在Server1上创立可用性组AlwaysOn01

b）AlwaysOn01选择可用性组数据库testDB1和testDB2

c）选择可用性副本Sever02，并设置Sever02为同步提交模式副本〔实现故障自动转移〕。

d）AlwaysOn1可用性组添加监听Listener01,并设置为静态IP〔192.168.1.130〕

e）可查看到Server1上testDB1和testDB2标识为已同步。

第八步：

验证

a）验证故障自动转移功能

●关闭Server01效劳器。

数据库客户端连接Server02，可查看到Server02此时已切换为主副本，Server02上的testDB1和testDB2也已切换为主数据库。

●再启动Server01，并在Server02的可用性组中参加Server01后，可查看到Server01此时又作为辅助副本。

●关闭Server02，此时又查看到Server01变为主副本。

b）验证监听Listen01的实时监听及AlwaysOn01可用性组同步功能

●Server01客户端连接Liseten01效劳，可访问到数据库testDB1和testDB2。

●在TestDB1数据库中Create新表testTabel1，在testDB2Create新表testTabel2。

●连接Server02数据库实例，发现Server02的TestDB1上可查看到testTabel1，testDB2可查看到testTabel2。

c）验证辅助副本的只读访问。

●查看AlwaysOn01属性，此时Server01为主副本，Server02为辅助副本。

●数据库管理工具连接Server02。

●在Server02上执行写操作将失败，执行查询操作成功。

7.Alwayson问题总结

1）Alwayson是否依赖于域环境?

答:

是,alwayson依赖于故障转移群集（只有在故障转移群集中的SQLServer才能启动高可行性组功能）,而故障转移群集依赖于域环境.

2）为了启用高可用性组功能,SQLServer效劳是否必须使用域账户运行?

答:

否,在使用非域账户运行的SQLServer效劳上仍然可构建高可用性组,效劳运行账户决定SQLServer中管理员的操作权限,如果运行的域账户有访问网络资源的权限,那么SA账户也拥有访问该资源的权限.

3）当域控效劳器失效时,高可用性组是否继续可用?

答：

当域控效劳器失效时,无法进行自动故障转移,无法使用机器名直接访问数据库,但仍可使用IP或高可用性组侦听器所拥有的IP进行访问.

4）域控效劳器重启对高可用性组的影响?

答：

当域控效劳器短暂重启时,对高可用性组影响较小，在域控效劳器重新恢复后，无需对高可用性组进行任何配置修改。

如域控效劳器长期失效时，建议删除高可用性组。

5）主域控效劳器和辅助域控效劳器的区别？

答：

主域控效劳器是建立域时的第一台域控效劳器，而辅助域控效劳器那么是域创立后添加的域控效劳器，常见配置中会将辅助域控效劳器DNS指向主域控效劳器，主域控和辅助域控都各自独立存放域相关信息，域控之间使用播送方式来传递更新信息以到达信息复制的目的，多台域控效劳器能提高域中账户验证速度，辅助域控可起到容错功能，主域控发生故障时，辅助域控能取代主域控提供效劳。

6）当域控效劳器失效时，是否仍然可以使用域账户登录效劳器？

答：

不一定，效劳器有一定的缓存机制，在账户第一次登录验证后，会保存该账户信息一段时间，在该时间段范围内域控效劳器失效时，用户依然能登录效劳器。

〔因此建议SQL效劳运行的域账户属性设置为密码永不过期〕

7）当域控效劳器失效或域账户密码变更时，以域账户运行的SQLServer效劳是否会受到影响？

答：

正在运行的SQLServer效劳不会受到影响，但当SQLServer效劳再次重启时，需要验证账户的密码，此时会重启失败。