One-pilvi - datakeskustason käyttöjärjestelmä Odnoklassnikissa

Aloha, ihmiset! Nimeni on Oleg Anastasjev, työskentelen Odnoklassnikissa Platform-tiimissä. Ja minun lisäksi Odnoklassnikissa työskentelee paljon laitteistoa. Meillä on neljä datakeskusta, joissa on noin 500 telinettä ja yli 8 tuhatta palvelinta. Jossain vaiheessa ymmärsimme, että uuden hallintajärjestelmän käyttöönotto mahdollistaa laitteiden tehokkaamman kuormituksen, helpottaa pääsynhallintaa, automatisoi laskentaresurssien (uudelleen)jakoa, nopeuttaa uusien palveluiden käynnistämistä ja nopeuttaa vastausta suuriin onnettomuuksiin.

Mitä siitä tuli?

Minun ja joukon laitteiston lisäksi tämän laitteiston parissa työskentelee myös ihmisiä: insinöörejä, jotka sijaitsevat suoraan datakeskuksissa; verkottajat, jotka määrittävät verkkoohjelmiston; ylläpitäjät tai SRE:t, jotka tarjoavat infrastruktuurin joustavuutta; ja kehitystiimit, joista jokainen on vastuussa osasta portaalin toimintoja. Niiden luoma ohjelmisto toimii jotakuinkin näin:

Käyttäjäpyynnöt vastaanotetaan molemmilla pääportaalin etupuolella www.ok.ru, ja muilla, esimerkiksi musiikin API-rintamilla. Liiketoimintalogiikan käsittelemiseksi he kutsuvat sovelluspalvelinta, joka pyyntöä käsitellessään kutsuu tarvittavat erikoistuneet mikropalvelut - yksikaavio (sosiaalisten yhteyksien kaavio), käyttäjävälimuisti (käyttäjäprofiilien välimuisti) jne.

Jokainen näistä palveluista on käytössä useilla koneilla, ja jokaisella on vastuulliset kehittäjät, jotka vastaavat moduulien toimivuudesta, toiminnasta ja teknologisesta kehityksestä. Kaikki nämä palvelut toimivat laitteistopalvelimilla, ja viime aikoihin asti käynnistimme täsmälleen yhden tehtävän palvelinta kohden, eli se oli erikoistunut tiettyyn tehtävään.

Miksi niin? Tällä lähestymistavalla oli useita etuja:

• Helpottunut massahallinta. Oletetaan, että tehtävä vaatii joitain kirjastoja, joitain asetuksia. Ja sitten palvelin määritetään täsmälleen yhteen tiettyyn ryhmään, tämän ryhmän cfengine-käytäntö kuvataan (tai se on jo kuvattu), ja tämä kokoonpano otetaan keskitetysti ja automaattisesti käyttöön kaikille tämän ryhmän palvelimille.
• Yksinkertaistettu diagnostiikka. Oletetaan, että katsot keskusprosessorin lisääntynyttä kuormitusta ja ymmärrät, että tämä kuormitus voi olla vain tässä laitteistoprosessorissa suoritettava tehtävä. Syyllisen etsiminen päättyy hyvin nopeasti.
• Yksinkertaistettu seurantaa. Jos palvelimessa on jotain vikaa, monitori ilmoittaa siitä ja tiedät tarkalleen, kuka on syyllinen.

Useista replikoista koostuvalle palvelulle on varattu useita palvelimia - yksi kullekin. Sitten palvelun laskentaresurssi allokoidaan hyvin yksinkertaisesti: kuinka monta palvelimia palvelulla on, kuinka paljon resursseja se voi kuluttaa. "Helppo" ei tarkoita, että se on helppokäyttöinen, vaan siinä mielessä, että resurssien allokointi tapahtuu manuaalisesti.

Tämä lähestymistapa antoi meille myös mahdollisuuden erikoistuneet rautakokoonpanot tällä palvelimella suoritettavaa tehtävää varten. Jos tehtävässä on suuria määriä dataa, käytämme 4U-palvelinta, jossa on 38 levyn runko. Jos tehtävä on puhtaasti laskennallinen, voimme ostaa halvemman 1U-palvelimen. Tämä on laskennallisesti tehokasta. Muun muassa tämä lähestymistapa antaa meille mahdollisuuden käyttää neljä kertaa vähemmän koneita, joiden kuormitus on verrattavissa yhteen ystävälliseen sosiaaliseen verkostoon.

Tällaisen laskentaresurssien käytön tehokkuuden pitäisi varmistaa myös taloudellinen tehokkuus, jos lähdetään siitä, että kallein on palvelimet. Pitkään laitteisto oli kallein, ja panostimme paljon laitteiston hinnan alentamiseen ja kehitimme vikasietoalgoritmeja vähentääksemme laitteiston luotettavuusvaatimuksia. Ja tänään olemme saavuttaneet vaiheen, jossa palvelimen hinta on lakannut olemasta ratkaiseva. Jos et ota huomioon viimeisintä eksotiikkaa, telineessä olevien palvelimien erityisellä kokoonpanolla ei ole väliä. Nyt meillä on toinen ongelma - palvelinkeskuksen palvelimen käyttämän tilan hinta, eli telineen tilan hinta.

Ymmärsimme, että näin oli, päätimme laskea, kuinka tehokkaasti käytämme telineitä.
Otimme tehokkaimman palvelimen hinnan taloudellisesti perusteltujen joukosta, laskemme kuinka monta tällaista palvelinta voisimme sijoittaa räkkeihin, kuinka monta tehtävää ajettaisiin niillä vanhan mallin "yksi palvelin = yksi tehtävä" perusteella ja kuinka paljon sellaisia. tehtävissä voisi hyödyntää laitteita. He laskivat ja vuodattivat kyyneleitä. Kävi ilmi, että tehokkuutemme telineiden käytössä on noin 11 %. Johtopäätös on ilmeinen: meidän on tehostettava datakeskusten käyttöä. Vaikuttaa siltä, ​​​​että ratkaisu on ilmeinen: sinun on suoritettava useita tehtäviä yhdellä palvelimella kerralla. Mutta tästä vaikeudet alkavat.

