Descripción de migración shadow

La migración shadow utiliza la interposición, pero está integrada al dispositivo y no requiere una máquina física aparte. Cuando se generan recursos compartidos, existe la opción de realizar una migración "shadow" de un directorio existente, ya sea de manera local o mediante NFS. En este caso, el tiempo de inactividad se programa una vez, donde el dispositivo de origen X se coloca en modo de solo lectura, se genera un recurso compartido con la propiedad shadow configurada, y los clientes se actualizan para apuntar al nuevo recurso compartido de Oracle ZFS Storage Appliance. A continuación, los clientes pueden acceder al dispositivo en modo lectura y escritura.

Figura 5-11  Migración shadow

Una vez que está configurada la propiedad shadow, los datos se migran de manera transparente en segundo plano desde el dispositivo de origen de manera local. Si una solicitud proviene de un cliente para un archivo que aún no se ha migrado, el dispositivo migrará automáticamente este archivo al servidor local antes de responder la solicitud. Esto puede generar latencia inicial en algunas solicitudes de clientes, pero una vez que se haya migrado un archivo, todos los accesos serán locales para el dispositivo y tendrán rendimiento nativo. A menudo sucede que el conjunto de trabajo actual para un sistema de archivos es mucho más pequeño que el tamaño total; por lo tanto, una vez que se ha migrado este conjunto de trabajo, no se percibirán cambios en el rendimiento, independientemente del tamaño nativo total en el origen.

La desventaja de la migración shadow es que requiere una confirmación antes de que finalice la migración de datos, aunque esto sucede con cualquier método de interposición. Durante la migración, partes de los datos se encuentran en dos ubicaciones, lo que significa que las copias de seguridad son más complicadas y las instantáneas pueden estar incompletas o existir solo en un host. Por lo tanto, es extremadamente importante que antes de realizar cualquier migración entre dos hosts esta se pruebe cuidadosamente, para asegurarse de que la gestión de identidad y los controles de acceso estén configurados correctamente. Para esto no es necesario probar toda la migración de datos, pero se debe verificar que los archivos o directorios que no se leen a nivel mundial migren correctamente, que se conserven las ACL (si hubiera) y que las identidades estén representadas correctamente en el nuevo sistema.

La migración shadow se implementa con datos en el disco dentro del sistema de archivos; por lo tanto, no existe una base de datos externa ni datos almacenados localmente fuera de la agrupación de almacenamiento. Si se produce un failover de una agrupación de un cluster, o si se produce un error en los dos discos de sistema y se necesita un nuevo nodo principal, todos los datos necesarios para continuar con la migración shadow sin interrupciones se mantendrán en la agrupación de almacenamiento.

A continuación se describen las restricciones del origen shadow:

• Para migrar datos correctamente, el directorio o sistema de archivos de origen *debe ser de solo lectura*. Los cambios realizados en el origen de archivos pueden (o no) propagarse en función del tiempo, y los cambios de la estructura de directorio pueden provocar errores irrecuperables en el dispositivo.

• La migración shadow admite la migración solo de orígenes NFS. Los recursos compartidos NFSv4 proporcionarán los mejores resultados. Es posible llevar a cabo la migración de NFSv2 y NFSv3; sin embargo, las ACL se perderán en el proceso y los archivos demasiado grandes para NFSv2 no se podrán migrar mediante ese protocolo. No se admite la migración desde orígenes SMB.

• No se admite la migración shadow de LUN.

Durante la migración, si un cliente accede a un archivo o directorio que aún no se ha migrado, se produce un efecto observable sobre el comportamiento. A continuación se describe la semántica del sistema de archivos shadow:

• En el caso de los directorios, se bloquean las solicitudes de cliente hasta que finalice la migración de todo el directorio. En el caso de los archivos, solo se migra la parte del archivo que se solicita y diversos clientes pueden migrar diferentes partes de un archivo al mismo tiempo.

• Se puede eliminar y sobrescribir los archivos y directorios, o cambiar su nombre, de manera arbitraria en el sistema de archivos shadow sin afectar el proceso de migración.

• En el caso de archivos que son enlaces físicos, es posible que el recuento de enlaces físicos no coincida con el origen hasta la finalización de la migración.

• La mayoría de los atributos de los archivos se migran cuando se crea el directorio, pero el tamaño en disco (st_nblocks en la estructura estática UNIX) no está disponible hasta que se realiza una operación de lectura o escritura en el archivo. El tamaño lógico será correcto, pero el comando du(1), u otro, informará un tamaño cero hasta que se migre realmente el contenido de los archivos.

• Si se reinicia el dispositivo, la migración retomará desde donde se detuvo originalmente. Si bien el dispositivo no deberá volver a migrar datos, es posible que deba recorrer algunas partes ya migradas del sistema de archivos local, lo cual puede afectar el tiempo total de migración debido a la interrupción.

• La migración de datos utiliza atributos extendidos privados en los archivos. En general, no son observables, excepto en el directorio raíz del sistema de archivos o mediante instantáneas. La agregación, la modificación o la eliminación de cualquier atributo extendido que comience con SUNWshadow ejercerá efectos indefinidos en el proceso de migración y generará un estado de daño o incompleto. Además, el estado de todo el sistema de archivos se almacena en el directorio .SUNWshadow en la raíz del sistema de archivos. Cualquier modificación que se realice en este contenido tendrá un efecto similar.

• Una vez que el sistema de archivos haya finalizado la migración, se publicará una alerta y se eliminará el atributo shadow, junto con los metadatos aplicables. Después de esto, el sistema de archivos no se podrá distinguir de un sistema de archivos normal.

• Los datos se pueden migrar en múltiples sistemas de archivos a un único sistema de archivos, mediante el uso de montajes de clientes automáticos NFSv4 (en ocasiones denominados montajes reflejados) o montajes locales anidados.

Use las siguientes reglas para migrar correctamente la información de identidad de los archivos, incluidas las ACL:

• Los dispositivos de origen y de destino de la migración deben tener la misma configuración de servicio de nombres.

• Los dispositivos de origen y de destino de la migración deben tener el mismo dominio mapid NFSv4.

• El origen de la migración debe admitir NFSv4. Es posible utilizar NFSv3, pero se perderá una parte de la información. Se conservarán los permisos de POSIX y la información de identidad básica (propietario y grupo), pero se perderán las ACL.

• Se debe exportar el origen de la migración con permisos root al dispositivo.

Si observa archivos o directorios cuyo propietario es "nobody" (nadie), probablemente signifique que el dispositivo no tiene servicios de nombres configurados correctamente, o que el dominio mapid NFSv4 es diferente. Si obtiene errores de 'permiso denegado' cuando recorre sistemas de archivos a los que el cliente debería tener acceso, el problema más probable radica en la imposibilidad de exportar el origen de la migración con permisos root.