迁移IT系统并非易事。 但是，特别困难的情况是，您不仅需要从旧版本切换到新版本，而且还需要在现有设备上迁移到新操作系统，而又不迁移生产数据。 这样的举动持续了大约一年，其中大部分都需要准备。
客户在不同城市有两个站点，每个站点都有两个连接的数据存储系统。 使用内置复制工具将来自一个存储系统的信息发送到第二个。 使用外部备份系统执行管理。 在一个城市中，安装了两个NetApp 3250系统，在另一个城市中-主NetApp 6220和备用NetApp3250。客户端计划在将来扩展此综合设施，添加磁盘和升级控制器。
图 1存储系统与IBS的交互方案而与此有关的主要问题是-支持终止。 对于存储系统上安装的Data ONTAP 8.2 7-模式操作系统，两年来一直没有重大更新，严重错误更正的发布将在2021年停止。 较新的驱动器和控制器与旧版操作系统不兼容。
解决方案是过渡到ONTAP 9.1集群系统，这是这些存储控制器最后一个受支持的系统。 它的主要优点是：
- 通过合并到单个容错群集中进行水平扩展，这将使您能够基于生产性存储和SRK创建单个系统。
- 控制器，磁盘之间的负载平衡以及在存储系统内部移动数据的过程中不会中断服务并停止对应用程序的访问。
- 维护数据存储系统的硬件和软件，而不会中断其工作和服务。
- 创建异构集群配置（包括各种类型的控制器和磁盘，包括第三方存储系统）的能力取决于使用许可证对其磁盘容量进行虚拟化。
- 能够将SSD用作聚合的缓存层。
- 数据压缩机制的优化操作（压缩和重复数据删除）。
从7模式迁移到集群模式有3个选项：
- 使用Netapp 7模式转换工具（7MTT）和基于副本的转换（CBT）迁移数据复制。 为此，需要具有较小磁盘空间和基于SnapMirror的分阶段复制的第二个存储系统。 对于每种服务，在给定时间协调并执行切换。
在我们的一位客户中，我们已经在都市集群上执行了此过程。 由于卷数量众多，LUN（> 400）以及详细信息，停机时间等的长时间协调。 迁移大约花了3个月，不包括培训。 - 使用Netapp 7模式转换工具（7MTT）和无副本转换（CFT）迁移而不移动数据。 为此，您需要另一个具有最少磁盘数量的存储系统，在初步准备之后，该系统将切换生产磁盘子系统。 对于所有服务，都同意一个大的停机时间。
- 使用主机工具进行复制数据迁移。 这是任何制造商的存储系统之间的传统迁移路径。
由于现有存储系统仍在供应商的支持下，并且控制器的性能在不久的将来就足够了，因此未分配购买新控制器的预算。 在这方面，决定使用7MTT CFT将控制器迁移到群集模式。 关键要求之一是存储系统的运行中不应出现明显的中断：大多数系统应在工作日平稳运行。 因此，在生产存储系统上进行迁移的主要工作计划在周末进行。
准备阶段开始于从存储系统收集信息并进行初步检查。 专用的NetApp 7MTT软件会生成警报列表，这些警报可能会干扰迁移或无法完成迁移。 例如，对于其中一个系统，此列表包含200多个项目。 必须将所有系统更新到最新的操作系统支持版本，更新控制器的固件，磁盘架和磁盘本身。 此外，新操作系统具有不同的操作逻辑，需要其他IP地址和存储系统之间的连接。
停止因素的发现非常迅速-客户端使用的技术不是基于整个卷复制，而是基于qtree复制（适用于访问，卷等限制的小节），并且无法将SnapVault关系迁移到新操作系统。 结果，在开始工作之前，有必要完全删除所有复制副本。 为了确保迁移后的客户端不会没有备份，在迁移之前就启动了基于整个卷复制的备份。 使用SnapMirror，在旧备份旁边创建了新备份，并且在四个星期的过程中积累了更改日志。 并且，如果其中一个站点上有足够的空间用于此，则第二个空间有限，则有必要逐步制作其中一卷的副本。 四周后，旧的关系被删除，新的关系被创建。 一个相当漫长，分阶段的过程，一个站点大约要花1.5个月，第二个站点要花3个月以上。 另外，我想指出，停止Snapvault关系的过程伴随着目标qtree的删除，其执行速度在很大程度上取决于文件的数量，并在较小程度上取决于文件的大小。 例如，在24小时内删除了具有400万个文件和500GB大小的qtree。
在此过程中，出现了各种困难。 在客户端系统上进行更改的流程的官僚化增加了工作协调的条件。 幸运的是，我们设法同意直接解决技术问题，在更高级别上仅讨论重要的“意识形态”问题，例如就工作计划达成协议并选择具体的移居日期。
困难是由于使用临时存储引起的。 在7MTT的指导下，我们根据要求和预检查配置了两个存储系统。 然后他们关闭了旧存储，并将磁盘架连接到新的。 再次检查了一切。 从NetApp软件的角度来看，迁移过程已完成，每个人都分散
了精力 。 但是下一步是将所有内容返回给旧的客户端控制器。 事实是，这种转换-从新控制器到旧控制器的转换-不受官方支持。 切换回去后，操作系统开始出现错误并抱怨群集出现问题。 经过研究，我发现问题出在集群突然切换到交换模式，而不想回到无交换模式。 解决该错误花了很长时间。 解决了群集启动问题，方法是在启动时不连接通往战斗网络的电缆，将群集内网络提升到一根电缆上，然后添加第二根。 顺便说一句，应该记住，在较旧的控制器和较旧版本的OS上，只能在有限范围的适配器的某些端口上建立群集内网络，例如，在FAS3250上是e1a和e2a（客户必须购买10GB以太网卡）。
他们在第二个站点上花了更多的时间来工作，希望至少避免一些问题，但这无济于事-操作系统的行为异常。 图表移动了两次。 在第一种情况下，当我们使用FAS3250时，由于最近更改的客户网络基础架构设置中的错误，无法迁移以24/7运行的战斗系统（尽管在工作开始前一周测试迁移，但一切都飞起来了）。 vMotion将虚拟机以小于1 Mbps的速度复制到远程存储系统。
在迁移期间，客户端部分更改了体系结构。 先前已通过NFS以太网发布了分发到其VMware vSphere基础架构的卷。 客户端重命名了它们，然后它们移到了光纤通道。 在迁移过程中，事实证明LUN完全更改了其ID，因此，VMware看到了用旧数据寻址到它的新LUN，并拒绝永久连接它们。 因此，借助VMware专家的帮助，可以通过控制台持续连接这些LUN，这表明这是旧数据存储的快照。 然后，我不得不重新启动VMware主机。 结果，他们设法看到了虚拟机并提升了虚拟基础架构。 而且，如果客户端继续使用NFS，则不会出现这样的问题-IP地址和DNS名称与以前相同。
直接在迁移日的工作计划：
星期五：使用存储系统和IBS
- 他们停止了SnapVault和SnapMirror之间的所有关系，切换了临时存储，并检查了系统是否已准备好进行迁移。 我们开始了使用“自由复制过渡”方法将存储迁移到7MTT的过程。 将战斗磁盘团重新连接到临时控制器。
- 迁移到7MTT，将替换控制器的根卷迁移到SRK存储系统的磁盘架。 我们安装了新的以太网适配器，启动了SRK存储系统，删除了配置，并从HTTP服务器通过网络下载了OS映像。 我们安装了新版本的固件和操作系统（在此阶段，通过网络下载映像存在无法解释的问题。最后，直接从便携式计算机下载了映像）。
- 我们用旧的替换了集群中的控制器，并通过移动存储过程进行升级，将战斗磁盘架连接到存储系统。 我们还原了群集，重新配置了网络接口（我必须解决与群集错误操作相关的问题）并安装了许可证密钥。
星期六：使用主存储
- 我们将临时磁盘架连接到临时存储，然后重新设置。
- 重要的虚拟机已使用VMware vMotion迁移到存储到远程数据中心。
- 使用CFT方法将主要的存储系统迁移到7MTT。 他们关闭了主战存储，将其磁盘架连接到控制器，并将操作系统元数据转换为7MTT。 交换控制器的根卷已迁移到SRK存储系统的磁盘架。
- 我们安装了新的以太网适配器，并以无盘配置启动了战役存储，删除了设置，然后从HTTP服务器通过网络下载了该存储。 已安装新的固件和操作系统版本。 我们更换了集群中的控制器，并通过移动存储过程进行升级，将作战磁盘架连接到存储系统。
- 恢复了群集，重新配置了网络接口（由于连接了战斗网络接口而使群集无法正常工作）。 已安装的许可证密钥。
- 我们恢复了与VMware服务器的存储连接，更改了SAN网络中的分区，配置了LUN的映射，将卷移到了单独的SVM上以进行FC访问。 将LUN连接到ESXi。 由于LUN ID已更改，因此数据存储未出现在自动模式下，因此我必须一致地重新启动ESXi服务器，并通过esxcli用命令将LUN连接起来。
- 重新配置了战斗界面，重命名了CIFS服务器，并重新获得了对CIFS Ball和NFS导出的访问权限。
星期日：解决和设置IBS软件的问题
- 虚拟机从存储系统迁移回战斗存储系统。
- 我们解决了通过Linux主机以录制模式访问文件夹的问题。 我们部署了最新版本的Netapp onCommand Unified Manager 7.3监视软件，并将两个存储系统都连接到该软件。
- 我们使用Unified Manager软件，使用SSD将缓存层连接到现有磁盘单元（闪存/存储池），分析了有关单元当前负载的数据。
- 他们关闭了备用存储系统，创建了群集链接（群集对等，SVM对等），以便可以使用复制。 我们基于现有卷（在SnapMirror 7模式关系中使用了）并在更改数据的重新同步基础上在主存储和SRK存储之间创建了新的SnapMirror关系，然后将SnapMirror关系转换为SnapVault（SnapMirror XDP）关系。
- 我们使用Commvault技术支持将两个存储系统都以NetApp开放复制模式连接到Commvault SRC软件，尽管我们已按照说明进行了所有操作，但这并没有什么不同。 已配置从SRK的作战存储和存储系统发送自动支持日志。
星期一：磨
- 验证存储系统的主要生产性存储和存储系统的操作。 解决可能的问题和故障。
- 断开和拆除临时设备。
迁移本身仅用了两天。 此举很成功，所有客户数据都是安全可靠的。 还保留了备份管理系统以及与现有SRK软件的集成。 如果您以前将Commvault捆绑包与OnCommand Unified Manager一起使用，则在切换到群集模式后，决定放弃它，转而使用Netapp Open Replication将Commvault直接连接到存储控制器。
根据此迁移的结果，我可以提供的主要建议是：从7模式切换到群集模式，以及更换控制器。 如果您仍然打算移至第二个控制器（如上述情况），则需要计划足够的时间来解决移回旧控制器时必然出现的各种问题。 如果得到专业人员的信任，使用迁移而不使用7MTT CFT迁移数据是完全安全的过程。
迁移过程中使用的有用指南：
Dmitry Kostryukov，存储系统首席设计工程师
计算机综合体“ Jet信息系统”设计中心