Przewodnik po uaktualnieniu do wersji Data Center
Nie ma dwóch takich samych organizacji, podobnie jak nie ma dwóch identycznych procesów migracji. Postępuj zgodnie z naszym szczegółowym przewodnikiem po uaktualnieniu, aby płynnie przejść z wersji Atlassian Server do Data Center.
Oceń
Każda organizacja ma unikatowe potrzeby i wymagania, dlatego ważne jest zapoznanie się z dostępnymi opcjami, aby zaplanować pomyślne uaktualnienie.
Poznaj wymagania dotyczące architektury i infrastruktury
Wybierasz Data Center? Musisz poznać wspieraną architekturę Data Center i konfiguracje wdrażania.
Wersję Data Center można wdrożyć na dwa różne sposoby: z architekturą klastrowaną lub nieklastrowaną. Każdy z tych wariantów umożliwia korzystanie z funkcji i możliwości dla przedsiębiorstw, jednak wybór odpowiedniego wymaga rozważenia różnych kwestii. Poniższa tabela zawiera opis różnic między architekturą nieklastrowaną i klastrowaną:
Nieklastrowana zalecane
Wymagania dotyczące infrastruktury
Architektura nieklastrowana umożliwia uaktualnienie do wersji Data Center z wykorzystaniem istniejącej infrastruktury, dzięki czemu nie ma potrzeby wprowadzania żadnych zmian infrastrukturalnych.
Zalecane przypadki użycia
Wszystkim klientom zalecamy uaktualnienie do Data Center za pomocą nieklastrowanej ścieżki uaktualnienia. W razie potrzeby klienci mogą wdrożyć architekturę klastrowaną po aktywowaniu Data Center.
Korzyści
Uzyskaj dostęp do funkcji dla przedsiębiorstw, które nie wykorzystują klastrowania:
Zazwyczaj migracja klientów do wersji Data Center zaczyna się od uaktualnień architektury nieklastrowanej. Zalecamy skorzystanie z tego 2-minutowego uaktualnienia, aby ten proces przebiegł sprawnie.
Klastrowana
Wszystkim klientom zalecamy najpierw uaktualnienie do Data Center za pomocą nieklastrowanej ścieżki uaktualnienia. Po uaktualnieniu do Data Center klienci mogą w razie potrzeby wdrożyć architekturę klastrowaną.
Wymagania dotyczące infrastruktury
W celu przeprowadzenia uaktualnienia do wersji Data Center w klastrze potrzebne będą następujące komponenty:
- Moduł równoważenia obciążenia
- Węzły aplikacji
- System plików dostępny dla wszystkich węzłów aplikacji
- Węzeł Elasticsearch (Bitbucket)
Zalecane przypadki użycia
- Potrzebujesz wysokiej dostępności
- Chcesz uaktualniać bez przestojów
- W krótkim czasie spodziewane jest rozwinięcie skali działalności do poziomu XL
Korzyści
Zyskaj dostęp do funkcji korporacyjnych zapewnianych przez klastrowanie:
- Funkcje i możliwości rozwiązania Enterprise
- Wysoka dostępność i możliwość pracy w trybie failover — jeśli jeden węzeł w klastrze aplikacji przestanie działać, jego obciążenie przejmą inne węzły, dzięki czemu użytkownicy mają nieprzerwany dostęp do produktu.
- Natychmiastowa skalowalność — możliwość dodawania do klastra nowych węzłów bez przestojów lub dodatkowych opłat licencyjnych. Indeksy i aplikacje są synchronizowane automatycznie.
- Odzyskiwanie po awarii — możliwość wdrożenia systemu odzyskiwania po awarii w lokalizacji zewnętrznej w celu zapewnienia ciągłości działalności biznesowej, nawet w przypadku całkowitej niedostępności systemu. Współdzielone indeksy produktów pozwalają na szybkie przywrócenie działania.
Planowanie i przygotowanie
Po wybraniu ścieżki uaktualnienia do wersji Data Center nadszedł czas na utworzenie szczegółowego planu uaktualnienia.
Opracowanie osi czasu Wymagane
Poniżej przedstawiamy podstawowe ramy czasowe, które można przyjąć, aby ocenić prawdopodobny czas potrzebny na przeprowadzenie uaktualnienia.
| | Nieklastrowana | Klastrowana |
|---|---|---|
| Planowanie | Nieklastrowana 0–2 tygodni | Klastrowana Powyżej 1 miesiąca |
| Rozruch testowy | Nieklastrowana 0–1 tygodnia | Klastrowana 3–6 miesięcy |
| Wdrożenie produkcyjne | Nieklastrowana 0–1 tygodnia | Klastrowana ~6–9 miesięcy |
Przedstawione tutaj ramy czasowe zostały wyliczone na podstawie doświadczeń wielu naszych klientów, którzy pomyślnie przeszli uaktualnienie z wersji Data Center. Należy jednak pamiętać, że rzeczywisty czas będzie zależał od czynników unikatowych dla danego środowiska, a w szczególności od jego rozmiaru, stopnia złożoności i zakresu przygotowania.
Zdefiniuj środowisko Data Center Wymagane
Warstwa aplikacji
Instancje i lokalizacje
- Czy chcesz dokonać federacji lub skonsolidować swoje instancje?
- Jak wygląda Twój przyszły wzrost?
- Czy potrzebujesz izolacji danych?
- Ile środowisk ma Twój zespół, w tym środowisk stagingowych lub produkcyjnych?
Profile instancji
- Ile osób będzie mieć dostęp do Twojej instancji?
- Gdzie będą zlokalizowane Twoje zespoły?
- Ile danych znajduje się obecnie w Twojej instancji i ile danych zamierzasz do niej dodać?
Aplikacje, integracje i dostosowywanie
Czy potrzebujesz wszystkich tych elementów, a może jest to dobra okazja na wprowadzenie uproszczeń?
Warstwa infrastruktury
Określanie rozmiaru instancji
- Jakie są prognozy dotyczące Twojego przyszłego wzrostu?
- Czy zdarza się, że poziom ruchu użytkowników jest niższy?
Aby uzyskać więcej informacji, zapoznaj się z przeglądem rozmiarów węzłów.
Struktura konta
- Na jakich kontach ma być wdrożone Twoje środowisko?
- Czy chcesz powiązać różne konta z każdym ze swoich środowisk?
- Czy chcesz, aby produkty Data Center korzystały z tego samego konta co inne narzędzia CI/CD lub narzędzia do współpracy?
Model zarządzania
- Jak wygląda Twój model zarządzania?
- Jakie są Twoje minimalne standardy systemowe?
- Czy korzystać ze scentralizowanego rejestrowania?
- Jakie są Twoje potrzeby w zakresie zarządzania użytkownikami?
Rozważ użycie strefy docelowej AWS i programu AWS System Manager jako elementów modelu zarządzania.
VPC
-
Czy chcesz korzystać z nowej wirtualnej chmury prywatnej (VPC)?
Niezależnie od tego, czy chcesz wdrożyć w nowej chmurze VPC, czy użyć istniejącej, możesz skorzystać z szablonu Atlassian Standard Infrastructure (ASI).
- Czy istnieją jakieś zasady sieciowe, które chcesz zmienić, takie jak ograniczenie publicznego dostępu do Internetu i wewnętrznego adresowania IP dla biura i sieci VPN?
- Czy masz korzystać z certyfikatów TLS?
Geografia
-
Jeśli korzystasz z istniejącej chmury VPC, czy masz plan dostępu do sieci biurowej i VPN?
Zalecamy, aby zezwolić na dostęp ze wszystkich biur i sieci VPN, ponieważ z czasem korzystanie z produktu najprawdopodobniej się zwiększy.
Bezpośrednie połączenie
- Czy chcesz korzystać z funkcji bezpośredniego połączenia, aby pomóc w poprawie wydajności i bezpieczeństwa?
- Ile danych chcesz przenieść z instancji wersji Server do Data Center?
AWS Snow Family może być przydatnym zasobem, jeśli przenosisz duże ilości danych.
Zachowanie ciągłości działania i odzyskiwanie awaryjne
Kopia zapasowa
Jak wygląda Twoja strategia tworzenia kopii zapasowych?
Zalecamy skorzystanie z kombinacji zarówno istniejącej strategii tworzenia kopii zapasowych, jak i funkcji tworzenia kopii zapasowych wbudowanych w AWS. Aby uzyskać więcej informacji, zobacz:
AWS oferuje usługi infrastrukturalne, które są mniej podatne na pojedyncze przestoje.
Regionalny tryb failover
Czy musisz wdrażać centra odzyskiwania danych używanych rzadko, często i bardzo często w różnych regionach?
Zazwyczaj Twoje potrzeby w zakresie odzyskiwania po awarii są zaspokajane poprzez uruchamianie usług w wielu strefach dostępności, ale być może zależy Ci także na ograniczeniu regionalnych przestojów. Decydując, czy chcesz zaimplementować te centra w różnych regionach, musisz wziąć pod uwagę następujące kwestie:
- Koszt infrastruktury i transferu danych
- Szybkość odzyskiwania w porównaniu z AWS
- Czas poświęcony na utrzymanie i testowanie centrum odzyskiwania
- Koszt funkcjonowania centrum
Uaktualnienie do Data Center (architektura nieklastrowana) zalecane
Wszystkim klientom zalecamy uaktualnienie do Data Center za pomocą architektury nieklastrowanej. Uaktualnienia nieklastrowane są szybszą i bardziej uproszczoną opcją zapewniającą szybszy dostęp do zabezpieczeń, wsparcia i funkcji korporacyjnych Data Center.
Uaktualnienie do Data Center (architektura klastrowana) niezalecane
Nie zalecamy początkowych uaktualnień do Data Center w architekturze klastrowanej ze względu na ich złożoność. Wszystkim klientom zalecamy najpierw uaktualnienie do Data Center za pomocą nieklastrowanej ścieżki uaktualnienia. Następnie klienci, którzy potrzebują architektury klastrowanej, mogą rozpocząć wdrażanie.
Po uaktualnieniu do Data Center w architekturze nieklastrowanej można wdrożyć architekturę klastrowaną, jeśli wymagana jest wysoka dostępność.
Zbudowanie infrastruktury potrzebnej do obsługi klastra
Aby wdrożyć rozwiązanie Data Center w środowisku klastrowanym, potrzebne będą następujące komponenty:
- Baza danych
- Moduł równoważenia obciążenia
- Węzły aplikacji
- Współdzielony system plików
- Węzeł Elasticsearch (Bitbucket)
Moduł równoważenia obciążenia
Moduł równoważenia obciążenia to pierwszy komponent, do którego będą trafiać żądania użytkowników po wdrożeniu architektury klastrowanej. Żądania trafiają do modułu równoważenia obciążenia, który następnie przekierowuje każde z nich do odpowiedniego węzła aplikacji. Możesz użyć sprzętowego lub programowego modułu równoważenia obciążenia. W przypadku każdego z tych wariantów moduł równoważenia obciążenia powinien być połączony z klastrem aplikacji za pomocą szybkiego połączenia LAN, aby zapewnić dużą przepustowość przy małych opóźnieniach. Wszystkie programowe moduły równoważenia obciążenia powinny działać na dedykowanych komputerach.
W produktach Data Center założono, że żądanie każdego użytkownika będzie w trakcie sesji trafiało do tego samego węzła. Jeśli żądania będą kierowane do innych węzłów, może dojść do nieoczekiwanego wylogowania użytkowników, a nawet utraty informacji zapisanych w ich sesjach. W związku z tym wymagane jest powiązanie sesji z jednym węzłem poprzez aktywowanie opartego na plikach cookie mechanizmu sticky session (lub koligacji sesji) w module równoważenia obciążenia. Oparty na plikach cookie mechanizm sticky session pozwala użyć pliku cookie wygenerowanego przez produkt lub przez moduł równoważenia obciążenia.
Można jednak zapewnić dodatkową warstwę ochrony i zapobiec sytuacji, w której moduł równoważenia obciążenia stałby się pojedynczym punktem awarii, dodając opcję nadmiarowości do rozwiązania odpowiedzialnego za równoważenie obciążenia. W tym celu należy skonfigurować dwa moduły równoważenia obciążenia w konfiguracji aktywny-pasywny, nadając obydwu modułom wirtualny adres IP. Jeśli aktywny moduł równoważenia obciążenia ulegnie awarii, nastąpi przełączenie awaryjne na moduł pasywny.
Więcej informacji zawierają nasze opcje konfiguracji modułu równoważenia obciążenia.
Węzły aplikacji
Węzły aplikacji to miejsca, w których funkcjonuje właściwy produkt. W każdym węźle w klastrze Data Center musi być uruchomiona ta sama wersja produktu. Ponadto węzły muszą się znajdować w jednej lokalizacji, aby ograniczyć opóźnienia do minimum. Można jednak włączyć sieć dostarczania zawartości (CDN), która pozwala zwiększyć wydajność w zespołach, których członkowie znajdują się w różnych miejscach świata. Te węzły powinny być skonfigurowane w klaster, działając jako pojedynczy węzeł w celu zapewnienia użytkownikom dostępu do produktu. Liczba węzłów w klastrze zależy od potrzeb organizacji oraz sposobu konfiguracji produktu. W przypadku większości klastrów wystarcza zazwyczaj od 2 do 4 węzłów, jednak warto skorzystać z naszych przewodników po doborze rozmiaru węzłów, które pomogą podjąć właściwą decyzję.
Bitbucket wymaga dodatkowego węzła aplikacji dedykowanego silnikowi Elasticsearch, który umożliwia wyszukiwanie kodu.
Współdzielony system plików
Współdzielony system plików to miejsce przechowywania danych, które powinny być dostępne z dowolnego węzła aplikacji, takich jak załączone pliki i repozytoria git.
W środowisku Data Center trzeba skonfigurować współdzielony system plików w odrębnym węźle. Do obsługi systemu plików można wykorzystać dowolny system NAS lub SAN bazujący na protokole NFS, jednak w celu utrzymania właściwej wydajności zalecamy protokół NFS3. Należy tylko pamiętać, aby nie korzystać z protokołów rozproszonych, takich jak DFS, ponieważ nie są one obsługiwane.
Utworzenie środowiska przejściowego
Aby uaktualnienie do środowiska wielowęzłowego przebiegło pomyślnie, zalecamy utworzenie środowiska przejściowego, które umożliwi wypróbowanie wersji Data Center przed przejściem do trybu produkcyjnego.
Środowisko przejściowe powinno być bardzo zbliżone do środowiska produkcyjnego, z uwzględnieniem odwrotnych serwerów proxy, konfiguracji SSL lub modułu równoważenia obciążenia. Można w tym celu wykorzystać inny serwer fizyczny lub rozwiązanie zwirtualizowane. Najważniejsze w tym przypadku jest utworzenie odpowiedniej repliki środowiska produkcyjnego.
Szczegółowe instrukcje, patrz:
Porozmawiaj z ekspertem
Masz pytania dotyczące opcji lub ścieżki migracji? Uzyskaj fachowe wskazówki od naszego zespołu specjalistów ds. migracji.