Notas técnicas - Almacenamiento de datos, infraestructura ... · PDF fileFederated Live...

1

Federated Live Migration

Descripción técnica

Notas técnicas Número de referencia 300-012-013

Rev. A04 Junio de 2011

Este documento de notas técnicas contiene información sobre los siguientes temas:

Resumen ...................................................................................................... 2 Introducción y descripción general ......................................................... 3 Uso de FLM para llevar a cabo una migración ...................................... 5 Storage Area Network (SAN) y zonificación ......................................... 8 Proceso de failback opcional a dispositivos Symmetrix DMX

donantes ...................................................................................................... 9 Reutilización optativa de dispositivos Symmetrix DMX donantes ....... 10 Disponibilidad y presentación ............................................................... 12 Consideraciones y dependencias ........................................................... 12 Principales cambios en Solutions Enabler ............................................ 15 Referencia integral de los comandos ..................................................... 16 Resumen y conclusión ............................................................................. 31

2

Resumen

Descripción técnica de Federated Live Migration Notas técnicas

Resumen

El EMC® Symmetrix VMAX™ con Enginuity™ incorpora un diseño de interconexión de fabric escalable que permite que el arreglo de almacenamiento pase sin dificultades de una configuración de nivel de entrada a un sistema de 2 PB. El Symmetrix® VMAX ofrece un rendimiento predecible de optimización automática y permite que las organizaciones realicen un escalamiento horizontal según la demanda en ambientes de nube privada. Automatiza las operaciones de almacenamiento para superar los requerimientos del negocio en ambientes virtualizados, con herramientas de administración que se integran con servidores virtualizados y reducen el tiempo de administración en infraestructuras de nube privada. Los clientes pueden lograr una disponibilidad “siempre activa” con máxima seguridad, operaciones completamente no disruptivas y migración, recuperación y reinicio de múltiples sites para evitar el tiempo muerto de las aplicaciones.

Enginuity 5875 para el Symmetrix VMAX extiende los beneficios del cliente en las siguientes áreas:

• Más eficiencia: La tecnología sin tiempo muerto se actualiza con Federated Live Migration y reduce los costos mediante la organización en niveles automatizada.

• Más escalabilidad: Ancho de banda del sistema aumentado hasta dos veces, con la posibilidad de administrar hasta 10 veces más de capacidad por administrador de almacenamiento.

• Más seguridad: Cifrado de datos inactivos incorporado

• Mayor compatibilidad con las aplicaciones: Mayor valor para ambientes virtuales de servidor y mainframe, que incluye rendimiento mejorado y aprovisionamiento más rápido para servidores z/OS.

Federated Live Migration ofrece una migración completamente no disruptiva desde el Symmetrix DMX™ a VMAX. FLM realiza esto atando la migración basada en arreglos de los datos, que proporciona EMC Open Replicator para el Symmetrix, con la redirección de la aplicación a nivel de host, proporcionada por EMC PowerPath, Veritas DMP o host MPIO. Esto se realiza mediante el uso de un conjunto de grupos coordinados a través de EMC Symmetrix Management Console o SYMCLI para iniciar la sesión de migración y coordinar la redirección de la aplicación host desde un punto central, lo que hace que la migración sea completamente no disruptiva.

3

Introducción y descripción general


De forma adicional, Federated Live Migration admite un número de agrupamientos de sistemas operativos de arreglos, PowerPath y host que ayudan a eliminar los procesos de corrección que consumen tiempo. Federated Live Migration también es muy flexible; puede admitir combinaciones de migración thick a thick, thick a thin y thin a thin, al igual que múltiples sistemas de consolidación en un Symmetrix.

Público al que está dirigido Este documento de notas técnicas está orientado a cualquier persona que necesite comprender la opción Federated Live Migration (FLM) y su función. Este documento está específicamente destinado al personal técnico de campo de EMC y a los clientes de EMC que planifican una migración de datos o que consideran a Federated Live Migration como la solución de migración.

Información adicional Para obtener información importante y actualizada, se recomienda enfáticamente que se consulte el siguiente recurso antes de continuar con Federated Live Migration (FLM):

• Notas de la versión de Solutions Enabler

• Symmetrix Procedure Generator

Para conocer los procedimientos detallados de soporte de migración, utilizando Federated Live Migration por tipo de host y rutas múltiples, consulte el EMC Symmetrix Procedure Generator.

• Simple Support Matrix

Para obtener información acerca de los sistemas operativos, los sistemas de archivos y los administradores de volúmenes lógicos soportados, consulte EMC Federated Live Migration Simple Support Matrix.

Puede encontrar recursos sobre Powerlink en http://powerlink.emc.com


Federated Live Migration (FLM) permite que un usuario mueva datos de un almacenamiento antiguo al arreglo Enginuity 5875 nuevo sin que los hosts de aplicaciones experimenten tiempo fuera. Esta característica utiliza las funciones existentes del Symmetrix para mover los datos entre los arreglos y EMC PowerPath®, Veritas DMP u otra solución de múltiples rutas para administrar el acceso del host a los datos mientras ocurre la migración. La migración se controla mediante las interfaces de usuario de Solutions Enabler (SE) SYMCLI o de Symmetrix Management Console (SMC).

http://powerlink.emc.com/�

4



Durante su operación, Federated Live Migration (FLM) se encarga de que el dispositivo VMAX nuevo asuma la identidad y la geometría del dispositivo donante Symmetrix DMX y luego realiza una operación Open Replicator (ORS) como el método de movimiento de datos actual entre el arreglo nuevo y el donante. Para que se permita la operación de migración, el dispositivo VMAX nuevo debe ser igual que el dispositivo Symmetrix DMX donante o más grande.

El almacenamiento donante debe ser un Symmetrix y el dispositivo donante no puede involucrarse en ningún tipo de replicación local o remota. Esta limitación es necesaria para garantizar la integridad de los datos en el dispositivo nuevo, ya que una sesión de extracción de Open Replicator no puede copiar datos consistentes si se escriben datos nuevos en el dispositivo donante Symmetrix DMX mientras se ejecuta la sesión.

A continuación se presenta una configuración FLM, incluida la red, los arreglos de discos de almacenamiento, los hosts de aplicaciones y el host Solutions Enabler (SE):

Host SE Hosts de aplicaciones existentes

Zona nueva que conecta los hosts de aplicaciones con el

almacenamiento nuevo

Zona existente que conecta los hosts de aplicaciones con el almacenamiento antiguo

Zona Zona

Zona

Zona nueva que conecta el almacenamiento antiguo con

el nuevo

SAN

5

Uso de FLM para llevar a cabo una migración


La interfaz SYMCLI de Federated Live Migration controla todas las funciones de la migración de datos; sin embargo, no configura automáticamente ninguna de las zonas Fibre Channel de la migración. Esto incluiría las zonas que se extienden desde los hosts de aplicaciones hasta el nuevo arreglo de discos de almacenamiento y desde el arreglo de discos de almacenamiento donante hasta el nuevo arreglo de discos de almacenamiento. Además, una vez finalizada la migración, el usuario podrá programar opcionalmente un horario para que se reinicien los hosts y para deshacer la identidad o la geometría asumida de los dispositivos VMAX nuevos.


