Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
A hierarquização na cloud, uma funcionalidade opcional do Azure File Sync, diminui a quantidade de armazenamento local necessária, mantendo o desempenho de um servidor de ficheiros no local.
Quando ativa este recurso, armazena apenas os ficheiros frequentemente acedidos, ou "hot files", no seu servidor local. Arquivos acessados com pouca frequência (legais) são divididos em namespace (estrutura de arquivos e pastas) e conteúdo de arquivo. O namespace é armazenado localmente e o conteúdo dos ficheiros é armazenado numa partilha de ficheiros do Azure na cloud.
Quando um utilizador abre um ficheiro em camadas, o Azure File Sync recupera perfeitamente os dados do ficheiro partilhado do Azure.
Como funciona a hierarquização na nuvem
A hierarquização na nuvem funciona monitorando padrões de acesso a arquivos e hierarquizando arquivos com base em políticas definidas.
Políticas de hierarquização em nuvem
Quando ativas o tiering na cloud, existem duas políticas que podes definir para informar Azure File Sync quando classificar ficheiros cool: a política de espaço livre volume e a política date.
Política de espaço livre de volume
A política de espaço livre do volume instrui o Azure File Sync a transferir ficheiros pouco utilizados para a cloud quando uma determinada quantidade de espaço é ocupada no seu disco local.
Por exemplo, se a capacidade do seu disco local for de 200 GiB e quiser que pelo menos 40 GiB da capacidade local do disco permaneçam sempre livres, defina a política de espaço livre de volume para 20%. O espaço livre de volume aplica-se ao nível do volume e não ao nível de diretórios individuais ou pontos de extremidade do servidor.
Política de datas
Com a política de datas, os arquivos pouco utilizados são hierarquizados na nuvem se não tiverem sido acessados (lidos ou gravados) por um número x de dias. Por exemplo, se você notar que os arquivos que passaram mais de 15 dias sem serem acessados são normalmente arquivos de arquivamento, você deve definir sua política de data para 15 dias.
Para mais exemplos sobre como a política de datação e a política de espaço livre de volume funcionam em conjunto, consulte Escolher políticas de tiering em nuvem do Azure File Sync.
Deduplicação de dados do Windows Server
A partir do Windows Server 2016, a deduplicação de dados é suportada em volumes que têm a estratificação na nuvem ativada. Para mais informações, consulte Planear uma implementação Azure File Sync.
Mapa de calor de camadas da nuvem
O Azure File Sync monitoriza o acesso a ficheiros (operações de leitura e escrita) ao longo do tempo e atribui uma pontuação de calor a cada ficheiro com base em quão recentemente e com que frequência o ficheiro foi acedido. Ele usa essas pontuações para construir um "mapa de calor" do seu namespace em cada endpoint do servidor. Este heatmap é uma lista de todos os arquivos sincronizados em um local com a hierarquização da nuvem habilitada, ordenada por sua pontuação de calor. Ficheiros frequentemente acedidos que foram abertos recentemente são considerados quentes, enquanto ficheiros que raramente foram acedidos e não foram acedidos há algum tempo são considerados frios.
Para determinar a posição relativa de um ficheiro individual nesse mapa de calor, o sistema utiliza o máximo de seus carimbos de data/hora, na seguinte ordem: MAX (Hora de Último Acesso, Hora de Última Modificação, Hora de Criação).
Normalmente, o tempo do último acesso é rastreado e disponível. No entanto, quando crias um novo endpoint de servidor com a cloud tiering ativada, não passou tempo suficiente para observar o acesso aos ficheiros. Se não houver um tempo válido do último acesso, o último tempo modificado será usado para avaliar a posição relativa no mapa de calor.
A política de data funciona da mesma forma. Sem um último tempo de acesso, a política de data atua no último tempo modificado. Se isso não estiver disponível, volta ao tempo de criação de um ficheiro. Com o tempo, o sistema observa mais pedidos de acesso a ficheiros e começa automaticamente a usar o último tempo de acesso auto-rastreado.
Observação
A hierarquização na nuvem não depende do recurso NTFS para rastrear o tempo do último acesso. Este recurso NTFS está desativado por padrão. Devido a considerações de desempenho, não recomendamos que você habilite manualmente esse recurso. A hierarquização na nuvem rastreia a hora do último acesso separadamente.
Considerações para escolher uma política de hierarquização na nuvem
Ficheiros frios que são acedidos com menos frequência são mais adequados para serem armazenados em camadas, pois a recuperação de dados requer o download a partir da nuvem. Azure File Sync reserva 10% de memória total para recordações persistentes no disco. Se 60% desta memória reservada estiverem em uso, as recolhas não são persistidas no disco. Se um grande número de arquivos hierárquicos estiver presente no sistema e houver muito acesso, o sistema poderá atingir um limite de memória. Esta situação pode causar saídas extras inesperadas, degradação do desempenho de I/O, lentidão do sistema e bloqueios.
Recordação proativa
Quando um ficheiro é criado ou modificado, pode recuar proativamente o ficheiro para os servidores que especificar. A recuperação proativa torna o arquivo novo ou modificado prontamente disponível para consumo em cada servidor especificado.
Por exemplo, uma empresa distribuída globalmente tem filiais nos EUA e na Índia. Pela manhã, nos EUA, os profissionais da informação criam uma nova pasta e arquivos para um novo projeto e trabalham o dia todo nele. O Azure File Sync sincroniza a pasta e os ficheiros para a partilha de ficheiros Azure (endpoint cloud), que serve como hub central entre todos os servidores registados. Os profissionais da informação na Índia continuarão trabalhando no projeto em seu fuso horário. Quando chegam de manhã, o servidor local com Azure File Sync na Índia precisa de ter estes novos ficheiros disponíveis localmente para que a equipa da Índia possa trabalhar eficientemente a partir de uma cache local. Ativar o recall proativo informa o servidor para transferir os ficheiros assim que são alterados ou criados na partilha de ficheiros do Azure, em vez de esperar até que um utilizador tente abri-los.
Se os ficheiros chamados de volta pelo servidor não forem necessários localmente, o chamamento desnecessário pode aumentar o tráfego de saída e os custos. Por isso, só ative a recordação proativa quando souber que pré-preencher a cache de um servidor com alterações recentes da cloud terá um efeito positivo nos utilizadores ou aplicações que utilizam os ficheiros desse servidor.
Ativar a recuperação proativa pode também resultar num aumento do uso da largura de banda no servidor e pode levar a que outros conteúdos relativamente novos no servidor local sejam agressivamente escalonados devido ao aumento dos ficheiros a serem recuperados. Por sua vez, a hierarquização muito cedo pode levar a mais recalls se os arquivos que estão sendo hierarquizados forem considerados quentes pelos servidores.
Para mais informações sobre o recall proativo, consulte Deploy Azure File Sync.
Comportamento de ficheiros em camadas versus armazenados em cache localmente
A hierarquização na nuvem é a separação entre o namespace (a hierarquia de arquivos e pastas, bem como as propriedades do arquivo) e o conteúdo do arquivo.
Arquivo em camadas
Para arquivos hierárquicos, o tamanho no disco é zero porque o conteúdo do arquivo em si não está sendo armazenado localmente. Quando um ficheiro é escalonado, o filtro do sistema de ficheiros Azure File Sync (StorageSync.sys) substitui localmente o ficheiro por um ponteiro chamado ponto de reparse. O ponto de reapreciação representa uma URL para o ficheiro no compartilhamento de ficheiros do Azure. Um arquivo em camadas tem o offline atributo e o FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS atributo definidos em NTFS para que aplicativos de terceiros possam identificar com segurança arquivos em camadas.
Arquivo armazenado em cache localmente
Para ficheiros armazenados num servidor local, o tamanho no disco é aproximadamente igual ao tamanho lógico do ficheiro, porque todo o ficheiro (atributos e conteúdo do ficheiro) é armazenado localmente.
Também é possível que um arquivo seja parcialmente hierarquizado ou parcialmente recuperado. Em um arquivo parcialmente hierárquico, apenas parte do arquivo é armazenada no disco. Você pode ter recuperado parcialmente os arquivos em seu volume se os arquivos forem lidos parcialmente por aplicativos que suportam acesso de streaming a arquivos. Alguns exemplos são leitores multimédia e utilitários zip. O Azure File Sync é eficiente e só recupera a informação solicitada da partilha de ficheiros Azure conectada.
Observação
Tamanho representa o tamanho lógico do arquivo. Tamanho no disco representa o tamanho físico do fluxo de arquivos armazenado no disco.
Modo de pouco espaço em disco
Discos que têm pontos de extremidade do servidor podem ficar sem espaço por várias razões, mesmo quando a hierarquização em nuvem está ativada. Estas razões incluem:
- Copiar manualmente os dados para o disco fora do caminho do endpoint do servidor
- Sincronização lenta ou atrasada fazendo com que os arquivos não sejam hierarquizados
- Recuperações excessivas de ficheiros escalonados
Quando o espaço em disco acaba, o Azure File Sync pode não funcionar corretamente e até tornar-se inutilizável. Embora o Azure File Sync não consiga prevenir completamente estas ocorrências, o modo de espaço em disco reduzido (disponível nas versões do Azure File Sync agent a partir da 15.1) ajuda a evitar que o endpoint do servidor atinja esta situação e ajuda o servidor a sair dela mais rapidamente.
Para endpoints de servidor com escalonamento na nuvem ativado, se o espaço livre no volume cair abaixo do limiar calculado, o volume entra em modo de baixa capacidade de disco.
No modo de pouco espaço em disco, o agente Azure File Sync faz duas coisas de forma diferente:
Particionamento proativo: O agente de Sincronização de Ficheiros classifica os ficheiros de forma mais proativa na nuvem. O agente de sincronização verifica se os ficheiros são classificados a cada minuto em vez da frequência normal de cada hora. A hierarquização da política de espaço livre do volume normalmente não ocorre durante a sincronização inicial do carregamento; apenas acontece quando o carregamento completo está concluído. No entanto, no modo de pouco espaço em disco, a escalonação está ativada durante a sincronização inicial de upload, e os ficheiros são considerados para escalonamento assim que o ficheiro individual é carregado para a partilha de ficheiros Azure.
Recordações não persistentes: Quando um utilizador abre um ficheiro em níveis, os ficheiros recordados diretamente da partilha de ficheiros Azure não são persistidos no disco. As recolhas iniciadas pelo
Invoke-StorageSyncFileRecallcmdlet são uma exceção a esta regra e são persistidas em disco.
Quando o espaço livre de volume ultrapassa o limiar, o Azure File Sync reverte automaticamente para o estado normal. O modo de espaço em disco reduzido aplica-se apenas a servidores com tiering cloud ativado e respeita sempre a política de espaço livre de volume.
Se um volume tiver dois endpoints de servidor, um com tiering ativado e outro sem tiering, o modo de espaço em disco reduzido aplica-se apenas ao endpoint de servidor onde a tiering está ativada.
Como é calculado o limite para o modo de pouco espaço em disco?
Calcule o limite tomando o mínimo dos três números seguintes:
- 10% de tamanho de volume em GiB
- Política de espaço livre de volume em GiB
- 20 GiB
A tabela seguinte inclui alguns exemplos de como o limiar é calculado e quando o volume está em modo de espaço em disco reduzido.
| Tamanho do volume | 10% de tamanho de volume | Política de Espaço Livre de Volume | Limite = Min (10% do Tamanho do Volume, Política de Espaço Livre do Volume, 20 GiB) | Espaço livre de volume atual | É o modo de pouco espaço em disco? | Motivo |
|---|---|---|---|---|---|---|
| 100 GiB | 10 GiB | 7% (7 GiB) | 7 GiB = min (10 GiB, 7 GiB, 20 GiB) | 9% (9 GiB) | Não | Limite de espaço livre de volume atual (9 GiB) > (7 GiB) |
| 100 GiB | 10 GiB | 7% (7 GiB) | 7 GiB = min (10 GiB, 7 GiB, 20 GiB) | 5% (5 GiB) | Sim | Limite de espaço livre de volume atual (5 GiB) < (7 GiB) |
| 300 GiB | 30 GiB | 8% (24 GiB) | 20 GiB = Min(30 GiB, 24 GiB, 20 GiB) | 7% (21 GiB) | Não | Limite de espaço livre de volume atual (21 GiB) > (20 GiB) |
| 300 GiB | 30 GiB | 8% (24 GiB) | 20 GiB = Min(30 GiB, 24 GiB, 20 GiB) | 6% (18 GiB) | Sim | Limite de espaço livre de volume atual (18 GiB) < (20 GiB) |
Como funciona o modo de pouco espaço em disco com a política de espaço livre de volume?
O modo de pouco espaço em disco sempre respeita a política de espaço livre de volume. O cálculo do limiar é desenhado para garantir que respeita a política de espaço livre de volume que definiste.
Qual é a causa mais comum para o ponto de extremidade do servidor estar no modo de disco baixo?
A principal causa do modo de disco baixo é copiar ou mover grandes quantidades de dados para o disco onde um ponto de extremidade de servidor habilitado para hierarquização está localizado.
Como posso sair do modo de pouco espaço em disco?
O modo de baixo disco muda automaticamente para o comportamento normal ao não persistir recuperações e ao realocar ficheiros com mais frequência, sem necessidade de qualquer intervenção. Você pode acelerar manualmente o processo aumentando o tamanho do volume ou liberando espaço fora do ponto de extremidade do servidor.
Como posso verificar se um servidor está em modo de pouco espaço em disco?
- Se um endpoint servidor estiver em modo de espaço em disco reduzido, o portal Azure exibe-o na secção cloud tiering health do separador Erros + resolução de problemas do endpoint do servidor.
- A ID de Evento 19000 é registrada no log de eventos de Telemetria a cada minuto para cada ponto de extremidade do servidor. Use este evento para determinar se o endpoint do servidor está em modo de espaço em disco reduzido (IsLowDiskMode = verdadeiro). Pode encontrar o registo de eventos de telemetria no Visualizador de Eventos em
Applications and Services\Microsoft\FileSync\Agent.