Domande frequenti sulla resilienza delle applicazioni per Azure NetApp Files

  • Articolo

Questo articolo risponde alle domande frequenti sulla resilienza dell'applicazione Azure NetApp Files.

Cosa è consigliabile per gestire potenziali interruzioni dell'applicazione dovute a eventi di manutenzione del servizio di archiviazione?

Azure NetApp Files potrebbe essere sottoposto a manutenzione pianificata occasionale( ad esempio, aggiornamenti della piattaforma, servizio o aggiornamenti software). Dal punto di vista di un protocollo file (NFS/SMB), le operazioni di manutenzione non sono indisruptive, purché l'applicazione possa gestire le pause di I/O che potrebbero verificarsi brevemente durante questi eventi. Le pause di I/O sono in genere brevi, comprese tra alcuni secondi e 30 secondi. Il protocollo NFS è particolarmente affidabile e le operazioni sui file del server client continuano normalmente. Alcune applicazioni potrebbero richiedere l'ottimizzazione per gestire le pause di I/O fino a 30-45 secondi. Di conseguenza, assicurarsi di conoscere le impostazioni di resilienza dell'applicazione per gestire gli eventi di manutenzione del servizio di archiviazione. Per le applicazioni interattive umane che sfruttano il protocollo SMB, le impostazioni del protocollo standard sono in genere sufficienti.

Importante

Per garantire un'architettura resiliente, è fondamentale riconoscere che il cloud opera con un modello di responsabilità condivisa. Questo modello include la piattaforma cloud di Azure, i servizi di infrastruttura, il livello del sistema operativo e i fornitori di applicazioni. Ognuno di questi componenti svolge un ruolo fondamentale nella gestione normale di potenziali interruzioni delle applicazioni che possono verificarsi durante gli eventi di manutenzione del servizio di archiviazione.

È necessario adottare precauzioni speciali per le applicazioni basate su SMB?

Sì, alcune applicazioni basate su SMB richiedono il failover trasparente SMB. Il failover trasparente SMB consente operazioni di manutenzione nel servizio Azure NetApp Files senza interrompere la connettività alle applicazioni server che archiviano e accedono ai dati nei volumi SMB. Per supportare il failover trasparente SMB per applicazioni specifiche, Azure NetApp Files supporta ora l'opzione Condivisioni di disponibilità continua SMB. L'uso della disponibilità continua SMB è supportato solo per i carichi di lavoro in:

Attenzione

Le applicazioni personalizzate non sono supportate con disponibilità continua SMB e non possono essere usate con volumi abilitati per la disponibilità continua SMB.

Si esegue IBM MQ in Azure NetApp Files. Quali precauzioni è possibile adottare per evitare interruzioni dovute a eventi di manutenzione del servizio di archiviazione nonostante l'uso del protocollo NFS?

Se si esegue l'applicazione IBM MQ in una configurazione di file condivisi, in cui i dati e i log IBM MQ vengono archiviati in un volume di Azure NetApp Files, è consigliabile tenere presenti le considerazioni seguenti per migliorare la resilienza durante gli eventi di manutenzione del servizio di archiviazione:

  • È necessario usare solo il protocollo NFS v4.1.
  • Per la disponibilità elevata, è consigliabile usare una configurazione a istanze multiple IBM MQ usando volumi NFS v4.1 condivisi.
  • È necessario verificare la funzionalità della configurazione a istanze multiple IBM usando volumi NFS v4.1 condivisi.
  • È consigliabile implementare un'architettura IBM MQ con scalabilità orizzontale anziché usare una configurazione IBM MQ a più istanze di grandi dimensioni. Distribuendo il carico di elaborazione dei messaggi tra più coppie di istanze IBM MQ, la probabilità di interruzione del servizio potrebbe essere ridotta perché ogni coppia di istanze multiple MQ elabora meno messaggi.

Nota

Il numero di messaggi che ogni coppia di istanze multiistanza MQ deve elaborare dipende in modo elevato dall'ambiente specifico. È necessario decidere il numero di coppie di istanze multiistanza MQ necessarie o le regole di aumento o riduzione delle prestazioni.

