Niezawodność serwerów – klastry

Klastry – czyli jeden z najpopularniejszych sposobów zwiększania niezawodności lub wydajności gdy pojedyncza jednostka obliczeniowa zawodzi. Poprzednio pisałem o klastrach w kontekście niezawodności i to należy rozszerzyć.

Nie ma większego sensu generować klastra na sprzęcie który nie będzie wirtualizowany. Innymi słowy klastrowanie pojedynczej usługi w oparciu o zasoby sprzętowe to raczej kiepski pomysł prowadzący do marnowania zasobów. Znacznie częściej stosowanym podejściem jest klastrowanie hostów tzw. Hypervisorów które służą do wirtualizowania oraz konteneryzacji zasobów. Klastrowania dokonuje się w opraciu o mechanizmy wirtualizacyjne w przypadku Microsoft odpowiada za to usługa Microsoft Failover Clustering na której następnie stawiane są role, w przypadku np. vmWare i XenServer mówić będziemy o pulach Pools które gromadzą nody. Skupiając się na klastrach rodziny Microsoft, które są mi najbliższe – każdy klaster składać się może z minimum dwóch maszyn (nodów) i musi współdzielić zasoby (np. musi posiadać wspólny dysk dostępny np. poprzez protokół iSCSI albo SMB). W przypadku klastra opartego o dwie nody warto także rozważyć w kontekście głosowania dodatkowy głos – tzw świadka (może np. być nim share lub dysk). W razie awarii sieci obie maszyny klastra sądzą że są „klastrem” więc decyzja o tym która z nich powinna przejąć jego rolę musi być podyktowana dostępem do świadka (zasobu).

Mamy zatem dwa serwery o jednakowej lub podobnej budowie – posiadają własne mechaniczne zabezpieczenia np. raid, np. redundancje łączy, czy też redundancje zasilania. Zostają włączone do klastra i stają się jego elementami, będą więc dostarczać funkcjonalności. Jedna z maszyn jest aktywna i serwuje serwis, druga jest tzw. hot-standby która przejmie serwisy w razie awarii pierwszej. Istnieją również klastry active-active gdzie obie maszyny są jednocześnie dostępne a ruch jest balansowany – tu jednak dochodzą problemy z zasobami i wielodostępem do dysków – a konkretnie do warstwy systemu plików (operacje I/O) dlatego są stosowane wyłącznie do wysoko skalowalnych rozwiązań – najczęściej bazodanowych np. MSSQL. Dlaczego zasoby na nodach klastra muszą być podobne jak nie jednakowe? Ponieważ np. w przypadku wirtualizacji maszyny wirtualne mają przydzielaną ilość pamięci i vCPU – więc nie może dojść do sytuacji że w przypadku awarii 1 nody, druga nie ma dość pamięci aby uruchomić instancje wirtualne! W przypadku procesorów i ich wirtualizacji sprawa jest o tyle zróżnicowana że można wirtualizować nawet cory procesora, ale zapewnienie wsparcia możliwe jest wyłącznie w ramach jednej architektury – vendora. Jest to spowodowane różnymi procesami konstrukcyjnymi i sposobem oferowania wirtualizacji. Hypervisor jest w stanie użyć więc różnych procesorów tego samego producenta do migracji maszyn używając specjalnej opcji kompatybilności uruchamianej np. powershellem:

Set-VMProcessor -CompatibilityForMigrationEnabled $true

W tak skonstruowanym klastrze można uruchamiać różne usługi – najczęściej są to maszyny wirtualne, jednak mogą to być serwery plików, wysokodostępne serwery DHCP, itp. Co jest więc słabym elementem klastra? Zasoby. Mamy wysokodostępne usługi na np. 3 nodach, ale wszystkie one korzystają z dysku na np. starej macierzy NAS która nie jest replikowana. W przypadku jej awarii, klaster pozostanie bez zasobów – więc chociażby było w nim 10 nod – nie będzie działał. Należy zatem zadbać o zapewnienie wysokiej dostępności zasobów co jest równie ważne jak same nody.