Resilienza per i deployment SAP su Google Cloud

Questo documento descrive le considerazioni di progettazione che ti aiutano a eseguire sistemi SAP resilienti e affidabili su Google Cloud.

L'infrastruttura e il software possono avere dei guasti. Le cause e l'ambito di questi errori richiedono che i deployment dei sistemi SAP seguano determinati principi per poter usufruire al meglio dell' Google Cloud infrastruttura. La combinazione di opzioni di infrastruttura con architetture di implementazione del software SAP resilienti garantisce l'integrità e la protezione dei dati da perdita di dati o mancata disponibilità del sistema.

Opzioni di resilienza e affidabilità

Puoi implementare sistemi resilienti e solidi utilizzando le funzionalità sia nei livelli di infrastruttura sia in quelli di applicazione per assorbire gli errori o consentire il recupero dagli errori. Per garantire resilienza e affidabilità per le implementazioni del sistema SAP su Google Cloud, ti consigliamo di prendere in considerazione le seguenti opzioni:

  • Resilienza della piattaforma: Google Cloud i servizi e i prodotti sono progettati tenendo conto della resilienza e dispongono di ridondanza integrata per raggiungere gli accordi sul livello del servizio pubblicati. Quando esegui il deployment dei sistemi SAP in conformità con le Google Cloud linee guida e con le best practice, i meccanismi della piattaforma di base aumentano la resilienza del sistema SAP. In questo modo, puoi continuare le operazioni aziendali in caso di guasto o calamità.
  • Alta disponibilità (HA): utilizzando configurazioni di infrastruttura e software che supportano l'HA, puoi attivare il recupero automatico del sistema con interruzioni minime. Questo utilizzo garantisce inoltre che sia richiesto un intervento minimo nel caso in cui si verifichino errori in parti dell'infrastruttura o del software di applicazione sottostante. L'alta disponibilità è progettata per proteggere il sistema da errori o degradi di singoli componenti grazie alla ridondanza dei componenti di sistema.
  • Ripristino di emergenza (RE): il RE consente di ripristinare le operazioni aziendali in caso di guasto causato da un disastro. Il disaster recovery prevede il trasferimento dei servizi e delle applicazioni in una sede secondaria fisicamente isolata da cui è possibile continuare le operazioni. I sistemi di RE vanno oltre un singolo componente o un singolo errore di servizio per mitigare eventi meno frequenti, ma di maggiore impatto. Possono essere inclusi eventi regionali come calamità naturali, interruzioni dell'alimentazione elettrica ed eventi localizzati come incendi o errori umani. Le disposizioni relative al RE includono quanto segue:
    • Replica dei dati:puoi utilizzare la replica a livello di software o di archiviazione per assicurarti che i dati vengano trasferiti in una posizione secondaria con una potenziale perdita minima di dati.
    • Backup:puoi recuperare un sistema o un database utilizzando i backup archiviati separatamente dall'archiviazione dei dati principale. Ciò può includere l'utilizzo di snapshot o backup caricati in Cloud Storage, a condizione che gli snapshot o i backup siano archiviati in una regione diversa da quella in cui è stato eseguito il deployment del sistema.

Poiché queste opzioni sono complementari, puoi combinare aspetti di ciascuna per aumentare la resilienza all'interno dei tuoi implementazioni SAP. Le opzioni selezionate influiscono sul Recovery Time Objective (RTO) e sul Recovery Point Objective (RPO) del deployment. Pertanto, devi anche valutare il costo di queste opzioni rispetto al loro impatto sulla resilienza del sistema e sulla continuità aziendale. Ti consigliamo di valutare attentamente tutte le opzioni disponibili e di implementarle in base ai tuoi obiettivi di ripristino di emergenza.

La sezione seguente descrive un esempio di implementazione SAP e l'impatto che puoi prevedere su resilienza e affidabilità da diverse configurazioni di HA e RE.

Scenari di esempio

Prendi in considerazione un deployment di SAP S/4HANA con scalabilità verticale su Google Cloud. La tabella seguente presenta esempi di configurazioni HA e RE che possono essere applicate a questo deployment e il relativo impatto previsto su dimensioni di resilienza e affidabilità del sistema come disponibilità, RTO e RPO.

