Panoramica del ripristino di emergenza e linee guida sull'infrastruttura per il carico di lavoro SAP

  • Articolo

Molte organizzazioni che eseguono applicazioni aziendali critiche in Azure configurano sia la strategia di disponibilità elevata che ripristino di emergenza. Lo scopo della disponibilità elevata è aumentare il contratto di servizio dei sistemi aziendali eliminando singoli punti di errore nell'infrastruttura di sistema sottostante. Le tecnologie a disponibilità elevata riducono l'effetto di errori dell'infrastruttura non pianificati e contribuiscono alla manutenzione pianificata. Il ripristino di emergenza è definito come criteri, strumenti e procedure per consentire il ripristino o la continuazione di infrastrutture e sistemi tecnologici vitali in seguito a un disastro naturale o indotto dall'uomo geograficamente diffuso.

Per ottenere la disponibilità elevata per il carico di lavoro SAP in Azure, le macchine virtuali vengono in genere distribuite in un set di disponibilità, in zone di disponibilità o in un set di scalabilità flessibile per proteggere le applicazioni dalla manutenzione o dall'errore dell'infrastruttura all'interno dell'area. Tuttavia, la distribuzione non protegge le applicazioni da un'emergenza diffusa all'interno dell'area. Per proteggere le applicazioni da situazioni di emergenza a livello di area, è necessario implementare la strategia di ripristino di emergenza per le applicazioni. Il ripristino di emergenza è un approccio documentato e strutturato progettato per aiutare un'organizzazione nell'esecuzione dei processi di ripristino in risposta a un'emergenza e per proteggere o ridurre al minimo le interruzioni dei servizi IT e promuovere il ripristino.

Questo documento fornisce informazioni dettagliate sulla protezione dei carichi di lavoro SAP da catastrofi su larga scala implementando un approccio di ripristino di emergenza strutturato. I dettagli in questo documento vengono presentati a livello astratto, in base a diversi servizi e componenti SAP di Azure. La strategia di ripristino di emergenza esatta e l'ordine di ripristino per il carico di lavoro SAP devono essere testati, documentati e ottimizzati regolarmente. Inoltre, il documento è incentrato sulla strategia di ripristino di emergenza da Azure ad Azure per il carico di lavoro SAP.

Considerazioni generali sul piano di ripristino di emergenza

Il carico di lavoro SAP in Azure viene eseguito in macchine virtuali in combinazione con diversi servizi di Azure per distribuire livelli diversi (servizi centrali, server applicazioni, server di database) di una tipica applicazione SAP NetWeaver. In generale, è consigliabile pianificare una strategia di ripristino di emergenza per l'intero panorama IT in esecuzione in Azure, il che significa prendere in considerazione anche le applicazioni non SAP. La soluzione aziendale in esecuzione nei sistemi SAP potrebbe non essere eseguita nel suo complesso, se i servizi o gli asset dipendenti non vengono ripristinati nel sito di ripristino di emergenza. È quindi necessario avere un piano di ripristino di emergenza completo ben definito considerando tutti i componenti e i sistemi.

Per il ripristino di emergenza in Azure, le organizzazioni devono considerare scenari diversi che possono attivare il failover.

  • Disponibilità di applicazioni SAP o processi aziendali.
  • I servizi di Azure (ad esempio macchine virtuali, archiviazione, bilanciamento del carico e così via) non sono disponibili all'interno di un'area a causa di un errore diffuso.
  • Potenziali minacce e vulnerabilità all'applicazione (ad esempio, attacco DDoS a livello di applicazione)
  • Conformità aziendale richiedeva attività operative per testare la strategia di ripristino di emergenza (ad esempio, l'esercizio sugli errori di ripristino di emergenza da eseguire ogni anno in base alla conformità).

Per raggiungere l'obiettivo di ripristino per diversi scenari, l'organizzazione deve definire l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO) per il carico di lavoro in base ai requisiti aziendali. RTO descrive la quantità di tempo che l'applicazione può essere ridotta, in genere misurata in ore, minuti o secondi. Mentre RPO descrive la quantità di dati transazionali che è accettabile per le aziende per perdere per poter riprendere le normali operazioni. L'identificazione di RTO e RPO dell'azienda è fondamentale, in quanto consente di progettare la strategia di ripristino di emergenza in modo ottimale. I componenti (calcolo, archiviazione, database e così via) coinvolti nel carico di lavoro SAP vengono replicati nell'area di ripristino di emergenza usando tecniche diverse (servizi nativi di Azure, tecnologia di replica nativa del database, script personalizzati). Ogni tecnica fornisce un RPO diverso, che deve essere tenuto in considerazione durante la progettazione di una strategia di ripristino di emergenza. In Azure è possibile usare alcuni dei servizi nativi di Azure, ad esempio Azure Site Recovery, Backup di Azure che consentono di soddisfare RTO e RPO dei carichi di lavoro SAP. Fare riferimento al contratto di servizio di Azure Site Recovery e Backup di Azure per allinearsi in modo ottimale all'obiettivo RTO e all'obiettivo rpo.

