Implementazione dell'alta disponibilità per le applicazioni SAP su IBM Power Virtual Server

L'esecuzione di SAP su IBM® Power® Virtual Server offre una piattaforma coerente per applicazioni tradizionali e basate su SAP HANA, prestazioni di livello mondiale, resilienza per carichi di lavoro critici e un'infrastruttura flessibile.

Utilizza le seguenti informazioni per capire come implementare soluzioni ad alta disponibilità per i sistemi di gestione dell' SAP, utilizzando istanze di Power Virtual Server.

SAP architettura del sistema

I componenti principali di un sistema di controllo elettronico della trasmissione ( SAP ) sono i seguenti.

Sistema SAP HANA

Il sistema " SAP HANA " fornisce il database dei tenant per i server delle applicazioni " SAP ".

SAP server applicativo

SAP i server applicativi forniscono la parte funzionale di un'applicazione ( SAP, S/4HANA o altro). Tutti i dati di personalizzazione e applicazione di un sistema SAP sono memorizzati in un database tenant di un sistema SAP HANA.

Un sistema applicativo SAP e è installato e configurato come unità singola e consiste nelle seguenti istanze applicative.

Un'istanza di ABAP System Central Services (istanza ASCS) Ogni sistema applicativo di SAP e ha esattamente un'istanza ASCS, che consiste in un server di messaggistica e un server di accodamento.
Una o più istanze di server applicativo (istanze AS)
- Il Primary Application Server (PAS) è la prima istanza AS installata per un sistema ABAP.
- Altri esempi di AS installati per un sistema ABAP sono chiamati server applicativi aggiuntivi (AAS).

Sia le istanze del server applicativo che l'istanza ASCS dipendono da un file system condiviso e richiedono l'accesso in lettura/scrittura ad esso.

Sistema di file condiviso

In genere, il file system condiviso viene esportato su un server NFS e montato su tutte le istanze.

La figura 1 illustra i componenti tecnici di un sistema di controllo della pressione di sovralimentazione ( SAP ).

Figura 1. Componenti tecnici per sistemi di controllo dell' SAP e — Componenti tecnici per sistemi di controllo dell' SAP e

Considerazioni per l'implementazione di una soluzione ad alta disponibilità ( SAP )

Per una protezione ad alta disponibilità, si raccomanda di installare i server delle applicazioni in modo ridondante. Installare almeno due server applicativi (PAS e AAS) e utilizzare gruppi di accesso per implementare il bilanciamento del carico. Se un server applicativo si guasta, tutte le sessioni utente collegate a quell'istanza vengono interrotte. L'utente effettua nuovamente l'accesso e il bilanciamento del carico reindirizza l'utente a un altro server applicazioni ancora in esecuzione.

Gli altri componenti tecnici, come l'istanza ASCS, il database dell' SAP HANA, e il file system condiviso, sono singoli punti di errore e devono essere protetti.

Istanza ASCS

Il modo migliore per salvaguardare l'istanza ASCS è quello di implementare un'istanza Enqueue Replication Server (ERS) su un server virtuale aggiuntivo e utilizzare il software di clustering HA per automatizzare il failover.

Installa ASCS ed ERS su un disco condiviso collegato a entrambe le istanze del server virtuale o su un file system di tipo " NFS ".

Il server di accodamento dell'istanza ASCS gestisce la tabella di blocco e l'ERS crea una copia replicata della tabella di blocco nella sua memoria principale. Se il server di accodamento deve essere riavviato, la tabella di blocco viene ricostruita utilizzando la copia sull'ERS e tutti i blocchi vengono mantenuti.

È sufficiente un semplice riavvio del server dei messaggi perché non è necessario conservare alcun dato.

Seguite i passaggi in Configurazione dell'alta disponibilità per SAP S/4HANA(ASCS e ERS)in un cluster Red Hat Enterprise Linux High Availability Add-On per configurare un cluster HA per l'istanza ABAP System Central Services.
Sistema di file condiviso

Il metodo consigliato per proteggere il server dell' NFS e è quello di implementare un'istanza di server virtuale aggiuntiva. Quindi, creare i file system esportati in modalità " NFS " su dischi condivisi collegati a entrambe le istanze del server virtuale e automatizzare il failover utilizzando il software HA cluster.

Seguire la procedura descritta in Configurazione di un server NFS attivo-passivo in un cluster Red Hat Enterprise Linux High Availability Add-On per configurare un cluster HA per il file system condiviso.
Sistema SAP HANA

SAP HANA fornisce due approcci per scalare un sistema: scale-up e scale-out. Con il set completo e altamente scalabile di profili certificati IBM Power Virtual Server per SAP HANA disponibili su IBM Power Virtual Server, l'attenzione è rivolta alle soluzioni di scale-up SAP HANA.

Il modo migliore per proteggere un sistema di e- SAP HANA ing è quello di impostare un sistema di e- SAP HANA ing secondario su un'istanza di server virtuale separata. Quindi, configurare la replica del sistem SAP HANA e e automatizzare il failover con il software HA cluster.

La figura seguente mostra una panoramica architettonica di un sistema di gestione dell' SAP e ad alta disponibilità implementato su Power Virtual Server.

Figura 2. SAP su Power Virtual Server Panoramica dell'architettura HA — SAP su Power Virtual Server Panoramica dell'architettura HA

SAP HANA scenari di soluzioni ad alta disponibilità

La soluzione varia a seconda dell'obiettivo di tempo di recupero (RTO).

