Najpierw przygotuj i przetestuj nowy serwer, skopiuj dane metodą spójności obsługiwaną przez aplikację, zdefiniuj okno przełączenia i zachowaj stare środowisko. Wycofanie musi uwzględniać zapisy przyjęte na nowym serwerze, a nie tylko zmianę DNS.
Zinwentaryzuj usługę przed przeniesieniem maszyny
Migracja obejmuje więcej niż pliki aplikacji. Wymień bazy danych, przesłane pliki, zadania zaplanowane, procesy robocze kolejek, certyfikaty, domeny, sekrety i integracje wychodzące. Zapisz wersje oprogramowania i istotne założenia operacyjne, takie jak uprawnienia do plików i ścieżki przechowywania. Świeży serwer dedykowany może ujawnić zapomnianą zależność, która została po cichu zainstalowana lata wcześniej w starym środowisku.
Wyznacz osobę odpowiedzialną za decyzję o przełączeniu i zdefiniuj, jak wygląda sukces. Uwzględnij kontrole widoczne dla użytkownika, spójność danych i możliwość odzyskania dostępu. Przed ogłoszeniem daty migracji potwierdź, że nowa konfiguracja została dostarczona i jest użyteczna. Potwierdzenie zamówienia lub podana specyfikacja sprzętowa to nie to samo co działające środowisko docelowe gotowe do przyjęcia danych produkcyjnych.
Zbuduj środowisko docelowe jako osobne środowisko
Zainstaluj wymagany stos, skonfiguruj administrację i ustaw docelowy firewall. Trzymaj sekrety w poufności i celowo ustaw uprawnienia usług. Przed przeniesieniem ruchu publicznego zweryfikuj oczekiwaną nazwę hosta i działanie certyfikatu aplikacji. Dokumentacja hostów wirtualnych Apache pokazuje, dlaczego routing nazw hostów jest odrębną decyzją konfiguracyjną od adresu serwera. Działająca strona domyślna nie dowodzi, że skonfigurowano właściwy host aplikacji.
Do próby użyj reprezentatywnego przywróconego zbioru danych, z wyłączoną lub przekierowaną do bezpiecznych systemów testowych pocztą wychodzącą, płatnościami i zadaniami zaplanowanymi. Zapobiega to podejmowaniu działań na prawdziwych użytkownikach przez środowisko testowe. Przećwicz logowanie, przesyłanie plików, pracę w tle i przywracanie. Zapisz procedurę i jej czas trwania, aby rzeczywiste okno opierało się na zaobserwowanym procesie, a nie na optymizmie.
Wybierz spójną granicę danych
Użyj metody tworzenia kopii zapasowych lub replikacji obsługiwanej przez bazę danych i aplikację. PostgreSQL rozróżnia zrzuty SQL, kopie zapasowe systemu plików i ciągłe archiwizowanie, z których każde ma własne założenia. Wskazówki dotyczące zrzutów zauważają, że zrzuty bazy danych mogą być wewnętrznie spójne, podczas gdy role w całym klastrze i inne szczegóły wymagają osobnego postępowania. Przeczytaj wymagania dla dokładnie tego systemu, który uruchamiasz, zamiast bezrefleksyjnie kopiować otwarte pliki danych.
Zaplanuj, jak baza danych odnosi się do przesłanych plików i stanu kolejek. Jeśli rekord wskazuje plik skopiowany w innym czasie, przywrócona aplikacja może być niekompletna, nawet gdy obie kopie zakończyły się sukcesem osobno. Zdecyduj, czy na krótko wstrzymać zapisy, użyć przetestowanego rozwiązania replikacji, czy wykonać eksport specyficzny dla aplikacji. Utrzymuj tę decyzję o spójności w jawny sposób w runbooku.
| Etap | Wymagany dowód | Decyzja |
|---|---|---|
| Próba | Aplikacja i przywrócone dane przechodzą kontrole | Środowisko docelowe można rozważyć do przełączenia |
| Końcowa synchronizacja | Zdefiniowany spójny punkt odzyskiwania | Kontynuuj tylko ze zrozumiałymi pozostałymi zmianami |
| Przełączenie ruchu | Poprawny routing i działanie certyfikatu | Monitoruj oba środowiska docelowe |
| Wycofanie | Lokalizacja wszystkich nowo przyjętych zapisów | Uzgodnij dane przed przywróceniem ruchu |
Przygotuj routing ruchu bez obiecywania natychmiastowych zmian
DNS time-to-live kontroluje, jak długo rekordy mogą być buforowane, co wyjaśniono w dokumentacji DNS Cloudflare. Sprawdź TTL wcześnie, jeśli DNS jest częścią migracji, i pozwól istniejącym buforowanym rekordom wygasnąć zgodnie z ich poprzednim ustawieniem. Zmiana wartości w momencie przełączenia nie może wstecznie skrócić każdej buforowanej odpowiedzi. Różni klienci mogą w trakcie przejścia trafiać do różnych miejsc docelowych.
Utrzymuj stare środowisko dostępne, dopóki zmiany routingu się nie ustabilizują, z celową polityką dotyczącą tego, czy może ono nadal przyjmować zapisy. Unikaj uruchamiania zduplikowanych konsumentów kolejek lub zadań zaplanowanych, chyba że aplikacja jest do tego zaprojektowana. Monitoruj żądania po obu stronach i potwierdź zamierzoną nazwę hosta, certyfikat TLS i wersję aplikacji z niezależnych klientów.
Zdefiniuj wycofanie po rozpoczęciu zapisów
Zanim nowy system zacznie przyjmować zmiany, przywrócenie ruchu może być stosunkowo proste. Później samo odwrócenie DNS może spowodować utratę pracy lub powstanie dwóch sprzecznych historii. Zdefiniuj, jak nowo utworzone rekordy i przesłane pliki zostaną zachowane lub uzgodnione. Jeśli aplikacja nie może ich bezpiecznie scalić, kontrolowany okres konserwacji może być lepszy niż doraźny powrót do starej kopii.
Ustal warunki wymagające wstrzymania migracji i utrzymuj kontakt z osobą odpowiedzialną za decyzję. Zachowaj logi i przydatne dowody zgodnie z zasadami retencji projektu. Nie usuwaj starej maszyny ani jej niezależnej kopii zapasowej tylko dlatego, że strona główna raz się załadowała. Okres retencji powinien obejmować uzgodnione potrzeby weryfikacji i wycofania.
Zakończ migrację kontrolami operacyjnymi
Po przełączeniu zweryfikuj kopie zapasowe, alerty, odnawianie certyfikatów, zadania zaplanowane i odzyskiwanie dostępu. Potwierdź, że monitorowany host to nowe środowisko docelowe i że w środowisku produkcyjnym nie pozostały żadne integracje testowe. Przejrzyj błędy aplikacji i czasy widoczne dla użytkownika przy zwykłym ruchu. Zaktualizuj inwentarz i runbook, aby następny administrator nie musiał domyślać się, co się zmieniło.
Dedykowane rodziny SwissOctet oferują różne konfiguracje fizyczne, ale prace migracyjne i zarządzane wsparcie trzeba potwierdzić dla wybranej usługi. Użyj katalogu, aby wybrać odpowiednie zasoby, a następnie zbuduj przetestowane przeniesienie wokół danych swojej aplikacji. Migracja jest zakończona, gdy usługa i jej proces odzyskiwania działają w środowisku docelowym, a nie tylko gdy pliki zostały przeniesione.
Twoja praktyczna lista kontrolna.
- Zinwentaryzuj dane, zadania, sekrety i integracje.
- Zweryfikuj dostarczone środowisko docelowe przed zaplanowaniem.
- Przećwicz z bezpiecznymi integracjami zewnętrznymi.
- Zdefiniuj spójność bazy danych i przesłanych plików.
- Zaplanuj przejście routingu i zapobieganie duplikowaniu zadań.
- Określ wycofanie dla nowych zapisów.
- Zweryfikuj kopie zapasowe i monitorowanie po przełączeniu.
Szczegóły, które mają znaczenie.
Czy mogę przeprowadzić migrację, kopiując katalog aplikacji?+
Tylko jeśli obejmuje to wszystko, czego potrzebuje usługa, i zachowuje spójność. Bazy danych, przesłane pliki, zadania, sekrety i konfiguracja zwykle wymagają osobnej uwagi.
Czy obniżenie TTL DNS sprawia, że przełączenie jest natychmiastowe?+
Nie. Wcześniej buforowane odpowiedzi mogą pozostać do końca swojego wcześniejszego okresu życia, a klienci mogą aktualizować się w różnym czasie.
Czy wycofanie polega tylko na wskazaniu DNS na stary serwer?+
Nie po tym, jak nowy serwer zacznie przyjmować zapisy. Musisz uwzględnić te rekordy i pliki przed przywróceniem ruchu.
Przejdź do źródła.
Te źródła wspierają koncepcje techniczne w tym przewodniku. Przed zmianą systemu produkcyjnego zapoznaj się z aktualną dokumentacją.
- PostgreSQL: Kopia zapasowa i przywracanie www.postgresql.org
- PostgreSQL: Spójność i przywracanie zrzutów SQL www.postgresql.org
- Apache: Dokumentacja hostów wirtualnych httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Wskazówki redakcyjne SwissOctet. Przykłady są ilustracyjne. Specyfikacje usług, dostępne opcje i warunki umowne należy zweryfikować osobno.