Co sprawdzamy przed każdą migracją serwera?

Weekend przy szafie rackowej. Instalacja nowej platformy. Przełączenie użytkowników.

Tak zwykle wyobrażamy sobie migrację serwera. I rzeczywiście, to jej najbardziej widoczna część.

Ale zanim do niej dojdziemy, trzeba odpowiedzieć na kilka pytań. Co działa w środowisku? Od czego zależy? I jak przywrócimy usługi, jeśli przeniesienie się nie powiedzie?

Po kilkudziesięciu zrealizowanych migracjach wiemy, jak ryzykowne potrafi być zdanie: „Przecież znamy to środowisko”. Infrastruktura lubi wtedy przypomnieć o czymś, o czym wszyscy zdążyli zapomnieć.

Dlatego zaczynamy od przygotowania.

Od audytu usług, zależności i backupu. Dopiero na tej podstawie układamy harmonogram, scenariusz powrotu i testy, które trzeba wykonać przed oddaniem środowiska użytkownikom.

Co naprawdę działa w tym środowisku?

Dokumentacja bardzo pomaga.

O ile opisuje środowisko, które nadal istnieje.

Spotykamy opisy sprzed kilku lat, bez nowych usług i zmian konfiguracji. Czasem jedyną dokumentacją jest administrator, który akurat jest na urlopie albo odszedł z firmy.

Co robi ten serwer? Jest kontrolerem domeny, serwerem plików, bazą danych? A może uruchamia jedno zadanie, ale tylko od czasu do czasu?

Najpierw ustalamy rolę każdego systemu i jego znaczenie dla organizacji. Kontroler domeny, serwer plików i baza danych mają inne wymagania, choć mogą uczestniczyć w jednym procesie biznesowym. Dlatego do inwentaryzacji dopisujemy też zadania harmonogramu, integracje i usługi uruchamiane okresowo.

Kilka razy trafiliśmy na zapomniane usługi. Ich znaczenie ujawniło się dopiero po wyłączeniu: wykonywały niewielkie, lecz krytyczne zadanie.

Cisza w logach podczas oględzin? To jeszcze za mało, żeby uznać maszynę za zbędną.

Dla każdej usługi zapisz nazwę systemu, osobę odpowiedzialną po stronie klienta, lokalizację danych, sposób logowania, zależności sieciowe i dopuszczalną przerwę. Potem porównaj to zestawienie z konfiguracją aplikacji, harmonogramami zadań oraz logami z okresu obejmującego jej rzeczywisty cykl pracy.

System wykonuje zadanie na koniec miesiąca? Jeden spokojny dzień obserwacji niewiele nam o nim powie.

Zależności wyznaczają kolejność migracji

Mamy listę maszyn. Co dalej?

Trzeba ustalić, które usługi muszą działać, zanim uruchomimy kolejne. Użytkownik widzi jeden ekran logowania. Za nim mogą stać baza danych, DNS, uwierzytelnianie i udział plikowy.

W zapisie zależności wskaż system źródłowy i docelowy, używaną nazwę lub adres, port oraz funkcję połączenia. Sprawdź konfigurację i wykonaj konkretną operację w aplikacji. Dopiero jej poprawny wynik potwierdza, że połączenie spełnia swoją rolę.

Ping odpowiada? Dobrze. O dostępności samej usługi nadal wiemy niewiele.

Przykładowo, przed przeniesieniem aplikacji korzystającej z oddzielnej bazy trzeba ustalić kolejność zatrzymania zapisów, przeniesienia danych i ponownego uruchomienia usług. Plan powinien też obejmować integracje z zewnętrznymi systemami, które mogą nadal wysyłać dane w czasie okna serwisowego.

Backup sprawdzamy przez odtworzenie

„Czy macie backup?”

Zwykle słyszymy: „Tak”.

Wtedy pada drugie pytanie: „Kiedy ostatnio udało się z niego odtworzyć dane?”. Ta data mówi nam znacznie więcej.

Dlatego przed migracją sprawdzamy zarówno wykonywanie kopii, jak i możliwość odzyskania z nich danych.

Test powinien kończyć się działającą usługą i sprawdzonymi danymi. Do próby wybierz kopię konkretnego systemu, odtwórz ją w odizolowanym środowisku i uruchom niezbędne zależności. Kopia nie powinna samoczynnie połączyć się z produkcją, wysłać wiadomości ani wykonać zadań integracyjnych. Następnie sprawdź logowanie, odczyt danych oraz uzgodnioną operację aplikacyjną na danych testowych.

Zapisz czas rozpoczęcia odtwarzania i chwilę, w której usługa przeszła testy. Porównaj wynik z uzgodnionym RTO, czyli docelowym czasem przywrócenia działania. RPO określa natomiast dopuszczalny okres utraty danych. Oceń go na podstawie punktu w czasie, do którego rzeczywiście można odtworzyć dane, a nie tylko godziny zakończenia zadania backupu. W harmonogramie migracji uwzględnij także czas na decyzję i przygotowanie odtwarzania.

Jeśli środowisko korzysta z Proxmox Backup Server, zadania weryfikacji pozwalają sprawdzać integralność zapisanych kopii. Wynik takiego zadania warto połączyć z próbą odtworzenia: kontrola danych w repozytorium i sprawdzenie działania aplikacji odpowiadają na różne pytania. Ustawienia weryfikacji opisuje dokumentacja Proxmox Backup Server.

Okno serwisowe musi pomieścić testy i powrót

Większość migracji realizujemy poza godzinami pracy klienta. Często w weekend, żeby zdążyć sprawdzić środowisko przed powrotem użytkowników.

Brzmi jak sporo czasu.

