Jak przenieść serwer lokalny do AWS (Prosty podręcznik)

Wprowadzenie

Migracje z on-prem do AWS rzadziej kończą się niepowodzeniem z powodu obliczeń, a bardziej z powodu luk w planowaniu: niejasne cele przełączenia, pominięte zależności i pośpieszne testy. Ten przewodnik sprawia, że proces jest łatwy do śledzenia, pozostając jednocześnie operacyjnym. Zdefiniujesz, jak wygląda sukces, przygotujesz minimalną strefę lądowania, przeprowadzisz testowe uruchomienia AWS MGN, pewnie przełączysz się, a następnie zoptymalizujesz obciążenie po jego uruchomieniu.

Co powinieneś zdecydować przed migracją czegokolwiek?

Która strategia migracji pasuje do tego serwera (AWS "7 Rs")?

Naj szybszym sposobem na stracenie czasu jest migracja niewłaściwej rzeczy. Zanim zainstalujesz jakikolwiek agent, zdecyduj, jaka strategia migracji przysługuje serwerowi, aby nie przenosić czegoś, co powinno zostać wycofane lub zastąpione. W praktyce wiele zespołów zaczyna od rehosting dla szybkości, a następnie optymalizuje później, gdy obciążenie jest stabilne w AWS.

Jednak to działa tylko wtedy, gdy serwer jest dobrym kandydatem "takim, jakim jest" i nie stworzy kosztownego długu technicznego natychmiast po przełączeniu. Praktyczne skróty decyzyjne:

• Rehosting: działaj szybko przy minimalnych zmianach, gdy czas jest ograniczony.
• Replatforming: zachowaj aplikację, ale wprowadź drobne dostosowania do pasowania do AWS.
• Refaktoryzacja: zarezerwuj wysiłek na kluczowe różnice dla biznesu.
• Odkupienie: zastąp tym SaaS zamiast migrowania serwera.
• Zrezygnować/Zachować: usuń nieużywane systemy lub utrzymuj ograniczone obciążenia lokalnie.

Przydatnym wewnętrznym punktem kontrolnym jest zapytanie, czy obciążenie ma „chmurową przyszłość”. Jeśli serwer zostanie później rozłożony na usługi zarządzane lub konteneryzowane, udokumentuj to teraz i traktuj rehosting jako tymczasowy krok, a nie stały projekt.

Jakie są RTO/RPO, okno przestoju i wyzwalacze przywracania?

Przejścia udają się, gdy sukces jest mierzalny. Zdefiniuj akceptowalny czas przestoju i tolerancję na utratę danych, a następnie zapisz warunki, które wymuszają powrót do poprzedniego stanu. To utrzymuje cel migracji i zapobiega improwizacji zespołów w trakcie okna przejścia. Pomaga to również interesariuszom biznesowym w zatwierdzeniu, ponieważ mogą dokładnie zobaczyć, jakie ryzyko jest akceptowane.

Zdefiniuj i udokumentuj:

• RTO: maksymalny dopuszczalny czas przestoju.
• RPO: maksymalna dopuszczalna utrata danych.
• Okno przestoju: kiedy możesz przełączyć ruch produkcyjny.
• Wyzwalacze przywracania: specyficzne warunki awarii (przerwa w autoryzacji, nieudane transakcje, niezgodność danych).
• Mechanizm przełączenia: DNS flip, przełącznik równoważenia obciążenia, zmiany w routingu/zaporze.

Aby utrzymać plan przywracania w realistyczny sposób, określ, kto odpowiada za każde działanie podczas przejścia. Na przykład, jedna osoba odpowiada za zmiany DNS, jedna za walidację aplikacji, a jedna za „decyzję o przywróceniu” na podstawie powyższych wyzwalaczy.

Co musisz mieć gotowe w AWS i na miejscu jako pierwsze?

Podstawy łączności i zapory ogniowej dla replikacji

Replikacja działa tylko wtedy, gdy źródłowe środowisko może konsekwentnie łączyć się z AWS. Najczęstszymi przeszkodami są surowe kontrole wyjścia, serwery proxy oraz inspekcja TLS, które zakłócają wychodzący ruch HTTPS. Sprawdź łączność wcześnie i utrzymuj stabilną ścieżkę sieciową podczas początkowej replikacji i testów uruchomieniowych. W wielu środowiskach replikacja nie jest całkowicie „zablokowana”; zamiast tego, sporadyczne przerwy lub inspekcja pakietów powodują niestabilne zachowanie, które jest trudne do zdiagnozowania później.

