高级SAN迁移策略。这是个好主意吗

Question

在我工作的公司中，我们正在计划退役一个旧的SAN，它是我们的生产服务器的两个节点，使用集群运行两个Server实例(一个是一个实例的备份，另一个是主实例，反之亦然)。而不是那个旧的SAN设备(我相信它是VNX 500，但技术规范实际上与我在这里要求的并不重要，…)我们将有一个新的，或多或少应该用更好的能力和更多的存储取代现有的。简而言之，我们要做的就是做到这一点。

作为一个DBA，我参与了大量的Server迁移，但是在这种情况下，我们并不是真正地迁移数据库服务器，我们只是把SAN放在下面，用一个更华丽、更漂亮的…来代替它。我们已经和我们的企业架构师讨论了一种方法，它或多或少是这样的(非常高级)

1. 使用某些工具(TBD)设置文件同步，该工具将在文件块级别上工作，以同步数据和日志文件的内容。这将作为一个服务运行，而生产中的现有数据库服务器正在工作(使用旧的SAN)。
2. 让这个同步运行一两天，并观察到没有出现错误。
3. 晚上我们是不是做了我们的切割器
   • 使用MS群集管理控制台关闭Server服务(两个实例)
   • 使用MS群集管理控制台关闭群集本身
   • 将新的SAN设备呈现给SQL服务器。
   • 删除旧分区(不指定字母)
   • 把这些信分配给新山的隆斯一家
   • 使群集联机
   • 启动Server服务

4. 测试、测试、测试:一致性检查、验证Server错误日志以及查找其他问题

换句话说，我们正在考虑让SQL Server休眠一段时间，对SQL Server进行必要的基础结构更改，这些更改对于SQL Server来说应该是透明的，因此当我们将服务联机时，事情就会像以前一样被SQL所关注，但只是这一次我们正在读取新的SAN。

不对数据库进行直接备份/还原的原因是，我们试图将停机时间降到最低，而且我们相信，如果我们找到了在文件级别同步的正确工具，我们最终可能只需要进行最后的同步，以赶上最新的更改(一旦我们关闭了SQL Server Service)，而不是主要的文件复制操作(我们的数据库相当大，停机时间必须最少)。

我并不是要求全面检讨策略，亦不是在极低的层次上讨论这个问题，我只是想向社会人士提出这样的意见：

• 你有没有做过类似的事？成功了吗？
• 有什么发现吗？
• 这里缺少的任何东西(请注意，我知道我错过了很多东西，但我说的是高层次的楼梯)
• 您知道有什么工具可以提供我们正在寻找的功能，以便以这种方式同步文件(进行初始同步，然后只同步文件中的位/扇区/集群)吗？

感谢和抱歉的长篇，但我觉得如果我不包括至少一点细节，问题将相当模糊。

Answer 1

如果您正在使用vnx，您应该能够使用复制管理器或镜像视图，这两者都是emc产品。如果您的新SAN也来自emc，您应该有emc支持并使用它们来获得此类操作的建议。

Answer 2

除了Alex提到的复制之外，大多数现代存储系统都能够将其他数组连接为“外部存储”。因此，即使您拥有来自另一个供应商的存储，它也可能具有虚拟化旧数组并在数组之间迁移或镜像数据的能力。如果您的新存储系统可以这样做，如果需要购买许可证，请咨询您的供应商。它们可以提供临时或仅迁移许可。