Continuità aziendale e ripristino di emergenza per una migrazione SAP

Articolo
08/14/2024

Questo articolo si basa sulle considerazioni e le raccomandazioni nell'area di progettazione della zona di destinazione di Azure per BCDR. Questo articolo descrive i vincoli univoci nelle zone di destinazione che supportano una piattaforma SAP. SAP è una piattaforma cruciale, quindi è consigliabile incorporare anche altre linee guida cruciali nella progettazione.

Scenario e ambito

Incorporare principi nell'architettura che riguardano scenari di continuità aziendale e ripristino di emergenza locali. Questi principi si applicano anche ad Azure. Azure potrebbe tuttavia avere una capacità hardware maggiore rispetto all'ambiente locale per compensare un errore dell'host. Per ripristinare automaticamente anche le macchine virtuali di Azure più grandi, è possibile configurarle per il riavvio in un altro server. Configurare le distribuzioni di Azure per usare le stesse condizioni delle distribuzioni locali. Se si usano configurazioni del cluster di failover automatico per distribuire sistemi locali o hardware bare metal, distribuirli nello stesso modo in Azure. Le applicazioni SAP che eseguono i processi aziendali più critici dell'organizzazione richiedono:

Disponibilità del processo aziendale e del servizio.
Obiettivi del tempo di ripristino (RTO) per scenari di errore o scenari di emergenza.
Obiettivi del punto di ripristino (RPO) per gli scenari di errore.
Attività operative e di gestione del ciclo di vita e tecnologie eseguite durante gli scenari di errore. Queste attività di gestione includono l'applicazione di patch ai sistemi operativi guest e ai sistemi di gestione di database, la clonazione e l'aggiornamento dei sistemi SAP.

Suggerimento

Determinare una soluzione di disponibilità elevata e ripristino di emergenza (HADR) per ognuno degli archetipi nel panorama SAP all'inizio. Assicurarsi che la soluzione includa tutti i componenti SAP.

Configurare una soluzione HADR in Azure in anticipo, in almeno un panorama e mantenerla attiva. I team possono quindi acquisire esperienza con le tecnologie della soluzione, che potrebbero differire dalle tecnologie esistenti. Configurare HADR in anticipo per sviluppare ed evolvere le procedure operative standard (SOP).

Pianificare la disponibilità elevata completa, il ripristino di emergenza e la protezione dei backup per i carichi di lavoro di produzione non appena il sistema è attivo.

Questo articolo illustra gli aspetti seguenti in materia di continuità aziendale e ripristino di emergenza per uno scenario SAP su scala aziendale:

Disponibilità elevata all'interno di un'area di Azure
Considerazioni su backup e ripristino
Criteri per decidere tra il ripristino di emergenza tra aree e regionali

Disponibilità elevata all'interno di un'area di Azure

Le sezioni seguenti forniscono considerazioni sulla progettazione e consigli per la disponibilità elevata all'interno di un'area di Azure per uno scenario aziendale SAP.

Considerazioni sulla progettazione per la disponibilità elevata

Quando si implementa la disponibilità elevata, l'obiettivo è fornire la disponibilità per il singolo punto di errore del software SAP, ad esempio:

Sistemi di gestione del database.
Singoli punti di errore in un'applicazione, ad esempio SAP Advanced Business Application Programming (ABAP), ABAP SAP Central Services (ASCS) e SAP Central Services (SCS). Gli esempi di disponibilità elevata includono SAP NetWeaver e l'architettura SAP S/4HANA.
Altri strumenti, ad esempio SAP Web Dispatcher.

Per altri scenari, non limitare la disponibilità a errori dell'infrastruttura o errori software. Applicare la disponibilità a tutte le attività di gestione del ciclo di vita necessarie. Ad esempio, è possibile applicare patch al sistema operativo nelle macchine virtuali, al sistema di gestione del database (DBMS) e al software SAP. Per ridurre al minimo le interruzioni che possono verificarsi durante i tempi di inattività pianificati e le operazioni di gestione del ciclo di vita, usare strumenti comuni che consentono di proteggere i sistemi da interruzioni del servizio non pianificate.

