Generic selectors
Exact matches only
Search in title
Search in content

Atlassian Data Center

14.03.2017 / 0 Comments

Übersicht

    1.Allgemeine Informationen über das Data Center

    Was bietet das Data Center?

    Ein Data Center bietet den Komfort und den Funktionsempfang der normalen Server-Version der Atlassian Applikationen und erweitert diesen.
So ermöglicht der Einsatz von mehreren Nodes eine Erhöhung der Verfügbarkeit ihres Systems, sowie eine höhere Leistung für jeden Benutzer.
    
Außerdem ist es innerhalb eines Data Centers sehr einfach weitere Nodes hinzuzufügen und so bietet das Data Center eine sehr gute Skalierbarkeit.

    Ist das Data Center sicher vor einem Ausfall?

    Durch die Replikation aller Informationen über alle Nodes, ist auch beim Ausfall eines oder mehrerer Nodes, die Verfügbarkeit des Systems weiter gesichert. Ausschließlich der Ausfall aller Nodes könnte zum Ausfall des gesamten Systems führen. Solange also der Ausfall aller Nodes nahezu ausgeschlossen ist, so ist auch das gesamte System vor dem Ausfall geschützt.

    Was ist ein Node

    Ein Node innerhalb eines Data Centers ist eine Instanz von JIRA/ Confluence auf einem Server. Im Normalfall ist nur eine Instanz auf einem Server installiert und somit ist der Node gleichbedeutend mit einem Server.
Durch die Verteilung des Systems auf mehrere Server wird die Verfügbarkeit erhöht und das Hinzufügen neuer Server ermöglicht eine einfache Skalierbarkeit.

    Wo befindet sich im Data Center die Benutzerverwaltung?

    Die Benutzerverwaltung innerhalb des Data Centers funktioniert genau wie bei der normalen Server Version. So ist es auch im Data Center möglich die Benutzerverwaltung über Atlassian Crowd zu regeln oder über Active Directory oder ähnliche Systeme.

    Wie werden die Benutzer auf den passenden Server geleitet

    Die Benutzer des Data Center müssen natürlich nicht die Adressen der einzelnen Nodes kennen, sondern werden durch einen Load Balancer automatisch auf den Nodes verteilt.
Der Load Balancer hat seine eigene Adresse. So wäre es zum Beispiel möglich Ihr Data Center über die Adresse www.mein-data-center.com verfügbar zu machen.
 Hier greift dann der Load-Balancer ein und leitet den Benutzer, ohne dass dieser dies mitbekommt, auf einen der Nodes, mit einer anderen Adresse, um.
Sollte der Node nun während der Arbeit ausfallen, so wird der Benutzer einfach an einen neuen Node weitergeleitet und kann seine Arbeit fortsetzen, als wäre der Node immer noch im Einsatz.

    Was ist der Load Balancer und ist er im Data Center integriert?

    Der Load Balancer fängt die Abfragen der Nutzer ab und verteilt sie auf die Nodes innerhalb des Data Centers. Hierdurch entsteht für den Nutzer der Eindruck er nutzt immer denselben Server und auch bei einem Ausfall eines Nodes, bleibt das System für den Nutzer ohne Einschränkung nutzbar.
