Transferências de dados descarregadas do Windows

ODX (Offloaded Data Transfer) é um recurso que acelera as operações de cópia e movimentação do servidor. Esse recurso está disponível a partir do Windows Server 2012 e é suportado em volumes NTFS. Esta página descreve ODX de uma perspetiva de sistema de ficheiros e minifiltro. Para obter informações relacionadas a dispositivos de armazenamento, consulte Transferências de dados descarregadas de armazenamento do Windows.

A transferência de dados entre computadores ou dentro do mesmo computador é uma atividade frequente do sistema de arquivos. Usar as funções padrão ReadFile e WriteFile funciona bem do ponto de vista funcional, mas envolve movimentação de dados pesada através de todos os níveis do sistema e, potencialmente, através de uma rede. Esta complexidade pode afetar a disponibilidade dos sistemas envolvidos na transferência e da rede que liga os sistemas. Os recursos avançados disponíveis com muitos subsistemas de armazenamento fornecem um meio mais eficiente de executar a tarefa pesada de movimentação de dados.

Os aplicativos podem aproveitar esses recursos para ajudar a descarregar o processo de movimentação de dados para o subsistema de armazenamento. Normalmente, os filtros do sistema de arquivos podem monitorar essas ações intercetando solicitações de leitura e gravação em um volume. Mais ações são necessárias para que os filtros estejam cientes das ODXs.

Transferências de dados típicas

Mover dados em um cenário de aplicativo hoje é mais simples. Envolve a leitura dos dados na memória local e, em seguida, gravá-los de volta para um novo local. O diagrama a seguir ilustra esse cenário.

Esse cenário envolve a cópia de um arquivo entre dois locais em dois servidores de arquivos diferentes, cada um com seu próprio disco virtual exposto por meio de um ISA (Intelligent Storage Array). O sistema iniciador primeiro precisa ler os dados do disco virtual de origem em um buffer local. Em seguida, empacota e transmite os dados através de algum transporte e protocolo (como SMB acima de 1 GbE) para o segundo sistema. O segundo sistema então recebe os dados e os envia para um buffer local. Em seguida, o sistema de destino grava os dados no disco virtual de destino. Este cenário descreve um método típico de leitura/gravação de transferência de dados que é executado várias vezes por muitos aplicativos diferentes todos os dias.

Embora as leituras e gravações padrão funcionem bem na maioria dos cenários, os dados que pretendem ser copiados podem estar localizados em discos virtuais gerenciados pelo mesmo Intelligent Storage Array. Essa situação significa que os dados são movidos para fora da matriz, para um servidor, através de um transporte de rede, para outro servidor e de volta para a mesma matriz mais uma vez. O ato de mover dados dentro de um servidor e através de um transporte de rede pode afetar significativamente a disponibilidade desses sistemas. Além disso, a taxa de transferência da movimentação de dados é limitada pela taxa de transferência e disponibilidade da rede.

Transferências de dados descarregadas (ODX)

Descarregando a transferência de dados

Dois FSCTLs foram introduzidos no Windows 8 que facilitam um método de otimização na transferência de dados. Esse descarregamento desloca a carga do movimento de bits dos servidores para o movimento de bits que ocorre de forma inteligente nos subsistemas de armazenamento. A melhor maneira de visualizar a semântica de comandos é pensá-los como análogos a uma leitura sem buffer e uma gravação sem buffer.

• FSCTL_OFFLOAD_READ

  Este pedido de controlo inclui um deslocamento dentro do arquivo a ser lido e um comprimento desejado na estrutura FSCTL_OFFLOAD_READ_INPUT. Caso seja suportado, o subsistema de armazenamento que hospeda o arquivo recebe o comando de leitura de descarregamento de armazenamento associado. Em seguida, ele gera um token, que é uma representação lógica dos dados destinados a serem lidos no momento do comando offload read. Essa cadeia de caracteres de token é retornada ao chamador na estrutura FSCTL_OFFLOAD_READ_OUTPUT .

• FSCTL_OFFLOAD_WRITE

  Esta solicitação de controlo aceita um offset dentro do ficheiro onde se está a escrever, o comprimento desejado para a escrita e o token, que é uma representação lógica dos dados a serem gravados. Se suportado, o subsistema de armazenamento que hospeda o arquivo a ser gravado recebe o comando associado de gravação offload. Ele primeiro tenta reconhecer o token fornecido e, em seguida, executa a operação de gravação, se possível. A operação de gravação é concluída no Windows e, portanto, os componentes no sistema de arquivos e nas pilhas de armazenamento não veem a movimentação de dados. Quando a movimentação de dados estiver concluída, o número de bytes gravados será retornado ao chamador.

