Ignite Teenuse Grid — taaskäivitamine

26. veebruaril korraldasime Apache Ignite GreenSourcei kohtumise, kus esinesid avatud lähtekoodiga projekti kontributsioonide autorid. Apache IgniteSelle kogukonna elu tähtsaks sündmuseks oli komponendi ümberkujundamine Ignite Service Grid, mis võimaldab kasutajate mikroteenuseid otse Ignite'i klastris rakendada. Sellest keerulisest protsessist rääkis kohtumisel Vjatseslav Daradur, tarkvarainsener ja juba rohkem kui kahe aasta kontributsioonide autor Apache Ignite'is.

Alustame sellest, mis on Apache Ignite. See on andmebaas, mis esindab hajutatud võtme/väärtuse salvestust, millel on SQL, tehingute ja vahemälu toetus. Lisaks võimaldab Ignite kasutajate teenuseid otse Ignite'i klastris rakendada. Arendajatel on juurdepääs kõikidele tööriistadele, mida Ignite pakub — hajutatud andmestruktuurid, vestlus, voog, arvutamine ja andmevõrk. Näiteks Data Grid'i kasutamisel kaob vajadus andmesalvestusele eraldi infrastruktuuri haldamiseks, mis omakorda vähendab sellega seotud kulusid.

Kasutades API Service Grid'i, saab teenuse rakendada lihtsalt, määrates konfigureerimises rakendamise skeemi ja vastava teenuse.

Tavaliselt on deploy skeem näitaja klastris sõlmedes kasutatavate instantside arvu. On kaks tüüpilist deploy skeemi. Esimene on Cluster Singleton: igal ajahetkel on klastris garanteeritult saadaval üks kasutaja teenuse instants. Teine on Node Singleton: igas klastrisõlmes on üks teenuse instants.

Kasutaja võib samuti määrata teenuse instantside arvu kogu klastris ja määratleda predikaadi sobivate sõlmede filtreerimiseks. Sellisel juhul arvutab Service Grid automaatselt optimaalse jaotuse teenuste deploy jaoks.

Lisaks on olemas funktsioon nimega Affinity Service. Affinity on funktsioon, mis määratleb võtmete seose partitsioonidega ja partii seose sõlmedega topoloogias. Võtme kaudu saab määrata primaarse sõlme, kus andmed asuvad. Seega saab siduda oma teenuse võtmega ja affinity-funktsiooni vahemäluga. Kui affinity-funktsioon muutub, toimub automaatne redeploy. Nii asetatakse teenus alati andmete lähedale, millega ta peab töötama, vähendades seeläbi juurdepääsu kulusid teabele. Sellist skeemi võib nimetada omamoodi kolokatsiooniks.

Nüüd, kui oleme arutanud Service Gridi eeliseid, räägime selle arengulugu.

Mis oli varem

Eelmise Service Gridi teostus põhines Ignite'i tehingute replikatsioonil põhineval süsteemi vahemälul. Ignite'i all peetakse silmas salvestusruumi. See ei ole midagi ajutist, nagu võiks arvata. Kuigi vahemälu on replikatsiooniga ja iga sõlm sisaldab kogu andmekogumit, on vahemälu sees partitsioneeritud esitus. See on seotud salvestusruumide optimeerimisega.

Mis juhtus, kui kasutaja soovis teenust juurutada?

• Klastri kõik sõlmed registreerusid andmete uuenduste jaoks salvestuses, kasutades sisseehitatud Continuous Query mehhanismi.
• Algatava sõlme read-committed tehingu all tehti andmebaasi kirje, mis sisaldas teenuse konfiguratsiooni, sealhulgas serialiseeritud instantsi.
• Uue kirje saamisel arvutas koordinaator jaotuse välja konfiguratsiooni põhjal. Saadud objekt kirjutati tagasi andmebaasi.
• Kui sõlm kuulus jaotusse, pidi koordinaator selle juurutama.

Mis meid ei rahuldanud

