Migración shadow

Figura 14-1  Migración shadow

La migración shadow utiliza la interposición, pero está integrada en el dispositivo ZFSSA y no requiere un equipo físico 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 ZFSSA de origen X se coloca en modo de sólo lectura, se crea un recurso compartido con la propiedad shadow configurada y los clientes se actualizan para apuntar al nuevo recurso compartido del dispositivo Sun Storage 7000 ZFSSA. A continuación, los clientes pueden acceder al dispositivo ZFSSA en modo lectura y escritura.

Una vez que está configurada la propiedad shadow, los datos se migran de manera transparente en segundo plano desde el dispositivo ZFSSA de origen localmente. Si una solicitud proviene de un cliente para un archivo que aún no se ha migrado, el dispositivo ZFSSA 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 ZFSSA 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 sólo en un host. Por lo tanto, es extremadamente importante que antes de realizar cualquier migración entre dos hosts ésta 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.