A continuación se indica, para ampliar el contexto, la secuencia de comandos de Solutions Enabler SYMCLI para utilizar Federated Live Migration.

Es importante tener en cuenta que esta lista no cubre todos los comandos relacionados con el host que son necesarios para brindar soporte a una migración FLM válida. Para obtener una lista completa de los comandos FLM y de hosts, consulte los ejemplos que se presentan por tipo de sistema operativo al final de esta nota técnica.

PRECAUCIÓN. A menudo las migraciones de datos son operaciones complejas y requieren una planificación cuidadosa y la ejecución de procedimientos predeterminados. Si no se identifican y llevan a cabo los pasos necesarios o el trabajo dentro de las configuraciones soportadas, es posible que se pierdan datos o que ellos no estén disponibles.

NOTA: Para conocer los detalles de los procedimientos de soporte de migración que se utilizan con Federated Live Migration por los tipos host y de múltiples rutas, consulte EMC Symmetrix Procedure Generator disponible en http://powerlink.emc.com.

A continuación se indica la secuencia de comandos básica de una migración FLM:

symrcopy create –migrate –pull

[-frontend_zero]

–file sym1tosym2

[–name sym1_to_sym2]

-host_type WINDOWS|LINUX|AIX|SUNOS_SPARC|HPUX

–hba_type EMULEX|QLOGIC

–mp_type PPATH|PPATH45|DMP


6



Donde sym1tosym2 es un archivo de entrada ORS estándar. La primera columna define los dispositivos VMAX nuevos y la segunda columna define los dispositivos Symmetrix DMX donantes correspondientes. El archivo de entrada ORS acepta tanto la sintaxis symdev como la wwn.

symdev=<symid>:<symdev> symdev=<symid>:<symdev> symdev=<symid>:<symdev> wwn=<symdev_wwn> wwn=<symdev_wwn> symdev=<symid>:<symdev> wwn=<symdev_wwn> wwn=<symdev_wwn> …

Se requiere la opción –pull en un comando create de Federated Live Migration. Una sesión de migración creada correctamente será una sesión ORS de extracción activa con actualización de donante, sin realización de copia. La opción -frontend_zero se utiliza para activar las migraciones thick a thin a un dispositivo, esta opción se puede aplicar para preservar una relación thin a thin existente, o para reclamar espacio durante una migración desde un ambiente provisionado estándar. También puede incluirse la opción –ceiling en un comando migrate create de ORS para controlar la tasa de flujo o para limitar el ancho de banda disponible entre arreglos. La opción –migrate indica que la sesión se tratará como una sesión Federated Live Migration. Una vez creada la sesión con –migrate, se requiere que todos los comandos symrcopy subsiguientes se dirijan a la sesión para garantizar el procesamiento Federated Live Migration. La opción –hba_type opcional identifica el tipo HBA en el host de aplicaciones. Es necesario brindar soporte a las migraciones FLM con -host_type SUNOS_SPARC. La opción -mp_type opcional identifica el proveedor y la versión del software de múltiples rutas del host. Esta opción es necesaria para brindar soporte a las migraciones FLM con -Host_type WINDOWS.

NOTA: Para obtener información acerca de los sistemas operativos, los sistemas de archivos y los administradores de volúmenes lógicos soportados, consulte EMC Federated Live Migration Simple Support Matrix, que se encuentra disponible en http://powerlink.emc.com.


7



Cuando se crea una sesión de migración FLM, se configura el dispositivo VMAX nuevo en modo host_passive y asume el WWN y la geometría del dispositivo Symmetrix DMX donante. En el modo host_passive, el host no puede acceder a un dispositivo que en otras circunstancias estaría listo. FLM utiliza este modo para redireccionar la I/O al arreglo activo durante la migración. La opción –host_type le proporciona a la FLM el contexto del sistema operativo necesario para permitir que la FLM configure correctamente los estados host_passive particulares en el software de múltiples rutas según los requisitos individuales del host.

Es posible que el usuario desee cambiar la geometría del dispositivo VMAX nuevo por la del dispositivo remoto mediante el comando symconfigure antes de ejecutar el comando symrcopy create, pero si no lo hace, el comando create cambiará la geometría automáticamente. Mientras la sesión de migración permanezca activa no podrá cambiarse la geometría con symconfigure.

El comando symrcopy create verificará lo siguiente:

• Que los puertos VMAX nuevos tengan ACLX habilitado.

• Que los dispositivos VMAX nuevos no tengan ya una identidad federada.

• Que los dispositivos VMAX nuevos no estén contenidos en una vista de enmascaramiento de autoaprovisionamiento.

Si no se cumplen las condiciones precedentes, el comando create generará un error.

Si el comando create se realiza correctamente, entonces el usuario se encargará de que el dispositivo VMAX nuevo sea visible para los hosts de aplicaciones de la SAN mediante las funciones de autoaprovisionamiento estándar de Solutions Enabler o SMC. Es importante destacar que si la creación de la sesión FLM generara un error, el sistema quedará en el estado de inicio en el cual se encontraba antes de ejecutar el comando.

symrcopy activate –f sym1tosym2 –migrate

Cuando se activa la sesión FLM, el dispositivo Symmetrix DMX donante pasa a modo host_passive y el dispositivo VMAX nuevo al modo host_active, de modo que los accesos al host se dirigen ahora al dispositivo VMAX nuevo. Cualquier reserva de dispositivos se transfiere del dispositivo Symmetrix DMX donante al dispositivo VMAX nuevo y la sesión ORS pasa al modo de copia. Si el comando activate de FLM generara un error, la sesión permanecerá en el estado en el cual se creó.

8

Storage Area Network (SAN) y zonificación


Una vez que se active correctamente la sesión se copiarán los segmentos del dispositivo Symmetrix DMX donante al dispositivo VMAX nuevo. Si ocurriera un error en algún momento luego de la activación de la sesión, la sesión FLM experimentará automáticamente un proceso de failback. Si se realizara automáticamente un failback en la sesión FLM, el dispositivo VMAX nuevo regresará al modo host_passive y el dispositivo Symmetrix DMX donante regresará al modo host_active, y ello tendrá como resultado que todos los accesos al host vuelvan a dirigirse al arreglo donante. Es necesario el switch –migrate para activar una sesión FLM.

symrcopy query –session_name sym1_to_sym2

(Y/O)

symrcopy verify –f sym1tosym2

Para monitorear la finalización, el usuario puede utilizar el comando symrcopy query o verify hasta que la sesión FLM alcance el estado “Copied” (Copiado).

symrcopy terminate –session_name sym1_to_sym2 –migrate

Cuando se haya completado la transferencia de datos o se haya generado un error, será necesario utilizar el comando terminate con la opción –migrate para terminar la sesión FLM. Esto no afecta el estado de ninguno de los dispositivos involucrados en la sesión FLM, incluida la identidad federada, la geometría, el director/puerto o la configuración del modo host_active/host_passive. Después de terminar una sesión FLM que se haya realizado correctamente, el dispositivo Symmetrix DMX donante permanecerá en el modo host_passive y las reservas permanecerán con el dispositivo VMAX nuevo.

Storage Area Network (SAN) y zonificación

