Transferencia de datos descargados de almacenamiento de Windows
La transferencia de datos descargados (ODX) de Windows es una función que acelera las operaciones de copia y traslado del servidor. Está disponible a partir de Windows Server 2012 y se admite en volúmenes NTFS.
En este artículo se describe ODX desde la perspectiva de un dispositivo de almacenamiento. Para obtener información relacionada con los sistemas de archivos y minifiltros, consulte Transferencias de datos descargados.
Información general
En lugar de copiar grandes cantidades de datos durante las transferencias de archivos, Windows ODX introdujo una operación tokenizada para mover datos en dispositivos de almacenamiento. El archivo de origen y un archivo de destino pueden estar en cualquiera de las siguientes ubicaciones:
- En el mismo volumen.
- En dos volúmenes diferentes que hospeda la misma máquina.
- En un volumen local y un volumen remoto a través del bloque de mensajes del servidor (SMB2 o SMB3).
- En dos volúmenes de dos máquinas diferentes a través de SMB2 o SMB3.
El proceso de una operación de copia de descarga en dispositivos de almacenamiento compatibles con ODX se muestra en el diagrama siguiente.
- La aplicación de copia envía una solicitud de lectura de descarga al administrador de copias del dispositivo de almacenamiento de origen.
- El administrador de copia de origen devuelve un token. El token es una representación de los datos (ROD) que se van a copiar.
- La aplicación envía una solicitud de escritura de descarga con token al administrador de copias del dispositivo de almacenamiento de destino.
- El administrador de copia de la matriz de almacenamiento mueve los datos del dispositivo de origen al dispositivo de destino y devuelve el resultado de la escritura de descarga a la aplicación.
Identificación de un origen y un destino compatibles con ODX
Para admitir ODX, las matrices de almacenamiento deben implementar las especificaciones estándar de T10 relacionadas para matrices de almacenamiento compatibles con ODX, incluidas las operaciones de lectura y escritura de descarga con tokens. Durante la enumeración de dispositivos LUN (un evento de arranque del sistema o un evento plug-and-play), Windows recopila o actualiza la información de funcionalidad de ODX del dispositivo de destino de almacenamiento mediante los pasos siguientes.
- Funcionalidad de consulta de copia de descarga.
- Recopilar los parámetros necesarios para las operaciones y limitaciones de copia de descarga.
De forma predeterminada, Windows intenta primero la ruta de acceso de ODX para una operación de copia si los LUN de origen y destino son compatibles con ODX. Si el dispositivo de almacenamiento produce un error en la solicitud inicial de ODX, Windows marca la combinación del LUN de origen y destino como una ruta de acceso "no compatible con ODX" y sigue la ruta de acceso del código del archivo de copia heredada.
Operaciones de lectura/escritura de ODX
Adopción y API de comandos sincrónicas
Una solicitud de escritura de descarga grande se divide mediante el siguiente algoritmo para garantizar una sólida escritura de descarga sincrónica.
- Si el dispositivo de almacenamiento de destino no proporciona un tamaño de transferencia óptimo, establezca el tamaño de transferencia óptimo a 64 MB.
- Si el tamaño óptimo de transferencia establecido por el dispositivo de destino es superior a 256 MB, establezca el tamaño óptimo de transferencia en 256 MB.
- El tamaño óptimo de transferencia especificado por el dispositivo de destino de almacenamiento es mayor que cero y menor que 256 MB.
Los comandos SCSI de lectura y escritura de descarga sincrónica reducen la complicación de los escenarios de conmutación por error de clúster y MPIO. Windows espera que el administrador de copias complete los comandos SCSI de lectura y escritura sincrónica en un plazo de 4 segundos.
Las aplicaciones pueden usar las API de FSCTL, DSM IOCTL o SCSI_PASS_THROUGH para interactuar con matrices de almacenamiento y ejecutar operaciones de copia de descarga. Para evitar daños en los datos o inestabilidad del sistema, Windows impide que las aplicaciones escriban directamente en un volumen montado en el sistema de archivos sin obtener primero acceso exclusivo al volumen. Esta restricción es necesaria debido a la condición de que una escritura en el volumen pueda colisionar con las escrituras del sistema de archivos. Cuando se producen tales colisiones, el contenido del volumen podría quedar en un estado incoherente.
Operaciones de lectura de descarga
La solicitud de lectura de descarga de una aplicación puede especificar la duración del token (tiempo de espera de inactividad). Si la aplicación establece la duración del token en cero, el temporizador de inactividad predeterminado se usa como duración del token. El administrador de copias de la matriz de almacenamiento mantiene y valida el token según su valor y credenciales de tiempo de espera de inactividad. El host de Windows también limita el número de fragmentos de archivo a 64. Si la solicitud de lectura de descarga tiene de más de 64 fragmentos, Windows produce un error en la solicitud de copia de descarga y vuelve a la operación de copia tradicional.
Después de completar la solicitud de lectura de descarga, el administrador de copias prepara una representación del token de datos (ROD) para el comando de recepción del resultado de la lectura de descarga. El campo de token de ROD especifica la representación en un momento dado de la información de protección y datos de usuario. El ROD puede ser datos de usuario en formato "abierto exclusivamente" o "abierto con recurso compartido". El administrador de copias puede invalidar el token según su configuración de directiva ROD. Si el ROD está "abierto exclusivamente" para una operación de copia de descarga, el token de ROD se puede invalidar cuando se modifica o mueve el ROD. Si ROD está en formato "abierto con recurso compartido", el token de ROD permanece válido cuando se modifica el ROD. Un token de ROD es de 512 bytes con el formato siguiente:
| Tamaño en bytes | Contenido del token |
|---|---|
| 4 | Tipo de token de ROD |
| 508 | ID de token de ROD |
Dado que la matriz de almacenamiento concede y consume el token de ROD, su formato es opaco, único y muy seguro. Si el token se modifica, no se valida o ha expirado, el administrador de copias puede invalidar el token durante la operación de escritura de descarga. El token de ROD devuelto de la operación de lectura de descarga tiene un valor de tiempo de espera inactivo para indicar el número de segundos que el administrador de copias debe mantener el token válido para el siguiente uso de escritura mediante token.
Operaciones de escritura de descarga
Una vez que la aplicación recibe el token de ROD del administrador de copias, envía la solicitud de escritura de descarga con el token de ROD al administrador de copias de la matriz de almacenamiento. Cuando se envía un comando de escritura de descarga sincrónica al dispositivo de destino, Windows espera que el administrador de copias complete el comando en un plazo de 4 segundos. Si el comando finaliza debido al tiempo de espera del comando u otras condiciones de error, Windows produce un error en el comando. La aplicación vuelve a la operación de copia heredada según el código de estado devuelto.
La solicitud de escritura de descarga se puede completar con uno o varios comandos de recepción de resultado de escritura de descarga. Si la escritura de descarga se completa parcialmente, el administrador de copias devuelve el retardo estimado y el número de recuentos de transferencias para indicar el progreso de la copia. El número de recuentos de transferencias especifica el número de bloques lógicos contiguos que se escribieron sin errores del medio de origen al de destino. El administrador de copias puede realizar escrituras de descarga en un patrón secuencial o de dispersión o recopilación.
Cuando se produce un error de escritura, el progreso de la copia cuenta los bloques lógicos contiguos del primer bloque lógico al bloque de error. La aplicación cliente o el motor de copia reanuda la escritura de descarga del bloque de error de escritura. Cuando se completa la escritura de descarga, el administrador de copias completa el comando de recepción de información del token de ROD con:
- El retardo de actualización de estado estimado establecido en cero.
- El progreso del recuento de transferencias de datos al 100 %.
Si el resultado de la recepción de la escritura de descarga devuelve el mismo progreso del recuento de transferencias de datos, Windows devuelve la operación de copia a la aplicación después de cuatro reintentos.
Una aplicación cliente también puede realizar la operación de escritura de descarga con un token de ROD conocido, que es un token de ROD predefinido con un patrón de datos conocido y formato de token. Una implementación común se denomina token cero. Una aplicación cliente puede usar un token cero para rellenar uno o varios intervalos de bloques lógicos con ceros. Si el token conocido no es compatible o reconocible, el administrador de copias produce un error en la solicitud de escritura de descarga con "Token no válido". Un token de ROD conocido es de 512 bytes con el formato siguiente:
| Tamaño en bytes | Contenido del token |
|---|---|
| 4 | Tipo de token de ROD |
| 2 | Patrón conocido |
| 506 | ID de token de ROD |
En una escritura de descarga con un token de ROD conocido, una aplicación cliente no puede usar una lectura de descarga para solicitar un token conocido. El administrador de copias comprueba y mantiene los tokens de ROD conocidos según su propia directiva.
Parámetros de ajuste del rendimiento de la implementación de ODX
El rendimiento de ODX no depende de las velocidades del vínculo de transporte de la red del servidor cliente o de la red de área de almacenamiento (SAN) entre el servidor y la matriz de almacenamiento. El administrador de copias y los servidores de dispositivos de la matriz de almacenamiento mueven los datos.
No todas las copias de descargas se benefician de la tecnología ODX. Por ejemplo, el administrador de copias de una matriz de almacenamiento iSCSI de 1 Gbit podría completar una copia de archivos de 3 GB en un plazo de 10 segundos y la velocidad de transferencia de datos será superior a 300 MB por segundo. La velocidad de transferencia de datos ya supera la velocidad máxima de transferencia teórica de la interfaz Ethernet de 1 Gbit.
Además, es posible que el rendimiento de copia de los archivos de un tamaño determinado no se beneficie de la tecnología ODX. Para optimizar el rendimiento, el uso de ODX se puede restringir a un tamaño mínimo de archivo y longitudes máximas de copia. Nota:
Windows establece un requisito mínimo de tamaño de archivo para las operaciones de copia de descarga a 256 KB en el motor de copia. Si un archivo es inferior a 256 KB, el motor de copia vuelve al proceso de copia heredado.
El host de Windows usa un tamaño máximo de transferencia de tokens y un recuento óptimo de transferencias para preparar el tamaño óptimo de transferencia de un comando SCSI de lectura o escritura de descarga. El tamaño total de la transferencia en número de bloques no debe superar el tamaño máximo de transferencia de tokens. Si la matriz de almacenamiento no notifica un recuento óptimo de transferencias, Windows usa 64 MB como recuento predeterminado.
Los parámetros de longitud de transferencia óptima y máxima especifican el número óptimo y máximo de bloques en un descriptor de intervalo. Las aplicaciones de copia de descarga pueden cumplir estos parámetros para lograr el rendimiento óptimo de la transferencia de archivos.
Compatibilidad con el control de errores y la alta disponibilidad de ODX
Cuando una operación de ODX produce un error en una solicitud de copia de archivos, el motor de copia y el sistema de archivos de Windows (NTFS) se revierten a la operación de copia heredada. Si se produce un error en la copia de descarga en medio de la operación de escritura de descarga, el motor de copia y NTFS se reanudan con la operación de copia heredada desde el primer punto de error de la escritura de descarga.
Control de errores de ODX
ODX usa un algoritmo sólido de control de errores de acuerdo con las características de la matriz de almacenamiento. Si se produce un error en la copia de descarga en una ruta de acceso compatible con ODX, el host de Windows espera que la aplicación vuelva a la operación de copia heredada. En este momento, el motor de copia de Windows ya ha implementado el mecanismo de "recurrir a copia tradicional". Después del error de copia de descarga, NTFS marca el LUN de origen y destino como no compatible con ODX durante tres minutos. Una vez transcurrido este período de tiempo, el motor de copia de Windows vuelve a intentar la operación ODX. Una matriz de almacenamiento podría usar esta característica para deshabilitar temporalmente la compatibilidad con ODX en algunas rutas de acceso durante situaciones muy estresantes.
Conmutación por error de ODX en configuraciones de servidor de clúster y MPIO
Las operaciones de lectura y escritura de descarga deben completarse o cancelarse desde el mismo vínculo de almacenamiento (nexo I_T).
Cuando se produce una conmutación por error de servidor MPIO o de clúster durante una operación de lectura o escritura de descarga sincrónica, Windows controla la conmutación por error de la siguiente manera:
Si se produce una conmutación por error de la ruta de acceso MPIO, Windows vuelve a intentar el comando ODX con errores. Si se vuelve a producir un error en el comando, Windows:
- Inicia una conmutación por error de nodo de servidor de clúster cuando forma parte de un servidor de clúster.
- Emite un restablecimiento de LUN en el dispositivo de almacenamiento y devuelve un estado de error de E/S a la aplicación si la conmutación por error del servidor de clúster no es una opción.
En una configuración del servidor de clúster, el servicio de almacenamiento de clúster conmuta por error al siguiente nodo de clúster preferido y, a continuación, reanuda el servicio de almacenamiento del clúster. La aplicación de descarga debe tener en cuenta el clúster para poder volver a intentar el comando de lectura y escritura de descarga después de la conmutación por error del servicio de almacenamiento del clúster.
Si se produjo un error en el comando de lectura o escritura de descarga después de la conmutación por error de la ruta de acceso de MPIO y del nodo de clúster, Windows emite un restablecimiento de LUN en el dispositivo de almacenamiento después de la conmutación por error. El dispositivo de almacenamiento finaliza todos los comandos y operaciones pendientes en el LUN.
Actualmente, Windows no emite comandos SCSI de lectura o escritura de descarga asincrónica desde la pila de almacenamiento.
Modelo de uso de ODX
ODX en disco físico, disco duro virtual y disco compartido SMB
Para realizar operaciones de ODX, el servidor de aplicaciones debe tener acceso al LUN de origen y de destino con privilegios de lectura y escritura. La aplicación de copia de descarga emite una solicitud de lectura de descarga en el LUN de origen y recibe un token del administrador de copias del LUN de origen. Las aplicaciones de copia de descarga usan el token para emitir una solicitud de escritura de descarga en el LUN de destino. A continuación, el administrador de copias mueve los datos del LUN de origen al LUN de destino a través de la red de almacenamiento. En el diagrama siguiente se ven los destinos de origen y de destino más básicos admitidos en las transferencias de datos descargados.
Operación de ODX con un servidor
En una configuración de servidor único, la aplicación de copia de descarga emite las solicitudes de lectura y escritura de descarga desde el mismo sistema de servidor.
El servidor de origen (o máquina virtual de origen) tiene acceso tanto al LUN de origen (disco duro virtual o físico) como al LUN de destino (VHD o disco físico). La aplicación de copia de descarga emite una solicitud de lectura de descarga en el LUN de origen y recibe el token del LUN de origen. A continuación, la aplicación de copia de descarga usa el token para emitir una solicitud de escritura de descarga en el LUN de destino. El administrador de copias mueve los datos del LUN de origen al LUN de destino dentro de la misma matriz de almacenamiento.
Operación de ODX con dos servidores
En la configuración de dos servidores, hay dos servidores y varias matrices de almacenamiento administradas por el mismo administrador de copias.
- Un servidor (o máquina virtual) es el host del LUN de origen y el otro servidor (o máquina virtual) es el host del LUN de destino. El servidor de origen comparte el LUN de origen con el cliente de la aplicación a través del protocolo SMB y el servidor de destino también comparte el LUN de destino con el cliente de la aplicación a través del protocolo SMB. Por lo tanto, el cliente de la aplicación tiene acceso al LUN de origen y al LUN de destino.
- El mismo administrador de copias administra las matrices de almacenamiento de origen y destino en una configuración SAN.
- Desde el sistema cliente de aplicación, la aplicación de copia de descarga emite una solicitud de lectura de descarga al LUN de origen y recibe el token del LUN de origen y, a continuación, emite una solicitud de escritura de descarga con el token al LUN de destino. El administrador de copias mueve los datos del LUN de origen al LUN de destino en dos matrices de almacenamiento diferentes en dos ubicaciones diferentes.
Migración masiva de datos
La migración masiva de datos es el proceso de importar una gran cantidad de datos, como registros de base de datos, hojas de cálculo, archivos de texto, documentos escaneados e imágenes en un nuevo sistema. La migración de datos puede deberse a una actualización del sistema de almacenamiento, a un nuevo motor de base de datos o a cambios en el proceso de aplicación o negocio. ODX se puede usar para migrar datos de un sistema de almacenamiento heredado a un nuevo sistema de almacenamiento cuando el administrador de copias del nuevo sistema también puede administrar el sistema heredado.
- Un servidor es el host del sistema de almacenamiento heredado y el otro es el host del nuevo sistema de almacenamiento. El servidor de origen comparte el LUN de origen como cliente de la aplicación de migración de datos a través del protocolo SMB y el servidor de destino comparte el LUN de destino como el cliente de la aplicación de migración de datos a través del protocolo SMB. Por lo tanto, el cliente de la aplicación tiene acceso al LUN de origen y de destino.
- El mismo administrador de copias administra el sistema de almacenamiento heredado y el nuevo sistema de almacenamiento en una configuración SAN.
- Desde el sistema cliente de la aplicación de migración de datos, la aplicación de copia de descarga emite una solicitud de lectura de descarga en el LUN de origen y recibe el token del LUN de origen. A continuación, la aplicación emite una solicitud de escritura de descarga con el token al LUN de destino. El administrador de copias mueve los datos del LUN de origen al LUN de destino en dos sistemas de almacenamiento diferentes en dos ubicaciones diferentes.
- La migración masiva de datos también podría funcionar con un servidor en la misma ubicación.
Transferencia de datos controlada por host dentro de un dispositivo de almacenamiento en niveles
Un dispositivo de almacenamiento en niveles clasifica los datos en distintos tipos de medios de almacenamiento para reducir los costes, aumentar el rendimiento y solucionar problemas de capacidad. Las categorías se pueden basar en los niveles de protección necesarios, requisitos de rendimiento, frecuencia de uso y otras consideraciones.
La estrategia de migración de datos desempeña un papel importante en el resultado final de una estrategia de almacenamiento en niveles. ODX habilita la migración de datos controlada por host dentro del dispositivo de almacenamiento en niveles. En el ejemplo siguiente se describe ODX en un dispositivo de almacenamiento de dos niveles:
- El servidor es el host del sistema de almacenamiento en niveles. El LUN de origen es el dispositivo de almacenamiento de nivel 1 y el LUN de destino es el dispositivo de almacenamiento de nivel 2.
- El mismo administrador de copias administra todos los dispositivos de almacenamiento en niveles.
- Desde el sistema de servidor, la aplicación de migración de datos emite una solicitud de lectura de descarga al LUN de origen y recibe el token del LUN de origen. A continuación, esta aplicación emite una solicitud de escritura de descarga con el token al LUN de destino. El administrador de copias mueve los datos del LUN de origen al LUN de destino en dos dispositivos de almacenamiento de niveles diferentes.
- Una vez completada la tarea de migración de datos, la aplicación elimina los datos del dispositivo de almacenamiento del nivel 11 y reclama el espacio de almacenamiento.