System Centralny MHŻP w Warszawie
Wymagania
Stworzenie niezawodnej platformy do uruchamiania Systemu Centralnego muzeum. System centralny działa na dwóch serwerach Windows. Awaria serwera nie może przeszkodzić pracy systemu centralnego. Jeżeli dojdzie do przełączenia systemu w stan awaryjny, to ma w nim pozostać do czasu ingerencji administratora. Macierze mają służyć tylko do przechowywania danych.
Sprzęt
Do wykonania zadania otrzymaliśmy cztery serwery, dwie macierze dyskowe, bibliotekę taśmową, przełączniki optyczne i sieciowe. Całość zamontowana wraz z UPS w firmowej szafie Fujitsu. Serwery zostały połączone z macierzami przy pomocy światłowodów poprzez dwa przełączniki optyczne. Wszystkie serwery mają lokalne dyski do instalacji OS, dwa dodatkowo wewnętrzne macierze dyskowe.
Realizacja
Wybrano rozwiązanie klastrowe na bazie Linuksa. Cztery serwery Suse Linux Enterprise Server (SLES 11SP3) z doinstalowanym rozszerzeniem klastrowym High Availability utworzyły dwa klastry. W jednym przygotowano dwie maszyny wirtualne dla serwerów Windows. W drugim przygotowano sklastrowany system backupu (Bareos) i również sklastrowany serwer pocztowy (Postfix).
Synchronizacja danych
W czasie prac projektowych trzeba było podjąć kilka decyzji:
- jak synchronizować dane (macierze)
- jak synchronizować maszyny wirtualne
Macierze były nowym modelem i nie miały możliwości wewnętrznej/systemowej synchronizacji danych. Zdecydowano się na użycie DRBD do synchronizacji. Rozbudowano dwa serwery o dodatkowe karty sieciowe 10GB/s i połączono je bezpośrednio. Pewne obawy budził spodziewany czas pierwszej pełnej synchronizacji 30TB danych. W praktyce okazało się nie tak źle. Pierwsza synchronizacja uruchomiona jeszcze w trakcie budowy struktury raid5 zakończyła się przed upływem drugiej doby.
Synchronizacja maszyn wirtualnych
Maszyny wirtualne są uruchamiane z lokalnych dysków serwerów. W przeciwieństwie do danych te dyski nie mają być synchronizowane na bieżąco, a tylko po zmianie oprogramowania systemu centralnego – wymaganie twórców aplikacji. Wykorzystano tu również DRBD, ale w specyficznej konfiguracji. Na pierwszym serwerze klaster uruchamia drbd w trybie primary. Na drugim serwerze drbd jest uruchamiane przez administratora wtedy, gdy jest to konieczne w celu zsynchronizowania danych.
Wirtualizacja w klastrze
Jako wirtualizator wybrano qemu/kvm. Maszyny wirtualne mają zdefiniowane kilka dysków. Systemowy (C: w Windows) na lokalnej macierzy jako urządzenie blokowe drbd/lokalny dysk na drugim węźle klastra i dyski z danymi – urządzenia blokowe drbd z macierzy.
Na dyskach systemowych zainstalowano Windows Serwer 2012. Do każdego serwera Windows doinstalowano agenta backupu (Bareos) i serwer ssh. Użycie serwera ssh pozwala klastrowi na skuteczne i bezpieczne wyłączenie Windows poprzez polecenie shutdown.
W obu serwerach utworzono bridge, do którego dołączane są interfejsy sieciowe maszyn wirtualnych. Połączenie z interfejsem fizycznym klastra uzyskano przez iptables. Takie rozwiązanie pozwala na bardzo szybką komunikację między oboma serwerami Windows przy jednoczesnym filtrowaniu ruchu z LAN.
Konfiguracja klastra
W celu uzyskania możliwości automatycznego wyłączania maszyn wirtualnych z Windows zmodyfikowano skrypt Resource Agent, dodając do niego polecenie wyłączania Windows przez ssh. Przeniesienie maszyn wirtualnych na drugi węzeł normalnie jest powodowane awarią węzła lub maszyny wirtualnej widzianej przez kvm. Zgodnie z założeniami projektu jest to niewystarczające. Efektywne sprawdzenie stanu Windows z zewnątrz jest trudne. Przyjęto rozwiązanie, w którym system centralny sam diagnozuje swoje środowisko pracy i w przypadku problemów zamyka jeden z portów swojego interfejsu sieciowego. Specjalnie napisany Resource Agent bada dostępność tego portu i w razie potrzeby tworzy w konfiguracji klastra regułę, która „przykleja” niezbędne zasoby do drugiego węzła. Taka migracja usług zawiera wyłączenie maszyn wirtualnych na pierwszym węźle (serwerze), zmianę kierunku synchronizacji macierzy i uruchomienie maszyn wirtualnych na drugim węźle. Cały proces trwa kilka minut. Po tym czasie system centralny odzyskuje pełną sprawność. Po naprawie i/lub usunięciu przyczyn migracji Administrator usuwa tę regułę i klaster przenosi zasoby na pierwszy serwer odzyskując w ten sposób pożądaną konfigurację.