Esaminare le funzionalità di disponibilità elevata dell'infrastruttura di Azure

Completato

Per ottimizzare la disponibilità elevata del sistema SAP NetWeaver in Azure, si applicano i principi seguenti:

• Il sistema completo viene distribuito in Azure (obbligatorio; il livello DBMS, l'istanza di (A)SCS e il livello dell'applicazione completa devono essere eseguiti nello stesso percorso).
• Il sistema completo viene eseguito all'interno di una sottoscrizione di Azure (obbligatorio).
• Il sistema completo viene eseguito all'interno di una rete virtuale di Azure (obbligatorio).
• Ogni livello (ad esempio DBMS, ASCS, server applicazioni) deve usare un set di disponibilità dedicato.
• Tutte le macchine virtuali che eseguono istanze DBMS di un sistema SAP si trovano in un set di disponibilità. Le funzionalità native di disponibilità elevata DBMS, ad esempio Always On di SQL Server o Oracle Data Guard, consentono di eseguire più di una macchina virtuale che ospita istanze DBMS per ogni sistema.
• Tutte le macchine virtuali usano dischi gestiti.
• I file di dati e di log DBMS vengono replicati usando le funzioni a disponibilità elevata DBMS per la sincronizzazione dei dati.
• I file delle istanze (A)SCS e la cartella globale SAP sono archiviati in una condivisione file a disponibilità elevata o replicati in modo sincrono tra i dischi di due macchine virtuali di Azure che fanno parte dello stesso set di disponibilità (ad esempio, usando SIOS DataKeeper).

Opzioni di disponibilità elevata di Macchina virtuale di Azure

La disponibilità elevata di Macchine virtuali di Azure deve essere presa in considerazione nei tre scenari principali seguenti:

• Macchine virtuali di Azure singole (contratto di servizio con tempo di attività del 99,9%).
• Due o più macchine virtuali nello stesso set di disponibilità (contratto di servizio con tempo di attività del 99,95%).
• Due o più macchine virtuali in zone di disponibilità diverse nella stessa area di Azure (contratto di servizio con tempo di attività del 99,99%).

Per tutte le macchine virtuali con due o più istanze distribuite nello stesso set di disponibilità, Azure garantisce la connettività delle macchine virtuali ad almeno un'istanza per il 99,95% del tempo. Quando due o più macchine virtuali fanno parte dello stesso set di disponibilità, a ogni macchina virtuale presente nel set viene assegnato un dominio di aggiornamento e un dominio di errore dalla piattaforma Azure sottostante.

• I domini di aggiornamento garantiscono che più macchine virtuali non vengano riavviate contemporaneamente durante la manutenzione pianificata di un'infrastruttura di Azure. Viene riavviata solo una macchina virtuale alla volta.
• I domini di errore garantiscono che le macchine virtuali vengano distribuite in componenti hardware che non condividono un’origine di alimentazione e un commutatore di rete comuni. Quando i server, un commutatore di rete o una fonte di alimentazione subiscono tempi di fermo per la manutenzione non pianificati, ciò influisce solo su una macchina virtuale.

I set di disponibilità possono essere usati negli scenari seguenti nei sistemi SAP:

• Architettura di disponibilità elevata per i server applicazioni SAP.
• Architettura di disponibilità elevata per un'istanza di SAP ASCS/SCS in Windows e Linux.
• Istanza DBMS di disponibilità elevata.

Aspetti da considerare durante la configurazione di un set di disponibilità:

• A ogni macchina virtuale in un set di disponibilità vengono assegnati un dominio di aggiornamento e un dominio di errore dalla piattaforma Azure sottostante.
• Ogni set di disponibilità può avere due o tre domini di errore. Sapere quando usare ognuno (corrisponde alla topologia delle applicazioni). e 20 domini di aggiornamento.
• Quando più di cinque macchine virtuali vengono configurate all'interno di un singolo set di disponibilità, la sesta macchina virtuale viene inserita nello stesso dominio di aggiornamento della prima macchina virtuale. La settima macchina virtuale viene inserita nello stesso dominio di aggiornamento della seconda macchina virtuale e così via.
• Le macchine virtuali vengono inoltre allineate ai domini di errore del disco. Tale allineamento garantisce che tutti i dischi gestiti collegati a una macchina virtuale rientrino negli stessi domini di errore.
• Conoscere la differenza a livello del contratto di servizio tra cluster di set di disponibilità, cluster non di set di disponibilità e zone di disponibilità.
• Assicurarsi di comprendere l'interazione con i gruppi di posizionamento della prossimità.

Scenario con macchina virtuale singola

In uno scenario con macchina virtuale singola si crea una macchina virtuale di Azure per la distribuzione SAP. Si usa Archiviazione Premium di Azure per ospitare il disco del sistema operativo e tutti i dischi dati. Il contratto di servizio per il tempo di attività di Azure del 99,9% e i contratti di servizio degli altri componenti di Azure sono sufficienti per soddisfare i contratti di servizio relativi alla disponibilità per i clienti. In questo scenario non è necessario usare un set di disponibilità di Azure. Ci si basa invece su due diverse funzionalità:

