Zum Inhalt

Planen der Bereitstellung

Wie viele Sitzungsserver sollten Sie bereitstellen? Wie viele MSS-Server? Welche anderen Erwägungen müssen berücksichtigt werden? Dieser Abschnitt erläutert, wie Sie die Bereitstellung der Sitzungsserver und MSS-Server optimieren.

Skalierung und Hochverfügbarkeit

Als ersten Schritt zur Planung der Bereitstellung müssen Sie ermitteln, wie viele Sitzungsserver und MSS-Server Sie zum Erfüllen Ihrer Anforderungen benötigen. Host Access for the Cloud kann je nach den spezifischen Anforderungen mit großer Kapazität und mit hoher Verfügbarkeit bereitgestellt werden.

Die optimale Lösung hängt von den jeweiligen Anforderungen ab. Der Abschnitt „Beispielplan einer Hochverfügbarkeits-Bereitstellung“ beschreibt ein Beispiel einer Bereitstellung, die sowohl Anforderungen in Bezug auf die Skalierbarkeit als auch auf die Hochverfügbarkeit erfüllt.

Stellen Sie sich die folgenden wesentlichen Fragen:

  • Maximal wie viele Hostsitzungen werden gleichzeitig verwendet?
  • Wie viele Benutzer werden das System verwenden?
  • Welche Anforderungen an die Verfügbarkeit muss das System im Falle eines Fehlers in verschiedenen Systembereichen erfüllen?

Skalierung

Die Skalierbarkeit bezeichnet die Fähigkeit des Systems, verschieden hohe Lasten zu bewältigen. Zum Erhöhen der Kapazität kann das System vertikal hochskaliert werden, indem es auf einem leistungsfähigeren Server ausgeführt wird, oder horizontal, indem zusätzliche Server oder Knoten hinzugefügt werden.

Beide Szenarien sind mit jeweils spezifischen Kompromissen verbunden:

  • Das vertikale Hochskalieren bietet dank der geringeren Serveranzahl eine größere Einfachheit, erhöht jedoch auch die Gefahr einer schwerwiegenderen Störung, wenn ein Server ausfällt.
  • Das horizontale Hochskalieren erfordert eine größere Anzahl Server, teilt jedoch die Risiken auf so viele Server aus, dass im Falle eines Serverausfalls weniger Benutzer betroffen sind.

Aufgrund der größeren Stabilität wird das horizontale Hochskalieren empfohlen, d. h. das Erhöhen der Kapazität durch Hinzufügen zusätzlicher Server oder Knoten.

Hochverfügbarkeit

Hochverfügbarkeit bezeichnet die Fähigkeit eines Systems, selbst im Falle eines Fehlers im System weiterhin Services bereitzustellen. Hochverfügbarkeit wird erreicht, indem Schlüsselkomponenten des Systems redundant bereitgestellt werden.

Hinweis

Dieses Handbuch beschreibt das Bereitstellen der Hochverfügbarkeit der Kernservices von Host Access for the Cloud. Echte Hochverfügbarkeit beruht jedoch auf der Redundanz vieler verschiedener Ebenen in allen Systembereichen, was den Rahmen dieses Dokuments überschreitet.

Hochverfügbarkeit wird in Host Access for the Cloud auf folgende Weise erreicht:

  • Bereitstellen einer ausreichenden Anzahl an Sitzungsservern und MSS-Servern, um die erforderliche Kapazität abzudecken und einen Toleranzbereich (Freiraum) für Ausfälle zu bieten
  • Bereitstellen eines ausreichend großen Toleranzbereichs, um sicherzustellen, dass die verbleibenden Server im Falle eines Serverausfalls die zusätzliche Last bewältigen können
  • Verwenden eines Lastverteilers, der die Last verteilt und die Benutzer im Falle eines Ausfalls zu anderen Servern leitet
  • Replizieren von Daten zwischen MSS-Servern mittels MSS-Clustering

Der Abschnitt Beispielplan einer Hochverfügbarkeits-Bereitstellung stellt dar, wie diese Anforderungen erfüllt werden können.

Bestimmung der Anzahl der Sitzungsserver

Die Anzahl der erforderlichen Sitzungsserver hängt von der Anzahl der gleichzeitig ausgeführten Hostsitzungen ab. Hostsitzungen erzeugen eine größere Last auf dem Sitzungsserver als Benutzer. Deshalb ist die Anzahl der erforderlichen Hostsitzungen von größerer Bedeutung als die Anzahl der Benutzer.