Considerazioni sulla progettazione per il ripristino di emergenza in Azure

Quando si progetta una soluzione di ripristino di emergenza in Azure, è necessario prendere in considerazione diversi elementi. I principi e i concetti considerati per progettare soluzioni di ripristino di emergenza locali si applicano anche ad Azure. In Azure, tuttavia, la selezione dell'area è una parte fondamentale della strategia di progettazione per il ripristino di emergenza. Tenere quindi presente quanto segue quando si sceglie l'area di ripristino di emergenza in Azure.

  • I requisiti di conformità aziendali o normativi possono specificare un requisito di distanza tra un sito primario e quello di ripristino di emergenza. Un requisito di distanza consente di fornire disponibilità se si verifica una calamità naturale in una geografia più ampia. In questo caso, un'organizzazione può scegliere un'altra area di Azure come sito di ripristino di emergenza. Le aree di Azure sono spesso separate da una distanza elevata che potrebbe essere centinaia o persino migliaia di chilometri come nel Stati Uniti. A causa della distanza, la latenza del round trip di rete sarà superiore, che potrebbe comportare un RPO superiore.

  • I clienti che vogliono simulare la strategia di ripristino di emergenza della metropolitana locale in Azure possono usare le zone di disponibilità per il ripristino di emergenza. Tuttavia, la strategia di ripristino di emergenza da zona a zona potrebbe non avere requisiti di resilienza se si verifica un'emergenza naturale geograficamente diffusa.

  • In Azure ogni area è associata a un'altra area all'interno della stessa area geografica (ad eccezione del Brasile meridionale). Questo approccio consente la replica fornita dalla piattaforma delle risorse in tutta l'area. Il vantaggio della scelta dell'area abbinata è disponibile nel documento coppie di aree. Quando un'organizzazione sceglie di usare aree abbinate di Azure, è necessario considerare diversi punti aggiuntivi per un carico di lavoro SAP:

    • Non tutti i servizi di Azure offrono la replica tra aree nell'area abbinata.

    • I servizi e le funzionalità di Azure in aree di Azure abbinate potrebbero non essere simmetrici. Ad esempio, Azure NetApp Files, gli SKU delle macchine virtuali come le serie M disponibili nell'area primaria potrebbero non essere disponibili nell'area abbinata. Per verificare se il prodotto o i servizi di Azure è disponibile in un'area, vedere Prodotti Azure per area.

    • L'opzione GRS è disponibile per l'account di archiviazione con tipo di archiviazione standard che replica i dati nell'area abbinata. Tuttavia, l'archiviazione standard non è adatta per DBMS SAP o dischi dati virtuali.

    • Il servizio di backup di Azure usato per eseguire il backup di soluzioni supportate può replicare i backup solo tra aree abbinate. Per tutti gli altri dati, eseguire repliche personalizzate con funzionalità DBMS native, ad esempio SQL Server Always On, replica di sistema SAP HANA e altri servizi. Usare una combinazione di Azure Site Recovery, rsync o robocopy e di altri software di terze parti per il livello dell'applicazione SAP.

Informazioni di riferimento sulla distribuzione del carico di lavoro SAP

Dopo aver identificato un'area di ripristino di emergenza, è importante che l'ampiezza dei servizi di base di Azure (ad esempio rete, calcolo, archiviazione) configurata nell'area primaria sia disponibile e possa essere configurata nell'area di ripristino di emergenza. L'organizzazione deve sviluppare un modello di distribuzione di ripristino di emergenza per il carico di lavoro SAP. Il modello di distribuzione varia e deve essere allineato alle esigenze dell'organizzazione.

  • Distribuire il carico di lavoro SAP di produzione nell'area primaria e nel carico di lavoro non di produzione nell'area di ripristino di emergenza.
  • Distribuire tutto il carico di lavoro SAP (produzione e non produzione) nell'area primaria. L'area di ripristino di emergenza viene usata solo se è presente un failover.