Massakonfiguroinnista tulee dramaattisesti monimutkaisempi - nyt on mahdotonta määrittää yhtäkään ryhmää palvelimelle. Nyt loppujen lopuksi useita eri komentojen tehtäviä voidaan käynnistää yhdellä palvelimella. Lisäksi kokoonpano voi olla ristiriitainen eri sovelluksissa. Diagnoosista tulee myös monimutkaisempi: jos näet lisääntyneen suorittimen tai levyn kulutuksen palvelimella, et tiedä, mikä tehtävä aiheuttaa ongelmia.

Mutta tärkeintä on, että samalla koneella suoritettavien tehtävien välillä ei ole eristystä. Tässä on esimerkiksi kaavio palvelintehtävän keskimääräisestä vasteajasta ennen ja sen jälkeen, kun toinen laskentasovellus käynnistettiin samalla palvelimella, ei millään tavalla liity ensimmäiseen - päätehtävän vasteaika on kasvanut merkittävästi.

Ilmeisesti sinun on suoritettava tehtäviä joko säilöissä tai virtuaalikoneissa. Koska lähes kaikki tehtävämme toimivat yhden käyttöjärjestelmän (Linux) alaisuudessa tai on mukautettu sitä varten, meidän ei tarvitse tukea monia eri käyttöjärjestelmiä. Näin ollen virtualisointia ei tarvita, vaan se on ylimääräisen lisäkulun vuoksi vähemmän tehokasta kuin kontissa.

Säilöjen toteutuksena tehtävien suorittamiseen suoraan palvelimilla Docker on hyvä ehdokas: tiedostojärjestelmän kuvat ratkaisevat hyvin ristiriitaisten kokoonpanojen ongelmat. Se, että kuvat voivat koostua useista kerroksista, mahdollistaa sen, että voimme merkittävästi vähentää niiden käyttöönottamiseksi infrastruktuurissa tarvittavan datan määrää jakamalla yhteiset osat erillisiin peruskerroksiin. Silloin perus (ja laajimmat) kerrokset välimuistiin tallennetaan melko nopeasti koko infrastruktuurissa, ja monien erityyppisten sovellusten ja versioiden toimittamiseksi tarvitsee siirtää vain pieniä kerroksia.

Lisäksi Dockerin valmis rekisteri ja kuvakoodaus antavat meille valmiita primitiivejä versiointiin ja koodin toimittamiseen tuotantoon.

Docker, kuten mikä tahansa muu vastaava tekniikka, tarjoaa meille jonkin tason kontin eristyksen pakkauksesta. Esimerkiksi muistin eristäminen - jokaiselle säiliölle annetaan koneen muistin käytölle raja, jonka yli se ei kuluta. Voit myös eristää säiliöitä suorittimen käytön perusteella. Meille tavallinen eristys ei kuitenkaan riittänyt. Mutta siitä lisää alla.

Säilöjen suora ajaminen palvelimilla on vain osa ongelmaa. Toinen osa liittyy konttien isännöintiin palvelimilla. Sinun on ymmärrettävä, mikä kontti voidaan sijoittaa mille palvelimelle. Tämä ei ole niin helppo tehtävä, koska kontit on sijoitettava palvelimille mahdollisimman tiheästi niiden nopeutta hidastamatta. Tällainen sijoittaminen voi olla vaikeaa myös vikasietoisuuden kannalta. Usein haluamme sijoittaa saman palvelun replikoita eri telineisiin tai jopa palvelinkeskuksen eri huoneisiin, jotta hyllyn tai huoneen rikkoutuessa emme heti menetä kaikkia palvelukopioita.

Konttien manuaalinen jakaminen ei ole vaihtoehto, kun sinulla on 8 tuhatta palvelinta ja 8-16 tuhatta konttia.

Lisäksi halusimme antaa kehittäjille enemmän itsenäisyyttä resurssien allokoinnissa, jotta he voisivat isännöidä palveluitaan tuotannossa itse ilman järjestelmänvalvojan apua. Samalla halusimme säilyttää hallinnan, jotta jokin pieni palvelu ei kuluttaisi kaikkia palvelinkeskuksiemme resursseja.

Ilmeisesti tarvitsemme ohjauskerroksen, joka tekisi tämän automaattisesti.

Joten pääsimme yksinkertaiseen ja ymmärrettävään kuvaan, jota kaikki arkkitehdit rakastavat: kolme neliötä.

one-cloud masters on pilviorkestraatiosta vastaava vikasietoklusteri. Kehittäjä lähettää pääkäyttäjälle manifestin, joka sisältää kaikki palvelun isännöimiseen tarvittavat tiedot. Sen perusteella isäntä antaa komentoja valituille kätyreille (koneille, jotka on suunniteltu ajamaan kontteja). Kätyreillä on agenttimme, joka vastaanottaa komennon, antaa sen Dockerille ja Docker määrittää Linux-ytimen käynnistämään vastaavan säilön. Komentojen suorittamisen lisäksi agentti raportoi jatkuvasti isännälle sekä minion-koneen että siinä käynnissä olevien säiliöiden tilan muutoksista.

Resurssien kohdentaminen

Katsotaanpa nyt monimutkaisempien resurssien allokoinnin ongelmaa monille kätyreille.

Yhden pilven laskentaresurssi on:

• Tietyn tehtävän kuluttaman prosessorin tehon määrä.
• Tehtävän käytettävissä olevan muistin määrä.
• Verkkoliikenne. Jokaisella kätyreillä on erityinen verkkoliitäntä rajoitetulla kaistanleveydellä, joten on mahdotonta jakaa tehtäviä ottamatta huomioon niiden verkon yli lähettämän tiedon määrää.
• Levyt. Lisäksi näiden tehtävien tilaan jaamme tietysti myös levytyypin: HDD tai SSD. Levyt voivat palvella rajallisen määrän pyyntöjä sekunnissa - IOPS. Siksi tehtäville, jotka tuottavat enemmän IOPS:ia kuin yksi levy pystyy käsittelemään, varaamme myös "karat" - eli levylaitteet, jotka on varattava yksinomaan tehtävää varten.

Sitten johonkin palveluun, esimerkiksi käyttäjän välimuistiin, voimme tallentaa kulutetut resurssit näin: 400 prosessoriydintä, 2,5 TB muistia, 50 Gbit/s liikennettä molempiin suuntiin, 6 TB HDD-tilaa 100 karalla. Tai tutussa muodossa, kuten tässä:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

