Diese Seite wurde von der Cloud Translation API übersetzt.

Rechenzentrum hinzufügen

Edge for Private Cloud v4.18.05

In diesem Dokument wird beschrieben, wie Sie einem vorhandenen Rechenzentrum ein Rechenzentrum (auch als Region bezeichnet) hinzufügen.

Überlegungen vor dem Hinzufügen eines Rechenzentrums

Bevor Sie ein Rechenzentrum hinzufügen, müssen Sie wissen, wie Sie OpenLDAP-, ZooKeeper-, Cassandra- und Postgres-Server in den Rechenzentren konfigurieren. Außerdem müssen die erforderlichen Ports zwischen den Knoten in den beiden Rechenzentren geöffnet sein.

OpenLDAP
Jedes Rechenzentrum hat einen eigenen OpenLDAP-Server, der mit aktivierter Replikation konfiguriert ist. Wenn Sie das neue Rechenzentrum installieren, müssen Sie OpenLDAP für die Replikation konfigurieren und den OpenLDAP-Server im vorhandenen Rechenzentrum neu für die Replikation konfigurieren.
ZooKeeper
Geben Sie für die Property ZK_HOSTS für beide Rechenzentren die IP-Adressen oder DNS-Namen aller ZooKeeper-Knoten aus beiden Rechenzentren in derselben Reihenfolge an und kennzeichnen Sie alle Knoten mit dem Modifikator „:observer“. Knoten ohne den :observer-Modifikator werden als „Wähler“ bezeichnet. In Ihrer Konfiguration muss eine ungerade Anzahl von „Wählern“ vorhanden sein.

In dieser Topologie ist der ZooKeeper-Host auf Host 9 der Beobachter:

In der Beispielkonfigurationsdatei unten ist Knoten 9 mit dem Modifikator :observer getaggt, sodass es fünf Stimmen gibt: Knoten 1, 2, 3, 7 und 8.

Geben Sie für die Property ZK_CLIENT_HOSTS für jedes Rechenzentrum die IP-Adressen oder DNS-Namen nur der ZooKeeper-Knoten im Rechenzentrum in derselben Reihenfolge für alle ZooKeeper-Knoten im Rechenzentrum an.
Cassandra
Alle Rechenzentren müssen dieselbe Anzahl von Cassandra-Knoten haben.

Geben Sie für CASS_HOSTS für jedes Rechenzentrum alle Cassandra-IP-Adressen (keine DNS-Namen) für beide Rechenzentren an. Listen Sie für Rechenzentrum 1 zuerst die Cassandra-Knoten in diesem Rechenzentrum auf. Listen Sie für Rechenzentrum 2 zuerst die Cassandra-Knoten in diesem Rechenzentrum auf. Listen Sie die Cassandra-Knoten in derselben Reihenfolge für alle Cassandra-Knoten im Rechenzentrum auf.

Alle Cassandra-Knoten müssen das Suffix „:d,r“ haben, z. B. „ip:1,1“ für Rechenzentrum 1 und Rack/Verfügbarkeitszone 1 oder „ip:2,1“ für Rechenzentrum 2 und Rack/Verfügbarkeitszone 1.

Beispiel: „192.168.124.201:1,1 192.168.124.202:1,1 192.168.124.203:1,1 192.168.124.204:2,1 192.168.124.205:2,1 192.168.124.206:2,1“

Der erste Knoten im Rack/in der Verfügbarkeitszone 1 jedes Rechenzentrums wird als Startserver verwendet. Bei diesem Bereitstellungsmodell sieht die Cassandra-Einrichtung so aus:

Postgres

Standardmäßig installiert Edge alle Postgres-Knoten im Mastermodus. Wenn Sie jedoch mehrere Rechenzentren haben, konfigurieren Sie die Postgres-Knoten so, dass die Master-Standby-Replikation verwendet wird. Wenn der Masterknoten ausfällt, kann der Standbyknoten den Serververkehr fortsetzen. Normalerweise konfigurieren Sie den Master-Postgres-Server in einem Rechenzentrum und den Standby-Server im zweiten Rechenzentrum.