Der Load Balancer ist nicht im Data Center integriert, sondern muss separat installiert und konfiguriert werden. Eine Möglichkeit, um einen Load Balancer zu erstellen bietet Apache httpd. Aber auch andere Load Balancer sind nutzbar. Durch die große Auswahl an Balancern und deren Konfigurationsmöglichkeiten, können Sie das System so gestalten wie Sie wollen. So wäre zum Beispiel auch denkbar, dass einige Nodes als Standard-Nodes agieren und andere nur als Notfall-Nodes, falls andere ausfallen oder eine Überlastung auftritt.

    Welche Anforderungen muss der Load Balancer erfüllen und was sind sticky-sessions?

    Die wichtigste Anforderung an den Load Balancer ist, dass er sticky-sessions unterstützt. Sticky-sessions dienen dazu, dass jedem Benutzer nur eine Session zugeteilt wird und während dieser nur auf einem Server gearbeitet wird. Das heißt jede Anfrage an das Data Center wird vom Load Balancer an denselben Node weitergeleitet welcher eine Session für den Benutzer speichert. So muss der Benutzer sich nicht bei jeder Anfrage neu einloggen, sondern arbeitet im Data Center als würde er direkt auf einen der Nodes zugreifen. Nur in dem Fall, dass der Node ausfällt, wird eine neue Session gestartet und der Benutzer nutzt dann einen anderen Node.

    2. Wie richte ich ein Jira Data Center ein?

    Um Jira als Data Center einzurichten, sind einige Voraussetzungen zu schaffen.
    Die einzelnen Schritte bei der Einrichtung eines Data Centers sind:

    1. Einrichten eines Standard Jira Servers
    2. Einzelserver zum Data Center umkonfigurieren
    3. Neue Nodes hinzufügen

    Wenn die wichtigsten Feinheiten beachtet werden, so erhält man ein hoch verfügbares, einfach skalierbares Jira-System.

    1. Einrichten eines Standard Jira Servers

    Sollte noch kein System bestehen, so beginnt das Einrichten eines Data Centers damit, eine Server-Version von Jira zu installieren und zu konfigurieren.
    Damit die Installation später zu einem Data Center erweitert werden kann, ist es wichtig eine passende Datenbank für die Daten einzurichten. Die integrierte H2-Datenbank ist nicht für die Nutzung in einem Data Center geeignet.
    Der entsprechende Datenbank-Server muss von allen späteren Nodes des Data Center erreichbar sein.

    2. Einzelserver zum Data Center umkonfigurieren

    Nach der erfolgreichen Konfiguration des Jira-Servers, ist es jetzt an der Zeit, das System zu einem Data Center zu erweitern.

    Netzwerk-Ressource freigeben

    Hierfür wird eine Ressource im Netzwerk benötigt, welche von allen Nodes zugänglich ist. Hier wird ein gemeinsamer Home-Ordner angelegt, der die wichtigen Daten für alle Nodes enthält und die Replikation aller Plug-Ins, etc. ermöglicht.
    Hierfür sind beispielsweise NFS- und SMB- Freigaben geeignet.
    Anschließend wird der Jira-Server heruntergefahren und eine cluster.properties-Datei erstellt.

    Was ist die cluster.properties und wo finde ich sie?

    Die cluster.properties enthält alle wichtigen Informationen für das Jira Data Center, um dessen Nodes zu identifizieren und die Replikation zwischen diesen zu ermöglichen.
    Die Datei befindet sich im lokalen Home-Verzeichnis eines jeden Data Center Nodes, da sie für jeden Node angepasst werden muss.
    Innerhalb dieser Datei werden mindestens zwei Einträge benötigt:

    • jira.node.id

    hier wird der identifizierende Name für den jeweiligen Node angegeben. Z.B.: node1

    • jira.shared.home

    hier muss die Netzwerk-Ressource, die vorher eingerichtet wurde, eingetragen werden. Z.B.: //my-Server/my-home-folder
    Weitere optionale Einträge, die unter Umständen nötig sind, damit die Replikation korrekt funktioniert sind:

    • ehcache.listener.hostName

    hier ist es möglich für die Replikation, die Adresse des Nodes einzutragen, falls diese nicht automatisch aufgelöst werden kann

    • ehcache.peer.discovery

    hier kann die Methode zum Erkennen anderer Nodes geändert werden. Standardmäßig steht diese auf default. Sollte es Probleme beim Finden anderer Nodes kommen, so ist es möglich hier auf automatic umzuschalten. Dann werden die Nodes per Multicast gesucht und es sind die folgenden weiteren Einträge nötig, um das Multicasting zu konfigurieren

    • ehcache.multicast.address

    hier muss die entsprechende Multicast-Adresse eingetragen werden, die verwendet werden soll, entsprechend der Reichweite des Multicasts. Um das Multicasting auf alles Systeme im Subnetz zu beschränken wäre dies: 224.0.0.1

    • ehcache.multicast.port

    Der Standard-Port ist 40001 und sollte angepasst werden, wenn der Port bereits für andere Dienste genutzt wird oder blockiert wird.

    • ehcache.multicast.timeToLive

    Die Standard-TimeToLive ist 32 und kann je nach Größe des Netzwerks verkleinert oder vergrößert werden, um überflüssigen Traffic zu vermeiden oder alle Nodes erreichen zu können.

    • ehcache.multicast.hostName

    Der Host Name ist erneut die Adresse des Nodes und sollte eingetragen werden, wenn es nicht möglichst diesen automatisch aufzulösen.

    Ist die Datei richtig erstellt, ist es nun möglich den Server erneut zu starten.

    Starten des ersten Nodes

    Es wird nun alles konfiguriert und das gemeinsame Home-Verzeichnis mit allen nötigen Dateien gefüllt.
    Sollte es beim Starten zu Fehlern kommen, so kann man sich diese per Aufruf des Servers über den Browser anzeigen lassen.
    Ein Fehler, der beim ersten Starten als Data Center auftritt, ist der, dass der Server keine Data-Center Lizenz hat, sondern lediglich eine Standard-Server-Lizenz. Es wird direkt die Möglichkeit gegeben, eine Data Center Lizenz einzutragen.
    Darauf muss der Server neu gestartet werden und anschließend sollte der Server als Data Center funktionieren.

    Load Balancer

    Um später weitere Nodes hinzuzufügen und den Traffic auf alle Nodes zu verteilen, ist es nun nötig den Balancer entsprechend zu konfigurieren.
    Ist der Balancer installiert und korrekt konfiguriert, muss nun die Adresse des Balancers in Jira als Basis-URL eingetragen werden, damit das Weiterleiten im Falle des Ausfalls eines Nodes ordnungsgemäß funktioniert

    3. Neue Nodes hinzufügen

    Wenn das Data Center mit einem Node korrekt funktioniert, so ist das Hinzufügen neuer Nodes keine große Schwierigkeit.
    Zuerst empfiehlt es sich die gesamte Jira-Installation auf den neuen Server zu kopieren, also sowohl das Jira-Verzeichnis, als auch das lokale Jira-Home-Verzeichnis. Dadurch wird verhindert, dass die Installationen groß abweichen und das Replizieren zu Beginn deutlich vereinfacht.
    Anpassungen müssen lediglich in der cluster.properties im Home-Verzeichnis vorgenommen werden, da diese den Node identifiziert und die Kommunikation mit den anderen Teilen des Data Centers definiert.
    Hier sind vor allem der Name, sowie die Adressen des Nodes anzupassen. Sollte der Pfad zu der gemeinsamen Netzwerk-Ressource abweichen ist auch dieser anzupassen.
    Ansonsten kann der neue Node danach gestartet werden und bei erfolgreichem Start zum Balancer hinzugefügt werden.

    Ab jetzt verteilt der Balancer alle Nutzer auf die verschiedenen Nodes und erhöht somit die Leistung, sowie die Verfügbarkeit des Systems. Jede Änderung auf einem der Nodes wird automatisch auf alle anderen Nodes repliziert.
    So werden auch installierte Plug-Ins sofort auf alle Nodes kopiert und sind für alle Jira-Nutzer nutzbar.
    Sollte es zu größeren Problemen mit dem Data Center kommen, so sind diese meistens im Balancer begründet. Insbesondere die sticky-sessions führen zu größeren Problemen, vor allem beim Login.