Käyttäjävälimuistin palveluresurssit kuluttavat vain osan kaikista tuotantoinfrastruktuurin käytettävissä olevista resursseista. Siksi haluan varmistaa, että yhtäkkiä, operaattorin virheestä tai ei, käyttäjän välimuisti ei kuluta enempää resursseja kuin sille on varattu. Eli resursseja on rajoitettava. Mutta mihin voisimme sitoa kiintiön?

Palataanpa suuresti yksinkertaistettuun kaavioomme komponenttien vuorovaikutuksesta ja piirretään se uudelleen yksityiskohtaisemmin - esimerkiksi näin:

Mikä pistää silmään:

• Verkkokäyttöliittymä ja musiikki käyttävät saman sovelluspalvelimen eristettyjä klustereita.
• Voimme erottaa loogiset kerrokset, joihin nämä klusterit kuuluvat: frontot, välimuistit, tiedon tallennus- ja hallintakerros.
• Käyttöliittymä on heterogeeninen, se koostuu erilaisista toiminnallisista alijärjestelmistä.
• Välimuistit voivat myös olla hajallaan sen alijärjestelmän poikki, jonka tiedot ne tallentavat välimuistiin.

Piirretään kuva uudestaan:

Bah! Kyllä, näemme hierarkian! Tämä tarkoittaa, että voit jakaa resursseja suuremmissa osissa: määritä vastuullinen kehittäjä tämän hierarkian solmulle, joka vastaa toiminnallista alijärjestelmää (kuten kuvassa "musiikki") ja liitä kiintiö samalle hierarkian tasolle. Tämän hierarkian ansiosta voimme myös järjestää palvelut joustavammin hallinnan helpottamiseksi. Esimerkiksi jaamme koko verkon, koska tämä on erittäin suuri palvelinryhmä, useisiin pienempiin ryhmiin, jotka näkyvät kuvassa ryhmänä ryhmä1, ryhmä2.

Poistamalla ylimääräiset rivit voimme kirjoittaa kuvamme jokaisen solmun litteämmässä muodossa: group1.web.front, api.music.front, user-cache.cache.

Näin tulemme käsitteeseen "hierarkkinen jono". Sillä on nimi kuten "ryhmä1.web.etu". Sille on määritetty kiintiö resursseille ja käyttöoikeuksille. Annamme DevOps-henkilölle oikeudet lähettää palvelu jonoon, ja tällainen työntekijä voi käynnistää jotain jonossa, ja OpsDev-henkilöllä on järjestelmänvalvojan oikeudet, ja nyt hän voi hallita jonoa, määrätä ihmisiä sinne, antaa näille ihmisille oikeudet jne. Tässä jonossa käynnissä olevat palvelut toimivat jonon kiintiön sisällä. Jos jonon laskentakiintiö ei riitä kaikkien palvelujen suorittamiseen kerralla, ne suoritetaan peräkkäin, jolloin muodostuu itse jono.

Katsotaanpa palveluita tarkemmin. Palvelulla on täydellinen nimi, joka sisältää aina jonon nimen. Sitten etuverkkopalvelulla on nimi ok-web.group1.web.front. Ja sovelluspalvelinpalvelu, jota se käyttää, kutsutaan ok-app.group1.web.front. Jokaisella palvelulla on manifesti, jossa määritellään kaikki tarvittavat tiedot tietyille koneille sijoittamista varten: kuinka paljon resursseja tämä tehtävä kuluttaa, mitä konfiguraatioita siihen tarvitaan, kuinka monta replikaa pitäisi olla, ominaisuudet tämän palvelun vikojen käsittelyyn. Ja kun palvelu on sijoitettu suoraan koneille, sen esiintymät ilmestyvät. Ne on myös nimetty yksiselitteisesti - ilmentymän numerona ja palvelun nimellä: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

Tämä on erittäin kätevää: katsomalla vain käynnissä olevan kontin nimeä voimme heti saada selville paljon.

Katsotaanpa nyt tarkemmin, mitä nämä esiintymät todella tekevät: tehtäviä.

Tehtävän eristysluokat

Kaikki OK:n tehtävät (ja luultavasti kaikkialla) voidaan jakaa ryhmiin:

• Lyhyen viiveen tehtävät - tuot. Tällaisille tehtäville ja palveluille vastausviive (latenssi) on erittäin tärkeä, kuinka nopeasti järjestelmä käsittelee jokaisen pyynnön. Esimerkkejä tehtävistä: verkkoetuot, välimuistit, sovelluspalvelimet, OLTP-tallennus jne.
• Laskentaongelmat - erä. Tässä yksittäisen pyynnön käsittelynopeudella ei ole merkitystä. Heille on tärkeää, kuinka monta laskutoimitusta tämä tehtävä tekee tietyn (pitkän) ajanjakson aikana (läpivirtaus). Nämä ovat mitä tahansa MapReducen, Hadoopin, koneoppimisen ja tilastojen tehtäviä.
• Taustatehtävät - tyhjäkäynnillä. Tällaisissa tehtävissä latenssi tai suoritusteho eivät ole kovin tärkeitä. Tämä sisältää erilaisia ​​testejä, siirtoja, uudelleenlaskuja ja tietojen muuntamista muodosta toiseen. Toisaalta ne ovat samanlaisia ​​kuin laskelmat, toisaalta meille ei ole väliä kuinka nopeasti ne valmistuvat.

Katsotaan kuinka tällaiset tehtävät kuluttavat resursseja, esimerkiksi keskusprosessoria.

Lyhyet viivetehtävät. Tällaisella tehtävällä on tämän kaltainen suorittimen kulutuskuvio:

Käyttäjältä vastaanotetaan käsittelypyyntö, tehtävä alkaa käyttää kaikkia saatavilla olevia CPU-ytimiä, käsittelee sen, palauttaa vastauksen, odottaa seuraavaa pyyntöä ja pysähtyy. Seuraava pyyntö saapui - jälleen valitsimme kaiken, mikä oli siellä, laskimme sen ja odotamme seuraavaa.

Jotta voimme taata tällaisen tehtävän vähimmäisviiveen, meidän on otettava sen kuluttamat enimmäisresurssit ja varattava tarvittava määrä ytimiä minionille (koneelle, joka suorittaa tehtävän). Sitten ongelmamme varauskaava on seuraava:

alloc: cpu = 4 (max)

