Migracja serwerów i hostingu bez przestojów

Przenosimy działające strony, sklepy, bazy danych, usługi działające w tle i pocztę na nowy serwer lub do nowego dostawcy hostingu. Nowy serwer działa równolegle, dopóki każda strona nie przejdzie testów, a samo przełączenie to zmiana w DNS, którą można cofnąć.

Kiedy migracja spada Wam na głowę

Nikt nie przenosi serwerów dla przyjemności. Zwykle termin wyznacza ktoś inny, a na serwerze działa więcej, niż ktokolwiek pamięta.

Hosting wygasza Wasz plan, a na serwerze jest poczta, pięć stron i nieudokumentowane zadanie cron
Rachunek za hosting znowu wzrósł, a przeprowadzka wydaje się bardziej ryzykowna niż płacenie
System operacyjny lub panel przestał dostawać aktualizacje, a osoba, która go konfigurowała, odeszła
Chcecie połączyć kilka starych serwerów w jeden albo przejść na tańsze serwery ARM
Poczta Waszych domen działa na tej samej maszynie i nikt nie wie, od jakich rekordów DNS zależy
Poprzednia próba migracji skończyła się zepsutymi obrazkami, utraconymi zamówieniami lub odrzuconą pocztą

Co przenosimy

Najpierw inwentaryzacja

Zanim cokolwiek skopiujemy, spisujemy, co faktycznie działa: strony, bazy danych, zadania cron, procesy w tle, skrzynki i przekierowania poczty, konta FTP, certyfikaty i rekordy DNS. Zwykle ta lista ujawnia kilka rzeczy, o których właściciel nie wiedział.

Serwery WWW i bazy danych

nginx i Apache, kilka wersji PHP obok siebie, MySQL i PostgreSQL oraz panele takie jak aaPanel i FastPanel. Strony przenoszą się razem z ustawieniami, użytkownikami i uprawnieniami do plików, a nie tylko z samymi plikami.

Node, Docker i usługi

Aplikacje Node.js pod PM2 lub systemd, kontenery Docker i procesy działające w tle. Zależności budujemy na nowej maszynie od nowa, co ma znaczenie przy zmianie architektury procesora.

Poczta

Skrzynki z hasłami i historią, aliasy i przekierowania, filtr antyspamowy oraz DKIM, SPF i DMARC. Jeśli dostawca blokuje wychodzący port 25, poczta wychodzi przez przekaźnik (relay), więc nic nie zostaje odrzucone.

DNS i Cloudflare

Strefy odtwarzamy na podstawie rekordów w panelu rejestratora lub Cloudflare, a nie zgadujemy ich z zapytań DNS. TTL obniżamy z wyprzedzeniem, a serwery nazw u rejestratora zmieniamy dopiero wtedy, gdy nowa strefa jest kompletna.

Kopie zapasowe i monitoring

Nowy serwer dostaje kopie zapasowe w osobnym magazynie z polityką retencji i próbnym odtworzeniem, a także monitoring dostępności, certyfikatów i miejsca na dysku. Serwer bez nich jest przeniesiony tylko w połowie.

Migracja zaplanowana tak, że przełączenie jest nudne

Każda strona najpierw działa na nowym serwerze pod tymczasowym adresem. Otwieramy jej podstrony, wysyłamy formularze, składamy testowe zamówienie tam, gdzie jest koszyk, wysyłamy i odbieramy pocztę i czekamy, aż wykonają się zadania cron. Tuż przed przełączeniem jeszcze raz synchronizujemy dane, więc zamówienia i komentarze z czasu od pierwszej kopii nie przepadają. Potem przenosimy DNS strefa po strefie. Stary serwer zostaje nietknięty, dopóki nowy nie popracuje przez jakiś czas, więc powrót to zmiana jednego rekordu.

