SQLServerAlwaysOn高可用性解决专项方案.docx

Microsoft SQL Server AlwaysOn
高可用性处理方案编 制 人：***
审 批：****
编 号：Q/DF-XX.2.01-
目前版本：V1.0
公布日期：7月8日
反馈对象： 市场中心 销售中心 融资中心 人资中心 财务中心 研发中心

1. 术语定义
1) 高可用性：HA（High Availability）
通常来描述一个系统经过专门设计，从而降低停工时间，而保持其服务高度可用性
2) 灾难恢复：DR（Disaster Recovery）
指自然或人为灾难后，重新启用信息系统数据、硬件及软件设备，恢复正常商业运作过程
3) 故障转移群集：WSFC（Windows Server Failover Cluster）
微软操作系统针对服务器提供一个服务，该服务用于预防单台服务器故障造成服务失效。
2. 企业数据库使用现实状况及问题瓶颈
其它部门对应用开发部负责融资管理系统性能提出以下问题：
1) 数据部：
a) 服务器不稳定
b) 数据库性能配置低
2) 市场部：
a) 查询效率太低
3) 产品部：
a) 报表、BI支撑难
这些性能问题无不包含到后台数据库性能及可靠性问题。
还有一个安全问题也值得重视。现在，企业产品数据库和融资管系统全部布署在10.44.1.3一台服务器上。理论上，产品数据库不应和Web应用布署在同一台机器而暴露给用户，产品数据库最好只交由专职DBA来管理。因为，万一Web应用遭受黑客攻击，产品数据将见面临巨大威胁，甚至有可能被永久性物理删除。前很快，就有报道携程数据遭受有预谋内部攻击被物理删除（）。假如分开布署，那么即使Web应用遭受攻击，只要产品数据在，我们仍然能够在短时间内布署新Web应用。

3. SQL Server 高可用技术介绍
1) 故障转移群集(Failover Cluster)
共享存放，效率高，但某一个时间点只有一个节点处于活动状态，造成硬件资源浪费。
2) 数据库镜像(Database Mirror)
提供几乎是瞬时故障转移，以提升数据库可用性。但其最大弊端在于镜像数据库处于不可读状态，一样造成硬件资源浪费。
3) 日志传送(Log Shipping)
还原作业之间间隔时间内只读访问权限，可用做报表查询。通常见于远程异步容灾，存在部分数据丢失可能性。
4) 复制(Replication)
基于数据库对象等级，灵活性较高，但弊端在于，它不支持DDL命令，不便维护。
5) AlwaysOn
AlwaysOn是SQL Server 中提供一个全新高可用性技术，其集中了上述4种高可用性技术优点，以确保企业无需增加成本和提升复杂度，即可实现最高等级可用性和数据保护。可在数据中心内部和跨数据中心实现数据冗余，快速地实现应用程序故障转移，保护现有硬件资源，同时简化了其配置过程。AlwaysOn能够实现服务器实例级和数据库级配置高可用性，所对应技术就是AlwaysOn故障转移群集实例和AlwaysOn可用性组。
下图1展示了使用Alwayson可用性组 HA 和 DR 处理方案

图1

4. AlwaysOn高可用性技术介绍
1) AlwaysOn 故障转移群集实例
通常来说，在单服务器情况下，当服务器上出现硬件或软件故障时，连接到该服务器应用程序或用户端将会停机。在AlwaysOn故障转移群集实例环境中，SQL Server 实例高可用性受到冗余节点保护。 在群集环境中，一次只能有一个节点拥有群集资源组。 在出现故障(硬件故障、操作系统故障、应用程序或服务故障)或进行计划升级时，该资源组全部权就会转移至另一个群集节点。 此过程对于连接到 SQL Server 用户端或应用程序是透明，能够最大程度地缩短出现故障时应用程序或用户端停机时间。所以AlwaysOn故障转移群集实例必需由一组物理服务器节点组成，这些服务器节点推荐使用类似硬件配置和相同软件配置，如操作系统版本、SQL Server 版本、修补程序等级、组件和实例名称。 相同配置是确保群集在节点间进行故障转移时能够正常运行前提条件。
　　SQL Server 在原有SQL Server故障转移群集基础上功效得到了深入增强，支持跨越子网实现多站点群集，此技术通常见于两个或两个以上数据中心，以同时提供当地高可用性和远程灾难恢复。其中，每个故障转移群集节点全部连接到其它子网或其它子网组。这些子网能够处于同一位置中，也能够在地理上分散站点。 跨地理上分散站点进行群集有时又被称为扩展群集。 因为没有供全部节点全部能够访问共享存放，所以在多个子网上数据存放之间应该复制数据。所以，多子网故障转移群集除了含有高可用性之外，还提供了灾难恢复处理方案。下面以图例说明：