ja jos meillä on minionikone, jossa on 16 ydintä, niin siihen voidaan sijoittaa täsmälleen neljä tällaista tehtävää. Huomaamme erityisesti, että tällaisten tehtävien keskimääräinen prosessorin kulutus on usein hyvin alhainen - mikä on selvää, koska merkittävä osa ajasta tehtävä odottaa pyyntöä eikä tee mitään.

Laskentatehtävät. Niiden malli on hieman erilainen:

Keskimääräinen suorittimen resurssien kulutus tällaisissa tehtävissä on melko korkea. Usein haluamme laskentatehtävän valmistuvan tietyssä ajassa, joten meidän on varattava minimimäärä prosessoreita, joita se tarvitsee, jotta koko laskenta saadaan valmiiksi hyväksyttävässä ajassa. Sen varauskaava näyttää tältä:

alloc: cpu = [1,*)

"Aseta se kätyrin päälle, jossa on ainakin yksi vapaa ydin, ja niin monta kuin niitä on, se syö kaiken."

Täällä käytön tehokkuus on jo paljon parempi kuin lyhyellä viiveellä tehtävissä tehtävissä. Mutta hyöty on paljon suurempi, jos yhdistät molemmat tehtävät yhdessä kätyrikoneessa ja jaat sen resursseja tien päällä. Kun tehtävä pienellä viiveellä vaatii prosessoria, se vastaanottaa sen välittömästi ja kun resursseja ei enää tarvita, ne siirretään laskennalliseen tehtävään, eli jotain tällaista:

Mutta miten se tehdään?

Katsotaan ensin prod ja sen alloc: cpu = 4. Meidän on varattava neljä ydintä. Docker-ajossa tämä voidaan tehdä kahdella tavalla:

• Vaihtoehtoa käyttämällä --cpuset=1-4eli varaa neljä tiettyä ydintä koneessa tehtävään.
• Käytä --cpuquota=400_000 --cpuperiod=100_000, määritä prosessoriajalle kiintiö, eli osoita, että jokaista 100 ms reaaliaikaa tehtävä kuluttaa enintään 400 ms prosessoriaikaa. Saadaan samat neljä ydintä.

Mutta mikä näistä menetelmistä sopii?

cpuset näyttää varsin houkuttelevalta. Tehtävässä on neljä erillistä ydintä, mikä tarkoittaa, että prosessorin välimuistit toimivat mahdollisimman tehokkaasti. Tällä on myös varjopuolensa: meidän olisi otettava tehtäväksi jakaa laskelmat koneen kuormittamattomille ytimille käyttöjärjestelmän sijaan, ja tämä on melko ei-triviaali tehtävä, varsinkin jos yritämme sijoittaa erätehtäviä sellaiselle kone. Testit ovat osoittaneet, että vaihtoehto kiintiöllä sopii tähän paremmin: näin käyttöjärjestelmällä on enemmän vapautta valita ydin kulloinkin tehtävää suorittamaan ja prosessoriaika jakautuu tehokkaammin.

Selvitetään kuinka tehdä varauksia Dockerissa ytimien vähimmäismäärän perusteella. Erätehtävien kiintiö ei ole enää voimassa, koska enimmäismäärää ei tarvitse rajoittaa, riittää, että vain takaat minimin. Ja tähän vaihtoehto sopii hyvin docker run --cpushares.

Sovimme, että jos erä vaatii takuun vähintään yhdelle ytimelle, niin ilmoitamme --cpushares=1024, ja jos ytimiä on vähintään kaksi, osoitamme --cpushares=2048. Prosessoriosuudet eivät millään tavalla häiritse prosessoriajan jakautumista niin kauan kuin sitä on tarpeeksi. Näin ollen, jos prod ei tällä hetkellä käytä kaikkia neljää ydintään, mikään ei rajoita erätehtäviä, ja ne voivat käyttää ylimääräistä prosessoriaikaa. Mutta tilanteessa, jossa prosessoreista on pula, jos prod on kuluttanut kaikki neljä ydintään ja saavuttanut kiintiönsä, jäljellä oleva prosessoriaika jaetaan suhteellisesti cpushares-osaan, eli kolmen vapaan ytimen tilanteessa yksi annetaan tehtävälle, jossa on 1024 cpushares, ja loput kaksi annetaan tehtävälle, jossa on 2048 cpushares.

Mutta kiintiöiden ja osakkeiden käyttö ei riitä. Meidän on varmistettava, että tehtävä, jolla on lyhyt viive, on etusijalla erätehtävään nähden prosessoriaikaa varattaessa. Ilman tällaista priorisointia erätehtävä vie kaiken prosessoriajan sillä hetkellä, kun prod sitä tarvitsee. Docker-ajossa ei ole säilön priorisointivaihtoehtoja, mutta Linuxin suorittimen ajoituskäytännöt ovat hyödyllisiä. Voit lukea niistä yksityiskohtaisesti täällä, ja tämän artikkelin puitteissa käymme ne läpi lyhyesti:

• SCHED_OTHER
  Oletuksena kaikki normaalit Linux-koneen käyttäjäprosessit vastaanottavat.
• SCHED_BATCH
  Suunniteltu resurssiintensiivisiin prosesseihin. Kun tehtävä asetetaan prosessorille, otetaan käyttöön ns. aktivointirangaistus: tällainen tehtävä ei todennäköisesti saa prosessoriresursseja, jos sitä käyttää parhaillaan tehtävä, jossa on SCHED_OTHER
• SCHED_IDLE
  Taustaprosessi, jolla on erittäin alhainen prioriteetti, jopa pienempi kuin kiva -19. Käytämme avoimen lähdekoodin kirjastoamme yksi-nio, jotta voidaan asettaa tarvittava käytäntö, kun kontti käynnistetään soittamalla

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

Mutta vaikka et ohjelmoisi Javalla, sama voidaan tehdä chrt-komennolla:

chrt -i 0 $pid

Tehdään yhteenveto kaikista eristystasoistamme yhteen taulukkoon selvyyden vuoksi:

Eristysluokka
Alloc esimerkki
Docker-ajovaihtoehdot
sched_setscheduler chrt*

Prod
prosessori = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

Erä
Prosessori = [1, *)
--cpushares=1024
SCHED_BATCH

Idle
Cpu = [2, *)
--cpushares=2048
SCHED_IDLE

