Metas de escalabilidade e desempenho para Arquivos do Azure e Sincronização de Arquivos do Azure

O Azure Files oferece compartilhamentos de arquivos totalmente gerenciados na nuvem que podem ser acessados por meio dos protocolos de sistema de arquivos SMB (Server Message Block) e NFS (Network File System). Este artigo discute as metas de escalabilidade e desempenho para contas de armazenamento do Azure, Arquivos do Azure e Sincronização de Arquivos do Azure.

Os destinos listados aqui podem ser afetados por outras variáveis em sua implantação. Por exemplo, o desempenho de E/S de um arquivo pode ser afetado pelo comportamento do cliente SMB e pela largura de banda de rede disponível. Você deve testar seu padrão de uso para determinar se a escalabilidade e o desempenho dos Arquivos do Azure atendem aos seus requisitos.

Aplica-se a

Tipo de partilhas de ficheiros	SMB	NFS
Partilhas de ficheiros Standard (GPv2), LRS/ZRS
Partilhas de ficheiros Standard (GPv2), GRS/GZRS
Partilhas de ficheiros Premium (FileStorage), LRS/ZRS

Metas de dimensionamento dos Ficheiros do Azure

Os compartilhamentos de arquivos do Azure são implantados em contas de armazenamento, que são objetos de nível superior que representam um pool compartilhado de armazenamento. Esse pool de armazenamento pode ser usado para implantar vários compartilhamentos de arquivos. Portanto, há três categorias a serem consideradas: contas de armazenamento, compartilhamentos de arquivos do Azure e arquivos individuais.

Metas de dimensionamento de conta de armazenamento

As metas de escala da conta de armazenamento aplicam-se no nível da conta de armazenamento. Há dois tipos principais de contas de armazenamento para Arquivos do Azure:

• Contas de armazenamento de uso geral versão 2 (GPv2): as contas de armazenamento GPv2 permitem implantar compartilhamentos de arquivos do Azure em hardware padrão/baseado em disco rígido (baseado em HDD). Além de armazenar compartilhamentos de arquivos do Azure, as contas de armazenamento GPv2 podem armazenar outros recursos de armazenamento, como contêineres de blob, filas ou tabelas. Os compartilhamentos de arquivos podem ser implantados nas camadas otimizadas para transações (padrão), hot ou cool.

• Contas de armazenamento FileStorage: as contas de armazenamento FileStorage permitem implantar compartilhamentos de arquivos do Azure em hardware premium/baseado em disco de estado sólido (baseado em SSD). As contas FileStorage só podem ser usadas para armazenar compartilhamentos de arquivos do Azure; nenhum outro recurso de armazenamento (contêineres blob, filas, tabelas, etc.) pode ser implantado em uma conta FileStorage.

1 Com um aumento de cota, você pode criar até 500 contas de armazenamento com endpoints padrão por região. Para obter mais informações, consulte Aumentar as cotas da conta de Armazenamento do Azure. 2 As contas de armazenamento da versão 2 de uso geral suportam limites de capacidade mais altos e limites mais altos para entrada por solicitação. Para solicitar um aumento dos limites de conta, contacte o Suporte do Azure.

Destinos de escala de compartilhamento de arquivos do Azure

Os destinos de escala de compartilhamento de arquivos do Azure se aplicam no nível de compartilhamento de arquivos.

1 Os limites para compartilhamentos de arquivos padrão se aplicam a todas as três camadas disponíveis para compartilhamentos de arquivos padrão: transação otimizada, quente e legal.

2 Os Arquivos do Azure impõem determinadas regras de nomenclatura para nomes de diretório e arquivo.

Destinos de dimensionamento de ficheiros

Os alvos de dimensionamento de ficheiros aplicam-se a ficheiros individuais armazenados nas partilhas de ficheiros do Azure.

^{1 Aplica-se a E/S de leitura e gravação (normalmente tamanhos de E/S menores menores ou iguais a 64 KiB). As operações de metadados, para além das leituras e escritas, podem ser mais baixas. Estes são limites flexíveis e a limitação pode ocorrer para além destes limites.}

