Architettura di riferimento: SAP Business Suite su SAP ASE o IBM Db2 su Google Cloud

Questa architettura di riferimento è destinata a chi sta valutando Google Cloud come piattaforma per il deployment di applicazioni SAP Business Suite su SAP ASE o IBM Db2. Include considerazioni durante la fase di pianificazione, i modelli di deployment e l'automazione e le procedure operative comuni, come le attività di backup e RE.

Google Cloud offre un'infrastruttura conveniente, affidabile, sicura e ad alte prestazioni certificata SAP per l'esecuzione di SAP Business Suite su SAP ASE o IBM Db2. Per un elenco completo delle soluzioni SAP supportate su Google Cloud, consulta SAP su Google Cloud.

Architettura

I seguenti diagrammi mostrano una visione generale di tre modelli di deployment comuni per SAP Business Suite: centralizzato, distribuito e distribuito con disponibilità elevata.

Deployment centralizzato

In un deployment centralizzato, puoi installare SAP Business Suite e il database SAP ASE o IBM Db2 sulla stessa istanza VM di Compute Engine. Consigliamo questo approccio per gli ambienti non di produzione, come gli ambienti sandbox e di sviluppo.

Le seguenti sezioni mostrano le architetture di riferimento per SAP Business Suite su SAP ASE e IBM Db2 in deployment centralizzati.

Deployment centralizzato di SAP Business Suite con SAP ASE

Il seguente diagramma mostra un'architettura di riferimento per un deployment centralizzato di SAP Business Suite su SAP ASE. Tieni presente che SAP ASCS, PAS, WD e il database sono installati sulla stessa istanza VM.

Diagramma dell'architettura di SAP Business Suite in SAP ASE su Google Cloud in un deployment centralizzato.

Distribuzione centralizzata di SAP Business Suite con IBM Db2

Il seguente diagramma mostra un'architettura di riferimento per un deployment centralizzato di SAP Business Suite su IBM Db2. Tieni presente che SAP ASCS, PAS, WD e il database sono installati sulla stessa istanza VM.

Diagramma dell'architettura di SAP Business Suite su IBM Db2 su Google Cloud in un deployment centralizzato.

Deployment distribuito

In un deployment distribuito, puoi installare i vari componenti su diverse istanze di Compute Engine. Consigliamo questo approccio per gli ambienti di produzione o gli ambienti che richiedono molta potenza di calcolo per gestire pesanti carichi delle transazioni.

Deployment distribuito di SAP Business Suite con SAP ASE

Il seguente diagramma mostra un'architettura di riferimento per SAP Business Suite su SAP ASE in un deployment distribuito. Tieni presente che SAP ASCS, PAS, WD e ASE sono tutti installati su istanze VM diverse.

Diagramma dell'architettura di SAP Business Suite su SAP ASE su Google Cloud in un deployment distribuito.

Deployment distribuito di SAP Business Suite con IBM Db2

Il seguente diagramma mostra un'architettura di riferimento per SAP Business Suite su IBM Db2 in un deployment distribuito. Tieni presente che SAP ASCS, PAS, WD e IBM Db2 sono installati su istanze VM diverse.

Diagramma dell'architettura di SAP Business Suite su IBM Db2 su Google Cloud in un deployment distribuito.

Deployment distribuito con disponibilità elevata

In un deployment distribuito con disponibilità elevata, i cluster Linux sono configurati in più zone per evitare errori dei componenti in una determinata regione. Puoi eseguire il deployment di un cluster Linux in più zone utilizzando una configurazione attiva/passiva. In entrambi i casi, devi innanzitutto configurare due istanze VM di Compute Engine in zone separate per garantire la massima ridondanza, ciascuna con il proprio database SAP ASE o IBM Db2.

  • Deployment distribuito di SAP ASE con disponibilità elevata: su Google Cloud puoi eseguire il deployment di un database SAP ASE ad alta disponibilità e a tolleranza di emergenza (HADR) supportato da SAP. Per ulteriori informazioni, consulta la Guida alla pianificazione di SAP ASE.

    Il seguente diagramma illustra un'architettura per SAP Business Suite su SAP ASE che utilizza un cluster Linux per ottenere disponibilità elevata sia sul lato delle applicazioni che sul lato database:

    Diagramma dell'architettura di SAP Business Suite su SAP ASE su Google Cloud in un deployment distribuito ad alta disponibilità.

    Il cluster che gestisce l'alta disponibilità include le seguenti funzioni e funzionalità:

    • Tre VM host, due host, ciascuno con un'istanza di database e una con Fault Manager.
    • Replica sincrona di SAP ASE.
    • Gestore delle risorse del cluster ad alta disponibilità Pacemaker.
    • Un meccanismo di fencing che utilizza Fault Manager per garantire l'isolamento delle risorse con errori.
    • Riavvio automatico dell'istanza non riuscita come nuova istanza secondaria e nuova registrazione automatica per la replica SAP ASE.

  • Deployment distribuito di IBM Db2 con disponibilità elevata: su Google Cloud puoi eseguire il deployment di un database IBM Db2 ad alta disponibilità e a tolleranza di emergenza (HADR) supportato da SAP. Per ulteriori informazioni, consulta la guida alla pianificazione di IBM Db2 per SAP.

    Puoi configurare un cluster HADRPacemakercluster a due host utilizzando la soluzione di clustering fornita da IBM per Db2. Per ulteriori informazioni, consulta il PDF SAP Guida all'amministrazione dei database per SAP su IBM Db2 per Linux, Unix e Windows.

    Il seguente diagramma illustra un'architettura per SAP Business Suite su IBM Db2 che utilizza un cluster Linux per ottenere una disponibilità elevata sia sul lato delle applicazioni che sul lato database.

    Diagramma dell'architettura di SAP Business Suite su IBM Db2 su Google Cloud in un deployment distribuito ad alta disponibilità.

    Il cluster che gestisce l'alta disponibilità include le seguenti funzioni e funzionalità:

    • Due VM host, ciascuna con un'istanza di IBM Db2.
    • Replica HADR Db2 IBM sincrona.
    • Un gestore di risorse di un cluster Linux ad alta disponibilità, come Pacemaker.
    • Un meccanismo di recinzione che isola il nodo in errore.
    • Un bilanciatore del carico delle applicazioni interno per instradare il VIP al nodo attivo.
    • Riavvio automatico dell'istanza non riuscita come nuova istanza secondaria e nuova registrazione automatica per IBM Db2 HADR.

L'architettura lato applicazione è simile. In questo caso, il cluster gestisce i SAP Central Services (ASCS) ABAP e l'Enqueue Replication Server o l'Enqueue Replicator (ERS) utilizzati per fornire al sistema SAP Business Suite un'alta disponibilità nel caso in cui succeda qualcosa a una delle istanze ASCS ed ERS.

A seconda della versione di SAP NetWeaver utilizzata con il sistema SAP Business Suite, il server di accodamento e il server di replica di accodamento / replicatore di accodamento vengono eseguiti su una versione diversa:

Il seguente diagramma mostra un sistema SAP Business Suite che utilizza un cluster Pacemaker per limitare i single point of failure sia dal server di messaggi che dal server di accodamento:

Diagramma dell'architettura per SAP NetWeaver, con un database, in un deployment ad alta disponibilità su Google Cloud.

I dettagli sul deployment del sistema ad alta disponibilità e sul clustering di Linux nelle zone sono trattati più avanti in questo documento.

Nota sul bilanciamento del carico

In una SAP Business Suite distribuita su ambiente SAP ASE o IBM Db2, il bilanciamento del carico è obbligatorio. Puoi configurare il bilanciamento del carico delle applicazioni utilizzando una combinazione del livello delle applicazioni SAP e dei bilanciatori del carico di rete. Per ulteriori informazioni, consulta la sezione Implementazioni VIP del bilanciatore del carico di rete passthrough interno nella guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su Google Cloud.

Componenti del deployment