图2
在上图中共有两个数据中心而且处于不一样子网，当地数据中心subnet1使用IP地址是10.168.0.10，当当地数据中心发生故障时，SQL Server服务会转移到远程数据中心，远程数据中心subnet2所使用是不一样IP地址，为192.168.0.10来继续提供数据库服务，这两个IP地址之间是OR关系，也就是说这两个IP地址任意一个在线话，虚拟网络名称SQLClus全部能够正常向用户端提供服务。
在此需要使用到存放等级复制技术，将当地数据中心数据库中数据文件及日志文件复制到远程数据中心，当当地数据中心发生故障时，Windows 群集检测到故障，远程数据中心存放软件能够检测到复制失效，会将存放转换为读写状态，接下来Windows群集会将远程站点可读写存放设备挂接到远程Cluster节点上，此时存放复制方向就从远程数据中心向当地数据中心复制。也就是说，故障转移群集实例成功开启后，Windows群集服务将监视基础群集运行情况和 SQL Server 实例运行情况。SQL Server 中许可群集服务使用专用连接来轮询活动 SQL Server 实例，方便经过系统存放过程获取具体组件诊疗信息。好处是，利用和 SQL Server 实例专用连接，能够对组件诊疗信息进行可靠轮询，即使在故障转移群集实例负荷较重时也是如此。利用具体组件诊疗信息，能够配置更灵活故障转移策略，由此用户能选择哪些故障条件将触发故障转移和哪些故障条件将不触发故障转移。用户利用产生诊疗信息，还能够经过追溯方法愈加好地对自动故障转移进行故障排除。此诊疗信息将存放到和 SQL Server 错误日志并置日志文件中。 能够将这些日志文件加载到日志文件查看器中以检验造成出现故障转移组件状态，从而确定造成该故障转移原因。
2) AlwaysOn可用性组
AlwaysOn可用性组是SQL Server 中提供全新功效，确保了应用程序数据可用性，实现零数据丢失。AlwaysOn可用性组技术融合了数据库群集和数据库镜像优点，此技术一大好处是提供非共享存放，能够避免因为存放单点故障而造成整个可用性方案失效。
　　AlwaysOn可用性组基于数据库(组)等级，是将一组用户数据库(能够是一个或多个)划到一个组中。每组可用性数据库全部由一个可用性副本承载。可用性副本包含一个主副本和一到四个辅助副本（最多支持8个）。 主副本用于承载主数据库，辅助副本则承载一组辅助数据库并作为可用性组潜在故障转移目标。主副本使主数据库可用于用户端读写连接，实现对数据库更改操作。 同时在数据库等级进行同时。 主副本将每个主数据库事务日志统计发送到每个辅助数据库。 每个辅助副本缓存事务日志统计，然后将它们还原到对应辅助数据库。 主数据库和每个连接辅助数据库独立进行数据同时。 所以，一个辅助数据库能够挂起或失败而不会影响其它辅助数据库，一个主数据库能够挂起或失败而不会影响其它主数据库。
　　另外，用户能够借助辅助数据库来实现近实时报表查询，将查询负载分担到只读副本。相对于数据库群集及镜像来说，能够愈加好利用硬件资源，从而提升IT效率并降低成本。
下面看一下AlwaysOn可用性组架构，以下图3所表示：

