Ignite Service Grid – taaskäivitamine

26. veebruaril korraldasime Apache Ignite GreenSource'i kohtumise, kus esinesid avatud lähtekoodiga projekti panustajad. Apache Ignite. Selle kogukonna jaoks oli oluline sündmus komponendi Ignite Service Grid, mille abil saab kasutaja mikroteenuseid otse Ignite'i klastri sisse juurutada. Sellest keerulisest protsessist rääkis kohtumisel Vyacheslav Daradur, tarkvarainsener ja üle kahe aasta Apache Ignite'i kaastöötaja.

Alustame sellest, mis asi on Apache Ignite üldse. See on andmebaas, mis esindab jaotatud Key/Value salvestusruumi, mis toetab SQL-i, tehingutekäitlemist ja vahemälumist. Lisaks võimaldab Ignite kasutajateenuste juurutamist otse Ignite'i klastri sees. Arendajatele on kätkestatud kõik Ignite'i pakutavad tööriistad — jaotatud andmestruktuurid, sõnumiedastus, voog ja arvutus ning andmevõrk. Näiteks, kasutades andmevõrku, kaob vajadus hallata eraldi infrastruktuuri andmehoidla jaoks, mille tulemusena väheneb sellega seotud kulu.

Kasutades Service Gridi API-t, saab teenuse juurutada, lihtsalt määrates konfiguratsioonis juurutusskeemi ja vastava teenuse.

Tavaliselt on juurutusskeem — see, kui palju instantsi peaks klastri sõlmedes olema. On kaks tüüpilist juurutusskeemi. Esiteks on Cluster Singleton: igal ajal on klastris garanteeritult ainult üks kasutajateenuse eksemplar. Teiseks on Node Singleton: igas klastrisõlmes on üks teenuse eksemplar.

Kasutaja saab määrata teenuse instantside arvu kogu klastri ulatuses ja määrata predikaadi sobivate sõlmede filtreerimiseks. Sellise stsenaariumi korral arvutab Service Grid ise välja optimiseeritud jaotuse teenuste juurutamiseks.

Lisaks on olemas selline funktsioon nagu Affinity Service. Affinity on funktsioon, mis määrab võtmete seose partitsioonidega ja partii seose sõlmedega topoloogias. Võtme abil saab määrata primaarse sõlme, kus andmed asuvad. Nii saab seostada oma teenuse võtmega ja affinity-funktsiooni vahemälu. Kui affinity-funktsioon muutub, toimub automaatne redeploy. Nii on teenus alati paigutatud lähedale andmetele, millega see peab manipuleerima, vähendades seeläbi juurdepääsu kulusid. Sellist skeemi võib nimetada teatud tüüpi kolokatsioonide arvutusteks.

Nüüd, kui oleme uurinud, milles seisneb Service Grid võlu, räägime selle arenguloost.

Mis oli varem

Eelmine Service Grid'i rakendus põhines tehingureplikatsioonil põhineval süsteemi vahemälul Ignite. Sõna "vahemälu" all mõistetakse Ignites andmesalvestust. See ei ole midagi ajutist, nagu võiks arvata. Kuigi vahemälu on replikatsiooni all ja igas sõlmes on kogu andmekogum, on vahemälu sees partitsioneeritud esitus. See on seotud salvestuste optimeerimisega.

Mis juhtus, kui kasutaja soovis teenust välja panna?

• Kõik sõlmed klastris registreerisid end andmete muutuste jälgimiseks salvestuses, kasutades sisseehitatud mehhanismi Continuous Query.
• Algatava sõlme read-committed tehingu kaudu tegi andmebaasi kirje, mis sisaldas teenuse konfiguratsiooni, sealhulgas serialiseeritud eksemplari.
• Uue kirje teavitamisel arvutas koordinaator jaotuse vastavalt konfiguratsioonile. Saadud objekt kirjutati tagasi andmebaasi.
• Kui sõlm kuulus jaotusse, pidi koordinaator selle välja panema.

