Guida alla pianificazione di IBM Db2 per SAP

Questa guida fornisce informazioni che puoi utilizzare per pianificare l'installazione di un sistema IBM Db2 Advanced Enterprise Server Edition (AESE) (IBM Db2) che supporta le applicazioni SAP su Google Cloud.

Per eseguire il deployment di IBM Db2 con i prodotti SAP su Google Cloud, consulta:

Per i link a ulteriori informazioni di SAP su IBM Db2, consulta SAP su IBM Db2 per Linux, UNIX e Windows.

Per ulteriori informazioni sui prodotti su cui SAP certifica l'esecuzione Google Cloud, incluso IBM Db2, consulta la Nota SAP 2456432 - Applicazioni SAP su Google Cloud: prodotti e Google Cloud tipi di macchine supportati .

Google Cloud basics

Google Cloud è composto da molti prodotti e servizi basati su cloud. Quando esegui i prodotti SAP su Google Cloud, utilizzi principalmente i servizi basati su IaaS offerti tramite Compute Engine e Cloud Storage, nonché alcune funzionalità a livello di piattaforma, come gli strumenti.

Consulta la panoramica della piattaforma per informazioni sui concetti e sulla terminologia importanti.Google Cloud Questa guida duplica alcune informazioni della panoramica per praticità e contesto.

Per una panoramica delle considerazioni che le organizzazioni di grandi dimensioni devono tenere conto quando eseguono Google Cloud, consulta il Framework di architettura.Google Cloud

Interazione con Google Cloud

Google Cloud offre tre modi principali per interagire con la piattaforma e le tue risorse nel cloud:

  • La console Google Cloud, che è un'interfaccia utente basata sul web.
  • Lo strumento a riga di comando gcloud, che fornisce un superset delle funzionalità offerte dalla console Google Cloud.
  • Librerie client, che forniscono API per accedere ai servizi e gestire le risorse. Le librerie client sono utili per creare i tuoi strumenti.

Google Cloud servizi

I deployment SAP in genere utilizzano alcuni o tutti i seguenti Google Cloud servizi:

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 disco permanente 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 DP 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 dischi permanenti 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 informazioni significative tramite dashboard, grafici e avvisi. Puoi monitorare le metriche di calcolo senza costi tramite monitoring.
IAM

Fornisce un controllo unificato sulle 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.

Prezzi e quote

Puoi utilizzare il Calcolatore prezzi per stimare i costi di utilizzo. Per ulteriori informazioni sui prezzi, consulta Prezzi di Compute Engine, Prezzi di Cloud Storage e Prezzi di Google Cloud Observability.

Google Cloud sono soggette a quote. Se prevedi di utilizzare macchine con più CPU o con molta memoria, potresti dover richiedere una quota aggiuntiva. Per ulteriori informazioni, consulta Quote delle risorse di Compute Engine.

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, vedi Controlli di conformità e sovranità per SAP su Google Cloud.

Architettura di deployment

Un'installazione di IBM Db2 con un database a partizione singola su Google Cloud comprende i seguenti componenti:

  • Una VM Compute Engine su cui è in esecuzione il database IBM Db2.

  • Uno o più dischi con dischi permanenti per quanto segue:

    • Il disco principale.
    • Il volume dell'ID database (/db2/<DBSID>/),
    • Il volume dell'istanza (/db2/db2<dbsid>), che contiene la home directory dell'utente db2<dbsid> e i dati dell'istanza IBM Db2 per <DBSID>, nonché il software IBM Db2.
    • Il volume dei log (/db2/<DBSID>/log_dir), che contiene almeno i file di log del database online.
    • Il volume di dump/diagnostica (/db2/<DBSID>/db2dump), che contiene file di log di diagnostica Db2, file di dump Db2 e altre informazioni per gli ingegneri di servizio.
    • Il volume di dati (/db2/<DBSID>/sapdata<n> o /db2/<DBSID>/sapdata/sapdata<n>). Si tratta della posizione di archiviazione per gli spazi tabella con FILE dello spazio gestito dal database (DMS) di tipo contenitore o per gli spazi tabella con lo spazio di archiviazione automatico di Db2
    • Il volume dello spazio tabella temporaneo (/db2/<DBSID>/saptmp<n> o /db2/ <DBSID>/saptmp/saptmp<n>). Si tratta della posizione di archiviazione per gli spazi tabella temporanei.