SAP Business Suite su SAP ASE o IBM Db2 è costituito dai seguenti componenti tecnici:

  • Database SAP ASE o IBM Db2
  • Fault Manager, solo su SAP ASE
    • che dispone di un proprio server host e monitora i server principali e in standby. Fault Manager garantisce l'alta disponibilità di SAP ASE tramite l'avvio del failover automatico. Monitora i seguenti componenti: agente di gestione della replica, server di replica, applicazioni, database e sistema operativo. Consente inoltre di verificare l'integrità del database e riavviarlo se necessario.
  • ASCS: servizi centrali SAP ABAP
    • Contiene il server dei messaggi e il server di accodamento, richiesti in qualsiasi sistema SAP ABAP.
    • Distribuito sulla propria istanza VM in deployment ad alta disponibilità o sull'istanza VM che ospita il PAS.
    • Nei deployment ad alta disponibilità, le risorse ASCS sono gestite da un gestore delle risorse del cluster Linux, come Pacemaker.
  • ERS: server di replica di accodamento o replicatore di accodamento
    • Distribuito in deployment ad alta disponibilità per mantenere una replica della tabella di blocco nel caso in cui succeda qualcosa all'istanza ASCS.
    • Gestito da un gestore di risorse del cluster Linux, come Pacemaker.
  • PAS: server applicazione principale
    • Il primo o unico server di applicazioni per il sistema SAP.
  • AAS: server applicazioni aggiuntivo
    • Viene generalmente eseguito il deployment per il bilanciamento del carico a livello di applicazione. Puoi installare più istanze AAS per ottenere una disponibilità maggiore anche dal punto di vista del livello dell'applicazione. Se uno dei server delle applicazioni smette di funzionare, tutte le sessioni utente connesse a quel server vengono terminate, ma gli utenti possono accedere di nuovo all'altro AAS nell'ambiente.
  • Gateway SAP NetWeaver
    • Deployment eseguito come sistema autonomo o come parte del sistema SAP Business Suite.
    • Consente al sistema di connettere dispositivi, ambienti e piattaforme a sistemi SAP utilizzando Open Data Protocol (OData).
  • Server front-end SAP Fiori
    • Deployment eseguito come sistema autonomo o come parte del sistema SAP Business Suite.
    • Il sistema SAP Netweaver ABAP viene utilizzato per ospitare le applicazioni SAP Fiori.
  • WD: Web Dispatcher (facoltativo)
    • Bilanciatore del carico software intelligente che distribuisce le richieste HTTP e HTTPS, in base al tipo di applicazione, a PAS e AAS.

I seguenti servizi Google Cloud vengono utilizzati nella SAP Business Suite su deployment SAP ASE o IBM Db2:

Servizio Descrizione
Networking VPC

Connette le tue istanze VM tra loro e a internet.

Ogni istanza VM fa parte di una rete legacy con un singolo intervallo IP globale oppure di una rete di subnet consigliata, in cui l'istanza VM è membro di una singola subnet che fa parte di una rete più grande.

Tieni presente che una rete Virtual Private Cloud (VPC) non può coprire progetti Google Cloud, ma un progetto Google Cloud può avere più reti VPC.

Per connettere risorse di più progetti a una rete VPC comune, puoi utilizzare un VPC condiviso, in modo che le risorse possano comunicare tra loro in modo sicuro ed efficiente utilizzando indirizzi IP interni di quella rete. Per informazioni su come eseguire il provisioning di un VPC condiviso, inclusi requisiti, passaggi di configurazione e utilizzo, consulta Provisioning del VPC condiviso.

Compute Engine Crea e gestisce le VM con il sistema operativo e lo stack software che preferisci.
Persistent Disk e Hyperdisk

Puoi utilizzare Persistent Disk e Google Cloud Hyperdisk:

  • I volumi di Persistent Disk sono disponibili come hard disk (HDD) standard o unità a stato solido (SSD). Per i dischi permanenti bilanciati e i dischi permanenti SSD, la replica DP Async fornisce la replica asincrona dei dati SAP tra due regioni Google Cloud.
  • I volumi Hyperdisk Extreme offrono opzioni di IOPS e velocità effettiva massime più elevate rispetto ai volumi di dischi permanenti SSD.
  • Per impostazione predefinita, Compute Engine cripta i contenuti at-rest dei clienti, inclusi quelli all'interno dei volumi Persistent Disk e Hyperdisk. Per ulteriori informazioni sulla crittografia del disco e sulle possibili opzioni di crittografia, consulta Informazioni sulla crittografia del disco.
Console Google Cloud

Uno strumento basato su browser per la gestione delle risorse Compute Engine.

Utilizza un modello per descrivere tutte le risorse e le istanze Compute Engine di cui hai bisogno. Non devi creare e configurare le risorse singolarmente o capire le dipendenze perché la console Google Cloud lo fa al posto tuo.
Cloud Storage Puoi archiviare i backup dei tuoi database SAP in Cloud Storage per una maggiore durabilità e affidabilità, con la replica.
Cloud Monitoring

Offre visibilità su deployment, prestazioni, uptime e integrità di dischi Compute Engine, rete e archiviazione permanente.

Monitoring raccoglie metriche, eventi e metadati da Google Cloud e li utilizza per generare insight tramite dashboard, grafici e avvisi. Puoi monitorare le metriche di computing senza costi aggiuntivi tramite Monitoring.
IAM

Fornisce un controllo unificato sulle autorizzazioni per le risorse Google Cloud.

IAM consente di controllare chi può eseguire operazioni del piano di controllo sulle VM, tra cui creazione, modifica ed eliminazione di VM e dischi di archiviazione permanente, nonché creazione e modifica di reti.
Filestore

Archiviazione di file NFS completamente gestita ad alte prestazioni da Google Cloud.

Per i deployment ad alta disponibilità multi-zona, consigliamo di utilizzare Filestore Enterprise, che ha uno SLA (accordo sul livello del servizio) con disponibilità del 99,99%. Per informazioni sui livelli di servizio Filestore, consulta Livelli di servizio.
NetApp Cloud Volumes ONTAP

Una soluzione di archiviazione intelligente e completa di cui esegui il deployment e la gestione in autonomia su un'istanza VM di Compute Engine.

Per maggiori informazioni su NetApp Cloud Volumes ONTAP, consulta Panoramica di Cloud Volumes ONTAP.
Google Cloud NetApp Volumes

Una soluzione di archiviazione di file NFS e SMB completamente gestita di Google Cloud, basata su NetApp Cloud Volumes ONTAP.

A seconda della regione, possono essere disponibili più livelli di servizio tra cui scegliere. Per maggiori informazioni, consulta Livelli di servizio.

Note sul layout

Questa sezione fornisce indicazioni per aiutarti a utilizzare questa architettura di riferimento per sviluppare un'architettura che soddisfi i tuoi requisiti specifici di sicurezza, affidabilità, efficienza operativa, costi e prestazioni.

Networking

Esistono diversi modi per eseguire il deployment di un sistema SAP Business Suite dal punto di vista del networking e il modo in cui esegui il deployment della rete ha un impatto significativo su disponibilità, resilienza e prestazioni. Come accennato in precedenza, un VPC (Virtual Private Cloud) è una rete privata sicura e isolata ospitata all'interno di Google Cloud. I VPC sono globali in Google Cloud, quindi un singolo VPC può abbracciare più regioni senza comunicare tramite internet.

Un tipico deployment SAP posiziona le istanze dei sistemi ad alta disponibilità in zone diverse della stessa regione per garantire resilienza e fornire bassa latenza. Le subnet possono estendersi in più zone grazie alle funzionalità di Google Cloud. Queste funzionalità semplificano anche il clustering SAP poiché l'indirizzo IP virtuale (VIP) del cluster può rientrare nello stesso intervallo delle istanze dei sistemi ad alta disponibilità. Questa configurazione protegge l'IP mobile utilizzando un bilanciatore del carico delle applicazioni interno ed è applicabile al clustering ad alta disponibilità del livello dell'applicazione (ASCS ed ERS) e del livello del database SAP ASE o IBM Db2 (primario e secondario).

