Skalierung und Elastizität

Wenn es darum geht, das Beste aus einer guten Software herauszuholen, befindet man sich an Verbindungstelle zwischen Software-Entwicklung und Betrieb, zwischen Development und Operations, also im DevOps Bereich.

Wir sind der festen Überzeugung, dass die Anforderungen von Kunden bezügliche Effizienz und Flexibilität nur in einem engen Schulterschluss zwischen diesen Disziplinen erfüllt werden können. Insbesondere moderne Cloud-Umgebungen wie AWS bieten ein extrem elastisches Hosting, d.h. es ist möglich, in kürzester Zeit auf gestiegene Leistungsanforderungen zu reagieren und der Software mehr Ressourcen zur Verfügung zu stellen. Umgekehrt können Energie und Kosten gespart werden, wenn in ruhigen Zeiten Ressourcen entzogen werden.

Um diese Elastizität nutzen zu können, muss die Software sehr gut skalieren, d.h. sie muss in der Lage sein, sich an die zur Verfügung stehenden Ressourcen anzupassen bzw. Ressourcenanforderungen passend zu stellen. Dabei soll sie die Last möglichst gleichmäßig auf die Ressourcen verteilen, ohne diese zu überlasten. Bei anstehender Überlastung werden idealerweise Ressourcen dynamisch zur Verfügung gestellt, was natürlich bei On-Premise-Umgebung nicht beliebig zutreffen kann.

Last-Separation

Auch wenn man es sich kaum vorstellen kann, ist es möglich, ein komplettes Schleupen.CS System in einem Rechner zu betreiben. Für produktive Systeme ist dies schon aus Gründen der Ausfallsicherheit unüblich.

Häufig kommt dieses Installation allerdings bei Entwicklungssystemen vor.

Ein wesentlicher Baustein der Skalierungsfähigkeit der Schleupen.CS Plattform ist die Gruppierung gleichartiger Lasten, die wir Deloyment-Rollen nennen. Auf einem Host können einzelne oder mehrere dieser Rollen installiert werden. Dadurch wird es möglich, Last zu separieren. Wir unterscheiden aktuell:

• Interaktive Server
  Diese stellen die UIs für die Anwender zur Verfügung. Anforderung ist hier, dass das Benutzer-Erlebnis flüssig und responsiv sein soll. Aus diesem Grund werden diese Hosts in der Regel nicht bis an Ihre Grenzen ausgelastet. Ein wesentliches Kriterium für die Skalierung ist die Anzahl der Nutzer.
• Dienste Server
  Hier wird schwerpunktmäßig die Workflow-Verarbeitung gehostet, d.h. die Teile der Verarbeitung, die ohne Frontend auskommen. Diese Hosts sollen möglichst nah an ihrer Auslastungsgrenze betrieben werden.
• SQL-Server-System
  Aufgrund der Konzeption relationaler Datenbanksysteme skalieren diese gut vertikal, d.h. das Hinzufügen von mehr oder schnellerem RAM, CPU etc. führt zu einer verbesserten Performance. In horizontaler Richtung (mehrere Hosts für die gleiche DB) trifft das leider nicht zu. Aus diesem Grund ermöglicht es die Plattform im Extremfall jede Instanz eines DB-Schemas, d.h. die Daten eines Landes auf einem Systemstrukturelement in eine eigene DB zu legen. Diese DBs können dann auf verschiedene Hosts verteilt werden.
• Service Bus
  Der Service Bus ist als Teil der Plattform auf allen interaktiven und Dienste-Servern verfügbar und stellt so insbesondere den Zugang zur Service-Registry, dem Broker und dem Message-Bus zur Verfügung.
• Message-Bus
  Der Message-Bus ist der am stärksten beanspruchte Teil des Service-Bus. Je nach Art und Anzahl der Prozesse die auf dem System laufen, werden tausende von Nachrichten innerhalb kürzester Zeit durch den Message Bus verteilt. Dies ist in der Regel kein Problem, dennoch sollten dessen Hosts nur soweit ausgelastet werden, dass eine sichere und performante Nachrichtenübermittlung gewährleistet ist. Es muss unbedingt sichergestellt werden, dass die Nachrichten "im Fluss bleiben" und es nicht zu Staus oder Stockungen kommt, die einen manuellen Eingriff erforderlich machen. Aufgrund der besonderen Bedeutung des Nachrichtentransports für die Funktion des Gesamtsystems, hat die Plattform eine Komponente, die diesen überwacht, den AutoScaler. Dieser drosselt die Nachrichtenverarbeitung wenn eine Überlastung droht und fährt diese wieder hoch, sobald sich die Situation entspannt.
• Reporting-Server
  Erstellen Dokumente aus den Daten des Systems. Es ist besonders problematisch hier eine möglichst gute Auslastung zu erreichen, da Dokumente in Prozessen wie Abrechnungen, häufig ad hoc in großen Mengen entstehen. In ruhigen Zeiten sind diese Host oft so wenig ausgelastet, dass ein Host mehrere Systeme bedienen kann.
• Plattform-Monitoring
  Das Plattform-Monitoring kann auf einem Server oder in einem Cluster betrieben werden.

Skalierung

Diese Deployment-Rollen lassen sich auf verschiedenen Host installieren, zwischen denen dann eine Lastverteilung stattfindet.

In elastischen Cloud-Umgebungen kann das Starten und Stoppen von Hosts lastabhängig / dynamisch erfolgen.

Ausfallsicherheit

Die Verteilung der Last auf verschiedene Hosts steigert auch die Ausfallsicherheit des Systems.
Für das SQL-Server System können die von Microsoft angebotenen Spiegelmechanismen genutzt werden, um dessen Ausfallsicherheit zu erhöhen.

Architektur: Skalierung und Elastizität