*Jos teet chrt:n säilön sisältä, saatat tarvita sys_nice-ominaisuuden, koska oletuksena Docker poistaa tämän ominaisuuden säilöä käynnistettäessä.

Mutta tehtävät kuluttavat paitsi prosessoria, myös liikennettä, mikä vaikuttaa verkkotehtävän latenssiin jopa enemmän kuin prosessoriresurssien virheellinen allokointi. Siksi haluamme luonnollisesti saada täsmälleen saman kuvan liikenteestä. Eli kun prod-tehtävä lähettää joitain paketteja verkkoon, rajoitamme maksiminopeutta (kaava alloc: lan=[*,500mbps) ), jolla tuote voi tehdä tämän. Ja erälle takaamme vain vähimmäissuorituskyvyn, mutta emme rajoita enimmäismäärää (kaava alloc: lan=[10Mbps,*) ) Tässä tapauksessa tuoteliikenteen tulisi olla etusijalla erätehtäviin nähden.
Tässä Dockerilla ei ole mitään primitiiviä, jota voimme käyttää. Mutta se tulee avuksemme Linuxin liikenteenohjaus. Pystyimme saavuttamaan halutun tuloksen kurinalaisuuden avulla Hierarkkinen oikeudenmukainen palvelukäyrä. Sen avulla erottelemme kaksi liikenneluokkaa: korkean prioriteetin prod ja matalan prioriteetin erä/idle. Tämän seurauksena lähtevän liikenteen kokoonpano on seuraava:

tässä 1:0 on hsfc-alan "root qdisc"; 1:1 - hsfc-alaluokka kokonaiskaistanleveysrajalla 8 Gbit/s, jonka alle kaikkien säilöjen aliluokat sijoitetaan; 1:2 - hsfc-lapsiluokka on yhteinen kaikille erä- ja joutokäyntitehtäville "dynaamisella" rajalla, jota käsitellään alla. Loput hsfc-lapiluokat ovat omistettuja luokkia tällä hetkellä käynnissä oleville tuotesäiliöille, joiden rajoitukset vastaavat niiden luetteloita - 450 ja 400 Mbit/s. Jokaiselle hsfc-luokalle on määritetty qdisc-jono fq tai fq_code Linux-ytimen versiosta riippuen, jotta vältetään pakettien menetys liikennepurskeiden aikana.

Tyypillisesti tc-alat priorisoivat vain lähtevää liikennettä. Mutta haluamme priorisoida myös tulevaa liikennettä - loppujen lopuksi jotkut erätehtävät voivat helposti valita koko saapuvan kanavan vastaanottaen esimerkiksi suuren erän syöttödataa map&reduce -ohjelmaa varten. Tätä varten käytämme moduulia ifb, joka luo ifbX-virtuaalirajapinnan jokaiselle verkkorajapinnalle ja ohjaa saapuvan liikenteen rajapinnasta lähtevään liikenteeseen ifbX:ssä. Lisäksi ifbX:ssä kaikki samat tieteenalat ohjaavat lähtevää liikennettä, jonka hsfc-kokoonpano on hyvin samanlainen:

Kokeiden aikana havaitsimme, että hsfc näyttää parhaat tulokset, kun 1:2-luokka ei-prioriteetista erä/joutokäyntiä on rajoitettu minion-koneissa vain tietylle vapaalle kaistalle. Muuten ei-prioriteettiliikenteellä on liikaa vaikutusta tuotantotehtävien latenssiin. miniond määrittää nykyisen vapaan kaistanleveyden joka sekunti mittaamalla tietyn minionin kaikkien prod-tehtävien keskimääräisen liikenteenkulutuksen ja vähentämällä se verkkoliitännän kaistanleveydestä pienellä marginaalilla, ts.

Taastot määritellään erikseen saapuvalle ja lähtevälle liikenteelle. Ja uusien arvojen mukaan miniond konfiguroi uudelleen ei-prioriteettiluokkarajan 1:2.

Näin ollen toteutimme kaikki kolme eristysluokkaa: prod, batch ja idle. Nämä luokat vaikuttavat suuresti tehtävien suoritusominaisuuksiin. Siksi päätimme sijoittaa tämän attribuutin hierarkian huipulle, jotta hierarkkisen jonon nimeä tarkasteltaessa olisi heti selvää, mistä on kyse:

Kaikki ystävämme verkko и musiikki etuosat sijoitetaan sitten hierarkiaan tuotekohtaan. Esimerkiksi erän alle sijoitetaan palvelu musiikkiluettelo, joka kokoaa säännöllisesti kappaleluettelon Odnoklassnikiin ladatuista mp3-tiedostoista. Esimerkki palvelusta tyhjäkäynnillä olisi musiikin muuntaja, joka normalisoi musiikin äänenvoimakkuuden.

Kun ylimääräiset rivit on poistettu, voimme kirjoittaa palveluiden nimet litteämmäksi lisäämällä tehtävän eristysluokan palvelun täyden nimen loppuun: web.front.prod, catalog.music.batch, transformer.music.idle.

Ja nyt, kun katsomme palvelun nimeä, ymmärrämme paitsi mitä toimintoa se suorittaa, myös sen eristysluokkaa, mikä tarkoittaa sen kriittisyyttä jne.

Kaikki on hienoa, mutta on yksi katkera totuus. Yhdellä koneella suoritettavia tehtäviä on mahdotonta eristää kokonaan.

Mitä onnistuimme saavuttamaan: jos erä kuluttaa intensiivisesti vain CPU-resurssit, sisäänrakennettu Linux-suorittimen ajastin tekee työnsä erittäin hyvin, eikä se käytännössä vaikuta tuotantotehtävään. Mutta jos tämä erätehtävä alkaa aktiivisesti toimia muistin kanssa, keskinäinen vaikutus näkyy jo. Tämä johtuu siitä, että prod-tehtävä "pestään pois" prosessorin välimuistista - tämän seurauksena välimuistin puuttuminen lisääntyy ja prosessori käsittelee prod-tehtävän hitaammin. Tällainen erätehtävä voi lisätä tyypillisen tuotesäiliömme latenssia 10 %.

Liikenteen eristäminen on vielä vaikeampaa, koska nykyaikaisissa verkkokorteissa on sisäinen pakettijono. Jos erätehtävän paketti saapuu sinne ensin, se lähetetään ensimmäisenä kaapelin kautta, eikä sille voida tehdä mitään.