SAP e i database SAP supportano i cluster di failover automatico. In Windows la funzionalità clustering di failover di Windows Server 2022 supporta il failover. In Linux, Linux Pacemaker o strumenti partner come SIOS Protection Suite e Veritas InfoScale supportano il failover. In Azure è possibile distribuire solo una configurazione a disponibilità elevata di subset nel proprio data center.

Per altre informazioni, vedere Scenari supportati per carichi di lavoro SAP in macchine virtuali di Azure e Scenari supportati per le istanze Large di SAP HANA.

Per il livello DBMS, il modello di architettura comune consiste nel replicare i database contemporaneamente e con stack di archiviazione diversi rispetto a quelli usati dalle macchine virtuali primarie e dalle macchine virtuali secondarie. Azure non supporta le architetture in cui le macchine virtuali primarie e le macchine virtuali secondarie condividono l'archiviazione per i dati DBMS. Azure non supporta anche i log delle transazioni o i log di rollforward. Il principio guida consiste nell'usare due stack di archiviazione indipendenti, anche se si basano su condivisioni NFS (Network File System). Queste limitazioni sono esclusive delle soluzioni di Azure e non delle soluzioni locali.

Azure offre altre opzioni perché supporta la condivisione NFS e Server Message Block. È possibile usare dischi condivisi di Azure in Windows per i componenti ASCS e SCS e scenari di disponibilità elevata specifici. Configurare i cluster di failover separatamente per i componenti del livello applicazione SAP e il livello DBMS. Azure non supporta architetture a disponibilità elevata che combinano componenti a livello di applicazione SAP e il livello DBMS in un cluster di failover.

La maggior parte dei cluster di failover per i componenti del livello applicazione SAP e il livello DBMS richiedono un indirizzo IP virtuale per un cluster di failover. Un'eccezione comune è quando si usa Oracle Data Guard, che non richiede un indirizzo IP virtuale. Azure Load Balancer deve gestire l'indirizzo IP virtuale per tutti gli altri casi. È possibile usare un servizio di bilanciamento del carico per ogni configurazione del cluster. È consigliabile usare la versione standard del servizio di bilanciamento del carico. Per altre informazioni, vedere Connettività degli endpoint pubblici per le macchine virtuali usando Azure Load Balancer Standard in scenari di disponibilità elevata SAP.

Per altre informazioni, vedere Architettura e scenari a disponibilità elevata per SAP NetWeaver.

La tabella seguente illustra i contratti di servizio a livello di piattaforma per varie opzioni di distribuzione a disponibilità elevata. I partner che forniscono i servizi gestiti forniscono anche il contratto di servizio a livello di applicazione.

Livello	Scenario di disponibilità elevata	Contratto di servizio della piattaforma
1	Zona di disponibilità	99,99%
2	Set di disponibilità	99,95%
3	Singola macchina virtuale (riparazione automatica)	99,90%

Zone di disponibilità e set di disponibilità di Azure

Prima di distribuire l'infrastruttura a disponibilità elevata, determinare se eseguire la distribuzione con un set di disponibilità di Azure o una zona di disponibilità a seconda dell'area scelta. Le differenze principali per le macchine virtuali distribuite con un set di disponibilità sono:

Le macchine virtuali non vengono distribuite in zone di disponibilità diverse.
Il tipo di macchine virtuali che è possibile distribuire tramite un singolo set di disponibilità è limitato perché la prima macchina virtuale distribuita nel set definisce l'host. Ad esempio, non è possibile combinare macchine virtuali serie M e macchine virtuali serie E in un unico set di disponibilità.

