Transferencias de datos descargados de Windows

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 un sistema de archivos y una perspectiva de minifiltro. Para obtener información relacionada con los dispositivos de almacenamiento, consulte Transferencias de datos descargadas de Almacenamiento de Windows.

Transferir datos entre equipos o dentro del mismo equipo es una actividad frecuente del sistema de archivos. El uso de las funciones ReadFile y WriteFile estándar funciona bien desde un punto de vista funcional, pero implica un gran movimiento de datos a través de todos los niveles del sistema y potencialmente a través de una red. Esto puede afectar a la disponibilidad de los sistemas implicados en la transferencia y la red que conecta los sistemas. Las funcionalidades avanzadas disponibles con muchos subsistemas de almacenamiento proporcionan un medio más eficaz para realizar la tarea de "trabajo pesado" del movimiento de datos.

Las aplicaciones pueden aprovechar estas funcionalidades para ayudar a descargar el proceso de movimiento de datos al subsistema de almacenamiento. Los filtros del sistema de archivos normalmente pueden supervisar estas acciones interceptando solicitudes de lectura y escritura en un volumen. Se requieren acciones adicionales para que los filtros sean conscientes de las transferencias de datos descargadas.

Transferencias de datos típicas

Mover datos en un escenario de aplicación hoy en día es bastante sencillo. Implica leer los datos en la memoria local y, a continuación, volver a escribirlos en una nueva ubicación. En el diagrama siguiente se muestra este escenario.

Este escenario implica copiar un archivo entre dos ubicaciones en dos servidores de archivos diferentes, cada uno con su propio disco virtual expuesto a través de una matriz de almacenamiento inteligente (ISA). El sistema iniciador primero debe leer los datos del disco virtual de origen en un búfer local. A continuación, empaqueta y transmite los datos a través de algún transporte y protocolo (como SMB de más de 1 GbE) al segundo sistema, que luego recibe los datos y los envía a un búfer local. A continuación, el sistema de destino escribe los datos en el disco virtual de destino. En este escenario se describe un método de lectura y escritura muy típico de transferencia de datos que se realiza varias veces por muchas aplicaciones diferentes todos los días.

Aunque las lecturas y escrituras estándar funcionan bien en la mayoría de los escenarios, los datos que pretenden copiarse pueden encontrarse en discos virtuales administrados por la misma matriz de almacenamiento inteligente. Esto significa que los datos se mueven fuera de la matriz, a un servidor, a través de un transporte de red, a otro servidor y vuelven a la misma matriz una vez más. El acto de mover datos dentro de un servidor y a través de un transporte de red puede afectar significativamente a la disponibilidad de esos sistemas; no mencionar el hecho de que el rendimiento del movimiento de datos está limitado por el rendimiento y la disponibilidad de la red.

Transferencias de datos descargados (ODX)

Descarga de la transferencia de datos

Se introdujeron dos nuevos FSCTL en Windows 8 que facilitan un método de descarga de la transferencia de datos. Esto desplaza la carga del movimiento de bits fuera de los servidores a un movimiento de bits que se produce de forma inteligente dentro de los subsistemas de almacenamiento. La mejor manera de visualizar la semántica del comando es pensar en ellas como análoga a una lectura sin búfer y una escritura sin búfer.

• FSCTL_OFFLOAD_READ

  Esta solicitud de control toma un desplazamiento dentro del archivo que se va a leer y una longitud deseada en la estructura FSCTL_OFFLOAD_READ_INPUT . Si se admite, el subsistema de almacenamiento que hospeda el archivo recibe el comando de almacenamiento de lectura de descarga asociado y genera un token, que es una representación lógica de los datos destinados a leerse en el momento del comando de descarga de lectura. Esta cadena de token se devuelve al autor de la llamada en la estructura FSCTL_OFFLOAD_READ_OUTPUT .

• FSCTL_OFFLOAD_WRITE

  Esta solicitud de control toma un desplazamiento dentro del archivo en el que se va a escribir, la longitud deseada de la escritura y el token que es una representación lógica de los datos en los que se va a escribir. Si se admite, el subsistema de almacenamiento que hospeda el archivo que se va a escribir recibe el comando de almacenamiento de escritura de descarga asociado. Primero intenta reconocer el token especificado y, a continuación, realiza la operación de escritura si es posible. La operación de escritura se completa debajo de Windows y, por lo tanto, los componentes del sistema de archivos y las pilas de almacenamiento no verán el movimiento de datos. Una vez completado el movimiento de datos, el número de bytes escritos se devuelve al autor de la llamada.

