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

Questa architettura di riferimento è destinata a chi valuta Google Cloud come piattaforma per il deployment di applicazioni SAP Business Suite su SAP ASE o IBM Db2. Comprende considerazioni durante la fase di pianificazione, modelli di deployment e automazione e procedure operative comuni come il backup e RE.

Google Cloud offre costi contenuti, affidabili, sicuri e infrastruttura 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 per 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 distribuite con disponibilità elevata.

Deployment centralizzato

In un deployment centralizzato, puoi installare SAP Business Suite e SAP ASE o IBM Db2 sulla stessa istanza VM di Compute Engine. Lo consigliamo per ambienti non di produzione come sandbox e sviluppo ambienti cloud-native.

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 modello il deployment di SAP Business Suite su SAP ASE. Tieni presente che SAP ASCS, PAS, WD e siano tutti 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 modello deployment di SAP Business Suite su IBM Db2. Tieni presente che SAP ASCS, PAS, WD e siano tutti 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 diverse istanze di Compute Engine. Consigliamo questo approccio di produzione o ambienti che richiedono molta potenza di calcolo per gestire grandi carichi di 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 tutte installate 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 tutte installate 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 vengono configurati tra zone diverse per evitare errori dei componenti in una data regione. Puoi il deployment di un cluster Linux in più zone utilizzando una configurazione attiva/passiva. Nel in entrambi i casi, la prima cosa da fare è configurare due istanze VM di Compute Engine zone separate per la massima ridondanza, ciascuna con il proprio SAP ASE o IBM Db2 per configurare un database.

  • Deployment distribuito di SAP ASE con disponibilità elevata: puoi eseguire il deployment database SAP ASE ad alta disponibilità e a tolleranza di emergenza (HADR) Google Cloud supportato da SAP. Per ulteriori informazioni, vedi 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 sia dal lato applicazione che dal 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 caratteristiche:

    • Tre VM host, due host ciascuna con un'istanza di database e una con errore Gestore.
    • Replica sincrona di SAP ASE.
    • Gestore delle risorse del cluster ad alta disponibilità Pacemaker.
    • un meccanismo di recinzione che utilizzi Fault Manager per garantire l’isolamento di un guasto delle risorse con errori.
    • Il riavvio automatico dell'istanza non riuscita come nuova istanza secondaria e nuova registrazione automatica per la replica SAP ASE.

  • Implementazione distribuita di IBM Db2 con disponibilità elevata: puoi eseguire il deployment di un database IBM Db2 ad alta disponibilità e a tolleranza di emergenza (HADR) Google Cloud supportato da SAP. Per ulteriori informazioni, vedi Guida alla pianificazione di IBM Db2 per SAP.

    Puoi configurare un cluster HADRPacemakercluster a due host utilizzando il cluster fornita da IBM per Db2. Per ulteriori informazioni, vedi il PDF SAP Guida all'amministrazione di 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 disponibilità elevata sia sia dal lato applicazione che dal 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 caratteristiche:

    • 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.
    • Il 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 servizi centrali di SAP ABAP (ASCS) e il server di replica in coda (EQUE Replicator, replicatore di coda) utilizzati per fornire SAP Business Suite alta disponibilità nel caso in cui succeda qualcosa agli ASCS delle istanze ERS.

In base La versione di SAP NetWeaver utilizzata con il sistema SAP Business Suite, vengono eseguiti il server di accodamento e il server di replica di accodamento / Replicatore di coda su un'altra versione:

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

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

Dettagli sul deployment del sistema ad alta disponibilità e di Linux il clustering in più zone, verrà trattato più avanti in questo documento.

Nota sul bilanciamento del carico

In una suite SAP Business distribuita su SAP ASE o IBM Db2 il bilanciamento del carico è obbligatorio. Puoi configurare il carico dell'applicazione utilizzando una combinazione di livelli di applicazione SAP Bilanciatori del carico di rete. Per ulteriori informazioni, vedi Implementazioni VIP del bilanciatore del carico di rete passthrough interno della guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su in Google Cloud.

Componenti del deployment

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

  • Database SAP ASE o IBM Db2
  • Fault Manager, solo su SAP ASE
    • Ha il proprio server host e monitora le istanze principali e in standby server web. Fault Manager garantisce l'alta disponibilità di SAP ASE iniziando il failover automatico. Monitora i seguenti componenti: replica Agente di gestione, server di replica, applicazioni, database e sistemi operativi di un sistema operativo completo. Consente anche di verificare l'integrità del database e riavviare se necessario.
  • ASCS: servizi centrali SAP ABAP
    • Contiene il server dei messaggi e il server di accodamento, richiesti in in qualsiasi sistema SAP ABAP.
    • Distribuito sulla propria istanza VM in deployment ad alta disponibilità oppure sull'istanza VM che ospita il PAS.
    • Nei deployment ad alta disponibilità, le risorse ASCS sono gestite da un cluster Linux di risorse 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 in caso succede 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 maggiore disponibilità da un livello di applicazione punto di vista. Se uno dei server delle applicazioni non funziona, tutti le sessioni utente connesse al server delle applicazioni vengono terminate, possano accedere nuovamente all'altro AAS nell'ambiente.
  • Gateway SAP NetWeaver
    • Distribuito come sistema autonomo o come parte Sistema SAP Business Suite.
    • Consente al sistema di connettere dispositivi, ambienti e piattaforme a Sistemi SAP che utilizzano Open Data Protocol (OData).
  • Server front-end SAP Fiori
    • Distribuito come sistema autonomo o come parte 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 HTTP e HTTPS in base al tipo di richiesta, a PAS e AAS.

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

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 un intervallo IP globale o una rete di subnet consigliata, in cui l'istanza VM un 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 ma un progetto Google Cloud può avere più reti VPC.