^{2 Sujeito aos limites de rede da máquina, largura de banda disponível, tamanhos de E/S, profundidade da fila e outros fatores. Para obter detalhes, consulte Desempenho multicanal SMB.}

^{3 Os Arquivos do Azure dão suporte a 10.000 identificadores abertos no diretório raiz e 2.000 identificadores abertos por arquivo e diretório dentro do compartilhamento. O número de usuários ativos suportados por compartilhamento depende dos aplicativos que estão acessando o compartilhamento. Se seus aplicativos não estiverem abrindo um identificador no diretório raiz, os Arquivos do Azure poderão oferecer suporte a mais de 10.000 usuários ativos por compartilhamento. No entanto, se você estiver usando os Arquivos do Azure para armazenar imagens de disco para cargas de trabalho de área de trabalho virtual de grande escala, poderá ficar sem identificadores para o diretório raiz ou por arquivo/diretório. Nesse caso, talvez seja necessário usar vários compartilhamentos de arquivos do Azure. Para obter mais informações, consulte Diretrizes de dimensionamento de Arquivos do Azure para a Área de Trabalho Virtual do Azure.}

Diretrizes de dimensionamento de Arquivos do Azure para a Área de Trabalho Virtual do Azure

Um caso de uso popular para Arquivos do Azure é armazenar contêineres de perfil de usuário e imagens de disco para a Área de Trabalho Virtual do Azure, usando FSLogix ou App attach. Em implantações de Área de Trabalho Virtual do Azure em grande escala, você pode ficar sem identificadores para o diretório raiz ou por arquivo/diretório se estiver usando um único compartilhamento de arquivos do Azure. Esta seção descreve como as alças são consumidas por vários tipos de imagens de disco e fornece orientação de dimensionamento dependendo da tecnologia que você está usando.

FSLogix

Se você estiver usando o FSLogix com a Área de Trabalho Virtual do Azure, seus contêineres de perfil de usuário são arquivos VHD (Disco Rígido Virtual) ou VHDX (Disco Rígido Virtual Hyper-V) e são montados em um contexto de usuário, não em um contexto de sistema. Cada usuário abrirá um único identificador de diretório raiz, que deve ser para o compartilhamento de arquivos. Os Arquivos do Azure podem dar suporte a um máximo de 10.000 usuários, supondo que você tenha o compartilhamento de arquivos (\\storageaccount.file.core.windows.net\sharename) + o diretório de perfil (%sid%_%username%) + contêiner de perfil (profile_%username.vhd(x)).

Se você estiver atingindo o limite de 10.000 identificadores simultâneos para o diretório raiz ou se os usuários estiverem vendo um desempenho ruim, tente usar um compartilhamento de arquivos adicional do Azure e distribuir os contêineres entre os compartilhamentos.

Por exemplo, se você tiver 2.400 usuários simultâneos, precisará de 2.400 identificadores no diretório raiz (um para cada usuário), o que está abaixo do limite de 10.000 identificadores abertos. Para usuários do FSLogix, atingir o limite de 2.000 identificadores de arquivos e diretórios abertos é extremamente improvável. Se você tiver um único contêiner de perfil FSLogix por usuário, consumirá apenas dois identificadores de arquivo/diretório: um para o diretório de perfil e outro para o arquivo de contêiner de perfil. Se os usuários tiverem dois contêineres cada (perfil e ODFC), você precisará de um identificador adicional para o arquivo ODFC.

App anexar com CimFS

Se estiver a utilizar a anexação de aplicações MSIX ou a anexação de aplicações para anexar dinamicamente aplicações, pode utilizar ficheiros CimFS (Composite Image File System) ou VHD/VHDX para imagens de disco. De qualquer forma, os limites de escala são por VM montando a imagem, não por usuário. O número de utilizadores é irrelevante no cálculo dos limites de escala. Quando uma VM é inicializada, ela monta a imagem de disco, mesmo que haja zero usuários.

Se você estiver usando o App attach com o CimFS, as imagens de disco só consomem identificadores nos arquivos de imagem de disco. Eles não consomem identificadores no diretório raiz ou no diretório que contém a imagem de disco. No entanto, como uma imagem CimFS é uma combinação do arquivo .cim e pelo menos dois outros arquivos, para cada VM montando a imagem de disco, você precisará de um identificador para cada um para três arquivos no diretório. Portanto, se você tiver 100 VMs, precisará de 300 identificadores de arquivo.

