Klooster → eenvoudig OTP-clusterbeheer

Vrijwel elke succesvolle bedrijfsapplicatie komt vroeg of laat in een fase waarin horizontale schaalvergroting vereist is. In veel gevallen kunt u eenvoudigweg een nieuw exemplaar starten en het belastingsgemiddelde verlagen. Maar er zijn ook minder triviale gevallen waarin we ervoor moeten zorgen dat verschillende knooppunten elkaar kennen en de werklast zorgvuldig verdelen.

Het bleek zo gelukkig erlang, dat we hebben gekozen vanwege de prettige syntaxis en de hype eromheen, heeft eersteklas ondersteuning voor gedistribueerde systemen. In theorie klinkt dit volkomen triviaal:

Het doorgeven van berichten tussen processen op verschillende knooppunten, evenals tussen links en monitors, is transparant […]

In de praktijk is alles iets ingewikkelder. Gedistribueerd erlang werd ontwikkeld toen "container" een grote ijzeren kist voor de scheepvaart betekende, en "dokwerker" eenvoudigweg een synoniem was voor dokwerker. IN IP4 er waren veel onbezette adressen, netwerkbreuken werden meestal veroorzaakt door ratten die door de kabel knauwden, en de gemiddelde uptime van het productiesysteem werd gemeten in tientallen jaren.

Nu zijn we allemaal ongelooflijk zelfvoorzienend, verpakt en gedistribueerd erlang in een omgeving waar dynamische IP-adressen worden uitgedeeld op basis van het principe van grote willekeur, en knooppunten kunnen verschijnen en verdwijnen in de grillen van de linkerhiel van de planner. Om stapels standaardcode te voorkomen in elk project waarin een gedistribueerd wordt uitgevoerd erlangOm de vijandige omgeving te bestrijden is hulp nodig.

Noot: Ik ben me ervan bewust dat dat zo is libcluster. Het is echt gaaf, het heeft meer dan duizend sterren, de auteur is beroemd in de gemeenschap, en zo. Als de methoden die dit pakket biedt voor het maken en onderhouden van een cluster voldoende voor u zijn, ben ik blij voor u. Helaas heb ik nog veel meer nodig. Ik wil de opzet tot in detail controleren en geen externe toeschouwer zijn in het theater van clusterreorganisatie.

Eisen

Wat ik persoonlijk nodig had, was een bibliotheek die het beheer van het cluster zou overnemen en de volgende eigenschappen zou hebben:

• transparant werken met zowel een hardgecodeerde lijst met knooppunten als dynamische ontdekking via services erlang;
• volledig functionele callback voor elke topologiewijziging (knooppunt daar, knooppunt hier, netwerkinstabiliteit, splitsingen);
• transparante interface voor het starten van een cluster met lange en korte namen, zoals bij :nonode@nohost;
• Docker-ondersteuning out-of-the-box, zonder dat u infrastructuurcode hoeft te schrijven.

Dit laatste betekent dat nadat ik de applicatie lokaal heb getest in :nonode@nohost, of in een kunstmatig gedistribueerde omgeving met behulp van test_cluster_task, ik wil gewoon rennen docker-compose up --scale my_app=3 en zie hoe het drie instanties in docker uitvoert zonder enige codewijzigingen. Ik wil ook afhankelijke applicaties zoals mnesia - wanneer de topologie verandert, bouwen ze achter de schermen het cluster live opnieuw op zonder enige extra kick van de applicatie.

Klooster was niet bedoeld als een bibliotheek die alles kan, van het ondersteunen van een cluster tot het zetten van koffie. Het is geen wondermiddel dat tot doel heeft alle mogelijke gevallen te bestrijken, of een academisch complete oplossing te zijn in de zin dat theoretici uit CS in deze term gezet. Deze bibliotheek is ontworpen om een ​​heel duidelijk doel te dienen, maar doet zijn niet al te grote werk perfect. Dit doel zal zijn om volledige transparantie te bieden tussen de lokale ontwikkelomgeving en een gedistribueerde elastische omgeving vol vijandige containers.

Gekozen aanpak

Klooster is bedoeld om als applicatie te worden uitgevoerd, hoewel geavanceerde gebruikers handmatig kunnen werken met de montage en het onderhoud van het cluster door deze rechtstreeks uit te voeren Cloister.Manager in de supervisorstructuur van de doeltoepassing.

