VMAX、PowerMax：IBMi 主机平台的无中断迁移

支持环境：
NDM for IBMi 可用于连接到运行 PowerMaxOS 版本 5978.444.444 或更高版本的 VMAX 或 PowerMax 阵列的受支持 IBMi 主机系统。

这适用于在 IBM Power Server 平台 Power6 或更高版本上运行且运行 IBMi作系统 i6.1.1 或更高版本的 IBMi 逻辑分区 （LPAR）。VMAX 或 PowerMax 一般 e-Lab 支持矩阵提供了详细信息并列出了支持的光纤通道 （FC） IBMi I/O 适配器 （IOA）（也称为主机总线适配器 （HBA））。当 IBMi 是具有 IBM 虚拟 I/O 服务器 (VIOS) 分配的虚拟 I/O 资源的客户端 LPAR 时，NDM 也受到支持。借助 IBM VIOS/VFC （NPIV） 功能部件，虚拟 FC 适配器 （vFC） 将分配给客户端 LPAR，以便使用支持的 SAN 交换机连接到存储阵列。

vFC 充当主机磁盘连接的直通;从主机端来看，这是完全透明的，并且存储阵列的所有受支持功能在该虚拟化适配器设置中也可用。

后台和高层迁移方案：
Symmetrix Remote Data Facility （SRDF） 是在 20 世纪 90 年代初期开发的，作为 Dell Enterprise 存储阵列的灾难恢复 （DR） 复制技术。多年来，它还被用于执行从一个阵列到另一个阵列的基于存储的迁移。也就是说，在通过实施新的存储阵列来执行技术更新时，以“背靠背”方式连接新旧阵列并复制数据卷。虽然卷或逻辑单元 （LUN） 的 SRDF 复制过程对连接的主机系统是透明的，但传统上，从源卷 （R1） 完成复制过程时，始终需要一个短暂的脱机“切换”窗口。目标（新）卷 (R2) 支持读/写，并且主机系统的 FC 连接（通过 SAN 分区和掩蔽）指向新阵列。

SRDF/Metro 随 VMAX 全闪存存储阵列系列一起推出。SRDF/Metro 提供对来自两个阵列的源卷 （R1） 和目标卷 （R2） 的真正主动/主动主机访问。SRDF/Metro 可与支持的主机多路径驱动程序配合使用以进行磁盘访问。这包括用于磁盘路径的本机 IBMi 动态多路径 (DMP) 保护。IBMi DMP 会自动检测是否有多个 FC 路径到同一个磁盘设备。此外，它还提供基本但有效的“循环”负载均衡方案，以跨可用的 FC 适配器路径分布磁盘 I/O 工作负载。当连接可能失败时，IBMi DMP 通过将磁盘 I/O 操作重定向到剩余的活动路径之一来提供自动路径故障切换。恢复故障连接后，IBMi 会自动恢复这些路径，并再次开始向这些路径发送磁盘 I/O。

具有 METRO 和预拷贝选项的 NDM 基于底层 SRDF/Metro 技术，可同时访问旧存储设备和新存储设备。

创建阶段：
创建 SRDF/Metro 复制设备对 （R1>R2） 时，目标阵列中的 R2 设备会显示相同的 R1 设备身份。本质上，两个设备都提供了相同的磁盘序列号和设备 WWPN。最初，新 R2 设备处于 AA-NR/DEV-INACT（活动/活动-未就绪/设备不活动）状态。R1>R2 设备对同步后，可以通过启用对 R2 卷的读取和写入访问权限进入主动/主动状态。

READY_TARGET阶段：
现在，当从 IBMi LPAR 到 R2 设备的路径已启用（SAN 分区已到位并且通过 NDM readytgt 命令激活了新阵列的掩蔽）时，IBMi 主机会发现指向现有磁盘设备的新 FC 路径。在 IBMi NDM 场景中，将显示主动/主动 R1 + R2 设备。

