{"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\/ro\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","title":{"rendered":"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/fa983acacec59ff2d4ed098f87223971.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Aloha, oameni buni! Numele meu este Oleg Anastasie, lucrez la Odnoklassniki \u00een echipa Platformei. Pe l\u00e2ng\u0103 mine, \u00een Odnoklassniki lucreaz\u0103 o mul\u021bime de echipamente. Avem patru centre de date, cu aproximativ 500 de rack-uri \u0219i peste 8000 de servere. La un moment dat, ne-am dat seama c\u0103 implementarea unui nou sistem de management ne va permite s\u0103 folosim mai eficient tehnologia, s\u0103 simplific\u0103m gestionarea accesului, s\u0103 automatiz\u0103m (re)distribu\u021bia resurselor computa\u021bionale, s\u0103 acceler\u0103m lansarea de noi servicii \u0219i s\u0103 r\u0103spundem mai rapid la avarii mari. <\/p>\n<p><\/p>\n<p>Ce a ie\u0219it din asta? <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Pe l\u00e2ng\u0103 mine \u0219i o mul\u021bime de echipamente, sunt oameni care lucreaz\u0103 cu aceste echipamente: ingineri care se afl\u0103 direct \u00een centrele de date; speciali\u0219ti \u00een re\u021bea care configureaz\u0103 infrastructura de re\u021bea; administratori, adic\u0103 SRE, care asigur\u0103 rezilien\u021ba infrastructurii; \u0219i echipe de dezvoltatori, fiecare fiind responsabil pentru o parte din func\u021biile portalului. Software-ul pe care \u00eel creeaz\u0103 func\u021bioneaz\u0103 cam a\u0219a:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/592fd0acfa7322eb80fbb85601a92918.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Cererea utilizatorilor ajunge at\u00e2t la frontend-ul principal al portalului <noindex><a rel=\"nofollow\" href=\"http:\/\/www.ok.ru\/\">www.ok.ru<\/a><\/noindex>, c\u00e2t \u0219i la altele, de exemplu la frontend-urile API-ului de muzic\u0103. Acestea, pentru a gestiona logica de business, apeleaz\u0103 serverul de aplica\u021bii, care, \u00een procesul de prelucrare a cererii, invoc\u0103 microserviciile specializate necesare \u2014 one-graph (grafica leg\u0103turilor sociale), user-cache (cache-ul profilurilor utilizatorilor) etc.<\/p>\n<p><\/p>\n<p>Fiecare dintre aceste servicii este desf\u0103\u0219urat pe mai multe ma\u0219ini, iar pentru fiecare exist\u0103 dezvoltatori responsabili de func\u021bionarea modulelor, exploatarea acestora \u0219i dezvoltarea tehnologic\u0103. Toate aceste servicii sunt lansate pe servere fizice, iar p\u00e2n\u0103 de cur\u00e2nd am rulat exact o sarcin\u0103 pe un server, adic\u0103 acesta era specializat pentru o anumit\u0103 sarcin\u0103.<\/p>\n<p><\/p>\n<p>De ce a\u0219a? Acest lucru avea c\u00e2teva avantaje:<\/p>\n<p><\/p>\n<ul>\n<li>Se simplific\u0103 <strong>gestionarea \u00een mas\u0103<\/strong>. S\u0103 spunem c\u0103 sarcina necesit\u0103 anumite biblioteci, anumite configura\u021bii. Atunci serverul este alocat exact unei anumite grupuri, se descrie o politic\u0103 cfengine pentru aceast\u0103 grup\u0103 (sau deja a fost descris\u0103), iar aceast\u0103 configura\u021bie este r\u0103sp\u00e2ndit\u0103 centralizat \u0219i automat pe toate serverele din aceast\u0103 grup\u0103.<\/li>\n<li>Se simplific\u0103 <strong>diagnosticarea<\/strong>. S\u0103 presupunem c\u0103 observi o \u00eenc\u0103rcare crescut\u0103 a procesorului central \u0219i \u00ee\u021bi dai seama c\u0103 aceast\u0103 \u00eenc\u0103rcare a fost generat\u0103 doar de sarcina care ruleaz\u0103 pe acest procesor fizic. C\u0103ut\u0103rile pentru vinovat se \u00eencheie foarte repede.<\/li>\n<li>Se simplific\u0103 <strong>monitorizare<\/strong>. Dac\u0103 exist\u0103 o problem\u0103 cu serverul, monitorul te anun\u021b\u0103 \u0219i \u0219tii exact cine este de vin\u0103.<\/li>\n<\/ul>\n<p><\/p>\n<p>Serviciului, format din mai multe replici, i se atribuie mai multe servere - c\u00e2te unul pentru fiecare. Astfel, resursa de calcul pentru serviciu este alocat\u0103 foarte simplu: c\u00e2te servere are serviciul, at\u00e2tea resurse poate consuma la maxim. \u201eSimplu\u201d aici nu \u00eenseamn\u0103 c\u0103 este u\u0219or de utilizat, ci c\u0103 distribu\u021bia resurselor se face manual.<\/p>\n<p><\/p>\n<p>Aceast\u0103 abordare ne-a permis de asemenea s\u0103 realiz\u0103m <strong>configura\u021bii hardware specializate<\/strong> pentru sarcini care ruleaz\u0103 pe acest server. Dac\u0103 sarcina stocheaz\u0103 volume mari de date, folosim un server 4U cu \u0219asiu pentru 38 de discuri. Dac\u0103 sarcina este pur \u0219i simplu de calcul, putem cump\u0103ra un server 1U mai ieftin. Aceasta este eficient din punct de vedere al resurselor de calcul. De asemenea, aceast\u0103 abordare ne permite s\u0103 utiliz\u0103m de patru ori mai pu\u021bine ma\u0219ini pentru o \u00eenc\u0103rcare comparabil\u0103 cu o re\u021bea social\u0103 prietenoas\u0103 nou\u0103. <\/p>\n<p><\/p>\n<p>Aceast\u0103 eficien\u021b\u0103 \u00een utilizarea resurselor de calcul ar trebui s\u0103 asigure \u0219i eficien\u021ba economic\u0103, av\u00e2nd \u00een vedere presupunerea c\u0103 cele mai scumpe sunt serverele. O perioad\u0103 lung\u0103 de timp, cel mai scump a fost \u00een mod cert hardware-ul, iar noi am investit mult \u00een reducerea costului hardware-ului, invent\u00e2nd algoritmi pentru asigurarea rezilien\u021bei \u00een fa\u021ba erorilor pentru a reduce cerin\u021bele de fiabilitate a echipamentului. \u0218i ast\u0103zi am ajuns la un stadiu \u00een care pre\u021bul serverului nu mai este determinant. Dac\u0103 nu lu\u0103m \u00een considerare cele mai recente exotisme, configura\u021bia specific\u0103 a serverelor \u00een rack nu mai conteaz\u0103. Acum ne confrunt\u0103m cu o alt\u0103 problem\u0103 - costul locului ocupat de server \u00een data center, adic\u0103 locul din rack.<\/p>\n<p><\/p>\n<p>Realiz\u00e2nd c\u0103 este a\u0219a, am decis s\u0103 calcul\u0103m c\u00e2t de eficient utiliz\u0103m rack-urile.<br \/>\nAm preluat pre\u021bul celui mai puternic server din categoria economic\u0103, am calculat c\u00e2te astfel de servere putem amplasa \u00een rack-uri, ce sarcini am putea rula pe acestea conform vechii metode \u201eun server = o sarcin\u0103\u201d \u0219i c\u00e2t de eficient ar putea fi utilizat echipamentul. Am calculat \u0219i am r\u0103mas surprin\u0219i. S-a dovedit c\u0103 eficien\u021ba utiliz\u0103rii rack-urilor este de aproximativ 11%. Concluzia este evident\u0103: trebuie s\u0103 cre\u0219tem eficien\u021ba utiliz\u0103rii centrelor de date. Ar p\u0103rea c\u0103 solu\u021bia este simpl\u0103: trebuie s\u0103 rul\u0103m mai multe sarcini pe un singur server. \u00cens\u0103 aici apar dificult\u0103\u021bile. <\/p>\n<p><\/p>\n<p>Configurarea \u00een mas\u0103 devine rapid mult mai complicat\u0103 \u2014 acum nu mai este posibil s\u0103 aloc\u0103m un anumit grup unui server. Deoarece pe un singur server pot rula mai multe sarcini ale echipelor diferite. \u00cen plus, configura\u021bia poate fi conflictual\u0103 pentru diferite aplica\u021bii. Diagnosticarea devine de asemenea mai dificil\u0103: dac\u0103 observa\u021bi un consum crescut de CPU sau de discuri pe server, nu \u0219ti\u021bi care dintre sarcini cauzeaz\u0103 probleme.<\/p>\n<p><\/p>\n<p>Dar cel mai important este c\u0103 \u00eentre sarcinile rulate pe aceea\u0219i ma\u0219in\u0103 nu exist\u0103 izolare. De exemplu, graficul timpului mediu de r\u0103spuns al unei sarcini server dup\u0103 ce pe acela\u0219i server a fost lansat\u0103 o alt\u0103 aplica\u021bie de calcul complet necorespunz\u0103toare primei \u2014 timpul de r\u0103spuns pentru sarcina principal\u0103 a crescut semnificativ.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/c7c07359ae572ca8c84a4c63559e4083.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Este evident c\u0103 trebuie s\u0103 rul\u0103m sarcinile fie \u00een containere, fie \u00een ma\u0219ini virtuale. Deoarece practic toate sarcinile noastre ruleaz\u0103 sub un singur sistem de operare (Linux) sau sunt adaptate pentru acesta, nu avem nevoie s\u0103 men\u021binem o multitudine de sisteme de operare diferite. Prin urmare, virtualizarea nu este necesar\u0103, iar din cauza costurilor suplimentare, va fi mai pu\u021bin eficient\u0103 dec\u00e2t containerizarea.<\/p>\n<p><\/p>\n<p>Ca implementare a containerelor pentru a rula sarcini direct pe serverele Docker este un candidat destul de bun: imaginile sistemelor de fi\u0219iere rezolv\u0103 bine problemele cu configura\u021biile conflictuale. Faptul c\u0103 imaginile pot fi compuse din mai multe straturi ne permite s\u0103 reducem semnificativ volumul de date necesar pentru desf\u0103\u0219urarea lor pe infrastructur\u0103, dedic\u00e2nd p\u0103r\u021bile comune unor straturi de baz\u0103 separate. Astfel, straturile de baz\u0103 (\u0219i cele mai voluminoase) vor fi rapid cache-uite pe \u00eentreaga infrastructur\u0103, iar pentru livrarea unui num\u0103r mare de tipuri diferite de aplica\u021bii \u0219i versiuni va fi necesar s\u0103 transfer\u0103m doar straturi mici. <\/p>\n<p><\/p>\n<p>\u00cen plus, registrul preg\u0103tit \u0219i etichetarea imaginilor \u00een Docker ne ofer\u0103 primitive gata f\u0103cute pentru versionarea \u0219i livrarea codului \u00een produc\u021bie.<\/p>\n<p><\/p>\n<p>Docker, ca orice alt\u0103 tehnologie similar\u0103, ne ofer\u0103 un anumit nivel de izolare a containerelor din cutie. De exemplu, izolarea pe memorie \u2014 fiec\u0103rui container i se atribuie o limit\u0103 pentru utilizarea memoriei ma\u0219inii, dincolo de care nu va consuma. De asemenea, este posibil s\u0103 se izoleze containerele \u00een func\u021bie de utilizarea CPU. Cu toate acestea, pentru noi, izola\u021bia standard a fost insuficient\u0103. Dar despre asta - mai jos.<\/p>\n<p><\/p>\n<p>Lansarea direct\u0103 a containerelor pe servere este doar o parte a problemelor. Cealalt\u0103 parte este legat\u0103 de plasarea containerelor pe servere. Trebuie s\u0103 \u00een\u021belegem ce container poate fi plasat pe ce server. Acesta nu este o sarcin\u0103 at\u00e2t de simpl\u0103, deoarece containerele trebuie s\u0103 fie plasate pe servere c\u00e2t mai dens, f\u0103r\u0103 a reduce viteza lor de func\u021bionare. O astfel de plasare poate fi complex\u0103 \u0219i din perspectiva rezilien\u021bei. Adesea dorim s\u0103 plas\u0103m replicile aceluia\u0219i serviciu \u00een rackuri diferite sau chiar \u00een s\u0103li diferite ale centrului de date, astfel \u00eenc\u00e2t, \u00een caz de defec\u021biune a unui rack sau a unei s\u0103li, s\u0103 nu pierdem toate replicile serviciului. <\/p>\n<p><\/p>\n<p>Distribuirea manual\u0103 a containerelor nu este o variant\u0103, c\u00e2nd ai 8.000 de servere \u0219i \u00eentre 8.000 \u0219i 16.000 de containere. <\/p>\n<p><\/p>\n<p>\u00cen plus, am vrut s\u0103 oferim dezvoltatorilor mai mult\u0103 autonomie \u00een distribuirea resurselor, astfel \u00eenc\u00e2t s\u0103 poat\u0103 plasa singuri serviciile lor \u00een produc\u021bie, f\u0103r\u0103 ajutorul unui administrator. \u00cen acela\u0219i timp, am dorit s\u0103 p\u0103str\u0103m controlul, astfel \u00eenc\u00e2t un serviciu secundar s\u0103 nu consume toate resursele centrelor noastre de date. <\/p>\n<p><\/p>\n<p>Este evident c\u0103 este nevoie de un strat de management care s\u0103 se ocupe de acest lucru \u00een mod automat.<\/p>\n<p><\/p>\n<p>Iat\u0103 c\u0103 am ajuns la o imagine simpl\u0103 \u0219i clar\u0103, pe care o ador\u0103 to\u021bi arhitec\u021bii: trei p\u0103tr\u0103\u021bele. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/079df6e79874ef55b0d967fde3d5feca.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>one-cloud masters \u2014 un cluster tolerant la erori, responsabil pentru orchestruirea norului. Dezvoltatorul trimite \u00een master un manifest care con\u021bine toate informa\u021biile necesare pentru g\u0103zduirea serviciului. Masterul, pe baza acestuia, d\u0103 comenzi miniunilor selectate (ma\u0219ini destinate rul\u0103rii containerelor). Pe miniuni se afl\u0103 agentul nostru, care prime\u0219te comanda, d\u0103 propriile sale comenzi Docker, iar Docker configureaz\u0103 kernel-ul linux pentru a rula containerul corespunz\u0103tor. Pe l\u00e2ng\u0103 executarea comenzilor, agentul comunic\u0103 continuu masterului despre schimb\u0103rile de stare at\u00e2t ale ma\u0219inii-minion, c\u00e2t \u0219i ale containerelor rulate pe aceasta.<\/p>\n<p><\/p>\n<h2 id=\"raspredelenie-resursov\">Distribu\u021bia resurselor<\/h2>\n<p><\/p>\n<p>\u0218i acum s\u0103 ne ocup\u0103m de sarcina unei distribu\u021bii mai complexe a resurselor pentru mai multe miniuni.<\/p>\n<p><\/p>\n<p>Resursa de calcul \u00een one-cloud este<\/p>\n<p><\/p>\n<ul>\n<li>Puterea de procesare a procesorului consumat\u0103 de o sarcin\u0103 specific\u0103. <\/li>\n<li>Volumul de memorie disponibil pentru sarcin\u0103. <\/li>\n<li>Traficul de re\u021bea. Fiecare dintre miniuni are o interfa\u021b\u0103 de re\u021bea specific\u0103 cu o l\u0103\u021bime de band\u0103 limitat\u0103, a\u0219a c\u0103 nu putem distribui sarcini f\u0103r\u0103 a \u021bine cont de volumul de date transmise prin re\u021bea. <\/li>\n<li>Discuri. Pe l\u00e2ng\u0103, evident, spa\u021biul necesar datelor sarcinii, de asemenea, aloc\u0103m tipul de disc: HDD sau SSD. Discurile pot deservi un num\u0103r finit de cereri pe secund\u0103 \u2014 IOPS. Prin urmare, pentru sarcinile care genereaz\u0103 mai multe IOPS dec\u00e2t poate deservi un singur disc, aloc\u0103m \u0219i \u201espindle-uri\u201d \u2014 adic\u0103 dispozitive de disc care trebuie rezervate exclusiv pentru sarcin\u0103.<\/li>\n<\/ul>\n<p><\/p>\n<p>A\u0219adar, pentru un serviciu anume, precum user-cache, putem nota resursele consumate \u00eentr-un mod similar: 400 de nuclee de procesor, 2,5 Tb de memorie, 50 Gbit\/s de trafic \u00een ambele direc\u021bii, 6 Tb de spa\u021biu pe HDD, g\u0103zduit pe 100 de spindle-uri. Sau \u00eentr-o form\u0103 mai familiar\u0103 pentru noi:<\/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>Resursele serviciului user-cache consum\u0103 doar o parte din toate resursele disponibile \u00een infrastructura de produc\u021bie. Prin urmare, ne dorim s\u0103 facem astfel \u00eenc\u00e2t, dintr-o eroare a operatorului sau nu, user-cache s\u0103 nu consume mai multe resurse dec\u00e2t i s-au alocat. Cu alte cuvinte, trebuie s\u0103 limit\u0103m resursele. Dar la ce am putea lega cota?<\/p>\n<p><\/p>\n<p>S\u0103 ne \u00eentoarcem la schema noastr\u0103 foarte simplificat\u0103 de interac\u021biune a componentelor \u0219i s\u0103 o redesen\u0103m cu mai multe detalii \u2014 a\u0219a: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/27e5bfbffadd3d4b9fdc6bf138d135ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ce atrage aten\u021bia:<\/p>\n<p><\/p>\n<ul>\n<li>Frontend-ul web \u0219i muzica folosesc clustere izolate ale aceluia\u0219i server de aplica\u021bii.<\/li>\n<li>Se pot eviden\u021bia straturile logice, la care apar\u021bin aceste clustere: fronturi, cache-uri, strat de stocare \u0219i gestionare a datelor.<\/li>\n<li>Frontend-ul nu este omogen, ci reprezint\u0103 diferite subsisteme func\u021bionale. <\/li>\n<li>Cache-urile pot fi de asemenea distribuite \u00een cadrul subsistemului ale c\u0103rui date le cache-uiesc.<\/li>\n<\/ul>\n<p><\/p>\n<p>\u00cenc\u0103 o dat\u0103, s\u0103 redesen\u0103m imaginea:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/905dacc0aca859e65bd33ef751a557cf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wow! Vedem o ierarhie! Asta \u00eenseamn\u0103 c\u0103 putem distribui resursele \u00een buc\u0103\u021bi mai mari: s\u0103 desemn\u0103m un dezvoltator responsabil pentru un nod al acestei ierarhii, corespunz\u0103tor subsistemului func\u021bional (precum \u201emusic\u201d \u00een imagine), \u0219i s\u0103 leg\u0103m o cot\u0103 la acest nivel al ierarhiei. O astfel de ierarhie ne permite, de asemenea, s\u0103 organiz\u0103m mai flexibil serviciile pentru o gestionare mai comod\u0103. De exemplu, toate web, deoarece este un grup foarte mare de servere, le \u00eemp\u0103r\u021bim \u00een c\u00e2teva grupuri mai mici, reprezentate \u00een imagine ca group1, group2.<\/p>\n<p><\/p>\n<p>Elimin\u00e2nd liniile inutile, putem scrie fiecare nod al imaginii noastre \u00eentr-o form\u0103 mai plat\u0103: <strong>group1.web.front<\/strong>, <strong>api.music.front<\/strong>, <strong>user-cache.cache<\/strong>.<\/p>\n<p><\/p>\n<p>Astfel, ajungem la conceptul de \u00abcoada ierarhic\u0103\u00bb. Aceasta are un nume, cum ar fi \u00abgroup1.web.front\u00bb. Se aloc\u0103 o cot\u0103 de resurse \u0219i drepturi utilizatorilor. O persoan\u0103 din DevOps va primi drepturi de a trimite serviciul \u00een coad\u0103, iar acest angajat poate activa ceva \u00een coad\u0103, iar unei persoane din OpsDev i se vor da drepturi administrative, \u0219i acum poate gestiona coada, poate desemna oameni acolo, le poate oferi drepturi etc. Serviciile activat\u0103 \u00een aceast\u0103 coad\u0103 vor fi executate \u00een cadrul cotei cozii. Dac\u0103 cota de calcul a cozii este insuficient\u0103 pentru a executa simultan toate serviciile, atunci acestea vor fi executate secven\u021bial, form\u00e2nd astfel propriuzis coada. <\/p>\n<p><\/p>\n<p>S\u0103 analiz\u0103m serviciile \u00een detaliu. Fiecare serviciu are un nume complet, care include \u00eentotdeauna numele cozii. Atunci serviciul frontului web va avea numele <strong>ok-web.group1.web.front<\/strong>. Iar serviciul serverului de aplica\u021bii, la care se adreseaz\u0103, se va numi <strong>ok-app.group1.web.front<\/strong>. Fiecare serviciu are un manifest care specific\u0103 toate informa\u021biile necesare pentru desf\u0103\u0219urarea pe ma\u0219ini specifice: c\u00e2te resurse consum\u0103 aceast\u0103 sarcin\u0103, ce configura\u021bie \u00eei este necesar\u0103, c\u00e2te replici trebuie s\u0103 existe, propriet\u0103\u021bile pentru gestionarea defec\u021biunilor acestui serviciu. \u0218i dup\u0103 desf\u0103\u0219urarea serviciului direct pe ma\u0219ini, apar instan\u021bele acestuia. Acestea sunt, de asemenea, denumite \u00een mod univoc \u2014 ca num\u0103rul instan\u021bei \u0219i numele serviciului: <strong>1.ok-web.group1.web.front, 2.ok-web.group1.web.front, \u2026<\/strong><\/p>\n<p><\/p>\n<p>Este foarte convenabil: uit\u00e2ndu-ne doar la numele containerului pornit, putem afla imediat multe informa\u021bii.<\/p>\n<p><\/p>\n<p>Acum s\u0103 ne familiariz\u0103m mai bine cu ceea ce fac de fapt aceste instan\u021be: cu sarcinile.<\/p>\n<p><\/p>\n<h2 id=\"klassy-izolyacii-zadach\">Clase de izolare a sarcinilor<\/h2>\n<p><\/p>\n<p>Toate sarcinile din OK (\u0219i probabil \u0219i \u00een alt\u0103 parte) pot fi \u00eemp\u0103r\u021bite \u00een grupuri:<\/p>\n<p><\/p>\n<ul>\n<li><strong>Sarcini cu \u00eent\u00e2rziere scurt\u0103 \u2014 prod<\/strong>. Pentru astfel de sarcini \u0219i servicii, \u00eent\u00e2rzierea r\u0103spunsului (latency) este foarte important\u0103, c\u00e2t de repede va fi procesat fiecare dintre cereri de c\u0103tre sistem. Exemple de sarcini: fronturi web, cache-uri, servere de aplica\u021bii, stoc\u0103ri OLTP etc.<\/li>\n<li><strong>Sarcini de calcul \u2014 batch<\/strong>. Aici, viteza de procesare a fiec\u0103rei cereri specifice nu este esen\u021bial\u0103. Ceea ce conteaz\u0103 este c\u00e2te calcule totale va efectua aceast\u0103 sarcin\u0103 \u00eentr-un anumit (mare) interval de timp (throughput). Astfel vor fi sarcinile de tip MapReduce, Hadoop, \u00eenv\u0103\u021bare automat\u0103, statistic\u0103.<\/li>\n<li><strong>Sarcini de fundal \u2014 idle<\/strong>. Pentru astfel de sarcini, nici latency, nici throughput nu sunt foarte importante. Aici intr\u0103 diverse teste, migra\u021bii, recalcul\u0103ri, conversii de date dintr-un format \u00een altul. Pe de o parte, seam\u0103n\u0103 cu cele de calcul, pe de alt\u0103 parte \u2014 nu ne intereseaz\u0103 foarte mult c\u00e2t de repede se finalizeaz\u0103. <\/li>\n<\/ul>\n<p><\/p>\n<p>S\u0103 ne uit\u0103m cum consum\u0103 astfel de sarcini resursele, de exemplu, ale procesorului central.<\/p>\n<p><\/p>\n<p><strong>Sarcini cu \u00eent\u00e2rziere scurt\u0103.<\/strong> Astfel de sarcini vor avea un model de consum al CPU similar cu acesta:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/1ed82c0df76325eb30056ad9af86e86e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Un cerere de la utilizator este procesat\u0103, sarcina \u00eencepe s\u0103 foloseasc\u0103 toate nucleele CPU disponibile, se finalizeaz\u0103, returneaz\u0103 un r\u0103spuns, a\u0219teapt\u0103 urm\u0103toarea cerere \u0219i st\u0103. A sosit urm\u0103toarea cerere \u2014 din nou folose\u0219te tot ce a fost, se calculeaz\u0103, a\u0219tept\u0103m urm\u0103toarea.<\/p>\n<p><\/p>\n<p>Pentru a garanta o \u00eent\u00e2rziere minim\u0103 pentru aceast\u0103 sarcin\u0103, trebuie s\u0103 lu\u0103m maximul resurselor consumate de ea \u0219i s\u0103 rezerv\u0103m num\u0103rul necesar de nuclee pe minion (ma\u0219ina care va efectua sarcina). Atunci formula de rezervare pentru sarcina noastr\u0103 va fi urm\u0103toarea:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = 4 (max)<\/code><\/pre>\n<p><\/p>\n<p>\u0218i dac\u0103 avem o ma\u0219in\u0103-minion cu 16 nuclee, putem rula exact patru astfel de sarcini pe ea. Este important de men\u021bionat c\u0103 consumul mediu al procesorului pentru astfel de sarcini este adesea foarte sc\u0103zut \u2014 ceea ce este evident, deoarece o mare parte din timp sarcina este \u00een a\u0219teptarea unei cereri \u0219i nu face nimic.<\/p>\n<p><\/p>\n<p><strong>Sarcini de calcul.<\/strong> Acestea vor avea un model ceva diferit:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/35b37fa1d70a137287cafdbfe3bcfc2e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Consumului mediu de resurse ale procesorului pentru astfel de sarcini este destul de ridicat. De multe ori, dorim ca o sarcin\u0103 de calcul s\u0103 fie finalizat\u0103 \u00eentr-un anumit interval de timp, a\u0219a c\u0103 trebuie s\u0103 rezerv\u0103m un num\u0103r minim de procesoare de care are nevoie, astfel \u00eenc\u00e2t \u00eentreaga calculare s\u0103 se \u00eencheie \u00eentr-un timp rezonabil. Formula de rezervare va ar\u0103ta astfel:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = [1,* )<\/code><\/pre>\n<p><\/p>\n<p><em>\u00abTe rog, plaseaz\u0103-l pe minion acolo unde exist\u0103 cel pu\u021bin un nucleu liber, iar restul \u2014 s\u0103 consume tot ce este disponibil\u00bb.<\/em><\/p>\n<p><\/p>\n<p>Aici, eficien\u021ba utiliz\u0103rii este semnificativ mai bun\u0103 dec\u00e2t \u00een cazul sarcinilor cu \u00eent\u00e2rziere scurt\u0103. \u00cens\u0103 c\u00e2\u0219tigul va fi mult mai mare dac\u0103 combin\u0103m ambele tipuri de sarcini pe aceea\u0219i ma\u0219in\u0103-minion \u0219i distribuim resursele acesteia pe parcurs. Atunci c\u00e2nd o sarcin\u0103 cu \u00eent\u00e2rziere scurt\u0103 are nevoie de procesor \u2014 \u00eel prime\u0219te imediat, iar c\u00e2nd resursele nu mai sunt necesare \u2014 acestea sunt transferate sarcinii de calcul, adic\u0103 cam a\u0219a:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/875ad8d3f6a01e4fd0a89d0931e986c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dar cum s\u0103 faci asta?<\/p>\n<p><\/p>\n<p>Mai \u00eent\u00e2i, s\u0103 ne ocup\u0103m de prod \u0219i de alloc: cpu = 4. Trebuie s\u0103 rezerv\u0103m patru nuclee. \u00cen Docker run, acest lucru se poate face \u00een dou\u0103 moduri: <\/p>\n<p><\/p>\n<ul>\n<li>Prin op\u021biunea <code>--cpuset=1-4<\/code>, adic\u0103 s\u0103 aloc\u0103m sarcinii patru nuclee specifice pe ma\u0219in\u0103.<\/li>\n<li>Utiliza\u021bi <code>--cpuquota=400_000 --cpuperiod=100_000<\/code>, s\u0103 stabilim o cot\u0103 de timp de procesor, adic\u0103 s\u0103 indic\u0103m c\u0103 fiecare 100 ms de timp real, sarcina consum\u0103 nu mai mult de 400 ms de timp de procesor. Rezultatul sunt acelea\u0219i patru nuclee. <\/li>\n<\/ul>\n<p><\/p>\n<p>Dar care dintre aceste metode este potrivit\u0103?<\/p>\n<p><\/p>\n<p>Aspectul cpuset este destul de atr\u0103g\u0103tor. Sarcina are patru nuclee dedicate, ceea ce \u00eenseamn\u0103 c\u0103 cache-urile procesorului vor func\u021biona la capacitate maxim\u0103. Exist\u0103 \u0219i o latur\u0103 negativ\u0103: ar trebui s\u0103 ne asum\u0103m sarcina de a distribui calculele pe nuclee ne\u00eenc\u0103rcate ale ma\u0219inii \u00een locul sistemului de operare, \u0219i aceasta este o sarcin\u0103 destul de neobi\u0219nuit\u0103, mai ales dac\u0103 \u00eencerc\u0103m s\u0103 plas\u0103m pe o astfel de ma\u0219in\u0103 sarcini batch. Testele au ar\u0103tat c\u0103 varianta cu cota este mai potrivit\u0103: astfel, sistemul de operare are mai mult\u0103 libertate \u00een alegerea nucleului pentru executarea sarcinii \u00een acel moment, iar timpul procesorului este distribuit mai eficient.<\/p>\n<p><\/p>\n<p>S\u0103 \u00een\u021belegem cum s\u0103 facem rezerv\u0103ri \u00een docker pentru num\u0103rul minim de nuclee. Cota pentru sarcinile batch nu mai este aplicabil\u0103, deoarece nu este nevoie s\u0103 se limiteze maximul, este suficient s\u0103 se asigure un minim. \u00cen acest caz, op\u021biunea este potrivit\u0103 <code>docker run --cpushares<\/code>.<\/p>\n<p><\/p>\n<p>Am convenit c\u0103 dac\u0103 batch-ul necesit\u0103 o garan\u021bie minim\u0103 pe un nucleu, atunci vom specifica <code>--cpushares=1024<\/code>, iar dac\u0103 minimul este pe dou\u0103 nuclee, atunci specific\u0103m <code>--cpushares=2048<\/code>. Cpu shares nu interfereaz\u0103 \u00een distribu\u021bia timpului procesorului at\u00e2ta timp c\u00e2t exist\u0103 suficient. Astfel, dac\u0103 prod nu utilizeaz\u0103 \u00een acel moment toate cele patru nuclee \u2014 nu exist\u0103 nimic care s\u0103 limiteze sarcinile batch \u0219i acestea pot utiliza timp suplimentar de procesor. \u00cens\u0103, \u00een situa\u021bia \u00een care exist\u0103 o lips\u0103 de procesor, dac\u0103 prod a consumat toate cele patru nuclee \u0219i a atins cota \u2014 timpul r\u0103mas de procesor va fi \u00eemp\u0103r\u021bit propor\u021bional cu cpushares, adic\u0103, \u00een cazul a trei nuclee libere, una va primi sarcina cu 1024 cpushares, iar celelalte dou\u0103 \u2014 sarcina cu 2048 cpushares.<\/p>\n<p><\/p>\n<p>Dar utilizarea quota \u0219i shares nu este suficient\u0103. Trebuie s\u0103 ne asigur\u0103m c\u0103 sarcina cu \u00eent\u00e2rziere scurt\u0103 prime\u0219te prioritate fa\u021b\u0103 de sarcina batch \u00een distribu\u021bia timpului procesorului. F\u0103r\u0103 o astfel de prioritizare, sarcina batch va acapara tot timpul de procesor \u00een momentul \u00een care este necesar prod. \u00cen Docker run nu exist\u0103 op\u021biuni de prioritizare a containerelor, dar politicile de planificare a procesorului \u00een Linux vin \u00een ajutor. Despre acestea se poate citi \u00een detaliu <noindex><a rel=\"nofollow\" href=\"http:\/\/man7.org\/linux\/man-pages\/man2\/sched_setscheduler.2.html\">aici<\/a><\/noindex>, iar \u00een cadrul acestui articol vom trece prin ele pe scurt:<\/p>\n<p><\/p>\n<ul>\n<li><strong>SCHED_OTHER<\/strong><br \/>\n\u00cen mod implicit, toate procesele utilizatorilor obi\u0219nui\u021bi de pe o ma\u0219in\u0103 Linux primesc aceast\u0103 politic\u0103.<\/li>\n<li><strong>SCHED_BATCH<\/strong><br \/>\nDestinat pentru procese care consum\u0103 multe resurse. Atunci c\u00e2nd o sarcin\u0103 este plasat\u0103 \u00een procesor, se introduce a\u0219a-numita penalizare de activare: o astfel de sarcin\u0103 are \u0219anse mai mici de a ob\u021bine resursele procesorului dac\u0103 acesta este momentan utilizat de o sarcin\u0103 cu SCHED_OTHER<\/li>\n<li><strong>SCHED_IDLE<\/strong><br \/>\nUn proces de fundal cu o prioritate foarte sc\u0103zut\u0103, chiar mai mic\u0103 dec\u00e2t nice \u201319. Folosim biblioteca noastr\u0103 cu cod surs\u0103 deschis <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/odnoklassniki\/one-nio\">one-nio<\/a><\/noindex>, pentru a stabili politica necesar\u0103 la pornirea containerului prin apelul<\/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>Dar chiar dac\u0103 nu programezi \u00een Java, acela\u0219i lucru se poate face cu comanda chrt:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">chrt -i 0 $pid<\/code><\/pre>\n<p><\/p>\n<p>S\u0103 adun\u0103m toate nivelurile noastre de izolare \u00eentr-un tabel pentru claritate:<\/p>\n<p><\/p>\n<p>Clasa de izolare<br \/>\nExemplu alloc<br \/>\nOp\u021biuni 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>*Dac\u0103 faci chrt din interiorul containerului, poate fi necesar s\u0103 ai capability sys_nice, deoarece implicit Docker elimin\u0103 aceast\u0103 capacitate la pornirea containerului.<\/p>\n<p><\/p>\n<p>Dar sarcinile consum\u0103 nu numai procesor, ci \u0219i trafic, care afecteaz\u0103 \u0219i mai mult \u00eent\u00e2rzierea sarcinii de re\u021bea dec\u00e2t o distribu\u021bie gre\u0219it\u0103 a resurselor procesorului. De aceea, dorim, \u00een mod natural, s\u0103 ob\u021binem o imagine exact\u0103 \u0219i pentru trafic. Adic\u0103, atunci c\u00e2nd sarcina prod trimite pachete \u00een re\u021bea, limit\u0103m viteza maxim\u0103 (formula <em>alloc: lan=[*,500mbps)<\/em> ), cu care prod poate face acest lucru. Iar pentru batch garant\u0103m doar l\u0103\u021bimea de band\u0103 minim\u0103, dar nu limit\u0103m maxima (formula <em>alloc: lan=[10Mbps,*)<\/em> ) \u00cen acest timp, traficul prod ar trebui s\u0103 aib\u0103 prioritate fa\u021b\u0103 de sarcinile batch.<br \/>\nAici Docker nu are nicio primitiv\u0103 pe care am putea-o folosi. Dar ne vine \u00een ajutor <noindex><a rel=\"nofollow\" href=\"http:\/\/lartc.org\/\">Controlul Traficului Linux<\/a><\/noindex>. Am reu\u0219it s\u0103 ob\u021binem rezultatul dorit cu ajutorul disciplinei <noindex><a rel=\"nofollow\" href=\"http:\/\/linux-ip.net\/articles\/hfsc.en\/\">Hierarchical Fair Service Curve<\/a><\/noindex>. Cu ajutorul acesteia, aloc\u0103m dou\u0103 clase de trafic: prod de \u00eenalt\u0103 prioritate \u0219i batch\/idle de prioritate sc\u0103zut\u0103. \u00cen cele din urm\u0103, configura\u021bia pentru traficul ie\u0219itor devine astfel:<\/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 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/3f52a968118b6021bd0c920af17a00c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>aici 1:0 \u2014 &#171;qdisc r\u0103d\u0103cin\u0103&#187; disciplina hsfc; 1:1 \u2014 clas\u0103 secundar\u0103 hsfc cu un limit comun de l\u0103\u021bime de band\u0103 de 8 Gbit\/s, sub care sunt incluse clasele secundare ale tuturor containerelor; 1:2 \u2014 clas\u0103 secundar\u0103 hsfc comun\u0103 pentru toate sarcinile batch \u0219i idle cu un limit &#171;dinamic&#187;, despre care se discut\u0103 mai jos. Celelalte clase secundare hsfc sunt clase dedicate pentru containerele prod care func\u021bioneaz\u0103 \u00een prezent cu limite corespunz\u0103toare manifestelor lor, \u2014 450 \u0219i 400 Mbit\/s. Fiec\u0103rui clas\u0103 hsfc \u00eei este atribuit\u0103 o coad\u0103 qdisc fq sau fq_codel, \u00een func\u021bie de versiunea nucleului linux, pentru a evita pierderile de pachete \u00een timpul cre\u0219terilor de trafic. <\/p>\n<p><\/p>\n<p>De obicei, disciplinele tc sunt folosite pentru a prioritiza doar traficul de ie\u0219ire. Dar dorim s\u0103 prioritiz\u0103m \u0219i traficul de intrare, pentru c\u0103 o sarcin\u0103 batch ar putea ocupa tot canalul de intrare, primind, de exemplu, un pachet mare de date de intrare pentru map&amp;reduce. Pentru aceasta, folosim modulul <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/350023\/tc-ingress-policing-and-ifb-mirroring\">ifb<\/a><\/noindex>, care crea un interf\u0103\u021b ifbX virtual pentru fiecare interfa\u021b\u0103 de re\u021bea \u0219i redirec\u021bioneaz\u0103 traficul de intrare de pe interfa\u021b\u0103 \u00een ie\u0219ire pe ifbX. Apoi, pentru ifbX func\u021bioneaz\u0103 toate acelea\u0219i discipline pentru controlul traficului de ie\u0219ire, pentru care configura\u021bia hsfc va fi foarte asem\u0103n\u0103toare:<\/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 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/967da9c0637cc70ba195af781db18adf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>\u00cen timpul experimentelor, am descoperit c\u0103 cele mai bune rezultate hsfc se ob\u021bin atunci c\u00e2nd clasa 1:2 a traficului batch\/idle neprioritar este limitat\u0103 pe ma\u0219inile-minion la o l\u0103\u021bime liber\u0103 de band\u0103. \u00cen caz contrar, traficul neprioritar influen\u021beaz\u0103 prea mult \u00eent\u00e2rzierea sarcinilor prod. Valoarea curent\u0103 a l\u0103\u021bimii de band\u0103 liber\u0103 este determinat\u0103 de miniond \u00een fiecare secund\u0103, m\u0103sur\u00e2nd consumul mediu de trafic de c\u0103tre toate sarcinile prod ale acestui minion <img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/9d6f38110d3b1693afe222b01430b9bb.jpg\" style=\"display:block;margin: 0 auto;\" \/> \u0219i sc\u0103z\u00e2nd-o din l\u0103\u021bimea de band\u0103 a interfe\u021bei de re\u021bea <img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/d5608ec4c58e44b8571ab0b1d0cc7701.jpg\" style=\"display:block;margin: 0 auto;\" \/> cu un mic rezerv\u0103, adic\u0103.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/fb01347c2224bd5bbd82169861eeb7e4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>L\u0103\u021bimile sunt definite pentru traficul de intrare \u0219i de ie\u0219ire independent. \u0218i conform noilor valori miniond reconfigureaz\u0103 limita clasei neprioritare 1:2.<\/p>\n<p><\/p>\n<p>Astfel, am implementat toate cele trei clase de izolare: prod, batch \u0219i idle. Aceste clase influen\u021beaz\u0103 semnificativ performan\u021bele execu\u021biei sarcinilor. De aceea, am decis s\u0103 plas\u0103m acest atribut sus \u00een ierarhie, pentru a fi evident din numele cozii ierarhice cu ce ne confrunt\u0103m: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/34dc89c461db711b19a0f4eccc50efce.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Toate fronturi cunoscute <strong>web<\/strong> \u0219i <strong>music<\/strong> ocupa\u021bi apoi ierarhiile sub prod. De exemplu, sub batch s\u0103 plas\u0103m serviciul <strong>catalog muzical<\/strong>, care periodic creeaz\u0103 un catalog de melodii dintr-un set de fi\u0219iere mp3 \u00eenc\u0103rcate \u00een \u00ab\u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0438\u00bb. Un exemplu de serviciu pentru idle poate fi <strong>transformator de muzic\u0103<\/strong>, care normalizeaz\u0103 nivelul de volum al muzicii.<\/p>\n<p><\/p>\n<p>\u00cendep\u0103rt\u00e2nd din nou liniile inutile, putem scrie numele serviciilor noastre mai simplu, ad\u0103ug\u00e2nd clasa de izolare a sarcinii la sf\u00e2r\u0219itul numelui complet al serviciului: <strong>web.front.prod<\/strong>, <strong>catalog.music.batch<\/strong>, <strong>transformer.music.idle<\/strong>.<\/p>\n<p><\/p>\n<p>\u0218i acum, privind la numele serviciului, \u00een\u021belegem nu doar ce func\u021bie \u00eendepline\u0219te, ci \u0219i clasa de izolare a acestuia, iar asta \u00eenseamn\u0103 criticitatea sa etc.<\/p>\n<p><\/p>\n<p>Totul este minunat, dar exist\u0103 o adev\u0103rat\u0103 am\u0103r\u0103ciune. Este imposibil s\u0103 izol\u0103m complet sarcinile care ruleaz\u0103 pe aceea\u0219i ma\u0219in\u0103.<\/p>\n<p><\/p>\n<p>Ce am reu\u0219it s\u0103 ob\u021binem: dac\u0103 batch consum\u0103 intens <strong>doar<\/strong> resursele procesorului, planificatorul \u00eencorporat al CPU-ului Linux \u00ee\u0219i face foarte bine treaba, iar influen\u021ba asupra sarcinii prod este practic inexistent\u0103. Dar dac\u0103 aceast\u0103 sarcin\u0103 batch \u00eencepe s\u0103 lucreze activ cu memoria, atunci influen\u021ba reciproc\u0103 devine evident\u0103. Acest lucru se \u00eent\u00e2mpl\u0103 deoarece sarcina prod 'scoate' cache-urile procesorului din memorie \u2014 \u00een rezultatul acesta cresc ratele de e\u0219ec \u00een cache, iar procesorul proceseaz\u0103 sarcina prod mai lent. O astfel de sarcin\u0103 batch poate cre\u0219te \u00eent\u00e2rzierile containerului nostru tipic prod cu 10%.<\/p>\n<p><\/p>\n<p>Este \u0219i mai complicat s\u0103 izol\u0103m traficul din cauza c\u0103 modernii cipuri de re\u021bea au o coad\u0103 intern\u0103 de pachete. Dac\u0103 un pachet din sarcina batch a intrat primul acolo, \u00eenseamn\u0103 c\u0103 va fi transmis primul prin cablu, \u0219i nu avem ce face \u00een leg\u0103tur\u0103 cu asta.<\/p>\n<p><\/p>\n<p>\u00cen plus, deocamdat\u0103 am reu\u0219it s\u0103 rezolv\u0103m doar problema prioritiz\u0103rii traficului TCP: pentru UDP, abordarea cu hsfc nu func\u021bioneaz\u0103. \u0218i chiar \u0219i \u00een cazul traficului TCP, dac\u0103 sarcina batch genereaz\u0103 mult trafic, acest lucru aduce de asemenea o cre\u0219tere de aproximativ 10% a \u00eent\u00e2rzierii sarcinii prod.<\/p>\n<p><\/p>\n<h2 id=\"otkazoustoychivost\">Redundan\u021b\u0103<\/h2>\n<p><\/p>\n<p>Unul dintre obiectivele \u00een dezvoltarea one-cloud a fost \u00eembun\u0103t\u0103\u021birea rezisten\u021bei la defec\u021biuni pentru \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0438. Prin urmare, a\u0219 dori s\u0103 analizez mai detaliat posibilele scenarii de defec\u021biuni \u0219i accidente. S\u0103 \u00eencepem cu un scenariu simplu \u2014 cu defec\u021biunea unui container. <\/p>\n<p><\/p>\n<p>Un container poate e\u0219ua \u00een mai multe moduri. Poate fi vorba despre un experiment, un bug sau o eroare \u00een manifest, ceea ce determin\u0103 o sarcin\u0103 de produc\u021bie s\u0103 consume mai multe resurse dec\u00e2t cele specificate \u00een manifest. Am avut un caz: un dezvoltator a implementat un algoritm complex, l-a ref\u0103cut de mai multe ori, s-a complicat at\u00e2t de mult \u00eenc\u00e2t, \u00een cele din urm\u0103, sarcina s-a blocat \u00eentr-un ciclu destul de complex. \u0218i, av\u00e2nd \u00een vedere c\u0103 sarcina de produc\u021bie are prioritate mai mare dec\u00e2t toate celelalte pe acelea\u0219i minioane, a \u00eenceput s\u0103 consume toate resursele disponibile ale procesorului. \u00cen aceast\u0103 situa\u021bie, izolarea a salvat situa\u021bia, mai exact cota pe timpul CPU. Dac\u0103 sarcinii i se aloc\u0103 o cot\u0103, aceasta nu va consuma mai mult. Prin urmare, toate sarcinile batch \u0219i celelalte sarcini de produc\u021bie care func\u021bionau pe aceea\u0219i ma\u0219in\u0103 nu au observat nimic. <\/p>\n<p><\/p>\n<p>A doua problem\u0103 posibil\u0103 este pr\u0103bu\u0219irea containerului. \u0218i aici ne ajut\u0103 politicile de restart, pe care toat\u0103 lumea le cunoa\u0219te; Docker se descurc\u0103 perfect. Practic, toate sarcinile de produc\u021bie au o politic\u0103 de restart 'always'. Uneori folosim 'on_failure' pentru sarcinile batch sau pentru depanarea containerelor de produc\u021bie.<\/p>\n<p><\/p>\n<p>Ce putem face \u00een cazul \u00een care un \u00eentreg minion devine inaccesibil?<\/p>\n<p><\/p>\n<p>Evident, putem rula containerul pe o alt\u0103 ma\u0219in\u0103. Ceea ce este interesant aici este ce se \u00eent\u00e2mpl\u0103 cu adresa IP (adreselor) atribuite containerului. <\/p>\n<p><\/p>\n<p>Putem atribui containerelor acelea\u0219i adrese IP ca cele ale ma\u0219inilor-minion pe care aceste containere sunt rulate. A\u0219adar, la pornirea unui container pe o alt\u0103 ma\u0219in\u0103, adresa sa IP se schimb\u0103 \u0219i to\u021bi clien\u021bii trebuie s\u0103 \u00een\u021beleag\u0103 c\u0103 containerul s-a mutat, iar acum trebuie s\u0103 acceseze o alt\u0103 adres\u0103, ceea ce necesit\u0103 un serviciu de Service Discovery separat. <\/p>\n<p><\/p>\n<p>Service Discovery este convenabil. Pe pia\u021b\u0103 exist\u0103 multe solu\u021bii de diferite grade de fiabilitate pentru organizarea unui registru de servicii. Adesea, \u00een astfel de solu\u021bii se implementeaz\u0103 logica unui balancer de sarcin\u0103, stocarea unei configura\u021bii suplimentare sub form\u0103 de KV-storage etc.<br \/>\nCu toate acestea, ne-ar pl\u0103cea s\u0103 putem evita necesitatea introducerii unui registru separat, deoarece aceasta ar \u00eensemna introducerea unui sistem critic utilizat de toate serviciile \u00een mediu de produc\u021bie. Asta \u00eenseamn\u0103 c\u0103 ar fi un punct poten\u021bial de e\u0219ec \u0219i trebuie s\u0103 alegem sau s\u0103 dezvolt\u0103m o solu\u021bie foarte fiabil\u0103, ceea ce, evident, nu este deloc simplu, dureaz\u0103 mult \u0219i cost\u0103 mult. <\/p>\n<p><\/p>\n<p>\u0218i o alt\u0103 mare problem\u0103: pentru ca infrastructura noastr\u0103 veche s\u0103 func\u021bioneze cu cea nou\u0103, ar trebui s\u0103 rescriem absolut toate sarcinile pentru a utiliza un sistem de Service Discovery. Este un volum de munc\u0103 FOARTE mare, iar uneori devine imposibil, mai ales c\u00e2nd vine vorba de dispozitive la nivel de kernel sau care interac\u021bioneaz\u0103 direct cu hardware-ul. Implementarea acestei func\u021bionalit\u0103\u021bi prin tiparele consacrate de solu\u021bii, cum ar fi <noindex><a rel=\"nofollow\" href=\"https:\/\/linkerd.io\">side-car<\/a><\/noindex> ar \u00eensemna uneori o \u00eenc\u0103rcare suplimentar\u0103, alteori \u2014 o complicare a exploat\u0103rii \u0219i scenarii suplimentare de e\u0219ec. Nu ne-am dorit s\u0103 complic\u0103m lucrurile, a\u0219a c\u0103 am decis s\u0103 facem utilizarea Service Discovery op\u021bional\u0103. <\/p>\n<p><\/p>\n<p>\u00cen one-cloud, IP-ul urm\u0103re\u0219te containerul, adic\u0103 fiecare instan\u021b\u0103 a sarcinii are propria adres\u0103 IP. Aceast\u0103 adres\u0103 este \u201estatic\u0103\u201d: ea este alocat\u0103 fiec\u0103rei instan\u021be \u00een momentul primei trimitere a serviciului \u00een cloud. Dac\u0103 pe parcursul vie\u021bii serviciului a existat un num\u0103r variabil de instan\u021be, atunci \u00een final va fi alocat\u0103 at\u00e2t de multe adrese IP c\u00e2te instan\u021be au fost maximum existente.<\/p>\n<p><\/p>\n<p>Ulterior, aceste adrese nu se modific\u0103: sunt alocate o singur\u0103 dat\u0103 \u0219i continu\u0103 s\u0103 existe pe toat\u0103 durata de via\u021b\u0103 a serviciului \u00een produc\u021bie. Adresele IP urm\u0103resc containerele prin re\u021bea. Dac\u0103 un container este mutat pe alt minion, atunci \u0219i adresa \u00eel va urma. <\/p>\n<p><\/p>\n<p>Astfel, asocierea numelui serviciului cu lista adreselor sale IP se schimb\u0103 foarte rar. Dac\u0103 privim din nou la numele instan\u021belor serviciului pe care le-am men\u021bionat la \u00eenceputul articolului (<strong>1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, \u2026<\/strong>), atunci ne putem da seama c\u0103 acestea seam\u0103n\u0103 cu FQDN-urile utilizate \u00een DNS. \u0218i da, pentru a afi\u0219a numele instan\u021belor serviciilor \u00een adresele lor IP, folosim protocolul DNS. Acest DNS returneaz\u0103 toate adresele IP rezervate ale tuturor containerelor \u2014 at\u00e2t cele active, c\u00e2t \u0219i cele oprite (de exemplu, dac\u0103 folosim trei replici, dar avem cinci adrese rezervate \u2014 toate cele cinci vor fi returnate). Clien\u021bii, primind aceste informa\u021bii, vor \u00eencerca s\u0103 se conecteze la toate cele cinci replici \u2014 \u0219i astfel vor identifica care dintre ele sunt active. Aceast\u0103 metod\u0103 de determinare a disponibilit\u0103\u021bii este semnificativ mai fiabil\u0103, neimplic\u00e2nd nici DNS, nici Service Discovery, astfel \u00eenc\u00e2t nu exist\u0103 probleme greu de rezolvat cu men\u021binerea actualizat\u0103 a informa\u021biilor \u0219i a rezilien\u021bei acestor sisteme. Mai mult, \u00een cazul serviciilor critice, de la care depinde func\u021bionarea \u00eentregului portal, putem s\u0103 nu folosim deloc DNS, ci pur \u0219i simplu s\u0103 introducem adresele IP \u00een configura\u021bie.<\/p>\n<p><\/p>\n<p>Implementarea unei astfel de migra\u021bii a IP-urilor \u00eentre containere poate fi non-trivial\u0103 \u2014 \u0219i ne vom opri asupra modului \u00een care func\u021bioneaz\u0103, pe urm\u0103torul exemplu:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/faf99c2609a57daa1bdc193cb0f4cb31.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>S\u0103 presupunem c\u0103 masterul one-cloud d\u0103 comanda minionului M1 s\u0103 porneasc\u0103 <strong>1.ok-web.group1.web.front.prod<\/strong> cu adresa 1.1.1.1. Pe minion func\u021bioneaz\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Bird_Internet_routing_daemon\">BIRD<\/a><\/noindex>, care anun\u021b\u0103 aceast\u0103 adres\u0103 \u00een serverele speciale <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Route_reflector\">route reflector<\/a><\/noindex>. Acestea au o sesiune BGP cu echipamentul de re\u021bea, \u00een care se transmite ruta adresei 1.1.1.1 la M1. M1 roteaz\u0103 pachetele \u00een interiorul containerului folosind instrumentele Linux. Exist\u0103 trei servere route reflector, deoarece aceasta este o parte foarte critic\u0103 a infrastructurii one-cloud \u2014 f\u0103r\u0103 ele, re\u021beaua \u00een one-cloud nu va func\u021biona. Le plas\u0103m \u00een rackuri diferite, dac\u0103 este posibil \u00een s\u0103li diferite ale centrului de date, pentru a reduce probabilitatea unei defec\u021biuni simultane a tuturor celor trei.<\/p>\n<p><\/p>\n<p>Acum s\u0103 presupunem c\u0103 leg\u0103tura \u00eentre masterul one-cloud \u0219i minionul M1 a disp\u0103rut. Masterul one-cloud va ac\u021biona acum, presupun\u00e2nd c\u0103 M1 a e\u0219uat complet. Adic\u0103 va da comanda minionului M2 s\u0103 porneasc\u0103 <strong>web.group1.web.front.prod<\/strong> cu aceea\u0219i adres\u0103 1.1.1.1. Acum avem dou\u0103 rute conflictuale \u00een re\u021bea pentru 1.1.1.1: pe M1 \u0219i pe M2. Pentru a rezolva astfel de conflicte, folosim Multi Exit Discriminator, care este specificat \u00een anun\u021bul BGP. Acest num\u0103r arat\u0103 greutatea rutei anun\u021bate. Din cele conflictuale, va fi aleas\u0103 ruta cu valoarea MED mai mic\u0103. Masterul one-cloud suport\u0103 MED ca parte integrant\u0103 a adreselor IP ale containerelor. Adresa este emis\u0103 pentru prima dat\u0103 cu un MED suficient de mare = 1.000.000. \u00cen situa\u021bia unei astfel de mut\u0103ri de urgen\u021b\u0103 a containerului, masterul reduce MED-ul, iar M2 va primi comanda de a anun\u021ba adresa 1.1.1.1 cu MED = 999.999. Instan\u021ba care func\u021bioneaz\u0103 pe M1 va r\u0103m\u00e2ne f\u0103r\u0103 conexiune, iar soarta sa ulterioar\u0103 nu ne intereseaz\u0103 prea mult p\u00e2n\u0103 la restabilirea conexiunii cu masterul, c\u00e2nd va fi oprit ca un dublu vechi.<\/p>\n<p><\/p>\n<h2 id=\"avarii\">Avarii<\/h2>\n<p><\/p>\n<p>Toate sistemele de management al datacentrelor gestioneaz\u0103 \u00eentotdeauna acceptabil e\u0219ecurile minore. C\u0103derea unui container este o norm\u0103 aproape peste tot.<\/p>\n<p><\/p>\n<p>S\u0103 analiz\u0103m cum gestion\u0103m o avarie, de exemplu o \u00eentrerupere a aliment\u0103rii \u00een una sau mai multe \u00eenc\u0103peri ale datacenter-ului.<\/p>\n<p><\/p>\n<p>Ce \u00eenseamn\u0103 o avarie pentru sistemul de management al datacenter-ului? \u00cen primul r\u00e2nd, este o defalcare masiv\u0103 a multor ma\u0219ini \u00een acela\u0219i timp, iar sistemul de management trebuie s\u0103 migreze simultan un num\u0103r mare de containere. Dar dac\u0103 avaria este foarte extins\u0103, este posibil ca toate sarcinile s\u0103 nu poat\u0103 fi relocuite pe alte ma\u0219ini, deoarece capacitatea resurselor a datacenter-ului scade sub 100% din sarcin\u0103. <\/p>\n<p><\/p>\n<p>Adesea, avariile sunt precedate de o defalcare a stratului de control. Acest lucru se poate \u00eent\u00e2mpla din cauza defect\u0103rii echipamentului s\u0103u, dar mai frecvent din cauza faptului c\u0103 avariile nu sunt testate, iar stratul de control se pr\u0103bu\u0219e\u0219te din cauza \u00eenc\u0103rc\u0103rilor crescute. <\/p>\n<p><\/p>\n<p>Ce se poate face cu toate acestea?<\/p>\n<p><\/p>\n<p>Migra\u021biile \u00een mas\u0103 \u00eenseamn\u0103 c\u0103 \u00een infrastructur\u0103 apar multe ac\u021biuni, migra\u021bii \u0219i plasamente. Fiecare migra\u021bie poate dura un timp necesar pentru livrarea \u0219i desf\u0103\u0219urarea imaginilor containerelor pe ma\u0219ini, lansarea \u0219i ini\u021bializarea containerelor etc. Prin urmare, este de dorit ca sarcinile mai importante s\u0103 fie lansate \u00eenaintea celor mai pu\u021bin importante.<\/p>\n<p><\/p>\n<p>S\u0103 privim din nou la ierarhia de servicii pe care o cunoa\u0219tem \u0219i s\u0103 \u00eencerc\u0103m s\u0103 decid\u0103m ce sarcini dorim s\u0103 lans\u0103m \u00een primul r\u00e2nd.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/2e827271adb8d3ff3d385e53553aaacf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Desigur, acestea sunt procesele care particip\u0103 direct la procesarea cererilor utilizatorilor, adic\u0103 prod. Acest lucru este specificat prin <strong>prioritatea plas\u0103rii<\/strong> \u2014 un num\u0103r care poate fi atribuit unei cozi. Dac\u0103 o coad\u0103 are o prioritate mai mare, serviciile sale sunt plasate cu prioritate.<\/p>\n<p><\/p>\n<p>Pe prod, atribuim priorit\u0103\u021bi mai mari, 0; pe batch \u2014 pu\u021bin mai mici, 100; pe idle \u2014 chiar \u0219i mai mici, 200. Priorit\u0103\u021bile se aplic\u0103 ierarhic. Toate sarcinile de sub ierarhie vor avea prioritatea corespunz\u0103toare. Dac\u0103 dorim ca \u00een interiorul prod s\u0103 fie active cache-urile \u00eenaintea frontend-urilor, atunci atribuim prioritate cache-ului = 0 \u0219i frontend-urilor subordonate = 1. De exemplu, dac\u0103 dorim ca portalul principal s\u0103 porneasc\u0103 \u00eenaintea frontend-ului muzical, putem atribui unei priorit\u0103\u021bi mai mici pentru acesta \u2014 10.<\/p>\n<p><\/p>\n<p>Urm\u0103toarea problem\u0103 este lipsa de resurse. A\u0219adar, am avut o defec\u021biune la un num\u0103r mare de echipamente, \u00eentregi s\u0103li de centre de date, iar noi am activat at\u00e2t de multe servicii \u00eenc\u00e2t acum nu avem suficiente resurse. Trebuie s\u0103 decid\u0103m ce sarcini s\u0103 sacrific\u0103m pentru a avea func\u021bionale serviciile principale critice. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/1b1ad3da16df6677dd0ba4b038cdd7d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Spre deosebire de prioritatea plas\u0103rii, nu putem sacrifica toat\u0103 sarcinile batch; unele dintre ele sunt importante pentru func\u021bionarea portalului. Prin urmare, am dedicat separat <strong>prioritatea de excludere<\/strong> sarcinii. Atunci c\u00e2nd se plaseaz\u0103 o sarcin\u0103 cu prioritate mai mare, aceasta poate exclude, adic\u0103 opri o sarcin\u0103 cu prioritate mai mic\u0103, dac\u0103 nu exist\u0103 minioni disponibili. \u00cen acest caz, sarcina cu prioritate sc\u0103zut\u0103 va r\u0103m\u00e2ne probabil neplasat\u0103, adic\u0103 nu va mai exista un minion potrivit cu suficiente resurse libere.<\/p>\n<p><\/p>\n<p>\u00cen ierarhia noastr\u0103, este foarte simplu s\u0103 specific\u0103m o prioritate de excludere astfel \u00eenc\u00e2t sarcinile prod \u0219i batch s\u0103 exclud\u0103 sau s\u0103 opreasc\u0103 sarcinile idle, dar nu una pe cealalt\u0103, specific\u00e2nd pentru idle o prioritate de 200. La fel ca \u00een cazul priorit\u0103\u021bii plas\u0103rii, putem folosi ierarhia noastr\u0103 pentru a descrie reguli mai complexe. De exemplu, specific\u0103m c\u0103, pentru func\u021bia de muzic\u0103, sacrific\u0103m dac\u0103 ne lipsesc resursele pentru portalul web principal, stabilind pentru nodurile corespunz\u0103toare o prioritate mai mic\u0103: 10.<\/p>\n<p><\/p>\n<h2 id=\"avarii-dc-celikom\">Accidente ale DC-ului \u00een \u00eentregime<\/h2>\n<p><\/p>\n<p>De ce poate e\u0219ua \u00eentregul centru de date? For\u021ba naturii. A fost un articol bun despre cum <noindex><a rel=\"nofollow\" href=\"https:\/\/habrahabr.ru\/company\/dataline\/blog\/333578\/\">uraganul a afectat func\u021bionarea centrului de date<\/a><\/noindex>. Oamenii f\u0103r\u0103 ad\u0103post pot fi considera\u021bi o for\u021b\u0103 a naturii, av\u00e2nd \u00een vedere c\u0103 au ars odat\u0103 fibra optic\u0103 \u00eentr-un canal \u0219i centrul de date a pierdut complet leg\u0103tura cu celelalte loca\u021bii. Cauza defec\u021biunii poate fi \u0219i factorul uman: un operator poate da o comand\u0103 astfel \u00eenc\u00e2t \u00eentregul centru de date s\u0103 se pr\u0103bu\u0219easc\u0103. Acest lucru se poate \u00eent\u00e2mpla din cauza unui bug major. \u00cen general, centrele de date se pr\u0103bu\u0219esc \u2014 nu este ceva rar. La noi se \u00eent\u00e2mpl\u0103 o dat\u0103 la c\u00e2teva luni. <\/p>\n<p><\/p>\n<p>\u0218i iat\u0103 ce facem pentru ca nimeni s\u0103 nu posteze \u00een #okjivi pe Twitter.<\/p>\n<p><\/p>\n<p>Prima strategie \u2014 izolare. Fiecare instan\u021b\u0103 one-cloud este izolat\u0103 \u0219i poate gestiona ma\u0219inile doar dintr-un singur centru de date. Asta \u00eenseamn\u0103 c\u0103 pierderea unui nor din cauza bug-urilor sau a unei comenzi gre\u0219ite a operatorului \u2014 este pierderea doar unui centru de date. Suntem preg\u0103ti\u021bi pentru asta: avem o politic\u0103 de rezervare, conform c\u0103reia replicile aplica\u021biei \u0219i ale datelor sunt plasate \u00een toate centrele de date. Folosim baze de date rezistente la defectiuni \u0219i test\u0103m periodic aceste defecte.<br \/>\nDeoarece ast\u0103zi avem patru centre de date, avem \u0219i patru instan\u021be separate, complet izolate de one-cloud.<\/p>\n<p><\/p>\n<p>Aceast\u0103 abordare nu doar c\u0103 protejeaz\u0103 \u00eempotriva defec\u021biunilor fizice, dar poate proteja \u0219i \u00eempotriva erorilor operatorului.<\/p>\n<p><\/p>\n<p>Ce altceva mai putem face cu factorul uman? Atunci c\u00e2nd un operator d\u0103 o comand\u0103 ciudat\u0103 sau poten\u021bial periculoas\u0103 norului, acesta poate fi solicitat brusc s\u0103 rezolve o mic\u0103 sarcin\u0103 pentru a verifica c\u00e2t de bine s-a g\u00e2ndit la asta. De exemplu, dac\u0103 este o oprire masiv\u0103 a multor replici sau pur \u0219i simplu o comand\u0103 ciudat\u0103 \u2014 reducerea num\u0103rului de replici sau schimbarea numelui imaginii, nu doar a num\u0103rului de versiune din noul manifest.<\/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 sistem de operare la nivel de centru de date \u00een Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/f7ee44a77e30612a3cd99a6f7aee3820.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<h2 id=\"itogi\">Concluzii<\/h2>\n<p><\/p>\n<p>Caracteristicile distinctive ale one-cloud: <\/p>\n<p><\/p>\n<ul>\n<li><strong>Un sistem de denumire ierarhic \u0219i vizual pentru servicii \u0219i containere<\/strong>, care permite identificarea rapid\u0103 a sarcinii, a domeniului de aplicare \u0219i a func\u021bion\u0103rii acesteia, precum \u0219i a persoanei responsabile. <\/li>\n<li>Folosim <strong>tehnologia noastr\u0103 de combinare a sarcinilor prod- \u0219i batch-<\/strong>pe minioni pentru a cre\u0219te eficien\u021ba utiliz\u0103rii ma\u0219inilor. \u00cen loc de cpuset, folosim cote CPU, ac\u021biuni, politici ale programatorului CPU \u0219i QoS Linux.<\/li>\n<li>Nu am reu\u0219it s\u0103 izol\u0103m complet containerele care ruleaz\u0103 pe aceea\u0219i ma\u0219in\u0103, dar influen\u021ba lor reciproc\u0103 r\u0103m\u00e2ne \u00een limite de p\u00e2n\u0103 la 20%.<\/li>\n<li>Organizarea serviciilor \u00eentr-o ierarhie ajut\u0103 la eliminarea automat\u0103 a accidentelor prin <strong>priorit\u0103\u021bi de plasare \u0219i de \u00eenl\u0103turare.<\/strong>.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"chavo\">FAQ<\/h2>\n<p><\/p>\n<p>De ce nu am adoptat o solu\u021bie gata f\u0103cut\u0103.<\/p>\n<p><\/p>\n<ul>\n<li>Diferitele clase de izolare a task-urilor necesit\u0103 o logic\u0103 diferit\u0103 pentru alocarea pe minioni. Dac\u0103 sarcinile prod pot fi alocate prin rezervarea simpl\u0103 a resurselor, atunci batch \u0219i idle trebuie alocate urm\u0103rind utilizarea real\u0103 a resurselor pe ma\u0219inile minioni. <\/li>\n<li>Necesitatea de a considera resursele consumate de aceste sarcini, cum ar fi: \n<ul>\n<li>l\u0103\u021bimea de band\u0103 a re\u021belei;<\/li>\n<li>tipurile \u0219i \u201espindelii\u201d discurilor.<\/li>\n<\/ul>\n<\/li>\n<li>Necesitatea de a specifica priorit\u0103\u021bile serviciilor \u00een cazul unor \u00eentreruperi, drepturile \u0219i cotele echipelor pentru resurse, ceea ce se rezolv\u0103 prin intermediul cozii ierarhice \u00een one-cloud.<\/li>\n<li>Necesitatea de a avea denumiri umane pentru module pentru a reduce timpul de reac\u021bie la incidente \u0219i \u00eentreruperi.<\/li>\n<li>Imposibilitatea de a implementa simultan Service Discovery \u00een \u00eentreaga re\u021bea; necesitatea de a coexista o perioad\u0103 mai lung\u0103 cu sarcinile alocate pe servere fizice \u2014 ceea ce se rezolv\u0103 prin intermediul adreselor IP \u201estatice\u201d care urmeaz\u0103 modulelor, \u0219i, ca urmare, necesitatea unei integr\u0103ri unice cu o infrastructur\u0103 de re\u021bea mare.<\/li>\n<\/ul>\n<p><\/p>\n<p>Toate aceste func\u021bii ar necesita modific\u0103ri semnificative ale solu\u021biilor existente pentru a se potrivi nevoilor noastre, iar evalu\u00e2nd volumul de munc\u0103, am realizat c\u0103 putem dezvolta propria noastr\u0103 solu\u021bie cu un efort similar. Dar solu\u021bia noastr\u0103 va fi semnificativ mai u\u0219or de exploatat \u0219i dezvoltat \u2014 nu con\u021bine abstrac\u021bii inutile care s\u0103 sus\u021bin\u0103 func\u021bionalit\u0103\u021bi de care nu avem nevoie. <\/p>\n<p><\/p>\n<p>Celor care au citit ultimele r\u00e2nduri \u2014 v\u0103 mul\u021bumim pentru perseveren\u021b\u0103 \u0219i aten\u021bie!<\/p>\n<p>Sursa: <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.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0410\u043b\u043e\u0445\u0430, \u043f\u0438\u043f\u043b!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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 sistem de operare la nivel de data center \u00een Odnoklassniki | ProHoster","description":"Aloha, oameni buni!","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/84114","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=84114"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/84114\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/84115"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=84114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=84114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=84114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}