Erstellen von Diensten zum Freigeben der HADR-Endpunkte in Db2
Um Verbindungsinformationen für die ferne Quell- oder ferne Zieldatenbank in Db2 High Availability Disaster Recovery (HADR) anzugeben, müssen Sie Serviceendpunkte erstellen und angeben, sodass die Db2-HADR-Ports verfügbar werden.
Im Gegensatz zum herkömmlichen (lokalen) Db2 HADR können Sie die Pod-IP-Adresse nicht zur Definition des HADR-Remote-Servers verwenden, da sich die IP-Adresse des Pods oder Containers bei Red Hat® OpenShift® jeder Neuplanung des Pods ändert. Stattdessen müssen Sie die HADR-Verbindungsinformationen als Dienst OpenShift offenlegen, auf den dann die Remote-HADR-Kopie verweisen kann, um die Datenbankkonfigurationsparameter hadr_remote_host und hadr_remote_svcfestzulegen. Das OpenShift Cluster-DNS löst den Dienst dann auf den richtigen aktiven Pod auf, unabhängig davon, auf welchem Worker-Knoten er geplant ist.
Ab wurden IBM Software Hub4.5 Netzwerkrichtlinien eingeführt, um den Datenverkehr zu und von den Db2 Bereitstellungen zu steuern. Für HADR sind zusätzliche Netzwerkrichtlinien erforderlich, damit die Datenbanken miteinander kommunizieren können.
Sie können das bereitgestellte Skript verwenden, um die erforderlichen Service- und Netzwerkrichtliniendefinitionen für HADR zu generieren.
Je nach HADR-Topologie generiert das erstellte HADR-Services-Skript die entsprechenden Service-Definitionen:
- Einzelner Cluster (einzelnes Projekt oder mehrere Projekte)
- Ein ClusterIP Diensttyp für jede Datenbank in ihrem eigenen Red Hat OpenShift Projekt
- Unterschiedliche Cluster
- Ein Dienst vom NodeIP Typ für jede Datenbank in ihrem eigenen Red Hat OpenShift Projekt
- ExternalName Dienste, die jeder Datenbank in jedem Red Hat OpenShift Projekt sowie jedem Cluster entsprechen
Syntax
Parameter
- --db-role
- Die HADR-Rolle für die aktuelle Datenbank, entweder 'primary', 'standby', 'aux1' oder 'aux2'.
- --primary-name
- Der Name des primären Db2 Clusters.
- --standby-name
- Der Name des Db2 Standby-Clusters.
- --aux1-name
- Der Name des Clusters auxiliary1Db2.
- --aux2-name
- Der Name des Clusters auxiliary2Db2.
- --primary-ext-host
- Die externe IP-Adresse oder der externe Hostname des primären Datenbankclusters. Erforderlich, wenn die Topologie mehrere Cluster umfasst, z. B. virtuelle IP-, ELB- oder Infra-Knoten mit externem Ingress-Controller.
- --standby-ext-host
- Die externe IP-Adresse oder der externe Hostname des Bereitschaftsdatenbankclusters. Erforderlich, wenn die Topologie mehrere Cluster enthält.
- --aux1-ext-host
- Die externe IP-Adresse oder der externe Hostname des Datenbank-Clusters 'auxiliary1'. Erforderlich, wenn die Topologie mehrere Cluster enthält.
- --aux2-ext-host
- Die externe IP-Adresse oder der externe Hostname des Datenbank-Clusters 'auxiliary2'. Erforderlich, wenn die Topologie mehrere Cluster enthält.
- --cpd
- Erforderlich, wenn die Bereitstellung auf CP4D ( Software Hub ) erfolgt. Bei eigenständiger Verwendung den Parameter überspringen.
Vorbereitungen
Notieren Sie sich die Namen der Db2uCluster oder Db2uInstance benutzerdefinierten Ressourcen, die den Primär- und Standby-Datenbanken entsprechen. Geben Sie für jede Datenbank eine HADR-Rolle an:
- Primär => primary
- Hauptbereitschaftsdatenbank = > standby
- Nebenbereitschaftsdatenbank 1 = > aux1
- Nebenbereitschaftsdatenbank 2 = > aux2
Wie bereits erwähnt, wird der automatische Failover nur zwischen der primären und der Hauptbereitschaftsdatenbank unterstützt. Deshalb werden diese Rollen in der HADR-Konfiguration festgelegt und können nicht inaktiviert werden, ohne dass HADR rekonfiguriert wird.
oc get db2ucluster,db2uinstance
NAME STATE AGE
db2oltp-primary Ready 6h26m
db2oltp-standby Ready 6h26m
db2oltp-aux Ready 6h26m