Semelhante ao primeiro diagrama, o diagrama a seguir mostra uma cópia de arquivo simples entre dois discos virtuais em dois servidores diferentes.

No entanto, em vez de fazer leituras e gravações normais, descarregamos o trabalho pesado do movimento de bits para a matriz de armazenamento. O primeiro sistema emite a operação de leitura de descarregamento, solicitando que a matriz gere um token que represente uma visualização point-in-time dos dados a serem lidos dentro da região do primeiro disco virtual. O primeiro sistema então transmite o token para o segundo sistema, que por sua vez emite uma operação de gravação offload para o segundo disco virtual com o token. Em seguida, a matriz interpreta o token e tenta executar a movimentação de dados entre os discos virtuais. A transferência de dados real ocorre dentro da matriz de armazenamento inteligente, e não entre os dois hosts. Este design melhora significativamente a disponibilidade dos dois sistemas, eliminando virtualmente o tráfego de rede entre os sistemas.

Integração com o mecanismo de cópia

O mecanismo de cópia principal no Windows é usado por CopyFile e funções relacionadas. A partir do Windows 8, o mecanismo de cópia tenta usar ODX de forma transparente antes do caminho de código de arquivo de cópia tradicional. As APIs de cópia são usadas pela maioria dos aplicativos, utilitários e pelo shell. Esses chamadores são capazes de usar recursos ODX por padrão com pouca, ou nenhuma, modificação de código ou intervenção do usuário.

As etapas a seguir resumem como o mecanismo de cópia tenta uma ODX:

1. O mecanismo de cópia emite um FSCTL_OFFLOAD_READ no arquivo de origem para obter um token de leitura.
2. Se houver uma falha na recuperação do token de leitura, o mecanismo de cópia retornará às leituras e gravações tradicionais (o caminho de código do arquivo de cópia tradicional). Se a falha indicar que o volume de origem não suporta descarga, o mecanismo de cópia também marcará o volume em um cache por processo. O mecanismo de cópia não tenta mais descarregar os volumes no cache por processo.
3. Se o token for recuperado com êxito, o mecanismo de cópia tenta emitir comandos FSCTL_OFFLOAD_WRITE no ficheiro de destino em grandes partes até que todos os dados que são logicamente representados pelo token sejam escritos de forma descarregada.
4. Quaisquer erros na execução do descarregamento de leitura/gravação resultam no mecanismo de cópia caindo de volta para o caminho de código de leitura/gravação tradicional. Este fallback começa exatamente do ponto onde o caminho do código de transferência terminou, ou seja, onde a leitura ou gravação foi truncada. O mecanismo de cópia atualiza o mesmo cache por processo para que não tente descarregar nesses volumes se uma das seguintes condições for verdadeira. O cache por processo é redefinido periodicamente.

• A falha indica que o volume de destino não suporta descarga.
• O volume de origem não pode atingir o volume de destino.

As seguintes funções suportam ODXs:

• CopyFile
• CopyFileEx
• MoveFile
• MoveFileEx
• CopyFile2

As seguintes funções não suportam ODXs:

• CopyFileTransacted
• MoveFileTransacted

Cenários de transferência de dados de descarregamento suportados

O apoio às operações de descarga é fornecido na pilha de armazenamento Hyper-V e no Servidor de Ficheiros SMB do Windows. Onde o armazenamento físico de backup suporta operações ODX, os chamadores podem emitir FSCTL_OFFLOAD_READ e FSCTL_OFFLOAD_WRITE para arquivos que residem em VHDs ou em compartilhamentos de arquivos remotos, seja de dentro de uma máquina virtual ou em hardware físico. O diagrama a seguir ilustra os destinos de origem e destino suportados mais básicos para ODXs.

Modelo de aceitação do filtro do sistema de arquivos e efeito nos aplicativos

A partir do Windows 8, o Gerenciador de Filtros permite que um filtro especifique a capacidade de descarregamento como um recurso suportado. Os filtros do sistema de arquivos anexados a um volume podem determinar coletivamente se uma determinada operação descarregada é suportada. Se não for suportado, a operação falhará com um código de erro apropriado.

