Aupa, jendea! Nire izena Oleg Anastasyev da, Odnoklassniki-n egiten dut lan Plataforma taldean. Eta niz gain, hardware asko dago lanean Odnoklassnikin. Lau datu-zentro ditugu 500 bastidor ingururekin 8 mila zerbitzari baino gehiagorekin. Une jakin batean, konturatu ginen kudeaketa sistema berri bat sartzeak ekipamenduak modu eraginkorragoan kargatzeko, sarbideen kudeaketa errazteko, baliabide informatikoen (bir)banaketa automatizatzeko, zerbitzu berrien abiarazte bizkortzeko eta erantzunak bizkortzeko aukera emango zigula. eskala handiko istripuetara.
Zer atera zen hortik?
Ni eta hardware mordoaz gain, hardware honekin lan egiten duen jendea ere bada: datu-zentroetan zuzenean kokatzen diren ingeniariak; sareko softwarea konfiguratzen duten saregileak; azpiegituren erresilientzia ematen duten administratzaileak edo SREak; eta garapen taldeek, horietako bakoitza atariaren funtzioen zati baten arduraduna da. Sortzen duten softwareak honela funtzionatzen du:
Erabiltzaileen eskaerak atari nagusiko bi frontoietan jasotzen dira , eta beste batzuetan, adibidez, musikaren API fronteetan. Negozio-logika prozesatzeko, aplikazio-zerbitzariari deitzen diote, eta horrek, eskaera prozesatzen duenean, beharrezko mikrozerbitzu espezializatuei deitzen die - grafiko bakarra (konexio sozialen grafikoa), erabiltzaile-cachea (erabiltzaile-profilen cachea), etab.
Zerbitzu horietako bakoitza makina askotan hedatzen da, eta horietako bakoitzak moduluen funtzionamenduaz, haien funtzionamenduaz eta garapen teknologikoaz arduratzen diren garatzaile arduradunak ditu. Zerbitzu hauek guztiak hardware zerbitzarietan exekutatzen dira, eta duela gutxi arte zerbitzari bakoitzeko ataza bat abiarazten genuen, hau da, zeregin zehatz baterako espezializatua zegoen.
Zergatik da hori? Ikuspegi honek hainbat abantaila zituen:
- Lasaituta masa kudeaketa. Demagun zeregin batek liburutegi batzuk, ezarpen batzuk behar dituela. Eta gero zerbitzaria zehatz-mehatz talde zehatz bati esleitzen zaio, talde honen cfengine politika deskribatzen da (edo dagoeneko deskribatu da), eta konfigurazio hau zentralki eta automatikoki zabaltzen da talde honetako zerbitzari guztietan.
- Sinplifikatua diagnostikoak. Demagun prozesadore zentraleko karga handituari erreparatzen diola eta konturatzen zarela karga hori hardware-prozesadore honetan exekutatzen den zereginak soilik sor dezakeela. Errua duen norbaiten bilaketa oso azkar amaitzen da.
- Sinplifikatua jarraipena. Zerbitzarian zerbait gaizki badago, monitoreak horren berri ematen du, eta zehatz-mehatz badakizu zein den errua.
Hainbat erreplikez osatutako zerbitzu bati hainbat zerbitzari esleitzen zaizkio, bakoitzari bat. Ondoren, zerbitzuaren baliabide informatikoa oso sinpleki esleitzen da: zerbitzuak dituen zerbitzari kopurua, kontsumi dezakeen gehienezko baliabideak. "Erraza" hemen ez du esan nahi erabiltzeko erraza denik, baliabideen esleipena eskuz egiten den zentzuan baizik.
Planteamendu honek ere egiteko aukera eman zigun burdinaren konfigurazio espezializatuak zerbitzari honetan exekutatzen ari den zeregin baterako. Zereginak datu kopuru handiak gordetzen baditu, 4 disko dituen 38U zerbitzari bat erabiltzen dugu. Zeregin hutsa konputazionala bada, orduan 1U zerbitzari merkeago bat eros dezakegu. Hau konputazionalki eraginkorra da. Besteak beste, ikuspegi horri esker, sare sozial lagunkoi baten pareko karga duten lau aldiz makina gutxiago erabil ditzakegu.
Baliabide informatikoen erabileran eraginkortasun horrek eraginkortasun ekonomikoa ere bermatu beharko luke, garestiena zerbitzariak direlako premisatik abiatuz gero. Denbora luzez, hardwarea izan zen garestiena, eta hardwarearen prezioa murrizteko ahalegin handia egin genuen, akatsen tolerantziarako algoritmoak sortuz, hardwarearen fidagarritasun-eskakizunak murrizteko. Eta gaur zerbitzariaren prezioak erabakigarria izateari utzi dion fasera iritsi gara. Azken exotikoak kontuan hartzen ez badituzu, rack-eko zerbitzarien konfigurazio zehatzak ez du axola. Orain beste arazo bat dugu: zerbitzariak datu-zentroan hartzen duen espazioaren prezioa, hau da, rack-eko espazioa.
Hori horrela zela konturatuta, bastilak zenbaterainoko eraginkortasunarekin erabiltzen ari ginen kalkulatzea erabaki genuen.
Ekonomikoki justifikagarriak diren zerbitzari boteretsuenaren prezioa hartu dugu, honelako zenbat zerbitzari jar genitzakeen bastidoreetan, zenbat zeregin exekutatu beharko genituzkeen "zerbitzari bat = zeregin bat" eredu zaharraren arabera kalkulatu dugu eta zenbat halako. zereginek ekipamendua erabil dezakete. Kontatu eta malkoak isuri zituzten. Kontuan izan da bastidoreak erabiltzeko gure eraginkortasuna %11 ingurukoa dela. Ondorioa begi bistakoa da: datu-zentroak erabiltzeko eraginkortasuna areagotu behar dugu. Konponbidea begi-bistakoa dela dirudi: hainbat zeregin exekutatu behar dituzu aldi berean zerbitzari batean. Baina hor hasten dira zailtasunak.
Masa konfigurazioa ikaragarri zaildu egiten da; orain ezinezkoa da talde bat zerbitzari bati esleitzea. Azken finean, orain komando ezberdinetako hainbat zeregin abiarazi daitezke zerbitzari batean. Gainera, konfigurazioa gatazkatsua izan daiteke aplikazio desberdinetarako. Diagnostikoa ere zaildu egiten da: zerbitzari batean CPU edo disko-kontsumo handiagoa ikusten baduzu, ez dakizu zein zeregin sortzen ari den arazoak.
Baina gauza nagusia da makina berean exekutatzen diren zereginen artean isolamendurik ez dagoela. Hona hemen, adibidez, zerbitzariaren zeregin baten batez besteko erantzun-denboraren grafiko bat zerbitzari berean beste aplikazio konputazional bat abiarazi aurretik eta ondoren, inola ere lehenengoarekin lotuta - zeregin nagusiaren erantzun-denbora nabarmen handitu da.
Jakina, zereginak edukiontzietan edo makina birtualetan exekutatu behar dituzu. Gure zeregin ia guztiak OS bakarrean (Linux) exekutatzen direnez edo horretarako egokituta daudenez, ez dugu sistema eragile ezberdin asko onartzen. Horrenbestez, birtualizazioa ez da beharrezkoa; gainkostu gehigarriaren ondorioz, edukiontziratzea baino eraginkorragoa izango da.
Zerbitzarietan atazak zuzenean exekutatzeko edukiontzien ezarpen gisa, Docker hautagai ona da: fitxategi-sistemaren irudiek ondo konpontzen dituzte konfigurazio gatazkatsuen arazoak. Irudiak hainbat geruzaz osatuta egoteari esker, azpiegituran hedatzeko beharrezkoak diren datu kopurua nabarmen murrizten dugu, zati komunak oinarrizko geruza bereizietan banatuz. Ondoren, oinarrizko geruza (eta bolumen handikoak) nahiko azkar gordeko dira azpiegitura osoan zehar, eta aplikazio eta bertsio mota asko emateko, geruza txikiak baino ez dira transferitu beharko.
Gainera, Docker-en prest egindako erregistroak eta irudien etiketatzeak prest dauden primitiboak ematen dizkigu bertsioak egiteko eta kodea ekoizpenera bidaltzeko.
Docker-ek, antzeko beste edozein teknologiak bezala, edukiontzien isolamendu maila bat eskaintzen digu kutxatik kanpo. Adibidez, memoria isolatzea: edukiontzi bakoitzari makinaren memoriaren erabilerari muga bat ematen zaio, eta hortik kanpo ez du kontsumituko. Ontziak ere isola ditzakezu CPU erabileraren arabera. Guretzat, ordea, isolamendu estandarra ez zen nahikoa. Baina horri buruz gehiago behean.
Zerbitzarietan edukiontziak zuzenean martxan jartzea arazoaren zati bat baino ez da. Beste zatia zerbitzarietan edukiontziak ostatzearekin lotuta dago. Zein edukiontzi zein zerbitzaritan jar daitekeen ulertu behar duzu. Ez da hain lan erraza, edukiontziak zerbitzarietan ahalik eta trinkoen jarri behar direlako abiadura murriztu gabe. Kokapen hori akatsen tolerantziaren ikuspuntutik ere zaila izan daiteke. Sarritan zerbitzu beraren erreplikak bastidore desberdinetan edo are datu-zentroko gela ezberdinetan jarri nahi ditugu, horrela rack edo gela batek huts egiten badu, zerbitzu-erreplika guztiak berehala gal ez daitezen.
Ontziak eskuz banatzea ez da aukera bat 8 ββmila zerbitzari eta 8-16 mila edukiontzi dituzunean.
Horrez gain, baliabideen esleipenean garatzaileei independentzia handiagoa eman nahi izan diegu, euren zerbitzuak produkzioan beraiek ostata ditzaten, administratzaile baten laguntzarik gabe. Aldi berean, kontrola mantendu nahi genuen, zerbitzu txikiren batek gure datu-zentroetako baliabide guztiak kontsumituko ez zitezen.
Jakina, hori automatikoki egingo lukeen kontrol-geruza bat behar dugu.
Beraz, arkitekto guztiek maite duten irudi sinple eta ulergarri batera iritsi ginen: hiru lauki.
one-cloud masters hodei-orkestrazioaz arduratzen den hutsegite-kluster bat da. Garatzaileak manifestu bat bidaltzen dio maisuari, eta bertan zerbitzua ostatatzeko beharrezkoa den informazio guztia jasotzen du. Horretan oinarrituta, maisuak aginduak ematen dizkie hautatutako minions (ontziak exekutatzeko diseinatutako makinak). Minions-ek gure agentea dute, komandoa jasotzen duena, bere komandoak igortzen dizkio Dockerri, eta Docker-ek linux nukleoa konfiguratzen du dagokion edukiontzia abiarazteko. Aginduak exekutatzeaz gain, agenteak etengabe jakinarazten dio maisuari bai minion makinaren eta bertan exekutatzen diren edukiontzien egoera aldaketen berri.
Baliabideen Esleipena
Orain ikus dezagun minion askorentzat baliabide konplexuagoen esleipenaren arazoa.
Hodei bakarreko baliabide informatiko bat hau da:
- Zeregin zehatz batek kontsumitzen duen prozesadorearen potentzia.
- Zereginarentzat eskuragarri dagoen memoria kopurua.
- Sareko trafikoa. Minion bakoitzak sare-interfaze espezifiko bat du banda-zabalera mugatua duena, beraz, ezinezkoa da zereginak banatzea sarean transmititzen duten datu kopurua kontuan hartu gabe.
- Diskoak. Horrez gain, jakina, zeregin hauetarako espazioari, disko mota ere esleitzen diogu: HDD edo SSD. Diskoek segundoko eskaera kopuru finitu bat bete dezakete - IOPS. Hori dela eta, disko bakar batek kudeatu dezakeena baino IOPS gehiago sortzen dituzten zereginetarako, "ardatzak" ere esleitzen ditugu, hau da, atazarako soilik gorde behar diren disko-gailuak.
Ondoren, zerbitzu batzuetarako, adibidez erabiltzaile-cacherako, kontsumitutako baliabideak modu honetan graba ditzakegu: 400 prozesadore nukleo, 2,5 TB memoria, 50 Gbit/s-ko trafikoa bi noranzkoetan, 6 ardatzetan kokatutako 100 TB HDD espazioa. Edo honelako forma ezagunago batean:
alloc:
cpu: 400
mem: 2500
lan_in: 50g
lan_out: 50g
hdd:100x6TErabiltzaile-cacheko zerbitzu-baliabideek produkzio-azpiegiturako baliabide erabilgarri guztien zati bat baino ez dute kontsumitzen. Hori dela eta, ziurtatu nahi dut bat-batean, operadorearen errore bat dela eta, erabiltzaile-cacheak ez duela esleitzen zaizkion baliabide gehiago kontsumitzen. Hau da, baliabideak mugatu behar ditugu. Baina zeri lotu genezake kupoa?
Itzuli gaitezen osagaien elkarrekintzaren oso sinplifikatutako diagrama eta marraztu dezagun xehetasun gehiagorekin, honela:
Zerk harrapatzen dizu begia:
- Web frontend-ak eta musikak aplikazio-zerbitzari bereko kluster isolatuak erabiltzen dituzte.
- Kluster hauek dauden geruza logikoak bereiz ditzakegu: fronteak, cacheak, datuak biltegiratzea eta kudeaketa geruza.
- Frontend-a heterogeneoa da; azpisistema funtzional ezberdinez osatuta dago.
- Cacheak cachean gordetzen dituen azpisisteman ere saka daitezke.
Marraz dezagun berriro irudia:
Bah! Bai, hierarkia bat ikusten dugu! Horrek esan nahi du baliabideak zati handiagoetan banatu ditzakezula: esleitu garatzaile arduratsu bat azpisistema funtzionalari dagokion hierarkia honetako nodo bati (irudian "musika" bezala) eta erantsi kuota bat hierarkiaren maila berean. Hierarkia horrek zerbitzuak malgutasun handiagoz antolatzeko aukera ere ematen digu, kudeaketa errazteko. Esate baterako, web guztia zatitzen dugu, zerbitzarien talde oso handia denez, hainbat talde txikitan, irudian talde1, talde2 gisa agertzen dena.
Lerro gehigarriak kenduz, gure irudiaren nodo bakoitza forma lauago batean idatz dezakegu: taldea1.web.aurrealdea, api.music.front, user-cache.cache.
Horrela iritsiko gara βilara hierarkikoarenβ kontzeptura. "group1.web.front" bezalako izena du. Baliabideen eta erabiltzaileen eskubideen kuota bat esleitzen zaio. DevOps-eko pertsonari zerbitzu bat ilaran bidaltzeko eskubideak emango dizkiogu, eta halako langile batek ilaran zerbait abiarazi dezake, eta OpsDev-eko pertsonak administratzaile eskubideak izango ditu, eta orain ilara kudea dezake, han jendea esleitu, eman pertsona horiei eskubideak, etab. Ilara honetan exekutatzen diren zerbitzuak ilararen kuotaren barruan exekutatzen dira. Ilararen konputazio-kuota ez bada nahikoa zerbitzu guztiak aldi berean exekutatzeko, orduan sekuentzialki exekutatu egingo dira, horrela ilara bera osatuz.
Ikus ditzagun arretaz zerbitzuak. Zerbitzu batek izen guztiz kualifikatua du, beti ilararen izena jasotzen duena. Ondoren, aurrealdeko web zerbitzuak izena izango du ok-web.group1.web.front. Eta sartzen den aplikazio-zerbitzari-zerbitzuari deituko zaio ok-app.group1.web.front. Zerbitzu bakoitzak manifestu bat du, eta bertan makina zehatzetan kokatzeko beharrezko informazio guztia zehazten du: zeregin honek zenbat baliabide kontsumitzen dituen, zer konfigurazio behar den horretarako, zenbat erreplika izan behar diren, zerbitzu honen akatsak kudeatzeko propietateak. Eta zerbitzua zuzenean makinetan jarri ondoren, bere instantziak agertzen dira. Anbiguorik gabe ere izendatzen dira - instantzia-zenbakia eta zerbitzu-izen gisa: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front,β¦
Hau oso erosoa da: martxan dagoen edukiontziaren izenari bakarrik begiratuta, berehala jakin dezakegu asko.
Orain ikus ditzagun kasu hauek benetan zer egiten duten: zereginak.
Zereginak Isolatzeko Klaseak
Ados-eko zeregin guztiak (eta, ziurrenik, nonahi) taldetan bana daitezke:
- Latentzia laburreko ataza - prod. Halako zeregin eta zerbitzuetarako, erantzunaren atzerapena (latentzia) oso garrantzitsua da, sistemak eskaera bakoitza zein azkar prozesatuko duen. Zereginen adibideak: web-aurreak, cacheak, aplikazio-zerbitzariak, OLTP biltegiratzea, etab.
- Kalkulu-arazoak - lotea. Hemen, eskaera zehatz bakoitzaren prozesatzeko abiadura ez da garrantzitsua. Haientzat, garrantzitsua da zeregin horrek zenbat kalkulu egingo dituen denbora-tarte jakin batean (luzea). Hauek izango dira MapReduce, Hadoop, ikaskuntza automatikoa, estatistikak.
- Atzeko planoko zereginak - inaktibo. Horrelako zereginetarako, ez latentzia ez transmisioa ez dira oso garrantzitsuak. Horrek hainbat proba, migrazio, birkalkuluak eta datuen formatu batetik bestera bihurtzea barne hartzen ditu. Alde batetik, kalkulatutakoen antzekoak dira, bestetik, ez zaigu axola zenbat azkar osatzen diren.
Ikus dezagun nola kontsumitzen dituzten zereginek baliabideak, adibidez, prozesadore zentralak.
Atzerapen laburreko zereginak. Zeregin horrek PUZaren kontsumo eredua izango du honen antzekoa:
Erabiltzailearen eskaera bat jasotzen da prozesatzeko, zeregina erabilgarri dauden CPU nukleo guztiak erabiltzen hasten da, prozesatzen du, erantzun bat itzultzen du, hurrengo eskaeraren zain geratzen da eta gelditzen da. Hurrengo eskaera iritsi zen - berriro zegoen guztia aukeratu genuen, kalkulatu eta hurrengoaren zain gaude.
Zeregin baterako gutxieneko latentzia bermatzeko, kontsumitzen dituen baliabide maximoak hartu eta beharrezko nukleo kopurua erreserbatu behar dugu minionean (ataza exekutatuko duen makina). Orduan gure arazoaren erreserba-formula hau izango da:
alloc: cpu = 4 (max)eta 16 nukleo dituen minion makina bat badugu, orduan zehazki lau zeregin jar daitezke bertan. Bereziki ohartzen gara horrelako zereginen batez besteko prozesadorearen kontsumoa oso baxua dela askotan, hori begi bistakoa da, zereginak denboraren zati handi batean eskaera baten zain geratzen baita eta ez du ezer egiten.
Kalkulu-zereginak. Haien eredua zertxobait desberdina izango da:
Honelako zereginetarako CPU baliabideen batez besteko kontsumoa nahiko altua da. Askotan kalkulu-ataza bat denbora-tarte jakin batean burutzea nahi dugu, beraz, behar dituen gutxieneko prozesadore kopurua erreserbatu behar dugu, kalkulu osoa denbora onargarrian burutu dadin. Bere erreserba-formula honela izango da:
alloc: cpu = [1,*)"Mesedez, jarri minion baten gainean, gutxienez nukleo libre bat dagoen, eta, gero, dauden adina, dena irentsiko du".
Hemen erabileraren eraginkortasuna askoz ere hobea da atzerapen laburreko zereginetan baino. Baina irabazia askoz handiagoa izango da bi zeregin motak makina minion batean konbinatzen badituzu eta bere baliabideak edonon banatzen badituzu. Atzerapen txikia duen ataza batek prozesadore bat behar duenean, berehala jasotzen du, eta baliabideak gehiago behar ez direnean, konputazio-zereginera pasatzen dira, hau da, honelako zerbait:
Baina nola egin hori?
Lehenik eta behin, ikus ditzagun prod eta bere alloka: cpu = 4. Lau nukleo erreserbatu behar ditugu. Docker exekutatzen bi modutan egin daiteke:
- Aukera erabiliz
--cpuset=1-4, hau da, makinan lau nukleo zehatz esleitu zereginari. - erabiltzea
--cpuquota=400_000 --cpuperiod=100_000, esleitu kuota bat prozesadorearen denborarako, hau da, adierazi denbora errealeko 100 ms bakoitzean zereginak ez duela prozesadorearen denbora 400 ms baino gehiago kontsumitzen. Lau nukleo berdinak lortzen dira.
Baina metodo hauetatik zein da egokia?
cpuset itxura nahiko erakargarria da. Zereginak lau nukleo dedikatu ditu, hau da, prozesadorearen cacheak ahalik eta modu eraginkorrenean funtzionatuko duela. Honek ere alde txarra du: kalkuluak makinaren deskargatutako nukleoetan zehar banatzeko zeregina bere gain hartu beharko genuke OSaren ordez, eta zeregin ez-huts samarra da, batez ere batch zereginak halako batean jartzen saiatzen bagara. makina. Testek frogatu dute hemen hobeto egokitzen dela kuota duen aukera: horrela sistema eragileak askatasun handiagoa du unean uneko ataza egiteko nukleoa aukeratzeko eta prozesadorearen denbora eraginkorrago banatzen da.
Ikus dezagun nola egin erreserbak Docker-en gutxieneko nukleoen arabera. Batch zereginetarako kuota jada ez da aplikagarria, ez baitago gehienezko muga mugatu beharrik, gutxienekoa bermatzea nahikoa da. Eta hemen aukera ondo egokitzen da docker run --cpushares.
Adostu genuen lote batek gutxienez nukleo baterako bermea eskatzen badu, orduan adierazten dugu --cpushares=1024, eta gutxienez bi nukleo badaude, orduan adierazten dugu --cpushares=2048. CPU akzioek ez dute inola ere oztopatzen prozesadorearen denboraren banaketan, nahikoa den bitartean. Horrela, prod-ek ez baditu bere lau nukleoak erabiltzen, ez dago batch zereginak mugatzen dituenik, eta prozesadorearen denbora gehigarria erabil dezakete. Baina prozesadore eskasia dagoen egoeran, prod-ek bere lau nukleoak kontsumitu baditu eta bere kuota lortu badu, gainerako prozesadorearen denbora proportzionalki banatuko da cpushares-ekin, hau da, hiru nukleo libreko egoeran, bat izango da. 1024 cpusharre dituen ataza bati emango zaio, eta gainontzeko biak 2048 cpusharre dituen ataza bati emango zaizkio.
Baina kuota eta akzioak erabiltzea ez da nahikoa. Ziurtatu behar dugu atzerapen laburreko ataza batek batch-zeregin baten aurrean lehentasuna duela prozesadorearen denbora esleitzerakoan. Lehentasun hori gabe, lote-zereginak prozesadorearen denbora guztia hartuko du produktuak behar duen unean. Docker-en exekuzioan ez dago edukiontzien lehentasun-aukerarik, baina Linux CPU-ren programatzaileen politikak erabilgarriak dira. Haiei buruz zehatz-mehatz irakur dezakezu , eta artikulu honen esparruan labur-labur aztertuko ditugu:
- SCHED_OTHER
Lehenespenez, Linux makina bateko erabiltzaile-prozesu arrunt guztiek jasotzen dute. - SCHED_BATCH
Baliabide askoko prozesuetarako diseinatua. Zeregin bat prozesadore batean jartzean, aktibazio-zigorra deritzon bat sartzen da: zeregin horrek prozesadore-baliabideak jasotzeko aukera gutxiago du une honetan SCHED_OTHER duen zeregin batek erabiltzen badu. - SCHED_IDLE
Lehentasun oso baxuko atzeko prozesu bat, -19 polita baino txikiagoa ere. Gure kode irekiko liburutegia erabiltzen dugu , deituz edukiontzia abiaraztean beharrezko politika ezartzeko
one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )Baina Javan programatzen ez baduzu ere, gauza bera egin daiteke chrt komandoa erabiliz:
chrt -i 0 $pidLabur ditzagun gure isolamendu-maila guztiak taula batean argitzeko:
Isolamendu-klasea
Alloc adibidea
Docker exekutatzeko aukerak
sched_setscheduler chrt*
Prod
CPU = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER
Batch
CPU = [1, *)
--cpushares=1024
SCHED_BATCH
idle
CPU= [2, *)
--cpushares=2048
SCHED_IDLE
* Edukiontzi baten barruan chrt egiten ari bazara, baliteke sys_nice gaitasuna behar izatea, lehenespenez Docker-ek gaitasun hori kentzen baitu edukiontzia abiaraztean.
Baina zereginek prozesadorea ez ezik, trafikoa ere kontsumitzen dute, eta horrek sareko ataza baten latentzian are gehiago eragiten du prozesadorearen baliabideen esleipen okerra baino. Hori dela eta, zirkulaziorako irudi berdina lortu nahi dugu. Hau da, prod ataza batek pakete batzuk sarera bidaltzen dituenean, gehienezko abiadura mugatzen dugu (formula alloc: lan=[*,500mbps) ), zein prod-ek hau egin dezakeen. Eta loterako gutxieneko errendimendua soilik bermatzen dugu, baina ez dugu gehienez mugatzen (formula alloc: lan=[10Mbps,*) ) Kasu honetan, produktuen trafikoak lehentasuna izan beharko luke lotekako zereginen aurrean.
Hemen Docker-ek ez du erabil dezakegun primitiborik. Baina gure laguntzara dator . Diziplinaren laguntzarekin nahi genuen emaitza lortu genuen . Bere laguntzarekin, bi trafiko klase bereizten ditugu: lehentasun handiko produktua eta lehentasun baxuko lote/inaktiboa. Ondorioz, irteerako trafikoaren konfigurazioa honelakoa da:
hemen 1:0 hsfc diziplinaren "root qdisc" da; 1:1 - hsfc haur-klasea 8 Gbit/s-ko banda-zabalera guztirako muga duena, eta horren azpian edukiontzi guztien seme-alabak jartzen dira; 1:2 - hsfc seme-alaba klasea batch eta inaktiboko zeregin guztietan komuna da "dinamiko" muga duten, eta hori behean aztertzen da. Gainerako hsfc seme-alabak klase dedikatuak dira une honetan prod edukiontziak exekutatzen dituztenentzat, manifestuei dagozkien mugekin: 450 eta 400 Mbit/s. Hsfc klase bakoitzari qdisc ilara fq edo fq_codel bat esleitzen zaio, Linux kernelaren bertsioaren arabera, trafiko-leherketan paketeak gal ez daitezen.
Normalean, tc diziplinek irteerako trafikoa soilik lehenesteko balio dute. Baina sarrerako trafikoa ere lehenetsi nahi dugu; azken finean, batch zeregin batzuek erraz hauta dezakete sarrerako kanal osoa, adibidez, sarrerako datu sorta handi bat jasoz mapa eta murrizteko. Horretarako modulua erabiltzen dugu , sareko interfaze bakoitzeko ifbX interfaze birtual bat sortzen duena eta sarrerako trafikoa interfazetik ifbX-en irteerako trafikora birbideratzen du. Gainera, ifbX-rako, diziplina berdinek irteerako trafikoa kontrolatzeko lan egiten dute, eta horretarako hsfc konfigurazioa oso antzekoa izango da:
Esperimentuetan zehar, hsfc-k emaitzarik onenak erakusten dituela jakin dugu lehentasuna ez den lotearen/inolako trafikoaren 1:2 klasea minion makinetan doako bide jakin batera mugatzen denean. Bestela, lehentasunezkoa ez den trafikoak eragin handiegia du produkzio-zereginen latentzian. miniond-ek uneko banda-zabalera librearen zenbatekoa zehazten du segundo bakoitzean, minion jakin baten produkzio-zeregin guztien batez besteko trafiko-kontsumoa neurtuz. eta sareko interfazearen banda-zabaleratik kenduz marjina txikiarekin, alegia.
Bandak modu independentean definitzen dira sarrerako eta irteerako trafikorako. Eta balio berrien arabera, miniond-ek lehentasuna ez duen klase-muga 1:2 birkonfiguratzen du.
Horrela, hiru isolamendu klaseak inplementatu ditugu: prod, batch eta idle. Klase hauek asko eragiten dute zereginen errendimendu-ezaugarrietan. Hori dela eta, atributu hau hierarkiaren goiko aldean jartzea erabaki dugu, ilara hierarkikoaren izenari begira berehala argi gera dadin zertaz ari garen:
Gure lagun guztiak web ΠΈ musika fronteak gero hierarkian jartzen dira prod. Adibidez, lotearen azpian, jar dezagun zerbitzua musika katalogoa, Odnoklassniki-ra kargatutako mp3 fitxategi multzo bateko pisten katalogoa biltzen duena. Idle azpian dagoen zerbitzu baten adibidea izango litzateke musika transformatzailea, musikaren bolumen maila normalizatzen duena.
Lerro gehigarriak berriro kenduta, gure zerbitzu-izenak lauago idatz ditzakegu zereginen isolamendu-klasea zerbitzu osoaren izenaren amaieran gehituz: web.front.prod, katalogo.musika.sorta, transformadore.musika.inaktibo.
Eta orain, zerbitzuaren izenari erreparatuta, zer funtzio betetzen duen ez ezik, bere isolamendu-klasea ere ulertzen dugu, hau da, bere kritikotasuna, etab.
Dena da handia, baina bada egia mingotsa bat. Ezinezkoa da makina batean exekutatzen ari diren zereginak guztiz isolatzea.
Lortu genuena: loteak intentsiboki kontsumitzen badu bakarrik CPU baliabideak, orduan integratutako Linux CPU programatzaileak oso ondo egiten du bere lana, eta ia ez dago inolako eraginik produkzio-zereginean. Baina sorta-zeregin hau memoriarekin aktiboki lan egiten hasten bada, elkarrekiko eragina dagoeneko agertzen da. Prod zeregina prozesadorearen memoria-cacheetatik "garbitzen" delako gertatzen da; ondorioz, cache hutsak areagotzen dira eta prozesadoreak prod zeregina motelago prozesatzen du. Halako lote-zeregin batek gure produktuen edukiontzi tipikoaren latentzia % 10 handitu dezake.
Trafikoa isolatzea are zailagoa da sare-txartel modernoek paketeen barne-ilara bat dutelako. Batch zereginaren paketea lehenik iristen bada, orduan kable bidez transmitituko den lehena izango da, eta ezin da ezer egin.
Gainera, orain arte TCP trafikoa lehenesteko arazoa konpontzea baino ez dugu lortu: hsfc ikuspegiak ez du funtzionatzen UDPrentzat. Eta TCP trafikoaren kasuan ere, lote-zereginak trafiko asko sortzen badu, honek prod-zereginaren atzerapenaren %10 inguruko gehikuntza ere ematen du.
akatsen tolerantzia
Hodei bakarra garatzean helburuetako bat Odnoklassniki-ren akatsen tolerantzia hobetzea zen. Horregatik, hurrengo porrot eta istripuen eszenatoki posibleak zehatzago aztertu nahiko nituzke. Has gaitezen eszenatoki sinple batekin: edukiontziaren hutsegite bat.
Ontziak berak hainbat modutan huts egin dezake. Manifestuko esperimentu, akats edo errore motaren bat izan daiteke, eta, ondorioz, prod ataza manifestuan adierazitakoa baino baliabide gehiago kontsumitzen hasten da. Kasu bat izan genuen: garatzaile batek algoritmo konplexu bat inplementatu zuen, askotan berritu zuen, bere burua gehiegi pentsatu eta hain nahastu zen, non azkenean arazoa modu ez-hutsean errepikatu zen. Eta prod atazak beste guztiak baino lehentasun handiagoa duenez minion berdinetan, erabilgarri dauden prozesadore-baliabide guztiak kontsumitzen hasi zen. Egoera horretan, isolamenduak, edo hobeto esanda, PUZaren denbora kuotak, eguna salbatu zuen. Zeregin bati kuota bat esleitzen bazaio, zereginak ez du gehiago kontsumituko. Hori dela eta, makina berean exekutatzen ziren batch eta beste prod zereginek ez zuten ezer nabaritu.
Bigarren arazo posiblea edukiontzia erortzea da. Eta hemen berrabiarazi politikak salbatzen gaituzte, denek ezagutzen dituzte, Docker-ek berak lan bikaina egiten du. Produkzio-zeregin ia guztiek beti berrabiarazi politika dute. Batzuetan, on_failure erabiltzen dugu batch zereginetarako edo produktuen edukiontziak arazketarako.
Zer egin dezakezu minion oso bat erabilgarri ez badago?
Jakina, edukiontzia beste makina batean exekutatu. Hemen parte interesgarria da edukiontziari esleitutako IP helbideekin gertatzen dena.
Edukiontzi horiek exekutatzen dituzten minion makinen IP helbide berdinak esleitu diezaiekegu. Ondoren, edukiontzia beste makina batean abiarazten denean, bere IP helbidea aldatzen da, eta bezero guztiek ulertu behar dute edukiontzia mugitu dela, eta orain beste helbide batera joan behar dute, eta horrek Zerbitzuaren Aurkikuntza Zerbitzu bereizi bat behar du.
Zerbitzua aurkitzea erosoa da. Zerbitzu-erregistroa antolatzeko akatsen tolerantzia-maila ezberdineko irtenbide asko daude merkatuan. Askotan, horrelako soluzioek karga orekatzeko logika ezartzen dute, konfigurazio gehigarria gordetzen dute KV biltegiratze moduan, etab.
Hala ere, erregistro bereizi bat ezartzeko beharra saihestu nahiko genuke, horrek produkzioan zerbitzu guztiek erabiltzen duten sistema kritikoa sartzea ekarriko lukeelako. Horrek esan nahi du hau hutsegite-puntu bat dela, eta akatsekiko tolerantzia handiko irtenbide bat aukeratu edo garatu behar duzula, jakina, oso zaila, denbora asko eta garestia dena.
Eta eragozpen handi bat gehiago: gure azpiegitura zaharrak berriarekin funtziona dezan, erabat berridatzi beharko genituzke zeregin guztiak Service Discovery sistemaren bat erabiltzeko. Lan ASKO dago, eta leku batzuetan ia ezinezkoa da OS kernel mailan edo hardwarearekin zuzenean lan egiten duten behe-mailako gailuei dagokienez. Funtzionalitate hau ezarrita dauden soluzio ereduak erabiliz, adibidez Leku batzuetan karga gehigarria ekarriko luke, beste batzuetan - funtzionamenduaren konplikazioa eta hutsegite eszenatoki osagarriak. Ez genuen gauzak zaildu nahi, beraz, Service Discovery erabiltzea aukerakoa izatea erabaki genuen.
Hodei bakarrean, IPak edukiontziari jarraitzen dio, hau da, ataza-instantzia bakoitzak bere IP helbidea du. Helbide hau "estatikoa" da: instantzia bakoitzari esleitzen zaio zerbitzua hodeira lehen aldiz bidaltzen denean. Zerbitzu batek bere bizitzan zehar instantzia-kopuru desberdina izan badu, azkenean gehienez instantzia adina IP helbide esleituko zaizkio.
Gerora, helbide horiek ez dira aldatzen: behin esleitzen dira eta zerbitzuaren bizitza osoan zehar existitzen dira ekoizpenean. IP helbideak sarean zehar edukiontziei jarraitzen die. Edukiontzia beste minion batera transferitzen bada, helbidea jarraitu egingo du.
Horrela, zerbitzu-izena bere IP helbideen zerrendarekin mapatzea oso gutxitan aldatzen da. Artikuluaren hasieran aipatu ditugun zerbitzu-instantziaren izenei berriro begiratuz gero (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod,β¦), DNSn erabiltzen diren FQDNen antza dutela ohartuko gara. Hori bai, zerbitzu-instantziaren izenak beren IP helbideetara mapatzeko, DNS protokoloa erabiltzen dugu. Gainera, DNS honek edukiontzi guztien erreserbatutako IP helbide guztiak itzultzen ditu - martxan zein geldituta (demagun hiru erreplika erabiltzen direla, eta bost helbide ditugu bertan erreserbatuta - bost guztiak itzuliko dira). Bezeroak, informazio hori jasota, bost erreplikekin konexio bat ezartzen saiatuko dira, eta horrela funtzionatzen ari direnak zehazten. Eskuragarritasuna zehazteko aukera hau askoz fidagarriagoa da; ez du DNS edo Service Discovery dakar, hau da, ez dago arazo zailrik konpontzerik sistema horien informazioaren garrantzia eta akatsen tolerantzia ziurtatzeko. Gainera, atari osoaren funtzionamendua menpe dagoen zerbitzu kritikoetan ezin dugu DNS batere erabili, IP helbideak konfigurazioan sartu besterik ez dugu egin.
Edukiontzien atzean IP transferentzia hori ezartzea ez da hutsala izan - eta nola funtzionatzen duen aztertuko dugu adibide honekin:
Demagun hodei bakarreko maisuak minion M1-i exekutatzeko agindua ematen diola 1.ok-web.group1.web.front.prod 1.1.1.1 helbidearekin. Minion batean lan egiten du , helbide hau zerbitzari berezietara iragartzen duena . Azken hauek BGP saio bat dute sareko hardwarearekin, eta bertan M1.1.1.1eko 1 helbidearen ibilbidea itzultzen da. M1-ek paketeak edukiontzi barruan bideratzen ditu Linux erabiliz. Hiru ibilbide islatzaile zerbitzari daude, hau hodei bakarreko azpiegituraren zati oso kritikoa baita; haiek gabe, hodei bakarreko sareak ez du funtzionatuko. Rack ezberdinetan jartzen ditugu, ahal bada datu-zentroko gela desberdinetan kokatuta, hirurak aldi berean huts egiteko probabilitatea murrizteko.
Demagun orain hodei bakarreko maisuaren eta M1 minionaren arteko konexioa galdu dela. Hodei bakarreko maisuak M1 erabat huts egin duelakoan jardungo du orain. Hau da, M2 minion-ari abiarazteko agindua emango dio web.group1.web.front.prod helbide berdinarekin 1.1.1.1. Orain 1.1.1.1 sarean bi bide gatazkatsu ditugu: M1-n eta M2-n. Halako gatazkak konpontzeko, Irteera Anitzeko Diskriminatzailea erabiltzen dugu, BGP iragarkian zehazten dena. Iragarritako ibilbidearen pisua erakusten duen zenbakia da. Ibilbide gatazkatsuen artean, MED balio txikiagoa duen ibilbidea hautatuko da. Hodei bakarreko maisuak MED onartzen du edukiontzien IP helbideen osagai gisa. Lehen aldiz, helbidea MED = 1 nahiko handi batekin idazten da. Halako larrialdi-ontzien transferentziaren egoeran, maisuak MED murrizten du, eta M000-k dagoeneko jasoko du 000 helbidea iragartzeko komandoa MED = batekin. 2. M1.1.1.1-n exekutatzen ari den instantzia horretan geratuko da kasu honetan ez dago loturarik, eta bere patu gehiago ezer gutxi interesatzen zaigu maisuarekiko konexioa berrezarri arte, noiz hartu zahar bat bezala geldituko baita.
istripuak
Datu zentroak kudeatzeko sistema guztiek akats txikiak modu onargarrian kudeatzen dituzte beti. Edukiontzi gainezka ohikoa da ia nonahi.
Ikus dezagun nola kudeatzen dugun larrialdi bat, adibidez, datu-zentro bateko gela batean edo gehiagotan argindar hutsegite bat.
Zer esan nahi du istripu batek datu zentroak kudeatzeko sistemarentzat? Lehenik eta behin, makina askoren behin-behineko hutsegite izugarria da, eta kontrol sistemak aldi berean edukiontzi asko migratu behar ditu. Baina hondamendia oso eskala handia bada, gerta liteke zeregin guztiak ezin izatea beste minion batzuei berriro esleitu, datu-zentroaren baliabide-ahalmena kargaren % 100etik behera jaisten delako.
Askotan istripuak kontrol-geruzaren porrotarekin batera izaten dira. Hau bere ekipamenduaren hutsegiteagatik gerta daiteke, baina maizago istripuak probatzen ez direlako eta kontrol-geruza bera erortzen da karga handitzearen ondorioz.
Zer egin dezakezu honetaz guztiarekin?
Migrazio masiboek azpiegituran jarduera, migrazio eta inplementazio ugari gertatzen direla esan nahi dute. Baliteke migrazio bakoitzak behar den denbora pixka bat behar izatea edukiontzien irudiak minioni entregatzeko eta deskonprimitzeko, edukiontziak abiarazteko eta hasieratzeko, etab. Hori dela eta, komenigarria da zeregin garrantzitsuagoak ez hain garrantzitsuak baino lehen abian jartzea.
Ikus dezagun berriro ezagutzen ditugun zerbitzuen hierarkiari eta saia gaitezen lehenengo zein zeregin exekutatu nahi ditugun erabakitzen.
Jakina, hauek dira erabiltzaileen eskaerak prozesatzen zuzenean parte hartzen duten prozesuak, hau da, prod. Honekin adierazten dugu kokatzea lehentasuna β ilarari esleitu daitekeen zenbakia. Ilara batek lehentasun handiagoa badu, bere zerbitzuak lehenik jartzen dira.
Prod-en lehentasun handiagoak esleitzen ditugu, 0; lotean - apur bat txikiagoa, 100; inaktiboan - are txikiagoa, 200. Lehentasunak hierarkikoki aplikatzen dira. Hierarkian beheragoko zeregin guztiek lehentasuna izango dute. Prod barruko cacheak frontend-en aurretik abiarazi nahi baditugu, orduan lehentasunak esleituko dizkiogu cache-ri = 0 eta aurrealdeko azpi-ilarrei = 1. Esaterako, atari nagusia aurrealdeetatik abiarazi nahi badugu, eta musika-aurrealdea soilik. orduan, lehentasun txikiagoa eman diezaiokegu azken honi - 10.
Hurrengo arazoa baliabide falta da. Beraz, ekipamendu kopuru handi batek, datu-zentroko areto osoek, huts egin zuten, eta hainbeste zerbitzu berrabiarazi genituen, non gaur egun guztientzako baliabide nahikorik ez dagoela. Zerbitzu kritiko nagusiak martxan mantentzeko zein zeregin sakrifikatu erabaki behar duzu.
Kokatze-lehentasuna ez bezala, ezin ditugu lote-zeregin guztiak sakrifikatu; horietako batzuk garrantzitsuak dira atariaren funtzionamendurako. Hori dela eta, bereizita nabarmendu dugu lehentasunezko lehentasuna zereginak. Jarritakoan, lehentasun handiagoko zeregin batek aurrea hartu dezake, hau da, geldiarazi, lehentasun baxuagoko zeregina askeko sekuilu gehiago ez badago. Kasu honetan, lehentasun baxuko zeregin bat lekurik gabe geratuko da ziurrenik, hau da, jada ez da izango horretarako doako baliabide nahikoa duen minion egokirik.
Gure hierarkian, oso erraza da lehenespen-lehentasun bat zehaztea, hala nola prod eta batch zereginek inaktibo zereginei aurrea hartzeko edo geldiarazteko, baina ez elkarri, 200 balioko inaktiborako lehentasuna zehaztuz. Kokapen-lehentasunaren kasuan bezala, guk gure hierarkia erabil dezakegu arau konplexuagoak deskribatzeko. Adibidez, adierazi dezagun musika funtzioa sakrifikatzen dugula web atari nagusirako baliabide nahikorik ez badugu, dagozkien nodoei lehentasuna baxuago ezarriz: 10.
DC istripu osoak
Zergatik huts egin dezake datu-zentro osoak? Elementua. Post ona izan zen . Elementuak etxegabetzat har daitezke garai batean optika multzoan erre zutenak, eta datu-zentroak beste gune batzuekin kontaktua erabat galdu zuen. Porrotaren kausa giza faktorea ere izan daiteke: operadoreak halako komando bat emango du, non datu-zentro osoa eroriko baita. Hau akats handi baten ondorioz gerta daiteke. Oro har, datu-zentroen kolapsoa ez da arraroa. Hilabete batzuetan behin gertatzen zaigu hori.
Eta hau da inor #bizirik txiorik ez egiteko egiten duguna.
Lehen estrategia isolamendua da. Hodei bakarreko instantzia bakoitza isolatuta dago eta datu-zentro bakarrean kudea ditzake makinak. Hau da, akatsen edo operadoreen komando okerren ondorioz hodei bat galtzea datu-zentro bakarra galtzea da. Horretarako prest gaude: erredundantzia politika bat dugu, non aplikazioaren eta datuen erreplikak datu-zentro guztietan kokatzen diren. Akatsekiko tolerantziazko datu-baseak erabiltzen ditugu eta aldian-aldian hutsegiteak probatzen ditugu.
Gaur egun lau datu-zentro ditugunez, horrek esan nahi du hodei bakarreko lau instantzia bereizi eta guztiz isolatuak.
Planteamendu honek akats fisikoetatik babesten du, operatzailearen akatsetatik ere babesten du.
Zer gehiago egin daiteke giza faktorearekin? Operadore batek hodeiari komando arraro edo arriskutsu bat ematen dionean, baliteke bat-batean arazo txiki bat konpontzeko eska diezaioke zein ondo pentsatu zuen ikusteko. Adibidez, erreplika askoren geldialdi masiboa edo komando arraro bat besterik ez bada - erreplika kopurua murriztea edo irudiaren izena aldatzea, eta ez manifestu berriko bertsio-zenbakia soilik.
Emaitzak
Hodei bakarraren ezaugarri bereizgarriak:
- Zerbitzuen eta edukiontzien izendapen eskema hierarkikoa eta bisuala, eta horri esker, oso azkar jakin daiteke zeregina zein den, zeri lotuta eta nola funtzionatzen duen eta nor den horren arduraduna.
- Gurea aplikatzen dugu produktuak eta loteak konbinatzeko teknikaminions-en zereginak makina partekatzeko eraginkortasuna hobetzeko. Cpuset-en ordez PUZaren kuotak, partekatzeak, CPU programatzailearen politikak eta Linux QoS erabiltzen ditugu.
- Ezin izan zen makina berean ibiltzen ziren ontziak guztiz isolatu, baina elkarren arteko eragina %20aren barruan geratzen da.
- Zerbitzuak hierarkia batean antolatzeak hondamendien berreskuratze automatikoa erabiltzen laguntzen du kokapen eta lehentasunezko lehentasunak.
FAQ
Zergatik ez dugu prest egindako irtenbiderik hartu?
- Zereginen isolamendu-klase ezberdinek logika desberdina behar dute minionetan jartzen direnean. Produkzio-zereginak baliabideak erreserbatuz besterik gabe jar daitezke, orduan batch eta inaktibo lanak jarri behar dira, minion makinetan baliabideen benetako erabileraren jarraipena eginez.
- Zereginek kontsumitzen dituzten baliabideak kontuan hartu beharra, hala nola:
- sareko banda zabalera;
- disko motak eta "ardatzak".
- Larrialdi-erantzunean zerbitzuen lehentasunak, baliabideen komandoen eskubideak eta kuotak adierazi beharra, hodei bakarreko ilara hierarkikoak erabiliz konpontzen dena.
- Edukiontzien giza izendapena eduki beharra, istripu eta gertaeren aurrean erantzuteko denbora murrizteko
- Zerbitzuaren aurkikuntzaren behin-behineko hedapena ezartzeko ezintasuna; hardware ostalarietan ostatatutako zereginekin denbora luzez elkarrekin bizitzeko beharra - edukiontzien ondoren IP helbide "estatikoekin" konpontzen den zerbait, eta, ondorioz, sare-azpiegitura handi batekin integrazio bereziaren beharra.
Funtzio horiek guztiek lehendik dauden soluzioen aldaketa nabarmenak beharko lituzkete gurera egokitzeko, eta, lan-kopurua ebaluatuta, konturatu ginen gure soluzio propioa garatu genezakeela gutxi gorabehera lan-kostu berdinekin. Baina zure irtenbidea funtzionatzeko eta garatzeko askoz errazagoa izango da - ez ditu behar ez ditugun funtzionalitateak onartzen dituzten alferrikako abstrakziorik.
Azken lerroak irakurtzen dituzunei, eskerrik asko zuen pazientziagatik eta arretagatik!
Iturria: www.habr.com