Guida alla pianificazione di IBM Db2 per SAP

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

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

Per saperne di più su SAP su IBM Db2, consulta SAP su IBM Db2 per Linux, UNIX e Windows.

Per ulteriori informazioni sui prodotti che SAP certifica per l'esecuzione su Google Cloud, incluso IBM Db2, consulta la nota SAP 2456432: applicazioni SAP su Google Cloud Platform: prodotti supportati e tipi di VM Google.

Nozioni di base su Google Cloud

Google Cloud comprende molti prodotti e servizi basati su cloud. Quando esegui prodotti SAP su Google Cloud, utilizzi principalmente i servizi basati su IaaS offerti da Compute Engine e Cloud Storage, oltre ad alcune funzionalità a livello di piattaforma, come strumenti.

Consulta la panoramica di Google Cloud Platform per concetti importanti e terminologia. Questa guida duplica alcune informazioni dalla panoramica per praticità e contesto.

Per una panoramica delle considerazioni che le organizzazioni su scala aziendale devono prendere in considerazione quando vengono eseguite su Google Cloud, consulta il framework dell'architettura Google Cloud.

Interazione con Google Cloud

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

  • La console Google Cloud, che è un'interfaccia utente basata sul Web.
  • Lo strumento a riga di comando gcloud, che offre un soprainsieme di funzionalità offerte dalla console Google Cloud.
  • Librerie client, che forniscono API per l'accesso ai servizi e la gestione delle risorse. Le librerie client sono utili quando crei i tuoi strumenti.

Servizi Google Cloud

In genere, i deployment SAP utilizzano alcuni o tutti i seguenti servizi Google Cloud:

Servizio Descrizione
Rete VPC Connette le istanze VM tra loro e a Internet. Ogni istanza è membro di una rete legacy con un singolo intervallo IP globale o di una rete di subnet consigliata, dove l'istanza è membro di una singola subnet che è membro di una rete più grande. Tieni presente che una rete non può estendersi su progetti Google Cloud, ma un progetto Google Cloud può avere più reti.
Compute Engine Crea e gestisce le VM con il tuo sistema operativo e il tuo stack software a tua scelta.
Dischi permanenti I dischi permanenti sono disponibili come unità disco rigido (HDD) standard o unità a stato solido (SSD).
Console Google Cloud Strumento basato su browser per la gestione delle risorse di Compute Engine. Utilizza un modello per descrivere tutte le risorse e le istanze di Compute Engine di cui hai bisogno. Non devi creare e configurare individualmente le risorse o capire le dipendenze, perché la console Google Cloud fa al caso tuo.
Cloud Storage Puoi effettuare il backup dei backup del tuo database SAP in Cloud Storage per avere una maggiore durabilità e affidabilità, con replica.
Cloud Monitoring Offre visibilità su deployment, prestazioni, uptime e integrità di Compute Engine, della rete e dei dischi permanenti.

Monitoring raccoglie metriche, eventi e metadati da Google Cloud e li utilizza per generare insight tramite dashboard, grafici e avvisi. Puoi monitorare le metriche di calcolo senza costi aggiuntivi tramite Monitoring.
IAM Fornisce un controllo unificato sulle autorizzazioni per le risorse Google Cloud. Stabilisci chi può eseguire operazioni del piano di controllo sulle tue VM, tra cui creazione, modifica ed eliminazione di VM e dischi permanenti, nonché creazione e modifica delle reti.

Prezzi e quote

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

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

Architettura di deployment

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

  • Una VM di Compute Engine che esegue il tuo database IBM Db2.
  • Una o più unità disco permanente per le seguenti applicazioni:

    • Il disco radice.
    • Il volume dell'ID del 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 del 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 i file di log diagnostici di Db2, i file di dump di Db2 e ulteriori informazioni del tecnico di servizio.
    • Il volume dei dati (/db2/<DBSID>/sapdata<n> o /db2/<DBSID>/sapdata/sapdata<n>). Questa è la posizione di archiviazione delle tabelle con spazi gestiti del database (DMS) di tipo container o delle tabelle con spazio di archiviazione automatico di Db2.
    • Il volume temporaneo della tabella (/db2/<DBSID>/saptmp<n> o /db2/ <DBSID>/saptmp/saptmp<n>). Questa è la posizione di archiviazione per le tabelle temporanee.

A seconda dei requisiti di installazione, potresti anche dover includere quanto segue:

  • Un gateway NAT. Un gateway NAT consente di fornire una connettività Internet per le tue VM, negando anche la connettività Internet diretta a tali VM. Puoi anche configurare questa VM come bastion host che ti consenta di stabilire connessioni SSH alle altre VM nella tua subnet privata. Per ulteriori informazioni, consulta la sezione Gateway NAT e bastion host.
  • Un volume di backup per l'archiviazione dei backup caldi.
  • Un volume di archiviazione per l'archiviazione degli archivi di log.

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

