Domande frequenti sul gruppo di volumi di applicazioni di Azure NetApp Files

  • Articolo

Questo articolo risponde alle domande frequenti sul gruppo di volumi di applicazioni Azure NetApp Files.

Domande frequenti generico

Questa sezione risponde alle domande generiche sui gruppi di volumi di applicazioni di Azure NetApp Files.

Perché è consigliabile usare un pool di capacità QoS manuale per tutti i volumi di database?

Il pool di capacità QoS manuale offre il miglior equilibrio tra capacità e velocità effettiva in base alle esigenze del database. Evita il provisioning eccessivo per raggiungere le prestazioni di , ad esempio il volume di log o il volume di dati. Può anche riservare spazio maggiore per i backup dei log mantenendo le prestazioni su un valore adatto alle proprie esigenze. In generale, l'uso del pool di capacità QoS manuale comporta un vantaggio sui costi.

Nota

Durante la creazione del gruppo di volumi dell'applicazione solo i pool di capacità QoS manuali verranno visualizzati nell'elenco da cui selezionare.

È possibile clonare un volume creato con il gruppo di volumi dell'applicazione?

Sì, è possibile clonare un volume creato dal gruppo di volumi dell'applicazione. A tale scopo, selezionare uno snapshot e ripristinarlo in un nuovo volume. La clonazione è un processo esterno al flusso di lavoro del gruppo di volumi dell'applicazione. Di conseguenza, prendere in considerazione le restrizioni seguenti:

  • Quando si clona un singolo volume, nessuna delle dipendenze specifiche del gruppo di volumi viene controllata.
  • Il volume clonato non fa parte del gruppo di volumi.
  • Il volume clonato viene sempre posizionato nello stesso endpoint di archiviazione del volume di origine.
  • Per ottenere la latenza più bassa per il volume clonato, è necessario montare con lo stesso indirizzo IP del volume di origine.

Quanto tempo è necessario per creare un gruppo di volumi?

La creazione di un gruppo di volumi prevede molti passaggi diversi e non tutte possono essere eseguite in parallelo. In particolare quando si crea il primo gruppo di volumi per una determinata posizione, potrebbero essere necessari 9-12 minuti per il completamento. La creazione dei gruppi di volumi successivi richiede meno tempo.

La distribuzione non è riuscita e non è stato creato nemmeno un singolo volume. Perché?

Si tratta di un comportamento normale. Il gruppo di volumi dell'applicazione eseguirà il provisioning dei volumi in modo atomico ed eseguirà il rollback della distribuzione nel caso in cui uno dei componenti non venga distribuito. La distribuzione ha in genere esito negativo perché la posizione specificata non dispone di risorse sufficienti per soddisfare i requisiti. Controllare il log di distribuzione per informazioni dettagliate e correggere la configurazione del pool di capacità, se necessario.

Perché non è possibile modificare la descrizione del gruppo di volumi?

Nell'implementazione corrente, il gruppo di volumi dell'applicazione è incentrato solo sulla creazione iniziale e l'eliminazione di un gruppo di volumi.

Quali criteri di snapshot è consigliabile usare per i volumi di database?

È possibile usare prodotti come AzAcSnap o Commvault per un backup coerente con l'applicazione per l'ambiente di database. Non è possibile usare gli snapshot standard pianificati dai criteri di snapshot predefiniti di Azure NetApp Files per una protezione dei dati coerente.

Le raccomandazioni generali per gli snapshot in un ambiente di database sono le seguenti:

  • Monitorare attentamente gli snapshot del volume di dati. Mantenere gli snapshot per un lungo periodo potrebbe aumentare le esigenze di capacità. Assicurarsi di monitorare la capacità usata rispetto alla capacità allocata.
  • Se si creano automaticamente snapshot per la protezione dei dati primari, assicurarsi di monitorare la conservazione per evitare un consumo imprevisto della capacità del volume.

Domande frequenti sul gruppo di volumi di applicazioni per SAP HANA

Questa sezione risponde alle domande sul gruppo di volumi di applicazioni di Azure NetApp Files per SAP HANA.

Le istruzioni di montaggio di un volume includono un elenco di indirizzi IP. Quale indirizzo IP è necessario usare?

