Lähes jokainen menestyvä yrityssovellus siirtyy ennemmin tai myöhemmin vaiheeseen, jossa vaaditaan vaakasuuntaista skaalausta. Monissa tapauksissa voit yksinkertaisesti aloittaa uuden ilmentymän ja pienentää kuormituksen keskiarvoa. Mutta on myös vähemmän triviaaleja tapauksia, joissa meidän on varmistettava, että eri solmut tietävät toisistaan ja jakavat työtaakan huolellisesti.
Se osoittautui niin onnekkaaksi erlang, jonka valitsimme sen miellyttävän syntaksin ja sen ympärillä olevan hypetyksen vuoksi, on ensiluokkainen . Teoriassa tämä kuulostaa täysin triviaalilta:
Viestien välitys eri solmuissa olevien prosessien välillä sekä linkkien ja monitorien välillä on läpinäkyvää […]
Käytännössä kaikki on hieman monimutkaisempaa. Hajautettu erlang kehitettiin, kun "kontti" tarkoitti suurta rautalaatikkoa merenkulkuun, ja "docker" oli yksinkertaisesti synonyymi sanalle longshoreman. SISÄÄN IP4 tyhjiä osoitteita oli paljon, verkkokatkot johtuivat yleensä kaapelin läpi pureskeluista rotista ja tuotantojärjestelmän keskimääräinen käyttöaika mitattiin vuosikymmeninä.
Nyt olemme kaikki uskomattoman omavaraisia, pakattuja ja hajautettuja erlang ympäristössä, jossa dynaamiset IP-osoitteet jaetaan suuren satunnaisuuden periaatteella ja solmut voivat ilmaantua ja kadota ajoittajan vasemman kantapään mielijohteesta. Välttääksesi kasat tiivistekoodin jokaisessa projektissa, jossa on hajautettu erlang, vihamielisen ympäristön torjumiseksi tarvitaan apua.
Huomata: Tiedän, että on olemassa . Se on todella siistiä, siinä on yli tuhat tähteä, kirjailija on kuuluisa yhteisössä ja kaikkea muuta. Jos tämän paketin tarjoamat menetelmät klusterin luomiseen ja ylläpitoon riittävät sinulle, olen iloinen puolestasi. Valitettavasti tarvitsen paljon enemmän. Haluan hallita asetuksia yksityiskohtaisesti, enkä olla ulkopuolinen katsoja klusterin uudelleenjärjestelyn teatterissa.
Vaatimukset
Tarvitsin henkilökohtaisesti kirjaston, joka otti haltuunsa klusterin hallinnan ja jolla on seuraavat ominaisuudet:
- läpinäkyvä työ sekä kovakoodatun solmuluettelon että dynaamisen palveluiden avulla erlang;
- täysin toimiva takaisinsoitto jokaiselle topologian muutokselle (solmu siellä, solmu tässä, verkon epävakaus, halkeamat);
- läpinäkyvä käyttöliittymä klusterin käynnistämiseen pitkillä ja lyhyillä nimillä, kuten
:nonode@nohost; - Docker-tuki heti valmiina ilman infrastruktuurikoodin kirjoittamista.
Jälkimmäinen tarkoittaa, että kun testasin sovellusta paikallisesti :nonode@nohosttai keinotekoisesti jaetussa ympäristössä käyttämällä , Haluan vain juosta docker-compose up --scale my_app=3 ja katso kuinka se suorittaa kolme esiintymää Dockerissa ilman koodimuutoksia. Haluan myös riippuvaisia sovelluksia, kuten mnesia - kun topologia muuttuu, kulissien takana he rakentavat klusterin uudelleen livenä ilman lisäpotkua sovelluksesta.
Luostari ei ollut tarkoitettu kirjastoksi, joka pystyy kaikkeen klusterin tukemisesta kahvin keittämiseen. Se ei ole hopealuodi, jonka tarkoituksena on kattaa kaikki mahdolliset tapaukset tai olla akateemisesti täydellinen ratkaisu siinä mielessä, että teoreetikot CS laittaa tähän termiin. Tämä kirjasto on suunniteltu palvelemaan hyvin selkeää tarkoitusta, mutta se tekee ei liian suuren tehtävänsä täydellisesti. Tavoitteena on tarjota täydellinen läpinäkyvyys paikallisen kehitysympäristön ja hajautetun joustavan ympäristön välillä, joka on täynnä vihamielisiä kontteja.
Valittu lähestymistapa
Luostari on tarkoitettu käytettäväksi sovelluksena, vaikka kokeneet käyttäjät voivat käsitellä klusterin kokoamista ja ylläpitoa manuaalisesti suorittamalla Cloister.Manager kohdesovelluksen valvojapuussa.
Sovelluksena suoritettuna kirjasto luottaa siihen config, josta se lukee seuraavat perusarvot:
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 changedYllä olevat parametrit tarkoittavat kirjaimellisesti seuraavaa: Luostari käytetään OTP-sovelluksessa :my_app, käyttää erlang-palvelun löytäminen solmujen yhdistämiseen vähintään kolme ja MyApp.Listener moduuli (toteutus ) on määritetty vastaanottamaan ilmoituksia topologian muutoksista. Yksityiskohtainen kuvaus koko kokoonpanosta löytyy osoitteesta .
Tällä kokoonpanolla sovellus Luostari tahto , viivyttää pääsovelluksen käynnistysprosessia, kunnes konsensus saavutetaan (kolme solmua on yhdistetty ja yhdistetty, kuten yllä olevassa esimerkissä.) Tämä antaa pääsovellukselle mahdollisuuden olettaa, että klusteri on jo käytettävissä sen käynnistyessä. Aina kun topologia muuttuu (niitä tulee olemaan monia, koska solmut eivät käynnisty täysin synkronisesti), käsittelijä kutsutaan . Suurimman osan ajasta suoritamme toiminnon, kun saamme tilaviestin %Cloister.Monitor{status: :up}, mikä tarkoittaa: "Hei, klusteri on koottu."
Useimmissa tapauksissa asennus consensus: 3 on optimaalinen, koska vaikka odotamme useamman solmun muodostavan yhteyden, takaisinsoitto menee läpi status: :rehashing → status: :up missä tahansa vasta lisätyssä tai poistetussa solmussa.
Kun aloitat kehitystilassa, sinun tarvitsee vain asettaa consensus: 1 и Luostari ohittaa mielellään klusterin kokoonpanon odottamisen, kun hän näkee :nonode@nohostTai :node@hostTai :node@host.domain - riippuen siitä, kuinka solmu on konfiguroitu (:none | :shortnames | :longnames).
Hajautettu sovellusten hallinta
Hajautetut sovellukset, jotka eivät ole tyhjiössä, sisältävät yleensä hajautettuja riippuvuuksia, kuten mnesia. Meidän on helppo hoitaa niiden uudelleenmääritys samasta takaisinsoittosta on_state_change/2. Tässä on esimerkiksi yksityiskohtainen kuvaus uudelleenmäärityksestä mnesia lennossa sisään .
Käytön tärkein etu Luostari on, että se suorittaa kaikki tarvittavat toiminnot klusterin rakentamiseksi uudelleen topologian muutoksen jälkeen konepellin alle. Sovellus yksinkertaisesti toimii jo valmiissa hajautetussa ympäristössä, jossa kaikki solmut on kytketty, riippumatta siitä, tiedämmekö IP-osoitteet ja siten solmujen nimet etukäteen vai onko ne määritetty/muokattu dynaamisesti. Tämä ei vaadi mitään erityisiä telakointiaseman konfigurointiasetuksia, ja sovelluskehittäjän näkökulmasta katsottuna ei ole eroa, toimiiko hajautettu ympäristö vai paikallisessa ympäristössä. :nonode@nohost. Voit lukea tästä lisää kohdasta .
Vaikka topologian muutosten monimutkainen käsittely on mahdollista mukautetun toteutuksen avulla MyApp.Listener, saattaa aina olla reunatapauksia, joissa nämä kirjaston rajoitukset ja konfiguraatioharha osoittautuvat toteutuksen kulmakiviksi. Ei hätää, ota vain yllä oleva libcluster, joka on yleiskäyttöisempi, tai jopa käsitellä matalan tason klusteria itse. Tämän koodikirjaston tavoitteena ei ole kattaa kaikkia mahdollisia skenaarioita, vaan käyttää yleisintä skenaariota ilman turhaa kipua ja hankalaa kopiointia.
Huom: tässä vaiheessa alkuperäisessä oli lause "Happy clustering!", ja Yandex, jolla käännän (minun ei tarvitse itse käydä sanakirjoja läpi), tarjosi minulle vaihtoehdon "Happy clustering!" On ehkä mahdotonta kuvitella parempaa käännöstä, varsinkin nykyisen geopoliittisen tilanteen valossa.
Lähde: will.com