L'architettura di riferimento seguente mostra il tipico sistema SAP NetWeaver in esecuzione in Azure insieme alla disponibilità elevata nell'area primaria. Il sito secondario riportato di seguito è il sito di ripristino di emergenza in cui i sistemi SAP verranno ripristinati dopo un evento di emergenza. Le aree di ripristino di emergenza e primarie fanno parte della stessa sottoscrizione. Per ottenere il ripristino di emergenza per il carico di lavoro SAP, è necessario identificare la strategia di ripristino per ogni livello SAP insieme ai diversi servizi di Azure usati dall'applicazione.

Le organizzazioni devono pianificare e progettare una strategia di ripristino di emergenza per l'intero panorama IT. In genere i sistemi SAP in esecuzione nell'ambiente di produzione sono integrati con diversi servizi e interfacce, ad esempio Active Directory, DNS, applicazioni di terze parti e così via. È quindi necessario includere anche i sistemi non SAP e altri servizi nella pianificazione del ripristino di emergenza. Questo documento è incentrato sulla pianificazione del ripristino per le applicazioni SAP. È tuttavia possibile espandere le dimensioni e l'ambito della pianificazione del ripristino di emergenza per i componenti dipendenti in base alle esigenze.

Disaster Recovery reference architecture for SAP workload

Componenti dell'infrastruttura della soluzione di ripristino di emergenza per il carico di lavoro SAP

Un carico di lavoro SAP in esecuzione in Azure usa diversi componenti dell'infrastruttura per eseguire una soluzione aziendale. Per pianificare il ripristino di emergenza per tale soluzione, è essenziale che tutti i componenti dell'infrastruttura configurati nell'area primaria siano disponibili e possano essere configurati anche nell'area di ripristino di emergenza. Quando si progetta una soluzione di ripristino di emergenza per il carico di lavoro SAP in Azure, è necessario considerare i componenti dell'infrastruttura seguenti.

  • Rete
  • Calcolo
  • Storage

Rete

  • ExpressRoute estende la rete locale nel cloud Microsoft tramite una connessione privata con l'aiuto di un provider di connettività. Nella progettazione dell'architettura di ripristino di emergenza, è necessario tenere conto della creazione di una connettività di rete back-end affidabile usando il circuito ExpressRoute con ridondanza geografica. È consigliabile configurare almeno un circuito ExpressRoute dall'ambiente locale all'area primaria. E gli altri devono connettersi all'area di ripristino di emergenza. Vedere l'articolo Progettazione di Azure ExpressRoute per il ripristino di emergenza, che descrive diversi scenari per progettare il ripristino di emergenza per ExpressRoute.

    Nota

    Valutare la possibilità di configurare una VPN da sito a sito (S2S) come backup di Azure ExpressRoute. Per altre informazioni, vedere Uso della VPN da sito a sito come backup per il peering privato di Azure ExpressRoute.

  • La rete virtuale e le subnet si estendono su tutte le zone di disponibilità in un'area. Per il ripristino di emergenza in due aree, è necessario configurare reti virtuali e subnet separate nell'area di ripristino di emergenza. Per altre informazioni sulla configurazione di rete nell'area di ripristino di emergenza, vedere Informazioni sulla rete nel ripristino di emergenza delle macchine virtuali di Azure.

  • Azure Load Balancer Standard fornisce elementi di rete per la progettazione a disponibilità elevata dei sistemi SAP. Per i sistemi in cluster, Load Balancer Standard fornisce l'indirizzo IP virtuale per il servizio cluster, ad esempio istanze e database ASCS/SCS in esecuzione nelle macchine virtuali. Per eseguire un sistema SAP a disponibilità elevata nel sito di ripristino di emergenza, è necessario creare un servizio di bilanciamento del carico separato e la configurazione del cluster deve essere modificata di conseguenza.

  • app Azure lication Gateway è un servizio di bilanciamento del carico del traffico Web. Con la funzionalità web application firewall , il servizio più adatto per esporre le applicazioni Web a Internet con una maggiore sicurezza. app Azure gateway può eseguire il servizio di client pubblici (Internet) o privati o entrambi, a seconda della configurazione. Dopo il failover, per accettare traffico HTTP in ingresso simile nell'area di ripristino di emergenza, è necessario configurare un gateway di app Azure lication separato nell'area di ripristino di emergenza.

  • Poiché i componenti di rete (ad esempio rete virtuale, firewall e così via) vengono creati separatamente nell'area di ripristino di emergenza, è necessario assicurarsi che il carico di lavoro SAP nell'area di ripristino di emergenza sia adattato alle modifiche di rete, ad esempio l'aggiornamento DNS, il firewall e così via.

  • Le reti virtuali in entrambe le aree sono indipendenti e per stabilire la comunicazione tra le due aree, è necessario abilitare il peering di reti virtuali tra le due aree.