Requisiti delle risorse

Per molti aspetti, l'esecuzione di IBM Db2 con SAP su Google Cloud è simile all'esecuzione nel tuo data center. Devi comunque pensare a risorse di calcolo, archiviazione e networking.

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

Configurazione 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 CPU

Il numero di vCPU richiesto dipende dal carico dell'applicazione su IBM Db2 LUW. Devi allocare almeno due vCPU all'installazione di IBM Db2. Per utilizzare al meglio le risorse esistenti tramite il sistema IBM Db2, segui le indicazioni riportate nella documentazione relativa a SAP su IBM Db2 per Linux, UNIX e Windows e modifica le risorse di computing in base alle tue esigenze.

Configurazione della memoria

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

La quantità di memoria ottimale per il tuo caso d'uso dipende dalla complessità delle query in esecuzione, dalla dimensione dei tuoi dati, dalla quantità di parallelismo utilizzato e dal livello di prestazioni previsto. Per ulteriori indicazioni sull'ottimizzazione della configurazione della memoria, consulta la documentazione di SAP su IBM Db2 per Linux, UNIX e Windows.

Configurazione spazio di archiviazione

Per impostazione predefinita, ogni VM di Compute Engine ha un piccolo disco permanente radice che contiene il sistema operativo. Inoltre, dovete creare, collegare, formattare e montare dischi aggiuntivi per il vostro database, i vostri log e le vostre stored procedure.

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

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

Per indicazioni da SAP sul dimensionamento del disco, consulta:

Versioni IBM Db2 supportate

SAP NetWeaver certificato SAP con le seguenti versioni di IBM Db2 su Google Cloud:

  • Db2 Advanced Enterprise Server Edition (AESE) versione 11.1 per Linux, UNIX e Windows
  • Db2 Advanced Enterprise Server Edition (AESE) versione 10.5 per Linux, UNIX e Windows

Devi utilizzare i livelli di pacchetti software (FP) IBM Db2 certificati SAP. L'utilizzo di altri livelli software IBM Db2 non è consentito.

Per ulteriori informazioni, vedi Nota SAP 101809-DB6: versioni Db2 supportate e correzione dei livelli dei pacchetti.

Funzioni IBM Db2 supportate

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

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

Sistemi operativi supportati

SAP ha certificato Google Cloud per l'esecuzione di IBM Db2 sui seguenti 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 località geografica specifica in cui puoi eseguire le tue risorse e corrisponde a una località del data center. Ogni regione è composta da una o più zone.

È possibile accedere a risorse globali, come immagini del disco e snapshot del disco preconfigurati, in regioni e zone. Le risorse a livello di area geografica, come gli indirizzi IP esterni statici, sono accessibili solo alle risorse che si trovano nella stessa area geografica. Le risorse di zona, come VM e dischi, sono accessibili solo dalle risorse che si trovano nella stessa zona.

Regioni e zone di Google Cloud

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

  • La località degli utenti e delle risorse interne, ad esempio il data center o la rete aziendale. Per ridurre la latenza, seleziona una località vicina agli utenti e alle risorse.
  • La località 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 desktop o di un server.

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

Puoi utilizzare uno qualsiasi dei seguenti tipi di disco permanente di Compute Engine:

  • Dischi permanenti standard (pd-standard): archiviazione a blocchi efficiente ed economica supportata da unità disco rigido (HDD) standard per la gestione delle operazioni di lettura/scrittura sequenziale, ma non ottimizzata per la gestione di frequenze 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).
  • Bilanciata (pd-balanced): fornisce archiviazione a blocchi basata su SSD a costi contenuti e affidabile.
  • Estrema (pd-extreme): fornisce opzioni di IOPS e velocità effettiva massime più elevate di pd-ssd per i tipi di macchine Compute Engine più grandi. Per maggiori informazioni, vedi Dischi permanenti con carico estremo.

Le prestazioni degli SSD e dei dischi permanenti bilanciati scalano automaticamente in base alle dimensioni, permettendoti di regolare le prestazioni mediante il ridimensionamento dei dischi permanenti esistenti o l'aggiunta di più dischi permanenti a una VM.

Il tipo di VM in uso e il numero di vCPU che contiene influiscono anche sulle prestazioni del disco permanente.

I dischi permanenti si trovano indipendentemente dalle tue VM, quindi puoi scollegare o spostare i dischi permanenti per conservare i dati, anche dopo aver eliminato le VM.

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

