High Availability (HA)

High Availability (HA) (=Hochverfügbarkeit) bedeutet vor allem Verfügbarkeit und Ausfallsicherheit. Darüber hinaus berührt die High Availability noch weitere Aspekte:

Vorbeugende Maßnahmen

• Change Management (inklusive Staging / Produktivinstanzen für Änderungsimplementierungen)
• Netzwerk-, Anwendungs-, Speicher- und Datenbank-Redundanzen schaffen
• System-, Netzwerk- und Anwendungsüberwachung

Reaktive Maßnahmen

• Technische Failover-Mechanismen: Entweder automatisch oder semi-automatisch (Scripte) mit manuellem Umschalten
• Standard-Reaktionsabläufe für Maßnahmen in Krisensituationen

Diese Anleitung setzt voraus, dass Prozesse wie Change-Management abgedeckt sind, und konzentriert sich auf die Themen Redundanz/Replizierung und Failover. Ziel ist es, eine standardisierte und schnelle Datenreplizierung zu beschreiben, wenn es zu System- oder Anwendungsfehlern kommt. Die Anleitung geht zudem davon aus, dass eine klassische Jira-Installation ohne "Schnickschnack" besteht und alle Plugins installiert sind, die in diesem Szenario vorgesehen sind.

Hochverfügbarkeit und Anforderungen

Grundsätzlich hängt die Methode, Hochverfügbarkeit zu erreichen, maßgeblich von Ihren Anforderungen an das System ab:

• Vorgesehene Uptime des Systems über das Kalenderjahr hinweg
• Die Downtime, die Sie während eines Ausfalls akzeptieren können (z.B. die Dauer, die der Start einer synchronisierten, aber "kalten" Standby-Instanz erfordert)
• Die Kosten, die Sie in Kauf nehmen, da das Schaffen von Redundanzen mit Investitionen in zusätzliche Hardware, Software und Infrastruktur verbunden ist

Erfahrungsgemäß sehen viele Nutzer von Atlassian-Produkten, Atlassian Experts und Atlassians Jira-Teams selbst das "kalte" Umschalten als beste verfügbare Methode an.

Jira läuft also in Kombination mit Reverse Proxies und Standby-Instanzen des Jira-Anwendungsservers und der Datenbank. Kommt es zum Ausfall, versucht ein Failover-Mechanismus zunächst, diesen zu beheben (automatische Fehlerbehebung). Ist dies nicht erfolgreich, wird der Start einer Standby-Instanz entweder manuell oder automatisch in die Wege geleitet. Diese Option ist im Kontext mit weiteren Szenarien zu betrachten:

Automatische Fehlerbehebung

Bevor Sie Failover-Lösungen für Ihre Jira-Instanz implementieren, sollten Sie automatische Fehlerbehebungsmaßnahmen evaluieren und vorantreiben. Dazu empfiehlt sich die Implementierung eines Monitoring-Dienstes, der die Anwendung beobachtet und Scripte zum Starten, Herunterfahren, Abbrechen und Neustarten von Diensten ausführt.

• Der Monitoring-Dienst stellt fest, dass das System ausgefallen ist.
• Das Fehlerbehebungs-Script versucht, das System herunterzufahren.
  • Geschieht dies nicht innerhalb eines festgelegten Zeitraums, bricht das Script den Prozess ab.
• Sobald bestätigt wird, dass der Prozess nicht mehr läuft, wird er nochmals gestartet.
• Ist der Neustart erfolgreich, endet der Mechanismus.
  • Ist die Fehlerbehebung nicht oder nur teilweise erfolgreich, wird ein Failover-Mechanimus angestoßen, sofern einer implementiert ist.

Cold-Standby-Szenarien

Für jeden Schritt in der Kette der HA-Maßnahmen gibt es verschiedene Alternativen der Implementierung. Dies sind einige Beispiele und Optionen für jeden Schritt:

• System-Setup
  • Datei-Replizierung
  • Datenbank-Replizierung
  • Netzwerkredundanzen
  • Monitoring
  • Reverse Proxys

• Maßnahmen bei Ausfall
  • Automatische Fehlerbehebung
  • Maßnahmen während des Ausfalls
  • Maßnahmen nach dem Ausfall

System-Setup

Datei-Replizierung

Um die beiden Jira-Instanzen zu synchronisieren, müssen spezifische anwendungsrelevante Verzeichnisse synchron gehalten werden. In Abhängigkeit von der Betriebsnotwendigkeit von Jira und Ihrer IT-Infrastruktur haben Sie diese Optionen im Hinblick auf Replizierungsmethoden: synchron oder asynchron, Dateiblockebene, Kernel-Driver, Dateiebene oder Batch-Replizierung.

