Escolher políticas de hierarquização na nuvem
Este artigo fornece orientação sobre como selecionar e ajustar políticas de hierarquização na nuvem para o Azure File Sync. Antes de ler este artigo, certifique-se de entender como funciona a hierarquização na nuvem. Para obter os fundamentos da hierarquização na nuvem, consulte Compreender a hierarquização da nuvem do Azure File Sync. Para obter uma explicação detalhada das políticas de hierarquização na nuvem com exemplos, consulte Políticas de hierarquização na nuvem do Azure File Sync.
Limitações
A hierarquização da nuvem não é suportada no volume do sistema Windows.
Se você estiver usando o Gerenciador de Recursos de Servidor de Arquivos (FSRM) para gerenciamento de cotas em pontos de extremidade de servidor, recomendamos aplicar as cotas no nível de pasta e não no nível de volume. Você ainda pode habilitar a hierarquização na nuvem se tiver uma cota de FSRM no nível de volume. Depois que uma cota FSRM é definida, as APIs de consulta de espaço livre que são chamadas relatam automaticamente o espaço livre no volume de acordo com a configuração de cota. No entanto, quando uma cota rígida está presente em uma raiz de volume, o espaço livre real no volume e o espaço restrito de cota no volume podem não ser os mesmos. Isso pode causar interminável hierarquização se o Azure File Sync achar que não há espaço livre de volume suficiente no ponto de extremidade do servidor.
Tamanho mínimo de um arquivo para a camada
O tamanho mínimo de um arquivo para a camada é baseado no tamanho do cluster do sistema de arquivos. O tamanho mínimo de ficheiro elegível para hierarquização na nuvem é calculado em 2x o tamanho do cluster e num mínimo de 8 KiB. A tabela a seguir ilustra os tamanhos mínimos de arquivo que podem ser hierarquizados, com base no tamanho do cluster de volume:
| Tamanho do cluster de volume | Arquivos desse tamanho ou maiores podem ser hierarquizados |
|---|---|
| 4 KiB ou inferior (4.096 bytes) | 8 KiB |
| 8 KiB (8.192 bytes) | 16 KiB |
| 16 KiB (16.384 bytes) | 32 KiB |
| 32 KiB (32.768 bytes) | 64 KiB |
| 64 KiB (65.536 bytes) | 128 KiB |
| 128 KiB (131.072 bytes) | 256 KiB |
| 256 KiB (262.144 bytes) | 512 KiB |
| 512 KiB (524.288 bytes) | 1 MiB |
| 1 MiB (1.048.576 bytes) | 2 MiB |
| 2 MiB (2.097.152 bytes) | 4 MiB |
A Sincronização de Ficheiros do Azure suporta a hierarquização da nuvem em volumes com tamanhos de cluster até 2 MiB.
Todos os sistemas de ficheiros utilizados pelo Windows organizam o disco rígido com base no tamanho do cluster (também conhecido como tamanho da unidade de alocação). O tamanho do cluster representa a menor quantidade de espaço em disco que pode ser usada para armazenar um arquivo. Quando os tamanhos de arquivo não saem para um múltiplo uniforme do tamanho do cluster, espaço adicional deve ser usado para manter o arquivo - até o próximo múltiplo do tamanho do cluster.
O Azure File Sync tem suporte em volumes NTFS com o Windows Server 2012 R2 e versões mais recentes. A tabela a seguir descreve os tamanhos de cluster padrão quando você cria um novo volume NTFS com o Windows Server.
| Volume size | Windows Server |
|---|---|
| 7 MiB – 16 TiB | 4 KiB |
| 16 TiB – 32 TiB | 8 KiB |
| 32 TiB – 64 TiB | 16 KiB |
É possível que, ao criar o volume, você tenha formatado manualmente o volume com um tamanho de cluster diferente. Se o seu volume provém de uma versão mais antiga do Windows, os tamanhos de cluster padrão também podem ser diferentes. Mesmo que você escolha um tamanho de cluster menor que 4 KiB, um limite de 8 KiB como o menor tamanho de arquivo que pode ser hierarquizado ainda se aplica. (Mesmo que, tecnicamente, 2x o tamanho do cluster equivalesse a menos de 8 KiB.)
A razão para o mínimo absoluto é devido à maneira como NTFS armazena arquivos extremamente pequenos - 1 KiB a 4 KiB arquivos de tamanho. Dependendo de outros parâmetros do volume, é possível que arquivos pequenos não sejam armazenados em um cluster no disco. É possivelmente mais eficiente armazenar esses arquivos diretamente na tabela de arquivos mestre do volume ou "registro MFT". O ponto de análise de hierarquização na nuvem é sempre armazenado em disco e ocupa exatamente um cluster. Hierarquizar esses arquivos pequenos pode acabar sem economia de espaço. Casos extremos podem até acabar usando mais espaço com a hierarquização na nuvem habilitada. Para se proteger contra isso, o menor tamanho de um arquivo que a hierarquização na nuvem irá hierarquizar é de 8 KiB em um tamanho de cluster de 4 KiB ou menor.
Selecionar as políticas iniciais
Geralmente, ao habilitar a hierarquização na nuvem em um ponto de extremidade de servidor, você deve criar uma unidade virtual local para cada ponto de extremidade de servidor individual. Isolar o ponto de extremidade do servidor torna mais fácil entender como funciona a hierarquização na nuvem e ajustar suas políticas de acordo. No entanto, a Sincronização de Arquivos do Azure funciona mesmo se você tiver vários pontos de extremidade de servidor na mesma unidade, para obter detalhes, consulte a seção Vários pontos de extremidade de servidor no volume local. Também recomendamos que, ao habilitar a hierarquização na nuvem pela primeira vez, mantenha a política de data desativada e a política de espaço livre de volume em torno de 10% a 20%. Para a maioria dos volumes de servidor de arquivos, 20% de espaço livre de volume é geralmente a melhor opção.
Nota
Em alguns cenários de migração, se você provisionou menos armazenamento em sua instância do Windows Server do que sua origem, poderá definir temporariamente o espaço livre de volume para 99% durante a migração para arquivos de camada para a nuvem e, em seguida, defini-lo para um nível mais útil após a conclusão da migração.
Para simplificar e ter uma compreensão clara de como os itens serão hierarquizados, recomendamos que você ajuste principalmente sua política de espaço livre de volume e mantenha sua política de data desativada, a menos que necessário. Recomendamos isso porque a maioria dos clientes acha valioso preencher o cache local com o maior número possível de arquivos ativos e hierarquizar o restante na nuvem. No entanto, a política de data pode ser benéfica se você quiser liberar proativamente espaço em disco local e souber que os arquivos nesse ponto de extremidade do servidor acessados após o número de dias especificado em sua política de data não precisam ser mantidos localmente. Definir a política de data libera valiosa capacidade de disco local para outros pontos de extremidade no mesmo volume armazenarem em cache mais de seus arquivos.
Depois de definir suas políticas, monitore a saída e ajuste ambas as políticas de acordo. Recomendamos examinar o tamanho da recuperação da hierarquização da nuvem e o tamanho da recuperação da hierarquização da nuvem por métricas de aplicativo no Azure Monitor. Também recomendamos monitorar a taxa de acertos do cache para o ponto de extremidade do servidor para determinar a porcentagem de arquivos abertos que já estão no cache local. Para saber como monitorar a saída, consulte Monitorar a hierarquização da nuvem.
Ajustar as suas políticas
Se o número de arquivos constantemente recuperados do Azure for maior do que você deseja, você pode ter mais arquivos quentes do que espaço para salvá-los no volume do servidor local. Aumente o tamanho do volume local, se possível, e/ou diminua a porcentagem da política de espaço livre de volume em pequenos incrementos. Diminuir demais a porcentagem de espaço livre de volume também pode ter consequências negativas. Uma maior rotatividade no seu conjunto de dados requer mais espaço livre - para novos ficheiros e recuperação de ficheiros "frios". A hierarquização entra em ação com um atraso de até uma hora e, em seguida, precisa de tempo de processamento, e é por isso que você sempre deve ter amplo espaço livre em seu volume.
Manter mais dados locais significa custos de saída mais baixos, pois menos arquivos serão recuperados do Azure, mas também requer uma quantidade maior de armazenamento local, o que tem seu próprio custo.
Ao ajustar sua política de espaço livre de volume, a quantidade de dados que você deve manter local é determinada pelos seguintes fatores: largura de banda, padrão de acesso do conjunto de dados e orçamento. Com uma conexão de baixa largura de banda, você pode querer mais dados locais, para garantir um atraso mínimo para os usuários. Caso contrário, você pode baseá-lo na taxa de churn durante um determinado período. Por exemplo, se você sabe que 10% do seu conjunto de dados de 1 TiB muda ou é acessado ativamente a cada mês, então você pode querer manter 100 GiB local para não estar lembrando arquivos com frequência. Se o seu volume for de 2 TiB, então você vai querer manter 5% (ou 100 GiB) local, o que significa que os 95% restantes são a sua porcentagem de espaço livre de volume. No entanto, você deve adicionar um buffer para períodos de maior rotatividade – em outras palavras, comece com uma porcentagem de espaço livre de volume maior e, em seguida, ajuste-o, se necessário, mais tarde.
Procedimentos operacionais normalizados
- Ao migrar pela primeira vez para os Arquivos do Azure por meio da Sincronização de Arquivos do Azure, a hierarquização na nuvem depende do carregamento inicial
- A hierarquização na nuvem verifica a conformidade com as políticas de volume, espaço livre e data a cada sessenta minutos
- Usar a opção /LFSM no Robocopy ao migrar arquivos permitirá que os arquivos sejam sincronizados e a hierarquização na nuvem crie espaço durante o upload inicial
- Se a hierarquização ocorrer antes de um mapa de calor ser formado, os arquivos serão hierarquizados por carimbo de data/hora da última modificação