Igapäevastest avariidest stabiilsuseni: Informatica 10 administraatori silmade läbi

Andmete ladustamise ETL-komponent jääb sageli peamise ladustamise varju ja sellele pööratakse vähem tähelepanu kui peamisele andmebaasile või esifunktsioonidele, nagu BI ja aruandlus. Siiski mängib ETL andmete laadimise mehhanismi osas võtmerolli ja vajab haldurite tähelepanu mitte vähem kui teised komponendid. Minu nimi on Aleksandr, hetkel haldan ETL-i ettevõttes Rostelecom, ja antud artiklis püüan jagada oma kogemusi, millega silmitsi seisab haldur tuntud ETL-süsteemi juures suures andmete ladustamise mahus ettevõttes Rostelecom.

Kui austatud lugejad on juba tuttavad meie andmete ladustamise projektiga ja toote Informatica PowerCenteriga, siis võib kohe järgmisesse jaotisesse üle minna.

Mõni aasta tagasi sündis Rostelecomis idee ühtsest ettevõtte andmesalvestusest ning see hakkas ellu viidama. Mitmed salvestussüsteemid, mis lahendasid erinevaid ülesandeid, olid juba loodud, kuid stsenaariumide arv kasvas, hoolduskulud suurenesid ning sai selgeks, et tulevik kuulub centraliseerimisele. Arhitektuuriliselt koosneb see salvestus mitmest kihist, rakendatud Hadoopis ja GreenPlumis, abistavad andmebaasid, ETL mehhanismid ja BI.

Samas, arvestades suurte territoriaalsete ja heterogeensete andmeallikate arvu, loodi spetsiaalne andmete eksportimise mehhanism, mille tööd juhib Informatica. Tulemusena jõuavad andmepaketid Hadoopi liidesealasse, pärast mida algavad andmete laadimise protsessid salvestuse kihtidesse, Hadoopisse ja GreenPlumi, mida juhib nn ETL juhtimismehhanism, mis on rakendatud Informatica. Seega on Informatica süsteem üks võtmeelemente, mis tagab salvestuse toimimise.

Meie salvestusest räägitakse lähemalt ühes järgnevates postitustes.

Informatica PowerCenter/Big Data Management on hetkel peetakse juhtivaks tarkvaraks andmete integreerimise tööriistade valdkonnas. See on Ameerika ettevõtte Informatica toode, mis on üks tugevaimaid mängijaid ETL (Extract Transform Load), andmekvaliteedi haldamise, MDM (Master Data Management), ILM (Information Lifecycle Management) ja muudes valdkondades.

Kasutatav PowerCenter on integreeritud rakenduste server Tomcat, milles töötavad ise Informatica rakendused, mis rakendavad selle teenuseid:

Domeen, see on põhimõtteliselt alus kogu ülejäänule, mille raames tegutsevad teenused, kasutajad ja GRID-i komponendid.

Administrator Console, veebi haldus- ja monitooringu tööriist, lisaks Informatica arendaja kliendile, põhivahend tootega suhtlemiseks

MRS, Model Repository Service, metadata storage, toimib kihina andmebaasi vahel, kus metaandmed füüsiliselt talletatakse, ja Informatica Developer kliendi vahel, kus arendus toimub. Repositoriad hoiavad nii andmete kirjeldusi kui ka muud teavet, sealhulgas mitme muu Informatica teenuse jaoks, näiteks tööde käivitamise ajakava (Schedules) või jälgimisandmeid, samuti rakenduste parameterset’id, mis võimaldavad kasutada sama rakendust erinevate andmeallikate ja sihtkohtadega töötamiseks.

DIS, Andmeintegratsiooni teenus, see on teenus, kus toimuvad põhifunktsionaalsed protsessid, kus töötavad rakendused ja toimub tegelik Workflows (mappingute järjestuse ja nende omavaheline suhtlemine) ja Mappings (transformatsioonide, plokkide, kus toimuvad andmete töötlemise muutused).

GRID-i konfiguratsioon – sisuliselt on see komplekside ehitamise variant, kus mitmed serverid koos töötavad, jagades DIS-i tõukejõudu sõlmede (st domeenisse kuuluvate serverite) vahel. Sellise variandi puhul, peale DIS-i koormuse jaotamise läbi täiendava abastraktsiooni kihi GRID, mis ühendab mitmeid sõlmi, mis töötavad DIS-iga, mitte ainult ühel konkreetsel sõlmil, võivad samuti olla loodud täiendavad varukoopia MRS-i eksemplarid. Võib isegi rakendada kõrget saadavust, kus välistes taotlustes saab ühendust luua läbi varu sõlmede, kui peamine langeb välja. Sellisest ehitamisvariantist oleme veel loobunud.