Configurazione HA o RE Dimensione resilienza o affidabilità Previsione
Una configurazione ad alta disponibilità. Considera quanto segue:
  • us-central1 è la regione principale.
  • Le istanze X4 vengono implementate in due zone diverse, ad esempio us-central1-a e us-central1-b.
 Disponibilità
  • 99,99% o superiore per l'intero sistema.
  • 99,9% o superiore per ogni singola istanza.
Una configurazione di RE che utilizza la replica del sistema SAP HANA asincrona in un sistema di RE completamente residente in memoria. Considera quanto segue:
  • us-central1 è la località principale.
  • us-east4 è la località di RE ed esegue un'istanza X4 delle stesse dimensioni della località principale.
  • I dati vengono precaricati nell'istanza X4 che esegue SAP HANA nella sede di RE.
  • Nella località di RE, i server delle applicazioni sono stati sottoposti a provisioning o hai acquistato prenotazioni per questi server. Nota 1
 Tempo di recupero Alcune ore, che potrebbero includere il tempo necessario per la propagazione del DNS ai sistemi client.
Punto di recupero Minuti, rispetto all'ultima replica asincrona.
Una configurazione di RE che utilizza i backup con l'infrastruttura pre-provisionata Nota 1. Prendiamo in considerazione un sistema che utilizza il backup e il recupero basati su Backint. Tempo di recupero È ora di recuperare il database dal backup. Nota 2.
Punto di recupero Fino all'ultimo punto nel backup o nello snapshot dei log di SAP HANA.
Una configurazione di RE che utilizza i backup senza un'infrastruttura preprovisionata Nota 3. Prendiamo in considerazione un sistema che utilizza il backup e il recupero basati su Backint. Tempo di recupero Diversi giorni per il provisioning dell'infrastruttura (Nota 4) e per recuperare i dati dal backup (Nota 3).
Punto di recupero Fino all'ultimo punto nel backup o nello snapshot dei log di SAP HANA.

Note relative alla tabella:

  1. Puoi implementare la soluzione di DR senza pre-provisioning dell'infrastruttura richiesta prenotando in anticipo le risorse necessarie. In questo modo puoi assicurarti la disponibilità delle risorse necessarie quando devi attivare la soluzione di RE a causa di un disastro nella sede principale. Per ulteriori informazioni, consulta la pagina Prenotazioni di risorse di zona di Compute Engine.

  2. Il tempo di esecuzione di un'operazione di recupero dipende molto dalla soluzione di backup utilizzata e dalle dimensioni dei file di backup. Per determinare le tempistiche esatte per le dimensioni e i tassi di variazione del database, devi valutare la velocità di recupero della soluzione di backup che utilizzi, ad esempio Backint o snapshot del disco.

  3. Il deployment di una soluzione di RE senza preprovisioning o prenotazione delle risorse richieste può portare a situazioni in cui le risorse richieste non sono disponibili. Ciò può aumentare il tempo di recupero del deployment, che a sua volta influisce sulle operazioni aziendali.

  4. Per tipi di macchine come X4, che non sono disponibili on demand e devono essere ordinati, potrebbero essere necessarie diverse settimane di tempo di risposta senza una prenotazione anticipata della capacità.

Considera le informazioni riportate nella tabella precedente come supplementari a qualsiasi progettazione esistente e ai piani di disaster recovery ricavati dalle linee guida del settore. Per ulteriori informazioni, consulta le seguenti risorse:

Consigli per implementazioni resilienti

Le seguenti sezioni forniscono una panoramica delle configurazioni HA e DR che consigliamo per il deployment di carichi di lavoro SAP resilienti e affidabili suGoogle Cloud.

Sebbene sia vivamente consigliato di implementare questi consigli per i carichi di lavoro SAP che ospitano operazioni di produzione fondamentali per l'attività, puoi anche implementarli per i sistemi SAP non di produzione in cui un'interruzione prolungata può avere un impatto negativo sulle operazioni aziendali.

Per informazioni sui consigli, consulta le sezioni seguenti:

Consigli per l'alta disponibilità

  • Utilizza almeno due zone diverse all'interno della stessa regione per il deployment delle istanze.
  • Rimuovi i single point of failure. Puoi farlo aggiungendo risorse aggiuntive che forniscono resilienza e ridondanza ai servizi o ai componenti dell'applicazione difettosi in caso di errore.
  • Utilizza servizi regionali con ridondanza integrata. Ad esempio, utilizza Filestore Enterprise per l'hosting di file condivisi e i bilanciatori del carico forniti da Cloud Load Balancing.
  • Utilizza l'automazione per il failover. L'Automation limita la necessità di interventi manuali in caso di errore e riduce l'impatto sulle operazioni aziendali. Ad esempio, puoi utilizzare un gestore di cluster Linux come Pacemaker.

  • Utilizza percorsi di rete ridondanti. Assicurati di avere una connettività ridondante nella tua regione principale. A seconda dei requisiti di connettività, sono disponibili diverse opzioni. Per ulteriori informazioni, consulta la sezione sulla Google Cloud connettività.

    Per raggiungere una disponibilità del 99,99% per le connessioni alle regioni Google Cloud, consigliamo di configurare più connessioni. Per ulteriori informazioni, consulta la sezione Stabilire una disponibilità del 99,99% per Dedicated Interconnect.

  • Abilita i criteri di migrazione live e di riavvio automatico sulle risorse Compute Engine:

    • Per mantenere le istanze di calcolo online durante gli eventi di manutenzione avviati da Google, puoi utilizzare la migrazione live impostando la proprietà onHostMaintenance con l'opzione MIGRATE (Predefinito). Per le istanze di calcolo che non supportano la migrazione live, imposta la proprietà automaticRestart su true (predefinito). In questo modo Google può riavviare qualsiasi istanza che non risponde. Per saperne di più, consulta Informazioni sugli eventi host.
    • Per le istanze di calcolo che non supportano la migrazione live o la manutenzione pianificata, sono disponibili controlli avanzati per la manutenzione. Per maggiori informazioni, consulta Attivare il controllo di manutenzione avanzato per i nodi single-tenant.

  • Prima del lancio, testa il failover nel tuo ambiente.