Quando si distribuisce l'architettura a disponibilità elevata in zone di disponibilità diverse, è possibile avere un contratto di servizio superiore per le macchine virtuali. Per altre informazioni, vedere Contratti di servizio delle macchine virtuali di Azure. A seconda dell'area di Azure, è possibile individuare diverse condizioni di latenza di rete nel traffico di rete tra macchine virtuali. Per altre informazioni, vedere Configurazioni del carico di lavoro SAP con zone di disponibilità di Azure.

Se si sceglie un approccio di distribuzione a livello di zona, valutare il modo in cui la latenza tra zone per l'area di Azure scelta potrebbe influire sulle scelte di progettazione delle prestazioni e dell'architettura. Si consideri la latenza tra il server applicazioni e il database e tra i due nodi del database.

Se si usa una distribuzione di zona attiva/passiva per il livello server applicazioni in cui i server applicazioni devono connettersi al database nella stessa zona di disponibilità, configurare l'automazione e creare un SOP per abilitare il ripristino rapido e automatizzato in caso di failover del database.

Se si usano zone di disponibilità nella soluzione SAP, progettare anche tutti gli altri servizi di Azure e i componenti dell'infrastruttura nel panorama SAP per la ridondanza della zona in modo da ottenere una vera ridondanza della zona. Esempi di servizi e componenti da tenere in considerazione includono gateway Azure ExpressRoute, Load Balancer, File di Azure, Azure NetApp Files, proxy inversi, firewall, servizi antivirus e infrastruttura di backup.

Consigli di progettazione per la disponibilità elevata

Azure offre diverse opzioni per soddisfare i contratti di servizio dell'infrastruttura dell'applicazione. È consigliabile scegliere la stessa opzione per tutti e tre i componenti SAP: servizi centrali, server applicazioni e database. Per altre informazioni sui contratti di servizio per macchine virtuali, set di disponibilità e zone di disponibilità, vedere Contratti di servizio per Servizi online.
Quando si distribuiscono macchine virtuali in un set di disponibilità, l'allineamento con domini di errore e aggiornamento impedisce alle macchine virtuali di trovarsi nello stesso hardware host, che fornisce protezione da errori hardware. Quando si distribuiscono macchine virtuali tramite zone di disponibilità e si usano zone diverse, si creano le macchine virtuali in posizioni fisiche diverse. Questa configurazione offre una protezione aggiuntiva contro problemi di alimentazione, raffreddamento o rete che interessano i data center della zona nel suo complesso. Tuttavia, non è possibile distribuire i set di disponibilità di Azure all'interno di una zona di disponibilità di Azure a meno che non si usino gruppi di posizionamento di prossimità.

