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

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

Google Cloud offre un'infrastruttura certificata SAP conveniente, affidabile, sicura e ad alte prestazioni 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 di alto livello di tre modelli di deployment comuni per SAP Business Suite: centralizzato, distribuito e distribuito con alta disponibilità.

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 sezioni seguenti mostrano le architetture di riferimento per SAP Business Suite su SAP ASE e IBM Db2 nei 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 tutti installati sulla stessa istanza VM.

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

Deployment centralizzato 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 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 diversi componenti su diverse istanze Compute Engine. Consigliamo questo approccio per gli ambienti di produzione o per quelli che richiedono molta potenza di calcolo per gestire carichi di transazioni elevati.

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 tutti 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 alta disponibilità

In un deployment distribuito con alta disponibilità, i cluster Linux vengono configurati in più zone per proteggersi dai guasti 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, inizia con la configurazione di due istanze VM Compute Engine in zone separate per la massima ridondanza, ciascuna con il proprio database SAP ASE o IBM Db2.

  • Deployment distribuito di SAP ASE con disponibilità elevata: puoi eseguire il deployment di un database SAP ASE ad alta disponibilità e con tolleranza ai disastri (HADR) su Google Cloud 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 l'alta disponibilità sia a livello di applicazione sia a livello di 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 uno con Fault Manager.
    • Replica sincrona di SAP ASE.
    • Il gestore delle risorse del cluster ad alta disponibilità Pacemaker.
    • Un meccanismo di isolamento che utilizza Fault Manager per garantire l'isolamento delle risorse non riuscite o in stato di errore.
    • 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 alta disponibilità: puoi eseguire il deployment di un database IBM Db2 ad alta disponibilità e con tolleranza ai guasti (HADR) su Google Cloud supportato da SAP. Per ulteriori informazioni, consulta la guida alla pianificazione di IBM Db2 per SAP.

    Puoi configurare un cluster Pacemaker HADR a due host utilizzando la soluzione di clustering fornita da IBM per Db2. Per ulteriori informazioni, consulta il PDF di SAP Database Administration Guide for SAP on IBM Db2 for Linux, Unix, and Windows.

    Il seguente diagramma illustra un'architettura per SAP Business Suite su IBM Db2 che utilizza un cluster Linux per ottenere un'alta disponibilità sia sul lato dell'applicazione sia sul lato del 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 sincrona IBM Db2 HADR.
    • Un gestore delle risorse di cluster ad alta disponibilità Linux, come Pacemaker.
    • Un meccanismo di isolamento che isola il nodo in cui si è verificato l'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 servizi centrali SAP ABAP (ASCS) e il server di replica di coda o il replicatore di coda (ERS) utilizzati per fornire al sistema SAP Business Suite un'alta disponibilità nel caso in cui si verifichi un problema con una delle istanze ASCS e ERS.

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

Il seguente diagramma mostra un sistema SAP Business Suite che utilizza un cluster Pacemaker per limitare i singoli punti di errore sia del Message Server sia dell'Enqueue Server:

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

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

Una nota sul bilanciamento del carico

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

Componenti di deployment

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

  • Database SAP ASE o IBM Db2
  • Fault Manager, solo su SAP ASE
    • Ha un proprio server host e monitora i server principale e di riserva. Fault Manager garantisce l'alta disponibilità di SAP ASE avviando il failover automatico. Monitora i seguenti componenti: agente di gestione della replica, server di replica, applicazioni, database e sistema operativo. Inoltre, ti consente di controllare lo stato del database e di riavviare il database se necessario.
  • ASCS: ABAP SAP Central Services
    • Contiene il server di messaggistica e il server di coda, obbligatori in qualsiasi sistema SAP ABAP.
    • Essere dipiattate su una propria istanza VM nei deployment HA o su un'istanza VM che ospita il PAS.
    • Nei deployment HA, le risorse ASCS sono gestite da un gestore delle risorse del cluster Linux come Pacemaker.
  • ERS: Enqueue Replication Server o Enqueue Replicator
    • Implementato nei deployment ad alta disponibilità per mantenere una replica della tabella dei blocchi nel caso in cui si verifichi un problema con l'istanza ASCS.
    • Gestito da un gestore delle risorse del cluster Linux come Pacemaker.
  • PAS: Primary Application Server
    • Il primo o l'unico server di applicazioni per il sistema SAP.
  • AAS: Additional Application Server
    • Di solito viene implementato per il bilanciamento del carico a livello di applicazione. Puoi installare più istanze AAS per ottenere una maggiore disponibilità anche dal punto di vista del livello di applicazione. Se uno dei server delle applicazioni si arresta in modo anomalo, tutte le sessioni utente collegate a quel server vengono interrotte, ma gli utenti possono accedere di nuovo all'altro AAS nell'ambiente.
  • Gateway SAP NetWeaver
    • Implementato come sistema autonomo o come parte del sistema SAP Business Suite.
    • Consente al sistema di connettere dispositivi, ambienti e piattaforme ai sistemi SAP utilizzando il protocollo Open Data Protocol (OData).
  • Server front-end SAP Fiori
    • Implementato 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 nel deployment di SAP Business Suite su SAP ASE o IBM Db2:

Servizio Descrizione
Networking VPC

Connette le istanze VM tra loro e a internet.

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

Tieni presente che una rete Virtual Private Cloud (VPC) non può essere distribuita su più 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 la VPC condivisa, in modo che le risorse possano comunicare tra loro in modo sicuro ed efficiente utilizzando gli 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 Eseguire il provisioning di un VPC condiviso.

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

Puoi utilizzare Persistent Disk e Google Cloud Hyperdisk:

  • I volumi su Persistent Disk sono disponibili come unità disco rigido standard (HDD) o unità a stato solido (SSD). Per i dischi permanenti bilanciati e i dischi permanenti SSD, Replica asincrona dei dischi permanenti fornisce la replica asincrona dei dati SAP tra due regioni Google Cloud.
  • I volumi Hyperdisk Extreme offrono opzioni di IOPS e throughput massimi superiori rispetto ai volumi dei dischi permanenti SSD.
  • Per impostazione predefinita, Compute Engine cripta i contenuti at-rest dei clienti, inclusi i contenuti all'interno dei volumi di 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 singolarmente le risorse o capire le dipendenze perché la console Google Cloud lo fa per te.
Cloud Storage Puoi archiviare i backup del database SAP in Cloud Storage per una maggiore durabilità e affidabilità, con la replica.
Cloud Monitoring

Offre visibilità sul deployment, sulle prestazioni, sull'uptime e sull'integrità dei dischi di Compute Engine, di rete e di archiviazione permanente.

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

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

IAM ti consente di controllare chi può eseguire operazioni di piano di controllo sulle tue 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 di Google Cloud.

Per i deployment multizonali ad alta disponibilità, ti consigliamo di utilizzare Filestore Enterprise con 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 completa che puoi eseguire il deployment e gestire autonomamente su un'istanza VM Compute Engine.

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

Una soluzione di archiviazione 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 ulteriori 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 implementare un sistema SAP Business Suite dal punto di vista della rete e il modo in cui esegui il deployment della rete ha un impatto significativo sulla sua disponibilità, resilienza e prestazioni. Come accennato in precedenza, un Virtual Private Cloud (VPC) è una rete privata sicura e isolata ospitata in Google Cloud. I VPC sono globali in Google Cloud, quindi un singolo VPC può includere più regioni senza comunicare tramite internet.

