Gerarchia di archiviazione di Azure NetApp Files

Prima di creare un volume in Azure NetApp Files, è necessario acquistare e configurare un pool di capacità di cui è stato effettuato il provisioning. Per configurare un pool di capacità, è necessario un account di NetApp. Conoscere la gerarchia di archiviazione è utile per configurare e gestire le risorse di Azure NetApp Files.

Importante

Azure NetApp Files attualmente non supporta la migrazione delle risorse tra sottoscrizioni.

Diagramma concettuale della gerarchia di archiviazione

L'esempio seguente mostra le relazioni tra sottoscrizione di Azure, account di NetApp, pool di capacità e volumi.

Diagramma concettuale della gerarchia di archiviazione.

Account di NetApp

Pool di capacità

Comprendendo il funzionamento dei pool di capacità, sarà possibile scegliere i tipi di pool di capacità appropriati per le esigenze di archiviazione.

Regole generali dei pool di capacità regolari

  • Un pool di capacità viene misurato in base alla rispettiva capacità di cui è stato effettuato il provisioning.
    Per ulteriori informazioni, vedi Tipi QoS.
  • Il provisioning della capacità viene effettuato in base agli SKU fissi acquistati, ad esempio, una capacità di 4 TiB.
  • Un pool di capacità può avere un solo livello di servizio.
  • Ogni pool di capacità può appartenere a un solo account di NetApp. Tuttavia, è possibile avere più pool di capacità all'interno di un account di NetApp.
  • Non è possibile spostare un pool di capacità tra account NetApp.
    Ad esempio, nel diagramma concettuale della gerarchia di archiviazione, il pool di capacità 1 non può essere spostato dall'account di NetApp di Stati Uniti orientali all'account di NetApp di Stati Uniti occidentali 2.
  • Non è possibile eliminare un pool di capacità finché non si eliminano tutti i volumi all'interno del pool di capacità.
  • L'archiviazione di Azure NetApp Files con accesso a freddo è supportata nei pool di capacità Flexible, Standard, Premium e Ultra. Per altre informazioni sui livelli di servizio, incluso il livello di servizio flessibile, vedere Livelli di servizio per Azure NetApp Files.

Regole generali dei pool di capacità elastici

  • È necessario disporre di un account NetApp designato per l'uso con l'archiviazione a zone con ridondanza elastica.
  • Un pool di capacità viene misurato in base alla rispettiva capacità di cui è stato effettuato il provisioning.
  • Il provisioning della capacità viene effettuato in base agli SKU fissi acquistati, ad esempio, una capacità di 4 TiB.
  • Un pool di capacità può avere un solo livello di servizio.
  • Ogni pool di capacità può appartenere a un solo account NetApp Elastic. È possibile avere più pool di capacità all'interno di un account Elastic di NetApp.
  • Non è possibile spostare un pool di capacità tra account Elastic netApp. Nel diagramma della gerarchia di archiviazione, ad esempio, non è possibile spostare il Capacity Pool 1 dall'account NetApp Elastic US East 2 all'account NetApp Elastic US West 2.
  • Non è possibile eliminare un pool di capacità finché non si eliminano tutti i volumi all'interno del pool di capacità.
  • Se si usano chiavi gestite dal cliente, assicurarsi di aver configurato la crittografia prima di creare il pool di capacità.
  • I pool di capacità elastici consentono di creare un ordine di preferenza di failover delle zone di disponibilità. Alcune aree che supportano il livello di servizio elastico offrono solo due zone di disponibilità. Eseguire una query sull'area per la zona di disponibilità con l'API REST prima di creare il pool di capacità:
GET  https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.NetApp/locations/{location}/elasticRegionInfo?api-version=2025-09-01-preview.

Tipi di Qualità del servizio (QoS) per i pool di capacità

Il tipo QoS è un attributo di un pool di capacità. Azure NetApp Files offre due tipi di pool di capacità QoS: auto (pool di capacità regolari predefiniti), manuali (per i pool di capacità normali) e condivisi (impostazione predefinita per i pool di capacità elastici).

Tipo QoS automatico

Quando si crea un pool di capacità, il tipo QoS predefinito è automatico.

In un pool di capacità QoS automatico la velocità effettiva viene assegnata automaticamente ai volumi nel pool, proporzionalmente alla quota di dimensioni assegnata ai volumi.

