AWS SAP SAP HANA EC2 migracja

SAP HANA na EC2: usługi nie wstają po przełączeniu do AWS

Naprawa startu SAP HANA na EC2 po migracji do AWS: diagnoza usług hdbnsutil, dławienia IOPS/throughput na wolumenach danych i logów, doboru certyfikowanej klasy instancji oraz doboru pamięci.

Jerzy Kopaczewski · 2026-09-12

Migracja SAP do AWS przeszła etap kopiowania danych, instancja EC2 wstała, ale HANA nie podnosi usług - `sapcontrol` pokazuje procesy w stanie GRAY/YELLOW, indexserver się nie uruchamia, albo baza startuje i po chwili pada na dławieniu przepustowości dysków. Aplikacja SAP jest niedostępna, a okno przełączenia się kurczy. Ten runbook pokazuje, jak zdiagnozować i naprawić start HANA na EC2 po migracji.

Ten runbook opisuje rozwiązywanie problemów ze startem SAP HANA na EC2 po migracji do AWS. Pełny przewodnik po samej migracji znajdziesz w artykule Migracja SAP do AWS - przewodnik. W kwestii architektury SAP na AWS i planowania przełączenia produkcji umów konsultację.

Objaw

Instancja EC2 działa, ale HANA nie osiąga stanu „wszystkie usługi zielone”. Typowe sygnały:

# Status procesow HANA (jako <sid>adm)
sapcontrol -nr 00 -function GetProcessList
# Typowe:
#   hdbnameserver   GREEN
#   hdbindexserver  GRAY/YELLOW  <- nie startuje lub cyklicznie restartuje
#   hdbcompileserver, hdbpreprocessor ...

# Log startu bazy (najwazniejsze linie)
tail -n 80 /usr/sap/<SID>/HDB00/<hostname>/trace/nameserver_*.trc
tail -n 80 /usr/sap/<SID>/HDB00/<hostname>/trace/indexserver_*.trc

# Typowe komunikaty:
# "topology mismatch" / "hostname ... not found in landscape"     -> hdbnsutil
# "insufficient memory" / "global allocation limit"               -> sizing pamieci
# "disk full" / "log volume ... write error"                      -> wolumeny/IOPS
# "I/O ... throttled" / dlugie fsync w perftop                    -> throughput EBS

Procesy HANA nie dochodzą do GREEN, indexserver nie startuje lub restartuje się w pętli, albo baza startuje i pada pod obciążeniem I/O.

Przyczyna

Nieudany start HANA na EC2 po migracji ma zwykle jedną z czterech przyczyn:

Niezgodność topologii/hostname (hdbnsutil): po przeniesieniu na nowy host HANA wciąż trzyma w konfiguracji stary hostname/landscape. Nameserver startuje, ale indexserver nie potrafi zmapować topologii - typowe zaraz po rehostingu lub restore z backupu na inną maszynę.
Dławienie IOPS/przepustowości na wolumenach danych i logów: wolumeny gp3 z domyślnymi 3000 IOPS / 125 MB/s nie wystarczają dla produkcyjnego HANA. Wolumen logów głoduje na przepustowości, fsync się wydłuża, a baza pada lub działa skrajnie wolno. Częsty błąd przy migracji „1:1” bez dostrojenia EBS.
Niecertyfikowana lub źle dobrana klasa instancji: HANA jest wspierana tylko na certyfikowanych typach (rodziny z dużą pamięcią, np. r5/r6i/x2/High Memory). Uruchomienie na niecertyfikowanej lub za małej pamięciowo instancji kończy się błędem alokacji pamięci lub odmową startu przy sprawdzaniu wsparcia.
Źle dobrana pamięć względem instancji: parametr global_allocation_limit albo faktyczny rozmiar bazy przekracza pamięć instancji dobraną „na oko”. HANA trzyma dane w RAM - za mała instancja to insufficient memory przy ładowaniu kolumn.

Rozwiązanie

A) Ustal, czy to topologia, pamięć, czy I/O:

# Szybka triage z logow startu - ktora klasa problemu
grep -Ei 'topology|landscape|hostname' /usr/sap/<SID>/HDB00/*/trace/nameserver_*.trc | tail
grep -Ei 'insufficient memory|allocation limit'   /usr/sap/<SID>/HDB00/*/trace/indexserver_*.trc | tail
grep -Ei 'disk full|write error|I/O|throttl'       /usr/sap/<SID>/HDB00/*/trace/*.trc | tail

# Pamiec instancji vs oczekiwania HANA
free -g
cat /usr/sap/<SID>/SYS/global/hdb/custom/config/global.ini | grep -A2 memorymanager

B) Niezgodność topologii - przemapuj hostname (hdbnsutil):

# Jako <sid>adm - zatrzymaj HANA, zaktualizuj topologie na nowy host
HDB stop
hdbnsutil -convertTopology                 # przy zmianie hosta po migracji/restore
# lub jawna zmiana nazwy hosta w landscape:
hdbnsutil -renameSystem \
  --source=<STARY_HOST>:<SID>:00 \
  --target=<NOWY_HOST>:<SID>:00
HDB start
sapcontrol -nr 00 -function GetProcessList  # indexserver powinien dojsc do GREEN

C) Dławienie I/O - dostrój wolumeny EBS danych i logów:

# Podnies IOPS i throughput na wolumenie logow (gp3) - log jest najbardziej wrazliwy
aws ec2 modify-volume \
  --volume-id vol-log0123456789 \
  --iops 16000 \
  --throughput 1000        # MB/s

# Wolumen danych - IOPS/throughput wg rozmiaru bazy (dla duzych baz rozwaz io2 Block Express)
aws ec2 modify-volume --volume-id vol-data0123456789 --iops 20000 --throughput 1000

# Zweryfikuj po stronie OS, ze system plikow widzi nowa wydajnosc (XFS zalecany dla HANA)
iostat -xm 5 3
# Sprawdz, czy /hana/log i /hana/data sa na osobnych wolumenach - wspoldzielenie to typowy blad.

D) Klasa instancji i dobór pamięci - wybierz certyfikowany typ:

# Zmien typ na certyfikowany dla HANA (przyklad: r6i.4xlarge; dla duzych baz x2idn/High Memory)
aws ec2 stop-instances  --instance-ids i-0hana...
aws ec2 modify-instance-attribute --instance-id i-0hana... --instance-type r6i.4xlarge
aws ec2 start-instances --instance-ids i-0hana...

# Dopasuj global_allocation_limit do pamieci instancji (jako <sid>adm), np. ~90% RAM:
hdbparam --paramset memorymanager.global_allocation_limit=<MB>
# Regula: instancja musi miec RAM >= rozmiar danych w pamieci + bufory + system operacyjny.
# Certyfikacje typow sprawdz w SAP Note / AWS przed zmiana - niecertyfikowany typ nie jest wspierany.

Prewencja: dobierz instancję i wolumeny na etapie planowania na podstawie rzeczywistego zapotrzebowania HANA na zasoby (raport SAP HANA sizing / dane w pamięci), nie „1:1” z on-premu. Rozdziel /hana/data i /hana/log na osobne wolumeny z zapasem IOPS i przepustowości. Wykonaj próbny start i test obciążeniowy na kilka dni przed przełączeniem - błędy topologii i dławienia I/O łatwiej naprawić bez presji okna. Używaj wyłącznie certyfikowanych dla HANA typów instancji.

Walidacja

# 1. Wszystkie procesy HANA w stanie GREEN
sapcontrol -nr 00 -function GetProcessList
# Oczekiwane: hdbnameserver, hdbindexserver, hdbcompileserver, hdbpreprocessor = GREEN

# 2. Baza przyjmuje polaczenia i odpowiada na zapytanie kontrolne
hdbsql -n localhost:30015 -u SYSTEM -p '<haslo>' \
  "SELECT SERVICE_NAME, ACTIVE_STATUS FROM SYS.M_SERVICES"
# Oczekiwane: wszystkie uslugi ACTIVE = 'YES'

# 3. Brak dlawienia I/O pod obciazeniem (log i data)
iostat -xm 5 3
# Oczekiwane: %util wolumenu logow nie utrzymuje sie przy 100%, await niski i stabilny

# 4. Alokacja pamieci miesci sie w limicie, brak "insufficient memory" w trace
hdbsql -n localhost:30015 -u SYSTEM -p '<haslo>' \
  "SELECT HOST, ROUND(USED_PHYSICAL_MEMORY/1024/1024/1024) AS used_gb, ROUND(ALLOCATION_LIMIT/1024/1024/1024) AS limit_gb FROM SYS.M_HOST_RESOURCE_UTILIZATION"
# Oczekiwane: used_gb < limit_gb z zapasem

Jeśli wszystkie procesy HANA są GREEN, baza przyjmuje połączenia, nie ma dławienia I/O pod obciążeniem, a pamięć mieści się w limicie - system jest gotowy do przełączenia warstwy aplikacyjnej SAP. Wykonaj test obciążeniowy reprezentatywny dla produkcji przed właściwym przełączeniem.

HANA, która nie startuje po migracji, zatrzymuje całe środowisko SAP - warstwa aplikacyjna nie ma się do czego podłączyć, a przy migracji z wymogiem minimalnego przestoju to bezpośrednie ryzyko przesunięcia terminu. Groźniejszy jest scenariusz, w którym baza startuje na za małych wolumenach i pada dopiero pod produkcyjnym obciążeniem - już po przełączeniu, gdy system on-prem jest wyłączony. Dlatego dobór wielkości instancji i EBS oraz test obciążeniowy wykonuje się przed przełączeniem, nie po nim.

SAP HANA nie startuje po migracji na EC2?

Umów bezpłatną 30-minutową rozmowę. Przejrzymy topologię HANA, dobór wielkości instancji i konfigurację wolumenów, i doprowadzimy migrację SAP do czystego przełączenia.

Umów rozmowę