A seconda dei requisiti dell'installazione, potrebbe essere necessario includere anche quanto segue:

  • Un gateway NAT. Un gateway NAT ti consente di fornire connettività internet alle tue VM, impedendo al contempo la connettività internet diretta a queste VM. Puoi anche configurare questa VM come bastion host che ti consente di stabilire connessioni SSH con le altre VM nella tua subnet privata. Per ulteriori informazioni, consulta Gateway NAT e host bastioni.
  • Un volume di backup per l'archiviazione dei backup semi-freddi.
  • Un volume di archiviazione per l'archiviazione degli archivi dei log.

Casi d'uso diversi potrebbero richiedere dispositivi o database aggiuntivi. Per ulteriori informazioni, consulta:

Requisiti delle risorse

In molti modi, l'esecuzione di IBM Db2 con SAP su Google Cloud è simile a eseguirla nel tuo data center. Devi comunque tenere conto delle risorse di calcolo, dell'archiviazione e delle considerazioni relative alla rete.

Per ulteriori informazioni, consulta la guida all'installazione appropriata per il tuo sistema SAP con IBM Db2.

Configurazione della VM

IBM Db2 è certificato per l'esecuzione su tutti i tipi di macchine Compute Engine, inclusi i tipi personalizzati. Nella maggior parte dei casi, utilizza un tipo di macchina con due o più CPU virtuali.

Per informazioni sui diversi tipi di macchine Compute Engine e sui relativi casi d'uso, consulta Tipi di macchine nella documentazione di Compute Engine.

Configurazione della CPU

Il numero di vCPU richieste varia a seconda del carico dell'applicazione su IBM Db2 LUW. Devi allocare almeno due vCPU all'installazione di IBM Db2. Per ottenere il massimo utilizzo delle risorse esistenti da parte del sistema IBM Db2, segui le indicazioni riportate nella documentazione di SAP su IBM Db2 per Linux, UNIX e Windows e modifica le risorse di calcolo in base alle esigenze.

Configurazione della memoria

La VM IBM Db2 deve avere almeno 4 GB di RAM per vCPU. Di questa quantità, circa l'80% della RAM deve essere allocato a IBM Db2, mentre il resto all'OS su cui è in esecuzione IBM Db2.

La quantità ottimale di memoria per il tuo caso d'uso dipende dalla complessità delle query che stai eseguendo, dalle dimensioni dei dati, dalla quantità di parallelismo che stai utilizzando e dal livello di prestazioni che prevedi. Per ulteriori indicazioni sull'ottimizzazione della configurazione della memoria, consulta la documentazione di SAP su IBM Db2 per Linux, UNIX e Windows.

Configurazione dello spazio di archiviazione

Per impostazione predefinita, ogni VM Compute Engine dispone di un piccolo disco permanente principale che contiene il sistema operativo. Inoltre, devi creare, collegare, formattare e montare dischi aggiuntivi per il database, i log e le procedure memorizzate.

Le dimensioni e i requisiti di prestazioni del disco dipendono dall'applicazione. Scegli le dimensioni di ogni dispositivo in base alle tue esigenze.

Per ulteriori informazioni sulle opzioni di disco permanente per IBM Db2, consulta Dischi permanenti.

Per indicazioni di SAP sulle dimensioni dei dischi, consulta:

Versioni di IBM Db2 supportate

Devi utilizzare i livelli del fix pack (FP) del software IBM Db2 certificati da SAP. L'uso di altri livelli di software IBM Db2 non è consentito.

Per ulteriori informazioni, consulta la Nota SAP 101809 - DB6: Supported Db2 Versions and Fix Pack Levels.

Funzionalità di IBM Db2 supportate

SAP supporta la maggior parte delle funzionalità di IBM Db2 su Google Cloud. Tuttavia, le seguenti funzionalità non sono supportate:

  • Database Db2 con più partizioni
  • Funzionalità IBM Db2 pureScale

Sistemi operativi supportati

SAP ha ottenuto la certificazione Google Cloud per l'esecuzione di IBM Db2 sulle seguenti immagini dei sistemi operativi SUSE Linux Enterprise Server (SLES), Red Hat Enterprise Linux (RHEL) e Windows Server:

  • SLES 12 SP2 e versioni successive
  • RHEL 7.4
  • Windows Server 2012 R2 e versioni successive