Per collegare le risorse di più progetti a un sulla rete VPC, puoi utilizzare VPC condiviso, in modo che possono comunicare tra loro in modo sicuro ed efficiente utilizzando indirizzi IP interni di quella rete. Per informazioni su come per eseguire il provisioning di un VPC condiviso, inclusi requisiti, configurazione passaggi e utilizzo, vedi Esegui il provisioning di un VPC condiviso.

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

Puoi utilizzare Persistent Disk e Google Cloud Hyperdisk:

  • I volumi di Persistent Disk sono disponibili come disco rigido standard (HDD) o a stato solido (SSD). Per i dischi permanenti bilanciati dischi permanenti e SSD, Replica asincrona PD consente di eseguire la replica asincrona dei dati SAP tra due regioni di Google Cloud.
  • I volumi Hyperdisk Extreme offrono un massimo IOPS e velocità effettiva rispetto ai volumi di dischi permanenti SSD.
  • Per impostazione predefinita, Compute Engine cripta il cliente contenuti inattivi, inclusi quelli all'interno del Persistent Disk e i volumi Hyperdisk. Per ulteriori informazioni sui dischi la crittografia e le 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 Compute Engine e le istanze di cui hai bisogno. Non è necessario creare e gestire singolarmente a configurare le risorse o a individuare le dipendenze la console Google Cloud lo fa al posto tuo.
Cloud Storage Puoi archiviare i backup dei tuoi database SAP in Cloud Storage per con maggiore durabilità e affidabilità, con la replica.
Cloud Monitoring

Offre visibilità su deployment, prestazioni, uptime e l'integrità dei dischi di Compute Engine, della rete e dell'archiviazione permanente.

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

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

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

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

Per deployment ad alta disponibilità multi-zona, consigliamo di utilizzare Filestore Enterprise 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 su un'istanza VM di Compute Engine.

Per ulteriori informazioni su NetApp Cloud Volumes ONTAP, vedi Panoramica di Cloud Volumes ONTAP.
Google Cloud NetApp Volumes

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

A seconda della regione, possono essere previsti più livelli di servizio tra cui scegliere. Per ulteriori informazioni, vedi Servizio aggiuntivi.

Note sul layout

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

Networking

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

Un tipico deployment SAP posiziona le istanze dei sistemi ad alta disponibilità in diverse zone nella stessa regione per garantire la resilienza e al contempo una bassa latenza. Le subnet possono in più zone grazie alle funzionalità di Google Cloud. Queste funzionalità semplificare anche il clustering SAP perché l'indirizzo IP virtuale (VIP) del cluster 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 ad alta disponibilità il clustering del livello dell'applicazione (ASCS ed ERS) e Livello di database SAP ASE o IBM Db2 (primario e secondario).

Esistono diversi modi per creare la tua rete e connettere la tua SAP Business Suite con la tua infrastruttura:

  • Il peering di rete VPC connette due VPC in modo che le risorse in ogni rete possano comunicare tra loro. Le reti VPC possono essere ospitate nello stesso progetto Google Cloud, della stessa organizzazione o anche progetti diversi di diversi le tue organizzazioni. Il peering di rete VPC stabilisce una connessione diretta due reti VPC, ognuna con le proprie subnet, abilitando la comunicazione 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 un rete VPC comune. I sistemi che utilizzano un VPC condiviso possono comunicare in modo efficiente e sicuro utilizzando indirizzi IP interni. Puoi gestire centralmente e risorse di rete come subnet, route e firewall in un progetto host, e delega responsabilità amministrative per la creazione e la gestione le singole risorse ai progetti di servizio. Questa separazione dei problemi semplifica l'amministrazione della rete e applica criteri di sicurezza coerenti all'interno dell'organizzazione.

Per i sistemi SAP, in genere si consiglia di raggruppare le risorse per ambiente di testo. Ad esempio, gli ambienti di produzione non devono condividere le risorse di calcolo con ambienti non di produzione in modo da fornire un isolamento adeguato, ma puoi utilizzare un VPC condiviso per un livello comune di connettività in modo programmatico a gestire i progetti. Puoi anche utilizzare VPC indipendenti e utilizzare il peering VPC per connetterti in modo programmatico a gestire i progetti.