So ist es bei falsch konfigurierten sticky-sessions teilweise nicht möglich, sich in Jira anzumelden, da durch die fehlenden Informationen aus der Session der Login nicht durchgeführt werden kann.

    3. Was ist Synchrony und wofür ist es zuständig?

    Synchrony ist eine Software von Atlassian, die mit Confluence zusammenarbeitet. Sie ermöglicht das gemeinschaftliche Bearbeitung von Dokumenten. Änderungen werden über Synchrony, direkt an alle verbundenen Benutzer weitergeleitet und Änderungen von mehreren Benutzer gleichzeitig verarbeitet, so dass alle Änderungen für alle Benutzer in Echtzeit sichtbar sind.
    Einschränkungen gibt es hier allerdings in der Nachverfolgbarkeit von Änderungen und der Versionskontrolle.
So ist es nicht möglich die einzelnen Änderungen den jeweiligen Benutzern zuzuordnen und es wird lediglich derjenige als Nutzer gespeichert, der das Dokument am Ende speichert. Genauso ist es nicht möglich eine Version innerhalb des Änderungsprozesses wiederherzustellen, sondern nur die veröffentlichten Versionen können noch einmal wiederhergestellt werden.
    Synchrony kann ebenfalls als Cluster eingerichtet werden, um die Erreichbarkeit der Funktion sicher zu stellen. So ist es möglich auf jedem Confluence-Node auch einen Synchrony-Node einzurichten.

    4. Wie richte ich ein Confluence Data Center ein?

    Um Confluence als Data Center einzurichten, sind einige Schritte nötig.
    Die einzelnen Schritte zur Einrichtung sind:

    1. Einrichten des ersten Nodes.
    2. Optional: Einrichten von Synchrony
    3. Hinzufügen weiterer Nodes

    Wenn alle wichtigen Einrichtungen vorgenommen sind, erhält man ein hoch performantes und erreichbares Confluence-System.

    1. Einrichten des ersten Nodes

    Die Einrichtung des Confluence Data Centers beginnt auf dem ersten Server. Hier wird eine Confluence Installation durchgeführt. Der erste Unterschied zur Installation eines Einzel-Servers besteht in der Einrichtung. Bei der Abfrage der Lizenz wird eine Data Center Lizenz eingegeben.