Per ulteriori informazioni sulle immagini di Compute Engine, consulta Immagini.

Considerazioni sul deployment

Aree geografiche e zone

Quando esegui il deployment di una VM, devi scegliere una regione e una zona. Una regione è una posizione geografica specifica in cui puoi eseguire le tue risorse e corrisponde a una posizione del data center. Ogni regione è composta da una o più zone.

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

Regioni e zone Google Cloud

Quando scegli regioni e zone per le tue VM, tieni presente quanto segue:

  • La posizione dei tuoi utenti e delle tue risorse interne, ad esempio il tuo data center o la tua rete aziendale. Per ridurre la latenza, seleziona una località in prossimità di utenti e risorse.
  • La posizione delle altre risorse SAP. L'applicazione SAP e il database devono trovarsi nella stessa zona.

Dischi permanenti

I dischi permanenti sono dispositivi di archiviazione a blocchi durevoli che funzionano in modo simile ai dischi fisici di un computer o di un server.

Compute Engine offre diversi tipi di dischi permanenti. Ogni tipo ha caratteristiche di prestazioni diverse. Google Cloud gestisce l'hardware sottostante dei dischi permanenti per garantire la ridondanza dei dati e ottimizzare le prestazioni.

Puoi utilizzare uno dei seguenti tipi di dischi permanenti Compute Engine:

  • Dischi permanenti standard (pd-standard): archiviazione a blocchi efficiente ed economica basata su 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).
  • SSD (pd-ssd): fornisce archiviazione a blocchi affidabile e ad alte prestazioni supportata da unità a stato solido (SSD).
  • Bilanciato (pd-balanced): fornisce archiviazione a blocchi basata su SSD affidabile e conveniente.
  • Estremo (pd-extreme): offre opzioni di throughput e IOPS massimi superiori rispetto a pd-ssd per i tipi di macchine Compute Engine di dimensioni maggiori. Per ulteriori informazioni, consulta la pagina Dischi permanenti Extreme.

Le prestazioni dei dischi permanenti SSD e bilanciati scalano automaticamente insieme alle dimensioni, perciò puoi modificarle ridimensionando i dischi permanenti esistenti o aggiungendone altri a una VM.

Anche il tipo di VM in uso e il numero di vCPU in essa contenute influiscono sulle prestazioni del disco permanente.

I dischi permanenti si trovano in modo indipendente dalle VM, per consentirti di scollegarli o spostarli in modo da conservare i dati anche dopo aver eliminato le VM.

Per ulteriori informazioni sui diversi tipi di dischi permanenti Compute Engine, sulle relative caratteristiche di prestazioni e su come utilizzarli, consulta la documentazione di Compute Engine:

SSD locale (non persistente)

Google Cloud offre inoltre unità disco SSD locali. Sebbene le unità SSD locali possano offrire alcuni vantaggi rispetto ai dischi permanenti, non utilizzarle all'interno di un sistema IBM Db2. Le istanze VM con SSD locali collegate non possono essere arrestate e riavviate.

Gateway NAT e host bastioni

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 bastionata 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 relè attendibili per le connessioni in entrata, chiamate bastion host, o per l'uscita di rete, chiamate gateway NAT. Per una connettività più trasparente senza configurare queste connessioni, puoi utilizzare una risorsa gateway VPN gestita.

Utilizzo di bastion host per le connessioni in entrata

I bastion host forniscono un punto di accesso rivolto verso l'esterno per entrare in una rete contenente 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 mostrato nello scenario SSH

Puoi ottenere l'accesso SSH alle VM che non dispongono di un indirizzo IP esterno collegandoti prima a un bastion host. L'hardening completo di un bastion host esula dall'ambito di questo articolo, ma puoi eseguire alcuni passaggi iniziali, tra cui:

  • 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, devi utilizzare il forwarding dell'agente SSH per raggiungere la VM di destinazione anziché memorizzare la chiave privata della VM di destinazione sull'host bastion. Devi farlo anche se utilizzi la stessa coppia di chiavi sia per la VM bastion che per la VM di destinazione, poiché la VM bastion ha accesso diretto solo alla metà pubblica della coppia di chiavi.