Un tipico deployment SAP posiziona le istanze dei sistemi HA in zone diverse nella stessa regione per garantire la resilienza e al contempo una bassa latenza. Le subnet possono essere distribuite su più zone grazie alle funzionalità di Google Cloud. Queste funzionalità semplificano anche il clustering SAP perché l'indirizzo IP virtuale (VIP) del cluster può essere nello stesso intervallo delle istanze dei sistemi HA. Questa configurazione protegge l'IP flottante utilizzando un bilanciatore del carico delle applicazioni interno ed è applicabile al clustering HA del livello di applicazione (ASCS ed ERS) e al livello del database SAP ASE o IBM Db2 (principale 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 di 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 con le proprie sottoreti, consentendo la comunicazione privata tra le risorse nei VPC in peering.

  • La VPC condivisa è una funzionalità di Google Cloud che consente a un'organizzazione di connettere risorse di più progetti a una rete VPC comune. I sistemi che utilizzano una VPC condiviso possono comunicare in modo efficiente e sicuro utilizzando indirizzi IP interni. Puoi gestire centralmente le risorse di rete come subnet, route e firewall in un progetto host, delegando al contempo le responsabilità amministrative per la creazione e la gestione delle singole risorse ai progetti di servizio. Questa separazione degli aspetti semplifica l'amministrazione della rete e applica criteri di sicurezza coerenti in tutta l'organizzazione.

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

Durante la progettazione della rete, inizia con un progetto host contenente una o più reti VPC condiviso. Puoi collegare altri progetti di servizio a un progetto host, in modo che possano partecipare al VPC condiviso. A seconda delle tue esigenze, puoi eseguire il deployment di SAP Business Suite su un singolo VPC condiviso o su più VPC condivisi. I due scenari differiscono in termini di controllo della rete, isolamento dell'ambiente SAP e ispezione della rete:

  • Scenario 1: implementazione di SAP Business Suite su un singolo VPC condiviso. In questo modo, il deployment viene semplificato e i costi amministrativi ridotti, a discapito di un isolamento inferiore tra le reti.
  • Scenario 2: implementazione di SAP Business Suite su più VPC condivisi. Ciò aumenta l'isolamento della rete e aggiunge sicurezza a spese dell'aumento della complicità e dell'overhead amministrativo.

È anche possibile utilizzare un approccio ibrido. Ad esempio, puoi utilizzare una VPC condiviso per l'ambiente di produzione e una VPC condiviso per tutti i sistemi non di produzione. Per ulteriori informazioni, consulta la sezione "Networking" in 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 punti di errore comuni che possono influire sulla disponibilità del sistema:

  • Servizi centrali SAP come Message Server ed Enqueue Server
  • Server 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 e queste opzioni prevedono il deployment del sistema utilizzando soluzioni ad alta disponibilità, servizi di replica o altre funzionalità che proteggono il sistema dagli errori. Quando pianifichi il sistema SAP Business Suite su SAP ASE o IBM Db2, ti consigliamo di studiare questi singoli punti di errore e di pianificare di conseguenza. Per una panoramica delle soluzioni alternative che puoi utilizzare per gestire i singoli punti di défaillance, 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 aiutano a misurare il rendimento di un servizio. È una misura quantitativa accuratamente definita relativa ad alcuni aspetti del livello del 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 chiamati 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.
  • Recovery Point Objective (RPO): il Recovery Point Objective (RPO) è la quantità massima di dati che può essere persa, misurata in tempo, senza causare danni significativi. In pratica, si tratta del punto nel tempo in cui lo stato dei dati interessati deve essere recuperato a seguito di 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 il ripristino di emergenza:

  • Disponibilità elevata (HA): la capacità di un sistema che supporta lo scopo della continuità aziendale garantendo al contempo la disponibilità di dati e servizi per gli utenti in caso di necessità. Il modo consueto per ottenere questa funzionalità è attivare la ridondanza, inclusa la ridondanza hardware, la ridondanza di rete e la ridondanza del data center.
  • Disaster recovery (RE): la capacità di un sistema di essere protetto da interruzioni impreviste tramite metodi di ripristino affidabili e prevedibili su hardware e/o posizioni fisiche diversi.

Sia l'alta disponibilità sia il ripristino di emergenza sono compatibili, ma coprono casi e situazioni diversi. Ad esempio, una soluzione HA ti consente di continuare le tue operazioni se uno degli elementi del sistema presenta un tempo di riposo o un'interruzione imprevista senza causare interruzioni per gli utenti. Lo stesso si può dire di una soluzione di RE, con l'eccezione di un'interruzione dal momento dell'interruzione fino all&#RE;avvio degli elementi difettosi del sistema in una posizione diversa.

Le sezioni seguenti forniscono una panoramica delle diverse opzioni a tua disposizione per pianificare e implementare il sistema SAP Business Suite su SAP ASE o IBM Db2 su Google Cloud.

Tipi di macchine supportati per le istanze SAP Business Suite

Google Cloud offre tipi di istanze VM Compute Engine che sono in possesso della certificazione SAP per soddisfare i requisiti di dimensionamento quando esegui il deployment di SAP Business Suite con SAP ASE o IBM Db2. Per ulteriori informazioni sulla definizione delle dimensioni su Google Cloud e sui tipi di macchine supportati, consulta i seguenti documenti:

Pianificare 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ù sedi di data center relativamente vicine tra loro. Ogni regione è composta da una o più zone con connettività, alimentazione e raffreddamento ridondanti.

Le risorse globali, come le immagini e gli snapshot dei dischi preconfigurati, possono essere accesse in regioni e zone diverse. Le risorse regionali, come gli indirizzi IP esterni statici regionali, sono accessibili solo alle risorse che si trovano nella stessa regione. Le risorse di zona, come VM e dischi, sono accessibili solo alle risorse che si trovano nella stessa zona. Per ulteriori informazioni, consulta Risorse globali, regionali e a livello di zona.

Regioni e zone Google Cloud.

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

  • La posizione degli utenti e delle risorse interne, ad esempio il data center o la rete aziendale. Per ridurre la latenza, seleziona una località in prossimità degli utenti e delle risorse.
  • Le piattaforme CPU disponibili per la regione e la zona. Ad esempio, i processori Broadwell, Haswell, Skylake e Ice Lake di Intel 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 che sono 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à disco rigido (HDD) standard per la gestione di operazioni di lettura/scrittura sequenziali, ma non ottimizzata per gestire un elevato numero di operazioni di input/output casuali al secondo (IOPS).
  • Disco permanente SSD (pd-ssd): fornisce archiviazione a blocchi affidabile e ad alte prestazioni supportata da unità a stato solido (SSD).
  • Disco permanente bilanciato (pd-balanced): fornisce archiviazione a blocchi basata su SSD affidabile e conveniente.
  • Disco permanente estremo (pd-extreme): basato su SSD; offre opzioni di IOPS e throughput massimi superiori rispetto a pd-ssd per i tipi di macchine Compute Engine più grandi. Per ulteriori informazioni, consulta Dischi permanenti Extreme.

Hyperdisk

  • Hyperdisk Extreme (hyperdisk-extreme): offre opzioni di IOPS e throughput massimi superiori rispetto ai volumi di Persistent Disk basati su SSD. Seleziona le prestazioni necessarie per il provisioning delle IOPS, che determinano il throughput. Per ulteriori informazioni, consulta Informazioni su HyperDisk di Google Cloud.

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

Persistent Disk e Hyperdisk sono progettati per garantire un'elevata durabilità. I dati vengono archiviati in maniera ridondante per assicurarne l'integrità. Ogni volume del Persistent Disk può memorizzare 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 utilizzato. Una funzionalità chiave è che i volumi di Persistent Disk e Hyperdisk vengono criptati automaticamente per proteggere i dati.

Al momento della creazione, un'istanza VM Compute Engine alloca per impostazione predefinita un singolo Persistent Disk o Hyperdisk principale contenente il sistema operativo. Puoi aggiungere altre opzioni di archiviazione all'istanza VM in base alle tue esigenze.

Per le implementazioni SAP, consulta le opzioni di archiviazione consigliate nella struttura della directory e nelle opzioni di archiviazione SAP.

Soluzioni di condivisione di file

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

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

Per saperne di più sulle soluzioni di condivisione file per SAP Business Suite su Google Cloud, consulta Soluzioni di condivisione file per SAP su Google Cloud.

Cloud Storage per l'archiviazione di oggetti

Cloud Storage è uno spazio di archiviazione di oggetti per file di qualsiasi tipo o formato. Ha uno spazio di archiviazione praticamente illimitato e non devi preoccuparti di eseguirne il provisioning o di aggiungere altra capacità. Un oggetto in Cloud Storage contiene i dati del file e i relativi metadati associati e può avere dimensioni fino a 5 TB. Un bucket Cloud Storage può archiviare un numero qualsiasi di oggetti.

È prassi comune utilizzare Cloud Storage per archiviare i file di backup per quasi tutti gli scopi. Ad esempio, Cloud Storage è un buon posto per archiviare i backup del database SAP ASE o IBM Db2. Per informazioni sulla pianificazione del backup del database, consulta Backup e recupero del database. Puoi anche utilizzare Cloud Storage nell'ambito di una procedura 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 saperne di più, consulta Soluzioni di backup e ripristino di emergenza con Google Cloud.

Scegli l'opzione Cloud Storage in base alla frequenza con cui devi accedere ai dati. Per gli accessi frequenti, ad esempio più volte al mese, seleziona la classe di archiviazione Standard. Per gli accessi non frequenti, seleziona Nearline o Coldline Storage. Per i dati archiviati a cui non prevedi di accedere, seleziona Archivia dati.

Struttura della directory e opzioni di archiviazione di SAP ASE

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

  • Struttura di directory Linux consigliata 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 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 log del database SAP ASE devono trovarsi nella directory /sybase/SAP_SID. Sostituisci SAP_SID con l'identificatore del sistema SAP (SID), ovvero il numero dell'istanza SAP che hai 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 Hyperdisk o Persistent Disk basato su SSD
    /sybase/SAP_SID/log_dir Hyperdisk o Persistent Disk basato su SSD
    /sybase/SAP_SID/saptemp Disco permanente bilanciato
    /sybase/SAP_SID/sapdiag Disco permanente bilanciato

    Per informazioni di SAP sull'esecuzione di SAP ASE, consulta SAP Applications on SAP Adaptive Server Enterprise - Best Practices for Migration and Runtime.

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

    Drive Descrizione Opzione di archiviazione consigliata in Google Cloud
    C:\ Avvio Disco permanente bilanciato
    D:\ Programmi binari del database Disco permanente bilanciato
    E:\ File di dati del database Hyperdisk o Persistent Disk basato su SSD
    L:\ File di log del database Hyperdisk o Persistent Disk 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 di SAP sull'esecuzione di SAP ASE, consulta SAP Applications on SAP Adaptive Server Enterprise - Best Practices for Migration and Runtime.

Struttura della directory e opzioni di archiviazione di IBM Db2

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

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

    Struttura della directory di 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 Hyperdisk o Persistent Disk basato su SSD
    /db2/DB_SID/log_dir Hyperdisk o Persistent Disk basato su SSD
    /db2/DB_SID/saptmp1 Disco permanente bilanciato
    /db2backup Disco permanente bilanciato

    Per informazioni di 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 del server centrale.

    Drive Descrizione Opzione di archiviazione consigliata in Google Cloud
    C:\ Avvio Disco permanente bilanciato
    D:\ Programmi binari del database Disco permanente bilanciato
    E:\ File di dati del database Hyperdisk o Persistent Disk basato su SSD
    L:\ File di log del database Hyperdisk o Persistent Disk 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 di directory, consulta la 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 scegli un sistema operativo (SO) per SAP NetWeaver su Google Cloud, oltre a verificare che la versione del SO sia certificata da SAP, devi anche confermare che tutte e tre le aziende, SAP, il fornitore del SO e Google Cloud, supportano ancora la versione del SO.

La tua decisione deve tenere conto anche di quanto segue:

  • Indica se una determinata versione del sistema operativo è disponibile su Google Cloud. Le immagini del sistema operativo fornite da Compute Engine sono configurate per funzionare con Google Cloud. Se un sistema operativo non è disponibile su Google Cloud, puoi utilizzare la tua immagine e la tua licenza del sistema operativo (BYOI). Le immagini del sistema operativo BYOI sono indicate da Compute Engine come immagini personalizzate.
  • Le opzioni di licenza disponibili per una determinata versione del sistema operativo. Controlla se la versione del sistema operativo offre un'opzione di licenza on demand o se devi utilizzare un abbonamento BYOS (Bring Your Own Subscription) del fornitore del sistema operativo.
  • Indica se le funzionalità di alta disponibilità integrate 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à sia con SAP Business Suite sia con 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é funge da 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 sia del deployment su Google Cloud sia del 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 dei dati.

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

Architettura di deployment per IBM Db2

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

Il seguente diagramma mostra un'architettura di deployment per IBM Db2 su Google Cloud. Nel diagramma, tieni presente sia il deployment su Google Cloud sia il layout del disco. 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 dei dati.

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

Architettura di deployment per SAP Business Suite

Come accennato nella sezione Architettura, esistono più architetture di deployment che puoi utilizzare per il deployment di SAP Business Suite su SAP ASE o IBM Db2 su Google Cloud.

Architettura a due livelli

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

Architettura a due livelli per SAP Business Suite su SAP ASE o IBM Db2 su una VM 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 Compute Engine:

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

In questa architettura, il sistema SAP Business Suite distribuisce il lavoro su più server di applicazioni NetWeaver (AS), ciascuno ospitato su una VM separata. Tutti i nodi NetWeaver AS condividono lo stesso database, che è ospitato su una VM distinta. 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 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 vuoi che il tuo carico di lavoro SAP venga eseguito 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 aiuta a eseguire carichi di lavoro sicuri e conformi su Google Cloud senza compromettere la qualità della tua esperienza cloud. Per ulteriori informazioni, consulta Controlli di conformità e sovranità per SAP su Google Cloud.

Networking e sicurezza della rete

Tieni presente le informazioni riportate nelle sezioni seguenti quando pianifichi la rete e la sicurezza della rete.

Modello di privilegio minimo

Una delle prime linee di difesa è limitare chi può raggiungere la tua rete e le tue VM. A tale scopo, utilizza 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 ha regole firewall predefinite.

Creando regole firewall VPC, puoi limitare tutto il traffico su un determinato insieme di porte ad indirizzi IP di origine specifici. Per limitare l'accesso agli indirizzi IP, ai protocolli e alle 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 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 collegate a quella rete. Tutte le reti Compute Engine utilizzano il protocollo IPv4. A ogni progetto Google Cloud è associata una rete predefinita con configurazioni e regole firewall predefinite, ma ti consigliamo di aggiungere una subnet personalizzata e regole firewall in base a un modello di privilegi minimi. Per impostazione predefinita, una rete appena creata non ha regole firewall e, di conseguenza, non ha accesso alla rete.

Ti consigliamo di aggiungere più di una sottorete se vuoi isolare parti della tua rete o soddisfare altri requisiti. Per saperne di più, consulta Reti e sottoreti.

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 nelle subnet. Puoi anche configurare i firewall in modo che vengano applicati a VM di destinazione specifiche utilizzando i tag di rete.

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

Route

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

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

Host bastioni e gateway NAT

Se i tuoi criteri di sicurezza richiedono VM veramente interne, devi configurare manualmente un proxy NAT sulla tua 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 utilizzando SSH.

Per connetterti a queste macchine interne, devi configurare un'istanza bastion con un indirizzo IP esterno e poi eseguire 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 da intermediari attendibili per le connessioni in entrata, chiamati host bastioni, o per l'uscita della rete, chiamati gateway NAT. Per una connettività più trasparente senza dover configurare queste connessioni, puoi utilizzare una risorsa gateway VPN gestita.

Bastion host per le connessioni in entrata

I bastion host forniscono un punto di accesso rivolto verso l'esterno per entrare in una rete che contiene VM con rete privata. Questo host può rappresentare un unico punto di fortificazione o controllo e può essere avviato e interrotto per attivare o disattivare la comunicazione SSH in entrata da internet.

Bastion host visualizzato nello scenario SSH.

L'accesso SSH alle VM che non dispongono di un indirizzo IP esterno può essere ottenuto collegandosi prima a un bastion host. L'applicazione completa di misure di hardening a un bastion host esula dall'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 per utilizzare le chiavi private per l'autenticazione. Quando utilizzi un bastion host, accedi prima al bastion host e poi alla VM privata di destinazione. A causa di questo accesso in due passaggi, ti consigliamo di utilizzare il forwarding dell'agente SSH per raggiungere la VM di destinazione anziché memorizzare la chiave privata della VM di destinazione sull'bastion host. Devi farlo anche se utilizzi la stessa coppia chiave-valore sia per la VM bastion che per la VM target perché la VM 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ò effettuare collegamenti diretti 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ò indirizzare il traffico per conto di qualsiasi altra VM sulla rete. Utilizza un gateway NAT per ogni rete. Un gateway NAT con una sola VM non è ad alta disponibilità e non può supportare un throughput elevato del traffico per più VM. Per informazioni su come configurare una VM per farla funzionare come gateway NAT, consulta la guida al deployment per il tuo sistema operativo:

Cloud VPN

Puoi connettere in sicurezza la tua rete esistente a Google Cloud tramite una connessione VPN che utilizza IPsec utilizzando Cloud VPN.VPNIPsec 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 tramite la VPN utilizzando i tag istanza sulle route. I tunnel Cloud VPN vengono fatturati a una tariffa mensile fissa più gli addebiti standard per il trasferimento di dati in uscita. Tieni presente che la connessione di due reti nello stesso progetto comporta comunque costi 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 dati e dei tuoi log, assicurati di utilizzare TLS (HTTPS) durante l'invio di dati a Cloud Storage dalle tue VM per proteggere i dati in transito.

Sebbene Cloud Storage cripti 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 abusi, Google Cloud impone 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 quanto segue:

Affidabilità

Questa sezione fornisce informazioni sugli aspetti relativi all'affidabilità per l'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 ingegneria e principi di progettazione per garantire la continuità aziendale in caso di guasti. Questi approcci funzionano eliminando i singoli punti di errore e offrendo la possibilità di riprendere rapidamente le operazioni dopo un'interruzione del sistema o del componente con interruzioni minime dell'attività. Il recupero degli errori è il processo di recupero e ripresa delle operazioni dopo un'interruzione a causa di un componente in stato di errore.

Ad esempio, di seguito sono riportati alcuni strumenti di HA e RE che puoi utilizzare:

Disponibilità elevata di SAP ASE

Puoi ottenere l'alta disponibilità per il tuo database SAP ASE su Google Cloud configurando la replica sincrona tra i server principali e di standby, in modo che i due server siano sempre sincronizzati senza alcuna perdita di dati. L'opzione always-on di SAP ASE, che è un sistema di alta disponibilità e di 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 principale e di riserva devono avere i seguenti componenti:

  • SAP ASE
  • Agente host SAP, che monitora l'utilizzo della CPU, della memoria e di altre risorse da parte del server.
  • Replication Management Agent (RMA)
  • SAP ASE Cockpit, che esegue attività di database
  • Fault Manager, che ha un proprio server host. Monitora i server SAP ASE principali e di riserva. 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. Inoltre, ti consente di controllare lo stato del database e di riavviarlo, se necessario.

Per migliorare la disponibilità del sistema, un cluster SAP ASE consente di spostare i workload sul nodo secondario monitorando l'eventuale guasto del nodo principale. Il seguente diagramma mostra un'architettura di riferimento di alto livello che dimostra come i componenti SAP ASE descritti possono essere installati su Google Cloud.

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

Ripristino di emergenza di SAP ASE

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

  • Server principale: questo server gestisce tutta l'elaborazione delle transazioni.
  • Nodo di riserva: questo server funge da riserva attiva per il server principale e contiene copie di database designati del server principale.
  • Nodo DR: questo server è geograficamente distante e esegue il backup dei database designati dal server principale.

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

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

Alta disponibilità e ripristino di emergenza di IBM Db2

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

  • Devi implementare due istanze separate del database IBM Db2, una principale e l'altra di standby. Devi mantenerli sincronizzati. Se l'istanza principale non funziona, l'istanza standby supporta il carico di lavoro.

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

  • Poiché HADR stesso non dispone del rilevamento e dell'automazione degli errori, devi anche eseguire il deployment di Pacemaker. Pacemaker monitora entrambe le istanze e, se l'istanza principale si arresta in modo anomalo, attiva il rilevamento di HADR da parte dell'istanza in standby, assicurandosi che l'indirizzo IP flottante venga assegnato alla nuova istanza principale.

    Pacemaker gestisce la gestione del cluster e un VIP viene utilizzato insieme al 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 alta disponibilità 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 tua 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 sia per i casi d'uso di produzione sia per quelli non di produzione. Le licenze del sistema operativo sono incluse nei prezzi di Compute Engine.

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

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

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

Sconti

Con il modello di prezzi con pagamento a consumo di Google Cloud, paghi solo per i servizi che utilizzi. Non devi impegnarti a un determinato servizio o a una dimensione specifica; puoi modificare o interrompere l'utilizzo in base alle tue esigenze. Per i carichi di lavoro prevedibili, Compute Engine fornisce sconti per impegno di utilizzo (CUD) che contribuiscono a ridurre il costo dell'infrastruttura impegnandosi a rispettare un contratto in cambio di prezzi molto scontati per l'utilizzo delle VM.

Google Cloud offre questi sconti in cambio dell'acquisto di contratti basati su impegno di utilizzo, noti anche come commitments. Quando acquisti un impegno, ti impegni a una quantità minima di utilizzo delle risorse o a una quantità di spesa minima per un periodo specifico di uno o tre anni. Questi sconti ti consentono di ridurre la fattura mensile per le risorse utilizzate dal tuo sistema SAP Business Suite. Per maggiori informazioni, consulta la pagina relativa agli sconti per impegno di utilizzo (CUD).

Stime delle dimensioni

Le seguenti risorse 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 di applicazioni e del database in modo da poter recuperare i dati in caso di arresto anomalo del sistema, danneggiamento dei dati o altri problemi.

Hai a disposizione diverse opzioni per eseguire il backup dei dati di 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 recupero di un database IBM Db2 su Google Cloud:

  • Backup e ripristino mediante dischi: puoi utilizzare i meccanismi di backup e ripristino flessibili 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 come vengono utilizzati i dischi e Cloud Storage per memorizzare i backup di un database SAP ASE:

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

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

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

    Diagramma che mostra il backup dei dati di SAP ASE utilizzando gli snapshot dei dischi.

Eseguire il backup di un database IBM Db2

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

  • Utilizza 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 completamente arrestato, rendendolo non disponibile per gli utenti durante la creazione del backup.

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

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

    Diagramma che mostra il backup dei dati di SAP ASE utilizzando gli snapshot dei dischi.

La procedura per creare il backup del database dipende dal numero di partizioni del database IBM Db2:

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

    1. Accedi al tuo server database come utente db2DB_SID.

    2. Esegui questo comando:

      db2 backup db DB_SID

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

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

    1. Accedi al tuo server database come utente db2DB_SID.

    2. Esegui questo comando:

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

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

    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, consulta il documento SAP Eseguire un backup del database.

Recuperare un database IBM Db2

Puoi recuperare il database IBM Db2 da un backup riuscito. Il recupero del database dipende dall'accessibilità a un file di cronologia aggiornato, poiché da qui si accede a tutte le informazioni sulle immagini di backup e sui file di log.

  • Per recuperare il database IBM Db2 da un backup:

    1. Accedi al server di database come utente db2DB_SID o SAP_SIDadm.

    2. Esegui questo comando:

      db2 RECOVER DB DB_SID

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

  • Per recuperare il database IBM Db2 a un momento specifico, completa i seguenti passaggi:

    1. Accedi al server di database come utente db2DB_SID o SAP_SIDadm.

    2. Esegui questo comando:

      db2 RECOVER DB DB_SID to LOCAL_TIME_ON_DB_SERVER

      Sostituisci quanto segue:

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

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

Monitoraggio

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

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

Oltre alla raccolta obbligatoria delle metriche di SAP Host Agent, su Linux, Agent per SAP di Google Cloud include funzionalità facoltative come la raccolta delle metriche di monitoraggio dei processi e delle metriche di valutazione di Workload Manager. Puoi attivare queste funzionalità che consentono di utilizzare prodotti e servizi come la gestione dei carichi di lavoro per i tuoi workload SAP.

Ottimizzazione delle prestazioni

Questa sezione fornisce informazioni sull'ottimizzazione del rendimento dei carichi di lavoro SAP Business Suite tramite la definizione delle dimensioni e la configurazione di rete.

Dimensionamento

Sono disponibili diverse opzioni di dimensionamento in base al tipo di implementazione. Per le implementazioni di tipo greenfield, consigliamo di utilizzare lo strumento SAP Quick Sizer. Per informazioni dettagliate, consulta la pagina Dimensionamento di SAP. SAP fornisce anche guide T-shirt per soluzioni e strumenti specifici per la migrazione delle attuali soluzioni on-premise a Google Cloud. Ad esempio, consulta la nota SAP Nota SAP 2456432 - Applicazioni SAP su Google Cloud: prodotti supportati e tipi di macchine Google Cloud. SAP e Google Cloud utilizzano unità diverse per misurare le IOPS (operazioni di I/O al secondo). Rivolgiti al tuo partner SI (Systems Integrator) per convertire i requisiti di dimensionamento di SAP in un'infrastruttura Google Cloud di dimensioni adeguate.

Per determinare le dimensioni di un database SAP ASE, consulta il documento SAP Dimensionamento di SAP ASE.

Per determinare le dimensioni di un database IBM Db2, consulta il benchmark di dimensionamento 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 della VM 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 è in grado di supportare un throughput di rete da 2 a 32 Gbps. Alcuni tipi di macchine supportano anche throughput fino a 100 Gbps, il che richiede l'utilizzo del tipo di interfaccia gVNIC (Google Virtual NIC) con una configurazione di rete Tier_1. La possibilità di raggiungere queste velocità in bit dipende inoltre dalla direzione del traffico e dal tipo di indirizzo IP di destinazione.

Le interfacce di rete delle VM 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 di base. È possibile utilizzare più NIC virtuali per la separazione del traffico, ma questo non offre alcun vantaggio aggiuntivo in termini di resilienza o prestazioni.

Una singola NIC fornisce le prestazioni necessarie per i deployment di SAP ASE o IBM Db2 su Compute Engine. Il tuo caso d'uso, i tuoi requisiti di sicurezza o le tue preferenze specifici potrebbero richiedere anche interfacce aggiuntive per separare il traffico, ad esempio il traffico internet, il traffico di replica interna SAP ASE o IBM Db2 HADR o altri flussi che potrebbero trarre vantaggio da regole specifiche dei criteri di rete. Ti consigliamo di utilizzare la crittografia del traffico offerta dall'applicazione e di proteggere l'accesso alla rete seguendo un criterio di firewall con privilegio minimo per limitare l'accesso.

Valuta in anticipo la necessità di separare il traffico nell'ambito della progettazione della rete e alloca NIC aggiuntive quando esegui il deployment delle VM. Devi collegare ogni interfaccia di rete a una rete VPC diversa. La scelta del numero di interfacce di rete dipende dal livello di isolamento richiesto, con un massimo di 8 interfacce consentite per le VM con almeno 8 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 di SAP prima del 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 qualsiasi implementazione SAP, controlla nel marketplace SAP se sono disponibili guide e note aggiornate per l'installazione dei prodotti.

Per ulteriori informazioni sull'installazione di SAP ASE o IBM Db2, consulta quanto segue:

Automazione del deployment

Automatizzare il deployment di SAP ASE

Per automatizzare il deployment dell'infrastruttura necessaria 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 all'implementazione per il tuo scenario.

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

Automatizzare il deployment di IBM Db2

Per automatizzare il deployment dell'infrastruttura necessaria 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 all'implementazione per il tuo scenario.

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

Passaggi successivi