Informatica PowerCenter, scheemiliselt

Andmete tarne ahelas töötamise varastes etappides esines pidevalt probleeme, millest osa oli tingitud Informatica tol ajal ebastabiilsest tööst. Kavatseme jagada mõningaid meeldejäävamaid hetki sellest saagast – Informatica 10 omandamine.

Eelmine Informatica logo

Meie osakonna vastutusalasse kuuluvad ka teised Informatica keskkonnad, millel on oma spetsiifika erineva koormuse tõttu. Praegu keskendun aga sellele, kuidas Informatica on arenenud ETL-komponendina andmehoidla osana.

Kuidas see juhtus

2016. aastal, kui hakkasime vastutama Informatica töö eest, oli see juba jõudnud versioonini 10.0. Optimistlikult meelestatud kolleegide jaoks, kes otsustasid toote rakendamise üle, oli kõik selge — kasutada tuleb uut versiooni! Riistvaralised ressursid olid sel ajal suurepärased.

2016. aasta kevadest vastutas Informatica töö eest alltöövõtja ning väheste süsteemi kasutajate sõnul "töötas see paar korda nädalas". Siin on vaja selgitada, et andmehoidla oli de facto PoC etapis, administraatoreid meeskonnas ei olnud ja süsteem langes pidevalt erinevatel põhjustel, pärast mida tõstis alltöövõtja insener selle uuesti üles.

Sügiseks liitus meeskonnas kolm administraatorit, kes jagasid omavahel vastutusalad, ja süsteemide tõhus haldamine projektis, sealhulgas Informatica, hakkas sujuma. Peab eraldi märkima, et see toode ei ole laialdaselt levinud ega oma suurt kogukonda, kust leida vastuseid küsimustele või lahendada probleeme. Seetõttu oli äärmiselt oluline tõhus tehniline tugi Vene partnerilt Informatica, kelle abil parandati kõik meie vead ja ka noore Informatica 10 vead.

Esimene asi, mida meie meeskonna arendajate ja alltöövõtjate jaoks tegema pidime, oli Informatica töö stabiliseerimine ja web-administreerimise konsoli (Informatica Administrator) töökorda saamine.

Nii kohtasime sageli Informatica arendajaid.

Jätkates probleemiosalist välja jätmist, oli peamine põhjuseks Infomratica tarkvara suhtlemise skeem andmebaasi reposiitriumiga, mis asus võrgu maastiku seisukohalt suhteliselt kaugel serveris. See tekitas hilinemisi ja häiris Informatica domeeni oleku kontrollimise mehhanismide toimimist. Andmebaasi mõningase häälestamise, Informatica parameetrite muutmise, mis muutsid selle andmebaasi viivituste suhtes tolerantsemaks, ning lõpuks versiooniuuendamise Infomratica versioonile 10.1 ja andmebaasi üleviimise eelmiselt serverilt lähemal asuvasse serverisse, kaotas probleem oma aktuaalsuse ning selliseid tõrkeid me enam ei jälgi.

Üks katsetest saavutada Informatica Monitori töö

Administreerimise konsool oli samuti kriitilises seisundis. Kuna aktiivne arendustegevus käidi otse tootmiskeskkonnas, oli kolleegidel pidevalt vajalik analüüsida mappings'i ja workflow'd "liikvel" olles. Uues Informatica Data Integration Service'is pole eraldi tööriista selliseks jälgimiseks, kuid veebikonsoolis on ilmunud jälgimise sektsioon (Informatica Administrator Monitor), kus on võimalik jälgida rakenduste, workflow'de ja mappings'ite tööd, käivitusi ja logisid. Aeg-ajalt muutus konsool täiesti kättesaamatuks, või lakkasid DIS-i käimasolevate protsesside andmed uuendumast, või tekkisid vead lehtede laadimisel.

Java parameetrite kohandamine töö stabiilsuse tagamiseks