SSD locale (non persistente)

Google Cloud offre anche unità disco SSD locali. Anche se gli SSD locali possono offrire alcuni vantaggi rispetto ai dischi permanenti, non utilizzarli come parte di un sistema IBM Db2. Le istanze VM con SSD locali collegati non possono essere arrestate e riavviate.

Gateway NAT e bastion host

Se il tuo criterio di sicurezza richiede VM effettivamente interne, devi configurare manualmente un proxy NAT sulla rete e una route corrispondente in modo che le VM possano accedere a 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 di bastion che abbia un indirizzo IP esterno e quindi attraversarla tramite tunnel. Se 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 come agenti affidabili per le connessioni in entrata, chiamate bastion host, o in uscita dalla rete, chiamati gateway NAT. Per una connettività più trasparente senza configurare tali connessioni, puoi utilizzare una risorsa gateway VPN gestita.

Bastion host per le connessioni in entrata

Gli host di base forniscono un punto di accesso, rivolto verso l'esterno, per entrare in una rete che contiene VM di reti private. Questo host può fornire un solo punto di fortificazione o controllo e può essere avviato e arrestato per attivare o disattivare la comunicazione SSH in entrata da Internet.

Bastion host mostrato nello scenario SSH

Puoi accedere SSH alle VM che non hanno un indirizzo IP esterno connettendosi prima a un bastion host. Un protezione completa di un bastion host non rientra nell'ambito di questo articolo, ma puoi seguire 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 su VM è configurato per l'utilizzo di chiavi private per l'autenticazione. Quando usi un bastion host, devi prima accedere a quest'ultimo e poi alla VM privata di destinazione. Grazie a questo accesso in due passaggi, devi utilizzare l'inoltro SSH-agent per raggiungere la VM di destinazione invece di archiviare la chiave privata della VM di destinazione sul bastion host. Devi eseguire questa operazione anche se utilizzi la stessa coppia di chiavi sia per il bastion che per le VM di destinazione, in quanto il bastion ha accesso diretto soltanto alla metà pubblica della coppia di chiavi.

Utilizzo di gateway NAT per il traffico in uscita

Se a una VM non è assegnato un indirizzo IP esterno, non può effettuare connessioni dirette ai 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 in grado di instradare il traffico per conto di qualsiasi altra VM sulla rete. Ogni rete deve avere un gateway NAT. Tieni presente che un gateway NAT NAT con VM singola non deve essere considerato a disponibilità elevata e non può supportare una velocità effettiva di traffico elevato per più VM. Per istruzioni su come configurare una VM come gateway NAT, consulta la guida al deployment di IBM Db2 per SAP NetWeaver.

Immagini personalizzate

Una volta che il sistema è attivo, puoi creare immagini personalizzate. Dovresti creare queste immagini quando modifichi lo stato del disco permanente radice e vuoi poter ripristinare facilmente il nuovo stato. Dovresti avere un piano per la gestione delle immagini personalizzate che crei. Per saperne di più, consulta Best practice per la gestione delle immagini.

Identificazione degli utenti 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 risorse Google Cloud nel tuo progetto Google Cloud
  • Le risorse Google Cloud specifiche nel tuo progetto a cui ogni utente deve accedere

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

Le VM di Compute Engine hanno un proprio account di servizio. Tutti i programmi eseguiti su una VM possono utilizzare l'account di servizio VM, purché l'account di servizio VM disponga delle autorizzazioni per le risorse necessarie per il programma.

Dopo aver identificato le risorse Google Cloud che ogni utente deve utilizzare, concedi a ciascun utente l'autorizzazione a utilizzare ogni risorsa assegnandogli ruoli specifici per la risorsa. Esamina i ruoli predefiniti forniti da IAM per ogni risorsa e assegna a ciascun utente i ruoli che forniscono autorizzazioni sufficienti per completare le attività o le funzioni dell'utente e altro ancora.

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

Per ulteriori informazioni sui ruoli IAM di cui i programmi SAP hanno bisogno su Google Cloud, consulta Identity and Access Management per i programmi SAP su Google Cloud.

Per una panoramica della gestione di identità e accessi per SAP su Google Cloud, consulta la panoramica di Identity and Access Management per SAP su Google Cloud.

Networking e sicurezza della rete

Considera le informazioni nelle sezioni seguenti quando pianifichi networking e sicurezza.

Modello di privilegi minimo

