Hochverfügbarkeit

PowerShell Universal kann für Hochverfügbarkeit ("HA") konfiguriert werden, indem eine Kombination aus SQL-Server-Persistenz und einem Load Balancer verwendet wird, um sicherzustellen, dass sowohl die Front-End-Tools, wie zum Beispiel Dashboards, erreichbar sind als auch die Back-End-Tools, wie zum Beispiel Jobs, weiterhin ausgeführt werden.

Persistenzkonfiguration

Wir empfehlen, SQL-Persistenz (oder PostgreSQL) zu nutzen, um sicherzustellen, dass alle Knoten innerhalb Ihres Clusters dieselben Daten in Bezug auf Job-Warteschlangen, App-Tokens und Identitäten in Ihrem System teilen. Jeder Knoten sollte mit derselben SQL-Server-Verbindungszeichenfolge konfiguriert werden.

Während Jobs ausgeführt werden, Benutzer sich anmelden und App-Tokens erstellt werden, wird der SQL-Server zum Speichern dieser Informationen verwendet, und diese werden knotenübergreifend geteilt.

Konfiguration der Quellcodeverwaltung

Wir empfehlen die Verwendung der Git-Synchronisierung, um die PowerShell-Konfigurationsskripte, mit denen die PowerShell Universal-Knoten verwaltet werden, zu speichern und deren Versionen zu verwalten. Eine Einweg-Git-Synchronisierung kann vorzuziehen sein, da die Knoten dann schreibgeschützt sind und Konfigurationen erst abrufen, nachdem sie in Ihren Produktionsbranch gemerged wurden. Jeder Knoten ruft die Konfigurationsdateien in einem konfigurierbaren Intervall ab (Standard ist 1 Minute). Das Speichern der Git-Konfigurationseinstellungen in der Datenbank ist wünschenswert, da dadurch pro Knoten weniger Konfiguration erforderlich ist.

Load Balancing

PowerShell Universal unterstützt die Verwendung von Load Balancern wie F5 und nginx. Bei der Verwendung von Load Balancern müssen einige Voraussetzungen erfüllt werden.

• Persistente (sticky) Sitzungen sind für die Admin-Konsole und Apps erforderlich
• WebSocket-Unterstützung ist für die Admin-Konsole und Apps erforderlich

Zur Unterstützung des Load Balancings können Sie den Endpunkt /api/v1/status für Ihre Knoten verwenden. Der Endpunkt gibt Statuscodes basierend auf dem aktuellen Zustand des Knotens zurück. 200 bedeutet, dass der Knoten online und bereit ist, Anfragen zu empfangen. Server, die im Wartungsmodus laufen, geben 503 zurück. Server, die aufgrund eines Konfigurationsfehlers nicht gestartet werden konnten, geben 500 zurück. Server mit Apps, die nicht gestartet werden konnten, geben ebenfalls 500 zurück.

Status-APIs

/api/v1/status

Sie können Ihre Knoten in den Wartungsmodus versetzen, indem Sie auf Platform \ Computers klicken und die Option für den Wartungsmodus aktivieren. Sobald der Wartungsmodus aktiviert ist, beginnt der Endpunkt /api/v1/status 503 zurückzugeben. Dies sollte so konfiguriert werden, dass während der Wartung kein Datenverkehr an den Knoten weitergeleitet wird. Dieser Endpunkt gibt außerdem 5xx zurück, wenn Folgendes zutrifft:

• Der Computer befindet sich in einem Startfehlerstatus
• Der Computer befindet sich im Wartungsmodus
• Eine kritische App befindet sich in einem fehlgeschlagenen Startzustand
• API-Endpunkte sind konfiguriert, laufen aber nicht ordnungsgemäß

/api/v2/status

Die v2-Status-API gibt aus zusätzlichen Gründen einen 503 zurück. Dazu gehören:

• Ein Computer im Cluster ist offline, befindet sich aber nicht im Wartungsmodus
• Die Git-Synchronisierung kann auf einem Knoten keine Änderungen abrufen
• API-Endpunkte sind konfiguriert, laufen aber nicht ordnungsgemäß

Einschränkungen

Derzeit gibt es einige Einschränkungen bei hochverfügbaren PowerShell Universal-Clustern.

Knotenübergreifendes Caching

Das Caching mit $Cache ist auf einen einzelnen Prozess auf einem einzelnen Knoten beschränkt. Beispielsweise verfügt jede App, die außerhalb der integrierten Umgebung ausgeführt wird, über ihren eigenen Cache.

Set-PSUCache teilt Daten nicht knotenübergreifend, wenn -Persist nicht angegeben ist. Um sicherzustellen, dass alle Knoten dieselben Daten haben, geben Sie diesen Schalter an.

Knotenübergreifender App-Broadcast

Knotenübergreifende App-Broadcast-Nachrichten werden derzeit nicht unterstützt. Die Verwendung von Cmdlets wie Show-UDToast -Broadcast führt dazu, dass ein Toast-Modal allen verbundenen Benutzern des aktuellen Knotens angezeigt wird, es wird jedoch nicht an die Apps auf allen Knoten übertragen.