Data Center-Upgrade-Leitfaden
Kein Unternehmen gleicht dem anderen und auch deine Migration wird ganz individuell ablaufen. Folge deshalb unserem Schritt-für-Schritt-Leitfaden für eine reibungslose Umstellung von Atlassian Server auf Data Center.
Bewertung
Jedes Unternehmen hat individuelle Bedürfnisse und Anforderungen, deshalb solltest du bei deinem Upgrade bewusste Entscheidungen treffen.
Ermittlung deiner Architektur- und Infrastrukturanforderungen
Hast du dich für Data Center entschieden? Dann solltest du dich über die unterstützte Data Center-Architektur und die Bereitstellungskonfigurationen informieren.
Data Center kann auf zwei verschiedene Arten bereitgestellt werden: geclustert und nicht geclustert. Bei beiden Optionen stehen dir Enterprise-Funktionen zur Verfügung, trotzdem muss bei der Entscheidung einiges bedacht werden. In der folgenden Tabelle werden die Unterschiede zwischen einer nicht geclusterten und einer geclusterten Architektur erläutert:
Nicht geclustert
Infrastrukturanforderungen
Eine nicht geclusterte Architektur ermöglicht dir das Upgrade auf Data Center in deiner vorhandenen Infrastruktur, sodass du keine Infrastrukturänderungen vornehmen musst.
Empfohlene Anwendungsfälle
Hochverfügbarkeit ist nicht dringend erforderlich.
Vorteile
Nutze die Enterprise-Funktionen, für die kein Clustering erforderlich ist:
Hast du eine ausführliche Frage zu Cloud? Nimm Kontakt mit uns auf, um einen Cloud-Beratungstermin mit einem Migrationsspezialisten zu vereinbaren.*
Geclustert
Infrastrukturanforderungen
Für ein Upgrade auf Data Center in einem Cluster benötigst du die folgenden Komponenten:
- Load Balancer
- Anwendungsknoten
- Dateisystem, auf das von allen Anwendungsknoten aus zugegriffen werden kann
- ElasticSearch-Knoten (Bitbucket)
Empfohlene Anwendungsfälle
- Du benötigst eine hohe Verfügbarkeit.
- Du möchtest ein Upgrade ohne Ausfallzeiten durchführen.
- Du rechnest in naher Zukunft mit einem enormen Unternehmenswachstum.
Vorteile
Nutze die Unternehmensfunktionen, die Clustering bieten kann:
- Enterprise-Funktionen
- Hochverfügbarkeit und Failover: Wenn ein Knoten in deinem Anwendungs-Cluster ausfällt, übernehmen andere Knoten die Last, sodass ein störungsfreier Produktzugriff gewährleistet ist.
- Umgehende Skalierbarkeit: Neue Knoten können deinem Cluster ohne Ausfallzeiten oder zusätzliche Lizenzgebühren hinzugefügt werden. Indizes und Apps werden automatisch synchronisiert.
- Disaster Recovery: Stelle ein Offsite Disaster Recovery-System bereit, um selbst im Falle eines kompletten Systemausfalls den Geschäftsbetrieb aufrechtzuerhalten. Dank gemeinsamer Produktindizes bist du im Handumdrehen wieder einsatzbereit.
Planung und Vorbereitung
Nachdem du dich für deinen Data Center-Pfad entschieden hast, kannst du mit der Erstellung eines detaillierten Upgradeplans beginnen.
Ermittlung des Zeitrahmens Erforderlich
Anhand dieser grundlegenden Zeitpläne kannst du einschätzen, wie lange dein Upgrade ungefähr dauern wird.
| | Nicht geclustert | Geclustert |
|---|---|---|
| Planung | Nicht geclustert 0 – 2 Wochen | Geclustert Mind. 1 Monat |
| Testdurchlauf | Nicht geclustert 0 – 1 Woche | Geclustert 3 – 6 Monate |
| Einführung | Nicht geclustert 0 – 1 Woche | Geclustert ~6 – 9 Monate |
Diese Zeitangaben basieren auf den Zahlen einiger unserer Kunden, die erfolgreich ein Upgrade auf Data Center durchgeführt haben. Beachte jedoch, dass die tatsächliche Dauer von individuellen Faktoren deiner Umgebung abhängt, u. a. von deren Größe, Komplexität und Vorbereitung.
Definition deiner Data Center-Umgebung Erforderlich
Anwendungsschicht
Instanzen und Standorte
- Möchtest du deine Instanzen zu einem Verbund vereinen oder konsolidieren?
- Wie sieht dein zukünftiges Wachstum aus?
- Benötigst du eine Datenisolierung?
- Wie viele Umgebungen hat dein Team, beispielsweise Staging- oder Produktionsumgebungen?
Instanzprofile
- Wie viele Personen werden auf deine Instanz zugreifen?
- Wo werden sich deine Teams befinden?
- Wie viele Daten befinden sich derzeit in deiner Instanz und wie viele Daten planst du, deiner Instanz hinzuzufügen?
Apps, Integrationen und Anpassungen
Brauchst du sie alle, oder wäre das eine gute Gelegenheit, um die Umgebung zu vereinfachen?
Infrastrukturschicht
Dimensionierung der Instanz
- Wie sehen deine Wachstumsprognosen aus?
- Gibt es Zeiten, in denen du einen geringeren Benutzerdatenverkehr hast?
Weitere Informationen findest du in unserer Übersicht zur Bestimmung der Knotenanzahl.
Kontostruktur
- Auf welchen Konten sollte deine Umgebung bereitgestellt werden?
- Möchtest du, dass verschiedene Konten mit jeder deiner Umgebungen verknüpft werden?
- Möchtest du, dass deine Data Center-Produkte dasselbe Konto wie deine anderen Tools für CI/CD oder Zusammenarbeit verwenden?
Governance-Modell
- Wie sieht dein Governance-Modell aus?
- Was sind deine Mindestsystemanforderungen?
- Verwendest du eine zentralisierte Protokollierung?
- Was sind deine Anforderungen an die Benutzerverwaltung?
Ziehe die Verwendung von AWS Landing Zone und AWS System Manager als Teil deines Governance-Modells in Erwägung.
VPC (Virtual Private Cloud)
-
Möchtest du eine neue Virtual Private Cloud (VPC) nutzen?
Unabhängig davon, ob du in einer neuen oder in einer bestehenden VPC bereitstellen möchtest, kannst du die Vorlage für Atlassian Standard Infrastructure (ASI) nutzen.
- Gibt es Netzwerkprinzipien, die du ändern möchtest, z. B. die Einschränkung des öffentlichen Internetzugangs und der internen IP-Adressierung für Büro- und VPN-Netzwerk-Routing?
- Solltest du TLS-Zertifikate verwenden?
Region
-
Hast du bei Verwendung einer vorhandenen VPC einen Plan für den Büro- und VPN-Netzwerkzugriff erstellt?
Wir empfehlen dir, den Zugriff von allen Büros und VPNs aus zu erlauben, da deine Produktnutzung mit der Zeit höchstwahrscheinlich zunehmen wird.
Direct Connect
- Möchtest du Direct Connect verwenden, um Leistung und Sicherheit zu verbessern?
- Wie viele Daten brauchst du, um von deiner Server-Instanz zu Data Center zu wechseln?
Wenn du große Datenmengen verschieben willst, solltest du die AWS-Snow-Familie in Betracht ziehen.
Business Continuity und Disaster Recovery
Backup
Wie sieht deine Backup-Strategie aus?
Wir empfehlen dir, eine Kombination aus deiner bestehenden Backup-Strategie und den in AWS integrierten Backup-Funktionen zu verwenden. Weitere Informationen findest du hier:
AWS bietet Infrastrukturservices, die weniger anfällig für einzelne Ausfälle sind.
Regionales Failover
Musst du Cold, Warm oder Hot Sites in verschiedenen Regionen implementieren?
In der Regel werden deine Disaster-Recovery-Anforderungen dadurch erfüllt, dass deine Services über mehrere Verfügbarkeitszonen hinweg ausgeführt werden. Vielleicht möchtest du aber auch regionale Ausfälle mindern. Bei der Entscheidung, ob du diese Sites in verschiedenen Regionen implementieren möchtest, solltest du Folgendes berücksichtigen:
- Kosten für Infrastruktur und Datenübertragung
- Geschwindigkeit der Wiederherstellung im Vergleich zu AWS
- Zeit für die Wartung und das Testen der Wiederherstellungs-Site
- Kosten für den Betrieb der Site
Auf Data Center upgraden (nicht geclustert)
Wenn du dich für eine nicht geclusterte Architektur entschieden hast, kannst du ganz einfach auf Data Center upgraden.
Auf Data Center upgraden (geclustert)
Wenn du dich für ein Upgrade auf eine Cluster-Architektur entschieden hast und ein Plan dafür vorliegt, kannst du loslegen.
Welche Infrastruktur benötigst du für dein Cluster?
Für das Deployment von Data Center in einem Cluster benötigst du die folgenden Komponenten:
- Datenbank
- Load Balancer
- Anwendungsknoten
- Freigegebenes Dateisystem
- ElasticSearch-Knoten (Bitbucket)
Load Balancer
Der Load Balancer ist die erste Instanz, auf die die Anfragen deiner Benutzer treffen, wenn die Bereitstellung in einem Cluster erfolgt ist. Anfragen treffen im Load Balancer ein und der Load Balancer verteilt dann die einzelnen Anfragen an die Anwendungsknoten. Data Center unterstützt sowohl hardware- als auch softwarebasierte Load Balancer. Bei beiden Lösungen sollte der Load Balancer über eine schnelle LAN-Verbindung mit dem Anwendungscluster verbunden sein, um eine hohe Bandbreite und eine geringe Latenz zu gewährleisten. Alle softwarebasierten Load Balancer sollten auf dedizierten Rechnern ausgeführt werden.
Bei Data Center-Produkten wird davon ausgegangen, dass die Anfrage jedes Benutzers während einer Sitzung an denselben Knoten geht. Wenn Anfragen an verschiedene Knoten weitergeleitet werden, können Benutzer unerwartet abgemeldet werden, und sie könnten sogar in ihrer Sitzung gespeicherte Informationen verlieren. Daher muss eine Sitzung an den gleichen Knoten gebunden werden, indem Cookie-basierte "Sticky Sessions" (oder Sitzungsaffinität) auf dem Load Balancer aktiviert werden. Wenn du Cookie-basierte Sticky Sessions verwendest, kannst du das Cookie verwenden, das vom Produkt ausgegeben wird, oder du kannst ein Cookie verwenden, das vom Load Balancer generiert wird.
Fügen Sie eine zusätzliche Schutzebene hinzu und vermeiden Sie, dass der Load Balancer zu einem "Single Point of Failure" wird, indem Sie zu Ihrer Load Balancing-Lösung Redundanz hinzufügen. Sie können dazu zwei Load Balancer in einer Aktiv-Passiv-Konfiguration einrichten und dabei für beide Load Balancer eine virtuelle IP-Adresse verwenden. Wenn der aktive Load Balancer ausfällt, erfolgt ein Failover auf den passiven Load Balancer.
Weitere Informationen findest du in unseren Konfigurationsoptionen für Load Balancer.
Anwendungsknoten
Das eigentliche Produkt befindet sich auf den Anwendungsknoten. Jeder Knoten in deinem Data Center-Cluster muss dieselbe Version des Produkts ausführen und sich am selben physischen Standort befinden, um eine minimale Latenz zu gewährleisten. Du kannst jedoch ein Content Delivery Network (CDN) aktivieren, um die Leistung deiner geografisch verteilten Teams zu unterstützen. Diese Knoten sollten in einem Cluster konfiguriert sein und als Einheit funktionieren, um das Produkt für deine Benutzer bereitzustellen. Die Anzahl der Knoten in deinem Cluster hängt nicht nur von deinen Anforderungen ab, sondern auch davon, wie du dein Produkt konfigurierst. Unserer Erfahrung nach sind für die meisten Cluster normalerweise zwischen 2 und 4 Knoten ausreichend. Du kannst jedoch unsere Leitfäden zur Bestimmung der Knotenanzahl nutzen, um die richtige Entscheidung zu treffen.
Für Bitbucket ist ein weiterer Anwendungsknoten speziell für ElasticSearch erforderlich, um die Codesuche zu ermöglichen.
Freigegebenes Dateisystem
Im freigegebenen Dateisystem werden Daten gespeichert, auf die von jedem Anwendungsknoten aus zugegriffen werden kann, wie angehängte Dateien und Git-Repositorys.
In einer Data Center-Umgebung musst du dein Dateifreigabesystem als eigenen Knoten einrichten. Du kannst für dein Dateifreigabesystem jedes NFS-basierte NAS- oder SAN-Programm verwenden. Wir empfehlen jedoch NFS3 zur Aufrechterhaltung deiner Performance. Achte darauf, keine verteilten Protokolle wie DFS zu verwenden, da diese nicht unterstützt werden.
Erstellung einer Staging-Umgebung
Damit dein Upgrade auf mehrere Knoten zum Erfolg wird, empfehlen wir die Erstellung einer Staging-Umgebung, um Data Center vor der eigentlichen Einführung zu testen.
Deine Staging-Umgebung sollte deine Produktionsumgebung einschließlich Reverse-Proxys, SSL-Konfiguration oder Load Balancer so genau wie möglich nachbilden. Du könntest hierfür einen anderen physischen Server oder eine virtuelle Lösung nutzen. Hauptsache ist, dass du ein geeignetes Replikat deiner Produktionsumgebung erstellst.
Detaillierte Anleitungen:
Sprich mit einem Partner
Hast du eine Frage zu deinen Migrationsoptionen oder deinem Migrationspfad? Lass dich von unserem Team von Migrationsspezialisten beraten.