Durante la progettazione della rete, inizia con un progetto host che contenga uno o più in reti VPC condiviso. Puoi collegare progetti di servizio aggiuntivi a un che consente ai progetti di servizio di partecipare VPC condiviso. In base alle tue esigenze, puoi eseguire il deployment di SAP Business Suite in una singola 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 Questo semplifica il deployment e riduce i costi amministrativi a scapito a un minore isolamento tra le reti.
  • Scenario 2: deployment di SAP Business Suite su più VPC condivisi. Questo aumenta l'isolamento della rete e aggiunge la sicurezza a scapito dell'aumento della la complessità e l'overhead amministrativo.

È anche possibile utilizzare un approccio ibrido. Ad esempio, puoi utilizzare uno 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" sezione nel 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à di 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 più opzioni per ridurre l'impatto di questi singoli punti di errori, e queste opzioni prevedono il deployment del sistema ad alta disponibilità, servizi di replica o l'utilizzo di che proteggono il sistema da guasti. Quando pianifichi 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 una suite SAP Business su SAP ASE o IBM Db2, è necessario specificare i seguenti punti dati per definire disponibilità e continuità:

  • Obiettivi del livello di servizio (SLO): un valore target o un intervallo di valori per un che viene misurato mediante un indicatore del livello del servizio (SLI). Per ad esempio prestazioni, disponibilità e affidabilità.
  • Indicatori del livello del servizio (SLI): metriche, come la latenza, che consentono di a misurare le prestazioni di un servizio. Si tratta di un insieme di dati quantitativi attentamente definiti misura di alcuni aspetti del livello di servizio offerto.
  • Accordo sul livello del servizio (SLA): un contratto di servizio tra due parti. (fornitore, cliente) che definisce un accordo sul servizio fornito termini misurabili chiamati obiettivi del livello di servizio (SLO).
  • RTO (Recovery Time Objective). La durata massima tollerabile tra un l'incidente di perdita di dati e la sua mitigazione.
  • RPO (Recovery Point Objective): il Recovery Point Objective (RPO) è il quantità massima di dati che possono essere persi, misurata in tempo, senza causare danni significativi. In pratica, questo si traduce nel momento in cui lo stato dei dati interessati deve essere recuperato dopo un evento di perdita di dati.

A seconda dei punti dati e dei valori concordati tra tutti gli stakeholder, il sistema SAP Business Suite si basa su funzionalità come l'alta disponibilità o ripristino di emergenza:

  • Disponibilità elevata (HA): la capacità di un sistema che supporta l'obiettivo della continuità aziendale garantendo al contempo la disponibilità di dati e servizi gli utenti quando necessario. Il modo consueto per ottenere questa funzionalità è abilitare ridondanza, tra cui ridondanza hardware, ridondanza di rete e data center ridondanza.
  • Ripristino di emergenza (RE): la capacità di un sistema da proteggere di interruzioni non pianificate tramite metodi di ripristino affidabili e prevedibili hardware e/o luoghi fisici diversi.

L'alta disponibilità e il ripristino di emergenza sono compatibili, ma coprono casi e situazioni diverse. Ad esempio, una soluzione ad alta disponibilità ti consente alle tue operazioni se uno degli elementi del sistema presenta un'istanza non pianificata o in caso di interruzioni del servizio senza causare interruzioni ai tuoi utenti. Lo stesso può a proposito di una soluzione RE, con l'eccezione del fatto che dal momento dell'interruzione fino a quando la soluzione RE avvia la configurazione difettosa elementi del sistema in una posizione diversa.

Le sezioni successive forniscono una panoramica delle diverse opzioni a tua disposizione. durante la pianificazione e il deployment del 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 SAP Business Suite con SAP ASE o IBM Db2. Per saperne di più sul dimensionamento su Google Cloud e sui tipi di macchina 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 specifica posizione geografica in cui puoi eseguire le tue risorse e corrisponde a una o più sedi di data center relativamente vicine tra loro. Ciascuna ha una o più zone con connettività, alimentazione e raffreddamento ridondanti.

È possibile utilizzare risorse globali come le immagini disco preconfigurate e gli snapshot dei dischi a cui si accede tra regioni e zone. Risorse regionali, ad esempio i feed statici a livello di regione indirizzi IP esterni, sono accessibili solo alle risorse che si trovano nella stessa regione. Le risorse di zona, come VM e dischi, sono accessibili solo di risorse che si trovano nella stessa zona. Per ulteriori informazioni, vedi 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 i dati o in una rete aziendale. Per ridurre la latenza, seleziona una località che si trova in e nelle vicinanze di 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 carichi di lavoro di SAP NetWeaver su Google Cloud.
  • Assicurati che il server di applicazioni SAP e il database siano nella stessa posizione regione.

Opzioni di archiviazione per SAP Business Suite

