{"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\/da\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","title":{"rendered":"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau 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! Mit navn er Oleg Anastasyev, og jeg arbejder i Odnoklassniki i Platform-teamet. Udover mig er der ogs\u00e5 et v\u00e6ld af hardware i Odnoklassniki. Vi har fire datacentre med omkring 500 racks og mere end 8.000 servere. P\u00e5 et tidspunkt inds\u00e5 vi, at implementering af et nyt administrationssystem ville g\u00f8re det lettere at udnytte vores udstyr mere effektivt, forenkle adgangsstyringen, automatisere (gen)fordelingen af computerressourcer, accelerere lanceringsprocessen af nye tjenester og forbedre reaktionerne p\u00e5 store nedbrud. <\/p>\n<p><\/p>\n<p>Hvad kom der ud af det? <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Udover mig og en masse hardware er der ogs\u00e5 folk, der arbejder med dette udstyr: ingeni\u00f8rer, som befinder sig direkte i datacentrene; netv\u00e6rksspecialister, der konfigurerer netv\u00e6rksinfrastrukturen; administratorer eller SRE'er, der sikrer systemets p\u00e5lidelighed; og udviklingsteams, hvor hvert team har ansvaret for bestemte funktioner p\u00e5 portalen. Den software, de udvikler, fungerer s\u00e5ledes:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/592fd0acfa7322eb80fbb85601a92918.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Brugerforesp\u00f8rgsler modtages b\u00e5de p\u00e5 fronten af hovedportalen <noindex><a rel=\"nofollow\" href=\"http:\/\/www.ok.ru\/\">www.ok.ru<\/a><\/noindex>, og p\u00e5 andre, s\u00e5som p\u00e5 fronten til musik API'en. For at h\u00e5ndtere forretningslogikken kalder de applikationsserveren, som under behandlingen af foresp\u00f8rgslen kalder de n\u00f8dvendige specialiserede mikrotjenester \u2014 one-graph (graf over sociale forbindelser), user-cache (cache for brugerprofiler) osv.<\/p>\n<p><\/p>\n<p>Hver af disse tjenester er implementeret p\u00e5 mange maskiner, og hver har ansvarlige udviklere, der er ansvarlige for modulernes funktionalitet, drift og teknologiske udvikling. Alle disse tjenester k\u00f8rer p\u00e5 fysiske servere, og indtil for nylig k\u00f8rte vi pr\u00e6cist \u00e9n opgave p\u00e5 \u00e9n server, hvilket bet\u00f8d, at den var specialiseret til en bestemt opgave.<\/p>\n<p><\/p>\n<p>Hvorfor er det s\u00e5dan? Denne tilgang har haft flere fordele:<\/p>\n<p><\/p>\n<ul>\n<li>Det g\u00f8r det lettere at <strong>h\u00e5ndtere masseoperationer<\/strong>. Antag, at opgaven kr\u00e6ver bestemte biblioteker og konfigurationer. S\u00e5 bliver serveren tildelt \u00e9n bestemt gruppe, og der beskrives en cfengine-politik for denne gruppe (eller den er allerede beskrevet), og denne konfiguration rulles centralt og automatisk ud til alle servere i denne gruppe.<\/li>\n<li>Det forenkler <strong>diagnosticering<\/strong>. Antag at du ser p\u00e5 en h\u00f8j belastning p\u00e5 centralprocessoren og forst\u00e5r, at den belastning kun kunne v\u00e6re genereret af den opgave, der k\u00f8rer p\u00e5 denne fysiske processor. S\u00f8gningen efter den skyldige bliver hurtigt afsluttet.<\/li>\n<li>Det forenkler <strong>overv\u00e5gning<\/strong>. Hvis der er noget galt med serveren, rapporterer monitoren det, og du ved pr\u00e6cist, hvem der er skyld i det.<\/li>\n<\/ul>\n<p><\/p>\n<p>En tjeneste best\u00e5ende af flere kopier tildeles flere servere \u2014 en for hver. S\u00e5 udnyttelsen af beregningsressourcer til tjenesten er meget enkel: jo flere servere tjenesten har, desto flere ressourcer kan den maksimalt forbruge. 'Enkel' her betyder ikke, at det er nemt at bruge, men at ressourcerne tildeles manuelt.<\/p>\n<p><\/p>\n<p>Denne tilgang gjorde det ogs\u00e5 muligt for os at lave <strong>specialiserede hardwarekonfigurationer<\/strong> til opgaven, der udf\u00f8res p\u00e5 denne server. Hvis opgaven gemmer store m\u00e6ngder data, bruger vi en 4U-server med chassis til 38 harddiske. Hvis opgaven er rent beregningsm\u00e6ssig, kan vi k\u00f8be en billigere 1U-server. Dette er effektivt med hensyn til beregningsressourcer. Denne tilgang tillader os ogs\u00e5 at bruge fire gange f\u00e6rre maskiner ved en belastning, der svarer til en lokal social netv\u00e6rkstjeneste. <\/p>\n<p><\/p>\n<p>Denne effektivitet i udnyttelsen af beregningsressourcer b\u00f8r ogs\u00e5 sikre \u00f8konomisk effektivitet, hvis vi tager udgangspunkt i pr\u00e6missen om, at det dyreste er serverne. L\u00e6nger var det egentligt hardware, der var dyrest, og vi har investeret mange ressourcer i at s\u00e6nke omkostningerne til hardware ved at udvikle algoritmer til at sikre fejltolerance for at reducere kravene til udstyrets p\u00e5lidelighed. Og i dag er vi n\u00e5et til et punkt, hvor prisfaktoren for servere ikke l\u00e6ngere er afg\u00f8rende. Hvis vi ser bort fra den nyeste eksotiske teknologi, s\u00e5 har den specifikke konfiguration af servere i rack ikke l\u00e6ngere betydning. Nu har vi et andet problem \u2014 prisen for den plads, serveren optager i datacenteret, dvs. pladsen i rakket.<\/p>\n<p><\/p>\n<p>Da vi inds\u00e5, at det var tilf\u00e6ldet, besluttede vi at beregne, hvor effektivt vi bruger rackerne.<br \/>\nVi tog prisen for den mest kraftfulde server, der er \u00f8konomisk forsvarlig, og beregnede, hvor mange af disse servere vi kunne placere i racks, hvilke opgaver vi ville k\u00f8re p\u00e5 dem baseret p\u00e5 den gamle model '\u00e9n server = \u00e9n opgave', og hvor meget udstyr disse opgaver ville kunne udnytte. Det viser sig, at vores effektivitet i brugen af racks er omkring 11 %. Den \u00e5benlyse konklusion er, at vi skal \u00f8ge effektiviteten i brugen af datacentre. Tilsyneladende er l\u00f8sningen enkel: man skal k\u00f8re flere opgaver p\u00e5 \u00e9n server. Men her opst\u00e5r der komplikationer. <\/p>\n<p><\/p>\n<p>Massekonfigurationen bliver pludselig langt mere kompliceret \u2014 det er nu umuligt at tildele serveren en bestemt gruppe. For nu kan der k\u00f8re flere opgaver fra forskellige teams p\u00e5 \u00e9n server. Derudover kan konfigurationen v\u00e6re konfliktfyldt for forskellige applikationer. Diagnosen bliver ogs\u00e5 mere vanskelig: hvis du ser et \u00f8get forbrug af CPU'er eller diske p\u00e5 serveren, ved du ikke, hvilken opgave der for\u00e5rsager problemer.<\/p>\n<p><\/p>\n<p>Men det vigtigste er, at der ikke er isolation mellem opgaverne, der k\u00f8rer p\u00e5 \u00e9n maskine. For eksempel, grafen for den gennemsnitlige responstid for en serveropgave f\u00f8r og efter en anden, ikke-relateret beregningsapplikation blev k\u00f8rt p\u00e5 samme server \u2014 responstiden for den prim\u00e6re opgave steg betydeligt.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/c7c07359ae572ca8c84a4c63559e4083.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Det er \u00e5benlyst, at opgaverne skal k\u00f8res enten i containere eller i virtuelle maskiner. Da n\u00e6sten alle vores opgaver k\u00f8rer under \u00e9n operativsystem (Linux) eller er tilpasset til det, har vi ikke brug for at underst\u00f8tte mange forskellige operativsystemer. Derfor er virtualisering ikke n\u00f8dvendig, da det vil v\u00e6re mindre effektivt end containerisering p\u00e5 grund af de ekstra omkostninger.<\/p>\n<p><\/p>\n<p>Som en implementering af containere til at k\u00f8re opgaver direkte p\u00e5 servere er Docker en god kandidat: filsystembilleder l\u00f8ser problemer med konflikterende konfigurationer effektivt. Det faktum, at billeder kan sammens\u00e6ttes af flere lag, g\u00f8r det muligt for os at reducere m\u00e6ngden af data, der er n\u00f8dvendig for at implementere dem p\u00e5 infrastrukturen, ved at udskille de f\u00e6lles dele i separate basislag. S\u00e5 vil basislagene (og de st\u00f8rste) hurtigt blive cachet p\u00e5 hele infrastrukturen, og for at levere mange forskellige typer applikationer og versioner, vil vi kun skulle overf\u00f8re sm\u00e5 lag. <\/p>\n<p><\/p>\n<p>Derudover giver det f\u00e6rdige register og taggning af billeder i Docker os f\u00e6rdige primitiv til versionsstyring og levering af kode til produktionen.<\/p>\n<p><\/p>\n<p>Docker, ligesom enhver anden lignende teknologi, giver os et vist niveau af isolation af containere out-of-the-box. For eksempel isolering af hukommelse \u2014 hver container tildeles en gr\u00e6nse for brugen af maskinens hukommelse, som den ikke kan overskride. Det er ogs\u00e5 muligt at isolere containere i forhold til CPU-forbrug. For os var den standardiserede isolation dog ikke tilstr\u00e6kkelig. Men det er der mere om nedenfor.<\/p>\n<p><\/p>\n<p>Den direkte k\u00f8rsel af containere p\u00e5 servere er kun en del af problemerne. En anden del handler om placeringen af containere p\u00e5 serverne. Man skal forst\u00e5, hvilken container der kan placeres p\u00e5 hvilken server. Dette er ikke en s\u00e5 simpel opgave, fordi containere skal placeres p\u00e5 servere s\u00e5 t\u00e6t som muligt uden at neds\u00e6tte deres ydeevne. S\u00e5dan placering kan v\u00e6re kompleks ogs\u00e5 med hensyn til failover. Ofte \u00f8nsker vi at placere reprikater af den samme service i forskellige racks eller endda i forskellige datacenterhaller, s\u00e5 vi ikke mister alle reprikater af servicen p\u00e5 \u00e9n gang, hvis et rack eller en hal fejler. <\/p>\n<p><\/p>\n<p>At fordele containere manuelt er ikke en mulighed, n\u00e5r man har 8.000 servere og 8.000-16.000 containere. <\/p>\n<p><\/p>\n<p>Desuden \u00f8nskede vi at give udviklerne mere selvst\u00e6ndighed i fordelingen af ressourcer, s\u00e5 de selv kunne placere deres tjenester i produktion uden hj\u00e6lp fra en administrator. P\u00e5 den m\u00e5de \u00f8nskede vi at bevare kontrollen, s\u00e5 en sekund\u00e6r service ikke optager alle ressourcerne i vores datacentre. <\/p>\n<p><\/p>\n<p>Det er \u00e5benlyst, at der er brug for et administrationslag, der kan h\u00e5ndtere dette automatisk.<\/p>\n<p><\/p>\n<p>Her er vi kommet til et simpelt og klart billede, som alle arkitekter elsker: tre firkanter. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau 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 masters \u2013 en fejltolerant klynge, der er ansvarlig for orkestrering af skyen. Udvikleren sender en manifest til masteren, som indeholder al n\u00f8dvendig information til placering af tjenesten. Masteren giver ordre til udvalgte minions (maskiner, der er beregnet til at k\u00f8re containere) baseret p\u00e5 dette. P\u00e5 minions er vores agent, der modtager ordren, afgiver allerede sine kommandoer til Docker, som konfigurerer Linux-kernen for at k\u00f8re den relevante container. Udover at udf\u00f8re ordrer rapporterer agenten kontinuerligt til masteren om \u00e6ndringer i tilstanden af b\u00e5de minion-maskinerne og de containere, der k\u00f8rer p\u00e5 dem.<\/p>\n<p><\/p>\n<h2 id=\"raspredelenie-resursov\">Ressourcefordeling<\/h2>\n<p><\/p>\n<p>Lad os nu se p\u00e5 opgaven om mere kompleks ressourcefordeling for mange minions.<\/p>\n<p><\/p>\n<p>Computerressourcen i one-cloud er:<\/p>\n<p><\/p>\n<ul>\n<li>Den computerkraft, som en specifik opgave kr\u00e6ver. <\/li>\n<li>M\u00e6ngden af hukommelse, der er tilg\u00e6ngelig for opgaven. <\/li>\n<li>Netv\u00e6rkstrafik. Hver av minions har en specifik netv\u00e6rksgr\u00e6nseflade med begr\u00e6nset b\u00e5ndbredde, s\u00e5 opgaver kan ikke fordeles uden at tage h\u00f8jde for den m\u00e6ngde data, der sendes over netv\u00e6rket. <\/li>\n<li>Disker. Udover, \u00e5benlyst, plads til data fra opgaven, tildeler vi ogs\u00e5 disktypen: HDD eller SSD. Diskene kan h\u00e5ndtere et begr\u00e6nset antal anmodninger per sekund \u2013 IOPS. Derfor, for opgaver, der genererer flere IOPS, end en enkelt disk kan h\u00e5ndtere, tildeler vi ogs\u00e5 \"spindler\" \u2013 dvs. disk-enheder, der udelukkende skal reserveres til opgaven.<\/li>\n<\/ul>\n<p><\/p>\n<p>For en hvilken som helst tjeneste, for eksempel user-cache, kan vi angive de forbrugte ressourcer p\u00e5 denne m\u00e5de: 400 CPU-kerner, 2,5 TB hukommelse, 50 Gbit\/s trafik i begge retninger, 6 TB plads p\u00e5 HDD, placeret p\u00e5 100 spindler. Eller i en mere velkendt form s\u00e5ledes:<\/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>Ressourcerne for user-cache-tjenesten forbruger kun en del af alle tilg\u00e6ngelige ressourcer i produktionsinfrastrukturen. Derfor \u00f8nsker vi at sikre, at user-cache ikke pludselig forbruger flere ressourcer, end det er tildelt, hverken p\u00e5 grund af en operat\u00f8rfejl eller ej. Det vil sige, at vi skal begr\u00e6nse ressourcerne. Men hvad kunne vi knytte kvoten til?<\/p>\n<p><\/p>\n<p>Lad os vende tilbage til vores st\u00e6rkt forenklede diagram over komponenternes interaktion og tegne det om med flere detaljer \u2014 s\u00e5dan her: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/27e5bfbffadd3d4b9fdc6bf138d135ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hvad der springer i \u00f8jnene:<\/p>\n<p><\/p>\n<ul>\n<li>Web-frontenden og musikken bruger isolerede klynger fra den samme applikationsserver.<\/li>\n<li>Vi kan identificere logiske lag, som disse klynger tilh\u00f8rer: front-end, caches, lagring og databehandlingslag.<\/li>\n<li>Frontenden er heterogen, det er forskellige funktionelle undersystemer. <\/li>\n<li>Caches kan ogs\u00e5 fordeles i henhold til det undersystem, hvis data de cacher.<\/li>\n<\/ul>\n<p><\/p>\n<p>Lad os tegne billedet om igen:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/905dacc0aca859e65bd33ef751a557cf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>N\u00e5! Vi ser hierarkiet! Det betyder, at vi kan fordele ressourcer i st\u00f8rre m\u00e6ngder: tildele en ansvarlig udvikler til en knude i dette hierarki, som svarer til et funktionelt undersystem (som 'music' p\u00e5 billedet), og knytte en kvote til det samme hierarki. Dette hierarki g\u00f8r det ogs\u00e5 muligt for os at organisere tjenesterne mere fleksibelt for at lette administrationen. For eksempel opdeler vi alle web, da det er en meget stor gruppe servere, i flere mindre grupper, der er vist p\u00e5 billedet som group1, group2.<\/p>\n<p><\/p>\n<p>Ved at fjerne un\u00f8dvendige linjer kan vi skrive hver knude i vores billede p\u00e5 en mere flad m\u00e5de: <strong>group1.web.front<\/strong>, <strong>api.music.front<\/strong>, <strong>user-cache.cache<\/strong>.<\/p>\n<p><\/p>\n<p>S\u00e5 vi kommer til begrebet \"hierarkisk k\u00f8\". Den har et navn, som \"group1.web.front\". Der tildeles en kvote til ressourcer og brugerrettigheder. En person fra DevOps f\u00e5r rettigheder til at sende tjenesten til k\u00f8en, og s\u00e5dan en medarbejder kan starte noget i k\u00f8en, mens en person fra OpsDev \u2014 f\u00e5r administratorrettigheder, og nu kan han styre k\u00f8en, tildele folk til den, give disse folk rettigheder osv. Tjenester, der startes i denne k\u00f8, vil blive udf\u00f8rt inden for k\u00f8ens kvote. Hvis den beregnede kvote for k\u00f8en ikke er tilstr\u00e6kkelig til samtidig udf\u00f8relse af alle tjenester, vil de blive udf\u00f8rt sekventielt, og dermed danne en faktisk k\u00f8. <\/p>\n<p><\/p>\n<p>Lad os se n\u00e6rmere p\u00e5 tjenesterne. En tjeneste har et fuldt navn, som altid indeholder navnet p\u00e5 k\u00f8en. S\u00e5 web front-tjenesten vil have navnet <strong>ok-web.group1.web.front<\/strong>. Og tjenesten for applikationsserveren, som den henvender sig til, vil blive kaldt <strong>ok-app.group1.web.front<\/strong>. Hver tjeneste har et manifest, der angiver al n\u00f8dvendig information for placeringen p\u00e5 specifikke maskiner: hvor mange ressourcer denne opgave bruger, hvilken konfiguration der er n\u00f8dvendig, hvor mange replika der skal v\u00e6re, og egenskaberne for fejlh\u00e5ndtering af denne tjeneste. Efter placeringen af tjenesten direkte p\u00e5 maskinerne opst\u00e5r dens instanser. De navngives ogs\u00e5 entydigt \u2014 som instansnummeret og tjenestenavnet: <strong>1.ok-web.group1.web.front, 2.ok-web.group1.web.front, \u2026<\/strong><\/p>\n<p><\/p>\n<p>Dette er meget praktisk: ved kun at se p\u00e5 navnet p\u00e5 den k\u00f8rende container kan vi straks finde ud af meget.<\/p>\n<p><\/p>\n<p>Lad os nu komme t\u00e6ttere p\u00e5, hvad disse instanser faktisk udf\u00f8rer: opgaverne.<\/p>\n<p><\/p>\n<h2 id=\"klassy-izolyacii-zadach\">Klasser af opgaveisolering<\/h2>\n<p><\/p>\n<p>Alle opgaver i OK (og sikkert ogs\u00e5 andre steder) kan deles op i grupper:<\/p>\n<p><\/p>\n<ul>\n<li><strong>Opgaver med kort forsinkelse \u2014 prod<\/strong>. For s\u00e5danne opgaver og tjenester er responstiden (latency) meget vigtig, hvor hurtigt hvert enkelt af anmodningerne vil blive behandlet af systemet. Eksempler p\u00e5 opgaver: webfront-end, cache, applikationsservere, OLTP-lagre osv.<\/li>\n<li><strong>Beregningsopgaver \u2014 batch<\/strong>. Her er hastigheden for behandling af hver enkelt anmodning ikke vigtig. Det, der betyder noget, er, hvor mange beregninger denne opgave udf\u00f8rer i en given (stor) periode (throughput). Dette vil inkludere alle MapReduce-opgaver, Hadoop, maskinl\u00e6ring, statistik.<\/li>\n<li><strong>Baggrundsopgaver \u2014 idle<\/strong>. For s\u00e5danne opgaver er hverken latency eller throughput s\u00e6rlig vigtig. Herunder h\u00f8rer forskellige test, migrationer, genberegninger, konverteringer af data fra et format til et andet. P\u00e5 den ene side minder de om beregningsopgaver, men p\u00e5 den anden side er det ikke s\u00e6rlig vigtigt, hvor hurtigt de afsluttes. <\/li>\n<\/ul>\n<p><\/p>\n<p>Lad os se p\u00e5, hvordan s\u00e5danne opgaver forbruger ressourcer, for eksempel CPU.<\/p>\n<p><\/p>\n<p><strong>Opgaver med kort forsinkelse.<\/strong> En s\u00e5dan opgave har et m\u00f8nster for CPU-forbrug, der ligner dette:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/1ed82c0df76325eb30056ad9af86e86e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>En anmodning fra brugeren behandles, opgaven begynder at bruge alle tilg\u00e6ngelige CPU-kerner, behandler, returnerer et svar, venter p\u00e5 n\u00e6ste anmodning og st\u00e5r stille. Den n\u00e6ste anmodning kommer ind \u2014 vi bruger igen alt, hvad vi har, behandler, venter p\u00e5 n\u00e6ste.<\/p>\n<p><\/p>\n<p>For at sikre minimal forsinkelse for en s\u00e5dan opgave skal vi tage det maksimale af de ressourcer, den bruger, og reservere det n\u00f8dvendige antal kerner p\u00e5 minionen (maskinen, der vil udf\u00f8re opgaven). S\u00e5 vores reservationsformel for denne opgave bliver:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = 4 (max)<\/code><\/pre>\n<p><\/p>\n<p>Og hvis vi har en mini-maskine med 16 kerner, kan vi placere pr\u00e6cis fire af disse opgaver p\u00e5 den. Det er v\u00e6rd at bem\u00e6rke, at den gennemsnitlige CPU-forbrug for s\u00e5danne opgaver ofte er meget lavt - hvilket er \u00e5benlyst, da en v\u00e6sentlig del af tiden opgaven er i venteposition og ikke laver noget.<\/p>\n<p><\/p>\n<p><strong>Beregningsopgaver.<\/strong> De vil have et lidt anderledes m\u00f8nster:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/35b37fa1d70a137287cafdbfe3bcfc2e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Det gennemsnitlige ressourceforbrug p\u00e5 CPU for s\u00e5danne opgaver er ret h\u00f8jt. Vi \u00f8nsker ofte, at beregningsopgaven udf\u00f8res inden for en bestemt tidsramme, s\u00e5 vi skal reservere det minimale antal processorer, der kr\u00e6ves for at hele beregningen kan afsluttes inden for en acceptabel tid. Dens reservationsformel vil se s\u00e5ledes ud:<\/p>\n<p><\/p>\n<pre><code>alloc: cpu = [1,*)<\/code><\/pre>\n<p><\/p>\n<p><em>\u201ePlacer venligst p\u00e5 mini-maskinen, hvor der er mindst \u00e9n ledig kerne, og derefter vil den tage alt den kan f\u00e5.\u201c<\/em><\/p>\n<p><\/p>\n<p>Her er effektiviteten langt bedre end for opgaver med kort forsinkelse. Men gevinsten vil v\u00e6re meget st\u00f8rre, hvis begge typer opgaver kombineres p\u00e5 \u00e9n mini-maskine og dens ressourcer fordeles l\u00f8bende. N\u00e5r en opgave med kort forsinkelse har brug for CPU - f\u00e5r den den straks, og n\u00e5r ressourcerne ikke l\u00e6ngere er n\u00f8dvendige - gives de videre til beregningsopgaven, dvs. s\u00e5dan:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/875ad8d3f6a01e4fd0a89d0931e986c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Men hvordan g\u00f8r man det?<\/p>\n<p><\/p>\n<p>Lad os f\u00f8rst se p\u00e5 prod og dens alloc: cpu = 4. Vi skal reservere fire kerner. I Docker run kan dette g\u00f8res p\u00e5 to m\u00e5der: <\/p>\n<p><\/p>\n<ul>\n<li>Ved at bruge muligheden <code>--cpuset=1-4<\/code>, dvs. at tildele opgaven fire bestemte kerner p\u00e5 maskinen.<\/li>\n<li>Brug <code>--cpuquota=400_000 --cpuperiod=100_000<\/code>, tildele en kvote for CPU-tid, dvs. angive, at hver 100 ms i realtid bruger opgaven ikke mere end 400 ms CPU-tid. Det bliver de samme fire kerner. <\/li>\n<\/ul>\n<p><\/p>\n<p>Men hvilken af disse metoder er den rigtige?<\/p>\n<p><\/p>\n<p>Cpuset ser ganske attraktivt ud. Opgaven har fire dedikerede kerner, hvilket betyder, at processorcache kan fungere mest effektivt. Der er dog en bagside: vi ville skulle p\u00e5tage os opgaven med at fordele beregningen p\u00e5 de ubelastede kerner i maskinen i stedet for OS, og det er en ret ikke-triviel opgave, is\u00e6r hvis vi fors\u00f8ger at placere batch-opgaver p\u00e5 en s\u00e5dan maskine. Tests har vist, at en variant med kvote passer bedre her: p\u00e5 den m\u00e5de har operativsystemet mere frihed til at v\u00e6lge en kerne til opgaven i det aktuelle \u00f8jeblik, og processorens tid fordeles mere effektivt.<\/p>\n<p><\/p>\n<p>Lad os finde ud af, hvordan man i Docker kan reservere et minimum af kerner. Kvote for batch-opgaver er ikke l\u00e6ngere anvendelig, fordi det ikke er n\u00f8dvendigt at begr\u00e6nse maksimum, det er kun n\u00f8dvendigt at garantere minimum. Og her passer indstillingen godt <code>docker run --cpushares<\/code>.<\/p>\n<p><\/p>\n<p>Vi har aftalt, at hvis batch kr\u00e6ver garanti for minimum p\u00e5 \u00e9n kerne, s\u00e5 angiver vi <code>--cpushares=1024<\/code>, og hvis minimum er p\u00e5 to kerner, s\u00e5 angiver vi <code>--cpushares=2048<\/code>. Cpu shares p\u00e5virker ikke fordelingen af processorens tid, s\u00e5 l\u00e6nge der er tilstr\u00e6kkeligt af det. Hvis prod i \u00f8jeblikket ikke bruger alle sine fire kerner, begr\u00e6nser intet batch-opgaverne, og de kan bruge den ekstra processor tid. Men i en situation med mangel p\u00e5 processor, hvis prod har forbrugt alle sine fire kerner og rammer kvoten, vil den resterende processor tid blive fordelt proportionalt efter cpushares; dvs. i situationen med tre frie kerner vil \u00e9n f\u00e5 opgaven med 1024 cpushares, og de andre to vil f\u00e5 opgaven med 2048 cpushares.<\/p>\n<p><\/p>\n<p>Men brugen af kvote og shares er ikke nok. Vi skal s\u00f8rge for, at opgaver med kort forsinkelse f\u00e5r prioritet over batch-opgaverne ved fordelingen af processor tid. Uden s\u00e5dan prioritering vil batch-opgaven tage al processor tid, n\u00e5r den er n\u00f8dvendig for prod. I Docker run er der ingen prioriteringsmuligheder for containere, men CPU-scheduler politikerne i Linux tr\u00e6der til. Du kan l\u00e6se mere om dem <noindex><a rel=\"nofollow\" href=\"http:\/\/man7.org\/linux\/man-pages\/man2\/sched_setscheduler.2.html\">her<\/a><\/noindex>, men i denne artikel vil vi kort gennemg\u00e5 dem:<\/p>\n<p><\/p>\n<ul>\n<li><strong>SCHED_OTHER<\/strong><br \/>\nSom standard f\u00e5r alle almindelige brugerprocesser p\u00e5 en Linux-maskine.<\/li>\n<li><strong>SCHED_BATCH<\/strong><br \/>\nDesignet til ressourcekr\u00e6vende processer. N\u00e5r en opgave placeres i processoren, indf\u00f8res der en s\u00e5kaldt aktiveringsb\u00f8de: en s\u00e5dan opgave vil have mindre sandsynlighed for at modtage processorressourcer, hvis den i \u00f8jeblikket bruges af en opgave med SCHED_OTHER.<\/li>\n<li><strong>SCHED_IDLE<\/strong><br \/>\nBaggrundsprocessen med meget lav prioritet, endda lavere end nice -19. Vi bruger vores open source-bibliotek <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/odnoklassniki\/one-nio\">one-nio<\/a><\/noindex>, for at angive den n\u00f8dvendige politik ved opstart af containeren ved at kalde<\/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 selv hvis du ikke programmerer i Java, kan det samme g\u00f8res med kommandoen chrt:<\/p>\n<p><\/p>\n<pre><code class=\"bash\">chrt -i 0 $pid<\/code><\/pre>\n<p><\/p>\n<p>Lad os samle alle vores isolationsniveauer i en tabel for klarhed:<\/p>\n<p><\/p>\n<p>Isolationsklasse<br \/>\nEksempel alloc<br \/>\nDocker run muligheder<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>*Hvis du bruger chrt indefra containeren, kan det v\u00e6re n\u00f8dvendigt med capability sys_nice, fordi Docker som standard fjerner denne capability ved opstart af containeren.<\/p>\n<p><\/p>\n<p>Men opgaver bruger ikke kun processoren, men ogs\u00e5 trafik, som p\u00e5virker latenstiden for netv\u00e6rksopgaven endnu mere end forkert ressourcefordeling af processoren. Derfor vil vi naturligvis gerne have et pr\u00e6cist billede for trafikken. Det vil sige, n\u00e5r en prod-opgave sender nogle pakker til netv\u00e6rket, kvoterer vi den maksimale hastighed (formlen <em>alloc: lan=[*,500mbps)<\/em> ), som prod kan g\u00f8re dette. For batch garanterer vi kun minimums-b\u00e5ndbredden, men begr\u00e6nser ikke maksimum (formlen <em>alloc: lan=[10Mbps,*)<\/em> ) I denne proces skal trafikken fra prod have prioritet over batch-opgaver.<br \/>\nHer har Docker ikke nogen primitive v\u00e6rkt\u00f8jer, som vi kan bruge. Men vi f\u00e5r hj\u00e6lp fra <noindex><a rel=\"nofollow\" href=\"http:\/\/lartc.org\/\">Linux Traffic Control<\/a><\/noindex>. Vi kunne opn\u00e5 det \u00f8nskede resultat ved hj\u00e6lp af disciplinen <noindex><a rel=\"nofollow\" href=\"http:\/\/linux-ip.net\/articles\/hfsc.en\/\">Hierarchical Fair Service Curve<\/a><\/noindex>. Ved hj\u00e6lp af dette skelner vi mellem to klasser af trafik: h\u00f8jprioriteret prod og lavprioriteret batch\/idle. I sidste ende ser konfigurationen for udg\u00e5ende trafik s\u00e5dan ud:<\/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-niveau 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>her 1:0 \u2014 \u00abroot qdisc\u00bb for hsfc discipline; 1:1 \u2014 child class hsfc with a total bandwidth limit of 8 Gbit\/s, under which child classes of all containers are placed; 1:2 \u2014 child class hsfc common for all batch and idle tasks with a \u00abdynamic\u00bb limit, which will be discussed below. The other child classes hsfc are dedicated classes for currently running prod-containers with limits corresponding to their manifests \u2014 450 and 400 Mbit\/s. Each class hsfc is assigned a qdisc queue fq or fq_codel, depending on the version of the Linux kernel, to avoid packet loss during traffic spikes. <\/p>\n<p><\/p>\n<p>Typisk bruges tc disciplinerne til at prioritere kun udg\u00e5ende trafik. Men vi \u00f8nsker ogs\u00e5 at prioritere indg\u00e5ende trafik \u2014 en eller anden batch-opgave kan nemt tage hele den indg\u00e5ende kanal ved at modtage f.eks. et stort datapakke til map&amp;reduce. Til dette bruger vi modulet <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/350023\/tc-ingress-policing-and-ifb-mirroring\">ifb<\/a><\/noindex>, som skaber et virtuelt interface ifbX for hver netv\u00e6rksinterface og omdirigerer indg\u00e5ende trafik fra interfacet til udg\u00e5ende p\u00e5 ifbX. Derefter fungerer alle de samme discipliner for kontrol af udg\u00e5ende trafik for ifbX, hvor konfigurationen af hsfc vil v\u00e6re meget lig:<\/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-niveau 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 eksperimenterne fandt vi ud af, at hsfc giver de bedste resultater, n\u00e5r klassen 1:2 af ikke-prioriteret batch\/idle trafik er begr\u00e6nset p\u00e5 minion-maskinerne til maksimalt en vis ledig b\u00e5ndbredde. Ellers p\u00e5virker den ikke-prioriterede trafik for meget latens af prod-opgaverne. Den aktuelle st\u00f8rrelse af den ledige b\u00e5ndbredde fastl\u00e6gges af miniond hver sekund ved at m\u00e5le det gennemsnitlige trafikforbrug for alle prod-opgaver p\u00e5 den p\u00e5g\u00e6ldende minion <img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/9d6f38110d3b1693afe222b01430b9bb.jpg\" style=\"display:block;margin: 0 auto;\" \/> og tr\u00e6kke det fra netv\u00e6rksinterfacets b\u00e5ndbredde <img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/d5608ec4c58e44b8571ab0b1d0cc7701.jpg\" style=\"display:block;margin: 0 auto;\" \/> med et lille sikkerhedsniveau, dvs.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/fb01347c2224bd5bbd82169861eeb7e4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>B\u00e5ndbredderne defineres for indg\u00e5ende og udg\u00e5ende trafik uafh\u00e6ngigt. Og i henhold til de nye v\u00e6rdier rekonfigurerer miniond gr\u00e6nsen for den ikke-prioriterede klasse 1:2.<\/p>\n<p><\/p>\n<p>Dermed har vi implementeret alle tre isolationsklasser: prod, batch og idle. Disse klasser har stor indflydelse p\u00e5 opgaveudf\u00f8relsens karakteristika. Derfor besluttede vi at placere dette kendetegn \u00f8verst i hierarkiet, s\u00e5 det straks er klart, hvad vi har med at g\u00f8re ved at se p\u00e5 navnet p\u00e5 den hierarkiske k\u00f8: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/34dc89c461db711b19a0f4eccc50efce.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Alle vores kendte <strong>web<\/strong> og <strong>music<\/strong> frontende placeres dern\u00e6st i hierarkiet under prod. For eksempel lad os placere tjenesten <strong>music catalog under batch.<\/strong>, som periodisk laver et katalog over spor fra samlingen af mp3-filer, der er blevet uploaded til \"Odnoklassniki\". Et eksempel p\u00e5 en service under idle kan v\u00e6re <strong>music transformer<\/strong>, der normaliserer lydniveauet p\u00e5 musikken.<\/p>\n<p><\/p>\n<p>Ved igen at fjerne un\u00f8dvendige linjer kan vi skrive navnene p\u00e5 vores tjenester mere fladt ved at tilf\u00f8je klassen for opgaveisolering til slutningen af det fulde navn p\u00e5 tjenesten: <strong>web.front.prod<\/strong>, <strong>catalog.music.batch<\/strong>, <strong>transformer.music.idle<\/strong>.<\/p>\n<p><\/p>\n<p>Og nu, n\u00e5r vi ser p\u00e5 navnet p\u00e5 tjenesten, forst\u00e5r vi ikke kun, hvilken funktion den udf\u00f8rer, men ogs\u00e5 dens klasse for isolering, og dermed dens kritikalitet osv.<\/p>\n<p><\/p>\n<p>Alt er fantastisk, men der er en bitter sandhed. Det er umuligt at fuldst\u00e6ndig isolere opgaver, der k\u00f8rer p\u00e5 samme maskine.<\/p>\n<p><\/p>\n<p>Hvad vi har opn\u00e5et: hvis batch'en forbruger intensivt <strong>kun<\/strong> processorressourcer, g\u00f8r Linux' indbyggede CPU-planl\u00e6gger et fremragende stykke arbejde, og der er n\u00e6sten ingen indflydelse p\u00e5 prod-opgaven. Men hvis denne batch-opgave begynder at arbejde aktivt med hukommelsen, s\u00e5 viser den gensidige p\u00e5virkning sig allerede. Dette sker, fordi processorens caches for prod-opgaven 'udt\u00f8mmes' - i sidste ende vokser m\u00e5linger i cachen, og processoren behandler prod-opgaven langsommere. En s\u00e5dan batch-opgave kan \u00f8ge forsinkelsen af vores typiske prod-container med 10 %.<\/p>\n<p><\/p>\n<p>At isolere trafik er endnu sv\u00e6rere, fordi moderne netv\u00e6rkskort har en intern pakke-k\u00f8. Hvis en pakke fra batch-opgaven kom f\u00f8rst ind, vil den ogs\u00e5 blive sendt f\u00f8rst gennem kabelledningen, og der er ikke meget, man kan g\u00f8re ved det.<\/p>\n<p><\/p>\n<p>Derudover har vi kun form\u00e5et at l\u00f8se opgaven med prioritering af TCP-trafik indtil videre: til UDP virker tilgangen med hsfc ikke. Og selv i tilf\u00e6lde af TCP-trafik, hvis batch-opgaven genererer meget trafik, resulterer det ogs\u00e5 i en \u00f8gning af forsinkelse for prod-opgaven p\u00e5 cirka 10 %.<\/p>\n<p><\/p>\n<h2 id=\"otkazoustoychivost\">Fejltolerance<\/h2>\n<p><\/p>\n<p>Et af m\u00e5lene ved udviklingen af one-cloud var at forbedre redundans i Odnoklassniki. Derfor vil jeg gerne se n\u00e6rmere p\u00e5 mulige fejlscenarier og nedbrud. Lad os starte med et enkelt scenarie \u2014 med et containerfejl. <\/p>\n<p><\/p>\n<p>En container kan fejle p\u00e5 flere m\u00e5der. Det kan v\u00e6re et eksperiment, en fejl eller en fejl i manifestet, der g\u00f8r, at en produkt-opgave begynder at forbruge flere ressourcer, end der er angivet i manifestet. Vi havde et tilf\u00e6lde, hvor en udvikler implementerede en kompleks algoritme, tilbagerullede den mange gange og blev s\u00e5 forvirret, at opgaven endte med fornemt at k\u00f8re i loop. Og da produkt-opgaven har h\u00f8jere prioritet end alle andre p\u00e5 de samme noder, begyndte den at forbruge alle tilg\u00e6ngelige CPU-ressourcer. I denne situation blev vi reddet af isolation, n\u00e6rmere bestemt en kvote p\u00e5 CPU-tid. Hvis der er tildelt en kvote til opgaven, vil den ikke forbruge mere. Derfor bem\u00e6rkede batch- og andre produkt-opgaver, der k\u00f8rte p\u00e5 den samme maskine, ikke noget. <\/p>\n<p><\/p>\n<p>En anden potentiel udfordring er containerens nedbrud. Her hj\u00e6lper genstartspolitikkerne os, som alle kender, og Docker h\u00e5ndterer det rigtig godt. N\u00e6sten alle produkt-opgaver har en genstartspolitik, der altid er aktiv. Af og til bruger vi on_failure til batch-opgaver eller til fejlfinding af produkt-containere.<\/p>\n<p><\/p>\n<p>Hvad kan man g\u00f8re, n\u00e5r en hel node er utilg\u00e6ngelig?<\/p>\n<p><\/p>\n<p>\u00c5benlyst kan man k\u00f8re containeren p\u00e5 en anden maskine. Det mest interessante her er, hvad der sker med IP-adressen (adresserne) tildelt til containeren. <\/p>\n<p><\/p>\n<p>Vi kan tildele containere de samme IP-adresser som maskinerne, hvor disse containere k\u00f8rer. S\u00e5 n\u00e5r containeren k\u00f8res p\u00e5 en anden maskine, \u00e6ndres dens IP-adresse, og alle klienter skal forst\u00e5, at containeren er flyttet, og nu skal der tilg\u00e5s en anden adresse, hvilket kr\u00e6ver en separat Service Discovery-tjeneste. <\/p>\n<p><\/p>\n<p>Service Discovery er praktisk. Der findes mange l\u00f8sninger p\u00e5 markedet i forskellige grader af fejltilg\u00e6ngelighed til organisering af tjenesteregistre. I s\u00e5danne l\u00f8sninger implementeres der ofte logik til belastningsbalancering, lagring af ekstra konfiguration i form af KV-lager osv.<br \/>\nMen vi \u00f8nsker at undg\u00e5 at implementere et separat register, da det ville betyde at introducere et kritisk system, der anvendes af alle tjenester i produktionen. Det betyder, at det er et potentielt fejlpunkt, og man skal v\u00e6lge eller udvikle en meget fejltolerant l\u00f8sning, hvilket \u00e5benbart er meget kompliceret, langvarigt og kostbart. <\/p>\n<p><\/p>\n<p>Og endnu en stor ulempe: for at vores gamle infrastruktur kunne fungere med den nye, skulle vi genprogrammere alle opgaver til brug af et eller andet Service Discovery-system. Der er MEGET arbejde, og nogle steder er det umuligt, n\u00e5r det drejer sig om lavniveau enheder, der arbejder p\u00e5 niveau med OS-kernen eller direkte med hardwaren. Implementeringen af denne funktionalitet ved hj\u00e6lp af etablerede l\u00f8sningsm\u00f8nstre, som f.eks. <noindex><a rel=\"nofollow\" href=\"https:\/\/linkerd.io\">side-car<\/a><\/noindex> ville betyde, at der nogle steder kom ekstra belastning, og nogle steder \u2014 en komplicering af driften og ekstra fejlscenarier. Vi \u00f8nskede ikke at komplicere det, derfor besluttede vi at g\u00f8re brugen af Service Discovery valgfri. <\/p>\n<p><\/p>\n<p>I one-cloud f\u00f8lger IP'en med containeren, dvs. hver opgaveinstans har sin egen IP-adresse. Denne adresse er \"statisk\": den tildeles hver instans i det \u00f8jeblik, tjenesten sendes til skyen. Hvis tjenesten i l\u00f8bet af sin livscyklus har haft et forskelligt antal instanser, vil der i sidste ende v\u00e6re tildelt s\u00e5 mange IP-adresser, som der har v\u00e6ret instanser.<\/p>\n<p><\/p>\n<p>Senere \u00e6ndres disse adresser ikke: de tildeles \u00e9n gang og forbliver tilg\u00e6ngelige i hele tjenestens liv i produktionen. IP-adresserne f\u00f8lger containerne over netv\u00e6rket. Hvis en container flyttes til en anden minion, vil adressen ogs\u00e5 f\u00f8lge med. <\/p>\n<p><\/p>\n<p>Dermed \u00e6ndres sammenkoblingen af tjenestens navn med listen over dens IP-adresser meget sj\u00e6ldent. Hvis vi ser p\u00e5 navne p\u00e5 tjenesteinstanser, som vi n\u00e6vnte i begyndelsen af artiklen (<strong>1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, \u2026<\/strong>), kan vi se, at de ligner FQDN, der bruges i DNS. Det g\u00f8r de, for at vise navnene p\u00e5 serviceinstanser i deres IP-adresser, bruger vi DNS-protokollen. Desuden returnerer denne DNS alle reserverede IP-adresser til alle containere - b\u00e5de dem, der k\u00f8rer, og dem, der er stoppet (lad os sige, at tre replikaer bruges, og vi har fem adresser reserveret - alle fem vil blive returneret). Kunderne, der f\u00e5r denne information, vil fors\u00f8ge at oprette forbindelse til alle fem replikaer - og p\u00e5 den m\u00e5de bestemme, hvilke der fungerer. Denne metode til at bestemme tilg\u00e6ngeligheden er betydeligt mere p\u00e5lidelig, da den ikke involverer hverken DNS eller Service Discovery, hvilket betyder, at der ikke er problemer med at sikre opdateringsinformationen og systemernes fejltolerance. Desuden kan vi i kritiske tjenester, der er afg\u00f8rende for hele portalens drift, end ikke bruge DNS, men blot angive IP-adresserne i konfigurationen.<\/p>\n<p><\/p>\n<p>Implementeringen af en s\u00e5dan overf\u00f8rsel af IP adresser bag containere kan v\u00e6re ikke-triviel - og vi vil stoppe ved, hvordan det fungerer, i det n\u00e6ste eksempel:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/faf99c2609a57daa1bdc193cb0f4cb31.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Antag, at one-cloud master beder minion M1 om at starte <strong>1.ok-web.group1.web.front.prod<\/strong> med adressen 1.1.1.1. P\u00e5 minionen k\u00f8rer <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Bird_Internet_routing_daemon\">BIRD<\/a><\/noindex>, som annoncerer denne adresse til s\u00e6rlige servere <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Route_reflector\">route reflector<\/a><\/noindex>. Disse har en BGP-session med det netv\u00e6rksudstyr, hvor ruten til adressen 1.1.1.1 bliver transmitteret til M1. M1 router pakker ind i containeren ved hj\u00e6lp af Linux. Der er tre route reflectorer, da dette er en meget kritisk del af one-cloud infrastrukturen - uden dem vil netv\u00e6rket i one-cloud ikke fungere. Vi placerer dem i forskellige racks, s\u00e5 vidt muligt beliggende i forskellige haller i datacentret, for at minimere risikoen for samtidig svigt af alle tre.<\/p>\n<p><\/p>\n<p>Lad os nu antage, at forbindelsen mellem one-cloud master og minion M1 er brudt. One-cloud master vil nu handle ud fra antagelsen om, at M1 er helt fejlet. Det vil sige, at det vil give ordre til minion M2 om at starte <strong>web.group1.web.front.prod<\/strong> med den samme IP-adresse 1.1.1.1. Nu har vi to konflikerende ruter i netv\u00e6rket for 1.1.1.1: p\u00e5 M1 og M2. For at l\u00f8se s\u00e5danne konflikter bruger vi Multi Exit Discriminator, som angives i BGP-annonceringen. Dette tal angiver v\u00e6gten af den annoncerede rute. Ruten med den laveste MED-v\u00e6rdi v\u00e6lges blandt de konflikerende. Master one-cloud underst\u00f8tter MED som en integreret del af container-IP-adresser. Ved f\u00f8rste gang udstede adressen med en relativt h\u00f8j MED = 1 000 000. I situationen med en s\u00e5dan n\u00f8d-overf\u00f8rsel af containeren reducerer masteren MED, og M2 vil allerede modtage en kommando om at annoncere adressen 1.1.1.1 med MED = 999 999. Instansen, der k\u00f8rer p\u00e5 M1, forbliver uden forbindelse, og dens videre sk\u00e6bne interesserer os ikke meget, indtil forbindelsen til masteren er genoprettet, hvorefter den vil blive stoppet som en gammel dublet.<\/p>\n<p><\/p>\n<h2 id=\"avarii\">N\u00f8dsituationer<\/h2>\n<p><\/p>\n<p>Alle datacenterstyringssystemer h\u00e5ndterer normalt sm\u00e5 fejl. Udfald af en container er praktisk taget normen overalt.<\/p>\n<p><\/p>\n<p>Lad os se p\u00e5, hvordan vi h\u00e5ndterer en n\u00f8dsituation, for eksempel str\u00f8mafbrydelse i et eller flere datacenterlokaler.<\/p>\n<p><\/p>\n<p>Hvad betyder en n\u00f8dsituation for datacenterstyringssystemet? For det f\u00f8rste betyder det en massiv samtidig nedbrud af mange maskiner, og systemet skal samtidig migrere mange containerer. Men hvis n\u00f8dsituationen er meget stor, kan det ske, at alle opgaver ikke kan flyttes til andre minions, fordi datacenterets kapacitet falder under 100 % belastning. <\/p>\n<p><\/p>\n<p>Ofte ledsages n\u00f8dsituationer af et nedbrud af styringslaget. Dette kan ske p\u00e5 grund af svigt af dets udstyr, men oftere fordi n\u00f8dsituationer ikke testes, og styringslaget selv falder fra den \u00f8gede belastning. <\/p>\n<p><\/p>\n<p>Hvad kan der g\u00f8res ved alt dette?<\/p>\n<p><\/p>\n<p>Massiv migrering betyder, at der opst\u00e5r et stort antal handlinger, migreringer og placeringer i infrastrukturen. Hver migrering kan tage noget tid, der er n\u00f8dvendigt for at levere og udpakke containerbilleder til minions, starte og initialisere containerne osv. Derfor er det \u00f8nskeligt, at de vigtigste opgaver startes f\u00f8r de mindre vigtige.<\/p>\n<p><\/p>\n<p>Lad os igen se p\u00e5 den velkendte servicehierarki og fors\u00f8ge at afg\u00f8re, hvilke opgaver vi \u00f8nsker at starte f\u00f8rst.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/2e827271adb8d3ff3d385e53553aaacf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Selvf\u00f8lgelig, det er de processer, der direkte deltager i behandlingen af brugernes foresp\u00f8rgsler, dvs. prod. Vi angiver dette med hj\u00e6lp af <strong>placeringsprioritet<\/strong> \u2014 et tal, der kan tildeles til k\u00f8en. Hvis en k\u00f8 har en h\u00f8jere prioritet, placeres dens tjenester f\u00f8rst.<\/p>\n<p><\/p>\n<p>P\u00e5 prod tildeler vi h\u00f8jere prioriteter, 0; p\u00e5 batch \u2014 lidt lavere, 100; p\u00e5 idle \u2014 endnu lavere, 200. Prioriteter anvendes hierarkisk. Alle opgaver lavere i hierarkiet vil have den tilsvarende prioritet. Hvis vi \u00f8nsker, at caches inde i prod starter f\u00f8r frontenderne, tildeler vi prioriteter til cache = 0 og front underk\u00f8er = 1. Hvis vi derimod vil have, at hovedportalen starter f\u00f8rst blandt frontenderne, og musikfronten derefter, kan vi tildele den sidste lavere prioritet \u2014 10.<\/p>\n<p><\/p>\n<p>Det n\u00e6ste problem er mangel p\u00e5 ressourcer. S\u00e5 vi har haft mange maskiner, hele datacenterne er svigtet, og vi har startet s\u00e5 mange tjenester, at der nu ikke er ressourcer nok til alle. Vi skal beslutte, hvilke opgaver vi skal ofre, s\u00e5 de vigtigste kritiske tjenester kan fungere. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"One-cloud \u2014 datacenter-niveau OS i Odnoklassniki\" src=\"\/wp-content\/uploads\/2020\/06\/1b1ad3da16df6677dd0ba4b038cdd7d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I mods\u00e6tning til placeringsprioriteten kan vi ikke uforsigtigt ofre alle batch-opgaver, nogle af dem er vigtige for portalens drift. Derfor har vi s\u00e6rskilt \u0432\u044b\u0434\u0435\u043b\u0438\u043b\u0438 <strong>udskydningsprioritet<\/strong> opgaver. Ved placering kan en opgave med h\u00f8jere prioritet udskyde, dvs. stoppe en opgave med lavere prioritet, hvis der ikke l\u00e6ngere er ledige minioner. Samtidig vil en opgave med lavere prioritet sandsynligvis forblive uplaceret, dvs. der vil ikke v\u00e6re en passende minion med tilstr\u00e6kkelige frie ressourcer til den.<\/p>\n<p><\/p>\n<p>I vores hierarki er det meget enkelt at angive s\u00e5dan en udskydningsprioritet, s\u00e5 prod- og batch-opgaver udskyder eller stopper idle-opgaver, men ikke hinanden, ved at angive en prioritet for idle, der er lig med 200. Ligesom i tilf\u00e6lde af placeringsprioritet kan vi bruge vores hierarki til at beskrive mere komplekse regler. For eksempel vil vi angive, at musikfunktionen ofres, hvis vi mangler ressourcer til den prim\u00e6re webportal, ved at s\u00e6tte en lavere prioritet for de relevante noder: 10.<\/p>\n<p><\/p>\n<h2 id=\"avarii-dc-celikom\">Hele DC-nedbrud<\/h2>\n<p><\/p>\n<p>Hvorfor kan hele datacenteret svigte? Naturkatastrofer. Der var et godt indl\u00e6g om, hvordan <noindex><a rel=\"nofollow\" href=\"https:\/\/habrahabr.ru\/company\/dataline\/blog\/333578\/\">orkanen p\u00e5virkede datacenterets drift<\/a><\/noindex>. Man kan betragte hjeml\u00f8se som en trussel, da de en gang har sat ild til fiberoptikken i en kloak, og datacentret mistede helt forbindelsen til de \u00f8vrige steder. \u00c5rsagen til nedbruddet kan ogs\u00e5 v\u00e6re menneskelig fejl: operat\u00f8ren kan give en kommando, der f\u00e5r hele datacentret til at falde ned. Dette kan ske p\u00e5 grund af en stor fejl. Generelt set falder datacentre \u2014 det er ikke ualmindeligt. Vi oplever dette en gang hver anden m\u00e5ned. <\/p>\n<p><\/p>\n<p>Og her er hvad vi g\u00f8r, s\u00e5 ingen #oklevlive poster p\u00e5 Twitter.<\/p>\n<p><\/p>\n<p>Den f\u00f8rste strategi er isolation. Hver instans af one-cloud er isoleret og kan kun styre maskinerne i \u00e9t datacenter. Det vil sige, at tabet af cloud-l\u00f8sningen p\u00e5 grund af fejl eller en forkert kommando fra operat\u00f8ren kun p\u00e5virker \u00e9t datacenter. Vi er forberedt p\u00e5 dette: der er en reserven politik, hvor replikaer af applikationer og data placeres i alle datacentre. Vi bruger fejlresistente databaser og tester periodisk for fejl.<br \/>\nDa vi i dag har fire datacentre, har vi ogs\u00e5 fire separate, helt isolerede instanser af one-cloud.<\/p>\n<p><\/p>\n<p>Denne tilgang beskytter ikke kun mod fysiske fejl, men kan ogs\u00e5 beskytte mod operat\u00f8rfejl.<\/p>\n<p><\/p>\n<p>Hvad mere kan der g\u00f8res ved det menneskelige faktor? N\u00e5r operat\u00f8ren giver cloud'en en m\u00e6rkelig eller potentielt farlig kommando, kan der pludselig blive bedt om at udf\u00f8re en lille opgave for at teste, hvor godt han har t\u00e6nkt over det. For eksempel, hvis det er en massiv nedlukning af mange replikaer eller blot en m\u00e6rkelig kommando \u2014 at reducere antallet af replikaer eller \u00e6ndre navnet p\u00e5 billedet, ikke kun versionsnummeret i den nye 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 datacenter-niveau 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\">Resum\u00e9<\/h2>\n<p><\/p>\n<p>Kendetegn ved one-cloud: <\/p>\n<p><\/p>\n<ul>\n<li><strong>Hierarkisk og visuelt overskuelig navngivningsskema for tjenester og containere<\/strong>, som g\u00f8r det meget hurtigt at finde ud af, hvad det er for en opgave, hvad den relaterer sig til, hvordan den fungerer, og hvem der er ansvarlig for den. <\/li>\n<li>Vi anvender vores <strong>teknik til at kombinere prod- og batch-<\/strong>opgaver p\u00e5 minions for at \u00f8ge effektiviteten af maskinens deling. I stedet for cpuset bruger vi CPU-quotaer, shares, CPU-planl\u00e6gningspolitikker og Linux QoS.<\/li>\n<li>Vi har endnu ikke form\u00e5et at isolere containere, der k\u00f8rer p\u00e5 samme maskine, fuldst\u00e6ndigt, men deres indbyrdes indflydelse forbliver p\u00e5 op til 20%.<\/li>\n<li>Organisering af tjenester i et hierarki hj\u00e6lper ved automatisk afl\u00f8sning af n\u00f8dsituationer gennem <strong>placering og udrykningsprioriteter.<\/strong>.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"chavo\">FAQ<\/h2>\n<p><\/p>\n<p>Hvorfor vi ikke valgte en f\u00e6rdig l\u00f8sning.<\/p>\n<p><\/p>\n<ul>\n<li>Forskellige klasser af opgaveisolering kr\u00e6ver forskellige logiktyper ved placering p\u00e5 minions. Hvis produktionsopgaver kan placeres med simpel ressource-reservering, skal batch- og idle-opgaver placeres ved at overv\u00e5ge den faktiske ressourceudnyttelse p\u00e5 minion-maskinerne. <\/li>\n<li>N\u00f8dvendigheden af at tage h\u00f8jde for de ressourcer, som opgaverne forbruger, s\u00e5som: \n<ul>\n<li>netv\u00e6rksb\u00e5ndbredde;<\/li>\n<li>typer og \"spindler\" af diske.<\/li>\n<\/ul>\n<\/li>\n<li>N\u00f8dvendigheden af at angive prioriteter for tjenester ved n\u00f8dsituationer, rettigheder og kvoter for teams p\u00e5 ressourcer, hvilket l\u00f8ses ved hj\u00e6lp af hierarkiske k\u00f8er i one-cloud.<\/li>\n<li>N\u00f8dvendigheden af at have menneskelige navne til containere for at reducere reaktionstiden p\u00e5 n\u00f8dsituationer og h\u00e6ndelser.<\/li>\n<li>Umuligheden af samtidig implementering af Service Discovery; behovet for at co-existere i lang tid med opgaver, der er placeret p\u00e5 fysiske v\u00e6rter \u2014 hvilket l\u00f8ses med \"statiske\" IP-adresser der f\u00f8lger containere, og som f\u00f8lge heraf nedskrevne unikke integrationer med det store netv\u00e6rksinfrastruktur.<\/li>\n<\/ul>\n<p><\/p>\n<p>Alle disse funktioner ville kr\u00e6ve betydelige \u00e6ndringer af eksisterende l\u00f8sninger for at tilpasse dem til os, og efter at have vurderet arbejdsbyrden inds\u00e5 vi, at vi kunne udvikle vores egen l\u00f8sning med omtrent de samme arbejdsomkostninger. Men vores l\u00f8sning vil v\u00e6re betydeligt lettere at vedligeholde og udvikle \u2014 det indeholder ingen un\u00f8dvendige abstraktioner, der underst\u00f8tter un\u00f8dvendig funktionalitet for os. <\/p>\n<p><\/p>\n<p>Tak til dem, der l\u00e6ser de sidste linjer \u2014 tak for t\u00e5lmodighed og opm\u00e6rksomhed!<\/p>\n<p>Kilde: <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.3 - 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\/da\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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 datacenterniveau OS i Odnoklassniki | ProHoster","description":"Aloha, folkens!","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/one-cloud-os-urovnya-data-czentra-v-odnoklassnikah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/84114","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=84114"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/84114\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/84115"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=84114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=84114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=84114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}