Skalierung in Einheiten oder Pods

Obwohl Sie ein Datengrid in Tausenden von Java Virtual Machines implementieren können, sollten Sie darüber nachdenken, das Datengrid möglicherweise in Einheiten oder Pods einzuteilen, um die Zuverlässigkeit zu erhöhen und das Testen der Konfiguration zu vereinfachen. Ein Pod ist eine Gruppe von Servern, in denen dieselben Anwendungen ausgeführt werden.

Implementierungen eines einzigen großen Datengrids

Tests haben ergeben, dass eXtreme Scale auf über 1000 JVMs skaliert werden kann. Diese Tests animieren zum Erstellen von Anwendungen für die Implementierung eines einzigen Datengrids auf sehr vielen Maschinen. Obwohl diese Vorgehensweise möglich ist, wird sie aus verschiedenen Gründen, die im Folgenden beschrieben werden, nicht empfohlen.

  1. Budgetbedenken: Realistisch betrachtet ist Ihre Umgebung nicht in der Lage, ein Datengrid mit 1000 Servern zu testen. Tests mit einem sehr viel kleineren Datengrid sind unter Berücksichtigung von Budgetgründen jedoch möglich, so dass Hardware nicht doppelt gekauft werden muss, insbesondere bei einer solch hohen Anzahl an Servern.
  2. Verschiedene Anwendungsversionen: Für jeden einzelnen Test sehr viele Maschinen zu benötigen, ist nicht sehr praktisch. Es besteht das Risiko, dass nicht dieselben Faktoren getestet werden, wie es in einer Produktionsumgebung der Fall ist.
  3. Datenverlust: Die Ausführung einer Datenbank auf einem einzigen Festplattenlaufwerk ist unzuverlässig. Jedes Problem mit dem Festplattenlaufwerk führt zum Verlust von Daten. Die Ausführung einer ausbaufähigen Anwendung in einem einzigen Datengrid ist ähnlich. Es ist wahrscheinlich, dass Sie Programmfehler in Ihrer Umgebung und in Ihren Anwendungen haben. Die Speicherung aller Daten auf einem einzigen großen System führt deshalb häufig zum Verlust großer Datenmengen.

Aufteilung des Datengrids

Die Aufteilung des Anwendungsdatengrids in Pods (Einheiten) ist zuverlässiger. Ein Pod ist eine Gruppe von Servern, auf denen ein homogener Anwendungs-Stack ausgeführt wird. Pods können beliebig groß sein, sollten sich idealerweise aber aus ca. 20 physischen Servern zusammensetzen. Anstatt 500 physische Server in einem einzigen Datengrid zu verwenden, können Sie 25 Pods mit jeweils 20 physischen Servern verwenden. Es sollte jeweils nur eine einzige Version eines Anwendungs-Stacks in einem bestimmten Pod ausgeführt werden, aber die verschiedenen Pods können jeweils eigene Versionen eines Anwendungs-Stacks haben.

Im Allgemeinen werden in einem Anwendungs-Stack die Versionsstände der folgenden Komponenten berücksichtigt:
  • Betriebssystem
  • Hardware
  • JVM
  • Version von WebSphere eXtreme Scale
  • Anwendung
  • Weitere erforderliche Komponenten

Ein Pod ist eine Verteilungseinheit mit einer für Tests geeigneten Größe. Anstatt Hunderte von Servern für Tests zu verwenden, empfiehlt es sich, nur 20 Server zu verwenden. In diesem Fall testen Sie dieselbe Konfiguration wie in einer Produktionsumgebung. In Produktionsumgebungen werden Grids mit einer Größe von maximal 20 Servern, die einen Pod bilden, verwendet. Sie können Belastungstests für einen einzigen Pod ausführen und dabei die Kapazität, die Anzahl der Benutzer, das Datenvolumen und den Transaktionsdurchsatz dieses Pods bestimmen. Dies vereinfacht die Planung und entspricht dem Standard einer vorhersehbaren Skalierung zu vorhersehbaren Kosten.

Einrichtung einer Pod-basierten Umgebung

In manchen Fällen muss der Pod nicht unbedingt 20 Server haben. Die Pod-Größe dient ausschließlich dem Zweck praxistauglicher Tests. Ein Pod sollte klein genug sein, dass der Teil der beim Auftreten von Pod-Problemen in einer Produktionsumgebung betroffenen Transaktionen tolerierbar bleibt.

Im Idealfall wirkt sich ein Programmfehler auf einen einzigen Pod aus. Ein Programmfehler würde sich nur auf vier Prozent der Anwendungstransaktionen und nicht auf 100 Prozent auswirken. Außerdem sind Upgrades einfacher, weil sie nacheinander in jeweils einem Pod implementiert werden können. Wenn aufgrund eines Upgrades in einem Pod Probleme auftreten, kann der Benutzer somit den Pod auf die vorherige Version zurücksetzen. Upgrades umfassen alle Änderungen, die an der Anwendung bzw. am Anwendungs-Stack vorgenommen werden, sowie Systemaktualisierungen. Bei Upgrades sollte möglichst jeweils nur ein einziges Element des Stacks aktualisiert werden, um die Problemdiagnose zu vereinfachen.

Zum Implementieren einer Umgebung mit Pods benötigen Sie eine Routing-Schicht oberhalb der Pods, die auf- und abwärtskompatibel ist, wenn Software-Upgrades auf Pods angewendet werden. Außerdem sollten Sie ein Verzeichnis erstellen, das Informationen dazu enthält, welcher Pod welche Daten enthält. (Hierfür können Sie ein weiteres datenbankgestütztes eXtreme-Scale-Datengrid verwenden, vorzugsweise mit Verwendung des Write-behind-Szenarios.) Dies ergibt eine 2-Schichten-Lösung. Schicht 1 ist das Verzeichnis und wird verwendet, um den Pod zu ermitteln, der eine bestimmte Transaktion bearbeitet. Schicht 2 setzt sich aus den Pods selbst zusammen. Wenn Schicht 1 einen Pod identifiziert, leitet das Setup jede Transaktion an den richtigen Server im Pod weiter, der gewöhnlich der Server ist, der die Partition für die von der Transaktion verwendeten Daten enthält. Optional können Sie einen nahen Cache auf Schicht 1 verwenden, um die Auswirkungen zu mindern, die mit der Ermittlung des richtigen Pods verbunden sind.

Die Verwendung von Pods ist geringfügig komplexer als die Verwendung eines einzigen Datengrids, aber aufgrund der Verbesserungen in Bezug auf den Betrieb, die Tests und die Zuverlässigkeit sind Pods ein entscheidender Faktor bei Skalierbarkeitstests.