Utilizzo di gateway NAT per l'uscita del traffico

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ò instradare il traffico per conto di qualsiasi altra VM sulla rete. Devi avere un gateway NAT per rete. Tieni presente che un gateway NAT con una sola VM non deve essere considerato ad alta disponibilità e non può supportare un throughput elevato del traffico per più VM. Consulta la Guida al deployment di IBM Db2 per SAP NetWeaver per istruzioni su come configurare una VM come gateway NAT.

Immagini personalizzate

Una volta che il sistema è attivo e funzionante, puoi creare immagini personalizzate. Devi creare queste immagini quando modifichi lo stato del disco permanente di primo livello e vuoi poter ripristinare facilmente il nuovo stato. Dovresti avere un piano per gestire le immagini personalizzate che crei. Per ulteriori informazioni, consulta Best practice per la gestione delle immagini.

Identificazione utente e accesso alle risorse

Quando pianifichi la sicurezza per un deployment SAP su Google Cloud, devi identificare:

  • Gli account utente e le applicazioni che devono accedere alle Google Cloud risorse del tuo Google Cloud progetto
  • Le risorse Google Cloud specifiche del progetto a cui ogni utente deve accedere

Devi aggiungere ogni utente al progetto aggiungendo il relativo ID Account Google come principale. Per un programma di applicazione che utilizza risorseGoogle Cloud , crei un account di servizio che fornisce un'identità utente per il programma all'interno del progetto.

Le VM Compute Engine hanno un proprio account di servizio. Tutti i programmi eseguiti su una VM possono utilizzare l'account di servizio della VM, a condizione che l'account di servizio della VM disponga delle autorizzazioni delle risorse necessarie al programma.

Dopo aver identificato le Google Cloud risorse di cui ogni utente deve poter usufruire, devi concedere a ogni utente l'autorizzazione a utilizzare ogni risorsa assegnandogli ruoli specifici per le risorse. Esamina i ruoli predefiniti forniti dall'IAM per ogni risorsa e assegna a ogni utente ruoli che forniscono autorizzazioni sufficienti per completare le attività o le funzioni dell'utente e non di più.

Se hai bisogno di un controllo più granulare o restrittivo sulle autorizzazioni rispetto a quello fornito dai ruoli IAM predefiniti, puoi creare ruoli personalizzati.

Per saperne di più sui ruoli IAM di cui hanno bisogno i programmi SAP su Google Cloud, consulta Gestione di identità e accessi per i programmi SAP su Google Cloud.

Per una panoramica della gestione di identità e accessi per SAP su Google Cloud, consulta la Panoramica della gestione di identità e accessi 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.

Modello di privilegio minimo

Una delle prime linee di difesa è limitare chi può raggiungere la tua rete e le tue VM utilizzando i firewall. 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, puoi limitare tutto il traffico su un determinato insieme di porte a indirizzi IP di origine specifici. Devi seguire il modello di privilegio minimo per limitare l'accesso agli indirizzi IP, ai protocolli e alle porte specifici che richiedono l'accesso. Ad esempio, devi sempre configurare un bastion host e consentire l'accesso SSH al 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 è assegnata una rete predefinita con configurazioni e regole firewall predefinite, ma devi 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.

A seconda dei tuoi requisiti, ti consigliamo di aggiungere altre sottoreti per isolare parti della tua rete. Per ulteriori informazioni, consulta 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 nelle subnet. Puoi anche configurare i firewall in modo che vengano applicati a VM di destinazione specifiche utilizzando il meccanismo di tagging.

Alcuni prodotti SAP, come SAP NetWeaver, richiedono l'accesso a determinate porte. Assicurati di aggiungere 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 VM a VM 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 macchina virtuale come gateway NAT. Questa configurazione richiede di aggiungere il gateway NAT come route per l'istanza SAP. Per ulteriori informazioni, consulta Gateway NAT e host bastioni.

Cloud VPN

Puoi connettere in sicurezza la tua rete esistente a Google Cloud tramite una VPN connessione utilizzando IPsec utilizzando Cloud VPN. Il traffico tra le due reti viene criptato da un gateway VPN, quindi viene decriptato dall'altro gateway VPN. In questo modo i dati sono protetti mentre vengono trasmessi su internet. Puoi controllare dinamicamente le VM che 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 traffico in uscita. Tieni presente che il collegamento di due reti nello stesso progetto comporta comunque costi di uscita standard. Per ulteriori informazioni, consulta la panoramica di VPN e la sezione Scegliere un'opzione di routing VPN.

