Hierarquia de armazenamento do Azure NetApp Files

Antes de criar um volume no Azure NetApp Files, tem de comprar e configurar um pool de dimensão aprovisionada. Para configurar um conjunto de capacidade, precisa de ter uma conta da NetApp. Compreender a hierarquia de armazenamento ajuda-o a configurar e gerir os recursos do Azure NetApp Files.

Importante

Atualmente, os Arquivos NetApp do Azure não oferecem suporte à migração de recursos entre assinaturas.

Diagrama conceptual da hierarquia de armazenamento

O exemplo seguinte mostra as relações da subscrição do Azure, contas NetApp, conjuntos de capacidade e volumes.

Diagrama conceitual da hierarquia de armazenamento.

Contas NetApp

Conjuntos de capacidade

Compreender como os pools de capacidade funcionam ajuda a selecionar os tipos de pool de capacidade certos para suas necessidades de armazenamento.

Regras gerais dos grupos de capacidade regular

  • Um conjunto de capacidade é medido pela sua capacidade aprovisionada.
    Para obter mais informações, consulte Tipos de QoS.
  • A capacidade é provisionada pelas SKUs fixas que você comprou (por exemplo, uma capacidade de 4 TiB).
  • Um conjunto de capacidade pode ter apenas um nível de serviço.
  • Cada pool de capacidade pode pertencer a apenas uma conta NetApp. No entanto, você pode ter vários pools de capacidade em uma conta NetApp.
  • Não é possível mover um pool de capacidade entre contas NetApp.
    Por exemplo, no diagrama conceitual da hierarquia de armazenamento, não é possível mover a conta NetApp Leste dos EUA do Pool de Capacidade 1 para a conta NetApp Oeste dos EUA 2.
  • Não é possível excluir um pool de capacidade até excluir todos os volumes dentro do pool de capacidade.
  • O armazenamento de arquivos NetApp do Azure com acesso infrequente é suportado em pools de capacidade de nível de serviço Flexível, Standard, Premium e Ultra. Para obter mais informações sobre níveis de serviço, incluindo o nível de serviço flexível, consulte Níveis de serviço para arquivos NetApp do Azure.

Regras gerais dos pools de capacidade elástica

  • Deve ter uma conta NetApp designada para uso com armazenamento redundante de zona Elastic.
  • Um conjunto de capacidade é medido pela sua capacidade aprovisionada.
  • A capacidade é provisionada pelas SKUs fixas que você comprou (por exemplo, uma capacidade de 4 TiB).
  • Um conjunto de capacidade pode ter apenas um nível de serviço.
  • Cada pool de capacidade pode pertencer apenas a uma conta NetApp Elastic. Pode ter múltiplos pools de capacidade dentro de uma conta NetApp Elastic.
  • Não podes mover um pool de capacidade entre contas NetApp Elastic. Por exemplo, no diagrama da hierarquia de armazenamento, não pode mover o Capacity Pool 1 na conta NetApp Elastic do US East 2 para a conta do NetApp Elastic do US West 2.
  • Não é possível excluir um pool de capacidade até excluir todos os volumes dentro do pool de capacidade.
  • Se estiver a usar chaves geridas pelo cliente, certifique-se de que configurou a encriptação antes de criar o pool de capacidade...
  • Os pools de capacidade elástica permitem-lhe criar uma ordem de preferência de failover para as zonas de disponibilidade. Algumas regiões que suportam o nível de serviço Elastic oferecem apenas duas zonas de disponibilidade. Consulte a região para a zona de disponibilidade com a API REST antes de criar o pool de capacidade:
GET  https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.NetApp/locations/{location}/elasticRegionInfo?api-version=2025-09-01-preview.

Tipos de Qualidade de Serviço (QoS) para grupos de capacidade

O tipo de QoS é um atributo de um pool de capacidade. O Azure NetApp Files fornece dois tipos de pools de capacidade QoS: auto (por defeito para pools de capacidade regulares), manual (para pools de capacidade regulares) e comum (por defeito para pools de capacidade elásticos).

Tipo de QoS automático (ou auto)

Quando você cria um pool de capacidade, o tipo de QoS padrão é auto.