Diese wird von der Konfiguration als solche erkannt und ein anderer Einrichtungsvorgang beginnt.

    Als erstes wird nach dem gewünschten Namen für den neuen Cluster gefragt.
 Außerdem muss der freigegebene gemeinsame Ordner angegeben werden. Hier werden Daten gespeichert, die für alle Nodes wichtig sind.
Anschließend muss das Interface gewählt werden, über welches der Node mit anderen Nodes im Cluster kommunizieren kann.
Die Einstellung für das Finden neuer Nodes sollte auf Multicast belassen werden, um das Hinzufügen von neuen Nodes zu vereinfachen. Im Falle von TCP/IP müssen alle Nodes angegeben werden, so dass die Einstellung bei jedem neuen Node geändert werden muss.
Die Multicast-Adresse wird automatisch eingerichtet, wenn dies nicht abgewählt wird.
    Im Folgenden ist die Einrichtung dieselbe wie bei einem Einzel-Server. 
Es muss also die Datenbank eingerichtet werden und es ist möglich Daten aus einem Backup zu importieren oder eine neu Seite zu erstellen. Außerdem kann man entscheiden, ob die Benutzer in Confluence oder über ein Jira-System verwaltet werden sollen.
    Abschließend muss noch ein Administrator-Konto erstellt werden und dann ist die Konfiguration abgeschlossen.

    2. Optional: Einrichten von Synchrony

    Synchrony bietet die Möglichkeit mit mehreren Nutzern Dateien in Echtzeit zu bearbeiten.
Es handelt sich um eine eigene Software, welche ebenfalls in einem Cluster angelegt werden kann, um die Erreichbarkeit des Dienstes zu sichern.
Synchrony wird mit Confluence zusammen geliefert und kann ohne weitere Voraussetzungen installiert werden.
    Hierfür befindet sich im lokalen Home-Ordner von Confluence die Datei synchrony-standalone.jar . Diese muss an einen Ort kopiert werden, von dem aus sie gestartet werden soll. Außerdem muss der Treiber für die genutzte Datenbank aus dem Ordner Confluence -> WEB-INF -> lib im Installationsverzeichnis von Confluence in diesen Ordner kopiert werden.
    Anschließend kann Synchrony mit einem Startkommando mit allen Parametern gestartet werden.
Da sehr viele Parameter nötig sind, kann man den Start auch durch eine Batch-/Script-Datei einrichten.
    Im Folgenden werden alle Parameter und deren Bedeutung erklärt, die nötig sind, um Synchrony zu starten. Nicht beschriebene Parameter sollen auf Standardwerten belassen werden.

    java 
    -Xss2048k 
    -Xmx2g 
    #Classpath muss die standalone.jar , sowie den Treiber enthalten z.B: 
- classpath c:/Synchrony/synchrony-standalone.jar;c:/Synchrony/postgresql-9.4.1212.jar
    -Dsynchrony.cluster.impl=hazelcast-btf 
    #Port über den Synchrony erreichbar sein soll (Standardwert: 8091)
