Condividi tramite

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

  • Articolo

Trovare risposte alle domande frequenti sul gruppo di volumi di applicazioni di Azure NetApp Files.

Domande frequenti generiche

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 per soddisfare le esigenze del database. Evita di dover eseguire un provisioning eccessivo per raggiungere le prestazioni, ad esempio, del volume di log o del volume di dati. Può anche riservare spazio maggiore per i backup di log, mantenendo le prestazioni su un valore adatto alle proprie esigenze. In generale, l'uso del pool di capacità QoS manuale comporta un vantaggio in termini di costi.

Nota

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

È 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, tenere 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.
  • Perché il volume clonato abbia la latenza più bassa possibile, è 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 tutti possono essere eseguiti 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 richiederà un tempo minore.

La distribuzione non è riuscita e non è stato creato nemmeno un solo 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 sia distribuito correttamente. Generalmente, la distribuzione ha esito negativo perché la posizione specificata non dispone di risorse sufficienti per soddisfare i requisiti. Controllare il log di distribuzione per informazioni dettagliate e, se necessario, correggere la configurazione del pool di capacità.

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 eseguire 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 relative agli snapshot in un ambiente di database sono le seguenti:

  • Monitorare attentamente gli snapshot del volume di dati. Mantenere gli snapshot per un lungo periodo di tempo potrebbe aumentare le esigenze di capacità. Assicurarsi di monitorare la capacità usata rispetto a quella allocata.
  • Se si creano automaticamente snapshot per la protezione dei dati primari, assicurarsi di monitorare la loro 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 usare?

Il gruppo di volumi dell’applicazione garantisce che i volumi di dati e di log per un host abbiano sempre endpoint di archiviazione diversi con indirizzi IP diversi per ottenere prestazioni ottimali. Per ospitare dati, log e volumi condivisi 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 la subnet delegata di conseguenza. Vedere Requisiti e considerazioni per il gruppo di volumi di applicazioni per SAP HANA. Sebbene tutti gli indirizzi IP elencati possano 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 per NFSv4.1, ma richiede le versioni di sistema operativo Linux seguenti:

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

Quando si usa l'opzione di montaggio nconnect, 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 nomi anche quando il segnaposto {Hostid} è stato rimosso?

Il gruppo di volumi dell'applicazione richiede che il segnaposto {Hostid} faccia parte dei nomi. Se rimosso, hostid viene nuovamente 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) contro 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 realisticamente possibile ottenere. Se si necessita di 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 di montaggio nconnect.

Come si ridimensionano i volumi di Azure NetApp Files da usare con SAP HANA per ottenere prestazioni ottimali ed efficienza in termini di costi?

Per ottenere dimensioni ottimali, è importante ridimensionare il panorama completo, inclusi gli snapshot e i 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 distribuzioni SAP HANA.

È stato ricevuto un messaggio di avviso "Not enough pool capacity". 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à, esso 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 rientrino nel pool di capacità. Questo messaggio di errore viene visualizzato nuovamente alla modifica di ciascun 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 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 di Azure NetApp Files.

Le informazioni fondamentali 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 di conservazione degli snapshot locali, numero di backup basati su file, host singolo/host multipli 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 ha già familiarità con i sistemi (avendo eseguito HANA in precedenza), è possibile fornire manualmente i propri 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 a 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 archiviare la propria persistenza.
  • È necessario montare più partizioni in percorsi diversi. Ad esempio, il primo volume è su /hana/<SID>/data1/mnt00001 e 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 alla capacità e alla 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 e 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 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 che i database di dimensioni maggiori beneficino 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 database più piccoli, i valori KPI HANA potrebbero risultare superiori a quanto necessario per la maggior parte del tempo.

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

Tutti i volumi di cui viene effettuato il provisioning si trovano in prossimità dei server SAP HANA?

Con un gruppo di volumi di applicazioni, è possibile distribuire volumi con un posizionamento del volume a zona di disponibilità o a gruppo di posizionamento di prossimità. Entrambi i metodi assicurano che i volumi di dati vengano posizionati in prossimità delle macchine virtuali HANA, ma usando principi diversi.

L'uso del posizionamento del volume a zona di disponibilità (disponibile con estensione 1) inserisce i volumi nella stessa zona di disponibilità delle macchine virtuali dell'applicazione. L'uso delle zone di disponibilità supporta anche le funzionalità di rete Standard, che favoriscono la sicurezza avanzata tramite il supporto dei gruppi di sicurezza di rete. Questo metodo non richiede l'associazione manuale. È quindi più facile e veloce da usare.

L'uso del gruppo di posizionamento di prossimità richiede la creazione di un gruppo di posizionamento di prossimità per i server SAP HANA. Questo posizionamento garantisce che i dati, i log e i volumi condivisi vengano creati in prossimità dei server SAP HANA per ottenere latenza e velocità effettiva migliori. Questo metodo richiede l'aggiunta manuale del gruppo di posizionamento di prossimità, usato dal gruppo di volumi dell'applicazione per trovare la posizione ottimale per la distribuzione dei volumi. Questo metodo supporta solo le funzionalità di rete Basic. Notare che 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 disponibilità di 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 tale informazione al gruppo di volumi dell'applicazione per cercare le risorse di Azure NetApp Files nello stesso data center. Questa impostazione funziona solo quando almeno una macchina virtuale viene avviata nel PPG. In genere, è possibile aggiungere i server di database al PPG.

I gruppi di disponibilità comportano l’effetto collaterale che, se tutte le macchine virtuali subiscono un arresto, un loro seguente riavvio NON garantisce che siano avviate 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 e usare il flusso di lavoro di associazione HANA. Il flusso di lavoro non solo garantisce che le macchine virtuali non vengano spostate quando riavviate, ma anche che vengano selezionate posizioni in cui sono disponibili risorse di calcolo e di Azure NetApp Files sufficienti.

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 si necessiterà di, 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, 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.

Come 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 stretta prossimità. Il modo migliore per ottenere il risultato previsto consiste nel rimuovere il volume di backup dei dati o di backup del log alla creazione del 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 indichi un volume di backup dei dati e che sia 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 di 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.

Come si ridimensionano i volumi di Azure NetApp Files da usare con Oracle per ottenere prestazioni ottimali e convenienza in termini di costi?

Per un dimensionamento ottimale, è importante ridimensionare il panorama completo del database, inclusi 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 a Esegui i 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 loStrumento di stima di dimensionamento SAP in Azure NetApp Files usando l'opzione input Aggiungi volume singolo.

Le informazioni fondamentali da fornire per il ridimensionamento di ognuno dei volumi includono: SID, ruolo (produzione, sviluppo, pre-produzione/QA), memoria HANA, riserva snapshot in percentuale, numero di giorni di conservazione degli snapshot locali, numero di backup basati su file, host singolo/host multipli con il numero di host e requisiti di Data Guard (primari, secondari). 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, il log di archiviazione e i volumi di backup abbiano endpoint di archiviazione separati con indirizzi IP diversi per ottenere prestazioni ottimali. Sebbene tutti gli indirizzi IP elencati possano 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 volumi Oracle?

Usare Oracle dNFS nel client per montare i volumi. Sebbene il montaggio con dNFS funzioni 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 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 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 di tempo potrebbe aumentare le esigenze di capacità. Assicurarsi di monitorare la capacità usata rispetto a quella 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 volumi in un gruppo di volumi di applicazioni. Quando si sta usando ASM, i clienti sono invitati a usare altre opzioni di protezione dei dati compatibili 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