Se si sceglie un approccio di distribuzione a livello di zona, i livelli DBMS, central services e applicazione SAP vengono eseguiti in zone di disponibilità diverse. Tuttavia, ogni zona di disponibilità ha probabilmente più server applicazioni. In questo scenario, i server applicazioni in ogni zona non traggono automaticamente vantaggio dai domini di errore e dai domini di aggiornamento. È possibile usare i set di disponibilità per ottenere questi vantaggi. Per altre informazioni, vedere Gruppi di posizionamento di prossimità di Azure per una latenza di rete ottimale con SAP.
Quando si creano set di disponibilità, usare il numero massimo di domini di errore e domini di aggiornamento disponibili. Ad esempio, se si distribuiscono più di due macchine virtuali in un set di disponibilità, usare il numero massimo di domini di errore (tre). E usare domini di aggiornamento sufficienti per limitare l'effetto di potenziali errori hardware fisici, interruzioni di rete o interruzioni dell'alimentazione, oltre alla manutenzione pianificata di Azure. Il numero predefinito di domini di errore è due e non è possibile modificarlo online in un secondo momento.
In una distribuzione del set di disponibilità, ogni componente di un sistema SAP deve trovarsi nel proprio set di disponibilità. I servizi centrali SAP, il database e le macchine virtuali dell'applicazione devono trovarsi nei propri set di disponibilità.
Quando si usano i gruppi di posizionamento di prossimità di Azure in una distribuzione del set di disponibilità, assicurarsi che tutti e tre i componenti SAP (servizi centrali, il server applicazioni e il database) si trovino nello stesso gruppo di posizionamento di prossimità.
Se si usano gruppi di posizionamento di prossimità, usarne uno per ogni SID (SAP System Identification). I gruppi non si estendono tra zone di disponibilità o aree di Azure.
Quando si usano i gruppi di posizionamento di prossimità di Azure in una distribuzione delle zone di disponibilità, assicurarsi che i due componenti SAP (servizi centrali e server applicazioni) si trovino nello stesso gruppo di posizionamento di prossimità. Le macchine virtuali di database nelle due zone non fanno più parte dei gruppi di posizionamento di prossimità. I gruppi di posizionamento di prossimità per ogni zona hanno come ambito la distribuzione della macchina virtuale che esegue le istanze DI SAP ASCS e SCS. Il vantaggio di questa configurazione è che è possibile ridimensionare le macchine virtuali con maggiore flessibilità. È anche possibile passare facilmente ai nuovi tipi di vm nel livello DBMS o nel livello applicazione del sistema SAP.
Azure non supporta la combinazione di ASCS e disponibilità elevata del database in un singolo cluster Linux Pacemaker. Separarli in singoli cluster. È possibile combinare fino a cinque cluster di servizi centrali in una coppia di macchine virtuali.
Usare Load Balancer Standard davanti a ASCS e cluster di database.
Eseguire tutti i sistemi di produzione in unità SSD Premium di Azure e usare Azure NetApp Files o Archiviazione su disco Ultra di Azure. Assicurarsi almeno che il disco del sistema operativo si trovi nel livello Premium in modo da poter migliorare le prestazioni e ottenere il contratto di servizio migliore.
Distribuire entrambe le macchine virtuali nella coppia di disponibilità elevata in un set di disponibilità o nelle zone di disponibilità. Assicurarsi che queste macchine virtuali abbiano le stesse dimensioni e abbiano la stessa configurazione di archiviazione.
Usare la tecnologia di replica di database nativa per sincronizzare il database in una coppia a disponibilità elevata.
Usare uno dei servizi seguenti per eseguire cluster di servizi centrali SAP, a seconda del sistema operativo:
- Un cluster SUSE Linux Enterprise Server Pacemaker supporta un agente di isolamento di Azure e un numero di dispositivi di isolamento di tre nodi.
- Un cluster Red Hat Enterprise Linux Pacemaker supporta un agente di isolamento di Azure e non supporta i dispositivi di isolamento dei nodi.
- Un cluster Windows.
- Software cluster non Microsoft certificato SAP.
Configurare i parametri di timeout del cluster come consigliato nella documentazione per i servizi centrali e i cluster di database.

Archiviazione per carichi di lavoro SAP

Scegliere le opzioni di archiviazione appropriate quando si progetta la resilienza nel carico di lavoro SAP. La progettazione corretta dell'archiviazione di Azure per i carichi di lavoro SAP può ridurre al minimo la latenza e ottimizzare la velocità effettiva. Prendere in considerazione l'implementazione e il modo in cui le indicazioni seguenti consentono di prendere decisioni relative all'architettura per l'implementazione di SAP in Azure. Per altre informazioni, vedere Tipi di archiviazione di Azure per carichi di lavoro SAP.
È consigliabile eseguire SAP HANA in Azure solo in tipi di archiviazione certificati SAP. È necessario eseguire determinati volumi in determinate configurazioni del disco. Ad esempio, le configurazioni potrebbero abilitare l'acceleratore di scrittura o usare l'archiviazione SSD Premium. È anche necessario assicurarsi che il file system in esecuzione nell'archiviazione sia compatibile con il sistema DBMS in esecuzione nel computer. Per altre informazioni, vedere Configurazioni di archiviazione per SAP HANA.

