Transferência de dados descarregados de armazenamento do Windows

O Windows Offloaded Data Transfer (ODX) é um recurso que acelera as operações de cópia e movimentação do servidor. Está disponível a partir do Windows Server 2012 e é suportado em volumes NTFS.

Este artigo descreve a ODX de uma perspetiva de dispositivo de armazenamento. Para obter informações relacionadas a sistemas de arquivos e minifiltros, consulte Transferências de dados descarregadas.

Visão geral

Em vez de copiar grandes quantidades de dados durante as transferências de arquivos, o Windows ODX introduziu uma operação tokenizada para mover dados em dispositivos de armazenamento. O arquivo de origem e um arquivo de destino podem estar em qualquer um dos seguintes locais:

• No mesmo volume.
• Em dois volumes diferentes que a mesma máquina hospeda.
• Num volume local e num volume remoto utilizando o Server Message Block (SMB2 ou SMB3).
• Em dois volumes em duas máquinas diferentes através de SMB2 ou SMB3.

O processo de uma operação de cópia offload em dispositivos de armazenamento compatíveis com ODX é mostrado no diagrama a seguir.

1. O aplicativo de cópia envia uma solicitação de leitura de descarregamento para o gerenciador de cópias do dispositivo de armazenamento de origem.
2. O gerenciador de cópias de origem retorna um token. O token é uma representação de dados (ROD) a serem copiados.
3. A aplicação envia um pedido de descarga com token para o gestor de cópias do dispositivo de armazenamento de destino.
4. O gerenciador de cópias da matriz de armazenamento move os dados do dispositivo de origem para o dispositivo de destino e retorna o resultado da gravação de descarregamento para o aplicativo.

Identificar uma origem e um destino ODX-Capable

Para oferecer suporte ao ODX, as matrizes de armazenamento devem implementar as especificações padrão T10 relacionadas para matrizes de armazenamento compatíveis com ODX, incluindo operações de leitura e gravação descarregadas com tokens. Durante a enumeração do dispositivo LUN (uma inicialização do sistema ou um evento plug-and-play), o Windows coleta ou atualiza as informações de capacidade ODX do dispositivo de destino de armazenamento por meio das etapas a seguir.

1. Capacidade de descarregamento de cópia de consulta.
2. Reúna os parâmetros necessários para operações de descarregamento de cópia e suas limitações.

Por padrão, o Windows tenta o caminho ODX primeiro para uma operação de cópia se os LUNs de origem e de destino forem compatíveis com ODX. Se o dispositivo de armazenamento falhar na solicitação ODX inicial, o Windows marcará a combinação do LUN de origem e de destino como um caminho "não compatível com ODX" e seguirá o caminho de código do arquivo de cópia herdado.

Operações de leitura/gravação ODX

Adoção de comandos síncronos e APIs

Uma grande solicitação de gravação de descarregamento é dividida usando o seguinte algoritmo para garantir uma gravação de descarregamento síncrona robusta.

• Se o dispositivo de armazenamento de destino não fornecer um tamanho de transferência ideal, defina o tamanho de transferência ideal em 64 MB.
• Se o tamanho de transferência ideal definido pelo dispositivo alvo for superior a 256 MB, defina o tamanho de transferência ideal em 256 MB.
• O tamanho de transferência ideal especificado pelo dispositivo de destino de armazenamento é maior que zero e menor que 256 MB.

Os comandos SCSI de leitura e escrita de descarregamento síncronas reduzem a complicação dos cenários de MPIO e de failover de cluster. O Windows espera que o gerenciador de cópias conclua os comandos SCSI de leitura/gravação de descarregamento síncrono em 4 segundos.

Os aplicativos podem usar FSCTL, DSM IOCTL ou APIs SCSI_PASS_THROUGH para interagir com matrizes de armazenamento e executar operações de descarregamento de cópia. Para evitar corrupção de dados ou instabilidade do sistema, o Windows restringe os aplicativos de gravar diretamente em um volume montado no sistema de arquivos sem primeiro obter acesso exclusivo ao volume. Essa restrição é necessária devido à condição de que uma gravação no volume pode colidir com as gravações do sistema de arquivos. Quando tais colisões ocorrem, o conteúdo do volume pode ser deixado em um estado inconsistente.

Operações de leitura de descarga

A solicitação de leitura de descarregamento de um aplicativo pode especificar o tempo de vida do token (tempo limite de inatividade). Se o aplicativo definir o tempo de vida do token como zero, o temporizador de inatividade padrão será usado como o tempo de vida do token. O gerenciador de cópias do storage array mantém e valida o token de acordo com seu valor de tempo limite de inatividade e credenciais. O host do Windows também limita o número de fragmentos de arquivo a 64. Se a solicitação de leitura de descarregamento consistir em mais de 64 fragmentos, o Windows falhará a solicitação de descarregamento de cópia e retornará à operação de cópia tradicional.