Protezione di un 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 dei dati a Cloud Storage dalle VM per proteggere i dati in transito. Cloud Storage cripta automaticamente i dati a riposo. Puoi specificare le tue chiavi di crittografia se hai un tuo sistema di gestione delle chiavi.

Consulta le seguenti risorse di sicurezza aggiuntive per il tuo ambiente SAP su Google Cloud:

Backup e ripristino

Devi avere un piano per ripristinare il sistema alle condizioni di funzionamento se accade il peggio.

Per informazioni sul backup e sul recupero dei sistemi IBM Db2 che supportano SAP, consulta:

Per indicazioni generali su come pianificare il ripristino di emergenza utilizzando Google Cloud, consulta:

Automazione per i deployment di IBM Db2

Google Cloud fornisce un file di configurazione Terraform che puoi utilizzare per automatizzare il deployment delle risorse per IBM Db2 con Linux.

La configurazione sap_db2.tf fornita da Google Cloud per IBM Db2 fornisce le seguenti risorse:

  • Un'istanza VM Compute Engine in base al tipo di macchina scelto.
  • Il sistema operativo Red Hat Enterprise Linux (RHEL) o SUSE Linux Enterprise Server (SLES) che preferisci.
  • I dischi permanenti di Compute Engine.
  • L'agente di monitoraggio di Google Cloudper SAP NetWeaver.

Per le istruzioni sull'automazione del deployment, consulta Deployment automatico delle VM per IBM Db2 su Linux utilizzando Terraform.

Cluster IBM Db2 ad alta disponibilità

Puoi configurare un cluster IBM Db2 ad alta disponibilità e resiliente ai disastri su Google Cloud supportato da SAP. Il cluster è configurato e gestito da IBM Tivoli System Automation for Multiplatforms (TSAMP) e utilizza la funzione IBM Db2 HADR a scopo di replica.

Le applicazioni si connettono al server IBM Db2 principale tramite un indirizzo IP dinamico che, in caso di failover, TSAMP riassegna al server di riserva.

La funzione IBM Db2 HADR supporta fino a tre server di riserva. Su Google Cloud, le VM host del cluster devono trovarsi nella stessa regione, ma possono trovarsi in zone diverse all'interno della regione.

Il supporto SAP per i cluster DB2 HA su Google Cloud è elencato nella Nota SAP 2456432 - Applicazioni SAP su Google Cloud: prodotti e Google Cloud tipi di macchine supportati .

Per informazioni sulle funzionalità di IBM Db2 supportate da SAP, consulta la nota SAP 1555903.

Architetture di deployment

Puoi eseguire il deployment delle VM host in un cluster IBM Db2 HA in più zone Compute Engine nella stessa regione o, se necessario, in una singola zona.

Per la massima disponibilità, esegui il deployment di ogni VM host in una zona diversa.

Il seguente diagramma mostra un deployment multizona che utilizza un'implementazione di route statici per l'indirizzo IP dinamico.

Ogni host di un cluster Db2 HA viene implementato in una zona diversa.

Il seguente diagramma mostra un deployment a zona singola che utilizza un'implementazione di indirizzo IP alias per l'indirizzo IP dinamico.

Entrambi gli host di un cluster Db2 HA vengono dipartiti nella stessa zona.

Documentazione obbligatoria

Per eseguire il deployment di un cluster IBM Db2 HA per SAP, devi seguire la documentazione sia di SAP sia diGoogle Cloud .

Potresti dover fare riferimento a ulteriore documentazione SAP o IBM durante l'installazione dei componenti SAP e IBM.

Requisiti specifici per un cluster IBM Db2 ad alta disponibilità su Google Cloud

A partire dal giorno Google Cloud, SAP supporta i cluster IBM Db2 ad alta disponibilità solo sui sistemi operativi RHEL o SLES.

Per i Google Cloud requisiti software per le istanze IBM Db2, consulta Requisiti delle risorse.

Per IBM TSAMP, utilizza la versione più recente disponibile supportata dalla versione di IBM Db2 e dal sistema operativo.

Per tutti gli altri requisiti hardware e software, consulta la soluzione IBM Db2 ad alta disponibilità: IBM Tivoli System Automation for Multiplatforms.

Indirizzi IP mobili per i cluster IBM Db2 HA su Google Cloud

Un cluster IBM Db2 ad alta disponibilità per SAP utilizza un indirizzo IP mobile, noto anche come "indirizzo IP virtuale" o "indirizzo IP condiviso".