图3
　　布署 AlwaysOn 可用性组需要一个 Windows Server 故障转移群集 (WSFC) 群集。 给定可用性组每个可用性副本必需在相同 WSFC 群集不一样节点上。 布署AlwaysOn可用性组时，系统会为每个可用性组创建一个 WSFC 资源组。WSFC 群集将监视此资源组，判定节点间状态，方便评定主副本运行情况。 当发生失败时实现故障转移，针对 AlwaysOn 可用性组仲裁基于 WSFC 群集中全部节点，而和某一给定群集节点是否承载任何可用性副本无关。
　　用户能够经过创建一个可用性组侦听器来提供到给定可用性组主副本用户端连接。“可用性组侦听器”采取DNS名称方法连接给定可用性组资源，方便将用户端连接定向到对应可用性副本。
　　对于每个可用性副本，AlwaysOn所支持事务提交模式分为同时提交模式或异步提交模式。在异步提交模式下，主副本无需等候确定异步提交辅助副本已强制写入日志，便可提交事务。 异步提交模式可最大程度地降低辅助数据库上事务滞后时间，但许可它们滞后于主数据库，所以可能会造成一些数据丢失。此可用性模式是一个灾难恢复处理方案，适合于可用性副本分布距离较远情况。所谓同时提交模式是指在提交事务之前，同时提交主副本要等候同时提交辅助副本确定它已完成强制写入日志。 同时提交模式可确保在给定辅助数据库和主数据库同时时，充足保护已提交事务。 这种保护代价是延长事务滞后时间。此可用性模式相对于性能而言更强调高可用性和数据保护，当主副本和辅助副本距离较近时能够使用此方法，处理时时同时问题。
　　正因为AlwaysOn可用性组集现有高可用性技术优点于一身，不得不说，它是SQL Server 新特征中最为璀璨一个。
5. 东方融资网可实施AlwaysOn测试布署方案
1) 宿主机
宿主使用工作站（HYPR-V），其基础配置以下：
b) 处理器：Intel(R) Core(TM) i5-4470 CPU @ 3.20GHz 3.20GHz
c) 内存(RAM)：8.00GB
d) Windows版本：Windows Server R2 Standard
2) 虚拟机配置
数据库服务器基础配置：4个逻辑cpu，1G内存，100G硬盘(C:70G;D:30G)
HostName
IP配置
OS版本
SQL版本
功效介绍
AD Server
IP：192.168.1.110
Windows Server R2 Standard
NULL
域控制器
Server01
IP：192.168.1.111
Windows Server R2 Standard
SQL Server R2企业版
群集节点01
Server02
IP：192.168.1.112
Windows Server R2 Standard
SQL Server R2企业版
群集节点02

3) AlwaysOn可用性组安装配置架构图
以下图所表示，一个windows群集clustest01中包含三个节点（server01，server02）节点01和节点02组成SQL Server群集，实现实例等级自动故障转移和AlwaysOn可用性组，可用性组添加侦听IP[192.168.1.130]，用于用户端连接，以实现可用组切换而不用修改用户端连接配置。

图4
4) Windows群集安装
将三个服务器全部加入域环境中；并安装.Net 3.5和故障转移群集功效后，开始创建新群集。
第一步：配置主域控服务器AD Server
a) 在仪表板服务器角色中添加Active Directory 服务器及DNS服务，并配置域名为。
b) 配置本机IP为192.168.1.110。
c) 建立域账户sql @，账户属性设置为密码永不过期