Wenn das vorhandene Rechenzentrum bereits so konfiguriert ist, dass zwei Postgres-Knoten im Master/Standby-Modus ausgeführt werden, müssen Sie im Rahmen dieses Verfahrens den vorhandenen Standby-Knoten abmelden und durch einen Standby-Knoten im neuen Rechenzentrum ersetzen.

In der folgenden Tabelle sind die Postgres-Konfigurationen vor und nach der Migration für beide Szenarien zu sehen:

Vorher	Nachher
Einzelner Master-Postgres-Knoten in dc-1	Master-Postgres-Knoten in dc-1 Standby-Postgres-Knoten in dc-2
Master-Postgres-Knoten in dc-1 Standby-Postgres-Knoten in dc-1	Master-Postgres-Knoten in dc-1 Standby-Postgres-Knoten in dc-2 Alten Standby-Postgres-Knoten in dc-1 abmelden

Vorher

Nachher

Einzelner Master-Postgres-Knoten in dc-1

Master-Postgres-Knoten in dc-1

Standby-Postgres-Knoten in dc-2

Master-Postgres-Knoten in dc-1

Standby-Postgres-Knoten in dc-1

Master-Postgres-Knoten in dc-1

Standby-Postgres-Knoten in dc-2

Alten Standby-Postgres-Knoten in dc-1 abmelden

Portanforderungen
Sie müssen dafür sorgen, dass die erforderlichen Ports zwischen den Knoten in den beiden Rechenzentren geöffnet sind. Ein Portdiagramm finden Sie unter Portanforderungen.

Vorhandenes Rechenzentrum aktualisieren

Wenn Sie ein Rechenzentrum hinzufügen, müssen Sie die Schritte zum Installieren und Konfigurieren der neuen Rechenzentrumsknoten ausführen. Außerdem müssen Sie die Knoten im ursprünglichen Rechenzentrum aktualisieren. Diese Änderungen sind erforderlich, da Sie im neuen Rechenzentrum neue Cassandra- und ZooKeeper-Knoten hinzufügen, die für das vorhandene Rechenzentrum zugänglich sein müssen. Außerdem müssen Sie OpenLDAP so neu konfigurieren, dass die Replikation verwendet wird.

Konfigurationsdateien erstellen

Unten sehen Sie die Silent-Konfigurationsdateien für die beiden Rechenzentren. Jedes Rechenzentrum hat 6 Knoten, wie in Installationstopologien dargestellt. Beachten Sie, dass in der Konfigurationsdatei für dc-1 zusätzliche Einstellungen für Folgendes hinzugefügt werden:

OpenLDAP mit Replikation über zwei OpenLDAP-Knoten konfigurieren
Fügen Sie die neuen Cassandra- und ZooKeeper-Knoten aus dc-2 der Konfigurationsdatei für dc-1 hinzu.

# Datacenter 1
IP1=IPorDNSnameOfNode1
IP2=IPorDNSnameOfNode2
IP3=IPorDNSnameOfNode3
IP7=IPorDNSnameOfNode7
IP8=IPorDNSnameOfNode8
IP9=IPorDNSnameOfNode9 
HOSTIP=$(hostname -i)
MSIP=$IP1
ADMIN_EMAIL=opdk@google.com
APIGEE_ADMINPW=Secret123
LICENSE_FILE=/tmp/license.txt
USE_LDAP_REMOTE_HOST=n
LDAP_TYPE=2
LDAP_SID=1
LDAP_PEER=$IP7
APIGEE_LDAPPW=secret
MP_POD=gateway-1
REGION=dc-1
ZK_HOSTS="$IP1 $IP2 $IP3 $IP7 $IP8 $IP9:observer"
ZK_CLIENT_HOSTS="$IP1 $IP2 $IP3"
# Must use IP addresses for CASS_HOSTS, not DNS names.
CASS_HOSTS="$IP1:1,1 $IP2:1,1 $IP3:1,1 $IP7:2,1 $IP8:2,1 $IP9:2,1"
SKIP_SMTP=n
SMTPHOST=smtp.example.com
SMTPUSER=smtp@example.com 
SMTPPASSWORD=smtppwd   
SMTPSSL=n
SMTPPORT=25
SMTPMAILFROM="My Company <myco@company.com>"