Di seguito sono riportate le opzioni di archiviazione offerte da Google Cloud, certificato 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): blocco efficiente ed economico spazio di archiviazione supportato dischi rigidi standard (HDD) per la gestione delle operazioni sequenziali di lettura e scrittura, ma non è ottimizzata per gestire velocità elevate di operazioni di input-output casuali al secondo (IOPS).
  • Disco permanente SSD (pd-ssd): fornisce blocchi affidabili e ad alte prestazioni spazio di archiviazione supportato unità a stato solido (SSD).
  • Disco permanente bilanciato (pd-balanced): offre contenuti archiviazione a blocchi basata su SSD.
  • Disco permanente con carico estremo (pd-extreme): basato su SSD; offre un valore massimo Opzioni IOPS e velocità effettiva rispetto a pd-ssd per Compute Engine di dimensioni maggiori tipi di macchine virtuali. Per ulteriori informazioni, vedi Dischi permanenti con carico estremo.

Hyperdisk

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

  • Hyperdisk bilanciato (hyperdisk-balanced): la soluzione migliore per per la maggior parte dei carichi di lavoro. Consigliamo di utilizzare questa opzione con database che non richiedono le prestazioni di Hyperdisk Extreme. Selezioni le prestazioni necessarie eseguendo il provisioning di IOPS e velocità effettiva. Per ulteriori informazioni, vedi 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à. Ciascuna Un volume di Persistent Disk può archiviare fino a 64 TB, quindi puoi creare senza gestire array di dischi. Anche i volumi Hyperdisk consentire fino a 64 TB di spazio di archiviazione, a seconda del tipo che utilizzi. Una funzionalità chiave è i volumi Persistent Disk e Hyperdisk vengono criptati per proteggere i dati.

Al momento della creazione, un'istanza VM di Compute Engine alloca una singola radice Persistent Disk o Hyperdisk per impostazione predefinita che contiene un intero sistema operativo. Puoi aggiungere altre opzioni di archiviazione all'istanza VM obbligatorio.

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

Soluzioni di condivisione file

Su Google Cloud sono disponibili diverse soluzioni di condivisione file, tra cui le seguenti:

  • Filestore: Google Cloud ad alte prestazioni, completamente gestito Archiviazione di file NFS con disponibilità regionale.
  • Google Cloud NetApp Volumes: una soluzione di archiviazione di file NFS o SMB completamente gestita in Google Cloud.
  • NetApp Cloud Volumes ONTAP: una soluzione di archiviazione intelligente e completa di cui esegui il deployment e gestirli 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 che puoi eseguire il deployment dalla console Google Cloud.

Per ulteriori informazioni sulle soluzioni di condivisione file per SAP Business Suite su per Google Cloud, consulta Soluzioni di condivisione di 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; questo elemento dispone di uno spazio di archiviazione praticamente illimitato e non devi preoccuparti del provisioning o l'aggiunta di ulteriore capacità. Un oggetto in Cloud Storage contiene dati di file e i metadati associati e può e avere una dimensione massima di 5 TB. Un bucket Cloud Storage può archiviare un numero qualsiasi di oggetti.

È pratica comune utilizzare Cloud Storage per archiviare i file di backup per qualsiasi scopo. Ad esempio, Cloud Storage è un buon posto in cui archiviare il SAP ASE o IBM Db2 backup del database. Per informazioni sulla pianificazione del backup dei database, consulta Backup e ripristino del database. Puoi anche utilizzare Cloud Storage come parte processo di migrazione.

Inoltre, puoi utilizzare il servizio di backup e RE come servizio 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, vedi Soluzioni di backup e ripristino di emergenza con Google Cloud.

Scegli l'opzione Cloud Storage in base alla frequenza con cui devi eseguire per accedere ai dati. Per l'accesso frequente, ad esempio più volte al mese, seleziona l'icona Classe di archiviazione standard. Per un accesso sporadico, seleziona Nearline o Coldline Storage. Per i dati archiviati, che non prevedi seleziona Archive Storage.

Struttura della directory SAP ASE e opzioni di archiviazione

Le seguenti tabelle descrivono le strutture di directory per Sistema SAP Business Suite su 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ò essere montato anche come utilizzando una soluzione NFS come Filestore.

  • Di seguito è riportata la struttura consigliata della directory Linux 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 essere nella directory /sybase/SAP_SID. Sostituisci SAP_SID con l'identificatore di sistema SAP (SID), che è 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 delle directory Windows per SAP Business Suite su SAP ASE su Google Cloud. La directory seguente 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 Sistema SAP Business Suite su 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, vedi SAP su IBM Db2 per Linux, UNIX e Windows.

  • Di seguito è riportata la struttura consigliata delle directory Windows 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 Guida alla pianificazione di SAP NetWeaver. Per informazioni sul calcolo delle dimensioni del file di pagina, consulta la nota SAP 1518419: file di pagina e memoria virtuale richiesti dal sistema SAP.

Supporto dei sistemi operativi per SAP Business Suite

