El primer paso de preparación es identificar las LUN que se van a migrar. En el ejemplo que se muestra aquí, hay dos sistemas de archivos basados en SAN montados en /orabin y.. /backups.

El nombre del grupo de volúmenes se puede extraer del nombre del dispositivo, que utiliza el formato (nombre del grupo de volúmenes)-(nombre del volumen lógico). En este caso, se denomina al grupo de volúmenes sanvg.

La pvdisplay El comando se puede utilizar de la siguiente manera para identificar las LUN que admiten este grupo de volúmenes. En este caso, hay 10 LUN que componen el sanvg grupo de volúmenes.

Las LUN de ASM también se deben migrar. Para obtener el número de rutas de LUN y LUN desde sqlplus como usuario sysasm, ejecute el siguiente comando:

El entorno actual contiene 20 LUN que se van a migrar. Actualice la SAN actual para que ONTAP pueda acceder a los LUN actuales. Los datos aún no se han migrado, pero ONTAP debe leer la información de configuración de las LUN actuales para crear el nuevo directorio raíz de los datos.

Como mínimo, se debe configurar al menos un puerto HBA en el sistema AFF/FAS como puerto iniciador. Además, deben actualizarse las zonas de FC para que ONTAP pueda acceder a los LUN en la cabina de almacenamiento externa. Algunas cabinas de almacenamiento tienen configurado el enmascaramiento de LUN, lo que limita los nombres WWN que pueden acceder a una LUN determinada. En tales casos, el enmascaramiento de LUN también debe actualizarse para conceder acceso a los WWN de ONTAP.

Cuando se completa este paso, ONTAP debe poder ver la cabina de almacenamiento externa con el storage array show comando. El campo clave que devuelve es el prefijo que se utiliza para identificar la LUN externa en el sistema. En el siguiente ejemplo, las LUN de la cabina externa FOREIGN_1 Aparece en ONTAP con el prefijo de FOR-1.

Las LUN se pueden enumerar pasando el array-name para la storage disk show comando. Se hace referencia a los datos devueltos varias veces durante el procedimiento de migración.

Las LUN externas inicialmente se clasifican como cualquier tipo de LUN específico. Antes de poder importar los datos, las LUN deben etiquetarse como externas y, por lo tanto, candidatas para el proceso de importación. Este paso se completa pasando el número de serie al storage disk modify command, tal y como se muestra en el siguiente ejemplo. Tenga en cuenta que este proceso solo etiqueta la LUN como externa en ONTAP. No se escriben datos en la propia LUN externa.

Se necesita un volumen para alojar los LUN migrados. La configuración exacta de volúmenes depende del plan general para aprovechar las funciones de ONTAP. En este ejemplo, las LUN de ASM se colocan en un volumen y las LUN de LVM se colocan en un segundo volumen. Esto le permite gestionar las LUN como grupos independientes para fines como organización en niveles, creación de snapshots o configuración de controles de calidad de servicio.

Ajuste la snapshot-policy `to `none. El proceso de migración puede incluir un alto volumen de cambios de datos. Por lo tanto, es posible que se produzca un gran aumento en el consumo de espacio si las instantáneas se crean por accidente porque se capturan datos no deseados en las copias Snapshot.

Después de crear los volúmenes, es necesario crear las nuevas LUN. Normalmente, la creación de una LUN requiere que el usuario especifique dicha información como el tamaño de LUN, pero en este caso el argumento de disco externo se pasa al comando. Como resultado, ONTAP replica los datos de configuración de LUN actuales del número de serie especificado. También utiliza la geometría de la LUN y los datos de la tabla de particiones para ajustar la alineación de la LUN y establecer un rendimiento óptimo.

En este paso, se deben hacer referencias cruzadas de los números de serie a la cabina externa para asegurarse de que la LUN externa correcta coincida con la nueva LUN correcta.

Las LUN ahora se han creado, pero no se configuran como destino de replicación. Antes de poder realizar este paso, las LUN deben colocarse primero sin conexión. Este paso adicional está diseñado para proteger los datos de los errores de los usuarios. Si ONTAP permitiera realizar una migración a una LUN online, supondría el riesgo de que un error tipográfico pudiera provocar la sobrescritura de los datos activos. El paso adicional de obligar al usuario a desconectar primero una LUN ayuda a verificar que se utiliza la LUN de destino correcta como destino de migración.

Después de que las LUN estén sin conexión, puede establecer la relación de importación pasando el número de serie de la LUN externa al lun import create comando.

Una vez establecidas todas las relaciones de importación, las LUN pueden volver a colocarse en línea.

Un igroup forma parte de la arquitectura de enmascaramiento LUN de ONTAP. No es posible acceder a un LUN recién creado a menos que se conceda acceso en primer lugar a un host. Para ello, cree un igroup que enumere los nombres de iniciadores iSCSI o WWN de FC a los que se debe otorgar acceso. Cuando se escribió este informe, FLI solo se admitía para los LUN FC. Sin embargo, la conversión a iSCSI posterior a la migración es una tarea sencilla, como se muestra en la "Conversión de protocolos".

En este ejemplo, se crea un igroup que contiene dos WWN que corresponden a los dos puertos disponibles en el HBA del host.

Después de la creación del igroup, las LUN se asignan al igroup definido. Estos LUN solo están disponibles para los WWN incluidos en este igroup. NetApp asume que en esta etapa del proceso de migración no se ha zonificado el host en ONTAP. Esto es importante porque si se divide en zonas el host simultáneamente en la cabina externa y el nuevo sistema ONTAP, existe el riesgo de que LUN con el mismo número de serie se puedan detectar en cada cabina. Esta situación podría provocar fallos de funcionamiento de varias rutas o daños en los datos.