Compartir a través de


Transferencia de datos descargada de Almacenamiento de Windows

Introducción

La transferencia de datos descargada (ODX) es una característica que acelera las operaciones de copia y movimiento del servidor. Esta característica está disponible a partir de Windows Server 2012 y se admite en volúmenes NTFS. En esta página se describe ODX desde una perspectiva del dispositivo de almacenamiento. Para obtener información relacionada con los sistemas de archivos y minifiltros, consulte Transferencias de datos descargadas.

Windows ODX presenta una operación tokenizada para mover datos en dispositivos de almacenamiento. Un archivo de origen y un archivo de destino pueden estar en el mismo volumen, dos volúmenes diferentes hospedados por el mismo equipo, un volumen local y un volumen remoto a través del bloque de mensajes del servidor (SMB2 o SMB3), o dos volúmenes en dos máquinas diferentes a través de SMB2 o SMB3. ODX se introdujo en Windows 8.

El proceso de una operación de copia de descarga en dispositivos de almacenamiento compatibles con ODX se muestra en el diagrama siguiente y se describe a continuación.

Copia de la operación de descarga mediante ODX.

  1. La aplicación de copia envía una solicitud de lectura de descarga al administrador de copias del dispositivo de almacenamiento de origen.
  2. El administrador de copia de origen devuelve un token. El token es una representación de datos (ROD) que se va a copiar.
  3. La aplicación envía una solicitud de escritura de descarga con token al administrador de copias del dispositivo de almacenamiento de destino.
  4. 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 escritura de descarga a la aplicación.

Identificación de un origen y un destino de ODX-Capable

