Zeige mehr…

Jira-Failover-Guide - Hochverfuegbarkeit von Atlassian-Produkten

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

Reaktive Maßnahmen

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:

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

"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

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

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.

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

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:

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,

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:

Post-Failover-Maßnahmen

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

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:

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.

Zeige mehr…
Zeige mehr…