Muzeum POLIN: wdrożenie klastrów HA dla Systemu Centralnego

Realizacja: zespół techniczny Delkomtech · Wdrożenia i realizacje · Historyczny projekt, opracowanie zaktualizowane 1 listopada 2026 r.

Za multimedialną opowieścią o tysiącu lat historii stoi infrastruktura, której zwiedzający nie widzi. Dla Muzeum Historii Żydów Polskich POLIN w Warszawie przygotowaliśmy zaplecze wysokiej dostępności Systemu Centralnego: cztery serwery, dwa klastry HA, dwie macierze oraz mechanizmy synchronizacji i przełączania usług dopasowane do aplikacji wystawy.

Była to realizacja łącząca dostawę sprzętu, instalację systemów, wirtualizację i konfigurację rozwiązań klastrowych z pracą nad zachowaniem całej aplikacji w sytuacji awarii. Delkomtech realizował tę część projektu jako podwykonawca firmy 3Logic sp. z o.o., odpowiadając za infrastrukturę serwerową i klastrową Systemu Centralnego. Platforma stanowiła zaplecze Systemu Centralnego wspierającego środowisko setek miniaplikacji obsługujących wystawę.

Prestiżowe muzeum, duża skala multimediów

Wystawę stałą „1000 lat historii Żydów polskich” otwarto 28 października 2014 roku. W uroczystości uczestniczyli prezydent Polski Bronisław Komorowski i prezydent Izraela Reuven Rivlin oraz delegacje z wielu państw. To kontekst, który dobrze oddaje rangę przedsięwzięcia — dla nas również odpowiedzialność za przygotowanie jego zaplecza technicznego. Datę i uczestników otwarcia opisuje oficjalna historia Muzeum POLIN.

Branżowe opracowanie wystawy wskazuje ponad 4000 m² ekspozycji i ponad 230 stanowisk multimedialnych, w tym 84 interaktywne. Liczby te opisują całą wystawę i pokazują środowisko, w którym pracował System Centralny. Naszym zakresem była infrastruktura serwerowa i klastrowa tego systemu. Więcej o skali ekspozycji można przeczytać w archiwalnym opisie technicznym AVIntegracje.

Wyzwanie: dostępność Systemu Centralnego także po awarii

System Centralny pracował na dwóch serwerach Windows, uruchomionych jako maszyny wirtualne. Projekt wymagał przygotowania platformy, która po awarii węzła lub wykryciu problemu z aplikacją przejmie obsługę usług na drugim węźle. Ważna była zarówno możliwość przełączenia, jak i jego właściwa kolejność: zamknięcie systemów, przygotowanie danych i ponowne uruchomienie aplikacji.

Istotnym wymaganiem było też zachowanie po awarii. Po przeniesieniu usług środowisko miało pozostać na drugim węźle do czasu interwencji administratora. Powrót do konfiguracji podstawowej następował po usunięciu przyczyny problemu i świadomej decyzji osoby odpowiedzialnej za system.

Zakres wdrożenia: od sprzętu po działające usługi

Przygotowaliśmy kompletną warstwę infrastruktury objętą naszym zakresem: sprzęt serwerowy i pamięci masowe, połączenia, systemy operacyjne, wirtualizację, klastry oraz konfigurację usług. Środowisko obejmowało:

• cztery serwery fizyczne z lokalnymi dyskami systemowymi; dwa z nich również z wewnętrznymi macierzami dyskowymi;
• dwie zewnętrzne macierze dyskowe i bibliotekę taśmową;
• dwa przełączniki optyczne oraz przełączniki sieciowe;
• połączenia światłowodowe między serwerami a macierzami;
• zasilanie awaryjne UPS i zabudowę w szafie Fujitsu.

Na serwerach zainstalowaliśmy SUSE Linux Enterprise Server 11 SP3 z rozszerzeniem High Availability. Cztery serwery utworzyły dwa klastry, z wyraźnym podziałem zadań.

30 TB danych: synchronizacja bez natywnej replikacji macierzy

Użyty model macierzy nie oferował wtedy wewnętrznego mechanizmu synchronizacji danych. Rozwiązaliśmy to na poziomie infrastruktury serwerowej, wykorzystując DRBD do replikacji blokowej. Dwa serwery rozbudowano o dodatkowe karty sieciowe i połączono bezpośrednim, szybkim łączem przeznaczonym do synchronizacji.