提交阶段：
通过删除对 R1 设备的访问权限，IBMi 主机现在将无法访问旧阵列的路径，但继续使用新阵列的路径在 R2 设备上运行。完成此作后，可以删除旧阵列的 SAN 分区。应在 IBMi 系统上运行“重置多路径”实用程序，以便停止使用旧的非活动路径，并停止与这些现在“缺失”的路径关联的任何错误消息。可能需要初始程序加载 （IPL）（也称为重新启动）才能从 IBMi 主机的设备配置数据库（IBMi 存储管理信息存储库）中永久删除旧的非活动路径及其关联的 DMPxxx 磁盘硬件资源，但这不是必需的 IPL，它也可以等到下一个计划的 IPL 再执行。要删除这些“过时”设备：STRSST>启动服务工具>Hardware Service Manager>Failed and Non-reporting Hardware：使用选项 4 选择所有旧磁盘资源 DMPxxx 进行删除，然后按 Enter 键进行确认。

使用戴尔 STM
时的注意事项STM 也称为用于 VMAX 的 IBMi 复制控制的“存储拷贝服务工具包”，PowerMax 存储作为本机软件应用程序在一个或多个 IBMi 主机上运行。它可以控制 VMAX 和 PowerMax 阵列上支持的 SRDF 配置的远程复制以及 SnapVX 快照的本地复制。STM 有两种类型：标准功能版本和扩展功能版本。

STM 通过 FC 路径使用与存储阵列的带内通信，它使用小型专用设备，也称为系统调用的网关守护设备。IBMi 的网关守护设备是特殊的小型 D910 GK 类型设备，它们保留在未配置的磁盘单元部分中。这些网关守护设备不支持多路径，多个单路径网关守护设备通常显示在用于常规 ASP1 磁盘的同一组冗余路径上。建议至少使用四个网关守护设备。网关守护设备不是 NDM 迁移过程的一部分，因此在迁移后，将移除对旧阵列网关守护设备的访问权限，并提供新阵列中的新网关守护设备。

标准功能：
这用于仅使用 *SYSBAS 存储配置的系统。*SYSBAS 是指系统 ASP1 + 任何其他用户 ASP （ASP 2-32）。STM 仅安装在源节点上，它作为一个不可分割实体控制 *SYSBAS 中所有磁盘的复制对。  当底层磁盘配置发生变化时;即由 NDM“取消欺骗”作导致的磁盘序列号更改，在 IBMi 源主机上执行 STM DISCOVER 命令就足够了。当显示来自新阵列的网关守护设备时，运行 DISCOVER 选项。这会更新主机上集成文件系统 （IFS） 中的本地 symapi 数据库 （location= /var/symapi/db）。STM 屏幕现在也会反映新磁盘序列号。如果在 STM 内的复制设备配对中观察到任何问题，也可以仅使用安装选项从全新配置设置开始。这对已在 VMAX-PowerMax 存储阵列上配置的复制配对设置没有影响。对于干净暂存安装/设置，首先记录当前配置中的关联路径和步骤（GO MAINCTL>1，IMAGES>选择选项2，对于PATHS屏幕的系统映像> 创建屏幕捕获，如下例所示）：

退出 STM，删除 /var/symapi 文件夹及其子文件夹。删除 EMCCTL 库。再次运行 STM 安装程序。运行 CRTSYMAPI。转到MAINCTL，再次关联之前配置的相同路径。STM 现在检测并显示来自 VMAX-PowerMax 存储阵列的活动复制对的状态。STM作现在已准备就绪，可以恢复了。

扩展功能：
这用于使用具有一个或多个“可切换”iASP（独立 ASP）的 IBMi PowerHA 群集设置的系统。在这种情况下，仅复制 iASP，并且可以将此 iASP 或其副本呈现给 PowerHA 群集中的节点。每个群集节点已在自己的 *SYSBAS （ASP1） 上处于活动状态。iASP 在共享群集设备域中配置为可切换资源。群集中通常有两个或四个节点;这与以下示例所示为 4 节点群集，其中生产节点作为源，两端都有一个远程 DR 目标节点和一个 SnapVX 备份节点：

