Cloister → egyszerű OTP klaszterkezelés

Szinte minden sikeres üzleti alkalmazás előbb-utóbb olyan fázisba kerül, amikor vízszintes skálázásra van szükség. Sok esetben egyszerűen elindíthat egy új példányt, és csökkentheti a terhelési átlagot. De vannak kevésbé triviális esetek is, amikor gondoskodnunk kell arról, hogy a különböző csomópontok tudjanak egymásról, és gondosan osszák el a munkaterhelést.

Ez olyan szerencsésnek bizonyult kapott, amelyet a kellemes szintaxisa és a körülötte lévő hype miatt választottunk, első osztályú elosztott rendszerek támogatása. Elméletileg ez teljesen triviálisan hangzik:

A különböző csomópontokon lévő folyamatok, valamint a hivatkozások és a monitorok közötti üzenettovábbítás átlátható […]

A gyakorlatban minden egy kicsit bonyolultabb. Megosztott kapott akkor fejlesztették ki, amikor a "container" egy nagy vasdobozt jelentett a szállításhoz, a "docker" pedig egyszerűen a longshoreman szinonimája. BAN BEN IP4 sok volt a kihasználatlan cím, a hálózati megszakításokat általában a patkányok okozták, akik átrágták a kábelt, és a gyártórendszer átlagos üzemidejét évtizedekben mérték.

Most mindannyian hihetetlenül önellátóak vagyunk, csomagolva és elosztottan futunk kapott olyan környezetben, ahol a dinamikus IP-címeket a nagy véletlenszerűség elve alapján osztják ki, és csomópontok jelenhetnek meg és tűnhetnek el az ütemező bal sarkának szeszélye szerint. Annak elkerülése érdekében, hogy minden elosztott projektet futtató projektben ne halmozzanak fel sablonkódot kapott, az ellenséges környezet leküzdéséhez segítségre van szükség.

Megjegyzés: Tisztában vagyok vele, hogy van libcluster. Nagyon klassz, több mint ezer csillaga van, a szerző híres a közösségben, meg minden. Ha a csomag által kínált módszerek a klaszter létrehozására és karbantartására elegendőek Önnek, akkor örülök. Sajnos sokkal több kell. Szeretnék részletesen ellenőrizni a beállítást, és nem külső szemlélő lenni a klaszter-újraszervezés színházában.

Követelmények

Személy szerint egy olyan könyvtárra volt szükségem, amely átveszi a fürt kezelését, és a következő tulajdonságokkal rendelkezik:

• átlátható munkavégzés a csomópontok keményen kódolt listájával és a szolgáltatásokon keresztüli dinamikus felfedezéssel kapott;
• teljesen működőképes visszahívás minden topológiaváltozáshoz (csomópont ott, csomópont itt, hálózati instabilitás, felosztások);
• átlátszó felület a fürt elindításához hosszú és rövid nevekkel, mint pl :nonode@nohost;
• Docker támogatás a dobozból, anélkül, hogy infrastruktúra kódot kellene írnia.

Ez utóbbi azt jelenti, hogy miután helyben teszteltem az alkalmazást :nonode@nohost, vagy mesterségesen elosztott környezetben használva test_cluster_task, csak futni akarok docker-compose up --scale my_app=3 és nézze meg, hogyan hajt végre három példányt a Dockerben kódmódosítás nélkül. Én is szeretnék függő alkalmazásokat, mint pl mnesia - amikor a topológia megváltozik, a színfalak mögött élesben újjáépítik a fürtöt, anélkül, hogy az alkalmazás további rúgást adna.

Kolostor nem egy olyan könyvtárnak készült, amely a klaszter támogatásától a kávéfőzésig mindenre képes. Ez nem egy ezüstgolyó, amely az összes lehetséges esetet lefedi, vagy akadémiailag teljes megoldás abban az értelemben, ahogyan a teoretikusok CS belehelyezni ebbe a kifejezésbe. Ez a könyvtár nagyon világos célt szolgál, de nem túl nagy feladatát tökéletesen ellátja. Ez a cél az lesz, hogy teljes átláthatóságot biztosítson a helyi fejlesztési környezet és az ellenséges konténerekkel teli elosztott rugalmas környezet között.

Választott megközelítés

