Liberty-Verbundreplikatgruppen konfigurieren

Sie können Verbundreplikatgruppen konfigurieren. Eine Replikatgruppe stellt hochverfügbare Verwaltungsfunktionen für eine Liberty-Verwaltungsdomäne bereit.

Für verteilte PlattformenFür IBM i-Plattformen

Vorbereitende Schritte

Das Feature collectiveController-1.0 und seine Funktionen sind nur in WebSphere Application Server Liberty Network Deployment und in WebSphere Application Server Liberty for z/OS verfügbar. Das Feature ist in WebSphere Application Server Liberty und WebSphere Application Server Liberty Core nicht verfügbar. Wenn WebSphere Application Server Liberty Network Deployment installiert ist, können Sie das Feature collectiveController-1.0 dieser Installation verwenden, um mit Verbundmembern aus WebSphere Application Server Liberty- oder WebSphere Application Server Liberty Core-Installationen zusammenzuarbeiten.Ein Verbundmember kann aus jedem beliebigen WebSphere Application Server Liberty-Release kommen.

Informationen zu diesem Vorgang

Eine Replikatgruppe ist eine Gruppe von Verbundcontrollern, die für die Zusammenarbeit konfiguriert sind. Jedes Replikat enthält alle Repository-Aktualisierungen, die die anderen Replikate innerhalb der Gruppe verarbeitet haben. Deswegen ist es für ein Member oder einen Client nicht erforderlich, bei jeder Interaktion mit dem Verbund eine Verbindung zu einem bestimmten Verbundcontroller herzustellen. Jeder Verbundcontroller, der in der Replikatgruppe konfiguriert ist, kann dieselben Daten bereitstellen.

Ausführliche Informationen zur Erstellung und Konfiguration eines Verbundcontrollers finden Sie unter Liberty-Verbund konfigurieren.

Sie die folgenden Prozeduren ausführen, um eine Verbundreplikatgruppe zu konfigurieren:

  1. Replikat zu einer vorhandenen Replikatgruppe hinzufügen.
  2. Standardkonfiguration der ersten Replikatgruppe ändern.

Im Abschnitt Beispiel: Replikatgruppe erstellen und aktivieren wird anhand eines Beispiels erläutert, wie eine aus drei auf demselben Host befindlichen Verbundcontrollern bestehende Replikatgruppe erstellt wird.

Eine Replikatgruppe erfordert eine ungerade Zahl an Replikaten.