Um filtro deve indicar que ele suporta FSCTL_OFFLOAD_READ e FSCTL_OFFLOAD_WRITE através de um valor DWORD do registro chamado SupportedFeatures, localizado na definição de serviço de driver no registro em HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\nome do driver de filtro\. Esse valor contém campos de bits onde os bits determinam qual funcionalidade é aceita e deve ser definido durante a instalação do filtro.

Atualmente, os bits definidos são:

O modelo de aceitação do filtro pode ser habilitado ou desabilitado com base no valor presente na chave do Registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\FilterSupportedFeaturesMode, que tem os seguintes valores:

Testes

Para verificar as funcionalidades de um filtro suportadas pela pilha, utilize o utilitário fltmc. Execute o comando instâncias fltmc –v [volume]: como um utilizador com privilégios elevados e verifique a coluna SprtFtrs:

• Se o valor SprtFtrs for 0x00, implica que o filtro está impedindo o descarregamento nesse volume. Se SprtFtrs estiver definido como 0x03, ambas as operações de descarregamento serão suportadas.

Verificando o suporte a recursos no processamento de IRP

Como parte do processamento de IRP, a rotina FsRtlGetSupportedFeatures recupera o estado agregado SupportedFeatures para todos os filtros anexados à pilha de volumes fornecida. Componentes como o Gestor de E/S e o SRV (SMB) chamam esta rotina para validar o estado de SupportedFeatures para todos os filtros da pilha. Os componentes que rolam seus próprios IRPs de descarregamento devem chamar essa função para validar o suporte de aceitação para essa operação.

Considerações para drivers de filtro

ODX é uma maneira de mover dados no data center. Devido à integração da lógica de descarregamento no motor de cópia principal, muitos aplicativos têm, por padrão, a capacidade de executar a movimentação de dados descarregados sem optar explicitamente por isso. Como resultado, os desenvolvedores de filtros precisam entender como essas operações afetam os filtros. Não compreender essas operações completamente ou não avaliar a alteração no fluxo de dados pode resultar em cenários em que os dados podem se tornar inconsistentes ou corrompidos. A lista a seguir resume um conjunto de itens de ação para os desenvolvedores de filtros tomarem nota com o descarregamento:

• Entenda esse fluxo de dados, o efeito no filtro e a capacidade do filtro de suportar essas operações descarregadas.
• Atualize o instalador do filtro para adicionar um valor REG_DWORD para SupportedFeatures à subchave HKLM\System\CurrentControlSet\Services\[filter]. Inicialize-o para especificar a funcionalidade de descarregamento.
• Para filtros que desejam atuar em operações de descarga, atualize o registro para IRP_MJ_FILE_SYSTEM_CONTROL para lidar com FSCTL_OFFLOAD_READ e FSCTL_OFFLOAD_WRITE.
• Para filtros que precisam bloquear operações descarregadas, retorne o código de status STATUS_NOT_SUPPORTED de dentro do filtro. Não confie no valor do registro para bloquear operações de descarregamento, pois os utilizadores finais podem alterá-lo. Um filtro deve permitir ou proibir explicitamente operações de transferência.

Copiar tokens

Com operações descarregadas, a pilha de E/S não vê os dados do ficheiro. Em vez disso, os dados do arquivo são vistos como um token de 512 bytes que é o proxy lógico para os dados. Este token é uma das seguintes opções:

• Uma cadeia de caracteres opaca e exclusiva de um formato específico do fornecedor gerada pelo subsistema de armazenamento.
• Um tipo bem conhecido para representar um padrão de dados (como um intervalo de dados que é logicamente equivalente a zero).

As modificações nos dados do token de proxy resultam na invalidação do token ou na persistência dos dados originais pelo subsistema de armazenamento por meio de métodos específicos do fornecedor, como, por exemplo, um mecanismo de snapshot. Solicitações de leitura de descarregamento subsequentes para um intervalo especificado em um arquivo resultam em tokens exclusivos.

Existem classes de tokens que representam um padrão de dados bem definido. O token mais conhecido é o Zero Token, que é equivalente a zero. Quando um token é definido como um Token Bem Conhecido, o membro TokenType na estrutura STORAGE_OFFLOAD_TOKEN é definido como STORAGE_OFFLOAD_TOKEN_TYPE_WELL_KNOWN. Quando esse campo é definido, o membro WellKnownPattern determina qual padrão de dados é o token.