-Dsynchrony.port= 
    #Port über den Hazelcast kommunizieren soll (Standardwert: 5701)
-Dcluster.listen.port=
    #Port über den der Node mit anderen Nodes kommunizieren soll (Standardwert: 25500)
-Dsynchrony.cluster.base.port=
     
    # Wenn TCP/IP verwendet werden soll, um andere Nodes zu finden, werden diese Parameter benötigt
-Dcluster.join.type=tcpip 
    # Liste der Nodes, die über TCP/IP kommunizieren sollen
-Dcluster.join.tcpip.members= 
     
    # Wenn Multicast verwendet werden soll, um andere Nodes zu finden, werden diese Parameter benötigt
-Dcluster.join.type=multicast
    # Multicast-Adresse, die zur Kommunikation verwendet werden soll (z.B.: 224.0.0.1)
-Dcluster.join.multicast.group= 
    -Dcluster.join.multicast.port=54327 
    -Dcluster.join.multicast.ttl=32 
     
    
    -Dsynchrony.context.path=/synchrony 
    #  3 mal IP/Hostname des Knoten der eingerichtet werden soll
-Dsynchrony.cluster.bind= 
    -Dsynchrony.bind= 
    -Dcluster.interfaces=
    
    # IP/Hostname des Load-Balancers für Synchrony
    -Dsynchrony.service.url= 
    # Schlüssel, die von Confluence erstellt werden und für alle Nodes gleich sind. Diese sind in der confluence.cfg.xml (s.u.) zu finden
    -Djwt.private.key= 
    -Djwt.public.key=
    # Die URL der genutzten Datebank z.B.: jdbc:postgresql://mydbserver.com:5432/confluencedb
    -Dsynchrony.database.url= 
    # Benutzername und Passwort die für den Zugriff auf die Datenbank konfiguriert wurden
    -Dsynchrony.database.username= 
    -Dsynchrony.database.password=  
    
    # Alle folgenden Parameter können unverändert bleiben, müssen aber angegeben werden
    -Dip.whitelist=127.0.0.1,localhost
    -Dauth.tokens=dummy 
    -Dopenid.return.uri=http://example.com 
    -Ddynamo.events.table.name=5 
    -Ddynamo.snapshots.table.name=5
    -Ddynamo.secrets.table.name=5 
    -Ddynamo.limits.table.name=5 
    -Ddynamo.events.app.read.provisioned.default=5 
    -Ddynamo.events.app.write.provisioned.default=5 
    -Ddynamo.snapshots.app.read.provisioned.default=5 
    -Ddynamo.snapshots.app.write.provisioned.default=5 
    -Ddynamo.max.item.size=5 
    -Ds3.synchrony.bucket.name=5 
    -Ds3.synchrony.bucket.path=5 
    -Ds3.synchrony.eviction.bucket.name=5 
    -Ds3.synchrony.eviction.bucket.path=5 
    -Ds3.app.write.provisioned.default=100
    -Ds3.app.read.provisioned.default=100
    -Dstatsd.host=localhost 
    -Dstatsd.port=8125 
    synchrony.core 
    sql
    

    Um Synchrony zu starten, müssen alle Kommentare und Zeilenumbrüche entfernt werden, damit ein einziger Aufruf mit allen Parametern entsteht.
    Wenn der Start funktioniert hat, so kann nun Confluence so eingerichtet werden, dass Synchrony genutzt wird.
    Hierfür muss Confluence einen Parameter bekommen, welcher die Adresse des Synchrony Clusters enthält. Dieser kann am besten in die setenv.bat/setenv.sh hinzugefügt werden, welche im bin -Verzeichnis im Installationsverzeichnis von Confluence zu finden ist.
    Hier sollte unterhalb des Bereichs der Zeilen, welche mit set CATALINA_OPTS beginnen, eine neue Zeile hinzugefügt werden:

    java 
    
    set CATALINA_OPTS=-Dsynchrony.service.url=/synchrony/v1 %CATALINA_OPTS% 

    Anschließend kann der Confluence-Node neu gestartet und mit einem Administrator-Benutzer die Funktion getestet werden.
 Hierfür befindet sich unter Allgemeine Konfiguration eine Option Gemeinschaftliche Bearbeitung.
    Hier ist es möglich, diese einzuschalten und im Anschluss ist darunter ersichtlich, ob Synchrony richtig konfiguriert ist.

    3. Hinzufügen weiterer Nodes

    Um nun neue Nodes zum System hinzuzufügen, wird der Installationsordner, sowie der lokale Home-Ordner kopiert und auf dem neuen Server eingefügt.