Es la interfaz para que FLM realice toda la migración de datos real, sin embargo, no configura automáticamente ninguna de las zonas de SAN para la migración. Esto incluye las zonas que se extienden desde los hosts de aplicaciones hasta el nuevo arreglo de almacenamiento y desde el arreglo Symmetrix DMX donante hasta el nuevo arreglo VMAX.

Es posible que FLM y Open Replicator necesiten de una actualización de la configuración SAN antes de que se pueda realizar la copia de datos entre los arreglos de almacenamiento. Debido a los distintos tipos de cableado, zonificación y enmascaramiento que pueden existir en una configuración SAN, se proporcionan los siguientes requerimientos como referencia genérica para configurar la migración de datos con FLM y Open Replicator mediante una configuración SAN:

• Se necesita un switch Fibre Channel para FLM y Open Replicator. No se soportan conexiones directas (como un anillo arbitrado).

9

Proceso de failback opcional a dispositivos Symmetrix DMX donantes


• La SAN para arreglos de almacenamiento remoto debe estar conectada a Symmetrix SAN de control. FLM y Open Replicator requieren que al menos un puerto en el arreglo de almacenamiento remoto permita el acceso al dispositivo remoto, de forma que acceda al dispositivo de control mediante al menos un puerto para una copia en frío y todos los puertos para una copia en caliente del arreglo de control.

• La zonificación se debe configurar en el switch Fibre Channel para zonificar los adaptadores de fibra (FA) Symmetrix de control en los adaptadores front-end del arreglo de almacenamiento remoto.

• Dado que el puerto de almacenamiento para los dispositivos de origen está ejecutando el software de administración de configuración (VCM) Volume Logix para Symmetrix, la configuración necesitará de permisos para acceder a los dispositivos objetivos desde el puerto de almacenamiento objetivo, por ejemplo, en Symmetrix, los FA de control deben permitir el acceso a los dispositivos de arreglo de almacenamiento remoto.

El comando SYMCLI, symsan muestra una lista del puerto y de LUN WWN vistos desde un director y un puerto Symmetrix específico. Esto puede se puede utilizar para validar que la zonificación entre el puerto y el objetivo sea correcta. No requiere que se cree una sesión Open Replicator.

Utilice este comando para mostrar el WWN del puerto remoto y LUN WWN visto tras un WWN de puerto remoto:

symsan [-h]

list <-sanports | -sanluns -wwn <SanPort> >

-sid <SymmID> -dir <# | ALL> -port <# | ALL>

[-detail]

Consulte la EMC Solutions Enabler Symmetrix CLI Command Reference para obtener información adicional sobre symsan.

Proceso de failback opcional a dispositivos Symmetrix DMX donantes

Pueden utilizarse los siguientes comandos FLM opcionales para realizar un proceso de failback al dispositivo Symmetrix DMX donante o para restaurar las identidades o los estados del dispositivo VMAX nuevo o bien del dispositivo Symmetrix DMX donante tras la migración. Para obtener más contexto y los pasos adicionales necesarios, consulte los ejemplos que se presentan por tipo de sistema operativo al final de esta nota técnica.

symrcopy failback –session_name sym1_to_sym2 –migrate

10

Reutilización optativa de dispositivos Symmetrix DMX donantes


Si va a cancelarse la migración FLM y se desea un acceso completo de los datos al dispositivo Symmetrix DMX donante, es necesario el comando failback con la opción –migrate. Este comando detendrá la sesión FLM, restaurará el dispositivo Symmetrix DMX donante al modo host_active y restaurará el dispositivo VMAX nuevo al modo host_passive.

El comando failback no afecta el WWN del dispositivo, el director/puerto ni la federación de la geometría de dispositivo del nuevo dispositivo VMAX. Como resultado del comando failback, cualquier reserva de dispositivos existente se restaurará al dispositivo Symmetrix DMX donante. Este comando puede ejecutarse desde cualquier estado en el que la sesión FLM copie activamente datos o cuando la copia haya finalizado. La finalización del comando failback dejará la sesión FLM en estado “FailedBack” y solo podrá realizarse una operación de finalización. Una vez finalizada la sesión FLM no será posible realizar un proceso de failback.


Para reutilizar opcionalmente un dispositivo Symmetrix DMX donante luego de completar la migración FLM, el dispositivo Symmetrix DMX donante y el dispositivo VMAX nuevo no deben resultar visibles con la misma identidad desde ningún host. No deben permanecer en la misma SAN o bien deben utilizarse los comandos de restablecimiento de identidad y de geometría que se describen a continuación para restaurar los dispositivos VMAX nuevos a su identidad nativa. Para obtener más contexto y los pasos adicionales necesarios, consulte los ejemplos que se presentan por tipo de sistema operativo al final de esta nota técnica.

symconfigure commit –f restore_id –sid <SID>

En donde el archivo restore_id contiene una o dos de las opciones siguientes:

SET DEV <symdev>[:<symdev>] IDENTITY = NO IDENTITY; SET DEV <symdev>[:<symdev>] GEOMETRY = NO GEOMETRY;

Es posible restaurar opcionalmente la identidad y la geometría original del dispositivo correspondientes al dispositivo VMAX nuevo cuando haya finalizado la migración FLM. Cuando haya finalizado la sesión de migración FLM, la aplicación del host debe pasar a estar offline o debe apagarse el host de aplicaciones. Luego, para restaurar la identidad y la geometría del dispositivo, los comandos indicados anteriormente configurarán el WWN de su dispositivo con su valor original y restaurarán los valores del director/puerto y de la geometría del dispositivo a su estado original previo a la migración.

11



IMPORTANTE. Actualmente se recomienda ejecutar tanto la operación set identify como la set geometry juntas para restaurar la identidad original del dispositivo VMAX nuevo.

Cuando la aplicación del host vuelva a estar en línea o se reinicie, podrá accederse al dispositivo VMAX nuevo con su identidad original. No se permitirá esta restauración de la identidad y la geometría del dispositivo VMAX nuevo mientras exista la sesión FLM.

Es importante tener en cuenta que no puede establecerse (o quitarse) la identidad y la geometría del dispositivo en los siguientes dispositivos:

• Metamiembro

• Dispositivo vault

• Dispositivo SFS

• Dispositivo de ALMACENAMIENTO

• Dispositivo de DATOS

• DRV

• Dispositivo mapeado

• Dispositivo no FBA

• Dispositivo VCMDB

Para reutilizar opcionalmente el dispositivo Symmetrix DMX donante después de la finalización de la migración FLM, debe volver a ponerse en el modo host_active. Antes de hacerlo, el dispositivo Symmetrix DMX donante y el dispositivo VMAX nuevo no deben estar visibles con la misma identidad desde ningún host. No deben permanecer en la misma SAN o bien deben haberse ejecutado los comandos de restablecimiento de identidad y de geometría descritos anteriormente en el dispositivo VMAX nuevo.

Para poner los dispositivos Symmetrix DMX en host_active, se pueden utilizar los siguientes comandos con Solutions Enabler 7.3 o posterior y el Enginuity 5875 Service Release: symdev –sid <sid> host_active <symdev>

IMPORTANTE. Para instalaciones previas a Solutions Enabler 7.3 y Enginuity 5875 Service Release, póngase en contacto con el Servicio de soporte de EMC para restaurar los dispositivos Symmetrix DMX al modo host_active.

12

Disponibilidad y presentación