Anzahl der gleichzeitigen Hostsitzungen Erforderliche Anzahl an Sitzungsservern
Bis 3000 2 Sitzungsserver
Mehr als 3000 (Anzahl der erforderlichen Hostsitzungen) / 2000 + 1 (mindestens drei)
  • Ein einzelner Sitzungsserver unterstützt 2000 gleichzeitig verwendete Hostsitzungen.
  • Ein Sitzungsserver bietet im Falle eines Failover-Szenarios einen Toleranzbereich für 1000 zusätzliche Hostsitzungen.
  • Für Hochverfügbarkeitsbereitstellungen sind mindestens zwei Sitzungsserver erforderlich.

Bestimmung der Anzahl der MSS-Server

Anzahl gleichzeitiger Benutzer Erforderliche Anzahl an MSS-Servern
Bis 30.000 3 MSS-Server
Mehr als 30.000 (Benötigte Benutzeranzahl) / 10.000 + 1 (muss eine ungerade Zahl sein)
  • Ein einzelner MSS-Server unterstützt 10.000 gleichzeitige Benutzer.
  • Ein MSS-Server bietet im Falle eines Failover-Szenarios einen Toleranzbereich für zusätzliche 5000 Benutzer.
  • Für Hochverfügbarkeitsbereitstellungen sind mindestens 3 MSS-Server erforderlich
  • Die Anzahl der MSS-Server in einer Hochverfügbarkeits-Bereitstellung muss ungerade sein, um die Anforderung eines Datenbankquorums zu erfüllen.

Verwendung von Lastverteilern

Sowohl für die Sitzungsserver als auch für MSS muss ein Lastverteiler bereitgestellt werden. Berücksichtigen Sie hierbei die folgenden allgemeinen Einstellungen:

  • Lastausgleichalgorithmus: Der Algorithmus legt fest, zu welchem Server neuer Verkehr geleitet wird. Wir empfehlen eine Einstellung wie „Geringste Anzahl an Verbindungen“. Zur Gewährleistung der allgemeinen Systemstabilität sollte unbedingt überprüft werden, ob die Einstellung die Last ordnungsgemäß verteilt. Wenn der Lastverteiler nicht richtig konfiguriert ist oder nicht effizient ist, besteht die Gefahr der Überlastung einzelner Server.
  • Sitzungsbeständigkeit (Affinität/dauerhafte Sitzungen): Diese Einstellung beschreibt die Möglichkeit, einen bestimmten Benutzer über mehrere Anforderungen hinweg an den gleichen Server zu leiten. Sowohl der Sitzungsserver als auch MSS sind Stateful-Anwendungen (statusbehaftete Anwendungen) und erfordern die Aktivierung dauerhafter Sitzungen für die Lastverteiler.
  • Systemdiagnose-Endpunkt: Dies bezeichnet die URL auf dem Zielservice, mit der ermittelt wird, ob die Instanz in gutem Zustand ist und weiterverwendet werden soll. Jeder Servertyp stellt eine eigene Systemdiagnose-URL bereit.

Der Abschnitt Beispielplan einer Hochverfügbarkeits-Bereitstellung enthält empfohlene Werte für jede dieser Einstellungen.

TLS-Optionen

Für die Handhabung von TLS in einem Lastverteiler gibt es drei übliche Optionen. Die Wahl der Option hängt von Ihren Anforderungen ab.

Für die ersten beiden Optionen muss das Zertifikat im Lastverteiler installiert sein. Bei der dritten Option, TLS-Passthrough, ist kein Zertifikat auf dem Lastverteiler erforderlich. Im Hochverfügbarkeits-Beispielplan wird TLS-Bridging verwendet, um durchgängiges TLS mit auf Cookies basierender Beständigkeit bereitzustellen. Folgende Optionen sind möglich:

  • TLS Termination/Offloading: Bei dieser Option wird die HTTPS-Verbindung am Lastverteiler beendet und als HTTP-Verbindung zum Service fortgesetzt.

  • TLS-Bridging (Neuverschlüsselung): Bei dieser Option wird die HTTPS-Verbindung am Lastverteiler beendet und eine neue HTTPS-Verbindung zwischen Lastverteiler und Service wird hergestellt. Auf diese Weise wird durchgängiges TLS gewährleistet und der Lastverteiler kann dennoch einen Cookie für die Sitzungsbeständigkeit einfügen.

  • TLS-Passthrough (erforderlich für X.509): Der Lastverteiler agiert als Vertretung für die TLS-Verbindung, ohne sie zu entschlüsseln. Der Nachteil dieser Option besteht darin, dass kein Cookie eingefügt werden kann. Die Beständigkeit muss deshalb auf der Ursprungs-IP oder einem ähnlichen Parameter basieren.

