Linee guida per il ripristino di emergenza per l'applicazione SAP

  • Articolo

Per configurare il ripristino di emergenza per il carico di lavoro SAP in Azure, è necessario testare, ottimizzare e aggiornare regolarmente il processo. Il test del ripristino di emergenza consente di identificare la sequenza di servizi dipendenti necessari prima di poter attivare il failover del carico di lavoro SAP o avviare il sistema nel sito secondario. Le organizzazioni in genere hanno i propri sistemi SAP connessi ai servizi Active Directory (AD) e Domain Name System (DNS) per funzionare correttamente. Quando si configura ripristino di emergenza per il carico di lavoro SAP, assicurarsi che i servizi AD e DNS funzionino prima di ripristinare SAP e altri sistemi NON SAP, per garantire il corretto funzionamento delle funzioni dell'applicazione. Per indicazioni sulla protezione di Active Directory e DNS, informazioni su come proteggere Active Directory e DNS. La raccomandazione di ripristino di emergenza per l'applicazione SAP descritta in questo documento è a livello astratto, è necessario progettare la strategia di ripristino di emergenza in base alla configurazione specifica e documentare lo scenario end-to-end.

Raccomandazione di ripristino di emergenza per i carichi di lavoro SAP

In genere nei sistemi SAP NetWeaver distribuiti; i servizi centrali, il database e l'archiviazione condivisa (NFS/SMB) sono un singolo punto di errore (SPOF). Per attenuare l'effetto di spOFs diversi, è necessario configurare la ridondanza di questi componenti. La ridondanza di questi componenti SPOF nell'area primaria viene ottenuta configurando la disponibilità elevata. La configurazione a disponibilità elevata del componente protegge il sistema SAP da errori o catastrofi locali. Tuttavia, per proteggere le applicazioni SAP dalla emergenza geograficamente dispersa, la strategia di ripristino di emergenza deve essere implementata per tutti i componenti SAP.

Per i sistemi SAP in esecuzione nelle macchine virtuali, è possibile usare Azure Site Recovery per creare un piano di ripristino di emergenza. Di seguito è riportato l'approccio consigliato per il ripristino di emergenza per ogni componente di un sistema SAP. I motori SAP autonomi non NetWeaver, ad esempio INTUNE e applicazioni non SAP, non sono trattati in questo documento.

Componenti Recommendation
Dispatcher Web SAP Replicare la macchina virtuale con Azure Site Recovery
Servizi centrali SAP Replicare la macchina virtuale con Azure Site Recovery
Server applicazioni SAP Replicare la macchina virtuale con Azure Site Recovery
SAP Database Usare il metodo di replica offerto dal database
Archiviazione condivisa Replicare il contenuto usando il metodo appropriato per tipo di archiviazione

Dispatcher Web SAP

Il componente SAP Web Dispatcher funziona come servizio di bilanciamento del carico per il traffico SAP tra i server applicazioni SAP. Sono disponibili diverse opzioni per ottenere una disponibilità elevata del componente SAP Web Dispatcher nell'area primaria. Per altre informazioni su questa opzione, vedere Disponibilità elevata dell'installazionedi SAP Web Dispatcher e SAP Web dispatcher HA in Azure.

  • Opzione 1: disponibilità elevata tramite la soluzione cluster.
  • Opzione 2: disponibilità elevata con dispatcher Web SAP paralleli.

Per ottenere il ripristino di emergenza per la configurazione di SAP Web Dispatcher a disponibilità elevata nell'area primaria, è possibile usare Azure Site Recovery. Per i dispatcher Web paralleli (opzione 2) in esecuzione nell'area primaria, è possibile configurare Azure Site Recovery per ottenere il ripristino di emergenza. Tuttavia, se è stato configurato SAP Web Dispatcher usando l'opzione 1 nell'area primaria, è necessario apportare alcune modifiche aggiuntive dopo il failover per avere una configurazione di disponibilità elevata simile nell'area di ripristino di emergenza. Poiché la configurazione della disponibilità elevata di SAP Web Dispatcher con la soluzione cluster è configurata in modo analogo ai servizi centrali SAP. Seguire le stesse linee guida indicate per SAP Central Services.

Servizi centrali SAP

I servizi centrali SAP contengono inqueue e server messaggi, ovvero uno degli SPOF dell'applicazione SAP. In un sistema SAP è possibile configurare una sola istanza di questo tipo e può essere configurata per la disponibilità elevata. Leggere Disponibilità elevata per il servizio SAP Central per comprendere le diverse soluzioni a disponibilità elevata per il carico di lavoro SAP in Azure.