Una delle tue prime linee di difesa è quella di limitare gli utenti che possono raggiungere la tua rete e le tue VM utilizzando i firewall. Per impostazione predefinita, il traffico verso le VM, anche da altre VM, è bloccato dal firewall a meno che non crei regole per consentire l'accesso. L'unica eccezione è la rete predefinita, creata automaticamente con ogni progetto e dotata delle regole firewall predefinite.

Creando regole firewall puoi limitare tutto il traffico su un determinato insieme di porte a specifici indirizzi IP di origine. Segui il modello di privilegio minimo per limitare l'accesso a specifici indirizzi IP, protocolli e porte che richiedono l'accesso. Ad esempio, dovresti sempre configurare un host di bass e consentire SSH nel 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 tale rete. Tutte le reti Compute Engine utilizzano il protocollo IPv4. A ogni progetto Google Cloud è assegnata una rete predefinita con configurazioni predefinite e regole firewall, ma ti consigliamo di aggiungere una subnet personalizzata e delle regole firewall in base a un modello di privilegi minimi. Per impostazione predefinita, una rete appena creata non ha regole firewall e quindi non ha accesso alla rete.

A seconda dei requisiti, potresti aggiungere ulteriori subnet per isolare parti della rete. Per ulteriori informazioni, consulta la sezione Subnet.

Le regole firewall si applicano all'intera rete e a tutte le VM della rete. Puoi aggiungere una regola firewall che consenta il traffico tra VM nella stessa rete e tra subnet. Puoi anche configurare i firewall da applicare 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 le regole firewall per consentire l'accesso alle porte descritte da SAP.

Route

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

Per l'accesso esterno alle risorse Internet, avvia una VM senza indirizzi IP esterni e configura un'altra macchina virtuale come gateway NAT. Questa configurazione richiede l'aggiunta del gateway NAT come route per l'istanza SAP. Per ulteriori informazioni, consulta la pagina relativa ai gateway e ai bastion host NAT.

Cloud VPN

Puoi connettere in modo sicuro la rete esistente a Google Cloud tramite una connessione VPN utilizzando IPsec utilizzando Cloud VPN. Il traffico tra le due reti è 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 verso la VPN utilizzando i tag di istanza sulle route. I tunnel Cloud VPN sono fatturati con una tariffa mensile statica più tariffe in uscita standard. Tieni presente che il collegamento di due reti nello stesso progetto comporta ancora addebiti standard in uscita. Per ulteriori informazioni, consulta la pagina Panoramica della VPN e Scelta di un'opzione di routing per la VPN.

Protezione di un bucket Cloud Storage

Se utilizzi Cloud Storage per ospitare i tuoi backup di dati e log, assicurati di utilizzare TLS (HTTPS) durante l'invio dei dati a Cloud Storage dalle tue VM per proteggere i dati in transito. Cloud Storage cripta automaticamente i dati at-rest. Se hai un tuo sistema di gestione delle chiavi, puoi specificare le tue chiavi di crittografia.

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

Backup e ripristino

Se è peggiore, devi avere un piano su come ripristinare la condizione operativa del sistema.

Per informazioni sul backup e sul ripristino 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 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 esegue il provisioning delle seguenti risorse:

  • Un'istanza VM di Compute Engine basata sul tipo di macchina di tua scelta.
  • Scelta del sistema operativo Red Hat Enterprise Linux (RHEL) o SUSE Linux Enterprise Server (SLES).
  • di Compute Engine.
  • L'agente di monitoraggio di Google Cloud per SAP NetWeaver.

Per istruzioni sull'automazione del deployment, consulta la pagina relativa al deployment automatico delle VM per IBM Db2 su Linux con Terraform.

Cluster IBM Db2 ad alta disponibilità

Puoi configurare un cluster IBM Db2 a disponibilità elevata e a tolleranza di emergenza 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 per scopi di replica.

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

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

Il supporto di SAP per i cluster HA DB2 su Google Cloud è elencato nella Nota SAP 2456432.

Per informazioni sulle funzionalità 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 di Compute Engine nella stessa regione oppure, se necessario, puoi eseguirne il deployment in un'unica 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 statica per l'indirizzo IP mobile.

Ogni host di un cluster HA Db2 viene sottoposto a deployment in una zona diversa.

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

Entrambi gli host di un cluster HA Db2 vengono sottoposti a deployment nella stessa zona.

Documentazione obbligatoria

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

Potresti dover fare riferimento alla documentazione aggiuntiva di SAP o IBM durante l'installazione dei componenti SAP e IBM.

Requisiti specifici di un cluster IBM Db2 HA su Google Cloud

Su Google Cloud, SAP supporta i cluster IBM Db2 HA solo su sistemi operativi RHEL o SLES.

Per i requisiti software di Google Cloud per le istanze IBM Db2, consulta i 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 pagina IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms.