Esistono diversi modi per creare la tua rete e connettere il sistema SAP Business Suite alla tua infrastruttura:

  • Il peering di rete VPC connette due reti VPC in modo che le risorse in ciascuna rete possano comunicare tra loro. Le reti VPC possono essere ospitate nello stesso progetto Google Cloud, in progetti diversi della stessa organizzazione o anche in progetti diversi di organizzazioni diverse. Il peering di rete VPC stabilisce una connessione diretta tra due reti VPC, ciascuna delle quali utilizza le proprie subnet, consentendo la comunicazione privata tra le risorse nei VPC in peering.

  • VPC condiviso è una funzionalità di Google Cloud che consente a un'organizzazione di connettere risorse di più progetti a una rete VPC comune. I sistemi che usano un VPC condiviso possono comunicare in modo efficiente e sicuro Puoi gestire centralmente risorse di rete come subnet, route e firewall in un progetto host, delega le responsabilità amministrative per la creazione e la gestione di singole risorse ai progetti di servizio. Questa separazione dei problemi semplifica l'amministrazione della rete e applica criteri di sicurezza coerenti in tutta l'organizzazione.

Per i sistemi SAP, in genere consigliamo di raggruppare le risorse per tipo di ambiente. Ad esempio, gli ambienti di produzione non devono condividere risorse di calcolo con ambienti non di produzione per fornire un isolamento adeguato, ma puoi utilizzare un VPC condiviso per un livello comune di connettività tra i tuoi progetti. Puoi anche utilizzare VPC indipendenti e utilizzare il peering VPC per connettere i progetti.

Durante la progettazione della rete, inizia con un progetto host contenente una o più reti VPC condiviso. Puoi collegare progetti di servizio aggiuntivi a un progetto host per consentire ai progetti di servizio di partecipare al VPC condiviso. In base alle tue esigenze, puoi eseguire il deployment di SAP Business Suite su un singolo VPC condiviso o più VPC condivisi. I due scenari differiscono in termini di controllo della rete, isolamento dell'ambiente SAP e ispezione della rete:

  • Scenario 1: deployment di SAP Business Suite in un singolo VPC condiviso Ciò semplifica il deployment e riduce l'overhead amministrativo a scapito di un minore isolamento tra le reti.
  • Scenario 2: deployment di SAP Business Suite su più VPC condivisi. Ciò aumenta l'isolamento della rete e aggiunge la sicurezza, a scapito della complessità e del sovraccarico amministrativo.

È anche possibile utilizzare un approccio ibrido. Ad esempio, puoi utilizzare un VPC condiviso per l'ambiente di produzione e un VPC condiviso per tutti i sistemi non di produzione. Per ulteriori informazioni, consulta la sezione "Networking" nell'elenco di controllo generale per SAP su Google Cloud.

Single point of failure

Un sistema SAP Business Suite su SAP ASE o IBM Db2 presenta alcuni single point of failure comuni che possono influire sulla disponibilità del sistema:

  • Servizi centrali SAP come server di messaggi e server di accodamento
  • Server di applicazioni SAP
  • Database SAP ASE o IBM Db2
  • SAP Web Dispatcher, se utilizzato come frontend per l'accesso HTTP/HTTPS al sistema
  • Spazio di archiviazione condiviso come NFS

Esistono diverse opzioni per ridurre l'impatto di questi single point of failure, tra cui il deployment del sistema mediante soluzioni ad alta disponibilità, servizi di replica o l'utilizzo di altre funzionalità che proteggono il sistema dagli errori. Quando pianifichi il tuo sistema SAP Business Suite su SAP ASE o IBM Db2, ti consigliamo di studiare questi single point of failure e di pianificare di conseguenza. Per una panoramica delle soluzioni alternative che puoi utilizzare per gestire i single point of failure, consulta le seguenti sezioni di questa guida:

Disponibilità e continuità

Durante la fase di pianificazione dell'implementazione di un sistema SAP Business Suite su SAP ASE o IBM Db2, devi specificare i seguenti punti dati per definire la disponibilità e la continuità del sistema:

  • Obiettivi del livello di servizio (SLO): un valore target o un intervallo di valori per un livello di servizio misurato da un indicatore del livello del servizio (SLI). Ad esempio, prestazioni, disponibilità e affidabilità.
  • Indicatori del livello del servizio (SLI): metriche, come la latenza, che consentono di misurare le prestazioni di un servizio. È una misura quantitativa ben definita riguardo ad alcuni aspetti del livello di servizio fornito.
  • Accordo sul livello del servizio (SLA): un contratto di servizio tra due parti (fornitore, cliente) che definisce un accordo sul servizio fornito in termini misurabili denominati obiettivi del livello di servizio (SLO).
  • RTO (Recovery Time Objective): la durata massima tollerabile tra un incidente di perdita di dati e la sua mitigazione.
  • RPO (Recovery Point Objective): il Recovery Point Objective (RPO) è la quantità massima di dati che è possibile perdere, misurata in tempo, senza causare danni significativi. In pratica, ciò si traduce nel momento in cui è necessario recuperare lo stato dei dati interessati dopo un evento di perdita di dati.

A seconda dei punti dati e dei valori concordati tra tutte le parti interessate, il sistema SAP Business Suite si basa su funzionalità quali l'alta disponibilità o il ripristino di emergenza:

  • Disponibilità elevata (HA): la funzionalità di un sistema che supporta l'obiettivo della continuità aziendale garantendo al contempo la disponibilità di dati e servizi per gli utenti quando necessario. Il modo abituale per raggiungere questa funzionalità è abilitare la ridondanza, inclusa la ridondanza dell'hardware, della rete e dei data center.
  • Ripristino di emergenza (RE): la capacità di un sistema di essere protetto da interruzioni non pianificate tramite metodi di ripristino affidabili e prevedibili su un hardware e/o un luogo fisico diversi.

Sia l'alta disponibilità che il ripristino di emergenza sono compatibili, ma coprono casi e situazioni diverse. Ad esempio, una soluzione ad alta disponibilità ti consente di continuare le operazioni se si verifica un'interruzione o un tempo di inattività non pianificato per uno degli elementi del sistema senza causare interruzioni agli utenti. Lo stesso si può dire per una soluzione di RE con l'eccezione di avere un'interruzione dal momento dell'interruzione fino a quando la soluzione di RE avvia gli elementi difettosi del sistema in una posizione diversa.

Le sezioni successive forniscono una panoramica delle diverse opzioni a tua disposizione quando pianifichi ed esegui il deployment del tuo sistema SAP Business Suite su SAP ASE o IBM Db2 su Google Cloud.

Tipi di macchina supportati per istanze SAP Business Suite

Google Cloud offre tipi di istanze VM di Compute Engine certificati da SAP per soddisfare i requisiti di dimensionamento quando esegui il deployment di SAP Business Suite con SAP ASE o IBM Db2. Per ulteriori informazioni sul dimensionamento su Google Cloud e sui tipi di macchine supportati, consulta i seguenti documenti:

Pianifica regioni e zone

Quando esegui il deployment di una VM, devi scegliere una regione e una zona. Una regione è una località geografica specifica in cui puoi eseguire le tue risorse e corrisponde a una o più località di data center relativamente vicine tra loro. Ogni regione ha una o più zone con connettività, alimentazione e raffreddamento ridondanti.

È possibile accedere a risorse globali, come immagini disco preconfigurate e snapshot dei dischi, in più regioni e zone. Le risorse a livello di regione, ad esempio indirizzi IP esterni statici a livello di regione, sono accessibili solo alle risorse che si trovano nella stessa regione. Le risorse di zona, come VM e dischi, sono accessibili solo dalle risorse che si trovano nella stessa zona. Per ulteriori informazioni, consulta Risorse globali, a livello di regione e zona.

regioni e zone di Google Cloud.

Quando scegli una regione e una zona per le tue VM, considera quanto segue:

  • La località degli utenti e delle risorse interne, ad esempio il data center o la rete aziendale. Per ridurre la latenza, scegli una località vicina a utenti e risorse.
  • Le piattaforme CPU disponibili per quella regione e zona. Ad esempio, i processori Intel Broadwell, Haswell, Skylake e Ice Lake sono supportati per i carichi di lavoro di SAP NetWeaver su Google Cloud.
  • Assicurati che il server di applicazioni SAP e il database si trovino nella stessa regione.

Opzioni di archiviazione per SAP Business Suite

Di seguito sono riportate le opzioni di archiviazione offerte da Google Cloud certificate da SAP per l'utilizzo con SAP Business Suite e SAP ASE o IBM Db2.

Per informazioni generali sulle opzioni di archiviazione in Google Cloud, consulta Opzioni di archiviazione.

