A konfiguráció csak olvashatóvá vált: miért más az a hely, ahol lakik

Egy fájl szerkesztése jogosultsági hibába ütközik. A felhasználó root. A lemezen van hely. Az írás mégsem sikerül.

Itt semmi nem romlott el. A szóban forgó hely nem szokásos könyvtár, és szándékosan utasítja vissza az írást.

A konfiguráció helye nem könyvtár

A Proxmox egy helyen tartja a gépek konfigurációit, a tárolók meghatározásait, a tűzfalszabályokat és a mentési feladatokat. Fájlrendszernek látszik, vannak benne mappák és fájlok, mögötte azonban egy kis adatbázis ül, és ez az adatbázis a fürt minden csomópontjára replikálódik.

Az ok egyszerű: a fürt minden szerverének ugyanazt a gépmeghatározást kell látnia. Ha egy gép átkerül az egyik szerverről a másikra, a túloldalnak már előre tudnia kell, hogyan van az a gép meghatározva. Ha a konfiguráció egyetlen szerver lemezén, közönséges fájlként élne, a többiek nem tudnának róla.

Ennek a felépítésnek három következménye van, és mindhárom előkerül a napi életben.

Első következmény: többség nélkül nincs írás

Ha egy szerver nem látja a fürt többségét, az írás lekapcsol. Az olvasás továbbra is működik, az írás megáll.

Ez nem hiba, hanem döntés. Ha a hálózat kettéválna, és mindkét fél írhatna, ugyanannak a gépnek két különböző meghatározása keletkezne. A hálózat visszatértekor senki nem tudná megmondani, melyik a helyes, és összefésülni sem lehetne őket. A rendszer helyette ezt választja: a kisebbségben maradt oldal abbahagyja az írást.

Azt, hogy a fürtben hogyan számolódik a többség, és miért kényelmetlenek a kétszerveres felállások, külön cikk tárgyalja. Itt csak annyi tartozik hozzá, hogy a többségi szabály a gyakorlatban pontosan így érződik: hirtelen nem lehet írni.

Második következmény: ugyanez a szerkezet egyetlen szerveren is fut

Fürt nélkül is fut ez a szerkezet. Egyetlen szerver önmagában többség, ezért rendes körülmények között semmi nem romlik el.

Ha viszont a szerkezetet biztosító szolgáltatás nincs rendben, ugyanez a tünet egyetlen szerveren is megjelenik. A "nincs fürtöm, ez velem nem történhet meg" tehát nem igaz.

Van egy kevésbé ismert út is: a szerkezet mögötti adatbázis a helyi lemezen ül. Amikor a helyi lemez megtelik, az írások meghiúsulnak, és úgy tűnik, mintha a beállítások nem lennének módosíthatók. A tünet a konfiguráció oldalán van, az ok a tároló oldalán.

Harmadik következmény: ami oda kerül, mindenkihez eljut

Nincs olyan lehetőség, hogy "csak ezen a gépen módosuljon". Ami oda íródik, a fürt minden csomópontjára eljut.

A klasszikus hiba ennek ismerete nélkül az, hogy kísérleti módosítás történik az egyik csomóponton, azzal a feltételezéssel, hogy a többit nem érinti.

Még egy szempont: az a hely konfigurációra készült, nem adatra. Kis szöveges fájlok valók oda, szkriptek, archívumok és biztonsági mentések nem. Nem érdemes szokássá tenni, hogy fájlok maradnak ott.

Ha nem sikerül az írás, sorrendben érdemes ellenőrizni

Először a többség: látja-e a szerver a fürt többi részét? Ha nem, az igazi probléma a hálózatban van, a konfigurációs fájl ártatlan.

Aztán a szolgáltatás: fut-e a szerkezetet biztosító szolgáltatás?

Aztán a helyi lemez: ha megtelt, a fenti út játszik.

És az utolsó, amelyet a leggyakrabban kihagynak: lehet, hogy egy csomópont kilépett a fürtből. Hálózati kimaradás, egy lekapcsolt szomszéd, egy rosszul beállított tűzfalszabály. A tünet mindig ugyanúgy néz ki, az ok minden alkalommal máshol van.

Mit tesz az Atlas

Az Atlas közvetlenül fájlként olvassa ezt a szerkezetet, ahelyett, hogy minden alkalommal lefuttatná a rendszer lekérdező eszközét.

Meg is mértük, miért. Az eszköz minden hívása száz és kétszáz ezredmásodperc közötti processzoridőbe és nagyjából száz megabájt átmeneti memóriába kerül. Nyitott panel mellett tíz másodpercenként történik frissítés, és minden frissítéshez nyolc-tíz hívás kell. Vagyis a megfigyelés folyamatos billegést okozott pontosan azon a szerveren, amelyet megfigyelt.

Ugyanennek az információnak a fájlból olvasása mikroszekundumokba telik. A különbség több ezerszeres, és ez a különbség a felhasználó gépén stabilitásként jelenik meg.

A második részlet elegánsabb: a szerkezeten belül van egy változásszámláló, amely a konfiguráció minden módosulásakor növekszik. Az Atlas ezt figyeli. Így abban a pillanatban, amikor a panelről módosul egy beállítás, a gyorsítótár magától frissül: a ritka lekérdezés és az elavult információ teljes elkerülése egyszerre válik lehetségessé.

Ez egy máshol, ebben a wikiben is leírt elv másik arca: ami figyel, az ne kerüljön sokba. A megfigyelőeszköz legkönnyebben elkövethető hibája az, hogy lelassítja a figyelt rendszert, és ezzel elrontja pontosan azt a számot, amelyet mér.