Indirizzi IP mobili per cluster IBM Db2 HA su Google Cloud

Un cluster IBM Db2 HA 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 può implementare un indirizzo IP mobile utilizzando un route statico di Google Cloud o un indirizzo alias alias di Google Cloud.

L'implementazione della route statica è consigliata per i cluster IBM Db2 multizona. I deployment multi-zona contribuiscono a garantire che l'errore di una singola zona non rimuova il tuo sistema IBM Db2.

Tuttavia, se l'architettura di rete non supporta le route statiche o devi evitare soluzioni come l'overlay IP o il routing complesso, puoi utilizzare l'implementazione degli indirizzi IP alias con un cluster Db2 IBM a zona singola. Gli indirizzi IP alias non sono consigliati per i deployment multi-zona perché la riassegnazione dell'alias potrebbe non essere garantita in caso di errore di zona.

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

L'utilizzo di una route statica richiede che tu selezioni un indirizzo IP per il tuo indirizzo IP mobile che sia:

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

Consulta l'amministratore di rete per determinare un indirizzo IP adatto per l'implementazione di una route statica.

L'utilizzo di un indirizzo IP alias richiede di prenotare un indirizzo IP dell'intervallo IP della subnet da utilizzare come indirizzo IP mobile.

Per ulteriori informazioni sugli indirizzi IP mobili su Google Cloud, consulta Best practice per gli indirizzi IP mobili.

SAP consiglia l'uso di indirizzi IP mobili nei cluster IBM Db2 HA. SAP supporta il reindirizzamento automatico del client (ACR), a condizione che vengano accettati tutti i requisiti e le limitazioni di questo metodo. Per ulteriori informazioni, vedi Nota SAP 1568539.

Tiebreaker della rete

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

Poiché i gateway di rete su Google Cloud non rispondono alle richieste ICMP, utilizza qualsiasi altro indirizzo IP che possa essere sottoposto a ping e che sia altamente disponibile. Ad esempio, puoi utilizzare l'indirizzo IP virtuale della tua istanza di Service Central dell'applicazione SAP o del DNS di Google, 8.8.8.8.

Se il tiebreak di rete non può rispondere alle richieste ICMP durante la configurazione, l'installazione non riesce.

Esistono altri tiebreak di rete, che vengono definiti da IBM. Per ulteriori informazioni, consulta la pagina Configurare il tie-break.

Strumenti di configurazione per un cluster HA Db2

Puoi utilizzare uno dei seguenti strumenti forniti da SAP e IBM per configurare un cluster HADR IBM Db2:

  • Strumento di configurazione del cluster SAP (sapdb2cluster.sh)
  • Utilità di configurazione dell'istanza ad alta disponibilità IBM DB2 (db2haicu)

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

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

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

Le risorse create dalla classe di risorsa IBM.ServiceIP TSAMP di IBM generano richieste ARP gratuite, che non sono supportate nelle reti VPC su Google Cloud, come spiegato nella Sfida con la migrazione di IP mobili a Compute Engine.

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

Utilità di configurazione dell'istanza ad alta disponibilità IBM DB2 (db2haicu)

In alternativa allo strumento di configurazione del cluster SAP, puoi usare l'utilità IBM db2haicu, che offre 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 la relazione 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, l'utilità consente una maggiore personalizzazione per le configurazioni di rete complesse o altri requisiti specifici per il 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.

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

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

Licenses (Licenze)

Questa sezione fornisce informazioni sui requisiti di licenza.

Licenze IBM Db2

Quando esegui IBM Db2 su Google Cloud, devi utilizzare la tua licenza BYOL (Bring Your Own License). Puoi ottenere le licenze Db2 da SAP o da IBM. Per ulteriori informazioni sulle licenze e sull'assistenza, consulta le seguenti note di SAP:

Per ulteriori informazioni sulle licenze SAP, contatta SAP.

Licenze del sistema operativo

In Compute Engine, esistono due modi per ottenere la licenza SLES, RHEL e Windows Server:

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

  • Con BYOL, i costi delle VM di 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 una minore flessibilità.

Assistenza

Per problemi con l'infrastruttura o i servizi Google Cloud, 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 un problema risiede nei tuoi sistemi SAP, contatta l'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 problema di infrastruttura di Google Cloud, trasferisce il ticket al componente Google Cloud BC-OP-LNX-GOOGLE o BC-OP-NT-GOOGLE.

Requisiti per l'assistenza

Prima di poter ricevere assistenza per i sistemi SAP e l'infrastruttura e i servizi Google Cloud 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 sul supporto SAP per Db2, consulta SAP Note 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, vedi:

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