Skala danych wymagała uwzględnienia czasu pierwszego pełnego wyrównania zawartości. Synchronizację 30 TB uruchomiono jeszcze podczas budowy struktury RAID 5. Zakończyła się przed upływem drugiej doby. To wynik konkretnego etapu uruchomienia opisanego środowiska; dobrze pokazuje, dlaczego przepływ danych i czas inicjalizacji muszą być częścią projektu klastra.

Wirtualizacja KVM dopasowana do wymagań aplikacji

W warstwie wirtualizacji zastosowaliśmy QEMU/KVM. Dwie maszyny Windows Server 2012 korzystały z dysków systemowych umieszczonych lokalnie oraz z przestrzeni danych udostępnianej z macierzy przez urządzenia blokowe DRBD. Pozwoliło to oddzielnie potraktować systemy operacyjne i dane aplikacji.

Twórcy Systemu Centralnego wymagali, aby dyski systemowe maszyn wirtualnych synchronizować po zmianach oprogramowania, zamiast replikować je stale. Także tutaj wykorzystaliśmy DRBD, z konfiguracją i uruchamianiem synchronizacji dostosowanymi do tej procedury. Agenci Bareos obsługiwali kopie zapasowe wewnątrz systemów Windows.

Komunikację maszyn wirtualnych przygotowano przy użyciu mostów sieciowych oraz filtrowania ruchu przez iptables. Klaster otrzymał także możliwość kontrolowanego zamknięcia systemów Windows przez SSH. Każdy z tych elementów służył temu, aby przełączenie obejmowało cały działający układ usług.

Własny Resource Agent: klaster reagujący na stan aplikacji

Najbardziej wymagająca część dotyczyła wykrywania problemów. Sam fakt, że serwer i maszyna wirtualna pracują, nie wystarczał do potwierdzenia gotowości Systemu Centralnego. Aplikacja potrafiła diagnozować własne środowisko i sygnalizowała problem przez zamknięcie określonego portu sieciowego.

Przygotowaliśmy dedykowany Resource Agent, który sprawdzał dostępność tego portu. W razie wykrycia problemu tworzył regułę klastra kierującą wymagane zasoby na drugi węzeł. Dostosowaliśmy również skrypt odpowiedzialny za maszyny wirtualne, dodając kontrolowane zamykanie Windows przez SSH.

Przełączenie obejmowało następującą sekwencję:

1. wyłączenie maszyn wirtualnych na pierwszym węźle;
2. zmianę kierunku synchronizacji danych macierzy;
3. uruchomienie maszyn wirtualnych na drugim węźle;
4. pozostawienie zasobów na węźle przejmującym do decyzji administratora.

Według archiwalnego opisu realizacji cały proces trwał kilka minut, po których System Centralny odzyskiwał pełną sprawność. Po naprawie administrator usuwał regułę wymuszającą położenie zasobów, umożliwiając powrót do konfiguracji podstawowej.

Rezultat: platforma HA przygotowana do konkretnego systemu

Efektem prac było uruchomienie dwóch klastrów oraz połączenie wirtualizacji, replikacji danych i monitorowania aplikacji w jeden mechanizm obsługi awarii. Środowisko miało określoną procedurę przejęcia usług i kontrolowanego powrotu. W osobnym klastrze działały usługi backupu i poczty.

Ta realizacja pokazuje zakres naszych kompetencji w projektach wysokiej dostępności HA: od sprzętu i systemów Linux, przez wirtualizację serwerów i pamięci masowe, po integrację z zachowaniem aplikacji. Wymagała pracy na styku kilku warstw technicznych oraz uwzględnienia wymagań jej twórców.

Zobacz wystawę, dla której pracowało to zaplecze

Wystawa stała POLIN pozostaje dostępna dla zwiedzających. Jej przestrzeń i tematykę można poznać także przez oficjalne oprowadzania i materiały online Muzeum POLIN. Pokazują one kontekst projektu: technologia wspiera tu sposób opowiadania historii i doświadczenie odwiedzających.

Opis przedstawia historyczną konfigurację z naszego archiwum technicznego. Wymienione wersje systemów dotyczą tamtego wdrożenia. Opracowanie nie określa obecnej konfiguracji infrastruktury muzeum. Grafika przy artykule jest ilustracją infrastruktury serwerowej.