Spisana inwentaryzacja wszystkiego, co działa na starym serwerze
Każda strona sprawdzona na nowym serwerze przed jakąkolwiek zmianą DNS
Ostatnia synchronizacja danych tuż przed przełączeniem
Stary serwer jako zabezpieczenie, dopóki nie potwierdzicie, że wszystko działa

Problemy, które już znamy

Przenieśliśmy między serwerami dziesięć projektów i dwadzieścia trzy strony, w tym pełną przeprowadzkę z maszyn x86 na ARM64, i spisaliśmy każdy problem po drodze. Na ARM zależności Node trzeba zainstalować od nowa, a nie skopiować, a PHP potrafi się wywracać przy niektórych ustawieniach JIT. MySQL może zacząć rozróżniać wielkość liter w nazwach tabel i zepsuć zapytania, które działały latami. Nowszy lub starszy nginx odrzuca fragmenty starej konfiguracji, a bazy danych przenoszą się z niewłaściwym collation. Strefa w Cloudflare potrafi utknąć w aktywacji, filtr antyspamowy może nie podpisywać poczty, dopóki nie zostanie zrestartowany we właściwej kolejności, a reguła firewalla potrafi zablokować całe biuro korzystające z jednego adresu IP. Narzędzia migracji w panelach potrafią zgłosić sukces przy niepełnej kopii, a certyfikaty mogą po cichu przestać się odnawiać. Każdą z tych rzeczy sprawdzamy teraz w kilka minut, zamiast odkrywać ją godzinami.

Lista kontrolna zbudowana na prawdziwych migracjach, a nie na dokumentacji
Zmiany architektury, takie jak x86 na ARM64, prowadzone świadomie
Różnice wersji PHP, MySQL i nginx sprawdzone przed przełączeniem
Poczta, certyfikaty i reguły firewalla przetestowane, a nie założone

Po migracji: wsparcie zamiast teczki z dokumentami

Migracja to moment, w którym jeden zespół wreszcie zna cały serwer: co na nim działa, po co i co od czego zależy. Szkoda tracić tę wiedzę następnego dnia po przełączeniu. Większość naszych klientów po migracji zostaje przy miesięcznej administracji serwerem, w ramach której te same osoby instalują aktualizacje, pilnują kopii zapasowych i monitoringu, odnawiają certyfikaty i przeprowadzają kolejne zmiany. Jeśli wolicie prowadzić serwer sami, dostajecie dokumentację nowej konfiguracji i dostęp do wszystkiego.

Jak przebiega migracja

Inwentaryzacja

Dostajemy dostęp do odczytu starego serwera, domen i DNS. Wy dostajecie listę tego, co tam działa, i tego, co obejmie przeprowadzka.

Plan i nowy serwer

Uzgadniamy docelowy hosting i rozmiar serwera, a potem konfigurujemy nową maszynę z tymi samymi lub nowszymi wersjami oprogramowania. Dostajecie plan przełączenia dla każdej strony i każdej domeny.

Kopia i testy

Strony, bazy danych, usługi i poczta są kopiowane i sprawdzane pod tymczasowymi adresami. Problemy naprawiamy, gdy stary serwer wciąż obsługuje wszystkich.

Przełączenie

Po ostatniej synchronizacji danych przenosimy DNS strefa po strefie w wybranym przez Was terminie. Na bieżąco obserwujemy ruch, logi i pocztę.

Obserwacja i decyzja

Nowy serwer działa pod obserwacją, a stary czeka jako zabezpieczenie. Potem stary serwer jest wyłączany, a Wy wybieracie między miesięczną administracją a udokumentowanym przekazaniem.

Skąd i dokąd przenosimy

Panele i serwery WWW

Bazy danych i aplikacje

Poczta i DNS

Infrastruktura

Formy współpracy

Projekt migracji

Stały zakres uzgodniony po inwentaryzacji: które strony, usługi i domeny przenosimy i dokąd.

Migracja i miesięczna administracja

Przenosimy serwer, a potem dalej się nim opiekujemy: aktualizacje, kopie zapasowe, monitoring i kolejne zmiany.