Quando si sceglie un sistema operativo per SAP NetWeaver su Google Cloud, oltre a confermare che la versione del sistema operativo è certificata da SAP, devi per confermare che tutte e tre le aziende, SAP, il fornitore del sistema operativo e Google Cloud, supporta 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. La Le immagini sistema operativo fornite da Compute Engine sono configurate per funzionare con Google Cloud. Se non è disponibile un sistema operativo Google Cloud, puoi utilizzare il modello BYOI (Bring your own device, Porta la tua immagine del sistema operativo) e una licenza. Le immagini del sistema operativo BYOI sono definite da Compute Engine come immagini personalizzate.
  • Le opzioni di licenza disponibili per una determinata versione del sistema operativo. Verifica se il sistema operativo ha un'opzione di licenza on demand o se devi BYOS (Bring Your Own Subscription) del fornitore del sistema operativo.
  • 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 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à sia con SAP Business Suite che SAP ASE o IBM Db2 nelle seguenti guide:

Architettura di deployment per SAP ASE

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

Il seguente diagramma mostra un'architettura di deployment per SAP ASE su in Google Cloud. Nel diagramma, prendi nota di entrambi: il deployment Google Cloud e il layout del disco. Puoi utilizzare Cloud Storage per esegui il backup dei backup locali disponibili in /sybasebackup. Questa piastra da muro deve essere di dimensioni uguali o superiori a quelle del montaggio dei 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é uno dei possibili tipi di database per il sistema.

Il seguente diagramma mostra un'architettura di deployment per IBM Db2 su in Google Cloud. Nel diagramma, noterai che sia il deployment Google Cloud e il layout del disco. Puoi utilizzare Cloud Storage per esegui il backup dei backup locali disponibili in /db2backup. Questo supporto deve avere le dimensioni necessarie uguale o superiore al montaggio dei 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 utilizzabili per il deployment di SAP Business Suite su SAP ASE o IBM Db2 su Google Cloud.

Architettura a due livelli

Questa architettura viene presentata nel deployment centralizzato. Il seguente diagramma mostra alcuni dettagli di un'architettura a due livelli per SAP Business Suite in esecuzione di una VM di Compute Engine:

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

Architettura a tre livelli

Questa architettura viene presentata nel deployment distribuito. Puoi utilizzare questo per il deployment di sistemi SAP Business Suite ad alta disponibilità. La il seguente diagramma mostra alcuni dettagli di un'architettura a tre livelli 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 un su una VM di Compute Engine su Google Cloud.

In questa architettura, il sistema SAP Business Suite distribuisce il lavoro tra più server delle applicazioni NetWeaver (AS), ciascuno ospitato su una VM separata. Tutti i nodi NetWeaver AS condividono lo stesso database, che è ospitato su una rete VM. 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 una Volume di Persistent Disk condiviso tra tutti i nodi o su un soluzione di condivisione file.

Sicurezza, privacy e conformità

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

Conformità e controlli di sovranità

Se hai bisogno che il tuo carico di lavoro SAP venga eseguito in conformità con la residenza dei dati, controllo dell'accesso, del personale o dei requisiti normativi, devi pianificare l'utilizzo di Assured Workloads - un servizio che ti aiuta a eseguire carichi di lavoro sicuri e conformi su Google Cloud senza a compromettere la qualità della tua esperienza cloud. Per ulteriori informazioni, consulta la sezione Controlli di conformità e sovranità per SAP su Google Cloud.

Networking e sicurezza della rete

Prendi in considerazione le informazioni riportate nelle sezioni seguenti quando pianifichi il networking sicurezza di rete.

Modello di privilegi minimi

Una delle prime linee di difesa è limitare chi può raggiungere la rete per le tue VM. Per farlo, utilizzi Regole firewall VPC. Per impostazione predefinita, tutto il traffico verso le VM, anche da altre VM, viene bloccato dal firewall, a meno che e creare regole per consentire l'accesso. L'eccezione è la rete predefinita viene creato automaticamente con ogni progetto e ha regole firewall.

Creando regole firewall VPC, puoi limitare tutto il traffico su una di porte a specifici indirizzi IP di origine. Per limitare l'accesso al indirizzi IP, protocolli e porte specifici che richiedono l'accesso, devono rispettare le regole minime un modello di privilegio. Ad esempio, imposta sempre bastion host e consenti l'accesso tramite SSH le comunicazioni al tuo 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 collegato a quella rete. Tutte le reti Compute Engine utilizzano IPv4. Ogni evento Nel progetto Google Cloud è fornita una rete predefinita con configurazioni e regole firewall, ma ti consigliamo di aggiungere una subnet e aggiungi regole firewall basate su modello di privilegio minimo. Per impostazione predefinita, una nuova che non ha regole firewall e quindi non ha accesso alla rete.

Potresti voler aggiungere più di una subnet per isolare parti di alla tua rete o soddisfare altri requisiti. Per ulteriori informazioni, vedi 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 consenta il traffico tra le VM nella stessa rete e tra subnet. Puoi anche configurare firewall in modo che si applichino a specifiche le VM target usando i tag di rete.