Lisäksi olemme toistaiseksi onnistuneet ratkaisemaan vain TCP-liikenteen priorisoinnin ongelman: hsfc-lähestymistapa ei toimi UDP:ssä. Ja jopa TCP-liikenteen tapauksessa, jos erätehtävä tuottaa paljon liikennettä, tämä lisää myös noin 10 %:n lisäystä tuotantotehtävän viiveeseen.

vikasietoisuus

Yksi yhden pilven kehittämisen tavoitteista oli parantaa Odnoklassnikin vikasietoisuutta. Siksi haluaisin seuraavaksi tarkastella yksityiskohtaisemmin mahdollisia vikojen ja onnettomuuksien skenaarioita. Aloitetaan yksinkertaisella skenaariolla - kontin vika.

Itse säiliö voi epäonnistua useilla tavoilla. Tämä voi olla jonkinlainen kokeilu, bugi tai virhe luettelossa, jonka vuoksi prod-tehtävä alkaa kuluttaa enemmän resursseja kuin mitä manifestissa on ilmoitettu. Meillä oli tapaus: kehittäjä otti käyttöön yhden monimutkaisen algoritmin, työskenteli sen uudelleen monta kertaa, piti itsensä yli ja hämmentyi niin, että lopulta ongelma silmukautui hyvin ei-triviaalilla tavalla. Ja koska prod-tehtävällä on korkeampi prioriteetti kuin kaikilla muilla samoissa kätyreissä, se alkoi kuluttaa kaikkia käytettävissä olevia prosessoriresursseja. Tässä tilanteessa eristäminen tai pikemminkin CPU-aikakiintiö pelasti päivän. Jos tehtävälle on varattu kiintiö, tehtävä ei kuluta enempää. Siksi erä- ja muut tuotantotehtävät, jotka suoritettiin samalla koneella, eivät huomanneet mitään.

Toinen mahdollinen ongelma on kontin putoaminen. Ja tässä uudelleenkäynnistyskäytännöt pelastavat meidät, kaikki tietävät ne, Docker itse tekee hienoa työtä. Lähes kaikilla tuotantotehtävillä on aina uudelleenkäynnistyskäytäntö. Joskus käytämme on_failure-toimintoa erätehtäviin tai tuotesäiliöiden virheenkorjaukseen.

Mitä voit tehdä, jos koko kätyri ei ole käytettävissä?

Ilmeisesti käytä säiliötä toisessa koneessa. Mielenkiintoinen osa tässä on, mitä tapahtuu säilölle annetuille IP-osoitteille.

Voimme määrittää säilöille samat IP-osoitteet kuin minion-koneille, joilla nämä kontit toimivat. Sitten, kun kontti käynnistetään toisella koneella, sen IP-osoite vaihtuu ja kaikkien asiakkaiden on ymmärrettävä, että kontti on siirtynyt, ja nyt heidän on siirryttävä toiseen osoitteeseen, mikä vaatii erillisen Service Discovery -palvelun.

Palvelun etsiminen on kätevää. Markkinoilla on monia eriasteisia vikasietoisia ratkaisuja palvelurekisterin järjestämiseen. Usein tällaiset ratkaisut toteuttavat kuormituksen tasauslogiikkaa, tallentavat lisäkonfiguraatioita KV-tallennustilan muodossa jne.
Haluamme kuitenkin välttää erillisen rekisterin käyttöönoton, koska se merkitsisi kriittisen järjestelmän käyttöönottoa, jota kaikki tuotannon palvelut käyttävät. Tämä tarkoittaa, että tämä on mahdollinen vikakohta, ja sinun on valittava tai kehitettävä erittäin vikasietoinen ratkaisu, joka on luonnollisesti erittäin vaikea, aikaa vievä ja kallis.

Ja vielä yksi iso haittapuoli: jotta vanha infrastruktuurimme toimisi uuden kanssa, meidän olisi kirjoitettava täysin kaikki tehtävät uudelleen käyttämään jonkinlaista Service Discovery -järjestelmää. Työtä on PALJON, ja joissain paikoissa se on lähes mahdotonta, kun on kyse matalan tason laitteista, jotka toimivat käyttöjärjestelmän ydintasolla tai suoraan laitteiston kanssa. Tämän toiminnon toteuttaminen vakiintuneiden ratkaisumallien avulla, kuten sivuvaunu merkitsisi paikoin lisäkuormitusta, toisaalta toiminnan komplikaatiota ja ylimääräisiä vikaskenaarioita. Emme halunneet monimutkaistaa asioita, joten päätimme tehdä Service Discoveryn käytöstä valinnaista.

One-pilvessä IP seuraa konttia, eli jokaisella tehtäväinstanssilla on oma IP-osoite. Tämä osoite on "staattinen": se määritetään jokaiselle esiintymälle, kun palvelu lähetetään ensimmäisen kerran pilveen. Jos palvelulla oli elinkaarensa aikana eri määrä esiintymiä, sille annetaan lopulta niin monta IP-osoitetta kuin niitä oli enimmäismäärä.

Myöhemmin nämä osoitteet eivät muutu: ne määritetään kerran ja ne ovat olemassa koko palvelun käyttöiän tuotannossa. IP-osoitteet seuraavat säiliöitä verkon yli. Jos kontti siirretään toiselle kätyrille, osoite seuraa sitä.

Siten palvelun nimen yhdistäminen sen IP-osoiteluetteloon muuttuu hyvin harvoin. Jos katsot uudelleen artikkelin alussa mainitsemiemme palveluesiintymien nimiä (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), huomaamme, että ne muistuttavat DNS:ssä käytettyjä FQDN:itä. Aivan oikein, kartoittaaksemme palveluesiintymien nimet niiden IP-osoitteisiin, käytämme DNS-protokollaa. Lisäksi tämä DNS palauttaa kaikkien säilöjen kaikki varatut IP-osoitteet - sekä käynnissä että pysäytettyinä (oletetaan, että käytössä on kolme kopiota, ja meillä on sinne varattu viisi osoitetta - kaikki viisi palautetaan). Asiakkaat, saatuaan nämä tiedot, yrittävät muodostaa yhteyden kaikkiin viiteen kopioon - ja siten määrittää ne, jotka toimivat. Tämä käytettävyyden määrittämisvaihtoehto on paljon luotettavampi, se ei sisällä DNS- tai Service Discovery -toimintoa, mikä tarkoittaa, että näiden järjestelmien tiedon ja vikasietoisuuden varmistamisessa ei ole vaikeita ongelmia ratkaistavaksi. Lisäksi kriittisissä palveluissa, joista koko portaalin toiminta riippuu, emme voi käyttää DNS:ää ollenkaan, vaan yksinkertaisesti syöttää IP-osoitteet kokoonpanoon.