Depois de concluir a solicitação de leitura de download, o gestor de cópias prepara um token de representação de dados (ROD) para o comando de recebimento do resultado da leitura de download. O campo de token ROD especifica a representação point-in-time dos dados do usuário e informações de proteção. O ROD pode ser dados do usuário em formato "aberto exclusivamente" ou "aberto com compartilhamento". O gerenciador de cópias pode invalidar o token de acordo com sua configuração de política de ROD. Se o ROD estiver "aberto exclusivamente" para uma operação de descarregamento de cópia, o token ROD poderá ser invalidado quando o ROD for modificado ou movido. Se o ROD estiver no formato "aberto com compartilhamento", o token ROD permanecerá válido quando o ROD for modificado. Um token ROD é de 512 bytes com o seguinte formato:

Como o token ROD é concedido e consumido apenas pela matriz de armazenamento, seu formato é opaco, exclusivo e altamente seguro. Se o token for modificado, não validado ou expirado, o gerenciador de cópias poderá invalidá-lo durante a operação de gravação de descarregamento. O token ROD retornado da operação de leitura de descarregamento possui um valor de tempo limite inativo para indicar o número de segundos durante os quais o gestor de cópias deve manter o token válido para o próximo uso de Escrever com Token.

Operações de descarregamento de gravação

Depois que o aplicativo recebe o token ROD do gerenciador de cópias, ele envia a solicitação de gravação de descarregamento com o token ROD para o gerenciador de cópias da matriz de armazenamento. Quando um comando de gravação de descarregamento síncrono é enviado para o dispositivo de destino, o Windows espera que o gerenciador de cópias conclua o comando em 4 segundos. Se o comando for encerrado devido ao tempo limite do comando ou outras condições de erro, o Windows falhará no comando. A aplicação recorre à operação de cópia antiga de acordo com o código de status retornado.

A solicitação de gravação de descarregamento pode ser concluída com um ou vários comandos Receive Offload Write Result. Se a gravação de descarregamento for parcialmente concluída, o gerenciador de cópias retornará com o atraso estimado e o número de contagens de transferência para indicar o progresso da cópia. O número de contagens de transferência especifica o número de blocos lógicos contíguos que foram gravados sem erro da mídia de origem para a mídia de destino. O gerenciador de cópias pode executar gravações de descarregamento em um padrão sequencial ou de dispersão/coleta.

Quando ocorre uma falha de gravação, o progresso da operação de cópia conta blocos lógicos contíguos do primeiro bloco lógico até ao bloco de falha. A aplicação cliente ou motor de cópia retoma a gravação de offload a partir do bloco de falha de gravação. Quando a gravação de descarregamento é concluída, o gerenciador de cópias conclui o comando Receive ROD Token Information com:

• O atraso na atualização de estado estimado foi definido como zero.
• O progresso da transferência de dados está em 100 por cento.

Se o resultado de gravação de descarregamento de recebimento retornar o mesmo progresso da contagem de transferência de dados, o Windows falhará a operação de cópia de volta para o aplicativo após quatro tentativas.

Um aplicativo cliente também pode executar a operação de gravação de descarregamento com um token ROD bem conhecido, que é um token ROD predefinido com um padrão de dados conhecido e formato de token. Uma implementação comum é chamada de token zero. Um aplicativo cliente pode usar um token zero para preencher um ou mais intervalos de blocos lógicos com zeros. Se o token conhecido não for suportado ou reconhecível, o gestor de cópias falhará na solicitação de gravação de transferência com "Token inválido". Um token ROD bem conhecido é de 512 bytes com o seguinte formato:

Numa escrita de offload com um ROD token conhecido, uma aplicação cliente não pode usar uma leitura de offload para solicitar um ROD token conhecido. O gerenciador de cópias verifica e mantém os tokens ROD conhecidos de acordo com sua própria política.

Parâmetros de ajuste de desempenho da implementação ODX

O desempenho da ODX não depende das velocidades do link de transporte da rede cliente-servidor ou da SAN (Storage Area Network, rede de área de armazenamento) entre o servidor e a matriz de armazenamento. O gerenciador de cópias e os servidores de dispositivos da matriz de armazenamento movem os dados.

Nem todo descarregamento de cópia se beneficia da tecnologia ODX. Por exemplo, o gerenciador de cópias de uma matriz de armazenamento iSCSI de 1 Gbit pode concluir uma cópia de arquivo de 3 GB em 10 segundos e a taxa de transferência de dados será maior que 300 MB por segundo. A taxa de transferência de dados já supera a velocidade máxima de transferência teórica da interface Ethernet de 1 Gbit.