Persistent Disk

  • Disco permanente standard (pd-standard): archiviazione a blocchi efficiente ed economica supportata da unità HDD (hard disk) standard per gestire operazioni sequenziali di lettura e scrittura, ma non ottimizzata per gestire frequenze elevate di operazioni di input-output casuali al secondo (IOPS).
  • SSD Persistent Disk (pd-ssd): offre archiviazione a blocchi affidabile e ad alte prestazioni, supportata da unità a stato solido (SSD).
  • Disco permanente bilanciato (pd-balanced): offre archiviazione a blocchi basata su SSD a costi contenuti ed affidabili.
  • Disco permanente con carico estremo (pd-extreme): basato su SSD; offre opzioni di IOPS e velocità effettiva massimo più elevate rispetto a pd-ssd per tipi di macchine Compute Engine più grandi. Per ulteriori informazioni, consulta Dischi permanenti con carico estremo.

Hyperdisk

  • Hyperdisk Extreme (hyperdisk-extreme): offre opzioni di IOPS e velocità effettiva massimo rispetto ai volumi di Persistent Disk basati su SSD. Puoi selezionare le prestazioni necessarie eseguendo il provisioning delle IOPS, che determina la velocità effettiva. Per ulteriori informazioni, consulta Informazioni su Google Cloud Hyperdisk.

  • Hyperdisk bilanciato (hyperdisk-balanced): la soluzione migliore per la maggior parte dei carichi di lavoro. Consigliamo di utilizzare questa opzione con database che non richiedono le prestazioni di Hyperdisk Extreme. Puoi selezionare le prestazioni di cui hai bisogno eseguendo il provisioning di IOPS e velocità effettiva. Per ulteriori informazioni, consulta Informazioni su Google Cloud Hyperdisk.

Persistent Disk e Hyperdisk sono progettati per un'elevata durabilità. Archiviano i dati in modo ridondante per garantirne l'integrità. Ogni volume di Persistent Disk può archiviare fino a 64 TB, quindi puoi creare volumi logici di grandi dimensioni senza gestire array di dischi. I volumi Hyperdisk consentono inoltre fino a 64 TB di spazio di archiviazione, a seconda del tipo che utilizzi. Una funzionalità chiave è che i volumi Persistent Disk e Hyperdisk vengono criptati automaticamente per proteggere i dati.

Al momento della creazione, un'istanza VM di Compute Engine alloca per impostazione predefinita un singolo Persistent Disk radice o Hyperdisk contenente il sistema operativo. Se necessario, puoi aggiungere altre opzioni di archiviazione all'istanza VM.

Per le implementazioni SAP, esamina le opzioni di archiviazione consigliate in Struttura della directory SAP e opzioni di archiviazione.

Soluzioni di condivisione file

In Google Cloud sono disponibili diverse soluzioni di condivisione file, tra cui:

  • Filestore: archiviazione di file NFS ad alte prestazioni e completamente gestito con disponibilità regionale.
  • Google Cloud NetApp Volumes: una soluzione di archiviazione di file NFS o SMB completamente gestita di Google Cloud.
  • NetApp Cloud Volumes ONTAP: una soluzione di archiviazione intelligente e completa di cui esegui il deployment e che gestisci autonomamente su una VM di Compute Engine.
  • NetApp Cloud Volumes Service per Google Cloud: una soluzione di archiviazione file completamente gestita e ad alte prestazioni di NetApp di cui puoi eseguire il deployment dalla console Google Cloud.

Per ulteriori informazioni sulle soluzioni di condivisione file per SAP Business Suite su Google Cloud, vedi Soluzioni di condivisione file per SAP su Google Cloud.

Cloud Storage per l'archiviazione di oggetti

Cloud Storage è un archivio di oggetti per file di qualsiasi tipo o formato. Dispone di spazio di archiviazione praticamente illimitato e non devi preoccuparti di eseguirne il provisioning o di aggiungere ulteriore capacità. Un oggetto in Cloud Storage contiene dati di file e i metadati associati e può avere una dimensione massima di 5 TB. Un bucket di Cloud Storage può archiviare un numero qualsiasi di oggetti.

È prassi comune utilizzare Cloud Storage per archiviare i file di backup per quasi qualsiasi scopo. Ad esempio, Cloud Storage è ideale per archiviare i backup dei database SAP ASE o IBM Db2. Per informazioni sulla pianificazione del backup del database, consulta Backup e ripristino dei database. Puoi anche utilizzare Cloud Storage nell'ambito di un processo di migrazione.

Inoltre, puoi utilizzare il servizio di backup e RE come soluzione centralizzata per le operazioni di backup e ripristino di emergenza. Questo servizio supporta un ampio spettro di database, tra cui SAP ASE o IBM Db2. Per ulteriori informazioni, consulta Soluzioni di backup e ripristino di emergenza con Google Cloud.

Scegli l'opzione Cloud Storage in base alla frequenza con cui hai bisogno di accedere ai dati. Per l'accesso frequente, ad esempio più volte al mese, seleziona la classe di archiviazione Standard. Per un accesso sporadico, scegli Nearline o Coldline Storage. Per i dati archiviati a cui non prevedi di accesso, seleziona Archive Storage.

Struttura della directory SAP ASE e opzioni di archiviazione

Le seguenti tabelle descrivono le strutture di directory per il sistema SAP Business Suite sul database SAP ASE su Google Cloud.

  • Struttura consigliata della directory Linux per un'istanza SAP ABAP generica:

    Directory Linux Opzione di archiviazione consigliata in Google Cloud
    /sapmnt* Disco permanente bilanciato
    /usr/sap Disco permanente bilanciato

    Nei deployment distribuiti, /sapmnt può anche essere montato come file system di rete utilizzando una soluzione NFS come Filestore.

  • Di seguito è riportata la struttura di directory Linux consigliata per SAP Business Suite su SAP ASE su Google Cloud.

    Tieni presente che tutti i file di dati e di log del database SAP ASE devono trovarsi nella directory /sybase/SAP_SID. Sostituisci SAP_SID con l'identificatore di sistema SAP (SID), ovvero il numero di istanza SAP utilizzato durante l'installazione del database.

    Directory SAP ASE Opzione di archiviazione consigliata in Google Cloud
    /usr/sap Disco permanente bilanciato
    /sybase/SAP_SID/sapdata1 Persistent Disk o Hyperdisk basato su SSD
    /sybase/SAP_SID/log_dir Persistent Disk o Hyperdisk basato su SSD
    /sybase/SAP_SID/saptemp Disco permanente bilanciato
    /sybase/SAP_SID/sapdiag Disco permanente bilanciato

    Per informazioni da SAP sull'esecuzione di SAP ASE, consulta Applicazioni SAP su SAP Adaptive Server Enterprise - Best practice per migrazione e runtime.

  • Di seguito è riportata la struttura consigliata della directory Windows per SAP Business Suite su SAP ASE su Google Cloud. La seguente struttura di directory si applica all'installazione centrale dei server.

    Drive Descrizione Opzione di archiviazione consigliata in Google Cloud
    C:\ Avvio Disco permanente bilanciato
    D:\ File binari del database Disco permanente bilanciato
    E:\ File di dati del database Persistent Disk o Hyperdisk basato su SSD
    L:\ File di log del database Persistent Disk o Hyperdisk basato su SSD
    P:\ File di pagina Disco permanente bilanciato
    S:\ Directory /usr/sap e /sapmnt Disco permanente bilanciato
    T:\ Directory temp e saptemp Disco permanente bilanciato
    X:\ Backup Disco permanente bilanciato

    Per informazioni da SAP sull'esecuzione di SAP ASE, consulta Applicazioni SAP su SAP Adaptive Server Enterprise - Best practice per migrazione e runtime.

Struttura della directory IBM Db2 e opzioni di archiviazione