Mis meid ei rahuldanud

Mõnes etapis jõudsime järeldusele: teenustega ei saa nii töötada. Põhjuseid oli mitu.

Kui juurutamise ajal toimus mõni viga, sai sellest teada ainult selle sõlme logidest, kus see juhtus. Eksisteeris ainult asünkroonne juurutamine, seega pärast kasutaja juhtimise tagastamist juurutamismeetodist vajas teenuse käivitamine veel veidi aega — ja selle aja jooksul ei saanud kasutaja midagi juhtida. Et Service Grid'i edasi arendada, uusi funktsioone rakendada, uusi kasutajaid kaasata ja kõigi elu lihtsamaks teha, oli vaja midagi muuta.

Uue Service Grid'i projekteerimisel soovisime kõigepealt tagada sünkroonse juurutamise: kui kasutaja saab API kaudu juhtimise tagasi, saab ta kohe teenuseid kasutada. Soovisime anda algatajatele ka võimaluse juurutamise vigu töödelda.

Samuti soovisime rakendamise lihtsustamist, nimelt loobuda tehingutest ja taaskaalutamisest. Kuigi vahemälu on replikeeritud ja tasakaalu ei ole, esines suurtel juurutustel mitmete sõlmede vahel probleeme. Sõlmed peavad teavet vahetama topoloogia muutmisel ja suurte juurutuste korral võivad need andmed olla väga mahukad.

Kui topoloogia oli ebastabiilne, vajas koordineerija teenuste jaotuse uuesti arvutamiseks. Üldiselt, kui tuleb töötada tehingutega ebastabiilses topoloogias, võivad need viia keerukalt prognoositavate vigadeni.

Probleemid

Millised suured muutused oleksid ilma kaasnevate probleemideta? Esimene neist oli topoloogia muutus. Tuleb mõista, et igal ajal, isegi teenuse juurutamise hetkel, võib sõlm jõuda klastrisse või sellest välja minna. Veelgi enam, kui juurutamise hetkel liitub sõlm klastriga, on vajalik kogu teenuste teabe järjepidev edastamine 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õiks eraldi nimekirja koostada:

• Kuidas juurutada staatiliselt konfigureeritud teenuseid sõlme käivitamisel?
• Sõlme väljumine klastrist – mida teha, kui sõlm majutas teenuseid?
• Mida teha, kui koordineerija on vahetunud?
• Mida teha, kui klient on klastriga uuesti ühendatud?
• Kas tuleb töödelda aktiveerimise/deaktiveerimise päringuid ja kuidas?
• Aga mis juhtub, kui hävitamispäring saatakse vahemälule, mida on seotud affiniteedi teenustega?

Ja see ei ole kaugeltki kõik.

Lahendus

Sihtmärgiks valisime sündmustel põhineva lähenemise, rakendades protsesside vahelist suhtlust sõnumite kaudu. Ignite'is on juba rakendatud kaks komponente, mis võimaldavad sõlmedel üksteisele sõnumeid edastada — communication-spi ja discovery-spi.

Communication-spi võimaldab sõlmedel omavahel otse suhelda ja sõnumeid edastada. See sobib hästi suurte andmemahtude edastamiseks. Discovery-spi võimaldab saata sõnumi kõigile klastris olevatele sõlmedele. Tüüpilises rakenduses toimub see «ring» topoloogia kaudu. On ka integreerimine Zookeeperiga, mille puhul kasutatakse «täht» topoloogiat. Tasub mainida ka ühte olulist hetke: discovery-spi annab garantii, et sõnumid toimetatakse õiges järjekorras kõigile sõlmedele.

Vaatame saatmisprotokolli. Kõik kasutaja saatmis- ja tühistamissoovid saadetakse discovery-spi kaudu. See annab järgmised garantiid:

• Päring jõuab kõigi klastris olevate sõlmedeni. See võimaldab jätkata päringu töötlemist koordinaatori vahetamisel. Samuti tähendab see, et iga sõnumi puhul on igal sõlmel kõik vajalikud metaandmed, nagu teenuse konfiguratsioon ja selle serialiseeritud eksemplar.
• Sõnumite ranget järjekorra edastamist saab kasutada konfiguratsioonide ja konkurentsivõimeliste päringute konfliktide lahendamiseks.
• Kuna sõlme sisenemine topoloogiasse töödeldakse samuti discovery-spi kaudu, saavad uued sõlmed kõik teenustega töötamiseks vajalikud andmed.

Päringu saamisel valideerivad klastris olevad sõlmed selle ja loovad töötlemiseks ülesanded. Need ülesanded kogutakse järjekorda ja seejärel töödeldakse eraldi töölise poolt teises harudes. See on nii rakendatud, et kuna saatmine võib võtta märkimisväärselt aega, ei tohi kuluka discovery-voo katkestust lubada.

Kõiki järjekorrast päringuid töötleb deployment-manager. Tal on spetsiaalne töötaja, kes tõmbab ülesande järjekorrast ja algatab selle, et alustada ülesande täitmist. Pärast seda toimub järgnev:

1. Iga sõlm arvutab ise jaotuse uuendatud deterministliku assignimise funktsiooni põhjal.
2. Sõlmed koostavad sõnumi saatmise resultaatidest ja saadavad selle koordinaatorile.
3. Koordinaator kogub kõik sõnumid ja koostab kokkuvõtte kogu saatmisprotsessist, mis saadetakse discovery-spi kaudu kõigile klastris olevatele sõlmedele.
4. Pärast tulemuse saamist lõppeb saatmisprotsess, mille järel ülesanne eemaldatakse järjekorrast.

Uus event-driven disain: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java

Kui juurutamise ajal toimub tõrge, lisab sõlm kohe selle vea sõnumisse, mis saadetakse koordinaatorile. Pärast sõnumite kogumist on koordinaatoril teave kõigist tõrgetest juurutamise ajal ja saadab selle sõnumi discovery-spi kaudu. Tõrgete teave on saadaval igas klastri sõlmes.

Selle töö algoritmi alusel töödeldakse kõiki olulisi sündmusi Teenuste Gridis. Näiteks topoloogia muutmine on samuti sõnum discovery-spi kaudu. Ja kokkuvõttes, võrreldes varasemaga, osutus protokoll piisavalt kergekaaluliseks ja usaldusväärseks. Nii et see suudab käsitleda igasuguseid olukordi juurutamise ajal.

Mis saab edasi

Nüüd plaanidest. Iga suurem täiendus projektis Ignite viiakse läbi kui algatus Ignite'i täiustamiseks, nn IEP. Teenuste Gridi ümberkujundamisprotsessil on samuti IEP — IEP №17 naljaka nimega "Õli vahetamine Teenuste Gridis". Kuid tegelikult ei vahetanud me mitte mootori õli, vaid terve mootori.

IEP ülesanded jagasime kaheks faasiks. Esimene on suur faas, mis hõlmab juurutamise protokolli ümbertegemist. See on juba peaharusse integreeritud, saate proovida uut Teenuste Gridi, mis ilmub versioonis 2.8. Teine faas hõlmab paljusid muid ülesandeid:

• Kuuma uuesti juurutamine
• Teenuste versioonimine
• Tõrke taluvuse suurendamine
• Kerge klient
• Seire- ja erinevate mõõdikute arvestuse tööriistad

Lõpuks saame soovitada teile Teenuste Gridi kõrge kättesaadavuse tõrke taluva süsteemi loomiseks. Ja kutsume teid liituma meiega dev-list ja user-list oma kogemuste jagamiseks. Teie kogemus on tõeliselt oluline kogukonna jaoks, see aitab mõista, kuhu edasi liikuda ja kuidas edaspidi komponenti arendada.

Allikas: habr.com