SAP richiede l'accesso a determinate porte, quindi aggiungi regole firewall per consentire l'accesso a il definite 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 che inoltra il traffico da una VM a una VM all'interno della stessa rete e su senza richiedere indirizzi IP esterni.

Per l'accesso esterno alle risorse internet, avvia una VM senza IP esterno e configurare un'altra VM come gateway NAT. Questa configurazione richiede di aggiungere il gateway NAT come route per l'istanza SAP.

Bastion host e gateway NAT

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

Per connetterti a queste macchine interne, devi configurare un'istanza bastion che ha un indirizzo IP esterno e quindi lo attraversa. Quando le VM non hanno indirizzi IP esterni, possono essere raggiunti solo da altre VM sulla rete oppure attraverso un gateway VPN gestito. Puoi eseguire il provisioning delle VM nella tua rete relè attendibili per le connessioni in entrata, denominati bastion host, o in uscita, chiamati gateway NAT. Per una connettività più trasparente senza impostare per configurare queste connessioni, puoi utilizzare una risorsa gateway VPN gestito.

Bastion host per connessioni in entrata

Bastion host fornire un punto di ingresso rivolto all'esterno di una rete delle VM con rete privata. Questo padrone di casa può fornire un unico punto di fortificazione e può essere avviato e arrestato per abilitare o disabilitare l'SSH in entrata la comunicazione da internet.

Visualizzazione del bastion host nello scenario SSH.

L'accesso SSH alle VM che non hanno un indirizzo IP esterno può essere ottenuto che si connette prima a un bastion host. La protezione completa di un bastion host non rientra nell'ambito del presente documento, ma alcuni dei 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 un bastion host.

Per impostazione predefinita, SSH sulle VM è configurato in modo da utilizzare chiavi private per l'autenticazione. Quando utilizzi un bastion host, accedi prima al bastion host e poi a della VM privata di destinazione. A causa di questa procedura di accesso in due passaggi, ti consigliamo di utilizzare Inoltro dell'agente SSH per raggiungere la VM di destinazione anziché archiviare le relative VM chiave privata sul bastion host. Devi eseguire questa operazione anche se utilizzi lo stesso sia per il bastion che per le VM di destinazione, perché il bastion ha solo alla metà pubblica della coppia di chiavi.

Gateway NAT per il trasferimento di dati in uscita

Quando a una VM non è assegnato un indirizzo IP esterno, non è possibile effettuare a servizi esterni, inclusi altri servizi Google Cloud. Per consentire a queste VM di raggiungere i servizi su internet, puoi impostare un gateway NAT. Il gateway NAT è una VM che può instradare per conto di qualsiasi altra VM sulla rete. Utilizza un gateway NAT per in ogni rete. Un gateway NAT a VM singola non è ad alta disponibilità e non può supportare e la velocità effettiva del traffico per più VM. Per informazioni su come configurare una VM fungere da 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 VPN connessione che utilizza IPsec utilizzando o Cloud VPN. Il traffico tra le due reti è criptato da un gateway VPN, quindi decriptato dall'altro gateway VPN. In questo modo mentre vengono trasferiti su internet. Puoi controllare dinamicamente quali VM per indirizzare il traffico lungo la VPN usando i tag di istanza sulle route. Cloud VPN tunnel vengono fatturati a una tariffa mensile statica più addebiti standard per i servizi in uscita trasferimento di dati. Tieni presente che connettere due reti nello stesso progetto comporta 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 di dati e log quindi assicurati di utilizzare TLS (HTTPS) durante l'invio di dati a Cloud Storage dalle tue VM per proteggere i dati in transito.

Cloud Storage cripta automaticamente i dati at-rest, specificare le tue chiavi di crittografia, se disponi di sistemi di gestione delle chiavi di un sistema operativo completo.

Limiti per le notifiche via email

Per contribuire a proteggere i tuoi sistemi e quelli di Google da comportamenti illeciti, Google Cloud applica limitazioni per l'invio di email da Compute Engine. Questo 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 quanto segue:

Affidabilità

Questa sezione fornisce informazioni sugli aspetti relativi all'affidabilità con 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, e dei principi di progettazione per garantire la continuità aziendale in caso di errori. Questi approcci funzionano eliminando singoli punti un guasto e la possibilità di riprendere rapidamente le operazioni dopo che un sistema dei componenti con interruzioni minime dell'attività. Il recupero dai guasti è il processo di ripristino e ripristino delle operazioni dopo un'interruzione a causa di un componente in errore.

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 l'istanza principale e in standby, in modo che i due server siano sempre sincronizzati con zero e la perdita di dati. L'opzione SAP ASE sempre attiva, che è un'alta disponibilità e sistema di ripristino di emergenza (HADR), è supportato su Google Cloud. Per ulteriori informazioni, consulta Guida alla pianificazione di SAP ASE.

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

  • SAP ASE
  • Agente host SAP, 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
  • Gestore errori, che ha il proprio server host. Monitora il SAP ASE principale e in standby server web. Fault Manager garantisce l'alta disponibilità di SAP ASE iniziando il failover automatico. Monitora i seguenti componenti: RMA, replica server, applicazioni, database e sistema operativo. Ti permette anche di controllare l'integrità del database e, se necessario, riavviarlo.