# Datacenter 2
IP1=IPorDNSnameOfNode1
IP2=IPorDNSnameOfNode2
IP3=IPorDNSnameOfNode3
IP7=IPorDNSnameOfNode7
IP8=IPorDNSnameOfNode8
IP9=IPorDNSnameOfNode9 
HOSTIP=$(hostname -i)
MSIP=$IP7
ADMIN_EMAIL=opdk@google.com
APIGEE_ADMINPW=Secret123
LICENSE_FILE=/tmp/license.txt
USE_LDAP_REMOTE_HOST=n
LDAP_TYPE=2
LDAP_SID=2
LDAP_PEER=$IP1
APIGEE_LDAPPW=secret
MP_POD=gateway-2
REGION=dc-2
ZK_HOSTS="$IP1 $IP2 $IP3 $IP7 $IP8 $IP9:observer"
ZK_CLIENT_HOSTS="$IP7 $IP8 $IP9"
# Must use IP addresses for CASS_HOSTS, not DNS names.
CASS_HOSTS="$IP7:2,1 $IP8:2,1 $IP9:2,1 $IP1:1,1 $IP2:1,1 $IP3:1,1"
SKIP_SMTP=n
SMTPHOST=smtp.example.com
SMTPUSER=smtp@example.com 
SMTPPASSWORD=smtppwd   
SMTPSSL=n
SMTPPORT=25
SMTPMAILFROM="My Company <myco@company.com>"

Neues Rechenzentrum hinzufügen

In diesem Verfahren haben die Rechenzentren folgende Namen:

dc-1: das vorhandene Rechenzentrum
dc-2: das neue Rechenzentrum

So fügen Sie ein neues Rechenzentrum hinzu:

Auf dc-1 führen Sie setup.sh noch einmal auf den ursprünglichen Cassandra-Knoten mit der neuen dc-1-Konfigurationsdatei aus, die die Cassandra-Knoten von dc-2 enthält:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ds -f configFile1
```
Auf dc-1 führen Sie setup.sh noch einmal auf dem Knoten des Verwaltungsservers aus:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ms -f configFile1
```
Installieren Sie auf dc-2 apigee-setup auf allen Knoten. Weitere Informationen finden Sie unter Installieren Sie das Hilfsprogramm für das Edge-Apigee-Setup.
Installieren Sie auf dc-2 Cassandra und ZooKeeper auf den entsprechenden Knoten:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ds -f configFile2
```
Führen Sie auf „dc-2“ den Befehl „rebuild“ auf allen Cassandra-Knoten aus und geben Sie dabei den Regionsnamen „dc-1“ an:
```
/opt/apigee/apigee-cassandra/bin/nodetool -h cassIP rebuild dc-1
```
Installieren Sie auf dc-2 den Verwaltungsserver auf dem entsprechenden Knoten:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ms -f configFile2
```
Installieren Sie auf dem Managementserverknoten in dc-2 apigee-provision, wodurch das Dienstprogramm apigee-adminapi.sh installiert wird:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision install
```
Installieren Sie auf dc-2 die Routes und Message Processors auf den entsprechenden Knoten:
```
/opt/apigee/apigee-setup/bin/setup.sh -p rmp -f configFile2
```
Installieren Sie auf dc-2 Qpid auf den entsprechenden Knoten:
```
/opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile2
```
Installieren Sie auf dc-2 Postgres auf dem entsprechenden Knoten:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile2
```
Richten Sie die Master-/Standby-Replikation für die Postgres-Knoten ein. Der Postgres-Knoten in dc-1 ist der Master und der Postgres-Knoten in dc-2 ist der Standby-Server.
Hinweis: Wenn dc-1 bereits so konfiguriert ist, dass zwei Postgres-Knoten im Master/Standby-Modus ausgeführt werden, verwenden Sie im Rahmen dieses Verfahrens den vorhandenen Master-Postgres-Knoten in dc-1 als Master und den Postgres-Knoten in dc-2 als Standby-Server. Später in diesem Verfahren heben Sie die Registrierung des vorhandenen Postgres-Standby-Servers in dc-1 auf.
1. Bearbeiten Sie auf dem Masterknoten in dc-1 die Konfigurationsdatei und legen Sie Folgendes fest:
```
PG_MASTER=IPorDNSofDC1Master
PG_STANDBY=IPorDNSofDC2Standby
```
2. Aktivieren Sie die Replikation auf dem neuen Master:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFIle
```
3. Bearbeiten Sie auf dem Standby-Knoten in dc-2 die Konfigurationsdatei und legen Sie Folgendes fest:
```
PG_MASTER=IPorDNSofDC1Master
PG_STANDBY=IPorDNSofDC2Standby
```
4. Beenden Sie auf dem Standby-Knoten in dc-2 den Server und löschen Sie alle vorhandenen Postgres-Daten:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
rm -rf /opt/apigee/data/apigee-postgresql/
```
  Hinweis: Sie können diese Daten bei Bedarf vor dem Löschen sichern.