De forma similar al primer diagrama, el diagrama siguiente muestra una copia de archivo simple entre dos discos virtuales en dos servidores diferentes.

Sin embargo, en lugar de realizar lecturas y escrituras normales, descargamos el trabajo pesado de movimiento de bits en la matriz de almacenamiento. El primer sistema emite la operación de lectura de descarga, solicitando que la matriz genere un token que represente una vista a un momento dado de los datos que se van a leer dentro de la región del primer disco virtual. A continuación, el primer sistema transmite el token al segundo sistema, que a su vez emite una operación de escritura de descarga en el segundo disco virtual con el token. A continuación, la matriz interpreta el token e intenta realizar el movimiento de datos entre los discos virtuales. Observará que la transferencia de datos real se produce dentro de la matriz de almacenamiento inteligente y no entre los dos hosts. Esto mejora significativamente la disponibilidad de los dos sistemas, a la vez que elimina virtualmente el tráfico de red entre los sistemas.

Integración con el motor de copia

CopyFile usa el motor de copia principal en Windows y las funciones relacionadas. A partir de Windows 8, el motor de copia intenta usar de forma transparente las transferencias de datos descargadas antes de la ruta de acceso de código del archivo de copia tradicional. Dado que la mayoría de las aplicaciones, las utilidades y el shell usan las API de copia, estos autores de llamadas pueden usar funcionalidades de transferencia de datos descargadas de forma predeterminada con poca, si existe, modificación del código o intervención del usuario.

En los pasos siguientes se resume cómo el motor de copia intenta una transferencia de datos descargada:

1. El motor de copia emite un FSCTL_OFFLOAD_READ en el archivo de origen para obtener un token de lectura.
2. Si se produjo un error al recuperar el token de lectura, el motor de copia vuelve a las lecturas y escrituras tradicionales (la ruta de acceso del código del archivo de copia tradicional). Si el error indica que el volumen de origen no admite la descarga, el motor de copia también marca el volumen en una caché por proceso. El motor de copia no intentará descargar más para los volúmenes de la caché por proceso.
3. Si el token se recuperó correctamente, el motor de copia intenta emitir comandos FSCTL_OFFLOAD_WRITE en el archivo de destino en fragmentos grandes hasta que se hayan escrito todos los datos representados lógicamente por el token.
4. Cualquier error al realizar la descarga de lectura o escritura da como resultado que el motor de copia vuelva a la ruta de acceso de código tradicional de lecturas y escritura, empezando por dónde finalizó la ruta de acceso de código de descarga (donde se truncó la lectura o escritura). Si el error indica que el volumen de destino no admite la descarga o que el volumen de origen no puede llegar al volumen de destino, el motor de copia actualiza la misma caché por proceso para que no pruebe la descarga en estos volúmenes. Esta caché por proceso se restablecerá periódicamente.

Las siguientes funciones admiten transferencias de datos descargadas:

• CopyFile
• CopyFileEx
• MoveFile
• MoveFileEx
• CopyFile2

Las siguientes funciones no admiten transferencias de datos descargadas:

• CopyFileTransacted
• MoveFileTransacted

Escenarios de transferencia de datos de descarga admitidos

La compatibilidad con las operaciones de descarga se proporciona en la pila de almacenamiento de Hyper-V y en el servidor de archivos SMB de Windows. Cuando el almacenamiento físico de respaldo admite operaciones ODX, los autores de llamadas pueden emitir FSCTL_OFFLOAD_READ y FSCTL_OFFLOAD_WRITE a archivos que residen en discos duros virtuales o en recursos compartidos de archivos remotos, ya sea desde una máquina virtual o en hardware físico. En el diagrama siguiente se muestran los destinos de origen y destino admitidos más básicos para las transferencias de datos descargadas.

Filtro del sistema de archivos Opt-In modelo e impacto en las aplicaciones

A partir de Windows 8, el Administrador de filtros permite que un filtro especifique la funcionalidad de descarga como característica compatible. Los filtros del sistema de archivos adjuntos a un volumen pueden determinar colectivamente si se admite o no una determinada operación descargada; si no es así, se produce un error en la operación con un código de error adecuado.