Oltre ai dischi dati gestiti di Azure collegati alle macchine virtuali, diverse soluzioni di archiviazione condivise native di Azure eseguono applicazioni SAP in Azure. La configurazione a disponibilità elevata potrebbe differire perché Azure Site Recovery non supporta alcuni servizi di archiviazione disponibili in Azure. Usare i tipi di archiviazione seguenti per i carichi di lavoro SAP.

Tipo di archiviazione	Supporto della configurazione a disponibilità elevata
Dischi condivisi di Azure (archiviazione con ridondanza locale) o archiviazione con ridondanza della zona (ZRS)	Cluster di failover di Windows Server 2022. Per informazioni dettagliate sulla configurazione, vedere Progettare la disponibilità elevata di SAP con il clustering di failover di Windows Server 2022.
NFS in File di Azure (archiviazione con ridondanza locale o archiviazione con ridondanza della zona)	Cluster basato su Pacemaker in ambienti Linux. Assicurarsi di controllare la disponibilità di NFS in varie aree.
NFS in Azure NetApp Files	Cluster basato su Pacemaker in ambienti Linux. Per altre informazioni, vedere Azure NetApp Files per le macchine virtuali SAP.
SMB in File di Azure (archiviazione con ridondanza locale o archiviazione con ridondanza della zona)	Cluster di failover di Windows Server 2022. Per informazioni dettagliate sulla configurazione, vedere Installare SAP NetWeaver a disponibilità elevata con File di Azure SMB.
SMB in Azure NetApp Files	Cluster di failover di Windows Server 2022. Per informazioni dettagliate sulla configurazione, vedere Disponibilità elevata per SAP NetWeaver con Azure NetApp Files (SMB) per le applicazioni SAP.

Anziché i servizi di archiviazione condivisa nativi di Azure, è possibile usare cluster NFS tradizionali (in base alla replica distribuita di dispositivi bloccati replicati), GlusterFS o a un volume condiviso cluster con Spazi di archiviazione diretta come soluzione di archiviazione condivisa alternativa per eseguire carichi di lavoro SAP in Azure. Queste scelte sono particolarmente utili quando i servizi di archiviazione condivisa nativi di Azure non sono disponibili nell'area di Azure di destinazione o non supportano l'architettura di destinazione. Per altre informazioni sulla disponibilità del servizio di archiviazione, vedere Prodotti Azure per area.
Per informazioni sulle opzioni di archiviazione disponibili per i carichi di lavoro SAP in Azure, vedere Raccomandazioni e linee guida per configurare il ripristino di emergenza.

Backup e ripristino

Le sezioni seguenti descrivono le considerazioni di progettazione e le raccomandazioni per il backup e il ripristino in uno scenario SAP.

Anche se il backup e il ripristino non sono in genere considerati una soluzione a disponibilità elevata adeguata per un carico di lavoro SAP di produzione, la tecnologia offre altri vantaggi. La maggior parte delle aziende che usano applicazioni SAP deve seguire le normative di conformità che richiedono l'archiviazione a lungo termine dei backup. In altri scenari, è anche necessario disporre di un backup da cui è possibile eseguire il ripristino. Queste indicazioni presuppongono che sia già stato stabilito il backup e il ripristino e segua le procedure consigliate per le applicazioni SAP, il che significa che è possibile:

Eseguire un ripristino temporizzato per i database di produzione in qualsiasi momento, in un intervallo di tempo che soddisfa l'obiettivo RTO. Il ripristino temporizzato offre in genere protezione da errori degli operatori, ad esempio l'eliminazione di dati, nel livello DBMS o tramite SAP.
Gestire un archivio per mantenere i backup a lungo termine per soddisfare le normative di conformità.
Usare i backup del database per clonare il sistema SAP e ripristinare i backup in un altro server o macchina virtuale.
Usare i dati del database di produzione dai backup del database per aggiornare i sistemi non di produzione.
Eseguire il backup di server applicazioni SAP e macchine virtuali, dischi o snapshot di macchine virtuali.
Eseguire il backup di un sistema SAP HANA con la replica abilitata.
Eseguire il backup degli snapshot dell'istanza del database SAP HANA.