Il gruppo di volumi di applicazioni garantisce che i volumi di dati e di log per un host abbiano sempre endpoint di archiviazione separati con indirizzi IP diversi per ottenere prestazioni ottimali. Per ospitare i dati, registrare e condividere volumi tra le risorse di archiviazione di Azure NetApp Files, è possibile creare fino a sei endpoint di archiviazione per ogni risorsa di archiviazione di Azure NetApp Files usata. Per questo motivo, è consigliabile ridimensionare di conseguenza la subnet delegata. Vedere Requisiti e considerazioni per il gruppo di volumi di applicazioni per SAP HANA. Anche se tutti gli indirizzi IP elencati possono essere usati per il montaggio, il primo indirizzo IP elencato è quello che fornisce la latenza più bassa. È consigliabile usare sempre il primo indirizzo IP.

È possibile usare nconnect come opzione di montaggio?

Azure NetApp Files supporta nconnect NFSv4.1, ma richiede le versioni del sistema operativo Linux seguenti:

  • SLES 15SP2 e versioni successive
  • RHEL 8.3 e versioni successive

Quando si usa l'opzione nconnect di montaggio, il limite di lettura è fino a 4500 MiB/s (vedere Le procedure consigliate per le opzioni di montaggio NFS linux per Azure NetApp Files) e i limiti di velocità effettiva proposti per il volume di dati potrebbero dover essere adattati di conseguenza.

Perché l'elemento hostid (ad esempio, 00001) viene aggiunto ai miei nomi anche quando il segnaposto è stato rimosso {Hostid} ?

Il gruppo di volumi dell'applicazione richiede che il segnaposto {Hostid} faccia parte dei nomi. Se rimosso, viene hostid aggiunto automaticamente alla stringa specificata.

È possibile visualizzare i nomi finali per ognuno dei volumi dopo aver selezionato Rivedi e crea.

Perché 1500 MiB/s è il valore massimo di velocità effettiva proposto dal gruppo di volumi dell'applicazione per SAP HANA per il volume di dati?

NFSv4.1 è il protocollo supportato per SAP HANA e Oracle. Di conseguenza, una sessione TCP/IP è supportata quando si monta un singolo volume. Per l'esecuzione di una singola sessione TCP(ovvero da un singolo host) rispetto a un singolo volume, 1500 MiB/s è il limite di I/O tipico identificato. Ecco perché il gruppo di volumi di applicazioni per SAP HANA evita di allocare una velocità effettiva maggiore di quanto sia possibile ottenere in modo realistico. Se è necessaria una maggiore velocità effettiva, in particolare per i database HANA di dimensioni maggiori (ad esempio, 12 TiB), è consigliabile usare più partizioni o usare l'opzione nconnect di montaggio.

Ricerca per categorie dimensioni dei volumi di Azure NetApp Files da usare con SAP HANA per ottenere prestazioni ottimali ed efficienza dei costi?

Per un dimensionamento ottimale, è importante ridimensionare il panorama completo, inclusi gli snapshot e il backup. Decidere il layout del volume per la produzione, la disponibilità elevata e la protezione dei dati ed eseguire il ridimensionamento usando il calcolatore di ridimensionamento di Azure NetApp Files per le distribuzioni SAP HANA.

È stato ricevuto un messaggio di "Not enough pool capacity"avviso. Cosa posso fare?

Il gruppo di volumi dell'applicazione calcola la capacità e la domanda di velocità effettiva di tutti i volumi in base all'input della memoria HANA. Quando si seleziona il pool di capacità, verifica immediatamente se nel pool di capacità sono disponibili capacità e velocità effettiva sufficienti.

Nella schermata iniziale di SAP HANA è possibile ignorare questo messaggio e continuare con il flusso di lavoro facendo clic sul pulsante Avanti . In seguito è possibile adattare i valori proposti per ogni volume singolarmente in modo che tutti i volumi si adattino al pool di capacità. Questo messaggio di errore viene visualizzato nuovamente quando si modifica ogni singolo volume fino a quando tutti i volumi non rientrano nel pool di capacità.

È possibile aumentare le dimensioni del pool per evitare questo messaggio di avviso.

Come è possibile capire come ridimensionare il sistema o il panorama complessivo del sistema?

Per pianificare il dimensionamento complessivo del sistema SAP, contattare un esperto di dimensionamento di SAP NetApp Files.

Le informazioni importanti da fornire per ognuno dei sistemi includono gli elementi seguenti: SID, ruolo (produzione, sviluppo, pre-produzione/QA), memoria HANA, riserva snapshot in percentuale, numero di giorni per la conservazione degli snapshot locali, numero di backup basati su file, host singolo/multiple-host con il numero di host e HSR (primario, secondario).

