Konfiguracja stała się tylko do odczytu: dlaczego miejsce, w którym mieszka, jest inne

Próbujesz edytować plik i dostajesz odmowę uprawnień. Jesteś rootem. Na dysku jest miejsce. A mimo to nie możesz pisać.

Nic tu nie jest zepsute. Miejsce, na które patrzysz, nie jest zwykłym katalogiem i odmawia zapisu celowo.

Miejsce, w którym mieszka konfiguracja, nie jest katalogiem

Proxmox trzyma konfiguracje maszyn, definicje magazynów, reguły zapory i zadania kopii zapasowych w jednym miejscu. Wygląda to jak system plików, ma foldery i pliki, ale za tym siedzi mała baza danych, a ta baza jest kopiowana na każdy węzeł klastra.

Powód jest prosty: każdy serwer w klastrze musi widzieć tę samą definicję maszyny. Jeśli zamierzasz przenieść maszynę z jednego serwera na drugi, druga strona musi już wiedzieć, jak ta maszyna jest zdefiniowana. Gdyby konfiguracja była zwykłym plikiem na dysku jednego serwera, pozostałe nic by o niej nie wiedziały.

Ten projekt ma trzy skutki i wszystkie trzy pojawiają się w codziennej pracy.

Skutek pierwszy: bez większości zapis jest odrzucany

Jeśli serwer nie widzi większości klastra, zapis się zamyka. Odczyt działa dalej, zapis staje.

To nie jest awaria, to decyzja. Gdyby sieć rozpadła się na dwie części i obie połowy mogły pisać, ta sama maszyna skończyłaby z dwiema różnymi definicjami. Gdy sieć wróci, nikt nie umiałby powiedzieć, która jest właściwa, i nie byłoby sposobu, żeby je scalić. Zamiast tego system wybiera tak: strona pozostała w mniejszości przestaje pisać.

Jak liczy się większość w klastrze i dlaczego układy z dwoma serwerami są niewygodne, opisano w osobnym wpisie. Tu wystarczy dodać jedno: dokładnie tak ta reguła większości odczuwa się w praktyce, jako nagła niemożność zapisu.

Skutek drugi: ta sama konstrukcja działa nawet na pojedynczym serwerze

Nawet bez klastra ta konstrukcja pracuje. Pojedynczy serwer sam w sobie jest większością, więc normalnie nic się nie psuje.

Ale jeśli usługa dostarczająca tę konstrukcję nie jest zdrowa, ten sam objaw zobaczysz też na pojedynczym serwerze. Zdanie, że nie mam klastra, więc mnie to nie dotyczy, nie jest więc poprawne.

Jest też mniej znana ścieżka: baza danych stojąca za tą konstrukcją siedzi na dysku lokalnym. Gdy dysk lokalny się zapełni, zapisy zawodzą i wygląda ci to tak, jakbyś nie mógł zmienić ustawień. Objaw jest po stronie konfiguracji, przyczyna po stronie pamięci masowej.

Skutek trzeci: cokolwiek tam zapiszesz, idzie do wszystkich

Nie ma opcji, żeby zmienić to tylko na tej maszynie. To, co tam zostanie zapisane, dociera do każdego węzła klastra.

Klasycznym błędem popełnianym bez tej wiedzy jest wprowadzenie próbnej zmiany na jednym węźle w założeniu, że nie dotyka pozostałych.

Jeszcze jedno: to miejsce zaprojektowano do konfiguracji, a nie do danych. Małe pliki tekstowe tam należą; skrypty, archiwa i kopie zapasowe nie. Nie wyrabiaj w sobie nawyku zostawiania tam plików.

Jeśli nie możesz pisać, sprawdzaj po kolei

Najpierw sprawdź większość: czy serwer widzi resztę klastra? Jeśli nie widzi, prawdziwy problem jest w sieci, a plik konfiguracji jest niewinny.

Potem sprawdź usługę: czy usługa dostarczająca tę konstrukcję działa?

Potem sprawdź dysk lokalny: jeśli jest pełny, w grę wchodzi ścieżka opisana wyżej.

I na koniec to, co pomija się najczęściej: węzeł mógł opuścić klaster. Awaria sieci, wyłączony sąsiad, źle ustawiona reguła zapory. Objaw zawsze wygląda tak samo, przyczyna za każdym razem jest gdzie indziej.

Co robi Atlas

Atlas czyta tę konstrukcję wprost jako pliki, zamiast za każdym razem uruchamiać systemowe narzędzie zapytań.

Zmierzyliśmy dlaczego. Każde wywołanie tego narzędzia kosztuje od stu do dwustu milisekund czasu procesora i około stu megabajtów pamięci tymczasowej. Przy otwartym panelu odświeżenie następuje co dziesięć sekund, a każde odświeżenie wymaga ośmiu do dziesięciu wywołań. Innymi słowy, monitorowanie wytwarzało stałe falowanie na tym samym serwerze, który monitorowało.

Odczytanie tej samej informacji z pliku zajmuje mikrosekundy. Różnica jest tysiąckrotna, a na maszynie użytkownika widać ją jako spokój.

Drugi szczegół jest bardziej elegancki: wewnątrz tej konstrukcji istnieje licznik zmian, który rośnie za każdym razem, gdy zmienia się konfiguracja. Atlas go obserwuje. W chwili, gdy ustawienie zostaje zmienione z panelu, pamięć podręczna odświeża się więc sama; pytanie rzadko i nigdy niepokazywanie starych informacji stają się możliwe jednocześnie.

To kolejna strona zasady zapisanej w innych wpisach tej bazy wiedzy: to, co obserwuje, nie powinno być tym, co kosztuje. Najłatwiejszym błędem narzędzia monitorującego jest spowolnienie obserwowanego systemu, a przez to zafałszowanie tej samej liczby, którą mierzy.