TLS mit X.509-Single Sign-on

Bei der X.509-Authentifizierung ist die Option des TLS-Passthrough auf dem Host Access for the Cloud- und MSS-Lastverteiler erforderlich, weil den Servern im Back-End die Clientzertifikate präsentiert werden müssen. Weil TLS-Passthrough erforderlich ist, benötigen Sie eine nicht auf Cookies beruhende Methode zum Gewährleisten der Sitzungsbeständigkeit, zum Beispiel die Verwendung der Ursprungs-IP, für den Sitzungsserver- und MSS-Lastverteiler. Dies ist erforderlich, weil der Lastverteiler mit TLS-Passthrough die Verbindung nicht entschlüsseln kann und auch keinen Cookie setzen oder anzeigen kann.

Terminal ID Manager

Terminal ID Manager unterstützt zurzeit keine Hochverfügbarkeitsbereitstellungen. Sie können einen passiven Server einrichten, aber der Zustand der IDs wird nicht vom aktiven Server repliziert. Wenn der aktive Server nicht verfügbar ist, können Sie weiterhin auf den passiven Server zugreifen, die IDs behalten jedoch nicht ihren aktuellen Zustand bei.

Bereitstellungsoptionen

Zum Bereitstellen der Sitzungsserver haben Sie die Wahl zwischen zwei verschiedenen Verfahren:

  1. Herkömmliches Installieren jedes Sitzungsservers auf einem dedizierten Server

  2. Verwenden von Docker und Ausführen jedes Sitzungsservers in einem Container. Docker bietet verschiedene Vorteile, zum Beispiel eine größere Flexibilität in Bezug auf die Anzahl der Sitzungsserver, die auf einem einzelnen Server ausgeführt werden können. Weitere Informationen hierzu finden Sie unter Verwenden von Docker.

Grundlegendes zu Dienstunterbrechungen

Hinweis

Beachten Sie beim Auswählen der Bereitstellungsoptionen, dass HACloud aus mehreren Diensten besteht: Sitzungsserver, MSS und zugehörige Add-Ons, Terminal ID Manager und Nutzungsüberwachung. Standardmäßig werden MSS, Terminal ID Manager und die Nutzungsüberwachung zusammen in einem einzigen Prozess ausgeführt, können jedoch so konfiguriert werden, dass sie in separaten Prozessen ausgeführt werden. Der HACloud-Sitzungsserver wird immer als eigener Prozess ausgeführt.

Wenn der Sitzungsserver beendet wird, werden alle Hostsitzungen auf diesem Server geschlossen. Benutzer, die bei diesem Server angemeldet waren, müssen sich erneut authentifizieren, wenn der Server neu gestartet wird oder sie zu einem neuen Server umgeleitet werden.

In dieser Tabelle werden die Auswirkungen auf die Fähigkeiten des Endbenutzers beschrieben, wenn Dienste nicht verfügbar sind oder neu gestartet wurden.

Aktion Server nicht verfügbar Server neu gestartet
MSS
Anmelden Nein Ja
Neue Hostsitzungen erstellen Nein Ja
Vorhandene Hostsitzungen verwenden Ja Ja
Vorhandene Hostsitzungen wieder verbinden Ja (ausgenommen SSH-Sitzungen) Ja
Sitzungen bearbeiten Nein Ja (erneute Anmeldung erforderlich)
Benutzermakros aufzeichnen/bearbeiten Nein Ja
Terminal ID Manager
Hostsitzung verbinden, für die eine ID erforderlich ist Nein Ja
Hostsitzung verbinden, für die keine ID erforderlich ist Ja Ja
Nutzungsüberwachungsserver
Neue Hostsitzungen erstellen Nein* Ja
Vorhandene Hostsitzungen verwenden Ja Ja
  • Wenn die Eigenschaft metering.host.required auf „false“ festgelegt ist, können neue Sitzungen erstellt werden.

Wenn ein Sitzungsserver ausfällt, gehen alle Sitzungen für alle Benutzer verloren, die über den Lastverteiler mit diesem Sitzungsserver verbunden sind. Jeder Benutzer muss sich (über den Lastverteiler) bei einem anderen Sitzungsserver anmelden und neue Sitzungen starten.