Macchine virtuali

  • In Azure, componenti diversi di un singolo sistema SAP vengono eseguiti in macchine virtuali con tipi di SKU diversi. Per il ripristino di emergenza, la protezione di un'applicazione (SAP NetWeaver e non SAP) in esecuzione in macchine virtuali di Azure può essere abilitata replicando i componenti usando Azure Site Recovery in un'altra area o zona di Azure. Con Azure Site Recovery, le macchine virtuali di Azure vengono replicate continuamente dal sito primario al sito di ripristino di emergenza. A seconda dell'area di ripristino di emergenza di Azure selezionata, il tipo di SKU della macchina virtuale potrebbe non essere disponibile nel sito di ripristino di emergenza. È necessario assicurarsi che i tipi di SKU di macchina virtuale necessari siano disponibili anche nell'area DR di Azure. Controllare i prodotti Azure per area per verificare se il tipo di SKU della famiglia di macchine virtuali richiesto è disponibile o meno.

    Importante

    Se il sistema SAP è configurato con un set di scalabilità flessibile con FD=1, è necessario usare PowerShell per configurare Azure Site Recovery per il ripristino di emergenza. Attualmente, è l'unico metodo disponibile per configurare il ripristino di emergenza per le macchine virtuali distribuite nel set di scalabilità.

  • Per i database in esecuzione in macchine virtuali di Azure, è consigliabile usare la tecnologia di replica di database nativa per sincronizzare i dati con il sito di ripristino di emergenza. Le macchine virtuali di grandi dimensioni in cui sono in esecuzione i database potrebbero non essere disponibili in tutte le aree. Se si usano zone di disponibilità per il ripristino di emergenza, è necessario verificare che i rispettivi SKU di macchina virtuale siano disponibili nella zona del sito di ripristino di emergenza.

    Nota

    Non è consigliabile usare Azure Site Recovery per i database, perché non garantisce la coerenza del database e presenta limitazioni di varianza dei dati.

  • Con le applicazioni di produzione in esecuzione nell'area primaria in qualsiasi momento, le istanze di riserva vengono in genere usate per risparmiare sui costi di Azure. Se si usano istanze riservate, è necessario iscriversi per un impegno di 1 anno o di 3 anni che potrebbe non essere conveniente per il sito di ripristino di emergenza. Anche la configurazione di Azure Site Recovery non garantisce la capacità dello SKU di macchina virtuale necessario durante il failover. Per assicurarsi che la capacità dello SKU della macchina virtuale sia disponibile, è possibile prendere in considerazione un'opzione per abilitare la prenotazione della capacità su richiesta. Riserva capacità di calcolo in un'area di Azure o in una zona di disponibilità di Azure per qualsiasi periodo di tempo senza impegno. Azure Site Recovery è integrato con la prenotazione di capacità su richiesta. Con questa integrazione, è possibile usare la potenza della prenotazione della capacità con Azure Site Recovery per riservare la capacità di calcolo nel sito di ripristino di emergenza e garantire i failover. Per altre informazioni, vedere Limitazioni e restrizioni per la prenotazione della capacità su richiesta.

  • Una sottoscrizione di Azure ha quote per le famiglie di macchine virtuali (ad esempio, famiglia Mv2) e altre risorse. A volte le organizzazioni vogliono usare una sottoscrizione di Azure diversa per il ripristino di emergenza. Ogni sottoscrizione (primaria e ripristino di emergenza) può avere quote diverse assegnate per ogni famiglia di macchine virtuali. Assicurarsi che la sottoscrizione usata per il sito di ripristino di emergenza disponga di quote di calcolo sufficienti.