Para admitir ODX, las matrices de almacenamiento deben implementar las especificaciones estándar T10 relacionadas para matrices de almacenamiento compatibles con ODX, incluidas las operaciones de lectura y escritura descargadas con tokens. Durante la enumeración de dispositivos LUN (un 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.

  1. Funcionalidad de descarga de copia de consulta.
  2. Recopile los parámetros necesarios para copiar las operaciones de descarga y las limitaciones.

De forma predeterminada, Windows intenta primero la ruta de acceso de ODX para una operación de copia si los LUN de origen y de 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 y 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 escritura sólida 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 en 64 MB.
  • Si el tamaño de transferencia óptimo establecido por el dispositivo de destino es mayor que 256 MB, establezca el tamaño de transferencia óptimo en 256 MB.
  • El tamaño de transferencia óptimo especificado por el dispositivo de destino de almacenamiento es mayor que cero y menor que 256 MB.

La descarga sincrónica de comandos SCSI de lectura y descarga de descarga reduce la complicaciones de los escenarios de conmutación por error de MPIO y clúster. Windows espera que el administrador de copias complete los comandos SCSI de lectura y escritura sincrónicos en un plazo de 4 segundos.

Las aplicaciones pueden usar FSCTL, DSM IOCTL o SCSI_PASS_THROUGH API para interactuar con matrices de almacenamiento y ejecutar operaciones de descarga de copia. Para evitar daños en los datos o inestabilidad del sistema, Windows impide que las aplicaciones escriban directamente en un volumen montado por un sistema de archivos sin obtener primero acceso exclusivo al volumen. Esto se debe a la condición de que una escritura en el volumen pueda colisionar con las escrituras del sistema de archivos. Cuando se producen estas colisiones, el contenido del volumen puede dejarse en un estado incoherente.

Descarga de operaciones de lectura

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 copia de la matriz de almacenamiento mantiene y valida el token según su valor de tiempo de espera de inactividad y sus credenciales. El host de Windows también limita el número de fragmentos de archivo a 64. Si la solicitud de lectura de descarga consta de más de 64 fragmentos, Windows produce un error en la solicitud de descarga de copia 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 resultado de descarga de descarga de recepción. El campo token ROD especifica la representación a 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 es "abierto exclusivamente" para una operación de descarga de copia, el token rod se puede invalidar cuando se modifica o se mueve el ROD. Si ROD está en formato "abierto con recurso compartido", el token ROD permanece válido cuando se modifica el ROD. Un token ROD es de 512 bytes con el formato siguiente:

Tamaño en bytes Contenido del token
4 Tipo de token ROD
508 IDENTIFICADOR de token rod

Dado que la matriz de almacenamiento concede y consume el token ROD, su formato es opaco, único y altamente 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 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.

Descarga de operaciones de escritura

Después de recibir el token ROD del administrador de copias, la aplicación envía la solicitud de escritura de descarga con el token 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 receive Offload Write Result. Si la escritura de descarga se completa parcialmente, el administrador de copias devuelve con el retraso estimado y el número de recuentos de transferencia para indicar el progreso de la copia. El número de recuentos de transferencia especifica el número de bloques lógicos contiguos que se escribieron sin errores del origen al medio 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 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 Receive ROD Token Information con el retraso estimado de actualización de estado establecido en cero y el progreso del recuento de transferencia de datos al 100 %. Si el resultado de la descarga de descarga de recepción devuelve el mismo progreso del recuento de transferencia 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 ROD conocido. Se trata de un token ROD predefinido con un patrón de datos conocido y un 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 ROD conocido es de 512 bytes con el formato siguiente:

Tamaño en bytes Contenido del token
4 Tipo de token ROD
2 Patrón conocido
506 IDENTIFICADOR de token rod

En una escritura de descarga con un token 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 ROD conocidos según su propia directiva.

Parámetros de optimización del rendimiento de la implementación de ODX

El rendimiento de ODX no depende de la velocidad del vínculo de transporte de la red del servidor cliente o de la red del á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 descargas de copias 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 archivo 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 de transferencia teórica máxima 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 de archivo mínimo y longitudes máximas de copia permitidas. Nota:

  • Windows establece un requisito de tamaño de archivo mínimo para las operaciones de descarga de copia 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 transferencia 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 descarga de copia pueden cumplir estos parámetros para lograr el rendimiento óptimo de la transferencia de archivos.

Control de errores de ODX y compatibilidad con alta disponibilidad

Cuando se produce un error en una operación ODX de una solicitud de copia de archivos, el motor de copia y el sistema de archivos de Windows (NTFS) vuelven a la operación de copia heredada. Si se produce un error en la descarga de copia 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 descarga de copia 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 "reserva a la copia tradicional". Después del error de descarga de copia, 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 reintenta 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 (I_T nexus).

Cuando se produce una conmutación por error de MPIO o un servidor de clúster durante una operación de descarga o escritura sincrónica, Windows controla la conmutación por error de la siguiente manera:

  • En caso de conmutación por error de una ruta de acceso mpIO, Windows reintenta el comando ODX con errores. Si se produce un error de nuevo 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 pendientes y las operaciones pendientes en el LUN.

Actualmente, Windows no emite comandos SCSI de lectura o escritura asincrónicos de descarga desde la pila de almacenamiento.

Modelos 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 al LUN de destino con privilegios de lectura y escritura. La aplicación de descarga de copia 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 descarga de copia usan el token para emitir una solicitud de escritura de descarga en el LUN de destino. Después, 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 muestran los destinos de origen y destino admitidos más básicos para las transferencias de datos descargadas.

Destinos de origen y destino de ODX admitidos básicamente.

Operación de ODX con un servidor

En una configuración de servidor único, la aplicación de descarga de copia emite las solicitudes de lectura y escritura de descarga desde el mismo sistema de servidor.

El servidor de origen (o la 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 descarga de copia 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 descarga de copia 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 la aplicación, la aplicación de descarga de copia emite una solicitud de lectura de descarga en el 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 podría deberse a una actualización del sistema de almacenamiento, a un nuevo motor de base de datos o a cambios en la aplicación o el proceso empresarial. ODX se puede usar para migrar datos de un sistema de almacenamiento heredado a un nuevo sistema de almacenamiento, si el administrador de copia del nuevo sistema de almacenamiento puede administrar el sistema de almacenamiento heredado.

  • Un servidor es el host del sistema de almacenamiento heredado y el otro servidor 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 cliente de 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 destino.
  • El mismo administrador de copia 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 descarga de copia emite una solicitud de lectura de descarga en el 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 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.

Host-Controlled transferencia de datos dentro de un dispositivo de almacenamiento en capas

Un dispositivo de almacenamiento en capas clasifica los datos en diferentes tipos de medios de almacenamiento para reducir los costos, 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 capas. ODX habilita la migración de datos controlada por host dentro del dispositivo de almacenamiento en capas. 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 capas. El LUN de origen es el dispositivo de almacenamiento tier1 y el LUN de destino es el dispositivo de almacenamiento tier2.
  • Todos los dispositivos de almacenamiento en capas se administran mediante el mismo administrador de copia.
  • 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 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 dispositivos de almacenamiento de capas diferentes.
  • Una vez completada la tarea de migración de datos, la aplicación elimina los datos del dispositivo de almacenamiento tier1 y reclama el espacio de almacenamiento.