使用 iASP 或其复制副本不需要来自任何节点的 IPL。当 iASP 磁盘呈现给群集中的任何节点时，需要 VARY ON 命令才能使 iASP 可用于该节点。在 PowerHA 设置中，STM 源版本安装在源节点（在 EMCCTL 库中）上。在所有其他节点（SRDF 或 SnapVX 目标副本）上，目标版本已安装（在 EMCCTLC 库中）。当所有节点都处于活动状态时，STM 中内置了针对此设置中某些作的依赖关系和制衡机制，即如果该节点的 iASP 仍处于 VARY ON 状态，则禁止删除该节点的磁盘访问权限。对于节点间通信，在所有节点上的 EMCCTL 子系统中运行一个 STM 服务器作业。此作业通过群集 IP 接口在节点内进行通信。典型的 STM作可以从群集中的任何节点运行。这要求在每个节点上有一组相同的 STM 磁盘、适配器和路径配置文件可用。在 STM for PowerHA 的初始设置期间，使用源节点的 MAINCTL 选项 16 配置这些文件，同时将这些文件传播到目标节点，即 STM 安装库 EMCCTL 和 EMCCTLC 中的 IASPS、ISRCIOA 和 IMAGE 文件。这些文件也可以通过 DSPPFM EMCCTL/IMAGE 显示。这些文件包含有关用于 iASP 配置的磁盘和磁盘适配器的信息。适配器 ID 和磁盘序列号存储在这些文件中，并在 STM作中使用。

现在，考虑完成 NDM 取消欺骗作时发生的磁盘序列号更改的影响。STM 配置文件仍包含旧磁盘序列号。在这些配置文件更新之前，大多数 STM作不再正常工作。在运行 MAINCTL>Option-16（配置 iASP）且 iASP 磁盘可用于相应 PATH 步骤中的目标节点时，可以按照与初始 STM 安装期间相同的过程来更新和传播这些文件。更新这些文件后，STM iASP作将再次按预期运行。如果出现任何问题，请考虑仅为源节点和目标节点再次运行 STM 暂存安装，包括用于配置 iASP PATH 的选项 16 以及创建或传播 STM 配置文件。

具有戴尔支持帐户的注册用户可以查看 SRDF/TimeFinder Manager for IBM i ，了解有关这些 STM 版本的更多相关信息。

设备身份重置（也称为“取消欺骗”作）后下一次 IPL 的注意事项
NDM 取消欺骗作会更改磁盘序列号。仅当 IBMi LPAR 关闭时，才能执行此作。迁移后在计划的脱机维护时隙中完成此作时，有一些注意事项。IBMi LPAR 的激活从 IBM PowerServer 硬件管理控制台 （HMC） 进行控制，HMC 为 IBM PowerVM 虚拟化提供虚拟机管理程序功能。在此 HMC 上，每个 LPAR 都至少有一个 LPAR 配置文件，其中包含有关 LPAR 配置的详细信息，即 CPU/MEM、适配器等。当 LPAR 首次被 IPL（IPL = 初始程序加载 = 引导顺序）时，它会从所选配置文件读取配置详细信息。配置文件中有一个特殊选项卡，称为“Tagged I/O”。  标记的 I/O 设置定义了 LPAR 在 B 型 IPL 期间必须在何处搜索负载源 （LS） （= 引导磁盘），以及在何处搜索 D 型 IPL 期间的“备用重新启动设备”（即 DVD 或磁带）。如果 LPAR 首次成功执行 IPL作，则不必再次读取配置文件，因为最后的 IPL 信息存储在虚拟机管理程序上。在下一次 IPL 时，除非再次专门选择了 LPAR 配置文件，否则将使用默认设置“当前配置”。如果在 IPL 之间对 LS 控制器或 LS 磁盘详细信息进行了特定更改，则 LPAR 不会接受更改的 LS 磁盘，并且 IPL 会失败。如果出现以下情况，则会发生这种情况：LPAR 使用“当前配置”选项激活，或者如果标记的 I/O LS 适配器设置为“无”。LS 磁盘序列号的更改是这样的更改，以至于 LPAR 不接受它，并且需要使用选择正确的配置文件进行激活。

下面的屏幕截图显示了选择了有效 LS 适配器的传统 HMC LPAR 概要视图：

下图显示了具有 VIOS 3.x/4.x 的 HMC v10 的现代版本视图中的相同信息。

 

其他有用的信息包含在 PowerMax 和 VMAX 中：无中断和最小中断迁移最佳实践和作指南

======================================================================================

实用的 IBMi NDM 过程：

#NDM (Non Disruptive Migration) procedure for IBMi host environments.
#From VMAX>>>VMAX, VMAX>>>PMAX, PMAX>>>PMAX
#Written: Q4-2021
#Author: Wopke Hoekstra CSA IBMi Global Practice
#Version: 5
==========================================================================================

