WSFC SQL应用磁盘阵列替换

   在上篇文章中，我们讲了WSFC上层文件服务器应用数据磁盘的替换与升级，实际上我们可以有好多个场景去适用这种替换方式，第一，扩容替换 ，就是我们上篇所演示的那样，第二，坏损替换，事先文件服务器好的时候，把数据拷贝出来，某天忽然群集数据磁盘坏了，直接插入新磁盘，把备份的内容还原进来，点击修复磁盘即可。

   那么基于上篇文章提到的内容，本篇我们再来看一种场景，针对于SQL Server群集应用，完整替换群集磁盘阵列，应该怎么处理。

    一个SQL群集会有仲裁磁盘，DTC磁盘，数据磁盘，甚至日志磁盘，我们假设这些磁盘都来自同一个存储阵列，现在要全部换到另外一个新的存储阵列，应该如何操作。

    首先，根据我们上篇文章所提到的修复替换方法，可以参照下列流程操作

1. 新阵列分配LUN到群集节点

2. 群集节点识别存储磁盘，联机，初始化，分区，分配非原群集磁盘临时盘符

3. 首先添加见证磁盘，直接更改见证磁盘为新磁盘

4. 脱机SQL群集应用，这将停止SQL服务以释放SQL数据文件上任何打开的句柄

5. 拷贝原SQL数据磁盘完整目录内容到新数据磁盘，可以使用资源管理器，或使用Xcopy，RoboCopy拷贝，如果针对于数据库文件权限有所设置，这里可以进行处理

6. 记录现有DTC应用配置，删除，基于新磁盘原样重建新的DTC应用

7. 点击SQL应用现有数据磁盘，右键点击修复，选择新数据磁盘

8. 联机上线SQL应用

9. 原SQL数据磁盘自动从SQL群集应用删除，从群集可用磁盘删除

根据老王的研究，针对于SQL群集的磁盘替换，除了这种方法，还有以下几种方法

1. 新增替换：不采用修复替换，使用新增磁盘至SQL资源组，手动修改盘符。缺点：有一点点复杂，需要理解群集磁盘替换过程，如果不小心操作错误会导致应用不能联机

2. 备份恢复：网上也有朋友介绍过一种办法，事先针对于数据库进行MDF,LDF的备份，之后新增磁盘，删除原磁盘，附加还原数据库。缺点：如果数据库过多的话，会需要执行多个数据库备份，如果数据库不多，可能适用，但需考虑到数据库权限的恢复

3. 重装替换：直接重新搭建一个群集，再从备份的数据库文件恢复，缺点：如果数据库实例很多，重装将会非常耗时。如果只有一个数据库实例，可能适用，但仍需考虑数据库权限的恢复。

4. 工具替换：有一些第三方工具可以帮助我们在两个群集，或者说两个SQL实例之间，或是从文件到数据库，批量还原迁移数据库，同时可以保证数据库权限的恢复，但需要操作人员熟悉第三方工具

基于考虑我们决定采用最为熟悉稳妥的修复替换方式

环境介绍

DNS&iscsi

lan：10.0.0.2 255.0.0.0

iscsi：30.0.0.2 255.0.0.0

08node1

MGMET:10.0.0.3 255.0.0.0 DNS 10.0.0.2

ISCSI：30.0.0.3 255.0.0.0

CLUS：18.0.0.3 255.0.0.0

08node2

MGMET:10.0.0.4 255.0.0.0 DNS 10.0.0.2

ISCSI：30.0.0.4 255.0.0.0

CLUS：18.0.0.4 255.0.0.0

当前SQL群集已经配置完毕DTC，及SQL应用

验证SQL Server 故障转移，及查询，可以正常工作

时间节点来到第二步

各节点得到存储新分配的存储，并且已经完成分区格式化

新分配的S O X 分别为新见证磁盘，新DTC磁盘，新数据磁盘

其中 见证磁盘和DTC磁盘里面的数据可以接受重建，因此不需要考虑盘符问题

添加新阵列见证磁盘，DTC磁盘为群集可用磁盘

点击群集名称-更多操作-配置群集仲裁设置

在选择见证存储处取消勾选之前旧的存储，勾选新的见证磁盘作为见证

配置完成可以看到，群集见证磁盘已经自动变为了新的阵列磁盘，原有见证磁盘被移动至群集可用存储，这时它已经不起作用，可以选择从群集可用存储中删除。

这里的见证磁盘替换非常简单，因为见证磁盘的作用无非是在发生分区的时候帮助其中一方获胜存活，储存群集数据库副本，群集数据库副本各个节点本身都有，新的见证磁盘无非是添加进来重新和各节点同步下最新的群集数据库副本

在实际见证磁盘替换过程中，按照正常步骤操作，通常不会出现宕机情况，因为几乎就是一瞬间的事情，2012之后有动态仲裁，更不会宕机，如果在2012之前，发现替换见证磁盘过程意外出现宕机，可以使用强制仲裁启动群集服务。

接下来我们需要处理DTC和SQL，SQL群集应用可其它群集应用不一样的地方就是，它可能随时随地会在用着，有句柄在打开它的文件，因此我们需要脱机SQL群集应用，才可以做拷贝文件和处理DTC的操作，这也是此方案的弊病，如果采用备份替换，工具替换，则不会面临此问题，此过程宕机时间视数据库拷贝时间决定。

脱机SQL群集应用，宕机时间开始

在这一步骤中如果发现SQL旧数据磁盘不可见，可以单独把SQL旧数据磁盘进行联机，以便拷贝文件，这时候所有连接到SQL群集应用的句柄已经关闭

拷贝整个旧数据目录至新数据磁盘，如果针对于数据库文件有权限设置，这里可以使用xcopy，robocopy进行处理

记录现有DTC应用配置，然后删除，重建

这里针对于DTC应用，我们可以选择这种直接重建的方式，或者如果您不方便重建，修复替换，新增替换的方式也可以操作，DTC应用本身并没有什么不可以替换的数据，只是用于SQL各节点的间的分布式协调。因此我们采用直接重建没有问题。

最后使用修复替换掉SQL应用的数据磁盘，在SQL应用群集磁盘5的地方右键点击-更多操作 - 修复

这里的群集磁盘5状态一定要是脱机才可以使用修复

选择拷贝完成数据的新数据磁盘

和文件服务器替换一样，修复向导直接自动帮助我们把旧的群集磁盘信息，带入新群集磁盘，确认盘符为旧盘符

联机上线SQL群集应用

验证可以正常执行故障转移

验证可以正常进行数据库查询

到这里我们完成了SQL群集应用的全部存储替换

使用这种替换方式的好处，我们不用一个个的去备份还原数据，不用去care权限的问题，因为所有文件我们都是原封不动的拷贝

缺点就是SQL应用的停机时间较长，主要是脱机拷贝数据库目录的时间，具体实际环境下，也许可以有一些更灵活的方式，例如可以下班之前冻结SQL写入句柄，然后拷贝文件出来，下班之后直接替换见证，DTC，然后修复SQL。

以上是老王为大家带来的两篇关于群集替换存储的文章，希望能为感兴趣的朋友带来收获