AWS MGN: replikacja utknęła, rośnie lag, test-launch nie startuje
Naprawa zatrzymanej replikacji AWS MGN: diagnoza stanu agenta i serwera źródłowego, przepustowość sieci i throughput, problemy z uruchomieniem instancji testowej oraz dobór wielkości serwerów replikacyjnych.
Ten runbook opisuje rozwiązywanie problemów z replikacją AWS MGN (Application Migration Service) podczas migracji VMware do AWS. Pełny przewodnik po samej migracji znajdziesz w artykule Migracja VMware do AWS - kompletny przewodnik. W kwestii planowania i realizacji migracji umów konsultację.
Objaw
W konsoli MGN serwer źródłowy stoi w fazie „Initial sync” i nie dochodzi do 100%, albo wraca do resynchronizacji. Typowe sygnały:
# Stan serwerow zrodlowych i faza replikacji (data replication)
aws mgn describe-source-servers \
--query 'items[].{host:sourceProperties.identificationHints.hostname, state:dataReplicationInfo.dataReplicationState, backlog:dataReplicationInfo.replicatedDisks[].backlogedStorageBytes, lag:dataReplicationInfo.lagDuration}' \
--output table
# Typowe wartosci dataReplicationState:
# INITIAL_SYNC - trwa pierwsza synchronizacja
# STALLED - replikacja utknela (najczestszy problem)
# RESCAN - MGN wykryl rozjazd i skanuje dyski od nowa
# CONTINUOUS - stan docelowy (gotowy do przelaczenia)
# Komunikaty widoczne w konsoli / zdarzeniach:
# "Data replication has stalled"
# "Agent has not reported for X minutes"
# "Not enough free disk space on the replication server"
dataReplicationState = STALLED albo lagDuration (opóźnienie replikacji) narasta w czasie zamiast dążyć do zera. W skrajnym przypadku serwer cyklicznie wpada w RESCAN.
Przyczyna
Zatrzymana replikacja MGN i rosnące opóźnienie mają zwykle jedną z czterech przyczyn:
- Przepustowość sieci źródło → AWS: agent replikacyjny wysyła bloki przez port 1500/TCP do serwera replikacyjnego w VPC. Wąskie łącze wychodzące z on-premu, brak przepustowości na Direct Connect/VPN albo dławienie ruchu na firewallu powodują, że zaległość bloków do wysłania rośnie szybciej, niż MGN ją nadrabia. To najczęstsza przyczyna narastającego opóźnienia przy migracji dużych wolumenów.
- Serwer replikacyjny za mały lub bez miejsca na dysku: MGN uruchamia w koncie docelowym lekkie instancje replikacyjne (domyślnie t3.small) z wolumenami staging. Przy wielu równoległych serwerach źródłowych lub dużych dyskach brakuje IOPS-ów albo miejsca na staging - replikacja wpada w STALLED z komunikatem o braku miejsca.
- Agent się rozłącza / nie raportuje: zablokowany port 443 do endpointu MGN, wygasłe poświadczenia użyte przy instalacji agenta, restart maszyny źródłowej albo antywirus blokujący proces agenta powodują, że MGN traci kontakt z serwerem i wstrzymuje replikację.
- Rescan po zmianie na źródle: duża zmiana na dyskach źródłowych (defragmentacja, snapshot VMware, zmiana rozmiaru dysku) wymusza ponowne skanowanie. Powtarzające się RESCAN oznaczają zwykle niestabilne dyski źródłowe albo równolegle działające operacje na VM.
Rozwiązanie
A) Ustal, czy wąskim gardłem jest sieć, czy serwer replikacyjny:
# Backlog i lag per serwer zrodlowy - czy backlog maleje w czasie?
aws mgn describe-source-servers \
--query 'items[].{host:sourceProperties.identificationHints.hostname, state:dataReplicationInfo.dataReplicationState, lag:dataReplicationInfo.lagDuration, etaDateTime:dataReplicationInfo.etaDateTime}' \
--output table
# Jesli backlog stoi lub rosnie -> siec lub serwer replikacyjny.
# Sprawdz throughput z maszyny zrodlowej do endpointu replikacji (port 1500):
# iperf3 / nc do IP serwera replikacyjnego w VPC
# oraz drop-y na firewallu on-prem dla portow 443 (MGN API) i 1500 (dane).
B) Wąskie gardło sieciowe - ograniczenie przepustowości i okno replikacji:
# Ogranicz throughput per serwer, zeby nie zapchac lacza produkcyjnego w dzien,
# i pozwol nadrabiac w nocy (ustawienie w szablonie replikacji).
aws mgn update-replication-configuration \
--source-server-id s-1234567890abcdef0 \
--bandwidth-throttling 500 # Mbps; 0 = bez limitu
# Uzyj prywatnej sciezki (Direct Connect / VPN) zamiast publicznej,
# aby uniknac limitow i kosztow transferu przez internet:
aws mgn update-replication-configuration \
--source-server-id s-1234567890abcdef0 \
--use-dedicated-replication-server \
--create-public-ip false
C) Serwer replikacyjny za mały - zwiększ klasę i typ dysków staging:
# Zmien domyslny typ instancji serwera replikacyjnego i dyskow staging
# w szablonie (dotyczy nowo tworzonych serwerow replikacyjnych):
aws mgn update-replication-configuration-template \
--replication-configuration-template-id rct-1234567890abcdef0 \
--replication-server-instance-type t3.large \
--default-large-staging-disk-type GP3 \
--use-dedicated-replication-server
# Dla juz istniejacego serwera zrodlowego wymus odtworzenie serwera
# replikacyjnego po zmianie ustawien:
aws mgn update-replication-configuration \
--source-server-id s-1234567890abcdef0 \
--replication-server-instance-type t3.large \
--default-large-staging-disk-type GP3
D) Agent się rozłącza - odblokuj łączność i przeinstaluj agenta:
# Na maszynie zrodlowej sprawdz lacznosc do endpointow MGN (Linux):
curl -v https://mgn.eu-west-1.amazonaws.com 2>&1 | head -20 # port 443 - API
nc -vz <IP_serwera_replikacyjnego> 1500 # port 1500 - dane
# Wymagane reguly wyjsciowe z maszyny zrodlowej:
# 443/TCP -> mgn.<region>.amazonaws.com (rejestracja i sterowanie)
# 1500/TCP -> serwer replikacyjny w subnecie staging (transfer blokow)
# Jesli agent nie raportuje - przeinstaluj agenta swiezymi poswiadczeniami:
sudo python3 aws-replication-installer-init.py \
--region eu-west-1 \
--aws-access-key-id AKIA... \
--aws-secret-access-key ... \
--no-prompt
# Uzyj dedykowanego uzytkownika IAM z polityka AWSApplicationMigrationAgentPolicy,
# nie kluczy administracyjnych.
E) Powtarzające się RESCAN - ustabilizuj dyski źródłowe:
# Wstrzymaj na czas migracji operacje generujace duze zmiany blokow na VM:
# - snapshoty VMware w petli / backupy z change block tracking
# - defragmentacje, zmiany rozmiaru dyskow, przenosiny datastore
# Jesli rescan wynika z realnej zmiany rozmiaru dysku na zrodle,
# MGN musi przeskanowac go od nowa - zaplanuj to poza oknem przelaczenia.
Prewencja: uruchom replikację z wyprzedzeniem (dni, nie godziny przed przełączeniem) i monitoruj lagDuration od pierwszego dnia. Dla dużych wolumenów użyj prywatnej ścieżki sieciowej i ograniczenia przepustowości dopasowanego do łącza. Wykonaj próbne uruchomienie instancji na kilka dni przed właściwym przełączeniem - błędy uruchamiania systemu (sterowniki, bootloader) łatwiej naprawić bez presji okna.
Walidacja
# 1. Wszystkie serwery zrodlowe w stanie CONTINUOUS, lag bliski zera
aws mgn describe-source-servers \
--query 'items[].{host:sourceProperties.identificationHints.hostname, state:dataReplicationInfo.dataReplicationState, lag:dataReplicationInfo.lagDuration}' \
--output table
# Oczekiwane: dataReplicationState = "CONTINUOUS", lag = "PT0S" lub bliski zera
# 2. Probne uruchomienie instancji i weryfikacja startu bez wplywu na przelaczenie
aws mgn start-test \
--source-server-ids s-1234567890abcdef0
# Nastepnie w EC2 sprawdz status checks instancji testowej:
aws ec2 describe-instance-status \
--instance-ids i-0test... \
--query 'InstanceStatuses[0].{sys:SystemStatus.Status, inst:InstanceStatus.Status}'
# Oczekiwane: sys = "ok", inst = "ok"; maszyna sie uruchamia i jest osiagalna
# 3. Po udanym tescie oznacz i posprzataj instancje testowa
aws mgn mark-as-archived --source-server-id s-1234567890abcdef0 # dopiero po przelaczeniu
Jeśli wszystkie serwery są w stanie CONTINUOUS, opóźnienie jest stabilnie bliskie zera, a instancja testowa uruchamia się i przechodzi status checks - replikacja jest gotowa do przełączenia. Utrzymuj replikację w trybie ciągłym aż do zaplanowanego przełączenia.
Migracja VMware do AWS się przeciąga?
Umów bezpłatną 30-minutową rozmowę. Przejrzymy konfigurację MGN, sieć replikacji i dobór wielkości serwerów, i doprowadzimy migrację do czystego przełączenia.