Probleemi lahendamine toimus mitmeid teid pidi, eksperimenteeriti parameetrite muutmisega, koguti logisid, jstack'e, saadeti tugiteenusesse, samal ajal toimus aktiivne googeldamine ja lihtsalt jälgimine.

Esmalt oli loodud eraldi MRS jälgimiseks, kuna hiljem osutus see üheks meie keskkondade peamiseks ressursikasutajaks, kuna mappingute käivitamine toimub väga intensiivselt. Muudetud on java heap'i seadeid ja mitmeid teisi.
Tulemuseks oli, et järgmise Informatica 10.1.1 uuenduse puhul õnnestus konsoli ja monitori töö stabiliseerida, arendajad hakkasid töötama efektiivsemalt ning regulaarprotsessid muutusid üha regulaarsemaks.

Huvitav võib olla kogemus arenduse ja haldamise vahel. Ühine arusaam sellest, kuidas kõik töötab, mida on võimalik teha ja mida mitte, on alati oluline keeruliste süsteemide kasutamisel. Seetõttu on soovitatav kõigepealt koolitada administratiivmeeskond selle kohta, kuidas tarkvara haldada, ja arendajate meeskond selle kohta, kuidas koodi kirjutada ja süsteemis protsesse kavandada, ning alles seejärel lasta neil töötada. See on tõeliselt oluline, kui aeg ei ole lõpmatu ressurss. Paljusid probleeme saab lahendada isegi juhusliku lahenduste proovimise kaudu, kuid mõnikord on mõned neist nõuavad eelnevat teadmisi — meie juhtum kinnitab selle aksioomi mõistmise olulisust.

Näiteks, kui proovida aktiveerida versioonihaldust MRS-is (kui lõpuks selgub, et vajalik oli teine SVN versioon), avastasime mõne aja pärast murelikult, et süsteemi taaskäivitamise aeg oli kasvanud mitme kümne minutini. Põhjuse leidmisel ja versioonihalduse väljalülitamisel läks kõik taas hästi.

Mõned märkimisväärsed takistused, millega seoses on seotud Informatica, hõlmavad eepilist võitlust kasvavate Java-voogudega. Ühel hetkel tuli kohtumisele, et expandida loodud protsessid suurtele allika süsteemidele. Selgus, et kaugelki kõik protsessid versioonis 10.1.1 ei töötanud hästi ning mõne aja pärast muutus DIS toimimatuks. Avastati kümneid tuhandeid vooge, mille arv kasvas eriti silmatorkavalt rakenduste juurutamise protseduuri käigus. Mõnikord tuli töövõime taastamiseks teha mitu restarti päevas.

Siinkohal tuleb tänada tuge, probleemid lokaliseeriti ja parandati võrreldes kiiresti EBF (Emergency Bug Fix) abil – pärast seda tundsid kõik, et tööriist tõepoolest töötab.

See töötab tõepoolest!

Kui Informatica sihtrežiimis tööle asus, nägi see välja järgmiselt. Versioon Informatica 10.1.1HF1 (HF1 on HotFix1, tootja ehitus EBF-de kogumisest) oli lisatud EBF, mis lahendas meie mastaapsuse probleemid ja mõned muud, ühel kolmest GRID-i serverist, 20 x86_64 tuuma ja salvestus suurel aeglasel kohalike ketaste kogumil — see on serveri konfiguratsioon Hadoop-kliendile. Teisel samasugusel serveril on Oracle DB, millega töötavad nii Informatica domeen kui ka ETL-i juhtimismehhanism. Kõike seda jälgitakse meeskonnas kasutatavate tavapäraste jälgimisvahendite (Zabbix + Grafana) abil, kahest osapoost — nii Informatica kui tema teenustest, kui ka laadimisprotsessidest. Praegu sõltuvad jõudlus ja töö stabiilsus, arvestamata väliseid tegureid, seadistustest, mis piiravad koormust.

GRID-ist on eraldi rääkimist väärt. Keskkond ehitati kolme Node'i põhjal, koormuse tasakaalustamise võimalusega. Siiski testimise käigus leiti, et meie rakenduste käivitatud instantside vahelise suhtlemise probleemide tõttu ei töötanud selline konfiguratsioon oodatud viisil, mistõttu otsustati ajutiselt sellest skeemist loobuda, viies kaks kolmest node'ist domeenist välja. Skeem ise jäi samaks ja see on praegu GRID-teenus, kuid lihtsustatud ühe node'iga.