Kolostor alkalmazásként való futtatásra szánták, bár a haladó felhasználók a fürt manuális összeállításával és karbantartásával közvetlenül futtatva Cloister.Manager a célalkalmazás felügyeleti fájában.

Amikor alkalmazásként fut, a könyvtár támaszkodik config, amelyből a következő alapértékeket olvassa ki:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

A fenti paraméterek szó szerint a következőket jelentik: Kolostor OTP alkalmazáshoz használják :my_app, használ erlang szolgáltatás felfedezése csomópontok összekapcsolásához legalább három és MyApp.Listener modul (végrehajtás @behaviour Cloister.Listener) úgy van beállítva, hogy értesítéseket kapjon a topológia változásairól. A teljes konfiguráció részletes leírása itt található dokumentáció.

Ezzel a konfigurációval az alkalmazás Kolostor akarat szakaszosan indítja el, késlelteti a főalkalmazás elindításának folyamatát a konszenzus eléréséig (három csomópont van csatlakoztatva és csatlakoztatva, mint a fenti példában.) Ez lehetőséget ad a főalkalmazásnak arra, hogy feltételezze, hogy amikor elindul, a fürt már elérhető. Amikor a topológia megváltozik (sok lesz belőlük, mert a csomópontok nem indulnak el teljesen szinkronban), a kezelő meghívásra kerül. MyApp.Listener.on_state_change/2. Legtöbbször akkor hajtunk végre egy műveletet, amikor állapotüzenetet kapunk %Cloister.Monitor{status: :up}, ami azt jelenti: „Üdvözöljük, a fürt összeállt.”

A legtöbb esetben telepítés consensus: 3 optimális, mert még ha több csomópont csatlakozására is számítunk, a visszahívás átmegy status: :rehashing → status: :up minden újonnan hozzáadott vagy eltávolított csomóponton.

Amikor fejlesztői módban indul, csak be kell állítania consensus: 1 и Kolostor boldogan kihagyja a várakozást a fürt összeállítására, amikor meglátja :nonode@nohostVagy :node@hostVagy :[email protected] - attól függően, hogy a csomópont hogyan lett konfigurálva (:none | :shortnames | :longnames).

Elosztott alkalmazáskezelés

A nem vákuumban lévő elosztott alkalmazások általában tartalmaznak elosztott függőségeket, mint pl mnesia. Könnyen kezelhetjük az újrakonfigurálásukat ugyanabból a visszahívásból on_state_change/2. Itt van például egy részletes leírás az újrakonfigurálásról mnesia menet közben dokumentáció Kolostor.

A használat fő előnye Kolostor az, hogy elvégzi az összes szükséges műveletet a fürt újraépítéséhez egy topológiaváltás után a motorháztető alatt. Az alkalmazás egyszerűen egy már előkészített elosztott környezetben fut, minden csomópont csatlakoztatva van, függetlenül attól, hogy az IP-címeket és ezáltal a csomópontneveket előre ismerjük, vagy dinamikusan hozzárendeltük/változtattuk. Ez egyáltalán nem igényel speciális docker konfigurációs beállításokat, és az alkalmazásfejlesztői szempontból nincs különbség aközött, hogy elosztott környezetben vagy helyi környezetben fut. :nonode@nohost. Erről bővebben itt olvashat dokumentáció.

Bár a topológiaváltozások komplex kezelése egyedi megvalósításon keresztül lehetséges MyApp.Listener, mindig előfordulhatnak szélső esetek, amikor ezek a könyvtári korlátok és konfigurációs torzítások bizonyulnak a megvalósítás sarokköveinek. Nem baj, vedd csak a fentieket libcluster, amely általánosabb célú, vagy akár maga is kezelheti az alacsony szintű klasztert. Ennek a kódkönyvtárnak nem az a célja, hogy lefedjen minden lehetséges forgatókönyvet, hanem az, hogy a leggyakoribb forgatókönyvet használja fölösleges fájdalom és nehézkes másolás-beillesztés nélkül.

Megjegyzés: ezen a ponton az eredetiben ott volt a „Happy clustering!” kifejezés, és a Yandex, amivel fordítok (nem kell magamnak átnéznem a szótárakat), felajánlotta a „Boldog fürtözést!” lehetőséget. Ennél jobb fordítást talán elképzelni sem lehet, különösen a jelenlegi geopolitikai helyzet fényében.

Forrás: will.com