5. Konfigurieren Sie den Standby-Knoten in dc-2:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
```
Aktualisieren Sie auf dc-1 die Analysekonfiguration und konfigurieren Sie die Organisationen.
1. Ermitteln Sie auf dem Management-Serverknoten von dc-1 die UUID des Postgres-Knotens:
```
apigee-adminapi.sh servers list -r dc-1 -p analytics -t postgres-server \
  --admin adminEmail --pwd adminPword --host localhost
```
  Die UUID wird am Ende der zurückgegebenen Daten angezeigt. Speichern Sie diesen Wert.
  
  Hinweis: Wenn dc-1 so konfiguriert ist, dass zwei Postgres-Knoten im Master/Standby-Modus ausgeführt werden, werden in der Ausgabe zwei IP-Adressen und UUIDs angezeigt. Speichern Sie beide UUIDs. Anhand der IP-Adressen sollten Sie ableiten können, welche UUID für den Master und welche für den Standby-Knoten ist.
2. Rufen Sie auf dem Management-Serverknoten von dc-2 die UUID des Postgres-Knotens ab, wie im vorherigen Schritt gezeigt. Speichern Sie diesen Wert.
3. Ermitteln Sie auf dem Management-Serverknoten von dc-1 den Namen der Analyse- und Verbrauchergruppen. Für viele der folgenden Befehle sind diese Informationen erforderlich.
  Standardmäßig lautet der Name der Analysegruppe „axgroup-001“ und der Name der Verbrauchergruppe „consumer-group-001“. In der Silent-Konfigurationsdatei für eine Region können Sie den Namen der Analysegruppe mithilfe der Property AXGROUP festlegen.
  
  Wenn Sie sich nicht sicher sind, wie die Namen der Analyse- und Verbrauchergruppen lauten, können Sie sie mit dem folgenden Befehl aufrufen:
```
apigee-adminapi.sh analytics groups list \
  --admin adminEmail --pwd adminPword --host localhost
```
  Dieser Befehl gibt den Namen der Analysegruppe im Feld „name“ und den Namen der Nutzergruppe im Feld „consumer-groups“ zurück.
4. Entfernen Sie auf dem Verwaltungsserverknoten von dc-1 den vorhandenen Postgres-Server aus der Analysegruppe:
  1. Entfernen Sie den Postgres-Knoten aus der Verbrauchergruppe:
```
apigee-adminapi.sh analytics groups consumer_groups datastores remove \
  -g axgroup-001 -c consumer-group-001 -u UUID \
  -Y --admin adminEmail --pwd adminPword --host localhost