Le seguenti tabelle descrivono le strutture di directory per il sistema SAP Business Suite sul database IBM Db2 su Google Cloud.

  • Struttura consigliata della directory Linux per SAP Business Suite su IBM Db2 su Google Cloud:

    Struttura della directory IBM Db2 Opzione di archiviazione consigliata in Google Cloud
    /sapmnt Disco permanente bilanciato
    /usr/sap Disco permanente bilanciato
    /db2/DB_SID Disco permanente bilanciato
    /db2/DB_SID/db2dump Disco permanente bilanciato
    /db2/DB_SID/sapdata1 Persistent Disk o Hyperdisk basato su SSD
    /db2/DB_SID/log_dir Persistent Disk o Hyperdisk basato su SSD
    /db2/DB_SID/saptmp1 Disco permanente bilanciato
    /db2backup Disco permanente bilanciato

    Per informazioni da SAP sull'esecuzione di sistemi SAP su IBM Db2, consulta SAP su IBM Db2 per Linux, UNIX e Windows.

  • Di seguito è riportata la struttura di directory Windows consigliata per SAP Business Suite su IBM Db2 su Google Cloud. Questa struttura di directory si applica all'installazione centrale del server.

    Drive Descrizione Opzione di archiviazione consigliata in Google Cloud
    C:\ Avvio Disco permanente bilanciato
    D:\ File binari del database Disco permanente bilanciato
    E:\ File di dati del database Persistent Disk o Hyperdisk basato su SSD
    L:\ File di log del database Persistent Disk o Hyperdisk basato su SSD
    P:\ File di pagina Disco permanente bilanciato
    S:\ Directory /usr/sap e /sapmnt Disco permanente bilanciato
    T:\ Directory temp e saptemp Disco permanente bilanciato
    X:\ Backup Disco permanente bilanciato

    Per ulteriori informazioni sulle strutture delle directory, consulta la Guida alla pianificazione di SAP NetWeaver. Per informazioni sul calcolo delle dimensioni del file di pagina, vedi la nota SAP 1518419: file di pagina e memoria virtuale richieste dal sistema SAP.

Supporto dei sistemi operativi per SAP Business Suite

Quando scegli un sistema operativo per SAP NetWeaver su Google Cloud, oltre a confermare che la versione del sistema operativo è certificata da SAP, devi anche verificare che tutte e tre le società, SAP, il fornitore del sistema operativo e Google Cloud, supportino ancora la versione del sistema operativo.

La decisione deve prendere in considerazione anche i seguenti aspetti:

  • Indica se una determinata versione del sistema operativo è disponibile in Google Cloud. Le immagini del sistema operativo fornite da Compute Engine sono configurate per funzionare con Google Cloud. Se non è disponibile un sistema operativo in Google Cloud, puoi utilizzare la tua immagine del sistema operativo (BYOI) e la tua licenza. Le immagini del sistema operativo BYOI sono definite immagini personalizzate da Compute Engine.
  • Le opzioni di licenza disponibili per una determinata versione del sistema operativo. Verifica se per la versione del sistema operativo è disponibile un'opzione di licenza on demand o se hai bisogno di portare il tuo abbonamento (BYOS) dal fornitore del sistema operativo.
  • Indica se le funzionalità integrate ad alta disponibilità di una determinata versione del sistema operativo sono abilitate per Google Cloud.
  • L'opzione di sconto per impegno di utilizzo per le immagini SLES for SAP e RHEL for SAP.

I seguenti sistemi operativi sono certificati da SAP per l'utilizzo con SAP NetWeaver su Google Cloud:

Puoi trovare ulteriori informazioni su versioni specifiche del sistema operativo e sulla loro compatibilità con SAP Business Suite e SAP ASE o IBM Db2 nelle seguenti guide:

Architettura di deployment per SAP ASE

SAP ASE è un componente chiave di qualsiasi sistema SAP Business Suite perché rappresenta uno dei possibili tipi di database per il sistema.

Il seguente diagramma mostra un'architettura di deployment per SAP ASE su Google Cloud. Nel diagramma, prendi nota di entrambi: il deployment su Google Cloud e il layout del disco. Puoi utilizzare Cloud Storage per eseguire il backup dei backup locali disponibili in /sybasebackup. Le dimensioni di questo montaggio devono essere uguali o superiori a quelle del montaggio dati.

Diagramma dell'architettura per il deployment di SAP ASE su Google Cloud.

Architettura di deployment per IBM Db2

IBM Db2 è un componente fondamentale di qualsiasi sistema SAP Business Suite perché rappresenta uno dei possibili tipi di database per il sistema.

Il seguente diagramma mostra un'architettura di deployment per IBM Db2 su Google Cloud. Nota sia il deployment su Google Cloud che il layout del disco nel diagramma. Puoi utilizzare Cloud Storage per eseguire il backup dei backup locali disponibili in /db2backup. Le dimensioni di questo montaggio devono essere uguali o superiori a quelle del montaggio dati.

Diagramma dell'architettura per il deployment di IBM Db2 su Google Cloud.

Architettura di deployment per SAP Business Suite

Come menzionato nella sezione Architettura, sono disponibili diverse architetture di deployment che puoi utilizzare per eseguire il deployment di SAP Business Suite su SAP ASE o IBM Db2 su Google Cloud.

Architettura a due livelli

Questa architettura è presentata nella sezione relativa al deployment centralizzato. Il seguente diagramma mostra alcuni dettagli di un'architettura a due livelli per SAP Business Suite in esecuzione su una VM di Compute Engine:

Architettura a due livelli per SAP Business Suite su SAP ASE o IBM Db2 su una VM di Compute Engine su Google Cloud.

Architettura a tre livelli

Questa architettura è presentata nella sezione Deployment distribuito. Puoi utilizzare questa architettura per eseguire il deployment di sistemi SAP Business Suite ad alta disponibilità. Il seguente diagramma mostra alcuni dettagli di un'architettura a tre livelli per SAP Business Suite in esecuzione su VM di Compute Engine:

Architettura a tre livelli per SAP Business Suite su SAP ASE o IBM Db2 su una VM di Compute Engine su Google Cloud.

In questa architettura, il sistema SAP Business Suite distribuisce il lavoro su più server applicazioni NetWeaver, ognuno ospitato su una VM separata. Tutti i nodi NetWeaver AS condividono lo stesso database, che è ospitato su una VM separata. Tutti i nodi NetWeaver AS montano e accedono a un file system condiviso che ospita i profili SAP NetWeaver. Questo file system condiviso è ospitato su un volume di Persistent Disk condiviso tra tutti i nodi o su una soluzione di condivisione file supportata.

Sicurezza, privacy e conformità

Questa sezione fornisce informazioni su sicurezza, privacy e conformità per l'esecuzione di SAP Business Suite su SAP ASE o IBM Db2 su Google Cloud.

Conformità e controlli di sovranità

Se richiedi l'esecuzione del tuo carico di lavoro SAP in conformità con i requisiti di residenza dei dati, controllo dell'accesso, personale di assistenza o normativi, devi pianificare l'utilizzo di Assured Workloads, un servizio che ti consente di eseguire carichi di lavoro sicuri e conformi su Google Cloud senza compromettere la qualità dell'esperienza cloud. Per ulteriori informazioni, consulta Conformità e controlli di sovranità per SAP su Google Cloud.

Networking e sicurezza della rete

Considera le informazioni nelle sezioni seguenti quando pianifichi il networking e la sicurezza di rete.

Modello di privilegi minimi

Una delle prime linee di difesa è quella di limitare gli utenti che possono raggiungere la rete e le VM. Per farlo, puoi utilizzare le regole firewall VPC. Per impostazione predefinita, tutto il traffico verso le VM, anche da altre VM, viene bloccato dal firewall, a meno che non crei regole per consentire l'accesso. L'eccezione è la rete predefinita che viene creata automaticamente con ogni progetto e dispone di regole firewall predefinite.

Creando regole firewall VPC, puoi limitare tutto il traffico su un determinato insieme di porte a indirizzi IP di origine specifici. Per limitare l'accesso a indirizzi IP, protocolli e porte specifici che richiedono l'accesso, segui il modello di privilegio minimo. Ad esempio, configura sempre un bastion host e consenti le comunicazioni SSH con il sistema SAP NetWeaver solo da quell'host.

Reti personalizzate e regole firewall

Puoi utilizzare una rete per definire un IP gateway e l'intervallo di rete per le VM collegate alla rete. Tutte le reti Compute Engine utilizzano il protocollo IPv4. A ogni progetto Google Cloud è assegnata una rete predefinita con configurazioni predefinite e regole firewall, ma ti consigliamo di aggiungere una subnet personalizzata e di aggiungere regole firewall in base a un modello di privilegi minimi. Per impostazione predefinita, una rete appena creata non ha regole firewall e quindi non ha accesso alla rete.

