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 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
| Modelo de gestão | Modelo de faturação | Nível 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) | Geo (GRS) | |
|
| Microsoft.Storage | Provisionado v2 | HDD (padrão) | GeoZona (GZRS) | |
|
| Microsoft.Storage | Provisionado v1 | SSD (premium) | Local (LRS) | |
|
| Microsoft.Storage | Provisionado v1 | SSD (premium) | Zona (ZRS) | |
|
| Microsoft.Storage | Pay as you go | HDD (padrão) | Local (LRS) | |
|
| Microsoft.Storage | Pay as you go | HDD (padrão) | Zona (ZRS) | |
|
| Microsoft.Storage | Pay as you go | HDD (padrão) | Geo (GRS) | |
|
| Microsoft.Storage | Pay as you go | HDD (padrão) | GeoZona (GZRS) | |
|
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 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 arquivos do Azure; nenhum outro recurso de armazenamento (contêineres 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-lhe implementar partilhas de ficheiros pré-pagas em hardware 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.
| Atributo | SSD provisionado v1 | HDD provisionado v2 | HDD pré-pago consoante a utilização |
|---|---|---|---|
| Tipo de conta de armazenamento | FileStorage | FileStorage | StorageV2 |
| SKUs |
|
|
|
| Número de contas de armazenamento por região e 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 usar 50 ou menos) | 50 | Ilimitado (recomendado usar 50 ou menos) |
| IOPS máximo | 102.400 IOPS | 50.000 IOPS | 20.000 IOPS |
| Débito máximo | 10.340 MiB / seg | 5.120 MiB / seg |
|
| 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 por 5 minutos | 800 por 5 minutos | 800 por 5 minutos |
| Operações de gravação de gerenciamento | 10 por segundo/1200 por hora | 10 por segundo/1200 por hora | 10 por segundo/1200 por hora |
| Operações da lista de gestão | 100 por 5 minutos | 100 por 5 minutos | 100 por 5 minutos |
Regiões selecionadas com maior débito máximo para HDD pay-as-you-go
As seguintes regiões têm um débito máximo aumentado para contas de armazenamento pré-pago de HDD (StorageV2):
- Ásia Leste
- Sudeste Asiático
- Leste da Austrália
- Sul do Brasil
- Canadá Central
- China Leste 2
- Norte da China 3
- Europa do Norte
- Europa Ocidental
- França Central
- Alemanha Centro-Oeste
- Índia Central
- Leste do Japão
- Jio, Oeste da Índia
- Coreia do Sul Central
- Leste da Noruega
- Norte da África do Sul
- Suécia Central
- Norte dos E.A.U.
- Sul do Reino Unido
- E.U.A. Central
- E.U.A. Leste
- E.U.A. Leste 2
- US Gov - Virginia
- US Gov - Arizona
- E.U.A. Centro-Norte
- E.U.A. Centro-Sul
- E.U.A. Oeste
- E.U.A. Oeste 2
- EUA Oeste 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 de compartilhamento de arquivos.
| Atributo | SSD provisionado v1 | HDD provisionado v2 | HDD pré-pago consoante a utilização |
|---|---|---|---|
| Unidade de provisionamento de armazenamento | 1 GiB | 1 GiB | N/A |
| Unidade de provisionamento IOPS | N/A | 1 IO / seg | N/A |
| Unidade de provisionamento de taxa de transferência | N/A | 1 MiB / seg | 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 ficheiros | Ilimitado | Ilimitado | Ilimitado |
| IOPS máximo | 102.400 IOPS (dependente de provisionamento) | 50.000 IOPS (dependentes de provisionamento) | 20.000 IOPS |
| Débito máximo | 10.340 MiB / seg (dependente de provisionamento) | 5.120 IOPS (dependente de provisionamento) | Até limites de conta de armazenamento |
| Número máximo de snapshots de compartilhamento | 200 instantâneos | 200 instantâneos | 200 instantâneos |
| Comprimentomáximo do nome do arquivo 3 (nome completo do caminho, 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 componente2 do nome do caminho individual ( 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 link físico (somente NFS) | 178 | N/A | N/A |
| Número máximo de canais SMB Multichannel | 4 | N/A | N/A |
| Número máximo de políticas de acesso armazenado por compartilhamento de arquivos | 5 | 5 | 5 |
3 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.
| Atributo | SSD provisionado v1 | HDD provisionado v2 | HDD pré-pago consoante a utilização |
|---|---|---|---|
| Tamanho máximo do ficheiro | 4 TiB | 4 TiB | 4 TiB |
| IOPS de dados máximo por arquivo | 8.000 IOPS | 1000 IOPS | 1000 IOPS |
| Taxa de transferência máxima por arquivo | 1.024 MiB / seg | 60 MiB / seg | 60 MiB / seg |
| Máximo de identificadores simultâneos para o diretório raiz | 10.000 alças | 10.000 alças | 10.000 alças |
| Máximo de identificadores simultâneos por arquivo e diretório | 2000 identificadores | 2000 identificadores | 2000 identificadores |
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.
Aviso
Embora os Arquivos do Azure possam oferecer suporte a até 10.000 usuários simultâneos de um único compartilhamento de arquivos, é fundamental testar adequadamente suas cargas de trabalho em relação ao tamanho e ao tipo de compartilhamento de arquivos que você criou. Seus requisitos podem variar de acordo com os usuários, o tamanho do perfil e a 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), 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:
| Recurso | Destino | Limite fixo |
|---|---|---|
| Serviços de Sincronização de Armazenamento por região | 100 Serviços de Sincronização de Armazenamento | Sim |
| Serviços de sincronização de armazenamento por assinatura | 15 Serviços de sincronização de armazenamento | Sim |
| Grupos de sincronização por Serviço de Sincronização de Armazenamento | 200 grupos de sincronização | Yes |
| Servidores registados 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 finais privados | Sim |
| Pontos finais de cloud por grupo de sincronização | 1 ponto final de cloud | Yes |
| Pontos finais de servidor por grupo de sincronização | 100 pontos finais de servidor | Yes |
| Pontos finais de servidor por servidor | 30 pontos finais de servidor | Yes |
| Objetos do sistema de ficheiros (diretórios e ficheiros) por grupo de sincronização | 100 milhões de objetos | No |
| Número máximo de objetos do sistema de arquivos (diretórios e arquivos) em um diretório (não recursivo) | 5 milhões de objetos | Yes |
| Tamanho máximo do descritor de segurança do objeto (diretórios e ficheiros) | 64 KiB | Yes |
| Tamanho dos ficheiros | 100 GiB | No |
| Tamanho mínimo de ficheiro de um ficheiro a ser escalonado | Com base no tamanho do cluster do sistema de ficheiros (tamanho de cluster do sistema de ficheiros a dobrar). Por exemplo, se o tamanho do cluster do sistema de ficheiros for 4 KiB, o tamanho mínimo do ficheiro será 8 KiB. | Sim |
Nota
Um ponto de extremidade do Azure File Sync pode ser dimensionado até o tamanho de um compartilhamento de arquivos do Azure. Se o limite de tamanho de compartilhamento de arquivos do Azure for atingido, a sincronização não poderá operar.
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:
- 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.
- 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.
Nota
Quando muitos pontos de extremidade de servidor no mesmo grupo de sincronização estão sincronizando ao mesmo tempo, eles estão disputando recursos de serviço de nuvem. Como resultado, o desempenho do carregamento é afetado. Em casos extremos, algumas sessões de sincronização não conseguirão acessar os recursos e falharão. No entanto, essas sessões de sincronização serão retomadas em breve e, eventualmente, terão êxito quando o congestionamento for reduzido.
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:
| Configuração do sistema | Detalhes |
|---|---|
| CPU | 64 Núcleos Virtuais com cache L3 de 64 MiB |
| Memória | 128 GiB |
| Disco | Discos SAS com RAID 10 com cache apoiada por bateria |
| Rede | 1 Gbps de rede |
| Carga de trabalho | Servidor de Ficheiros para Fins Gerais |
Aprovisionamento pontual inicial
| Aprovisionamento pontual inicial | Detalhes |
|---|---|
| Número de objetos | 25 milhões de objetos |
| Tamanho do Conjunto de Dados | ~4,7 TiB |
| Tamanho Médio do Ficheiro | ~200 KiB (Ficheiro Maior: 100 GiB) |
| Enumeração inicial de alterações da cloud | 80 objetos por segundo |
| Débito de Carregamento | 20 objetos por segundo por grupo de sincronização |
| Débito de Transferência do Espaço de Nomes | 400 objetos por segundo |
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
| Sincronização contínua | Detalhes |
|---|---|
| Número de objetos sincronizados | 125 000 objetos (~1% de taxa de abandono) |
| Tamanho do Conjunto de Dados | 50 GiB |
| Tamanho Médio do Ficheiro | ~500 KiB |
| Débito de Carregamento | 20 objetos por segundo por grupo de sincronização |
| Débito de Transferência Total* | 60 objetos por segundo |
*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.
Nota
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, 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.