Além disso, é possível que o desempenho de cópia para arquivos de um determinado tamanho não se beneficie da tecnologia ODX. Para otimizar o desempenho, o uso de ODX pode ser restrito a um tamanho mínimo de arquivo permitido e comprimentos máximos de cópia. Observação:

• O Windows define um requisito de tamanho mínimo de arquivo para operações de descarregamento de cópia em 256 KB no mecanismo de cópia. Se um arquivo tiver menos de 256 KB, o mecanismo de cópia retornará ao processo de cópia herdado.

• O host Windows usa um tamanho máximo de transferência de token e uma contagem de transferência ideal para preparar o tamanho de transferência ideal de um comando SCSI de leitura ou gravação de descarregamento. O tamanho total da transferência em número de blocos não deve exceder o tamanho máximo da transferência de token. Se a matriz de armazenamento não relatar uma contagem de transferência ideal, o Windows usará 64 MB como a contagem padrão.

Os parâmetros de comprimento de transferência ótimo e máximo especificam o número ótimo e máximo de blocos em um descritor de intervalo. Os aplicativos de descarregamento de cópia podem estar em conformidade com esses parâmetros para alcançar o desempenho ideal de transferência de arquivos.

Tratamento de erros ODX e suporte de alta disponibilidade

Quando uma operação ODX falha em uma solicitação de cópia de arquivo, o mecanismo de cópia e o sistema de arquivos do Windows (NTFS) retornam à operação de cópia herdada. Se a cópia offload falhar no meio da operação de escrita offload, o motor de cópia e o NTFS retomarão com a operação de cópia herdada a partir do primeiro ponto de falha na escrita offload.

Tratamento de erros ODX

A ODX usa um algoritmo robusto de tratamento de erros de acordo com os recursos do storage array. Se o descarregamento de cópia falhar em um caminho compatível com ODX, o host do Windows espera que o aplicativo retorne à operação de cópia herdada. Neste ponto, o mecanismo de cópia do Windows já implementou o "fallback" para a cópia tradicional. Após a falha de descarregamento da cópia, o NTFS marca o LUN de origem e de destino como não compatível com ODX por três minutos. Após esse período de tempo, o mecanismo de cópia do Windows tenta novamente a operação ODX. Uma matriz de armazenamento pode usar esse recurso para desativar temporariamente o suporte a ODX em alguns caminhos durante situações altamente estressantes.

Failover de ODX no MPIO e configurações de servidores em cluster

As operações de descarga de leitura e gravação devem ser concluídas ou canceladas a partir da mesma conexão de armazenamento (I_T nexus).

Quando ocorre um failover de MPIO ou de servidor de cluster durante uma operação de leitura ou escrita de offload síncrono, o Windows lida com o failover da seguinte maneira:

• Se acontecer um failover de caminho MPIO, o Windows volta a tentar executar o comando ODX com falha. Se o comando falhar novamente, o Windows:

  • Inicia um failover de um nó de servidor no contexto de um servidor de cluster.
  • Emite uma redefinição de LUN para o dispositivo de armazenamento e retorna um estado de falha de E/S para a aplicação se o failover do servidor de cluster não for uma opção.

• Em uma configuração de servidor de cluster, o serviço de armazenamento de cluster realiza failover para o próximo nó de cluster preferencial e, em seguida, retoma o serviço de armazenamento de cluster. O aplicativo de descarregamento deve ter reconhecimento de cluster para poder repetir o comando de leitura/gravação de descarregamento após o failover do serviço de armazenamento de cluster.

Se o comando de leitura ou gravação de descarregamento falhar após o failover do caminho MPIO e do nó do cluster, o Windows emitirá uma redefinição de LUN para o dispositivo de armazenamento após o failover. O dispositivo de armazenamento encerra todos os comandos pendentes e operações pendentes no LUN.

Atualmente, o Windows não emite comandos SCSI de descarregamento assíncrono de leitura ou gravação da pilha de armazenamento.

Modelos de uso ODX

ODX em disco físico, disco rígido virtual e disco compartilhado SMB

Para executar operações ODX, o servidor de aplicativos deve ter acesso ao LUN de origem e ao LUN de destino com privilégios de leitura/gravação. O aplicativo de descarregamento de cópia emite uma solicitação de leitura de descarregamento para o LUN de origem e recebe um token do gerenciador de cópias do LUN de origem. As aplicações de descarregamento de cópia utilizam o token para emitir um pedido de escrita de descarregamento para o LUN de destino. Em seguida, o gerenciador de cópias move os dados do LUN de origem para o LUN de destino através da rede de armazenamento. O diagrama a seguir ilustra os alvos de origem e de destino mais básicos suportados para transferências de dados processadas externamente.

Operação ODX com um servidor

Em uma configuração de servidor único, a aplicação de cópia de descarga emite as solicitações de leitura e escrita de descarregamento do mesmo servidor.