Storage

  • Quando si abilita Azure Site Recovery per configurare il ripristino di emergenza, il sistema operativo e i dischi dati locali collegati alle macchine virtuali vengono replicati nel sito di ripristino di emergenza. Durante la replica, le scritture su disco della macchina virtuale vengono inviate a un account di archiviazione della cache nell'area di origine. I dati vengono inviati da questo account all'area di destinazione e vengono generati i punti di ripristino dai dati. Quando si esegue il failover di una macchina virtuale durante il ripristino di emergenza, viene usato un punto di ripristino per ripristinare la macchina virtuale nell'area di destinazione. Azure Site Recovery, tuttavia, non supporta tutti i tipi di archiviazione disponibili in Azure. Per altre informazioni, vedere Matrice di supporto di Azure Site Recovery per le risorse di archiviazione.

  • Oltre ai dischi dati gestiti di Azure collegati alle macchine virtuali, vengono usate diverse soluzioni di archiviazione native di Azure per eseguire l'applicazione SAP in Azure. L'approccio di ripristino di emergenza per ogni soluzione di archiviazione di Azure può variare, in quanto non tutti i servizi di archiviazione disponibili in Azure sono supportati con Azure Site Recovery. Di seguito è riportato l'elenco del tipo di archiviazione usato in genere per il carico di lavoro SAP.

    Tipo di archiviazione Raccomandazione sulla strategia di ripristino di emergenza
    Disco gestito Azure Site Recovery
    NFS in file di Azure (archiviazione con ridondanza locale o archiviazione con ridondanza della zona) Script personalizzato per replicare i dati tra due siti (ad esempio, rsync)
    NFS in Azure NetApp Files Usare la replica tra aree dei volumi di Azure NetApp Files
    Disco condiviso di Azure (archiviazione con ridondanza locale o archiviazione con ridondanza della zona) Soluzione personalizzata per replicare i dati tra due siti
    SMB in file di Azure (archiviazione con ridondanza locale o archiviazione con ridondanza della zona) Usare RoboCopy per copiare i file tra due siti
    SMB in Azure NetApp Files Usare la replica tra aree dei volumi di Azure NetApp Files

  • Per soluzioni di archiviazione personalizzate come il cluster NFS, è necessario assicurarsi che sia attiva la strategia di ripristino di emergenza appropriata.

  • Diversi servizi di archiviazione di Azure nativi (ad esempio File di Azure, Azure NetApp Files, disco condiviso di Azure) potrebbero non essere disponibili in tutte le aree. Per avere una configurazione SAP simile nell'area di ripristino di emergenza dopo il failover, assicurarsi che il rispettivo servizio di archiviazione sia disponibile nel sito di ripristino di emergenza. Per altre informazioni, vedere Prodotti Azure per area.

  • Se si usano zone di disponibilità per il ripristino di emergenza, tenere presente quanto segue:

    • La funzionalità Azure NetApp Files non è ancora in grado di riconoscere la zona. Attualmente la funzionalità Azure NetApp Files non viene distribuita in tutte le zone di disponibilità in un'area di Azure. È quindi possibile che il servizio Azure NetApp Files non sia disponibile nella zona di disponibilità scelta per la strategia di ripristino di emergenza.
    • La replica tra aree dei volumi di Azure NetApp File è disponibile solo in coppie di aree fisse, non tra zone.

  • Se è stata configurata l'archiviazione con l'integrazione di Active Directory, è necessario eseguire anche un'installazione simile nell'account di archiviazione del sito di ripristino di emergenza.

  • I dischi condivisi di Azure richiedono software cluster come Windows Server Failover Cluster (WSFC) che gestisce la comunicazione dei nodi del cluster e il blocco di scrittura. Pertanto, per avere una strategia di ripristino di emergenza per il disco condiviso di Azure, è necessario che anche il disco condiviso sia gestito dal software del cluster nel sito di ripristino di emergenza. È quindi possibile usare lo script per copiare dati dal disco condiviso collegato a un cluster nell'area primaria al disco condiviso collegato a un altro cluster nell'area di ripristino di emergenza.

Passaggi successivi