Você pode ficar sem identificadores de arquivo se o número de VMs por aplicativo exceder 2.000. Nesse caso, use um compartilhamento de arquivos adicional do Azure.

Anexar aplicações com VHD/VHDX

Se estiver a utilizar a anexação de aplicações com ficheiros VHD/VHDX, os ficheiros são montados num contexto de sistema, não num contexto de utilizador, e são partilhados e só de leitura. Mais de um identificador no arquivo VHDX pode ser consumido por um sistema de conexão. Para permanecer dentro dos limites de escala dos Arquivos do Azure, o número de VMs multiplicado pelo número de aplicativos deve ser inferior a 10.000 e o número de VMs por aplicativo não pode exceder 2.000. Portanto, a restrição é qualquer que você acerte primeiro.

Nesse cenário, você pode atingir o limite por arquivo/diretório com 2.000 montagens de um único VHD/VHDX. Ou, se o compartilhamento contiver vários arquivos VHD/VHDX, você poderá atingir o limite do diretório raiz primeiro. Por exemplo, 100 VMs montando 100 arquivos VHDX compartilhados atingirão o limite de diretório raiz de 10.000 manipuladores.

Em outro exemplo, 100 VMs acessando 20 aplicativos exigirão 2.000 identificadores de diretório raiz (100 x 20 = 2.000), o que está bem dentro do limite de 10.000 para identificadores de diretório raiz. Você também precisará de um identificador de arquivo e um identificador de diretório/pasta para cada VM que monta a imagem VHD(X), portanto, 200 identificadores neste caso (100 identificadores de arquivo + 100 identificadores de diretório), o que está confortavelmente abaixo do limite de 2.000 identificadores por arquivo/diretório.

Se você estiver atingindo os limites máximos de identificadores simultâneos para o diretório raiz ou por arquivo/diretório, use um compartilhamento de arquivos adicional do Azure.

Alvos de dimensionamento do Azure File Sync

A tabela a seguir indica quais destinos são soft, representando o limite testado pela Microsoft, e hard, indicando um máximo imposto:

Métricas de desempenho do Azure File Sync

Como o agente do Azure File Sync é executado em uma máquina Windows Server que se conecta aos compartilhamentos de arquivos do Azure, o desempenho efetivo da sincronização depende de vários fatores em sua infraestrutura: Windows Server e a configuração de disco subjacente, largura de banda de rede entre o servidor e o armazenamento do Azure, tamanho do arquivo, tamanho total do conjunto de dados e a atividade no conjunto de dados. Uma vez que o Azure File Sync funciona ao nível do ficheiro, as características de desempenho de uma solução baseada no Azure File Sync devem ser medidas pelo número de objetos (ficheiros e diretórios) processados por segundo.

Relativamente ao Azure File Sync, o desempenho é crítico em duas fases:

1. Aprovisionamento pontual inicial: para otimizar o desempenho no aprovisionamento inicial, veja Integração no Azure File Sync para obter os detalhes de implementação ideais.
2. Sincronização contínua: depois de os dados terem sido inicialmente propagados nas partilhas de ficheiros do Azure, o Azure File Sync mantém vários pontos finais sincronizados.

Resultados dos testes internos

Para ajudá-lo a planejar sua implantação para cada um dos estágios (provisionamento inicial único e sincronização contínua), aqui estão os resultados que observamos durante os testes internos em um sistema com a seguinte configuração:

Aprovisionamento pontual inicial

Enumeração inicial de alteração de nuvem: quando um novo grupo de sincronização é criado, a enumeração inicial de alteração de nuvem é a primeira etapa executada. Nesse processo, o sistema enumerará todos os itens no compartilhamento de arquivos do Azure. Durante esse processo, não haverá atividade de sincronização. Nenhum item será baixado do ponto de extremidade da nuvem para o ponto de extremidade do servidor e nenhum item será carregado do ponto de extremidade do servidor para o ponto de extremidade da nuvem. A atividade de sincronização será retomada assim que a enumeração inicial da alteração da cloud for concluída.

