Linee guida per il ripristino di emergenza per l'applicazione SAP
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 di ripristino di emergenza del carico di lavoro SAP o avviare il sistema nel sito secondario. Le organizzazioni hanno in genere i sistemi SAP connessi ai servizi Active Directory (AD) e DNS (Domain Name System) per funzionare correttamente. Quando si configura il ripristino di emergenza per il carico di lavoro SAP, assicurarsi che i servizi DI ACTIVE Directory e DNS funzionino prima di ripristinare SAP e altri sistemi non SAP, per garantire il corretto funzionamento dell'applicazione. Per le linee guida sulla protezione di Active Directory e DNS, apprendere 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 carichi di lavoro SAP
In genere nei sistemi SAP NetWeaver distribuiti; i servizi centrali, il database e l'archiviazione condivisa (NFS/SMB) sono singoli punti 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 locali o catastrofi. Tuttavia, per proteggere le applicazioni SAP da situazioni di emergenza geografiche distribuite, è necessario implementare la strategia di ripristino di emergenza per tutti i componenti SAP.
Per i sistemi SAP in esecuzione in 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 | Elemento consigliato |
|---|---|
| Dispatcher Web SAP | Replicare una macchina virtuale con Azure Site Recovery |
| Servizi centrali SAP | Replicare una macchina virtuale con Azure Site Recovery |
| Server applicazioni SAP | Replicare una 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 ogni tipo di archiviazione |
Dispatcher Web SAP
Il componente SAP Web Dispatcher funziona come servizio di bilanciamento del carico per il traffico SAP tra server applicazioni SAP. Sono disponibili diverse opzioni per ottenere la disponibilità elevata del componente SAP Web Dispatcher nell'area primaria. Per altre informazioni su questa opzione, vedere Disponibilità elevata del dispatcher Web SAP e configurazione della disponibilità elevata del dispatcher Web SAP in Azure.
- Opzione 1: disponibilità elevata con 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, per SAP Web Dispatcher configurato usando l'opzione 1 nell'area primaria, è necessario apportare alcune modifiche aggiuntive dopo il failover per avere una configurazione a 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 l'accodamento e il server di messaggi, che è uno degli SPOF dell'applicazione SAP. In un sistema SAP può essere presente una sola istanza di questo tipo e può essere configurata per la disponibilità elevata. Leggere Disponibilità elevata per SAP Central Service per comprendere le diverse soluzioni a disponibilità elevata per il carico di lavoro SAP in Azure.
La configurazione della 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 esistono 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 simile a disponibilità elevata nell'area di ripristino di emergenza dopo un failover, è necessario prendere in considerazione altri punti. Questi includono la riconfigurazione del cluster, la certezza che le directory condivise SAP siano disponibili e la replica di macchine virtuali e dei relativi dischi gestiti nel sito di ripristino di emergenza con 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 SAP Web Dispatcher è stato configurato usando la soluzione cluster pacemaker, si applicherà anche una considerazione simile.
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. Sarà necessario creare un servizio di bilanciamento del carico interno separato nel sito di ripristino di emergenza in anticipo o dopo il failover. Se in anticipo si crea un servizio di bilanciamento del carico interno, 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 pacemaker non funzionerà automaticamente nelle macchine virtuali dopo il failover. Per consentire il funzionamento della soluzione, è necessaria una riconfigurazione aggiuntiva del cluster.
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 isolamento.
- Failover del cluster SAP ASCS/ERS HA con dispositivo SBD (usando il server di destinazione iSCSI) nell'area di ripristino di emergenza tramite Azure Site Recovery.
- Failover del cluster SAP ASCS HA (in sistema operativo Linux) nell'area di ripristino di emergenza tramite Azure Site Recovery.
Directory condivise SAP per Linux
La configurazione a disponibilità elevata della piattaforma SAP NetWeaver o ABAP usa il server di replica di accodamento per ottenere la ridondanza a livello di applicazione per il servizio di accodamento del sistema SAP con la 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 l'installazione, è necessario assicurarsi che i dati vengano 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 (ad esempio rsync) |
| NFS in ANF | Sì (replica tra aree) |
| Cluster NFS | Personalizzazione |
Suggerimento
È consigliabile distribuire uno dei servizi NFS propri di Azure, NFS in File di Azure o volumi NFS ANF, per l'archiviazione di dati condivisi in un sistema SAP a disponibilità elevata. Tenere presente che vengono evidenziate le architetture di riferimento SAP tramite cluster NFS.
Meccanismo di isolamento
Indipendentemente dal sistema operativo (SLES o RHEL) e dalla relativa versione, pacemaker richiede un meccanismo di isolamento valido affinché l'intera soluzione funzioni correttamente. In base al tipo di meccanismo di isolamento configurato nell'area primaria, è necessario assicurarsi che lo stesso meccanismo di isolamento sia configurato nel sito di ripristino di emergenza dopo il failover.
| Meccanismo di isolamento | Raccomandazione sul ripristino di emergenza tra aree |
|---|---|
| SBD con 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 isolamento di Azure | Abilitare identità del sistema gestito nelle macchine virtuali di ripristino di emergenza. Assegnare ruoli personalizzati. Aggiornare la risorsa agente di isolamento nel cluster. |
| SBD con disco condiviso di Azure* | Configurare il nuovo disco condiviso di Azure nell'area di ripristino di emergenza. Collegare il disco condiviso di Azure alle macchine virtuali di ripristino di emergenza dopo il failover. Configurare il dispositivo SBD del disco condiviso di Azure. |
*L'archiviazione con ridondanza della zona per il disco condiviso di Azure è disponibile in aree limitate.
Nota
È consigliabile avere lo stesso meccanismo di isolamento sia per l'area primaria che per l'area di ripristino di emergenza per semplificare il funzionamento e il failover. Non è consigliabile disporre di meccanismi di isolamento diversi 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 il ripristino di emergenza per i server applicazioni SAP, è possibile configurare Azure Site Recovery per ogni macchina virtuale del server applicazioni. Per le risorse di archiviazione condivise (file system di trasporto, file system di interfaccia dei dati) 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 Azure Site Recovery 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 linee guida del database corrispondenti. La tabella seguente mostra l'elenco dei database usati per i carichi di lavoro SAP e la raccomandazione di ripristino di emergenza corrispondente.
| Database | Raccomandazione sul 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 AlwaysOn |
| SAP ASE | ASE HADR Always On |
| SAP MaxDB | Database di standby |
Per una 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 backup di Azure, un servizio di backup basato sul cloud per acquisire 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 gli scenari e le distribuzioni di Backup di Azure, vedere Backup di Azure matrice di supporto.
| Servizi | Componente | supporto Backup di Azure |
|---|---|---|
| Calcolo | Macchine virtuali di Azure | Supportata |
| Storage | Dischi gestiti di Azure, inclusi i dischi condivisi | Supportata |
| Storage | Condivisione file di Azure - SMB (Standard o Premium) | Supportata |
| Storage | BLOB di Azure | Supportata |
| Storage | Condivisione file di Azure - NFS (Standard o Premium) | Non supportato |
| Storage | Azure NetApp Files | Non supportato |
| Database | Database SAP HANA nelle macchine virtuali di Azure | Supportata |
| Database | SQL Server in macchine virtuali di Azure | Supportata |
| 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 abilitate, è possibile ripristinare i dati del tipo di gestione supportato nell'area secondaria.
Il backup e il ripristino sono un approccio più tradizionale ottimizzato per i costi, 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.