Nun müssen Anpassungen vorgenommen werden, um die Kopie funktionstüchtig zu machen.

    • confluence.cfg.xml

    
Als erstes ist hier die confluence.cfg.xml im Home-Ordner von Confluence anzupassen.
Hier sind vor allem die Einträge confluence.cluster.home , confluence.cluster.interface und hibernate.connection.url anzupassen.

    • confluence.cluster.home

    
Hier ist der gemeinsame freigegebene Home-Ordner angegeben. Je nach Konfiguration kann es nötig sein, diesen auf dem neuen Server anzupassen.

    • confluence.cluster.interface


    Hier ist das gewählte Interface zur Kommunikation innerhalb des Cluster anzugeben. In den meisten Fällen ist dies von Server zu Server unterschiedlich und muss entsprechend angepasst werden.
Hierzu bietet Atlassian eine Java-Datei an, welche alle vorhandenen Interfaces auflistet und ihre Bezeichnung angibt.
Diese ist hier zu finden.
    
In der Kommandozeile/Terminal kann die Datei mit dem Kommando „java -jar Listinterfaces-v2.jar“ ausgeführt werden.

    • Hibernate.connection.url

    
Dies ist URL der Datenbank. Je nach Konfiguration des Clusters ist auch hier eine Anpassung der Adresse nötig.

    • Load Balancer


    Anschließend muss der neue Node zum Load Balancer hinzugefügt werden. Je nach Load Balancer ist das Vorgehen unterschiedlich. Die Adresse des Balancers ist später als Basis-URL in Confluence einzutragen, um die volle Funktion des Data Centers zu ermöglichen.



    Start der Nodes


    Jetzt ist es möglich die einzelnen Nodes zu starten. Hier wird von Atlassian darauf hingewiesen, dass der Start der Nodes nacheinander erfolgen soll und der nächste Node erst gestartet werden soll, wenn der vorige Node über den Load Balancer erreichbar ist.
    Zum Testen der Funktion des Clusters, empfiehlt es sich über einen Node eine neue Seite zu erstellen. Danach sollte über einen anderen Node geprüft werden, ob die neu erstellte Seite über diesen anderen Node erreichbar und editierbar ist.
    Eine Übersicht über die Nodes des Clusters ist unter den Einstellungen für den Administrator zu finden. Unter Allgemeine Konfiguration -> Clustering werden alle Knoten und deren Auslastung angezeigt.

    5. Bleibt der Single Sign On auch im Data Center möglich?

    Auch am Single Sign On ändert sich nichts. Dieser ist genau wie vorher konfigurierbar.
Der Time-Out für die Login-Sessions ist auf jedem Node einzeln konfigurierbar. So ist es möglich auf einem Node ein sehr kurzes Time-Out festzulegen, um anschließend einen anderen Node für das Wiederanmelden zu nutzen, aber auch gleiche Time-Out Zeiten sind realisierbar.

    6. Wie nutze ich 2FA mit SecSign in einem Data Center

    Das SecSign- Plugin ist voll kompatibel mit den Data Center Versionen von Jira und Confluence.
    Die einzige Bedingung ist also die Installation des Plugins. Hierfür benötigen Sie Admin-Rechte. 
Dann ist es möglich das Plugin über den Plugin-Manager im Marktplatz zu suchen und zu installieren. In einem Data Center werden Plugins automatisch auf alle Nodes repliziert, so dass die 2FA direkt auf allen Servern nutzbar ist. Auch alle SecSign IDs werden automatisch auf allen Nodes repliziert, so dass kein weiterer Aufwand nötig ist.
    Der SecSign Login nutzt dieselben Session-Time-Outs wie auch die normale Atlassian-Anmeldung, so dass diese gleichfalls je Node konfigurierbar sind. (s.o)

    SecSign 2FA