Per una migliore disponibilità del sistema, un cluster SAP ASE consente ai carichi di lavoro Spostato al nodo secondario mediante il monitoraggio di errori del nodo primario. La il seguente diagramma mostra un'architettura di riferimento generale 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 SAP ASE HADR 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 agisce 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 designato 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 emergenza recupero

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'altro come standby. Devi mantenerli sincronizzati. Se l'istanza principale un errore, l'istanza in standby supporta il carico di lavoro.

    L'istanza principale gestisce le connessioni, le transazioni e i record client nei log. Questi log vengono inviati tramite TCP/IP al server di standby, li utilizza per aggiornare il proprio database, rimanendo sincronizzati con in esecuzione in un'istanza Compute Engine.

  • Poiché l'HADR stessa non dispone di rilevamento dei guasti e di automazione, il deployment di Pacemaker. Il pacemaker monitora entrambe le istanze e se l'istanza principale l'istanza si arresta in modo anomalo, Pacemaker attiva il takeover HADR da parte dell'istanza in standby verificando che l'indirizzo IP mobile sia assegnato alla nuova istanza principale.

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

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

Ottimizzazione dei costi

Questa sezione fornisce informazioni su licenze, sconti e stime 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 con licenza BYOL (Bring Your Own License) un modello di machine learning. Google Cloud supporta il modello BYOL sia per le risorse di produzione e non di produzione. Le licenze del sistema operativo sono incluse prezzi di Compute Engine.

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

Per informazioni sulla licenza per SAP ASE su Google Cloud, consulta "Licenze SAP" nel Guida alla pianificazione di SAP ASE.

Per eseguire il deployment di IBM Db2 per SAP su Google Cloud, devi utilizzare il tuo licenza. Puoi ottenere una licenza da SAP o da IBM. Per ulteriori informazioni sulle licenze e sull'assistenza, vedi la nota SAP 1168456 - DB6: Procedura di supporto e date di fine del supporto per IBM Db2 LUW.

Sconti

Con il modello di determinazione del prezzo con pagamento a consumo di Google Cloud, paghi solo che utilizzi. Non c'è alcun bisogno di impegnarsi per una dimensione particolare servizio; puoi modificare o interrompere l'utilizzo in base alle tue esigenze. Per risultati prevedibili Compute Engine offre sconti per impegno di utilizzo (CUD) ridurre il costo dell'infrastruttura grazie alla sottoscrizione di un per i prezzi di utilizzo delle VM molto scontati.

Google Cloud offre questi sconti in cambio dell'acquisto per impegno di utilizzo. noti anche come impegni. Quando acquisti un impegno, impegnarsi a un utilizzo minimo delle risorse o a un importo minimo di spesa per un determinato periodo di uno o tre anni. Questi sconti ti aiutano a ridurre fatturazione mensile per le risorse utilizzate dal sistema SAP Business Suite. Per ulteriori informazioni, vedi Sconti per impegno di utilizzo (CUD).

Stime delle dimensioni

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

Efficienza operativa

Questa sezione fornisce informazioni su come ottimizzare le risorse efficienza 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, che puoi ripristinare in caso di arresto anomalo del sistema, danneggiamento dei dati o altro problema.

Hai a disposizione diverse opzioni per il backup SAP ASE o IBM Db2 dati 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 mediante dischi: puoi utilizzare la soluzione flessibile di SAP ASE di backup e ripristino in combinazione con i tipi di Persistent Disk e Hyperdisk forniti da in Compute Engine. Per archiviare i backup per un periodo più lungo, puoi utilizzare di archiviazione ideale in Cloud Storage.

    Il seguente diagramma mostra come vengono utilizzati i dischi e Cloud Storage per archivia i backup per un database SAP ASE:

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

  • Backup e ripristino tramite snapshot dei dischi: un'altra opzione che puoi aggiungere alla strategia di backup consiste nell'acquisire snapshot di interi dischi mediante la funzionalità Istantanea disco in Compute Engine. Ad esempio, puoi creare snapshot pianificati disco che ospita la directory /sybasebackup per l'utilizzo nel ripristino di emergenza diversi scenari. È possibile utilizzare gli snapshot dei dischi anche per il backup e il ripristino il volume dei dati SAP ASE. Per garantire la coerenza dell'applicazione, acquisisci snapshot se 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 modifiche incrementali dei blocchi, come illustrato nello schema seguente:

    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 mentre il database è in corso la creazione del backup.
    • Modalità offline: in questa modalità, il database viene completamente arrestato, rendendo non disponibile per gli utenti durante la creazione del backup.

  • Esegui il backup e recupera il database IBM Db2 utilizzando gli snapshot del disco: un'altra opzione che puoi aggiungere alla strategia di backup consiste nell'acquisire snapshot di interi dischi mediante la funzionalità Istantanea disco in Compute Engine. Ad esempio, puoi creare snapshot pianificati disco che ospita la directory /db2backup per l'utilizzo nel ripristino di emergenza diversi scenari. È possibile utilizzare gli snapshot dei dischi anche per il backup e il ripristino il volume di dati IBM Db2. Per garantire la coerenza dell'applicazione, acquisisci snapshot se 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 modifiche incrementali dei blocchi, come illustrato nello schema seguente:

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

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

  • Database a partizione singola: in questa configurazione puoi creare un backup svolgendo i seguenti passaggi:

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

    2. Esegui questo comando:

      db2 backup db DB_SID

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

  • Database multipartizione: in questa configurazione puoi creare un backup svolgendo i seguenti passaggi:

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

    2. Esegui questo comando:

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

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

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