Disponibilidad y presentación

Federated Live Migration (FLM) está disponible para los clientes mediante Symmetrix Migrator, un paquete de software que se incluye en forma gratuita con la compra de cada Symmetrix VMAX.

Consideraciones y dependencias

• Para obtener información acerca de los sistemas operativos, los sistemas de archivos y los administradores de volúmenes lógicos soportados, consulte EMC Federated Live Migration Simple Support Matrix, que se encuentra disponible en http://powerlink.emc.com.

• Para conocer los detalles de los procedimientos de soporte de migración que se utilizan con Federated Live Migration por los tipos host y de múltiples rutas, consulte EMC Symmetrix Procedure Generator disponible en http://powerlink.emc.com.

• Es necesario contar con Enginuity 5875 en el Symmetrix VMAX de destino.

• Se necesita Solutions Enabler 7.2 o posterior. • ACLX debe estar habilitado en los puertos que se utilizan para FLM

en el almacenamiento VMAX nuevo. • Se necesita PowerPath 4.5.0 o posterior. Consulte cuál es la última

versión de E-Lab EMC Simple Support Matrix (ESSM) para Federated Live Migration para obtener la información más reciente sobre los ambientes admitidos.

• Esta solución requiere que el almacenamiento de información donante sea Symmetrix con ePack, ya que el estado host_active/host_passive del dispositivo Symmetrix DMX donante debe controlarse mediante Enginuity.

• Actualmente no se soportan reservas SCSI-3 Device, lo que limita las migraciones FLM en ambientes sin clúster. Los hosts independientes admitirán reservas de dispositivos SCSI-2.

• Actualmente, no hay soporte para migraciones FLM para dispositivos de encendido.

• El dispositivo Symmetrix DMX donante está sujeto a las limitaciones ORS normales para un hot pull y no debe involucrarse en ningún tipo de replicación local o remota.

• No se migrarán las sesiones TF/Snap, TF/Clone o SRDF existentes en el dispositivo Symmetrix DMX donante como parte del proceso Federated Live Migration. Luego de la finalización de la migración puede crearse una nueva sesión TimeFinder o SRDF en los volúmenes recientemente migrados.



13



• Si bien se da soporte tanto a los nombres nativos PowerPath como a los pseudodispositivos, se recomienda enfáticamente que se utilicen pseudodispositivos PowerPath con FLM y PowerPath.

• La mayoría de las migraciones incluirá la eliminación del arreglo antiguo; sin embargo, si fuera a utilizarse nuevamente el arreglo antiguo, se recomienda especial y enfáticamente no volver a desplegar el arreglo en la misma SAN ni en los mismos hosts, ni en ningún host que pueda ver el arreglo “nuevo”. En el caso poco habitual de que vuelva a desplegarse el arreglo dentro de la misma SAN, el administrador de almacenamiento deberá cambiar manualmente la identidad nativa/real de los dispositivos Symmetrix VMAX.

NOTA: ésta es una actividad disruptiva, ya que debe detenerse la aplicación antes de quitar la personalidad federada. Luego deberá reiniciarse el host. Después del reinicio, se asigna el nuevo ID de dispositivo nativo a la aplicación.

• Para reutilizar opcionalmente un dispositivo Symmetrix DMX donante después de que la migración FLM haya finalizado, se recomienda actualmente ejecutar tanto la operación set identify como la set geometry juntas en el VMAX nuevo.

• Debe comunicarse con el Servicio de soporte de EMC para restablecer los dispositivos Symmetrix DMX al modo host_active en las instalaciones previas a Solutions Enabler 7.3 y Enginuity 5875 Service Release donde el comando symdev –sid <sid> host_active <symdev> no esté disponible.

• Deben configurarse todos los puertos FA de origen y destino con los mismos parámetros de bits del puerto de director o grupo iniciador que estén disponibles, por host de aplicaciones. Deben configurarse los parámetros de bits del puerto de director o del grupo iniciador según la matriz de soporte de EMC.

• EMC exige que se ejecute cualquier corrección del host que sea necesaria según la matriz de soporte de EMC como parte de la eliminación de la suplantación de identidad para garantizar que el ambiente nativo funcione según la calificación. Cuando se seleccionen los dispositivos de destino para la migración FLM deben tenerse en cuenta las limitaciones de configuración del host de aplicaciones con respecto a la identidad suplantada y a la nativa.

• Por razones tanto de redundancia como de rendimiento, se requieren varias FA para Federated Live Migration (FLM) entre el Symmetrix DMX de origen y el VMAX de destino.

14



• El valor tope recomendado para el arreglo VMAX nuevo debe ser:

o 20% si el arreglo Symmetrix DMX donante ejecuta Enginuity 5671.

o 40% si el arreglo Symmetrix DMX donante ejecuta Enginuity 5773.

• Al elegir los puertos de director que se utilizarán para la conectividad Symmetrix a Symmetrix, los puertos que se utilicen en cada arreglo no deben estar en el mismo director local. Por ejemplo, no se admitiría el uso de los puertos 8aA y 8aB en el arreglo de origen y de los puertos 15eA y 15eB en el arreglo de destino porque existen los puertos A y B en los mismos directores locales (8a en el Symmetrix de origen y 15e Symmetrix de destino). Sin embargo, se admite el uso del 8aA y el 9aA en el arreglo de origen y del 15eA y el 16eA en el arreglo de destino, y ésta es la forma correcta de configurar la conectividad para FLM.

• No se admiten dispositivos BCV como dispositivos de origen de Federated Live Migration (FLM) para AIX. Los dispositivos remotos no tienen el mismo tipo RAID o metaconfiguración. Para operaciones de ingreso, la capacidad remota debe ser igual o mayor que las extensiones del dispositivo de control y viceversa para una operación de extracción. Una excepción para esto surge cuando los datos se han enviado a un dispositivo remoto que es mayor que el dispositivo de control y los datos deben enviarse de vuelta al dispositivo de control. En este caso, utilice la opción -force_copy.

• En operaciones de extracción desde los dispositivos con reservas SCSI, si los dispositivos remotos tienen un clúster funcionando en contra de ellos o los dispositivos son AIX LVM, el clúster, AIX host u otro software que esté creando las reservas SCSI deben apagarse antes de crear una sesión Open Replicator.

• Sólo se puede activar una sesión de copia por dispositivo de control a la vez. La sesión activa se debe completar o finalizar antes de que se pueda crear o iniciar otra sesión en el dispositivo.

• Una sesión Open Replicator está entre dos arreglos y no se puede crear con dispositivos de control y remotos en el mismo arreglo Symmetrix. La copia dentro del mismo arreglo Symmetrix se debe realizar, utilizando las operaciones de control SYMCLI, como TimeFinder®/Snap y Clone.

• Open Replicator sólo se puede utilizar con dispositivos FBA mediante directores integrados Fibre Channel. No se soportan los siguientes tipos de dispositivos, que pueden mapearse al host: CKD, VCM, WORM y metamiembros.

15

Principales cambios en Solutions Enabler


• Federated Live Migration (FLM) soporta un máximo de 32 pares de dispositivos por host al mismo tiempo.

• La cantidad máxima de sesiones activas permitida es 1024 cuando se ejecuta Enginuity versión 5773 o superior. El ajuste predeterminado en Enginuity versión 5773 o superior es de 1024.