Pomoc godzinowa

Inwentaryzacja i plan migracji dla Waszego zespołu albo pomoc przy jednym trudnym elemencie, takim jak poczta lub DNS.

Opinie

Do każdego klienta i jego projektu podchodzimy uważnie.

Zespół Revol stale usprawnia prace rozwojowe klienta dzięki wysokiej jakości pracy i niezawodnemu wsparciu. Sprawnie się komunikuje i doskonale rozumie potrzeby oraz biznes klienta.

Tomas

CEO (Jukon, Kanada)

Praca Revol w pełni spełniła oczekiwania i zadowoliła klienta. Świeże podejście i stała gotowość do wsparcia okazały się ogromnym atutem. Kto szuka komunikatywnego, zorientowanego na klienta zespołu do realizacji swoich celów, może śmiało na nich postawić.

Andrey

CEO, Stellium (USA)

Najczęściej zadawane pytania

Czy nasze strony przestaną działać w czasie migracji?

Nie powinny. Nowy serwer działa równolegle i przejmuje ruch dopiero wtedy, gdy każda strona zostanie na nim sprawdzona. W trakcie aktualizacji DNS część odwiedzających przez krótki czas nadal trafia na stary serwer, dlatego pozostaje on włączony, dopóki zmiana się nie rozpropaguje.

Co z zamówieniami i formularzami wysłanymi w trakcie przełączenia?

Tuż przed przełączeniem jeszcze raz synchronizujemy dane, więc zostaje tylko krótkie okno. W ruchliwych sklepach uzgadniamy, jak je zamknąć: przełączenie w spokojnej godzinie, wstrzymanie zamówień na kilka minut albo ręczne przeniesienie ostatnich zamówień ze starej bazy.

Czy możecie przenieść także naszą pocztę?

Tak. Skrzynki przenoszą się z wiadomościami i hasłami, o ile stary system na to pozwala, razem z aliasami i przekierowaniami. Odtwarzamy DKIM, SPF i DMARC dla nowego serwera i sprawdzamy, czy wychodząca poczta jest dostarczana, a nie tylko wysyłana.

Mamy serwery x86. Czy możemy przejść na ARM64?

Zwykle tak, a serwery ARM przy tym samym obciążeniu często są tańsze. Większość obciążeń PHP, WordPress, Node i baz danych działa na ARM po przebudowaniu zależności. Inwentaryzacja wcześnie pokazuje, czy coś istnieje tylko dla x86, na przykład stary obraz Docker lub zamknięty plik binarny, i wtedy tę część zostawiamy na x86.

Czy potrzebujecie dostępu do naszego rejestratora domen?

Do planowania wystarczy dostęp do odczytu DNS. Do przełączenia musimy edytować rekordy lub zmienić serwery nazw. Możecie to zrobić sami według naszych instrukcji albo dać nam dostęp na ten dzień.

Co, jeśli po przełączeniu coś się zepsuje?

Stary serwer wciąż istnieje, więc najszybsza naprawa to skierowanie DNS z powrotem, a my w tym czasie szukamy przyczyny. W pierwszych dniach po każdym przełączeniu pilnujemy logów, kolejek poczty i monitoringu, bo właśnie wtedy zwykle wychodzą problemy, których nie było widać w testach.

Czy możemy zrezygnować z panelu administracyjnego?

Tak. Możemy przenieść strony z jednego panelu do innego albo na czysty serwer bez panelu, zarządzany przez pliki konfiguracyjne i skrypty. Doradzamy to, co pasuje do osób, które później będą opiekować się serwerem.

Czy po migracji opiekujecie się serwerem?

Jeśli chcecie. Większość klientów po migracji zostaje przy miesięcznej administracji serwerem, w ramach której ten sam zespół zajmuje się aktualizacjami, kopiami zapasowymi, monitoringiem i dalszymi zmianami. W przeciwnym razie dostajecie dokumentację i pełen dostęp, a serwer prowadzicie sami.