# Just for reference: PowerMax OS 5978 Levels:

Name        Release Level/Code  
Elm         5978.144.144
Elm SR      5978.221.221
Foxtail     5978.444.444
Foxtail SR  5978.479.479
Hickory     5978.669.669
Hickory SR  5978.711.711
==========================================================================================
#PREREQS:
# MINIMUM Microcode Requirements: Foxtail (NDM IBMi support and NDM METRO-Mode available)
# MINIMUM of 2 RF directors per array are required
# Central external UniSphere/SE (SymCLI) server required with access to the source and target arrays
# MINIMUM SE version of 9.1
====================================================================================================

#Actual Customer Environment where this procedure was used:
# "OLD" VMAX: SN# ckxxxxxxxxx/ckxxxxxxxxx / 5978.479.479
# "NEW" PMAX: SN# ckxxxxxxxxx/ckxxxxxxxxx / 5978.479.479 

============================================================================================================
#Suggested NDM procedure: METRO NDM with Pre-Copy
#Also refer to the DELL EMC PowerMax NDM Whitepaper: Paragraph 3.2.4 / page 120
============================================================================================================

#PROCEDURE: Metro-based NDM with precopy 
#NOTE: (NDM with precopy allows end users to copy application data from the source array to target array while the application is still running on the source array)

#SAN requirements:
#Existing Host FC IOA ports/WWPN's will be used to also zone to the new target array's FA-ports. NO NEED for additional host FC connections.
#NOTE: The NEW array needs to be connected to the same SAN Fabric's as the OLD array.
#For each zone; add the desired target-array's FA-port WWPN into the existing zone (already containing the host initiator WWPN and OLD array FA-port WWPN)
#Or alternatively create new zones with same initiators to the new target-array's FA-ports

#NOTE: For LPAR's using VIOS/VFC(NPIV) connections and when the environment is setup for Live Partition Mobility, the vFC's secondary WWPN will be included in the zoning/masking.
#The secondary WWPN's will not be active and are not in the source array's Login History Table. NDM does not accept inactive WWPN's to be in the IG of the source host, hence the NDM VALIDATE and CREATE commands will fail.
#WORKAROUND: Temporarily remove the secondary WWPN's from the source LPAR IG. After the migration, simply add these secondary WWPN's back into the new IG on the target array. 

#Setup-phase: 
#symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -setup
symdm -sid 008 -tgt_sid 661 environment setup
#NDM RDFGroup will be created.

Now modify the SAN zoning to include the target-array FA-ports.
#NOTE: No devices are presented from the target-array yet.
#NOTE: You can already check if the existing initiator-WWPN's are actively logging in to the new array
symaccess -sid 661 list logins -dirport 1d:4

#To check the environment at any time:
#symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -validate
symdm -src_sid 336 -tgt_sid 662 environment -validate
symdm -src_sid 008 -tgt_sid 661 environment -validate

Other commands to display further details:
symdm -sid 336 -environment list
symcfg -sid 336 list -rdfg all
symcfg -sid 008 list -rdfg all

#NOTE: Take a copy of the source-array's masking database before the activity:
symaccess -sid 336 list view -all -v -detail>masking336_24Nov2021.txt
symaccess -sid 008 list view -all -v -detail>masking008_24Nov2021.txt

#Create Phase (with precopy: (run validation prior to execution))
#This creates an SRDF/Metro session with NDM attributes and puts the SRDF/Metro pair into adaptive copy disk mode. 
#It starts syncing data from R1 to R2. 
#Bias is on the Metro-based NDM source.
#symdm create –src_sid <SN of Source> -tgt_sid <SN of target> -sg <SG to be Migrated> [-tgt_srp <target SRP>] [-tgt_pg <target PG>] -precopy 
#First validate:
symdm create -src_sid 008 -tgt_sid 661 -sg SG_IBMPROD1_1 -precopy -validate
#Then execute:
symdm create -src_sid 008 -tgt_sid 661 -sg SG_IBMPROD1_1 -precopy

#Check NDM status:
#symdm –sid xxx list (-v) (-detail)
#symdm –sid<SN of SRC or TGT> -sg <SG to be Migrated> list –v –pairs_info -detail (shows device pairing)
#symrdf list -sid xxx (-rdfg xxx) (-sg xxx)
#symstat –sid <SRC SN> –rdfg<RDFG of Migration> –type RDF –i xx
symdm -sid 008 list