Principales cambios en Solutions Enabler

Se han mejorado los comandos SYMCLI symrcopy, symconfigure y symdev para que brinden soporte a la función Federated Live Migration.

Se ha cambiado el comando symrcopy para que acepte la nueva opción -migrate, que se utiliza como indicación de una operación Federated Live Migration, y para que acepte un nuevo comando de failback para las sesiones Federated Live Migration. Las sesiones Federated Live Migration son operaciones de extracción activa. Debe incluirse la opción –pull y las opciones –migrate al comando symrcopy create para que indiquen una sesión Federated Live Migration.

Debe incluirse la opción –migrate en todos los comandos symrcopy activate, terminate, failback y set ceiling posteriores que se relacionen con las sesiones Federated Live Migration. La opción –host_type le proporciona a la FLM el contexto del sistema operativo necesario para permitir que la FLM configure correctamente los estados host_active y host_passive particulares en el software de múltiples rutas, según los requisitos individuales del host.

La opción –hba_type opcional identifica el tipo HBA en el host de aplicaciones. Es posible que sea necesaria para brindar soporte a las migraciones FLM con valores específicos en la opción -host_type. La opción -mp_type opcional identifica el proveedor y la versión del software de múltiples rutas del host. Esta opción quizás resulte también necesaria cuando la opción -host_type tenga valores específicos.

Si se especifica la opción –migrate para cualquier otro comando symrcopy o para un comando activate, terminate o set pace en una sesión creada sin –migrate, entonces se la rechazará.

El nuevo comando symrcopy failback detendrá la sesión e indicará que el dispositivo Symmetrix DMX donante ha regresado al modo host_active y que el dispositivo VMAX nuevo ha regresado al modo host_passive en el que estaban después de la creación de la sesión. Este comando no afecta el WWN del dispositivo, el director/puerto ni la suplantación de la geometría de dispositivo del dispositivo VMAX nuevo.

16

Referencia integral de los comandos


Como resultado del comando failback, cualquier reserva de dispositivos existente se restaurará al dispositivo Symmetrix DMX donante. Este comando puede ejecutarse desde cualquier estado en el que la sesión copie activamente datos o cuando la copia haya finalizado. Cuando se ejecute este comando la sesión quedará en estado “FailedBack”, luego de lo cual la única operación posterior permitida será un comando terminate.

Se ha modificado el comando symrcopy list para que acepte una opción –type optativa, que indicará si el usuario desea ver solamente las sesiones Federated Live Migration o sólo las sesiones estándar que no sean Federated Live Migration. Los resultados de los comandos symrcopy query y list también se modificarán para que indiquen las sesiones de migración.

Se ha modificado el comando symrcopy verify para que acepte el nuevo estado: FailedBack.


La lista integral de comandos, opciones y resultados SYMCLI de Solutions Enabler que se encuentra a continuación ofrece una referencia detallada que lo ayudará a identificar los cambios que se realizaron para dar soporte a Federated Live Migration.

symrcopy <-file <FileName> [-noprompt] | -noprompt 'redirect stdin'> [-star] [-i <Interval>] [-c <Count>] create -pull -migrate -host_type <OStype> [-hba_type <HBAType>] [-mp_type <MPtype>] [-name <SessionName>] [-pace <Pace>] activate [-vxfs <MountPoint...>] | [-rdb -dbtype <DbType> [-db <DbName>]] | [-consistent] | [-migrate] failback -migrate set pace <Pace> [-migrate] set frontend_zero off [-migrate] terminate [-symforce] [-all_sessions | -migrate] symrcopy [-sid SymmID] [-i <Interval>] [-c <Count>] list [-offline] [-detail | -wwn]

17



[-type <migrate | standard>] verify [-star] | [-summary] [-createinprog | -created | -recreateinprog | -recreated | -copyinprog | -copyonaccess | -copyonwrite | -copied | -terminateinprog | -failed | -verifyinprog | -restored | -restinprog | -precopy [-cycled] | -syncinprog | -synchronized | -failedback]

NOTA: cuando se ejecuta el comando symrcopy list sin una opción –type, el comportamiento predeterminado es incluir todas las sesiones ORS en el resultado.

El comando symrcopy list con la opción –type filtrará el resultado según los tipos de sesiones especificados.

symrcopy list –sid 307 –type migrate

Symmetrix ID: 000194900307 Control Device Remote Device Flags Status Done --------------- ----------------------------------- ------- -------------- ---- Protected Sym Tracks Identification RI CDSHUTZ CTL <=> REM (%) ----- --------- -------------------------------- -- ------- -------------- ---- 0150 138090 000190100860:024A SD ...XXM. Created N/A Total --------- Tracks 138090 MB(s) 8630.6 Legend: R: (Remote Device Vendor Identification) S = Symmetrix, C = Clariion, . = Unknown. I: (Remote Device Specification Identifier) D = Device Name, W = LUN WWN, World Wide Name. Flags: (C): X = The background copy setting is active for this pair. . = The background copy setting is not active for this pair. (D): X = The session is a differential copy session. . = The session is not a differential copy session. (S): X = The session is pushing data to the remote device(s). . = The session is pulling data from the remote device(s). (H): X = The session is a hot copy session. . = The session is a cold copy session. (U): X = The session has donor update enabled. . = The session does not have donor update enabled. (T): M = The session is a migration session.

18



S = The session is a standard ORS session. (Z): X = The session has front-end zero detection enabled. . = The session does not have front-end zero detection enabled. (*): The failed session can be reactivated.

symrcopy query

El comando symrcopy query generará un resultado modificado para indicar las sesiones de migración según lo señalan los cambios en negrita que se encuentran a continuación:

symrcopy query –f query_test

Device File Name : query_test Control Device Remote Device Flags Status Done ---------------------------- ----------------------------------- ------- -------------- ---- Protected SID:symdev Tracks Identification RI CDSHUTZ CTL <=> REM (%) ------------------ --------- -------------------------------- -- ------- -------------- ---- 000194900307:0150 138090 000190100860:024A SD ...XXM. Created N/A Total --------- Track(s) 138090 MB(s) 8630.6 Legend: R: (Remote Device Vendor Identification) S = Symmetrix, C = Clariion, . = Unknown. I: (Remote Device Specification Identifier) D = Device Name, W = LUN WWN, World Wide Name. Flags: (C): X = The background copy setting is active for this pair. . = The background copy setting is not active for this pair. (D): X = The session is a differential copy session. . = The session is not a differential copy session. (S): X = The session is pushing data to the remote device(s). . = The session is pulling data from the remote device(s). (H): X = The session is a hot copy session. . = The session is a cold copy session. (U): X = The session has donor update enabled. . = The session does not have donor update enabled. (T): M = The session is a migration session. S = The session is a standard ORS session. (Z): X = The session has front-end zero detection enabled. . = The session does not have front-end zero detection enabled. (*): The failed session can be reactivated.

19



symrcopy query -summary

El resultado del comando symrcopy query –summary incluye ahora una línea para las sesiones en estado FailedBack. Por ejemplo:

symrcopy query -f query_test –summary