• Quando o campo WellKnownPattern é definido como STORAGE_OFFLOAD_PATTERN_ZERO ou STORAGE_OFFLOAD_PATTERN_ZERO_WITH_PROTECTION_INFORMATION, ele indica o Token Zero. Quando esse token é retornado por uma operação FSCTL_OFFLOAD_READ , ele indica que os dados contidos no intervalo de arquivos desejado são logicamente equivalentes a zero. Quando esse token é fornecido para uma operação FSCTL_OFFLOAD_WRITE , ele indica que o intervalo desejado do arquivo a ser gravado deve ser logicamente zerado.
• Além do Token Zero, não há outros padrões de Token Bem Conhecido atualmente definidos. Não é recomendado que os utilizadores definam os seus próprios padrões de Well Known Token.

Truncamento

O subsistema de armazenamento subjacente com o qual o Windows se comunica pode processar menos dados desejados em uma operação de descarregamento. Esta condição é chamada de truncamento. Durante a leitura de descarregamento, o símbolo retornado representa uma gama de dados inferior aos dados solicitados. O membro TransferLength na estrutura FSCTL_OFFLOAD_READ_OUTPUT é usado para indicar esse valor, que é uma contagem de bytes do início do intervalo do arquivo a ser lido. Para gravação offload, um truncamento indica que foram gravados menos dados do que o desejado. O membro LengthWritten na estrutura FSCTL_OFFLOAD_WRITE_OUTPUT indica esse valor, que é uma contagem de bytes do início do intervalo do arquivo a ser gravado. Erros no processamento de comandos, ou limitações dentro da pilha para grandes intervalos, resultam em truncamento.

Há dois cenários em que o NTFS trunca o intervalo a ser descarregado lido ou gravado:

1. O intervalo de cópia é truncado para VDL (Valid Data Length) se VDL estiver antes do End of the File (EOF). Esta ação pressupõe que o VDL está alinhado a um limite de setor lógico, caso contrário, veja o cenário.

   

   Durante uma operação FSCTL_OFFLOAD_READ, o sinalizador OFFLOAD_READ_FLAG_ALL_ZERO_BEYOND_CURRENT_RANGE é definido na estrutura FSCTL_OFFLOAD_READ_OUTPUT, indicando que o restante do arquivo contém zeros, e o membro TransferLength é truncado para VDL.

2. Semelhante ao Cenário 1, mas quando o VDL não está alinhado a um limite de setor lógico, o NTFS trunca o intervalo desejado para o próximo limite de setor lógico.

   

Limitações

• As operações de descarregamento são suportadas apenas em volumes NTFS.
• As operações de descarregamento são suportadas por meio de servidores de arquivos remotos se as seguintes condições forem verdadeiras:
  • O compartilhamento remoto é um volume NTFS.
  • O servidor está a correr Windows Server 2012 ou versões posteriores (supondo que a pilha remota também ofereça suporte a operações de delegação).
• O NTFS não suporta FSCTLs de descarregamento realizadas em ficheiros encriptados com encriptação Bitlocker ou NTFS (EFS), ficheiros desduplicados, ficheiros comprimidos, ficheiros residentes, ficheiros esparsos ou ficheiros que participam em transações TxF.
• O NTFS não suporta FSCTLs de descarregamento executadas em arquivos dentro de um instantâneo volsnap.
• O NTFS não processará o FSCTL de transferência se uma das seguintes condições se verificar. Esta abordagem segue a mesma semântica da E/S sem cache.
  • O intervalo de arquivos desejado não está alinhado ao tamanho do setor lógico no dispositivo de origem.
  • O intervalo de arquivos desejado não está alinhado ao tamanho do setor lógico no dispositivo de destino.
• O ficheiro de destino deve ser pré-alocado (SetEndOfFile e não SetAllocation) antes de FSCTL_OFFLOAD_WRITE.
• Quando o NTFS processa o descarregamento de leituras e gravações, ele primeiro chama CcCoherencyFlushAndPurgeCache para confirmar quaisquer dados modificados no cache do sistema. Esta ação tem a mesma semântica que a E/S não armazenada em cache.