Mingil hetkel jõudsime järeldusele: teenustega ei saa nii töötada. Põhjuseid oli mitu.

Kui juurutamise ajal ilmnes mingi viga, sai sellest teada vaid selle sõlme logidest, kus see aset leidis. Oli olemas ainult asünkroonne juurutamine, seega pärast juurutamismeetodist kasutaja juhtimise tagasiandmist vajas teenuse käivitamine mõningast lisaaega — ja sel ajal ei saanud kasutaja millegagi operatiivset. Service Gridi edasiviimiseks, uute funktsioonide arendamiseks, uute kasutajate kaasamiseks ja elu kõigile lihtsamaks tegemiseks on vajalik midagi muuta.

Uue Service Gridi kavandamisel soovisime eelkõige tagada sünkroonse juurutamise: niipea kui kasutaja sai API-lt juhtimise tagasi, sai ta kohe teenuseid kasutada. Samuti soovisime anda algatajale võimaluse juurutamisvigu töödelda.

Lisaks soovisime hõlbustada teostust, nimelt eemalduda tehingutest ja ümberjaotamisest. Kuigi vahemälu on replitseeritud ja tasakaalustamist ei toimu, tekkisid suure juurutamise ajal, millel oli palju sõlmi, probleemid. Sõlmed peavad teabe vahetamiseks suhtlema ning suure juurutamise korral võivad need andmed olla väga suured.

Kui topoloogia oli ebastabiilne, pidi koordinaator teenuste jaotust uuesti arvutama. Üldiselt, kui tuleb töötada tehingutega ebastabiilses topoloogias, võib see viia keeruliselt prognoositavate vigadeni.

Probleemid

Millised suured muutused tulevad ilma kaasnevate probleemideta? Esimene neist oli topoloogia muutmine. Tuleb mõista, et igal hetkel, isegi teenuse juurutamise ajal, võib sõlm liituda klastri või sellest lahkuda. Veelgi enam, kui sõlm liitub klastri ajal, tuleb kogu teenuste informatsioon järjepidevalt edastada uuele sõlmele. Ja jutt ei käi ainult sellest, mis on juba juurutatud, vaid ka praegustest ja tulevastest juurutustest.

See on vaid üks probleem, mille võib koostada eraldi nimekirjaks:

• Kuidas juurutada staatiliselt konfigureeritud teenuseid sõlme käivitamisel?
• Sõlme väljumine klastrimisest – mida teha, kui sõlm hostis teenuseid?
• Mida teha, kui koordinaator on vahetunud?
• Mida teha, kui klient on klastri juurde uuesti ühendunud?
• Kas oleks vaja töötleda aktiveerimise/deaktiveerimise päringuid ja kuidas?
• Ent mis siis, kui me kutsume üles andmete kustutamist, kuid meil on selle külge seotud afiinsus-tegevused?

Ja see on alles kaugel.

Lahendus

Sihtmärgiks valisime sündmuspõhise lähenemise, rakendades protsesside vahelist suhtlemist sõnumite kaudu. Ignite'is on juba rakendatud kaks komponenti, mis võimaldavad sõlmedel omavahel sõnumeid edastada — communication-spi ja discovery-spi.

Communication-spi võimaldab sõlmedel otse suhelda ja sõnumeid edastada. See sobib suure hulga andmete edastamiseks. Discovery-spi võimaldab saata sõnumi kõigile sõlmedele klastris. Standartse teostuse korral toimub see 'ring' topoloogia kaudu. Samuti on olemas integratsioon Zookeeperiga, juhul kasutatakse 'täht' topoloogiat. Oluline on märkida, et discovery-spi annab garantiisid, et sõnum toimetatakse kindlasti õiges järjekorras kõigile sõlmedele.

Vaatame juurutamise protokolli. Kõik kasutaja taotlused juurutamiseks ja eemaldamiseks saadetakse discovery-spi kaudu. See annab järgmised garantiid:

• Päringu saavad kõik klastris olevad sõlmed. See võimaldab päringu töötlemist koordinaatori vahetamisel. Samuti tähendab see, et iga sõlme jaoks on ühe sõnumi korral kõik vajalikud metaandmed, nagu teenuse seadistus ja selle serialiseeritud instants.
• Range sõnumite kohaletoimetamise järjekord võimaldab lahendada seadistuste ja konkureerivate päringute konflikte.
• Kuna sõlme sisenemine topoloogiasse töödeldakse ka discovery-spi kaudu, jõuavad kõik teenustega töötamiseks vajalikud andmed uuele sõlmele.

Päringu saamisel valideerivad klastris olevad sõlmed selle ja koostavad töötlemise ülesanded. Need ülesanded pannakse järjekorda ning seejärel töödeldakse neid teises lõimes eraldi töötaja poolt. See on ellu viidud just niimoodi, et juurutamine võib võtta märkimisväärset aega ja kallist discovery-voogu ei tohi viivitada.

Kogu järjekonnast saadud päringud töötleb juurutushaldur. Tal on eriline töötaja, kes võtab ülesande sellest järjekorrast ja initsialiseerib selle, et alustada juurutamist. Pärast seda toimuvad järgmised toimingud:

1. Iga sõlm arvutab jaotuse iseseisvalt tänu uuele deterministlikule määramisfunktsioonile.
2. Sõlmed koostavad teate deploüri tulemustega ja saadavad selle koordinaatorile.
3. Koordinaator kogub kõik teated ja koostab kogu deploüri protsessi tulemuse, mis saadetakse discovery-spi kaudu kõigile klastris asuvatele sõlmedele.
4. Kui tulemus on saadud, lõpeb deploüri protsess ja ülesanne eemaldatakse järjekorrast.

Uus üritustel põhinev disain: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java

Kui deployimise hetkel ilmneb viga, lisab sõlm selle vea kohe teatesse, mille ta saadab koordinaatorile. Pärast teate kogumist omab koordinaator teavet kõigi deployimise ajal esinenud vigade kohta ja saadab teate discovery-spi kaudu. Teave vigade kohta on kergesti ligipääsetav igas klastris asuvas sõlmes.

Selle töö algoritmi alusel töödeldakse kõiki olulisi sündmusi Teenuse Gridis. Näiteks on ka topoloogia muutmine discovery-spi kaudu saadetud teade. Ja üldiselt, võrreldes varasema lähenemisega, on protokoll piisavalt kergkaaluline ja usaldusväärne. Sedavõrd, et suudab käsitleda igasuguseid olukordi deployimise ajal.

Mis järgmiseks?

Nüüd plaanidest. Iga suur muudatus Ignite projektis tehakse kui algatus Ignite paremaks muutmiseks, nn IEP. Ka Service Grid'i ümberkujundamisel on IEP — IEP Nr 17 naljakalt nimelt «Õli vahetus Service Grid'is». Kuid tegelikult muutisime mitte ainult mootori õli, vaid kogu mootori.

IEP ülesanded on jagatud kaheks faasiks. Esimene — suur faas, mis hõlmab juurutamisprotokolli ümberehitust. See on juba masterisse lisatud, saate proovida uut Service Grid'i, mis ilmub versioonis 2.8. Teine faas sisaldab paljusid teisi ülesandeid:

• Kuum redemodeerimine
• Teenuste versioonimine
• Rikkes taluvuse suurendamine
• Õhuke klient
• Jälgimise ja erinevate mõõdikute arvestamise tööriistad

Lõpetuseks võime soovitada teile Service Grid'i kõrge kättesaadavuse ja rikketaluvate süsteemide loomiseks. Samuti kutsume teid liituma meiega dev-list ja user-list jagama oma kogemusi. Teie kogemus on tõeliselt oluline kogukonna jaoks, see aitab mõista, kuhu edasi liikuda ja kuidas arendada komponenti tulevikus.

Allikas: habr.com