#ReadyTGT Phase: 
#Moves RDF pair state from adaptive copy mode to Active/Active(in case of witness protection) or Active/Bias (without witness protection).
#Target devices are moved into a read/write mode, It puts the NDM pair in Active/Active or Active/Bias mode
#Masking view is created on the target array using the masking elements created during the create command.
#symdm –sid <SRC or TGT SN> -sg <SG to be Migrated> readytgt
symdm -sid 008 -sg SG_IBMPROD1_1 readytgt

#Check status:
#symdm –sid xxx list (-v) (-detail)
#symrdf list -sid xxx (-rdfg xxx) (-sg xxx)
symdm -sid 008 list

#On the IBMi LPAR, check for new detected FC paths (to the devices on new PowerMax)
#Logon to LPAR, go into System Service Tools: STRSST and go to "work with disks"> "disk configuration"> "9.Disk Paths"
#Let the system discover the paths, this may take a few minutes, just hit F5 to refresh the disk path status screen and verify all disks have the new paths added.

#Commit Phase (this is the actual cutover to the new array):
#symdm –sid <SRC or TGT SN> -sg <SG to be Migrated> commit
symdm -sid 008 -sg SG_IBMPROD1_1 commit

#The masking views will be removed on the old source array.
#On the IBMi LPAR, check for the old paths going into "failed" status (these failing paths are the paths to the old source array)
#Zoning cleanup: Remove the old array's FA-ports from the respective zones for this LPAR.
#Use SST procedure to run MULTIPATH RESETTER macro (this will prevent further error messages being sent to the QSYSOPR MSGQ until the system is IPL-ed)
#After next planned IPL, the path status will be correct again, with only the new active paths listed.

#ONLINE MIGRATION COMPLETED!
============================

#Remove NDM environment (ONLY after last migration is completed):
#symdm -sid xxx -environment -list
#symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -remove
symdm -sid 008 -tgt_sid 661 environment -remove
============================================================================================================

#Reset Device external Identity (un-Spoof) (Optional OFFLINE operation).
#Resetting the target's device external identity back to the original array-based identity of the NEW array (changes the IBMi disk serial number (= Vol.ID + Array-ID))
#THIS REQUIRES A SHUTDOWN OF THE IBMi LPAR!
#Can be done as planned activity when the IBMi LPAR is doing an offline activity, and will be re-IPL-ed... I.e. for full backup, scheduled IPL, etc.

#NOTE: When STM (SRDF/TimeFinder Manager for IBMi) is used on the migrated LPAR, it requires a reconfiguration or as a minimum a DISCOVER command action, due to the changing of the LPAR's disk serial numbers.
#Refer to KB article 193832 for more info and procedure.

只有未掩码的设备才能取消欺骗，因此请先记录并保存当前掩码视图的详细信息，然后删除 MV，取消欺骗，然后重新创建 MV。

symaccess -sid xxx show view -name xxxxxxxx >masking_xxxxxxxx.txt
symaccess -sid xxx delete view -name xxxxxxxx 

显示磁盘身份详细信息：

symdev -sid xxx list -identity_set
symdev -sid xxx list -identity -sg <sg-name>

对于单个设备：

symdev -sid xxx reset -identity -dev xxx -nop

对于一系列设备：

symdev -sid xxx reset -identity -devs xxx:xxx -nop

symaccess -sid xxx create view -name xxxxxxxx -sg xxxxxxxx -pg xxxxxxxx -ig xxxxxxxx 
symdev -sid xxx list -identity -sg <sg-name>

从 IBM HMC 验证在 LPAR 配置文件的“Tagged I/O”选项卡中，LS 控制器是否设置为正确的 FC 适配器。

请勿将“Tagged I/O”LS controller设置留空，并选择“none”。

使用 B-Normal 选项进行 IPL作，并为 IPL 选择 LPAR 配置文件，请勿将其保留为默认选项“current configuration”。

现在，IPL LPAR 并在系统重新联机后，从 SST 验证磁盘序列号。

序列 ID 现在应反映新阵列 symdev ID和阵列序列号。

=== End of Procedure ===