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.
Inhalte dieses Abschnitts:
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?
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 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.
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.
Die erforderliche Anzahl an MSS-Servern hängt von der Anzahl der gleichzeitigen Benutzer ab.
|
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.
Zum Bereitstellen der Sitzungsserver haben Sie die Wahl zwischen zwei verschiedenen Verfahren:
Herkömmliches Installieren jedes Sitzungsservers auf einem dedizierten Server
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 in Verwenden von Docker.
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. Siehe unten.
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 beschreibt die empfohlenen Einstellungswerte für jeden Lastverteiler.
Für die Handhabung von TLS/SSL 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.
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 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.