{"id":84114,"date":"2020-06-05T07:42:55","date_gmt":"2020-06-05T05:42:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah"},"modified":"2020-06-05T07:42:55","modified_gmt":"2020-06-05T05:42:55","slug":"one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","title":{"rendered":"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/fa983acacec59ff2d4ed098f87223971.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Aloha, inimesed! Minu nimi on Oleg Anastasyev, t\u00f6\u00f6tan Odnoklassnikis Platvormi meeskonnas. Lisaks mulle t\u00f6\u00f6tab Odnoklassnikis suur hulk seadmeid. Meil on neli andmekeskust, milles on umbes 500 riiulit \u00fcle 8000 serveri. \u00dchel hetkel m\u00f5istsime, et uue juhtimiss\u00fcsteemi rakendamine v\u00f5imaldab meil tehnika kasutust t\u00f5husamalt koormata, juurdep\u00e4\u00e4sude haldamist lihtsustada, arvutusressursside (uuesti) jaotamist automatiseerida, uusi teenuseid kiiremini k\u00e4ivitada ja suurte avariide korral reageerimisaega kiirendada. <\/p>\n<p><\/p>\n<p>Mida me selle tulemusena saavutasime? <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Lisaks mulle ja suurtele seadmetele on veel inimesi, kes nendega t\u00f6\u00f6tavad: insenerid, kes asuvad andmekeskustes; v\u00f5rguinsenerid, kes seadistavad v\u00f5rgulahendusi; adminnid ehk SRE-d, kes tagavad infrastruktuuri t\u00f6\u00f6kindluse; ja arendustiimid, kellest iga\u00fchel on oma roll portaali funktsioonides. Nende loodud tarkvara t\u00f6\u00f6tab umbes nii:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/592fd0acfa7322eb80fbb85601a92918.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kasutajate p\u00e4ringud saadetakse peamise portaali frontide kaudu <noindex><a rel=\"nofollow\" href=\"http:\/\/www.ok.ru\/\">www.ok.ru<\/a><\/noindex>, ja ka teistele, n\u00e4iteks muusika API frontendidele. Need t\u00f6\u00f6tlevad \u00e4ri loogikat, kutsudes esile rakenduste serverit, mis vajadusel kutsub v\u00e4lja vajalikud spetsialiseeritud mikroteenused \u2014 one-graph (sotsiaalsete suhete graafik), user-cache (kasutajaprofiilide vahem\u00e4lu) jne.<\/p>\n<p><\/p>\n<p>Iga\u00fcks neist teenustest on paigutatud paljudele masinatele ning igal neist on vastutavad arendajad, kes vastutavad moodulite toimimise, nende hoolduse ja tehnoloogilise arengu eest. K\u00f5ik need teenused k\u00e4ivitatakse raudserveritel, ja kuni hiljutise ajani k\u00e4ivitasime t\u00e4pselt \u00fche \u00fclesande \u00fche serveri peal, st see oli spetsialiseeritud konkreetsele \u00fclesandele.<\/p>\n<p><\/p>\n<p>Miks nii? Sellel l\u00e4henemisel oli mitu eelist:<\/p>\n<p><\/p>\n<ul>\n<li>Kergendab <strong>massilist haldust<\/strong>. Oletame, et \u00fclesanne vajab teatud teeke, teatud seadeid. Ja siis kantakse server t\u00e4pselt \u00fchte kindlasse gruppi, kirjeldatakse selle grupi cfengine poliitikat (v\u00f5i see on juba kirjeldatud), ja see konfiguratsioon rakendatakse keskendunult ja automaatselt k\u00f5ikidele selle grupi serveritele.<\/li>\n<li>Lihtsustab <strong>diagnostikat<\/strong>. Oletat, et vaatate suurenenud protsessori koormust ja m\u00f5istate, et selle koormuse v\u00f5is genereerida ainult see \u00fclesanne, mis t\u00f6\u00f6tab sellel raual. S\u00fc\u00fcdlaste leidmine l\u00f5ppema v\u00e4ga kiiresti.<\/li>\n<li>Lihtsustab <strong>j\u00e4lgimist,<\/strong>. Kui serveriga on midagi valesti, teatab monitor sellest, ja te teate t\u00e4pselt, kes on s\u00fc\u00fcdi.<\/li>\n<\/ul>\n<p><\/p>\n<p>Teenusele, mis koosneb mitmest koopiast, eraldatakse mitu serverit \u2014 iga\u00fchele \u00fcks. Nii et teenuse arvutusressursi jaotamine on v\u00e4ga lihtne: nii palju servereid, kui teenusel on, nii palju ressursse ta maksimaalselt tarbida saab. \u201eLihtne\u201d ei t\u00e4henda siin, et seda on lihtne kasutada, vaid et ressursside jaotamine toimub k\u00e4sitsi.<\/p>\n<p><\/p>\n<p>Selline l\u00e4henemine on v\u00f5imaldanud meil ka teha <strong>spetsialiseeritud riistvarakonfiguratsioone<\/strong> \u00fclesande jaoks, mis toimib sellel serveril. Kui \u00fclesanne talletab suuri andmemahtusid, siis kasutame 4U-serverit, mille \u0161assii mahutab 38 ketast. Kui \u00fclesanne on puhtalt arvutuslik, saame osta odavama 1U-serveri. See on arvutusressursside m\u00f5ttes efektiivne. Selline l\u00e4henemine v\u00f5imaldab meil kasutada neli korda v\u00e4hem seadmeid koormuse korral, mis on sarnane \u00fchele meile s\u00f5bralikule sotsiaalmeediale. <\/p>\n<p><\/p>\n<p>Selline arvutusressursside kasutamise efektiivsus peaks tagama ka majandusliku efektiivsuse, kui l\u00e4htuda eeldusest, et k\u00f5ige kallimad on serverid. Pikka aega olid k\u00f5ige kallimad just riistvara, ja oleme pannud palju vaeva riistvara hinna v\u00e4hendamiseks, v\u00e4lja t\u00f6\u00f6tades talitluspidevuse tagamise algoritme, et v\u00e4hendada seadmete usaldusv\u00e4\u00e4rsuse n\u00f5udeid. Ja t\u00e4na oleme j\u00f5udnud staadiumisse, kus serveri hind enam ei m\u00e4ngi m\u00e4\u00e4ravat rolli. Kui mitte arvestada uusimat eksootikat, siis konkreetse serveri konfiguratsioon rackis ei oma t\u00e4htsust. Praegu seisame silmitsi teise probleemiga \u2014 serveri asukoha hind andmekeskuses, st racki kohaga.<\/p>\n<p><\/p>\n<p>M\u00f5istes, et see nii on, otsustasime arvutada, kui efektiivselt me riiuleid kasutame.<br \/>\nV\u00f5tsime k\u00f5ige v\u00f5imsama serveri hinna, mis on majanduslikult p\u00f5hjendatud, ja arvutasime v\u00e4lja, kui palju selliseid servereid saame riiulitesse mahutada, kui palju \u00fclesandeid me nende peale k\u00e4ivitaksime vanast mudelist l\u00e4htudes, kus \"\u00fcks server = \u00fcks \u00fclesanne\", ja kui palju need \u00fclesanded suudaksid varustust \u00e4ra kasutada. Arvutasime \u2014 silmi niiskasid. Selgus, et meie riiulite kasutamise efektiivsus on umbes 11%. Tulemused on selged: andmekeskuste kasutamise efektiivsust tuleb t\u00f5sta. Tundub, et lahendus on ilmne: peame \u00fchel serveril korraga mitu \u00fclesannet k\u00e4ivitama. Kuid siin hakkavad probleemid. <\/p>\n<p><\/p>\n<p>Massiline konfiguratsioon muutub j\u00e4rsult keerulisemaks \u2014 n\u00fc\u00fcd ei saa serverile m\u00e4\u00e4rata \u00fchte kindlat r\u00fchma. K\u00fcll aga v\u00f5ivad \u00fchel serveril n\u00fc\u00fcd olla k\u00e4ivitatud mitmed erinevate meeskondade \u00fclesanded. Lisaks v\u00f5ib konfiguratsioon olla erinevate rakenduste jaoks konfliktne. Diagnostika muutub samuti keerulisemaks: kui n\u00e4ete serveris suurenenud protsessorite v\u00f5i ketaste kasutamist, ei tea te, milline \u00fclesanne p\u00f5hjustab probleeme.<\/p>\n<p><\/p>\n<p>Kuid k\u00f5ige t\u00e4htsam on see, et \u00fche masina peal k\u00e4ivitatavate \u00fclesannete vahel ei ole eraldatust. N\u00e4iteks, siin on keskmise vastuseaja graafik serveri\u00fclesandele enne ja p\u00e4rast seda, kui samal serveril k\u00e4ivitasime veel \u00fche, esimesega mitte seotud arvutusrakenduse \u2014 peamise \u00fclesande vastamisaeg on oluliselt suurenenud.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/c7c07359ae572ca8c84a4c63559e4083.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ilmselgelt tuleb \u00fclesandeid k\u00e4ivitada kas konteinerites v\u00f5i virtuaalmasinates. Kuna praktiliselt k\u00f5ik \u00fclesanded k\u00e4ivitatakse meil \u00fche ops\u00fcsteemi (Linuxi) all v\u00f5i on selle jaoks kohandatud, ei ole meil vajalik \u00fchegi erineva ops\u00fcsteemi toetamine. Seega ei ole virtualiseerimine vajalik, kuna selle t\u00e4iendavad kulud muudavad selle v\u00e4hem t\u00f5husaks kui konteineriseerimine.<\/p>\n<p><\/p>\n<p>Dockeri konteinereid, mis k\u00e4ivitavad \u00fclesandeid otse serverites, v\u00f5ib pidada heaks kandidaadiks: failis\u00fcsteemide pildid lahendavad konflikti tekkimise probleeme. Kuna pilte saab koostada mitmest kihist, suudame oluliselt v\u00e4hendada andmete mahtu, mis on vajalik nende juurutamiseks infrastruktuuris, eraldades \u00fchised osad eraldi baaskihiks. Nii et baaskihid (ja k\u00f5ige mahukamad kihid) salvestatakse kogu infrastruktuuri piisavalt kiiresti ja erinevat t\u00fc\u00fcpi rakenduste ja versioonide edastamiseks tuleb edastada ainult v\u00e4ikesed kihid. <\/p>\n<p><\/p>\n<p>Lisaks pakuvad valmis registreerimise ja pilte m\u00e4rgistamise v\u00f5imalused Dockeris meile valmis primitiive koodi versioonimiseks ja tootmisse toimetamiseks.<\/p>\n<p><\/p>\n<p>Docker, nagu iga teine sarnane tehnoloogia, pakub meile vaikimisi teatud taseme konteinerite isoleerimiseks. N\u00e4iteks m\u00e4lu isoleerimine \u2014 iga konteinerile m\u00e4\u00e4ratakse masina m\u00e4lu kasutamise limiit, millest k\u00f5rgemat ta ei kasuta. Samuti on v\u00f5imalik isoleerida konteinerite kasutust CPU puhul. Meie jaoks aga ei olnud standardne isoleerimine piisav. Kuid sellest r\u00e4\u00e4gime allpool.<\/p>\n<p><\/p>\n<p>Konteinerite otsene k\u00e4ivitamine serverites on ainult osa probleemidest. Teine osa on seotud konteinerite paigutamisega serveritesse. Tuleb m\u00f5ista, milliseid konteinerite saab kellele serverisse paigutada. See ei ole nii lihtne \u00fclesanne, sest konteinerid tuleb paigutada serveritesse v\u00f5imalikult tihedalt, samas kiirusest loobumata. Selline paigutamine v\u00f5ib olla keeruline ja usaldusv\u00e4\u00e4rsuse seisukohalt. Tihti soovime paigutada sama teenuse koopiaid erinevatesse rackidesse v\u00f5i isegi erinevatesse andmekeskuste saalidesse, et racki v\u00f5i saali rikke korral ei kaotaks me kohe k\u00f5ik teenuse koopiad. <\/p>\n<p><\/p>\n<p>Konteinerite k\u00e4sitsi jaotamine ei ole valik, kui sul on 8000 serverit ja 8000\u201316000 konteinerit. <\/p>\n<p><\/p>\n<p>Samuti soovisime anda arendajatele rohkem iseseisvust ressursside jaotamisel, et nad saaksid oma teenuseid ise tootmisesse paigutada ilma administraatori abita. Samas soovisime s\u00e4ilitada kontrolli, et m\u00f5ni v\u00e4hem oluline teenus ei kasutaks \u00fcles meie andmekeskuste ressursse. <\/p>\n<p><\/p>\n<p>Selgelt on vajalik juhtimistasand, mis tegeleb sellega automaatselt.<\/p>\n<p><\/p>\n<p>Ja siin oleme me lihtsa ja arusaadava pildi juures, mida k\u00f5ik arhitektid armastavad: kolm ruutu. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/079df6e79874ef55b0d967fde3d5feca.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>one-cloud masters \u2014 talitlush\u00e4ired v\u00e4ltiv klaster, mis vastutab pilve orkestreerimise eest. Arendaja saadab meistrile manifesti, milles on kogu teenuse paigutamiseks vajalik teave. Meister annab selle alusel k\u00e4ske valitud minioonidele (masinatele, mis on m\u00f5eldud konteinerite k\u00e4itamiseks). Minioonidel on meie agent, kes saab k\u00e4su, edastab juba oma k\u00e4sud Dockerile ja Docker konfigureerib Linuxi kerneli vastava konteineri k\u00e4ivitamiseks. Lisaks k\u00e4sude t\u00e4itmisele edastab agent pidevalt meistrile muutusi nii minioonimasina seisundis kui ka k\u00e4ivitatud konteinerites.<\/p>\n<p><\/p>\n<h2 id=\"raspredelenie-resursov\">Ressursside jaotamine<\/h2>\n<p><\/p>\n<p>N\u00fc\u00fcd vaatame keerulisemat ressursside jaotuse \u00fclesannet mitme minioni jaoks.<\/p>\n<p><\/p>\n<p>Arvutusressurss one-cloudis on:<\/p>\n<p><\/p>\n<ul>\n<li>Protsessori arvutusv\u00f5imsus, mida kasutatakse konkreetse \u00fclesande jaoks. <\/li>\n<li>M\u00e4lu maht, mis on \u00fclesandele saadaval. <\/li>\n<li>V\u00f5rguliiklus. Igal minionil on konkreetne v\u00f5rguinterfeiss piiratud l\u00e4bilaskev\u00f5imega, seega ei saa \u00fclesandeid jaotada, arvesse v\u00f5tmata edastatavate andmete mahtu. <\/li>\n<li>Kettad. Lisaks ilmselgelt ruumile \u00fclesande andmete jaoks m\u00e4\u00e4rame ka ketta t\u00fc\u00fcbi: HDD v\u00f5i SSD. Kettad suudavad teenindada piiratud arvu p\u00e4ringuid sekundis \u2014 IOPS. Seega, kui \u00fclesanded genereerivad rohkem IOPS'i, kui \u00fcks kettas suudab teenindada, m\u00e4\u00e4rame ka \"spindlid\" \u2014 st ketas-seadmed, mis tuleb eraldi \u00fclesande jaoks reserveerida.<\/li>\n<\/ul>\n<p><\/p>\n<p>Seega saame n\u00e4iteks teenuse, nagu user-cache, ressursin\u00f5udluse kirjutada j\u00e4rgmisel viisil: 400 protsessorituuma, 2,5 TB m\u00e4lu, 50 Gbit\/s liiklust m\u00f5lemas suunas, 6 TB ruumi HDD-l, mis asub 100 spindlil. V\u00f5i meie jaoks tuttavamal kujul nii:<\/p>\n<p><\/p>\n<pre><code>alloc:\n    cpu: 400\n    mem: 2500\n    lan_in: 50g\n    lan_out: 50g\n    hdd:100x6T<\/code><\/pre>\n<p><\/p>\n<p>User-cache'i teenused kasutavad ainult osa k\u00f5igist saadaval olevatest ressurssidest tootmisinfrastruktuuris. Seet\u00f5ttu soovime tagada, et user-cache ei tarbiks ootamatult rohkem ressursse, kui talle on eraldatud, olgu see siis inimese vea t\u00f5ttu v\u00f5i mitte. Peame ressursside kasutust piirama. Kuid mille p\u00f5hjal saaksime kvooti m\u00e4\u00e4rata?<\/p>\n<p><\/p>\n<p>Naaseme meie tugevalt lihtsustatud komponentide suhtlemise skeemi juurde ja joonistame selle suuremate detailidega \u2014 nii: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/27e5bfbffadd3d4b9fdc6bf138d135ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mida silma torkab:<\/p>\n<p><\/p>\n<ul>\n<li>Veebifront ja muusika kasutavad sama rakenduste serveri isoleeritud klastreid.<\/li>\n<li>Saame m\u00e4\u00e4ratleda loogilised kihid, mis kuuluvad nende klastrite alla: front'id, vahem\u00e4lud, andmete salvestamise ja haldamise kiht.<\/li>\n<li>Frontend ei ole \u00fchtlane, need on erinevad funktsionaalsed alams\u00fcsteemid. <\/li>\n<li>Vahem\u00e4lusid saab samuti jaotada alams\u00fcsteemi j\u00e4rgi, mille andmeid nad vahem\u00e4lustavad.<\/li>\n<\/ul>\n<p><\/p>\n<p>Joonistame pildi veel kord \u00fcmber:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/905dacc0aca859e65bd33ef751a557cf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vau! Me n\u00e4eme hierarhiat! See t\u00e4hendab, et saame ressursse jagada suuremates t\u00fckkides: m\u00e4\u00e4rata vastutav arendaja selle hierarhia s\u00f5lmele, mis vastab funktsionaalsetele alam-s\u00fcsteemidele (nagu \u201emusic\u201c pildil), ning siduda sellele tasemele hierarhias ka kvota. Selline hierarhia v\u00f5imaldab meil ka paindlikumalt korraldada teenuseid, et need oleksid haldamise seisukohalt mugavamad. N\u00e4iteks jagame k\u00f5ik veebiserverid, kuna see on v\u00e4ga suur serverite r\u00fchm, mitmeks v\u00e4iksemaks grupiks, nagu pildil on n\u00e4idatud group1, group2.<\/p>\n<p><\/p>\n<p>Eemaldades liigsed jooned, saame iga s\u00f5lme meie pildist kirja panna lamedamas vormis: <strong>group1.web.front<\/strong>, <strong>api.music.front<\/strong>, <strong>user-cache.cache<\/strong>.<\/p>\n<p><\/p>\n<p>Nii me j\u00f5uame m\u00f5isteteni \"hierarhiline j\u00e4rjekord\". Sel on nimi, n\u00e4iteks \"group1.web.front\". Sellele m\u00e4\u00e4ratakse ressursside kvoodid ja kasutajate \u00f5igused. DevOps t\u00f6\u00f6tajale anname \u00f5iguse teenuse j\u00e4rjekorda saatmiseks, ja selline t\u00f6\u00f6taja v\u00f5ib j\u00e4rjekorras midagi k\u00e4ivitada, ning OpsDev t\u00f6\u00f6tajale adminni\u00f5igused, mis t\u00e4hendab, et n\u00fc\u00fcd saab ta j\u00e4rjekorda hallata, sinna inimesi m\u00e4\u00e4rata, anda neile \u00f5igusi jne. J\u00e4rjekorras k\u00e4ivitatavad teenused t\u00f6\u00f6tatakse v\u00e4lja j\u00e4rjekorra kvoodi piires. Kui j\u00e4rjekorra arvutuslik kvoot ei ole piisav k\u00f5igi teenuste samaaegseks t\u00e4itmiseks, siis nad t\u00e4idetakse j\u00e4rjestikku, moodustades seel\u00e4bi ise j\u00e4rjekorra. <\/p>\n<p><\/p>\n<p>Vaatame teenuseid l\u00e4hemalt. Teenusel on t\u00e4ielik nimi, mis sisaldab alati j\u00e4rjekorra nime. Seega veebifront teenus saab nimeks <strong>ok-web.group1.web.front<\/strong>. Ja rakendusserveri teenus, millega see suhtleb, nimetatakse <strong>ok-app.group1.web.front<\/strong>. Iga teenusel on manifest, kus on kirjas kogu vajalik teave, et paigaldada see konkreetsetele masinatele: kui palju ressursse see \u00fclesanne tarbib, milline konfiguratsioon on vajalik, kui palju koopiaid peaks olema, teenuse t\u00f5rkeotsingu omadused. Ja p\u00e4rast teenuse paigaldamist masinatel ilmuvad selle eksemplarid. Need on samuti unikaalselt nimetatud \u2014 kui eksemplari number ja teenuse nimi: <strong>1.ok-web.group1.web.front, 2.ok-web.group1.web.front, \u2026<\/strong><\/p>\n<p><\/p>\n<p>See on v\u00e4ga mugav: vaadates ainult k\u00e4ivitatud konteineri nime, saame kohe palju selgeks teha.<\/p>\n<p><\/p>\n<p>Ja n\u00fc\u00fcd tutvume l\u00e4hemalt, mida need eksemplarid tegelikult teevad: \u00fclesanded.<\/p>\n<p><\/p>\n<h2 id=\"klassy-izolyacii-zadach\">\u00dclesannete isoleerimise klassid<\/h2>\n<p><\/p>\n<p>K\u00f5ik \u00fclesanded OKes (ja t\u00f5en\u00e4oliselt ka igal pool mujal) saab jagada r\u00fchmadesse:<\/p>\n<p><\/p>\n<ul>\n<li><strong>L\u00fchikese viivitusega \u00fclesanded \u2014 prod<\/strong>. Selliste \u00fclesannete ja teenuste puhul on v\u00e4ga oluline vastuse viivitus (latency), kui kiiresti s\u00fcsteem iga p\u00e4ringut t\u00f6\u00f6delda suudab. \u00dclesannete n\u00e4ited: veebi esipinnad, sisedoosid, rakenduste serverid, OLTP salvestused jne.<\/li>\n<li><strong>Arvutus\u00fclesanded \u2014 batch<\/strong>. Siin on igasuguste p\u00e4ringute t\u00f6\u00f6tlemise kiirus ebaoluline. Olulisem on, kui palju arvutusi antud (suur) ajavahemiku jooksul see \u00fclesanne teostab (throughput). Selle alla k\u00e4ivad k\u00f5ik MapReduce, Hadoop, masin\u00f5ppe, statistika \u00fclesanded.<\/li>\n<li><strong>Taust\u00fclesanded \u2014 idle<\/strong>. Selliste \u00fclesannete puhul ei ole ei latency ega throughput nii olulised. Siia kuuluvad erinevad testid, migratsioonid, \u00fcmberarvutused, andmete konverteerimine \u00fchest formaadist teise. \u00dchelt poolt sarnanevad need aritmeetilistele \u00fclesannetele, kuid teisalt pole meil v\u00e4ga oluline, kui kiiresti need l\u00f5pule viiakse. <\/li>\n<\/ul>\n<p><\/p>\n<p>Vaadakem, kuidas sellised \u00fclesanded ressursse, n\u00e4iteks keskprotsessorit, tarbivad.<\/p>\n<p><\/p>\n<p><strong>L\u00fchikese latentsusega \u00fclesanded.<\/strong> Sellise \u00fclesande proportsioon protsessori kasutuses n\u00e4eb v\u00e4lja selline:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/1ed82c0df76325eb30056ad9af86e86e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kasutajalt tuleb p\u00e4ring, \u00fclesanne hakkab kasutama k\u00f5iki saadaval olevaid protsessori tuumasid, t\u00f6\u00f6tleb, tagastab vastuse, ootab j\u00e4rgmist p\u00e4ringut ja seisab. J\u00e4rgmisel p\u00e4ringul \u2014 taas kasutatakse k\u00f5ike, mis oli, arvutatakse, ootame j\u00e4rgmist.<\/p>\n<p><\/p>\n<p>Minimaalse viivituse tagamiseks selle \u00fclesande puhul peame me v\u00f5tma maksimaalselt tarvitatavad ressursid ning reserveerima vajalikud tuumad minjoni (masina, mis t\u00e4idab \u00fclesannet) jaoks. Siis on meie \u00fclesande reserveerimise valem j\u00e4rgmine:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = 4 (max)<\/code><\/pre>\n<p><\/p>\n<p>ja kui meil on 16 tuumaga minjoni masin, siis saame sellele t\u00e4pselt neli sellist \u00fclesannet paigutada. Eriti oluline on m\u00e4rkida, et nende \u00fclesannete keskmine protsessori kasutus on sageli v\u00e4ga madal \u2014 mis on ilmselge, kuna suure osa ajast ootab \u00fclesanne p\u00e4ringut ja ei tee midagi.<\/p>\n<p><\/p>\n<p><strong>Arvutus\u00fclesanded.<\/strong> Nende muster on pisut erinev:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/35b37fa1d70a137287cafdbfe3bcfc2e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nende \u00fclesannete keskmine ressursi kasutus protsessoris on piisavalt k\u00f5rge. Sageli tahame, et arvutus\u00fclesanne teostataks kindla ajavahemiku jooksul, seega tuleb reserveerida minimaalne protsessorite arv, mis on vajalik, et kogu arvutus l\u00f5ppeks vastuv\u00f5etava aja jooksul. Selle reserveerimise valem n\u00e4eb v\u00e4lja j\u00e4rgmine:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = [1,* )<\/code><\/pre>\n<p><\/p>\n<p><em>\u201ePalun paiguta minjoni, kus on v\u00e4hemalt \u00fcks vaba tuum, ja \u00fclej\u00e4\u00e4nud v\u00f5tavad k\u00f5ik, mis saadaval on.\u201d<\/em><\/p>\n<p><\/p>\n<p>Siin on ressursikasutuse efektiivsus tunduvalt parem kui l\u00fchikese latentsusega \u00fclesannete puhul. Kuid kasu on palju suurem, kui kombineerida m\u00f5lemat t\u00fc\u00fcpi \u00fclesandeid \u00fchel masin-minionil ja jaotada selle ressursse jooksvalt. Kui l\u00fchikese latentsusega \u00fclesanne n\u00f5uab protsessorit, saab ta selle kohe, ja kui ressursse enam ei vajata, antakse need edasi arvutus\u00fclesandele, st umbes nii:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/875ad8d3f6a01e4fd0a89d0931e986c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Aga kuidas seda teha?<\/p>\n<p><\/p>\n<p>Alustame prod ja selle alloc\u2019i m\u00f5istmisest: cpu = 4. Me peame reserveerima neli s\u00fcdamikku. Docker run'is saab seda teha kahes erinevas viisis: <\/p>\n<p><\/p>\n<ul>\n<li>Kasutades valikut <code>--cpuset=1-4<\/code>, st m\u00e4\u00e4rata \u00fclesandele neli kindlat s\u00fcdant masinas.<\/li>\n<li>Kasutage <code>--cpuquota=400_000 --cpuperiod=100_000<\/code>, m\u00e4\u00e4rata protsessori aja kvoot, st n\u00e4idata, et iga 100 ms reaalajas tarbib \u00fclesanne mitte rohkem kui 400 ms protsessori aega. Selgub, et need on samad neli s\u00fcdamikku. <\/li>\n<\/ul>\n<p><\/p>\n<p>Aga milline neist viisidest sobib?<\/p>\n<p><\/p>\n<p>Cpuset n\u00e4eb \u00fcsna atraktiivne v\u00e4lja. \u00dclesandel on neli p\u00fchendatud tuuma, mis t\u00e4hendab, et protsessori vahem\u00e4lu t\u00f6\u00f6tab maksimaalselt efektiivselt. Kuid sellega kaasneb ka tagasil\u00f6\u00f6k: me peaksime ise hakkama \u00fclesandeid jaotama masiivi v\u00e4hem koormatud tuumade vahel, mitte operatsioonis\u00fcsteemi, ja see on \u00fcsna keeruline \u00fclesanne, eriti kui proovime viia sellisele masinale batch-\u00fclesandeid. Testid n\u00e4itasid, et siinkohal sobib paremini kvota variant: nii on operatsioonis\u00fcsteemil rohkem vabadust valida tuum, kus praegu \u00fclesannet t\u00e4ita, ja protsessori aeg jaguneb efektiivsemalt.<\/p>\n<p><\/p>\n<p>Selgitame, kuidas Dockeris minimaalsete tuuma arvude tagamiseks t\u00f6\u00f6tada. Batch-\u00fclesannete jaoks pole kvota enam rakendatav, kuna ei ole vajalik maksimaalselt piirata, piisab ainult minimaalse garanteerimisest. Siin sobib h\u00e4sti valik <code>docker run --cpushares<\/code>.<\/p>\n<p><\/p>\n<p>Me lepime kokku, et kui batch n\u00f5uab minimaalset garantiid \u00fche tuuma jaoks, siis m\u00e4rkime <code>--cpushares=1024<\/code>, ja kui minimaalne on kahe tuuma jaoks, siis m\u00e4rkime <code>--cpushares=2048<\/code>. CPU jagatud ei sekku protsessorite aja jaotamisse seni, kuni seda j\u00e4tkub. Seega, kui prod ei kasuta hetkel k\u00f5iki oma nelja tuuma - ei piira miski batch-\u00fclesandeid ning need v\u00f5ivad kasutada lisaprotsessori aega. Kuid protsessori nappuse olukorras, kui prod on kasutanud k\u00f5ik oma neli tuuma ja koperdab piirini - jagatakse \u00fclej\u00e4\u00e4nud protsessori aeg proportsionaalselt cpushares'i j\u00e4rgi. St kolme vabaga tuuma puhul saab \u00fche \u00fclesanne, millel on 1024 cpushares, ja teised kaks - \u00fclesanne, millel on 2048 cpushares.<\/p>\n<p><\/p>\n<p>Kuid kvota ja jagude kasutamine ei ole piisav. Me peame tagama, et madala viivitusega \u00fclesanne saab prioriteedi batch-\u00fclesande ees protsessori aja jaotamisel. Ilma sellise prioriteedita v\u00f5taks batch-\u00fclesanne kogu protsessori aja \u00e4ra, kui seda on vaja prod jaoks. Docker runis ei ole konteinerite prioriseerimiseks mingeid valikuid, kuid CPU ajakava poliitikad Linuxis tulevad appi. Nende kohta saab lugeda <noindex><a rel=\"nofollow\" href=\"http:\/\/man7.org\/linux\/man-pages\/man2\/sched_setscheduler.2.html\">siin<\/a><\/noindex>, ja selles artiklis k\u00e4sitleme neid l\u00fchidalt:<\/p>\n<p><\/p>\n<ul>\n<li><strong>SCHED_OTHER<\/strong><br \/>\nVaikimisi saavad k\u00f5ik tavalised kasutaja protsessid Linuxi masinal.<\/li>\n<li><strong>SCHED_BATCH<\/strong><br \/>\nM\u00f5eldud ressursimahukatele protsessidele. Kui \u00fclesanne paigutatakse protsessorisse, kehtestatakse nn aktiveerimisrakendus: sellisel juhul on t\u00f5en\u00e4olisem, et \u00fclesanne ei saa protsessori ressursse, kui neid kasutab SCHED_OTHER \u00fclesanne.<\/li>\n<li><strong>SCHED_IDLE<\/strong><br \/>\nTaustaprotsess, mille prioriteet on v\u00e4ga madal, isegi madalam kui nice \u201319. Kasutame oma avatud l\u00e4htekoodiga teeki <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/odnoklassniki\/one-nio\">one-nio<\/a><\/noindex>, et m\u00e4\u00e4rata vajalik poliitika konteineri k\u00e4ivitamisel kutsumisega<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"java\">one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )<\/code><\/pre>\n<p><\/p>\n<p>Kuid isegi kui te ei programmeeri Java keeles, saab sama teha k\u00e4suga chrt:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">chrt -i 0 $pid<\/code><\/pre>\n<p><\/p>\n<p>Kogume k\u00f5ik meie isolatsioonitasemed \u00fchte tabelisse selguse huvides:<\/p>\n<p><\/p>\n<p>Isolatsiooniklass<br \/>\nN\u00e4ide alloc<br \/>\nDocker run valikud<br \/>\nsched_setscheduler chrt*<\/p>\n<p>Prod<br \/>\ncpu = 4<br \/>\n<code>--cpuquota=400000<\/code> <code>--cpuperiod=100000<\/code><br \/>\nSCHED_OTHER<\/p>\n<p>Batch<br \/>\nCpu = [1, * )<br \/>\n<code>--cpushares=1024<\/code><br \/>\nSCHED_BATCH<\/p>\n<p>Idle<br \/>\nCpu= [2, *)<br \/>\n<code>--cpushares=2048<\/code><br \/>\nSCHED_IDLE<\/p>\n<p><\/p>\n<p>*Kui teete chrt konteineri seest, v\u00f5ib olla vajalik capability sys_nice, kuna vaikimisi eemaldab Docker selle capability konteineri k\u00e4ivitamisel.<\/p>\n<p><\/p>\n<p>Kuid \u00fclesanded tarbivad mitte ainult protsessorit, vaid ka liiklust, mis m\u00f5jutab v\u00f5rgu\u00fclesande viivitust isegi rohkem kui protsessori ressursi vale jaotamine. Seet\u00f5ttu soovime loomulikult saada t\u00e4pselt sama pilti ka liikluse osas. See t\u00e4hendab, et kui tootmis\u00fclesanne saadab v\u00f5rku teatud pakette, siis me m\u00e4\u00e4ratleme maksimaalse kiirus(piirangud) <em>alloc: lan=[*,500mbps)<\/em> ), mille kiirusel tootmine seda teha saab. Ja batch'i puhul garanteerime ainult minimaalse l\u00e4bilaskev\u00f5ime, kuid mitte maksimaalse (piirangud <em>alloc: lan=[10Mbps,*)<\/em> ) Samuti peab tootmise liiklus olema eelisseisundis batch-\u00fclesannete ees.<br \/>\nSiin ei ole Dockeril mingeid primitiive, mida saaksime kasutada. Kuid meid aitab <noindex><a rel=\"nofollow\" href=\"http:\/\/lartc.org\/\">Linux Traffic Control<\/a><\/noindex>. Me oleme saavutanud soovitud tulemuse distsipliini abil <noindex><a rel=\"nofollow\" href=\"http:\/\/linux-ip.net\/articles\/hfsc.en\/\">Hierarchical Fair Service Curve<\/a><\/noindex>. Selle abil eraldame kaks liikluse klassi: k\u00f5rge prioriteet tootmine ja madala prioriteediga batch\/idle. L\u00f5puks on v\u00e4ljamineva liikluse konfiguratsioon j\u00e4rgmine:<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/gh\/5k\/kf\/gh5kkfwkhwv0ilmbdmdbo83dp6k.png\"><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/3f52a968118b6021bd0c920af17a00c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>\u0437\u0434\u0435\u0441\u044c 1:0 \u2014 &#171;\u043a\u043e\u0440\u043d\u0435\u0432\u043e\u0439 qdisc&#187; \u0434\u0438\u0441\u0446\u0438\u043f\u043b\u0438\u043d\u044b hsfc; 1:1 \u2014 \u0434\u043e\u0447\u0435\u0440\u043d\u0438\u0439 \u043a\u043b\u0430\u0441\u0441 hsfc \u0441 \u043e\u0431\u0449\u0438\u043c \u043b\u0438\u043c\u0438\u0442\u043e\u043c \u043f\u0440\u043e\u043f\u0443\u0441\u043a\u043d\u043e\u0439 \u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0432 8 Gbit\/s, \u043f\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u043e\u043c\u0435\u0449\u0430\u044e\u0442\u0441\u044f \u0434\u043e\u0447\u0435\u0440\u043d\u0438\u0435 \u043a\u043b\u0430\u0441\u0441\u044b \u0432\u0441\u0435\u0445 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432; 1:2 \u2014 \u0434\u043e\u0447\u0435\u0440\u043d\u0438\u0439 \u043a\u043b\u0430\u0441\u0441 hsfc \u043e\u0431\u0449\u0438\u0439 \u0434\u043b\u044f \u0432\u0441\u0435\u0445 batch \u0438 idle \u0437\u0430\u0434\u0430\u0447 \u0441 &#171;\u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u043c&#187; \u043b\u0438\u043c\u0438\u0442\u043e\u043c, \u043e \u043a\u043e\u0442\u043e\u0440\u043e\u043c \u043d\u0438\u0436\u0435. \u041e\u0441\u0442\u0430\u043b\u044c\u043d\u044b\u0435 \u0434\u043e\u0447\u0435\u0440\u043d\u0438\u0435 \u043a\u043b\u0430\u0441\u0441\u044b hsfc \u2014 \u044d\u0442\u043e \u0432\u044b\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0435 \u043a\u043b\u0430\u0441\u0441\u044b \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0449\u0438\u0445 \u0432 \u0434\u0430\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 prod-\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u0441 \u043b\u0438\u043c\u0438\u0442\u0430\u043c\u0438, \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u043c\u0438 \u0438\u0445 \u043c\u0430\u043d\u0438\u0444\u0435\u0441\u0442\u0430\u043c, \u2014 450 \u0438 400 Mbit\/s. \u041a\u0430\u0436\u0434\u043e\u043c\u0443 \u043a\u043b\u0430\u0441\u0441\u0443 hsfc \u043d\u0430\u0437\u043d\u0430\u0447\u0435\u043d\u0430 qdisc \u043e\u0447\u0435\u0440\u0435\u0434\u044c fq \u0438\u043b\u0438 fq_codel, \u0432 \u0437\u0430\u0432\u0438\u0441\u0438\u043c\u043e\u0441\u0442\u0438 \u043e\u0442 \u0432\u0435\u0440\u0441\u0438\u0438 \u044f\u0434\u0440\u0430 linux, \u0434\u043b\u044f \u0438\u0437\u0431\u0435\u0436\u0430\u043d\u0438\u044f \u043f\u043e\u0442\u0435\u0440\u044c \u043f\u0430\u043a\u0435\u0442\u043e\u0432 \u043f\u0440\u0438 \u0432\u0441\u043f\u043b\u0435\u0441\u043a\u0430\u0445 \u0442\u0440\u0430\u0444\u0438\u043a\u0430. <\/p>\n<p><\/p>\n<p>Tavaliselt teenivad tc distsipliinid ainult v\u00e4ljamineva liikluse prioriseerimist. Kuid me tahame prioriseerida ka sissetulevat liiklust \u2014 kuna m\u00f5ni batch-\u00fclesanne v\u00f5ib kergesti \u00e4ra v\u00f5tta kogu sissetuleva kanali, n\u00e4iteks suurt andmepaketti map&amp;reduce'i jaoks. Selleks kasutame moodulit <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/350023\/tc-ingress-policing-and-ifb-mirroring\">ifb<\/a><\/noindex>, mis loob iga v\u00f5rgu liidese jaoks virtuaalse liidese ifbX ja suunab sissetuleva liikluse liideselt ifbX-i v\u00e4ljaminevaks. Edasi toimivad k\u00f5ik samad distsipliinid v\u00e4ljamineva liikluse kontrollimiseks, mille jaoks hsfc konfiguratsioon on v\u00e4ga sarnane:<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/iz\/ao\/-k\/izao-kgthgu_ptgyq9cjb1il0wm.png\"><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/967da9c0637cc70ba195af781db18adf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Eksperimentide k\u00e4igus selgus, et parimad tulemused hsfc saavutab siis, kui klassi 1:2 madalama prioriteediga batch\/idle liiklus on masinatel-minionidel piiratud mitte rohkem kui mingisuguse vaba ribalaiusega. Vastasel juhul m\u00f5jutab madalama prioriteediga liiklus liiga tugevalt prod-\u00fclesannete viivitust. Praegust vaba ribalaiuse suurust m\u00e4\u00e4rab miniond iga sekundi jooksul, m\u00f5\u00f5tes k\u00f5igi k\u00e4imasolevate prod-\u00fclesannete keskmist liiklusn\u00f5udlust selle minioni l\u00f5ikes <img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/9d6f38110d3b1693afe222b01430b9bb.jpg\" style=\"display:block;margin: 0 auto;\" \/> ja lahutades selle v\u00f5rgu liidese l\u00e4bilaskev\u00f5imest <img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/d5608ec4c58e44b8571ab0b1d0cc7701.jpg\" style=\"display:block;margin: 0 auto;\" \/> m\u00f5ningase varuga, st.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/fb01347c2224bd5bbd82169861eeb7e4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ribalaiused m\u00e4\u00e4ratakse sissetuleva ja v\u00e4ljamineva liikluse jaoks s\u00f5ltumatult. Ja vastavalt uutele v\u00e4\u00e4rtustele miniond konfigureerib \u00fcmber madalama prioriteediga klassi 1:2 limiidi.<\/p>\n<p><\/p>\n<p>Nii oleme rakendanud k\u00f5iki kolme isolatsiooniklassi: prod, batch ja idle. Need klassid m\u00f5jutavad oluliselt \u00fclesannete t\u00e4itmise omadusi. Seet\u00f5ttu otsustasime selle tunnuse hierarhiasse \u00fcles t\u00f5sta, et hierarhilise j\u00e4rjekorra nime vaadates oleks kohe selge, millega me tegeleme: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/34dc89c461db711b19a0f4eccc50efce.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>K\u00f5ik meie tuttavad <strong>web<\/strong> ja <strong>music<\/strong> frondid paigutatakse siis hierarhiatesse prod alla. N\u00e4iteks paigutame teenuse <strong>music catalog<\/strong>, mis perioodiliselt koostab muusikateoste katalooge, mis on \u00fcles laaditud \"Odnoklassniki\" mp3-failidest. N\u00e4iteks idle teenuse n\u00e4iteks v\u00f5ib olla <strong>music transformer<\/strong>, mis normaliseerib muusika helitugevuse taseme.<\/p>\n<p><\/p>\n<p>Korrates, kui eemaldame tarbetud read, saame meie teenuste nimed kirjutada lamedamalt, lisades \u00fclesande isolatsiooniklassi teenuse t\u00e4ieliku nime l\u00f5ppu: <strong>web.front.prod<\/strong>, <strong>catalog.music.batch<\/strong>, <strong>transformer.music.idle<\/strong>.<\/p>\n<p><\/p>\n<p>Ja n\u00fc\u00fcd, vaadates teenuse nime, m\u00f5istame mitte ainult seda, millist funktsiooni see t\u00e4idab, vaid ka tema isolatsiooniklassi, seega tema kriitilisust jne.<\/p>\n<p><\/p>\n<p>K\u00f5ik on suurep\u00e4rane, kuid on \u00fcks kibedat t\u00f5de. \u00dclesannete, mis t\u00f6\u00f6tavad \u00fchel masinal, t\u00e4ielik isolatsioon on v\u00f5imatu.<\/p>\n<p><\/p>\n<p>Mida oleme saavutanud: kui batch tarbib intensiivselt <strong>ainult<\/strong> CPU ressursside osas, integreeritud Linuxi CPU ajakava t\u00e4idab oma \u00fclesande v\u00e4ga h\u00e4sti, m\u00f5jutades tootmis\u00fclesannet peaaegu mitte midagi. Kuid kui see baatch-\u00fclesanne hakkab aktiivselt m\u00e4luga t\u00f6\u00f6tama, siis ilmneb juba vastastikune m\u00f5ju. See juhtub seet\u00f5ttu, et tootmis\u00fclesande puhul \"kannavad\" m\u00e4lust protsessori vahem\u00e4llud \u2014 tulemusena kasvavad vahem\u00e4lu tabamuste arv ja protsessor t\u00f6\u00f6tleb tootmis\u00fclesannet aeglasemalt. Selline baatch-\u00fclesanne v\u00f5ib t\u00f5sta meie t\u00fc\u00fcpilise tootmisn\u00f5ude latentsust kuni 10% v\u00f5rra.<\/p>\n<p><\/p>\n<p>Liiklust isoleerida on veelgi keerulisem, kuna kaasaegsetel v\u00f5rgukaartidel on olemas sisemine pakettide j\u00e4rjekord. Kui baatch-\u00fclesande pakett j\u00f5uab sinna esimesena, siis saadetakse see ka esimesena \u00fcle kaabli, ja siin ei saa midagi teha.<\/p>\n<p><\/p>\n<p>Lisaks oleme suutnud lahendada ainult TCP-liikluse prioriseerimise probleemi: UDP puhul ei t\u00f6\u00f6ta hsfc l\u00e4henemine. Ja isegi TCP-liiklusel, kui baatch-\u00fclesanne genereerib palju liiklust, p\u00f5hjustab see samuti umbes 10% tootmis\u00fclesande latentsuse suurenemist.<\/p>\n<p><\/p>\n<h2 id=\"otkazoustoychivost\">Katastroofitaluvus<\/h2>\n<p><\/p>\n<p>\u00dcheks eesm\u00e4rgiks one-cloud arendamisel oli parandada Odnoklassniki t\u00f5rkevastupidavust. Seega sooviksin p\u00f5hjalikumalt k\u00e4sitleda v\u00f5imalikke t\u00f5rke- ja h\u00e4daolukordi. Alustame lihtsast stsenaariumist \u2014 konteineri t\u00f5rkest. <\/p>\n<p><\/p>\n<p>Konteiner v\u00f5ib ise mitmeti eba\u00f5nnestuda. See v\u00f5ib olla mingi eksperiment, bug v\u00f5i viga manifestis, mis sunnib prod-\u00fclesannet tarbima rohkem ressursse kui manifestis m\u00e4\u00e4ratud. Meil oli olukord: arendaja rakendas keerulist algoritmi, tegi seda korduvalt, muutis selle liiga keeruliseks ja segadusse sattudes, p\u00f5hjustas, et \u00fclesanne j\u00e4i t\u00f5eliselt keeruliselt l\u00f5ksu. Kuna prod-\u00fclesanne on prioriteetsed k\u00f5ikidest teistest samadel mini-ressurssidel, hakkas see tarbima k\u00f5iki saadaval olevaid protsessorite ressursse. Sellises olukorras p\u00e4\u00e4stis isolatsioon, t\u00e4psemalt protsessori aja kvoot. Kui \u00fclesandele on m\u00e4\u00e4ratud kvoot, ei tarbi \u00fclesanne rohkem. Seega batch- ja muud prod-\u00fclesanded, mis t\u00f6\u00f6tasid samal masinal, ei m\u00e4rganud midagi. <\/p>\n<p><\/p>\n<p>Teine v\u00f5imalik probleem on konteineri kokkuvarisemine. Ja siinkohal aitavad meid taask\u00e4ivitamise poliitikad, millest k\u00f5ik teavad; Docker suudab sellega suurep\u00e4raselt toime tulla. Peaaegu k\u00f5ik prod-\u00fclesanded omavad taask\u00e4ivitamise poliitikat always. M\u00f5nikord kasutame on_failure batch-\u00fclesannete v\u00f5i prod-konteinerite silumise jaoks.<\/p>\n<p><\/p>\n<p>Mida saab teha, kui terve minion on k\u00e4ttesaamatuks muutunud?<\/p>\n<p><\/p>\n<p>Ilmselt tuleb konteiner k\u00e4ivitada teisel masinal. K\u00f5ige huvitavam on see, mis juhtub konteinerile m\u00e4\u00e4ratud IP-aadressiga (aedressidega). <\/p>\n<p><\/p>\n<p>Saame konteineritele m\u00e4\u00e4rata samu IP-aadresse nagu masinatel, mille minionid neid konteinerite k\u00e4ivitamiseks kasutavad. Siis kui konteiner k\u00e4ivitatakse teisel masinal, muutub tema IP-aadress, ja k\u00f5ik kliendid peavad m\u00f5istma, et konteiner on kolinud; n\u00fc\u00fcd tuleb minna teise aadressi juurde, mis n\u00f5uab eraldi teenuse Service Discovery. <\/p>\n<p><\/p>\n<p>Service Discovery on mugav. Turul on palju lahendusi erineva rikke taluvuse tasemega teenuste registri korraldamiseks. Tihti sellistes lahendustes rakendatakse koormuse tasakaalustamise loogikat, lisakonfiguratsiooni salvestamist KV-poodide kujul jne.<br \/>\nKuid me sooviksime v\u00e4ltida vajadust eraldi registri integreerimise j\u00e4rele, kuna see t\u00e4hendaks kriitilise s\u00fcsteemi loomist, mida kasutavad k\u00f5ik teenused tootmises. See t\u00e4hendab potentsiaalset rikke punkti, mist\u00f5ttu tuleb valida v\u00f5i arendada v\u00e4ga t\u00f5rke-kindel lahendus, mis on ilmselgelt v\u00e4ga keeruline, aegan\u00f5udev ja kallis. <\/p>\n<p><\/p>\n<p>Veel \u00fcks suur puudus: meie vana infrastruktuuri t\u00f6\u00f6tamiseks uuega oleks pidanud k\u00f5ik \u00fclesanded \u00fcmber kirjutama m\u00f5ne teenust avastava s\u00fcsteemi kasutamise jaoks. T\u00f6\u00f6 on \u00c4\u00c4RMISELT palju ja m\u00f5nes kohas lausa v\u00f5imatu, kui tegemist on madala taseme seadmetega, mis t\u00f6\u00f6tavad operatsioonis\u00fcsteemi tasandil v\u00f5i otse riistvaraga. Selle funktsionaalsuse rakendamine tuttavate lahendusmustritega, nagu n\u00e4iteks <noindex><a rel=\"nofollow\" href=\"https:\/\/linkerd.io\">side-car<\/a><\/noindex> t\u00e4hendaks m\u00f5nes kohas lisakoormust, m\u00f5nes \u2014 haldamise keerukust ja t\u00e4iendavaid rikke stsenaariume. Me ei soovinud keerukust, seega otsustasime teha teenust avastamise valikuliseks. <\/p>\n<p><\/p>\n<p>One-cloud IP j\u00e4rgneb konteinerile, st iga \u00fclesande eksemplaril on oma IP-aadress. See aadress on 'staatiline': see m\u00e4\u00e4ratakse igale eksemplarile hetkest, mil teenus esmakordselt pilve saadetakse. Kui teenuse eluea jooksul oli erinev arv eksemplare, siis l\u00f5puks on sellega seotud nii palju IP-aadresse, kui oli eksemplare maksimaalselt.<\/p>\n<p><\/p>\n<p>Hiljem neid aadresse ei muudeta: need m\u00e4\u00e4ratakse kord ja p\u00fcsivad teenuse elu jooksul tootmises. IP-aadressid j\u00e4rgivad konteinerite v\u00f5rku. Kui konteiner kantakse teisele miniaturisatsioonile, siis l\u00e4heb ka aadress tema kaasa. <\/p>\n<p><\/p>\n<p>Nii et teenuse nime ja tema IP-aadresside nimekirja sobitamine muutub v\u00e4ga harva. Kui veel kord vaadata teenuse eksemplaride nimesid, mida mainisime artikli alguses (<strong>1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, \u2026<\/strong>), siis m\u00e4rkame, et need sarnanevad DNS-is kasutatavatele FQDN-idele. Just selleks kasutame teenuste eksemplaride nimede sidumiseks nende IP-aadressidega DNS-protokolli. See DNS tagastab k\u00f5ik reserveeritud IP-aadressid k\u00f5igile konteineritele \u2014 nii t\u00f6\u00f6tavatele kui ka peatatud (kui meil on n\u00e4iteks kolm replikat ja seal on viis reserveeritud aadressi \u2014 tagastatakse k\u00f5ik viis). Klientidele, kes saavad selle teabe, proovivad nad \u00fchendust luua k\u00f5igi viie replikaga \u2014 ja tuvastavad seel\u00e4bi need, mis t\u00f6\u00f6tavad. See k\u00e4ttesaadavuse m\u00e4\u00e4ramise variant on oluliselt usaldusv\u00e4\u00e4rsem, kuna see ei h\u00f5lma DNS-i ega teenuse avastamist, mist\u00f5ttu ei teki ka keerulisi probleeme teabe ajakohasuse ja nende s\u00fcsteemide talitluskatkestuse tagamisega. Veelgi enam, kriitilistes teenustes, mille t\u00f6\u00f6 s\u00f5ltub kogu portaali toimimisest, v\u00f5ime DNS-i \u00fcldse mitte kasutada ja lihtsalt sisestada konfiguratsiooni IP-aadressid.<\/p>\n<p><\/p>\n<p>Sellise IP edastamise rakendamine konteinerite taga v\u00f5ib olla mitte triviaalne \u2014 ja peatume selle toimimisel j\u00e4rgmise n\u00e4ite kaudu:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/faf99c2609a57daa1bdc193cb0f4cb31.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kujutame ette, et one-cloud meister annab k\u00e4su minionile M1 k\u00e4ivitada <strong>1.ok-web.group1.web.front.prod<\/strong> aadressiga 1.1.1.1. Minione t\u00f6\u00f6tab <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Bird_Internet_routing_daemon\">BIRD<\/a><\/noindex>, mis kuulutab seda aadressi spetsiaalsetele serveritele <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Route_reflector\">route reflector<\/a><\/noindex>. Viimastel on BGP-seanss v\u00f5rgu seadmega, millele marsruut 1.1.1.1 edastatakse M1 kaudu. M1 suunab paketid konteinerisse juba Linuxi vahenditega. Route reflectorite arv on kolm, kuna see on one-cloudi infrastruktuuri v\u00e4ga kriitiline osa \u2014 ilma nendeta ei toimiks v\u00f5rk one-cloudis. Me paigutame need erinevatesse rackidesse, v\u00f5imalusel eri andmekeskuste saalidesse, et v\u00e4hendada k\u00f5igi kolme samaaegse rikke t\u00f5en\u00e4osust.<\/p>\n<p><\/p>\n<p>Oletame n\u00fc\u00fcd, et side one-cloudi meistri ja minioni M1 vahel on katkenud. One-cloudi meister k\u00e4itub n\u00fc\u00fcd eeldusel, et M1 on t\u00e4ielikult eba\u00f5nnestunud. See t\u00e4hendab, et ta annab k\u00e4su minionile M2 k\u00e4ivituda <strong>web.group1.web.front.prod<\/strong> sama aadressiga 1.1.1.1. N\u00fc\u00fcd on meil kaks konfliktset marsruuti v\u00f5rgus aadressile 1.1.1.1: M1 ja M2. Selliste konfliktide lahendamiseks kasutame Multi Exit Discriminator'it, mis on m\u00e4rgitud BGP-teates. See number n\u00e4itab reklaamitud marsruudi kaalu. Konfliktsetest valitakse marsruut, millel on v\u00e4iksem MED-v\u00e4\u00e4rtus. One-cloudi meister toetab MED'i kui IP-aadresside konteinerite lahutamatut osa. Esmakordselt v\u00e4ljastatakse aadress piisavalt suure MED = 1 000 000. Kui selline konteineri h\u00e4daolukord esineb, v\u00e4hendab meister MED'i ja M2 saab juba k\u00e4su reklaamida aadressi 1.1.1.1 MED = 999 999. Samas M1-l t\u00f6\u00f6tav eksemplar j\u00e4\u00e4b teie \u00fchenduse puudumise t\u00f5ttu ning selle edasine saatus meid ei huvitagi kuni \u00fchenduse taastamiseni meistriga, mil ta ka l\u00f5petatakse kui vana koopia.<\/p>\n<p><\/p>\n<h2 id=\"avarii\">Ohtlikud olukorrad<\/h2>\n<p><\/p>\n<p>K\u00f5ik andmekeskuste haldamise s\u00fcsteemid t\u00f6\u00f6tavad alati h\u00e4sti v\u00e4lja v\u00e4iksemaid t\u00f5rkeid. Koneetigear oli praktiliselt igal pool norm.<\/p>\n<p><\/p>\n<p>Vaatame, kuidas me h\u00e4daolukorraga toime tuleme, n\u00e4iteks toitekatkestus \u00fches v\u00f5i mitmes andmekeskuse saalis.<\/p>\n<p><\/p>\n<p>Mida t\u00e4hendab avarii andmekeskuse juhtimiss\u00fcsteemile? Esiteks on see massiivne korraga juhtunud mitme seadme rike, mille korral peab juhtimiss\u00fcsteem kohe migreerima v\u00e4ga palju konteynereid. Kuid kui avarii on v\u00e4ga ulatuslik, v\u00f5ib tekkida olukord, kus k\u00f5iki \u00fclesandeid ei saa mujale jaotada, kuna andmekeskuse ressursside maht langeb alla 100% koormuse. <\/p>\n<p><\/p>\n<p>Sageli kaasnevad avariidega ka juhtimistasandi riketeid. See v\u00f5ib juhtuda tema seadmete rikke t\u00f5ttu, kuid sagedamini seet\u00f5ttu, et avariisid ei ole testeeritud, ja juhtimistasand ise kukub suure koormuse t\u00f5ttu kokku. <\/p>\n<p><\/p>\n<p>Mida k\u00f5igega selle kohta teha saab?<\/p>\n<p><\/p>\n<p>Massilised migreerimised t\u00e4hendavad, et infrastruktuuris tekib suur hulk tegevusi, migreerimisi ja paigutusi. Iga migreerimine v\u00f5ib v\u00f5tta aega, mis on vajalik konteinerimoodulite piltide toimetamiseks ja lahtipakkimiseks minionides, konteinerite k\u00e4ivitamiseks ja initsialiseerimiseks jne. Seet\u00f5ttu on soovitav, et olulisemad \u00fclesanded k\u00e4ivituksid enne v\u00e4hemolulisi.<\/p>\n<p><\/p>\n<p>Uurime taas tuttavat teenuste hierarhiat ja proovime otsustada, millised \u00fclesanded me esmaj\u00e4rjekorras k\u00e4ima l\u00fckkame.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/2e827271adb8d3ff3d385e53553aaacf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Loomulikult on need protsessid, mis otse osalevad kasutaja p\u00e4ringute t\u00f6\u00f6tlemises, st prod. Me m\u00e4rkime selle \u00fcles <strong>prioriteedi m\u00e4\u00e4ramisega<\/strong> \u2014 numbriga, mis v\u00f5ib olla m\u00e4\u00e4ratud j\u00e4rjekorrale. Kui mingi j\u00e4rjekorra prioriteet on k\u00f5rgem, paigutatakse selle teenused esmaj\u00e4rjekorras.<\/p>\n<p><\/p>\n<p>Prodile m\u00e4\u00e4rame k\u00f5rgemad prioriteedid, 0; batchile veidi madalamad, 100; idle-le veel madalamad, 200. Prioriteedid kehtivad hierarhiliselt. K\u00f5ikidel madalama hierarhiaga \u00fclesannetel on vastav prioriteet. Kui tahame, et prod-i sees k\u00e4ivituksid vahem\u00e4lud enne frontend-e, siis m\u00e4\u00e4rame prioriteedid cache = 0 ja frontend-i alamj\u00e4rjekorrale = 1. Kui aga soovime, et frontidest k\u00e4ivituks esmalt p\u00f5hiportaal, ja muusika front siis hiljem, v\u00f5ime viimasele m\u00e4\u00e4rata madalama prioriteedi \u2014 10.<\/p>\n<p><\/p>\n<p>J\u00e4rgmine probleem on ressursside puudus. Meil on suured varustuse rikkeid, terveid andmekeskuste saale, ja oleme k\u00e4ivitanud nii palju teenuseid, et n\u00fc\u00fcd ei j\u00e4tku ressursse k\u00f5igile. Tuleb otsustada, millistest \u00fclesannetest v\u00f5ib loobuda, et p\u00e4\u00e4sta kriitilised teenused. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/1b1ad3da16df6677dd0ba4b038cdd7d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Erinevalt paigutuse prioriteedist ei saa me k\u00f5iki batch-\u00fclesandeid lihtsalt k\u00f5rvale j\u00e4tta, m\u00f5ned neist on portaali toimimise jaoks olulised. Seet\u00f5ttu oleme eraldanud <strong>prioriteedi v\u00e4lja t\u00f5rjumine<\/strong> \u00fclesande. Paigutamise ajal v\u00f5ib k\u00f5rgema prioriteediga \u00fclesanne k\u00f5rvale t\u00f5rjuda, st l\u00f5petada madalama prioriteediga \u00fclesande, kui ei ole enam vabu minione. Sel juhul j\u00e4\u00e4b madalama prioriteediga \u00fclesanne t\u00f5en\u00e4oliselt paigutamata, st ei leita talle enam sobivat minionit, kellel on piisavalt vabade ressursside.<\/p>\n<p><\/p>\n<p>Meie hierarhias on v\u00e4ga lihtne m\u00e4\u00e4rata selline prioriteet, et prod- ja batch-\u00fclesanded t\u00f5ukavad v\u00f5i peatavad idle-\u00fclesanded, kuid mitte \u00fcksteist, m\u00e4\u00e4rates idle jaoks prioriteedi, mis on 200. Nii nagu paigutuse prioriteedi puhul, saame kasutada meie hierarhias, et kirjeldada keerukamaid reegleid. N\u00e4iteks m\u00e4\u00e4rame, et muusika funktsioon on midagi, millega me loobume, kui meie p\u00f5hivebilehe ressursid ei piisa, seades vastavatele s\u00f5lmedele madalama prioriteedi: 10.<\/p>\n<p><\/p>\n<h2 id=\"avarii-dc-celikom\">DC avariid t\u00e4ielikult<\/h2>\n<p><\/p>\n<p>Miks v\u00f5ib kogu andmekeskus eba\u00f5nnestuda? Loodusj\u00f5ud. Oli hea postitus, kuidas <noindex><a rel=\"nofollow\" href=\"https:\/\/habrahabr.ru\/company\/dataline\/blog\/333578\/\">orkaan m\u00f5jutas andmekeskuse t\u00f6\u00f6d<\/a><\/noindex>. Loodusj\u00f5ududeks v\u00f5ib pidada ka kodutuid, kes kunagi suutsid optikat kollektoris p\u00f5letada, ja andmekeskus kaotas t\u00e4ielikult \u00fchenduse teiste paikadega. Rikkumise p\u00f5hjuseks v\u00f5ib olla ka inimfaktor: operaator annab k\u00e4su, mille tulemusena kukub kogu andmekeskus. See v\u00f5ib juhtuda suure vea t\u00f5ttu. \u00dcldiselt kukuvad andmekeskused \u2014 see pole haruldane. Meil toimub see \u00fcks kord paarikuu jooksul. <\/p>\n<p><\/p>\n<p>Ja siin on, mida me teeme, et keegi #ok\u017eivii ei postitaks Twitteris.<\/p>\n<p><\/p>\n<p>Esimene strateegia on isoleerimine. Iga one-cloud instants on isoleeritud ja suudab hallata vaid \u00fche andmekeskuse masinaid. Seega t\u00e4hendab pilve kaotamine vigade v\u00f5i operaatori vale k\u00e4su t\u00f5ttu vaid \u00fche andmekeskuse kaotamist. Oleme selleks valmis: meil on varukoopia poliitika, mille kohaselt rakenduse ja andmete koopiad on paigutatud k\u00f5ikidesse andmekeskustesse. Kasutame t\u00f5rgeteta andmebaase ja testime perioodiliselt t\u00f5rkeid.<br \/>\nKuna meil on t\u00e4na neli andmekeskust, on ka neli eraldi, t\u00e4ielikult isoleeritud one-cloud instantsi.<\/p>\n<p><\/p>\n<p>Selline l\u00e4henemine mitte ainult ei kaitse f\u00fc\u00fcsiliste rikete eest, vaid v\u00f5ib kaitsta ka operaatori vigu.<\/p>\n<p><\/p>\n<p>Mis veel saab inimfaktoriga teha? Kui operaator annab pilvele mingi kummalise v\u00f5i potentsiaalselt ohtliku k\u00e4su, v\u00f5ib temalt ootamatult n\u00f5uda v\u00e4ikese \u00fclesande t\u00e4itmist, et kontrollida, kui h\u00e4sti ta on m\u00f5elnud. N\u00e4iteks, kui see on mingi massiline peatamine paljude koopiate puhul v\u00f5i lihtsalt kummaline k\u00e4sk \u2014 koopiate arvu v\u00e4hendamine v\u00f5i pildi nime muutmine, mitte ainult versiooni numbri muutmine uues manifestis.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/vh\/vw\/0d\/vhvw0dzobo9sd4x7zih_cnfnlu8.png\"><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse taseme ops\u00fcsteem Odnoklassnikutes\" src=\"\/wp-content\/uploads\/2020\/06\/f7ee44a77e30612a3cd99a6f7aee3820.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<h2 id=\"itogi\">Kokkuv\u00f5te<\/h2>\n<p><\/p>\n<p>one-cloudi eristuvad jooned: <\/p>\n<p><\/p>\n<ul>\n<li><strong>Hierarhiline ja selge teenuste ja konteinerite nimetamise skeem<\/strong>, mis v\u00f5imaldab v\u00e4ga kiiresti teada saada, milline \u00fclesanne see on, millele see viitab, kuidas see t\u00f6\u00f6tab ja kes selle eest vastutab. <\/li>\n<li>Kasutame oma <strong>prod- ja batch-<\/strong>\u00fclesannete \u00fchinemise tehnikat minikonteinerites, et suurendada masinate \u00fchiskasutuse efektiivsust. Cpuset'i asemel kasutame CPU kvoote, aktsiaid, CPU ajakava poliitikat ja Linuxi QoS-i.<\/li>\n<li>T\u00e4ielikult isoleerida sama masinaga t\u00f6\u00f6tavad konteinerid ei \u00f5nnestunud, kuid nende vastastikune m\u00f5ju j\u00e4\u00e4b 20% piiresse.<\/li>\n<li>Teenuste korraldamine hierarhias aitab automaatsete avariide likvideerimise puhul <strong>paigutus- ja t\u00f5rjumisprioriteetide<\/strong>.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"chavo\">KKK<\/h2>\n<p><\/p>\n<p>Miks me ei valinud valmis lahendust.<\/p>\n<p><\/p>\n<ul>\n<li>Erinevad \u00fclesannete isolatsiooniklassid vajavad erinevat loogikat minikonteinerites paigutamisel. Kui prod-\u00fclesandeid saab paigutada lihtsalt ressursside reserveerimise kaudu, siis batch ja idle tuleb paigutada, j\u00e4lgides masinate minikonteinerite reaalseid ressursikasutusi. <\/li>\n<li>On oluline arvesse v\u00f5tta selliseid \u00fclesannete tarbimisressursse nagu: \n<ul>\n<li>v\u00f5rgulaius;<\/li>\n<li>ketaste t\u00fc\u00fcbid ja \"spindlid.\"<\/li>\n<\/ul>\n<\/li>\n<li>Teenuste prioriteetide m\u00e4\u00e4ramine h\u00e4daolukordade likvideerimise k\u00e4igus, meeskondade \u00f5igused ja piirangud ressurssidele, mida lahendatakse hierarhiliste j\u00e4rjekordade abil one-cloudis.<\/li>\n<li>Inimlikult m\u00f5istetavate konteinerite nimetuste loomise vajadus, et v\u00e4hendada reageerimisaega h\u00e4dadele ja intsidentidele.<\/li>\n<li>Teenuse avastamise kohustusliku ja samal ajal laialdase rakendamise v\u00f5imatus; vajadus kaua koos eksisteerida \u00fclesannetega, mis on paigutatud f\u00fc\u00fcsilisele riistvarale \u2014 seda lahendatakse \u00abstaatiliste\u00bb IP-aadressidega, mis j\u00e4rgnevad konteineritele, ja seet\u00f5ttu on vajalik ainulaadne integratsioon suure v\u00f5rguinfrastruktuuriga.<\/li>\n<\/ul>\n<p><\/p>\n<p>K\u00f5ik need funktsioonid n\u00f5uavad olemasolevate lahenduste olulisi \u00fcmberehitusi, ja arvestades t\u00f6\u00f6mahtu, m\u00f5istsime, et saame arendada oma lahenduse umbes sama t\u00f6\u00f6j\u00f5u pingutusega. Kuid meie lahendust on oluliselt lihtsam kasutada ja edasi arendada \u2014 selles puuduvad ebavajalikud abstraktsioonid, mis toetavad meile mitteolulist funktsionaalsust. <\/p>\n<p><\/p>\n<p>Neile, kes loevad viimaseid ridu, \u2014 ait\u00e4h kannatlikkuse ja t\u00e4helepanu eest!<\/p>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0410\u043b\u043e\u0445\u0430, \u043f\u0438\u043f\u043b! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041e\u043b\u0435\u0433 \u0410\u043d\u0430\u0441\u0442\u0430\u0441\u044c\u0435\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 \u041f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b. \u0410 \u043a\u0440\u043e\u043c\u0435 \u043c\u0435\u043d\u044f, \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043a\u0443\u0447\u0430 \u0436\u0435\u043b\u0435\u0437\u0430. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0447\u0435\u0442\u044b\u0440\u0435 \u0426\u041e\u0414\u0430, \u0432 \u043d\u0438\u0445 \u043e\u043a\u043e\u043b\u043e 500 \u0441\u0442\u043e\u0435\u043a \u0431\u043e\u043b\u0435\u0435 \u0447\u0435\u043c \u0441 8 \u0442\u044b\u0441\u044f\u0447\u0430\u043c\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432. \u0412 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 \u043c\u044b \u043f\u043e\u043d\u044f\u043b\u0438, \u0447\u0442\u043e \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435 \u043d\u043e\u0432\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442 \u043d\u0430\u043c \u0431\u043e\u043b\u0435\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0437\u0430\u0433\u0440\u0443\u0437\u0438\u0442\u044c \u0442\u0435\u0445\u043d\u0438\u043a\u0443, \u043e\u0431\u043b\u0435\u0433\u0447\u0438\u0442\u044c \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84115,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84114","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0410\u043b\u043e\u0445\u0430, \u043f\u0438\u043f\u043b! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041e\u043b\u0435\u0433 \u0410\u043d\u0430\u0441\u0442\u0430\u0441\u044c\u0435\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 \u041f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b. \u0410 \u043a\u0440\u043e\u043c\u0435 \u043c\u0435\u043d\u044f, \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043a\u0443\u0447\u0430 \u0436\u0435\u043b\u0435\u0437\u0430. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0447\u0435\u0442\u044b\u0440\u0435 \u0426\u041e\u0414\u0430, \u0432 \u043d\u0438\u0445 \u043e\u043a\u043e\u043b\u043e 500 \u0441\u0442\u043e\u0435\u043a \u0431\u043e\u043b\u0435\u0435 \u0447\u0435\u043c \u0441 8 \u0442\u044b\u0441\u044f\u0447\u0430\u043c\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432. \u0412 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 \u043c\u044b \u043f\u043e\u043d\u044f\u043b\u0438, \u0447\u0442\u043e \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435 \u043d\u043e\u0432\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442 \u043d\u0430\u043c \u0431\u043e\u043b\u0435\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0437\u0430\u0433\u0440\u0443\u0437\u0438\u0442\u044c \u0442\u0435\u0445\u043d\u0438\u043a\u0443, \u043e\u0431\u043b\u0435\u0433\u0447\u0438\u0442\u044c \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47One-cloud \u2014 \u041e\u0421 \u0443\u0440\u043e\u0432\u043d\u044f \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0430 \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0410\u043b\u043e\u0445\u0430, \u043f\u0438\u043f\u043b! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041e\u043b\u0435\u0433 \u0410\u043d\u0430\u0441\u0442\u0430\u0441\u044c\u0435\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 \u041f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b. \u0410 \u043a\u0440\u043e\u043c\u0435 \u043c\u0435\u043d\u044f, \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043a\u0443\u0447\u0430 \u0436\u0435\u043b\u0435\u0437\u0430. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0447\u0435\u0442\u044b\u0440\u0435 \u0426\u041e\u0414\u0430, \u0432 \u043d\u0438\u0445 \u043e\u043a\u043e\u043b\u043e 500 \u0441\u0442\u043e\u0435\u043a \u0431\u043e\u043b\u0435\u0435 \u0447\u0435\u043c \u0441 8 \u0442\u044b\u0441\u044f\u0447\u0430\u043c\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432. \u0412 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 \u043c\u044b \u043f\u043e\u043d\u044f\u043b\u0438, \u0447\u0442\u043e \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435 \u043d\u043e\u0432\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442 \u043d\u0430\u043c \u0431\u043e\u043b\u0435\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0437\u0430\u0433\u0440\u0443\u0437\u0438\u0442\u044c \u0442\u0435\u0445\u043d\u0438\u043a\u0443, \u043e\u0431\u043b\u0435\u0433\u0447\u0438\u0442\u044c \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-05T05:42:55+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-05T05:42:55+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikis | ProHoster","description":"Aloha, rahvas! Minu nimi on Oleg Anastasev, ma t\u00f6\u00f6tan Odnoklassnikis Platvormi meeskonnas. Lisaks mulle t\u00f6\u00f6tab Odnoklassnikis palju riistvara. Meil on neli andmekeskust, kus on umbes 500 riiulit ja \u00fcle 8000 serveri. \u00dchel hetkel m\u00f5istsime, et uue halduss\u00fcsteemi rakendamine v\u00f5imaldab meil tehnikat efektiivsemalt kasutada ja haldamist lihtsustada.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47One-cloud \u2014 \u041e\u0421 \u0443\u0440\u043e\u0432\u043d\u044f \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0430 \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 | ProHoster","og:description":"\u0410\u043b\u043e\u0445\u0430, \u043f\u0438\u043f\u043b! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041e\u043b\u0435\u0433 \u0410\u043d\u0430\u0441\u0442\u0430\u0441\u044c\u0435\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435 \u041f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b. \u0410 \u043a\u0440\u043e\u043c\u0435 \u043c\u0435\u043d\u044f, \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043a\u0443\u0447\u0430 \u0436\u0435\u043b\u0435\u0437\u0430. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0447\u0435\u0442\u044b\u0440\u0435 \u0426\u041e\u0414\u0430, \u0432 \u043d\u0438\u0445 \u043e\u043a\u043e\u043b\u043e 500 \u0441\u0442\u043e\u0435\u043a \u0431\u043e\u043b\u0435\u0435 \u0447\u0435\u043c \u0441 8 \u0442\u044b\u0441\u044f\u0447\u0430\u043c\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432. \u0412 \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 \u043c\u044b \u043f\u043e\u043d\u044f\u043b\u0438, \u0447\u0442\u043e \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u0435 \u043d\u043e\u0432\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442 \u043d\u0430\u043c \u0431\u043e\u043b\u0435\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e \u0437\u0430\u0433\u0440\u0443\u0437\u0438\u0442\u044c \u0442\u0435\u0445\u043d\u0438\u043a\u0443, \u043e\u0431\u043b\u0435\u0433\u0447\u0438\u0442\u044c \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-05T05:42:55+00:00","article:modified_time":"2020-06-05T05:42:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84114","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:04:42","updated":"2022-10-02 14:53:14"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/84114","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=84114"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/84114\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/84115"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=84114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=84114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=84114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}