Escolher as políticas da camada de nuvem
Este artigo fornece orientações sobre como selecionar e ajustar políticas de camada de nuvem para a Sincronização de Arquivos do Azure. Para ler o artigo, é importante entender como as camadas de nuvem funcionam. Para saber os conceitos básicos da camada de nuvem, confira Entender a camada de nuvem da Sincronização de Arquivos do Azure. Para obter uma explicação detalhada das políticas da camada de nuvem com exemplos, confira Políticas da camada de nuvem da Sincronização de Arquivos do Azure.
Limitações
Não há suporte às camadas de nuvem no volume do sistema Windows.
Ao usar o FSRM (Gerenciador de Recursos de Servidor de Arquivos) para gerenciamento de cotas em pontos de extremidade 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 no nível do volume. Depois que uma cota do FSRM é definida, as APIs de consulta de espaço livre que são chamadas automaticamente relatam o espaço livre no volume de acordo com a configuração de cota. No entanto, quando uma cota fixa está presente na raiz de um volume, o espaço livre real no volume e o espaço restrito pela 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 que ele seja transferido é 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 | Os arquivos desse tamanho ou maiores podem ser armazenados em camadas |
|---|---|
| 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 MiB |
| 1 MiB (1.048.576 bytes) | 2 MiB |
| 2 MiB (2.097.152 bytes) | 4 MiB |
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 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 manter um arquivo. Quando os tamanhos dos arquivos não chegam a um múltiplo par do tamanho do cluster, é necessário usar um espaço adicional para armazenar o arquivo, até o próximo múltiplo do tamanho do cluster.
Há suporte para a Sincronização de Arquivos do Azure nos volumes do NTFS com o 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 | Windows Server |
|---|---|
| 7 MiB – 16 TiB | 4 KiB |
| 16 TiB – 32 TiB | 8 KiB |
| 32 TiB – 64 TiB | 16 KiB |
Ao criar o volume, talvez você o tenha formatado manualmente com um tamanho de cluster diferente. Se o volume for baseado em 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, ainda será aplicado um limite de 8 KiB como o menor tamanho de arquivo que pode ser hierarquizado. (Mesmo que duas vezes o tamanho do cluster corresponda tecnicamente a menos de 8 KiB.)
A razão para o mínimo absoluto é a maneira como o NTFS armazena arquivos extremamente pequenos, de 1 KiB a 4 KiB. Dependendo de outros parâmetros do volume, é possível que arquivos pequenos não sejam armazenados em um cluster no disco. Talvez seja mais eficiente armazenar esses arquivos diretamente na tabela mestra de arquivos ou no "registro da MFT" do volume. 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 poderiam 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.
Como selecionar as políticas iniciais
Geralmente, ao habilitar a camada de nuvem em um ponto de extremidade de servidor, você deve criar uma unidade virtual local para cada ponto de extremidade do 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 quando há vários pontos de extremidade de servidor na mesma unidade. Para saber detalhes, confira a seção Vários 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 em sua origem, poderá definir temporariamente o espaço livre do volume como 99% durante a migração para colocar os arquivos em camadas na nuvem e, em seguida, defini-lo em um nível mais útil após a conclusão da migração.
Para simplificar e entender claramente como os itens serão armazenados em camadas, recomendamos que você ajuste principalmente a política de espaço livre do volume e mantenha a política de data desabilitada, a menos que ela seja necessária. Fazemos essa recomendação porque a maioria dos clientes acha importante preencher o cache local com o máximo de arquivos quentes possível e armazenar o restante em camadas na nuvem. No entanto, a política de data pode ser benéfica quando você quer liberar espaço em disco local proativamente e sabe que os arquivos nesse ponto de extremidade de servidor acessados após o número de dias especificado na política de data não precisam 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 observar as métricas tamanho de recall da camada de nuvem e tamanho de recall da camada de 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 a porcentagem de arquivos abertos que já estão no cache local. Para saber como monitorar a saída, confira Monitorar a camada de nuvem.
Como ajustar as políticas
Se o número de arquivos constantemente recuperados do Azure for maior do que o desejado, talvez você tenha mais arquivos ativos do que 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. A diminuição do percentual 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.
A presença de mais dados armazenados localmente significa custos de saída menores, pois menos arquivos serão recuperados do Azure, mas também exige uma quantidade maior de armazenamento local, o que gera um custo adicional.
Ao ajustar a política de espaço livre do volume, a quantidade de dados que deve ser mantida localmente é determinada pelos seguintes fatores: a largura de banda, o padrão de acesso do conjunto de dados e o orçamento. Com uma conexão de largura de banda baixa, é melhor ter mais dados locais, para garantir o mínimo de atraso aos usuários. Caso contrário, você pode baseá-lo na taxa de rotatividade durante um determinado período. Por exemplo, se você sabe que 10% do conjunto de dados de 1 TiB muda ou é acessado ativamente a cada mês, convém manter 100 GiB locais para não recuperar arquivos com frequência. Se o volume for de 2 TiB, mantenha 5% (ou 100 GiB) no local, o que significa que os 95% restantes serão a porcentagem de espaço livre do volume. No entanto, adicione um buffer para períodos de maior rotatividade, ou seja, comece com uma porcentagem de espaço livre de volume maior e, em seguida, ajuste-a 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
- O uso da opção /LFSM no Robocopy ao migrar arquivos permitirá que os arquivos sejam sincronizados e que a camada de nuvem crie 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