transferencias de datos descargados de Windows

ODX (Transferencia de datos descargados) es una función que acelera las operaciones de copia y traslado del servidor. Esta función está disponible a partir de Windows Server 2012 y se admite en volúmenes NTFS. En esta página se describe la ODX a partir de un contexto de sistema de archivos y minifiltro. Para obtener información relacionada con los dispositivos de almacenamiento, consulte Transferencias de datos descargados del almacenamiento de Windows .

La transferencia de datos entre equipos o en el mismo equipo es una actividad frecuente del sistema de archivos. El uso de las funciones ReadFile y WriteFile responde 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. Esta complejidad puede afectar a la disponibilidad de los sistemas implicados en la transferencia y la red que conecta los sistemas. Las funcionalidades avanzadas disponibles en muchos subsistemas de almacenamiento aportan un medio más eficaz para realizar la tarea de alto volumen de mover datos.

Las aplicaciones pueden hacer uso de estas funcionalidades para descargar el proceso de movimiento de datos al subsistema de almacenamiento. Por lo general, los filtros del sistema de archivos pueden controlar estas acciones interceptando solicitudes de lectura y escritura en un volumen. Pero se necesitan más acciones para que los filtros puedan tener en cuenta las ODX.

Transferencias de datos típicas

Mover datos en el entorno de una aplicación es más sencillo hoy en día. Implica leer los datos en la memoria local y luego volver a escribirlos en una nueva ubicación. El siguiente diagrama ilustra este escenario.

Este modo consiste en 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 iniciado primero debe leer los datos del disco virtual de origen en un búfer local. Luego, empaqueta y transmite los datos a través de algún sistema de transporte y protocolo (como SMB mediante 1 GbE) al segundo sistema. Después, el segundo sistema recibe los datos y los envía a un búfer local. Finalmente, el sistema de destino escribe los datos en el disco virtual de destino. En este caso se describe un método típico de lectura y escritura de transferencia de datos que realizan varias veces muchas aplicaciones diferentes todos los días.

Aunque las operaciones de lectura y escritura estándar funcionan bien en la mayoría de casos, los datos que pretenden copiarse podrían 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 de vuelta a la misma matriz una vez más. La acción de trasladar los datos dentro de un servidor y a través de un transporte de red puede afectar significativamente a la disponibilidad de esos sistemas. Además, el resultado del movimiento de los datos está limitado por el rendimiento y la disponibilidad de la red.

Transferencias de datos descargados (ODX)

Descarga de transferencia de datos

Se han introducido dos FSCTL en Windows 8 que facilitan un método de descarga de la transferencia de datos. Esta descarga desplaza el proceso del movimiento de bits de los servidores a un movimiento de bits que se produce de forma inteligente dentro de los subsistemas de almacenamiento. La mejor manera de ver la semántica de comandos es pensar en ella de forma análoga a una operación de lectura y una operación de escritura no almacenadas en el búfer.

• FSCTL_OFFLOAD_READ

  Esta solicitud de control toma una posición del archivo que se vaya 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 descarga de lectura asociado. A continuación, genera un token, que es una representación lógica de los datos que se van a leer en el momento de la operación de lectura de descarga. 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 una posición dentro del archivo en el que se va a escribir, la longitud deseada de la operación de escritura y el token que es una representación lógica de los datos que se van 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 para la descarga asociado. Primero intenta reconocer el token correspondiente y después realiza la operación de escritura si es posible. La operación de escritura se completa en segundo plano en Windows y, por tanto, los componentes del sistema de archivos y las pilas de almacenamiento no ven el movimiento de los 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, en el diagrama siguiente se ve una copia de archivos sencilla entre dos discos virtuales en dos servidores diferentes.

Sin embargo, en lugar de realizar operaciones de lectura y escritura normales, descargamos el mayor volumen del movimiento de bits en la matriz de almacenamiento. El primer sistema procesa la operación de lectura de descarga, solicitando que la matriz genere un token que represente en un momento dado y visualmente 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 procesa una operación de escritura para la descarga en el segundo disco virtual con el token. Seguidamente, la matriz interpreta el token e intenta realizar el movimiento de los datos entre los discos virtuales. La transferencia de datos real se produce dentro de la matriz de almacenamiento inteligente y no entre los dos hosts. Este diseño mejora significativamente la disponibilidad de los dos sistemas, a la vez que elimina prácticamente el tráfico de red entre los sistemas.

Integración con el motor de copia

CopyFile es el que usa el motor de copia principal de Windows y sus funciones relacionadas. A partir de Windows 8, el motor de copia intenta usar ODX de forma transparente antes de la ruta de código del archivo de copia tradicional. La mayoría de las aplicaciones, las utilidades y el shell usan las API de copia. Estos autores de llamadas pueden usar funcionalidades de ODX de forma predeterminada, modificando muy poco el código, si es posible, o mediante la intervención del usuario.

