Metas de escalabilidade e desempenho para Arquivos do Azure e Sincronização de Arquivos do Azure
O Arquivos do Azure oferece compartilhamentos de arquivos totalmente gerenciados na nuvem que são acessíveis por meio de protocolos de sistema de arquivos SMB ou NFS (Network File System). Este artigo discute as metas de escalabilidade e desempenho dos arquivos do Azure e do Azure File Sync.
Os destinos listados aqui podem ser afetados por outras variáveis na 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 o padrão de uso para determinar se a escalabilidade e o desempenho dos Arquivos do Azure atendem aos seus requisitos.
Aplica-se a
| Modelo de gestão | Modelo de cobrança | Camada de mídia | Redundância | SMB | NFS |
|---|---|---|---|---|---|
| Microsoft.Storage | Provisionado v2 | HDD (padrão) | Local (LRS) |  |
 |
| Microsoft.Storage | Provisionado v2 | HDD (padrão) | Zona (ZRS) | |
|
| Microsoft.Storage | Provisionado v2 | HDD (padrão) | Localização geográfica (GRS) | |
|
| Microsoft.Storage | Provisionado v2 | HDD (padrão) | GeoZone (GZRS) | |
|
| Microsoft.Storage | Provisionado v1 | SSD (premium) | Local (LRS) | |
|
| Microsoft.Storage | Provisionado v1 | SSD (premium) | Zona (ZRS) | |
|
| Microsoft.Storage | Pagamento conforme o uso | HDD (padrão) | Local (LRS) | |
|
| Microsoft.Storage | Pagamento conforme o uso | HDD (padrão) | Zona (ZRS) | |
|
| Microsoft.Storage | Pagamento conforme o uso | HDD (padrão) | Localização geográfica (GRS) | |
|
| Microsoft.Storage | Pagamento conforme o uso | HDD (padrão) | GeoZone (GZRS) | |
|
Destinos de escala de Arquivos do Azure
Os compartilhamentos de arquivo do Azure são implantados em contas de armazenamento, que são objetos de nível superior que representam um pool de armazenamento compartilhado. Este 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 escalabilidade da conta de armazenamento
Os destinos de escala da conta de armazenamento se aplicam no nível da conta de armazenamento. Há dois tipos principais de contas de armazenamento para Arquivos do Azure:
Contas de armazenamento FileStorage: as contas de armazenamento FileStorage permitem implantar compartilhamentos de arquivos do Azure com um modelo de cobrança provisionado. As contas FileStorage só podem ser usadas para armazenar compartilhamentos de arquivo do Azure; nenhum outro recurso de armazenamento (contêineres de blob, filas, tabelas etc.) pode ser implantado em uma conta FileStorage.
Contas de armazenamento de uso geral versão 2 (GPv2): as contas de armazenamento GPv2 permitem implantar compartilhamentos de arquivos com Pagamento Conforme o Uso em hardware baseado em HDD. Além de armazenar compartilhamentos de arquivo do Azure, as contas de armazenamento GPv2 podem armazenar outros recursos de armazenamento, como contêineres de blob, filas ou tabelas.
| Atributo | SSD provisionado v1 | HDD provisionado v2 | HDD de Pagamento Conforme o Uso |
|---|---|---|---|
| Tipo de conta de armazenamento | FileStorage | FileStorage | StorageV2 |
| SKUs |
|
|
|
| Número de contas de armazenamento por regiõ por assinatura | 250 | 250 | 250 |
| Capacidade máxima de armazenamento | 100 TiB | 4 PiB | 5 PiB |
| Número máximo de compartilhamentos de arquivos | 1024 (recomendado para usar 50 ou menos) | 50 | Ilimitado (recomendado para usar 50 ou menos) |
| IOPS máximo | 102.400 IOPS | 50.000 IOPS | 20.000 IOPS |
| Taxa de transferência máxima | 10.340 MiB/s | 5.120 MiB / s |
|
| Número máximo de regras de rede virtual | 200 | 200 | 200 |
| Número máximo de regras de endereço IP | 200 | 200 | 200 |
| Operações de leitura de gerenciamento | 800 a cada 5 minutos | 800 a cada 5 minutos | 800 a cada 5 minutos |
| Operações de gravação de gerenciamento | 10 por segundo/1.200 por hora | 10 por segundo/1.200 por hora | 10 por segundo/1.200 por hora |
| Operações da lista de gerenciamento | 100 a cada 5 minutos | 100 a cada 5 minutos | 100 a cada 5 minutos |
Regiões selecionadas com maior taxa de transferência máxima para HDD de Pagamento Conforme o Uso
As regiões a seguir têm uma taxa de transferência máxima maior para contas de armazenamento com pagamento conforme o uso do HDD (StorageV2):
- Leste da Ásia
- Sudeste Asiático
- Leste da Austrália
- Brazil South
- Canadá Central
- Leste da China 2
- Norte da China 3
- Norte da Europa
- Europa Ocidental
- França Central
- Centro-Oeste da Alemanha
- Índia Central
- Leste do Japão
- Jio Oeste da Índia
- Coreia Central
- Leste da Noruega
- Norte da África do Sul
- Suécia Central
- Norte dos EAU
- Sul do Reino Unido
- Centro dos EUA
- Leste dos EUA
- Leste dos EUA 2
- Gov. dos EUA – Virgínia
- Governo dos EUA do Arizona
- Centro-Norte dos EUA
- Centro-Sul dos Estados Unidos
- Oeste dos EUA
- Oeste dos EUA 2
- Oeste dos EUA 3
Destinos de escala de compartilhamento de arquivos do Azure
Os destinos de escala de compartilhamento de arquivos do Azure se aplicam no nível do compartilhamento de arquivos.
| Atributo | SSD provisionado v1 | HDD provisionado v2 | HDD de Pagamento Conforme o Uso |
|---|---|---|---|
| Unidade de provisionamento de armazenamento | 1 GiB | 1 GiB | N/A |
| Unidade de provisionamento IOPS | N/A | 1 IO / s | N/A |
| Unidade de provisionamento de taxa de transferência | N/A | 1 MiB/s | N/A |
| Tamanho mínimo de armazenamento | 100 GiB (provisionado) | 32 GiB (provisionado) | 0 bytes |
| Tamanho máximo de armazenamento | 100 TiB | 256 TiB | 100 TiB |
| Número máximo de arquivos | Ilimitado | Ilimitado | Ilimitado |
| IOPS máximo | 102.400 IOPS (dependente do provisionamento) | 50.000 IOPS (dependente do provisionamento) | 20.000 IOPS |
| Taxa de transferência máxima | 10.340 MiB/s (dependente do provisionamento) | 5.120 IOPS (dependente do provisionamento) | Até os limites da conta de armazenamento |
| Número máximo de instantâneos de compartilhamento | 200 instantâneos | 200 instantâneos | 200 instantâneos |
| Comprimento máximo do nome do arquivo 3 (nome de caminho completo, incluindo todos os diretórios, nomes de arquivo e caracteres de barra invertida) | 2\.048 caracteres | 2\.048 caracteres | 2\.048 caracteres |
| Comprimento máximo do componente individual do nome de caminho2 (no caminho \A\B\C\D, cada letra representa um diretório ou arquivo que é um componente individual) | 255 caracteres | 255 caracteres | 255 caracteres |
| Limite de vínculo físico (somente NFS) | 178 | N/D | N/D |
| Número máximo de canais do SMB Multichannel | 4 | N/D | N/D |
| Número máximo de políticas de acesso armazenadas por compartilhamento de arquivo | 5 | 5 | 5 |
3 Arquivos do Azure impõe determinadas regras de nomenclatura para nomes de diretório e arquivo.
Destinos de escala de arquivo
Os destinos de escala de arquivos se aplicam a arquivos individuais armazenados em compartilhamentos de arquivos do Azure.
| Atributo | SSD provisionado v1 | HDD provisionado v2 | HDD de Pagamento Conforme o Uso |
|---|---|---|---|
| Tamanho máximo do arquivo | 4 TiB | 4 TiB | 4 TiB |
| Máximo de IOPS de dados por arquivo | 8.000 IOPS | 1\.000 IOPS | 1\.000 IOPS |
| Taxa de transferência máxima por arquivo | 1.024 MiB/s | 60 MiB/s | 60 MiB/s |
| Máximo de identificadores simultâneos para o diretório raiz | 10.000 identificadores | 10.000 identificadores | 10.000 identificadores |
| Máximo de identificadores simultâneos por arquivo e diretório | 2\.000 identificadores | 2\.000 identificadores | 2\.000 identificadores |
Diretrizes de dimensionamento de Arquivos do Azure para a Área de Trabalho Virtual do Azure
Um caso de uso popular para os 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 anexação de aplicativo. Em implantações de Área de Trabalho Virtual do Azure em larga escala, você poderá 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 os identificadores são consumidos por vários tipos de imagens de disco e fornece diretrizes de dimensionamento dependendo da tecnologia que você está usando.
FSLogix
Se você estiver usando FSLogix com a Área de Trabalho Virtual do Azure, seus contêineres de perfil de usuário serão arquivos VHD (Disco Rígido Virtual) ou VHDX (Disco Rígido Virtual do Hyper-V) e eles serão montados em um contexto do usuário, não em um contexto do 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 no máximo 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 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.
Aviso
Embora os Arquivos do Azure possam dar suporte a até 10.000 usuários simultâneos de um único compartilhamento de arquivos, é essencial testar corretamente suas cargas de trabalho em relação ao tamanho e ao tipo de compartilhamento de arquivos que você criou. Seus requisitos podem variar com base nos usuários, no tamanho do perfil e na carga de trabalho.
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), que está abaixo do limite de 10.000 identificadores abertos. Para usuários do FSLogix, é extremamente improvável atingir o limite de 2.000 identificadores de arquivo aberto e diretório. 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.
Anexação de aplicativo com o CimFS
Se você estiver usando Anexação de aplicativo MSIX ou Anexação de aplicativo para anexar aplicativos dinamicamente, você poderá usar arquivos CimFS (Sistema de Arquivos de Imagem Composta) 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 usuários é irrelevante ao calcular os limites de escala. Quando uma VM é inicializada, ela monta a imagem de disco, mesmo que não haja usuários.
Se você estiver usando a Anexação de aplicativo com o CimFS, as imagens de disco consumirão apenas 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 que monta a imagem de disco, você precisará de um identificador para cada para três arquivos no diretório. Portanto, se você tiver 100 VMs, precisará de 300 identificadores de arquivo.
Você poderá ficar sem identificadores de arquivo se o número de VMs por aplicativo exceder 2.000. Nesse caso, use um compartilhamento de arquivo adicional do Azure.
Anexação de aplicativo com VHD/VHDX
Se você estiver usando a anexação de aplicativo com arquivos VHD/VHDX, os arquivos serão montados em um contexto do sistema, não em um contexto de usuário, e serão compartilhados e somente 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 multiplicadas pelo número de aplicativos deve ser menor que 10.000, e o número de VMs por aplicativo não pode exceder 2.000. Portanto, a restrição é o que você atingir 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 de diretório raiz primeiro. Por exemplo, 100 VMs que montam 100 arquivos VHDX compartilhados atingirão o limite de 10.000 identificadores de diretório raiz.
Em outro exemplo, 100 VMs que acessam 20 aplicativos exigirão 2.000 identificadores de diretório raiz (100 x 20 = 2.000), o que está dentro do limite de 10.000 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 nesse caso (100 identificadores de arquivo + 100 identificadores de diretório), que está confortavelmente abaixo do limite de 2.000 identificadores por arquivo/diretório.
Se você estiver atingindo os limites no máximo de identificadores simultâneos para o diretório raiz ou por arquivo/diretório, use um compartilhamento de arquivo adicional do Azure.
Destinos de escala de Sincronização de Arquivos do Azure
A tabela a seguir indica quais destinos são flexíveis, representando o limite testado pela Microsoft, e rígidos, indicando um máximo imposto:
| Recurso | Destino | Limite rígido |
|---|---|---|
| Serviços de Sincronização de Armazenamento por região | 100 Serviços de Sincronização de Armazenamento | Yes |
| Serviços de sincronização de armazenamento por assinatura | 15 serviços de sincronização de armazenamento | Yes |
| Grupos de sincronização por Serviço de Sincronização de Armazenamento | 200 grupos de sincronização | Sim |
| Servidores registrados por Serviço de Sincronização de Armazenamento | 100 servidores | Sim |
| Pontos de extremidade privados por serviço de sincronização de armazenamento | 100 pontos de extremidade privados | Yes |
| Pontos de extremidade na nuvem por grupo de sincronização | 1 ponto de extremidade de nuvem | Sim |
| Pontos de extremidade no servidor por grupo de sincronização | 100 pontos de extremidade de servidor | Sim |
| Pontos de extremidade de servidor por servidor | 30 pontos de extremidade de servidor | Sim |
| Objetos do sistema de arquivos (diretórios e arquivos) por grupo de sincronização | 100 milhões de objetos | Não |
| Número máximo de objetos do sistema de arquivos (diretórios e arquivos) em um diretório (não recursiva) | 5 milhões de objetos | Sim |
| Tamanho máximo do descritor de segurança (diretórios e arquivos) do objeto | 64 KiB | Sim |
| Tamanho do arquivo | 100 GiB | Não |
| Tamanho mínimo do arquivo para que um arquivo seja colocado em camadas | com base no tamanho do cluster do sistema de arquivos (tamanho duplo do cluster do sistema de arquivos). Por exemplo, caso o tamanho do cluster do sistema de arquivos seja 4 KiB, o tamanho mínimo do arquivo será 8 KiB. | Sim |
Observação
Um ponto de extremidade de Sincronização de Arquivos do Azure poderá aumentar o tamanho de um compartilhamento de arquivo do Azure. Caso o limite de tamanho do compartilhamento de arquivo do Azure seja atingido, a sincronização não será capaz de funcionar.
Métricas de desempenho de sincronização de arquivos do Azure
Como o agente da Sincronização de Arquivos do Azure é executado em um computador com Windows Server que se conecta aos compartilhamentos de arquivos do Azure, o desempenho eficaz da sincronização depende de vários fatores em sua infraestrutura: o Windows Server e a configuração do 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 atividade no conjunto de dados. Como a Sincronização de Arquivos do Azure funciona no nível do arquivo, as características de desempenho de uma solução baseada na Sincronização de Arquivos do Azure devem ser medidas pelo número de objetos (arquivos e diretórios) processados por segundo.
Para sincronização de arquivos do Azure, o desempenho for crítico em dois estágios:
- Provisionamento inicial único: para otimizar o desempenho no provisionamento inicial, consulte Integração com a Sincronização de Arquivos do Azure para obter detalhes para uma implantação ideal.
- Sincronização em andamento: depois que os dados inicialmente são propagados em compartilhamentos de arquivos do Azure, a sincronização de arquivos do Azure mantém vários pontos de extremidade em sincronia.
Observação
Quando muitos pontos de extremidade de servidor do mesmo grupo de sincronização estão sincronizando ao mesmo tempo, eles estão brigando por recursos do serviço de nuvem. Como resultado, o desempenho de upload é afetado. Em casos extremos, algumas sessões de sincronização não vão conseguir acessar os recursos e falharão. No entanto, essas sessões de sincronização serão retomadas em breve e, por fim, terão sucesso quando o congestionamento for reduzido.
Resultados do teste interno
Para ajudar você a planejar sua implantação para cada uma das etapas (provisionamento único inicial e sincronização contínua), aqui estão os resultados observados durante testes internos em um sistema com a seguinte configuração:
| Configuração do sistema | Detalhes |
|---|---|
| CPU | 64 núcleos virtuais com o cache de MiB L3 64 |
| Memória | 128 GiB |
| Disco | Cache de discos SAS com RAID 10 com bateria de reserva |
| Rede | Rede de 1 Gbps |
| Carga de trabalho | Servidor de arquivos de uso geral |
Provisionamento inicial de uso único
| Provisionamento inicial de uso único | Detalhes |
|---|---|
| Número de objetos | 25 milhões de objetos |
| Tamanho do conjunto de dados | Cerca de 4,7 TiB |
| Tamanho médio de arquivo | Cerca de 200 KiB (maior arquivo: 100 GiB) |
| Enumeração de alteração de nuvem inicial | 80 objetos por segundo |
| Carregue a taxa de transferência | 20 objetos por segundo por grupo de sincronização |
| Taxa de transferência do download do namespace | 400 objetos por segundo |
Enumeração inicial de alterações na nuvem: quando um novo grupo de sincronização é criado, a enumeração inicial de alterações na nuvem é o primeiro passo que é executado. Nesse processo, o sistema enumerará todos os itens no compartilhamento de arquivo do Azure. Durante esse processo, não haverá nenhuma atividade de sincronização. Nenhum item será baixado do ponto de extremidade na nuvem para o ponto de extremidade no servidor e nenhum item será carregado do ponto de extremidade no servidor para o ponto de extremidade na nuvem. A atividade de sincronização será retomada após a conclusão da enumeração de alteração de nuvem inicial.
A taxa de desempenho é de 80 objetos por segundo. Você pode estimar o tempo necessário para concluir a enumeração inicial de alterações na nuvem determinando o número de itens no compartilhamento de nuvem e usando a fórmula a seguir para obter o tempo em dias.
Tempo (em dias) para a enumeração de nuvem inicial = (número de objetos no ponto de extremidade de nuvem)/(80 * 60 * 60 * 24)
Sincronização inicial de dados do Windows Server para o compartilhamento de arquivos do Azure: muitas implantações de Sincronização de Arquivos do Azure começam com um compartilhamento de arquivos do Azure vazio porque todos os dados estão no Windows Server. Nesses casos, a enumeração inicial de alteração de nuvem é rápida, e a maior parte do tempo será gasta na sincronização de alterações do Windows Server para os compartilhamentos de arquivos do Azure.
Embora a sincronização carregue dados para o compartilhamento de arquivos do Azure, não há nenhum 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 carregamento de dados em segundo plano.
A sincronização inicial normalmente é limitada pela taxa de carregamento inicial de 20 arquivos por segundo por grupo de sincronização. Os clientes podem estimar o tempo para carregar todos os seus dados no Azure usando a fórmula a seguir para obter o tempo em dias:
Tempo (em dias) para carregar arquivos em um grupo de sincronização = (número de objetos no ponto de extremidade do servidor)/(20 * 60 * 60 * 24)
Dividir seus dados em vários pontos de extremidade de servidor e grupos de sincronização pode acelerar esse carregamento de dados inicial, pois o upload pode ser feito em paralelo para vários grupos de sincronização a uma taxa de 20 itens por segundo. Portanto, dois grupos de sincronização seriam executados em uma taxa combinada de 40 itens por segundo. O tempo total a ser concluído seria a estimativa de tempo para o grupo de sincronização com a maioria dos arquivos a serem sincronizados.
Taxa de transferência de download de namespace: quando um novo ponto de extremidade do servidor é adicionado a um grupo de sincronização existente, o agente de Sincronização de Arquivos do Azure não baixa nenhum conteúdo do arquivo do ponto de extremidade da nuvem. Sincronizar primeiro namespace completo e, em seguida, os gatilhos em segundo plano Lembre-se de fazer o download dos arquivos, em sua totalidade ou, se camadas na nuvem está habilitado para a política de camadas de nuvem definido no ponto de extremidade do servidor.
Sincronização contínua
| Sincronização contínua | Detalhes |
|---|---|
| Número de objetos sincronizados | 125.000 objetos (aproximadamente 1% rotatividade) |
| Tamanho do conjunto de dados | 50 GiB |
| Tamanho médio de arquivo | ~500 KiB |
| Carregue a taxa de transferência | 20 objetos por segundo por grupo de sincronização |
| Taxa de transferência do Download completo* | 60 objetos por segundo |
*Se a camada de nuvem estiver ativada, é provável que você observe um melhor desempenho, já que apenas alguns dados do arquivo são baixados. A Sincronização de Arquivos do Azure apenas faz o download dos dados dos arquivos em cache quando eles são alterados em qualquer um dos pontos de extremidade. Para arquivos em camadas ou recém-criados, o agente não faz o download dos dados do arquivo e, em vez disso, sincroniza apenas o namespace para todos os pontos de extremidade do servidor. O agente também dá suporte a downloads parciais de arquivos em camadas conforme são acessados pelo usuário.
Observação
Esses números não são uma indicação do desempenho que você experimentará. O desempenho real depende de vários fatores conforme descrito no início desta seção.
Como um guia geral para sua implantação, mantenha alguns pontos em mente:
- A taxa de transferência do objeto é dimensionado aproximadamente proporcionalmente ao número de grupos de sincronização no servidor. Dividir dados em vários grupos de sincronização em um servidor resulta em melhor taxa de transferência, que também é limitada pelo servidor e rede.
- A taxa de transferência do objeto é inversamente proporcional à MiB por segundo taxa de transferência. Para arquivos menores, você terá uma maior taxa de transferência em termos do número de objetos processados por segundo, mas uma taxa de transferência mais baixa em MiB por segundo. Por outro lado, para arquivos maiores, você terá menos objetos processados por segundo, mas uma taxa de transferência maior em MiB por segundo. A MiB por segundo taxa de transferência é limitada pelos destinos de escala de arquivos do Azure.