La velocità effettiva massima allocata a un volume dipende dal livello di servizio del pool di capacità e dalla quota di dimensioni del volume. Per un calcolo di esempio, vedere Livelli di servizio per Azure NetApp Files.

Per considerazioni sulle prestazioni sui tipi QoS, vedere Considerazioni sulle prestazioni per Azure NetApp Files.

Tipo QoS manuale

Quando si crea un pool di capacità, è possibile specificare per il pool di capacità di usare il tipo QoS manuale. È anche possibile modificare un pool di capacità esistente per usare il tipo QoS manuale. L'impostazione del tipo di capacità su QoS manuale è una modifica permanente. Non è possibile convertire un pool di capacità del tipo QoS manuale in un pool di capacità QoS automatico. È tuttavia possibile spostare i volumi da un pool di capacità QoS manuale a un pool di capacità QoS automatico. Vedere Modificare dinamicamente il livello di servizio di un volume).

In un pool di capacità QoS manuale è possibile assegnare la capacità e la velocità effettiva per un volume in modo indipendente. Per i livelli di velocità effettiva minima e massima, vedere Limiti delle risorse per Azure NetApp Files. La velocità effettiva totale di tutti i volumi creati con un pool di capacità QoS manuale è limitata dalla velocità effettiva totale del pool. Il suo valore è determinato dalla combinazione della velocità effettiva del livello di servizio e delle dimensioni del pool. Un pool con capacità di 4 TiB con il livello di servizio Ultra ha ad esempio una capacità di velocità effettiva totale di 512 MiB/s (4 TiB x 128 MiB/s/TiB) disponibile per i volumi.

I pool di capacità QoS manuali sono necessari per il livello di servizio Flessibile, consentendo di modificare i limiti di velocità effettiva e dimensioni in modo indipendente per i pool di capacità usando QoS manuale. Questo livello di servizio è progettato per applicazioni impegnative, ad esempio Oracle o SAP HANA. Per informazioni sulla velocità effettiva, vedere Livelli di servizio per Azure NetApp Files.

Esempio di uso di QoS manuale

Quando si usa un pool di capacità QoS manuale con, ad esempio, un sistema SAP HANA, un database Oracle o altri carichi di lavoro che richiedono più volumi, è possibile usare il pool di capacità per creare questi volumi dell'applicazione. Ogni volume può fornire le singole dimensioni e la velocità effettiva per soddisfare i requisiti dell'applicazione. Per informazioni dettagliate sui vantaggi, vedere Esempi di limiti di velocità effettiva in un pool di capacità QoS manuale.

Condiviso Tipo QoS

Quando si crea un pool di capacità nel livello di servizio archiviazione con ridondanza della zona elastica, il tipo QoS predefinito viene condiviso.

