{"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 tasemel operatsioonis\u00fcsteem Odnoklassnikites","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" 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 Anastasjev, t\u00f6\u00f6tan Klassikaaslaste meeskonnas Platvormi osas. Lisaks mulle t\u00f6\u00f6tab Klassikaaslaste juures terve hulk tehnikat. Meil on neli andmekeskust, kus on umbes 500 riiulit \u00fcle 8000 serveriga. \u00dchel hetkel taipasime, et uue juhtimiss\u00fcsteemi juurutamine v\u00f5imaldab meil tehnika t\u00f5husamat kasutamist, juurdep\u00e4\u00e4suhalduse lihtsustamist, arvutusressursside automatiseeritud (taas)jaotamist, uute teenuste k\u00e4ivitamise kiirendamist ning ulatuslike h\u00e4irete korral kiiremat reageerimist. <\/p>\n<p><\/p>\n<p>Mida me sellest l\u00f5ppkokkuv\u00f5ttes saime? <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Minu ja hulga tehnikate k\u00f5rval on ka inimesi, kes selle tehnikaga t\u00f6\u00f6tavad: insenerid, kes on otseselt andmekeskustes; v\u00f5rguinsenerid, kes seadistavad v\u00f5rgu infrastruktuuri; administraatorid ehk SRE-d, kes tagavad infrastruktuuri t\u00f6\u00f6kindluse; ja arendajate meeskonnad, kellel on iga\u00fchel oma osa portaali funktsioonidest. Nende loodud tarkvara t\u00f6\u00f6tab umbes niimoodi:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/592fd0acfa7322eb80fbb85601a92918.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kasutajate p\u00e4ringud tulevad nii p\u00f5hiv\u00e4ravatesse <noindex><a rel=\"nofollow\" href=\"http:\/\/www.ok.ru\/\">www.ok.ru<\/a><\/noindex>, kui ka muudele, n\u00e4iteks muusika API frontidele. Need kutsuvad \u00e4riloogika t\u00f6\u00f6tlemiseks esile rakenduste serveri, mis p\u00e4ringu t\u00f6\u00f6tlemisel kutsub vajalikud spetsialiseeritud mikroteenused - one-graph (sotsiaalsete sidemete graaf), user-cache (kasutajaprofiilide vahem\u00e4lu) jne.<\/p>\n<p><\/p>\n<p>Iga\u00fcks neist teenustest on paigaldatud paljudele masinatele ning igal neist on vastutavad arendajad, kes vastutavad moodulite toimimise, nende opereerimise ja tehnoloogilise arengu eest. K\u00f5ik need teenused k\u00e4ivitatakse rauas olevatel serveritel, ja kuni hiljutise ajani k\u00e4ivitasime t\u00e4pselt \u00fche \u00fclesande \u00fchel serveril, st see oli spetsialiseeritud konkreetsele \u00fclesandele.<\/p>\n<p><\/p>\n<p>Miks nii? Sellel l\u00e4henemisel oli mitmeid plusse:<\/p>\n<p><\/p>\n<ul>\n<li>Lihtsustatakse <strong>massiivne haldamine<\/strong>. Oletame, et \u00fclesanne n\u00f5uab mingisuguseid teeke, mingisuguseid seadistusi. Sel juhul m\u00e4\u00e4ratakse server t\u00e4pselt \u00fchte kindlasse gruppi, sellele grupile kirjeldatakse cfengine poliitika (v\u00f5i see on juba kirjeldatud), ja see konfiguratsioon levitatakse keskelt ja automaatselt k\u00f5igile selle grupi serveritele.<\/li>\n<li>Lihtsustatakse <strong>diagnoosimine<\/strong>. Oletame, et vaatad suurenenud protsessori koormust ja m\u00f5istad, et selle koormuse v\u00f5is genereerida ainult see \u00fclesanne, mis t\u00f6\u00f6tab sellel raual. S\u00fc\u00fcdlase otsingud l\u00f5ppesid v\u00e4ga kiiresti.<\/li>\n<li>Lihtsustatakse <strong>monitooring<\/strong>. Kui serveriga on midagi valesti, teavitab monitor sellest ning tead 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 oma. Seega antakse teenusele arvutusressursse v\u00e4ga lihtsalt: sama palju ressursse, kui teenusel on servereid, seda ta saab maksimaalselt tarbida. \"Lihtne\" ei t\u00e4henda siin seda, et seda on lihtne kasutada, vaid et ressursi jaotamine toimub k\u00e4sitsi.<\/p>\n<p><\/p>\n<p>See l\u00e4henemine v\u00f5imaldas meil ka teha <strong>spetsialiseeritud raua konfiguratsioone<\/strong> \u00fclesande jaoks, mis toimub sellel serveril. Kui \u00fclesanne hoiab suuri andmehulkasid, kasutame 4U-serverit, mille \u0161assiis on 38 ketast. Kui \u00fclesanne on puhtalt arvutuslik, v\u00f5ime osta odavama 1U-serveri. See on efektiivne arvutusressursside aspektist. Samuti v\u00f5imaldab see l\u00e4henemine meil kasutada neli korda v\u00e4hem masinaid sama koormuse korral, mis on v\u00f5rreldav \u00fche meie s\u00f5bralikule sotsiaalv\u00f5rgustikule. <\/p>\n<p><\/p>\n<p>Selline arvutusressursside efektiivne kasutamine peaks tagama ka majandusliku efektiivsuse, l\u00e4htudes v\u00e4itest, et k\u00f5ige kallim on serverid. Pikka aega oli k\u00f5ige kallim just raua hind ja oleme investeerinud palju ressursse raua hinna alandamisse, v\u00e4lja m\u00f5eldes talitlush\u00e4irete v\u00e4ltimise algoritmid, et v\u00e4hendada seadmete t\u00f6\u00f6kindluse n\u00f5udmisi. Ja t\u00e4na oleme j\u00f5udnud faasi, kus serveri hind ei ole enam m\u00e4\u00e4rav. Kui mitte arvesse v\u00f5tta v\u00e4rsket eksootikat, siis konkreetse serverikonfiguratsiooni paiknemine rackis ei oma t\u00e4htsust. N\u00fc\u00fcd on meil tekkinud teine probleem \u2014 serveri h\u00f5ivatud ruumi hind andmekeskuses, st ruumi rackis.<\/p>\n<p><\/p>\n<p>M\u00f5istes, et see nii on, otsustasime arvutada, kui t\u00f5husalt me racke kasutame.<br \/>\nV\u00f5tsime k\u00f5ige v\u00f5imsama serveri hinna, mis on majanduslikult p\u00f5hjendatud, arvutasime, kui palju selliseid servereid mahub meie rack'idesse ja kui palju \u00fclesandeid saaksime neile m\u00e4\u00e4rata, l\u00e4htuvalt vanast mudelist \"\u00fcks server = \u00fcks \u00fclesanne\" ning kui h\u00e4sti suudaksid need \u00fclesanded varustust \u00e4ra kasutada. Tegime arvutusi ja olime \u00fcllatunud. Selgus, et rackide kasutusefektiivsus meie juures on umbes 11%. J\u00e4reldus on ilmne: andmekeskuste kasutusefektiivsust tuleb parandada. Esmapilgul tundub, et lahendus on lihtne: tuleb \u00fchel serveril samal ajal k\u00e4ivitada mitu \u00fclesannet. Kuid siin tekivad probleemid. <\/p>\n<p><\/p>\n<p>Massiline konfiguratsioon muutub j\u00e4rsult keeruliseks \u2014 n\u00fc\u00fcd ei saa serverile m\u00e4\u00e4rata \u00fchte kindlat gruppi. Sest n\u00fc\u00fcd v\u00f5ivad \u00fchel serveril t\u00f6\u00f6tada mitu erinevate meeskondade \u00fclesannet. Lisaks v\u00f5ib konfiguratsioon olla erinevatele rakendustele konfliktselt. Diagnostika muutub samuti keeruliseks: kui saate serveris n\u00e4ha k\u00f5rgendatud protsessorite v\u00f5i ketta kasutust, ei tea te, milline \u00fclesanne tekitab probleeme.<\/p>\n<p><\/p>\n<p>Kuid peamine asi on see, et \u00fclesannete vahel, mis on k\u00e4ivitatud \u00fchel masinal, pole isolatsiooni. N\u00e4iteks on graafik serveri \u00fclesande keskmisest vastamisajast enne ja p\u00e4rast seda, kui samal serveril k\u00e4ivitati veel \u00fcks, mitte mingil moel seotud arvutusrakendus \u2014 peamise \u00fclesande vastamise aeg on oluliselt suurenenud.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/c7c07359ae572ca8c84a4c63559e4083.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ilmselgelt on vaja \u00fclesandeid k\u00e4ivitada kas konteinerites v\u00f5i virtuaalmasinates. Kuna praktiliselt k\u00f5ik \u00fclesanded k\u00e4ivitatakse meil \u00fche operatsioonis\u00fcsteemi (Linuxi) all v\u00f5i on selleks kohandatud, ei ole meil vajalik toetada mitmeid erinevaid operatsioonis\u00fcsteeme. Seega ei ole virtualiseerimine vajalik; t\u00e4nu lisa\u00fclekandekuludele on see konteineriseerimisest v\u00e4hem efektiivne.<\/p>\n<p><\/p>\n<p>Docker on konteinerite kasutamise jaoks hea lahendus serverites: failis\u00fcsteemi pildid lahendavad h\u00e4sti konflikti kohanduste probleemid. Pildid, mida saab koostada mitmest kihist, v\u00f5imaldavad meil oluliselt v\u00e4hendada andmemahu, mis on vajalik nende juurutamiseks infrastruktuurile, eraldades \u00fchised osad eraldi p\u00f5hikihidesse. Sel juhul on p\u00f5hikihid (ja k\u00f5ige mahukamad) kiiresti vahem\u00e4llu salvestatud kogu infrastruktuuris ning erinevate rakenduste ja versioonide kohaletoimetamiseks on vajalik edastada ainult v\u00e4ikesemahulisi kihte. <\/p>\n<p><\/p>\n<p>Lisaks pakub valmis register ja piltide m\u00e4rgistamine Dockeris meile valmis primitiivid versioonide haldamiseks ja koodi toimetamiseks tootmisse.<\/p>\n<p><\/p>\n<p>Docker, nagu iga teine sarnane tehnoloogia, pakub meile teatud isolatsioonitaseme konteinerite jaoks. N\u00e4iteks m\u00e4lu isolatsioon \u2013 igale konteinerile m\u00e4\u00e4ratakse masina m\u00e4lu kasutuspiir, mida ta ei \u00fcleta. Samuti saab konteinerite CPU kasutust isoleerida. Ent meie jaoks oli standardne isolatsioon ebapiisav. Kuid sellest allpool.<\/p>\n<p><\/p>\n<p>Konteinerite vahetu k\u00e4itamine serverites on vaid osa probleemidest. Teine osa on seotud konteinerite paigutamisega serveritesse. Tuleb aru saada, milline konteiner sobib millisele serverile. See ei ole nii lihtne \u00fclesanne, kuna konteinerid tuleb paigutada serveritesse nii tihedalt kui v\u00f5imalik, samas speedi aeglustamata. Selline paigutamine v\u00f5ib olla keeruline ka t\u00f5rkekindluse osas. Sageli soovime paigutada sama teenuse koopiaid erinevatesse riiulitesse v\u00f5i isegi erinevatesse andmekeskuse saalidesse, et korralduste v\u00f5i saali rikke korral ei kaotaks kohe k\u00f5iki teenuse koopiaid. <\/p>\n<p><\/p>\n<p>Konteinerite k\u00e4sitsi jaotamine ei ole variant, kui sul on 8000 serverit ja 8000\u201316000 konteinerit. <\/p>\n<p><\/p>\n<p>Lisaks soovisime anda arendajatele rohkem iseseisvust ressursside jaotamisel, et nad saaksid oma teenuseid tootmisse paigutada ilma administraatori abita. Samal ajal soovisime hoida kontrolli, et m\u00f5ni teisej\u00e4rguline teenus ei kasutaks k\u00f5iki meie andmekeskuste ressursse. <\/p>\n<p><\/p>\n<p>On selge, et on vaja halduskihti, mis tegeleks sellega automaatselt.<\/p>\n<p><\/p>\n<p>Siin me oleme 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 tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/079df6e79874ef55b0d967fde3d5feca.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>one-cloud meistrid \u2014 veakindel klaster, mis vastutab pilve orkestreerimise eest. Arendaja saadab meistrile manifesti, mis sisaldab kogu teenuse paigutamiseks vajalikku teavet. Meister annab selle p\u00f5hjal k\u00e4sklusi valitud minionidele (masinatele, mis on ette n\u00e4htud konteinerite k\u00e4itamiseks). Minionitel on meie agent, kes saab k\u00e4skluse, edastab juba oma k\u00e4sud Dockerile, ning Docker konfigureerib Linuxi tuuma vastava konteineri k\u00e4ivitamiseks. Peale k\u00e4skude t\u00e4itmise teatab agent pidevalt meistrile muutustest nii minioni masina seisundis kui ka sellel k\u00e4ivitatavatest konteineritest.<\/p>\n<p><\/p>\n<h2 id=\"raspredelenie-resursov\">Resursside jaotamine<\/h2>\n<p><\/p>\n<p>Ja n\u00fc\u00fcd vaatame keerulisemat \u00fclesannet, mis on ressursside jaotamine mitmete minionide jaoks.<\/p>\n<p><\/p>\n<p>K\u00fcsimus one-cloudi arvutusressursside kohta on:<\/p>\n<p><\/p>\n<ul>\n<li>Protsessori arvutusv\u00f5ime, mida konkreetne \u00fclesanne tarbib. <\/li>\n<li>M\u00e4lu maht, mis on \u00fclesandele saadaval. <\/li>\n<li>Void: iga minionil on spetsiaalne v\u00f5rguliides piiratud ribalaiusega, seet\u00f5ttu ei saa \u00fclesandeid jaotada, arvestamata nende kaudu edastatavaid andmehulki. <\/li>\n<li>Kettad. Peale ilmselgelt andmete hoidmiseks m\u00f5eldud ruumi m\u00e4\u00e4rame ka ketta t\u00fc\u00fcbi: HDD v\u00f5i SSD. Kettad saavad teenindada l\u00f5petatud p\u00e4ringute arvu sekundis \u2014 IOPS. Seega, \u00fclesannete puhul, mis genereerivad rohkem IOPS, kui \u00fcks ketas suudab teenindada, m\u00e4\u00e4rame eraldi 'spindlid' \u2014 st kettaseadmed, mis peavad olema rangelt reserveeritud \u00fclesande jaoks.<\/li>\n<\/ul>\n<p><\/p>\n<p>Nii et m\u00f5ne teenuse, n\u00e4iteks user-cache'i, jaoks saame ressursid registreerida j\u00e4rgmiselt: 400 protsessorituuma, 2,5 TB m\u00e4lu, 50 Gbit\/s liiklust m\u00f5lemas suunas, 6 TB ruumi HDD-l, mis on paigutatud 100 spindlile. V\u00f5i meie jaoks tuttavamas vormis 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 teenuse ressursid kasutavad vaid osa k\u00f5igist tootmistehnoloogiliste s\u00fcsteemide kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt, seet\u00f5ttu tahame saavutada, et user-cache ei kasutaks ootamatult, olenemata operaatori veast v\u00f5i mitte, rohkem ressursse, kui talle on m\u00e4\u00e4ratud. See t\u00e4hendab, et peame ressursse piiritama. Aga millega me saame kvooti siduda?<\/p>\n<p><\/p>\n<p>Naasime tagasi meie tugevalt lihtsustatud koostisosade koost\u00f6\u00f6skeemi ja joonistame selle \u00fcmber suurema detailiga \u2014 nii. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/27e5bfbffadd3d4b9fdc6bf138d135ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mida t\u00e4hele panna:<\/p>\n<p><\/p>\n<ul>\n<li>Veebi esik\u00fclg ja muusika kasutavad sama rakenduste serveri isoleeritud klastreid.<\/li>\n<li>V\u00f5ime tuvastada loogilised kihid, mis h\u00f5lmavad neid klastreid: esifront, vahem\u00e4lud, andmete salvestamise ja haldamise kiht.<\/li>\n<li>Esik\u00fclg ei ole homogeenne, need on erinevad funktsionaalsed alams\u00fcsteemid. <\/li>\n<li>Vahem\u00e4lud saab samuti jagada alams\u00fcsteemide vahel, mille andmeid nad vahem\u00e4lusse salvestavad.<\/li>\n<\/ul>\n<p><\/p>\n<p>Korrake pildi joonistamist:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" 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 ressursse on v\u00f5imalik jaotada suuremates plokkides: m\u00e4\u00e4rata vastutav arendaja selle hierarchia s\u00f5lme, mis vastab funktsionaalsele alams\u00fcsteemile (nagu \u201emuusika\u201d pildil), ja siduda selle sama hierarhiatasemega kvota. Selline hierarhia v\u00f5imaldab meil ka paindlikumalt korraldada teenuseid haldamise mugavuse huvides. N\u00e4iteks k\u00f5ik web, kuna see on v\u00e4ga suur serverite r\u00fchm, jagame mitmeks v\u00e4iksemaks grupiks, mida pildil on n\u00e4idatud kui group1, group2.<\/p>\n<p><\/p>\n<p>Eemaldades liigsed jooned, saame iga meie pildi s\u00f5lme j\u00e4\u00e4dvustada mitmekihilise kujul: <strong>group1.web.front<\/strong>, <strong>api.music.front<\/strong>, <strong>user-cache.cache<\/strong>.<\/p>\n<p><\/p>\n<p>Nii j\u00f5uame m\u00f5isteteni \u201ehierarhiline j\u00e4rjekord\u201d. Sellel on nimi, nagu \u201egroup1.web.front\u201d. Talle m\u00e4\u00e4ratakse ressursikvoot ja kasutaja\u00f5igused. DevOps inimesel on \u00f5igus saata teenuse j\u00e4rjekorda ja selline t\u00f6\u00f6taja v\u00f5ib j\u00e4rjekorras midagi k\u00e4ivitada, seevastu OpsDev\u2019ile antakse administraatori\u00f5igused, mis annab talle v\u00f5imaluse j\u00e4rjekorda hallata, seal inimesi m\u00e4\u00e4rata, nendele \u00f5igusi anda jne. Selle j\u00e4rjekorras k\u00e4ivitatavad teenused t\u00f6\u00f6tavad j\u00e4rjekorra kvoodi piirides. Kui j\u00e4rjekorra arvutite kvoot ei piisa k\u00f5igi teenuste samaaegseks k\u00e4ivitamiseks, k\u00e4ivitatakse need j\u00e4rjestikku, moodustades sellega tegeliku j\u00e4rjekorra. <\/p>\n<p><\/p>\n<p>Vaadakem teenuseid l\u00e4hemalt. Igal teenusel on t\u00e4ielik nimi, mis alati sisaldab j\u00e4rjekorra nime. Seega, web esifront teenusel on nimi <strong>ok-web.group1.web.front<\/strong>. Ja rakenduste serveriteenusel, millega ta \u00fchendust v\u00f5tab, saab olema nimeks <strong>ok-app.group1.web.front<\/strong>. Igal teenusel on manifest, kus on kirjas kogu vajalik teave paigutamiseks konkreetsetesse masinatesse: kui palju ressursse see \u00fclesanne tarbib, milline konfiguratsioon on vajalik, kui palju koopiaid peab olema, teenuse t\u00f5rke t\u00f6\u00f6tlemise omadused. Ja p\u00e4rast teenuse paigutamist otse masinatesse tekivad selle eksemplarid. Need on samuti unikaalselt nimetatud \u2014 eksemplari numbri ja teenuse nimega: <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 teada.<\/p>\n<p><\/p>\n<p>Ja n\u00fc\u00fcd tutvume l\u00e4hemalt, mida need eksemplarid tegelikult teevad: \u00fclesannete t\u00e4itmisega.<\/p>\n<p><\/p>\n<h2 id=\"klassy-izolyacii-zadach\">\u00dclesannete isolatsiooniklassid<\/h2>\n<p><\/p>\n<p>K\u00f5ik \u00fclesanded OK-s (ja ilmselt igal pool mujal) saab jagada r\u00fchmadesse:<\/p>\n<p><\/p>\n<ul>\n<li><strong>L\u00fchikese latentsusega \u00fclesanded \u2014 prod<\/strong>. Selliste \u00fclesannete ja teenuste jaoks on vastuse latentsus (latency) v\u00e4ga oluline, kui kiiresti iga p\u00e4ring s\u00fcsteemi poolt t\u00f6\u00f6deldakse. N\u00e4ited \u00fclesannetest: veebifrontid, vahem\u00e4lud, rakenduste serverid, OLTP ladustamisruumid jne.<\/li>\n<li><strong>Arvutusalased \u00fclesanded \u2014 batch<\/strong>. Siin pole iga konkreetse p\u00e4ringu t\u00f6\u00f6tlemise kiirus oluline. Neile on oluline, kui palju arvutusi see \u00fclesanne teatud (suure) ajavahemiku jooksul teeb (throughput). Sellisteks on igasugused MapReduce \u00fclesanded, Hadoop, masin\u00f5pe, statistika.<\/li>\n<li><strong>Taustal t\u00f6\u00f6tavad \u00fclesanded \u2014 idle<\/strong>. Selliste \u00fclesannete jaoks ei ole latentsus ega l\u00e4bi viidud t\u00f6\u00f6tlemise kiirus eriti olulised. Siia kuuluvad erinevad testid, migratsioonid, \u00fcmberarvutamised, andmete konverteerimised \u00fchest formaadist teise. \u00dchelt poolt sarnanevad nad arvutuslikele, teisalt \u2014 me ei pea v\u00e4ga oluliseks, kui kiiresti need l\u00f5pule j\u00f5uavad. <\/li>\n<\/ul>\n<p><\/p>\n<p>Vaatame, kuidas sellised \u00fclesanded tarbivad ressursse, n\u00e4iteks keskprotsessorit.<\/p>\n<p><\/p>\n<p><strong>L\u00fchikese latentsusega \u00fclesanded.<\/strong> Sellise \u00fclesande CPU tarbimise muster sarnaneb j\u00e4rgmisele:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/1ed82c0df76325eb30056ad9af86e86e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kasutajalt saabub p\u00e4ring, \u00fclesanne hakkab kasutama k\u00f5ik saadaval olevaid CPU tuumasid, t\u00f6\u00f6tleb, tagastab vastuse, ootab j\u00e4rgmist p\u00e4ringut ja seisab. J\u00e4rgnev p\u00e4ring saabus \u2014 uuesti valisime k\u00f5ik, mis oli, arvutasime l\u00e4bi, ootame j\u00e4rgmist.<\/p>\n<p><\/p>\n<p>Tagamaks, et sellise \u00fclesande latentsus oleks minimaalne, peame v\u00f5tma maksimumi selle tarbimistest ja reserveerima vajalikud tuumad minjonile (masinale, mis peab \u00fclesannet t\u00e4itma). Seega 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 tuuma minion-masin, siis saame sellele paigutada t\u00e4pselt neli sellist \u00fclesannet. Eriti m\u00e4rgime, et nende \u00fclesannete keskmine protsessoritarve on sageli v\u00e4ga madal \u2014 mis on ilmne, kuna suure osa ajast on \u00fclesanne ooteolekus ja ei tee midagi.<\/p>\n<p><\/p>\n<p><strong>Arvutamis\u00fclesanded.<\/strong> Neil on mustern\u00e4ide veidi erinev:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/35b37fa1d70a137287cafdbfe3bcfc2e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Selliste \u00fclesannete keskmine protsessoritarve on piisavalt k\u00f5rge. Sageli tahame, et arvutamis\u00fclesanne t\u00e4idetaks teatud ajavahemikus, seega tuleb reserveerida minimaalne protsessorite arv, mis on vajalik, et kogu arvutus l\u00f5petataks vastuv\u00f5etava ajaga. Tema 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 paigalda see minioni, kus on v\u00e4hemalt \u00fcks vaba tuum, ja edasi, mis iganes on \u2014 k\u00f5ik l\u00e4heb.\u201d<\/em><\/p>\n<p><\/p>\n<p>Siin on ressursi kasutamise efektiivsus juba oluliselt parem kui l\u00fchikese viivitusega \u00fclesannete puhul. Kuid kasu oleks palju suurem, kui kombineerida m\u00f5lemat t\u00fc\u00fcpi \u00fclesandeid \u00fchel minion-masinal ja jagada selle ressursse jooksvalt. Kui l\u00fchikese viivitusega \u00fclesanne vajab protsessorit \u2014 saab ta selle kohe, ja kui ressursid ei ole enam vajalikud \u2014 edastatakse need arvutamis\u00fclesandele, st midagi sellist:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" 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>K\u00e4ime esmalt l\u00e4bi prod ja tema alloc: cpu = 4. Me peame reserveerima neli tuuma. Docker run'is saab seda teha kahes viisist: <\/p>\n<p><\/p>\n<ul>\n<li>Kasutades valikut <code>--cpuset=1-4<\/code>, st m\u00e4\u00e4rata \u00fclesandele neli kindlat tuuma masinal.<\/li>\n<li>Kasutage <code>--cpuquota=400_000 --cpuperiod=100_000<\/code>, m\u00e4\u00e4rata kvota protsessoriaja, st n\u00e4idata, et iga 100 ms reaalaega \u00fclesanne tarbib mitte rohkem kui 400 ms protsessoriaega. Saame samad neli tuuma. <\/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\u00e4lud t\u00f6\u00f6tavad maksimaalselt efektiivselt. Sellel on ka tagasil\u00f6\u00f6ke: me peame v\u00f5tma \u00fclesande jagada arvutusi masin mittekoormatud tuumade vahel OS-i asemel, mis on \u00fcsna mitmekesine \u00fclesanne, eriti kui p\u00fc\u00fcame selles masinas k\u00e4itada partii\u00fclesandeid. Testid n\u00e4itasid, et siin sobib paremini kvota variant: sel juhul on operatsioonis\u00fcsteemil rohkem vabadust \u00fclesande t\u00e4itmiseks tuuma valimisel hetkel ja protsessori aeg jaotub efektiivsemalt.<\/p>\n<p><\/p>\n<p>Selgitame, kuidas Dockeris alustada minimaalset tuumade reservi. Kvota partii\u00fclesannete jaoks ei ole enam rakendatav, sest maksimumi piiramine ei ole vajalik, piisab vaid miinimumi tagamisest. Ja siia sobib h\u00e4sti valik <code>docker run --cpushares<\/code>.<\/p>\n<p><\/p>\n<p>Oleme kokku leppinud, et kui partii n\u00f5uab garantii \u00fchele tuumale, siis me m\u00e4\u00e4rame <code>--cpushares=1024<\/code>, ja kui minimaalselt kahel tuumal, siis m\u00e4\u00e4rame <code>--cpushares=2048<\/code>. Protsessori aktsiad ei sega protsessori aja jaotust, kuni aega piisab. Nii et kui prod ei kasuta hetkel k\u00f5iki nelja tuuma \u2014 ei ole midagi, mis piiraks partii\u00fclesandeid, ja need saavad kasutada t\u00e4iendavat protsessori aega. Kuid protsessori puuduse korral, kui prod on tarbinud k\u00f5ik neli tuuma ja j\u00f5udnud kvotani \u2014 \u00fclej\u00e4\u00e4nud protsessori aeg jagatakse proportsionaalselt cpushares, st kolme vaba tuuma korral saab \u00fcks \u00fclesanne 1024 cpushares ja \u00fclej\u00e4\u00e4nud kaks \u2014 2048 cpushares.<\/p>\n<p><\/p>\n<p>Kuid kvota ja aktsiate kasutamine ei piisa. Peame tagama, et l\u00fchikese latentsuse \u00fclesanne saaks prioriteedi partii\u00fclesande ees protsessori aja jaotamisel. Ilma sellise prioriseerimiseta v\u00f5tab partii\u00fclesanne kogu protsessori aja hetkel, kui see on vajalik prod-ile. Docker runis ei ole mingit konteinerite prioriseerimise valikut, kuid CPU planeerija poliitikad Linuxis tulevad appi. Nendest saab l\u00e4hemalt lugeda <noindex><a rel=\"nofollow\" href=\"http:\/\/man7.org\/linux\/man-pages\/man2\/sched_setscheduler.2.html\">siit<\/a><\/noindex>, kuid k\u00e4esolevas artiklis k\u00e4sitleme neid l\u00fchidalt:<\/p>\n<p><\/p>\n<ul>\n<li><strong>SCHED_OTHER<\/strong><br \/>\nSaavad vaikimisi k\u00f5ik tavalised kasutaja protsessid Linuxi masinas.<\/li>\n<li><strong>SCHED_BATCH<\/strong><br \/>\nM\u00f5eldud ressursimahukate protsesside jaoks. Kui \u00fclesanne protsessorisse suunatakse, kehtestatakse nn aktiveerimise trahv: selline \u00fclesanne saab t\u00f5en\u00e4oliselt v\u00e4hem protsessorit, kui seda kasutab \u00fclesanne SCHED_OTHER.<\/li>\n<li><strong>SCHED_IDLE<\/strong><br \/>\nTaustprotsess v\u00e4ga madala prioriteediga, isegi madalam kui nice \u201319. Me kasutame oma avatud l\u00e4htekoodiga raamatukogu. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/odnoklassniki\/one-nio\">one-nio<\/a><\/noindex>, et seadistada 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-s, 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>Kokkuv\u00f5tlikult koondame k\u00f5ik meie isolatsiooni tasemed \u00fchte tabelisse, et oleks selgem:<\/p>\n<p><\/p>\n<p>Isolatsiooni klass<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 Docker eemaldab selle capability konteineri k\u00e4ivitamisel vaikimisi.<\/p>\n<p><\/p>\n<p>Kuid \u00fclesanded tarbivad mitte ainult protsessorit, vaid ka liiklust, mis m\u00f5jutab v\u00f5rgu\u00fclesande viivitust rohkem kui vale protsessorite jaotamine. Seet\u00f5ttu tahame loomulikult saada sarnase pildi ka liiklusest. See t\u00e4hendab, et kui prod-\u00fclesanne saadab m\u00f5ningaid pakette v\u00f5rku, kvoteerime maksimaalse kiirus (valem <em>alloc: lan=[*,500mbps)<\/em> ), millega prod seda teha saab. Ja batch jaoks garanteerime ainult minimaalset l\u00e4bilaskvust, kuid ei piira maksimaalset (valem <em>alloc: lan=[10Mbps,*)<\/em> ) Sel juhul peab prod liiklus olema k\u00f5rgema prioriteediga v\u00f5rreldes batch-\u00fclesannetega.<br \/>\nSiin pole Dockeril mingeid primitiive, mida me saaksime kasutada. Kuid meie abiks tuleb <noindex><a rel=\"nofollow\" href=\"http:\/\/lartc.org\/\">Linuxi liikluseregulatsioon<\/a><\/noindex>. Oleme vajalikku tulemust saavutanud disipliini 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\u00f5rgema prioriteediga prod ja madalama prioriteediga batch\/idle. L\u00f5ppkokkuv\u00f5ttes on saateliikluse 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 tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/3f52a968118b6021bd0c920af17a00c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>siin 1:0 \u2014 &#171;juure qdisc&#187; hsfc distsipliin; 1:1 \u2014 alamklass hsfc, millel on 8 Gbit\/s \u00fchine ribalaiuse piirang, kuhu kuuluvad k\u00f5igi konteinerite alamklassid; 1:2 \u2014 alamklass hsfc, mis on \u00fchine k\u00f5igile batch ja idle \u00fclesannetele &#171;d\u00fcnaamilise&#187; piiranguga, millest allpool. \u00dclej\u00e4\u00e4nud alamklassid hsfc on eraldiseisvad klassid, mis on m\u00f5eldud aktiivselt t\u00f6\u00f6tavatele prod-konteineritele ja mille piirangud vastavad nende manifestidele \u2014 450 ja 400 Mbit\/s. Iga hsfc klassile on m\u00e4\u00e4ratud qdisc j\u00e4rjekord fq v\u00f5i fq_codel, s\u00f5ltuvalt linuxi tuumaversioonist, et v\u00e4ltida pakettide kadumist liikluspiikide ajal. <\/p>\n<p><\/p>\n<p>Tavaliselt teenivad tc distsipliinid ainult v\u00e4ljamineva liikluse prioriseerimist. Kuid me tahame prioriseerida ka sissetulevat liiklust \u2014 nimelt v\u00f5ib m\u00f5ni batch-\u00fclesanne h\u00f5ivata kogu sissetuleva kanali, saades n\u00e4iteks suurt paketti sissetulevaid andmeid map&amp;reduce jaoks. Selle jaoks kasutame moodulit <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/350023\/tc-ingress-policing-and-ifb-mirroring\">ifb<\/a><\/noindex>, mis loob virtuaalse liidese ifbX iga v\u00f5rku liidese jaoks ja suunab sissetuleva liikluse liideselt v\u00e4ljaminevaks ifbX-le. Edasi t\u00f6\u00f6tavad k\u00f5ik need samad distsipliinid v\u00e4ljamineva liikluse juhtimiseks, 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 tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/967da9c0637cc70ba195af781db18adf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Katsed on n\u00e4idanud, et parimad tulemused hsfc saavutatakse siis, kui klass 1:2 prioriteedita batch\/idle liiklust piiratakse masinatel-minionidel mitte rohkem kui teatud vabale ribalaiusele. Vastasel juhul m\u00f5jutab prioriteedita liiklus liiga palju prod-\u00fclesannete latentsust. Praeguse vabade ribalaiuste suuruse m\u00e4\u00e4rab miniond iga sekundi tagant, m\u00f5\u00f5tes masinatega seotud prod-\u00fclesannete keskmist liikluskasutust <img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/9d6f38110d3b1693afe222b01430b9bb.jpg\" style=\"display:block;margin: 0 auto;\" \/> ja lahutades selle v\u00f5rgu liidese ribalaiusest <img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/d5608ec4c58e44b8571ab0b1d0cc7701.jpg\" style=\"display:block;margin: 0 auto;\" \/> v\u00e4ikese varuga, st.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/fb01347c2224bd5bbd82169861eeb7e4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ribalaiused m\u00e4\u00e4ratakse s\u00f5ltumatult sissetulevale ja v\u00e4ljaminevale liiklusele. Ja vastavalt uutele v\u00e4\u00e4rtustele miniond konfigureerib 1:2 prioriteedita klassi limiidi \u00fcmber.<\/p>\n<p><\/p>\n<p>Seega oleme saavutanud k\u00f5ik kolm isolatsiooniklassi: prod, batch ja idle. Need klassid m\u00f5jutavad tugevalt \u00fclesannete t\u00e4itmise omadusi. Seet\u00f5ttu otsustasime, et see tunnus tuleb asetada hierarhia tippu, et vaadates hierarhilise j\u00e4rjekorra nime oleks kohe selge, millega me tegeleme: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" 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> frontid asetatakse siis hierarhiatesse prod alla. N\u00e4iteks asetame batch alla teenuse <strong>music catalog<\/strong>, mis perioodiliselt koostab lugude katalooge komplektist \u00fcleslaetud \"Odnoklassniki\" mp3-failidest. Ja n\u00e4itena idle teenusest v\u00f5ib tuua <strong>muusikamuundur<\/strong>, mis normaliseerib muusika helitaseme.<\/p>\n<p><\/p>\n<p>Eemaldades taaskord liigsed read, saame kirjutada oma teenuste nimed nutikamalt, lisades teenuse t\u00e4isnime l\u00f5ppu \u00fclesande isolatsiooni klassi: <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 ta t\u00e4idab, vaid ka tema isolatsiooni klassi, mis n\u00e4itab tema kriitilisust jne.<\/p>\n<p><\/p>\n<p>K\u00f5ik on suurep\u00e4rane, kuid on \u00fcks kibedat t\u00f5de. \u00dckski \u00fclesandeid, mis t\u00f6\u00f6tavad samas masinas, ei saa t\u00e4ielikult isoleerida.<\/p>\n<p><\/p>\n<p>Mida me oleme suutnud saavutada: kui batch tarbib intensiivselt <strong>seda<\/strong> protsessori ressursse, siis Linuxi sisseehitatud protsessoriplaneerija t\u00e4idab oma \u00fclesande v\u00e4ga h\u00e4sti ja sellel pole praktiliselt mingit m\u00f5ju prod-\u00fclesandele. Kuid kui see batch-\u00fclesanne hakkab aktiivselt t\u00f6\u00f6tama m\u00e4luga, siis m\u00f5ju on juba tajutav. See juhtub seet\u00f5ttu, et prod-\u00fclesande puhul \"voolavad\" protsessorikandjad m\u00e4lust v\u00e4lja \u2014 l\u00f5pptulemusena kasvavad vahepead ja protsessor t\u00f6\u00f6tleb prod-\u00fclesannet aeglasemalt. T\u00fc\u00fcpiline batch-\u00fclesanne v\u00f5ib suurendada meie t\u00fc\u00fcpilise prod-konteineri latentsust 10%.<\/p>\n<p><\/p>\n<p>Liiklust on veelgi raskem isoleerida, kuna t\u00e4nap\u00e4evastes v\u00f5rgukaartides on paigutatud pakettide sisemine j\u00e4rjekord. Kui pakett onde batch-\u00fclesandest on sinna sattunud esimesena, siis tema edastamine kaabli kaudu toimub ka esimesena, ja siin ei ole midagi teha.<\/p>\n<p><\/p>\n<p>Lisaks oleme seni suutnud lahendada ainult TCP-liikluse prioriseerimise \u00fclesande: UDP puhul ei toimi l\u00e4henemine hsfc. Ja isegi TCP-liikluse puhul, kui batch-\u00fclesanne genereerib palju liiklust, annab see samuti umbes 10% suurenemise prod-\u00fclesande latentsuses.<\/p>\n<p><\/p>\n<h2 id=\"otkazoustoychivost\">Talitluskatkestustunne<\/h2>\n<p><\/p>\n<p>\u00dcks eesm\u00e4rke one-cloud'i arendamisel oli parendada Odnoklassniki' s t\u00f5rkele vastu pidavust. Seega soovin n\u00fc\u00fcd \u00fcksikasjalikumalt uurida v\u00f5imalikke t\u00f5rke- ja avariis\u00fcsteeme. Alustame lihtsast stsenaariumist \u2014 konteineri t\u00f5rkest. <\/p>\n<p><\/p>\n<p>Konteiner v\u00f5ib eba\u00f5nnestuda mitmel viisil. See v\u00f5ib olla mingi eksperiment, t\u00f5rge v\u00f5i vigane manifest, mille t\u00f5ttu prod-\u00fclesanne hakkab tarbima rohkem ressursse kui manifestis ette n\u00e4htud. Meil oli juhtum: arendaja rakendas \u00fche keerulise algoritmi, tegi seda mitmel korral \u00fcmber, segas end nii \u00e4ra, et l\u00f5puks hakkas \u00fclesanne \u00fcsna keeruliselt l\u00f5ppema. Kuna prod-\u00fclesanne on prioriteetsem kui k\u00f5ik teised samadel minionitel, hakkas see tarbima k\u00f5iki saadaval olevaid CPU ressursse. Sellises olukorras aitas isolatsioon, t\u00e4psemalt CPU ajakvoot. Kui \u00fclesandele on m\u00e4\u00e4ratud kvoot, ei tarbita rohkem. Seet\u00f5ttu ei m\u00e4rganud batch- ja teised prod-\u00fclesanded, mis t\u00f6\u00f6tasid samal masinal, midagi. <\/p>\n<p><\/p>\n<p>Teine v\u00f5imalik probleem on konteineri kokkuvarisemine. Ja siin aitavad meid restart-poliitikad, mida k\u00f5ik tunnevad, Docker ise hoolitseb selle eest kenasti. Peaaegu k\u00f5ik prod-\u00fclesanded omavad restart-poliitikat always. M\u00f5nikord kasutame on_failure batch-\u00fclesannete v\u00f5i prod-konteinerite silumiseks.<\/p>\n<p><\/p>\n<p>Aga mida teha, kui terve minion on mittesaadav?<\/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-aadressidega. <\/p>\n<p><\/p>\n<p>Saame m\u00e4\u00e4rata konteineritele sama IP-aadressi nagu masinatel, millel need konteinerid t\u00f6\u00f6tavad. Seega, kui konteiner k\u00e4ivitatakse teisel masinal, muutub selle IP-aadress ning k\u00f5ik kliendid peavad m\u00f5istma, et konteiner on kolinud, n\u00fc\u00fcd tuleb minna uuele aadressile, mis n\u00f5uab eraldi teenust Service Discovery. <\/p>\n<p><\/p>\n<p>Service Discovery on mugav. Turul on palju lahendusi erineva t\u00f5rkekindluse tasemega teenuste registri korraldamiseks. Sageli sisaldavad sellised lahendused koormuse tasakaalustusloogika ja t\u00e4iendava konfiguratsiooni hoidmise KV-hoidlas jne.<br \/>\nKuid sooviksime l\u00e4bi saada ilma eraldi registri rakendamata, sest see t\u00e4hendaks kriitilise s\u00fcsteemi sisseseadmist, mida kasutavad k\u00f5ik teenused tootmises. Seega on see potentsiaalne t\u00f5rkepunkt ning tuleb valida v\u00f5i v\u00e4lja t\u00f6\u00f6tada v\u00e4ga t\u00f5rkekindel lahendus, mis on ilmselgelt v\u00e4ga keeruline, aegan\u00f5udev ja kallis. <\/p>\n<p><\/p>\n<p>Ja veel \u00fcks suur puudus: et meie vana infrastruktuur t\u00f6\u00f6taks koos uuega, oleks pidanud \u00fcmber kirjutama k\u00f5ik \u00fclesanded millelegi, mis kasutab Service Discovery s\u00fcsteemi. T\u00f6\u00f6 on \u00c4\u00c4RMUSLIKULT palju, ja kohati isegi v\u00f5imatu, kui jutt on madala tasemega seadmetest, mis t\u00f6\u00f6tavad ops\u00fcsteemi kerneli tasemel v\u00f5i otse riistvara k\u00fcljes. Selle funktsionaalsuse rakendamine tuntud lahenduste mustrite abil, nagu n\u00e4iteks <noindex><a rel=\"nofollow\" href=\"https:\/\/linkerd.io\">side-car<\/a><\/noindex> t\u00e4hendaks kohati t\u00e4iendavat koormust, kohati \u2014 kasutamise keerukuse suurenemist ja t\u00e4iendavaid t\u00f5rke stsenaariume. Meile ei meeldinud keerukuse suurendamine, seet\u00f5ttu otsustasime muuta Service Discovery kasutamise valikuliseks. <\/p>\n<p><\/p>\n<p>one-cloudis j\u00e4rgneb IP konteinerile, st. igal \u00fclesande eksemplaril on oma IP-aadress. See aadress on \"staatiline\": see kinnitatakse iga eksemplari puhul teenuse esmakordsel pilve saatmisel. Kui teenuse elu jooksul on olnud erinev arv eksemplare, siis l\u00f5puks kinnitatakse temaga nii palju IP-aadresse, kui eksemplare kunagi kokku on olnud.<\/p>\n<p><\/p>\n<p>Hiljem need aadressid ei muutu: need on antud ainult \u00fcks kord ja p\u00fcsivad terve teenuse elu jooksul produktsioonis. IP-aadressid j\u00e4rgivad konteinerite v\u00f5rku. Kui konteiner liigub teise minioni, siis j\u00e4rgneb aadress ka temale. <\/p>\n<p><\/p>\n<p>Seega muutub teenuse nime ja selle IP-aadresside loendi seos v\u00e4ga harva. Kui vaadata veelkord teenuse eksemplaride nimesid, mida me artikli alguses mainisime (<strong>1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, \u2026<\/strong>), siis m\u00e4rkame, et need meenutavad DNS-is kasutatavaid FQDN-e. See on t\u00f5si, teenuste eksemplaride nimede kuvamiseks nende IP-aadressides kasutame DNS-protokolli. Veelgi enam, see DNS tagastab k\u00f5ik broneeritud IP-aadressid k\u00f5ikidele konteineritele \u2014 nii t\u00f6\u00f6tavatele kui ka peatatud (kui meil on n\u00e4iteks kolm koopiat, kuid viis aadressi on broneeritud \u2014 k\u00f5ik viis aadressi tagastatakse). Klient, kes on selle teabe saanud, proovib luua \u00fchendust k\u00f5igi viie koopiaga \u2014 ja m\u00e4\u00e4rab seega need, mis t\u00f6\u00f6tavad. See k\u00e4ttesaadavuse m\u00e4\u00e4ramise variant on oluliselt usaldusv\u00e4\u00e4rsem, kuna see ei h\u00f5lma ei DNS-i ega teenuse avastamist, seega ei ole probleemi teabe ajakohasuse ja nende s\u00fcsteemide t\u00f5rketaluvusega. Veelgi enam, kriitiliste teenuste puhul, mis s\u00f5ltuvad kogu portaali t\u00f6\u00f6kindlusest, ei pea me DNS-i kasutama, vaid saame lihtsalt konfigureerida IP-aadresid.<\/p>\n<p><\/p>\n<p>Sellise IP-aadresside \u00fclekande rakendamine konteinerite vahel v\u00f5ib olla keeruline \u2014 ja peatume selle toimimise juures j\u00e4rgmise n\u00e4ite abil:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/faf99c2609a57daa1bdc193cb0f4cb31.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Oletame, et one-cloudi meister annab k\u00e4su minion M1-l k\u00e4ivitada <strong>1.ok-web.group1.web.front.prod<\/strong> aadressiga 1.1.1.1. Minionis t\u00f6\u00f6tab <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Bird_Internet_routing_daemon\">BIRD<\/a><\/noindex>, mis kuulutab selle aadressi spetsiaalsetele serveritele <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Route_reflector\">route reflector<\/a><\/noindex>. Viimastel on BGP-seanss v\u00f5rguseadmest, kuhu transleeritakse marsruut aadressile 1.1.1.1 M1-l. M1 mars\u00fcreerib paketid konteinerisse juba Linuxi vahenditega. Route reflector'e servereid on kolm, kuna see on one-cloudi infrastruktuuri v\u00e4ga kriitiline osa \u2014 ilma nendeta ei t\u00f6\u00f6ta one-cloudis v\u00f5rk. Paigutame need erinevatesse rack'idesse, v\u00f5imaluse korral erinevatesse andmekeskuse saalidesse, et v\u00e4hendada k\u00f5igi kolme samaaegse rikke t\u00f5en\u00e4osust.<\/p>\n<p><\/p>\n<p>Kujutame n\u00fc\u00fcd ette, et side one-cloudi meistri ja minion M1 vahel on kadunud. One-cloudi meister tegutseb n\u00fc\u00fcd oletuse p\u00f5hjal, et M1 on t\u00e4ielikult eba\u00f5nnestunud. See t\u00e4hendab, et ta annab k\u00e4su minion M2-l k\u00e4ivitada <strong>web.group1.web.front.prod<\/strong> sama aadress 1.1.1.1. N\u00fc\u00fcd on meil kaks konfliktset marsruuti v\u00f5rgus aadressile 1.1.1.1: M1-l ja M2-l. Selliste konfliktide lahendamiseks kasutame Multi Exit Discriminatorit, mis m\u00e4\u00e4ratakse BGP-teate kaudu. See number n\u00e4itab kuulutatud marsruudi kaalu. Konfliktide korral valitakse marsruut v\u00e4iksema MED-i v\u00e4\u00e4rtusega. One-cloudi domineerija toetab MED-i konteinerite IP-aadresside lahutamatu osana. Esmakordselt m\u00e4\u00e4ratakse aadress piisavalt suure MED-iga = 1 000 000. Kui toimub selline h\u00e4daolukorra konteineri \u00fcleviimine, v\u00e4hendab domineerija MED-i, ning M2 saab k\u00e4su kuulutada aadress 1.1.1.1 MED-iga = 999 999. Samal ajal j\u00e4\u00e4b M1-l t\u00f6\u00f6tav n\u00e4idis side puudumise t\u00f5ttu ilma, ja selle edasine saatus ei ole meile oluline, kuni side taastub domineerijaga, mil ta peatatakse kui vana dubleerimine.<\/p>\n<p><\/p>\n<h2 id=\"avarii\">H\u00e4dad<\/h2>\n<p><\/p>\n<p>K\u00f5ik andmekeskuste halduss\u00fcsteemid t\u00f6\u00f6tavad alati h\u00e4sti v\u00e4lja v\u00e4ikseid rikkeid. Konteineri v\u00e4ljalangevus on enamikus kohtades norm.<\/p>\n<p><\/p>\n<p>Vaatame, kuidas me t\u00f6\u00f6tleme h\u00e4daolukorda, n\u00e4iteks toitekatkestust \u00fches v\u00f5i enamas andmekeskuse saalis.<\/p>\n<p><\/p>\n<p>Mida t\u00e4hendab avaria andmekeskuse halduss\u00fcsteemile? Esiteks on see massiline samal ajal toimuv mitme masina rike ning halduss\u00fcsteem peab samal ajal migreerima v\u00e4ga palju konteineri. Kuid kui avaria on v\u00e4ga ulatuslik, v\u00f5ib juhtuda nii, et k\u00f5iki \u00fclesandeid ei saa teistele minionidele \u00fcle viia, kuna andmekeskuse ressursi maht langeb alla 100% koormusele. <\/p>\n<p><\/p>\n<p>Sageli kaasnevad h\u00e4dad haldamise kihi rikke ning. See v\u00f5ib juhtuda, kuna selle varustus eba\u00f5nnestub, kuid sagedamini seet\u00f5ttu, et h\u00e4dasid ei testita ning juhtimiskihid kukuvad ise kokku suurenenud koormuse t\u00f5ttu. <\/p>\n<p><\/p>\n<p>Mida selle k\u00f5igega teha?<\/p>\n<p><\/p>\n<p>Massiivsed migreerimised t\u00e4hendavad, et infrastruktuuris tekib suur hulk toiminguid, migreerimisi ja paigutusi. Iga migreerimine v\u00f5ib v\u00f5tta aega, mis on vajalik konteinerite piltide kohaletoimetamiseks ja lahtipakkimiseks minionidel, konteinerite k\u00e4ivitamiseks ja initsialiseerimiseks jne. Seet\u00f5ttu on soovitatav, et olulised \u00fclesanded k\u00e4ivitatakse enne v\u00e4hem olulisi.<\/p>\n<p><\/p>\n<p>Vaadakem uuesti tuttavat teenuste hierarhiat ja proovime otsustada, milliseid \u00fclesandeid tahame esmalt k\u00e4ivitada.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" 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 osalevad otseselt kasutaja p\u00e4ringute t\u00f6\u00f6tlemises, st prod. Me n\u00e4itame seda <strong>paigutamise prioriteedi<\/strong> \u2014 numbreid, mis v\u00f5ivad olla m\u00e4\u00e4ratud j\u00e4rjekorrale. Kui m\u00f5nel j\u00e4rjekorral on k\u00f5rgem prioriteet, paigutatakse selle teenused esimesena.<\/p>\n<p><\/p>\n<p>Prodis m\u00e4\u00e4rame k\u00f5rgemad prioriteedid, 0; batch-l\u00e4henemisel veidi madalam, 100; idle puhul veel madalam, 200. Prioriteedid rakendatakse hierarhiliselt. K\u00f5ikidel madalama taseme \u00fclesannetel on vastav prioriteet. Kui soovime, et prodis k\u00e4ivituksid vahem\u00e4lud enne esipinda, m\u00e4\u00e4rame vahem\u00e4lu prioriteedi = 0 ja esipinna alamj\u00e4rjekorrale = 1. Kui aga soovime, et esipindade seas k\u00e4ivituks esmalt p\u00f5hiv\u00e4rav ja alles seej\u00e4rel muusika front, siis v\u00f5ime viimasel m\u00e4\u00e4rata madalama prioriteedi \u2014 10.<\/p>\n<p><\/p>\n<p>J\u00e4rgmine probleem on ressursside puudus. Nii et meil on suures koguses varustust v\u00e4lja langenud, terveid andmekeskuse saale, ja oleme k\u00e4ivitanud nii palju teenuseid, et n\u00fc\u00fcd ei piisa ressursse k\u00f5igi jaoks. Peame otsustama, milliste \u00fclesannetega ohverdada, et peamised kriitilised teenused t\u00f6\u00f6taksid. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 andmekeskuse tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/1b1ad3da16df6677dd0ba4b038cdd7d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Erinevalt paigutamise prioriteedist ei saa me lihtsalt ohverdada k\u00f5iki batch-\u00fclesandeid, m\u00f5ned neist on portaali t\u00f6\u00f6 jaoks olulised. Seet\u00f5ttu oleme eraldi v\u00e4lja toonud <strong>v\u00e4ljaarvamise prioriteedi<\/strong> \u00fclesanne. Paigutamisel v\u00f5ib k\u00f5rgema prioriteediga \u00fclesanne v\u00e4lja arvata, st peatada madalama prioriteediga \u00fclesande, kui vabu minione enam ei ole. Samuti on madalama prioriteediga \u00fclesanne t\u00f5en\u00e4oliselt ei paigutata, st sellele ei ole enam sobivat minionit piisava vabade ressurssidega.<\/p>\n<p><\/p>\n<p>Meie hierarchias on v\u00e4ga lihtne m\u00e4\u00e4rata selline v\u00e4ljaarvamise prioriteet, et prod- ja batch-\u00fclesanded v\u00e4ljaaravad v\u00f5i peatavad idle-\u00fclesandeid, kuid mitte \u00fcksteist, m\u00e4\u00e4rates idle jaoks prioriteedi, mis on v\u00f5rdne 200. Nagu ka paigutamise prioriteedi puhul, saame kasutada meie hierarhiat, et kirjeldada keerukamaid reegleid. N\u00e4iteks saame m\u00e4\u00e4rata, et muusikafunktsiooniga ohverdame, kui meil ei piisa ressursse peamise veebiportaaliga, m\u00e4\u00e4rates vastavatele s\u00f5lmedele madalama prioriteedi: 10.<\/p>\n<p><\/p>\n<h2 id=\"avarii-dc-celikom\">Andmekeskuse \u00f5nnetused t\u00e4ielikult<\/h2>\n<p><\/p>\n<p>Miks v\u00f5ib kogu andmekeskus eba\u00f5nnestuda? Loodus\u00f5nnetused. Oli hea postitus, kuidas <noindex><a rel=\"nofollow\" href=\"https:\/\/habrahabr.ru\/company\/dataline\/blog\/333578\/\">orkan m\u00f5jutas andmekeskuse t\u00f6\u00f6d<\/a><\/noindex>. Elus v\u00f5ib pidada kodutuks inimeseks, kes \u00fchel p\u00e4eval h\u00e4vitas optika kanaliseerimisse, mist\u00f5ttu kaotas andmekeskus t\u00e4ielikult \u00fchenduse teiste lokaliseerimistega. Rikkumise p\u00f5hjuseks v\u00f5ib olla ka inimfaktor: operaator annab sellise k\u00e4su, et kogu andmekeskus kukub kokku. See v\u00f5ib juhtuda suurte vigade t\u00f5ttu. \u00dcldiselt, andmekeskuste t\u00f5rkeid esineb \u2014 see ei ole haruldane. Meil toimub see paar korda kuus. <\/p>\n<p><\/p>\n<p>Ja see on see, mida me teeme, et keegi #okelama ei postita Twitters.<\/p>\n<p><\/p>\n<p>Esimene strateegia on isoleerimine. Iga instance one-cloud on t\u00e4ielikult isoleeritud ja saab hallata masinate vaid \u00fches andmekeskuses. See t\u00e4hendab, et pilve kaotus vigade v\u00f5i vale k\u00e4su t\u00f5ttu operaatori poolt on kaotuseks vaid \u00fches andmekeskuses. Oleme sellele valmis: meil on varukoopiapoliitika, mille raames rakenduste ja andmete koopiad paigutatakse k\u00f5igis andmekeskustes. Kasutame vigadekindlaid andmebaase ja testime aeg-ajalt t\u00f5rkeid.<br \/>\nKuna meil on t\u00e4na neli andmekeskust, on ka neli eraldi, t\u00e4ielikult isoleeritud one-cloudi eksemplari.<\/p>\n<p><\/p>\n<p>Selline l\u00e4henemine kaitseb mitte ainult f\u00fc\u00fcsiliste t\u00f5rgete eest, vaid v\u00f5ib kaitsta ka operaatori vigade eest.<\/p>\n<p><\/p>\n<p>Ja mida veel saab teha inimfaktoriga? Kui operaator annab pilvele mingi imeliku v\u00f5i potentsiaalselt ohtliku k\u00e4su, v\u00f5ib ta ootamatult pidada lahendama v\u00e4ikese \u00fclesande, et kontrollida, kui h\u00e4sti ta m\u00f5tles. 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 tasemel operatsioonis\u00fcsteem Odnoklassnikites\" src=\"\/wp-content\/uploads\/2020\/06\/f7ee44a77e30612a3cd99a6f7aee3820.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<h2 id=\"itogi\">Summary<\/h2>\n<p><\/p>\n<p>One-cloudi erip\u00e4ra: <\/p>\n<p><\/p>\n<ul>\n<li><strong>Hierarhiline ja silmapaistev teenuste ja konteinerite nimetamise skeem<\/strong>, mis v\u00f5imaldab v\u00e4ga kiiresti teada saada, mis see \u00fclesanne on, millega see seondub ja kuidas see t\u00f6\u00f6tab ja kes on selle eest vastutav. <\/li>\n<li>Kasutame oma <strong>tehnika \u00fchildamise prod- ja batch-<\/strong>\u00fclesannete peal minionidel, et suurendada masinate \u00fchisarendamise t\u00f5husust. Cpuseti asemel kasutame CPU kvoote, aktsiaid, CPU ajajuhtimise poliitikaid ja Linuxi QoS-i.<\/li>\n<li>Konteinereid, mis t\u00f6\u00f6tavad \u00fchel masinal, ei suutnud t\u00e4ielikult isoleerida, kuid nende omavaheline m\u00f5ju j\u00e4\u00e4b 20% piiresse.<\/li>\n<li>Teenuste korraldamine hierarhias aitab automaatse avarii likvideerimise korral <strong>paigutamise ja k\u00f5rvalduste prioriteetide abil<\/strong>.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"chavo\">KKK<\/h2>\n<p><\/p>\n<p>Miks me ei valinud valmislahendust.<\/p>\n<p><\/p>\n<ul>\n<li>Erinevad t\u00f6\u00f6\u00fclesannete isoleerimise klassid n\u00f5uavad erinevat loogikat minionide paigutamisel. Kui tootmisseotud \u00fclesandeid saab paigutada lihtsalt ressursside reserveerimise kaudu, tuleb batch ja idle \u00fclesandeid paigutada, j\u00e4lgides minionide masinatel tegelikku ressursside kasutust. <\/li>\n<li>Tegemist on \u00fclesannete tarbitavate ressursside arvestamise vajadusega, nagu: \n<ul>\n<li>v\u00f5rgu l\u00e4bilaskev\u00f5ime;<\/li>\n<li>ketaste t\u00fc\u00fcbid ja \u201espindlid\u201c.<\/li>\n<\/ul>\n<\/li>\n<li>Teenuste prioriteetide m\u00e4\u00e4ramise vajadus h\u00e4daolukordade likvideerimise puhul, meeskondade \u00f5iguste ja kvotade m\u00e4\u00e4ramine ressurssidele, mida lahendatakse one-cloudis hierarhiliste j\u00e4rjekordade abil.<\/li>\n<li>Vajadus omada inimlikku nimetust konteineritele, et v\u00e4hendada reageerimisaega h\u00e4daolukordadele ja intsidentidele.<\/li>\n<li>\u00dcheainsa ja ulatusliku Service Discovery rakendamise v\u00f5imatus; vajadus koos eksisteerida pikalt raudvarale paigutatud \u00fclesannetega - see lahendatakse konteinerite j\u00e4litamise kaudu \u201estaatiliste\u201c IP-aadresside abil ja seel\u00e4bi ainulaadne integreerimine suure v\u00f5rguinfrastruktuuriga.<\/li>\n<\/ul>\n<p><\/p>\n<p>K\u00f5ik need funktsioonid n\u00f5uaksid olemasolevate lahenduste p\u00f5hjalikku \u00fcmbertegemist ning hinnates t\u00f6\u00f6mahtu j\u00f5udsime arusaamale, et saame v\u00e4lja t\u00f6\u00f6tada oma lahenduse ligikaudu samade t\u00f6\u00f6j\u00f5uressurssidega. Kuid meie lahendus on oluliselt lihtsam k\u00e4itada ja arendada - selles ei ole tarbetuid abstraktsioone, mis toetavad meile mittevajalikke funktsioone. <\/p>\n<p><\/p>\n<p>Neile, kes loevad viimaseid ridu - 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 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0410\u043b\u043e\u0445\u0430, \u043f\u0438\u043f\u043b!\" \/>\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) 5.0.1.1\" \/>\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!\" \/>\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 - andmekeskuse taseme OS Odnoklassnikutes | ProHoster","description":"Aloha, rahvas!","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!","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}