IBM Cloud Introduzione al VPC

Un VPC è un'offerta di cloud pubblico che un'azienda utilizza per creare il proprio ambiente di elaborazione privato simile a un cloud su un'infrastruttura di cloud pubblico condivisa. Le VPC consentono alle aziende di definire e controllare una rete virtuale che è logicamente isolata da tutti gli altri tenant del cloud pubblico, creando un luogo privato e sicuro sul cloud pubblico.

Immaginate che l'infrastruttura di un cloud provider sia un condominio residenziale e che al suo interno vivano più famiglie. Essere un affittuario di cloud pubblico è come condividere un appartamento con alcuni coinquilini. Al contrario, avere un VPC è come avere un condominio privato; nessun altro ha la chiave e nessuno può entrare nello spazio senza il vostro permesso. L'isolamento logico di una VPC viene implementato utilizzando funzioni di rete virtuali e caratteristiche di sicurezza che consentono al cliente aziendale di controllare in modo granulare quali indirizzi IP o applicazioni possono accedere a determinate risorse. È analogo ai controlli "solo amici" o "pubblico/privato" sugli account dei social media utilizzati per limitare chi può o non può vedere i vostri post altrimenti pubblici.

Con IBM Cloud VPC, è possibile utilizzare l'interfaccia utente, la CLI e l'API per eseguire il provisioning manuale delle istanze di server virtuale per VPC con prestazioni di rete elevate. L'infrastruttura VPC contiene diverse offerte Infrastructure-as-a-Service ( IaaS ), tra cui Virtual Servers for VPC. Utilizzate le seguenti informazioni per comprendere un semplice caso d'uso per la pianificazione, la creazione e la configurazione delle risorse per la vostra VPC, e scoprite altre panoramiche sulle VPC ed esercitazioni sulle VPC. Per ulteriori informazioni su VPC, vedere Per iniziare con Virtual Private Cloud(VPC).

SAP su IBM Cloud

SAP NetWeaver è la base fondamentale degli stack tecnologici di SAP ed è la piattaforma utilizzata per le applicazioni ABAP e Java. Il sistema SAP può essere installato e configurato in IBM Cloud per diversi tipi di sistemi e database.

Per ulteriori informazioni sulle architetture di sistema SAP su IBM Cloud VPC, consultare le architetture di riferimento dell'infrastruttura per SAP per ogni tipo di database supportato. Ad esempio, SAP NetWeaver 7.x su UNIX con HANA su IBM Cloud VPC è l'architettura di riferimento dedicata per questa soluzione SAP.

Dove eseguire gli script

Gli script vengono eseguiti dal Deployment Server perché quest'ultimo ha Terraform e Ansible già installati. I kit SAP devono essere scaricati nella memoria temporanea assegnata sul Deployment Server. Ansible i playbook installano i kit in base alla posizione dei kit specificati nei file di configurazione.

Prerequisiti

• Prima di distribuire una qualsiasi delle soluzioni automatizzate di SAP su IBM Cloud VPC, è necessario creare un server di distribuzione (Bastion Server) nella regione scelta. Il server di distribuzione (Bastion Server) viene utilizzato per scaricare e memorizzare i supporti specifici della soluzione SAP necessari per la successiva distribuzione dell'automazione. Il server di distribuzione (Bastion Server) viene utilizzato sia per gli scenari di distribuzione CLI, sia per le distribuzioni dell'interfaccia utente Schematics. Il server di distribuzione deve esistere nella stessa VPC del sistema primario SAP HANA. Per ulteriori informazioni su come creare il server di distribuzione (Bastion Server) e la relativa VPC, vedere Automatizzare SAP bastion server - SAP media storage repository.

• Una coppia di chiavi SSH da usare per connettersi ai VSI. La chiave pubblica deve essere caricata in IBM Cloud e aggiunta manualmente sul sistema primario VSI di SAP HANA in /root/.ssh/authorized_keys.

• Un sistema primario SAP HANA non HA distribuito, su un VSI in una regione diversa da quella scelta per il sistema secondario SAP HANA (costruito su uno dei seguenti SO: SUSE Linux Enterprise Server 15 SP 4 per SAP, SUSE Linux Enterprise Server 15 SP 3 per SAP, Red Hat Enterprise Linux 8.6 per SAP o Red Hat Enterprise Linux 8.4 per SAP ) in un IBM Cloud Gen2 VPC, su un singolo host (con o senza HA).

