Condividi tramite

Domande frequenti sulla resilienza delle applicazioni per Azure NetApp Files

  • Articolo

Questo articolo risponde alle domande frequenti (FAQ) 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, upgrade del servizio o del software). Dal punto di vista di un protocollo file (NFS/SMB), le operazioni di manutenzione non sono di tipo disruptive, 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, e variando da pochi secondi a 30 secondi. Il protocollo NFS è particolarmente affidabile e le operazioni sui file client-server continuano normalmente. Alcune applicazioni potrebbero richiedere l'ottimizzazione per gestire le pause di I/O anche di 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 standard del protocollo sono in genere sufficienti.

Importante

Per garantire un'architettura resiliente, è fondamentale riconoscere che il cloud opera secondo 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 efficiente delle potenziali interruzioni delle applicazioni che potrebbero verificarsi durante gli eventi di manutenzione del servizio di archiviazione.

È necessario adottare precauzioni particolari 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 di condivisioni della disponibilità continua SMB. L'uso della disponibilità continua SMB è supportato solo per i carichi di lavoro in:

Attenzione

Le applicazioni personalizzate non sono supportate da Disponibilità continua SMB e non possono essere usate con volumi abilitati per 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:

Nota

Il numero di messaggi che ogni coppia di istanza multipla MQ deve elaborare dipende fortemente dall'ambiente specifico. È necessario decidere quante coppie di istanze multiple MQ saranno necessarie o quali saranno le regole di scalabilità verticale o orizzontale.

L'architettura con scale-out è 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 relativo a IBM MQ nei volumi NFS condivisi, è necessario ottenere il supporto del fornitore presso IBM.

Sto eseguendo Apache ActiveMQ con LevelDB o KahaDB su 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 Disponibilità elevata di ActiveMQ con blocchi di archiviazione collegabili.

I modelli a disponibilità elevata di ActiveMQ assicurano che un'istanza di Broker sia sempre online e in grado di elaborare il traffico dei messaggi. I due modelli a disponibilità elevata di ActiveMQ più comuni prevedono la condivisione di un file system su una rete. Lo scopo è quello di 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 "blocco". Sono presenti dei problemi con questo modello a disponibilità elevata di ActiveMQ. Possono portare a una situazione "no-master", in cui la replica non è consapevole di poter bloccare il file. Possono anche portare a una configurazione "master-master" che provoca il danneggiamento dell'indice o del journal e, infine, la perdita dei messaggi. La maggior parte di questi problemi deriva da fattori esterni al controllo di ActiveMQ. Ad esempio, un client NFS ottimizzato in modo non adeguato può causare il blocco dei dati durante il caricamento, causando tempi di inattività “no-master” durante il failover.

Poiché la maggior parte dei problemi con questa soluzione a disponibilità elevata derivano dal blocco dei file non accurato a livello di sistema operativo, la comunità ActiveMQ ha introdotto il concetto di un locker di archiviazione collegabile nella versione 5.7 del broker. Questo approccio consente all'utente di sfruttare un diverso mezzo di blocco condiviso, usando un blocco del database JDBC a livello di riga anziché un blocco del file system a livello di sistema operativo. Per il supporto o la consulenza sulle architetture e le distribuzioni a disponibilità elevata di ActiveMQ, è necessario contattare OpenLogic by Perforce.

Sto eseguendo Apache ActiveMQ con LevelDB o KahaDB su 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 è non eseguire l'archiviazione condivisa KahaDB in CIFS [Common Internet File System]/SMB. In caso di problemi nel mantenimento dello stato di blocco accurato, verificare il Locker di archiviazione collegabile JDBC, che può fornire un meccanismo di blocco più affidabile. Per il supporto o la consulenza sulle architetture e le distribuzioni a disponibilità elevata di ActiveMQ, è necessario contattare OpenLogic by Perforce.

Si esegue Boomi su 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 Boomi per la disponibilità elevata e 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 di Boomi Molecule stabiliscono che è possibile usare NFS con 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