Recupera un database IBM Db2

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

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

    1. Come db2DB_SID o Utente SAP_SIDadm, accedi al server del database.

    2. Esegui questo comando:

      db2 RECOVER DB DB_SID

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

  • Per ripristinare il database IBM Db2 in un momento specifico, completa la seguenti passaggi:

    1. Come db2DB_SID o Utente 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 tuo server di database

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

Monitoraggio

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

Come richiesto da SAP, per ottenere supporto da SAP e consentire a SAP di soddisfare gli accordi sul livello del servizio (SLA), devi installare Agente Google Cloud per SAP su tutte le istanze VM di Compute Engine e i server Bare Metal Solution in esecuzione in qualsiasi sistema SAP. Per ulteriori informazioni sui prerequisiti dell'assistenza, vedi SAP nota SAP Note 2456406 - SAP su Google Cloud Platform: prerequisiti di assistenza di Google.

Oltre alla raccolta obbligatoria delle metriche di SAP Host Agent, su Linux, L'agente Google Cloud per SAP include funzionalità facoltative come la raccolta Metriche di monitoraggio dei processi e valutazione del Gestore carichi di lavoro metriche di valutazione. Puoi attivare queste funzionalità che abilitano prodotti e servizi quali come la gestione dei carichi di lavoro per i tuoi carichi di lavoro SAP.

Ottimizzazione delle prestazioni

Questa sezione fornisce informazioni sull'ottimizzazione del rendimento Carichi di lavoro SAP Business Suite attraverso il dimensionamento e la configurazione di rete.

Dimensionamento

Sono disponibili diverse opzioni di dimensionamento in base al tipo di implementazione. Per implementazioni greenfield, consigliamo di utilizzare lo strumento SAP Quick Sizer. Per per informazioni dettagliate, vedi SAP Taglie . SAP fornisce inoltre guide sulle t-shirt relative a soluzioni e strumenti specifici per migrazione delle attuali soluzioni on-premise a Google Cloud. Ad esempio, vedi la nota SAP SAP Note 2456432 - Applicazioni SAP su Google Cloud: prodotti supportati e Tipi di macchine Google Cloud di Google. SAP e Google Cloud utilizzano unità per misurare le IOPS (operazioni di I/O al secondo). Consulta il tuo SI (Systems Integrator) per convertire i requisiti di dimensionamento SAP in dell'infrastruttura Google Cloud delle dimensioni adeguata.

Per dimensionare un database SAP ASE, consulta il documento SAP Dimensioni 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, vedi il documento SAP Guide Finder per la piattaforma SAP NetWeaver e ABAP.

Configurazione di rete

Le funzionalità di rete delle VM di Compute Engine sono determinate e non in base all'interfaccia di rete (NIC) o all'indirizzo IP.

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

Le interfacce di rete delle VM di Compute Engine sono supportate da infrastruttura di rete resiliente mediante una rete fisica e software-defined componenti. Queste interfacce ereditano la ridondanza e la resilienza del la piattaforma sottostante. È possibile usare più NIC virtuali per la separazione del traffico, ma ciò non offre ulteriori vantaggi in termini di resilienza o prestazioni.

Un singolo NIC fornisce le prestazioni necessarie SAP ASE o IBM Db2 i deployment in Compute Engine. Il tuo caso d'uso specifico, i tuoi requisiti di sicurezza potrebbero richiedere interfacce aggiuntive per separare il traffico, come traffico internet, traffico interno Replica HADR SAP ASE o IBM Db2 traffico o altro che possono trarre vantaggio da regole specifiche dei criteri di rete. È consigliabile si utilizza la crittografia del traffico offerta dall'applicazione e la protezione della rete seguendo un criterio firewall con privilegi minimi per limitare l'accesso.

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

Per ulteriori informazioni, vedi:

Deployment

Questa sezione fornisce informazioni relative alla distribuzione 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 su SAP. Inoltre, prima di iniziare un'implementazione SAP, consultate il SAP Marketplace per consultare 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 Terraform configurazioni fornite da Google Cloud. Per ulteriori informazioni, consulta guide all'implementazione 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 Terraform configurazioni fornite da Google Cloud. Per ulteriori informazioni, consulta guide all'implementazione per il tuo scenario.

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

Passaggi successivi