
![[16.0.0.3 und höher]](../ng_v16003plus.gif)
Verfügbare Liberty-Cluster in Docker-Containern oder Node.js-Servern konfigurieren
Sie können einen Verbund so konfigurieren, dass er die autonome Implementierung eines Liberty-Servers in einem Docker-Container oder einem oder einem Node.js-Server unterstützt. Der Skalierungscontroller kann Liberty-Software auf einem registrierten Host installieren und einen neuen Server erstellen. Er kann außerdem implementierte Server ausgehend von der Ressourcennutzung und optionalen Skalierungsrichtlinien starten und stoppen. Die Zahl von verfügbaren Servern steigt, wenn die Anwendungsnachfrage hoch ist, und sinkt, wenn die Anwendungsnachfrage niedrig ist.
Vorgehensweise
- Führen Sie die Schritte unter Automatisch skalierbare Cluster für JVM-Elastizität konfigurieren aus.
Video: Im Video Configuring a Liberty auto-scalable cluster for JVM elasticity werden die Schritte veranschaulicht. [Transkript]
- Stellen Sie sicher, dass ein vorhandenes dynamisches Cluster-Member zu dem Clusternamen gehört, der in der Datei Paketname.deploy.xml verwendet wird, die in der Verzeichnisstruktur stackGroups gespeichert werden soll.
Der Typ dieses Cluster-Members muss mit dem Membertyp übereinstimmen, der gemäß der Definition in der Datei Paketname.deploy.xml implementiert wird. Wenn das Stack beispielsweise Docker ist, muss es ein Liberty-Docker-Member sein.
Paketname ist der Name des Serverpakets, das den Zielhosts vom Skalierungscontroller bereitgestellt wird. Weitere Informationen zu diesem Paket finden Sie in Schritt 5.
- Optional: Fügen Sie Skalierungsrichtlinien zum Skalierungscontroller hinzu (siehe Skalierungsrichtlinien definieren).
- Registrieren Sie jeden Zielhost bei einem Skalierungscontroller.
Durch das Registrieren eines Hosts kann der Skalierungscontroller Dateien auf diesen Host übertragen und auf Dateien, Befehle und andere Ressourcen auf dem Host zugreifen. Verwenden Sie zum Registrieren eines Zielhosts den Befehl registerHost. Suchen Sie in der Datei server.xml des Skalierungscontrollers nach den Werten für die Parameter --host, --port, --user und --password. Definieren Sie mit den Parametern --rpcUser und --rpcUserPassword einen Benutzer und ein Kennwort für die Betriebssystemanmeldung, damit keine SSH-Datei mit privatem Schlüssel wie für Zielhosts mit Linux- oder Windows-Betriebssystemen verwendet werden muss. Der mit --rpcUser angegebene Benutzer muss die Betriebssystemberechtigungen für die Position des Implementierungsziels besitzen.
wlp/bin/collective registerHost targetHost --host=controllerHost --port=controllerHTTPSPort --user=controllerAdmin --password=controllerAdminPassword --rpcUser=osUser --rpcUserPassword=osUserPassword
Wenn bereits ein Host registriert ist, können Sie den Befehl updateHost verwenden, um die Registrierungsinformationen neu zu definieren. Wenn sich der Zielhost auf demselben Computer wie der Controller-Host befindet, müssen Sie außerdem den Befehl updateHost für den Controller-Host ausführen. Weitere Informationen finden Sie im Artikel Host-Computer werden bei einem Liberty-Verbund registriert.
- Erstellen Sie eine Datei mit dem Namen Paketname.deploy.xml, die Implementierungsregeln für eine Implementierungsoperation DeployService konfiguriert.
Sie können Name/Wert-Paare hinzufügen, die Werte für die Eingabevariablen der Implementierungsregel setzt.
<deploy> <useRule id="Regel-ID" /> <variable name="Ein_Name" value="Ein_Wert" /> ... </deploy>
Geben Sie für Regel-ID den id-Wert einer von Liberty bereitgestellten Implementierungsregel an oder einen id-Wert Ihrer eigenen Implementierungsregel. Die Datei Paketname.deploy.xml wird im Stackgruppenverzeichnis packages (Schritt 7) gespeichert.
Verwenden Sie für Variablennamen und Wert die in der Implementierungsregel definierten Eingabevariablen.
Informationen für Node.js-Server zu den Anwendungsinhalten in .tgz-Dateien und zur Position in Schritt 2 finden Sie unter Node.js-Server mit REST-Implementierungs-APIs implementieren.
- Legen Sie einen Benutzernamen und ein Kennwort für den Verbundcontroller in der Skalierungscontrollerdatei server.xml fest.
<collectiveController user="adminUser" password="adminPassword" />
- Legen Sie die Datei Paketname.deploy.xml an der Position WLP_STACK_GROUPS_DIR ab, die standardmäßig als $WLP_USER_DIR/shared/stackGroups definiert ist.
Skalierungscontroller überwachen die Paketposition im Dateisystem und reagieren dynamisch auf Aktualisierungen. Wenn Sie die Datei an der Standardposition ablegen, müssen Sie keine der Standardattribute ändern.
Sie können die Standard-Stack-Gruppe defaultStackGroup verwenden. Alternativ können Sie Ihr eigenes Unterverzeichnis für stackGroups, wie z. B. myStackGroup, erstellen und es dem Unterverzeichnis packages hinzufügen.
wlp/usr /servers /shared ... /stackGroups /defaultStackGroup /installables /packages /myStackGroup /packages
Der Skalierungscontroller verwendet die Datei, um einen neuen Server in einem registrierten Host zu erstellen.
Tipp: Es wird nur ein neuer Server erstellt, wenn die Skalierungsrichtlinie aktiviert ist und einen neuen Server erfordert. Wenn Sie durchsetzen möchten, dass ein Skalierungscontroller einen neuen Server erstellt, passen Sie den Wert min und ggf. den Wert max der Skalierungsrichtlinie für den Skalierungscontroller an. Wenn Ihr Skalierungscontroller beispielsweise keine Skalierungsrichtlinie hat und Ihr Verbund drei Skalierungsmember enthält, fügen Sie der Skalierungscontrollerdatei server.xml eine Richtlinie hinzu, die durchsetzt, dass der Skalierungscontroller mindestens vier aktive Member hat:<scalingDefinitions> <defaultScalingPolicy enabled="true" min="4" max="6"/> </scalingDefinitions>
Die Clusternamenskonvention für die Liberty-Elastizität ist StackGroupName.PackageName. Wenn ein Stack implementiert wird, wird in der Datei server.xml des implementierten Servers automatisch <clusterMember name="StackGroupname.PackageName" festgelegt. Das entsprechende Element <scalingPolicy> enthält die Anweisung <bind clusters="StackGroupName.Packagename"/>. Bei den von Liberty für Docker und Node.js bereitgestellten Implementierungsregeln können Sie jedoch clusterName auf einen beliebigen Wert setzen.
- Untersuchen Sie die Implementierungsvariablen und überarbeiten Sie sie entsprechend den Anforderungen für Ihre Umgebung.
Das untergeordnete Element deployVariable gibt eine Substitutionsvariable an, die in den implementierten Stack eingefügt wird. Sie können angeben, dass die Substitutionsvariable bei jeder Stackimplementierung automatisch erhöht wird. Verwenden Sie beispielsweise ein Attribut vom Typ deployVariable, um einen Anfangswert für die Portnummer anzugeben und den Wert bei jeder Implementierung zu erhöhen. Das Attribut deployVariable hat in diesem Fall den Zweck, Portkonflikte auf dem Zielhost zu vermeiden.
Setzen Sie die Implementierungsvariablen für ein Docker-Image, wie in Schritt 1c im Abschnitt Docker-Container mit REST-Implementierungs-APIs implementieren beschrieben.
Setzen Sie die Implementierungsvariablen für eine Node.js-Serverimplementierung, wie in Schritt 3 im Abschnitt Node.js-Server mit Implementierungs-REST-APIs implementieren beschrieben.
- Optional: Ändern Sie das Intervall, in dem der Skalierungscontroller das Dateisystem auf hinzugefügte, aktualisierte und gelöschte Stackgruppen
überprüft.
Der Skalierungscontroller scannt den Inhalt des Verzeichnisses stackGroups und seiner Unterverzeichnisse nach Änderungen. Wurden Änderungen am Inhalt vorgenommen, kann dies dazu führen, dass der Controller Cluster bereitstellt, für die zuvor keine Pakete verfügbar waren. Die Aktualisierung von Paketen führt nicht dazu, dass der Controller vorhandene Cluster erneut bereitstellt.
Standardmäßig scannt der Controller die Position WLP_STACK_GROUPS_DIR alle 5000 Millisekunden (fünf Sekunden). Wenn Sie das Scanintervall ändern oder die Scans inaktivieren möchten, legen Sie in der Datei server.xml des Skalierungscontrollers neue Werte für die Stack-Manager-Attribute scanningInterval und scanningEnable fest. Sie können beispielsweise Scans aktivieren und das Scanintervall auf sechs Sekunden setzen, indem Sie eine Anweisung ähnlich der folgenden zur Datei server.xml des Skalierungscontrollers hinzufügen:
<stackManager groupsDir="${wlp.install.dir}/usr/shared/stackGroups/" controllerUser="adminUser" controllerUserPassword="adminPassword" scanningInterval="6000" scanningEnable="true"> </stackManager>
Wenn Sie die Scans inaktivieren möchten, setzen Sie scanningEnable auf false.
- Optional: Weisen Sie den Skalierungscontroller an, das System zu scannen, um neue, aktualisierte und gelöschte Stackgruppen zu ermitteln.
Führen Sie eine Operation der MBean "StackManager" aus, um durchzusetzen, dass der Skalierungscontroller die Position WLP_STACK_GROUPS_DIR auf hinzugefügte, aktualisierte und gelöschte Stackgruppen überprüft. Auch wenn die Datei server.xml des Skalierungscontrollers den Eintrag scanningEnable="false" enthält, können Sie eine Operation der MBean "StackManager" ausführen, um einen Scan auf hinzugefügte, aktualisierte und gelöschte Gruppen durchzusetzen.
In der Liste der bereitgestellten MBeans finden Sie weitere Informationen zur MBean "StackManager".
- Optional: Starten Sie IHS, um das Routing an Server zu aktivieren.
Damit IBM HTTP Server (IHS) Webanwendungen erkennt und an dynamisch bereitgestellte Cluster weiterleitet, müssen Sie Dynamic Routing auf dem Host aktivieren, auf dem sich der Skalierungscontroller befindet. IHS ruft die Routing-Informationen für die bereitgestellten Server vom Dynamic Routing-Service ab. Ist der Serverstatus aktiviert, können Sie die Routing-Informationen anzeigen.
Lesen Sie die Informationen unter Dynamisches Routing für Liberty-Verbünde konfigurieren, wenn IHS nicht installiert ist. Im folgenden Video wird außerdem gezeigt, wie die Unterstützung für Dynamic Routing mit IBM Installation Manager installiert wird:
Video: Im Video Enabling IHS for Liberty Dynamic Routing wird gezeigt, wie Sie IHS und Web Server Plug-in for WebSphere Application Server installieren und wie der vorläufige Fix für Dynamic Routing angewendet wird. [Transkript]

Dateiname: twlp_autoscale_deployxml.html