Moderne Logistiksoftware mit Clustering und verteiltem Rechnen
Das Clustering von Business-Anwendungen gehört zu den Königsdisziplinen in der IT - sollen doch zweierlei Aufgaben mit einem Cluster gelöst werden: Lastverteilung und Ausfallsicherheit. Jedoch gibt es verschiedene Ansätze einen Cluster zu betreiben und die Komplexität variiert dabei stark. Für die meisten Kunden ist Ausfallsicherheit das größere Thema und je nach Cluster kann der Ausfall eines Servers einen aktuell laufenden Prozess beeinträchtigen oder nicht.
###Ausfallsicherheit im Lager In jedem Lager gibt es Peakzeiten, in denen ein Ausfall von Software besonders schmerzt. In einem Retaillager sind dies z.B. Zeiten die kurz vor der Abholung der Ware durch KEP Dienstleister oder Speditionen liegen. Es gibt jedoch auch andere Ereignisse wie Stichtagsinventuren, bei denen ein Ausfall massive Personalmehrkosten nach sich ziehen würde. Das zusätzliche Problem in modernen Lägern ist die große Arbeitszeitspanne pro Tag. Zeitfenster für Installationen oder Updates von Software können auf bis zu 2-3 Stunden in der Nacht schmelzen, was organisatorische Probleme mit sich bringt. Auch hier kann ein Cluster helfen, da es ein Hot-Deployment von Software erlaubt, ohne das die Benutzer in ihrer Arbeit gestört werden.
###Cluster Light - ohne Anpassung an Software Es ist ohne weiteres möglich ein Cluster aufzusetzen, der für die Software transparent ist. Solch ein Cluster bzw. der Proxy (Loadbalancer), der die Anftragen auf die im Cluster befindlichen Server verteilt, merkt sich welcher User auf welchen Server gelangt ist und verteilt weitere Anfragen desselben Benutzers immer an denselben Server. Bei einem Loadbalancer nennt man dieses Feature "Session-Sticky". Die Anfragen werden also nicht nach Last verteilt, sondern nach Usersessions. Natürlich gibt es eine Lastverteilung alleine durch die Aufteilung auf mehrere Server im Cluster, dynamisch ist diese jedoch nicht. Falls per Zufall alle Poweruser auf Server1 landen und dort auch bleiben und auf Server2 nur Benutzer mit wenig arbeitsintensiven Aufgaben verweilen, dann hat man im Ergebnis eine sehr ungleiche Verteilung der Last.
Für viele Firmen ist dies der erste Kontakt in Sachen "Clustering". Es gilt zu beachten, dass wenn ein Server inmitten eines Benutzerprozesses "stirbt", es keine Möglichkeit gibt, diesen Prozess auf einem anderen Server im Cluster weiterzuführen, da die Anwendung auf dem anderen Server, keine Informationen über den Benutzer und dessen aktuellen Daten (Session) hat. Es ist jedoch möglich sich neu anzumelden. Dann würde der Benutzer auf dem zweiten Server weitermachen. Er würde den Ausfall des Servers also mitbekommen, kann jedoch weiterarbeiten. Somit hat auch solch ein Cluster einen positiven Effekt auf die Gesamtausfallsicherheit.
###Cluster mit Session-Replikation Ein Cluster mit Session-Replikation erfüllt die grundsätzliche Anforderung, dass die Anwendung auf Server2 zu jedem Zeitpunkt den Zustand eines Benutzers weiss, auch wenn dieser bisher von Server1 bedient wurde. Das hat zur Folge, dass im Falle eines Ausfalls von Server1 der Benutzer im besten Fall sofort für die nächste Aktion auf Server2 umgeleitet wird und dort weiter arbeiten kann, als wenn nichts geschehen wäre. Das Setup eines solchen Clusters ist etwas komplexer, da hier entweder die Anwendung oder der Applikationsserver, auf dem die Anwendung läuft, entsprechend konfiguriert sein muss. Es gibt eine stete Kommunikation der Anwendung/Server untereinander, um den Status der verschiedenen Benutzer zu replizieren.
Der Loadbalancer verteilt in diesem Zusammenhang die Anfragen auch nicht mehr pro User an die verschiedenen Server, sondern verteilt im einfachen Fall per Round-Robin an die Rechner (jeder Request wird an den nächsten Server verteilt). Dies erlaubt eine ausgewogenere Lastverteilung.
###Cluster mit Session-Replikation und Datagrid Eine weitere Ausbaustufe ist es, einen Cluster als Datagrid zu benutzen. Die Vorteile der bereits genannten Szenarien bleiben hierbei bestehen. Hinzu kommt jedoch die Möglichkeit, Rechenaufgaben bzw. komplexe Algorithmen auf verschiedene Server im Cluster zu verteilen. Ein Beispiel wäre z.B. eine Kalkulation über alle eingelagerten Artikel. Bei der Annahme, dass 300.000 Artikel im Lagerbestand sind, würde bei einem 3-Server Cluster, jeder Server 100.000 Artikel berechnen. Eine weitere Möglichkeit ist z.B. das Starten von zeitgesteuerten Jobs auf dem Server, der gerade am wenigsten Last hat. Ein Datagrid ist somit ein Netz aus Servern, die sich untereinander unterhalten und somit erweiterte Features im Erledigen von Aufgaben bereitstellen.
Bei dieser Art des Clusters sind in jedem Fall Anpassungen an die jeweilige Logistikanwendung erforderlich. Ein Datagrid Framework muss hierbei in die Anwendung integriert werden und Anpassungen an bestehenden Softwarecode muss beigesteuert werden. Im Java Umfeld haben sich einige Marktteilnehmer wie Oracle Coherence, Hazelcast und Terracotta etabliert, die entsprechende Offerings anbieten. LOGENTIS setzt auf Hazelcast als eine Open Source basierte Lösung mit einer Venture Capital finanzierten Firma Hazelcast Inc. im Hintergrund.
[Abbildung 1: Nodes in einem Datagrid]
###Das passende Cluster für jeweilige Kundenbedürfnisse Welche Art von Cluster nun für einen Anwender in Frage kommt, hängt natürlich von mehreren Faktoren ab. Falls man keine Kontrolle auf die Anwendungsarchitektur hat, als Benutzer von SAP oder Microsoft Dynamics etwa, bleibt einen in der Regel nur der Weg über ein Cluster, welches für die Anwendung transparent arbeitet, oder die Möglichkeit, den Hersteller nach Clusterfähigkeit zu fragen. Für erweiterte Möglichkeiten im Bereich Session Replikation oder verteiltes Rechnen (Datagrid), bedarf es Software, die auf solche Szenarien vorbereitet ist oder vorbereitet werden kann. LOGENTIS implementiert diese Fähigkeiten in alle seine Logistikprodukte, sodass sie schon ab Werk "Cluster-Ready" sind.