• È necessario eseguire un backup completo del database sul sistema primario per il database di sistema e tutti i database dei tenant.

Le immagini del sistema operativo IBM Cloud utilizzate per convalidare questa automazione sono indicate nel file Readme.

Per risparmiare sui costi, il Deployment Server (Bastion Server), con il suo storage dedicato ai supporti SAP, può essere dismesso dopo che le soluzioni SAP sono state implementate con successo sul cloud IBM Cloud VPC. In alternativa, è possibile mantenere il server di distribuzione (Bastion Server) e utilizzarlo come host di salto per quella regione specifica e per le distribuzioni future.

L'automazione è offerta gratuitamente, ma l'infrastruttura fornita ha un costo.

SAP Guida al valore del progetto - IBM Cloud VPC e automazione del backup del db HANA su Cloud Object Storage

SAP i progetti variano molto per portata e budget, ma nessuno è considerato banale. Che si tratti di un nuovo sistema SAP o dell'implementazione di modifiche a un sistema esistente, il requisito di non commettere errori nell'esecuzione e di ridurre i tempi del progetto per realizzare i benefici è sempre presente.

In molti scenari di progetti SAP, l'implementazione di un sistema SAP è spesso un compito chiave e ripetuto. Questa guida al valore del progetto riguarda l'implementazione automatizzata di IBM Cloud VPC e HANA db cross-regions DR. Ulteriori informazioni su SAP NetWeaver del database HANA e dell'Additional Application Server(AAS)all'istanza SAP e all'istanza HANA sono trattate nelle rispettive sezioni.

Essendo questo sistema una parte fondamentale del vostro progetto SAP, volete attivare un'architettura di Disaster Recovery interregionale per il vostro database produttivo esistente SAP HANA.

SAP HANA modulo di automazione del ripristino db cross-regions disaster recovery

SAP HANA il modulo di automazione db cross-regions Disaster Recovery (DR) sarà sviluppato come modulo di automazione autonomo che sarà integrato in qualsiasi soluzione SAP in esecuzione su database HANA.

SAP HANA Cloud offre la possibilità di replicare il database SAP HANA Cloud in modo sincrono all'interno della stessa zona di disponibilità o in modo asincrono in altre zone di disponibilità in un'altra regione da ottobre 2021.

Con queste opzioni, è possibile configurare un'architettura ad alta disponibilità (HA) e/o un'architettura di disaster recovery (DR) eseguendo il modulo di automazione cross-region di HANA DR in aggiunta a un prodotto SAP esistente in esecuzione su HANA db.

Nei diagrammi seguenti, il database SAP HANA è rappresentato come un passivo secondario di HANA. Le architetture di replica sincrona e asincrona sono illustrate per gli scenari HA e DR.

Valori diversi di RPO/RTO possono essere associati a diversi tipi di guasti. I sistemi business critical devono funzionare con un RPO di zero perdite di dati in caso di guasti locali e spesso anche in caso di disastro. Ma le sfide del disaster recovery sono diverse da quelle dei guasti recuperabili localmente. Per ottenere un RPO pari a zero e un RTO basso, i dati devono essere replicati in modo sincrono su distanze maggiori, il che ha un impatto sulle prestazioni regolari del sistema e può richiedere soluzioni di standby e failover più costose. Tutto questo porta a decisioni di compromesso sugli attributi della funzionalità di recupero dei guasti, del costo e della complessità.

Ecco come funziona la replica del sistema. Quando il sistema secondario funziona in modalità di replica live, ogni componente del servizio stabilisce una connessione con la sua controparte del sistema primario e richiede un'istantanea dei dati. Da qui, tutte le modifiche registrate nei sistemi primari vengono replicate.

Cosa succede se la replica fallisce?

Se la replica si interrompe a causa di un errore di rete, è possibile impostare il commit della transazione o il fallimento del commit sul sistema primario, fino al ripristino della replica.

SAP HANA supporta contenitori di database multi-tenant. La replica del sistema può essere impostata solo per il sistema nel suo complesso, non per ogni singolo tenant.

Ogni volta che i registri vengono conservati nel sistema primario (cioè scritti nei volumi di log di ciascun servizio), vengono inviati anche al sistema secondario. Una transazione nel sistema primario non viene impegnata finché i registri di ripristino non vengono replicati, come determinato da un'opzione di replica dei registri:

• Sincrono (usato per l'HA): Il sistema primario attende di eseguire il commit della transazione fino a quando non riceve la risposta che il log è persistito nel sistema secondario. Questa modalità garantisce la coerenza immediata tra entrambi i sistemi, a costo di ritardare la transazione per il tempo di trasmissione e persistenza dei dati nel sistema secondario.

• Sincrono in-memory: Il sistema primario esegue il commit della transazione dopo aver ricevuto la risposta che il log è stato ricevuto dal sistema secondario, ma prima che sia stato persistito. Il ritardo della transazione nel sistema primario è più breve, perché include solo il tempo di trasmissione dei dati.

• Asincrono (usato per il DR): Il sistema primario esegue il commit della transazione dopo l'invio del log senza attendere la risposta. In questo modo si elimina la latenza di sincronizzazione, con il rischio di una piccola perdita teorica di dati in caso di guasto. Questa modalità è molto utile quando il sito secondario si trova a centinaia di chilometri di distanza dal sito primario o quando la riduzione della latenza è fondamentale.

HSR sincronizza i dati tra un sistema HANA primario e uno secondario, garantendo che i dati critici rimangano accessibili anche in caso di eventi imprevisti.

Replica del sistema Aggiornamento continuo (sincrono e asincrono) del sistema secondario da parte del sistema primario, compreso il caricamento delle tabelle in memoria e la riproduzione continua dei log sul sistema secondario (se configurato).

SAP HANA la replica del sistema offre la possibilità di copiare e sincronizzare continuamente un database SAP HANA in una posizione secondaria nello stesso o in un altro data center. Di solito, la replica del sistema viene utilizzata per supportare l'alta disponibilità e il disaster recovery.

Distanza tra i data center:

• La replica del sistema offre modalità di replica sincrona e asincrona per adattarsi alla latenza della rete.
• Se la distanza tra i siti è inferiore a 100 km, è possibile utilizzare la modalità di replica sincrona SYNC o SYNCMEM.
• Se la distanza tra i siti è superiore a 100 km, è possibile utilizzare la modalità di replica asincrona ASYNC.

Transit Gateway

Con IBM Cloud Transit Gateway è possibile creare gateway di transito singoli o multipli per collegare tra loro le VPC. È inoltre possibile collegare l'infrastruttura classica IBM Cloud a un gateway di transito per garantire una comunicazione continua con le risorse dell'infrastruttura classica. Ogni nuova rete collegata a un gateway di transito viene automaticamente resa disponibile a tutte le altre reti ad esso collegate, in modo da poter scalare la rete man mano che cresce.

I gateway di transito offrono flessibilità consentendo di aggiungere reti ai gateway locali. Le reti possono essere collegate a più gateway locali e a un unico gateway globale, consentendo di mantenere il traffico locale su un gateway locale.

IBM Cloud Transit Gateway supporta il routing locale e globale tra le VPC e l'infrastruttura classica IBM Cloud. Tutte le opzioni di routing rimangono all'interno dell'infrastruttura privata IBM Cloud senza operare su Internet pubblica e sono ottimizzate per le prestazioni. IBM Cloud Transit Gateway consente ai clienti una maggiore flessibilità, ridondanza e velocità nella scalabilità dei carichi di lavoro e nella connessione di reti isolate che funzionano su IBM Cloud.

• Creare una porta di transito.

• Il sito Transit Gateway è ora creato e disponibile.

• Il gateway di transito mostra due connessioni con l'istanza del db HANA di VSI in due regioni separate.

Automazione per l'installazione di SAP

L'automazione basata su script Terraform e playbook Ansible è utilizzata per l'abilitazione della protezione del Disaster Recovery in più regioni per un sistema SAP HANA nonHA su VSI. Ansible è un motore di automazione IT open source che può essere utilizzato per configurare i sistemi, distribuire il software e orchestrare i flussi di lavoro per supportare la distribuzione delle applicazioni e gli aggiornamenti del sistema. Per maggiori informazioni su Ansible, consultare la documentazione Ansible.

I playbook di Ansible sono richiamati direttamente dagli script di Terraform. Per prima cosa gli elementi dell'infrastruttura VPC vengono creati dagli script di Terraform, quindi vengono utilizzati i playbook di Ansible per la configurazione LVM, l'impostazione del sistema operativo e l'installazione del sistema secondario SAP HANA, oltre all'impostazione e all'abilitazione del DR.