Vorgehensweise

  1. Fügen Sie ein Replikat einer vorhandenen Replikatgruppe hinzu.

    Während des Lebenszyklus einer Replikatgruppe kann es notwendig werden, ein oder mehr Replikate einer vorhandenen Gruppe hinzuzufügen, um beispielsweise die Kapazität zu erhöhen.

    Für die vorhandenen Replikate in der Replikatgruppe sind keine Aktualisierungen der Konfiguration erforderlich. Sie können die Replikate aktualisieren, damit ihre Konfigurationen in den entsprechenden Dateien des Typs server.xml die Replikate, aus denen die Replikatgruppe sich zusammensetzt, genauer widerspiegeln. Diese Aktualisierung ist jedoch nicht notwendig und hat keine Auswirkungen auf das Verhalten der Replikate.

    Anmerkung: Es ist nicht notwendig, den Wert für replicaSet in der Datei server.xml eines vorhandenen Replikats in der Gruppe zu ändern. Für vorhandene Replikate ist keine Konfigurationsänderung erforderlich. Wenn Sie die replicaSet-Werte in den Konfigurationen vorhandener Replikate in der Gruppe so ändern möchten, dass die Konfigurationswerte aller Replikate in der Gruppe konsistent sind, müssen Sie den Wert für isInitialReplicaSet in den Konfigurationen der vorhandenen Replikate auf false setzen. Nach der Änderung des replicaSet-Werts wird nicht mehr die ursprüngliche, sondern eine geänderte Replikatgruppe beschrieben.
    Anmerkung: Wenn Sie auf ein Replikat verweisen, müssen Sie dabei konsistent vorgehen und denselben Wert für host:port verwenden. Wird ein Hostname verwendet, muss er immer verwendet werden. Wird eine IP-Adresse verwendet, muss diese immer verwendet werden.

    Gehen Sie wie folgt vor, um ein Replikat hinzuzufügen:

    1. Stellen Sie sicher, dass die vorhandene Replikatgruppe aktiv ist und dass die Replikate mehrheitlich verfügbar sind.
    2. Erstellen Sie einen Server, der als neuer Verbundcontroller verwendet werden soll.
      wlp/bin/server create MyNewController
    3. Führen Sie die Replikation durch, um den neuen Server in einen Verbundcontroller umzuwandeln.
      wlp/bin/collective replicate MyNewController 
         --host=Host_des_aktiven_Controllers
         --port=HTTPS-Port_des_aktiven_Controllers
         --user=Benutzername_des_aktiven_Controllers
         --password=Benutzerkennwort_des_aktiven_Controllers
         --keystorePassword=Keystore-Kennwort_des_neuen_Controllers

      Der Befehl replicate schreibt XML-Ausgabe in eine Anzeige auf der Konsole. Sie kopieren die Ausgabe in die Datei server.xml.

      Wenn Sie die Ausgabe des Befehls in eine Datei schreiben möchten, anstatt sie in einer Konsolenanzeige auszugeben, geben Sie den Parameter --createConfigFile=Pfad_der_Ausgabedatei an. Schließen Sie anschließend die ausgegebene Datei in die Verbundkonfiguration ein, indem Sie der Datei server.xml eine include-Anweisung hinzufügen:
      <include location=Pfad_der_Ausgabedatei />
    4. Konfigurieren Sie die Datei server.xml des neuen Replikats mit der Ausgabe des Befehls replicate.
      Kopieren Sie die XML-Ausgabe des Befehls replicate in die Datei server.xml. Sie können die Replikatkonfiguration wie folgt ändern:
      • Erforderliche Einstellungen:
        Die Werte müssen explizit festgelegt werden. Die vom Befehl replicate ausgegebene XML enthält diese Konfiguration und ist für diese Einstellungen ausreichend.
        hostAuthInfo
        Die Authentifizierungsdaten für den Host, die Eigenschaften enthalten, die ein ferner Client zum Starten des Servers benötigt. Diese Einstellung ist nur erforderlich, wenn der Host des neuen Replikats nicht für SSH konfiguriert ist. Linux-Hosts sind gewöhnlich für SSH konfiguriert, Windows-Hosts aber nicht. Diese Einstellung ist daher möglicherweise nur auf Windows-Hosts erforderlich. Sie haben zwei Möglichkeiten, RPC-Berechtigungsnachweise für das Replikat festzulegen:
        • Legen Sie für rpcUser eine Benutzer-ID für Betriebssystemanmeldung für den Host fest, auf dem das Replikat sich befindet, und legen Sie für rpcUserPassword das Kennwort für Betriebssystemanmeldung für die Benutzer-ID fest. Wenn Sie sich beispielsweise am Replikatcomputer mit dem Benutzernamen test1 und dem Kennwort test1pwd anmelden, ändern Sie das Element hostAuthInfo wie folgt:
          <hostAuthInfo rpcUser="test1" rpcUserPassword="test1pwd" />
        • Wenn der Replikathost beim Verbundcontroller registriert ist, setzen Sie die Einstellung für hostAuthInfo useHostCredentials auf true, damit das Replikat RPC-Berechtigungsnachweise vom zugehörigen Host übernimmt.
          <hostAuthInfo useHostCredentials="true" />

        Weitere Informationen zu den Einstellungen für hostAuthInfo finden Sie unter Liberty-Server-Host-Informationen überschreiben.

        replicaSet
        Eine Liste mit host:port-Angaben für alle replicaHosts und replicaPorts in der Replikatgruppe. Ausgenommen sind die Werte für den Verbundcontroller, der jetzt zur Gruppe hinzugefügt wird.
        Beispiel:
        original.host.com:10001 some.other.host.com:10003
        Mindestens einer der Werte in dieser Gruppe muss bereits ein Replikat der vorhandenen Replikatgruppe sein.
      • Optionale Einstellungen:
        Diese Einstellungen werden standardmäßig verwendet, können jedoch geändert werden.
        isInitialReplicaSet
        False
        replicaHost
        Hostname für jedes einzelne Replikat.
        replicaPort
        Port für jedes einzelne Replikat.

        Dieser Port ist nicht der HTTP- oder HTTPS-Port des Verbundcontrollers, sondern ein eindeutiger Port, der für die Kommunikation zwischen den Replikaten der Replikatgruppe verwendet wird.

        repositoryDir
        Die Verzeichnisposition, die zum Speichern der Repository-Daten verwendet wird.
      Es folgt ein Beispiel für die Angaben, die Sie zur Datei server.xml eines neuen Replikats hinzufügen können:
      <collectiveController replicaHost="localhost" 
         replicaPort="10012" 
         replicaSet="localhost:10010 localhost:10011" 
         isInitialReplicaSet="false"/> 
      Die vom Befehl replicate ausgegebene XML erfordert, dass die Sicherheitskonfiguration des Servers aktualisiert und das Keystore-Kennwort collectiveRootKeys angegeben wird. Die Sicherheitskonfiguration des Servers muss mit der Konfiguration des ursprünglichen Verbundcontrollers und das Kennwort des Keystores collectiveRootKeys mit dem für den Keystore collectiveRootKeys des ursprünglichen Verbundcontrollers verwendeten Kennwort übereinstimmen. Wird das Replikat aus dem in Liberty-Verbund konfigurieren erstellten Controller erstellt, muss die Konfiguration des neuen Controllers Folgendes enthalten:
      <quickStartSecurity userName="adminUser" userPassword="adminPassword" />
        <!-- Stammunterzeichnerkeystore des Verbunds -->
        <keyStore id="collectiveRootKeys" password="yourPassword"
          location="${server.config.dir}/resources/collective/rootKeys.jks"/>
    5. Starten Sie das neue Replikat, indem Sie den neuen Verbundcontroller starten.
    6. Bestätigen Sie, dass der ursprüngliche Verbundcontroller eine Verbindung zu dem neuen Replikat hergestellt hat. Suchen Sie in der Datei messages.log des ursprünglichen Verbundcontrollers und des Replikats nach der Nachricht CWWKX6009I.
      Tipp: Fügen Sie für Scripts, die die Befehle replicate und addReplica ausführen, nach der Ausführung des Befehls replicate eine Wartezeit von 10 Sekunden hinzu, um sicherzustellen, dass der ursprüngliche Verbundcontroller und das Replikat miteinander verbunden sind, bevor Sie den Befehl addReplica ausführen.
    7. Rufen Sie die Operation addReplica für das Verbunddienstprogramm (collective) auf, um das neue Replikat zu aktivieren. Das Argument für addReplica muss der Replikatendpunkt (in der Form "Replicathost:Replikatport") des Replikats sein, das hinzugefügt wird.
      wlp/bin/collective addReplica localhost:10012 
        --host=Host_des_aktiven_Controllers
        --port=Port_des_aktiven_Controllers
        --user=Benutzer_für_aktiven_Controller
        --password=Benutzerkennwort
  2. Optional: Im Bedarfsfall können Sie die Standardkonfiguration der ursprünglichen Replikatgruppe ändern. Dieser Schritt wird empfohlen, ist aber nicht erforderlich.

    Die Konfiguration der ursprünglichen Replikatgruppe wird durchgeführt, wenn der ursprüngliche Verbundcontroller erstellt wird. Wenn es notwendig ist, die Standardkonfiguration für Replikate zu ändern, können die folgenden Eigenschaften in der Datei server.xml geändert werden:

    Optionale Einstellungen: Diese Werte werden standardmäßig verwendet, können jedoch geändert werden.
    replicaHost
    Hostname für jedes einzelne Replikat.
    replicaPort
    Port für jedes einzelne Replikat.

    Dieser Port ist nicht der HTTP- oder HTTPS-Port des Verbundcontrollers, sondern ein eindeutiger Port, der für die Kommunikation zwischen den Replikaten der Replikatgruppe verwendet wird.

    repositoryDir
    Die Verzeichnisposition, die zum Speichern der Repository-Daten verwendet wird.

