Untergeordnete Seiten
  • Jira-Failover-Guide - Hochverfuegbarkeit von Atlassian-Produkten
Zum Ende der Metadaten springen
Zum Anfang der Metadaten

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:

Failover-Option

Status der Standby-Instanz

Gespiegelte Daten

Manuell/automatisch

Weitere Infos

Jira-Unterstützung?

Automatische Reparatur / Neustart

N/A

N/A

Automatisch

  • Kein sekundäres System läuft
  • Nach einem Ausfall des Produktivsystems wird ein Neustart automatisch via Script eingeleitet

(Haken)

"Kalter" Standby

Replizierte Jira-Standby-Instanz, die nicht läuft

Ja

Manuell oder automatisch

  • Daten zwischen zwei Dateisystemen und zwei Datenbanken repliziert
  • Zweite Jira-Instanz nicht gestartet
  • Nach Versagen des Primärsystems wird die der Start der Standby-Instanz manuell oder automatisch initiiert
  • Hardware- und OS-Redundanzen erforderlich

(Haken)

Active-Passive / “Warmer” oder “heißer” Standby

Replizierte Jira-Instanz, die läuft

Ja

Manuell oder automatisch

  • Daten zwischen zwei Dateisystemen und zwei Datenbanken repliziert
  • Zweite Jira-Instanz läuft
  • Manuelles Umschalten: Konfigurationsänderungen automatisch, aber manuelle Bestätigung / Ausführung erforderlich.
  • Automatische Failover-Reaktion: Standby-System wird bei Ausfall automatisch zur Primärinstanz

(Minus)

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

Diagramm coming soon

Komponente

Beschreibung

Nutzer

Endnutzer mit Nugriff auf die Jira-Dienste

WAN

Das Wide Area Network, über das auf Ihre Systeme zugegriffen wird

Reverse Proxy Jira 1 & 2

Leitet den Nutzerstrom zur richtigen Jira-Instanz und von dort zur richtigen Datenbank, läuft redundant im HA-Modus

Jira 1

Das Haupt- und Produktivsystem von Jira

Jira 2

Abgeschaltete (kalte) Standby-Jira-Instanz

Datenbank 1

Die produktive Jira-Datenbank

Datenbank 2

Die Standby-Datenbank, die mit der Produktivinstanz repliziert wird

Monitoring-Dienst

Dienst, der die Komponentenn überwacht und Benachrichtigungen und Failover-Mechanismen anstößt

Failover-Mechanismus

Ereignisbasierte Mechanismen, über die beteiligte Mitarbeiter benachrichtigt werden, Konfigurationsänderungen an den Reverse Proxies oder Replizierungsdienste, Herunterfahren, Schließen und Neustarten von Diensten

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.

Abstraktionsschicht

Asynchron / Synchron

Beschreibung

Dateiblockebene

Synchron

Sogenannte Atomic Transactions, die einen Nulldatenverlust durch einen "Write-both-or-none-Ansatz" sicherstellen. Jede Schreiben-Operation wartet auf eine erfolgreiche Bestätigung des Replizierungssystems. Netzwerkgeschwindigkeit und Wartezeiten zwischen synchronisierten Knoten beeinflussen die Performance der Applikation stark. Auch das Fehlschlagen der Replizierung oder Netzwerkverbindungsprobleme können sich in diesem Szenario stark auf die Produktivinstanz auswirken. Aufgrund dessen ist die synchrone Replizierung eine selten genutzte Methode.

Dateiblockebene

Asynchron

Durch das asynchrone Schreiben von Daten im Replizierungssystem muss die Master-Instanz nicht auf positive Bestätigungen warten und die Anwendung kann kontinuierlich laufen. Diese Methode verbessert die Performance, bietet aber keine Garantie für einen Nulldatenverlust.

Dateiblockebene

Hybrid

Semisynchrone Methoden senken die Risiken von Replizierungsausfällen, indem das Standby-System positive Rückmeldung auf Schreiben-Anweisungen gibt (z.B. als Log-Files oder im Cache-Speicher). Die Master-Instanz muss allerdings nicht auf eine erfolgreiche Schreiben-Bestätigung des Replizierungssystems warten, wodurch sich die Performance verbessert. Bei der Point-in-time-Replizierung basiert die Synchronisierung jedoch eher auf Schnappschüssen als auf dem tatsächlichen Dateisystem und erlaubt eine intervallbasierte Methode. Diese Methode ist eher populär, wenn nur langsame Netzwerkverbindungen verfügbar sind oder die Kosteneffektivität ein wichtiges Kriterium ist.