La configurazione di disponibilità elevata per SAP Central Services protegge le risorse e i processi dagli eventi imprevisti locali. Per ottenere il ripristino di emergenza per SAP Central Services, è possibile usare Azure Site Recovery. Azure Site Recovery replica le macchine virtuali e i dischi gestiti collegati, ma sono disponibili considerazioni aggiuntive per la strategia di ripristino di emergenza. Per altre informazioni, vedere la sezione seguente, in base al sistema operativo usato per i servizi centrali SAP.

Per il sistema SAP, la ridondanza del componente SPOF nell'area primaria viene ottenuta configurando la disponibilità elevata. Per ottenere una configurazione a disponibilità elevata simile nell'area di ripristino di emergenza dopo il failover, è necessario considerare punti aggiuntivi come la riconfigurazione del cluster, la disponibilità delle directory condivise SAP, oltre alla replica di macchine virtuali e al disco gestito collegato al sito di ripristino di emergenza usando Azure Site Recovery. In Linux è possibile ottenere la disponibilità elevata dell'applicazione SAP usando la soluzione cluster pacemaker. Il diagramma seguente illustra i diversi componenti coinvolti nella configurazione della disponibilità elevata per i servizi centrali SAP con Pacemaker. Ogni componente deve essere preso in considerazione per avere una disponibilità elevata simile configurata nel sito di ripristino di emergenza. Se è stato configurato SAP Web Dispatcher usando la soluzione cluster pacemaker, verrà applicata anche una considerazione simile.

Architettura linux del sistema SAP

Servizio di bilanciamento del carico interno

Azure Site Recovery replica le macchine virtuali nel sito di ripristino di emergenza, ma non replica il servizio di bilanciamento del carico di Azure. È necessario creare un servizio di bilanciamento del carico interno separato nel sito di ripristino di emergenza o dopo il failover. Se si crea un servizio di bilanciamento del carico interno in anticipo, creare un pool back-end vuoto e aggiungere macchine virtuali dopo l'evento di failover.

Soluzione cluster Pacemaker

Le configurazioni di un cluster pacemaker risiedono nei file locali delle macchine virtuali, replicate nel sito di ripristino di emergenza con Azure Site Recovery. La configurazione del cluster as-is pacemaker non funzionerà in modo out-of-the-box nelle macchine virtuali dopo il failover. È necessaria una riconfigurazione aggiuntiva del cluster per rendere funzionante la soluzione.

Leggere questi blog per informazioni sulla riconfigurazione del cluster pacemaker nell'area di ripristino di emergenza, in base al tipo di meccanismo di archiviazione e di isolamento.

Directory condivise SAP per Linux

La configurazione a disponibilità elevata della piattaforma SAP NetWeaver o ABAP usa il server di replica inqueue per ottenere la ridondanza a livello di applicazione per il servizio sap con configurazione del cluster Pacemaker. La configurazione a disponibilità elevata dei servizi centrali SAP (ASCS e ERS) usa i montaggi NFS. È quindi necessario assicurarsi che i file binari e i dati SAP in questi montaggi NFS vengano replicati nel sito di ripristino di emergenza. Azure Site Recovery replica le macchine virtuali e il disco gestito locale collegato, ma non replica i montaggi NFS. In base al tipo di archiviazione NFS configurato per la configurazione, è necessario assicurarsi che i dati siano replicati e disponibili nel sito di ripristino di emergenza. La metodologia di replica tra aree per ogni archiviazione viene presentata a livello astratto. È necessario confermare i passaggi esatti per replicare l'archiviazione ed eseguire test.

Directory condivise SAP Replica tra aree
NFS nei file di Azure Personalizzato (come rsync)
NFS in ANF Sì (replica tra aree)
Cluster NFS Personalizzato

Suggerimento

È consigliabile distribuire uno dei servizi NFS di Prima parte di Azure: NFS in volumi NFS File di Azure o NFS ANF per l'archiviazione di dati condivisi in un sistema SAP a disponibilità elevata. Tenere presente che si sottolineano le architetture di riferimento SAP, usando i cluster NFS.

Meccanismo di fencing

Indipendentemente dal sistema operativo (SLES o RHEL) e dalla relativa versione, pacemaker richiede un meccanismo di fencing valido affinché l'intera soluzione funzioni correttamente. In base al tipo di meccanismo di fencing configurato nell'area primaria, è necessario assicurarsi che lo stesso meccanismo di fencing sia configurato nel sito di ripristino di emergenza dopo il failover.