Se si esegue il backup e il ripristino in locale, è necessario trasferire queste funzionalità nei sistemi SAP in Azure. Se si preferisce la soluzione corrente, controllare se il fornitore di backup supporta le distribuzioni di Azure o se ha una soluzione SaaS (Software as a Service) per Azure.

Azure offre un servizio SaaS di backup denominato Backup di Azure, che acquisisce snapshot di macchine virtuali e gestisce lo streaming di backup di SQL Server e SAP HANA. Se si usa Azure NetApp Files per archiviare i database SAP HANA, è possibile eseguire backup basati su snapshot di archiviazione coerenti con HANA.

È anche possibile usare Backup di Azure per eseguire il backup di database in cui è abilitata la replica di sistema SAP HANA (HSR). Backup di Azure gestisce automaticamente i backup quando si verifica un failover ed elimina la necessità di intervento manuale. Il backup fornisce anche:

Protezione immediata senza backup completi correttivi, quindi è possibile proteggere le istanze di HANA o i nodi di installazione HSR come singolo contenitore HSR.
Il vantaggio del backup istantaneo e del ripristino istantaneo.
Approccio basato su snapshot coerente con HANA che si integra con Backint per SAP HANA. È possibile usare Backup come singolo prodotto per l'intero panorama haNA e per qualsiasi dimensione del database.

Per altre informazioni, vedere Sistema di database SAP HANA con replica abilitata e backup dello snapshot dell'istanza di SAP HANA.

Consigli di progettazione per il backup e il ripristino

È possibile usare Backup di Azure per eseguire il backup del server applicazioni SAP e delle macchine virtuali dei servizi centrali.
È possibile usare un backup di SAP HANA per le distribuzioni HANA fino a 8 TB. Per altre informazioni, vedere Matrice di supporto per il backup dei database SAP HANA nelle macchine virtuali di Azure.
Se si usa un'infrastruttura come soluzione di backup del servizio, ridimensionare l'infrastruttura di backup per assicurarsi che possa eseguire il backup di tutti i sistemi di dimensioni di produzione simultaneamente o, come in uno scenario reale, entro gli intervalli di tempo previsti. Usare una configurazione di produzione o una configurazione simile per aree come la rete e la sicurezza.
Testare i tempi di backup e ripristino per verificare che soddisfino i requisiti RTO per ripristinare tutti i sistemi contemporaneamente dopo un'emergenza.
In teoria, evitare di eseguire il pull dei backup da Azure nell'infrastruttura di backup locale, soprattutto per i database di grandi dimensioni. Questo approccio può influire sulla larghezza di banda usata dai circuiti ExpressRoute.
Testare il carico degli strumenti di backup e ripristino come parte del piano di test delle prestazioni.

Ripristino di emergenza

Le sezioni seguenti descrivono le considerazioni di progettazione e le raccomandazioni per il ripristino di emergenza in uno scenario SAP.

Considerazioni sulla progettazione per il ripristino di emergenza

La mappa delle aree di Azure include più di 65 aree di Azure e non tutte eseguono gli stessi servizi. Per distribuzioni software SAP di grandi dimensioni, in particolare quelle che usano SAP HANA, cercare le aree di Azure che offrono macchine virtuali serie M di Azure o macchine virtuali serie Mv2. Archiviazione di Azure associa anche coppie di aree diverse per replicare un subset più piccolo di tipi di archiviazione in un'altra area. Per altre informazioni, vedere Panoramica delle regioni associate di Azure.

Le principali sfide dell'associazione di aree di Azure per carichi di lavoro SAP sono le seguenti:

Le coppie non sono sempre coerenti con i servizi delle macchine virtuali serie M o Mv2. Molte organizzazioni che distribuiscono i sistemi SAP non usano aree abbinate di Azure. Scelgono invece le aree in base alla disponibilità dei tipi di macchina virtuale necessari.
È possibile replicare l'archiviazione standard tra aree abbinate, ma non è possibile usare l'archiviazione standard per archiviare i database o i dischi rigidi virtuali. È possibile replicare i backup solo tra aree abbinate usate. Per tutti gli altri dati, eseguire la replica usando funzionalità DBMS native, ad esempio la replica di sistema SQL Server Always On o SAP HANA. Usare una combinazione di Site Recovery, strumenti come rsync o robocopye altri software non Microsoft per il livello dell'applicazione SAP.
In caso di emergenza, più clienti interessati in un'area di Azure eseguono il failover nell'area di ripristino di emergenza associata corrispondente. Questa situazione porta alla concorrenza delle risorse per portare le macchine virtuali inattite nell'area di ripristino di emergenza. La soluzione alternativa consiste nell'eseguire sistemi non di produzione nell'area di ripristino di emergenza e usare le stesse risorse per ospitare repliche di ripristino di emergenza dei sistemi di produzione. Questo uso duale delle infrastrutture di Azure nell'area di ripristino di emergenza consente di evitare vincoli di capacità delle risorse.

Un'altra considerazione importante consiste nel proteggere la capacità operativa necessaria nell'area di emergenza. In caso di emergenza, potrebbe essere necessario eseguire l'applicazione SAP per un intervallo di tempo minimo con capacità IT minima e per risorse umane critiche solo mentre si lavora per ripristinare il normale funzionamento nell'area primaria. Questa strategia richiede che l'infrastruttura IT minima sia disponibile nell'area di ripristino di emergenza.

Dopo aver definito le aree di Azure, è necessario scegliere un modello di distribuzione:

I sistemi di produzione verranno distribuiti nell'area primaria?
I sistemi SAP non di produzione verranno distribuiti nell'area di ripristino di emergenza?
Si userà un'architettura che raggruppa tutti i sistemi SAP nell'area primaria? Questa configurazione garantisce che l'area di ripristino di emergenza venga usata solo per il ripristino di emergenza.

La maggior parte delle organizzazioni usa entrambe le aree per i sistemi SAP operativi. Le organizzazioni che eseguono copie complete dei sistemi di produzione come sistemi di test di regressione aziendale in genere pianificano l'uso del sistema di test di regressione aziendale della linea di prodotti SAP come destinazione di ripristino di emergenza.

Quando si sceglie un'area di ripristino di emergenza, assicurarsi di avere la connettività ExpressRoute a tale area. Se si hanno più circuiti ExpressRoute che si connettono ad Azure, almeno uno di questi circuiti deve connettersi all'area di Azure primaria. Gli altri devono connettersi all'area di ripristino di emergenza. Questo tipo di architettura si connette alla rete di Azure in un'area geografica o geopolitica diversa e consente di proteggere la connessione se una catastrofe influisce su una delle aree di Azure.

Alcune organizzazioni usano una combinazione di architettura di disponibilità elevata e ripristino di emergenza, che raggruppa la disponibilità elevata con il ripristino di emergenza nella stessa area di Azure. Tuttavia, il raggruppamento della disponibilità elevata con il ripristino di emergenza non è ideale. Le zone di disponibilità di Azure supportano questa architettura. La distanza tra le zone di disponibilità all'interno di un'area di Azure non è così grande quanto la distanza tra due aree di Azure, quindi una calamità naturale potrebbe compromettere i servizi dell'applicazione nell'area in cui si verifica. È anche necessario considerare la latenza tra server applicazioni SAP e server di database. Secondo la nota SAP 1100926, un tempo di round trip minore o uguale a 0,3 ms è un valore valido e un tempo minore o uguale a 0,7 ms è un valore moderato. Pertanto, per le zone con latenze elevate, sono disponibili procedure operative per garantire che i server applicazioni SAP e i server di database vengano sempre eseguiti nella stessa zona. Le organizzazioni scelgono questa architettura per i motivi seguenti:

La conformità è sufficiente con le configurazioni che supportano distanze inferiori tra la distribuzione di produzione e una destinazione di ripristino di emergenza.
La sovranità dei dati è un fattore.
I fattori geopolitici sono coinvolti.
Si tratta di un'opzione a basso costo che supporta gli errori di zona, talvolta combinati con il trasferimento di backup nell'area secondaria per catastrofi naturali che influiscono su un raggio elevato.

Un altro fattore da considerare quando si sceglie l'area di ripristino di emergenza è l'obiettivo rpo e l'obiettivo di ripristino di emergenza per il failover nel sito di ripristino di emergenza. Maggiore è la distanza tra l'area di produzione e le aree di ripristino di emergenza, maggiore è la latenza di rete. La replica asincrona tra aree di Azure, ma la latenza di rete può influire sulla velocità effettiva che è possibile replicare e sulla destinazione RPO. Per ridurre al minimo il valore RPO, è possibile usare un'architettura combinata di disponibilità elevata e ripristino di emergenza. Questa configurazione comporta tuttavia un rischio potenzialmente più elevato da calamità naturali su larga scala.

Consigli di progettazione per il ripristino di emergenza

Assicurarsi che il routing tra domini (CIDR) senza classi per la rete virtuale primaria non sia in conflitto o si sovrapponga al CIDR della rete virtuale del sito di ripristino di emergenza.
Configurare le connessioni ExpressRoute dall'ambiente locale alle aree di ripristino di emergenza di Azure primario e secondario.
Valutare la possibilità di configurare le connessioni VPN dall'ambiente locale alle aree di ripristino di emergenza di Azure primario e secondario. Usare questo metodo come alternativa all'uso di ExpressRoute.
Usare Site Recovery per replicare un server applicazioni in un sito di ripristino di emergenza. Site Recovery consente anche di replicare le macchine virtuali del cluster dei servizi centrali nel sito di ripristino di emergenza. Quando si richiama il ripristino di emergenza, è necessario riconfigurare il cluster Linux Pacemaker nel sito di ripristino di emergenza. Ad esempio, potrebbe essere necessario sostituire l'indirizzo IP virtuale o SBD o eseguire corosync.conf.
Replicare il contenuto dell'insieme di credenziali delle chiavi, ad esempio certificati, segreti o chiavi tra aree, in modo da poter decrittografare i dati nell'area di ripristino di emergenza.
Usare la replica tra aree in Azure NetApp Files per sincronizzare i volumi di file tra l'area primaria e l'area di ripristino di emergenza.
Usare la replica di database nativa, anziché Site Recovery, per sincronizzare i dati con il sito di ripristino di emergenza.
Eseguire il peering delle reti virtuali di ripristino di emergenza e primarie. Ad esempio, per la replica di sistema HANA, è necessario eseguire il peering di una rete virtuale del database SAP HANA alla rete virtuale del database SAP HANA del sito di ripristino di emergenza.
Se si usa l'archiviazione di Azure NetApp Files per le distribuzioni SAP, creare almeno due account Azure NetApp Files nel livello Premium in due aree.
Valutare la possibilità di raggruppare i sistemi in base all'importanza aziendale e alla dipendenza di prossimità in base alle prestazioni dell'applicazione. Per ridurre al minimo l'effetto aziendale di un'interruzione a livello di area, distribuire ogni gruppo in un'area separata in un costrutto di area abbinato. Ad esempio, per ridurre al minimo l'effetto di un'interruzione a livello di area, è possibile distribuire due sistemi ERP Central Component critici che servono due business unit diverse, nel Regno Unito meridionale e nel Regno Unito occidentale.

Passaggio successivo

Opzioni di distribuzione per SAP in Azure

Condividi tramite