Per un cluster IBM Db2 HA, Google Cloud puoi implementare un indirizzo IP dinamico utilizzando una route statica o un Google Cloud indirizzo IP alias. Google Cloud

L'implementazione della route statica è consigliata per i cluster IBM Db2 HA multizona. I deployment multizona contribuiscono ad assicurarti che un errore in una singola zona non causi il fermo del sistema IBM Db2.

Tuttavia, se l'architettura di rete non supporta le route statiche o se devi evitare soluzioni come l'overlay IP o il routing complesso, puoi utilizzare l'implementazione dell'indirizzo IP alias con un cluster IBM Db2 HA a una zona. Gli indirizzi IP alias non sono consigliati per i deployment multizona perché la riallocazione dell'alias potrebbe non essere garantita in caso di guasto zonale.

A seconda che tu scelga l'implementazione della route statica o l'implementazione dell'alias IP, i requisiti per l'indirizzo IP utilizzato per l'indirizzo IP dinamico sono diversi.

L'utilizzo di una route statica richiede la selezione di un indirizzo IP per l'indirizzo IP dinamico che sia:

  • Al di fuori degli intervalli IP delle subnet Virtual Private Cloud esistenti in cui si trovano le VM.
  • Non entri in conflitto con indirizzi IP esterni nella rete estesa.

Rivolgiti all'amministratore di rete per determinare un indirizzo IP adatto per l'implementazione di un percorso statico.

L'utilizzo di un indirizzo IP alias richiede la prenotazione di un indirizzo IP dall'intervallo IP della subnet da utilizzare come indirizzo IP dinamico.

Per saperne di più sugli indirizzi IP mobili su Google Cloud, consulta Best practice per gli indirizzi IP mobili.

SAP consiglia di utilizzare indirizzi IP flottanti nei cluster IBM Db2 HA. SAP supporta il reindirizzamento automatico dei client (ACR), a condizione che vengano presi in considerazione tutti i requisiti e le limitazioni di questo metodo. Per ulteriori informazioni, consulta la nota SAP 1568539.

Il criterio di parità della rete

I cluster IBM Db2 HA in genere inviano una richiesta ICMP (ping) a un gateway di rete, che funge da tie-breaker di rete predefinito per determinare quale nodo deve assumere il controllo quando la comunicazione tra i nodi di un cluster viene persa.

Poiché i gateway di rete su Google Cloud non rispondono alle richieste ICMP, utilizza qualsiasi altro indirizzo IP a cui è possibile eseguire un ping e che sia molto disponibile. Ad esempio, puoi utilizzare l'indirizzo IP virtuale della tua istanza di Central Services dell'applicazione SAP o il DNS di Google, 8.8.8.8.

Se il tie-breaker di rete non può rispondere alle richieste ICMP durante la configurazione, la configurazione non va a buon fine.

Esistono altri criteri di parità della rete e sono definiti da IBM. Per ulteriori informazioni, consulta la sezione Configurare il criterio di spareggio.

Strumenti di configurazione per un cluster Db2 ad alta disponibilità

Per configurare un cluster IBM Db2 HADR, puoi utilizzare uno dei seguenti strumenti forniti da SAP e IBM:

  • Lo strumento di configurazione del cluster SAP (sapdb2cluster.sh)
  • L'utilità di configurazione delle istanze ad alta disponibilità di IBM DB2 (db2haicu)

Strumento di configurazione del cluster SAP Db2 (sapdb2cluster.sh)

SAP consiglia lo strumento di configurazione del cluster fornito da SAP, sapdb2cluster.sh, per configurare e creare un cluster Db2 HA. Le Google Cloud istruzioni di deployment utilizzano lo strumento di configurazione del cluster SAP. Lo strumento di configurazione del cluster semplifica gran parte della configurazione del cluster e garantisce che soddisfi i requisiti di supporto SAP.

Prima di creare il cluster HA con lo strumento di configurazione del cluster SAP, uno dei passaggi delle istruzioni di deployment apporta una piccola modifica allo strumento di configurazione del cluster SAP, sapdb2cluster.sh, in modo che lo strumento salti la creazione della classe di risorse IBM.ServiceIP predefinita. Google Cloud