Typowe wzorce łączności:

• Publiczny dostęp do internetu (najprostszy, gdy jest dozwolony)
• VPN site-to-site (często stosowane w przypadku prywatnej łączności)
• Bezpośrednie połączenie (bardziej przewidywalne dla większych środowisk)

Kontrole przed lotem:

• Outbound HTTPS działa niezawodnie z sieci źródłowej
• Zachowanie proxy jest rozumiane i testowane w ramach przepływu migracji
• Zespoły bezpieczeństwa zatwierdzają wymagany ruch wychodzący na okno migracji

Jeśli Twoje środowisko jest mocno zabezpieczone, dodaj krótki krok „weryfikacji sieci” do swojego planu falowego: zweryfikuj punkty końcowe z jednego serwera pilota, a następnie powiel dokładnie ten zestaw reguł dla reszty fali.

Minimalna lista kontrolna strefy lądowania AWS

Nie potrzebujesz idealnej strefy lądowania, aby zacząć, ale potrzebujesz spójnego celu, który nie zmieni się w trakcie fali. Utrzymuj budowę minimalną, ale przemyślaną, aby testowanie odzwierciedlało to, jak będzie wyglądać przełączenie. Wiele problemów z migracją wynika z "tymczasowych" skrótów sieciowych, które stają się trwałe, ponieważ nikt nie ma czasu, aby je odbudować po uruchomieniu.

Minimalne elementy strefy lądowania:

• A VPC i podsieci gdzie instancje będą uruchamiane (często oddzielne testowe vs produkcyjne)
• Grupy zabezpieczeń dostosowane do rzeczywistych przepływów aplikacji (unikaj „otwórz teraz, napraw później”)
• IAM gotowy na operacje migracyjne oraz dostęp i narzędzia drugiego dnia
• Podstawowy tagowanie więc własność i śledzenie kosztów są jasne po przejściu na nowy system

Pomaga to również wczesne podjęcie decyzji, w jaki sposób administratorzy będą uzyskiwać dostęp do instancji (bastion, VPN , SSM) oraz w jaki sposób będzie zapewniony dostęp do internetu (brama NAT, proxy). Te wybory wpływają na łatanie, agenty monitorujące i rozwiązywanie problemów od pierwszego dnia.

Lista kontrolna gotowości serwera źródłowego

Czysta migracja zależy od czystego źródła. Potwierdź, że obciążenie jest zgodne z metodą, którą wybrałeś, a następnie zidentyfikuj wszystko, co zależy od lokalnych założeń, które zmienią się w AWS. To również miejsce, w którym oznaczasz serwery "specjalnego przypadku", które mogą wymagać innej sekwencji. Na przykład serwer plików z intensywną aktywnością zapisu może potrzebować węższego okna przełączenia i surowszej weryfikacji otwartych plików i udziałów.

Kontrole gotowości, które zapobiegają niespodziankom:

• Kompatybilność systemu operacyjnego/obciążenia z podejściem do migracji
• Wystarczająca przestrzeń dyskowa i stabilne I/O dla narzutu replikacji
• Zależności mapowane: DNS , AD/LDAP , wewnętrzny PKI/certyfikaty , bazy danych, udostępnienia
• Ukryta kruchość: twardo zakodowane IP, przestarzałe TLS, rzadkie zadania zaplanowane
• Specjalne przypadki oznaczone wcześniej: kontrolery domen, klastry, urządzenia, licencjonowanie dongli

Zanim opuścisz ten krok, uchwyć elementy, które „muszą pozostać takie same”, takie jak wymagania dotyczące nazwy hosta, adresu IP lub powiązań certyfikatów, ponieważ mają one bezpośredni wpływ na ustawienia uruchamiania AWS i sekwencję przełączenia.

Jak przenieść serwer do AWS za pomocą AWS MGN?

Zainicjuj MGN i ustaw domyślne wartości replikacji

Zainicjuj AWS MGN w regionie, w którym będzie działał serwer, a następnie zdefiniuj domyślne ustawienia replikacji, aby wykonanie fali pozostało spójne. Stabilny szablon zmniejsza zmienność na poziomie serwera i sprawia, że rozwiązywanie problemów jest powtarzalne. Traktuj to jako swoją standardową procedurę operacyjną dla replikacji, podobnie jak złoty obraz w wirtualnym środowisku.

Ustaw domyślne wartości replikacji z góry:

• Strategia docelowej podsieci i rozmieszczenie sieci
• Podstawowa grupa zabezpieczeń dla uruchomionych instancji
• Zachowanie przechowywania (mapowanie woluminów, szyfrowanie oczekiwania)
• Ograniczanie replikacji w celu ochrony ruchu produkcyjnego

Jeśli już wiesz, że produkcja będzie wymagała innych ustawień niż testowanie, zdefiniuj te różnice wyraźnie. W ten sposób uruchomienia testowe pozostaną reprezentatywne, nie narażając sieci produkcyjnych na wcześniejsze ujawnienie.

Zainstaluj agenta i zakończ początkową synchronizację

Zainstaluj agenta replikacji na serwerze źródłowym i potwierdź, że rejestruje się pomyślnie. Początkowa synchronizacja to moment, w którym niestabilność kosztuje najwięcej, więc unikaj niepotrzebnych zmian i uważnie monitoruj stan replikacji. To również moment, w którym zespoły korzystają z dokumentowania "znanego dobrego" procesu instalacji, aby nie rozwiązywać tych samych problemów w każdej fali.

Wskazówki operacyjne:

• Zachowaj stabilność serwera podczas początkowej replikacji (unikaj ponownych uruchomień, jeśli to możliwe)
• Monitoruj status replikacji i natychmiast rozwiązuj błędy
• Dokumentuj metodę instalacji, aby przyszłe fale były spójne.

Podczas początkowej synchronizacji monitoruj nie tylko konsolę migracji, ale także wydajność serwera. Nadmiar replikacji może ujawnić wąskie gardła w magazynie lub błędy dysku, które wcześniej były ukryte w środowisku lokalnym.

Uruchom instancję testową i zweryfikuj

Test uruchomieniowy zamienia założenia w dowody. Uruchom instancję testową, a następnie zweryfikuj zdrowie aplikacji od początku do końca, a nie tylko sukces uruchomienia. Użyj listy kontrolnej, aby testowanie było powtarzalne na różnych serwerach i falach. Jeśli użytkownicy końcowi będą się łączyć przez TSplus Zdalny Dostęp włącz sprawdzenie ścieżki dostępu w walidacji. Spójność ma znaczenie, ponieważ pozwala na porównanie wyników między obciążeniami i dostrzeganie wzorców, takich jak problemy z rozwiązywaniem DNS wpływające na wiele serwerów.

Minimalna lista kontrolna walidacji:

• Uruchamianie kończy się, a usługi startują poprawnie
• Testy dymne aplikacji przechodzą dla kluczowych przepływów pracy
• Uwierzytelnianie działa (AD/LDAP/lokalnie)
• Ścieżki danych działają (połączenia DB, udostępnianie plików, integracje)
• Zadania zaplanowane i usługi w tle działają zgodnie z oczekiwaniami
• Logi i monitorowanie sygnałów pojawiają się tam, gdzie oczekuje ich zespół operacyjny

Dodaj jeszcze jeden krok, który zespoły często pomijają: zweryfikuj, w jaki sposób użytkownicy faktycznie uzyskają dostęp do aplikacji, w tym wewnętrzne routowanie, zasady zapory i wszelkie systemy upstream. Serwer może być „zdrowy”, ale w praktyce niedostępny.

Uruchom przełączenie i sfinalizuj

Cutover to kontrolowane przełączenie, a nie skok na głęboką wodę. Zamroź zmiany, gdy to możliwe, wykonaj przeniesienie ruchu za pomocą zaplanowanego mechanizmu, a następnie zweryfikuj, używając tej samej listy kontrolnej co podczas testowania. Utrzymuj wyraźne prawo do cofnięcia, aby decyzje były szybkie. Traktuj to jako powtarzalny podręcznik: im mniej improwizujesz, tym mniejsze ryzyko.

Podstawowe informacje dotyczące wykonania przełączenia:

• Potwierdź plan zamrożenia zmian i komunikacji
• Uruchom instancję przełączenia i przełącz ruch (DNS/LB/routing)
• Ponownie uruchom listę kontrolną walidacji z dodatkowym naciskiem na integralność danych
• Zastosuj wyzwalacze przywracania, jeśli to konieczne, i przywróć ruch w sposób czysty.
• Zakończ migrację i usuń lub zakończ zasoby testowe