Wenn Sie sich für einen Dateireplizierungsmanager entschieden haben, können Sie der folgenden Tabelle entnehmen, welche Jira-Dateien und -Ordner repliziert werden müssen:

Datenbankreplizierung

Alle Datenbanken, die von Jira unterstützt werden, bieten Replizierungsfunktionalitäten, die die Etablierung einer Master/Slave-Replizierung oder auch Clustering erlauben. Datenbanken wie PostgreSQL, Microsoft SQL Server and Oracle unterstützen synchrone Replizierung – einige haben sogar eigene Failover-Mechanismen. Nachfolgend finden Sie eine Übersicht der von Jira unterstützten Datenbanken und der Replizierungs- und Clustering-Optionen. (Die Links auf die Dokumentationen folgen in Kürze.)

Netzwerkredundanz

Um Hochverfügbarkeit zu erreichen, müssen nicht nur Server, Anwendung und Datenbanken redundant gemacht werden, sondern auch die Netzwerkinfrastruktur dazwischen. Vor allem Netzwerkausfälle, während derer Anwendungen nach wie vor laufen und parallel Master-Rollen einnehmen, können zu unschönen Problemen wie Split-Brain-Situationen führen. Daher ist es empfehlenswert, das Risiko von Netzwerkausfällen wie folgt zu minimieren:

• Nutzung von LACP, um redundante Netzwerkpfade zwischen allen Objekten zu implementieren.
• Duplizierung der Firewalls und Load Balancer und Konfiguration als High-Availability-Paare

Monitoring

Der Erfolg aller Sicherheitsmaßnahmen ist immer abhängig von der Qualität des Monitorings Ihrer Systeme. Ein Enterprise-Level-System-Monitoring versetzt Sie in die Lage,

• sich ein klares Bild vom Status der Systemkomponenten zu verschaffen.
• Probleme durch frühe Warnungen im Voraus zu antizipieren.
• sofort über Ausfälle, ihre Art und ihr Ausmaß informiert zu werden. (Beispielsweise sollte Ihr Monitoring-Dienst in der Lage sein, zwischen Netzwerkausfällen und Anwendungsausfällen zu differenzieren.)

Um hinlängliches Wissen über die Gesundheit Ihres Systems zu erhalten, ist es ratsam, die Jira-Instanzen, die entsprechenden Datenbanken, die Hardware und das Computernetzwerk zu überwachen. Jira basiert auf Industriestandard-Open-Source-Komponenten wie Tomcast als Anwendungsserver, Standarddatenbanken und sowie Standard-Computernetzwerken und -Hardware.

Implementieren Sie die Monitoring-Maßnahmen für CPU-, Laufwerks-, Netzwerk-Gesundheit usw., die Sie für jede andere Unternehmensanwendung auch durchführen würden. Auf der Anwendungsebene von Jira können Sie sich zudem die REST-API zunutze machen und Sample-Operationen durchspielen. Darüber hinaus ermöglicht das JavaMelody Monitoring Plugin die Integration der Open-Source-Java2EE-Applikation von JavaMelody.

Reverse Proxy

Dieser Dienst sitzt zwischen dem Anwendungsserver, den Nutzern und auch zwischen Jira und der Datenbank selbst. Er erzwingt den Failover-Mechanismus durch das Routen eingehenden und ausgehenden Traffics auf Basis der Richtlinien. Dabei agiert der Reverse Proxy als sog. Single Point of Contact z.B. zwischen den Nutzern und dem Jira-Server.

Wenn ein Jira-Server ausfällt, leitet der Reverse Proxy den Traffic einfach auf die Standby-Instanz um (nachdem sie hochgefahren wurde), während die Nutzer Jira weiterhin unter der gewohnten URL erreichen. Da alle Komponenten, die mit dem Reverse proxy verbunden sind, von seinen Funktionen abhängen, müssen diese Komponenten ebenfalls im High-Availability-Modus laufen, um einen sog. Single Point of total Failure auszuschließen.

Load Balancer: Ein Load Balancer, der normalerweise in komplexeren Cluster-Umgebungen zum Einsatz kommt, kann als Alternative zu einem Reverse Proxy genutzt werden. Ist der Pfad gewählt, müssen Richtlinien aufgesetzt und in Form einer 100/0-Matrix abgebildet werden. Das bedeutet, dass 100% des Traffics an eine Maschine gesendet werden und 0% an die Standby-Instanz.

Tools für Reverse Proxies und Load Balancer sind in HAproxy, Keepalived, LVS, LinuxHA oder zahlreichen kommerziellen Anwendungen enthalten.

Failover-Mechanismen

Der Failover-Mechanismus setzt ein, wenn ein Systemausfall festgestellt werden konnte und entschärft werden muss. Hier wird unterschieden zwischen automatischen Maßnahmen zur Behebung des Ausfalls und dem Wechsel auf ein Standby-System, wenn diese Versuche erfolglos waren. Entscheidend beim Aufsetzen eines Failover-Mechanismus ist der gewünschte Grad an Automatisierung.