Kernel Driver

Synchron/asynchron

Wie ein Virusscanner interpretiert ein Replication Device Driver Dateioperationen (CRUD) und imitiert sie in der Remote-Instanz.

Journal-Replizierung

Asynchron

Replizierung eines Dateisystems durch das Teilen seines Journals mit Remote-Maschinen, die dessen Events nachspielen. Kann periodisch oder in Echtzeit verfolgen.

Batch replication

Asynchron

Sychronisation eine Zieldateisystems durch den periodischen Vergleich mit dem Quellsystem. Dies ist ein eher reaktiver und systemintensiver Replizierungsansatz.

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:

Verzeichnis

Inhalte

Jira-Installationsverzeichnis

  • Single-sign-on-Konfiguration (seraph.xml)
  • Plugins

Jira-HOME-Verzeichnis

  • Datenbank-Konfigurationsdatei
  • Lucene-Suchindex
  • Anhänge
  • Plugins und entsprechende Konfigurationsdateien
  • Einige Avatare / Logos

Über Plugins

Im Falle installierter Plugins wird empfohlen, mit den Plugin-Anbietern abzustimmen, ob diese HA-Szenarien unterstützt werden. Jira-Erweiterungen bieten sehr viele Freiheiten dahingehend, wohin die Daten geschrieben werden sollen. Es könnte Szenarien geben, in denen ein Plugin externe Server oder andere Verzeichnisse nutzen als ihr sogenannter Persistence Layer. Diese Systeme würde ebenfalls redundant / repliziert. In jedem Fall sollten Sie beim entsprechenden Plugin-Anbieter die spezifischen HA-Anforderungen erfragen. Atlassian empfiehlt es als Best Practice, wenn Plugins entweder in Active Objects oder ins Jira-HOME-Verzeichnis schreiben.

Lassen Sie die Standby-Instanz heruntergefahren

Stellen Sie sicher, dass die Standby-Instanz heruntergefahren bleibt. Wird sie hochgefahren, während die Produktivinstanz läuft, besteht die Gefahr, dass dies zu inkonsistenten In-Memory-Caches, duplizierten Jira-Notifications (da beide Instanzen auf den Mailserver zugreifen) und Problemen mit anderen integrierten Anwendungen führt, die Anweisungen von beiden Jira-Instanzen erhalten.

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

Datenbank

Replizierung

Automatic Failover

High-Availability-Dokumentation

Monitoring-Dokumentation

Oracle 11G

Synchron / asynchron

Unterstützt

Oracle 11G HA Best Practice Guide

Oracle Database 11g: Real-Time SQL Monitoring

PostgreSQL 8.2 und höher

Synchron / asynchron

Unterstützt

Supported PostgreSQL HA Manual

PostgreSQL: Monitoring Database Activity

Microsoft SQL Server 2005 / 2008

Synchron / asynchron

Unterstützt

MSQL 2005 HA Doc, MSQL 2008 HA Doc

Monitoring SQL 2005 Server health, Monitoring SQL 2008 Server Performance

MySQL 5.x

Semi-synchron / asynchron

Ja, mit Drittanbieter-Software wie DRBD und Heartbeat

MySQL HA Doc

MySQL Enterprise Monitor 2.3.10

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:

Szenario

Ausgefallene Systeme

Failover-Mechanismus

Anwendungsausfall

Jira 1

Wechsel / Failover zu Jira 2 und Verbleib bei DB 1

Datenbankausfall

DB 1

Wechsel / Failover zu DB 2, Neustart von Jira 1

Totalausfall

Jira 1 und DB 1

Wechsel / Failover zu Jira 2 und DB 2

Netzwerkausfall

Netzwerk

Netzwerkfehler beheben und keinen Failover durchführen

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!

//SEIBERT/MEDIA ist Atlassian Platinum Solution Partner mit Erfahrung aus Hunderten Atlassian-Projekten. Gerne unterstützen wir Sie mit professionellen und individuellen Lösungen bei der Implementierung und beim Betrieb Ihrer hochverfügbaren Atlassian-Produkte. Sprechen Sie uns an oder füllen Sie schnell das Formular weiter oben in der rechten Spalte aus.