Beispiel: Replikatgruppe erstellen und aktivieren

Dieses Beispiel beschreibt, wie eine Replikatgruppe erstellt und dann aktiviert wird. Eine Replikatgruppe muss mindestens drei Replikate haben, um Hochverfügbarkeit bereitstellen zu können. In diesem Beispiel befinden die Repliken sich auf demselben Host, was voraussetzt, dass Sie den Replikaten eindeutige Portnummern zuweisen. Wenn Replikate sich auf verschiedenen Hosts befinden, können die Replikate dieselben Portnummern verwenden.

  1. Erstellen Sie eine Replikatgruppe.

    Um eine Replikatgruppe zu erstellen, müssen Sie die Anzahl der Verbundcontroller erhöhen und die Controller so konfigurieren, dass sie miteinander kommunizieren können. Jeder neue Verbundcontroller wird als Replikat bezeichnet, weil die hinzugefügten Verbundcontroller dieselbe Sicherheitskonfiguration haben wie der ursprüngliche Controller haben und weil alle Informationen, die in einen Controller geschrieben werden, automatisch auf allen anderen aktiven Controllern repliziert werden. Sind die Verbundcontroller in der Replikatgruppe einmal konfiguriert, können sie alle dieselben Operationen ausführen wie der ursprüngliche Controller.

    1. Wenn Sie keinen Verbundcontroller haben, erstellen Sie einen. Weitere Informationen finden Sie in Schritt 1 im Abschnitt Liberty-Verbund konfigurieren.
    2. Stellen Sie sicher, dass der Verbundcontroller aktiv ist. Führen Sie für einen vorhandenen Controller myController den Befehl status aus:
      wlp/bin/server status myController
      Wenn der Verbundcontroller nicht aktiv ist, starten Sie ihn mit dem Befehl start oder run:
      wlp/bin/server start myController
    3. Erstellen Sie einen Server, der als neuer Verbundcontroller verwendet werden soll.
      wlp/bin/server create myController2
    4. Replizieren Sie die Konfiguration des vorhandenen Verbundcontrollers im neuen Verbundcontroller. Der neue Verbundcontroller wird als Replikat bezeichnet.

      Führen Sie einen replicate-Befehl aus, der die Konfiguration der Verwaltungssicherheitsdomäne des vorhandenen Verbundcontrollers verwendet und ein neues Keystore-Kennwort für das Replikat festlegt. Suchen Sie in der Datei server.xml des vorhandenen Verbundcontrollers nach den Werten für die Parameter --host, --port, --user und --password. Definieren Sie für --keystorePassword einen Wert für den Keystore, z. B.myController2. Informationen zu diesen erforderlichen Parametern und zu optionalen Parametern erhalten Sie, wenn Sie in einer Befehlszeile den Befehl collective help replicate ausführen.

      wlp/bin/collective replicate myController2 --host=Host_des_vorhandenen_Controllers --port=HTTPS-Port_des_vorhandenen_Controllers --user=Benutzername_des_vorhandenen_Controllers --password=Benutzerkennwort_des_vorhandenen_Controllers --keystorePassword=Keystore-Kennwort_des_neuen_Controllers  

      Wenn Sie aufgefordert werden, die Zertifikatskette zu akzeptieren, geben Sie y (yes) ein.

      Der Befehl replicate schreibt XML-Ausgabe in eine Anzeige auf der Konsole. Sie kopieren die Ausgabe in die Datei server.xml.

      Wenn Sie die Ausgabe des Befehls in eine Datei schreiben möchten, anstatt sie in einer Konsolenanzeige auszugeben, geben Sie den Parameter --createConfigFile=Pfad_der_Ausgabedatei an. Schließen Sie anschließend die ausgegebene Datei in die Verbundkonfiguration ein, indem Sie der Datei server.xml eine include-Anweisung hinzufügen:
      <include location=Pfad_der_Ausgabedatei />
    5. Fügen Sie die XML-Ausgabe des Befehls replicate der Datei server.xml des Replikats hinzu und bearbeiten Sie die Parameterwerte nach Bedarf.
      • Vergewissern Sie sich, dass das Element httpEndpoint die Werte des Replikats für httpPort und httpsPort, die eindeutige Portnummern auf dem Host sind, festlegt. Nehmen Sie zum Beispiel an, dass sich der ursprüngliche Controller myController und das Replikat beide auf demselben lokalen Host befinden und myController das folgende httpEndpoint-Element hat:
        <httpEndpoint id="defaultHttpEndpoint"
                      host="*"
                      httpPort="9080"
                      httpsPort="9443" />
        Ändern Sie die Werte für myController2 in folgende Werte:
        <httpEndpoint id="defaultHttpEndpoint"
                      host="*"
                      httpPort="9085"
                      httpsPort="9448" />
      • Legen Sie RPC-Berechtigungsnachweise für hostAuthInfo fest. Es gibt zwei Möglichkeiten, RPC-Berechtigungsnachweise für das Replikat festzulegen:
        • Legen Sie für hostAuthInfo RPC-Benutzer- und Kennwortwerte fest. Legen Sie für rpcUser eine Benutzer-ID für Betriebssystemanmeldung für den Host fest, auf dem das Replikat sich befindet, und legen Sie für rpcUserPassword das Kennwort für Betriebssystemanmeldung für die Benutzer-ID fest. Wenn Sie sich beispielsweise am Replikatcomputer mit dem Benutzernamen test1 und dem Kennwort test1pwd anmelden, ändern Sie das Element hostAuthInfo wie folgt:
          <hostAuthInfo rpcUser="test1" rpcUserPassword="test1pwd" />
        • Wenn der Replikathost beim Verbundcontroller registriert ist, setzen Sie die Einstellung für hostAuthInfo useHostCredentials auf true, damit das Replikat RPC-Berechtigungsnachweise vom zugehörigen Host übernimmt.
          <hostAuthInfo useHostCredentials="true" />

        Weitere Informationen zu den Einstellungen für hostAuthInfo finden Sie unter Liberty-Server-Host-Informationen überschreiben.

      • Vergewissern Sie sich, dass replicaPort eine Portnummer für das Replikat festlegt, das in der Replikatgruppe eindeutig ist, und dassreplicaSet für Host:Port Werte festlegt, die die Replikatgruppe identifizieren. Wenn beispielsweise der ursprüngliche Controller myController und das Replikat sich beide auf demselben lokalen Host befinden, ändern Sie die Werte für myController2 von null:
        <collectiveController replicaPort="null"
                              replicaSet="localhost:null"
                              isInitialReplicaSet="false" />
        für den Replikatport in 10011 und für die Replikatgruppe in 10010:
        <collectiveController replicaPort="10011"
                              replicaSet="localhost:10010"
                              isInitialReplicaSet="false" />
      • Stellen Sie sicher, dass in der Sicherheitskonfiguration dieselben Werte festlegt werden, die auch vom ursprünglichen Controller verwendet werden. Beispielsweise verwenden sowohl myController als auch das Replikat myController2 die folgende Einstellung:
        <quickStartSecurity userName="adminUser" userPassword="adminPassword" />
      • Stellen Sie sicher, dass im Element für den Stammunterzeichnerkeystore des Verbunds dasselbe Kennwort festlegt wird, das auch vom ursprünglichen Controller verwendet wird. Kopieren Sie beispielsweise das Kennwort für den Keystore collectiveRootKeys aus der Datei server.xml von myController in die Datei server.xml des Replikats myController2. Das folgende Beispiel zeigt ein generiertes Kennwort:
        <!-- Stammunterzeichnerkeystore des Verbunds -->
        <keyStore id="collectiveRootKeys" password="{xor}Lz4sLCgwLTs="
                  location="${server.config.dir}/resources/collective/rootKeys.jks"/>
    6. Starten Sie das neue Replikat, indem Sie den neuen Verbundcontroller starten.
      wlp/bin/server start myController2
    7. Vergewissern Sie sich, dass der ursprüngliche Verbundcontroller mit dem neuen Replikat kommunizieren kann.
      1. Öffnen Sie das Nachrichtenprotokoll des ursprünglichen Controllers, $WLP_USER_DIR/servers/myController/logs/messages.log in einem Editor.
      2. Suchen Sie nach der folgenden Nachricht, die in Ihrer Umgebung möglicherweise andere IP-Adressen enthält:
        CWWKX6009I:
        Der Verbundcontroller wurde erfolgreich mit dem Replikat 127.0.0.1:10011 verbunden. Die derzeit aktive Replikatgruppe ist [127.0.0.1:10010]. Die konfigurierte Replikatgruppe ist [127.0.0.1:10010]. Die verbundenen Ausweichreplikate sind [127.0.0.1:10011].
    8. Vergewissern Sie sich, dass das neue Replikat mit dem ursprünglichen Verbundcontroller kommunizieren kann.
      1. Öffnen Sie das Nachrichtenprotokoll des Replikats,$WLP_USER_DIR/servers/myController2/logs/messages.log, in einem Editor.
      2. Suchen Sie nach der folgenden Nachricht, die in Ihrer Umgebung möglicherweise andere IP-Adressen enthält:
        CWWKX6009I:
        Der Verbundcontroller wurde erfolgreich mit dem Replikat 127.0.0.1:10010 verbunden. Die derzeit aktive Replikatgruppe ist []. Die konfigurierte Replikatgruppe ist []. Die verbundenen Ausweichreplikate sind [127.0.0.1:10011, 127.0.0.1:10010]. 
  2. Aktivieren Sie das neue Replikat.

    Führen Sie einen addReplica-Befehl aus, der die Konfiguration der Verwaltungssicherheitsdomäne des Verbundcontrollers verwendet und den Endpunkt des Replikats angibt, das Sie im Format Replikathost:Replikatport angeben möchten. Suchen Sie in der Datei server.xml des Verbundcontrollers nach den Werten für die Parameter --host, --port, --user und --password. Suchen Sie in der Datei server.xml des Replikats nach den Werten für Replikathost:Replikatport. Weitere Informationen zu diesen Parametern erhalten Sie, wenn Sie in einer Befehlszeile den Befehl collective help addReplica ausführen.

    wlp/bin/collective addReplica Replikat-Host:Replikat-Port --host=Host_des_vorhandenen_Controllers --port=Port_des_vorhandenen_Controllers --user=Benutzer_für_vorhandenen_Controller --password=Benutzerkennwort

    Führen Sie für dieses Beispiel, in dem der vorhandene Verbundcontroller und das Replikat sich auf demselben Host befinden, den folgenden Befehl aus:

    wlp/bin/collective addReplica localhost:10011 --host=localhost --port=9443 --user=adminUser --password=adminPassword

    Wenn Sie aufgefordert werden, die Zertifikatskette zu akzeptieren, geben Sie y (yes) ein.

  3. Wiederholen Sie ggf. die Schritte 1 und 2 für weitere Replikate. Fügen Sie beispielsweise der Replikatgruppe ein drittes Replikat hinzu. Nennen Sie das neue Replikat myController3 und geben Sie replicaPort="10012" an. Eine Replikatgruppe muss mindestens drei Replikate haben, um Hochverfügbarkeit bereitstellen zu können.
    Nachdem das dritte Replikat der Replikatgruppe hinzugefügt worden ist, können Sie prüfen, ob der ursprüngliche Verbundcontroller und neue Replikate erfolgreich synchronisiert wurden.
    • Suchen Sie im Nachrichtenprotokoll des ursprünglichen Controllers nach den folgenden Nachrichten. Die Nachrichten haben möglicherweise andere IP-Adressen in Ihrer Umgebung:
      CWWKX6015I: Es wurde eine Anforderung zum Ändern des aktiven Verbundcontrollerreplikats empfangen, die jetzt verarbeitet wird. Die momentan aktive Replikatgruppe ist {127.0.0.1:10010,127.0.0.1:10011}. Die angeforderte neue aktive Replikatgruppe ist {127.0.0.1:10010,127.0.0.1:10011,127.0.0.1:10012}.
      
      CWWKX6016I: Die aktive Replikatgruppe des Verbundcontrollers wurde erfolgreich geändert. Die momentan aktive Replikatgruppe ist {127.0.0.1:10010,127.0.0.1:10011,127.0.0.1:10012}. Die vorherige aktive Replikatgruppe war {127.0.0.1:10010,127.0.0.1:10011}.
      
      CWWKX6011I: Der Verbundcontroller ist bereit und kann Anforderungen akzeptieren. Der Leader ist 127.0.0.1:10010. Die derzeit aktive Replikatgruppe ist [127.0.0.1:10012, 127.0.0.1:10011, 127.0.0.1:10010]. Die konfigurierte Replikatgruppe ist [127.0.0.1:10010, 127.0.0.1:10011, 127.0.0.1:10012].
      
      CWWKX6014I: Das Verbundcontrollerreplikat hat die Datensynchronisation mit den anderen Replikaten durchgeführt.
    • Suchen Sie in den Nachrichtenprotokollen der hinzugefügten Replikate nach den folgenden Nachrichten. Die Nachrichten haben möglicherweise andere IP-Adressen in Ihrer Umgebung:
      CWWKX6016I: Die aktive Replikatgruppe des Verbundcontrollers wurde erfolgreich geändert. Die momentan aktive Replikatgruppe ist {127.0.0.1:10010,127.0.0.1:10011,127.0.0.1:10012}. Die vorherige aktive Replikatgruppe war {127.0.0.1:10010,127.0.0.1:10011}.
      
      CWWKX6011I: Der Verbundcontroller ist bereit und kann Anforderungen akzeptieren. Der Leader ist 127.0.0.1:10010. Die derzeit aktive Replikatgruppe ist [127.0.0.1:10012, 127.0.0.1:10011, 127.0.0.1:10010]. Die konfigurierte Replikatgruppe ist [127.0.0.1:10010, 127.0.0.1:10011, 127.0.0.1:10012].
      
      CWWKX8112I: Die Hostinformationen des Servers wurden erfolgreich im Verbundrepository veröffentlicht.
      
      CWWKX8114I: Die Pfade des Servers wurden erfolgreich im Verbundrepository veröffentlicht.
      
      CWWKX8116I: Der Serverstatus GESTARTET wurde erfolgreich im Verbundrepository veröffentlicht.

Symbol das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 01.12.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=tagt_wlp_configure_replicas
Dateiname: tagt_wlp_configure_replicas.html