Device File Name : query_test RCopy Session State Count ----------------------- ------ CreateInProg 0 Created 0 RecreateInProg 0 Recreated 0 CopyInProg 2 CopyOnAccess 0 CopyOnWrite 0 Copied 0 Restored 0 RestInProg 0 Precopy 0 TerminateInProg 0 Failed 0 FailedBack 0 VerifyInProg 0 ----------------------- ------ Total 2 Track(s) MB(s) ----------- ------- Total Protected 32333 2020.8

symrcopy query –output xml

se ha modificado el resultado XML del comando symrcopy query para que genere un resultado que indique las sesiones de migración según lo señalan los cambios en negrita que se encuentran a continuación. El nuevo valor session_type será Migrate para las sesiones Federated Live Migration y Standard para las sesiones que no sean Federated Live Migration.

symrcopy query –f query_test –output xml

<SymCLI_ML> <RCopy> <file>/tmp/query_test</file> <Session>

20



<state>Created</state> <percent_done>N/A</percent_done> <protected_tracks>33000</protected_tracks> <Control> <symid>000192600306</symid> <dev_name>01B2</dev_name> </Control> <Flags> <backgrnd_copy>False</backgrnd_copy> <differential>False</differential> <pull_data>True</pull_data> <hot_copy>True</hot_copy> <donor_update>True</donor_update> <session_type>Migrate</session_type> </Flags> </Session> </RCopy> <RCopy_Totals> <src_protected_tracks>33000</src_protected_tracks> <src_protected_tracks_mb>2062.5</src_protected_tracks_mb> </RCopy_Totals> </SymCLI_ML>

symrcopy list –output xml

Se ha modificado la versión del resultado XML del comando symrcopy list para que genere un resultado que indique las sesiones de migración según lo señalan los cambios en negrita que se encuentran a continuación.

symrcopy list -sid 000192600306 –output xml

<SymCLI_ML> <Symmetrix> <Symm_Info> <symid>000192600306</symid> </Symm_Info> <RCopy> <Session> <state>Created</state> <percent_done>N/A</percent_done> <protected_tracks>33000</protected_tracks> <Control> <symid>000192600306</symid> <dev_name>01B2</dev_name> </Control>

21



<Flags> <backgrnd_copy>False</backgrnd_copy> <differential>False</differential> <pull_data>True</pull_data> <hot_copy>True</hot_copy> <donor_update>True</donor_update> <session_type>Migrate</session_type> </Flags> </Session> </RCopy> <RCopy_Totals> <protected_tracks>33000</protected_tracks> <protected_tracks_mb>2062.5</protected_tracks_mb> </RCopy_Totals> </Symmetrix> </SymCLI_ML>

symrcopy query –summary –output xml

Se ha actualizado el resultado XML para que se adecue a la -opción summary. El contenido de la sección de la etiqueta <RCopy_Totals>, cuando se especifica –summary, se ha modificado para que incluya synchronization_rate y synchronization_rate_units.

NOTA: con la opción –summary, se muestran las etiquetas <synchronization_rate>, <synchronization_rate_units> y <estimated_time_to_completion> sólo cuando se cumplen las dos condiciones siguientes:

• Se especifica al menos una de las siguientes opciones: -i o -c.

• Ha ocurrido un cambio en los conteos de seguimiento protegidos desde la repetición anterior.

A continuación se presenta la segunda repetición del resultado XML a partir de symrcopy query- summary.

symrcopy query -f query_test -summary -output xml

<Device> <Device_Info> <name>query_test</name> </Device_Info> <RCopy_State> <state>CreateInProg</state> <count>0</count> </RCopy_State>

22



<RCopy_State> <state>Created</state> <count>0</count> </RCopy_State> <RCopy_State> <state>RecreateInProg</state> <count>0</count> </RCopy_State> <RCopy_State> <state>Recreated</state> <count>0</count> </RCopy_State> <RCopy_State> <state>CopyInProg</state> <count>2</count> </RCopy_State> <RCopy_State> <state>CopyOnAccess</state> <count>0</count> </RCopy_State> <RCopy_State> <state>CopyOnWrite</state> <count>0</count> </RCopy_State> <RCopy_State> <state>Copied</state> <count>0</count> </RCopy_State> <RCopy_State> <state>Restored</state> <count>0</count> </RCopy_State> <RCopy_State> <state>RestInProg</state> <count>0</count> </RCopy_State> <RCopy_State> <state>Precopy</state> <count>0</count> </RCopy_State> <RCopy_State> <state>TerminateInProg</state> <count>0</count> </RCopy_State> <RCopy_State> <state>Failed</state> <count>0</count> </RCopy_State> <RCopy_State> <state>FailedBack</state> <count>0</count> </RCopy_State> <RCopy_State>

23



<state>VerifyInProg</state> <count>0</count> </RCopy_State> <RCopy_State_Totals> <count>2</count> </RCopy_State_Totals> <RCopy_Totals> <protected_tracks>25718</protected_tracks> <protected_mbs>1607.4</protected_mbs> <synchronization_rate>13.9</synchronization_rate> <synchronization_rate_units>MB/S</synchronization_rate_units> <estimated_time_to_completion>0 days, 00:01:55</estimated_time_to_completion> </RCopy_Totals> </Device>

symconfigure

Se ha modificado la función symconfigure para que permita la restauración de la identidad de un dispositivo a su valor original.

Durante una sesión Federated Live Migration la identidad externa del dispositivo VMAX nuevo se configura como la del dispositivo remoto, el dispositivo remoto se configura en modo host_passive y el dispositivo VMAX nuevo se configura en modo host_active, de forma que el dispositivo VMAX nuevo reciba todas las solicitudes de acceso a operaciones de lectura y escritura. Una vez finalizada la sesión Federated Live Migration, puede utilizarse symconfigure para restaurar la identidad original del dispositivo VMAX nuevo del siguiente modo:

symconfigure commit –sid <SymmID> -file reset_id

En donde reset_id contiene: “set dev <SymDevName> identity=NO identity;”.

Establecimiento del atributo de un dispositivo:

set dev SymDevName[:SymDevName] attribute = [NO ]<device_attr>; set dev SymDevName[:SymDevName] identity = NO identity;

24



symdev

Se han modificado los comandos symdev show y list para que soporte la información del dispositivo externo nuevo. symdev show mostrará, en forma predeterminada, la información del dispositivo externo. symdev list acepta una nueva opción que permite la selección de dispositivos cuya identidad externa se haya modificado durante una operación Federated Live Migration y una opción adicional para seleccionar dispositivos que estén configurados actualmente en modo host_passive.

También pueden restaurarse los modos de acceso al host de los dispositivos de control luego de la sesión Federated Live Migration con el comando symdev.

