Datenbanken wie DB2/390 haben eine integrierte Partitionierung und können die Datenbankpartitionierung in der Anwendung überflüssig machen.
Obwohl Sie einen zuverlässigen Cluster für die Ausführung einer Anwendung konfigurieren können, kann die Datenbank zu einem Single Point of Failure und einer vertikalen Skalierungsgrenze werden, wenn der Cluster nur eine Datenbankinstanz verwendet. Die Datenbank ist deshalb ein Single Point of Failure, weil bei ihrem Ausfall keine weiteren Arbeiten mehr im Cluster durchgeführt werden können. Die meisten Datenbanken können nur vertikal skaliert werden, d. h. in der Geschwindigkeit. Sie müssen eine größere Maschine kaufen.
Die folgende Abbildung zeigt eine Architektur mit einem Datenbankserver. In dieser Abbildung werden zwei WebSphere Application Server gezeigt, aber es ist nur ein Datenbankserver verfügbar. Wenn stetig mehr Anwendungsserver hinzugefügt werden, wird die Datenbank zu einem Leistungsengpass.
Möglicherweise benötigen Sie eine horizontale Skalierung von Datenbanken und setzen voraus, dass nicht der gesamte Anwendungsserver-Cluster stoppt, wenn die Datenbank ausfällt. Bei vielen Anwendungen ist es akzeptabel, dass Ausfälle einen Teil der Anwendung betreffen, wohingegen der Ausfall der gesamten Anwendung nicht akzeptiert werden kann. Solche Architekturen verwenden ein partitioniertes Datenbankdesign.
Ein Beispiel für ein solches Design sind drei Maschinen, auf denen eigenständige DB2-Instanzen ausgeführt werden. Das Tabellenschema und das Sicherheitssystem sind für alle drei Datenbanken identisch. Alle Referenzdaten, die nur gelesen werden, werden von einer hoch verfügbaren DB2-Instanz mit den Master-Referenzdaten in allen drei Datenbanken repliziert. Die DB2-Instanz mit den Master-Referenzdaten ist im Normalbetrieb kein Single Point of Failure, weil sie von der Anwendung nicht direkt verwendet wird.
Wenn mehrere Server bereit sind, muss sichergestellt werden, dass die Anwendungsdaten partitionierbar sind. Ordnen Sie die Daten für eine bestimmte Partition einer bestimmten DB2-Instanz zu. Sie können hierfür ein einfaches Hash-Schema, einen Bereichsmechanismus oder eine replizierte Tabelle in den Datenbanken verwenden. Die Tabelle wird vom Anwendungsserver-Cluster zwischengespeichert und gibt die DB2-Instanz an, die die Daten für eine bestimmte Partition enthält. Mit dieser Konfiguration können kritische Daten ohne Anwendungsänderungen zwischen Datenbanken verschoben werden.
Sie benötigen ein Anwendungsprotokoll, um eine Korrelation zwischen Partition und einer Datenbankinstanz herzustellen. Mit dieser Art von Korrelation ist eine Anwendung in der Lage, für eine horizontale Skalierung der Gruppe verwendeter Datenbanken eine Datenbankinstanz hinzuzufügen. Der Vorteil bei der Verwendung von drei unabhängigen Datenbankinstanzen ist eine höhere Verfügbarkeit, als sie eine herkömmliche Cluster-Datenbank wie Oracle RAC oder DB2 EEE bietet. Die Datenbanken sind voneinander unabhängig, und der Ausfall einer der Datenbanken bedeutet nur, dass die in dieser Datenbank enthaltenen Daten nicht verfügbar sind. Die Anwendung kann jedoch weiterhin Transaktionen für die Daten in den anderen, weiterhin aktiven Datenbankinstanzen ausführen.
Diese Situation erweist sich bei einem vollständigen Ausfall als vorteilhaft. Allerdings ist die Verwaltung bei drei Datenbanken komplexer als bei einer. Die Anwendung verwendet so genannte gerichtete Transaktionen, um dem Anwendungsserver mitzuteilen, welche Datenbankinstanz die vollständigen Daten für die nächste Transaktion enthält. Dieses Muster ermöglicht eine äußerst flexible Verwaltung von Anwendungsdatenbanken, insbesondere bei der Verwendung der Zuordnungstabelle (MAPPER), die der Anwendung mitteilt, auf welchem Datenbankknoten die Daten für eine bestimmte Partition gespeichert sind.
WebSphere Extended Deployment unterstützt ein neues Feature, die Proxy-Datenquelle, mit dem die Anwendung vor dem Transaktionsstart mitteilen kann, welche Datenbank zu verwenden ist. Wenn ein Cluster-Member eine Anforderung für eine bestimmte Anwendungspartition empfängt, kann es die CMP-Laufzeitumgebung anweisen, die Datenquelle, mit denen die Beans implementiert werden, zu ignorieren und für die Dauer der nächsten Transaktion eine andere Datenquelle zu verwenden. Die Verwendung des Musters mit gerichteten Transaktionen erhöht die Verfügbarkeit einer Anwendung und unterstützt die horizontale Skalierung der Datenbankschicht in Blade-Umgebungen. Außerdem können die Anwendungen das Muster mit Zuordnungstabelle verwenden, um Daten zu verwalten und Partitionen zu verschieben.
Die folgende Abbildung veranschaulicht die neue Architektur. Es sind zwei Datenbanken im System vorhanden, und EJB1 ist in beiden Servern implementiert. In einer Transaktion greift EJB1 im oberen Server auf die Datenbank 1 zu. In einer anderen Transaktion greift EJB2 im unteren Server auf die Datenbank 2 zu. Die Datenbanklast ist auf mehrere Datenbankserver verteilt.
Related concepts
J2EE-Partitionierungsfunktionen