{"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\/sl\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","title":{"rendered":"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/fa983acacec59ff2d4ed098f87223971.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Aloha, ljudje! Moje ime je Oleg Anastasyev, delam v Odnoklassnikih v ekipi Platforme. Poleg mene pa v Odnoklassnikih dela \u0161e kup strojne opreme. Imamo \u0161tiri podatkovne centre, v njih pribli\u017eno 500 omar, kjer se nahaja ve\u010d kot 8 tiso\u010d stre\u017enikov. V dolo\u010denem trenutku smo spoznali, da nam uvedba novega sistema upravljanja omogo\u010da u\u010dinkovitej\u0161o obremenitev opreme, poenostavitev upravljanja dostopov, avtomatizacijo (ponovne) dodelitve ra\u010dunalni\u0161kih virov, pospe\u0161evanje zagonov novih storitev in hitrej\u0161e odzive na obse\u017ene okvare. <\/p>\n<p><\/p>\n<p>Kaj smo torej dosegli? <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Poleg mene in kupa strojne opreme so tukaj tudi ljudje, ki delajo s to opremo: in\u017eenirji, ki so neposredno v podatkovnih centrih; omre\u017eni in\u017eenirji, ki nastavljajo omre\u017eno infrastrukturo; administratorji ali SRE, ki zagotavljajo odpornost infrastrukture; ter ekipe razvijalcev, od katerih vsaka odgovarja za del funkcij portala. Programska oprema, ki jo ustvarjajo, deluje nekako tako:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/592fd0acfa7322eb80fbb85601a92918.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Zahteve uporabnikov prihajajo tako na fronte glavnega portala <noindex><a rel=\"nofollow\" href=\"http:\/\/www.ok.ru\/\">www.ok.ru<\/a><\/noindex>, kot tudi na druge, na primer na fronte API za glasbo. Te za obdelavo poslovne logike kli\u010dejo aplikacijski stre\u017enik, ki ob obdelavi zahteve kli\u010de potrebne specializirane mikroservise \u2014 one-graph (graf socialnih povezav), user-cache (predpomnilnik uporabni\u0161kih profilov) in tako naprej.<\/p>\n<p><\/p>\n<p>Vsaka od teh storitev je name\u0161\u010dena na ve\u010d strojih, vsaka ima odgovorne razvijalce, ki so odgovorni za delovanje modulov, njihovo delovanje in tehnolo\u0161ki razvoj. Vse te storitve delujejo na fizi\u010dnih stre\u017enikih, do nedavnega pa smo izvajali natan\u010dno eno nalogo na en stre\u017enik, torej je bil specializiran za dolo\u010deno nalogo.<\/p>\n<p><\/p>\n<p>Zakaj tako? Ta pristop je imel ve\u010d prednosti:<\/p>\n<p><\/p>\n<ul>\n<li>Poenostavi <strong>masovno upravljanje<\/strong>. Recimo, da naloga potrebuje dolo\u010dene knji\u017enice, dolo\u010dene nastavitve. Potem je stre\u017enik dodeljen to\u010dno eni dolo\u010deni skupini, opisuje se politika cfengine za to skupino (ali je \u017ee opisana), in ta konfiguracija se centralno in samodejno raz\u0161iri na vse stre\u017enike te skupine.<\/li>\n<li>Poenostavi <strong>diagnozo<\/strong>. Predpostavimo, da opazite pove\u010dano obremenitev centralnega procesorja in se zavedate, da je to obremenitev lahko povzro\u010dila le naloga, ki te\u010de na tem fizi\u010dnem procesorju. Iskanje krivca se kon\u010da zelo hitro.<\/li>\n<li>Poenostavi <strong>nadzor<\/strong>. \u010ce je s stre\u017enikom kaj narobe, monitor o tem obve\u0161\u010da in to\u010dno veste, kdo je kriv.<\/li>\n<\/ul>\n<p><\/p>\n<p>Storitvi, ki se sestavlja iz ve\u010d replik, je dodeljenih ve\u010d stre\u017enikov \u2014 po enem za vsak. Tako je dodelitev ra\u010dunalni\u0161kih virov za storitev zelo preprosta: kolikor ima storitev stre\u017enikov, toliko virov lahko maksimalno porabi. 'Preprosta' ni v smislu, da je enostavno uporabiti, temve\u010d da se dodelitev virov dogaja ro\u010dno.<\/p>\n<p><\/p>\n<p>Tak pristop nam je tudi omogo\u010dil, da smo izdelali <strong>specializirane strojne konfiguracije<\/strong> za nalogo, ki se izvaja na tem stre\u017eniku. \u010ce naloga hrani velike koli\u010dine podatkov, uporabljamo 4U stre\u017enik s \u0161asijo za 38 diskov. \u010ce gre za \u010disto ra\u010dunalni\u0161ko nalogo, lahko kupimo cenej\u0161i 1U stre\u017enik. To je u\u010dinkovito z vidika ra\u010dunalni\u0161kih virov. Ta pristop nam tudi omogo\u010da, da pri obremenitvi, ki je primerljiva z eno prijateljsko dru\u017eabno mre\u017eo, uporabljamo \u0161tirikrat manj naprav. <\/p>\n<p><\/p>\n<p>Tak\u0161na u\u010dinkovitost uporabe ra\u010dunalni\u0161kih virov bi morala zagotoviti tudi ekonomsko u\u010dinkovitost, \u010de izhajamo iz predpostavke, da so stre\u017eniki najdra\u017eji. Dolgo \u010dasa je bilo najdra\u017eje prav \u017eelezo, in vlo\u017eili smo veliko truda v zni\u017eevanje cen \u017eeleza, razvijaju\u0107i algoritme za zagotavljanje odpornosti, da bi zmanj\u0161ali zahteve po zanesljivosti opreme. Danes smo pri\u0161li do faze, v kateri cena stre\u017enika \u017ee ni ve\u010d odlo\u010dilna. \u010ce ne upo\u0161tevamo najnovej\u0161e eksotike, konkretna konfiguracija stre\u017enikov v omari ni pomembna. Zdaj imamo drug problem \u2014 cena prostora, ki ga stre\u017enik zaseda v podatkovnem centru, tj. prostora v omari.<\/p>\n<p><\/p>\n<p>Ko smo to spoznali, smo se odlo\u010dili izra\u010dunati, kako u\u010dinkovito uporabljamo omare.<br \/>\nVzeli smo ceno najmo\u010dnej\u0161ega stre\u017enika, ki je ekonomsko upravi\u010den, izra\u010dunali, koliko takih stre\u017enikov lahko postavimo v omarice, koliko nalog bi za njih zagnali na podlagi starega modela \u00bben stre\u017enik = ena naloga\u00ab, in koliko nalog bi bilo sposobnih u\u010dinkovito uporabiti opremo. Izra\u010dunali smo \u2014 jokali smo. Izkazalo se je, da je u\u010dinkovitost uporabe omaric pri nas okoli 11 %. O\u010ditna ugotovitev: potrebno je pove\u010dati u\u010dinkovitost uporabe podatkovnih centrov. Zdi se, da je re\u0161itev o\u010ditna: na enem stre\u017eniku je treba zagnati ve\u010d nalog. Toda tu se pojavljajo te\u017eave. <\/p>\n<p><\/p>\n<p>Masovna konfiguracija se drasti\u010dno zaplete \u2014 zdaj ni mogo\u010de dodeliti stre\u017eniku dolo\u010dene ene skupine. Saj lahko na enem stre\u017eniku poteka ve\u010d nalog razli\u010dnih ekip. Poleg tega je lahko konfiguracija konfliktna za razli\u010dne aplikacije. Diagnostika je tudi ote\u017eena: \u010de opazite pove\u010dano porabo procesorjev ali diskov na stre\u017eniku, ne veste, katera naloga povzro\u010da te\u017eave.<\/p>\n<p><\/p>\n<p>Toda najpomembnej\u0161e je to, da med nalogami, ki potekajo na isti napravi, ni izolacije. Na primer, graf povpre\u010dnega \u010dasa odgovora stre\u017eni\u0161ke naloge pred in po tem, ko smo na istem stre\u017eniku zagnali \u0161e eno, s prvim nepovezano izra\u010dunsko aplikacijo \u2014 \u010das odziva glavne naloge se je mo\u010dno podalj\u0161al.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/c7c07359ae572ca8c84a4c63559e4083.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>O\u010ditno je, da je potrebno naloge zagnati bodisi v kontejnerjih bodisi v virtualnih napravah. Ker se prakti\u010dno vse naloge izvajajo pod eno operacijskim sistemom (Linux) ali so prilagojene zanj, ni potrebno vzdr\u017eevati \u0161tevilnih razli\u010dnih operacijskih sistemov. Posledi\u010dno virtualizacija ni potrebna, zaradi dodatnih stro\u0161kov bo manj u\u010dinkovita od kontejnerizacije.<\/p>\n<p><\/p>\n<p>Kot sve\u017eenje vsebnika za zagon nalog neposredno na stre\u017enikih Docker, hitro pride v po\u0161tev: slike datote\u010dnih sistemov dobro re\u0161ujejo te\u017eave s konflikti v konfiguracijah. Mo\u017enost, da slike sestavimo iz ve\u010d plasti, nam omogo\u010da, da znatno zmanj\u0161amo obseg podatkov, potrebnih za njihovo uvajanje v infrastrukturo, tako da lo\u010dimo skupne dele v lo\u010dene osnovne plasti. Tako bodo osnovne (in najve\u010dje) plasti razmeroma hitro predpomnjene po celotni infrastrukturi, in za prenos \u0161tevilnih razli\u010dnih tipov aplikacij in razli\u010dic bo treba prena\u0161ati le majhne plasti. <\/p>\n<p><\/p>\n<p>Poleg tega nam \u017ee pripravljen registrir in ozna\u010devanje slik v Dockerju daje pripravljene osnovne gradnike za razli\u010dice in dostavo kode v produkcijo.<\/p>\n<p><\/p>\n<p>Docker, tako kot katera koli druga podobna tehnologija, nam omogo\u010da dolo\u010deno raven izolacije vsebnikov kar iz \u0161katle. Na primer, izolacija po pomnilniku \u2014 vsakemu vsebniku je dodeljena omejitev za uporabo pomnilnika naprave, ki je ne more prekora\u010diti. Prav tako lahko izoliramo vsebnike po uporabi CPU. Pri nas pa je bila standardna izolacija premalo. O tem pa kasneje.<\/p>\n<p><\/p>\n<p>Neposredni zagon vsebnikov na stre\u017enikih je le del te\u017eav. Druga te\u017eava je povezava vsebnikov na stre\u017enike. Treba je razumeti, kateri vsebnik lahko postavimo na kateri stre\u017enik. To ni tako enostavna naloga, saj je treba vsebnike na stre\u017enike postaviti \u010dim bolj gosto, ne da bi pri tem zmanj\u0161ali hitrost njihovega delovanja. Tak\u0161no postavljanje je lahko zapleteno tudi z vidika odpornosti. Pogosto \u017eelimo postaviti replike iste storitve v razli\u010dnih omarah ali celo v razli\u010dnih dvoranah podatkovnega centra, da ob okvari omare ali dvorane ne izgubimo vseh replik storitve. <\/p>\n<p><\/p>\n<p>Ro\u010dno razporejanje vsebnikov ni re\u0161itev, ko imate 8.000 stre\u017enikov in 8\u201316.000 vsebnikov. <\/p>\n<p><\/p>\n<p>Poleg tega smo \u017eeleli razvijalcem omogo\u010diti ve\u010djo samostojnost pri razporejanju virov, da bi lahko sami postavili svoje storitve v produkcijo, brez pomo\u010di skrbnika. Pri tem smo \u017eeleli ohraniti nadzor, da kak\u0161na nepomembna storitev ne bi porabila vseh virov na\u0161ih podatkovnih centrov. <\/p>\n<p><\/p>\n<p>O\u010ditno je potreben upravljalski sloj, ki bi se s tem avtomati\u010dno ukvarjal.<\/p>\n<p><\/p>\n<p>Tukaj smo pri\u0161li do preproste in jasne slike, ki jo obo\u017eujejo vsi arhitekti: tri kvadratki. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/079df6e79874ef55b0d967fde3d5feca.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>one-cloud masters \u2014 toleranten klaster, ki je odgovoren za orkestracijo oblaka. Razvijalec po\u0161lje v master manifest, ki vsebuje vse podatke potrebne za postavitev storitve. Master na njeni osnovi daje ukaze izbranim minionom (strojem, namenjenim za zagon kontejnerjev). Na minionih je na\u0161 agent, ki prejme ukaz, poda svoje ukaze Dockru, Dockr pa konfigurira linux kernel za zagon ustreznega kontejnerja. Poleg izvr\u0161evanja ukazov agent nenehno obve\u0161\u010da masterja o spremembah stanja tako miniona kot zagnanih kontejnerjev.<\/p>\n<p><\/p>\n<h2 id=\"raspredelenie-resursov\">Razporeditev virov<\/h2>\n<p><\/p>\n<p>Zdaj pa se lotimo te\u017eje naloge razporeditve virov za ve\u010d minionov.<\/p>\n<p><\/p>\n<p>Ra\u010dunalni\u0161ki vir v one-cloud \u2014 to je:<\/p>\n<p><\/p>\n<ul>\n<li>Ra\u010dunalni\u0161ka mo\u010d procesorja, ki jo porablja dolo\u010dena naloga. <\/li>\n<li>Obseg pomnilnika, dostopnega nalogi. <\/li>\n<li>Mre\u017eni promet. Vsak od minionov ima dolo\u010den omre\u017eni vmesnik z omejeno prepustnostjo, zato nalog ne moremo razporejati, ne da bi upo\u0161tevali obseg podatkov, ki jih prena\u0161ajo po omre\u017eju. <\/li>\n<li>Trdi diski. Poleg seveda prostora za podatke naloge, tudi dolo\u010damo vrsto diska: HDD ali SSD. Trdi diski lahko obravnavajo kon\u010dno \u0161tevilo zahtevkov na sekundo \u2014 IOPS. Zato za naloge, ki ustvarjajo ve\u010d IOPS, kot jih lahko obravnava en disk, tudi dodelimo 'spindle' \u2014 torej diske, ki jih je treba izklju\u010dno rezervirati za nalogo.<\/li>\n<\/ul>\n<p><\/p>\n<p>Tako za neko storitev, na primer user-cache, lahko zapi\u0161emo porabljene vire na naslednji na\u010din: 400 procesorskih jeder, 2,5 TB pomnilnika, 50 Gbit\/s prometa v obe smeri, 6 TB prostora na HDD, razporejenega na 100 'spindlih'. Ali v bolj poznani obliki tako:<\/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>Viri storitve user-cache porabijo le del vseh razpolo\u017eljivih virov v produkcijski infrastrukturi. Zato si \u017eelimo, da user-cache nenadoma, zaradi napake operaterja ali ne, ne bi porabil ve\u010d virov, kot mu je dodeljeno. To pomeni, da moramo omejiti vire. A na kaj bi lahko vezali kvoto?<\/p>\n<p><\/p>\n<p>Vrnimo se na na\u0161u vrlo pojednostavljenu shemu interakcije komponenti i ponovno je nacrtajmo s vi\u0161e detalja\u2014ovako: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/27e5bfbffadd3d4b9fdc6bf138d135ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u0160to se odmah uo\u010dava:<\/p>\n<p><\/p>\n<ul>\n<li>Web frontend i muzika koriste izolirane klastere istog aplikacijskog servera.<\/li>\n<li>Mo\u017eemo izdvojiti logi\u010dke slojeve kojima pripadaju ti klasteri: frontovi, ke\u0161evi, sloj za pohranu i upravljanje podacima.<\/li>\n<li>Frontend nije homogena celina, to su razli\u010diti funkcionalni podsistemi. <\/li>\n<li>Ke\u0161evi se tako\u0111e mogu rasporediti po podsistemu \u010dije podatke ke\u0161iraju.<\/li>\n<\/ul>\n<p><\/p>\n<p>Jo\u0161 jednom \u0107emo nacrtati sliku:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/905dacc0aca859e65bd33ef751a557cf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ha! Vidimo hijerarhiju! To zna\u010di da mo\u017eemo rasporediti resurse u ve\u0107im delovima: imenovati odgovornog programera za \u010dvor te hijerarhije, koji odgovara funkcionalnom podsistemu (kao \u0161to je \"music\" na slici), i ovoj hijerarhiji vezati kvotu. Takva hijerarhija nam tako\u0111e omogu\u0107ava da fleksibilnije organizujemo servise radi lak\u0161eg upravljanja. Na primer, svi web, budu\u0107i da je to vrlo velika grupacija servera, delimo na nekoliko manjih grupa, prikazanih na slici kao group1, group2.<\/p>\n<p><\/p>\n<p>Uklanjanjem suvi\u0161nih linija, mo\u017eemo zapisati svaki \u010dvor na\u0161e slike u ravnijem obliku: <strong>group1.web.front<\/strong>, <strong>api.music.front<\/strong>, <strong>user-cache.cache<\/strong>.<\/p>\n<p><\/p>\n<p>Tako dolazimo do pojma \"hijerarhijska queue\". Ona ima ime, kao \u0161to je \"group1.web.front\". Na nju se dodeljuje kvota resursa i prava korisnika. Osobi iz DevOps-a \u0107emo dati prava za slanje servisa u queue, i takva osoba mo\u017ee pokrenuti ne\u0161to u queue, dok osobi iz OpsDev dodeljujemo admins \u043f\u0440\u0430\u0432\u0430, i sada ona mo\u017ee upravljati queue, dodeliti ljude u nju, davati tim ljudima prava i sl. Servisi pokrenuti u ovoj queue \u0107e se izvr\u0161avati u okviru kvote queue. Ako ra\u010dunska kvota queue nije dovoljna za simultano izvr\u0161enje svih servisa, oni \u0107e se izvr\u0161avati jedan za drugim, \u010dime se formira pravopisna queue. <\/p>\n<p><\/p>\n<p>Hajde da pogledamo servise detaljnije. Svaki servis ima potpuno ime, koje uvek uklju\u010duje ime queue. Tako \u0107e servis web fronta imati ime <strong>ok-web.group1.web.front<\/strong>. A servis aplikacijskog servera kojem se obra\u0107a, bi\u0107e poznat kao <strong>ok-app.group1.web.front<\/strong>. Vsak storitev ima manifest, ki vsebuje vse potrebne informacije za gostovanje na dolo\u010denih strojih: koliko virov potrebuje ta naloga, kak\u0161na konfiguracija je potrebna, koliko replik mora biti, lastnosti za obvladovanje napak te storitve. In po gostovanju storitve na strojih se pojavijo njeni primerki. Ti so prav tako nedvoumno poimenovani - kot \u0161tevilka primerka in ime storitve: <strong>1.ok-web.group1.web.front, 2.ok-web.group1.web.front, \u2026<\/strong><\/p>\n<p><\/p>\n<p>To je zelo priro\u010dno: samo z imenom zagnanega kontejnerja lahko takoj ugotovimo veliko.<\/p>\n<p><\/p>\n<p>Zdaj se podrobneje spoznamo s tem, kaj ti primerki dejansko po\u010dnejo: z nalogami.<\/p>\n<p><\/p>\n<h2 id=\"klassy-izolyacii-zadach\">Razredi izolacije nalog<\/h2>\n<p><\/p>\n<p>Vse naloge v OK (verjetno pa povsod) lahko razdelimo v skupine:<\/p>\n<p><\/p>\n<ul>\n<li><strong>Naloge z kratko latenco \u2014 prod<\/strong>. Za tak\u0161ne naloge in storitve je zelo pomembna latenca odgovora (latency), kako hitro bo vsak od zahtevkov obdelan s sistemom. Primeri nalog: spletni vmesniki, predpomnilniki, stre\u017eniki aplikacij, OLTP skladi\u0161\u010da itd.<\/li>\n<li><strong>Ra\u010dunske naloge \u2014 batch<\/strong>. Tu hitrost obdelave vsakega posameznega zahtevka ni pomembna. Pomembno je, koliko skupnih izra\u010dunov bo ta naloga opravila v dolo\u010denem (velikem) \u010dasovnem obdobju (throughput). Sem spadajo katerikoli nalogi MapReduce, Hadoop, strojno u\u010denje, statistika.<\/li>\n<li><strong>Ozadnje naloge \u2014 idle<\/strong>. Za tak\u0161ne naloge niti latenca niti throughput nista posebej pomembna. Sem spadajo razli\u010dni testi, migracije, ponovni izra\u010duni, pretvorbe podatkov iz enega formata v drugega. Po eni strani so podobne ra\u010dunski nalogam, po drugi strani pa nam ni toliko pomembno, kako hitro se bodo zaklju\u010dile. <\/li>\n<\/ul>\n<p><\/p>\n<p>Oglejmo si, kako tak\u0161ne naloge porabljajo vire, na primer, centralni procesor.<\/p>\n<p><\/p>\n<p><strong>Naloge z kratko latenco.<\/strong> Pattern porabe CPU za tak\u0161no nalogo bo podoben temu:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/1ed82c0df76325eb30056ad9af86e86e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Prejeli smo zahtevo uporabnika, naloga za\u010dne uporabljati vse razpolo\u017eljive jedrne enote CPU, obdela, vrne odgovor, \u010daka na naslednjo zahtevo in miruje. Prito\u017eena je nova zahteva \u2014 spet je izbrala vse, kar je bilo, naredila izra\u010dun, \u010dakamo na naslednjo.<\/p>\n<p><\/p>\n<p>Da bi zagotovili minimalno latenco za tak\u0161no nalogo, moramo vzeti maksimum porabljenih virov in rezervirati potrebno \u0161tevilo jeder na minionu (stroju, ki bo izvajal nalogo). Tako bo formula za rezervacijo za na\u0161o nalogo tak\u0161na:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = 4 (max)<\/code><\/pre>\n<p><\/p>\n<p>\u010ce imamo stroj-minion s 16 jedri, lahko na njem natan\u010dno namestimo \u0161tiri tak\u0161ne naloge. Omeniti je treba, da je povpre\u010dna poraba procesorja pri tak\u0161nih nalogah pogosto zelo nizka \u2014 kar je o\u010ditno, saj je velika ve\u010dina \u010dasa naloga v \u010dakanju na zahtevo in ni\u010d ne po\u010dne.<\/p>\n<p><\/p>\n<p><strong>Izra\u010dunane naloge.<\/strong> Njihov vzorec bo nekoliko druga\u010den:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/35b37fa1d70a137287cafdbfe3bcfc2e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Povpre\u010dna poraba procesorskih virov pri tak\u0161nih nalogah je dovolj visoka. Pogosto \u017eelimo, da se izra\u010dunana naloga izvr\u0161i v dolo\u010denem \u010dasu, zato je treba rezervirati minimalno \u0161tevilo procesorjev, ki jih potrebuje, da se celoten izra\u010dun kon\u010da v sprejemljivem \u010dasu. Njena formula rezervacije bo videti takole:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = [1,*)<\/code><\/pre>\n<p><\/p>\n<p><em>\u201eProsim, namesti me na minionu, kjer je vsaj en prost jedro, ostalo pa kar koli je \u2014 vse bo porabljeno.\u201c<\/em><\/p>\n<p><\/p>\n<p>Tu je u\u010dinkovitost uporabe \u017ee znatno bolj\u0161a kot pri nalogah s kratko zakasnitvijo. A dobi\u010dek bo \u0161e ve\u010dji, \u010de zdru\u017eimo oba tipa nalog na enem minionu in sproti razdelimo njegove vire. Ko naloga s kratko zakasnitvijo potrebuje procesor \u2014 ga takoj dobi, ko pa viri niso ve\u010d potrebni \u2014 se prenesejo na izra\u010dunano nalogo, torej nekako takole:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/875ad8d3f6a01e4fd0a89d0931e986c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kako to narediti?<\/p>\n<p><\/p>\n<p>Najprej se pogovorimo o prod in njegovem alloc: cpu = 4. Potrebujemo rezervirati \u0161tiri jedra. V Docker run to lahko storimo na dva na\u010dina: <\/p>\n<p><\/p>\n<ul>\n<li>Z opcijo <code>--cpuset=1-4<\/code>, tj. dodeliti \u0161tiri dolo\u010dena jedra nalogi na napravi.<\/li>\n<li>Uporabite <code>--cpuquota=400_000 --cpuperiod=100_000<\/code>, dolo\u010dite kvoto za procesorski \u010das, tj. navedite, da naloga v 100 ms dejanskega \u010dasa ne porabi ve\u010d kot 400 ms procesorskega \u010dasa. Rezultat so ista \u0161tiri jedra. <\/li>\n<\/ul>\n<p><\/p>\n<p>Katero od teh na\u010dinov bi bilo primerno?<\/p>\n<p><\/p>\n<p>Cpuset izgleda prili\u010dno privla\u010dno. Zadatak ima \u010detiri dodijeljene jezgre, \u0161to zna\u010di da \u0107e procesorski ke\u0161ovi raditi maksimalno efikasno. Me\u0111utim, to ima i svoju negativnu stranu: bili bismo primorani preuzeti zada\u0107u raspodjele izra\u010duna po nezasi\u0107enim jezgrama ma\u0161ine umjesto operativnog sistema, \u0161to je prili\u010dno neobi\u010dan zadatak, posebno ako poku\u0161amo smjestiti batch-zadatke na ovakvu ma\u0161inu. Testovi su pokazali da ovdje bolje odgovara opcija sa kvotom: tako operativni sistem ima ve\u0107u slobodu u izboru jezgre za izvr\u0161avanje zadatka u tom trenutku i procesorsko vreme se raspore\u0111uje efikasnije.<\/p>\n<p><\/p>\n<p>Hajde da vidimo kako u dockeru napraviti rezervaciju po minimalnom broju jezgri. Kvota za batch-zadatke vi\u0161e nije primjenjiva, jer nije potrebno ograni\u010diti maksimum, dovoljno je samo garantirati minimum. A ovdje dobro odgovara opcija <code>docker run --cpushares<\/code>.<\/p>\n<p><\/p>\n<p>Dogovorili smo se da ako batch zahtijeva garanciju minimum na jednoj jezgri, onda navodimo <code>--cpushares=1024<\/code>, a ako minimum na dvije jezgre, onda navodimo <code>--cpushares=2048<\/code>. Cpu shares ne ometaju raspodjelu procesorskog vremena sve dok ga ima dovoljno. Tako, ako prod trenutno ne koristi sve svoje \u010detiri jezgre \u2014 ni\u0161ta ne ograni\u010dava batch-zadatke, i oni mogu koristiti dodatno procesorsko vreme. Me\u0111utim, u situaciji nedostatka procesora, ako prod iskoristi svih svojih \u010detiri jezgre i nai\u0111e na kvotu \u2014 preostalo procesorsko vreme \u0107e biti podeljeno proporcionalno cpushares, tj. u situaciji tri slobodne jezgre, jedna \u0107e dobiti zadatak sa 1024 cpushares, a ostale dve \u2014 zadatak sa 2048 cpushares.<\/p>\n<p><\/p>\n<p>Ali kori\u0161\u0107enje kvote i shares nije dovoljno. Trebamo u\u010diniti tako da zadatak sa kratkom latencijom ima prioritet pred batch-zadatkom prilikom raspodjele procesorskog vremena. Bez takve priorizacije, batch-zadatak \u0107e uzimati sve procesorsko vreme u trenutku kada je to potrebno prod. U Docker run nema opcija za priorizaciju kontejnera, ali politika planiranja centralnog procesora u Linuxu dolazi u pomo\u0107. Detaljno o njima se mo\u017ee pro\u010ditati <noindex><a rel=\"nofollow\" href=\"http:\/\/man7.org\/linux\/man-pages\/man2\/sched_setscheduler.2.html\">tukaj<\/a><\/noindex>, a u okviru ovog \u010dlanka \u0107emo ih pro\u0107i ukratko:<\/p>\n<p><\/p>\n<ul>\n<li><strong>SCHED_OTHER<\/strong><br \/>\nPodrazumevano dobijaju svi obi\u010dni korisni\u010dki procesi na Linux ma\u0161ini.<\/li>\n<li><strong>SCHED_BATCH<\/strong><br \/>\nDolo\u010dena je za obremenjujo\u010de procese. Pri prenosu naloge v procesor se uvede tako imenovana kazen za aktivacijo: tak\u0161na naloga ima manj\u0161o verjetnost, da pridobi vire procesorja, \u010de ga v tem trenutku uporablja naloga s SCHED_OTHER.<\/li>\n<li><strong>SCHED_IDLE<\/strong><br \/>\nOzadjski proces z zelo nizko prednostjo, celo pod nice \u201319. Uporabljamo na\u0161o knji\u017enico z odprto kodo. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/odnoklassniki\/one-nio\">one-nio<\/a><\/noindex>, da bi dolo\u010dili potrebno politiko ob zagonu kontejnerja s klicem.<\/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>Toda tudi \u010de ne programirate v Javi, lahko isto dose\u017eete s pomo\u010djo ukaza chrt:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">chrt -i 0 $pid<\/code><\/pre>\n<p><\/p>\n<p>Zbirajmo vse na\u0161e ravni izolacije v eno tabelo za ve\u010djo preglednost:<\/p>\n<p><\/p>\n<p>Razred izolacije<br \/>\nPrimer alloc<br \/>\nMo\u017enosti Docker run<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>*\u010ce izvajate chrt znotraj kontejnerja, je morda potrebna zmo\u017enost sys_nice, saj ta zmo\u017enost privzeto odvzame Docker ob zagonu kontejnerja.<\/p>\n<p><\/p>\n<p>Toda naloge porabljajo ne le procesor, ampak tudi promet, ki vpliva na zakasnitev omre\u017ene naloge \u0161e bolj kot napa\u010dna dodelitev virov procesorja. Zato si seveda \u017eelimo dose\u010di enako sliko tudi za promet. To pomeni, ko prod-naloga po\u0161ilja pakete v omre\u017eje, kvotiramo maksimalno hitrost (formula <em>alloc: lan=[*,500mbps)<\/em> ), s katero lahko prod to po\u010dne. Za batch pa jam\u010dimo le minimalno prepustnost, ne omejujemo pa maksimalne (formula <em>alloc: lan=[10Mbps,*)<\/em> ) Pri tem mora promet prod imeti prednost pred batch-nalogami.<br \/>\nTukaj Docker nima nobenih primit\u00edvov, ki bi jih lahko uporabili. Ampak na pomo\u010d nam pride <noindex><a rel=\"nofollow\" href=\"http:\/\/lartc.org\/\">Linux Traffic Control<\/a><\/noindex>. Uspe\u0161no smo dosegli \u017eelen rezultat s pomo\u010djo discipline <noindex><a rel=\"nofollow\" href=\"http:\/\/linux-ip.net\/articles\/hfsc.en\/\">Hierarchical Fair Service Curve<\/a><\/noindex>. S tem dolo\u010damo dve classi prometa: visoko prioriteto prod in nizko prioriteto batch\/idle. Na koncu konfiguracija za odhodni promet izgleda takole:<\/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 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/3f52a968118b6021bd0c920af17a00c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>tukaj 1:0 \u2014 &#171;korenska qdisc&#187; discipline hsfc; 1:1 \u2014 podrazred hsfc z skupno omejitvijo prepustnosti 8 Gbit\/s, ki vklju\u010duje podrazrede vseh kontejnerjev; 1:2 \u2014 podrazred hsfc, skupen za vse batch in idle naloge z &#171;dinami\u010dno&#187; omejitvijo, o kateri bomo govorili spodaj. Preostali podrazredi hsfc so dodeljeni razredi za trenutno delujo\u010de prod-kontejnerje z omejitvami, ki ustrezajo njihovim manifestom, \u2014 450 in 400 Mbit\/s. Vsakemu razredu hsfc je dodeljena qdisc vrsta fq ali fq_codel, odvisno od razli\u010dice jedra linux, da se prepre\u010dijo izgube paketov pri nenadnih porastih prometa. <\/p>\n<p><\/p>\n<p>Obi\u010dajno discipline tc slu\u017eijo za prioritizacijo samo odhodnega prometa. Toda mi \u017eelimo prioritizirati tudi prihajajo\u010di promet \u2014 saj lahko katera koli batch-naloga brez te\u017eav izkoristi celoten prihajajo\u010di kanal, na primer, ko prejme velik paket vhodnih podatkov za map&amp;reduce. Zato uporabljamo modul <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/350023\/tc-ingress-policing-and-ifb-mirroring\">ifb<\/a><\/noindex>, ki ustvari virtualni vmesnik ifbX za vsak omre\u017eni vmesnik in preusmeri prihajajo\u010di promet z vmesnika v odhodni promet na ifbX. Nato za ifbX delujejo vse iste discipline za nadzor odhodnega prometa, pri \u010demer bo konfiguracija hsfc zelo podobna:<\/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 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/967da9c0637cc70ba195af781db18adf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Med eksperimenti smo ugotovili, da hsfc dosega najbolj\u0161e rezultate, ko se razred 1:2 neprioritetnega batch\/idle prometa omeji na minionih na dolo\u010deno prostorno pasovno \u0161irino. V nasprotnem primeru neprioritetni promet preve\u010d vpliva na zakasnitve prod-nalog. Trenutno vrednost prostorne pasovne \u0161irine miniond dolo\u010da vsako sekundo, ko izra\u010dunava povpre\u010dno porabo prometa vseh prod-nalog na tem minionu <img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/9d6f38110d3b1693afe222b01430b9bb.jpg\" style=\"display:block;margin: 0 auto;\" \/> in jo od\u0161teje od pasovne \u0161irine omre\u017enega vmesnika <img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/d5608ec4c58e44b8571ab0b1d0cc7701.jpg\" style=\"display:block;margin: 0 auto;\" \/> s majhnim varovanjem, tj.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/fb01347c2224bd5bbd82169861eeb7e4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Pasovne \u0161irine se dolo\u010dajo za prihajajo\u010di in odhodni promet neodvisno. V skladu z novimi vrednostmi miniond ponovno konfigurira omejitev neprioritetnega razreda 1:2.<\/p>\n<p><\/p>\n<p>Tako smo uresni\u010dili vse tri razrede izolacije: prod, batch in idle. Ti razredi mo\u010dno vplivajo na zmogljivosti nalog. Zato smo se odlo\u010dili, da to lastnost postavimo na vrh hierarhije, da bo ob pogledu na ime hierarhi\u010dne vrste takoj jasno, s \u010dim imamo opraviti: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/34dc89c461db711b19a0f4eccc50efce.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vsi na\u0161i znani <strong>web<\/strong> in <strong>music<\/strong> fronji so nato v hierarhiji pod prod. Na primer, pod batch postavimo storitev <strong>music catalog<\/strong>, ki ob\u010das sestavi katalog skladb iz nabora nalo\u017eenih mp3-datotek v \u201eOdnoklassniki\u201c. Primer storitve za idle je lahko <strong>transformator glasbe<\/strong>, ki normalizira raven glasnosti glasbe.<\/p>\n<p><\/p>\n<p>Znova, ko odstranimo odve\u010dne vrstice, lahko imena na\u0161ih storitev zapi\u0161emo bolj plosko, tako da dodamo razred izolacije naloge na konec polnega imena storitve: <strong>web.front.prod<\/strong>, <strong>catalog.music.batch<\/strong>, <strong>transformer.music.idle<\/strong>.<\/p>\n<p><\/p>\n<p>In zdaj, ko gledamo na ime storitve, razumemo ne le to, katero funkcijo opravlja, ampak tudi njen razred izolacije, kar pomeni njeno kriti\u010dnost itd.<\/p>\n<p><\/p>\n<p>Vse je super, a obstaja ena grenka resnica. Popolnoma izolirati naloge, ki delujejo na eni napravi, ni mogo\u010de.<\/p>\n<p><\/p>\n<p>\u010cesar smo dosegli: \u010de batch intenzivno porablja <strong>le<\/strong> procesorske vire, vgrajeni na\u010drtovalnik CPU Linux zelo dobro opravlja svoje naloge, vpliv na prod-nalogo pa je skoraj zanemarljiv. Toda \u010de ta batch-naloga za\u010dne aktivno delati z pomnilnikom, se \u017ee za\u010dnejo ka\u017eejo medsebojni vplivi. To se zgodi, ker pri prod-nalogi \u201eizpuhti\u201c procesorske predpomnilnike pomnilnika \u2014 na koncu se v predpomnilniku pove\u010dajo zgre\u0161eni dostopi, procesor pa obdeluje prod-nalogo po\u010dasneje. Tak\u0161na batch-naloga lahko za 10 % pove\u010da zakasnitev na\u0161e tipi\u010dne prod-konfiguracije.<\/p>\n<p><\/p>\n<p>Izolirati promet je \u0161e bolj zahtevno, ker sodobne mre\u017ene kartice vsebujejo notranjo vrsto paketov. \u010ce paket iz batch-naloge pride tja prvi, bo tudi prvi prenesen po kablu, in tu ni ni\u010d za narediti.<\/p>\n<p><\/p>\n<p>Poleg tega nam je za zdaj uspelo re\u0161iti le nalogo prioritetizacije TCP-prometa: za UDP pristop s hsfc ne deluje. In celo v primeru TCP-prometa, \u010de batch-naloga generira veliko prometa, to povzro\u010da tudi okoli 10 % pove\u010danje zakasnitve prod-naloge.<\/p>\n<p><\/p>\n<h2 id=\"otkazoustoychivost\">Odporna zasnova<\/h2>\n<p><\/p>\n<p>Eden od ciljev pri razvoju one-cloud je bil izbolj\u0161anje odpornosti Odnoklassnikov. Zato bi rad podrobneje obravnaval mo\u017ene scenarije napak in nesre\u010d. Za\u010dnimo s preprostim scenarijem \u2014 z izpadom kontejnerja. <\/p>\n<p><\/p>\n<p>Kontejner lahko odpove na ve\u010d na\u010dinov. To je lahko eksperiment, napaka ali napaka v manifestu, zaradi katere za\u010dne produktna naloga porabljati ve\u010d virov, kot je navedeno v manifestu. Imeli smo primer: razvijalec je implementiral kompleksen algoritem, ga ve\u010dkrat predeloval, se zapletel tako, da se je na koncu naloga precej zapletla. Ker je bila produktna naloga prioriteta pred vsemi drugimi na istih minionih, je za\u010dela porabljati vse razpolo\u017eljive procesorske vire. V tej situaciji je izolacija re\u0161ila stvar, natan\u010dneje kvota na procesorsko \u010das. \u010ce je nalogi dodeljena kvota, naloga ne bo porabila ve\u010d. Zato batch in druge produktne naloge, ki so delale na isti napravi, niso opazile ni\u010desar. <\/p>\n<p><\/p>\n<p>Druga mo\u017ena te\u017eava \u2013 zru\u0161itev kontejnerja. In tu nam pomagajo politike ponovnega zagona, vsi jih poznajo, Docker se s tem odli\u010dno odre\u017ee. Skoraj vse produktne naloge imajo politiko ponovnega zagona always. V\u010dasih uporabljamo on_failure za batch naloge ali za odpravljanje napak pri produktnih kontejnerjih.<\/p>\n<p><\/p>\n<p>Kaj pa storiti, ko celoten minion ni dostopen?<\/p>\n<p><\/p>\n<p>O\u010ditno je potrebno zagnati kontejner na drugem stre\u017eniku. Najbolj zanimivo pri tem je, kaj se zgodi z IP naslovom (naslovi), dodeljenimi kontejnerju. <\/p>\n<p><\/p>\n<p>Lahko dodelimo kontejnerjem iste IP naslove kot imamo pri minion napravah, na katerih se ti kontejnerji izvajajo. Takrat, ko se kontejner za\u017eene na drugem stre\u017eniku, se njegov IP naslov spremeni in vsi odjemalci morajo razumeti, da se je kontejner preselil, zdaj se morajo povezati na drugo dolo\u010den naslov, kar zahteva lo\u010deno storitev za odkrivanje storitev. <\/p>\n<p><\/p>\n<p>Odkritje storitev je priro\u010dno. Na trgu je veliko re\u0161itev raznolike stopnje odpornosti za organizacijo registra storitev. Pogosto so v takih re\u0161itvah vklju\u010dene logike uravnava\u010da obremenitve, shranjevanje dodatne konfiguracije v obliki KV shrambe itd.<br \/>\nVendar pa bi si \u017eeleli izogniti potrebi po uvedbi lo\u010denega registra, saj bi to pomenilo uvedbo kriti\u010dnega sistema, ki ga uporabljajo vse storitve v produkciji. To pomeni, da je to potencialna to\u010dka odpovedi, in treba je izbrati ali razviti zelo odporn re\u0161itev, kar je o\u010ditno zelo te\u017eko, dolgotrajno in drago. <\/p>\n<p><\/p>\n<p>In addition, another major drawback is that for our old infrastructure to integrate with the new one, we would have to rewrite all tasks to use some form of Service Discovery system. The work involved is ENORMOUS, and in some cases, it borders on impossible, especially when it comes to low-level devices operating at the OS kernel level or directly with hardware. Implementing this functionality using established solution patterns, like for instance <noindex><a rel=\"nofollow\" href=\"https:\/\/linkerd.io\">side-car<\/a><\/noindex> would mean occasionally adding extra load, complicating operations in some instances, and introducing additional failure scenarios. We didn't want to complicate things, so we decided to make the use of Service Discovery optional. <\/p>\n<p><\/p>\n<p>In one-cloud, the IP follows the container, meaning each task instance has its own unique IP address. This address is 'static': it is assigned to each instance at the moment of its first deployment into the cloud. If during its lifetime the service has multiple instances, it will end up having as many IP addresses as there were maximum instances.<\/p>\n<p><\/p>\n<p>Subsequently, these addresses do not change: they are assigned once and remain throughout the entire lifespan of the service in production. The IP addresses follow the containers across the network. If a container is moved to another minion, the address will also move with it. <\/p>\n<p><\/p>\n<p>Thus, the mapping of the service name to its list of IP addresses changes very rarely. If we look again at the service instance names mentioned at the beginning of the article (<strong>1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, \u2026<\/strong>), bomo opazili, da spominjajo na FQDN, ki se uporablja v DNS. In res je, za prikazovanje imen primerkov storitev v njihovih IP-naslovih uporabljamo DNS protokol. Pri tem ta DNS vrne vse rezervirane IP-naslove vseh kontejnerjev \u2014 tako delujo\u010dih kot ustavljenih (recimo, da so aktivne tri replikacije, a imamo pet rezerviranih naslovov \u2014 vseh pet se bo vrnilo). Stranke, ki prejemajo te informacije, bodo posku\u0161ale vzpostaviti povezavo z vsemi petimi replikami \u2014 in tako bodo ugotovile, katere od njih so aktivne. Tak na\u010din ugotavljanja dostopnosti je bistveno bolj zanesljiv, saj ne vklju\u010duje niti DNS niti odkrivanja storitev, kar pomeni, da ni te\u017eav z zagotavljanjem a\u017eurnosti informacij in odpornosti teh sistemov. Poleg tega lahko v kriti\u010dnih storitvah, od katerih je odvisno delovanje celotnega portala, sploh ne uporabljamo DNS, temve\u010d preprosto vnesemo IP-naslove v konfiguracijo.<\/p>\n<p><\/p>\n<p>Izvedba take premestitve IP za kontejnerji je lahko zapletena \u2014 in osredoto\u010dili se bomo na to, kako to deluje, na naslednjem primeru:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/faf99c2609a57daa1bdc193cb0f4cb31.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Recimo, da glavni one-cloud da ukaz minionu M1, da za\u017eene <strong>1.ok-web.group1.web.front.prod<\/strong> z naslovom 1.1.1.1. Na minionu deluje <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Bird_Internet_routing_daemon\">BIRD<\/a><\/noindex>, ki ogla\u0161uje ta naslov na posebne stre\u017enike <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Route_reflector\">route reflector<\/a><\/noindex>. Ti imajo BGP sejo s strojno opremo omre\u017eja, na katero se prena\u0161a pot do naslova 1.1.1.1 na M1. M1 usmerja pakete v notranjost kontejnerja \u017ee z uporabo Linuxa. Imamo tri stre\u017enike route reflector, saj je to zelo kriti\u010den del infrastrukture one-cloud \u2014 brez njih omre\u017eje v one-cloud ne bo delovalo. Postavili smo jih v razli\u010dne omare, kolikor je mogo\u010de, v razli\u010dne dvorane podatkovnega centra, da zmanj\u0161amo verjetnost hkratnega odpovedi vseh treh.<\/p>\n<p><\/p>\n<p>Zdaj predpostavimo, da je povezava med glavnim one-cloud in minionom M1 izginila. Glavni one-cloud bo zdaj deloval na podlagi predpostavke, da je M1 popolnoma odpovedal. To pomeni, da bo dal ukaz minionu M2, da za\u017eene <strong>web.group1.web.front.prod<\/strong> z istojnim naslovom 1.1.1.1. Zdaj imamo dve nasprotujo\u010di si poti v omre\u017eju za 1.1.1.1: na M1 in na M2. Za re\u0161evanje tak\u0161nih konfliktov uporabljamo Multi Exit Discriminator, ki je naveden v BGP napovedi. To je \u0161tevilka, ki ozna\u010duje te\u017eo napovedane poti. Iz nasprotujo\u010dih si se bo izbrala pot z manj\u0161im vrednostjo MED. Master one-cloud podpira MED kot integralni del IP naslovov kontejnerjev. Prvi\u010d se naslov izda z dovolj velikim MED = 1.000.000. V primeru takega nujnega prenosa kontejnerja master zmanj\u0161a MED, in M2 bo prejel ukaz, da napove naslov 1.1.1.1 z MED = 999.999. Instanca, ki deluje na M1, bo ob tem ostala brez povezave, njena nadaljnja usoda nas malo zanima do trenutka, ko bo povezava z masterjem ponovno vzpostavljena, takrat pa bo ustavljena kot stara kopija.<\/p>\n<p><\/p>\n<h2 id=\"avarii\">Kr\u0161itve<\/h2>\n<p><\/p>\n<p>Vse sisteme za upravljanje podatkovnih centrov je vedno sprejemljivo obvladati manj\u0161e okvare. Izpad kontejnerja je norma skoraj povsod.<\/p>\n<p><\/p>\n<p>Poglejmo, kako obvladujemo kr\u0161itev, na primer izpad elektri\u010dne energije v eni ali ve\u010d dvoranah podatkovnega centra.<\/p>\n<p><\/p>\n<p>Kaj pomeni kr\u0161itev za sistem upravljanja podatkovnega centra? Najprej je to mno\u017ei\u010dna enkratna okvara mnogih strojev, in sistem upravljanja mora hkrati migrirati zelo veliko kontejnerjev. A \u010de je kr\u0161itev zelo obse\u017ena, se lahko zgodi, da vseh nalog ni mogo\u010de prenesti na druge vozli\u0161\u010dne naprave, ker zmogljivost podatkovnega centra pade pod 100 % obremenitve. <\/p>\n<p><\/p>\n<p>Pogosto so kr\u0161itve povezane z okvaro upravljalskega sloja. To se lahko zgodi zaradi okvare njegove opreme, vendar pogosteje zaradi tega, ker kr\u0161itve niso testirane in upravljalski sloj sam pade pod pove\u010dano obremenitvijo. <\/p>\n<p><\/p>\n<p>Kaj lahko storimo v zvezi s tem?<\/p>\n<p><\/p>\n<p>Mno\u017ene migracije pomenijo, da se v infrastrukturi pojavi velika koli\u010dina dejanj, migracij in nastanitev. Vsaka od migracij lahko traja nek \u010das potreben za dostavo in razpakiranje slik kontejnerjev do vozli\u0161\u010d, zagon in inicializacijo kontejnerjev itd. Zato je priporo\u010dljivo, da se pomembnej\u0161e naloge za\u017eenejo pred manj pomembnimi.<\/p>\n<p><\/p>\n<p>Poglejmo ponovno znano hierarhijo storitev in poskusimo re\u0161iti, katere naloge \u017eelimo zagnati najprej.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/2e827271adb8d3ff3d385e53553aaacf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Seveda, to so tisti procesi, ki neposredno sodelujejo pri obdelavi uporabni\u0161kih zahtev, tj. prod. To ozna\u010dimo z <strong>prednostjo postavitve<\/strong> \u2014 \u0161tevilom, ki ga lahko dodelimo vrsti. \u010ce ima neka vrsta vi\u0161jo prednost, se njeni storitvi postavijo na prvo mesto.<\/p>\n<p><\/p>\n<p>Na prod dodelimo vi\u0161je prednosti, 0; na batch pa malo ni\u017eje, 100; na idle pa \u0161e ni\u017eje, 200. Prednosti se uporabljajo hierarhi\u010dno. Vse naloge, ki so ni\u017eje v hierarhiji, bodo imele ustrezno prednost. \u010ce \u017eelimo, da se v prod znotraj predpomnilnikov izvajajo najprej, jih dodelimo prednost = 0, za front podvrste pa = 1. \u010ce pa \u017eelimo, da se z frontov najprej izvaja glavni portal, kasneje pa music front, lahko temu zadnjemu dodelimo ni\u017ejo prednost \u2014 10.<\/p>\n<p><\/p>\n<p>Naslednji problem je pomanjkanje virov. Tako smo imeli odpoved velikega \u0161tevila opreme, celih dvoran podatkovnih centrov, mi pa smo zagnali toliko storitev, da zdaj ni dovolj virov za vse. Moramo se odlo\u010diti, katerim nalogam se odpovedati, da bodo delovale glavne kriti\u010dne storitve. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/1b1ad3da16df6677dd0ba4b038cdd7d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>V nasprotju s prednostjo postavitve ne moremo kar tako odpovedati vsem batch-naloga, nekatere od njih so pomembne za delovanje portala. Zato smo posebej izpostavili <strong>prednost izrivanja<\/strong> naloge. Pri postavitvi lahko naloga z vi\u0161jo prednostjo izrine, tj. ustavi nalogo z ni\u017ejo prednostjo, \u010de ni ve\u010d prostih minionov. Pri tem naloga z ni\u017ejo prednostjo verjetno ostane nepostavljena, tj. zanj ni ve\u010d primernega miniona z dovolj prostimi viri.<\/p>\n<p><\/p>\n<p>V na\u0161i hierarhiji je zelo enostavno nastaviti tak\u0161no prednost izrivanja, da prod- in batch-naloge izrinjajo ali ustavljajo idle-naloge, vendar ne med seboj, tako da idle dodelimo prednost 200. Tako kot pri prednosti postavitve lahko izkoristimo na\u0161o hierarhijo za opisovanje bolj zapletenih pravil. Na primer, navedemo, da bomo funkcijo glasbe \u017ertvovali, \u010de nam ne bodo zadostovali viri za glavni spletni portal, s \u010dimer nastavimo odgovarjajo\u010dim vozli\u0161\u010dem ni\u017ejo prednost: 10.<\/p>\n<p><\/p>\n<h2 id=\"avarii-dc-celikom\">Popolne okvare DCA<\/h2>\n<p><\/p>\n<p>Zakaj lahko odpove celoten podatkovni center? Naravna nesre\u010da. Bilo je dober prispevek, kako <noindex><a rel=\"nofollow\" href=\"https:\/\/habrahabr.ru\/company\/dataline\/blog\/333578\/\">hurrikan vpliva na delovanje podatkovnega centra<\/a><\/noindex>. Element osebnosti lahko \u0161tejemo brezdomce, ki so nekega dne v kolektorju za\u017egali optiko, zaradi \u010desar je celoten podatkovni center izgubil povezavo z ostalimi lokacijami. Razlog za okvaro je lahko tudi \u010dlove\u0161ki faktor: operater lahko izda ukaz, zaradi katerega celoten podatkovni center pade. Do tega lahko pride zaradi velike napake. Na splo\u0161no padci podatkovnih centrov niso redki. Pri nas se to zgodi vsakih nekaj mesecev. <\/p>\n<p><\/p>\n<p>In to je, kar po\u010dnemo, da nih\u010de #ok\u017eivin ne objavlja na Twitterju.<\/p>\n<p><\/p>\n<p>Prva strategija je izolacija. Vsak in\u0161tanc one-cloud je izoliran in lahko upravlja samo naprave enega podatkovnega centra. Torej izguba oblaka zaradi napak ali napa\u010dnega ukaza operaterja pomeni izgubo le enega podatkovnega centra. Na to smo pripravljeni: obstaja politika rezerviranja, pri kateri so kopije aplikacij in podatkov razporejene v vseh podatkovnih centrih. Uporabljamo odpornosti baze podatkov in redno testiramo odpovedi.<br \/>\nKer imamo danes \u0161tiri podatkovne centre, imamo tudi \u0161tiri popolnoma izolirane in lo\u010dene primere one-cloud.<\/p>\n<p><\/p>\n<p>Tak pristop ne le da \u0161\u010diti pred fizi\u010dno okvaro, temve\u010d lahko za\u0161\u010diti tudi pred napakami operaterja.<\/p>\n<p><\/p>\n<p>Kaj \u0161e lahko storimo glede \u010dlove\u0161kega faktorja? Ko operater da oblaku nek nenavaden ali potencialno nevaren ukaz, od njega lahko nenadoma zahtevajo, da re\u0161i majhno nalogo, da preveri, koliko dobro je razmislil. Na primer, \u010de gre za mno\u017ei\u010dno ustavitev \u0161tevilnih kopij ali preprosto nenavadno ukaz \u2014 zmanj\u0161anje \u0161tevila kopij ali sprememba imena slike, ne le \u0161tevilke razli\u010dice v novem manifestu.<\/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 operacijski sistem na ravni podatkovnega centra v Odnoklassnikih\" src=\"\/wp-content\/uploads\/2020\/06\/f7ee44a77e30612a3cd99a6f7aee3820.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<h2 id=\"itogi\">Zaklju\u010dki<\/h2>\n<p><\/p>\n<p>Posebnosti one-cloud: <\/p>\n<p><\/p>\n<ul>\n<li><strong>Hierarhi\u010dna in pregledna shema poimenovanja storitev in vsebnika<\/strong>, ki omogo\u010da zelo hitro ugotovitev, kaj je naloga, na kaj se nana\u0161a, kako deluje in kdo je za to odgovoren. <\/li>\n<li>Uveljavili smo svojo <strong>tehniko zdru\u017eevanja prod- in batch-<\/strong>nalog na minionih, da pove\u010damo u\u010dinkovitost skupne rabe naprav. Namesto cpuset uporabljamo kvote CPU, delitve, politike na\u010drtovanja CPU in Linux QoS.<\/li>\n<li>Popolnoma izolirati kontejnerjev, ki delujejo na eni napravi, ni uspelo, a njihov medsebojni vpliv ostaja v okviru do 20%.<\/li>\n<li>Organizacija storitev v hierarhijo pomaga pri samodejnem odpravljanju napak s pomo\u010djo <strong>prednostnih nalog in izlo\u010ditve<\/strong>.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"chavo\">\u010cFAQ<\/h2>\n<p><\/p>\n<p>Zakaj nismo sprejeli \u017ee pripravljenih re\u0161itev.<\/p>\n<p><\/p>\n<ul>\n<li>Razli\u010dni razredi izolacije nalog zahtevajo razli\u010dno logiko pri namestitvi na minione. Medtem ko lahko prod-naloge namestimo preprosto z rezervacijo virov, je treba batch in idle naloge namestiti ob upo\u0161tevanju dejanske izrabe virov na minionih. <\/li>\n<li>Potrebno je upo\u0161tevati vire, ki jih naloge porabljajo, kot so: \n<ul>\n<li>pasovna \u0161irina omre\u017eja;<\/li>\n<li>tipi in 'spindli' diskov.<\/li>\n<\/ul>\n<\/li>\n<li>Potrebno je dolo\u010diti prioritete storitev pri odpravljanju izpadov, pravice in kvote ekip na vire, kar se re\u0161i z uporabo hierarhi\u010dnih vrst v one-cloud.<\/li>\n<li>Potrebno je imeti \u010dlove\u0161ka imena kontejnerjev za zmanj\u0161anje \u010dasa odziva na izpade in incidente.<\/li>\n<li>Nemogo\u010de je hkrati in povsod vpeljati Service Discovery; potrebno je dolgo \u010dasa soobstajati z nalogami, name\u0161\u010denimi na fizi\u010dnih stre\u017enikih \u2014 kar se re\u0161i s \"stati\u010dnimi\" IP naslovi, povezanimi s kontejnerji, in posledi\u010dno potrebo po edinstveni integraciji z obse\u017eno omre\u017eno infrastrukturo.<\/li>\n<\/ul>\n<p><\/p>\n<p>Vse te funkcije bi terjale obse\u017ene predelave obstoje\u010dih re\u0161itev, in ob oceni koli\u010dine dela smo spoznali, da lahko razvijemo lastno re\u0161itev pribli\u017eno z enakimi delovnimi napori. Toda lastna re\u0161itev bo \u0161e veliko la\u017eja za obvladovanje in razvoj \u2014 v njej ni nepotrebnih abstrakcij, ki podpirajo nam nepotrebne funkcionalnosti. <\/p>\n<p><\/p>\n<p>Hvala tistim, ki ste prebrali zadnje vrstice, za va\u0161o potrpe\u017eljivost in pozornost!<\/p>\n<p>Izvor: <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.4 - 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\/sl\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\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\/sl\/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 operacijski sistem na ravni podatkovnega centra v Odnoklassniki | ProHoster","description":"Aloha, ljudje!","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/84114","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=84114"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/84114\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/84115"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=84114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=84114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=84114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}