symdev [-sid SymmID] [-offline] [-cyl] [-geometry | -identity] show SymDevName symdev [-sid SymmID] [-offline] [-v] [-resv] [-wwn] [-all] list [ -FA <#|ALL> [-P #] | … [-geometry_set] [-identity_set] [-host_passive] [-identity [-detail]] … [-tdev [-bound | -unbound]] [-datadev [-nonpooled]]

symdev show

Se ha modificado el resultado del comando symdev show para que permita ver la identidad externa de dispositivos que se hayan virtualizado durante una operación de migración.

symdev –sid 207 show 0477

Device Physical Name : Not Visible Device Symmetrix Name : 0477 Device Serial ID : N/A Symmetrix ID : 000192600207 Number of RAID Groups : 1 Attached BCV Device : N/A Attached VDEV TGT Device : N/A Vendor ID : EMC Product ID : SYMMETRIX Product Revision : 5825 Device WWN : 60000970000192600207533030343737 Device Emulation Type : FBA

25



Device Defined Label Type: N/A Device Defined Label : N/A Device Sub System Id : 0x0001 Cache Partition Name : DEFAULT_PARTITION Device Block Size : 512 Device Capacity { Cylinders : 960 Tracks : 14400 512-byte Blocks : 1843200 MegaBytes : 900 KiloBytes : 921600 } Effective Device Information { Device WWN : 60000970000192600306533030313732 Front Director Paths (1): { ----------------------------------- DIRECTOR PORT LUN ---------- ---- -------- --------- Type Num Sts VBUS TID SYMM Host ----------------------------------- N/A 07E:3 RW 000 00 247 N/A N/A 07F:3 RW 000 00 247 N/A } Geometry: User Defined { Sectors/Track : 64 Tracks/Cylinder : 15 Cylinders : 200 512-byte Blocks : 192000 MegaBytes : 94 KiloBytes : 96000 } } Device Configuration : Unprotected Device is WORM Enabled : No Device is WORM Protected : No SCSI-3 Persistent Reserve: Disabled Dynamic Spare Invoked : No Dynamic RDF Capability : RDF1_OR_RDF2_Capable STAR Mode : No STAR Recovery Capability : None STAR Recovery State : NA Device Service State : Normal Device Status : Ready (RW)

26



Device SA Status : N/A (N/A) Host Access Mode : Active Front Director Paths (1): { ---------------------------------------------------------------------- POWERPATH DIRECTOR PORT LUN --------- ---------- ---- -------- --------- PdevName Type Type Num Sts VBUS TID SYMM Host ---------------------------------------------------------------------- Not Visible N/A FA 07E:1 RW 000 00 247 N/A Not Visible N/A FA 07F:1 RW 000 00 247 N/A } . . . Remote Copy Device Information { Remote Copy Session Name : N/A Session State : Created Pull : True Offline Copy : False Differential Copy : Disabled Background Copy : Disabled Incremental Copy : False Donor Update : True Federated Live Migration : True Starting Block : 0 Total Blocks : 192000 Percent Copied : N/A Remote Devices [1] { --------------------------------------------------------------------- Array:Dev WWN Starting Block --------------------- -------------------------------- -------------- 000187990007:012E 60000970000192600306533030313732 0 } }

symdev –identity_set list

El resultado del comando symdev list, cuando se utilice junto con el switch –identity_set, contendrá los dispositivos cuya identidad efectiva se haya modificado durante la operación de migración.

symdev -sid 207 –identity_set list

Symmetrix ID: 000192600207 Device Name Directors Device --------------------------- ------------- ------------------------------------- Cap Sym Physical SA :P DA :IT Config Attribute Sts (MB) --------------------------- ------------- ------------------------------------- 0477 /dev/sddv ***:* 06E:C1 2-Way Mir N/Grp'd (M) RW 2063

27



symdev –identity list

El resultado del comando symdev list, cuando se utilice junto con el switch –identity, contendrá todos los dispositivos y la identidad externa de los dispositivos. Si no se hubiera configurado ninguna identidad externa, este resultado informará la identidad nativa. Puede filtrarse este resultado con el switch –identity_set.

symdev -sid 207 –identity –identity_set list

symdev -sid 307 list -identity -identity_set Symmetrix ID: 000194900307 Device FLG External Identity ---------------------------------- --- ---------------------------------------- Sym Physical Config Sts IG Array ID Num Ser Num Cap (MB) ---------------------------------- --- ---------------------------------------- 0150 Not Visible 2-Way Mir RW X. 000190100860 0024A 600024A000 8631 Legend: Flags: (I)dentity : X = The device has a non-native external identity set . = The device does not have an external identity set (G)eometry : X = The device has a user defined geometry . = The device does not have a user defined geometry

Se puede expandir más el switch –identity con el switch –detail para que muestre el wwn del dispositivo externo.

symdev -sid 207 –identity –detail –identity_set list

Symmetrix ID: 000194900307 Device FLG External Identity ---------------------------------- --- ------------------------------------------------------------------------- Sym Physical Config Sts IG Array ID Num Ser Num Cap (MB) WWN ---------------------------------- --- ------------------------------------------------------------------------- 0150 Not Visible 2-Way Mir RW X. 000190100860 0024A 600024A000 8631 60060480000190100860533030323441 Legend: Flags: (I)dentity : X = The device has a non-native external identity set . = The device does not have an external identity set (G)eometry : X = The device has a user defined geometry . = The device does not have a user defined geometry

28



symdev –output xml show

Se ha modificado la versión del resultado XML del comando symdev show para que genere un resultado que indique las sesiones de migración según lo señalan los cambios en negrita que se encuentran a continuación.

symdev –sid 207 –output xml show 0477

<SymCLI_ML> <Symmetrix> <Symm_Info> <symid>000192600207</symid> </Symm_Info> <Device> <Dev_Info> <pd_name>Not Visible</pd_name> <dev_name>0477</dev_name> <configuration>Unprotected</configuration> <number_of_raid_groups>1</number_of_raid_groups> <attached_bcv>N/A</attached_bcv> <emulation>FBA</emulation> <status>Ready</status> <sa_status>N/A</sa_status> <service_state>Normal</service_state> <ssid>0x0001</ssid> <cache_partition_name>DEFAULT_PARTITION</cache_partition_name> <host_access_mode>Active</host_access_mode> </Dev_Info> <Attached> <BCV>N/A</BCV> <VDEV>N/A</VDEV> </Attached> <Product> <vendor>EMC</vendor> <name>SYMMETRIX</name> <revision>5874</revision> <serial_id>N/A</serial_id> <symid>000192600207</symid> <wwn>60000970000192600207533030343737</wwn> </Product> <Label> <type>N/A</type> <defined_label>N/A</defined_label> </Label> <Flags> <ckd>False</ckd> <worm_enabled>False</worm_enabled> <worm_protected>False</worm_protected> <dynamic_spare_invoked>False</dynamic_spare_invoked> <dynamic_rdf_capability>None</dynamic_rdf_capability> <star_mode>False</star_mode>

29



<star_recovery_capability>None</star_recovery_capability> <star_recovery_state>N/A</star_recovery_state> <radiant_managed>False</radiant_managed> <restricted_access_dev>False</restricted_access_dev> <rdb_checksum_enabled>False</rdb_checksum_enabled> <non_exclusive_access>False</non_exclusive_access> <scsi3_persist_res>Disabled</scsi3_persist_res> <aclx>False</aclx> <symmetrix_filesystem>False</symmetrix_filesystem> <snap_save_device>False</snap_save_device> <gatekeeper>False</gatekeeper> <datadev>False</datadev> <meta>None</meta> </Flags> <Capacity> <block_size>512</block_size> <cylinders>960</cylinders> <tracks>14400</tracks> <blocks>1843200</blocks> <megabytes>900</megabytes> <kilobytes>921600</kilobytes> </Capacity> <Effective_device_info> <wwn>60000970000192600306533030313732</wwn> <Front_End> <Port> <director>07E</director> <director_type>N/A</director_type> <powerpath_type>N/A</powerpath_type> <port>5</port> <port_status>Ready</port_status> <vbus>0</vbus> <tid>0</tid> <lun>247</lun> <host_lun>N/A</host_lun> </Port> <Port> <director>07F</director> <director_type>N/A</director_type> <powerpath_type>N/A</powerpath_type> <port>5</port> <port_status>Ready</port_status> <vbus>0</vbus> <tid>0</tid> <lun>247</lun> <host_lun>N/A</host_lun> </Port> </Front_End> <device_geometry> <geometry_type>User Defined</geometry_type> <sectors_per_tracks>64</sectors_per_tracks> <tracks_per_cylinder>15</tracks_per_cylinder> <cylinders>200</cylinders>

30



<blocks>192000</blocks> <megabytes>94</megabytes> <kilobytes>96000</kilobytes> </device_geometry> </Effective_device_info> <Front_End> <Port> <pd_name>Not Visible</pd_name> <director>07E</director> <director_type>FibreChannel</director_type> <powerpath_type>N/A</powerpath_type> <port>1</port> <port_status>Ready</port_status> <vbus>0</vbus> <tid>0</tid> <lun>247</lun> <host_lun>N/A</host_lun> </Port> <Port> <pd_name>Not Visible</pd_name> <director>07F</director> <director_type>FibreChannel</director_type> <powerpath_type>N/A</powerpath_type> <port>1</port> <port_status>Ready</port_status> <vbus>0</vbus> <tid>0</tid> <lun>247</lun> <host_lun>N/A</host_lun> </Port> </Front_End> . . . <RCopy_Device> <session_name>N/A</session_name> <state>Created</state> <pull>True</pull> <offline_copy>False</offline_copy> <differential_copy>Disabled</differential_copy> <background_copy>Disabled</background_copy> <incremental_copy>False</incremental_copy> <donor_update>True</donor_update> <session_type>Migrate</session_type> <start_block>0</start_block> <total_blocks>192000</total_blocks> <percent_copied>N/A</percent_copied> <Remote> <num_devs>1</num_devs> <symid>000187990007</symid> <dev_name>012E</dev_name> <wwn>60000970000192600306533030313732</wwn> <start_block>0</start_block> </Remote> </RCopy_Device>

31

Resumen y conclusión


El comando symdev list con la opción –identity_set permite la selección de dispositivos cuya identidad se haya modificado durante una operación de migración. La versión del resultado XML de este comando mostrará siempre el wwn externo del dispositivo, incluso sin la opción -detail.

symdev –identity –identity_set –output xml list

<?xml version="1.0" standalone="yes" ?> <SymCLI_ML> <Symmetrix> <Symm_Info> <symid>000194900307</symid> </Symm_Info> <Device> <Dev_Info> <dev_name>0150</dev_name> <pd_name>Not Visible</pd_name> <configuration>2-Way Mir</configuration> <status>Ready</status> </Dev_Info> <Flags> <external_identity_set>True</external_identity_set> <user_defined_geometry>False</user_defined_geometry> </Flags> <Capacity> <megabytes>8631</megabytes> </Capacity> <External_Identity> <wwn>60060480000190100860533030323441</wwn> <array_id>000190100860</array_id> <dev_name>024A</dev_name> <serial_number>600024A000</serial_number> </External_Identity> </Device> </Symmetrix> </SymCLI_ML>


El EMC Symmetrix VMAX con Enginuity incorpora un diseño de interconexión de fabric escalable que permite que el arreglo de discos de almacenamiento pase sin dificultades de una configuración de nivel de entrada a un sistema de 2 PB. Symmetrix VMAX ofrece un rendimiento predecible de optimización automática y permite que las organizaciones realicen un escalamiento horizontal según la demanda en ambientes de nube privada. Automatiza las operaciones de almacenamiento para superar los requerimientos del negocio en ambientes virtualizados, con herramientas de administración que se integran con servidores virtualizados y reducen el tiempo de administración en infraestructuras de nube privada. Los clientes pueden lograr una disponibilidad “siempre activa” con máxima seguridad, operaciones completamente no disruptivas y migración, recuperación y reinicio de múltiples sites para evitar el tiempo muerto de las aplicaciones.

32



Enginuity 5875 para el Symmetrix VMAX extiende los beneficios del cliente en las siguientes áreas:

• Más eficiencia: La tecnología sin tiempo muerto se actualiza con Federated Live Migration y reduce los costos mediante la organización en niveles automatizada.

• Más escalabilidad: ancho de banda del sistema aumentado hasta dos veces, con la posibilidad de administrar hasta 10 veces más de capacidad por administrador de almacenamiento.

• Más seguridad: encriptación de datos inactivos incorporada.

• Mayor compatibilidad con las aplicaciones: Mayor valor para ambientes virtuales de servidor y mainframe, que incluye rendimiento mejorado y aprovisionamiento más rápido para servidores z/OS.

Federated Live Migration entrega una migración de Symmetrix DMX a VMAX totalmente no disruptiva. FLM realiza esto atando la migración basada en arreglos de los datos, que proporciona EMC Open Replicator para Symmetrix, con la redirección de la aplicación a nivel de host, proporcionada por EMC PowerPath, Veritas DMP o host MPIO. Esto se realiza mediante el uso de un conjunto de grupos coordinados a través de EMC Symmetrix Management Console o SYMCLI para iniciar la sesión de migración y coordinar la redirección de la aplicación host desde un punto central, lo que hace que la migración sea completamente no disruptiva.

De forma adicional, Federated Live Migration admite un número de agrupamientos de sistemas operativos de arreglos de datos, múltiples rutas y host operativos que ayudan a eliminar los procesos de corrección que consumen tiempo. Federated Live Migration también es muy flexible; puede admitir combinaciones de migración thick a thick, thick a thin y thin a thin, al igual que múltiples sistemas de consolidación en un Symmetrix.

33



Copyright © 2011 EMC Corporation. Todos los derechos reservados.

EMC considera que la información de esta publicación es precisa en el momento de su publicación. La información está sujeta a cambios sin previo aviso.

LA INFORMACIÓN DE ESTA PUBLICACIÓN SE PROPORCIONA "TAL CUAL". EMC CORPORATION NO SE HACE RESPONSABLE NI OFRECE GARANTÍA DE NINGÚN TIPO CON RESPECTO A LA INFORMACIÓN DE ESTA PUBLICACIÓN Y, ESPECÍFICAMENTE, RENUNCIA A TODA GARANTÍA IMPLÍCITA DE COMERCIABILIDAD O CAPACIDAD PARA UN PROPÓSITO DETERMINADO.

El uso, la copia y la distribución de todo software de EMC descrito en esta publicación requiere una licencia de software correspondiente.

Para obtener una lista actualizada de nombres de productos de EMC, consulte las marcas comerciales de EMC Corporation en EMC.com (visite el sitio web de su país correspondiente).

Todas las otras marcas comerciales que aparecen aquí son propiedad de sus respectivos dueños.

Notas técnicas - Almacenamiento de datos, infraestructura ... · PDF fileFederated Live...

Documents

Transcript of Notas técnicas - Almacenamiento de datos, infraestructura ... · PDF fileFederated Live...