Variazioni per soluzioni ad alta disponibilità per SAP HANA
Scenario	Tipico RTO	Commento
Prestazioni ottimizzate	Pochi minuti	A meno che non si abbiano esigenze specifiche, questo scenario è quello predefinito.
Attivo/Attivo (lettura abilitata)	Pochi minuti	In una configurazione attiva/attiva (lettura abilitata), la replica del sistem SAP HANA e consente l'accesso in lettura al contenuto del database sul sistema secondario.
Ottimizzazione dei costi	Poche decine di minuti	In una configurazione a costi ottimizzati, un sistema di SAP HANA e non di produzione funziona sul nodo secondario durante il normale funzionamento. Le risorse hardware sul nodo secondario sono condivise tra il sistema non di produzione e il sistema secondario di replica ( SAP HANA ). Il consumo di memoria del sistema di replica secondaria dell' SAP HANA e di produzione viene ridotto disattivando il precaricamento dei dati nelle tabelle delle colonne. Quando si verifica un failover, l'istanza non di produzione viene automaticamente interrotta prima che il nodo assuma il carico di lavoro di produzione. Il tempo di ripresa è più lungo rispetto a una configurazione ottimizzata per le prestazioni.

A seconda delle esigenze, selezionare la documentazione per uno degli scenari.

SAP HANA Sistema Replica scenario ottimizzato per le prestazioni

Configurazione della replica del sistema scale-up SAP HANA in un cluster Red Hat Enterprise Linux High Availability Add-On.
SAP HANA Scenario ottimizzato in termini di costi per la replica di sistemi

Configurazione della replica di sistema scale-up ottimizzata per i costi di SAP HANA in un cluster Red Hat Enterprise Linux High Availability Add-On.
SAP HANA Replica di sistema Scenario attivo-attivo (lettura abilitata)

Configurazione della replica del sistema SAP HANA attivo/attivo(abilitato alla lettura)in un cluster Red Hat Enterprise Linux High Availability Add-On.

SAP HANA scenari di soluzioni per il ripristino in caso di disastro

Per una protezione extra del sistema di database, replicare il sistema di gestione dei dati ( SAP HANA ) su un terzo sistema che si trova in una regione diversa utilizzando la replica del sistema di gestione dei dati ( SAP HANA ). A seconda delle esigenze, selezionare una delle due topologie disponibili.

SAP HANA scenario di replica di un sistema multilivello

Con la replica di sistema multilivello di SAP HANA, è possibile collegare più sistemi insieme per ottenere un livello di disponibilità più elevato.

Configurazione della replica del sistema multitier SAP HANA in un cluster Red Hat Enterprise Linux High Availability Add-On.
SAP HANA scenario di replica del sistema multitarget

La replica del sistema multitarget consente ai sistemi primari e secondari di replicare le modifiche su più di un sistema.

Configurazione della replica del sistema multitarget SAP HANA in un cluster Red Hat Enterprise Linux High Availability Add-On.

SAP HANA soluzione ad alta disponibilità in un ambiente multizona

Una sottorete in IBM Power Virtual Server non può estendersi su più aree di lavoro. Non è possibile spostare un indirizzo IP di servizio in un secondo spazio di lavoro e continuare a utilizzarlo da VPC o da altri spazi di lavoro per accedere ai servizi forniti. Tuttavia, questa capacità è necessaria per impostare uno scenario di replica del sistema di alta disponibilità ( SAP HANA ) in un ambiente multizona.

L'agente risorse dell' powervs-subnet, affronta questo limite. Durante un evento di acquisizione, l'agente delle risorse sposta l'intera sottorete, compreso l'indirizzo IP, da uno spazio di lavoro a un altro.

Le figure seguenti illustrano questo scenario.

Due istanze di server virtuali sono distribuite in aree di lavoro separate con sottoreti diverse.

SAP HANA è installato su entrambe le istanze del server virtuale ed è configurata la replica di sistema di SAP HANA.
Le due istanze del server virtuale sono configurate come un cluster a due nodi ad alta disponibilità con le proprie sottoreti.
Una risorsa cluster che utilizza l'agente risorse dell' powervs-subnet, è configurata per Subnet 3 e IP address 3. IP address 3 Scegli un intervallo piccolo per il Classless Inter-Domain Routing (CIDR), solo un indirizzo IP per il gateway e un indirizzo IP per l' Subnet 3.
SAP HANA i clienti del database utilizzano IP address 3 per connettersi al database.

Durante il normale funzionamento

La sottorete 3 viene creata nello spazio di lavoro 1.
La sottorete 3 è collegata all'istanza di server virtuale 1.
L'indirizzo IP 3 è configurato sull'istanza 1 del server virtuale.
Il primario SAP HANA e è attivo sull'istanza 1 del server virtuale, il secondario SAP HANA e è attivo sull'istanza 2 del server virtuale.

Figura 3. SAP HANA su Power Virtual Server nella regione multizona Panoramica HA — SAP HANA su Power Virtual Server nella regione multizona Panoramica HA

Dopo l'acquisizione di un gruppo

La sottorete 3 viene creata nell'area di lavoro 2.
La sottorete 3 è collegata all'istanza 2 del server virtuale.
L'indirizzo IP 3 è configurato sull'istanza 2 del server virtuale.
Il primario dell' SAP HANA e è attivo sull'istanza 2 del server virtuale.

Figura 4. SAP HANA su Power Virtual Server nella regione multizona HA acquisizione — SAP HANA su Power Virtual Server nella regione multizona HA acquisizione

Si vedano le informazioni contenute in Implementazione di un cluster Red Hat Enterprise Linux High Availability Add-On in un ambiente multizona regionale su come preparare e configurare un cluster Red Hat Enterprise Linux (RHEL) High Availability (HA) per l'agente di risorse powervs-subnet.