Consigli per il ripristino di emergenza

  • Ospitata la soluzione di DR in una località diversa da quella principale. Per evitare che la soluzione di DR venga interessata dallo stesso evento del sistema principale, assicurati che i due siano ospitati in località diverse.

    Idealmente, la località di DR deve essere in un'altra regione. Tuttavia, se l'utilizzo di una seconda regione non è una buona opzione per problemi di residenza o sovranità dei dati, contatta il team Google Cloud Vendita per discutere di altre opzioni disponibili.

    Il seguente diagramma mostra l'architettura di alto livello di un deployment SAP HANA su Google Cloud con le seguenti disposizioni di HA e RE:

    • Per garantire l'HA, il sistema principale ha due nodi di cui viene eseguito il deployment in zone diverse all'interno della stessa regione.
    • Per garantire la resilienza, i sistemi principali e di RE sono ospitati in regioni diverse, con replica asincrona.

    Diagramma di architettura di alto livello per SAP HANA su Google Cloud con alta disponibilità e ripristino di emergenza.

  • Assicurati che la capacità nella località di RE sia adeguata.

    • Decidi se il sistema di RE deve funzionare con la stessa capacità del sistema principale o con una capacità ridotta. Per i database come SAP HANA, la località di RE deve disporre di risorse sufficienti per gestire in modo produttivo il workload SAP.
    • Inoltre, controlla in anticipo che le risorse richieste siano disponibili nella località del tuo RP. Per garantire la disponibilità delle risorse, puoi eseguirne il provisioning nella località di RE o acquistare le prenotazioni in anticipo. L'acquisto di prenotazioni ti consente di evitare scenari in cui, dopo un errore, le risorse non sono disponibili perché sono state allocate ad altri clienti. Google CloudCiò è particolarmente importante per i tipi di istanze di calcolo più grandi, come M2 o X4. Per informazioni sulle prenotazioni, consulta la pagina relativa alle prenotazioni di risorse di zona di Compute Engine.

    Per ottenere una maggiore efficienza in termini di costi, l'infrastruttura nella località di RE può essere utilizzata per i carichi di lavoro non di produzione e passare a servire il carico di lavoro di produzione durante un evento di RE. Tuttavia, questo comporta un aumento del tempo di recupero.

  • Convalida la connettività alla tua sede RE DR. Come per i percorsi di rete ridondanti per la tua sede principale, ti consigliamo di aggiungere altre opzioni di riserva come Cloud VPN.

  • Identifica gli indicatori che possono essere utilizzati per identificare un disastro. Questi indicatori aiutano a decidere quando attivare la soluzione di RE. Di seguito sono riportati alcuni esempi di indicatori di questo tipo:

    • Informazioni sull'integrità dei Google Cloud servizi da Google Cloud integrità del servizio.
    • Perdita completa della disponibilità dell'istanza segnalata da Cloud Monitoring, come configurato per i tuoi progetti Google Cloud.
    • Comunicazione dell'Assistenza clienti Google Cloud o del rappresentante del tuo accountGoogle Cloud , che fornisce informazioni su interruzioni e potenziali tempi di risoluzione.
    • Danni logici al database determinati dagli utenti o dagli amministratori del sistema SAP, che non possono essere risolti dai meccanismi di HA.

  • Testa regolarmente la soluzione RE DR. Assicurati che la tua soluzione funzioni in caso di calamità. Ciò può influire sulle tue operazioni quotidiane. Se le tue operazioni lo consentono, valuta la possibilità di operare in modo simmetrico nelle sedi principali e secondarie e di ruotare le operazioni tra le due ogni 3-6 mesi.

  • Utilizza la replica per ottenere il punto di ripristino migliore. La replica fornisce una versione quasi in tempo reale del tuo sito principale sul sito di RE. Sono disponibili le seguenti opzioni di replica, a seconda della progettazione del tuo carico di lavoro SAP:

    • Replica a livello di database tramite meccanismi come la replica di sistema SAP HANA, che esegue la replica a livello logico tra il sito principale e il sito di RE.
    • Replica a livello di archiviazione tramite meccanismi come la replica asincrona del disco permanente, che esegue la replica a livello di archiviazione a blocchi. A seconda dell'opzione di archiviazione utilizzata dal tuo carico di lavoro SAP, le opzioni di replica a livello di archiviazione disponibili sono diverse.

    Assicurati di monitorare la replica utilizzando uno strumento appropriato, ad esempio SAP HANA Cockpit. In questo modo puoi verificare che il tuo carico di lavoro SAP sia stato completamente replicato prima che la soluzione di RE venga attivata in caso di evento di RE.

  • Utilizza i backup dei dati per garantire il recupero point-in-time.

    • Per creare ridondanza, utilizza più posizioni di archiviazione per archiviare i backup. Ad esempio:
      • Durante la creazione di un backup utilizzando la funzionalità Backint dell'agente per SAP diGoogle Cloud, utilizza una posizione del bucket con due regioni o più regioni. Per ulteriori informazioni, consulta Creare bucket Cloud Storage.
      • Durante la creazione di un backup utilizzando la funzionalità di snapshot del disco dell'agente, utilizza Cloud Storage multi-regione o dual-regione. Per informazioni sulle località dei bucket Cloud Storage, consulta Località dei bucket.
    • Utilizza i backup incrementali o differenziali, che possono includere la memorizzazione degli snapshot su Google Cloud.
    • Monitora i backup per assicurarti che vengano creati correttamente in base alla tua strategia di backup. Per una soluzione completa per la protezione dei dati, ti consigliamo di utilizzare il servizio di backup e RE di Google Cloud.
    • Testa periodicamente i backup per assicurarti che siano recuperabili in caso di disastro e controlla il tempo necessario per recuperare il sistema o il database. Ti consigliamo di testare il recupero una volta ogni ciclo di backup, che solitamente dura 28 giorni.
    • Proteggi i tuoi backup come faresti con il sistema principale, ad esempio utilizzando le impostazioni di conservazione dello spazio di archiviazione e le chiavi di crittografia.

Altri consigli

  • Valuta il costo delle configurazioni HA e RE rispetto all'impatto che hanno sui seguenti aspetti della tua attività:
    • Potenziale tempo di inattività nelle operazioni e nelle transazioni commerciali.
    • Potenziale perdita di dati che comporta la perdita della fiducia di clienti, fornitori o vendite o errori di conformità.
  • Tutte le attività hanno considerazioni specifiche. Se la tua situazione particolare richiede una soluzione più personalizzata, non esitare a contattare il team Google Cloud Vendite.

Passaggi successivi