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.
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.
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.
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.
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.