Un filtro debe indicar que admite FSCTL_OFFLOAD_READ y FSCTL_OFFLOAD_WRITE a través de un valor DWORD del Registro denominado SupportedFeatures, ubicado en la definición del servicio de controlador en el registro en HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\nombre del controlador de filtro\. Este valor contiene campos de bits en los que los bits determinan qué funcionalidad se ha optado por participar y se deben establecer durante la instalación del filtro.

Actualmente, los bits definidos son:

Marca	Significado
SUPPORTED_FS_FEATURES_OFFLOAD_READ 0x00000001	El filtro admite FSCTL_OFFLOAD_READ
SUPPORTED_FS_FEATURES_OFFLOAD_WRITE 0x00000002	El filtro admite FSCTL_OFFLOAD_WRITE

El modelo de participación de filtro se puede habilitar o deshabilitar en función del valor presente en la clave del Registro de HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\FilterSupportedFeaturesMode, que tiene los siguientes valores:

Valor FilterSupportedFeaturesMode	Significado
0 (predeterminado)	Realice el procesamiento normal de la participación.
1	No participar nunca (equivalente a establecer SupportedFeatures en 0 en todos los filtros adjuntos)

Prueba

Para comprobar las características admitidas de un filtro de la pila, use la utilidad fltmc. Ejecute instancias de fltmc –v [volumen]: como un usuario con privilegios elevados y compruebe la columna SprtFtrs :

• Si el valor de SprtFtrs es 0x00, implica que el filtro está bloqueando la descarga en este volumen. Si SprtFtrs se establece en 0x03, se admiten ambas operaciones de descarga.

Comprobación de la compatibilidad de características en el procesamiento de IRP

Como parte del procesamiento de IRP, la rutina FsRtlGetSupportedFeatures recupera el estado SupportedFeatures agregado para todos los filtros asociados a la pila de volúmenes especificada. Los componentes como el Administrador de E/S y SRV (SMB) llaman a esta rutina para validar el estado SupportedFeatures para todos los filtros de la pila. Los componentes que implementan sus propios IRP de descarga deben llamar a esta función para validar la compatibilidad de participación con esa operación.

Consideraciones para los controladores de filtro

La transferencia de datos descargado es una nueva manera de mover datos en el centro de datos. Debido a la integración de la lógica de descarga en el motor de copia principal, muchas aplicaciones de forma predeterminada tendrán la capacidad de realizar el movimiento de datos descargado sin participar explícitamente. Como resultado, los desarrolladores de filtros deben comprender cómo afectan estas nuevas operaciones a los filtros. No comprender estas operaciones por completo o no evaluar el nuevo flujo de datos puede dar lugar a escenarios en los que los datos se pueden volver incoherentes o dañados. En la lista siguiente se resume un conjunto de elementos de acción para que los desarrolladores de filtros anoten con la descarga:

• Comprenda este flujo de datos, el impacto en el filtro y la capacidad del filtro para admitir estas operaciones descargadas.
• Actualice el instalador de filtro para agregar un valor de REG_DWORD para SupportedFeatures a la subclave HKLM\System\CurrentControlSet\Services\[filter]. Inicialícelo para especificar la funcionalidad de descarga.
• En el caso de los filtros que quieran actuar tras las operaciones de descarga, actualice el registro a IRP_MJ_FILE_SYSTEM_CONTROL para controlar FSCTL_OFFLOAD_READ y FSCTL_OFFLOAD_WRITE.
• Para los filtros que necesitan bloquear las operaciones descargadas, devuelva el código de estado STATUS_NOT_SUPPORTED desde el filtro. No confíe en el valor del Registro para aplicar las operaciones de descarga de bloqueo, ya que los usuarios finales pueden cambiarla. Un filtro debe permitir o denegar explícitamente las operaciones de descarga.

Copiar tokens

Con las operaciones descargadas, la pila de E/S no ve los datos del archivo. En su lugar, se considera un token de 512 bytes que es el proxy lógico para los datos. Este token es una cadena opaca y única de un formato específico del proveedor generado por el subsistema de almacenamiento, o puede ser de un tipo conocido para representar un patrón de datos (por ejemplo, un intervalo de datos que es lógicamente equivalente a cero). Las modificaciones en los datos para los que el token es un proxy darán lugar a invalidar el token o para que el subsistema de almacenamiento conserve los datos originales mediante algún medio específico del proveedor (por ejemplo, a través de un mecanismo de instantánea). Las solicitudes de lectura de descarga posteriores a un intervalo especificado en un archivo da como resultado tokens únicos.

