SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)

因为篇幅原因,AlwaysOn可用性组被拆成了两部分:理论部分和实战部分。而实战部分又被拆成了准备工作和AlwaysOn可用性组搭建。

三篇文章各自的链接:

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(理论篇)

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之AlwaysOn可用性组搭建

 

 

 

之前的随笔《SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(理论篇)》中讲了AlwaysOn的理论篇,接下来是实战篇。以一个实战例子来实验AlwaysOn。话不多说,开始。由于SQL Server AlwaysOn依赖于WSFC,需要虚拟域名来实现故障转移。因此我们需要事先安装好活动目录域、DNS服务器和Windows故障转移群集才能进行后面的AlwaysOn可用性组搭建。而这篇文章就专门讲搭建AlwaysOn可用性组的准备工作。

 

架设环境信息

域名:jerrychen.com

AlwaysOn虚拟IP地址:192.168.2.200

WSFC虚拟IP地址:192.168.2.201

WSFC群集名:AOCLUSTER

 

  Domain Controller Primary Replica Secondary Replica
Server Name dc.jerrychen.com     main.jerrychen.com   slave1.jerrychen.com
OS Windows Server 2012 Data Center x64 Windows Server 2012 Data Center x64 Windows Server 2012 Data Center x64
IP Address 192.168.2.100 192.168.2.102 192.168.2.101
Gateway 192.168.2.2 192.168.2.2 192.168.2.2
SQL Server Version - SQL Server 2014 enterprise x64 SQL Server 2014 enterprise x64
DNS 127.0.0.1   192.168.2.100 192.168.2.100

 

 

 

 

 

 

 

 

搭建活动目录域和DNS服务器

首先是要搭建活动目录域和DNS服务器,因为这个不属于AlwaysOn范畴内,不细做。Windows Server 2012下可以通过服务器管理界面去添加主机角色成为一个域控制器并同时创建DNS服务器。然后按照上面的配置信息配置IP地址等网络配置。

 

域控

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第1张图片

 

主节点和副节点

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第2张图片

 

创建一个域管理员账户

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第3张图片

 

配置DNS服务器地址映射记录

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第4张图片

 

各台主机保证能互相ping通

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第5张图片

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第6张图片

 

准备工作完成后。就是在主节点和辅助接点上搭建故障转移群集,DC上不需要。

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第7张图片

 

安装好后打开故障转移群集管理界面,打开验证配置向导

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第8张图片

 

添加进群集节点

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第9张图片

 

使用推荐选项来进行节点的各项测试,包括磁盘、网络等

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第10张图片

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第11张图片

 

完成后可以点击View Report查看详细报告。这里例子里面会收到许多警告。比如网络,因为我们只有一块网卡。因为高可用推荐最好有两块网卡。一块网卡意味着单点可用。但并不要求非得有两块网卡才可以进行群集。所以只是警告。

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第12张图片

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第13张图片

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第14张图片

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第15张图片

 

其实上面打开的报表的源文件在存放在C:\Windows\Cluster\Reports这个地方的。这里存放了验证过程中的日志记录。

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第16张图片

 

 点击Finish后进入群集访问点配置界面,这里需要指定文章开头“架构环境信息”中提高的群集名和虚拟地址

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第17张图片

 

 这里需要提下这个"Add all eligible Storage to the cluster"选项。这个选项默认是勾选的。如果勾选了,意味着节点上的任何磁盘是要是对群集可见且满足了群集条件的就会被加入群集。通常一些服务器上会有许多磁盘,有些用于存放共享文件,有些存放数据库文件,有些存放应用程序文件等等。如果你不希望其他的一些无关的磁盘的故障影响到群集锁服务的主程序,就不要勾选。

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第18张图片

 

黄色高亮的区域意思是没有找到见证磁盘。这是因为我们还没有配置群集仲裁的缘故。当然也是我们接下来要配置的。

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第19张图片

 

完成了之后你就可以在DNS服务器上看到自动建立的DNS指针映射记录,记录着群集名和IP地址的映射。

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第20张图片

 

活动目录域上也可以找到对应的群集虚拟机器。说明刚才的配置没问题。

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第21张图片

 

接下来是配置群集仲裁。关于仲裁,可以在文章尾部的的“参考”中找到相应的文章。这里我们选择仲裁模式中的Node and File Share Majority,所以需要在DC上创建一个共享文件夹来充当充当仲裁的共享文件夹,用于记录存储群集节点的运行状态以决定是否故障转移。

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第22张图片

 

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第23张图片

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第24张图片

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第25张图片

 

这里报错了。原因是在创建好共享文件夹后虚拟群集机器需要对它有读写权限,包括NTFS权限和共享权限

 SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第26张图片

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第27张图片

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第28张图片

 

再重新配置就成功了

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第29张图片

 

SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作)_第30张图片

 

好。到此就完成了整个故障转移群集的搭建。完成群集搭建后就可以进行AlwaysOn可用性组的搭建了。

 

下篇将是《SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之AlwaysOn可用性组搭建》

 

参考:

WSFC 仲裁模式和投票配置 (SQL Server)

Windows Server 故障转移群集 (WSFC) 与 SQL Server

Failover Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster

Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery

 

你可能感兴趣的:(SQL Server ->> 高可用与灾难恢复(HADR)技术 -- AlwaysOn(实战篇)之建立活动目录域、DNS服务器和Windows故障转移群集(准备工作))