En el proceso siguiente se explica resumidamente cómo el motor de copia realiza una ODX:

1. El motor de copia crea un FSCTL_OFFLOAD_READ en el archivo de origen para obtener un token de lectura.
2. Si se produce un error al recuperar el token de lectura, el motor de copia activa las operaciones de lectura y escritura tradicionales (la ruta de 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 ya no intenta realizar la descarga de los volúmenes en la memoria caché por proceso.
3. Si el token se ha recupera correctamente, el motor de copia intenta crear comandos FSCTL_OFFLOAD_WRITE en el archivo de destino en fragmentos grandes hasta que se descargan todos los datos representados lógicamente por el token.
4. Cualquier error al realizar la lectura y escritura de la descarga hace que el motor de copia vuelva a la ruta del código de lectura y escritura tradicional. Esta sistema auxiliar comienza desde donde terminó la ruta del código de descarga (donde se truncó la operación de lectura o escritura). El motor de copia actualiza la misma caché por proceso, por lo que no realiza la descarga en estos volúmenes si se cumple alguna de las condiciones siguientes. Esta caché por proceso se restablece periódicamente.

• El error indica que el volumen de destino no admite la descarga.
• El volumen de origen no puede llegar al volumen de destino.

Las siguientes funciones son compatibles con ODX:

• CopyFile
• CopyFileEx
• MoveFile
• MoveFileEx
• CopyFile2

Las siguientes funciones no son compatibles con ODX:

• CopyFileTransacted
• MoveFileTransacted

Usos de transferencias de datos descargados admitidos

Las funciones compatibles con las operaciones de descarga vienen incluidas en la pila de almacenamiento de Hyper-V y en el servidor de archivos SMB de Windows. Cuando el almacenamiento físico auxiliar admite operaciones de ODX, los autores de llamadas pueden crear FSCTL_OFFLOAD_READ y FSCTL_OFFLOAD_WRITE en archivos que residan en discos duros virtuales o en recursos compartidos de archivos remotos, ya sea a través de una máquina virtual o hardware físico. En el diagrama siguiente se ven los destinos de origen y de destino más básicos admitidos en las ODX.

Modelo de aceptación de filtros del sistema de archivos y su efecto en las aplicaciones

A partir de Windows 8, el Administrador de filtros permite que un filtro admita la funcionalidad de descarga como característica compatible. Los filtros del sistema de archivos conectados a un volumen pueden determinar de forma conjunta si se admite una determinada operación descargada. Si no se admite, se producirá un error en la operación con el código de error correspondiente.

Un filtro debe indicar que admite FSCTL_OFFLOAD_READ y FSCTL_OFFLOAD_WRITE a través de un valor de registro DWORD llamado SupportedFeatures, ubicado en la definición del servicio del controlador en el registro en HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\nombre de dispositivo de filtro\. Este valor incluye campos de bits en los que los bits determinan qué funcionalidad se ha aceptado y, además, se debe crear al instalar el 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 aceptación de filtros se puede habilitar o deshabilitar en función del valor que haya en la clave del registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\FilterSupportedFeaturesMode, que tiene los siguientes valores:

Valor FilterSupportedFeaturesMode	Significado
0 (Predeterminado)	Realice el procesamiento de aceptación normal.
1	No se acepta nunca (lo que es igual a cambiar SupportedFeatures al valor 0 en todos los filtros asociados)

Prueba

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

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

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

Como parte del procesamiento de IRP, la rutina FsRtlGetSupportedFeatures recupera el estado SupportedFeatures agrupado en todos los filtros asociados a la pila de volúmenes determinada. Los componentes como el Administrador de E/S y SRV (SMB) llaman a esta rutina para validar el estado SupportedFeatures en 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 aceptación para esa operación.

Observaciones sobre los controladores de filtro

ODX es una manera de mover datos en el centro de datos. Con motivo de la integración de la lógica de descarga en el motor de copia principal, muchas aplicaciones tienen la opción predeterminada de mover los datos descargados sin aceptarlo explícitamente. Por ello, los desarrolladores de filtros deben saber cómo afectan estas operaciones a los filtros. Si no se conocen bien estas operaciones o no se analizan los cambios en el flujo de datos, esto puede dar lugar a escenarios en los que los datos pueden ser incoherentes o terminar dañados. En la lista siguiente se presentan de forma resumida las acciones que los desarrolladores de filtros deben tener en cuenta al realizar descargas:

• Conozca este flujo de datos, sus efectos en el filtro y la capacidad del filtro para admitir estas operaciones descargadas.
• Actualice el instalador de filtro para agregar un valor REG_DWORD en SupportedFeatures a la subclave HKLM\System\CurrentControlSet\Services\[filtro]. Inicialícelo para indicar la funcionalidad de descarga.
• En el caso de los filtros que quiera aplicar tras las operaciones de descarga, actualice el registro en 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 dentro del filtro. No confíe en el valor del registro para bloquear operaciones de descarga, ya que los usuarios finales pueden cambiarlo. Un filtro debe permitir o denegar expresamente las operaciones de descarga.

Copia de tokens

Con las operaciones descargadas, la pila de E/S no ve los datos de los archivos. En vez de eso, los datos de los archivos se ven como un token de 512 bytes que es el proxy lógico de los datos. Este token es una de esta dos cosas:

• Una cadena opaca y única con un formato específico del proveedor generado por el subsistema de almacenamiento.
• 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 del token proxy hacen que el token se invalide o que el subsistema de almacenamiento conserve los datos originales mediante algunos medios específicos del proveedor, como un mecanismo de creación de instantáneas. Las solicitudes de lectura posteriores realizan la descarga en un intervalo dado en un archivo, lo que genera tokens únicos.

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

• Cuando el campo WellKnownPattern pasa a STORAGE_OFFLOAD_PATTERN_ZERO o STORAGE_OFFLOAD_PATTERN_ZERO_WITH_PROTECTION_INFORMATION, indicará el token cero. Cuando una operación FSCTL_OFFLOAD_READ devuelve este token, indicará que los datos contenidos en el rango del archivo deseado es lógicamente equivalente a cero. Cuando este token se integra en una operación FSCTL_OFFLOAD_WRITE, indicará que el rango deseado del archivo que se va a escribir debe ser cero de forma lógica.
• Aparte del token cero, no hay ningún otro patrón de token conocido que se defina 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 de los deseados en una operación de descarga. Esta condición se denomina truncamiento. Con la descarga de lectura, el token devuelto representa un rango de datos menor que los datos solicitados. El miembro TransferLength de la estructura FSCTL_OFFLOAD_READ_OUTPUT se usa para indicar este valor, que es el número de bytes desde el principio del rango del archivo que se va a leer. En el caso de la descarga de escritura, un truncamiento indica que se han escrito menos datos de los deseados. El miembro LengthWritten de la estructura FSCTL_OFFLOAD_WRITE_OUTPUT indica este valor, que es el número de bytes desde el principio del rango del archivo que se va a escribir. Los errores en el procesamiento de comandos, o las limitaciones dentro de la pila con rangos grandes, generan un truncamiento.

Hay dos situaciones en las que NTFS trunca el rango que se va a descargar de lectura o escritura:

1. El rango de copia se trunca en la Longitud de datos válida (VDL) si la VDL está antes del final del archivo (EOF). Esta acción supone que la VDL está alineada con un límite de sector lógico; si no, examine el ejemplo.

   

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

2. De forma similar al ejemplo 1, pero cuando la VDL no está alineada con el límite de sector lógico, NTFS trunca el rango deseado y lo pasa al siguiente límite del sector lógico.

   

Limitaciones

• Las operaciones de descarga solo se admiten en volúmenes NTFS.
• Las operaciones de descarga son posibles a través de servidores de archivos remotos si se cumplen las condiciones siguientes:
  • El recurso compartido remoto es un volumen NTFS.
  • El servidor ejecuta Windows Server 2012 o versiones posteriores (suponiendo que la pila remota también admita operaciones de descarga).
• NTFS no admite la descarga de FSCTL realizada en archivos cifrados con cifrado de Bitlocker o NTFS (EFS), archivos desduplicados, archivos comprimidos, archivos residentes, archivos dispersos o archivos que intervienen en transacciones TxF.
• NTFS no admite la descarga de FSCTL realizada en archivos dentro de una instantánea volsnap.
• Se genera un error en NTFS al descargar FSCTL si se cumple una de las condiciones siguientes. Este método sigue la misma semántica que la E/S sin almacenamiento en caché.
  • El rango de archivos deseado no está asignado al tamaño del sector lógico en el dispositivo de origen.
  • El rango de archivos deseado no está asignado al tamaño del sector lógico en el dispositivo de destino.
• El archivo de destino debe estar asignado previamente (SetEndOfFile y no SetAllocation) antes de FSCTL_OFFLOAD_WRITE.
• Cuando NTFS procesa las lecturas y escrituras de descarga, primero llama a CcCoherencyFlushAndPurgeCache para confirmar los datos modificados en la memoria caché del sistema. Esta acción es la misma semántica que la E/S no almacenada en caché.