Zbudowałem klaster, a maszyny się nie przenoszą: brakuje pamięci masowej

Zbudowałeś klaster, węzły się widzą, wszystkie stoją obok siebie w interfejsie. Potem próbujesz przenieść maszynę na inny węzeł i się nie udaje.

Brakuje nie klastra, tylko pamięci masowej.

To, co się przenosi, nie jest maszyną, tylko pamięcią

Przeniesienie działającej maszyny wirtualnej oznacza skopiowanie stanu z jej pamięci na drugi węzeł. Dzieje się to przez sieć i jest szybkie.

Ale potrzebny jest też dysk maszyny, a dysk jest wielokrotnie większy od pamięci. Jeśli dysk siedzi tylko na własnym napędzie pierwszego węzła, drugi węzeł go nie dosięgnie. Migracja albo w ogóle się nie zaczyna, albo musi skopiować także dysk, co zajmuje już nie sekundy, tylko minuty, a nawet godziny.

Odpowiedź mieści się więc w jednym zdaniu: dysk musi być widoczny z obu węzłów.

Dwa sposoby, żeby to urządzić

Współdzielona pamięć masowa. Dysk siedzi we wspólnym miejscu, do którego łączą się oba węzły: magazyn sieciowy, serwer pamięci masowej albo rozproszona warstwa pamięci. Przy migracji dysk w ogóle nie jest kopiowany, bo już tam jest. To sposób najszybszy i najczystszy.

Replikacja. Dysk pozostaje lokalny, ale jest w regularnych odstępach kopiowany na drugi węzeł. Przy migracji wysyłane jest tylko to, co zmieniło się od ostatniej kopii, i dlatego jest szybko. Ceną jest to: ponieważ kopia robiona jest według harmonogramu, możesz stracić ostatnie kilka minut. W migracji planowanej to nie problem; przy nagłej awarii może nim być.

Pytanie rozstrzygające, co ci pasuje, brzmi tak: jeśli węzeł padnie nagle, na ile minut straty się godzisz? Jeśli odpowiedź brzmi zero, potrzebujesz współdzielonej pamięci masowej. Jeśli odpowiedź brzmi kilka minut wystarczy, replikacja jest wystarczająca i znacznie tańsza.

Kontenery nie przenoszą się tak jak maszyny wirtualne

To miejsce, w którym budujący pierwszy klaster są zaskakiwani najczęściej. Maszynę wirtualną można przenieść w trakcie działania. Kontenera nie: wyłącza się go, przenosi i uruchamia ponownie.

Dla twoich kontenerów nie istnieje więc coś takiego jak migracja bez przerwy, nawet z klastrem. To nie jest niedostatek, tylko natura kontenera: maszyna wirtualna niesie własne jądro, kontener używa jądra serwera, a to jądro nie może podróżować.

Praktyczny skutek: uwzględnij to, decydując, która praca siedzi w kontenerze, a która w maszynie wirtualnej. Jeśli praca nieznosząca przerw siedzi w kontenerze, ta praca zatrzyma się w noce serwisowe.

Ustal kolejność z wyprzedzeniem

W noc, w której aktualizujesz węzeł, odpowiedzi na te pytania powinny być już gotowe: ile maszyn jest na tym węźle, ile da się przenieść, ile trzeba wyłączyć i na który węzeł idą te przenoszalne.

Ustalanie tego tej samej nocy jest złym pomysłem. Napisz raz i trzymaj pod ręką.

Co robi Atlas

Przed aktualizacją węzła Atlas wypisuje działające na nim maszyny i podpowiada kolejność migracji: która maszyna na który węzeł. Podpowiedź jest budowana tak, by rozłożyć je kolejno na węzły dostępne.

Rozróżnienie kontenerów jest tu robione wprost. Dla maszyn wirtualnych podpowiadaną metodą jest migracja w trakcie działania; dla kontenerów łańcuch wyłącz, przenieś, uruchom. Produkt nie oferuje tego jako opcji, tylko stwierdza, że kontenera nie da się przenieść inaczej.

Maszyny oddane pod zarządzanie wysokiej dostępności też są oznaczone, bo przeniesienie ich ręcznie i pozostawienie własnej decyzji menedżera to różne rzeczy.

A podpowiedź pozostaje podpowiedzią: polecenie migracji nie wykonuje się samo, przycisk naciskasz ty.

Uczciwe ograniczenie: dziś Atlas traktuje każdą działającą maszynę wirtualną jako przenoszalną i nie sprawdza, czy jej dysk jest naprawdę widoczny z drugiego węzła. Produkt nie odpowiada więc za ciebie na powyższe pytanie o pamięć masową, na nie musisz raz odpowiedzieć sam. Czytaj podpowiedź, wiedząc o tym.