Tyle że systemy automatyczne niekoniecznie mają wolną sobotę. Termin trzeba dopasować także do ich pracy oraz dostępności osób, które odbiorą aplikacje. Bez miejsca na testy sobota bardzo szybko zamieni się w niedzielę, a niedziela w nerwowe oczekiwanie na poniedziałek.

W harmonogramie uwzględnij zatrzymanie zapisów, końcową synchronizację lub kopię, przeniesienie, uruchomienie zależności i testy. Każda z tych czynności potrzebuje czasu.

Ile zajmie kopiowanie? Najlepiej sprawdzić to podczas próby na planowanej trasie i docelowym storage. Zanotuj rozmiar przeniesionych danych, czas oraz obciążenie podczas próby. Nominalna prędkość portu sieciowego wygląda dobrze w specyfikacji. Nie jest jednak wynikiem pomiaru migracji.

Osobno wyznacz najpóźniejszą godzinę decyzji o powrocie. Od końca uzgodnionego okna odejmij sprawdzony czas wycofania zmian, ponownych testów oraz rezerwę. Po przekroczeniu tego terminu dalsze próby naprawy mogą pozbawić zespół możliwości terminowego przywrócenia usług.

Ograniczanie przerwy zaczyna się właśnie od takich ustaleń. Ten wątek rozwijamy w artykule o planowaniu migracji do Proxmox VE i dostępności usług.

Plan powrotu uwzględnia dane zapisane po przełączeniu

A jeśli trzeba będzie się wycofać?

Na to pytanie odpowiadamy przed rozpoczęciem prac. Ustalamy, do którego momentu można wycofać zmiany i kto podejmuje decyzję. Zapisujemy też warunki przerwania migracji, na przykład nieudany test krytycznej aplikacji albo brak czasu na zakończenie odbioru.

Ważny moment przychodzi wtedy, gdy nowe środowisko zaczyna przyjmować zapisy. Od tej chwili stary serwer może już zawierać nieaktualne dane.

„To po prostu włączymy stary” brzmi kusząco. Tylko co z pracą wykonaną po przełączeniu?

Plan musi określać sposób zatrzymania zapisów, przeniesienia lub uzgodnienia zmian i ponownego udostępnienia usługi. Samo uruchomienie starej kopii może oznaczać utratę tej pracy.

Przed oknem serwisowym trzeba też potwierdzić dostęp do starej infrastruktury, kopii, kluczy szyfrowania i wymaganych kont. Osoba odpowiedzialna za powrót powinna wiedzieć, skąd odtworzyć konfigurację sieci i w jakiej kolejności uruchomić systemy.

Dobór nowej infrastruktury oprzyj na pomiarach

Skoro już przenosimy środowisko, spójrzmy trzy lub pięć lat do przodu.

Czy wystarczy pamięci? Jak poradzi sobie storage? Czy sieć nie zacznie nas ograniczać?

Te pytania zadajemy przed zakupem sprzętu. Analizujemy pamięć, wydajność storage i sieć, uwzględniając zarówno obecne obciążenie, jak i usługi, które mają dojść w przyszłości.

Z monitoringu zbierz wykorzystanie CPU w procentach, zajętość RAM-u w GB, pojemność danych, liczbę operacji dyskowych na sekundę, opóźnienia storage w milisekundach i ruch sieciowy. Odczyty powinny obejmować zwykłą pracę oraz szczyty, takie jak backup czy przetwarzanie okresowe. Zapisz interwał pomiaru i porównuj wartości z tych samych przedziałów czasu, aby zobaczyć, które obciążenia występują jednocześnie.

Przy planowaniu Proxmox Virtual Environment sprawdź także zgodność systemów gości, urządzeń przekazywanych do maszyn oraz narzędzi backupu z wybranymi wersjami. Wymagania aplikacji i wsparcie jej producenta należy ustalić przed przeniesieniem. Udane uruchomienie testowej maszyny jest dopiero częścią tej oceny.

Po czym poznać, że migracja jest zakończona?

Maszyny się uruchomiły. Można kończyć?

Teraz zaczyna się odbiór.

Przed przekazaniem środowiska sprawdzamy usługi, dostęp użytkowników, backup i wydajność. Kryteria ustalamy jeszcze podczas audytu. Dzięki temu po migracji nie trzeba prowadzić dyskusji o tym, co właściwie znaczy „działa poprawnie”.

1. Zaloguj się z uzgodnionej stacji kontem zwykłego użytkownika. Sprawdź dostęp do aplikacji i zasobów zgodnie z jego uprawnieniami.
2. Wykonaj uzgodniony scenariusz biznesowy, na przykład otwarcie dokumentu, zapis danych testowych i wygenerowanie raportu. Wynik powinien potwierdzić właściciel aplikacji.
3. Sprawdź wykonanie zadań okresowych i integracji w ich właściwym terminie. Porównaj log zakończenia oraz wynik zadania z oczekiwanym rezultatem.
4. Porównaj czas tej samej operacji przed migracją i po niej, na podobnych danych i przy porównywalnym obciążeniu. Odchylenie oceń względem uzgodnionego limitu, zapisując wyniki w sekundach.
5. Wykonaj kopię z nowego środowiska i sprawdź odtworzenie uzgodnionego zakresu. Potwierdź również, że wynik zadania i alarmy docierają do osoby odpowiedzialnej za utrzymanie.

Na koniec zostaje dokumentacja. Role systemów, adresacja, zależności, harmonogramy backupu, sposób odtworzenia i odpowiedzialność za obsługę — wszystko powinno odpowiadać nowemu środowisku.

Za rok ktoś będzie szukał tych informacji podczas awarii albo rozbudowy. Niewykluczone, że będziemy to my.

Audyt i przygotowanie planu można połączyć z pracami infrastrukturalnymi Symbit.