```
    Wenn dc-1 so konfiguriert ist, dass zwei Postgres-Knoten im Master/Standby-Modus ausgeführt werden, entfernen Sie beide:
```
apigee-adminapi.sh analytics groups consumer_groups datastores remove \
  -g axgroup-001 -c consumer-group-001 -u "UUID_1,UUID_2" \
  -Y --admin adminEmail --pwd adminPword --host localhost
```
  2. Entfernen Sie den Postgres-Knoten aus der Analysegruppe:
```
apigee-adminapi.sh analytics groups postgres_server remove \
  -g axgroup-001 -u UUID -Y --admin adminEmail \
  --pwd adminPword --host localhost
```
    Wenn dc-1 so konfiguriert ist, dass zwei Postgres-Knoten im Master/Standby-Modus ausgeführt werden, entfernen Sie beide:
```
apigee-adminapi.sh analytics groups postgres_server \
  remove -g axgroup-001 -u UUID1,UUID2 -Y --admin adminEmail \
  --pwd adminPword --host localhost
```
5. Fügen Sie auf dem Management-Serverknoten von dc-1 die neuen Master-/Standby-Postgres-Server der Analysegruppe hinzu:
  1. Fügen Sie der Analysegruppe beide Postgres-Server hinzu:
```
apigee-adminapi.sh analytics groups postgres_server \
  add -g axgroup-001 -u "UUID_1,UUID_2" --admin adminEmail \
  --pwd adminPword --host localhost
```
    Hier entspricht UUID_1 dem Master-Postgres-Knoten in dc-1 und UUID_2 dem Standby-Postgres-Knoten in dc-2.
  2. Fügen Sie die PG-Server der Verbrauchergruppe als Master/Standby hinzu:
```
apigee-adminapi.sh analytics groups consumer_groups datastores \
  add -g axgroup-001 -c consumer-group-001 -u "UUID_1,UUID_2" --admin adminEmail \
  --pwd adminPword --host localhost
```
6. Fügen Sie der Analysegruppe die Qpid-Server von dc-2 hinzu:
  1. Ermitteln Sie auf dem Management-Serverknoten von dc-1 die UUIDs der Qpid-Knoten in dc-2:
```
apigee-adminapi.sh servers list -r dc-2 -p central -t qpid-server \
  --admin adminEmail --pwd adminPword --host localhost
```
    Die UUIDs werden am Ende der zurückgegebenen Daten angezeigt. Speichern Sie diese Werte.
  2. Fügen Sie auf dem Management-Serverknoten von dc-1 die Qpid-Knoten der Analysegruppe hinzu (führen Sie beide Befehle aus):
```
apigee-adminapi.sh analytics groups qpid_server \
  add -g axgroup-001 -u "UUID_1" --admin adminEmail \
  --pwd adminPword --host localhost

apigee-adminapi.sh analytics groups qpid_server \
  add -g axgroup-001 -u "UUID_2" --admin adminEmail \
  --pwd adminPword --host localhost
```
  3. Fügen Sie auf dem Management-Serverknoten von dc-1 die Qpid-Knoten der Verbrauchergruppe hinzu (führen Sie beide Befehle aus):
```
apigee-adminapi.sh analytics groups consumer_groups consumers \
  add -g axgroup-001 -c consumer-group-001 -u "UUID_1" \
  --admin adminEmail --pwd adminPword --host localhost

apigee-adminapi.sh analytics groups consumer_groups consumers \
  add -g axgroup-001 -c consumer-group-001 -u "UUID_2" \
  --admin adminEmail --pwd adminPword --host localhost
```
7. Registrieren Sie den alten Postgres-Standbyserver von dc-1 ab und löschen Sie ihn:
  1. Registrieren Sie den vorhandenen Postgres-Standby-Server dc-1 ab:
```
apigee-adminapi.sh servers deregister -u UUID -r dc-1 \
  -p analytics -t postgres-server -Y --admin adminEmail \
  --pwd adminPword --host localhost