Le risorse create dalla classe di risorse IBM.ServiceIP di IBM TSAMP inviano richieste ARP gratuite, che non sono supportate nelle reti VPC su Google Cloud, come spiegato in Problemi di migrazione degli IP flottanti a Compute Engine.

Per scaricare la versione più recente dello strumento di configurazione del cluster, consulta la nota SAP 960843.

L'utilità di configurazione delle istanze IBM DB2 ad alta disponibilità (db2haicu)

In alternativa allo strumento di configurazione del cluster SAP, puoi utilizzare l'utilità IBM db2haicu, che fornisce anche un'interfaccia interattiva. Lo strumento di configurazione del cluster SAP utilizza db2haicu per la configurazione del cluster.

Quando utilizzi l'utilità db2haicu, devi prima configurare il rapporto HADR prima di poter utilizzare l'utilità db2haicu per configurare il cluster. Sebbene la procedura di configurazione complessiva possa essere più complessa con l'utilità db2haicu, quest'ultima consente una maggiore personalizzazione per configurazioni di rete complesse o altri requisiti specifici del tuo ambiente.

Segui sempre le linee guida di SAP e IBM quando utilizzi l'utilità db2haicu.

Per ulteriori informazioni su db2haicu, consulta la documentazione di IBM Db2.

Google Cloud Script di assistenza per l'integrazione del cluster IBM TSAMP

Per consentire al cluster IBM Db2 HA di chiamare i comandi API appropriati per avviare, arrestare e monitorare la risorsa TSAMP per l'indirizzo IP dinamico, devi scaricare uno script di assistenza da Google Cloud alle VM host. Google Cloud Quando crei la risorsa indirizzo IP mobile in IBM TSAMP, fai riferimento allo Google Cloud script di assistenza.

Licenze

Questa sezione fornisce informazioni sui requisiti di licenza.

Licenze IBM Db2

Quando esegui IBM Db2 su Google Cloud, devi utilizzare una licenza di tua proprietà (BYOL). Puoi acquistare le licenze Db2 da SAP o da IBM. Per ulteriori informazioni su licenze e assistenza, consulta le seguenti note SAP:

Per ulteriori informazioni sulle licenze SAP, contatta SAP.

Licenze del sistema operativo

In Compute Engine, esistono due modi per concedere in licenza SLES, RHEL e Windows Server:

  • Con le licenze con pagamento a consumo, il costo orario della VM Compute Engine include le licenze. Google gestisce la logistica delle licenze. I costi ora sono più elevati, ma hai la massima flessibilità per aumentarli e diminuirli, in base alle esigenze. Questo è il modello di licenza utilizzato per le Google Cloud immagini pubbliche che includono SLES, RHEL e Windows Server.

  • Con BYOL, i costi delle VM Compute Engine sono inferiori perché le licenze non sono incluse. Devi eseguire la migrazione di una licenza esistente o acquistare la tua licenza, il che significa pagare in anticipo e avere meno flessibilità.

Assistenza

Per problemi relativi all' Google Cloud infrastruttura o ai servizi, contatta l'assistenza clienti. Puoi trovare i dati di contatto nella pagina Panoramica dell'assistenza nella console Google Cloud. Se l'assistenza clienti stabilisce che il problema riguarda i tuoi sistemi SAP, ti verrà consigliato di rivolgerti all'assistenza SAP.

Per problemi relativi ai prodotti SAP, registra la richiesta di assistenza con l'assistenza SAP. SAP valuta il ticket di assistenza e, se sembra essere un Google Cloud problema di infrastruttura, lo trasferisce al componenteGoogle Cloud appropriato nel proprio sistema: BC-OP-LNX-GOOGLE o BC-OP-NT-GOOGLE.

Requisiti di assistenza

Prima di poter ricevere assistenza per i sistemi SAP e per l'Google Cloud infrastruttura e i servizi che utilizzano, devi soddisfare i requisiti minimi del piano di assistenza.

Per ulteriori informazioni sui requisiti minimi di assistenza per SAP su Google Cloud, consulta:

Per informazioni sull'assistenza SAP per Db2, consulta la nota SAP 1168456 - DB6: Support Process and End of Support Dates for IBM DB2 LUW

Passaggi successivi

Per eseguire il deployment di IBM Db2 su Google Cloud, consulta:

Per eseguire il deployment di un cluster IBM Db2 ad alta disponibilità in Google Cloud, consulta la guida al deployment del cluster IBM Db2 ad alta disponibilità per SAP.