L'architettura con scalabilità orizzontale è costituita da più coppie di istanze multiple IBM MQ distribuite dietro un'istanza di Azure Load Balancer. Le applicazioni configurate per comunicare con IBM MQ verranno quindi configurate per comunicare con le istanze IBM MQ tramite Azure Load Balancer. Per il supporto correlato a IBM MQ nei volumi NFS condivisi, è necessario ottenere il supporto del fornitore presso IBM.

Si esegue Apache ActiveMQ con LevelDB o KahaDB in Azure NetApp Files. Quali precauzioni è possibile adottare per evitare interruzioni dovute a eventi di manutenzione del servizio di archiviazione nonostante l'uso del protocollo NFS ?

Se si esegue Apache ActiveMQ, è consigliabile distribuire La disponibilità elevata di ActiveMQ con blocchi pluggable Archiviazione.

I modelli activeMQ a disponibilità elevata assicurano che un'istanza di Broker sia sempre online e in grado di elaborare il traffico dei messaggi. I due modelli di disponibilità elevata ActiveMQ più comuni implicano la condivisione di un file system in una rete. Lo scopo è fornire LevelDB o KahaDB alle istanze del broker attivo e passivo. Questi modelli a disponibilità elevata richiedono che venga ottenuto e mantenuto un blocco a livello di sistema operativo in un file nelle directory LevelDB o KahaDB, denominate "lock". Esistono alcuni problemi con questo modello a disponibilità elevata di ActiveMQ. Possono causare una situazione "no-master", in cui la replica non è in grado di bloccare il file. Possono anche portare a una configurazione "master-master" che comporta il danneggiamento dell'indice o del journal e infine la perdita di messaggi. La maggior parte di questi problemi deriva da fattori esterni al controllo di ActiveMQ. Ad esempio, un client NFS ottimizzato in modo non ottimale può causare un blocco dei dati non aggiornato durante il caricamento, causando tempi di inattività "senza master" durante il failover.

Poiché la maggior parte dei problemi con questa soluzione a disponibilità elevata deriva dal blocco di file a livello di sistema operativo non accurato, la community di ActiveMQ ha introdotto il concetto di unlocker di archiviazione collegabile nella versione 5.7 del broker. Questo approccio consente a un utente di sfruttare diversi mezzi del blocco condiviso, usando un blocco di database JDBC a livello di riga anziché un blocco del file system a livello di sistema operativo. Per assistenza o consulenza su architetture e distribuzioni a disponibilità elevata ActiveMQ, contattare OpenLogic by Perforce.

Si esegue Apache ActiveMQ con LevelDB o KahaDB in Azure NetApp Files. Quali precauzioni è possibile adottare per evitare interruzioni dovute a eventi di manutenzione del servizio di archiviazione nonostante l'uso del protocollo SMB ?

La raccomandazione generale del settore è di non eseguire l'archiviazione condivisa KahaDB in CIFS/SMB. In caso di problemi durante il mantenimento dello stato di blocco accurato, vedere Pluggable JDBC Archiviazione Locker, che può fornire un meccanismo di blocco più affidabile. Per assistenza o consulenza su architetture e distribuzioni a disponibilità elevata ActiveMQ, contattare OpenLogic by Perforce.

Sto eseguendo Boomi in Azure NetApp Files. Quali precauzioni è possibile adottare per evitare interruzioni dovute a eventi di manutenzione del servizio di archiviazione?

Se si esegue Boomi, è consigliabile seguire le procedure consigliate di Boomi per la disponibilità elevata e il ripristino di emergenza in fase di esecuzione.

Boomi consiglia di usare Boomi Molecule per implementare la disponibilità elevata per Boomi Atom. I requisiti di sistema Boomi Molecule dichiarano che è possibile usare NFS con il blocco NFS abilitato (supporto NLM) o condivisioni file SMB. Nel contesto di Azure NetApp Files, i volumi NFSv4.1 hanno il supporto NLM.

Boomi consiglia di usare la condivisione file SMB con le macchine virtuali Windows; per NFS, Boomi consiglia le macchine virtuali Linux.

Nota

Le condivisioni di disponibilità continua di Azure NetApp Files non sono supportate con Boomi.

Passaggi successivi