第二步：配置三个数据库服务器Server01，Server02
a) 设置IP Server01（192.168.1.111），Server02（192.168.1.112）
b) 关闭防火墙
c) 加入域
d) 在仪表板功效中添加.Net 3.5和故障转移群集
第三步：创建新群集Cluster01
a) 在数据库服务器Server01上创建新群集Cluster01。
b) 将server01、server02添加到该群集中。
c) Cluster01群集IP配置为192.168.1.120。
d) 测试验证经过后，域中自动生成Cluster01$域账户。
e) 在AD Server上创建仲裁共享文件夹ClusterShare ，并共享给Cluster01$域账户，设定其读写权限。
第四步：Server01，Server02安装SQL server R2
a) 分别安装SQL server R2
b) 网络配置服务中SQL Server 数据库服务启用AlwaysOn高可用性组。
c) SQL Server 数据库服务及SQLServer代理登录设置为域账户
第五步：仲裁配置
为配置简单且在资源有限情况下，该测试环境中AlwaysOn群集仲裁配置为多数节点和文件共享模式。
配置过程见以下截图：
a) 更多操作配置群集仲裁

图5
b) 进入配置群集仲裁向导界面

图6

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

图7

第六步：创建测试数据库
a) 在Server01数据库实例上创建测试数据库testDB1和testDB2
b) testDB1和testDB2做好完整备份
c) 在Server01 D盘创建共享文件夹 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) 验证故障自动转移功效
l 关闭Server01服务器。数据库用户端连接Server02，可查看到Server02此时已切换为主副本，Server02上testDB1和testDB2也已切换为主数据库。
l 再开启Server01，并在Server02可用性组中加入Server01后，可查看到Server01此时又作为辅助副本。
l 关闭Server02，此时又查看到Server01变为主副本。
b) 验证监听Listen01实时监听及AlwaysOn01可用性组同时功效
l Server01用户端连接Liseten01服务，可访问到数据库testDB1和testDB2。
l 在TestDB1数据库中Create 新表 testTabel1，在testDB2 Create 新表 testTabel2。
l 连接Server02数据库实例，发觉Server02TestDB1上可查看到testTabel1，testDB2可查看到testTabel2。
c) 验证辅助副本只读访问。
l 查看AlwaysOn01属性，此时 Server01为主副本，Server02为辅助副本。
l 数据库管理工具连接Server02。
l 在Server02上实施写操作将失败，实施查询操作成功。
6. Alwayson问题总结
1) Alwayson 是否依靠于域环境?
答: 是, alwayson依靠于故障转移群集(只有在故障转移群集中SQL Server 才能开启高可行性组功效),而故障转移群集依靠于域环境.
2) 为了启用高可用性组功效,SQL Server服务是否必需使用域账户运行?
答: 否,在使用非域账户运行SQL Server服务上仍然可构建高可用性组,服务运行账户决定SQL Server中管理员操作权限, 假如运行域账户有访问网络资源权限,那么SA账户也拥有访问该资源权限.
3) 当域控服务器失效时, 高可用性组是否继续可用?
答：当域控服务器失效时,无法进行自动故障转移, 无法使用机器名直接访问数据库,但仍可使用IP或高可用性组侦听器所拥有IP进行访问.
4) 域控服务器重启对高可用性组影响?
答：当域控服务器短暂重启时,对高可用性组影响较小，在域控服务器重新恢复后，无需对高可用性组进行任何配置修改。如域控服务器长久失效时，提议删除高可用性组。
5) 主域控服务器和辅助域控服务器区分？
答：主域控服务器是建立域时第一台域控服务器，而辅助域控服务器则是域创建后添加域控服务器，常见配置中会将辅助域控服务器DNS指向主域控服务器，主域控和辅助域控全部各自独立存放域相关信息，域控之间使用广播方法来传输更新信息以达成信息复制目标，多台域控服务器能提升域中账户验证速度，辅助域控可起到容错功效，主域控发生故障时，辅助域控能替换主域控提供服务。
6) 当域控服务器失效时，是否仍然能够使用域账户登录服务器？
答：不一定，服务器有一定缓存机制，在账户第一次登录验证后，会保留该账户信息一段时间，在该时间段范围内域控服务器失效时，用户仍然能登录服务器。（所以提议SQL服务运行域账户属性设置为密码永不过期）
7) 当域控服务器失效或域账户密码变更时，以域账户运行SQL Server服务是否会受到影响？
答：正在运行SQL Server 服务不会受到影响，但当SQL Server服务再次重启时，需要验证账户密码，此时会重启失败。