Klaster Newterm HA²

Zapotrzebowanie na architekturę serwerową typu high availability u naszych klientów ewoluuje w czasie, tak jak i dostępne technologie sieciowe i oprogramowanie.

Nasz klaster serwerowy Newterm HA² opracowaliśmy bazując na doświadczeniach z poprzednich wdrożeń oraz research’u dostępnych technologii. Opracowany w 2013 klaster dwóch węzłów HA był rozwiązaniem ograniczonym przez liczbę fizycznych serwerów - wówczas były to dwie maszyny. W opracowanej w 2021 architekturze wykorzystaliśmy możliwości jakie daje użycie najmniejszej nieparzystej liczby węzłów klastra - trzech serwerów fizycznych.

Porównanie graficzne rozwiązania 2013 oraz Newterm HA² (2021):

Zastępowane rozwiązanie 2013 to:

• dwa fizyczne serwery,
• corosync i dwa redundantne połączenia sieciowe między fizycznymi serwerami w celu minimalizacji ryzyka rozpięcia klastra,
• LVM jako zarządca przestrzeni dyskowej,
• DRBD jako system replikacji danych,
• dwie maszyny wirtualne Xen (Debian Stable), będące serwerami danych SZARP,
• Pacemaker/crm jako nadzorca klastra,
• automatyczna migracja maszyn wirtualnych w przypadku padu fizycznego serwera,
• możliwość ręcznej migracji i wyłączeń na potrzeby prac serwisowych,
• konfiguracja ograniczająca ryzyko wystąpienia split brain,
• konfiguracja zabezpieczająca przed skutkami split brain.

Rozwiązanie Newterm HA² (2021) to:

• trzy fizyczne serwery,
• dwa redundantne połączenia sieciowe (w tym ring światłowodowy), spięte w systemowy bond (możliwość rozpięcia dowolnego łącza fizycznego bez wpływu na działanie klastra),
• corosync działający na skonfigurowanym bondzie,
• LVM jako zarządca przestrzeni dyskowej,
• DRBD jako system replikacji danych pomiędzy wszystkimi trzema serwerami (connection-mesh),
• cztery maszyny wirtualne Xen (Debian Stable), będące serwerami danych SZARP,
• Pacemaker/crm w ograniczonej roli nadzorcy klastra,
• zapobieganie split brain poprzez utrzymywanie quorum DRBD przynajmniej dwóch węzłów,
• zabezpieczenia klastra w większości scedowane do konfiguracji DRBD,
• automatyczna migracja maszyn wirtualnych w przypadku padu fizycznego serwera,
• możliwość ręcznej migracji i wyłączeń przy użyciu crm, w szczególności opracowanie procedur na potrzeby ręcznego uruchomienia klastra z pominięciem quorum.

Zaimplementowane rozwiązanie zapewnia całkowite zabezpieczenie przed wystąpieniem split brain w oparciu o sprawdzone oprogramowanie corosync/DRBD. Jednocześnie zachowaliśmy cenioną przez naszych klientów i jedną z najważniejszych cech naszego dotychczasowego klastra: automatyczną migrację maszyn wirtualnych w przypadku awarii serwera bądź sieci. Jest to cecha szczególnie ważna w konfigurowanych przez nas instalacjach przemysłowych, gdyż pozwala na zminimalizowanie przerwy w rejestracji danych w systemie SCADA SZARP w przypadku awarii sprzętu, a jednocześnie zwalnia załogę obiektu przemysłowego od konieczności ciągłego monitorowania działania systemu informatycznego. W szczególności ze względu na tę cechę zdecydowaliśmy się pozostać przy sprawdzonym przez nas oprogramowaniu corosync/DRBD/Pacemaker, odrzucając inne istniejące na rynku systemy takie jak w szczególności Proxmox/Ceph.