Tällaisen IP-siirron toteuttaminen säiliöiden takana voi olla ei-triviaalia - ja katsomme kuinka se toimii seuraavan esimerkin avulla:

Oletetaan, että yhden pilven päällikkö antaa kätyri M1:lle käskyn juosta 1.ok-web.group1.web.front.prod osoitteella 1.1.1.1. Toimii minionilla LINTU, joka mainostaa tätä osoitetta erikoispalvelimille reittiheijastin. Jälkimmäisillä on BGP-istunto verkkolaitteiston kanssa, johon käännetään M1.1.1.1:n osoitteen 1 reitti. M1 reitittää paketit kontin sisällä Linuxin avulla. Reittiheijastinpalvelimia on kolme, koska tämä on erittäin kriittinen osa yhden pilven infrastruktuuria - ilman niitä yhden pilven verkko ei toimi. Sijoitamme ne eri telineisiin, mikäli mahdollista palvelinkeskuksen eri huoneisiin, vähentääksemme todennäköisyyttä, että kaikki kolme epäonnistuvat samanaikaisesti.

Oletetaan nyt, että yhteys yhden pilven masterin ja M1-minionin välillä on katkennut. Yhden pilven päällikkö toimii nyt olettaen, että M1 on täysin epäonnistunut. Eli se antaa M2-minionille komennon käynnistää web.group1.web.front.prod samalla osoitteella 1.1.1.1. Verkossa on nyt kaksi ristiriitaista reittiä 1.1.1.1:lle: M1 ja M2. Tällaisten ristiriitojen ratkaisemiseksi käytämme Multi Exit Discriminator -työkalua, joka on määritelty BGP-ilmoituksessa. Tämä on numero, joka näyttää ilmoitetun reitin painon. Ristiriitaisista reiteistä valitaan reitti, jolla on pienempi MED-arvo. Yhden pilven isäntä tukee MED:ää kiinteänä osana kontti-IP-osoitteita. Ensimmäistä kertaa osoite kirjoitetaan riittävän suurella MED = 1 000 000. Tällaisessa hätäkonttisiirrossa isäntä pienentää MED:ää ja M2 saa jo komennon mainostaa osoitetta 1.1.1.1, jossa MED = 999 999. M1:llä ajettava instanssi pysyy tässä tapauksessa yhteyttä ei ole, ja hänen tuleva kohtalonsa ei kiinnosta meitä juurikaan ennen kuin yhteys herraan palautuu, jolloin hänet pysäytetään kuin vanha ote.

onnettomuus

Kaikki konesalin hallintajärjestelmät käsittelevät aina pienet viat hyväksyttävästi. Säiliön ylivuoto on normaalia lähes kaikkialla.

Katsotaanpa, kuinka käsittelemme hätätilanteita, kuten sähkökatkoksia yhdessä tai useammassa palvelinkeskuksen huoneessa.

Mitä onnettomuus tarkoittaa datakeskuksen hallintajärjestelmälle? Ensinnäkin tämä on monien koneiden massiivinen kertavika, ja ohjausjärjestelmän on siirrettävä useita kontteja samanaikaisesti. Mutta jos katastrofi on erittäin laaja, voi tapahtua, että kaikkia tehtäviä ei voida jakaa uudelleen muille kätyreille, koska palvelinkeskuksen resurssikapasiteetti putoaa alle 100 % kuormituksesta.

Usein onnettomuuksiin liittyy ohjauskerroksen vika. Tämä voi tapahtua sen laitteiden vian vuoksi, mutta useammin siitä syystä, että onnettomuuksia ei testata, ja itse ohjauskerros putoaa lisääntyneen kuormituksen vuoksi.

Mitä voit tehdä tälle kaikelle?

Joukkosiirrot tarkoittavat, että infrastruktuurissa tapahtuu suuri määrä toimintoja, siirtymiä ja käyttöönottoja. Jokainen siirto voi kestää jonkin aikaa, joka tarvitaan konttikuvien toimittamiseen ja purkamiseen kätyreille, säiliöiden käynnistämiseen ja alustamiseen jne. Siksi on toivottavaa, että tärkeämmät tehtävät käynnistetään ennen vähemmän tärkeitä.

Katsotaanpa uudelleen meille tuttua palveluhierarkiaa ja yritetään päättää, mitkä tehtävät haluamme suorittaa ensin.

Tietenkin nämä ovat prosesseja, jotka liittyvät suoraan käyttäjien pyyntöjen käsittelyyn, eli prod. Osoitamme tämän kanssa sijoittelun prioriteetti — numero, joka voidaan määrittää jonoon. Jos jonolla on korkeampi prioriteetti, sen palvelut sijoitetaan ensin.

Tuotteissa määritämme korkeammat prioriteetit, 0; erässä - hieman pienempi, 100; tyhjäkäynnillä - jopa alempi, 200. Prioriteetit sovelletaan hierarkkisesti. Kaikilla hierarkiassa alemmilla tehtävillä on vastaava prioriteetti. Jos haluamme, että prod-välimuistit käynnistetään ennen käyttöliittymää, asetamme prioriteetit välimuistille = 0 ja etualijonoille = 1. Jos esimerkiksi haluamme, että pääportaali käynnistetään ensin etupuolelta ja vain musiikkirintama. Sitten voimme määrittää jälkimmäiselle alemman prioriteetin - 10.

Seuraava ongelma on resurssien puute. Niinpä suuri määrä laitteita, kokonaisia ​​palvelinkeskuksen halleja epäonnistui ja lanseerasimme uudelleen niin paljon palveluita, että nyt ei riitä resurssit kaikille. Sinun on päätettävä, mitkä tehtävät uhrata, jotta tärkeimmät kriittiset palvelut pysyvät käynnissä.