A taxa de desempenho é de 80 objetos por segundo. Você pode estimar o tempo que levará para concluir a enumeração inicial de alteração de nuvem determinando o número de itens no compartilhamento de nuvem e usando as fórmulas a seguir para obter o tempo em dias.

Tempo (em dias) para enumeração inicial da cloud = (Número de objetos no ponto final da cloud)/(80 * 60 * 60 * 24)

Sincronização inicial de dados do Windows Server para a partilha de ficheiros do Azure: muitas implementações do Azure File Sync começam com uma partilha de ficheiros do Azure vazia, porque todos os dados estão no Windows Server. Nesses casos, a enumeração inicial de alteração na nuvem é rápida e a maior parte do tempo é gasta sincronizando alterações do Windows Server no(s) compartilhamento(s) de arquivos do Azure.

Embora a sincronização carregue dados para o compartilhamento de arquivos do Azure, não há tempo de inatividade no servidor de arquivos local e os administradores podem configurar limites de rede para restringir a quantidade de largura de banda usada para o carregamento de dados em segundo plano.

Normalmente, a sincronização inicial é limitada pela taxa de carregamento inicial de 20 ficheiros por segundo por grupo de sincronização. Os clientes podem calcular o tempo para carregar todos os dados para o Azure com as seguintes fórmulas para obter tempo em dias:

Tempo (em dias) para carregar ficheiros para um grupo de sincronização = (Número de objetos no ponto final do servidor)/(20 * 60 * 60 * 24)

Dividir os dados em vários pontos finais de servidor e grupos de sincronização pode acelerar este carregamento de dados inicial, uma vez que o carregamento pode ser feito em paralelo para vários grupos de sincronização a uma taxa de 20 itens por segundo cada. Assim, dois grupos de sincronização seriam executados a uma taxa combinada de 40 itens por segundo. O tempo total para concluir seria a estimativa de tempo para o grupo de sincronização com mais ficheiros a sincronizar.

Taxa de transferência de download de namespace: quando um novo ponto de extremidade de servidor é adicionado a um grupo de sincronização existente, o agente de Sincronização de Arquivos do Azure não baixa nenhum conteúdo de arquivo do ponto de extremidade na nuvem. Primeiro sincroniza o espaço de nomes completo e, em seguida, aciona a recuperação em segundo plano para transferir os ficheiros, na sua totalidade ou, se o arrumo na cloud estiver ativado, para o conjunto de políticas de arrumo na cloud no ponto final do servidor.

Sincronização contínua

*Se a hierarquização na nuvem estiver ativada, é provável que observe um melhor desempenho, uma vez que apenas alguns dos dados do ficheiro são transferidos. A Sincronização de Arquivos do Azure só baixa os dados de arquivos armazenados em cache quando eles são alterados em qualquer um dos pontos de extremidade. Para quaisquer arquivos hierárquicos ou recém-criados, o agente não baixa os dados do arquivo e, em vez disso, sincroniza apenas o namespace com todos os pontos de extremidade do servidor. O agente também suporta downloads parciais de arquivos hierárquicos à medida que são acessados pelo usuário.

Como um guia geral para sua implantação, tenha algumas coisas em mente:

• O débito do objeto reduz-se horizontalmente de forma aproximada em proporção ao número de grupos de sincronização no servidor. Dividir dados em múltiplos grupos de sincronização num servidor gera um débito melhor, o que também é limitado pelo servidor e pela rede.
• O débito do objeto é inversamente proporcional ao débito de MiB por segundo. Para arquivos menores, você experimentará uma taxa de transferência mais alta em termos do número de objetos processados por segundo, mas uma taxa de transferência MiB por segundo menor. Por outro lado, para arquivos maiores, você obterá menos objetos processados por segundo, mas maior taxa de transferência de MiB por segundo. O débito de MiB por segundo é limitado pelos destinos de dimensionamento dos Ficheiros do Azure.

Consulte também

• Compreender o desempenho dos Arquivos do Azure
• Planear uma implementação de Ficheiros do Azure
• Planear uma implementação do Azure File Sync