Wanneer het als een applicatie wordt uitgevoerd, vertrouwt de bibliotheek op config, waaruit de volgende basiswaarden worden gelezen:

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

De bovenstaande parameters betekenen letterlijk het volgende: Klooster gebruikt voor OTP-toepassing :my_app, toepassingen ontdekking van erlang-services om knooppunten te verbinden, minstens drie, en MyApp.Listener module (implementeren @behaviour Cloister.Listener) is geconfigureerd om meldingen over topologiewijzigingen te ontvangen. Een gedetailleerde beschrijving van de volledige configuratie vindt u in documentatie.

Met deze configuratie kan de applicatie Klooster zullen in fasen lanceren, waardoor het proces van het starten van de hoofdapplicatie wordt uitgesteld totdat consensus is bereikt (drie knooppunten zijn verbonden en verbonden, zoals in het bovenstaande voorbeeld). Dit geeft de hoofdapplicatie de mogelijkheid om aan te nemen dat wanneer deze start, het cluster al beschikbaar is. Telkens wanneer de topologie verandert (er zullen er veel zijn, omdat de knooppunten niet volledig synchroon starten), wordt de handler aangeroepen MyApp.Listener.on_state_change/2. Meestal voeren we een actie uit als we een statusbericht ontvangen %Cloister.Monitor{status: :up}, wat betekent: "Hallo, het cluster is gemonteerd."

In de meeste gevallen installatie consensus: 3 is optimaal, want zelfs als we verwachten dat er meer knooppunten verbinding zullen maken, zal de callback doorgaan status: :rehashing → status: :up op elk nieuw toegevoegd of verwijderd knooppunt.

Wanneer u in de ontwikkelingsmodus start, hoeft u alleen maar in te stellen consensus: 1 и Klooster zal met plezier het wachten op de clustermontage overslaan als hij het ziet :nonode@nohostOf :node@hostOf :[email protected] - afhankelijk van hoe het knooppunt is geconfigureerd (:none | :shortnames | :longnames).

Gedistribueerd applicatiebeheer

Gedistribueerde toepassingen die zich niet in een vacuüm bevinden, omvatten doorgaans gedistribueerde afhankelijkheden, zoals mnesia. Het is voor ons gemakkelijk om hun herconfiguratie via hetzelfde terugbelverzoek af te handelen on_state_change/2. Hier vindt u bijvoorbeeld een gedetailleerde beschrijving van hoe u opnieuw kunt configureren mnesia op de vlucht naar binnen documentatie Klooster.

Het belangrijkste voordeel van het gebruik Klooster is dat het alle noodzakelijke bewerkingen uitvoert om het cluster opnieuw op te bouwen na een topologiewijziging onder de motorkap. De applicatie draait eenvoudigweg in een reeds voorbereide gedistribueerde omgeving, waarbij alle knooppunten zijn aangesloten, ongeacht of we de IP-adressen en dus de knooppuntnamen vooraf kennen, of dat deze dynamisch zijn toegewezen/gewijzigd. Dit vereist absoluut geen speciale docker-configuratie-instellingen en vanuit het oogpunt van een applicatie-ontwikkelaar is er geen verschil tussen draaien in een gedistribueerde omgeving of draaien in een lokale omgeving. :nonode@nohost. Meer hierover leest u in documentatie.

Hoewel een complexe afhandeling van topologiewijzigingen mogelijk is via een aangepaste implementatie MyApp.Listener, kunnen er altijd randgevallen zijn waarin deze bibliotheekbeperkingen en configuratievooroordelen de hoekstenen van de implementatie blijken te zijn. Het is oké, neem gewoon het bovenstaande libcluster, wat algemener is, of zelfs zelf het cluster op laag niveau afhandelt. Het doel van deze codebibliotheek is niet om elk mogelijk scenario te dekken, maar om het meest voorkomende scenario te gebruiken zonder onnodige pijn en omslachtig kopiëren en plakken.

Opmerking: op dit punt in het origineel stond de zinsnede "Happy clustering!", en Yandex, waarmee ik vertaal (ik hoef zelf niet door woordenboeken te bladeren), bood me de optie "Happy clustering!" Een betere vertaling is wellicht niet denkbaar, zeker in het licht van de huidige geopolitieke situatie.

Bron: www.habr.com