W ramach klastra Docker Swarm znajdziemy dwa typy węzłów – worker i manager. Te pierwsze wykonują prace obliczeniowe związane z uruchomieniem kontenerów i znajdujących się w nich aplikacji. Węzły zarządzające (manager) odpowiedzialne są za utrzymanie spójności całego klastra oraz poprawne jego funkcjonowanie. Bez nich węzły typu worker nie mogłyby działać.

Każdy klaster musi mieć co najmniej jeden węzeł zarządzający. Co więcej liczba węzłów tego typu w każdym klastrze powinna być nieparzysta. Pomiędzy nimi kreowany jest tak zwany „konsensus”. Jest to stan zapewniający, że w przypadku awarii któregokolwiek z managerów każdy inny manager będzie miał wystarczającą ilość informacji, aby kontynuować zarządzanie całym klastrem zgodnie z jego konfiguracją. W każdym klastrze Docker Swarm jeden z węzłów typu manager pełni wiodącą rolę. Wszelkie informacje są automatycznie replikowane z niego do pozostałych managerów. Całość działania opiera się o tak zwany Raft Consensus Algorithm, który został opracowany na uniwersytecie w Stanford.

Co do zasady nie ma górnego limitu liczby węzłów typu manager, które mogą zostać skonfigurowane w danym klastrze. Powinna ich być jednak nieparzysta liczba. Dodatkowe różne testy i badania dowiodły, że nie warto definiować więcej niż siedem lub dziewięć węzłów zarządzających niezależnie od rozmiaru całego klastra. W przypadku mniejszych klastrów optymalną wydaje się liczba trzech lub pięciu managerów. Aby zapewnić spójność konfiguracji całego klastra, ponad połowa węzłów zarządzających musi posiadać aktualną wiedzę o stanie klastra. Mówimy tutaj o odporności klastra na awarię węzłów zarządzających (patrz tabela). Odporność ta jest niezbędna, aby w przypadku awarii, na skutek której poszczególne węzły nie mogą się ze sobą komunikować, nie doszło do sytuacji, w której rozbity na części klaster zacząłby działać niezależnie od siebie. W momencie usunięcia awarii ponowne połączenie byłoby wtedy niemożliwe, a co więcej serwisy wystawione do sieci prawdopodobnie działałyby nieprawidłowo i nie były osiągalne a aplikacja działała niezgodnie z jej założeniem.

W tabeli oznaczyłem preferowane liczby węzłów zarządzających, w zależności od rozmiaru klastra:

Liczba węzłów manager Ile węzłów stanowi większość? Ile może ulec awarii?
1 1 0
2 2 0
3 2 1
4 3 1
5 3 2
6 4 2
7 4 3
8 5 3
9 5 4

Kworum oraz Raft Consensus

Aby zapewnić bezpieczeństwo pracy klastra musimy odpowiednio w naszej infrastrukturze rozlokować węzły typu worker, a w szczególności węzły manager. Większość klastrów budowana jest przy użyciu maszyn wirtualnych, na których następnie uruchamia się Docker Engine. W chmurze publicznej powinniśmy wykorzystywać tak zwane Availability Zones, czyli strefy zapewniające logiczną i fizyczną separację zasobów, na których działają usługi. Takie strefy dostępności znajdziemy u każdego dostawcy chmury publicznej czy rozwiązań hybrydowych. Jeżeli mamy wątpliwości w jaki sposób powinniśmy rozłożyć serwery skontaktujmy się z pomocą techniczną dostawcy. Takie samo podejście musimy zastosować, jeżeli uruchamiamy maszyny wirtualne z Docker Engine całkowicie w obrębie własnych serwerowni. Nasze data center powinno być podzielone na strefy, w których występuje separacja zasobów sprzętowych, programowych, a nawet infrastruktury fizycznej (okablowanie, źródła prądu, klimatyzacja pomieszczeń itp.) w taki sposób, że problemy czy awarie występujące w jednej strefie nie mają wpływu na pozostałe strefy.

Liczba węzłów manager Jak rozłożyć węzły pomiędzy 3 strefy?
3 1-1-1
5 2-2-1
7 3-2-2
9 3-3-3

Gdy utracimy kworum

Klastry Docker Swarm są mocno odporne na awarię poszczególnych węzłów. Dość szybko i bez udziału administratora potrafią przywrócić po awarii do pracy swoje węzły i rozpocząć ponowne przetwarzanie danych, jeżeli awaria nastąpiła w skutek restartu maszyny czy samego silnika Docker Engine. Bardzo często tego typu sytuacje są nieodczuwalne z punktu widzenia dostępności samej aplikacji. Jednakże klaster nie potrafi sam powrócić do działania, jeżeli zostanie utracone kworum. Co prawda same Kontenery z aplikacjami będą nadal działać na dostępnych węzłach, jednak żadne działania administracyjne nie będą możliwe. Do takich działań zaliczamy, choćby skalowanie aplikacji czy zmiany w uruchomionych serwisach, nie mówiąc o dodawaniu i usuwaniu węzłów z klastra. W takiej sytuacji najprościej przywrócić klaster do działania poprzez ponowne, poprawne podłączenie do niego węzłów zarządzających, które uległy awarii. Jeżeli to nie jest możliwe musimy od początku zbudować klaster poleceniem:

docker swarm init –force-new-cluster.

Polecenie to wydajemy na jednym z węzłów manager. Stanie się on managerem nowego klastra. Dzięki parametrowi:

–force-new-cluster

wykorzystane zostaną informacje o serwisach, czy zadaniach ze starego klastra, a także o węzłach typu worker. Odtworzona zostanie zatem ostatnia znana i poprawna konfiguracja klastra. Nam pozostanie jedynie dodanie do niego z powrotem pozostałych węzłów zarządzających.