Hay clases de tokens que representan un patrón de datos que está bien definido. El token conocido más común es el token cero, que equivale a cero. Cuando un token se define como un token conocido, el miembro TokenType de la estructura STORAGE_OFFLOAD_TOKEN se establecerá en STORAGE_OFFLOAD_TOKEN_TYPE_WELL_KNOWN. Cuando se establece este campo, el miembro WellKnownPattern determina qué patrón de datos es el token.

• Cuando el campo WellKnownPattern se establece en STORAGE_OFFLOAD_PATTERN_ZERO o STORAGE_OFFLOAD_PATTERN_ZERO_WITH_PROTECTION_INFORMATION, indica el token cero. Cuando una operación de FSCTL_OFFLOAD_READ devuelve este token, indica que los datos contenidos en el intervalo de archivos deseados son lógicamente equivalentes a cero. Cuando este token se proporciona a una operación de FSCTL_OFFLOAD_WRITE , indica que el intervalo deseado del archivo que se va a escribir debe estar en ceros lógicamente.
• Aparte del token cero, no hay ningún otro patrón de token conocido definido actualmente. No se recomienda que los usuarios definan sus propios patrones de token conocidos.

Truncamiento

El subsistema de almacenamiento subyacente con el que Windows se comunica puede procesar menos datos deseados en una operación de descarga. Esto se denomina truncamiento. Con la descarga de lectura, esto significa que el token devuelto representa un intervalo de los datos menores que los solicitados. Esto se indica mediante el miembro TransferLength en la estructura FSCTL_OFFLOAD_READ_OUTPUT , que es un recuento de bytes desde el principio del intervalo del archivo que se va a leer. En el caso de la descarga de escritura, un truncamiento indica que se escribieron menos datos de los deseados. Esto se indica mediante el miembro LengthWritten en la estructura FSCTL_OFFLOAD_WRITE_OUTPUT , que es un recuento de bytes desde el principio del intervalo del archivo que se va a escribir. Los errores en el procesamiento de comandos, o las limitaciones dentro de la pila de intervalos grandes, producen un truncamiento.

Hay dos escenarios en los que NTFS trunca el intervalo que se va a descargar de lectura o escritura:

1. El intervalo de copia se truncará a Longitud de datos válida (VDL) si VDL está antes del final del archivo (EOF). Se supone que VDL está alineado con un límite de sector lógico; en caso contrario, vea el escenario.

   

   Durante una operación de FSCTL_OFFLOAD_READ , la marca OFFLOAD_READ_FLAG_ALL_ZERO_BEYOND_CURRENT_RANGE se establece en la estructura FSCTL_OFFLOAD_READ_OUTPUT que indica que el resto del archivo contiene ceros y el miembro TransferLength se trunca en VDL.

2. De forma similar al escenario 1, pero cuando VDL no está alineado con un límite de sector lógico, el intervalo deseado se trunca por NTFS al siguiente límite del sector lógico.

   

Limitaciones

• Las operaciones de descarga solo se admiten en volúmenes NTFS.
• Las operaciones de descarga se admiten a través de servidores de archivos remotos si el recurso compartido remoto es un volumen NTFS y si el servidor ejecuta Windows Server 2012 o versiones posteriores (suponiendo que la pila remota también admite operaciones de descarga).
• NTFS no admite la descarga de FSCTLs realizadas en archivos cifrados con cifrado de Bitlocker o NTFS (EFS), archivos desduplicados, archivos comprimidos, archivos residentes, archivos dispersos o archivos que participan en transacciones TxF.
• NTFS no admite la descarga de FSCTLs realizadas en archivos dentro de una instantánea de volsnap.
• NTFS producirá un error en la descarga FSCTL si el intervalo de archivos deseado no está asignado al tamaño del sector lógico en el dispositivo de origen o si el intervalo de archivos deseado no está asignado al tamaño del sector lógico en el dispositivo de destino. Esto sigue la misma semántica que la E/S no almacenada en caché.
• El archivo de destino debe asignarse previamente (SetEndOfFile y no SetAllocation) antes de FSCTL_OFFLOAD_WRITE.
• En el procesamiento de la descarga de lectura y descarga de escritura, NTFS llama primero a CcCoherencyFlushAndPurgeCache para confirmar los datos modificados en la memoria caché del sistema. Se trata de la misma semántica que la E/S no almacenada en caché.