Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo fornece diretrizes sobre como selecionar e ajustar políticas de camada de nuvem para a Sincronização de Arquivos do Azure. Antes de ler este artigo, verifique se você entende como funciona a camada de nuvem. Para entender os fundamentos do escalonamento em nuvem, consulte Compreender o escalonamento em nuvem da Sincronização de Arquivos do Azure. Para obter uma explicação detalhada das políticas de camada de nuvem com exemplos, consulte as políticas de camada de nuvem da Sincronização de Arquivos do Azure.
Limitações
Não há suporte à camada de nuvem no volume do sistema do Windows.
Se você estiver usando o FSRM (Gestor de Recursos de Servidor de Arquivo) para gerenciamento de cotas nos endpoints do servidor, recomendamos aplicar as cotas no nível da pasta e não no nível do volume. Você ainda poderá habilitar a camada de nuvem se tiver uma cota do FSRM de nível do 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 poderá causar a criação de camadas intermináveis se a Sincronização de Arquivos do Azure acreditar que não há espaço livre de volume suficiente no ponto de extremidade do servidor.
Tamanho mínimo do arquivo para que ele seja armazenado em camadas
O tamanho mínimo do arquivo para uma camada de arquivo é baseado no tamanho do cluster do sistema de arquivos. O tamanho mínimo do arquivo qualificado para a camada de nuvem é calculado como duas vezes o tamanho do cluster e, no mínimo, 8 KiB. A seguinte tabela ilustra os tamanhos mínimos de arquivo que podem ser armazenados em camadas, com base no tamanho do cluster de volume:
| Tamanho do cluster de volume | Arquivos desse tamanho ou maiores podem ser hierarquizados |
|---|---|
| 4 KiB ou menor (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 Mebibyte |
| 1 MiB (1.048.576 bytes) | 2 MiB |
| 2 MiB (2.097.152 bytes) | 4 MiB |
O tamanho do cluster de volume pode ser encontrado executando o comando fsutil fsinfo ntfsinfo volumedriveletter: em um prompt de comando administrativo. O campo Bytes por Cluster exibe o tamanho do cluster de volume em bytes e o valor em quilobytes é mostrado entre parênteses.
A Sincronização de Arquivos do Azure dá suporte à camada de nuvem em volumes com tamanhos de cluster de até 2 MiB.
Todos os sistemas de arquivos usados pelo Windows organizam seu 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 manter um arquivo. Quando os tamanhos de arquivo não correspondem a um múltiplo exato do tamanho do cluster, espaço adicional deve ser usado para armazenar o arquivo até o próximo múltiplo do tamanho do cluster.
A Sincronização de Arquivos do Azure tem suporte em volumes NTFS com Windows Server 2012 R2 e mais recentes. A tabela a seguir descreve os tamanhos de cluster padrão quando você cria um novo volume NTFS com o Windows Server.
| Tamanho do volume | Servidor Windows |
|---|---|
| 7 MiB – 16 TiB | 4 KiB |
| 16 TiB – 32 TiB | 8 KiB |
| 32 TiB – 64 TiB | 16 KiB |
É possível que, após a criação do volume, você formate manualmente o volume com um tamanho de cluster diferente. Se o volume for proveniente de uma versão mais antiga do Windows, os tamanhos de cluster padrão também poderão ser diferentes. Mesmo se você escolher um tamanho de cluster menor que 4 KiB, um limite de 8 KiB como o menor tamanho de arquivo que pode ser em camadas ainda se aplica. (Mesmo que tecnicamente o tamanho do cluster 2x equivaleria a menos de 8 KiB.)
O motivo do mínimo absoluto se deve à maneira como o NTFS armazena arquivos extremamente pequenos – 1 KiB a 4 arquivos do tamanho de KiB. 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 no "registro MFT". O ponto de nova análise da camada de nuvem sempre é armazenado em disco e ocupa exatamente um cluster. O armazenamento desses arquivos pequenos em camadas poderia acabar sem economia de espaço. Os casos extremos poderão até acabar usando mais espaço com a camada de nuvem habilitada. Para evitar esse problema, o menor tamanho de um arquivo que as camadas de nuvem hierarquizam é de 8 KiB em um tamanho de cluster de 4 KiB ou menor.
Selecionando suas políticas iniciais
Geralmente, ao habilitar a classificação em nuvem em um endpoint do servidor, você deve criar uma unidade virtual local para cada endpoint de servidor individual. O isolamento do ponto de extremidade de servidor facilita o entendimento de como a camada de nuvem funciona e o ajuste correto das políticas. 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 Múltiplos pontos de extremidade de servidor no volume local. Também recomendamos que, ao habilitar a camada de nuvem pela primeira vez, você deixe a política de data desabilitada e a política de espaço livre no volume em cerca de 10% a 20%. Para a maioria dos volumes de servidor de arquivos, 20% do espaço livre do volume geralmente é a melhor opção.
Observação
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 como 99% durante a migração para arquivos de camada para a nuvem e 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 classificados, recomendamos que você ajuste sua política de espaço livre no volume principalmente e mantenha sua política de organização por datas desabilitada, a menos que seja necessário. Recomendamos isso porque a maioria dos clientes acha importante preencher o cache local com o máximo de arquivos frequentes possível e colocar o restante na nuvem em camadas. No entanto, a política de data poderá ser benéfica se você quiser liberar proativamente o 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 precisarão ser mantidos localmente. A configuração da política de data libera uma capacidade de disco local importante para que outros pontos de extremidade no mesmo volume armazenem mais arquivos em cache.
Depois de configurar suas políticas, monitore a saída e ajuste as duas políticas corretamente. Recomendamos examinar as métricas de tamanho de recuperação de hierarquização na nuvem e tamanho de recuperação de hierarquização na nuvem por aplicativo no Azure Monitor. Também recomendamos monitorar a taxa de ocorrências no cache do ponto de extremidade do servidor para determinar o percentual de arquivos abertos que já estão no cache local. Para saber como monitorar a saída, veja Monitorar a camada de nuvem.
Ajustando suas políticas
Se o número de arquivos constantemente recuperados do Azure for maior do que você deseja, talvez você tenha mais arquivos quentes do que tem espaço para salvá-los no volume do servidor local. Aumente o tamanho do volume local se possível e/ou diminua o percentual de política de espaço livre do volume em incrementos pequenos. Diminuir muito a porcentagem de espaço livre do volume também pode ter consequências negativas. Uma rotatividade mais alta no conjunto de dados exige mais espaço livre, para os arquivos novos e a recuperação de arquivos “frios”. O armazenamento em camadas é iniciado com um atraso de até uma hora e, depois, precisa de tempo de processamento. Por isso, você sempre deve ter bastante espaço livre no 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, 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: sua largura de banda, o padrão de acesso do conjunto de dados e o orçamento. Com uma conexão de baixa largura de banda, talvez você queira mais dados locais para garantir um atraso mínimo para os usuários. Caso contrário, você pode baseá-lo na taxa de rotatividade durante determinado período. Por exemplo, se você souber que 10% de seu conjunto de dados de 1 TiB são alterados ou são acessados ativamente a cada mês, talvez você queira manter 100 GiB local para não estar recuperando arquivos com frequência. Se o volume for de 2 TiB, você desejará manter 5% (ou 100 GiB) locais, o que significa que os 95% restantes são sua porcentagem de espaço livre de volume. No entanto, adicione um buffer para períodos de maior rotatividade, ou seja, comece com um percentual de espaço livre de volume maior e, em seguida, ajuste-o se necessário.
Procedimentos operacionais padrão
- Na primeira migração para os Arquivos do Azure por meio da Sincronização de Arquivos do Azure, a camada de nuvem depende de um upload inicial
- A camada de nuvem verifica a conformidade com as políticas de espaço livre no volume e de data a cada sessenta minutos
- Usar a opção /LFSM no Robocopy ao migrar arquivos permitirá que os arquivos sincronizem e a hierarquização de armazenamento em nuvem abra espaço durante o upload inicial
- Se o armazenamento em camadas ocorrer antes da formação de um mapa de calor, os arquivos serão armazenados em camadas pelo carimbo de data/hora da última modificação