Szinte minden sikeres üzleti alkalmazás előbb-utóbb elér egy szakaszt, amikor vízszintes skálázásra van szükség. Sok esetben egyszerűen elindíthatunk egy új példányt, és csökkenthetjük az átlagos terhelést. De léteznek kevésbé triviális helyzetek is, amikor biztosítani kell, hogy a különböző csomópontok tudjanak egymásról, és gondosan osszák el a munkaterhelést.
Szerencsésen alakult úgy, hogy erlang, amelyet kellemes szintaxisa és a körülette lévő hype miatt választottunk, kiváló . Elméletben ez teljesen triviálisnak hangzik:
Az üzenetek átvitele a különböző csomópontokon lévő folyamatok között, valamint a linkek és figyelők között átlátható […]
A gyakorlatban azonban minden kicsit bonyolultabb. Az elosztott erlang a kifejlesztés idején, amikor a "konténer" egy nagy fém dobozt jelentett a szállításra, a "docker" pedig csak a kikötői rakodót jelentette. Az IP4 számtalan üres címet tartalmazott, a hálózati problémákért általában a kábeleket rágnak át a patkányok, és a gyártási rendszer átlagos működési ideje évtizedekben mérhető volt.
Most mindannyian elképzelhetetlenül önfenntartóak vagyunk, csomagoltak, és elosztott erlang környezetben futtatunk, ahol a dinamikus IP-címek egy nagy véletlenszerűség elve alapján osztódnak ki, és a csomópontok a tervező bal sarkának kívánsága szerint jelennek meg vagy tűnnek el. Annak érdekében, hogy elkerüljük a sablonkódok halmazát minden projektben, amely elosztott erlangindít, segítségre van szükség.
Megjegyzés: tudom, hogy van . Tényleg menő, több mint ezer csillaggal rendelkezik, a szerző pedig ismert a közösségben, és hasonlók. Ha Önnek elegendő az ebben a csomagban javasolt klaszter létrehozási és fenntartási módokból - örülök Önnek. Sajnos nekem sokkal többre van szükségem. Szeretném részletesen irányítani a beállítást, és nem csak egy külső néző lenni a klaszter újraformálásának színházában.
Követelmények
Amire személy szerint szükségem volt, az egy könyvtár, amely átveszi a klaszter kezelését és a következő tulajdonságokkal bír:
- átlátható működés, mind a mereven kódolt csomópontlistával, mind a dinamikus felfedezéssel a szolgáltatásokon keresztül erlang;
- teljes körű visszahívási funkció minden topológiai változáskor (itt egy csomópont, ott egy csomópont, hálózati instabilitás, megszakítások);
- átlátható felület a klaszter elindításához hosszú és rövid nevekkel, akár
:nonode@nohost; - a Docker támogatása dobozból, programozási infrastruktúra kód írása nélkül.
Ez azt jelenti, hogy miután lokálisan teszteltem az alkalmazást :nonode@nohost, vagy mesterségesen elosztott környezetben a segítségével, egyszerűen csak el akarom indítani a docker-compose up --scale my_app=3 parancsot, és látni, hogyan fut három példány Dockerben kódváltoztatások nélkül. Azt is szeretném, ha a függő alkalmazások, mint például a mnesia - amikor a topológia megváltozik, a háttérben élőben újraépítenék a klasztert, a programtól függő extra lökés nélkül.
A Cloister nem úgy lett tervezve, mint egy mindenre képes könyvtár: a klaszter támogatásától a kávéfőzésig. Ez nem egy ezüst golyó, amely megpróbálja lefedni az összes lehetséges esetet, vagy egy akadémikusan teljes megoldás abban az értelemben, ahogy a CS teoretikusai értelmezik ezt a kifejezést. Ez a könyvtár egy nagyon világos célt szolgál, de azt tökéletesen végzi el, nem túl nagy munkakörrel. Ez a cél a teljes átláthatóság biztosítása a helyi fejlesztési környezet és a strukturált, rugalmas környezet között, amely telített ellenséges konténerekkel.
A választott megközelítés
A Cloister azt jelenti, hogy alkalmazásként fut, bár a tapasztalt felhasználók képesek lehetnek a klaszter kézi összeállítására és karbantartására úgy, hogy egyszerűen elindítják a Cloister.Manager t a célalkalmazás felügyeleti fájljában.
Alkalmazásként való indításkor a könyvtár a configállományra támaszkodik, ahonnan a következő alapvető értékeket olvassa ki:
config :cloister,
otp_app: :my_app,
sentry: :"cloister.local", # vagy ~w|n1@foo n2@bar|a
consensus: 3, # a figyelembe vett csomópontok száma
# a klaszter üzemel
listener: MyApp.Listener # a hallgató, akit hívni kell, amikor
# a kör megváltozottA fenti paraméterek szószerinti jelentése a következő: A Cloister használják az OTP alkalmazást :my_app, használja az erlang szolgáltatás felfedezést a csomópontok, legalább három, összekapcsolásához, és MyApp.Listener modul (amely megvalósítja a ) be van állítva, hogy értesítéseket kapjon a topológiai változásokról. A teljes konfiguráció részletes leírását megtalálja a .
Ezzel a konfigurációval az alkalmazás A Cloister lesz , elhalasztva a fő alkalmazás indítási folyamatát a konszenzus eléréséig (három csomópont csatlakozott és összekapcsolva, mint a fenti példában). Ez lehetővé teszi a fő alkalmazás számára, hogy feltételezze, hogy amikor elindult, a klaszter már elérhető. Minden topológiai változásnál (amiből sok lesz, mivel a csomópontok nem teljesen szinkronizáltan indulnak) a kezelő lesz hívva . A legtöbb esetben műveletet hajtunk végre, amikor állapotüzenetet kapunk %Cloister.Monitor{status: :up}, ami azt jelenti: „helló, a klaszter összeállt”.
A legtöbb esetben a beállítás consensus: 3 optimális, mert még ha arra is számítunk, hogy több csomópont csatlakozik, a visszahívás áthalad status: :rehashing → status: :up bármely újonnan hozzáadott vagy eltávolított csomóponton.
Fejlesztési módban elegendő egyszerűen beállítani consensus: 1 és A Cloister örömmel átugorja a klaszterépítési várakozást, látva :nonode@nohost, vagy :node@host, vagy :node@host.domain — attól függően, hogy hogyan lett beállítva a csomópont (:none | :shortnames | :longnames).
Elosztott alkalmazások kezelése
Az elosztott alkalmazások nem vákuumban jönnek létre, általában tartalmaznak elosztott függőségeket is, mint például mnesia. Könnyen kezeljük ezek újrakonfigurálását ugyanabból a visszahívásból on_state_change/2. Például itt van egy részletes leírás arról, hogyan lehet újrakonfigurálni mnesia élesben a .
A legnagyobb előny abban, hogy A Cloister , hogy végrehajtja az összes szükséges műveletet a klaszter újjáépítésére a topológia megváltoztatása után a motorháztető alatt. Az alkalmazás egyszerűen elindul egy előkészített elosztott környezetben, az összes csatlakoztatott csomóponttal, függetlenül attól, hogy előre tudjuk-e az IP-címeket és ezzel együtt a csomópontok nevét, vagy azok dinamikusan lettek hozzárendelve/változtatva. Ez semmilyen különleges Docker konfigurálást nem igényel, és a fejlesztő számára nincs különbség az elosztott környezetben vagy helyben való futtatás között. :nonode@nohost. Erről bővebben olvashatunk a .
Bár a topológiai változások bonyolult kezelése lehetséges saját megvalósítással MyApp.Listener, mindig lehetnek határhelyzetek, amikor ezek a könyvtári korlátok és a konfigurálásra való elfogult megközelítés a bevezetés kövekké válnak. Ez rendben van, csak vegye figyelembe a fent említetteket. libcluster, amely sokkal általánosabb, vagy akár saját magad is kezelheted az alacsony szintű klasztert. Ennek a kód könyvtárnak a célja nem az, hogy lefedje az összes lehetséges forgatókönyvet, hanem hogy a leggyakoribb forgatókönyvet használja, szükségtelen fájdalom és terjedelmes másolás-beillesztés nélkül.
Megjegyzés: Ezen a helyen az eredetiben az „Happy clustering!” kifejezés szerepelt, és az Yandex, akinek fordítok (nem magamnak kellene a szótárakban keresgélnem), a „Szerencsés klaszterezést!” javasolta nekem. Jobb fordítást valószínűleg nem is lehetne találni, különösen a jelenlegi geopolitikai helyzet fényében.
Forrás: habr.com