Em um pool de capacidade de QoS automático, a taxa de transferência é atribuída automaticamente aos volumes no pool, proporcionalmente à cota de tamanho atribuída aos volumes.

A taxa de transferência máxima alocada a um volume depende do nível de serviço do pool de capacidade e da cota de tamanho do volume. Consulte Níveis de serviço para Arquivos NetApp do Azure para obter um exemplo de cálculo.

Para considerações de desempenho sobre tipos de QoS, consulte Considerações de desempenho para Azure NetApp Files.

Tipo de QoS manual

Ao criar um pool de capacidade, você pode especificar para que o pool de capacidade use o tipo de QoS manual. Você também pode alterar um pool de capacidade existente para usar o tipo de QoS manual. Definir o tipo de capacidade como QoS manual é uma mudança permanente. Não é possível converter um pool de capacidade do tipo QoS manual para um pool de capacidade de QoS automático. (No entanto, você pode mover volumes de um pool de capacidade de QoS manual para um pool de capacidade de QoS automático. Consulte Alterar dinamicamente o nível de serviço de um volume.)

Em um pool de capacidade de QoS manual, você pode atribuir a capacidade e a taxa de transferência de um volume independentemente. Para obter os níveis de taxa de transferência mínimo e máximo, consulte Limites de recursos para arquivos NetApp do Azure. O débito total de todos os volumes criados com um pool de capacidade QoS manual está limitado pelo débito total desse pool. Ele é determinado pela combinação do tamanho do pool e da taxa de transferência do nível de serviço. Por exemplo, um pool de capacidade de 4 TiB com o nível de serviço Ultra tem uma capacidade total de transferência de 512 MiB/s (4 TiB x 128 MiB/s/TiB) disponível para os volumes.

Os pools de capacidade de QoS manual são necessários para o nível de serviço flexível, permitindo que você ajuste a taxa de transferência e os limites de tamanho independentemente para pools de capacidade usando QoS manual. Esse nível de serviço foi projetado para aplicativos exigentes, como Oracle ou SAP HANA. Para obter informações sobre a taxa de transferência, consulte Níveis de serviço para arquivos NetApp do Azure.

Exemplo de utilização de QoS manual

Quando você usa um pool de capacidade de QoS manual com, por exemplo, um sistema SAP HANA, um banco de dados Oracle ou outras cargas de trabalho que exigem vários volumes, o pool de capacidade pode ser usado para criar esses volumes de aplicativos. Cada volume pode fornecer o tamanho e a taxa de transferência individuais para atender aos requisitos do aplicativo. Consulte Exemplos de limites de throughput dos volumes num pool de capacidade de QoS manual para obter detalhes sobre os benefícios.

Partilhado Tipo QoS

Quando crias um pool de capacidade no nível de serviço de armazenamento redundante por zonas do Elastic, o tipo de QoS por defeito é partilhado.

A largura de banda não é alocada por volume num pool de capacidade QoS partilhado. Em vez disso, todos os volumes partilham o débito total do pool. O orçamento de desempenho do pool é determinado pelo seu tamanho e nível de serviço (por exemplo, cerca de 32 MiB/s de largura de banda por 1 TiB de capacidade no nível de armazenamento redundante entre zonas). Ao contrário do QoS automático (que liga o débito ao tamanho do volume) ou do QoS manual (que exige definir o débito de cada volume), um pool de QoS partilhado não tem limites fixos por volume. O sistema distribui dinamicamente as E/S para que cada volume possa atingir a largura de banda necessária desde que o pool não tenha ultrapassado o seu limite.

Observação

O débito total em QoS partilhado continua a ser finito (limitado pelo tamanho do pool × pela taxa de transmissão ao nível de serviço), por isso planeie a capacidade em conformidade. Para limites exatos de throughput, veja Limites de Recursos Armazenamento elástico redundante por zonas.