Natychmiast po przełączeniu, zarejestruj, co zmieniło się w produkcji (nowe adresy IP, nowe trasy, nowe zasady grupy zabezpieczeń) i udokumentuj to. To jest informacja, której zespół operacyjny potrzebuje, gdy coś się zepsuje tygodnie później.

Co zazwyczaj się psuje i co powinieneś zrobić zaraz po przełączeniu?

Egress sieciowy, zależności DNS/AD i „przeniesienie nie zostało zakończone”

Większość awarii to awarie zależności. Replikacja ma tendencję do łamania się na ograniczeniach wyjścia i proxy, podczas gdy zachowanie aplikacji ma tendencję do łamania się na tożsamości, rozwiązywaniu nazw i certyfikatach. Nawet gdy przełączenie się powiedzie, rehosting to tylko pierwszy kamień milowy, a nie stan końcowy. Bez drugiej fazy często kończysz z "dziedzictwem hostowanym w chmurze", które kosztuje więcej i jest trudniejsze w obsłudze.

Najczęstsze punkty przerwania:

• Outbound HTTPS zablokowany lub zmieniony przez proxy inspekcja TLS
• Zmiany w rozwiązywaniu DNS (problemy z podziałem horyzontu, brakujące zasady rozwiązywania)
• Luki w dostępności AD/LDAP z VPC
• Brak zaufanych lub brakujących wewnętrznych łańcuchów PKI w nowym środowisku
• Trudno zakodowane punkty końcowe i przestarzałe założenia dotyczące lokalnych ścieżek sieciowych

Prostym rozwiązaniem jest wczesne przetestowanie tożsamości i DNS podczas pilotażowego uruchomienia. Jeśli te podstawy działają, reszta walidacji aplikacji staje się znacznie bardziej przewidywalna.

Stabilizacja po migracji: bezpieczeństwo, kopie zapasowe, monitorowanie, koszty

Pierwsze 48 godzin po przełączeniu powinny koncentrować się na stabilności i kontroli. Upewnij się, że obciążenie jest obserwowalne, możliwe do odzyskania i zarządzane w sposób bezpieczny, zanim poświęcisz czas na głębszą optymalizację. To również tutaj twoja migracja odnosi długoterminowy sukces, ponieważ dobre operacje drugiego dnia zapobiegają wynikom „przenieśliśmy to, ale nikt nie chce się tym zająć”.

Natychmiastowe działania po przełączeniu:

• Potwierdź, że monitorowanie/alertowanie jest aktywne i przypisane.
• Upewnij się, że kopie zapasowe są włączone i zakończona walidacja przywracania
• Zacieśnij grupy zabezpieczeń i zastosuj zasadę najmniejszych uprawnień IAM
• Standaryzacja podejścia do łatania i dostępu administracyjnego (ścieżki audytowalne)
• Rozpocznij dostosowywanie po zebraniu rzeczywistych danych dotyczących wykorzystania
• Wymuś tagowanie, aby zapobiec dryfowi kosztów „nieznanego właściciela”

Gdy stabilność zostanie potwierdzona, zaplanuj krótką recenzję optymalizacji dla każdego migrowanego serwera. Nawet lekkie przeglądanie typów pamięci, wyboru rodziny instancji i strategii rezerwowanej pojemności może znacznie obniżyć koszty.

Gdzie pasuje TSplus po przeniesieniu serwerów do AWS?

Po uruchomieniu obciążeń systemu Windows na AWS, wiele zespołów nadal potrzebuje prostego sposobu na publikowanie aplikacji i pulpitów systemu Windows dla użytkowników bez budowania ciężkiego stosu VDI. TSplus Zdalny Dostęp dostarcza publikację aplikacji i zdalny dostęp do pulpitu dla serwerów Windows w AWS, w lokalnych lub hybrydowych środowiskach, z prostą administracją i przewidywalnym licencjonowaniem, które pasuje do operacji SMB i średniego rynku.

Wniosek

Migracja serwera lokalnego do AWS jest najbardziej udana, gdy przebiega zgodnie z powtarzalnym podręcznikiem: wybierz odpowiednią strategię migracji, zweryfikuj zależności, replikuj bezpiecznie, testuj realistycznie i przełącz się z wyraźnymi wyzwalaczami przywracania. Gdy produkcja jest stabilna, skoncentruj się na operacjach drugiego dnia: wzmocnienie bezpieczeństwa, weryfikacja kopii zapasowych, monitorowanie i dostosowywanie zasobów. To przekształca "przeniesienie" w niezawodną, kontrolowaną kosztowo platformę.