• Riavvio automatico della macchina virtuale di Azure, noto anche come correzione del servizio di Azure
• Riavvio automatico di SAP

Il riavvio automatico della macchina virtuale di Azure, o correzione del servizio, costituisce una funzionalità di Azure che opera su due livelli:

• L'host server controlla l'integrità delle macchine virtuali guest.
• Il controller di infrastruttura di Azure monitora l'integrità e la disponibilità dell'host del server.

Una funzionalità di controllo dell'integrità monitora l'integrità di ogni macchina virtuale ospitata in un host del server di Azure. Se una macchina virtuale passa a uno stato non integro, l'agente host di Azure che ne controlla l’integrità può avviarne il riavvio. Il controller di infrastruttura verifica l'integrità dell'host controllando numerosi parametri diversi che potrebbero indicare problemi con l'hardware dell'host. Verifica anche l'accessibilità dell'host tramite la rete. Un'indicazione di problemi a livello di host può portare agli eventi seguenti:

• Se l'host segnala uno stato di integrità insufficiente, viene attivato un riavvio dell'host e delle macchine virtuali in esecuzione nell'host.
• Se, dopo un riavvio riuscito, l'host non presenta uno stato di integrità adeguato, viene avviata una ridistribuzione delle macchine virtuali che si trovavano originariamente nel nodo non integro in un server host integro. In questo caso, l'host originale viene contrassegnato come non integro. Non viene usato per altre distribuzioni fino a quando non viene cancellato o sostituito.
• Se l'host non integro manifesta problemi durante il processo di riavvio, viene attivato il riavvio immediato delle macchine virtuali in un host integro.

Attraverso il monitoraggio di host e macchine virtuali fornito da Azure, le macchine virtuali di Azure che riscontrano problemi di host vengono automaticamente riavviate in un host di Azure integro.

La correzione del servizio di Azure non riavvia le macchine virtuali Linux in cui il sistema operativo guest si trova in uno stato kernel panic. Azure mantiene invece il sistema operativo nello stato di errore grave del kernel per consentire l'associazione di un debugger del kernel per l'analisi. Si presuppone che tali occorrenze siano rare. È possibile sovrascrivere il comportamento predefinito per consentire il riavvio della macchina virtuale. Per modificare il comportamento predefinito, abilitare il parametro "kernel.panic" in /etc/sysctl.conf. Il tempo impostato per questo parametro è espresso in secondi. In genere, è consigliata un'attesa di circa 20-30 secondi prima di attivare il riavvio. Per altre informazioni, vedere https://gitlab.com/procps-ng/procps/blob/master/sysctl.conf.

Grazie a SAP HANA, è possibile configurare il riavvio automatico del servizio HANA dopo il riavvio della macchina virtuale. Sebbene sia potenzialmente possibile configurare un nodo di failover ad accesso saltuario (nella documentazione di SAP HANA, questa configurazione è chiamata failover automatico dell’host), tale configurazione ha senso in una situazione di distribuzione locale in cui l'hardware del server è limitato e si dedica un nodo a server singolo come nodo di failover automatico host per un set di host di produzione. Tuttavia, in Azure, in cui l'infrastruttura sottostante fornisce un server di destinazione integro per il corretto riavvio di una macchina virtuale, non ha senso distribuire il failover automatico dell'host di SAP HANA. A causa della correzione del servizio di Azure, non è disponibile un'architettura di riferimento che preveda un nodo di standby per il failover automatico dell'host HANA.

Avvio automatico di SAP

L'avvio automatico di SAP offre la funzionalità che consente di avviare le istanze di SAP immediatamente dopo l'avvio del sistema operativo nella macchina virtuale. Tuttavia, SAP non consiglia più di usare questa impostazione perché non fornisce alcun controllo sull'ordine dei riavvii dell'istanza, presupponendo che più di una macchina virtuale venga riavviata. Per altre informazioni, vedere Usare il riavvio della macchina virtuale dell'infrastruttura di Azure per ottenere una maggiore disponibilità di un sistema SAP.

Inoltre, anche se il parametro attiva l'avvio di un'istanza di SAP ABAP o Java quando viene avviato il servizio Windows/Linux correlato dell'istanza, in alcuni scenari è consigliabile evitare il riavvio automatico. I riavvii dei servizi SAP, ad esempio, sono comuni quando si usano le funzionalità di gestione del ciclo di vita del software SAP, ad esempio SUM, o durante gli aggiornamenti. In questi scenari, i riavvii possono provocare interruzioni dei servizi. Inoltre, il parametro di avvio automatico non deve essere usato per le istanze di SAP in cluster.