26. februarja smo imeli meet-up Apache Ignite GreenSource, kjer so nastopali prispevkarji open source projekta. Pomemben dogodek v življenju te skupnosti je bila preureditev komponenta. , ki omogoča razporejanje uporabniških mikroservisov neposredno v klasteru Ignite. O tem zahtevnem procesu je na meet-upu govoril , programski inženir in že več kot dve leti prispevkar Apache Ignite.
Začnimo s tem, kaj pravzaprav je Apache Ignite. To je baza podatkov, ki predstavlja porazdeljeno shramba Key/Value s podporo za SQL, transakcije in predpomnjenje. Poleg tega Ignite omogoča razporejanje uporabniških storitev neposredno v klasteru Ignite. Razvijalcu so na voljo vsi orodja, ki jih ponuja Ignite — porazdeljene podatkovne strukture, sporočanje, pretakanje, izračuni in podatkovni gridi. Na primer, pri uporabi podatkovnega grida odpadne težave z administracijo ločene infrastrukture za shrambo podatkov in s tem povezani stroški.
Z uporabo API Service Grid je mogoče namestiti storitev, preprosto z navedbo sheme namestitve in ustrezne storitve v konfiguraciji.
Običajno shema namestitve pomeni navedbo števila primerkov, ki naj bi bili razporejeni na vozliščih klasterja. Obstajata dve tipični shemi namestitve. Prva je Cluster Singleton: v vsakem trenutku bo v klasterju zagotovo na voljo en primerek uporabniške storitve. Druga je Node Singleton: na vsakem vozlišču klasterja je nameščen en primerek storitve.
Prav tako lahko uporabnik navede število primerkov storitve v celotnem klasterju in določi predikat za filtriranje ustreznih vozlišč. V tem scenariju bo Service Grid sam izračunal optimalno razporeditev za namestitev storitev.
Poleg tega obstaja funkcija, imenovana Affinity Service. Affinity je funkcija, ki določa povezavo ključev s particijami in povezavo strank z vozlišči v topologiji. Po ključu lahko določite primarno vozlišče, kjer so shranjeni podatki. S tem lahko povežete svojo storitev s ključem in predpomnilnikom funkcije affinity. V primeru spremembe funkcije affinity bo samodejno izvedena ponovna namestitev. Tako bo storitev vedno nameščena blizu podatkov, s katerimi mora upravljati, in s tem zmanjšala stroške dostopa do informacij. To shemo lahko imenujemo nekakšno kolokacijsko računanje.
Zdaj, ko smo razložili, kaj je čar Service Grid, bomo govorili o njegovi zgodovini razvoja.
Kaj je bilo prej
Prejšnja izvedba Service Grid je temeljila na transakcijskem replikacijskem sistemskem predpomnilniku Ignite. Pod izrazom 'predpomnilnik' v Ignite razumemo shrambo. Torej, to ni nekaj začasnega, kot bi lahko pomislili. Kljub temu, da je predpomnilnik replikativen in vsako vozlišče vsebuje celoten nabor podatkov, ima predpomnilnik interno particionirano predstavo. To je povezano z optimizacijo shrambe.
Kaj se je zgodilo, ko je uporabnik želel naštimati storitev?
- Vsa vozlišča v grozdu so se prijavila za posodobitev podatkov v shrambi preko vgrajenega mehanizma Continous Query.
- Vozlišče iniciator je pod transakcijo read-committed zapisalo v bazo, ki je vsebovala konfiguracijo storitve, vključno s serializirano instanco.
- Ob prejemu obvestila o novem zapisu je koordinator izračunal razporeditev glede na konfiguracijo. Pridobljen objekt je bil vpisan nazaj v bazo.
- Če je vozlišče vstopilo v razporeditev, ga je moral koordinator naštimati.
Kaj nas ni prepričevalo
Nekega trenutka smo prišli do spoznanja: tako delati s storitvami ni mogoče. Razlogov je bilo več.
Če je med namestitvijo prišlo do napake, je bilo to mogoče izvedeti le iz dnevnikov tistega vozlišča, kjer se je vse zgodilo. Obstajala je le asinhrona namestitev, tako da po vrnitvi nadzora uporabniku iz metode namestitve je bilo potrebno dodatno čas za zagon storitve - v tem času uporabnik ni mogel ničesar upravljati. Da bi Service Grid razvili naprej, dodali nove funkcije, privabili nove uporabnike in olajšali življenje vsem, je bilo treba nekatere stvari spremeniti.
Pri načrtovanju novega Service Grid smo si prvenstveno želeli zagotoviti jamstvo sinhroniziranega namestitve: takoj ko uporabnik ponovno prevzame nadzor nad API-jem, lahko takoj začne uporabljati storitve. Prav tako smo želeli omogočiti iniciatorju obravnavo napak pri namestitvi.
Poleg tega smo želeli poenostaviti izvedbo, in sicer se izogniti transakcijam in rebalance-ingu. Kljub temu, da je predpomnilnik replikativen in ni nikakršne porazdelitve, so se med velikimi namestitvami s številnimi vozlišči pojavile težave. Pri spremembi topologije morajo vozlišča izmenjavati informacije, in pri velikih namestitvah so ti podatki lahko zelo obsežni.
Ko je bila topologija nestabilna, je koordinator moral ponovno izračunati porazdelitev storitev. Prav tako, ko se je treba ukvarjati s transakcijami v nestabilni topologiji, to lahko privede do težko napovedljivih napak.
Težave
Kakšne so globalne spremembe brez spremljajočih težav? Prva od njih je postala sprememba topologije. Treba je razumeti, da v vsakem trenutku, tudi ob namestitvi storitve, lahko vozlišče vstopi v klaster ali izstopi iz njega. Še več, če v trenutku namestitve vozlišče vstopi v klaster, bo potrebno dosledno prenesti vse informacije o storitvah na novo vozlišče. Govorimo ne le o že razporejenih, temveč tudi o trenutnih in prihodnjih namestitvah.
To je le ena od težav, ki jih je mogoče zbrati v ločen seznam:
- Kako namestiti statično konfigurirane storitve ob zagonu vozlišča?
- Izstop vozlišča iz klasterja - kaj storiti, če je vozlišče gostilo storitve?
- Kaj storiti, če se je koordinator spremenil?
- Kaj storiti, če se je stranka znova povezana s klasterjem?
- Ali je treba obravnavati zahteve za aktivacijo/deaktivacijo in kako?
- In kaj, če je bila klicana uničitev predpomnilnika, medtem ko imamo na njem odvisne storitve?
In to še zdaleč ni vse.
Solution
Kot cilj smo izbrali pristop Event Driven z izvajanjem komunikacije procesov prek sporočil. V Ignite sta že implementirana dva komponente, ki omogočata vozliščem, da si izmenjujejo sporočila, - communication-spi in discovery-spi.
Communication-spi omogoča vozliščem neposredno komunikacijo in pošiljanje sporočil. Dobro se obnese pri pošiljanju velikega obsega podatkov. Discovery-spi omogoča pošiljanje sporočila vsem vozliščem v gruči. V standardni implementaciji se to izvede po topologiji 'obroč'. Poleg tega obstaja integracija z Zookeeper, kjer se uporablja topologija 'zvezda'. Pomembno je tudi opozoriti, da discovery-spi zagotavlja, da se sporočilo zagotovo dostavi v pravilnem vrstnem redu vsem vozliščem.
Poglejmo protokol nameščanja. Vse uporabniške zahteve za namestitev in razne namestitve se pošiljajo preko discovery-spi. To prinaša naslednje garancije:
- Zahteva bo prejeta s strani vseh vozlišč v gruči. To omogoča nadaljevanje obdelave zahteve v primeru spremembe koordinatorja. Prav tako to pomeni, da bo imelo vsako vozlišče ob eni sami sporočilu vse potrebne meta podatke, kot so konfiguracija storitve in njen сериализованный экземпляр.
- Strog vrstni red dostave sporočil omogoča reševanje konfliktov konfiguracij in konkurenčnih zahtev.
- Ker vstop vozlišča v topologijo obravnava tudi discovery-spi, bodo na novo vozlišče prišle vse potrebne informacije za delo s storitvami.
Ob prejemanju zahteve vozlišča v gruči potrjujejo zahtevo in oblikujejo naloge za obdelavo. Te naloge se nakažejo v vrsto in nato obdelajo v drugem niti z ločenim delavcem. To je uresničeno na ta način, ker lahko nameščanje traja znatno časa in zadrževanje dragocene discovery-toka ni sprejemljivo.
Vse zahteve iz vrste obdeluje upravitelj nameščanja. Ima posebnega delavca, ki iz te vrste potegne nalogo in jo inicializira, da začne nameščanje. Po tem se izvedejo naslednji koraki:
- Vsako vozlišče samostojno izračuna razporeditev zahvaljujoč novi deterministični funkciji dodelitve.
- Vozlišča oblikujejo sporočilo z rezultati nameščanja in ga pošljejo koordinatorju.
- Koordinator agregira vsa sporočila in oblikuje rezultat celotnega postopka nameščanja, ki se pošlje preko discovery-spi vsem vozliščem v gruči.
- Ob prejemu rezultata se postopek nameščanja zaključi, po čemer se naloga odstrani iz vrste.
Nov zasnovan dogodek: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Če se med razporeditvijo zgodi napaka, vozlišče takoj vključi to napako v sporočilo, ki ga pošlje koordinatorju. Po aglomeraciji sporočil bo koordinator imel informacije o vseh napakah med namestitvijo in to sporočilo bo poslano prek discovery-spi. Informacije o napakah bodo dostopne na katerem koli vozlišču v grozdu.
Po tem algoritmu se obdelujejo vse pomembne dogodke v Service Grid. Na primer, sprememba topologije je prav tako sporočilo prek discovery-spi. In na splošno, če primerjamo s tem, kar je bilo, je protokol postal dovolj lahkotno in zanesljivo. Toliko, da lahko obravnava katero koli situacijo med namestitvijo.
V naslednjem ponedeljku, 25. marca, bo na
Zdaj o načrtih. Vsaka večja izboljšava v projektu Ignite se izvaja kot pobuda za izboljšanje Ignite, tako imenovani IEP. Redizajn Service Grid ima prav tako IEP — z zabavno naslovom „Zamenjava olja v storitvi Grid“. V resnici pa nismo zamenjali olja v motorju, temveč celoten motor.
Naloge v IEP smo razdelili na 2 fazi. Prva je velika faza, ki se osredotoča na prenovo protokola namestitve. Ta je že vključena v glavno vejo, lahko preizkusite nov Service Grid, ki bo na voljo v različici 2.8. Druga faza vključuje številne druge naloge:
- Hiter redeploy
- Različnost storitev
- Povečana odpornosti na napake
- Tanka stranka
- Orodja za spremljanje in zbiranje različnih metrik
Na koncu vam lahko priporočimo Service Grid za gradnjo visokAvailability sistemov z odpornostjo na napake. Prav tako vas vabimo, da se nam pridružite na in in delite svoje izkušnje. Vaše izkušnje so resnično pomembne za skupnost, pomagajo razumeti, kam naprej, kako v prihodnosti razvijati ta komponent.
Izvor: habr.com