Ti consigliamo di aggiungere più di una subnet per isolare parti della rete o soddisfare altri requisiti. Per ulteriori informazioni, consulta Reti e subnet.

Le regole firewall si applicano all'intera rete e a tutte le VM al suo interno. Puoi aggiungere una regola firewall che consente il traffico tra le VM nella stessa rete e tra le subnet. Puoi anche configurare i firewall da applicare a specifiche VM di destinazione utilizzando i tag di rete.

SAP richiede l'accesso a determinate porte, quindi aggiungi regole firewall per consentire l'accesso alle porte delineate da SAP.

Route

Le route sono risorse globali collegate a una singola rete. Le route create dall'utente si applicano a tutte le VM in una rete. Ciò significa che puoi aggiungere una route che inoltra il traffico da una VM a una VM all'interno della stessa rete e tra subnet senza richiedere indirizzi IP esterni.

Per l'accesso esterno alle risorse internet, avvia una VM senza indirizzi IP esterni e configura un'altra VM come gateway NAT. Questa configurazione richiede l'aggiunta del gateway NAT come route per l'istanza SAP.

Bastion host e gateway NAT

Se il criterio di sicurezza richiede VM effettivamente interne, devi configurare manualmente un proxy NAT sulla rete e una route corrispondente in modo che le VM possano raggiungere internet. È importante notare che non puoi connetterti direttamente a un'istanza VM completamente interna tramite SSH.

Per connetterti a queste macchine interne, devi configurare un'istanza bastion che abbia un indirizzo IP esterno e quindi eseguirne il tunnel. Quando le VM non hanno indirizzi IP esterni, possono essere raggiunte solo da altre VM sulla rete o tramite un gateway VPN gestito. Puoi eseguire il provisioning delle VM nella tua rete in modo che agiscano come relè attendibili per le connessioni in entrata, chiamati bastion host o server in uscita dalla rete, chiamati gateway NAT. Per una connettività più trasparente senza configurare queste connessioni, puoi utilizzare una risorsa gateway VPN gestito.

Bastion host per connessioni in entrata

I bastion host forniscono un punto di ingresso rivolto verso l'esterno in una rete contenente VM di reti private. Questo host può fornire un unico punto di fortificazione o controllo e può essere avviato e arrestato per attivare o disattivare la comunicazione SSH in entrata da internet.

Visualizzazione del bastion host nello scenario SSH.

L'accesso SSH alle VM che non hanno un indirizzo IP esterno può essere ottenuto con una connessione a un bastion host. Il rafforzamento completo di un bastion host non rientra nell'ambito di questo documento, ma alcuni passaggi iniziali possono includere:

  • Limita l'intervallo CIDR degli IP di origine che possono comunicare con il bastion.
  • Configura le regole del firewall per consentire il traffico SSH alle VM private solo dal bastion host.

Per impostazione predefinita, SSH sulle VM è configurato in modo da utilizzare chiavi private per l'autenticazione. Quando utilizzi un bastion host, devi prima accedere al bastion host, quindi alla VM privata di destinazione. A causa di questo accesso in due passaggi, ti consigliamo di utilizzare l'inoltro dell'agente SSH per raggiungere la VM di destinazione anziché archiviare la chiave privata della VM di destinazione sul bastion host. Devi eseguire questa operazione anche se utilizzi la stessa coppia chiave-valore sia per le VM bastion che per le VM di destinazione, perché il bastion ha accesso diretto solo alla metà pubblica della coppia di chiavi.

Gateway NAT per il trasferimento di dati in uscita

Quando una VM non ha un indirizzo IP esterno assegnato, non può stabilire connessioni dirette a servizi esterni, inclusi altri servizi Google Cloud. Per consentire a queste VM di raggiungere i servizi su internet, puoi impostare e configurare un gateway NAT. Il gateway NAT è una VM che può instradare traffico per conto di qualsiasi altra VM sulla rete. Usa un gateway NAT per rete. Un gateway NAT a VM singola non è ad alta disponibilità e non può supportare una velocità effettiva di traffico elevata per più VM. Per informazioni su come configurare una VM in modo che agisca come gateway NAT, consulta la guida al deployment per il tuo sistema operativo:

Cloud VPN

Puoi connettere in modo sicuro la tua rete esistente a Google Cloud tramite una connessione VPN che utilizza IPsec tramite Cloud VPN. Il traffico tra le due reti viene criptato da un gateway VPN, quindi viene decriptato dall'altro gateway VPN. In questo modo i dati sono protetti mentre vengono trasferiti su internet. Puoi controllare dinamicamente quali VM possono inviare traffico attraverso la VPN utilizzando i tag di istanza sulle route. I tunnel Cloud VPN vengono fatturati con una tariffa mensile statica più gli addebiti standard per il trasferimento di dati in uscita. Tieni presente che il collegamento di due reti nello stesso progetto comporta comunque addebiti standard per il trasferimento di dati in uscita. Per ulteriori informazioni, vedi:

Sicurezza per i bucket Cloud Storage

Se utilizzi Cloud Storage per ospitare i backup dei tuoi volumi di dati e di log, assicurati di utilizzare TLS (HTTPS) durante l'invio dei dati a Cloud Storage dalle tue VM per proteggere i dati in transito.

Sebbene Cloud Storage cripta automaticamente i dati at-rest, puoi specificare le tue chiavi di crittografia se hai un tuo sistema di gestione delle chiavi.

Limiti per le notifiche via email

Per contribuire a proteggere i tuoi sistemi e quelli di Google da comportamenti illeciti, Google Cloud applica limitazioni all'invio di email da Compute Engine. Ciò ha implicazioni per la transazione SCOT sui sistemi SAP NetWeaver ABAP, perché richiede una configurazione specifica rispetto ai sistemi on-premise.

Per ulteriori informazioni, incluse quelle sulla configurazione di SCOT, consulta Invio di email da un'istanza.

Per ulteriori informazioni sulle risorse di sicurezza per il tuo ambiente SAP su Google Cloud, consulta le seguenti risorse:

Affidabilità

Questa sezione fornisce informazioni sugli aspetti relativi all'affidabilità dell'esecuzione di SAP Business Suite su SAP ASE o IBM Db2 su Google Cloud.

Alta disponibilità e ripristino di emergenza

L'alta disponibilità (HA) e il ripristino di emergenza (RE) sono insiemi di tecniche, pratiche di progettazione e principi di progettazione per consentire la continuità aziendale in caso di errori. Questi approcci funzionano eliminando i single point of failure e offrendo la possibilità di riprendere rapidamente le operazioni dopo un'interruzione del sistema o di un componente con interruzioni minime dell'attività. Il ripristino da errori è il processo di ripristino e ripristino delle operazioni dopo un'interruzione a causa di un componente guasto.

Ad esempio, di seguito sono riportati alcuni strumenti di alta disponibilità e RE che puoi utilizzare:

Alta disponibilità SAP ASE

Puoi ottenere una disponibilità elevata per il tuo database SAP ASE su Google Cloud configurando la replica sincrona tra i server principali e in standby, in modo che i due server siano sempre sincronizzati senza perdita di dati. L'opzione SAP ASE sempre attiva, che è un sistema ad alta disponibilità e ripristino di emergenza (HADR), è supportata su Google Cloud. Per ulteriori informazioni, consulta la guida alla pianificazione di SAP ASE.

Le istanze VM che ospitano i server principali e in standby devono avere i seguenti componenti:

  • SAP ASE
  • SAP Host Agent, che monitora l'utilizzo di CPU, memoria e altre risorse da parte del server.
  • Agente di gestione della replica (RMA)
  • SAP ASE Cockpit, che esegue attività di database
  • Fault Manager, che ha il proprio server host. Monitora i server SAP ASE primari e in standby. Fault Manager garantisce l'alta disponibilità di SAP ASE avviando il failover automatico. Monitora i seguenti componenti: RMA, server di replica, applicazioni, database e sistema operativo. Consente inoltre di verificare l'integrità del database e riavviarlo se necessario.

Per una migliore disponibilità del sistema, un cluster SAP ASE consente lo spostamento dei carichi di lavoro nel nodo secondario mediante il monitoraggio di eventuali errori del nodo primario. Il seguente diagramma mostra un'architettura di riferimento di alto livello che mostra come i componenti SAP ASE descritti possono essere installati su Google Cloud.

