Panoramica per automatizzare l'implementazione del carico di lavoro HA di SAP su IBM Cloud® Virtual Private Cloud (VPC) (Terraform e Ansible )
È possibile utilizzare Terraform per automatizzare il provisioning di IBM Cloud VPC. La VPC fornita comprende istanze di server virtuali con elevate prestazioni di rete. L'infrastruttura VPC contiene una serie di offerte Infrastructure-as-a-Service ( IaaS ), tra cui i server virtuali. Dopo il provisioning della VPC, gli script utilizzano il Playbook Ansible per installare il sistema SAP.
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 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 virtuali per VPC con prestazioni di rete elevate. L'infrastruttura VPC contiene una serie di 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 architettura dei prodotti su IBM Cloud VPC
Un Virtual Private Cloud(VPC) contiene uno degli ambienti cloud più sicuri e affidabili per le applicazioni SAP all'interno del proprio VPC con le istanze di server virtuale incluse. Si tratta di un'Infrastruttura come servizio ( IaaS ){: external} all'interno di IBM Cloud che offre tutti i vantaggi dell'infrastruttura cloud virtuale isolata, sicura e flessibile di IBM. In confronto, l'offerta di server virtuali dell'infrastruttura classica di IBM Cloud utilizza istanze virtuali con rete nativa e VLAN per comunicare tra loro all'interno di un data center; tuttavia, le istanze sono limitate in un pod ben funzionante utilizzando la rete subnet e VLAN, in quanto un gap di scale up delle risorse virtuali dovrebbe basarsi tra i pod. La novità di IBM Cloud VPC è un concetto di livello di orchestratore di rete che elimina i confini e le restrizioni dei pod, quindi questo nuovo concetto gestisce tutto il networking per ogni istanza virtuale in esecuzione all'interno della VPC attraverso regioni e zone.
Sistema ad alta disponibilità per SAP NetWeaver su IBM Cloud VPC
In un sistema altamente disponibile (HA), ogni istanza può essere eseguita su un'istanza di server virtuale IBM Cloud separata. La configurazione HA del cluster per l'application server SAP consiste in due istanze di server virtuali, ciascuna delle quali si trova nella stessa zona per la zona singola o in zone diverse per la zona multipla all'interno della stessa regione utilizzando i gruppi di posizionamento. I gruppi di collocazione assicurano che sia le risorse del cluster che quelle del cloud siano collocate in nodi di calcolo diversi, come specificato nella seguente sezione Gruppi di collocazione.
Gruppi di posizionamento su IBM Cloud VPC per l'architettura SAP HA
I gruppi di posizionamento (PG) per VPC hanno due diverse strategie di anti-affinità per l'alta disponibilità. Utilizzando le strategie di posizionamento, si riduce al minimo la possibilità di interruzione del servizio con istanze di server virtuali collocate su host diversi o in un'infrastruttura con alimentazione e rete separate.
La progettazione dei gruppi di posizionamento per i server virtuali IBM Cloud risolve questo problema. I gruppi di posizionamento ti forniscono un certo controllo sull'host in cui viene posizionato un nuovo server virtuale pubblico. Con questa versione è stata implementata una regola di "diffusione", che significa che i server virtuali all'interno di un gruppo di collocamento sono tutti distribuiti su host diversi. È possibile creare un'applicazione altamente disponibile all'interno di un data center e sapere che i server virtuali sono isolati gli uni dagli altri.
I gruppi di posizionamento con la regola di “distribuzione” sono disponibili per la creazione in data center IBM Cloud selezionati. Dopo aver creato una regola di "diffusione", è possibile eseguire il provisioning di un server virtuale in quel gruppo e garantire che non si trovi sullo stesso host di altri server virtuali. Il vantaggio principale? Non c'è assolutamente alcun addebito per l'utilizzo di questa funzione.
È possibile creare il gruppo di collocamento, quindi assegnare fino a quattro nuove istanze di server virtuale. Con la regola di "distribuzione", il provisioning di ciascuno dei server virtuali viene eseguito su host fisici differenti. Nelle seguenti configurazioni di esempio, viene utilizzata l'opzione "Power Spread".
Si tratta delle seguenti istanze di SAP, necessarie per uno scenario HA:
- Istanza dei servizi centrali ABAP (istanza ASCS): contiene il server dei messaggi ABAP e il server enqueue ABAP
- Enqueue istanza del server di replica (istanza ERS) per l'istanza ASCS
- Istanza del database
- Istanza applicativa primaria (PAS) sul nodo 1
- Istanza di applicazione aggiuntiva (AAS) sul nodo 2
Si consiglia di eseguire sia l'istanza ASCS che l'istanza ERS in un'infrastruttura cluster switchover.
IBM Cloud File Storage for VPC per l'architettura HA di SAP
IBM Cloud File Storage for VPC viene utilizzata per rendere disponibili le directory di SAP al sistema SAP. Le tecnologie prescelte sono NFS, dischi condivisi e cluster file system. Se si è deciso di utilizzare una soluzione ad alta disponibilità (HA) per il sistema SAP, assicurarsi di affrontare correttamente i requisiti HA dei file system SAP nell'ambiente SAP.
- Condivisioni di file montate come file system permanenti NFS su entrambi i nodi del cluster per SAP apps HA:
/usr/sap/<SAPSID>/SYS/sapmnt<SAPSID>/usr/sap/trans
- File system gestiti in cluster per SAP Apps HA: ASCS si ERS
/usr/sap/<SAPSID>/ASCS00/usr/sap/<SAPSID>/ERS01
- Montaggio permanente NFS su SAP Apps HA nodo 1 istanza PAS:
/usr/sap/<SAPSID>/Dxx
- Montaggio permanente NFS su SAP Apps HA nodo 2 istanza di dialogo:
/usr/sap/<SAPSID>/Dyy
Prerequisiti
È necessario installare l'hardware (host, dischi e rete) e decidere come distribuire il database, le istanze SAP e, se necessario, il server Network File System ( NFS ) sui nodi del cluster.
Contesto
Dal punto di vista di un'applicazione SAP, questi sono i tipi di directory SAP:
- Directory fisicamente condivise:
/<sapmnt>/<SAPSID>e/usr/sap/trans - Le directory logicamente condivise che sono legate a un nodo, come
/usr/sap, con le seguenti directory locali:/usr/sap/<SAPSID>/usr/sap/<SAPSID>/SYS/usr/sap/hostctrl
- Le directory locali che contengono le istanze di SAP, ad esempio
/usr/sap/<SAPSID>/ASCS<Instance_Number> - La directory di trasporto globale potrebbe risiedere su un host di trasporto separato SAP come una configurazione standard del livello di trasporto a tre sistemi.
Sono necessari almeno due nodi e un file system condiviso per le istanze distribuite di ASCS e ERS, e si presume che il resto dei componenti sia distribuito su altri nodi.
Installazione di ASCS e ERS
Affinché le istanze ASCS ed ERS possano spostarsi da un nodo all'altro, devono essere installate su un file system condiviso e utilizzare hostname virtuali basati sull'IP virtuale.
In questa soluzione SAP HA basata su VPC, il file system condiviso richiesto dal cluster è sostituito dal file storage montato su NFS e l'IP virtuale è sostituito da Application Load Balancer for VPC (ALB).
In questo scenario, vengono utilizzati tre ALB, uno per ogni componente Single Point of Failure (SPOF), al fine di sostituire il requisito IP virtuale: ALB per ASCS, ALB per ERS e ALB per HANA. Ogni ALB è configurato come backend per i server del cluster corrispondente e reindirizza tutte le comunicazioni ricevute sulle porte front-end al server attivo del pool backend.
Bilanciatore di carico delle applicazioni private
Un bilanciatore di carico delle applicazioni privato è accessibile attraverso le sottoreti private configurate per creare il bilanciatore di carico.
Analogamente a un bilanciatore di carico delle applicazioni pubblico, all'istanza di servizio del bilanciatore di carico delle applicazioni privato viene assegnato un FQDN; tuttavia, questo nome di dominio è registrato con uno o più indirizzi IP privati.
Nel corso del tempo, le operazioni IBM Cloud potrebbero modificare il numero e il valore dei tuoi indirizzi IP privati assegnati, in base alle attività di manutenzione e ridimensionamento. Le istanze del server virtuale di back-end che ospitano l'applicazione devono essere eseguite nella stessa regione e nella stessa VPC.
Utilizzate il FQDN ALB assegnato per inviare il traffico al bilanciatore di carico delle applicazioni privato, per evitare problemi di connettività alle applicazioni durante le attività di manutenzione del sistema o di ridimensionamento.
Ogni ALB invia il traffico al nodo del cluster in cui è in esecuzione l'applicazione (ASCS, ERS, HANA DB). Durante il failover del cluster, l'ALB reindirizza tutto il traffico al nuovo nodo dove le risorse sono attive e funzionanti.
DNSaaS (DNS as a Service) è il servizio di gestione IBM Cloud VPC DNS del meccanismo HA e FQDN (IP).
L'ALB ha un valore predefinito di 50 secondi per il timeout di client e server, quindi dopo 50 secondi di inattività le connessioni vengono chiuse. Per supportare le connessioni SAP attraverso ALB e non perdere la connessione dopo 50 secondi, è necessario richiedere la modifica di questo valore a un minimo di 300 secondi (connessione inattiva lato client = minimo 300s e connessione inattiva lato server = minimo 300s ). Per richiedere questa modifica, aprire un ticket di assistenza. Si tratta di una modifica a livello di account che riguarda tutti gli ALB dell'account. Per ulteriori informazioni, vedere Timeout di connessione.
DNS Services con VPC
IBM Cloud DNS Services fornisce un DNS privato agli utenti della VPC. Le zone DNS private sono risolvibili solo su IBM Cloud e solo dalle reti esplicitamente autorizzate in un account. Per iniziare, creare un'istanza di DNS Services utilizzando la console IBM Cloud.
DNS Services vi permettono di:
- Creare zone DNS private che sono raccolte per contenere i nomi di dominio.
- Creare record di risorse DNS in queste zone DNS.
- Specificare i controlli di accesso utilizzati per la risoluzione DNS dei record di risorse a livello di zona.
DNS Services mantiene anche un proprio set mondiale di risolutori DNS. Le istanze fornite sotto IBM Cloud su una rete IBM Cloud possono usare i record di risorse configurati attraverso IBM Cloud DNS Services interrogando i resolver di DNS Services.
I record di risorse e le zone configurate tramite DNS Services sono:
- Separato dal più ampio DNS pubblico e dai suoi documenti pubblicamente accessibili.
- Nascosto ai sistemi esterni e non facenti parte della rete privata IBM Cloud.
- Accessibile solo dai sistemi autorizzati dall'utente sulla rete privata IBM Cloud.
- Risolvibile solo attraverso i resolver forniti dal servizio.
Il servizio DNS mappa l'FQDN di ogni ALB con gli hostname virtuali di ASCS, ERS e HANA utilizzati dalle applicazioni SAP.
Latenza di rete tra le zone VPC e le regioni
Per quanto riguarda la latenza di rete tra le zone e le regioni VPC, consultare l'argomento VPC Network latency dashboards ed eseguire le proprie misurazioni in base alla nota SAP "500235 - Network Diagnosis with NIPING" per eseguire un controllo della latenza utilizzando lo strumento SAP niping.
I risultati riportati sono quelli misurati. Queste misure non forniscono alcuna garanzia di prestazione. Queste statistiche forniscono visibilità sulla latenza tra tutte le regioni e le zone per aiutarvi a pianificare la scelta ottimale per l'implementazione del cloud e a pianificare gli scenari, come la residenza dei dati e le prestazioni.
Sistema ad alta disponibilità per il database SAP HANA
Al livello più elementare, un cluster HA HANA standard in una configurazione attiva-passiva ha due nodi: uno è il nodo primario e l'altro è il nodo di standby. Ciò significa semplicemente che il nodo primario sta servendo attivamente le istanze attive di SAP (PAS e AAS), mentre il nodo di standby è in attesa di intervenire in caso di guasto.
Sistema ad alta disponibilità per l'istanza dell'applicazione SAP
Il cluster è impostato con un hostname IP virtuale (l'hostname è mappato sull'FQDN dell'ALB HANA tramite DNS, come spiegato in precedenza per le istanze SAP ASCS e ERS). Istanze di applicazione (PAS e AAS), questi sono i dettagli da utilizzare nei profili SAP per chiamare quel particolare componente. Il cluster assegna l'IP virtuale al nodo attivo e utilizza un monitor heartbeat per confermare la disponibilità dei componenti. Se il nodo primario smette di rispondere, si attiva il meccanismo di failover automatico che chiama il nodo di standby a diventare il nodo primario. L'ALB rileva la modifica, reindirizza il traffico al nuovo nodo attivo e gli assegna l'IP virtuale, ripristinando la disponibilità del componente. Una volta riparato, il nodo guasto viene messo in linea come nodo di riserva.
Meccanismo di replica sincrona su disco (sync) del database HANA supportato da SAP
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 opzione garantisce la coerenza immediata tra i due sistemi, a costo di ritardare la transazione per il tempo di trasmissione e persistenza dei dati nel sistema secondario.
Quando la connessione al sistema secondario viene persa, il sistema primario continua l'elaborazione della transazione e scrive le modifiche solo sul disco locale. In questo scenario non si verifica alcuna perdita di dati se il sistema secondario è collegato. La perdita di dati può verificarsi quando il takeover viene eseguito mentre il sistema secondario è disconnesso.
Inoltre, questa modalità di replica può essere eseguita con l'opzione di sincronizzazione completa. Ciò significa che la scrittura del registro è riuscita quando il buffer del registro è stato scritto nel file di registro del sistema primario
e secondario. Quando il sistema secondario viene disconnesso (ad esempio, a causa di un guasto della rete), il sistema primario sospende l'elaborazione delle transazioni finché non viene ristabilita la connessione con il sistema secondario.
In questo scenario non si verifica alcuna perdita di dati. È possibile impostare l'opzione di sincronizzazione completa per la replica del sistema con il parametro [system_replication]/enable_full_sync.
Se la replica del sistema SAP HANA viene eseguita in modalità di replica sincrona con l'opzione di sincronizzazione completa attivata e se la connessione al sito secondario viene interrotta, non è possibile eseguire operazioni di scrittura sul sito primario. L'operazione di creazione di un database tenant, ad esempio, attende finché la connessione al secondario non viene ristabilita o l'istruzione SQL non va in timeout.
L'automazione è offerta gratuitamente, ma l'infrastruttura fornita ha un costo.