O servidor de origem (ou VM de origem) tem acesso ao LUN de origem (VHD ou disco físico) e ao LUN de destino (VHD ou disco físico). O aplicativo de descarregamento de cópia emite uma solicitação de leitura de descarregamento para o LUN de origem e recebe o token do LUN de origem. Em seguida, o aplicativo de descarregamento de cópia usa o token para emitir uma solicitação de gravação de descarregamento para o LUN de destino. O gerenciador de cópias move os dados do LUN de origem para o LUN de destino dentro do mesmo storage array.

Operação ODX com dois servidores

Na configuração de dois servidores, há dois servidores e várias matrizes de armazenamento gerenciadas pelo mesmo gerenciador de cópias.

• Um servidor (ou VM) é o host do LUN de origem e o outro servidor (ou VM) é o host do LUN de destino. O servidor de origem compartilha o LUN de origem com o cliente de aplicativo por meio do protocolo SMB, e o servidor de destino também compartilha o LUN de destino com o cliente de aplicativo por meio do protocolo SMB. Assim, o cliente do aplicativo tem acesso ao LUN de origem e ao LUN de destino.
• Os storage arrays de origem e destino são gerenciados pelo mesmo gerenciador de cópias em uma configuração de SAN.
• Do sistema cliente do aplicativo, o aplicativo de descarregamento de cópia emite uma solicitação de leitura de descarregamento para o LUN de origem e recebe o token do LUN de origem e, em seguida, emite uma solicitação de gravação de descarregamento com o token para o LUN de destino. O gerenciador de cópias move os dados do LUN de origem para o LUN de destino em dois storage arrays diferentes em dois locais diferentes.

Migração massiva de dados

A migração massiva de dados é o processo de importação de uma grande quantidade de dados, como registros de banco de dados, planilhas, arquivos de texto, documentos digitalizados e imagens para um novo sistema. A migração de dados pode ser causada por um upgrade do sistema de armazenamento, um novo mecanismo de banco de dados ou alterações no aplicativo ou no processo de negócios. A ODX pode ser usada para migrar dados de um sistema de armazenamento herdado para um novo sistema de armazenamento quando o gerenciador de cópias do novo sistema também pode gerenciar o sistema herdado.

• Um servidor é o host do sistema de armazenamento herdado e o outro servidor é o host do novo sistema de armazenamento. O servidor de origem compartilha o LUN de origem como o cliente do aplicativo de migração de dados por meio do protocolo SMB, e o servidor de destino compartilha o LUN de destino como o cliente do aplicativo de migração de dados por meio do protocolo SMB. Assim, o cliente do aplicativo tem acesso ao LUN de origem e de destino.
• O sistema de armazenamento herdado e o novo sistema de armazenamento são gerenciados pelo mesmo gerenciador de cópias em uma configuração de SAN.
• A partir do sistema cliente do aplicativo de migração de dados, o aplicativo de descarregamento de cópia emite uma solicitação de leitura de descarregamento para o LUN de origem e recebe o token do LUN de origem. Em seguida, a aplicação emite um pedido de escrita de offload com o token para o LUN de destino. O gerenciador de cópias move os dados do LUN de origem para o LUN de destino em dois sistemas de armazenamento diferentes em dois locais diferentes.
• A migração massiva de dados também pode ser operada com um servidor no mesmo local.

Host-Controlled transferência de dados num dispositivo de armazenamento hierárquico

Um dispositivo de armazenamento hierárquico categoriza os dados em diferentes tipos de mídia de armazenamento para reduzir custos, aumentar o desempenho e resolver problemas de capacidade. As categorias podem ser baseadas nos níveis de proteção necessários, requisitos de desempenho, frequência de uso e outras considerações.

A estratégia de migração de dados desempenha um papel importante no resultado final de uma estratégia de armazenamento hierárquico. A ODX permite a migração de dados controlada pelo host dentro do dispositivo de armazenamento hierárquico. O exemplo a seguir descreve a ODX em um dispositivo de armazenamento de duas camadas:

• O servidor é o host do sistema de armazenamento hierárquico. O LUN de origem é o dispositivo de armazenamento Tier1 e o LUN de destino é o dispositivo de armazenamento Tier2.
• O mesmo gerenciador de cópias gerencia todos os dispositivos de armazenamento hierárquico.
• A partir do sistema do servidor, o aplicativo de migração de dados emite uma solicitação de leitura de descarregamento para o LUN de origem e recebe o token do LUN de origem. Em seguida, este aplicativo emite uma solicitação de gravação offload com o token para o LUN de destino. O gerenciador de cópias move os dados do LUN de origem para o LUN de destino em dois dispositivos de armazenamento de camadas diferentes.
• Quando a tarefa de migração de dados é concluída, o aplicativo exclui os dados do dispositivo de armazenamento Tier1 e recupera o espaço de armazenamento.