Architettura per un sistema ad alta disponibilità SAP ASE su Google Cloud

Ripristino di emergenza SAP ASE

Il sistema HADR SAP ASE con nodi per il ripristino di emergenza (RE) è costituito da tre server SAP ASE:

  • Server principale: questo server gestisce l'elaborazione di tutte le transazioni.
  • Nodo standby: questo server funge da "hot standby" per il server principale e contiene copie dei database designati dal server principale.
  • Nodo RE: questo server è geograficamente distante ed esegue il backup dei database designati dal server principale.

Il seguente diagramma mostra il flusso del ripristino di emergenza di SAP ASE:

Architettura per un sistema SAP ASE su Google Cloud con ripristino di emergenza

Disponibilità elevata e ripristino di emergenza di IBM Db2

Puoi ottenere l'alta disponibilità e il ripristino di emergenza (HADR) per il tuo database IBM Db2 come segue:

  • Devi eseguire il deployment di due istanze separate del tuo database IBM Db2: una principale e l'altra in standby. Devi mantenerli sincronizzati. Se l'istanza principale non riesce, l'istanza in standby supporta il carico di lavoro.

    L'istanza principale gestisce le connessioni e le transazioni client e le registra nei log. Questi log vengono inviati tramite TCP/IP al server in standby, che li utilizza per aggiornare il database, rimanendo sincronizzati con l'istanza principale.

  • Poiché l'HADR non dispone di automazione e rilevamento degli errori, devi anche eseguire il deployment di Pacemaker. Pacemaker monitora entrambe le istanze e, in caso di arresto anomalo dell'istanza principale, attiva il takeover ad alta disponibilità da parte dell'istanza in standby, garantendo che l'indirizzo IP mobile venga assegnato alla nuova istanza principale.

    Il pacemaker gestisce la gestione dei cluster e un VIP viene utilizzato insieme al bilanciatore del carico delle applicazioni interno per instradare le richieste dell'applicazione all'istanza principale.

Architettura per un sistema IBM Db2 su Google Cloud con disponibilità elevata e ripristino di emergenza

Ottimizzazione dei costi

Questa sezione fornisce informazioni su licenze, sconti e stima delle dimensioni del carico di lavoro.

Licenze

Se sei un cliente SAP, puoi utilizzare la licenza esistente per eseguire il deployment di SAP SAP Business Suite su Google Cloud in base a un modello BYOL (Bring Your Own License). Google Cloud supporta il modello BYOL per i casi d'uso di produzione e non di produzione. Le licenze del sistema operativo sono incluse nei prezzi di Compute Engine.

In alternativa, puoi utilizzare anche la tua immagine del sistema operativo e le tue licenze. Per maggiori informazioni, vedi Immagini del sistema operativo personalizzate.

Per informazioni sulla licenza per SAP ASE su Google Cloud, consulta la sezione "Licenze SAP" nella guida alla pianificazione di SAP ASE.

Per eseguire il deployment di IBM Db2 per SAP su Google Cloud, devi utilizzare la tua licenza. Puoi ottenere una licenza da SAP o da IBM. Per ulteriori informazioni su licenze e supporto, vedi la nota SAP 1168456 - DB6: Support Process and End of Support Dates for IBM Db2 LUW.

Sconti

Con il modello di determinazione del prezzo con pagamento a consumo di Google Cloud, paghi solo per i servizi che utilizzi. Non è necessario impegnarsi per una dimensione o un servizio particolare; puoi modificare o interrompere l'utilizzo in base alle tue esigenze. Per carichi di lavoro prevedibili, Compute Engine offre sconti per impegno di utilizzo (CUD) che consentono di ridurre il costo dell'infrastruttura tramite la sottoscrizione di un contratto che consente di ottenere prezzi di utilizzo delle VM molto scontati.

Google Cloud offre questi sconti in cambio dell'acquisto di contratti basati su impegno di utilizzo, noti anche come impegni. Quando acquisti un impegno, ti impegni per un utilizzo minimo delle risorse o per un importo minimo di spesa per un periodo specificato di uno o tre anni. Questi sconti ti consentono di ridurre la fatturazione mensile per le risorse utilizzate dal sistema SAP Business Suite. Per maggiori informazioni, consulta Sconti per impegno di utilizzo (CUD).

Stime delle dimensioni

Le risorse riportate di seguito forniscono informazioni su come eseguire stime delle dimensioni per i sistemi SAP prima di eseguirne la migrazione a Google Cloud:

Efficienza operativa

Questa sezione fornisce informazioni su come ottimizzare l'efficienza operativa di SAP Business Suite su SAP ASE o IBM Db2 su Google Cloud.

Backup e ripristino

Crea regolarmente backup del server delle applicazioni e del database, in modo da poter eseguire il ripristino in caso di arresto anomalo del sistema, danneggiamento dei dati o qualsiasi altro problema.

Hai a disposizione diverse opzioni per eseguire il backup dei tuoi dati SAP ASE o IBM Db2 su Google Cloud, tra cui:

Esegui il backup e recupera SAP ASE

Puoi utilizzare le seguenti opzioni per eseguire il backup e il ripristino di un database IBM Db2 su Google Cloud:

  • Backup e ripristino tramite dischi: puoi utilizzare i meccanismi flessibili di backup e ripristino di SAP ASE in combinazione con i tipi di Persistent Disk e Hyperdisk forniti da Compute Engine. Per archiviare i backup per un periodo più lungo, puoi utilizzare Cloud Storage.

    Il seguente diagramma mostra in che modo i dischi e Cloud Storage vengono utilizzati per archiviare i backup per un database SAP ASE:

    Diagramma che mostra il backup dei dati SAP ASE su dischi e Cloud Storage

  • Backup e ripristino mediante snapshot di dischi: un'altra opzione che puoi aggiungere alla tua strategia di backup consiste nell'acquisizione di snapshot di interi dischi utilizzando la funzionalità Istantanea del disco di Compute Engine. Ad esempio, puoi creare snapshot pianificati del disco che ospita la directory /sybasebackup da utilizzare in scenari di ripristino di emergenza. Puoi utilizzare gli snapshot dei dischi anche per eseguire il backup e il recupero del volume di dati SAP ASE. Per garantire la coerenza dell'applicazione, crea snapshot quando non vengono apportate modifiche al volume di destinazione. Gli snapshot si verificano a livello di blocco.

    Dopo il primo snapshot, ogni snapshot successivo è incrementale e archivia solo le modifiche dei blocchi incrementali, come mostrato nel seguente diagramma:

    Diagramma che mostra il backup di dati SAP ASE tramite snapshot di dischi.

Esegui il backup di un database IBM Db2

Puoi eseguire il backup di un database IBM Db2 utilizzando una delle seguenti opzioni:

  • Utilizzare le modalità online e offline fornite da IBM:
    • Modalità online: in questa modalità, gli utenti possono continuare a lavorare durante la creazione del backup del database.
    • Modalità offline: in questa modalità, il database viene arrestato completamente, rendendolo non disponibile per gli utenti durante la creazione del backup.

  • Esegui il backup e recupera il database IBM Db2 utilizzando snapshot del disco: un'altra opzione che puoi aggiungere alla tua strategia di backup è creare snapshot di interi dischi utilizzando la funzionalità Istantanea del disco di Compute Engine. Ad esempio, puoi creare snapshot pianificati del disco che ospita la directory /db2backup da utilizzare in scenari di ripristino di emergenza. Puoi utilizzare gli snapshot dei dischi anche per eseguire il backup e il recupero del volume di dati IBM Db2. Per garantire la coerenza dell'applicazione, crea snapshot quando non vengono apportate modifiche al volume di destinazione. Gli snapshot si verificano a livello di blocco.

    Dopo il primo snapshot, ogni snapshot successivo è incrementale e archivia solo le modifiche dei blocchi incrementali, come mostrato nel seguente diagramma:

    Diagramma che mostra il backup di dati SAP ASE tramite snapshot di dischi.