Meccanismo di fencing Raccomandazione di ripristino di emergenza tra aree
SBD usando il server di destinazione iSCSI Replicare il server di destinazione iSCSI usando Azure Site Recovery.
Nelle macchine virtuali di ripristino di emergenza individuare di nuovo il disco iSCSI.
Agente di recinzione di Azure Abilitare identità del sistema gestito nelle macchine virtuali di ripristino di emergenza.
Assegnare ruoli personalizzati.
Aggiornare la risorsa agente di recinzione nel cluster.
SBD usando il disco condiviso di Azure* Configurare il nuovo disco condiviso di Azure nell'area di ripristino di emergenza. Collegare disco condiviso di Azure alle macchine virtuali di ripristino di emergenza dopo il failover.
Configurare il dispositivo SBD del disco condiviso di Azure.

*ZRS per il disco condiviso di Azure è disponibile in aree limitate.

Nota

È consigliabile disporre dello stesso meccanismo di fencing per l'area primaria e di ripristino di emergenza per semplificare l'operazione e il failover. Non è consigliabile disporre di un meccanismo di isolamento diverso dopo il failover nel sito di ripristino di emergenza.

Server applicazioni SAP

Nell'area primaria la ridondanza dei server applicazioni SAP viene ottenuta installando istanze in più macchine virtuali. Per avere ripristino di emergenza per i server applicazioni SAP, è possibile configurare Site Recovery di Azure per ogni macchina virtuale del server applicazioni. Per le risorse di archiviazione condivise (file system di trasporto, file system di interfaccia) collegate ai server applicazioni, seguire la procedura di ripristino di emergenza appropriata in base al tipo di archiviazione condivisa.

Server di database SAP

Per i database che eseguono il carico di lavoro SAP, usare la tecnologia di replica DBMS nativa per configurare il ripristino di emergenza. L'uso di Site Recovery di Azure per i database non è consigliato, perché non garantisce la coerenza del database e presenta limitazioni di varianza dei dati. La tecnologia di replica per ogni database è diversa, quindi seguire le rispettive linee guida per il database. Nella tabella seguente viene illustrato l'elenco dei database usati per i carichi di lavoro SAP e la raccomandazione di ripristino di emergenza corrispondente.

Database Raccomandazione di ripristino di emergenza
SAP HANA Replica di sistema HANA (HSR)
Oracle Oracle Data Guard (FarSync)
IBM DB2 Ripristino di emergenza a disponibilità elevata (HADR)
Microsoft SQL Microsoft SQL Always On
SAP ASE ALWAYS ON DI ASE HADR
SAP MaxDB Database di standby

Per la soluzione ottimizzata per i costi, è anche possibile usare l'opzione di backup e ripristino per la strategia di ripristino di emergenza del database.

Backup e ripristino

Il backup e il ripristino sono altre soluzioni che è possibile usare per ottenere il ripristino di emergenza per i carichi di lavoro SAP se l'RTO aziendale e RPO non sono critici. È possibile usare il backup di Azure, un servizio di backup basato sul cloud per eseguire copie di diversi componenti del carico di lavoro SAP, ad esempio macchine virtuali, dischi gestiti e database supportati. Per altre informazioni sulle impostazioni di supporto generali e sulle limitazioni per scenari e distribuzioni di Backup di Azure, vedere Backup di Azure matrice di supporto.

Servizi Componente supporto Backup di Azure
Calcolo Macchine virtuali di Azure Supportato
Archiviazione Azure Managed Disks inclusi i dischi condivisi Supportato
Archiviazione Condivisione file di Azure - SMB (Standard o Premium) Supportato
Archiviazione BLOB di Azure Supportato
Archiviazione Condivisione file di Azure - NFS (Standard o Premium) Non supportato
Archiviazione Azure NetApp Files Non supportato
Database Database SAP HANA nelle macchine virtuali di Azure Supportato
Database SQL Server nelle macchine virtuali di Azure Supportato
Database Oracle Supportato*
Database IBM DB2, SAP ASE Non supportato

Nota

*Backup di Azure supporta il database Oracle usando il backup di macchine virtuali di Azure per gli snapshot coerenti con il database.

Backup di Azure non supporta tutte le risorse di archiviazione e i database di Azure usati per il carico di lavoro SAP.

Backup di Azure archivia i backup nell'insieme di credenziali dei servizi di ripristino, che replica i dati in base al tipo di replica scelto (archiviazione con ridondanza locale, archiviazione con ridondanza della zona o archiviazione con ridondanza geografica). Per l'archiviazione con ridondanza geografica, i dati di backup vengono replicati in un'area secondaria abbinata. Con la funzionalità di ripristino tra aree abilitata, è possibile ripristinare i dati del tipo di gestione supportato nell'area secondaria.

Il backup e il ripristino sono un approccio ottimizzato per i costi più tradizionale, ma offre un compromesso di RTO più elevato. Poiché è necessario ripristinare tutte le applicazioni dal backup in caso di failover nell'area di ripristino di emergenza. È quindi necessario analizzare le esigenze aziendali e progettare di conseguenza una strategia di ripristino di emergenza.

Riferimenti