Resilienza per i deployment SAP su Google Cloud

Questo documento descrive le considerazioni relative alla progettazione per aiutarti a eseguire attività resilienti sistemi SAP 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'infrastruttura Google Cloud. Combinazione di infrastruttura con architetture di deployment di software SAP resilienti Garantisce l'integrità dei dati e la protezione da perdite di dati o dal sistema indisponibilità.

Opzioni di resilienza e affidabilità

Puoi eseguire il deployment di sistemi resilienti e solidi utilizzando le funzionalità in e applicazioni per assorbire gli errori o consentire in caso di errori. Per garantire la resilienza e l'affidabilità dei deployment dei sistemi SAP su Google Cloud, ti consigliamo di prendere in considerazione le seguenti opzioni:

  • Resilienza della piattaforma: i servizi e i prodotti Google Cloud sono progettati con particolare attenzione alla resilienza e alla ridondanza integrata per raggiungere Accordi sul livello del servizio. Quando esegui il deployment dei sistemi SAP in conformità con le linee guida e le best practice di Google Cloud, 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 da parte tua in caso di 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 ripristino di emergenza prevede il trasferimento dei servizi e delle applicazioni in una sede secondaria fisicamente isolata da cui è possibile continuare le operazioni. I sistemi di RE estendono al di là del guasto di un singolo componente o servizio per mitigare meno frequenti di eventi di maggiore impatto. Possono essere inclusi eventi regionali come disastri, perdita della rete elettrica ed eventi localizzati quali incendi o errori umani. Le disposizioni di 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 disaster recovery.

La seguente sezione descrive un esempio di deployment SAP e l'impatto che che ci si può aspettare da diverse configurazioni HA e RE sulla sua resilienza l'affidabilità.

Scenari di esempio

Valuta un deployment SAP S/4HANA con scale up su Google Cloud. Le seguenti presenta configurazioni HA e RE di esempio che possono essere applicate deployment e il loro impatto previsto su resilienza e affidabilità del sistema come disponibilità, RTO e RPO.

Configurazione HA o DR 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 asincrona di sistema SAP HANA su un completamente residente in memoria. Considera quanto segue:
  • us-central1 è la località principale.
  • us-east4 è la località di DR 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, viene eseguito il provisioning dei server delle applicazioni che hai acquistato. 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. Prendi in considerazione un sistema che utilizzi Backup e ripristino basati su Backint. Tempo di recupero Tempo per 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 infrastruttura preprovisionata Nota 3. Prendi in considerazione un sistema che utilizzi Backup e ripristino 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 ripristino All'ultimo momento nello snapshot o nel backup dei log SAP HANA.

Note tabella:

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

  2. Il tempo di esecuzione di un ripristino dipende molto dalla soluzione di backup utilizzata e dalle dimensioni 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. Deployment di una soluzione di RE senza il pre-provisioning o la prenotazione delle risorse richieste possono determinare 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 macchina come X4, che non sono disponibili on demand e da ordinare, potrebbero essere necessarie diverse settimane senza una prenotazione di capacità preventiva.

Considera le informazioni presentate nella tabella precedente come supplementari alla eventuali progetti e piani di ripristino di emergenza esistenti ottenuti dall'industria linee guida. Per ulteriori informazioni, consulta le seguenti risorse:

Suggerimenti per i deployment resilienti

Le sezioni seguenti forniscono una panoramica delle configurazioni HA e DR che consigliamo per il deployment di carichi di lavoro SAP resilienti e affidabili su Google 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 suggerimenti, consulta le seguenti sezioni:

Suggerimenti per l'alta disponibilità

  • Usa almeno due zone diverse all'interno della stessa regione per il deployment di Compute Engine.
  • 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.
  • Usa l'automazione per il failover. L'automazione limita la necessità di intervento manuale 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, vedi Connettività di Google Cloud.

    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.

  • Attiva 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 in tempo reale 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 diventi 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 le informazioni, vedi Abilita 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 ripristino di emergenza in una località diversa da quella principale. A evitare che la tua soluzione di RE venga influenzata dallo stesso evento dell'istanza principale di sistema, accertati 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 motivi di residenza o sovranità dei dati, contatta il team di vendita di Google Cloud per discutere di altre opzioni disponibili.

    Il seguente diagramma mostra l'architettura di alto livello per un'istanza SAP HANA il deployment su Google Cloud con le seguenti disposizioni di alta disponibilità 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 ripristino di emergenza 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.

  • Garantire una capacità adeguata nel luogo di RE.

    • Decidi se il tuo sistema di RE deve funzionare alla stessa capacità del o a una capacità ridotta. Per database come SAP HANA, la tua sede di RE deve disporre di risorse sufficienti per carico di lavoro SAP.
    • Inoltre, verifica in anticipo che le risorse richieste siano disponibili nel tuo posizione di RE. Per garantire la disponibilità delle risorse, puoi eseguirne il provisioning presso la sede di RE o acquistare 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 Cloud. Ciò è particolarmente importante per i tipi di istanze di calcolo più grandi come M2 o X4. Per informazioni sulle prenotazioni, consulta Prenotazioni delle risorse di zona Compute Engine.

    Per ottenere una maggiore efficienza in termini di costi, l'infrastruttura nella località di DR 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 DR. Tuttavia, questo comporta un aumento del tempo di recupero.

  • Convalida la connettività alla tua sede di DR. Come per la rete ridondante percorsi verso la tua sede principale, valuta la possibilità 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. La Ecco alcuni esempi di indicatori di questo tipo:

    • Informazioni sull'integrità dei servizi Google Cloud da Integrità dei servizi Google Cloud.
    • 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 l'account Google Cloud, che offre consulenze 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 tua soluzione di RE. Assicurati che la soluzione funzioni nel caso di un disastro. Ciò può influire sulle tue operazioni quotidiane. Se le tue operazioni consentire, quindi valuta la possibilità di operare in modo simmetrico rispetto ai nodi principali e secondari località e alternare le operazioni ogni 3-6 mesi.

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

    • Replica a livello di database sfruttando meccanismi come Replica di sistema SAP HANA, che si replica a livello logico tra il sito primario e quello di RE.
    • Replica a livello di archiviazione sfruttando meccanismi quali Replica asincrona PD, che viene replicato a livello di archiviazione a blocchi. In base all'opzione di archiviazione utilizzate dal carico di lavoro SAP, le opzioni di replica a livello di archiviazione differiscono.

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

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

    • Per creare la ridondanza, utilizza più posizioni di archiviazione per archiviare i backup. Ad esempio:
      • Durante la creazione di un backup mediante la funzionalità Backint di di Google Cloud per SAP, utilizza una località di bucket a due o più regioni. Per ulteriori informazioni, consulta Creare bucket Cloud Storage.
      • Durante la creazione di un backup utilizzando Istantanea del disco funzionalità dell'agente, utilizza Cloud Storage multiregionale o doppia. Per informazioni sulle località dei bucket Cloud Storage, Località dei bucket.
    • Utilizza backup incrementali o differenziali, che possono includere l'archiviazione di snapshot su Google Cloud.
    • Monitora i tuoi backup per assicurarti che vengano creati correttamente in in base alla tua strategia di backup. Per una soluzione completa di 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 necessità di un'emergenza e rivedere quanto tempo ci vuole per ripristinare il sistema per configurare un 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 DR 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 con conseguente perdita di fiducia da parte di clienti, fornitori o vendite o mancata conformità.
  • Tutte le attività hanno considerazioni specifiche. Se la tua situazione particolare richiede una soluzione più personalizzata, non esitare a contattare il team di vendita di Google Cloud.

Passaggi successivi