Il processo per la creazione del backup del database dipende dal numero di partizioni del database IBM Db2:

  • Database a partizione singola: in questa configurazione puoi creare un backup completando questi passaggi:

    1. Accedi al server del tuo database in qualità di utente db2DB_SID.

    2. Esegui questo comando:

      db2 backup db DB_SID

      Sostituisci DB_SID con l'identificatore di sistema del database (SID).

  • Database multipartizione: in questa configurazione, puoi creare un backup completando questi passaggi:

    1. Accedi al server del tuo database in qualità di utente db2DB_SID.

    2. Esegui questo comando:

      db2 "backup db DB_SID on ALL DBPARTITIONNUMS..."

      Sostituisci DB_SID con l'identificatore di sistema del database (SID).

    Puoi anche utilizzare lo strumento DBA Cockpit fornito da IBM per creare un backup del database. Per ulteriori informazioni sul backup di un database IBM Db2, vedi il documento SAP Esecuzione di un backup del database.

Recupera un database IBM Db2

Puoi ripristinare il database IBM Db2 dopo un backup riuscito. Il ripristino del database dipende dall'accessibilità a un file di cronologia aggiornato, perché da lì è possibile accedere a tutte le informazioni sulle immagini di backup e sui file di log.

  • Per ripristinare il tuo database IBM Db2 da un backup, completa questi passaggi:

    1. In qualità di utente db2DB_SID o SAP_SIDadm, accedi al server del database.

    2. Esegui questo comando:

      db2 RECOVER DB DB_SID

      Sostituisci DB_SID con l'identificatore di sistema del database (SID).

  • Per ripristinare il tuo database IBM Db2 in un momento specifico, completa questi passaggi:

    1. In qualità di utente db2DB_SID o SAP_SIDadm, accedi al server del database.

    2. Esegui questo comando:

      db2 RECOVER DB DB_SID to LOCAL_TIME_ON_DB_SERVER

      Sostituisci quanto segue:

      • DB_SID: identificatore di sistema del database (SID)
      • LOCAL_TIME_ON_DB_SERVER: l'ora locale sul server del database

    Per ulteriori informazioni sul recupero di un database IBM Db2, consulta il documento SAP Ripristino del database utilizzando il comando RECOVER.

Monitoraggio

Per monitorare e fornire assistenza per i carichi di lavoro SAP in esecuzione su istanze VM di Compute Engine e server Bare Metal Solution, Google Cloud fornisce l'agente per SAP.

Come richiesto da SAP, per ricevere assistenza da SAP e consentire a SAP di rispettare i suoi accordi sul livello del servizio (SLA), devi installare Agente di Google Cloud per SAP su tutte le istanze VM di Compute Engine e sui server Bare Metal Solution che eseguono qualsiasi sistema SAP. Per ulteriori informazioni sui prerequisiti di assistenza, vedi la nota SAP SAP Note 2456406 - SAP on Google Cloud Platform: Support Prerequisites.

Oltre alla raccolta obbligatoria delle metriche dell'agente host SAP, su Linux, l'agente di Google Cloud per SAP include funzionalità facoltative come la raccolta di metriche di monitoraggio dei processi e metriche di valutazione di Workload Manager. Puoi attivare queste funzionalità che abilitano prodotti e servizi come la gestione dei carichi di lavoro per i carichi di lavoro SAP.

Ottimizzazione delle prestazioni

Questa sezione fornisce informazioni sull'ottimizzazione delle prestazioni dei carichi di lavoro SAP Business Suite attraverso il dimensionamento e la configurazione della rete.

Dimensionamento

Sono disponibili diverse opzioni di dimensionamento in base al tipo di implementazione. Per le implementazioni greenfield, consigliamo di utilizzare lo strumento SAP Quick Sizer. Per informazioni più dettagliate, vedi la pagina sulle dimensioni di SAP. SAP fornisce inoltre guide per le t-shirt relative a soluzioni e strumenti specifici per la migrazione delle soluzioni on-premise attuali a Google Cloud. Ad esempio, consulta la nota su SAP SAP Note 2456432 - SAP Applications on Google Cloud: Protected Products and Google Cloud machine types . SAP e Google Cloud usano diverse unità per misurare le IOPS operazioni di I/O al secondoo). Consulta il tuo partner SI (integratore di sistemi) per convertire i requisiti di dimensionamento SAP in un'infrastruttura Google Cloud di dimensioni adeguate.

Per dimensionare un database SAP ASE, consulta il documento SAP Dimensioni di SAP ASE.

Per dimensionare un database IBM Db2, consulta il benchmark delle dimensioni SAP.

Per informazioni sui requisiti hardware per l'esecuzione di SAP ASE o IBM Db2 con diversi sistemi operativi e versioni di SAP NetWeaver, consulta il documento SAP Guide Finder per SAP NetWeaver e ABAP Platform.

Configurazione di rete

Le funzionalità di rete delle VM di Compute Engine sono determinate dalla famiglia di macchine e non dall'interfaccia di rete (NIC) o dall'indirizzo IP.

In base al tipo di macchina, l'istanza VM può raggiungere una velocità effettiva di rete da 2 a 32 Gbps. Alcuni tipi di macchine supportano anche velocità effettiva fino a 100 Gbps, che richiede l'utilizzo del tipo di interfaccia NIC virtuale Google (gVNIC) con una configurazione di rete Tier_1. La capacità di raggiungere queste velocità di velocità effettiva dipende ulteriormente dalla direzione del traffico e dal tipo di indirizzo IP di destinazione.

Le interfacce di rete delle VM di Compute Engine sono supportate da un'infrastruttura di rete ridondante e resiliente che utilizza componenti di rete fisici e software-defined. Queste interfacce ereditano la ridondanza e la resilienza della piattaforma sottostante. Per la separazione del traffico possono essere utilizzate più NIC virtuali, ma questo non offre ulteriori vantaggi in termini di resilienza o prestazioni.

Un singolo NIC fornisce le prestazioni necessarie per i deployment SAP ASE o IBM Db2 su Compute Engine. Il tuo caso d'uso, i tuoi requisiti di sicurezza o le tue preferenze particolari potrebbero richiedere interfacce aggiuntive per separare il traffico, come il traffico internet, il traffico di replica SAP ASE interno o IBM Db2 HADR o altri flussi che potrebbero trarre vantaggio da regole dei criteri di rete specifiche. Ti consigliamo di utilizzare la crittografia del traffico offerta dall'applicazione e di proteggere l'accesso alla rete mediante un criterio firewall con privilegi minimi per limitare l'accesso.

Considera la necessità di separare il traffico fin dalle prime fasi nella progettazione della tua rete e alloca NIC aggiuntive quando esegui il deployment delle VM. Devi collegare ciascuna interfaccia di rete a una rete VPC diversa. La scelta per il numero di interfacce di rete dipende dal livello di isolamento richiesto, con fino a 8 interfacce consentite per VM con 8 o più vCPU.

Per ulteriori informazioni, vedi:

Deployment

Questa sezione fornisce informazioni relative al deployment di SAP Business Suite su SAP ASE o IBM Db2 su Google Cloud.

Note importanti su SAP pre-deployment

Prima di iniziare a eseguire il deployment di un sistema SAP Business Suite su Google Cloud, leggi le seguenti note SAP. Inoltre, prima di iniziare un'implementazione SAP, controlla in SAP Marketplace le guide e le note aggiornate per l'installazione dei prodotti.

Per ulteriori informazioni sull'installazione di SAP ASE o IBM Db2, consulta le seguenti risorse:

Automazione del deployment

Automatizza il deployment di SAP ASE

Per automatizzare il deployment dell'infrastruttura richiesta per eseguire SAP ASE e SAP NetWeaver su Linux su Google Cloud, puoi utilizzare le configurazioni Terraform fornite da Google Cloud. Per ulteriori informazioni, consulta le guide al deployment per il tuo scenario.

Per informazioni sulla pianificazione del deployment di SAP ASE, consulta:

Automatizza il deployment di IBM Db2

Per automatizzare il deployment dell'infrastruttura richiesta per eseguire IBM Db2 e SAP NetWeaver su Linux su Google Cloud, puoi utilizzare le configurazioni Terraform fornite da Google Cloud. Per ulteriori informazioni, consulta le guide al deployment per il tuo scenario.

Per informazioni sulla pianificazione del deployment di SAP ASE, consulta:

Passaggi successivi