Volumes

  • Um volume é medido pelo consumo de capacidade lógica e é escalável.
  • O consumo de capacidade de um volume é contabilizado na capacidade aprovisionada do seu pool.
  • O consumo de throughput de um volume é descontado do throughput disponível do seu pool. Consulte Tipo de QoS manual.
  • Cada volume pertence a apenas um conjunto, mas um conjunto pode conter vários volumes.
  • Os volumes contêm uma capacidade entre 50 GiB e 100 TiB. Você pode criar um grande volume com um tamanho entre 50 GiB e 1 PiB.
  • Por predefinição, todos os volumes normais existentes e novos do Azure NetApp Files suportam um tamanho máximo de ficheiros de 64 TiB.

Volumes elásticos

  • Um volume é medido pelo consumo de capacidade lógica e é escalável.
  • O consumo de capacidade de um volume é contabilizado na capacidade aprovisionada do seu pool.
  • O consumo de throughput de um volume contribui para a utilização global de throughput do pool, que é distribuída dinamicamente por todos os volumes com base na procura e disponibilidade.
  • Cada volume pertence a apenas um conjunto, mas um conjunto pode conter vários volumes.
  • A capacidade de volumes situa-se entre 1 GiB e 16 TiB. Atualmente, não é possível criar um volume grande.

Grandes volumes

Os Arquivos NetApp do Azure permitem criar grandes volumes de até 1 PiB. Por outro lado, os volumes regulares de Arquivos NetApp do Azure são oferecidos entre 50 GiB e 102.400 GiB.

Grandes volumes começam com uma capacidade de 50 TiB e escalam até 1 PiB (ou 2 PiB como pedidos especiais). Com o acesso frio ativado, grandes volumes podem crescer para 7,2 PiB.

Para obter mais informações, consulte Requisitos e considerações para grandes volumes.

Pontos finais de armazenamento

Para servir um volume, o Azure NetApp Files cria um endpoint de armazenamento (o recurso de rede, com o seu próprio endereço IP, que os clientes montam) na sub-rede delegada. Um endpoint de armazenamento é sempre criado quando o primeiro volume é implementado numa sub-rede delegada. Para implementações de volumes subsequentes, o serviço pode criar autonomamente mais endpoints de armazenamento quando disponibilidade de recursos, necessidades de desempenho ou requisitos de colocação assim o exigirem. A criação e colocação de endpoints de armazenamento são operações internas de serviço e não são expostas como opções configuráveis pelo utilizador.

Observação

Criar um endpoint de armazenamento acrescenta ao tempo total de provisionamento. Quando é necessário criar um novo endpoint de armazenamento durante a criação de volumes, o volume pode permanecer no estado de Criação durante vários minutos antes de transitar para Succeeded. Este comportamento é esperado. Volumes que reutilizam um endpoint de armazenamento existente normalmente provisionam mais rapidamente porque não é necessário novo endpoint.

O mesmo comportamento aplica-se às implantações de grupos de volume de aplicações, que criam múltiplos pontos finais de armazenamento para colocar os volumes de dados e registos de forma ótima. Por isso, criar um grupo de volume de aplicações pode demorar entre 9 a 12 minutos. Para mais informações, consulte Compreender os grupos de volumes de aplicações do Azure NetApp Files.

Se a sua implementação depende de tempos de provisionamento previsíveis, planeie a criação do endpoint de armazenamento antes do início da implementação da carga de trabalho. Esta consideração é especialmente importante para implementações automatizadas do Azure Kubernetes Service (AKS) ou Azure Red Hat OpenShift que provisionam dinamicamente volumes Azure NetApp Files. Durante a inicialização do ambiente, crie um pequeno volume na sub-rede delegada de destino. O volume inicial pode desencadear a criação do endpoint de armazenamento antecipadamente, pelo que volumes posteriores podem provisionar mais rapidamente quando o serviço pode reutilizar o endpoint existente.

Esta abordagem pode reduzir os atrasos de provisionamento, mas não garante um tempo de provisionamento consistente para cada volume posterior. Se o Azure NetApp Files determinar que é necessário um endpoint de armazenamento adicional devido à disponibilidade de recursos, necessidades de desempenho ou requisitos de colocação, o serviço poderá criar outro endpoint durante uma futura implementação de volumes. Nesse caso, o volume pode novamente permanecer no estado de Criação durante vários minutos antes de transitar para Sucedido. Planeie fluxos de trabalho de automação para permitir este comportamento esperado.

Próximos passos

  • Last updated on