Hetkel on endiselt keerukus, mis on seotud jõudluse langusega monitooringu skeemi regulaarse puhastamise käigus — samal ajal toimuva töötlemise ja käivitatud puhastuse tõttu võivad ETL-i juhtimise mehhanismi töös esineda tõrked. See lahendatakse praegu „kustutuste” kaudu — monitooringu skeemi käsitsi puhastamisega, kaotades kõik varasemad andmed. See ei ole liiga kriitiline tootmises tavapärase töö käigus, kuid samas otsitakse normaalsemat lahendust.

Samas olukorrast tuleneb veel üks probleem — mõnikord toimuvad meie juhtimismehhanismi mitu käivitamist.

Rakenduste korduvad käivitamised, mis põhjustavad mehhanismi purunemise.

Ajakava järgi käivitamisel süsteemi suurte koormuste hetkedest võivad tekkida olukorrad, mis viivad mehhanismi purunemiseni. Probleemi lahendatakse siiani käsitsi, otsides püsivat lahendust.

Kokkuvõttes võib öelda, et suurte koormuste korral on äärmiselt oluline pakkuda adekvaatseid ressursse, sealhulgas nii riistvaralisi ressursse Informatica jaoks kui ka andmebaasi hoidmiseks, samuti tagada nendele optimaalsed seaded. Lisaks on küsimus lahtine seoses sellega, milline andmebaasi paigutusskeem on parem — eraldi serveris või samas serveris, kus töötab Informatica tarkvara. Ühelt poolt on ühe serveri kasutamine odavam ja ühendamise korral praktiliselt kõrvaldatakse võrguside probleem, teisalt tõukab andmebaasi koormus serveri koormust ülespoole, lisandudes Informatica koormusele.

Nagu igas tõsises tootmises, leidub ka Informatica puhul paar naljakat hetke.
Kord, kui uurisin mõnda õnnetust, pöörasin tähelepanu sellele, et MRS logides on sündmuste kellaaeg kahtlaselt märgitud.

Ajadualism MRS logides on "disaini tõttu".

Selgus, et ajatempleid kirjutatakse 12-tunnises formaadis, ilma AM/PM näidusteta, st enne või pärast keskpäeva. Selle kohta avati isegi paberimajandus ja saadi ametlik vastus – just nii oli see ette nähtud, logis MRS on märgid kirjutatud just sellises formaadis. See jätab vahel siiski mingi intriigi seoses mõne ERROR-i tekkimise ajaga...

Püüdle paremuse poole

Tänaseks on Informatica piisavalt stabiilne tööriist, mis on mugav administraatoritele ja kasutajatele ning neid võimalusi ja potentsiaali arvesse võttes äärmiselt võimas. See ületab meie funktsionaalsed vajadused korduvalt ja de facto kasutatakse seda projektis mitte kõige iseloomulikumas ja tüüpilisemalt. Raskused on osaliselt seotud sellega, kuidas mehhanismid töötavad – eripära seisneb selles, et lühikese ajavahemiku jooksul käivitatakse suur hulk protsesse, mis intensiivselt värskendavad parameterset’e ja töötavad andmebaasi reposiitriumiga, samal ajal kui serveri riistvararessursid on protsessoril peaaegu täielikult利用itud.

Oleme nüüd lähedal üleminekule Informatica 10.2.1 või 10.2.2 versioonile, kus on ümber tehtud mõned sisemised mehhanismid ja toetuse lubadus, et lahendatakse mitmed praegu meie jaoks olemasolevad jõudluse ja toimimise probleemid. Samuti oodatakse riistvara osas servereid, mis on meie jaoks optimaalsete konfiguratsioonidega, arvestades lähiaja kasvu ja arengu vajadusi.

Muidugi tuleb läbi viia testimine, kontrollida ühilduvust ja võimalik, et teha arhitektuuri muudatusi HA GRID osas. Informatica raames areng jätkub, kuna lühiajaliselt ei saa me süsteemi asendamiseks midagi paigaldada.
Need, kes tulevikus vastutavad selle süsteemi eest, suudavad kindlasti tuua selle nõutud usaldusväärsuse ja jõudluse näitajate juurde, mida tellijad nõuavad.

Artikkel on koostatud „Rostelecomi” andmejuhtimise meeskonna poolt.

Aktiivne Informatica logo

Allikas: habr.com