Toisin kuin sijoitusprioriteetti, emme voi uhrata umpimähkäisesti kaikkia erätehtäviä, vaan osa niistä on tärkeitä portaalin toiminnan kannalta. Siksi olemme korostaneet erikseen etuoikeus tehtäviä. Kun korkeampi prioriteettitehtävä sijoitetaan, se voi ennaltaehkäistä eli pysäyttää alhaisemman prioriteetin tehtävän, jos vapaita kätyriä ei ole enää. Tässä tapauksessa matalan prioriteetin tehtävä jää todennäköisesti sijoittamatta, eli sille ei enää löydy sopivaa kätyriä, jolla on riittävästi vapaita resursseja.

Hierarkiassamme on hyvin yksinkertaista määrittää ennaltaehkäisyprioriteetti siten, että tuotanto- ja erätehtävät ennaltaehkäisevät tai pysäyttävät joutotehtävät, mutta eivät toisiaan, määrittämällä tyhjäkäynnille prioriteetiksi 200. Aivan kuten sijoittelun prioriteetin tapauksessa, me voi käyttää hierarkiaamme monimutkaisempien sääntöjen kuvaamiseen. Oletetaan esimerkiksi, että uhraamme musiikkitoiminnon, jos meillä ei ole tarpeeksi resursseja pääverkkoportaalille, asettamalla vastaavien solmujen prioriteetti alhaisemmaksi: 10.

Kokonaisia ​​DC-onnettomuuksia

Miksi koko palvelinkeskus voi epäonnistua? Elementti. Oli hyvä postaus hurrikaani vaikutti palvelinkeskuksen työhön. Elementtejä voidaan pitää kodittomina, jotka kerran polttivat jakotukin optiikkaa, ja palvelinkeskus menetti kokonaan yhteyden muihin kohteisiin. Vian syy voi olla myös inhimillinen tekijä: operaattori antaa sellaisen komennon, että koko konesali kaatuu. Tämä voi tapahtua suuren bugin takia. Yleensä datakeskusten romahtaminen ei ole harvinaista. Tämä tapahtuu meille kerran muutamassa kuukaudessa.

Ja näin me teemme estääksemme ketään twiittauttamasta #elossa.

Ensimmäinen strategia on eristäminen. Jokainen yhden pilven ilmentymä on eristetty ja voi hallita koneita vain yhdessä datakeskuksessa. Toisin sanoen pilven katoaminen virheiden tai virheellisten operaattorikomentojen vuoksi on vain yhden datakeskuksen menetys. Olemme valmiita tähän: meillä on redundanssikäytäntö, jonka mukaan sovelluksen ja datan jäljennökset sijaitsevat kaikissa palvelinkeskuksissa. Käytämme vikasietoisia tietokantoja ja testaamme säännöllisesti vikojen varalta.
Nykyään meillä on neljä datakeskusta, mikä tarkoittaa neljää erillistä, täysin eristettyä yhden pilven esiintymää.

Tämä lähestymistapa ei suojaa ainoastaan ​​fyysisiltä vioista, vaan voi myös suojata käyttäjän virheiltä.

Mitä muuta inhimilliselle tekijälle voidaan tehdä? Kun käyttäjä antaa pilvelle oudon tai mahdollisesti vaarallisen komennon, häntä voidaan yhtäkkiä pyytää ratkaisemaan pieni ongelma nähdäkseen, kuinka hyvin hän ajatteli. Jos tämä on esimerkiksi jonkinlainen monien replikoiden massapysäytys tai vain outo komento - replikoiden määrän vähentäminen tai kuvan nimen muuttaminen, ei vain versionumeron uudessa luettelossa.

Tulokset

Yhden pilven erityispiirteet:

• Hierarkkinen ja visuaalinen nimeämisjärjestelmä palveluille ja säilöille, jonka avulla saat erittäin nopeasti selville, mikä tehtävä on, mihin se liittyy ja miten se toimii ja kuka siitä vastaa.
• Sovellamme meidän tekniikka tuotteen ja erän yhdistämiseksitehtäviä kätyreille koneen jakamisen tehostamiseksi. Cpusetin sijasta käytämme prosessorikiintiöitä, jakoja, suorittimen ajoituskäytäntöjä ja Linuxin QoS:ää.
• Samalla koneella toimivia kontteja ei voitu täysin eristää, mutta niiden keskinäinen vaikutus pysyy 20 %:n sisällä.
• Palveluiden järjestäminen hierarkiaan helpottaa automaattista katastrofipalautusta sijoitus- ja etuostoprioriteetit.

Ohje

Miksi emme ottaneet valmiita ratkaisuja?

• Eri tehtävien eristysluokat vaativat erilaista logiikkaa, kun ne asetetaan kätyreille. Jos prod-tehtävät voidaan sijoittaa yksinkertaisesti varaamalla resursseja, on sijoitettava erä- ja joutotehtävät, jotka seuraavat resurssien todellista käyttöä minionikoneissa.
• Tarve ottaa huomioon tehtävien kuluttamat resurssit, kuten:
  • verkon kaistanleveys;
  • levytyypit ja "karat".
• Tarve ilmoittaa palvelujen prioriteetit hätätilanteessa, resurssien komentojen oikeudet ja kiintiöt, joka ratkaistaan ​​hierarkkisten jonojen avulla yhdessä pilvessä.
• Tarve nimetä säiliöt ihmisille, jotta onnettomuuksiin ja vaaratilanteisiin reagointiaika lyhenisi
• Service Discoveryn kertaluonteisen laajan käyttöönoton mahdottomuus; tarve elää pitkään rinnakkain laitteistoisännillä isännöityjen tehtävien kanssa - mikä ratkaistaan ​​"staattisilla" IP-osoitteilla, jotka seuraavat säiliöitä, ja sen seurauksena tarve ainutlaatuiseen integraatioon suuren verkkoinfrastruktuurin kanssa.

Kaikki nämä toiminnot edellyttäisivät huomattavia muutoksia olemassa oleviin ratkaisuihin meille sopiviksi, ja työn määrää arvioituamme totesimme, että voisimme kehittää oman ratkaisumme suunnilleen samoilla työvoimakustannuksilla. Mutta ratkaisusi on paljon helpompi käyttää ja kehittää - se ei sisällä tarpeettomia abstraktioita, jotka tukevat toiminnallisuutta, jota emme tarvitse.

Niille, jotka lukevat viimeiset rivit, kiitos kärsivällisyydestänne ja huomiostanne!

Lähde: will.com