È possibile usare lo strumento di stima delle dimensioni di SAP HANA per ottimizzare il processo di dimensionamento.

Se si conoscono i sistemi (dall'esecuzione di HANA prima), è possibile fornire manualmente i dati anziché questi presupposti generici.

È possibile usare la nuova funzionalità SAP HANA di più partizioni?

Il gruppo di volumi di applicazioni per SAP HANA non è stato creato con un focus dedicato su più partizioni, ma è possibile usare il gruppo di volumi di applicazioni per SAP HANA durante l'adattamento dell'input.

Le nozioni di base per più partizioni sono le seguenti:

  • Più partizioni indicano che un singolo host SAP HANA usa più volumi per archiviarne la persistenza.
  • È necessario montare più partizioni in percorsi diversi. Ad esempio, il primo volume è su /hana/<SID>/data1/mnt00001e il secondo volume richiede un percorso diverso (/hana/<SID>/data2/mnt00002). Per ottenere questo risultato, è necessario adattare manualmente la convenzione di denominazione. ovvero <SID>-DATA1-MNT00001; <SID>-DATA2-MNT00002, ....
  • La memoria è la chiave per il gruppo di volumi dell'applicazione per SAP HANA per la capacità e la velocità effettiva. Di conseguenza, è necessario adattare le dimensioni in base al numero di partizioni. Per due partizioni, è consigliabile usare il 50% della memoria. Per tre partizioni, è consigliabile usare il 33% della memoria e così via.

Per ogni host e ogni partizione che si vuole creare, è necessario rieseguire il gruppo di volumi di applicazioni per SAP HANA ed è necessario adattare la proposta di denominazione per soddisfare le raccomandazioni precedenti.

Per altre informazioni su questo argomento, vedere Uso di Avg di Azure NetApp Files per SAP HANA per distribuire HANA con più partizioni.

Quali sono le regole alla base della velocità effettiva proposta per i volumi di dati e log HANA?

SAP definisce gli indicatori di prestazioni chiave (KPI) per i volumi HANA come 400 MiB/s per i dati e 250 MiB/s per il volume di log. Questa definizione è indipendente dalle dimensioni o dal carico di lavoro del database HANA. Il gruppo di volumi dell'applicazione ridimensiona i valori di velocità effettiva in modo che anche il database più piccolo soddisfi gli indicatori KPI sap HANA e i vantaggi del database di dimensioni maggiori derivanti da un livello di velocità effettiva superiore, ridimensionando la proposta in base alle dimensioni del database HANA immesse.

La tabella seguente descrive l'intervallo di memoria e la velocità effettiva proposta per il volume di dati HANA:

Intervallo di memoria (TB)Velocità effettiva proposta (MB/s)
MinimoMassimo
01400
12600
24800
461000
681200
8101400
10Illimitati1500

La tabella seguente descrive l'intervallo di memoria e la velocità effettiva proposta per il volume di log HANA:

Intervallo di memoria (TB)Velocità effettiva proposta (MB/s)
MinimoMassimo
04250
4Illimitati500

La velocità effettiva del volume del database influisce principalmente sul tempo necessario per leggere i dati in memoria all'avvio del database. In fase di esecuzione, tuttavia, la maggior parte delle operazioni di I/O è di I/O di scrittura, in cui anche gli indicatori KPI mostrano valori inferiori. L'esperienza utente mostra che, per i database più piccoli, i valori KPI HANA possono essere superiori a quelli necessari per la maggior parte del tempo.

Le prestazioni di Azure NetApp Files di ogni volume possono essere modificate in fase di esecuzione. Di conseguenza, in qualsiasi momento, è possibile modificare le prestazioni del database modificando la velocità effettiva dei dati e del volume di log in base ai requisiti specifici. Ad esempio, è possibile ottimizzare le prestazioni e ridurre i costi consentendo una maggiore velocità effettiva all'avvio riducendo al contempo gli indicatori KPI durante il normale funzionamento.

Verrà effettuato il provisioning di tutti i volumi in prossimità dei server SAP HANA?

L'uso del gruppo di posizionamento di prossimità creato per i server SAP HANA garantisce che i dati, i log e i volumi condivisi vengano creati vicino ai server SAP HANA per ottenere la latenza e la velocità effettiva migliori. Tuttavia, i volumi di backup dei log e di backup dei dati non richiedono bassa latenza. Dal punto di vista della protezione, è opportuno archiviare questi volumi di backup in una posizione diversa dai dati, dai log e dai volumi condivisi. Di conseguenza, il gruppo di volumi dell'applicazione inserisce i volumi di backup in un percorso di archiviazione diverso all'interno dell'area con capacità e velocità effettiva sufficienti.

Qual è la relazione tra volumi AVset, VM, PPG e Azure NetApp Files?

Un gruppo di posizionamento di prossimità (PPG) deve avere almeno una macchina virtuale assegnata, direttamente o tramite un oggetto AVset. Lo scopo del PPG è estrarre la posizione esatta di una macchina virtuale e passare queste informazioni al gruppo di volumi dell'applicazione per cercare le risorse di Azure NetApp Files nello stesso data center. Questa impostazione funziona solo quando viene avviata almeno una macchina virtuale nel ppg. In genere, è possibile aggiungere i server di database al PPG.

I ppg hanno l'effetto collaterale che, se tutte le macchine virtuali vengono arrestate, un riavvio delle macchine virtuali seguente NON garantisce che inizieranno nello stesso data center di prima. Per evitare che si verifichi questa situazione, è consigliabile usare un AVset in cui tutte le macchine virtuali e il PPG sono associati a e usare il flusso di lavoro di aggiunta HANA. Il flusso di lavoro non solo garantisce che le macchine virtuali non vengano spostate quando vengono riavviate, garantisce anche che le posizioni siano selezionate dove sono disponibili risorse di calcolo sufficienti e di Azure NetApp Files.

Per un sistema SAP HANA multihost, il volume condiviso verrà ridimensionato quando si aggiungono altri host HANA?

No. Questo scenario è attualmente uno dei pochi casi in cui è necessario regolare manualmente le dimensioni. SAP consiglia di ridimensionare il volume condiviso come 1 x RAM per ogni quattro host HANA. Poiché il volume condiviso viene creato come parte del primo host SAP HANA, è già ridimensionato come 1 TB. Sono disponibili due opzioni per ridimensionare correttamente il volume di condivisione per SAP HANA.

  • Se si sa in anticipo che sono necessari, ad esempio sei host, è possibile modificare la proposta di 1 TB durante la creazione iniziale con il gruppo di volumi dell'applicazione per SAP HANA. A questo punto, è anche possibile aumentare la velocità effettiva, ovvero QoS, per ospitare sei host.
  • È sempre possibile modificare il volume condiviso e modificare le dimensioni e la velocità effettiva singolarmente dopo la creazione del volume. È possibile farlo all'interno del gruppo di posizionamento del volume o direttamente nel volume usando il provider di risorse di Azure o l'interfaccia utente grafica.

Si vuole creare il volume di backup dei dati non solo per una singola istanza, ma per più di un database SAP HANA. Come posso fare?

I volumi di backup dei log e dei dati sono facoltativi e non richiedono prossimità. Il modo migliore per ottenere il risultato previsto consiste nel rimuovere il volume di backup dei dati o di backup del log quando si crea il primo volume dal gruppo di volumi dell'applicazione per SAP HANA. È quindi possibile creare un volume personalizzato come singolo volume indipendente usando il provisioning di volumi standard e selezionando la capacità e la velocità effettiva appropriate per soddisfare le proprie esigenze. È consigliabile usare una convenzione di denominazione che indica un volume di backup dei dati e che viene usata per più SID.

Domande frequenti sul gruppo di volumi di applicazioni per Oracle

Questa sezione risponde alle domande sul gruppo di volumi di applicazioni azure NetApp Files per Oracle.

Verrà effettuato il provisioning di tutti i volumi nella stessa zona di disponibilità del server di database per Oracle?

Il flusso di lavoro di distribuzione garantisce che tutti i volumi vengano inseriti nella zona di disponibilità selezionata al momento della creazione, che deve corrispondere alla zona di disponibilità delle macchine virtuali Oracle. Per le aree che non supportano le zone di disponibilità, i volumi vengono posizionati con un ambito a livello di area.

Ricerca per categorie dimensioni dei volumi di Azure NetApp Files per l'uso con Oracle per ottenere prestazioni ottimali ed efficienza dei costi?

Per un dimensionamento ottimale, è importante ridimensionare il panorama completo del database, tra cui disponibilità elevata, snapshot e backup. Decidere il layout del volume per la produzione, la disponibilità elevata e la protezione dei dati ed eseguire il dimensionamento in base all'esecuzione dei carichi di lavoro Oracle più impegnativi in Azure senza sacrificare prestazioni o scalabilità e strumento di stima per ridimensionare i carichi di lavoro Oracle in macchine virtuali IaaS di Azure. È anche possibile usare SAP in Azure NetApp Files Sizing Estimator usando l'opzione Aggiungi input volume singolo.

Informazioni importanti da fornire per il ridimensionamento di ognuno dei volumi includono: SID, ruolo (produzione, sviluppo, pre-prod/QA), riserva di snapshot in percentuale, numero di giorni per la conservazione degli snapshot locali, numero di backup basati su file, host singolo/host multiplo con il numero di host e requisiti di Data Guard (primario, secondario). Per pianificare il dimensionamento complessivo del sistema Oracle, contattare un esperto di dimensionamento di Oracle in Azure NetApp Files.

Le istruzioni di montaggio di un volume includono un elenco di indirizzi IP. Quale indirizzo IP è necessario usare per Oracle?

Il gruppo di volumi di applicazioni garantisce che i dati, il log di rollforward, i volumi di log di archiviazione e di backup abbiano endpoint di archiviazione separati con indirizzi IP diversi per ottenere prestazioni ottimali. Anche se tutti gli indirizzi IP elencati possono essere usati per il montaggio, il primo indirizzo IP elencato è quello che fornisce la latenza più bassa. È consigliabile usare sempre il primo indirizzo IP.

Quale versione di NFS è consigliabile usare per i volumi Oracle?

Usare Oracle dNFS nel client per montare i volumi. Durante il montaggio con dNFS funziona con volumi creati con NFSv3 e NFSv4.1, è consigliabile distribuire i volumi usando NFSv3. Per altre informazioni e dipendenze di rilascio, vedere le note sul sistema operativo client e su Oracle. Per altre informazioni, vedere Vantaggi dell'uso di Azure NetApp Files con oracle Database e prestazioni del database Oracle in più volumi di Azure NetApp Files.

Per ottenere prestazioni ottimali per i database di grandi dimensioni, è consigliabile usare dNFS nel server di database per montare il volume. Per semplificare la configurazione dNFS, è consigliabile creare i volumi con NFSv3.

Quali criteri di snapshot è consigliabile usare per i volumi Oracle?

Questa domanda non è direttamente correlata al gruppo di volumi dell'applicazione per Oracle. È possibile usare prodotti come AzAcSnap o Commvault per un backup coerente con l'applicazione per i database Oracle. Non è possibile usare gli snapshot standard pianificati dai criteri di snapshot predefiniti di Azure NetApp Files per garantire una protezione coerente dei dati del database Oracle.

Le raccomandazioni generali per gli snapshot in un ambiente Oracle sono le seguenti:

  • Usare gli strumenti snapshot compatibili con il database per garantire la creazione di snapshot coerenti con il database.
  • Monitorare attentamente gli snapshot del volume di dati. Mantenere gli snapshot per un lungo periodo potrebbe aumentare le esigenze di capacità. Assicurarsi di monitorare la capacità usata rispetto alla capacità allocata.
  • Se si creano automaticamente snapshot per il volume di backup, assicurarsi di monitorare la conservazione per evitare una crescita imprevista del volume.

È possibile usare Oracle ASM con AVG per i volumi creati da Oracle?

L'uso di Oracle ASM in combinazione con il gruppo di volumi dell'applicazione Azure NetApp Files per Oracle è supportato, ma senza supporto per la coerenza degli snapshot tra i volumi in un gruppo di volumi di applicazioni. I clienti sono invitati a usare altre opzioni di protezione dei dati compatibili quando si usa ASM fino a un ulteriore preavviso.

Perché è possibile usare facoltativamente un gruppo di posizionamento di prossimità (PPG) per la distribuzione Oracle?

Quando si distribuisce in aree con disponibilità limitata delle risorse, potrebbe non essere possibile distribuire i volumi nelle posizioni più ottimali. In questi casi, è possibile scegliere di distribuire volumi usando la funzione gruppo di posizionamento prossimità per ottenere una distribuzione con il posizionamento del volume ottimale nelle condizioni specificate. Come impostazione predefinita, l'uso di PPG è disabilitato. È necessario richiedere l'abilitazione dell'uso dei gruppi di posizionamento di prossimità tramite il canale di supporto.

Passaggi successivi