Pięć i sześć serwerów może tolerować dokładnie tyle samo awarii consensusowych
Intuicja podpowiada, że sześć serwerów jest bardziej odporne niż pięć. W klastrze opartym na większości nie zawsze. Pięć węzłów potrzebuje trzech głosów, więc może stracić dwa. Sześć potrzebuje czterech, więc również może stracić tylko dwa. Dopiero siedem węzłów podnosi tolerancję do trzech awarii. Dlatego klastry consensusowe często buduje się z nieparzystej liczby głosujących członków. etcd w dokumentacji ostrzega nawet, że dodanie czwartego węzła do zdrowego klastra trzyosobowego zwiększa quorum z dwóch do trzech, nie zwiększając tolerancji na kolejną awarię.
Quorum rośnie skokowo
W systemie większościowym potrzeba więcej niż połowy wszystkich głosów. Dla trzech węzłów quorum wynosi dwa, dla czterech trzy, dla pięciu trzy, dla sześciu cztery, a dla siedmiu cztery. Odporność na utratę członków wynika z różnicy pomiędzy całkowitą liczbą a wymaganym quorum.
Parzysty węzeł nie zawsze kupuje nową odporność
Przejście z pięciu do sześciu maszyn zwiększa koszt sprzętu, replikacji i komunikacji, ale nadal trzeba zachować cztery? W sześciu rzeczywiście quorum to cztery, więc utrata trzech zatrzymuje postęp. W pięciu quorum to trzy i utrata trzech również zatrzymuje postęp. Oba klastry tolerują więc dwie awarie.
etcd ostrzega przed pozornym ulepszeniem
W FAQ etcd opisuje analogiczny przypadek dla trzech i czterech członków. Klaster trzyosobowy z quorum dwa toleruje awarię jednego członka. Po dodaniu czwartego quorum rośnie do trzech, więc system nadal toleruje tylko jedną awarię. Co gorsza, źle wykonana zmiana członkostwa podczas awarii może chwilowo zwiększyć wymagane quorum i utrudnić odzyskanie systemu.
Nie znaczy to, że parzysta liczba maszyn nigdy nie ma sensu
Nie wszystkie węzły muszą być głosującymi członkami jednego protokołu, a architektura może mieć inne cele: pojemność odczytową, geograficzną redundancję czy osobne repliki danych. Ciekawostka dotyczy konkretnej odporności quorum consensusowego, nie uniwersalnej zasady „zawsze kupuj nieparzyście”.
Matematyka większości przekłada się na rachunek infrastruktury
To dobry przykład sytuacji, w której więcej sprzętu nie daje liniowo większej niezawodności. Liczy się topologia głosowania. Projektant powinien wiedzieć, jaki konkretnie rodzaj awarii ma tolerować klaster, zamiast zakładać, że każdy kolejny serwer automatycznie zwiększa bezpieczeństwo.
Więcej węzłów zwiększa też koszt consensusu
Każdy dodatkowy głosujący członek to więcej komunikacji, stanu i potencjalnych opóźnień. Jeśli nie zwiększa tolerowanej liczby awarii, jego obecność może być trudna do uzasadnienia. Dlatego projektując membership, patrzy się jednocześnie na fault tolerance i koszty protokołu, a nie na samą liczbę maszyn.
Nie wolno mylić członków consensusowych z replikami pomocniczymi
System może mieć dodatkowe repliki do odczytów, backupy albo węzły niegłosujące bez zwiększania rozmiaru quorum. To pozwala skalować inne właściwości bez wpływania na większość. Ciekawostka o pięciu i sześciu dotyczy członków mających głos w tej samej grupie consensusowej; architektura całej usługi może oczywiście zawierać znacznie więcej maszyn.
Przykład pokazuje również, dlaczego membership change sam jest operacją wymagającą ostrożności. Dodanie lub usunięcie głosującego węzła zmienia definicję większości, czyli regułę, według której późniejsze decyzje uznaje się za prawomocne. Nie można traktować tego jak dopisania adresu do listy serwerów w pliku konfiguracyjnym. Dobre protokoły mają specjalne procedury rekonfiguracji właśnie po to, aby podczas przejścia nie powstały dwa różne zbiory quorum mogące niezależnie zatwierdzać historię.
Wielkość klastra consensusowego wpływa również na prawdopodobieństwo, że któryś członek będzie wolny albo chwilowo odłączony. Większa grupa daje więcej kopii, ale też więcej uczestników, których trzeba obserwować i utrzymywać. Dlatego małe grupy 3, 5 lub 7 węzłów są częste w systemach metadanych: mają wystarczającą redundancję dla założonego modelu awarii, a jednocześnie nie rozciągają consensusu na dziesiątki maszyn bez potrzeby.