{"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\/sk\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","title":{"rendered":"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/fa983acacec59ff2d4ed098f87223971.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ahoj, \u013eudia! Vol\u00e1m sa Oleg Anastasiev, pracujem v Odnoklassnikoch v t\u00edmu Platformy. Okrem m\u0148a v Odnoklassnikoch pracuje mno\u017estvo hardv\u00e9ru. M\u00e1me \u0161tyri d\u00e1tov\u00e9 centr\u00e1, v ktor\u00fdch je pribli\u017ene 500 stojanov s viac ako 8 000 servermi. V ur\u010ditom momente sme si uvedomili, \u017ee zavedenie nov\u00e9ho syst\u00e9mu riadenia n\u00e1m umo\u017en\u00ed efekt\u00edvnej\u0161ie vy\u0165a\u017ei\u0165 techniku, u\u013eah\u010di\u0165 spr\u00e1vu pr\u00edstupov, automatizova\u0165 (re)alok\u00e1ciu v\u00fdpo\u010dtov\u00fdch zdrojov, ur\u00fdchli\u0165 spustenie nov\u00fdch slu\u017eieb a r\u00fdchlo reagova\u0165 na rozsiahle hav\u00e1rie. <\/p>\n<p><\/p>\n<p>\u010co z toho vy\u0161lo? <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Okrem m\u0148a a mno\u017estva hardv\u00e9ru s\u00fa tu aj \u013eudia, ktor\u00ed s t\u00fdmto hardv\u00e9rom pracuj\u00fa: in\u017einieri, ktor\u00ed s\u00fa priamo v d\u00e1tov\u00fdch centr\u00e1ch; sie\u0165ov\u00e9 t\u00edmy, ktor\u00e9 konfiguruj\u00fa sie\u0165ov\u00e9 vybavenie; administr\u00e1tori, alebo SRE, ktor\u00ed zabezpe\u010duj\u00fa odolnos\u0165 infra\u0161trukt\u00fary; a t\u00edmy v\u00fdvoj\u00e1rov, pri\u010dom ka\u017ed\u00e1 z nich zodpoved\u00e1 za \u010das\u0165 funkci\u00ed port\u00e1lu. Softv\u00e9r, ktor\u00fd vytv\u00e1raj\u00fa, funguje takto:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/592fd0acfa7322eb80fbb85601a92918.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Po\u017eiadavky pou\u017e\u00edvate\u013eov prich\u00e1dzaj\u00fa ako na fronty hlavn\u00e9ho port\u00e1lu <noindex><a rel=\"nofollow\" href=\"http:\/\/www.ok.ru\/\">www.ok.ru<\/a><\/noindex>, tak aj na in\u00e9, napr\u00edklad na fronty API hudby. Na spracovanie obchodnej logiky volaj\u00fa server aplik\u00e1ci\u00ed, ktor\u00fd pri spracovan\u00ed \u017eiadosti vykon\u00e1va potrebn\u00e9 \u0161pecializovan\u00e9 mikroslu\u017eby \u2014 one-graph (graf soci\u00e1lnych v\u00e4zieb), user-cache (cache pou\u017e\u00edvate\u013esk\u00fdch profilov) a podobne.<\/p>\n<p><\/p>\n<p>Ka\u017ed\u00e1 z t\u00fdchto slu\u017eieb je nasaden\u00e1 na mno\u017estve strojov a ka\u017ed\u00fd z nich m\u00e1 zodpovedn\u00fdch v\u00fdvoj\u00e1rov, ktor\u00ed s\u00fa zodpovedn\u00ed za fungovanie modulov, ich prev\u00e1dzku a technologick\u00fd rozvoj. V\u0161etky tieto slu\u017eby sa sp\u00fa\u0161\u0165aj\u00fa na fyzick\u00fdch serveroch a dovtedy sme sp\u00fa\u0161\u0165ali presne jedno zadanie na jeden server, teda bol \u0161pecializovan\u00fd na konkr\u00e9tnu \u00falohu.<\/p>\n<p><\/p>\n<p>Pre\u010do je to tak? Tento pr\u00edstup mal nieko\u013eko v\u00fdhod:<\/p>\n<p><\/p>\n<ul>\n<li>Jednoduch\u0161ie <strong>hromadn\u00e9 riadenie<\/strong>. Predpokladajme, \u017ee \u00faloha vy\u017eaduje nejak\u00e9 kni\u017enice, nejak\u00e9 nastavenia. V takom pr\u00edpade sa server prirad\u00ed presne k jednej ur\u010ditej skupine, op\u00ed\u0161e sa politika cfengine pre t\u00fato skupinu (alebo u\u017e bola op\u00edsan\u00e1) a t\u00e1to konfigur\u00e1cia sa centralizovane a automaticky nasadzuje na v\u0161etky servery tejto skupiny.<\/li>\n<li>Zjednodu\u0161uje sa <strong>diagnostika<\/strong>. Predpokladajme, \u017ee sledujete zv\u00fd\u0161en\u00e9 za\u0165a\u017eenie procesora a uvedomujete si, \u017ee toto za\u0165a\u017eenie mohla vygenerova\u0165 len t\u00e1 \u00faloha, ktor\u00e1 be\u017e\u00ed na tomto hardv\u00e9rovom procesore. H\u013eadanie vinn\u00edka kon\u010d\u00ed ve\u013emi r\u00fdchlo.<\/li>\n<li>Zjednodu\u0161uje sa <strong>monitoring<\/strong>. Ak je so serverom nie\u010do v neporiadku, monitor o tom informuje a vy presne viete, kto za to m\u00f4\u017ee.<\/li>\n<\/ul>\n<p><\/p>\n<p>Slu\u017ebe, ktor\u00e1 sa sklad\u00e1 z nieko\u013ek\u00fdch replik, je pridelen\u00fdch nieko\u013eko serverov \u2014 po jednom na ka\u017ed\u00fa. Vtedy je priradenie v\u00fdpo\u010dtov\u00fdch zdrojov pre slu\u017ebu ve\u013emi jednoduch\u00e9: ko\u013eko m\u00e1 slu\u017eba serverov, to\u013eko m\u00f4\u017ee maxim\u00e1lne zdrojov vyu\u017ei\u0165. 'Jednoduch\u00e9' tu nie je v tom zmysle, \u017ee sa to \u013eahko pou\u017e\u00edva, ale v tom, \u017ee pridelenie zdrojov prebieha ru\u010dne.<\/p>\n<p><\/p>\n<p>Tak\u00fdto pr\u00edstup n\u00e1m tie\u017e umo\u017enil robi\u0165 <strong>\u0161pecializovan\u00e9 hardv\u00e9rov\u00e9 konfigur\u00e1cie<\/strong> pre \u00falohu, ktor\u00e1 be\u017e\u00ed na tomto serveri. Ak \u00faloha uchov\u00e1va ve\u013ek\u00e9 objemy \u00fadajov, pou\u017e\u00edvame 4U server s r\u00e1mom na 38 diskov. Ak je \u00faloha \u010disto v\u00fdpo\u010dtov\u00e1, m\u00f4\u017eeme k\u00fapi\u0165 lacnej\u0161\u00ed 1U server. To je efekt\u00edvne z h\u013eadiska v\u00fdpo\u010dtov\u00fdch zdrojov. Tento pr\u00edstup n\u00e1m tie\u017e umo\u017e\u0148uje pou\u017e\u00edva\u0165 \u0161tyrikr\u00e1t menej strojov pri za\u0165a\u017een\u00ed, ktor\u00e9 je porovnate\u013en\u00e9 s jednou priate\u013eskou soci\u00e1lnou sie\u0165ou. <\/p>\n<p><\/p>\n<p>Tak\u00e1to efekt\u00edvnos\u0165 vyu\u017e\u00edvania v\u00fdpo\u010dtov\u00fdch zdrojov by mala zabezpe\u010di\u0165 aj ekonomick\u00fa efekt\u00edvnos\u0165, ak vych\u00e1dzame z predpokladu, \u017ee najdrah\u0161ie s\u00fa servery. Dlho bola najdrah\u0161ia pr\u00e1ve technika, a my sme vlo\u017eili ve\u013ea s\u00edl do zni\u017eovania jej ceny, vym\u00fd\u0161\u013eaj\u00fac algoritmy zabezpe\u010denia odolnosti vo\u010di poruch\u00e1m na zn\u00ed\u017eenie po\u017eiadaviek na spo\u013eahlivos\u0165 zariaden\u00ed. A dnes sme sa dostali do f\u00e1zy, v ktorej cena servera prestala by\u0165 ur\u010duj\u00faca. Ak nezoh\u013ead\u0148ujeme najnov\u0161ie exotiky, konkr\u00e9tna konfigur\u00e1cia serverov v stojane u\u017e nem\u00e1 v\u00fdznam. Teraz m\u00e1me in\u00fd probl\u00e9m \u2014 cena miesta, ktor\u00e9 server zaber\u00e1 v d\u00e1tovom centre, t.j. miesta v stojane.<\/p>\n<p><\/p>\n<p>Ke\u010f sme si to uvedomili, rozhodli sme sa vypo\u010d\u00edta\u0165, ako efekt\u00edvne vyu\u017e\u00edvame stojany.<br \/>\nZobrali sme cenu najv\u00fdkonnej\u0161ieho servera z ekonomick\u00e9ho h\u013eadiska, vypo\u010d\u00edtali, ko\u013eko tak\u00fdchto serverov m\u00f4\u017eeme umiestni\u0165 do rackov, ko\u013eko \u00faloh by sme na nich spustili na z\u00e1klade starej modely \u201ejeden server = jedna \u00faloha\u201c a ako efekt\u00edvne by tak\u00e9 \u00falohy mohli vyu\u017ei\u0165 hardv\u00e9r. Vypo\u010d\u00edtali sme to \u2014 a vypla\u010deme sa. Uk\u00e1zalo sa, \u017ee efektivita vyu\u017eitia rackov je u n\u00e1s okolo 11 %. Z\u00e1ver je jasn\u00fd: je potrebn\u00e9 zv\u00fd\u0161i\u0165 efektivitu vyu\u017e\u00edvania d\u00e1tov\u00fdch centier. Na prv\u00fd poh\u013ead je rie\u0161enie jasn\u00e9: treba na jednom serveri spusti\u0165 viacero \u00faloh naraz. Ale tu za\u010d\u00ednaj\u00fa probl\u00e9my. <\/p>\n<p><\/p>\n<p>Hromadn\u00e1 konfigur\u00e1cia sa v\u00fdrazne komplikuje \u2014 teraz nie je mo\u017en\u00e9 priradi\u0165 serveru len jednu skupinu. Ve\u010f na jednom serveri m\u00f4\u017eu be\u017ea\u0165 viacer\u00e9 \u00falohy z r\u00f4znych t\u00edmov. Navy\u0161e m\u00f4\u017ee by\u0165 konfigur\u00e1cia konfliktuj\u00faca pre r\u00f4zne aplik\u00e1cie. Diagnostika je tie\u017e zlo\u017eit\u00e1: ak vid\u00edte zv\u00fd\u0161en\u00fa spotrebu procesorov alebo diskov na serveri, neviete, ktor\u00e1 z \u00faloh sp\u00f4sobuje probl\u00e9my.<\/p>\n<p><\/p>\n<p>Ale najd\u00f4le\u017eitej\u0161ie je, \u017ee medzi \u00falohami spusten\u00fdmi na jednom stroji nie je izol\u00e1cia. Napr\u00edklad, graf priemern\u00e9ho \u010dasu odpovede serverovej \u00falohy pred a po tom, ako sa na tom istom serveri spustila \u010fal\u0161ia, s prvou nes\u00favisiaca v\u00fdpo\u010dtov\u00e1 aplik\u00e1cia \u2014 \u010das odpovede hlavnej \u00falohy sa v\u00fdrazne zv\u00fd\u0161il.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/c7c07359ae572ca8c84a4c63559e4083.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Je zrejm\u00e9, \u017ee \u00falohy treba sp\u00fa\u0161\u0165a\u0165 bu\u010f v kontejnere, alebo vo virtu\u00e1lnych strojoch. Ke\u010f\u017ee takmer v\u0161etky \u00falohy sa u n\u00e1s sp\u00fa\u0161\u0165aj\u00fa pod jednou opera\u010dnou s\u00fastavou (Linux) alebo s\u00fa na \u0148u prisp\u00f4soben\u00e9, nie je potrebn\u00e9 podporova\u0165 mno\u017estvo r\u00f4znych opera\u010dn\u00fdch syst\u00e9mov. Pod\u013ea toho nie je potrebn\u00e1 virtualiz\u00e1cia, z d\u00f4vodu dodato\u010dn\u00fdch re\u017eijn\u00fdch n\u00e1kladov bude menej efekt\u00edvna ako kontajneriz\u00e1cia.<\/p>\n<p><\/p>\n<p>Ako implement\u00e1cia kontajnerov na sp\u00fa\u0161\u0165anie \u00faloh priamo na serveroch je Docker skvel\u00fdm kandid\u00e1tom: obrazy s\u00faborov\u00fdch syst\u00e9mov dobre rie\u0161ia probl\u00e9my s conflictuj\u00facimi konfigur\u00e1ciami. Mo\u017enos\u0165 zostavi\u0165 obrazy z viacer\u00fdch vrstiev n\u00e1m umo\u017e\u0148uje v\u00fdrazne zn\u00ed\u017ei\u0165 objem \u00fadajov potrebn\u00fdch na ich nasadenie v infra\u0161trukt\u00fare, pri\u010dom spolo\u010dn\u00e9 \u010dasti s\u00fa vy\u010dlenen\u00e9 do samostatn\u00fdch z\u00e1kladn\u00fdch vrstiev. T\u00fdm p\u00e1dom bud\u00fa z\u00e1kladn\u00e9 (a najobjemnej\u0161ie) vrstvy dostato\u010dne r\u00fdchlo vyrovn\u00e1van\u00e9 v celej infra\u0161trukt\u00fare a na dodanie mnoh\u00fdch r\u00f4znych typov aplik\u00e1ci\u00ed a verzi\u00ed sa bud\u00fa musie\u0165 pren\u00e1\u0161a\u0165 iba mal\u00e9 objemn\u00e9 vrstvy. <\/p>\n<p><\/p>\n<p>Navy\u0161e, hotov\u00fd registr a ozna\u010dovanie obrazov v Dockeri n\u00e1m poskytuj\u00fa z\u00e1kladn\u00e9 primit\u00edvy pre verzionovanie a dod\u00e1vanie k\u00f3du do produkcie.<\/p>\n<p><\/p>\n<p>Docker, rovnako ako ak\u00e1ko\u013evek in\u00e1 podobn\u00e1 technol\u00f3gia, n\u00e1m poskytuje ur\u010dit\u00fa \u00farove\u0148 izol\u00e1cie kontajnerov priamo z krabice. Napr\u00edklad, izol\u00e1cia pam\u00e4te \u2014 ka\u017ed\u00e9mu kontajneru je priraden\u00fd limit na pou\u017e\u00edvanie pam\u00e4te stroja, nad ktor\u00fa neprenikne. Rovnako je mo\u017en\u00e9 izolova\u0165 kontajnery pod\u013ea vyu\u017eitia CPU. Pre n\u00e1s v\u0161ak bola \u0161tandardn\u00e1 izol\u00e1cia nedostato\u010dn\u00e1. Ale o tom \u2014 ni\u017e\u0161ie.<\/p>\n<p><\/p>\n<p>Priame sp\u00fa\u0161\u0165anie kontajnerov na serveroch je len \u010das\u0165 probl\u00e9mov. \u010eal\u0161ia \u010das\u0165 s\u00favis\u00ed s umiestnen\u00edm kontajnerov na serveroch. Je potrebn\u00e9 zisti\u0165, ktor\u00fd kontajner m\u00f4\u017ee by\u0165 umiestnen\u00fd na akom serveri. To nie je tak\u00e1 jednoduch\u00e1 \u00faloha, preto\u017ee kontajnery je potrebn\u00e9 umiestni\u0165 na serveroch \u010do najhustej\u0161ie, pri\u010dom by sa nemala zni\u017eova\u0165 r\u00fdchlos\u0165 ich pr\u00e1ce. Tak\u00e9to umiestnenie m\u00f4\u017ee by\u0165 zlo\u017eit\u00fdm aj z h\u013eadiska odolnosti vo\u010di zlyhaniu. \u010casto chceme umiest\u0148ova\u0165 repliky tej istej slu\u017eby do r\u00f4znych rackov alebo dokonca do r\u00f4znych s\u00e1l d\u00e1tov\u00e9ho centra, aby sme pri zlyhan\u00ed racku alebo s\u00e1ly nestratili v\u0161etky repliky slu\u017eby naraz. <\/p>\n<p><\/p>\n<p>Ru\u010dn\u00e9 rozde\u013eovanie kontajnerov nie je mo\u017enos\u0165, ke\u010f m\u00e1\u0161 8 tis\u00edc serverov a 8\u201416 tis\u00edc kontajnerov. <\/p>\n<p><\/p>\n<p>Okrem toho sme chceli poskytn\u00fa\u0165 v\u00fdvoj\u00e1rom viac samostatnosti pri rozde\u013eovan\u00ed zdrojov, aby si mohli sami umiestni\u0165 svoje slu\u017eby do produkcie bez pomoci administr\u00e1tora. Pri tom sme chceli zachova\u0165 kontrolu, aby nejak\u00e1 ved\u013eaj\u0161ia slu\u017eba nepou\u017eila v\u0161etky zdroje na\u0161ich d\u00e1tov\u00fdch centier. <\/p>\n<p><\/p>\n<p>Je zrejm\u00e9, \u017ee potrebujeme riadiacu vrstvu, ktor\u00e1 by sa t\u00fdmto automaticky zaoberala.<\/p>\n<p><\/p>\n<p>Tu sme pri\u0161li k jednoduch\u00e9mu a preh\u013eadn\u00e9mu obrazu, ktor\u00fd v\u0161etci architekti miluj\u00fa: tri \u0161tvorec. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/079df6e79874ef55b0d967fde3d5feca.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>one-cloud masters \u2014 vysokodostupn\u00fd klaster zodpovedaj\u00faci za orchestr\u00e1ciu cloudu. V\u00fdvoj\u00e1r odosiela do mastera manifest, v ktorom je obsiahnut\u00e9 v\u0161etko potrebn\u00e9 na umiestnenie slu\u017eby. Master na jeho z\u00e1klade vyd\u00e1va pr\u00edkazy vybran\u00fdm minionom (strojom ur\u010den\u00fdm na sp\u00fa\u0161\u0165anie kontajnerov). Na minionoch je n\u00e1\u0161 agent, ktor\u00fd prij\u00edma pr\u00edkaz, vyd\u00e1va u\u017e svoje pr\u00edkazy Dockeru, a Docker konfiguruje linuxov\u00fd kernel na spustenie pr\u00edslu\u0161n\u00e9ho kontajnera. Okrem vykon\u00e1vania pr\u00edkazov agent neust\u00e1le informuje mastera o zmen\u00e1ch stavu ako minionovej ma\u0161iny, tak aj spusten\u00fdch na nej kontajnerov.<\/p>\n<p><\/p>\n<h2 id=\"raspredelenie-resursov\">Rozdelenie zdrojov<\/h2>\n<p><\/p>\n<p>A teraz sa pozrime na \u00falohu zlo\u017eitej\u0161ieho rozdelenia zdrojov pre mno\u017estvo minionov.<\/p>\n<p><\/p>\n<p>V\u00fdpo\u010dtov\u00fd zdroj v one-cloud \u2014 to je:<\/p>\n<p><\/p>\n<ul>\n<li>V\u00fdpo\u010dtov\u00fd v\u00fdkon procesora po\u017eadovan\u00fd konkr\u00e9tnou \u00falohou. <\/li>\n<li>Objem pam\u00e4te dostupn\u00fd \u00falohe. <\/li>\n<li>Sie\u0165ov\u00fd prenos. Ka\u017ed\u00fd z minionov m\u00e1 konkr\u00e9tny sie\u0165ov\u00fd rozhranie s obmedzenou prenosovou schopnos\u0165ou, tak\u017ee nie je mo\u017en\u00e9 rozde\u013eova\u0165 \u00falohy bez zoh\u013eadnenia objemu d\u00e1t pren\u00e1\u0161an\u00fdch cez sie\u0165. <\/li>\n<li>Disky. Okrem, samozrejme, miesta pre d\u00e1ta \u00falohy, tie\u017e ur\u010dujeme typ disku: HDD alebo SSD. Disky m\u00f4\u017eu obsl\u00fa\u017ei\u0165 kone\u010dn\u00e9 mno\u017estvo po\u017eiadaviek za sekundu \u2014 IOPS. Preto pre \u00falohy, generuj\u00face viac IOPS, ne\u017e m\u00f4\u017ee jeden disk obsl\u00fa\u017ei\u0165, rovnak\u00e9 \u201espindles\u201c \u2014 t.j. diskov\u00e9 zariadenia, ktor\u00e9 je potrebn\u00e9 v\u00fdlu\u010dne rezervova\u0165 pre \u00falohu.<\/li>\n<\/ul>\n<p><\/p>\n<p>Potom pre niektor\u00fa slu\u017ebu, napr\u00edklad pre user-cache, m\u00f4\u017eeme zap\u00edsa\u0165 po\u017eadovan\u00e9 zdroje takto: 400 procesorov\u00fdch jadier, 2,5 TB pam\u00e4te, 50 Gbit\/s prenosu v oboch smeroch, 6 TB miesta na HDD, umiestnen\u00e9ho na 100 spindloch. Alebo v n\u00e1m zn\u00e1mej\u0161ej forme takto:<\/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>Zdroje slu\u017eby user-cache spotreb\u00favaj\u00fa len \u010das\u0165 v\u0161etk\u00fdch dostupn\u00fdch zdrojov v produk\u010dnej infra\u0161trukt\u00fare. Preto chceme urobi\u0165 tak, aby n\u00e1hle, z d\u00f4vodu chyby oper\u00e1tora alebo nie, user-cache nespotreboval viac zdrojov, ne\u017e mu bolo pridelen\u00e9. Teda mus\u00edme limitova\u0165 zdroje. Ale na \u010do by sme mohli viaza\u0165 kv\u00f3tu?<\/p>\n<p><\/p>\n<p>Vr\u00e1\u0165me sa k na\u0161ej silne zjednodu\u0161enej sch\u00e9me interakcie komponentov a prekreslime to s v\u00e4\u010d\u0161\u00edm mno\u017estvom detailov \u2014 takto: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/27e5bfbffadd3d4b9fdc6bf138d135ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>To, \u010do najviac udrie do o\u010d\u00ed:<\/p>\n<p><\/p>\n<ul>\n<li>Webov\u00fd frontend a hudba pou\u017e\u00edvaj\u00fa izolovan\u00e9 klastre toho ist\u00e9ho aplika\u010dn\u00e9ho servera.<\/li>\n<li>M\u00f4\u017eeme vy\u010dleni\u0165 logick\u00e9 vrstvy, ku ktor\u00fdm tieto klastry patria: fronty, cache, vrstva ukladania a spr\u00e1vy \u00fadajov.<\/li>\n<li>Frontend nie je homog\u00e9nny, s\u00fa to r\u00f4zne funk\u010dn\u00e9 subsyst\u00e9my. <\/li>\n<li>Cache m\u00f4\u017eeme tie\u017e rozmiestni\u0165 pod\u013ea subsyst\u00e9mu, ktor\u00e9ho \u00fadaje cacheuj\u00fa.<\/li>\n<\/ul>\n<p><\/p>\n<p>E\u0161te raz prekresl\u00edme obr\u00e1zok:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/905dacc0aca859e65bd33ef751a557cf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>H\u013ea! Vid\u00edme hierarchiu! To znamen\u00e1, \u017ee m\u00f4\u017eeme rozde\u013eova\u0165 zdroje vo v\u00e4\u010d\u0161\u00edch celkoch: priradi\u0165 zodpovedn\u00e9ho v\u00fdvoj\u00e1ra na uzol tejto hierarchie, ktor\u00fd zodpoved\u00e1 funk\u010dn\u00e9mu subsyst\u00e9mu (ako \u00abmusic\u00bb na obr\u00e1zku), a k tomuto uzlu hierarchie priradi\u0165 kv\u00f3tu. Tak\u00e1to hierarchia n\u00e1m tie\u017e umo\u017e\u0148uje flexibilnej\u0161ie organizova\u0165 slu\u017eby pre pohodlie spr\u00e1vy. Napr\u00edklad v\u0161etky webov\u00e9 servery, ke\u010f\u017ee je to ve\u013emi ve\u013ek\u00e1 skupina serverov, del\u00edme na nieko\u013eko men\u0161\u00edch skup\u00edn, zn\u00e1zornen\u00fdch na obr\u00e1zku ako group1, group2.<\/p>\n<p><\/p>\n<p>Zbaven\u00edm sa nadbyto\u010dn\u00fdch \u010diar m\u00f4\u017eeme zap\u00edsa\u0165 ka\u017ed\u00fd uzol n\u00e1\u0161ho obr\u00e1zka v ploch\u0161ej forme: <strong>group1.web.front<\/strong>, <strong>api.music.front<\/strong>, <strong>user-cache.cache<\/strong>.<\/p>\n<p><\/p>\n<p>Tak dospejeme k pojmu \u201ehierarchick\u00e1 fronta\u201c. M\u00e1 svoje meno, ako \u201egroup1.web.front\u201c. Na \u0148u sa prira\u010fuje kv\u00f3ta na zdroje a pr\u00e1va pou\u017e\u00edvate\u013eov. Osobe z DevOps poskytneme pr\u00e1va na zasielanie slu\u017eby do fronty, a tak\u00fdto zamestnanec m\u00f4\u017ee sp\u00fa\u0161\u0165a\u0165 nie\u010do vo fronte, zatia\u013e \u010do osobu z OpsDev obdar\u00edme administr\u00e1torsk\u00fdmi pr\u00e1vami, pri\u010dom teraz m\u00f4\u017ee spravova\u0165 frontu, prira\u010fova\u0165 do nej \u013eud\u00ed, d\u00e1va\u0165 t\u00fdmto \u013eu\u010fom pr\u00e1va at\u010f. Slu\u017eby spusten\u00e9 v tejto fronte sa vykon\u00e1vaj\u00fa v r\u00e1mci kv\u00f3ty fronty. Ak je v\u00fdpo\u010dtov\u00e1 kv\u00f3ta fronty nedostato\u010dn\u00e1 na s\u00fa\u010dasn\u00e9 vykonanie v\u0161etk\u00fdch slu\u017eieb, bud\u00fa sa vykon\u00e1va\u0165 postupne, \u010d\u00edm sa vlastne vytvor\u00ed fronta. <\/p>\n<p><\/p>\n<p>Pozrime sa na slu\u017eby podrobnej\u0161ie. Slu\u017eba m\u00e1 cel\u00e9 meno, ktor\u00e9 v\u017edy obsahuje meno fronty. Tak slu\u017eba webov\u00e9ho frontu bude ma\u0165 n\u00e1zov <strong>ok-web.group1.web.front<\/strong>. A slu\u017eba aplika\u010dn\u00e9ho servera, na ktor\u00fa sa odkazuje, sa bude naz\u00fdva\u0165 <strong>ok-app.group1.web.front<\/strong>. Ka\u017ed\u00e1 slu\u017eba m\u00e1 manifest, v ktorom s\u00fa uveden\u00e9 v\u0161etky potrebn\u00e9 inform\u00e1cie na nasadenie na konkr\u00e9tnych strojoch: ko\u013eko zdrojov t\u00e1to \u00faloha spotrebuje, ak\u00e1 konfigur\u00e1cia je pre \u0148u potrebn\u00e1, ko\u013eko replik by malo by\u0165, vlastnosti na spracovanie ch\u00fdb tejto slu\u017eby. A po umiestnen\u00ed slu\u017eby priamo na strojoch sa objavuj\u00fa jej in\u0161tancie. Tieto s\u00fa tie\u017e jednozna\u010dne pomenovan\u00e9 \u2013 ako \u010d\u00edslo in\u0161tancie a meno slu\u017eby: <strong>1.ok-web.group1.web.front, 2.ok-web.group1.web.front, \u2026<\/strong><\/p>\n<p><\/p>\n<p>To je ve\u013emi pohodln\u00e9: len poh\u013eadom na meno spusten\u00e9ho kontajnera m\u00f4\u017eeme okam\u017eite zisti\u0165 ve\u013ea vec\u00ed.<\/p>\n<p><\/p>\n<p>A teraz sa bli\u017e\u0161ie zozn\u00e1mime s t\u00fdm, \u010do tieto in\u0161tancie vlastne vykon\u00e1vaj\u00fa: s \u00falohami.<\/p>\n<p><\/p>\n<h2 id=\"klassy-izolyacii-zadach\">Klasifik\u00e1cia izol\u00e1cie \u00faloh<\/h2>\n<p><\/p>\n<p>V\u0161etky \u00falohy v O\u041a (a pravdepodobne kdeko\u013evek inde) m\u00f4\u017eu by\u0165 rozdelen\u00e9 do skup\u00edn:<\/p>\n<p><\/p>\n<ul>\n<li><strong>\u00dalohy s kr\u00e1tkou latenciou \u2013 prod<\/strong>. Pre tak\u00e9to \u00falohy a slu\u017eby je ve\u013emi d\u00f4le\u017eit\u00e9 oneskorenie odpovede (latencia), ako r\u00fdchlo bude ka\u017ed\u00fd z dopytov syst\u00e9mom spracovan\u00fd. Pr\u00edklady \u00faloh: webov\u00e9 fronty, cache, aplika\u010dn\u00e9 servery, OLTP \u00falo\u017eisk\u00e1 a pod.<\/li>\n<li><strong>V\u00fdpo\u010dtov\u00e9 \u00falohy \u2013 batch<\/strong>. Tu na r\u00fdchlosti spracovania ka\u017ed\u00e9ho konkr\u00e9tneho dopytu nez\u00e1le\u017e\u00ed. Pre nich je d\u00f4le\u017eit\u00e9, ko\u013eko celkov\u00fdch v\u00fdpo\u010dtov za ur\u010dit\u00fd (ve\u013ek\u00fd) \u010dasov\u00fd \u00fasek t\u00e1to \u00faloha vykon\u00e1 (priepustnos\u0165). Tak\u00e9to bud\u00fa ak\u00e9ko\u013evek \u00falohy MapReduce, Hadoop, strojov\u00e9 u\u010denie, \u0161tatistika.<\/li>\n<li><strong>Pozadie \u00falohy \u2013 idle<\/strong>. Pre tak\u00e9to \u00falohy nie je d\u00f4le\u017eit\u00e9 ani latency, ani throughput. Sem patr\u00ed r\u00f4zne testovanie, migr\u00e1cie, prepo\u010dty, konverzie d\u00e1t z jedn\u00e9ho form\u00e1tu do druh\u00e9ho. Na jednej strane s\u00fa podobn\u00e9 v\u00fdpo\u010dtov\u00fdm, na druhej strane n\u00e1m ve\u013emi nez\u00e1le\u017e\u00ed na ich r\u00fdchlom dokon\u010den\u00ed. <\/li>\n<\/ul>\n<p><\/p>\n<p>Pozrime sa, ako tieto \u00falohy spotrebov\u00e1vaj\u00fa zdroje, napr\u00edklad centr\u00e1lneho procesora.<\/p>\n<p><\/p>\n<p><strong>\u00dalohy s kr\u00e1tkou latenciou.<\/strong> \u00daloha s tak\u00fdmto modelom spotreby CPU bude vyzera\u0165 asi takto:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/1ed82c0df76325eb30056ad9af86e86e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Na spracovanie sa prij\u00edma dopyt od pou\u017e\u00edvate\u013ea, \u00faloha za\u010dne vyu\u017e\u00edva\u0165 v\u0161etky dostupn\u00e9 jadr\u00e1 CPU, spracuje, vr\u00e1ti odpove\u010f, \u010dak\u00e1 na \u010fal\u0161\u00ed dopyt a stoj\u00ed. Pri\u0161iel \u010fal\u0161\u00ed dopyt \u2013 op\u00e4\u0165 vyu\u017eila v\u0161etko, \u010do bolo, vypo\u010d\u00edtala, \u010dak\u00e1me na \u010fal\u0161\u00ed.<\/p>\n<p><\/p>\n<p>Aby sme zaru\u010dili minim\u00e1lne oneskorenie pre tak\u00fato \u00falohu, mus\u00edme vzia\u0165 maximum spotrebovan\u00fdch zdrojov a rezervova\u0165 potrebn\u00fd po\u010det jadier na minione (stroji, ktor\u00fd bude \u00falohu vykon\u00e1va\u0165). Potom bude rezerva\u010dn\u00e1 formula pre na\u0161u \u00falohu vyzera\u0165 takto:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = 4 (max)<\/code><\/pre>\n<p><\/p>\n<p>A ak m\u00e1me minion stroj so 16 jadrami, m\u00f4\u017eeme na \u0148om umiestni\u0165 presne \u0161tyri tak\u00e9to \u00falohy. Osobitne zd\u00f4raz\u0148ujeme, \u017ee priemern\u00e1 spotreba procesora t\u00fdchto \u00faloh je \u010dasto ve\u013emi n\u00edzka \u2014 \u010do je zrejm\u00e9, preto\u017ee v\u00e4\u010d\u0161inu \u010dasu \u00faloha \u010dak\u00e1 na po\u017eiadavku a ni\u010d nerob\u00ed.<\/p>\n<p><\/p>\n<p><strong>V\u00fdpo\u010dtov\u00e9 \u00falohy.<\/strong> Ich vzor bude o nie\u010do odli\u0161n\u00fd:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/35b37fa1d70a137287cafdbfe3bcfc2e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Priemern\u00e1 spotreba procesorov\u00fdch zdrojov t\u00fdchto \u00faloh je dostato\u010dne vysok\u00e1. \u010casto chceme, aby v\u00fdpo\u010dtov\u00e1 \u00faloha bola vykonan\u00e1 v ur\u010ditom \u010dase, preto je potrebn\u00e9 rezervova\u0165 minim\u00e1lny po\u010det procesorov, ktor\u00fd je potrebn\u00fd na to, aby sa cel\u00fd v\u00fdpo\u010det dokon\u010dil v prijate\u013enom \u010dase. Jej rezerva\u010dn\u00e1 formula bude vyzera\u0165 takto:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = [1,*)<\/code><\/pre>\n<p><\/p>\n<p><em>\u201eUmiestni, pros\u00edm, na minione, kde je aspo\u0148 jedno vo\u013en\u00e9 jadro, a \u010falej ko\u013eko je \u2014 v\u0161etko zje.\u201c<\/em><\/p>\n<p><\/p>\n<p>Tu je efekt\u00edvnos\u0165 vyu\u017eitia u\u017e ove\u013ea lep\u0161ia ako pri \u00faloh\u00e1ch s kr\u00e1tkou latenciou. Ale zisk bude omnoho v\u00e4\u010d\u0161\u00ed, ak skombinujeme oba typy \u00faloh na jednom minion stroji a budeme dynamicky rozde\u013eova\u0165 jej zdroje. Ke\u010f \u00faloha s kr\u00e1tkou latenciou potrebuje procesor \u2014 dostane ho okam\u017eite, a ke\u010f s\u00fa zdroje nepotrebn\u00e9 \u2014 prejd\u00fa na v\u00fdpo\u010dtov\u00fa \u00falohu, t.j. nejako takto:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/875ad8d3f6a01e4fd0a89d0931e986c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ale ako to spravi\u0165?<\/p>\n<p><\/p>\n<p>Pre za\u010diatok sa pozrime na prod a jeho alloc: cpu = 4. Mus\u00edme rezervova\u0165 \u0161tyri jadra. V Docker run to m\u00f4\u017eeme urobi\u0165 dvoma sp\u00f4sobmi: <\/p>\n<p><\/p>\n<ul>\n<li>Pomocou vo\u013eby <code>--cpuset=1-4<\/code>, t.j. priradi\u0165 \u00falohe \u0161tyri konkr\u00e9tne jadra na stroji.<\/li>\n<li>Pou\u017ei\u0165 <code>--cpuquota=400_000 --cpuperiod=100_000<\/code>, priradi\u0165 kv\u00f3tu na procesorov\u00fd \u010das, t.j. ur\u010di\u0165, \u017ee ka\u017ed\u00fdch 100 ms re\u00e1lneho \u010dasu \u00faloha spotrebuje maxim\u00e1lne 400 ms procesorov\u00e9ho \u010dasu. Vznikn\u00fa tie ist\u00e9 \u0161tyri jadra. <\/li>\n<\/ul>\n<p><\/p>\n<p>Ale ktor\u00fd z t\u00fdchto sp\u00f4sobov sa hod\u00ed?<\/p>\n<p><\/p>\n<p>Cpuset vyzer\u00e1 celkom atrakt\u00edvne. \u00daloha m\u00e1 \u0161tyri vyhraden\u00e9 jadr\u00e1, \u010do znamen\u00e1, \u017ee cache procesora bude fungova\u0165 maxim\u00e1lne efekt\u00edvne. M\u00e1 to v\u0161ak aj svoju odvr\u00e1ten\u00fa str\u00e1nku: museli by sme prevzia\u0165 zodpovednos\u0165 za rozdelenie v\u00fdpo\u010dtov medzi nezapojen\u00e9 jadr\u00e1 stroja namiesto opera\u010dn\u00e9ho syst\u00e9mu, \u010do je dos\u0165 zlo\u017eit\u00e1 \u00faloha, najm\u00e4 ak sa pok\u00fasime umiestni\u0165 na tak\u00fdto stroj batch \u00falohy. Testy uk\u00e1zali, \u017ee tu lep\u0161ie vyhovuje varianta s kv\u00f3tou: tak m\u00e1 opera\u010dn\u00fd syst\u00e9m v\u00e4\u010d\u0161iu slobodu pri v\u00fdbere jadra pre vykonanie \u00falohy v danom okamihu a procesorov\u00fd \u010das sa rozde\u013euje efekt\u00edvnej\u0161ie.<\/p>\n<p><\/p>\n<p>Pozrime sa, ako v dockeri urobi\u0165 rezerv\u00e1ciu na minim\u00e1lny po\u010det jadier. Kv\u00f3ta pre batch \u00falohy u\u017e nie je pou\u017eite\u013en\u00e1, preto\u017ee obmedzi\u0165 maximum nie je potrebn\u00e9, sta\u010d\u00ed zaru\u010di\u0165 minimum. A tu dobre vyhovuje mo\u017enos\u0165 <code>docker run --cpushares<\/code>.<\/p>\n<p><\/p>\n<p>Dohodli sme sa, \u017ee ak batch vy\u017eaduje z\u00e1ruku minim\u00e1lneho jedn\u00e9ho jadra, uvedieme <code>--cpushares=1024<\/code>, a ak minimum na dve jadr\u00e1, uvedieme <code>--cpushares=2048<\/code>. Cpu shares nijako nezasahuj\u00fa do rozdelenia procesorov\u00e9ho \u010dasu, pokia\u013e je ho dostatok. Tak\u017ee, ak prod moment\u00e1lne nevyu\u017e\u00edva v\u0161etky svoje \u0161tyri jadr\u00e1, batch \u00falohy nemaj\u00fa \u017eiadne obmedzenia a m\u00f4\u017eu vyu\u017ei\u0165 \u010fal\u0161\u00ed procesorov\u00fd \u010das. Av\u0161ak v situ\u00e1cii nedostatku procesora, ak prod spotreboval v\u0161etky svoje \u0161tyri jadr\u00e1 a narazil na kv\u00f3tu, zost\u00e1vaj\u00faci procesorov\u00fd \u010das sa rozdel\u00ed proporcion\u00e1lne pod\u013ea cpushares, t. j. v situ\u00e1cii troch vo\u013en\u00fdch jadier jedno z\u00edska \u00faloha s 1024 cpushares, a ostatn\u00e9 dve \u00falohy s 2048 cpushares.<\/p>\n<p><\/p>\n<p>Ale pou\u017e\u00edvanie kv\u00f3ty a shares nesta\u010d\u00ed. Mus\u00edme zabezpe\u010di\u0165, aby \u00faloha s kr\u00e1tkym oneskoren\u00edm mala prioritu pred batch \u00falohou pri rozdelen\u00ed procesorov\u00e9ho \u010dasu. Bez takejto prioritiz\u00e1cie bude batch \u00faloha zaberaj\u00faca v\u0161etok procesorov\u00fd \u010das v momente, ke\u010f je potrebn\u00fd pre prod. V Docker run nie s\u00fa \u017eiadne mo\u017enosti prioritiz\u00e1cie kontajnerov, ale prich\u00e1dzaj\u00fa na pomoc politiky pl\u00e1nova\u010da centr\u00e1lneho procesora v Linuxe. O nich sa d\u00e1 podrobne pre\u010d\u00edta\u0165 <noindex><a rel=\"nofollow\" href=\"http:\/\/man7.org\/linux\/man-pages\/man2\/sched_setscheduler.2.html\">tu<\/a><\/noindex>, a v r\u00e1mci tohto \u010dl\u00e1nku sa nimi prejdeme stru\u010dne:<\/p>\n<p><\/p>\n<ul>\n<li><strong>SCHED_OTHER<\/strong><br \/>\nPredvolene z\u00edskavaj\u00fa v\u0161etky be\u017en\u00e9 pou\u017e\u00edvate\u013esk\u00e9 procesy na Linuxovom stroji.<\/li>\n<li><strong>SCHED_BATCH<\/strong><br \/>\nUr\u010den\u00e9 pre n\u00e1ro\u010dn\u00e9 procesy. Pri umiestnen\u00ed \u00falohy do procesora sa zav\u00e1dza takzvan\u00fd trest za aktiv\u00e1ciu: tak\u00e1 \u00faloha s men\u0161ou pravdepodobnos\u0165ou z\u00edska zdroje procesora, ak je v danom momente aktu\u00e1lne pou\u017e\u00edvan\u00e1 \u00falohou so SCHED_OTHER<\/li>\n<li><strong>SCHED_IDLE<\/strong><br \/>\nPozadie s ve\u013emi n\u00edzkou prioritou, dokonca ni\u017e\u0161ou ako nice \u201319. Pou\u017e\u00edvame na\u0161u kni\u017enicu s otvoren\u00fdm k\u00f3dom <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/odnoklassniki\/one-nio\">one-nio<\/a><\/noindex>, aby sme nastavili po\u017eadovan\u00fa politiku pri spusten\u00ed kontajnera volan\u00edm<\/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>Ale aj ke\u010f neprogramujete v Jave, to ist\u00e9 m\u00f4\u017eete urobi\u0165 pomocou pr\u00edkazu chrt:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">chrt -i 0 $pid<\/code><\/pre>\n<p><\/p>\n<p>Zhrnieme v\u0161etky na\u0161e \u00farovne izol\u00e1cie do jednej tabu\u013eky pre preh\u013eadnos\u0165:<\/p>\n<p><\/p>\n<p>Trieda izol\u00e1cie<br \/>\nPr\u00edklad 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>*Ak vykon\u00e1vate chrt zvn\u00fatra kontajnera, m\u00f4\u017ee by\u0165 potrebn\u00e1 opr\u00e1vnenie sys_nice, preto\u017ee Docker toto opr\u00e1vnenie predvolene odn\u00edma pri spusten\u00ed kontajnera.<\/p>\n<p><\/p>\n<p>Ale \u00falohy spotrebov\u00e1vaj\u00fa nielen procesor, ale aj prenos, ktor\u00fd m\u00e1 e\u0161te v\u00e4\u010d\u0161\u00ed vplyv na oneskorenie sie\u0165ovej \u00falohy ne\u017e nespr\u00e1vne rozdelenie zdrojov procesora. Preto chceme ma\u0165 obraz aj pre prenos. To znamen\u00e1, \u017ee ke\u010f prod-\u00faloha odosiela nejak\u00e9 pakety do siete, obmedzujeme maxim\u00e1lnu r\u00fdchlos\u0165 (vzorec <em>alloc: lan=[*,500mbps)<\/em> ), s ktorou prod m\u00f4\u017ee robi\u0165. Pre batch garantujeme len minim\u00e1lny prenos, ale neobmedzujeme maxim\u00e1lnu (vzorec <em>alloc: lan=[10Mbps,*)<\/em> ) V tomto pr\u00edpade by mal ma\u0165 prenos prod prioritu pred batch-\u00falohami.<br \/>\nTu Docker nem\u00e1 \u017eiadne primit\u00edva, ktor\u00e9 by sme mohli pou\u017ei\u0165. Ale pom\u00e1ha n\u00e1m <noindex><a rel=\"nofollow\" href=\"http:\/\/lartc.org\/\">Linux Traffic Control<\/a><\/noindex>. Podarilo sa n\u00e1m dosiahnu\u0165 po\u017eadovan\u00fd v\u00fdsledok pomocou discipl\u00edny <noindex><a rel=\"nofollow\" href=\"http:\/\/linux-ip.net\/articles\/hfsc.en\/\">Hierarchical Fair Service Curve<\/a><\/noindex>. S jej pomocou vy\u010dle\u0148ujeme dve triedy prenosu: vysoko-prioritn\u00fd prod a n\u00edzko-prioritn\u00fd batch\/idle. Nakoniec konfigur\u00e1cia pre odch\u00e1dzaj\u00faci prenos vyzer\u00e1 takto:<\/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 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/3f52a968118b6021bd0c920af17a00c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>tu 1:0 \u2014 &#171;korenn\u00fd qdisc&#187; discipl\u00edny hsfc; 1:1 \u2014 podtrieda hsfc s celkov\u00fdm limitom priepustnosti 8 Gbit\/s, pod ktor\u00fa spadaj\u00fa podtriedy v\u0161etk\u00fdch kontajnerov; 1:2 \u2014 podtrieda hsfc spolo\u010dn\u00e1 pre v\u0161etky batch a idle \u00falohy s &#171;dynamick\u00fdm&#187; limitom, o ktorom sa hovor\u00ed ni\u017e\u0161ie. Ostatn\u00e9 podtriedy hsfc s\u00fa ur\u010den\u00e9 triedy pre aktu\u00e1lne be\u017eiace prod-kontajnery s limitmi, ktor\u00e9 zodpovedaj\u00fa ich manifestom \u2014 450 a 400 Mbit\/s. Ka\u017edej triede hsfc je priraden\u00e1 qdisc fronta fq alebo fq_codel, v z\u00e1vislosti od verzie jadra linux, aby sa predi\u0161lo strat\u00e1m paketov pri n\u00e1razoch v doprave. <\/p>\n<p><\/p>\n<p>Obvykle discipl\u00edny tc sl\u00fa\u017eia na prioriz\u00e1ciu len odch\u00e1dzaj\u00facej prev\u00e1dzky. Ale chceme priorizova\u0165 aj prich\u00e1dzaj\u00facu prev\u00e1dzku, preto\u017ee nejak\u00e1 batch-\u00faloha m\u00f4\u017ee \u013eahko vyu\u017ei\u0165 cel\u00fd prich\u00e1dzaj\u00faci kan\u00e1l a z\u00edska\u0165 tak ve\u013ek\u00fd bal\u00edk prich\u00e1dzaj\u00facich \u00fadajov pre map&amp;reduce. Na to pou\u017e\u00edvame modul <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/350023\/tc-ingress-policing-and-ifb-mirroring\">ifb<\/a><\/noindex>, ktor\u00fd vytv\u00e1ra virtu\u00e1lne rozhranie ifbX pre ka\u017ed\u00fd sie\u0165ov\u00fd rozhranie a presmerov\u00e1va prich\u00e1dzaj\u00facu prev\u00e1dzku z rozhrania do odch\u00e1dzaj\u00facej prev\u00e1dzky na ifbX. Potom pre ifbX funguj\u00fa v\u0161etky tieto discipl\u00edny na kontrolu odch\u00e1dzaj\u00facej prev\u00e1dzky, pri\u010dom konfigur\u00e1cia hsfc bude ve\u013emi podobn\u00e1:<\/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 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/967da9c0637cc70ba195af781db18adf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Po\u010das experimentov sme zistili, \u017ee najlep\u0161ie v\u00fdsledky hsfc dosahuje, ke\u010f je trieda 1:2 neppriorizovanej batch\/idle prev\u00e1dzky obmedzen\u00e1 na strojoch-minionoch na nie viac ako ur\u010dit\u00fa vo\u013en\u00fa p\u00e1smo. Inak neppriorizovan\u00e1 prev\u00e1dzka pr\u00edli\u0161 silno ovplyv\u0148uje latenciu prod-\u00faloh. Aktu\u00e1lnu hodnotu vo\u013en\u00e9ho p\u00e1sma miniond ur\u010duje ka\u017ed\u00fa sekundu, meraj\u00faci priemern\u00fa spotrebu prev\u00e1dzky v\u0161etk\u00fdmi prod-\u00falohami dan\u00e9ho miniona <img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/9d6f38110d3b1693afe222b01430b9bb.jpg\" style=\"display:block;margin: 0 auto;\" \/> a od\u010d\u00edtava ju z priepustnosti sie\u0165ov\u00e9ho rozhrania <img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/d5608ec4c58e44b8571ab0b1d0cc7701.jpg\" style=\"display:block;margin: 0 auto;\" \/> s malou rezervou, t.j.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/fb01347c2224bd5bbd82169861eeb7e4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>P\u00e1sma s\u00fa ur\u010den\u00e9 pre prich\u00e1dzaj\u00facu a odch\u00e1dzaj\u00facu prev\u00e1dzku nez\u00e1visle. A v s\u00falade s nov\u00fdmi hodnotami miniond rekonfiguruje limit neppriorizovanej triedy 1:2.<\/p>\n<p><\/p>\n<p>Takto sme implementovali v\u0161etky tri triedy izol\u00e1cie: prod, batch a idle. Tieto triedy maj\u00fa z\u00e1sadn\u00fd vplyv na v\u00fdkon \u00faloh. Preto sme sa rozhodli umiestni\u0165 tento atrib\u00fat na vrchol hierarchie, aby pri poh\u013eade na meno hierarchickej fronty bolo jasn\u00e9, s \u010d\u00edm m\u00e1me do\u010dinenia: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/34dc89c461db711b19a0f4eccc50efce.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>V\u0161etky na\u0161e zn\u00e1me <strong>web<\/strong> a <strong>music<\/strong> fronty s\u00fa umiestnen\u00e9 v hierarchii pod prod. Pre pr\u00edklad pod batch umiestnime slu\u017ebu <strong>music catalog<\/strong>, ktor\u00fd pravidelne zostavuje katal\u00f3g skladieb z mno\u017einy nahran\u00fdch mp3 s\u00faborov na \u201eOdnoklassniki\u201c. Pr\u00edkladom slu\u017eby pre idle m\u00f4\u017ee by\u0165 <strong>transform\u00e1tor hudby<\/strong>, ktor\u00fd normalizuje \u00farove\u0148 hlasitosti hudby.<\/p>\n<p><\/p>\n<p>Op\u00e4\u0165 sme odstr\u00e1nili nadbyto\u010dn\u00e9 riadky, m\u00f4\u017eeme zap\u00edsa\u0165 n\u00e1zvy na\u0161ich slu\u017eieb ploch\u0161ie, dop\u00edsa\u0165 triedu izol\u00e1cie \u00falohy na koniec \u00fapln\u00e9ho n\u00e1zvu slu\u017eby: <strong>web.front.prod<\/strong>, <strong>catalog.music.batch<\/strong>, <strong>transformer.music.idle<\/strong>.<\/p>\n<p><\/p>\n<p>A teraz, ke\u010f sa pozrieme na n\u00e1zov slu\u017eby, ch\u00e1peme nielen to, ak\u00fa funkciu vykon\u00e1va, ale aj jej triedu izol\u00e1cie, \u010do znamen\u00e1, jej kritickos\u0165 a pod.<\/p>\n<p><\/p>\n<p>V\u0161etko je skvel\u00e9, ale existuje jedna bolestn\u00e1 pravda. \u00daplne izolova\u0165 \u00falohy, ktor\u00e9 be\u017eia na jednom stroji, nie je mo\u017en\u00e9.<\/p>\n<p><\/p>\n<p>\u010co sa n\u00e1m podarilo dosiahnu\u0165: ak batch intenz\u00edvne spotrebov\u00e1va <strong>iba<\/strong> procesorov\u00e9 zdroje, tak integrovan\u00fd pl\u00e1nova\u010d CPU Linux si ve\u013emi dobre pln\u00ed svoju \u00falohu, a vplyv na prod-\u00falohu je takmer \u017eiadny. Ale ak t\u00e1to batch-\u00faloha za\u010dne akt\u00edvne pracova\u0165 s pam\u00e4\u0165ou, vz\u00e1jomn\u00fd vplyv sa u\u017e prejavuje. D\u00f4vodom je, \u017ee pri prod-\u00falohe sa \u201evysu\u0161uj\u00fa\u201c procesorov\u00e9 cache pam\u00e4te \u2014 v d\u00f4sledku toho sa v cache zvy\u0161uj\u00fa z\u00e1sahy, a procesor spracov\u00e1va prod-\u00falohu pomal\u0161ie. Tak\u00e1 batch-\u00faloha m\u00f4\u017ee o 10 % zv\u00fd\u0161i\u0165 oneskorenia na\u0161ich typick\u00fdch prod-kontejnerov.<\/p>\n<p><\/p>\n<p>Izolova\u0165 prenos je e\u0161te \u0165a\u017e\u0161ie, preto\u017ee modern\u00e9 sie\u0165ov\u00e9 karty maj\u00fa vn\u00fatorn\u00fa frontu paketov. Ak paket od batch-\u00falohy sa dostane do fronty ako prv\u00fd, znamen\u00e1 to, \u017ee bude odoslan\u00fd po k\u00e1bli ako prv\u00fd, a s t\u00fdm sa ned\u00e1 ni\u010d robi\u0165.<\/p>\n<p><\/p>\n<p>Okrem toho sa n\u00e1m zatia\u013e podarilo rie\u0161i\u0165 iba probl\u00e9m prioritiz\u00e1cie TCP-prenosu: pre UDP pr\u00edstup s hsfc nefunguje. A dokonca aj v pr\u00edpade TCP-prenosu, ak batch-\u00faloha generuje ve\u013ea prenosu, to tie\u017e zvy\u0161uje oneskorenie prod-\u00falohy o pribli\u017ene 10 %.<\/p>\n<p><\/p>\n<h2 id=\"otkazoustoychivost\">Odolnos\u0165 vo\u010di zlyhaniam<\/h2>\n<p><\/p>\n<p>Jedn\u00fdm z cie\u013eov pri v\u00fdvoji one-cloud bolo zlep\u0161i\u0165 odolnos\u0165 vo\u010di poruch\u00e1m Odnoklassnikov. Preto by som sa r\u00e1d podrobnej\u0161ie pozrel na mo\u017en\u00e9 scen\u00e1re zlyhania a hav\u00e1rie. Po\u010fme za\u010da\u0165 s jednoduch\u00fdm scen\u00e1rom \u2014 so zlyhan\u00edm kontajnera. <\/p>\n<p><\/p>\n<p>Kontajner s\u00e1m o sebe m\u00f4\u017ee zlyha\u0165 nieko\u013ek\u00fdmi sp\u00f4sobmi. M\u00f4\u017ee to by\u0165 nejak\u00fd experiment, bug alebo chyba v manifeste, kv\u00f4li ktorej prod-\u00faloha za\u010dne spotrebov\u00e1va\u0165 viac zdrojov, ne\u017e je uveden\u00e9 v manifeste. Mali sme pr\u00edpad: v\u00fdvoj\u00e1r implementoval jeden zlo\u017eit\u00fd algoritmus, ve\u013ea r\u00e1z ho prepracov\u00e1val, a\u017e sa tak zamot\u00e1val, \u017ee nakoniec \u00faloha sa stala dos\u0165 netrivi\u00e1lne cyklickou. A ke\u010f\u017ee prod-\u00faloha m\u00e1 vy\u0161\u0161iu prioritu ne\u017e v\u0161etky ostatn\u00e9 na rovnak\u00fdch mini\u00f3noch, za\u010dala spotrebov\u00e1va\u0165 v\u0161etky dostupn\u00e9 prostriedky procesora. V tejto situ\u00e1cii n\u00e1s zachr\u00e1nila izol\u00e1cia, sk\u00f4r konkr\u00e9tne kv\u00f3ta na procesorov\u00fd \u010das. Ak m\u00e1 \u00faloha pridelen\u00fa kv\u00f3tu, \u00faloha nespotrebuje viac. Preto batch- a in\u00e9 prod-\u00falohy, ktor\u00e9 pracovali na tej istej ma\u0161ine, si ni\u010d nev\u0161imli. <\/p>\n<p><\/p>\n<p>Druh\u00e1 mo\u017en\u00e1 nepr\u00edjemnos\u0165 \u2014 p\u00e1d kontajnera. A tu n\u00e1s zachra\u0148uj\u00fa politiky re\u0161tartu, s ktor\u00fdmi s\u00fa v\u0161etci obozn\u00e1men\u00ed, Docker si s t\u00fdm dokonale porad\u00ed. Takmer v\u0161etky prod-\u00falohy maj\u00fa politiku re\u0161tartu always. Niekedy pou\u017e\u00edvame on_failure pre batch-\u00falohy alebo na ladenie prod-kontajnerov.<\/p>\n<p><\/p>\n<p>A \u010do m\u00f4\u017eeme urobi\u0165 v pr\u00edpade nedostupnosti cel\u00e9ho mini\u00f3na?<\/p>\n<p><\/p>\n<p>O\u010dividne spusti\u0165 kontajner na inom stroji. Najzauj\u00edmavej\u0161ie tu je, \u010do sa deje s IP adresou (adresami) pridelen\u00fdmi kontajneru. <\/p>\n<p><\/p>\n<p>M\u00f4\u017eeme kontajnerom prira\u010fova\u0165 rovnak\u00e9 IP adresy, ak\u00e9 maj\u00fa stroje-mini\u00f3ny, na ktor\u00fdch s\u00fa tieto kontajnery spusten\u00e9. Potom pri spusten\u00ed kontajnera na inom stroji sa jeho IP adresa men\u00ed a v\u0161etci klienti musia pochopi\u0165, \u017ee kontajner sa pres\u0165ahoval, a teraz je potrebn\u00e9 nav\u0161tevova\u0165 in\u00fa adresu, \u010do si vy\u017eaduje samostatn\u00fa slu\u017ebu Service Discovery. <\/p>\n<p><\/p>\n<p>Service Discovery \u2014 to je praktick\u00e9. Na trhu je ve\u013ea rie\u0161en\u00ed s r\u00f4znou mierou odolnosti vo\u010di poruch\u00e1m na organiz\u00e1ciu registra slu\u017eieb. \u010casto v tak\u00fdchto rie\u0161eniach sa implementuje logika vyva\u017eova\u010da z\u00e1\u0165a\u017ee, uchov\u00e1vanie dodato\u010dnej konfigur\u00e1cie vo forme KV-store at\u010f.<br \/>\nAv\u0161ak, radi by sme sa obi\u0161li bez nutnosti zav\u00e1dzania samostatn\u00e9ho registra, preto\u017ee by to znamenalo zavedenie kritick\u00e9ho syst\u00e9mu, ktor\u00fd pou\u017e\u00edvaj\u00fa v\u0161etky slu\u017eby v produkcii. A to znamen\u00e1, \u017ee je to potenci\u00e1lny bod zlyhania, a treba vybra\u0165 alebo vyvin\u00fa\u0165 ve\u013emi odoln\u00e9 rie\u0161enie, \u010do je o\u010dividne ve\u013emi zlo\u017eit\u00e9, \u010dasovo n\u00e1ro\u010dn\u00e9 a drah\u00e9. <\/p>\n<p><\/p>\n<p>A \u010fal\u0161\u00edm ve\u013ek\u00fdm nedostatkom je, \u017ee aby na\u0161a star\u00e1 infra\u0161trukt\u00fara fungovala s novou, museli by sme prepracova\u0165 v\u0161etky \u00falohy tak, aby vyu\u017e\u00edvali nejak\u00fd syst\u00e9m Service Discovery. Pr\u00e1ce by bolo VE\u013dMI mnoho a miestami by to bolo takmer nemo\u017en\u00e9, ke\u010f ide o n\u00edzko\u00farov\u0148ov\u00e9 zariadenia pracuj\u00face na \u00farovni opera\u010dn\u00e9ho syst\u00e9mu alebo priamo so schopnos\u0165ami hardv\u00e9ru. Implement\u00e1cia tejto funkcionality prostredn\u00edctvom ust\u00e1len\u00fdch vzorov rie\u0161en\u00ed, ako napr\u00edklad <noindex><a rel=\"nofollow\" href=\"https:\/\/linkerd.io\">side-car<\/a><\/noindex> by v niektor\u00fdch pr\u00edpadoch znamenala dodato\u010dn\u00e9 za\u0165a\u017eenie, v in\u00fdch by to skomplikovalo prev\u00e1dzku a vytvorilo nov\u00e9 sc\u00e9n\u00e1re zlyhania. Nechceli sme to komplikova\u0165, preto sme sa rozhodli, \u017ee pou\u017eitie Service Discovery bude volite\u013en\u00e9. <\/p>\n<p><\/p>\n<p>V one-cloud IP nasleduje za kontajnerom, t. j. ka\u017ed\u00fd pr\u00edpad \u00falohy m\u00e1 svoju vlastn\u00fa IP adresu. T\u00e1to adresa je \u201estatick\u00e1\u201c: je priraden\u00e1 ka\u017ed\u00e9mu pr\u00edpadom pri prvom odoslan\u00ed slu\u017eby do cloudu. Ak mala slu\u017eba po\u010das svojej existencie r\u00f4zne po\u010dty pr\u00edpadov, tak v kone\u010dnom d\u00f4sledku bude ma\u0165 pridelen\u00e9 to\u013eko IP adries, ko\u013eko maxim\u00e1lne bolo pr\u00edpadov.<\/p>\n<p><\/p>\n<p>N\u00e1sledne sa tieto adresy nemenia: s\u00fa priraden\u00e9 raz a pokra\u010duj\u00fa v existencii po\u010das celej doby slu\u017eby v produkcii. IP adresy sleduj\u00fa kontajnery cez sie\u0165. Ak sa kontajner presunie na in\u00fd minion, adresa sa presunie s n\u00edm. <\/p>\n<p><\/p>\n<p>T\u00fdmto sp\u00f4sobom sa zmena mapovania mena slu\u017eby na zoznam jej IP adries vyskytuje ve\u013emi zriedka. Ak sa znova pozrieme na men\u00e1 pr\u00edpadov slu\u017eby, o ktor\u00fdch sme hovorili na za\u010diatku \u010dl\u00e1nku (<strong>1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, \u2026<\/strong>), v\u0161imneme si, \u017ee pripom\u00ednaj\u00fa FQDN pou\u017e\u00edvan\u00e9 v DNS. A skuto\u010dne, na zobrazenie mien in\u0161tanci\u00ed slu\u017eieb v ich IP adres\u00e1ch pou\u017e\u00edvame DNS protokol. Tento DNS vr\u00e1ti v\u0161etky rezervovan\u00e9 IP adresy v\u0161etk\u00fdch kontajnerov \u2014 ako be\u017eiacich, tak aj zastaven\u00fdch (povedzme, \u017ee s\u00fa pou\u017eit\u00e9 tri repliky a m\u00e1me tam p\u00e4\u0165 rezervovan\u00fdch adries \u2014 v\u0161etk\u00fdch p\u00e4\u0165 bude vr\u00e1ten\u00fdch). Klienti, ktor\u00ed dostan\u00fa tieto inform\u00e1cie, sa pok\u00fasia nadviaza\u0165 spojenie so v\u0161etk\u00fdmi piatimi replikami \u2014 a t\u00fdm zistia tie, ktor\u00e9 funguj\u00fa. Tento sp\u00f4sob ur\u010dovania dostupnosti je ove\u013ea spo\u013eahlivej\u0161\u00ed, ne\u00fa\u010dastn\u00ed sa v \u0148om ani DNS, ani Service Discovery, a teda sa neobjavuj\u00fa \u0165a\u017eko rie\u0161ite\u013en\u00e9 \u00falohy s udr\u017eovan\u00edm aktu\u00e1lnosti inform\u00e1ci\u00ed a odolnosti t\u00fdchto syst\u00e9mov. Viac ne\u017e to, v kritick\u00fdch slu\u017eb\u00e1ch, od ktor\u00fdch z\u00e1vis\u00ed fungovanie cel\u00e9ho port\u00e1lu, nemus\u00edme DNS v\u00f4bec pou\u017e\u00edva\u0165, ale jednoducho zasadi\u0165 do konfigur\u00e1cie IP adresy.<\/p>\n<p><\/p>\n<p>Realiz\u00e1cia tak\u00e9hoto prenosu IP za kontajnermi m\u00f4\u017ee by\u0165 netrivi\u00e1lna \u2014 a zastav\u00edme sa pri tom, ako to funguje, na nasleduj\u00facom pr\u00edklade:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/faf99c2609a57daa1bdc193cb0f4cb31.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Predpokladajme, \u017ee majster one-cloud d\u00e1 pr\u00edkaz mini\u00f3novi M1 spusti\u0165 <strong>1.ok-web.group1.web.front.prod<\/strong> s adresou 1.1.1.1. Na mini\u00f3ne be\u017e\u00ed <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Bird_Internet_routing_daemon\">BIRD<\/a><\/noindex>, ktor\u00fd oznamuje t\u00fato adresu \u0161peci\u00e1lnym serverom <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Route_reflector\">route reflector<\/a><\/noindex>. Tieto servery maj\u00fa BGP rel\u00e1ciu so sie\u0165ov\u00fdm zariaden\u00edm, do ktor\u00e9ho sa pren\u00e1\u0161a cesta adresy 1.1.1.1 na M1. M1 u\u017e smeruje pakety do kontajnera pomocou prostriedkov Linuxu. Serverov route reflector je tri, preto\u017ee ide o ve\u013emi kritick\u00fa \u010das\u0165 infra\u0161trukt\u00fary one-cloud \u2014 bez nich sie\u0165 v one-cloud nebude fungova\u0165. Umies\u0165ujeme ich do r\u00f4znych stojanov, pokia\u013e mo\u017eno umiestnen\u00fdch v r\u00f4znych miestnostiach d\u00e1tov\u00e9ho centra, aby sme zn\u00ed\u017eili pravdepodobnos\u0165 s\u00fa\u010dasn\u00e9ho zlyhania v\u0161etk\u00fdch troch.<\/p>\n<p><\/p>\n<p>Predpokladajme teraz, \u017ee spojenie medzi majstrom one-cloud a mini\u00f3nom M1 sa stratilo. Majster one-cloud teraz bude kona\u0165, vych\u00e1dzaj\u00fac zo predpokladu, \u017ee M1 \u00faplne zlyhal. Teda d\u00e1 pr\u00edkaz mini\u00f3novi M2 spusti\u0165 <strong>web.group1.web.front.prod<\/strong> s touto istou adresou 1.1.1.1. Teraz m\u00e1me dva konfliktn\u00e9 trasy v sieti pre 1.1.1.1: na M1 a na M2. Na vyrie\u0161enie t\u00fdchto konfliktov pou\u017e\u00edvame Multi Exit Discriminator, ktor\u00fd sa uv\u00e1dza v BGP ozn\u00e1men\u00ed. Toto \u010d\u00edslo ud\u00e1va v\u00e1hu oznamovanej trasy. Z konfliktn\u00fdch sa vyberie trasa s ni\u017e\u0161ou hodnotou MED. Master one-cloud podporuje MED ako integr\u00e1lnu s\u00fa\u010das\u0165 IP adries kontajnerov. Po prv\u00fdkr\u00e1t sa adresa zapisuje s dostato\u010dne vysok\u00fdm MED = 1 000 000. V pr\u00edpade havarijn\u00e9ho presunu kontajnera master zn\u00ed\u017ei MED, a M2 dostane pokyn ozn\u00e1mi\u0165 adresu 1.1.1.1 s MED = 999 999. Pr\u00edpad, ktor\u00fd pracuje na M1, zostane bez pripojenia, a jeho \u010fal\u0161\u00ed osud n\u00e1s ve\u013emi nezauj\u00edma do okamihu obnovenia pripojenia s masterom, kedy bude zastaven\u00fd ako star\u00e1 duplik\u00e1t.<\/p>\n<p><\/p>\n<h2 id=\"avarii\">Havarie<\/h2>\n<p><\/p>\n<p>V\u0161etky syst\u00e9my spr\u00e1vy d\u00e1tov\u00fdch centier prijate\u013ene spracov\u00e1vaj\u00fa drobn\u00e9 poruchy. Vypadnutie kontajnera je be\u017en\u00e9 takmer v\u0161ade.<\/p>\n<p><\/p>\n<p>Pozrime sa, ako spracov\u00e1vame hav\u00e1riu, napr\u00edklad v\u00fdpadok elektrickej energie v jednej alebo viacer\u00fdch miestnostiach d\u00e1tov\u00e9ho centra.<\/p>\n<p><\/p>\n<p>\u010co znamen\u00e1 hav\u00e1ria pre syst\u00e9m spr\u00e1vy d\u00e1tov\u00e9ho centra? Predov\u0161etk\u00fdm to znamen\u00e1 mas\u00edvny s\u00fa\u010dasn\u00fd v\u00fdpadok mnoh\u00fdch strojov, a syst\u00e9m spr\u00e1vy mus\u00ed s\u00fa\u010dasne migrova\u0165 ve\u013ek\u00e9 mno\u017estvo kontajnerov. Ak je hav\u00e1ria ve\u013emi rozsiahla, m\u00f4\u017ee sa sta\u0165, \u017ee v\u0161etky \u00falohy nebud\u00fa m\u00f4c\u0165 by\u0165 presunut\u00e9 na in\u00e9 minionky, preto\u017ee kapacita d\u00e1tov\u00e9ho centra kles\u00e1 pod 100 % za\u0165a\u017eenia. <\/p>\n<p><\/p>\n<p>Havarie \u010dasto sprev\u00e1dza aj v\u00fdpadok riadiacej vrstvy. K tomu m\u00f4\u017ee d\u00f4js\u0165 z d\u00f4vodu poruchy jej hardv\u00e9ru, ale \u010dastej\u0161ie kv\u00f4li tomu, \u017ee hav\u00e1rie nie s\u00fa testovan\u00e9, a riadiaca vrstva sama zlyh\u00e1 z d\u00f4vodu zv\u00fd\u0161enej z\u00e1\u0165a\u017ee. <\/p>\n<p><\/p>\n<p>\u010co s t\u00fdm v\u0161etk\u00fdm m\u00f4\u017eeme urobi\u0165?<\/p>\n<p><\/p>\n<p>Masy migr\u00e1ci\u00ed znamenaj\u00fa, \u017ee v infra\u0161trukt\u00fare vznik\u00e1 ve\u013ek\u00e9 mno\u017estvo oper\u00e1ci\u00ed, migr\u00e1ci\u00ed a umiestnen\u00ed. Ka\u017ed\u00e1 migr\u00e1cia m\u00f4\u017ee trva\u0165 nejak\u00fd \u010das, potrebn\u00fd na doru\u010denie a rozbalenie obrazov kontajnerov na minionky, spustenie a inicializ\u00e1ciu kontajnerov at\u010f. Preto je \u017eiaduce, aby sa d\u00f4le\u017eitej\u0161ie \u00falohy sp\u00fa\u0161\u0165ali pred menej d\u00f4le\u017eit\u00fdmi.<\/p>\n<p><\/p>\n<p>Pozrime sa znova na n\u00e1m zn\u00e1mu hierarchiu slu\u017eieb a pok\u00fasme sa rozhodn\u00fa\u0165, ktor\u00e9 \u00falohy chceme spusti\u0165 ako prv\u00e9.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/2e827271adb8d3ff3d385e53553aaacf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Samozrejme, s\u00fa to procesy, ktor\u00e9 priamo z\u00fa\u010dast\u0148uj\u00fa spracovania po\u017eiadaviek pou\u017e\u00edvate\u013eov, t. j. prod. Uv\u00e1dzame to pomocou <strong>prioritiz\u00e1cie umiestnenia<\/strong> \u2014 \u010d\u00edslo, ktor\u00e9 m\u00f4\u017ee by\u0165 priraden\u00e9 frontu. Ak m\u00e1 nejak\u00fd front vy\u0161\u0161iu prioritu, jeho slu\u017eby sa umiest\u0148uj\u00fa ako prv\u00e9.<\/p>\n<p><\/p>\n<p>Na prod prira\u010fujeme vy\u0161\u0161ie priority, 0; na batch \u2014 o nie\u010do ni\u017e\u0161ie, 100; na idle \u2014 e\u0161te ni\u017e\u0161ie, 200. Prioirty sa uplat\u0148uj\u00fa hierarchicky. V\u0161etky \u00falohy ni\u017e\u0161ie v hierarchii bud\u00fa ma\u0165 zodpovedaj\u00facu prioritu. Ak chceme, aby sa v r\u00e1mci prod ke\u0161 sp\u00fa\u0161\u0165al pred frontendmi, prirad\u00edme priority cache = 0 a front podfronty = 1. Ak v\u0161ak napr\u00edklad chceme, aby z frontov sa najprv sp\u00fa\u0161\u0165al hlavn\u00fd port\u00e1l a a\u017e potom music front, posledn\u00e9mu m\u00f4\u017eeme priradi\u0165 ni\u017e\u0161iu prioritu \u2014 10.<\/p>\n<p><\/p>\n<p>\u010eal\u0161\u00edm probl\u00e9mom je nedostatok zdrojov. Tak\u017ee sa n\u00e1m pokazilo ve\u013ek\u00e9 mno\u017estvo zariaden\u00ed, cel\u00e9 s\u00e1ly d\u00e1tov\u00e9ho centra, a spustili sme to\u013eko slu\u017eieb, \u017ee teraz na v\u0161etk\u00fdch nie s\u00fa dostato\u010dn\u00e9 zdroje. Je potrebn\u00e9 rozhodn\u00fa\u0165, ktor\u00fdmi \u00falohami obetova\u0165, aby fungovali hlavn\u00e9 kritick\u00e9 slu\u017eby. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/1b1ad3da16df6677dd0ba4b038cdd7d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Na rozdiel od priority umiestnenia nem\u00f4\u017eeme len tak obetova\u0165 v\u0161etky batch-\u00falohy, niektor\u00e9 z nich s\u00fa d\u00f4le\u017eit\u00e9 pre fungovanie port\u00e1lu. Preto sme osobitne vy\u010dlenili <strong>prioritu vytl\u00e1\u010dania<\/strong> \u00faloh. Pri umiestnen\u00ed m\u00f4\u017ee \u00faloha s vy\u0161\u0161ou prioritou vytla\u010di\u0165, t. j. zastavi\u0165 \u00falohu s ni\u017e\u0161ou prioritou, ak u\u017e nie s\u00fa k dispoz\u00edcii \u017eiadni vo\u013en\u00ed minioni. \u00daloha s ni\u017e\u0161ou prioritou pravdepodobne zostane neumiestnen\u00e1, t. j. pre \u0148u u\u017e nebude vhodn\u00fd minion s dostatkom vo\u013en\u00fdch zdrojov.<\/p>\n<p><\/p>\n<p>V na\u0161ej hierarchii je ve\u013emi jednoduch\u00e9 ur\u010di\u0165 tak\u00fa prioritu vytl\u00e1\u010dania, aby prod- a batch-\u00falohy vytl\u00e1\u010dali alebo zastavovali idle-\u00falohy, ale nie navz\u00e1jom, priraden\u00edm priority pre idle rovnej 200. Rovnako ako v pr\u00edpade priority umiestnenia m\u00f4\u017eeme vyu\u017ei\u0165 na\u0161u hierarchiu na opisovanie zlo\u017eitej\u0161\u00edch pravidiel. Napr\u00edklad ur\u010d\u00edme, \u017ee funkciou hudby obetujeme, ak n\u00e1m bude ch\u00fdba\u0165 zdroje pre hlavn\u00fd webov\u00fd port\u00e1l, a prirad\u00edme ni\u017e\u0161iu prioritu pre pr\u00edslu\u0161n\u00e9 uzly: 10.<\/p>\n<p><\/p>\n<h2 id=\"avarii-dc-celikom\">Hav\u00e1rie D\u0426 \u00faplne<\/h2>\n<p><\/p>\n<p>Pre\u010do m\u00f4\u017ee zlyha\u0165 cel\u00e9 d\u00e1tov\u00e9 centrum? \u017divel. Bol dobr\u00fd pr\u00edspevok, ako <noindex><a rel=\"nofollow\" href=\"https:\/\/habrahabr.ru\/company\/dataline\/blog\/333578\/\">hurik\u00e1n ovplyvnil fungovanie d\u00e1tov\u00e9ho centra<\/a><\/noindex>Elementom s\u00fa bezdomovci, ktor\u00ed raz zap\u00e1lili optiku v kolektore, a d\u00e1tov\u00e9 centrum \u00faplne stratilo spojenie s ostatn\u00fdmi lokalitami. Pr\u00ed\u010dinou v\u00fdpadku m\u00f4\u017ee by\u0165 aj \u013eudsk\u00fd faktor: oper\u00e1tor m\u00f4\u017ee zada\u0165 pr\u00edkaz, ktor\u00fd sp\u00f4sob\u00ed p\u00e1d cel\u00e9ho d\u00e1tov\u00e9ho centra. K tak\u00fdmto udalostiam m\u00f4\u017ee d\u00f4js\u0165 kv\u00f4li ve\u013ekej chybe. V\u0161eobecne nie je nezvy\u010dajn\u00e9, \u017ee d\u00e1tov\u00e9 centr\u00e1 zlyh\u00e1vaj\u00fa \u2013 u n\u00e1s sa to st\u00e1va ka\u017ed\u00fdch nieko\u013eko mesiacov. <\/p>\n<p><\/p>\n<p>A toto je to, \u010do rob\u00edme, aby nikto #ok\u017eiv\u00ed nepostoval na Twitteri.<\/p>\n<p><\/p>\n<p>Prv\u00e1 strat\u00e9gia - izol\u00e1cia. Ka\u017ed\u00fd in\u0161tancia one-cloud je izolovan\u00e1 a m\u00f4\u017ee spravova\u0165 stroje len jedn\u00e9ho d\u00e1tov\u00e9ho centra. To znamen\u00e1, \u017ee strata cloudu kv\u00f4li chyb\u00e1m alebo nespr\u00e1vnemu pr\u00edkazu oper\u00e1tora znamen\u00e1 stratu iba jedn\u00e9ho d\u00e1tov\u00e9ho centra. Sme na to pripraven\u00ed: m\u00e1me politiku rezerv\u00e1cie, v r\u00e1mci ktorej s\u00fa repliky aplik\u00e1ci\u00ed a \u00fadajov umiestnen\u00e9 vo v\u0161etk\u00fdch d\u00e1tov\u00fdch centr\u00e1ch. Pou\u017e\u00edvame odoln\u00e9 datab\u00e1zy a pravidelne testujeme v\u00fdpadky.<br \/>\nKe\u010f\u017ee dnes m\u00e1me \u0161tyri d\u00e1tov\u00e9 centr\u00e1, existuj\u00fa aj \u0161tyri samostatn\u00e9, \u00faplne izolovan\u00e9 in\u0161tancie one-cloud.<\/p>\n<p><\/p>\n<p>Tak\u00fdto pr\u00edstup nielen\u017ee chr\u00e1ni pred fyzick\u00fdm v\u00fdpadkom, ale m\u00f4\u017ee chr\u00e1ni\u0165 aj pred chybami oper\u00e1tora.<\/p>\n<p><\/p>\n<p>\u010co \u010fal\u0161ie m\u00f4\u017eeme urobi\u0165 s \u013eudsk\u00fdm faktorom? Ke\u010f oper\u00e1tor zad\u00e1 cloudu nejak\u00fd zvl\u00e1\u0161tny alebo potenci\u00e1lne nebezpe\u010dn\u00fd pr\u00edkaz, m\u00f4\u017ee by\u0165 n\u00e1hle po\u017eiadan\u00fd, aby vyrie\u0161il mal\u00fa \u00falohu, aby sa overilo, ako dobre o tom prem\u00fd\u0161\u013eal. Napr\u00edklad, ak ide o hromadn\u00e9 zastavenie mnoh\u00fdch replik alebo proste divn\u00fd pr\u00edkaz - zn\u00ed\u017eenie po\u010dtu replik alebo zmena n\u00e1zvu obrazu, a nie len \u010d\u00edsla verzie v novom manifeste.<\/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 opera\u010dn\u00fd syst\u00e9m \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnikach\" src=\"\/wp-content\/uploads\/2020\/06\/f7ee44a77e30612a3cd99a6f7aee3820.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<h2 id=\"itogi\">Zhrnutie<\/h2>\n<p><\/p>\n<p>Charakteristick\u00e9 \u010drty one-cloud: <\/p>\n<p><\/p>\n<ul>\n<li><strong>Hierarchick\u00e1 a preh\u013eadn\u00e1 sch\u00e9ma pomenovania slu\u017eieb a kontajnerov<\/strong>, ktor\u00e1 umo\u017e\u0148uje ve\u013emi r\u00fdchlo zisti\u0165, o ak\u00fa \u00falohu ide, na \u010do sa vz\u0165ahuje a ako funguje a kto za \u0148u zodpoved\u00e1. <\/li>\n<li>Aplikujeme svoju <strong>techniku kombin\u00e1cie prod- a batch-<\/strong>\u00faloh na mini\u00f3noch, aby sme zv\u00fd\u0161ili efektivitu zdie\u013eania strojov. Namiesto cpuset pou\u017e\u00edvame CPU kv\u00f3ty, shares, politiky pl\u00e1nova\u010da CPU a Linux QoS.<\/li>\n<li>\u00daplne izolova\u0165 kontajnery be\u017eiace na jednom stroji sa nepodarilo, ale ich vz\u00e1jomn\u00fd vplyv zost\u00e1va v rozmedz\u00ed do 20%.<\/li>\n<li>Organiz\u00e1cia slu\u017eieb do hierarchie pom\u00e1ha pri automatickom odstr\u00e1nen\u00ed hav\u00e1ri\u00ed pomocou <strong>prior\u00edt umiestnenia a vytl\u00e1\u010dania.<\/strong>.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"chavo\">\u010cASTO KLADEN\u00c9 OT\u00c1ZKY<\/h2>\n<p><\/p>\n<p>Pre\u010do sme si nevybrali hotov\u00e9 rie\u0161enie.<\/p>\n<p><\/p>\n<ul>\n<li>R\u00f4zne triedy izol\u00e1cie \u00faloh si vy\u017eaduj\u00fa r\u00f4znu logiku pri umiest\u0148ovan\u00ed na miniony. Ak je mo\u017en\u00e9 umiestni\u0165 prod-\u00falohy jednoduch\u00fdm rezervovan\u00edm zdrojov, batch a idle je potrebn\u00e9 umiestni\u0165 tak, aby sa sledovala skuto\u010dn\u00e1 vyu\u017eite\u013enos\u0165 zdrojov na strojoch-minionoch. <\/li>\n<li>Potrebnos\u0165 zoh\u013eadni\u0165 tak\u00e9to zdroje spotrebov\u00e1van\u00e9 \u00falohami, ako s\u00fa: \n<ul>\n<li>priepustnos\u0165 siete;<\/li>\n<li>typy a 'spindle' diskov.<\/li>\n<\/ul>\n<\/li>\n<li>Potrebnos\u0165 uvies\u0165 priority slu\u017eieb pri likvid\u00e1cii hav\u00e1ri\u00ed, pr\u00e1va a kv\u00f3ty t\u00edmov na zdroje, \u010do sa rie\u0161i pomocou hierarchick\u00fdch front v one-cloud.<\/li>\n<li>Potrebnos\u0165 ma\u0165 \u013eudsk\u00e9 pomenovanie kontajnerov na skr\u00e1tenie \u010dasu reakcie na hav\u00e1rie a incidenty.<\/li>\n<li>Nemo\u017enos\u0165 jednorazov\u00e9ho celoplo\u0161n\u00e9ho zavedenia Service Discovery; potreba dlh\u0161\u00ed \u010das koexistova\u0165 s \u00falohami umiestnen\u00fdmi na fyzick\u00fdch hostite\u013eoch \u2014 to, \u010do sa rie\u0161i \u201estatick\u00fdmi\u201c IP adresami nasleduj\u00facimi za kontajnermi, a taktie\u017e potreba unik\u00e1tnej integr\u00e1cie s ve\u013ekou sie\u0165ovou infra\u0161trukt\u00farou.<\/li>\n<\/ul>\n<p><\/p>\n<p>V\u0161etky tieto funkcie by si vy\u017eadovali zna\u010dn\u00e9 prestavby existuj\u00facich rie\u0161en\u00ed pod\u013ea seba a po zhodnoten\u00ed mno\u017estva pr\u00e1ce sme si uvedomili, \u017ee budeme schopn\u00ed vyvin\u00fa\u0165 svoje vlastn\u00e9 rie\u0161enie pribli\u017ene s rovnak\u00fdmi n\u00e1kladmi na pr\u00e1cu. Ale na\u0161e rie\u0161enie bude ove\u013ea jednoduch\u0161ie na prev\u00e1dzku a rozvoj \u2014 neobsahuje zbyto\u010dn\u00e9 abstrakcie, ktor\u00e9 podporuj\u00fa pre n\u00e1s nepotrebn\u00fa funkcionalitu. <\/p>\n<p><\/p>\n<p>T\u00fdm, ktor\u00ed \u010d\u00edtaj\u00fa posledn\u00e9 riadky, - \u010fakujeme za trpezlivos\u0165 a pozornos\u0165!<\/p>\n<p>Zdroj: <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\/sk\/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=\"sk_SK\" \/>\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\/sk\/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 os \u00farovne d\u00e1tov\u00e9ho centra v Odnoklassnik\u00e1ch | ProHoster","description":"Aloha, \u013eudia!","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","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\/sk\/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\/sk\/wp-json\/wp\/v2\/posts\/84114","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=84114"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/84114\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/84115"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=84114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=84114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=84114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}