In un pool di capacità QoS condiviso la velocità effettiva non viene allocata per volume. Tutti i volumi condividono invece la velocità effettiva totale del pool. Il budget delle prestazioni del pool è determinato dalle dimensioni e dal livello di servizio (ad esempio, circa 32 MiB/s di throughput per 1 TiB di capacità nel livello di servizio di archiviazione a ridondanza di zona). A differenza del QoS automatico (che collega la velocità effettiva alle dimensioni del volume) o QoS manuale (che richiede l'impostazione della velocità effettiva di ogni volume), un pool QoS condiviso non ha limiti fissi per volume. Il sistema distribuisce in modo dinamico le operazioni di I/O in modo che ogni volume possa raggiungere la velocità effettiva necessaria, purché il pool non abbia superato il limite.

Annotazioni

La velocità effettiva totale in QoS condiviso è ancora limitata (limitata dalle dimensioni del pool × velocità effettiva a livello di servizio), quindi pianificare di conseguenza la capacità. Per i limiti di velocità effettiva esatti, vedere Limiti delle risorse Archiviazione con ridondanza della zona elastica.

Volumi

  • Un volume viene misurato in base all'utilizzo della capacità logica ed è scalabile.
  • L'utilizzo della capacità di un volume concorre al calcolo della capacità di cui è stato effettuato il provisioning del pool.
  • L'utilizzo della velocità effettiva di un volume concorre al calcolo della velocità effettiva disponibile del pool. Vedere Tipo QoS manuale.
  • Ogni volume appartiene a un solo pool, ma un pool può contenere più volumi.
  • I volumi contengono una capacità compresa tra 50 GiB e 100 TiB. È possibile creare un volume di grandi dimensioni con dimensioni comprese tra 50 GiB e 1 PiB.
  • Per impostazione predefinita, tutti i volumi esistenti e nuovi normali di Azure NetApp Files supportano una dimensione massima di 64 TiB.

Volumi elastici

  • Un volume viene misurato in base all'utilizzo della capacità logica ed è scalabile.
  • L'utilizzo della capacità di un volume concorre al calcolo della capacità di cui è stato effettuato il provisioning del pool.
  • Il consumo del throughput di un volume contribuisce all'utilizzo complessivo del throughput del pool, che viene distribuito dinamicamente tra tutti i volumi in base alla domanda e alla disponibilità.
  • Ogni volume appartiene a un solo pool, ma un pool può contenere più volumi.
  • La capacità dei volumi è compresa tra 1 GiB e 16 TiB. Attualmente non è possibile creare un volume di grandi dimensioni.

Volumi di grandi dimensioni

Azure NetApp Files consente di creare volumi di grandi dimensioni fino a 1 PiB. Al contrario, i normali volumi di Azure NetApp Files vengono offerti tra 50 GiB e 102.400 GiB.

I volumi di grandi dimensioni iniziano con una capacità di 50 TiB e aumentano fino a 1 PiB (o 2 PiB come richieste speciali). Con l'accesso a freddo abilitato, i volumi di grandi dimensioni possono raggiungere fino a 7,2 PiB.

Per altre informazioni, vedere Requisiti e considerazioni per volumi di grandi dimensioni.

Endpoint di archiviazione

Per servire un volume, Azure NetApp Files crea un endpoint di storage (la risorsa di rete, con il proprio indirizzo IP, che i client montano) nella subnet delegata. Un endpoint di storage viene sempre creato quando il primo volume viene distribuito in una subnet delegata. Per le successive implementazioni di volumi, il servizio potrebbe creare autonomamente più endpoint di storage quando disponibilità di risorse, esigenze di prestazioni o requisiti di posizionamento lo richiedono. La creazione e il posizionamento degli endpoint di storage sono operazioni di servizio interne e non sono esposte come opzioni configurabili dall'utente.

Annotazioni

La creazione di un endpoint di archiviazione aumenta il tempo totale di provisioning. Quando è necessario creare un nuovo endpoint di storage durante la creazione del volume, il volume può rimanere nello stato di Creazione per diversi minuti prima di passare a Riuscito. Questo comportamento è previsto. I volumi che riutilizzano un endpoint di storage esistente tipicamente effettuano provisioning più velocemente perché non è necessario un nuovo endpoint.

Lo stesso comportamento vale per le implementazioni di gruppi di volumi applicativi, che creano più endpoint di archiviazione per posizionare dati e volumi di log in modo ottimale. Per questo motivo, creare un gruppo di volumi applicativo può richiedere 9-12 minuti. Per ulteriori informazioni, consulta Comprendi i gruppi di volumi applicativi di Azure NetApp Files.

Se la tua distribuzione dipende da tempi di provisioning prevedibili, pianifica la creazione degli endpoint di archiviazione prima che inizi la distribuzione del carico di lavoro. Questa considerazione è particolarmente importante per le implementazioni automatizzate Servizio Azure Kubernetes (AKS) o Azure Red Hat OpenShift che prevedono dinamicamente volumi Azure NetApp Files. Durante l'inizializzazione dell'ambiente, creare un piccolo volume nella subnet delegata di destinazione. Il volume iniziale può innescare la creazione degli endpoint di storage in anticipo, quindi volumi successivi potrebbero fare provisioning più rapidamente quando il servizio può riutilizzare l'endpoint esistente.

Questo approccio può ridurre i ritardi nel provisioning, ma non garantisce tempi di provisioning coerenti per ogni volume successivo. Se Azure NetApp Files determina che è necessario un endpoint di storage aggiuntivo a causa della disponibilità di risorse, delle esigenze di prestazioni o di posizionamento, il servizio potrebbe creare un altro endpoint durante una futura distribuzione di volumi. In tal caso, il volume può nuovamente rimanere nello stato Creazione per diversi minuti prima di passare a Completato. Pianifica i flussi di lavoro di automazione per consentire questo comportamento atteso.

Passaggi successivi

  • Last updated on