```
    Dabei ist UUID der alte Standby-Postgres-Knoten in dc-1.
  2. Löschen Sie den vorhandenen Postgres-Standbyserver „dc-1“:
    Hinweis: Mit diesem Befehl wird der Postgres-Serverknoten nicht deinstalliert. Er wird nur aus der Liste der Edge-Knoten entfernt. Sie können Postgres bei Bedarf später vom Knoten deinstallieren.
```
apigee-adminapi.sh servers delete -u UUID \
  --admin adminEmail --pwd adminPword --host localhost
```
Aktualisieren Sie die Cassandra-Schlüsselbereiche mit dem richtigen Replikationsfaktor für die beiden Rechenzentren. Sie müssen diesen Schritt nur einmal auf einem beliebigen Cassandra-Server in einem der beiden Rechenzentren ausführen:
Hinweis: Mit den folgenden Befehlen wird der Replikationsfaktor auf „3“ festgelegt, was drei Cassandra-Knoten im Cluster bedeutet. Ändern Sie diesen Wert nach Bedarf für Ihre Installation.
1. Starten Sie das Cassandra-cqlsh-Dienstprogramm:
```
/opt/apigee/apigee-cassandra/bin/cqlsh cassandraIP
```
2. Führen Sie die folgenden CQL-Befehle an der Eingabeaufforderung „cqlsh>“ aus, um die Replikationsebenen für Cassandra-Schlüsselbereiche festzulegen:
  1. ```
  ALTER KEYSPACE "identityzone" WITH replication = { 'class': 'NetworkTopologyStrategy', 'dc-1': '3','dc-2': '3' }; 
```
2. ```
ALTER KEYSPACE "system_traces" WITH replication = { 'class': 'NetworkTopologyStrategy', 'dc-1': '3','dc-2': '3' };
```
  3. Rufen Sie die Schlüsselbereiche mit dem Befehl auf:
```
select * from system.schema_keyspaces;
```
  4. cqlsh beenden:
```
exit
```
Führen Sie den folgenden nodetool-Befehl auf allen Cassandra-Knoten in dc-1 aus, um Arbeitsspeicher freizugeben:
```
/opt/apigee/apigee-cassandra/bin/nodetool -h cassandraIP cleanup
```
Für jede Organisation und jede Umgebung, die Sie standortübergreifend unterstützen möchten:
1. Fügen Sie auf dem Management-Serverknoten von dc-1 der Organisation den neuen MP_POD hinzu:
```
apigee-adminapi.sh orgs pods add -o orgName -r dc-2 -p gateway-2 \
  --admin adminEmail --pwd adminPword --host localhost
```
  Dabei ist gateway-2 der Name des Gateway-Pods, wie er durch das Attribut „MP_POD“ in der Konfigurationsdatei „dc-2“ definiert ist.
2. Fügen Sie der Organisation und Umgebung die neuen Nachrichtenverarbeiter hinzu:
  1. Ermitteln Sie auf dem Management-Serverknoten von dc-2 die UUIDs der Nachrichtenprozessorknoten in dc-2:
```
apigee-adminapi.sh servers list -r dc-2 -p gateway-2 \
  -t message-processor --admin adminEmail --pwd adminPword --host localhost
```
    Die UUIDs werden am Ende der zurückgegebenen Daten angezeigt. Speichern Sie diese Werte.
  2. Fügen Sie auf dem Management-Serverknoten von dc-1 jedem Nachrichtenprozessor in dc-2 eine Umgebung für die Organisation hinzu:
```
apigee-adminapi.sh orgs envs servers add -o orgName -e envName \
  -u UUID --admin adminEmail --pwd adminPword --host localhost
```
3. Prüfen Sie auf dem Management-Serverknoten von dc-1 die Organisation:
```
apigee-adminapi.sh orgs apis deployments -o orgName -a apiProxyName \
  --admin adminEmail --pwd adminPword --host localhost
```
  Dabei ist apiProxyName der Name eines in der Organisation bereitgestellten API-Proxys.