{"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\/sv\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","title":{"rendered":"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/fa983acacec59ff2d4ed098f87223971.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Aloha, folk! Jag heter Oleg Anastasyev, och jag arbetar i Odnoklassniki i plattformsteamet. Ut\u00f6ver mig finns det massor av h\u00e5rdvara i Odnoklassniki. Vi har fyra datacenter, och i dem finns det cirka 500 rack med mer \u00e4n 8000 servrar. Vid en viss tidpunkt ins\u00e5g vi att implementeringen av ett nytt hanteringssystem skulle l\u00e5ta oss utnyttja tekniken mer effektivt, underl\u00e4tta \u00e5tkomsthantering, automatisera (om)f\u00f6rdelning av ber\u00e4kningsresurser, p\u00e5skynda lanseringen av nya tj\u00e4nster och \u00f6ka reaktionshastigheten vid stora haverier. <\/p>\n<p><\/p>\n<p>Vad blev resultatet av detta? <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>F\u00f6rutom mig och massor av h\u00e5rdvara finns det ocks\u00e5 m\u00e4nniskor som arbetar med dessa maskiner: ingenj\u00f6rer som \u00e4r direkt i datacentren; n\u00e4tverkstekniker som konfigurerar n\u00e4tverksl\u00f6sningarna; administrat\u00f6rer eller SRE som ser till att infrastrukturen \u00e4r fel-tolerant; och team av utvecklare, d\u00e4r varje team ansvarar f\u00f6r en del av portalens funktioner. Programvaran de skapar fungerar ungef\u00e4r s\u00e5 h\u00e4r:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/592fd0acfa7322eb80fbb85601a92918.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Anv\u00e4ndarf\u00f6rfr\u00e5gningar kommer b\u00e5de till fronten av den huvudsakliga portalen <noindex><a rel=\"nofollow\" href=\"http:\/\/www.ok.ru\/\">www.ok.ru<\/a><\/noindex>, s\u00e5v\u00e4l som till andra, till exempel till API:ets musikfronter. F\u00f6r att bearbeta aff\u00e4rslogik anropar de applikationsservern, som vid behandling av f\u00f6rfr\u00e5gningar anropar n\u00f6dv\u00e4ndiga specialiserade mikrotj\u00e4nster \u2014 one-graph (graf \u00f6ver sociala relationer), user-cache (cache f\u00f6r anv\u00e4ndarprofiler) och s\u00e5 vidare.<\/p>\n<p><\/p>\n<p>Varje av dessa tj\u00e4nster \u00e4r distribuerade \u00f6ver m\u00e5nga maskiner, och var och en har ansvariga utvecklare som ansvarar f\u00f6r driften av modulerna, deras underh\u00e5ll och teknologisk utveckling. Alla dessa tj\u00e4nster k\u00f6rs p\u00e5 fysiska servrar, och fram till nyligen k\u00f6rde vi exakt en uppgift p\u00e5 varje server, dvs. den var specialiserad f\u00f6r en specifik uppgift.<\/p>\n<p><\/p>\n<p>Varf\u00f6r s\u00e5? Denna strategi hade flera f\u00f6rdelar:<\/p>\n<p><\/p>\n<ul>\n<li>Det underl\u00e4ttar <strong>massf\u00f6rvaltning<\/strong>. Anta att en uppgift kr\u00e4ver vissa bibliotek, vissa inst\u00e4llningar. D\u00e5 kopplas servern just till en viss grupp, och en policy f\u00f6r cfengine beskriver denna grupp (eller s\u00e5 \u00e4r den redan beskriven), och denna konfiguration distribueras centralt och automatiskt till alla servrar i den gruppen.<\/li>\n<li>Det f\u00f6renklar <strong>diagnostik<\/strong>. Anta att du tittar p\u00e5 en \u00f6kad belastning p\u00e5 centralprocessorn och inser att denna belastning endast kan ha orsakats av den uppgift som k\u00f6rs p\u00e5 den h\u00e4r kraftfulla processorn. Att finna den skyldige g\u00e5r v\u00e4ldigt snabbt.<\/li>\n<li>Det f\u00f6renklar <strong>\u00f6vervakning<\/strong>. Om det \u00e4r n\u00e5got fel med servern meddelar monitorn detta, och du vet exakt vem som \u00e4r skyldig.<\/li>\n<\/ul>\n<p><\/p>\n<p>En tj\u00e4nst som best\u00e5r av flera repliker tilldelas flera servrar \u2013 en f\u00f6r varje. D\u00e5 tilldelas ber\u00e4kningsresursen f\u00f6r tj\u00e4nsten v\u00e4ldigt enkelt: s\u00e5 m\u00e5nga servrar som tj\u00e4nsten har, s\u00e5 mycket resurser kan den maximalt konsumera. \"Enkelt\" h\u00e4r betyder inte att det \u00e4r l\u00e4tt att anv\u00e4nda, utan att resursf\u00f6rdelningen sker manuellt.<\/p>\n<p><\/p>\n<p>Denna metod till\u00e4t oss ocks\u00e5 att skapa <strong>specialiserade h\u00e5rdvarukonfigurationer<\/strong> f\u00f6r uppgiften som k\u00f6rs p\u00e5 denna server. Om uppgiften lagrar stora datam\u00e4ngder, anv\u00e4nder vi en 4U-server med chassi f\u00f6r 38 diskar. Om uppgiften \u00e4r rent ber\u00e4kningsm\u00e4ssig kan vi k\u00f6pa en billigare 1U-server. Detta \u00e4r effektivt sett till ber\u00e4kningsresurser. Denna metod till\u00e5ter oss ocks\u00e5 att anv\u00e4nda fyra g\u00e5nger f\u00e4rre maskiner vid en belastning j\u00e4mf\u00f6rbar med ett av v\u00e5ra v\u00e4nliga sociala n\u00e4tverk. <\/p>\n<p><\/p>\n<p>Denna effektivitet i anv\u00e4ndningen av ber\u00e4kningsresurser b\u00f6r ocks\u00e5 ge ekonomisk effektivitet, om man utg\u00e5r fr\u00e5n antagandet att det dyraste \u00e4r servrar. Under l\u00e5ng tid var h\u00e5rdvara det dyraste, och vi har lagt ner mycket energi p\u00e5 att minska kostnaden f\u00f6r h\u00e5rdvara genom att utveckla algoritmer f\u00f6r att s\u00e4kerst\u00e4lla redundans och minska kraven p\u00e5 h\u00e5rdvarans tillf\u00f6rlitlighet. Idag har vi n\u00e5tt en punkt d\u00e4r serverpriserna inte l\u00e4ngre \u00e4r avg\u00f6rande. Om vi inte r\u00e4knar med den senaste exoteran, spelar den specifika konfigurationen av servrar i en rack ingen roll. Nu har vi ett annat problem \u2013 kostnaden f\u00f6r den plats servern upptar i datacentret, dvs. platsen i rack.<\/p>\n<p><\/p>\n<p>N\u00e4r vi ins\u00e5g detta beslutade vi att r\u00e4kna p\u00e5 hur effektivt vi anv\u00e4nder racken.<br \/>\nVi tog priset f\u00f6r den mest kraftfulla servern som \u00e4r ekonomiskt motiverad, ber\u00e4knade hur m\u00e5nga s\u00e5dana servrar vi kan placera i rack, vilka uppgifter vi skulle k\u00f6ra p\u00e5 dem baserat p\u00e5 den gamla modellen 'en server = en uppgift' och hur effektivt utrustningen skulle kunna anv\u00e4nda s\u00e5dana uppgifter. Det visade sig att v\u00e5r rackanv\u00e4ndning \u00e4r cirka 11 %. Slutsatsen \u00e4r uppenbar: vi m\u00e5ste \u00f6ka effektiviteten i datacenteranv\u00e4ndningen. Det skulle tyckas att l\u00f6sningen \u00e4r sj\u00e4lvklart: man b\u00f6r k\u00f6ra flera uppgifter p\u00e5 en och samma server. Men h\u00e4r b\u00f6rjar sv\u00e5righeterna. <\/p>\n<p><\/p>\n<p>Masskonfigurationen blir pl\u00f6tsligt mycket mer komplicerad - nu g\u00e5r det inte att tilldela en server till en specifik grupp. Eftersom det nu kan k\u00f6ras flera uppgifter fr\u00e5n olika team p\u00e5 en och samma server. Dessutom kan konfigurationen vara konfliktfylld f\u00f6r olika applikationer. Diagnostiken blir ocks\u00e5 mer komplicerad: om du ser \u00f6kad processor- eller diskf\u00f6rbrukning p\u00e5 servern, vet du inte vilken av uppgifterna som orsakar problemen.<\/p>\n<p><\/p>\n<p>Men det fr\u00e4msta problemet \u00e4r att det inte finns n\u00e5gon isolering mellan uppgifter som k\u00f6rs p\u00e5 samma maskin. H\u00e4r \u00e4r till exempel grafen \u00f6ver genomsnittlig svarstid f\u00f6r en serveruppgift f\u00f6re och efter att ett annat, helt orelaterat ber\u00e4kningsprogram har k\u00f6rts p\u00e5 samma server - svarstiden f\u00f6r den prim\u00e4ra uppgiften \u00f6kade kraftigt.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/c7c07359ae572ca8c84a4c63559e4083.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Det \u00e4r uppenbart att uppgifter antingen m\u00e5ste k\u00f6ras i containrar eller virtuella maskiner. Eftersom n\u00e4stan alla v\u00e5ra uppgifter k\u00f6rs under en och samma OS (Linux) eller anpassas f\u00f6r den, beh\u00f6ver vi inte st\u00f6dja m\u00e5nga olika operativsystem. D\u00e4rf\u00f6r beh\u00f6vs inte virtualisering, och p\u00e5 grund av de extra kostnaderna kommer den att vara mindre effektiv \u00e4n containrar.<\/p>\n<p><\/p>\n<p>Som en implementation av containrar f\u00f6r att k\u00f6ra uppgifter direkt p\u00e5 servrar \u00e4r Docker en bra kandidat: filsystemavbilder l\u00f6ser bra problem med konfliktande konfigurationer. Det faktum att avbilder kan best\u00e5 av flera lager g\u00f6r att vi kraftigt kan minska m\u00e4ngden data som kr\u00e4vs f\u00f6r att distribuera dem p\u00e5 infrastrukturen, genom att separera gemensamma delar i egna baslager. D\u00e5 kommer de grundl\u00e4ggande (och mest omfattande) lagren att cachas snabbt p\u00e5 hela infrastrukturen, och f\u00f6r att leverera m\u00e5nga olika typer av applikationer och versioner beh\u00f6vs endast sm\u00e5 lager av \u00f6verf\u00f6ring. <\/p>\n<p><\/p>\n<p>Dessutom ger den f\u00e4rdiga registratorn och taggningen av avbilder i Docker oss f\u00e4rdiga primitiva f\u00f6r versionering och leverans av kod till produktion.<\/p>\n<p><\/p>\n<p>Docker, precis som vilken annan liknande teknologi som helst, ger oss en viss niv\u00e5 av isolering f\u00f6r containrar direkt ur l\u00e5dan. Till exempel, minnesisolering \u2014 varje container f\u00e5r en gr\u00e4ns f\u00f6r hur mycket minne den kan anv\u00e4nda, som inte f\u00e5r \u00f6verskridas. Det g\u00e5r ocks\u00e5 att isolera containrar baserat p\u00e5 CPU-anv\u00e4ndning. F\u00f6r oss var dock den standardiserade isoleringen otillr\u00e4cklig. Men mer om det nedan.<\/p>\n<p><\/p>\n<p>Att direkt k\u00f6ra containrar p\u00e5 servrar \u00e4r bara en del av problemen. En annan del handlar om att placera containrar p\u00e5 servrar. Vi m\u00e5ste f\u00f6rst\u00e5 vilken container som kan placeras p\u00e5 vilken server. Det \u00e4r ingen enkel uppgift, eftersom containrar m\u00e5ste placeras s\u00e5 t\u00e4tt som m\u00f6jligt p\u00e5 servrarna utan att s\u00e4nka hastigheten p\u00e5 deras arbete. S\u00e5dan placering kan vara komplex och ur perspektivet av fel tolerans. Ofta vill vi placera repliker av samma tj\u00e4nst i olika st\u00e4ll och till och med i olika hallar i datacentret, f\u00f6r att vi inte ska f\u00f6rlora alla repliker av tj\u00e4nsten vid ett fel. <\/p>\n<p><\/p>\n<p>Att distribuera containrar manuellt \u00e4r inget alternativ n\u00e4r du har 8000 servrar och 8000\u201316000 containrar. <\/p>\n<p><\/p>\n<p>Dessutom ville vi ge utvecklarna mer sj\u00e4lvst\u00e4ndighet i resursf\u00f6rdelningen, s\u00e5 att de kan placera sina tj\u00e4nster i produktion sj\u00e4lva, utan administrat\u00f6rens hj\u00e4lp. Samtidigt ville vi beh\u00e5lla kontrollen, s\u00e5 att ingen sekund\u00e4r tj\u00e4nst konsumerar alla resurser i v\u00e5ra datacenter. <\/p>\n<p><\/p>\n<p>Det \u00e4r uppenbart att vi beh\u00f6ver ett hanteringslager som automatiskt skulle hantera detta.<\/p>\n<p><\/p>\n<p>H\u00e4r har vi kommit till en enkel och tydlig bild som alla arkitekter \u00e4lskar: tre rutor. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/079df6e79874ef55b0d967fde3d5feca.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>one-cloud-m\u00e4stare \u2014 en redundanskluster som ansvarar f\u00f6r orkestrering av molnet. Utvecklaren skickar en manifest till m\u00e4staren, som inneh\u00e5ller all n\u00f6dv\u00e4ndig information f\u00f6r att placera tj\u00e4nsten. M\u00e4staren ger order till de valda minionerna (maskiner som \u00e4r avsedda att k\u00f6ra beh\u00e5llare) baserat p\u00e5 denna information. P\u00e5 minionerna finns v\u00e5r agent, som tar emot order, ger sina egna order till Docker, och Docker konfigurerar Linux-k\u00e4rnan f\u00f6r att k\u00f6ra den relevanta beh\u00e5llaren. F\u00f6rutom att utf\u00f6ra kommandon, rapporterar agenten kontinuerligt till m\u00e4staren om status\u00e4ndringar f\u00f6r b\u00e5de minionmaskinen och de beh\u00e5llare som k\u00f6rs p\u00e5 den.<\/p>\n<p><\/p>\n<h2 id=\"raspredelenie-resursov\">Resursf\u00f6rdelning<\/h2>\n<p><\/p>\n<p>L\u00e5t oss nu titta n\u00e4rmare p\u00e5 uppgiften med mer komplex resursf\u00f6rdelning f\u00f6r m\u00e5nga minioner.<\/p>\n<p><\/p>\n<p>Ber\u00e4kningsresurs i one-cloud \u00e4r:<\/p>\n<p><\/p>\n<ul>\n<li>Den ber\u00e4kningskraft som en specifik uppgift anv\u00e4nder. <\/li>\n<li>M\u00e4ngden minne som \u00e4r tillg\u00e4nglig f\u00f6r uppgiften. <\/li>\n<li>N\u00e4tverkstrafik. Varje minion har ett specifikt n\u00e4tverksgr\u00e4nssnitt med begr\u00e4nsad bandbredd, s\u00e5 uppgifter kan inte f\u00f6rdelas utan att ta h\u00e4nsyn till den data som \u00f6verf\u00f6rs via n\u00e4tverket. <\/li>\n<li>Diskenheter. F\u00f6rutom, uppenbarligen, utrymmet f\u00f6r uppgiftens data tilldelar vi \u00e4ven typ av disk: HDD eller SSD. Diskenheter kan hantera ett best\u00e4mt antal f\u00f6rfr\u00e5gningar per sekund \u2014 IOPS. D\u00e4rf\u00f6r, f\u00f6r uppgifter som genererar mer IOPS \u00e4n vad en disk kan hantera, tilldelar vi \u00e4ven ''spindlar'' \u2014 det vill s\u00e4ga disk-enheter som m\u00e5ste reserveras specifikt f\u00f6r uppgiften.<\/li>\n<\/ul>\n<p><\/p>\n<p>S\u00e5 f\u00f6r n\u00e5gon tj\u00e4nst, till exempel user-cache, kan vi skriva de anv\u00e4nda resurserna s\u00e5 h\u00e4r: 400 CPU-k\u00e4rnor, 2,5 TB minne, 50 Gbit\/s trafik i b\u00e5da riktningarna, 6 TB utrymme p\u00e5 HDD, placerad p\u00e5 100 spindlar. Eller i en mer bekant form enligt nedan:<\/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>Resurserna f\u00f6r tj\u00e4nsten user-cache anv\u00e4nder endast en del av alla tillg\u00e4ngliga resurser i produktionsinfrastruktur. D\u00e4rf\u00f6r vill vi se till att user-cache inte pl\u00f6tsligt f\u00f6rbrukar mer resurser \u00e4n det tilldelats, varken p\u00e5 grund av en operat\u00f6rsfel eller av annan anledning. Det vill s\u00e4ga att vi m\u00e5ste begr\u00e4nsa resurserna. Men vad skulle vi kunna knyta kvoten till?<\/p>\n<p><\/p>\n<p>L\u00e5t oss \u00e5terv\u00e4nda till v\u00e5r starkt f\u00f6renklade schematiska representation av komponenternas interaktion och rita om med fler detaljer \u2013 s\u00e5 h\u00e4r: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/27e5bfbffadd3d4b9fdc6bf138d135ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vad som sticker ut:<\/p>\n<p><\/p>\n<ul>\n<li>Webbfrontend och musik anv\u00e4nder isolerade kluster av samma applikationsserver.<\/li>\n<li>Det g\u00e5r att s\u00e4rskilja logiska lager, som omfattar dessa kluster: fronter, cacher, lagrings- och datastyrningslager.<\/li>\n<li>Frontend \u00e4r heterogen, det \u00e4r olika funktionella delsystem. <\/li>\n<li>Cacher kan ocks\u00e5 f\u00f6rdelas \u00f6ver delsystemet vars data de cachar.<\/li>\n<\/ul>\n<p><\/p>\n<p>L\u00e5t oss rita om bilden igen:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/905dacc0aca859e65bd33ef751a557cf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Oj! Vi ser en hierarki! Det betyder att vi kan f\u00f6rdela resurser i st\u00f6rre bitar: tills\u00e4tta en ansvarig utvecklare p\u00e5 noden i denna hierarki, som motsvarar det funktionella delsystemet (som 'music' i bilden), och knyta en kvot till samma niv\u00e5 i hierarkin. En s\u00e5dan hierarki g\u00f6r det ocks\u00e5 m\u00f6jligt att mer flexibelt organisera tj\u00e4nster f\u00f6r att underl\u00e4tta hanteringen. Till exempel, alla web, eftersom det \u00e4r en mycket stor gruppering av servrar, delar vi upp i flera mindre grupper, som visas p\u00e5 bilden som group1, group2.<\/p>\n<p><\/p>\n<p>Genom att ta bort \u00f6verfl\u00f6diga linjer kan vi skriva ner varje nod i v\u00e5r bild mer platt: <strong>group1.web.front<\/strong>, <strong>api.music.front<\/strong>, <strong>user-cache.cache<\/strong>.<\/p>\n<p><\/p>\n<p>S\u00e5 kommer vi till begreppet 'hierarkisk k\u00f6'. Den har ett namn, som 'group1.web.front'. Den tilldelas en kvot p\u00e5 resurser och anv\u00e4ndarr\u00e4ttigheter. En person fr\u00e5n DevOps f\u00e5r r\u00e4tt att skicka tj\u00e4nsten till k\u00f6n, och en s\u00e5dan medarbetare kan k\u00f6ra n\u00e5got i k\u00f6n, medan en person fr\u00e5n OpsDev f\u00e5r administrat\u00f6rsr\u00e4ttigheter, och nu kan han hantera k\u00f6n, tilldela personer dit, ge dessa personer r\u00e4ttigheter och s\u00e5 vidare. Tj\u00e4nster som k\u00f6rs i denna k\u00f6 kommer att utf\u00f6ras inom k\u00f6kvoten. Om den ber\u00e4knade kvoten f\u00f6r k\u00f6 \u00e4r otillr\u00e4cklig f\u00f6r att k\u00f6ra alla tj\u00e4nster samtidigt, kommer de att k\u00f6ras sekventiellt, och skapar d\u00e4rmed sj\u00e4lva k\u00f6n. <\/p>\n<p><\/p>\n<p>L\u00e5t oss titta n\u00e4rmare p\u00e5 tj\u00e4nsterna. En tj\u00e4nst har ett helt namn, vilket alltid inkluderar namnet p\u00e5 k\u00f6n. D\u00e5 kommer tj\u00e4nsten webbfronten att ha namnet <strong>ok-web.group1.web.front<\/strong>. Och tj\u00e4nsten f\u00f6r applikationsservern som den kontaktar kommer att kallas <strong>ok-app.group1.web.front<\/strong>Varje tj\u00e4nst har en manifestfil som inneh\u00e5ller all n\u00f6dv\u00e4ndig information f\u00f6r distribution p\u00e5 specifika maskiner: hur mycket resurser den h\u00e4r uppgiften f\u00f6rbrukar, vilken konfiguration som kr\u00e4vs, hur m\u00e5nga repliker som b\u00f6r finnas, egenskaper f\u00f6r felhantering av denna tj\u00e4nst. Efter distributionen av tj\u00e4nsten p\u00e5 maskinerna skapas dess instanser. De namnges ocks\u00e5 entydigt \u2014 med instansnumret och tj\u00e4nstens namn: <strong>1.ok-web.group1.web.front, 2.ok-web.group1.web.front, \u2026<\/strong><\/p>\n<p><\/p>\n<p>Detta \u00e4r mycket praktiskt: genom att bara titta p\u00e5 namnet p\u00e5 den k\u00f6rda containern kan vi genast ta reda p\u00e5 mycket.<\/p>\n<p><\/p>\n<p>L\u00e5t oss nu l\u00e4ra k\u00e4nna vad dessa instanser faktiskt utf\u00f6r: uppgifterna.<\/p>\n<p><\/p>\n<h2 id=\"klassy-izolyacii-zadach\">Klassificering av uppgifter<\/h2>\n<p><\/p>\n<p>Alla uppgifter i OK (och s\u00e4kerligen p\u00e5 andra st\u00e4llen) kan delas in i grupper:<\/p>\n<p><\/p>\n<ul>\n<li><strong>Uppgifter med kort svarstid \u2014 prod<\/strong>. F\u00f6r s\u00e5dana uppgifter och tj\u00e4nster \u00e4r svarstid (latens) mycket viktig; hur snabbt varje beg\u00e4ran hanteras av systemet. Exempel p\u00e5 uppgifter: webfrontend, cache, applikationsservrar, OLTP-lagring m.m.<\/li>\n<li><strong>Ber\u00e4kningsuppgifter \u2014 batch<\/strong>. H\u00e4r \u00e4r hastigheten f\u00f6r bearbetning av varje specifik beg\u00e4ran inte s\u00e5 viktig. Det som betyder mest \u00e4r hur m\u00e5nga ber\u00e4kningar den h\u00e4r uppgiften g\u00f6r under en viss (l\u00e5ng) tidsperiod (genomstr\u00f6mning). Detta omfattar alla MapReduce-uppgifter, Hadoop, maskininl\u00e4rning, statistik.<\/li>\n<li><strong>Bakgrundsuppgifter \u2014 idle<\/strong>. F\u00f6r dessa uppgifter \u00e4r varken latens eller genomstr\u00f6mning s\u00e4rskilt viktig. H\u00e4r ing\u00e5r olika tester, migrationer, omber\u00e4kningar, konverteringar av data fr\u00e5n ett format till ett annat. \u00c5 ena sidan liknar de ber\u00e4kningsuppgifter, \u00e5 andra sidan \u00e4r det inte s\u00e5 viktigt hur snabbt de avslutas. <\/li>\n<\/ul>\n<p><\/p>\n<p>L\u00e5t oss titta p\u00e5 hur s\u00e5dana uppgifter f\u00f6rbrukar resurser, till exempel centrala processorn.<\/p>\n<p><\/p>\n<p><strong>Uppgifter med kort svarstid.<\/strong> M\u00f6nstret f\u00f6r CPU-f\u00f6rbrukning f\u00f6r en s\u00e5dan uppgift ser ut som f\u00f6ljande:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/1ed82c0df76325eb30056ad9af86e86e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>En beg\u00e4ran kommer in fr\u00e5n anv\u00e4ndaren, uppgiften b\u00f6rjar anv\u00e4nda alla tillg\u00e4ngliga CPU-k\u00e4rnor, bearbetar, returnerar svaret, v\u00e4ntar p\u00e5 n\u00e4sta beg\u00e4ran och st\u00e5r stilla. N\u00e4r n\u00e4sta beg\u00e4ran kommer in tar vi \u00e5terigen allt som finns, ber\u00e4knar, och v\u00e4ntar p\u00e5 n\u00e4sta.<\/p>\n<p><\/p>\n<p>F\u00f6r att garantera minimi latens f\u00f6r en s\u00e5dan uppgift m\u00e5ste vi ta maximalt f\u00f6rbrukade resurser och reservera r\u00e4tt antal k\u00e4rnor p\u00e5 minionen (maskinen som kommer att utf\u00f6ra uppgiften). D\u00e5 kommer formeln f\u00f6r reservationen f\u00f6r v\u00e5r uppgift att bli:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = 4 (max)<\/code><\/pre>\n<p><\/p>\n<p>Och om vi har en minionmaskin med 16 k\u00e4rnor kan vi exakt k\u00f6ra fyra s\u00e5dana uppgifter p\u00e5 den. Det \u00e4r v\u00e4rt att notera att medelprocessorf\u00f6rbrukningen f\u00f6r s\u00e5dana uppgifter ofta \u00e4r mycket l\u00e5g \u2014 vilket \u00e4r uppenbart eftersom en stor del av tiden uppgiften v\u00e4ntar p\u00e5 f\u00f6rfr\u00e5gan och inte g\u00f6r n\u00e5got.<\/p>\n<p><\/p>\n<p><strong>Ber\u00e4kningsuppgifter.<\/strong> De kommer att ha ett n\u00e5got annat m\u00f6nster:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/35b37fa1d70a137287cafdbfe3bcfc2e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Medelresursf\u00f6rbrukningen f\u00f6r processorn f\u00f6r s\u00e5dana uppgifter \u00e4r ganska h\u00f6g. Ofta vill vi att ber\u00e4kningsuppgiften ska slutf\u00f6ras inom en viss tid, s\u00e5 vi m\u00e5ste reservera det minimiantal processorer som kr\u00e4vs f\u00f6r att hela ber\u00e4kningen ska slutf\u00f6ras p\u00e5 en acceptabel tid. Formeln f\u00f6r reservering kommer att se ut s\u00e5 h\u00e4r:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = [1,* )<\/code><\/pre>\n<p><\/p>\n<p><em>\"Sn\u00e4lla placera detta p\u00e5 minionen d\u00e4r det finns \u00e5tminstone en ledig k\u00e4rna, och sedan f\u00e5r den anv\u00e4nda allt som finns.\"<\/em><\/p>\n<p><\/p>\n<p>H\u00e4r \u00e4r effektiviteten redan betydligt b\u00e4ttre \u00e4n med uppgifter med kort f\u00f6rsening. Men vinsten blir mycket st\u00f6rre om man kombinerar b\u00e5da typer av uppgifter p\u00e5 samma minionmaskin och distribuerar dess resurser dynamiskt. N\u00e4r en uppgift med kort f\u00f6rsening beh\u00f6ver processorn \u2014 f\u00e5r den den omedelbart, och n\u00e4r resurserna inte l\u00e4ngre beh\u00f6vs \u2014 \u00f6verf\u00f6rs de till ber\u00e4kningsuppgiften, det vill s\u00e4ga ungef\u00e4r s\u00e5 h\u00e4r:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/875ad8d3f6a01e4fd0a89d0931e986c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Men hur g\u00f6r man detta?<\/p>\n<p><\/p>\n<p>F\u00f6rst, l\u00e5t oss f\u00f6rst\u00e5 prod och dess alloc: cpu = 4. Vi beh\u00f6ver reservera fyra k\u00e4rnor. I Docker run kan detta g\u00f6ras p\u00e5 tv\u00e5 s\u00e4tt: <\/p>\n<p><\/p>\n<ul>\n<li>Genom alternativet <code>--cpuset=1-4<\/code>, det vill s\u00e4ga att tilldela uppgiften fyra best\u00e4mda k\u00e4rnor p\u00e5 maskinen.<\/li>\n<li>Anv\u00e4nd <code>--cpuquota=400_000 --cpuperiod=100_000<\/code>, tilldela en kvot f\u00f6r processor-tid, det vill s\u00e4ga att ange att varje 100 ms verklig tid f\u00e5r uppgiften inte konsumera mer \u00e4n 400 ms processor-tid. Det blir samma fyra k\u00e4rnor. <\/li>\n<\/ul>\n<p><\/p>\n<p>Men vilket av dessa s\u00e4tt \u00e4r r\u00e4tt?<\/p>\n<p><\/p>\n<p>Cpuset ser ganska lockande ut. Om uppgiften har fyra dedikerade k\u00e4rnor, betyder det att processorcacheminnet kommer att fungera maximalt effektivt. Detta har dock en bakside: vi skulle ta p\u00e5 oss uppgiften att f\u00f6rdela ber\u00e4kningarna \u00f6ver de avlastade k\u00e4rnorna ist\u00e4llet f\u00f6r operativsystemet, vilket \u00e4r en ganska icke-trivial uppgift, s\u00e4rskilt om vi f\u00f6rs\u00f6ker placera batchuppgifter p\u00e5 en s\u00e5dan maskin. Tester har visat att en kvotvariant passar b\u00e4ttre h\u00e4r: d\u00e5 har operativsystemet mer frihet att v\u00e4lja k\u00e4rna f\u00f6r att utf\u00f6ra uppgiften f\u00f6r stunden och processortiden f\u00f6rdelas mer effektivt.<\/p>\n<p><\/p>\n<p>L\u00e5t oss ta reda p\u00e5 hur man g\u00f6r reservreservation i Docker f\u00f6r det minimiantal k\u00e4rnor. En kvot f\u00f6r batchuppgifter \u00e4r redan otill\u00e4mplig, eftersom det inte \u00e4r n\u00f6dv\u00e4ndigt att begr\u00e4nsa ett maximum, det r\u00e4cker med att garantera ett minimum. H\u00e4r passar alternativet bra: <code>docker run --cpushares<\/code>.<\/p>\n<p><\/p>\n<p>Vi har kommit \u00f6verens om att om en batch kr\u00e4ver garantin f\u00f6r minst ett k\u00e4rn, anger vi <code>--cpushares=1024<\/code>, och om det beh\u00f6vs minst tv\u00e5 k\u00e4rnor, anger vi <code>--cpushares=2048<\/code>. Cpu shares p\u00e5verkar inte f\u00f6rdelningen av processortid s\u00e5 l\u00e4nge det finns tillr\u00e4ckligt. S\u00e5ledes, om prod f\u00f6r n\u00e4rvarande inte anv\u00e4nder alla sina fyra k\u00e4rnor \u2014 begr\u00e4nsar inget batchuppgifterna, och de kan anv\u00e4nda extra processortid. Men i en situation med brist p\u00e5 CPU, om prod har anv\u00e4nt alla sina fyra k\u00e4rnor och n\u00e5tt sin kvot \u2014 kommer den \u00e5terst\u00e5ende processortiden att delas proportionellt mellan cpushares, det vill s\u00e4ga i en situation med tre lediga k\u00e4rnor f\u00e5r uppgiften med 1024 cpushares en k\u00e4rna, medan de andra tv\u00e5 f\u00e5r uppgiften med 2048 cpushares.<\/p>\n<p><\/p>\n<p>Men anv\u00e4ndning av kvota och shares \u00e4r inte tillr\u00e4ckligt. Vi m\u00e5ste se till att en uppgift med kort f\u00f6rdr\u00f6jning f\u00e5r prioritet \u00f6ver batchuppgiften vid f\u00f6rdelningen av processortid. Utan s\u00e5dan prioritering kommer batchuppgiften att ta all processortid i det \u00f6gonblick n\u00e4r det beh\u00f6vs av prod. I Docker run finns det inga alternativ f\u00f6r prioritering av containrar, men CPU-schemal\u00e4ggarpolicyer i Linux kommer till hj\u00e4lp. Du kan l\u00e4sa mer om dem <noindex><a rel=\"nofollow\" href=\"http:\/\/man7.org\/linux\/man-pages\/man2\/sched_setscheduler.2.html\">). Ett typiskt exempel p\u00e5 anv\u00e4ndning:<\/a><\/noindex>, men inom ramen f\u00f6r denna artikel ska vi kort g\u00e5 igenom dem:<\/p>\n<p><\/p>\n<ul>\n<li><strong>SCHED_OTHER<\/strong><br \/>\nF\u00e5r som standard alla vanliga anv\u00e4ndarprocesser p\u00e5 en Linux-maskin.<\/li>\n<li><strong>SCHED_BATCH<\/strong><br \/>\nAvsedd f\u00f6r resurskr\u00e4vande processer. N\u00e4r en uppgift placeras i processorn inf\u00f6rs s\u00e5 kallad aktiveringsstraff: en s\u00e5dan uppgift har st\u00f6rre sannolikhet att mindre f\u00e5 processorns resurser om den f\u00f6r n\u00e4rvarande anv\u00e4nds av en uppgift med SCHED_OTHER.<\/li>\n<li><strong>SCHED_IDLE<\/strong><br \/>\nEn bakgrundsprocess med mycket l\u00e5g prioritet, till och med l\u00e4gre \u00e4n nice \u201319. Vi anv\u00e4nder v\u00e5rt \u00f6ppna k\u00e4llkods-bibliotek. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/odnoklassniki\/one-nio\">one-nio<\/a><\/noindex>, f\u00f6r att s\u00e4tta n\u00f6dv\u00e4ndig policy vid start av containern genom att kalla p\u00e5<\/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>Men \u00e4ven om du inte programmerar i Java kan samma sak g\u00f6ras med kommandot chrt:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">chrt -i 0 $pid<\/code><\/pre>\n<p><\/p>\n<p>L\u00e5t oss sammanfatta alla v\u00e5ra isoleringsniv\u00e5er i en tabell f\u00f6r tydlighet:<\/p>\n<p><\/p>\n<p>Isoleringsklass<br \/>\nExempel alloc<br \/>\nDocker run-alternativ<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>*Om du k\u00f6r chrt inuti containern kan du beh\u00f6va capability sys_nice, eftersom Docker som standard tar bort denna capability vid start av containern.<\/p>\n<p><\/p>\n<p>Men uppgifter konsumerar inte bara processor, utan ocks\u00e5 trafik, vilket p\u00e5verkar f\u00f6rdr\u00f6jningen av n\u00e4tverksuppgiften \u00e4nnu mer \u00e4n felaktig f\u00f6rdelning av processorresurser. D\u00e4rf\u00f6r vill vi naturligtvis f\u00e5 exakt samma bild f\u00f6r trafiken. Det vill s\u00e4ga, n\u00e4r prod-uppgiften skickar paket till n\u00e4tverket, kvoterar vi den maximala hastigheten (formel <em>alloc: lan=[*,500mbps)<\/em> ), som prod kan g\u00f6ra detta. F\u00f6r batch garanterar vi endast en minimal \u00f6verf\u00f6ringskapacitet, men begr\u00e4nsar inte den maximala (formel <em>alloc: lan=[10Mbps,*)<\/em> ) I detta fall ska trafiken fr\u00e5n prod prioriteras \u00f6ver batch-uppgifter.<br \/>\nH\u00e4r har Docker inga primitiva verktyg som vi kan anv\u00e4nda. Men vi f\u00e5r hj\u00e4lp av <noindex><a rel=\"nofollow\" href=\"http:\/\/lartc.org\/\">Linux Traffic Control<\/a><\/noindex>. Vi lyckades uppn\u00e5 \u00f6nskat resultat med hj\u00e4lp av disciplinen <noindex><a rel=\"nofollow\" href=\"http:\/\/linux-ip.net\/articles\/hfsc.en\/\">Hierarchical Fair Service Curve<\/a><\/noindex>. Med den delar vi upp trafiken i tv\u00e5 klasser: h\u00f6gprioriterad prod och l\u00e5gt prioriterad batch\/idle. Sammanfattningsvis blir konfigurationen f\u00f6r utg\u00e5ende trafik s\u00e5 h\u00e4r:<\/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 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/3f52a968118b6021bd0c920af17a00c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>h\u00e4r 1:0 \u2014 \u00abroot qdisc\u00bb f\u00f6r disciplinen hsfc; 1:1 \u2014 barnklass hsfc med en gemensam bandbreddsgr\u00e4ns p\u00e5 8 Gbit\/s, under vilken alla barnklasser f\u00f6r alla containrar placeras; 1:2 \u2014 barnklass hsfc gemensam f\u00f6r alla batch- och idle-uppgifter med en \u00abdynamisk\u00bb gr\u00e4ns, som beskrivs nedan. De \u00f6vriga barnklasserna hsfc \u00e4r dedikerade klasser f\u00f6r aktuella prod-containrar med gr\u00e4nser som motsvarar deras manifester, \u2014 450 och 400 Mbit\/s. Varje hsfc-klass tilldelas qdisc-k\u00f6 fq eller fq_codel, beroende p\u00e5 versionen av linux-k\u00e4rnan, f\u00f6r att undvika paketf\u00f6rluster vid trafikspikar. <\/p>\n<p><\/p>\n<p>Vanligtvis anv\u00e4nds tc-discipliner f\u00f6r att prioritera endast utg\u00e5ende trafik. Men vi vill \u00e4ven prioritera inkommande trafik \u2014 eftersom en batch-uppgift helt kan ta \u00f6ver hela den inkommande kanalen genom att f\u00e5, till exempel, ett stort paket inkommande data f\u00f6r map&amp;reduce. F\u00f6r detta anv\u00e4nder vi modulen <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/350023\/tc-ingress-policing-and-ifb-mirroring\">ifb<\/a><\/noindex>, som skapar en virtuell ifbX-gr\u00e4nssnitt f\u00f6r varje n\u00e4tverksgr\u00e4nssnitt och omdirigerar inkommande trafik fr\u00e5n gr\u00e4nssnittet till utg\u00e5ende p\u00e5 ifbX. D\u00e4refter fungerar alla de samma disciplinerna f\u00f6r kontroll av utg\u00e5ende trafik f\u00f6r ifbX, f\u00f6r vilken hsfc-konfigurationen kommer att vara mycket lik:<\/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 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/967da9c0637cc70ba195af781db18adf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Under experimenten har vi fastst\u00e4llt att hsfc ger de b\u00e4sta resultaten n\u00e4r klass 1:2 f\u00f6r icke-prioriterad batch\/idle-trafik begr\u00e4nsas p\u00e5 minion-maskiner till h\u00f6gst en viss fri bandbredd. Annars p\u00e5verkar icke-prioriterad trafik latensen f\u00f6r prod-uppgifter f\u00f6r mycket. Den aktuella fri bandbredden best\u00e4ms av miniond varje sekund genom att m\u00e4ta den genomsnittliga trafikf\u00f6rbrukningen f\u00f6r alla prod-uppgifter p\u00e5 den aktuella minionen <img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/9d6f38110d3b1693afe222b01430b9bb.jpg\" style=\"display:block;margin: 0 auto;\" \/> och subtrahera den fr\u00e5n bandbredden f\u00f6r n\u00e4tverksgr\u00e4nssnittet <img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/d5608ec4c58e44b8571ab0b1d0cc7701.jpg\" style=\"display:block;margin: 0 auto;\" \/> med en liten marginal, det vill s\u00e4ga.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/fb01347c2224bd5bbd82169861eeb7e4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Bandbredden best\u00e4ms f\u00f6r inkommande och utg\u00e5ende trafik oberoende. I enlighet med de nya v\u00e4rdena \u00e5terkonfigurerar miniond gr\u00e4nsen f\u00f6r den icke-prioriterade klassen 1:2.<\/p>\n<p><\/p>\n<p>S\u00e5ledes har vi implementerat alla tre isoleringsklasser: prod, batch och idle. Dessa klasser p\u00e5verkar kraftigt prestanda f\u00f6r uppgifterna. D\u00e4rf\u00f6r har vi beslutat att placera denna egenskap h\u00f6gst upp i hierarkin, s\u00e5 att n\u00e4r man tittar p\u00e5 namnet p\u00e5 den hierarkiska k\u00f6n kan man direkt se vad vi har att g\u00f6ra med: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/34dc89c461db711b19a0f4eccc50efce.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Alla v\u00e5ra bekanta <strong>web<\/strong> och <strong>music<\/strong> fronter placeras d\u00e5 i hierarkin under prod. F\u00f6r exempel under batch l\u00e5t oss placera tj\u00e4nsten <strong>music catalog<\/strong>, som periodiskt skapar en katalog \u00f6ver l\u00e5tar fr\u00e5n upps\u00e4ttningen av mp3-filer som laddats upp till \"Odnoklassniki\". Ett exempel p\u00e5 en tj\u00e4nst under idle kan vara <strong>music transformer<\/strong>, som normaliserar ljudniv\u00e5n p\u00e5 musiken.<\/p>\n<p><\/p>\n<p>Genom att \u00e5terigen ta bort \u00f6verfl\u00f6diga linjer kan vi skriva namnen p\u00e5 v\u00e5ra tj\u00e4nster mer platt, genom att l\u00e4gga till klass f\u00f6r uppgiftsisolering i slutet av tj\u00e4nstens fullst\u00e4ndiga namn: <strong>web.front.prod<\/strong>, <strong>catalog.music.batch<\/strong>, <strong>transformer.music.idle<\/strong>.<\/p>\n<p><\/p>\n<p>Och nu, n\u00e4r vi ser p\u00e5 tj\u00e4nstens namn, f\u00f6rst\u00e5r vi inte bara vilken funktion den utf\u00f6r, utan ocks\u00e5 dess klass f\u00f6r isolering, vilket betyder dess kritikalitet etc.<\/p>\n<p><\/p>\n<p>Allt \u00e4r fantastiskt, men det finns en bitter sanning. Det \u00e4r om\u00f6jligt att helt isolera uppgifter som k\u00f6rs p\u00e5 samma maskin.<\/p>\n<p><\/p>\n<p>Vad vi har lyckats \u00e5stadkomma: om batch intensivt f\u00f6rbrukar <strong>bara<\/strong> CPU-resurser, s\u00e5 fungerar Linux inbyggda CPU-scheduler mycket bra, och p\u00e5verkan p\u00e5 prod-uppgiften \u00e4r n\u00e4stan obefintlig. Men om denna batch-uppgift b\u00f6rjar arbeta aktivt med minnet, s\u00e5 visar \u00f6msesidig p\u00e5verkan sig. Detta h\u00e4nder eftersom prod-uppgiften \"tappar\" processorcacheminnet \u2014 med resultatet att tr\u00e4ffarna i cachen \u00f6kar, och processorn bearbetar prod-uppgiften l\u00e5ngsammare. En s\u00e5dan batch-uppgift kan \u00f6ka latensen f\u00f6r v\u00e5r typiska prod-container med 10%.<\/p>\n<p><\/p>\n<p>Att isolera trafiken \u00e4r \u00e4nnu sv\u00e5rare eftersom moderna n\u00e4tverkskort har en intern k\u00f6 f\u00f6r paket. Om ett paket fr\u00e5n batch-uppgiften kommer in f\u00f6rst, s\u00e5 skickas det f\u00f6rst \u00f6ver kabeln, och det kan vi inte \u00e4ndra p\u00e5.<\/p>\n<p><\/p>\n<p>Dessutom har vi hittills bara lyckats l\u00f6sa problemet med prioritering av TCP-trafik: f\u00f6r UDP fungerar inte strategin med hsfc. \u00c4ven n\u00e4r det kommer till TCP-trafik, om batch-uppgiften genererar mycket trafik, ger det ocks\u00e5 omkring 10% \u00f6kning av latensen f\u00f6r prod-uppgiften.<\/p>\n<p><\/p>\n<h2 id=\"otkazoustoychivost\">Fel-tolerans<\/h2>\n<p><\/p>\n<p>Ett av m\u00e5len n\u00e4r vi utvecklade one-cloud var att f\u00f6rb\u00e4ttra motst\u00e5ndskraften hos Odnoklassniki. D\u00e4rf\u00f6r skulle jag nu vilja titta n\u00e4rmare p\u00e5 m\u00f6jliga fel- och n\u00f6dsituationer. L\u00e5t oss b\u00f6rja med ett enkelt scenario \u2014 med ett containerfel. <\/p>\n<p><\/p>\n<p>En container kan misslyckas p\u00e5 flera s\u00e4tt. Det kan vara ett experiment, en bugg eller ett fel i manifestet, vilket g\u00f6r att en produktuppgift b\u00f6rjar konsumera fler resurser \u00e4n vad som anges i manifestet. Vi hade ett fall d\u00e4r en utvecklare implementerade en komplicerad algoritm, omarbetade den flera g\u00e5nger och f\u00f6rvirrade sig s\u00e5 mycket att uppgiften slutligen blev ganska komplex och fastnade i en loop. Eftersom produktuppgiften har h\u00f6gre prioritet \u00e4n alla andra p\u00e5 samma noder, b\u00f6rjade den att konsumera alla tillg\u00e4ngliga processorresurser. I denna situation r\u00e4ddade isolering, specifikt en kvot p\u00e5 processoranv\u00e4ndningen. Om uppgiften har en kvot, kommer den inte att konsumera mer. D\u00e4rf\u00f6r m\u00e4rkte batch- och andra produktuppgifter som k\u00f6rdes p\u00e5 samma maskin ingenting. <\/p>\n<p><\/p>\n<p>Den andra m\u00f6jliga problemet \u00e4r att containern kraschar. H\u00e4r r\u00e4ddas vi av restart-policyer, som alla k\u00e4nner till, Docker hanterar detta utm\u00e4rkt. N\u00e4stan alla produktuppgifter har en restart-policy \"always\". Ibland anv\u00e4nder vi \"on_failure\" f\u00f6r batchuppgifter eller f\u00f6r att fels\u00f6ka produktcontainrar.<\/p>\n<p><\/p>\n<p>Vad kan man g\u00f6ra n\u00e4r en hel nod \u00e4r otillg\u00e4nglig?<\/p>\n<p><\/p>\n<p>Sj\u00e4lvklart kan vi starta containern p\u00e5 en annan maskin. Det mest intressanta h\u00e4r \u00e4r vad som h\u00e4nder med IP-adressen (adresserna) som tilldelas containern. <\/p>\n<p><\/p>\n<p>Vi kan tilldela containrar samma IP-adresser som noderna d\u00e4r dessa containrar k\u00f6rs. N\u00e4r containern startas p\u00e5 en annan maskin, \u00e4ndras dess IP-adress, och alla klienter m\u00e5ste f\u00f6rst\u00e5 att containern har flyttat, och nu m\u00e5ste de anv\u00e4nda en annan adress, vilket kr\u00e4ver en separat Service Discovery-tj\u00e4nst. <\/p>\n<p><\/p>\n<p>Service Discovery \u00e4r praktiskt. Det finns m\u00e5nga l\u00f6sningar p\u00e5 marknaden med olika grad av felresistens f\u00f6r att etablera en tj\u00e4nsteregister. I m\u00e5nga s\u00e5dana l\u00f6sningar implementeras logik f\u00f6r lastbalansering, lagring av ytterligare konfiguration i form av en nyckel-v\u00e4rde-lager, etc.<br \/>\nVi vill dock g\u00e4rna undvika behovet av att inf\u00f6ra ett separat register, eftersom det skulle inneb\u00e4ra inf\u00f6randet av ett kritiskt system som anv\u00e4nds av alla tj\u00e4nster i produktion. Det inneb\u00e4r att det \u00e4r en potentiell felpunkt, och man m\u00e5ste v\u00e4lja eller utveckla en mycket felresistent l\u00f6sning, vilket uppenbarligen \u00e4r mycket komplicerat, tidskr\u00e4vande och kostsamt. <\/p>\n<p><\/p>\n<p>En stor nackdel \u00e4r att f\u00f6r att v\u00e5r gamla infrastruktur ska kunna fungera med den nya m\u00e5ste vi omprogrammera alla uppgifter f\u00f6r att anv\u00e4nda ett Service Discovery-system. Det finns EXTREMT mycket arbete, och ibland \u00e4r det praktiskt taget om\u00f6jligt, s\u00e4rskilt n\u00e4r det g\u00e4ller l\u00e5gniv\u00e5-enheter som arbetar p\u00e5 OS-k\u00e4rnniv\u00e5 eller direkt med h\u00e5rdvara. Att implementera denna funktionalitet med hj\u00e4lp av etablerade l\u00f6sningsm\u00f6nster, som till exempel <noindex><a rel=\"nofollow\" href=\"https:\/\/linkerd.io\">side-car<\/a><\/noindex> , skulle inneb\u00e4ra extra belastning p\u00e5 vissa st\u00e4llen, och i andra fall skulle det komplicera drift och skapa ytterligare felhanteringsscenarier. Vi ville inte komplicera saker, s\u00e5 vi beslutade att g\u00f6ra anv\u00e4ndningen av Service Discovery valfri. <\/p>\n<p><\/p>\n<p>I one-cloud f\u00f6ljer IP-adressen efter containern, det vill s\u00e4ga varje instans av uppgiften har sin egen IP-adress. Denna adress \u00e4r \"statisk\": den knyts till varje instans vid f\u00f6rsta g\u00e5ngen tj\u00e4nsten skickas till molnet. Om tj\u00e4nsten under sin livstid har haft ett varierande antal instanser, kommer s\u00e5 m\u00e5nga IP-adresser att knytas till den som det maximala antalet instanser var.<\/p>\n<p><\/p>\n<p>Dessa adresser \u00e4ndras inte senare: de tilldelas en g\u00e5ng och kvarst\u00e5r under hela tj\u00e4nstens livstid i produktionen. IP-adresserna f\u00f6ljer efter containrarna i n\u00e4tverket. Om containern flyttas till en annan nod, f\u00f6ljer ocks\u00e5 adressen med. <\/p>\n<p><\/p>\n<p>S\u00e5ledes f\u00f6r\u00e4ndras sambandet mellan tj\u00e4nstens namn och listan \u00f6ver dess IP-adresser mycket s\u00e4llan. Om vi ser p\u00e5 namnen p\u00e5 tj\u00e4nsteinstanserna som vi n\u00e4mnde i b\u00f6rjan av artikeln (<strong>1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, \u2026<\/strong>), kommer vi att m\u00e4rka att de liknar FQDN som anv\u00e4nds i DNS. Det st\u00e4mmer, f\u00f6r att visa namnen p\u00e5 tj\u00e4nsternas instanser i deras IP-adresser anv\u00e4nder vi DNS-protokollet. Detta DNS returnerar \u00e4ven alla reserverade IP-adresser f\u00f6r alla containrar \u2014 b\u00e5de aktiva och inaktiva (antag att tre repliker anv\u00e4nds, men fem adresser \u00e4r reserverade \u2014 alla fem kommer att returneras). Kunderna, efter att ha f\u00e5tt denna information, kommer att f\u00f6rs\u00f6ka etablera en anslutning till alla fem repliker \u2014 och p\u00e5 s\u00e5 s\u00e4tt identifiera vilka som fungerar. Denna metod f\u00f6r tillg\u00e4nglighetsbest\u00e4mning \u00e4r betydligt mer tillf\u00f6rlitlig, eftersom varken DNS eller Service Discovery \u00e4r involverade, vilket eliminerar sv\u00e5ra problem med att s\u00e4kerst\u00e4lla informationens aktualitet och systemens redundans. Dessutom kan vi i kritiska tj\u00e4nster, som \u00e4r avg\u00f6rande f\u00f6r hela portalens funktion, helt undvika att anv\u00e4nda DNS och ist\u00e4llet direkt ange IP-adresser i konfigurationen.<\/p>\n<p><\/p>\n<p>Implementeringen av en s\u00e5dan \u00f6verf\u00f6ring av IP bakom containrarna kan vara en utmaning \u2014 och vi kommer att stanna vid hur detta fungerar i f\u00f6ljande exempel:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/faf99c2609a57daa1bdc193cb0f4cb31.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Anta att one-cloud-m\u00e4staren ger order till minion M1 att starta <strong>1.ok-web.group1.web.front.prod<\/strong> med adressen 1.1.1.1. Minionen k\u00f6r <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Bird_Internet_routing_daemon\">BIRD<\/a><\/noindex>, som annonserar denna adress till specifika servrar <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Route_reflector\">route reflector<\/a><\/noindex>. De har en BGP-session med n\u00e4tverksutrustningen, som slussar vidare routen f\u00f6r adressen 1.1.1.1 till M1. M1 vidarebefordrar paketen inuti containern med hj\u00e4lp av Linux. Det finns tre route reflectors, eftersom detta \u00e4r en mycket kritisk del av one-cloud-infrastrukturen \u2014 utan dem kommer n\u00e4tverket i one-cloud att sluta fungera. Vi placerar dem i olika rack, helst i olika datahallar, f\u00f6r att minska risken f\u00f6r att alla tre skulle sluta fungera samtidigt.<\/p>\n<p><\/p>\n<p>L\u00e5t oss nu anta att kommunikationen mellan one-cloud-m\u00e4staren och minion M1 har brutits. One-cloud-m\u00e4staren kommer nu att agera under antagandet att M1 har g\u00e5tt helt ner. Det vill s\u00e4ga, den kommer att ge order till minion M2 att starta <strong>web.group1.web.front.prod<\/strong> med samma IP-adress 1.1.1.1. Nu har vi tv\u00e5 konfliktfulla rutter i n\u00e4tverket f\u00f6r 1.1.1.1: p\u00e5 M1 och M2. F\u00f6r att l\u00f6sa s\u00e5dana konflikter anv\u00e4nder vi Multi Exit Discriminator, som anges i BGP-annonsen. Detta \u00e4r ett nummer som visar vikten p\u00e5 den annonserade rutten. Rutten med l\u00e4gre MED-v\u00e4rde kommer att v\u00e4ljas av de konfliktfulla. Masten one-cloud st\u00f6der MED som en integrerad del av container-IP-adresser. F\u00f6rsta g\u00e5ngen skrivs adressen ut med ett tillr\u00e4ckligt stort MED = 1 000 000. I en situation med en n\u00f6dflyttning av containern minskar masten MED, och M2 f\u00e5r en order att annonsera IP-adressen 1.1.1.1 med MED = 999 999. Instansen som k\u00f6rs p\u00e5 M1 kommer att f\u00f6rbli utan kontakt, och dess \u00f6de intresserar oss inte mycket f\u00f6rr\u00e4n kontakten med masten \u00e5terst\u00e4lls, d\u00e5 den kommer att stoppas som en gammal dubblett.<\/p>\n<p><\/p>\n<h2 id=\"avarii\">Avbrott<\/h2>\n<p><\/p>\n<p>Alla datacenterhanteringssystem hanterar alltid mindre fel p\u00e5 ett acceptabelt s\u00e4tt. Avbrott av en container \u00e4r n\u00e4stan normen \u00f6verallt.<\/p>\n<p><\/p>\n<p>L\u00e5t oss titta p\u00e5 hur vi hanterar ett avbrott, till exempel str\u00f6mavbrott i en eller flera hallar i datacentret.<\/p>\n<p><\/p>\n<p>Vad betyder ett avbrott f\u00f6r datacenterhanteringssystemet? F\u00f6rst och fr\u00e4mst betyder det en massiv samtidigt fel av m\u00e5nga maskiner, och systemet m\u00e5ste migrera ett stort antal containrar samtidigt. Men om avbrottet \u00e4r mycket omfattande kan det h\u00e4nda att alla uppgifter inte kan omplaceras till andra noder, eftersom resurskapaciteten i datacentret faller under 100 % belastning. <\/p>\n<p><\/p>\n<p>Ofta \u00e5tf\u00f6ljs avbrott av f\u00f6rlust av kontrollskiktet. Detta kan ske p\u00e5 grund av att dess utrustning g\u00e5r s\u00f6nder, men oftare beror det p\u00e5 att avbrotten inte testas, och kontrollskiktet sj\u00e4lv kraschar p\u00e5 grund av \u00f6kad belastning. <\/p>\n<p><\/p>\n<p>Vad kan g\u00f6ras med allt detta?<\/p>\n<p><\/p>\n<p>Massa\u00f6verf\u00f6ringar inneb\u00e4r att det uppst\u00e5r ett stort antal \u00e5tg\u00e4rder, \u00f6verf\u00f6ringar och placeringar i infrastrukturen. Varje \u00f6verf\u00f6ring kan ta tid som kr\u00e4vs f\u00f6r att \u00f6verf\u00f6ra och packa upp containerbilder till noder, starta och initiera containrar etc. D\u00e4rf\u00f6r \u00e4r det \u00f6nskv\u00e4rt att mer viktiga uppgifter startas f\u00f6re mindre viktiga.<\/p>\n<p><\/p>\n<p>L\u00e5t oss \u00e5terigen titta p\u00e5 den bekanta hierarkin av tj\u00e4nster och f\u00f6rs\u00f6ka avg\u00f6ra vilka uppgifter vi vill k\u00f6ra f\u00f6rst.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/2e827271adb8d3ff3d385e53553aaacf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Sj\u00e4lvklart, det \u00e4r de processer som direkt deltar i behandlingen av anv\u00e4ndarf\u00f6rfr\u00e5gningar, dvs. prod. Vi anger detta med <strong>placeringsprioritet<\/strong> \u2014 ett nummer som kan tilldelas en k\u00f6. Om en k\u00f6 har en h\u00f6gre prioritet placeras dess tj\u00e4nster f\u00f6rst.<\/p>\n<p><\/p>\n<p>P\u00e5 prod tilldelar vi h\u00f6gre prioriteringar, 0; p\u00e5 batch \u2014 n\u00e5got l\u00e4gre, 100; p\u00e5 idle \u2014 \u00e4nnu l\u00e4gre, 200. Prioriteter till\u00e4mpas hierarkiskt. Alla uppgifter l\u00e4ngre ner i hierarkin har motsvarande prioritet. Om vi vill att cache ska k\u00f6ras f\u00f6re front-end i prod, tilldelar vi prioriteten cache = 0 och front-subk\u00f6n = 1. Om vi till exempel vill att huvudportalen ska starta f\u00f6rst bland front-end, medan music front k\u00f6rs efter\u00e5t, kan vi tilldela den senare en l\u00e4gre prioritet \u2014 10.<\/p>\n<p><\/p>\n<p>N\u00e4sta problem \u00e4r brist p\u00e5 resurser. S\u00e5, vi har haft stora utrustningsavbrott, hela hallar i datacentret, och vi har startat s\u00e5 m\u00e5nga tj\u00e4nster att det nu inte finns tillr\u00e4ckliga resurser f\u00f6r alla. Vi m\u00e5ste avg\u00f6ra vilka uppgifter vi kan offra f\u00f6r att de viktigaste kritiska tj\u00e4nsterna ska fungera. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niv\u00e5 OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/1b1ad3da16df6677dd0ba4b038cdd7d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Till skillnad fr\u00e5n placeringsprioriteten kan vi inte helt enkelt offra alla batch-uppgifter, vissa av dem \u00e4r viktiga f\u00f6r portalen. D\u00e4rf\u00f6r har vi s\u00e4rskilt identifierat <strong>utdragningsprioritet<\/strong> F\u00f6r uppgifter. Vid placering kan en uppgift med h\u00f6gre prioritet utdriva, dvs. stoppa en uppgift med l\u00e4gre prioritet, om det inte finns n\u00e5gra lediga minions. Om s\u00e5 \u00e4r fallet kommer en uppgift med l\u00e5g prioritet sannolikt att f\u00f6rbli oplacerad, dvs. det kommer inte att finnas n\u00e5gon l\u00e4mplig minion med tillr\u00e4ckliga lediga resurser f\u00f6r den.<\/p>\n<p><\/p>\n<p>I v\u00e5r hierarki \u00e4r det mycket enkelt att ange en s\u00e5dan utdragningsprioritet s\u00e5 att prod- och batch-uppgifter utdriver eller stoppar idle-uppgifter, men inte varandra, genom att ange en prioritet f\u00f6r idle som \u00e4r 200. Precis som med placeringsprioritet kan vi anv\u00e4nda v\u00e5r hierarki f\u00f6r att beskriva mer komplexa regler. Till exempel kan vi ange att musikinneh\u00e5ll offras om vi inte har tillr\u00e4ckliga resurser f\u00f6r huvudwebbportalen, genom att s\u00e4tta l\u00e4gre prioritet p\u00e5 de relevanta noderna: 10.<\/p>\n<p><\/p>\n<h2 id=\"avarii-dc-celikom\">Hela datacentrets krascher<\/h2>\n<p><\/p>\n<p>Varf\u00f6r kan hela datacentret fallera? Naturkatastrofer. Det fanns ett bra inl\u00e4gg om hur <noindex><a rel=\"nofollow\" href=\"https:\/\/habrahabr.ru\/company\/dataline\/blog\/333578\/\">orkanen p\u00e5verkade datacentrets verksamhet<\/a><\/noindex>. Elementet kan beskrivas som heml\u00f6sa, som en g\u00e5ng skadade fiberoptiken i en avloppsledning, vilket gjorde att datacentret helt f\u00f6rlorade kontakten med andra platser. Orsaken till haveri kan ocks\u00e5 vara m\u00e4nsklig: en operat\u00f6r kan ge en s\u00e5dan direktiv att hela datacentret g\u00e5r ner. Detta kan h\u00e4nda p\u00e5 grund av allvarliga buggar. Sammanfattningsvis, datacenter kraschar - det \u00e4r inte ovanligt. Det h\u00e4nder hos oss n\u00e5gra g\u00e5nger per \u00e5r. <\/p>\n<p><\/p>\n<p>Och detta \u00e4r vad vi g\u00f6r f\u00f6r att ingen #\u00f6verbrygga ska posta p\u00e5 Twitter.<\/p>\n<p><\/p>\n<p>Den f\u00f6rsta strategin \u00e4r isolering. Varje instans av one-cloud \u00e4r isolerad och kan bara hantera maskiner fr\u00e5n ett enda datacenter. Det inneb\u00e4r att f\u00f6rlust av molnet p\u00e5 grund av buggar eller felaktiga kommandon fr\u00e5n operat\u00f6ren - det \u00e4r bara f\u00f6rlust av ett datacenter. Vi \u00e4r f\u00f6rberedda f\u00f6r detta: det finns en reservpolicy d\u00e4r applikations- och datakopior placeras i alla datacenter. Vi anv\u00e4nder h\u00f6g tillg\u00e4nglighet i databaserna och testar regelbundet systemfel.<br \/>\nEftersom vi idag har fyra datacenter, finns det ocks\u00e5 fyra separata, helt isolerade instanser av one-cloud.<\/p>\n<p><\/p>\n<p>Denna metod skyddar inte bara mot fysiska fel, utan kan ocks\u00e5 skydda mot operat\u00f6rsfel.<\/p>\n<p><\/p>\n<p>Vad mer kan g\u00f6ras med det m\u00e4nskliga faktorn? N\u00e4r operat\u00f6ren ger molnet n\u00e5got konstigt eller potentiellt farligt kommando, kan de pl\u00f6tsligt beh\u00f6va l\u00f6sa en liten uppgift f\u00f6r att kontrollera hur noga de har t\u00e4nkt. Till exempel, om det handlar om ett massavbrott av m\u00e5nga kopior eller bara ett konstigt kommando - att minska antalet kopior eller \u00e4ndra namnet p\u00e5 en bild i st\u00e4llet f\u00f6r bara versionsnumret i den nya manifestfilen.<\/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 datacenter-niv\u00e5 OS i 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\">Sammanfattning<\/h2>\n<p><\/p>\n<p>Utm\u00e4rkande drag av one-cloud: <\/p>\n<p><\/p>\n<ul>\n<li><strong>En hierarkisk och tydlig namngivningsschema f\u00f6r tj\u00e4nster och containrar<\/strong>, vilket g\u00f6r att man snabbt kan f\u00f6rst\u00e5 vilken uppgift det handlar om, vad den relaterar till, hur den fungerar och vem som ansvarar f\u00f6r den. <\/li>\n<li>Vi till\u00e4mpar v\u00e5r <strong>teknik f\u00f6r att kombinera prod- och batch-<\/strong>uppgifter p\u00e5 minioner f\u00f6r att \u00f6ka effektiviteten av resursdelning. Ist\u00e4llet f\u00f6r cpuset anv\u00e4nder vi CPU-quota, shares, policyer f\u00f6r CPU-schemal\u00e4ggning och Linux QoS.<\/li>\n<li>Att helt isolera containrar som k\u00f6rs p\u00e5 en maskin har vi inte lyckats med, men deras \u00f6msesidiga p\u00e5verkan f\u00f6rblir inom 20%.<\/li>\n<li>Att organisera tj\u00e4nster i en hierarki hj\u00e4lper vid automatiskt felavhj\u00e4lpande med hj\u00e4lp av <strong>placering och utst\u00f6tningsprioriteter<\/strong>.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"chavo\">FAQ<\/h2>\n<p><\/p>\n<p>Varf\u00f6r vi inte valde en f\u00e4rdig l\u00f6sning.<\/p>\n<p><\/p>\n<ul>\n<li>Olika klasser av isolering av uppgifter kr\u00e4ver olika logik f\u00f6r placering p\u00e5 minioner. Medan produktionsuppgifter kan placeras enkelt genom resursreservering, beh\u00f6ver batch och idle placeras genom att \u00f6vervaka den faktiska resursutnyttjandet p\u00e5 maskinminionerna. <\/li>\n<li>Behov av att ta h\u00e4nsyn till resurser som uppgifterna konsumerar, s\u00e5som: \n<ul>\n<li>n\u00e4tverksbandbredd;<\/li>\n<li>typer och \"spindlar\" av diskar.<\/li>\n<\/ul>\n<\/li>\n<li>Behov av att ange prioriteringar f\u00f6r tj\u00e4nster vid avbrott, r\u00e4ttigheter och kvoter f\u00f6r team p\u00e5 resurser, vilket l\u00f6ses med hierarkiska k\u00f6er i one-cloud.<\/li>\n<li>Behov av att ha m\u00e4nskliga namn f\u00f6r containrar f\u00f6r att minska reaktionstiden p\u00e5 avbrott och incidenter.<\/li>\n<li>Of\u00f6rm\u00e5ga att implementera Service Discovery \u00f6verallt samtidigt; behovet av att samexistera l\u00e4nge med uppgifter som \u00e4r placerade p\u00e5 fysiska v\u00e4rdar \u2013 vilket l\u00f6ses med \"statisk\" IP-adresser som f\u00f6ljer containrarna, och d\u00e4rmed behovet av unik integration med en stor n\u00e4tverksinfrastruktur.<\/li>\n<\/ul>\n<p><\/p>\n<p>Alla dessa funktioner skulle kr\u00e4va betydande ombyggnader av de befintliga l\u00f6sningarna, och efter att ha bed\u00f6mt m\u00e4ngden arbete ins\u00e5g vi att vi skulle kunna utveckla v\u00e5r egen l\u00f6sning med ungef\u00e4r samma arbetsinsats. Men v\u00e5r l\u00f6sning kommer att vara mycket enklare att anv\u00e4nda och utveckla \u2013 den har inga on\u00f6diga abstraktioner som st\u00f6der funktionalitet vi inte beh\u00f6ver. <\/p>\n<p><\/p>\n<p>Till alla som l\u00e4ser de sista raderna \u2013 tack f\u00f6r ert t\u00e5lamod och uppm\u00e4rksamhet!<\/p>\n<p>K\u00e4lla: <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\/sv\/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=\"sv_SE\" \/>\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\/sv\/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 \u2013 datacenter-niv\u00e5 OS i Odnoklassniki | ProHoster","description":"Aloha, folk!","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/84114","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=84114"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/84114\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/84115"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=84114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=84114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=84114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}