Die meisten Kunden bevorzugen hier manuelle Entscheidungsschritte. Es ist aber möglich, für den Fall, dass die Uptime maximiert werden soll, einen automatischen Failover-Mechanismus zu implementieren. Abhängig von der Art des Ausfalls, fokussieren sich Failover-Mechanismen auf Anwendungs- und Datenbankausfälle:

Der Mechanismus kann über ein Failover-Tools oder ein angepasstes Script implementiert werden. In jedem Fall werden die folgenden Schritte empfohlen:

• Der Monitoring-Dienst stellt fest, dass ein oder mehrere Systeme ausgefallen sind. Automatische Behebung war nicht erfolgreich.
• Sind die Instanzen nach wie vor nicht erreichbar, fahren Sie so fort:
  • Manueller Wechsel: Der Failover-Mechanismus enthält gescriptete Routinen zum Wechsel auf das Standby-System. Dennoch liegt es in der Hand des Systemadministrators, ob die Systeme repariert oder ob diese Scripte ausgeführt werden sollen.
  • Automatischer Failover: Der Mechanismus routet den Traffic zur Standby-Instanz.
    • Im Fall eines Anwendungsausfalls:
      • Sich versichern, dass das System nicht läuft. System schließen oder – sofern das nicht möglich ist – alle Prozesse abbrechen, um zwei parallel laufende Jira-Anwendungen zu vermeiden
      • Replizierungsdienste für das Dateisystem ausschalten
      • Standby-Instanz starten
      • Vergewissern, dass die Standby-Instanz korrekt läuft und den Traffic ordnungsgemäß routet
    • Im Fall eines Datenbankausfalls:
      • Replizierungsdienste für die Datenbank abschalten
      • Vergewissern, dass die Standby-Instanz korrekt läuft und den Traffic ordnungsgemäß routet
      • Traffic zur DB 2 routen
    • Im Falle eines Totalausfalls:
      • Schritte wie beim Datenbankausfall durchführen
      • Schritte wie beim Anwendungsausfall durchführen
• Post-Failover-Maßnahmen durchführen

Post-Failover-Maßnahmen

Nach dem Failover sollten unbedingt einige Checks durchgeführt werden, wenn möglich, automatisiert.

• Rollenumkehr: Ändern der Replizierungsrichtung für das Dateisystem und die Datenbank und Start des Replizierungsdienstes
  Services
• Suchindex: Test des Zustands des Lucene-Suchindex’. Dies kann automatisch mit der Lucene CheckIndex API durchgeführt werden. Ist der Suchindex gesund, können die User direkt zu dieser Instanz geroutet werden, um die Produkiv-Downtime auf ein Minimum zu beschränken. Ist der Suchindex inkonsistent, kann manuell eine Re-Indizierung der Suche vorgenommen oder diese Aufgabe mit einem Curl Script automatisch ausgeführt werden. Eine solche Inkonsistenz betrifft nur einen kleinen Teil der Vorgänge, leider aber exakt jene, an denen unmittelbar vor dem Crash Nutzer gearbeitet haben. Hier muss eine Wahl zwischen Verfügbarkeit und
  Exaktheit bzw. Vollständigkeit getroffen werden.
• Datenbankintegrität: Der Integrety Checker sollte manuell gestartet werden, um alle Datenbankinkonsistenzen zu identifizieren. Wenn Datenkonsistenz der entscheidende Faktor ist, kann eine automatische Re-Indizierung der Datenbank automatisch per Voreinstellung gestartet werden. (Das führt allerdings zu zusätzlicher Downtime.)

Selbst wenn Dateisystem, Suchindex und Datenbak synchronisiert und in der Standby-Instanz up to date sind, könnte es beim Wechsel auf das Standby-System potenziell zu Datenverlusten kommen. Im Wesentlichen sind alle Informationen in einem flüchtigen Speicher im Anwendungsserver gespeichert, in der Regel im Arbeitsspeicher der Maschine. Dazu gehören:

• User-Login-Status: Nach dem Failover müssten sich die Nutzer wieder einloggen. Um dies abzumildern, bietet sich ein SSO-Dienst wie Crowd an.
• Sessions: User-Sitzungen und Informationen zum gegenwärtigen Login-Status oder zu aktuellen Search Views sind verloren.
• Cache: Cached Pages sind verloren und müssen wieder hergestellt werden. Daher erscheint die Standby-Instanz langsam, wenn sie zum ersten Mal gestartet und genutzt wird. Das gibt sich, wenn sich der Cache mit der Zeit füllt.

Arbeiten Sie mit Atlassian Platinum Solution Partnern zusammen!