Viena mākoņa — datu centra līmeņa operētājsistēma Odnoklassniki

Aloha, cilvēki! Mani sauc Oļegs Anastasjevs, es strādāju Odnoklassniki platformas komandā. Un bez manis Odnoklassniki strādā daudz aparatūras. Mums ir četri datu centri ar aptuveni 500 plauktiem ar vairāk nekā 8 tūkstošiem serveru. Noteiktā brīdī sapratām, ka jaunas vadības sistēmas ieviešana ļaus efektīvāk ielādēt iekārtas, atvieglos piekļuves pārvaldību, automatizēs skaitļošanas resursu (pār)dali, paātrinās jaunu pakalpojumu palaišanu un paātrinās atbildes reakcijas. liela mēroga negadījumiem.

Kas no tā sanāca?

Bez manis un daudz aparatūras ir arī cilvēki, kas strādā ar šo aparatūru: inženieri, kas atrodas tieši datu centros; Tīkla speciālisti, kas iestata tīkla programmatūru; administratori jeb SRE, kas nodrošina infrastruktūras noturību; un izstrādes komandas, katra no tām ir atbildīga par daļu no portāla funkcijām. Viņu izveidotā programmatūra darbojas apmēram šādi:

Lietotāju pieprasījumi tiek saņemti abās galvenā portāla priekšpusēs www.ok.ru, un citās, piemēram, mūzikas API frontēs. Lai apstrādātu biznesa loģiku, viņi izsauc lietojumprogrammu serveri, kas, apstrādājot pieprasījumu, izsauc nepieciešamos specializētos mikropakalpojumus - vienu grafiku (sociālo savienojumu grafiks), lietotāja kešatmiņu (lietotāju profilu kešatmiņu) utt.

Katrs no šiem pakalpojumiem ir izvietots daudzās iekārtās, un katrā no tām ir atbildīgi izstrādātāji, kas ir atbildīgi par moduļu darbību, to darbību un tehnoloģiju attīstību. Visi šie pakalpojumi darbojas uz aparatūras serveriem, un vēl nesen mēs palaižām tieši vienu uzdevumu katram serverim, t.i., tas bija specializēts konkrētam uzdevumam.

Kāpēc ir tā, ka? Šai pieejai bija vairākas priekšrocības:

• Atvieglota masu vadība. Pieņemsim, ka uzdevumam ir nepieciešamas dažas bibliotēkas, daži iestatījumi. Un tad serveris tiek piešķirts tieši vienai noteiktai grupai, ir aprakstīta cfengine politika šai grupai (vai tā jau ir aprakstīta), un šī konfigurācija tiek centralizēti un automātiski izlaista uz visiem šīs grupas serveriem.
• Vienkāršots diagnostika. Pieņemsim, ka aplūkojat palielināto centrālā procesora slodzi un saprotat, ka šo slodzi var ģenerēt tikai uzdevums, kas darbojas šajā aparatūras procesorā. Vainīgā meklēšana beidzas ļoti ātri.
• Vienkāršots uzraudzību. Ja ar serveri kaut kas nav kārtībā, monitors par to ziņo, un jūs precīzi zināt, kurš ir vainīgs.

Pakalpojumam, kas sastāv no vairākām replikām, tiek piešķirti vairāki serveri – katram pa vienam. Tad pakalpojuma skaitļošanas resurss tiek piešķirts ļoti vienkārši: pakalpojumam piederošo serveru skaits, maksimālais resursu daudzums, ko tas var patērēt. “Viegli” šeit nenozīmē, ka tas ir viegli lietojams, bet gan tādā nozīmē, ka resursu piešķiršana tiek veikta manuāli.

Šī pieeja arī ļāva mums to darīt specializētas dzelzs konfigurācijas uzdevumam, kas darbojas šajā serverī. Ja uzdevums glabā lielu datu apjomu, tad mēs izmantojam 4U serveri ar šasiju ar 38 diskiem. Ja uzdevums ir tīri skaitļošanas, tad varam nopirkt lētāku 1U serveri. Tas ir skaitļošanas ziņā efektīvi. Cita starpā šī pieeja ļauj izmantot četras reizes mazāk mašīnu ar slodzi, kas ir salīdzināma ar vienu draudzīgu sociālo tīklu.

Šādai skaitļošanas resursu izmantošanas efektivitātei būtu jānodrošina arī ekonomiskā efektivitāte, ja izejam no pieņēmuma, ka visdārgākais ir serveri. Ilgu laiku aparatūra bija visdārgākā, un mēs pielikām daudz pūļu, lai samazinātu aparatūras cenas, izstrādājot kļūdu tolerances algoritmus, lai samazinātu aparatūras uzticamības prasības. Un šodien mēs esam sasnieguši posmu, kurā servera cena vairs nav noteicošā. Ja neņem vērā jaunāko eksotiku, tad konkrētajai serveru konfigurācijai plauktā nav nozīmes. Tagad mums ir vēl viena problēma - cena par vietu, ko datu centrā aizņem serveris, tas ir, vieta plauktā.

Apzinoties, ka tas tā ir, mēs nolēmām aprēķināt, cik efektīvi mēs izmantojam statīvus.
Jaudīgākā servera cenu ņēmām no ekonomiski attaisnojamajiem, sarēķinājām, cik šādus serverus varētu novietot stacijās, cik uzdevumus uz tiem darbināsim pēc vecā modeļa “viens serveris = viens uzdevums” un cik tādus uzdevumi varētu izmantot aprīkojumu. Viņi skaitīja un lija asaras. Izrādījās, ka mūsu efektivitāte statīvu izmantošanā ir aptuveni 11%. Secinājums ir acīmredzams: mums ir jāpaaugstina datu centru izmantošanas efektivitāte. Šķiet, ka risinājums ir acīmredzams: vienā serverī vienlaikus jāpalaiž vairāki uzdevumi. Bet šeit sākas grūtības.

Masveida konfigurācija kļūst ievērojami sarežģītāka - tagad nav iespējams serverim piešķirt nevienu grupu. Galu galā tagad vienā serverī var palaist vairākus dažādu komandu uzdevumus. Turklāt konfigurācija var būt pretrunīga dažādām lietojumprogrammām. Diagnostika arī kļūst sarežģītāka: ja serverī redzat palielinātu CPU vai diska patēriņu, jūs nezināt, kurš uzdevums rada problēmas.

Bet galvenais ir tas, ka nav izolācijas starp uzdevumiem, kas darbojas vienā un tajā pašā mašīnā. Šeit, piemēram, ir parādīts servera uzdevuma vidējā reakcijas laika grafiks pirms un pēc citas skaitļošanas lietojumprogrammas palaišanas tajā pašā serverī, kas nekādā veidā nav saistīts ar pirmo - galvenā uzdevuma reakcijas laiks ir ievērojami palielinājies.

Acīmredzot uzdevumi ir jāizpilda konteineros vai virtuālajās mašīnās. Tā kā gandrīz visi mūsu uzdevumi darbojas vienā operētājsistēmā (Linux) vai ir tai pielāgoti, mums nav jāatbalsta daudzas dažādas operētājsistēmas. Attiecīgi virtualizācija nav nepieciešama, papildu pieskaitāmo izmaksu dēļ tā būs mazāk efektīva nekā konteinerizācija.

Kā konteineru ieviešana uzdevumu izpildei tieši serveros, Docker ir labs kandidāts: failu sistēmas attēli labi atrisina problēmas ar konfliktējošām konfigurācijām. Tas, ka attēlus var veidot no vairākiem slāņiem, ļauj ievērojami samazināt datu apjomu, kas nepieciešams, lai tos izvietotu infrastruktūrā, sadalot kopējās daļas atsevišķos bāzes slāņos. Tad pamata (un apjomīgākie) slāņi diezgan ātri tiks saglabāti kešatmiņā visā infrastruktūrā, un, lai nodrošinātu dažādu veidu lietojumprogrammas un versijas, būs jāpārsūta tikai nelieli slāņi.

Turklāt gatavs reģistrs un attēlu marķēšana programmā Docker sniedz mums gatavus primitīvus versiju veidošanai un koda piegādei uz ražošanu.

Docker, tāpat kā jebkura cita līdzīga tehnoloģija, nodrošina mums zināmu konteinera izolāciju no iepakojuma. Piemēram, atmiņas izolācija - katram konteineram ir noteikts mašīnas atmiņas izmantošanas ierobežojums, kuru pārsniedzot, tas netiks patērēts. Varat arī izolēt konteinerus, pamatojoties uz CPU lietojumu. Mums gan ar standarta izolāciju nepietika. Bet vairāk par to zemāk.

Tieša konteineru darbināšana serveros ir tikai daļa no problēmas. Otra daļa ir saistīta ar konteineru mitināšanu serveros. Jāsaprot, kurš konteiners uz kura servera var tikt novietots. Tas nav nemaz tik viegls uzdevums, jo konteineri serveros ir jānovieto pēc iespējas blīvāk, nesamazinot to ātrumu. Šāda izvietošana var būt sarežģīta arī no kļūdu pielaides viedokļa. Bieži vien mēs vēlamies viena un tā paša pakalpojuma kopijas izvietot dažādos statīvos vai pat dažādās datu centra telpās, lai, ja kāds plaukts vai telpa sabojājas, mēs uzreiz nepazaudētu visas servisa kopijas.

Manuāla konteineru izplatīšana nav iespējama, ja jums ir 8 tūkstoši serveru un 8-16 tūkstoši konteineru.

Turklāt mēs vēlējāmies nodrošināt izstrādātājiem lielāku neatkarību resursu piešķiršanā, lai viņi paši varētu mitināt savus pakalpojumus ražošanā bez administratora palīdzības. Tajā pašā laikā mēs vēlējāmies saglabāt kontroli, lai kāds neliels pakalpojums nepatērētu visus mūsu datu centru resursus.

Acīmredzot mums ir nepieciešams vadības slānis, kas to darītu automātiski.

Tātad mēs nonācām pie vienkārša un saprotama attēla, ko visi arhitekti dievina: trīs kvadrāti.

one-cloud masters ir kļūmjpārlēces klasteris, kas atbild par mākoņu orķestrēšanu. Izstrādātājs nosūta kapteinim manifestu, kurā ir visa informācija, kas nepieciešama pakalpojuma mitināšanai. Pamatojoties uz to, kapteinis dod komandas atlasītajiem minioniem (mašīnām, kas paredzētas konteineru darbināšanai). Minioniem ir mūsu aģents, kas saņem komandu, izdod tās Docker, un Docker konfigurē Linux kodolu, lai palaistu atbilstošo konteineru. Papildus komandu izpildei aģents nepārtraukti ziņo kapteinim par izmaiņām gan miniona mašīnas, gan tajā strādājošo konteineru stāvoklī.

Resursu piešķiršana

Tagad aplūkosim sarežģītāku resursu piešķiršanas problēmu daudziem minioniem.

Skaitļošanas resurss vienā mākonī ir:

• Procesora jaudas daudzums, ko patērē konkrētam uzdevumam.
• Uzdevumam pieejamās atmiņas apjoms.
• Tīkla trafiks. Katram no minioniem ir īpašs tīkla interfeiss ar ierobežotu joslas platumu, tāpēc nav iespējams sadalīt uzdevumus, neņemot vērā datu apjomu, ko tie pārraida tīklā.
• Diski. Turklāt, protams, šo uzdevumu vietai mēs piešķiram arī diska veidu: HDD vai SSD. Diski var apkalpot ierobežotu skaitu pieprasījumu sekundē - IOPS. Tāpēc uzdevumiem, kas ģenerē vairāk IOPS, nekā var apstrādāt viens disks, mēs piešķiram arī “vārpstas” - tas ir, diska ierīces, kas ir jārezervē tikai uzdevumam.

Tad kādam pakalpojumam, piemēram, lietotāja kešatmiņai, patērētos resursus varam ierakstīt šādi: 400 procesora kodoli, 2,5 TB atmiņa, 50 Gbit/s trafika abos virzienos, 6 TB HDD vietas, kas atrodas uz 100 vārpstām. Vai arī pazīstamākā formā, piemēram, šī:

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

Lietotāju kešatmiņas pakalpojumu resursi patērē tikai daļu no visiem ražošanas infrastruktūrā pieejamajiem resursiem. Tāpēc es vēlos pārliecināties, ka pēkšņi, operatora kļūdas vai nē, lietotāja kešatmiņa nepatērē vairāk resursu, nekā tai ir atvēlēts. Tas ir, mums ir jāierobežo resursi. Bet ar ko mēs varētu piesaistīt kvotu?

Atgriezīsimies pie mūsu ievērojami vienkāršotās komponentu mijiedarbības diagrammas un pārzīmēsim to ar sīkāku informāciju, piemēram:

Kas piesaista jūsu uzmanību:

• Tīmekļa priekšgals un mūzika izmanto viena un tā paša lietojumprogrammu servera izolētas kopas.
• Mēs varam atšķirt loģiskos slāņus, kuriem šīs kopas pieder: frontes, kešatmiņas, datu uzglabāšanas un pārvaldības slānis.
• Priekšgals ir neviendabīgs, tas sastāv no dažādām funkcionālām apakšsistēmām.
• Kešatmiņas var būt arī izkaisītas pa apakšsistēmu, kuras dati tiek saglabāti kešatmiņā.

Pārzīmēsim attēlu vēlreiz:

Bah! Jā, mēs redzam hierarhiju! Tas nozīmē, ka varat sadalīt resursus lielākos gabalos: piešķirt atbildīgo izstrādātāju šīs hierarhijas mezglam, kas atbilst funkcionālajai apakšsistēmai (piemēram, “mūzika” attēlā), un pievienot kvotu tam pašam hierarhijas līmenim. Šī hierarhija arī ļauj elastīgāk organizēt pakalpojumus, lai atvieglotu pārvaldību. Piemēram, mēs sadalām visu tīmekli, jo šī ir ļoti liela serveru grupa, vairākās mazākās grupās, kas attēlā parādītas kā grupa1, grupa2.

Noņemot papildu līnijas, mēs varam rakstīt katru sava attēla mezglu plakanākā formā: grupa1.tīmekļa priekšpuse, api.music.front, user-cache.cache.

Tā mēs nonākam pie jēdziena “hierarhiskā rinda”. Tam ir tāds nosaukums kā "group1.web.front". Tam tiek piešķirta resursu un lietotāju tiesību kvota. Mēs piešķirsim personai no DevOps tiesības nosūtīt pakalpojumu rindā, un šāds darbinieks var kaut ko palaist rindā, un personai no OpsDev būs administratora tiesības, un tagad viņš var pārvaldīt rindu, nozīmēt tur cilvēkus, piešķirt šīm personām tiesības utt. Pakalpojumi, kas darbojas šajā rindā, darbosies rindas kvotas ietvaros. Ja rindas skaitļošanas kvota nav pietiekama, lai izpildītu visus pakalpojumus vienlaikus, tad tie tiks izpildīti secīgi, tādējādi veidojot pašu rindu.

Apskatīsim tuvāk pakalpojumus. Pakalpojumam ir pilnībā kvalificēts nosaukums, kurā vienmēr ir iekļauts rindas nosaukums. Tad priekšējam tīmekļa pakalpojumam būs nosaukums ok-web.group1.web.front. Un tiks izsaukts lietojumprogrammu servera pakalpojums, kuram tas piekļūst ok-app.group1.web.front. Katram pakalpojumam ir manifests, kurā ir norādīta visa nepieciešamā informācija izvietošanai uz konkrētām mašīnām: cik resursu patērē šis uzdevums, kāda konfigurācija tam nepieciešama, cik daudz replikām jābūt, rekvizīti šī pakalpojuma kļūmju apstrādei. Un pēc tam, kad pakalpojums ir ievietots tieši iekārtās, parādās tā gadījumi. Tie ir arī nosaukti nepārprotami — kā instances numurs un pakalpojuma nosaukums: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

Tas ir ļoti ērti: apskatot tikai skrienošā konteinera nosaukumu, mēs uzreiz varam daudz ko uzzināt.

Tagad pievērsīsimies tuvāk tam, ko šie gadījumi faktiski veic: uzdevumus.

Uzdevumu izolācijas klases

Visus uzdevumus OK (un, iespējams, visur) var iedalīt grupās:

• Īsa latentuma uzdevumi — prod. Šādiem uzdevumiem un pakalpojumiem ļoti svarīga ir atbildes aizkave (latents), cik ātri katrs no pieprasījumiem tiks apstrādāts sistēmā. Uzdevumu piemēri: tīmekļa frontes, kešatmiņas, lietojumprogrammu serveri, OLTP krātuve utt.
• Aprēķinu problēmas - partija. Šeit katra konkrētā pieprasījuma apstrādes ātrums nav svarīgs. Viņiem ir svarīgi, cik aprēķinu šis uzdevums veiks noteiktā (garā) laika periodā (caurlaidība). Tie būs visi MapReduce, Hadoop, mašīnmācīšanās, statistikas uzdevumi.
• Fona uzdevumi - dīkstāvē. Šādiem uzdevumiem ne latentums, ne caurlaidspēja nav īpaši svarīgas. Tas ietver dažādus testus, migrēšanu, pārrēķinus un datu konvertēšanu no viena formāta uz citu. No vienas puses, tie ir līdzīgi aprēķinātajiem, no otras puses, mums nav īsti svarīgi, cik ātri tie tiek pabeigti.

Apskatīsim, kā šādi uzdevumi patērē resursus, piemēram, centrālo procesoru.

Īsas kavēšanās uzdevumi. Šādam uzdevumam būs līdzīgs CPU patēriņa modelis:

No lietotāja tiek saņemts pieprasījums apstrādei, uzdevums sāk izmantot visus pieejamos CPU kodolus, apstrādā to, atgriež atbildi, gaida nākamo pieprasījumu un apstājas. Sanāca nākamais pieprasījums - atkal izvēlējāmies visu, kas bija, izrēķinājām un gaidām nākamo.

Lai garantētu minimālo latentumu šādam uzdevumam, mums ir jāņem maksimālie resursi, ko tas patērē, un jārezervē nepieciešamais kodolu skaits minionā (mašīnā, kas izpildīs uzdevumu). Tad mūsu problēmas rezervēšanas formula būs šāda:

alloc: cpu = 4 (max)

un, ja mums ir minionu mašīna ar 16 kodoliem, tad tajā var ievietot tieši četrus šādus uzdevumus. Mēs īpaši atzīmējam, ka šādu uzdevumu vidējais procesora patēriņš bieži ir ļoti zems - tas ir acīmredzams, jo ievērojamu daļu laika uzdevums gaida pieprasījumu un neko nedara.

Aprēķinu uzdevumi. To modelis būs nedaudz atšķirīgs:

Vidējais CPU resursu patēriņš šādiem uzdevumiem ir diezgan augsts. Bieži vien mēs vēlamies, lai aprēķina uzdevums tiktu izpildīts noteiktā laikā, tāpēc mums ir jārezervē minimālais tam nepieciešamo procesoru skaits, lai viss aprēķins tiktu pabeigts pieņemamā laikā. Tās rezervēšanas formula izskatīsies šādi:

alloc: cpu = [1,*)

"Lūdzu, novietojiet to uz miniona, kur ir vismaz viens brīvs kodols, un tad, cik daudz ir, tas aprīs visu."

Šeit lietošanas efektivitāte jau ir daudz labāka nekā uzdevumiem ar nelielu kavēšanos. Taču ieguvums būs daudz lielāks, ja apvienosiet abus uzdevumu veidus vienā miniona mašīnā un sadalīsiet tās resursus, atrodoties ceļā. Ja uzdevumam ar nelielu aizkavi ir nepieciešams procesors, tas to nekavējoties saņem, un, kad resursi vairs nav vajadzīgi, tie tiek pārsūtīti uz skaitļošanas uzdevumu, t.i., apmēram šādi:

Bet kā to darīt?

Vispirms apskatīsim prod un tā alloc: cpu = 4. Mums ir jārezervē četri kodoli. Docker palaišanā to var izdarīt divos veidos:

• Izmantojot opciju --cpuset=1-4, t.i., uzdevumam piešķiriet četrus konkrētus iekārtas kodolus.
• Lietot --cpuquota=400_000 --cpuperiod=100_000, piešķiriet procesora laika kvotu, t.i., norādiet, ka ik pēc 100 ms reāllaika uzdevums patērē ne vairāk kā 400 ms procesora laika. Tiek iegūti tie paši četri serdeņi.

Bet kura no šīm metodēm ir piemērota?

cpuset izskatās diezgan pievilcīgi. Uzdevumam ir četri atvēlēti kodoli, kas nozīmē, ka procesora kešatmiņas darbosies pēc iespējas efektīvāk. Tam ir arī negatīvā puse: mums būtu jāuzņemas uzdevums sadalīt aprēķinus pa neielādētajiem mašīnas kodoliem, nevis OS, un tas ir diezgan nenozīmīgs uzdevums, it īpaši, ja mēs cenšamies izvietot pakešu uzdevumus šādā ierīcē. mašīna. Pārbaudes ir pierādījušas, ka šeit labāk piemērota ir iespēja ar kvotu: tādējādi operētājsistēmai ir lielāka brīvība izvēlēties kodolu, lai pašreizējā brīdī veiktu uzdevumu, un procesora laiks tiek sadalīts efektīvāk.

Izdomāsim, kā Docker veikt rezervācijas, pamatojoties uz minimālo kodolu skaitu. Pakešu uzdevumu kvota vairs nav piemērojama, jo nav jāierobežo maksimums, pietiek tikai garantēt minimumu. Un šeit šī opcija labi iederas docker run --cpushares.

Vienojāmies, ja partijai ir nepieciešama garantija vismaz vienam kodolam, tad norādām --cpushares=1024, un, ja ir vismaz divi serdeņi, tad mēs norādām --cpushares=2048. CPU akcijas nekādā veidā netraucē procesora laika sadali, ja vien tā ir pietiekami. Tādējādi, ja prod pašlaik neizmanto visus savus četrus kodolus, nekas neierobežo pakešu uzdevumus, un tie var izmantot papildu procesora laiku. Bet situācijā, kad pietrūkst procesoru, ja prod būs iztērējis visus četrus kodolus un ir sasniedzis savu kvotu, atlikušais procesora laiks tiks sadalīts proporcionāli cpushares, t.i., trīs brīvo kodolu situācijā būs viens dots uzdevumam ar 1024 cpushares, bet pārējie divi tiks doti uzdevumam ar 2048 cpushares.

Bet ar kvotu un akciju izmantošanu nepietiek. Mums ir jāpārliecinās, ka uzdevums ar nelielu aizkavi saņem prioritāti pār pakešu uzdevumu, piešķirot procesora laiku. Bez šādas prioritāšu noteikšanas pakešu uzdevums aizņems visu procesora laiku brīdī, kad tas būs vajadzīgs prod. Docker palaišanā nav konteineru prioritāšu noteikšanas iespēju, taču noder Linux CPU plānotāja politikas. Jūs varat lasīt par tiem sīkāk šeit, un šī raksta ietvaros mēs tos īsi apskatīsim:

• SCHED_OTHER
  Pēc noklusējuma tiek saņemti visi parastie lietotāja procesi Linux datorā.
• SCHED_BATCH
  Paredzēts resursietilpīgiem procesiem. Uzliekot uzdevumu procesoram, tiek ieviests tā sauktais aktivizācijas sods: šāds uzdevums, visticamāk, saņems procesora resursus, ja to pašlaik izmanto uzdevums ar SCHED_OTHER
• SCHED_IDLE
  Fona process ar ļoti zemu prioritāti, pat zemāku par patīkamu -19. Mēs izmantojam mūsu atvērtā pirmkoda bibliotēku viens-nio, lai uzstādītu nepieciešamo politiku, startējot konteineru, zvanot

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

Bet pat tad, ja jūs neprogrammējat Java, to pašu var izdarīt, izmantojot komandu chrt:

chrt -i 0 $pid

Skaidrības labad apkoposim visus mūsu izolācijas līmeņus vienā tabulā:

Izolācijas klase
Alloc piemērs
Docker palaišanas iespējas
sched_setscheduler chrt*

Bikstīt
CPU = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

Partijas
CPU = [1, *)
--cpushares=1024
SCHED_BATCH

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

*Ja veicat chrt no konteinera iekšpuses, jums var būt nepieciešama sys_nice iespēja, jo pēc noklusējuma Docker noņem šo iespēju, startējot konteineru.

Taču uzdevumi patērē ne tikai procesoru, bet arī trafiku, kas tīkla uzdevuma latentumu ietekmē pat vairāk nekā nepareiza procesora resursu piešķiršana. Tāpēc mēs, protams, vēlamies iegūt tieši tādu pašu priekšstatu par satiksmi. Tas ir, kad ražošanas uzdevums nosūta dažas paketes tīklam, mēs ierobežojam maksimālo ātrumu (formula piešķirt: lan=[*,500 Mb/s) ), ar kuru prod to var izdarīt. Un partijai mēs garantējam tikai minimālo caurlaidspēju, bet neierobežojam maksimālo (formula piešķirt: lan=[10Mbps,*) ) Šajā gadījumā prod trafikam ir jāpiešķir prioritāte pār pakešu uzdevumiem.
Šeit Docker nav nekādu primitīvu, ko mēs varētu izmantot. Bet tas nāk mums palīgā Linux satiksmes kontrole. Ar disciplīnas palīdzību varējām sasniegt vēlamo rezultātu Hierarhiskā godīgas apkalpošanas līkne. Ar tās palīdzību mēs izšķiram divas trafika klases: augstas prioritātes prod un zemas prioritātes partijas/dīkstāves. Rezultātā izejošās trafika konfigurācija ir šāda:

šeit 1:0 ir hsfc disciplīnas “saknes qdisc”; 1:1 - hsfc bērnu klase ar kopējo joslas platuma ierobežojumu 8 Gbit/s, zem kuras ir novietotas visu konteineru bērnklases; 1:2 — hsfc pakārtotā klase ir kopīga visiem pakešu un dīkstāves uzdevumiem ar “dinamisku” ierobežojumu, kas ir aplūkots tālāk. Pārējās hsfc bērnu klases ir paredzētas pašlaik strādājošiem prod konteineriem ar ierobežojumiem, kas atbilst to manifestiem - 450 un 400 Mbit/s. Katrai hsfc klasei atkarībā no Linux kodola versijas tiek piešķirta qdisc rinda fq vai fq_code, lai izvairītos no pakešu zuduma trafika pārrāvumu laikā.

Parasti tc disciplīnas kalpo tikai izejošās satiksmes prioritātes noteikšanai. Bet mēs vēlamies arī piešķirt prioritāti ienākošajai trafikai - galu galā daži pakešu uzdevumi var viegli atlasīt visu ienākošo kanālu, saņemot, piemēram, lielu ieejas datu partiju map&reduce. Šim nolūkam mēs izmantojam moduli ifb, kas izveido ifbX virtuālo saskarni katram tīkla interfeisam un novirza ienākošo trafiku no saskarnes uz izejošo trafiku vietnē ifbX. Turklāt ifbX visas tās pašas disciplīnas darbojas, lai kontrolētu izejošo trafiku, kurai hsfc konfigurācija būs ļoti līdzīga:

Eksperimentu laikā mēs noskaidrojām, ka hsfc uzrāda vislabākos rezultātus, ja 1:2 neprioritārās pakešu/dīkstāves satiksmes klase minionu mašīnās ir ierobežota līdz noteiktai brīvai joslai. Pretējā gadījumā neprioritārā datplūsma pārāk daudz ietekmē ražošanas uzdevumu latentumu. miniond nosaka pašreizējo brīvā joslas platuma apjomu katru sekundi, mērot vidējo trafika patēriņu visiem konkrētā miniona prod-uzdevumiem un atņemot to no tīkla interfeisa joslas platuma ar nelielu rezervi, t.i.

Joslas tiek definētas neatkarīgi ienākošajai un izejošajai satiksmei. Un saskaņā ar jaunajām vērtībām miniond pārkonfigurē bezprioritātes klases ierobežojumu 1:2.

Tādējādi mēs ieviesām visas trīs izolācijas klases: prod, partijas un dīkstāves. Šīs klases lielā mērā ietekmē uzdevumu izpildes īpašības. Tāpēc nolēmām šo atribūtu novietot hierarhijas augšgalā, lai, apskatot hierarhiskās rindas nosaukumu, uzreiz būtu skaidrs, ar ko mums ir darīšana:

Visi mūsu draugi web и mūzika frontes tiek novietotas hierarhijā zem prod. Piemēram, zem partijas izvietosim pakalpojumu mūzikas katalogs, kas periodiski apkopo ierakstu katalogu no mp3 failu kopas, kas augšupielādēts Odnoklassniki. Dīkstāves pakalpojuma piemērs varētu būt mūzikas transformators, kas normalizē mūzikas skaļuma līmeni.

Atkal noņemot papildu rindiņas, pakalpojumu nosaukumus varam rakstīt precīzāk, pilna pakalpojuma nosaukuma beigās pievienojot uzdevuma izolācijas klasi: web.front.prod, katalogs.mūzika.partija, transformators.mūzika.dīkstāve.

Un tagad, aplūkojot pakalpojuma nosaukumu, mēs saprotam ne tikai to, kādu funkciju tas veic, bet arī tā izolācijas klasi, kas nozīmē tā kritiskumu utt.

Viss ir lieliski, bet ir viena rūgta patiesība. Nav iespējams pilnībā izolēt uzdevumus, kas darbojas vienā mašīnā.

Ko mums izdevās panākt: ja partija intensīvi patērē tikai CPU resursi, tad iebūvētais Linux CPU plānotājs savu darbu dara ļoti labi, un praktiski nav nekādas ietekmes uz prod uzdevumu. Bet, ja šis pakešu uzdevums sāk aktīvi strādāt ar atmiņu, tad jau parādās savstarpējā ietekme. Tas notiek tāpēc, ka prod. uzdevums tiek “izskalots” no procesora atmiņas kešatmiņām — tā rezultātā palielinās kešatmiņas izlaidumi, un procesors apstrādā prod. uzdevumu lēnāk. Šāds pakešu uzdevums var palielināt mūsu tipiskā produkta konteinera latentumu par 10%.

Trafika izolēšana ir vēl grūtāka, jo mūsdienu tīkla kartēs ir iekšēja pakešu rinda. Ja pakete no pakešu uzdevuma nokļūst vispirms, tad tā būs pirmā, kas tiks pārsūtīta pa kabeli, un ar to neko nevar darīt.

Turklāt mums līdz šim ir izdevies tikai atrisināt TCP trafika prioritātes problēmu: hsfc pieeja nedarbojas UDP. Un pat TCP trafika gadījumā, ja pakešu uzdevums ģenerē daudz trafika, tas arī rada aptuveni 10% pieaugumu prod uzdevuma aizkavē.

kļūdu tolerance

Viens no mērķiem, izstrādājot vienu mākoņu, bija uzlabot Odnoklassniki kļūdu toleranci. Tāpēc tālāk es vēlētos sīkāk apsvērt iespējamos kļūmju un negadījumu scenārijus. Sāksim ar vienkāršu scenāriju – konteinera kļūme.

Pats konteiners var neizdoties vairākos veidos. Tas varētu būt kāds eksperiments, kļūda vai kļūda manifestā, kuras dēļ ražošanas uzdevums sāk patērēt vairāk resursu, nekā norādīts manifestā. Mums bija gadījums: izstrādātājs ieviesa vienu sarežģītu algoritmu, daudzkārt to pārstrādāja, pārdomāja sevi un kļuva tik apmulsis, ka galu galā problēma tika atrisināta ļoti nenozīmīgā veidā. Un tā kā ražošanas uzdevumam ir augstāka prioritāte nekā visiem citiem tajos pašos minionos, tas sāka patērēt visus pieejamos procesora resursus. Šajā situācijā izolācija vai drīzāk CPU laika kvota izglāba situāciju. Ja uzdevumam tiek piešķirta kvota, uzdevums nepatērēs vairāk. Tāpēc sērijveida un citi prod uzdevumi, kas darbojās tajā pašā mašīnā, neko nepamanīja.

Otra iespējamā problēma ir konteinera krišana. Un šeit restartēšanas politikas mūs izglābj, visi tās zina, pats Docker paveic lielisku darbu. Gandrīz visiem ražošanas uzdevumiem ir vienmēr restartēšanas politika. Dažreiz mēs izmantojam on_failure pakešu uzdevumiem vai produktu konteineru atkļūdošanai.

Ko jūs varat darīt, ja viss minions nav pieejams?

Acīmredzot palaidiet konteineru citā mašīnā. Interesantā daļa šeit ir par to, kas notiek ar konteineram piešķirto IP adresi(-ēm).

Mēs varam piešķirt konteineriem tādas pašas IP adreses kā minionu mašīnām, kurās šie konteineri darbojas. Pēc tam, kad konteiners tiek palaists citā datorā, tā IP adrese mainās, un visiem klientiem ir jāsaprot, ka konteiners ir pārvietots, un tagad viņiem ir jādodas uz citu adresi, kam nepieciešams atsevišķs Service Discovery pakalpojums.

Pakalpojumu atklāšana ir ērta. Pakalpojumu reģistra organizēšanai tirgū ir daudz risinājumu ar dažādu kļūdu tolerances pakāpi. Bieži vien šādos risinājumos tiek ieviesta slodzes balansētāja loģika, tiek uzglabāta papildu konfigurācija KV krātuves veidā utt.
Tomēr mēs vēlētos izvairīties no nepieciešamības ieviest atsevišķu reģistru, jo tas nozīmētu kritiskas sistēmas ieviešanu, ko izmanto visi ražošanas pakalpojumi. Tas nozīmē, ka tas ir potenciāls neveiksmes punkts, un jums ir jāizvēlas vai jāizstrādā ļoti kļūmēm izturīgs risinājums, kas acīmredzami ir ļoti sarežģīts, laikietilpīgs un dārgs.

Un vēl viens liels trūkums: lai mūsu vecā infrastruktūra strādātu ar jauno, mums būtu jāpārraksta pilnīgi visi uzdevumi, lai izmantotu kaut kādu Service Discovery sistēmu. Ir daudz darba, un dažās vietās tas ir gandrīz neiespējami, ja runa ir par zema līmeņa ierīcēm, kas darbojas OS kodola līmenī vai tieši ar aparatūru. Šīs funkcionalitātes ieviešana, izmantojot izveidotos risinājumu modeļus, piemēram, blakusvāģa vietām nozīmētu papildu slodzi, citviet - darbības sarežģījumus un papildu atteices scenārijus. Mēs nevēlējāmies sarežģīt lietas, tāpēc nolēmām pakalpojumu Discovery izmantošanu padarīt neobligātu.

Vienā mākonī IP seko konteineram, t.i., katrai uzdevuma instancei ir sava IP adrese. Šī adrese ir “statiska”: tā tiek piešķirta katram gadījumam, kad pakalpojums pirmo reizi tiek nosūtīts uz mākoni. Ja pakalpojumam tā darbības laikā bija atšķirīgs gadījumu skaits, tad galu galā tam tiks piešķirts tik daudz IP adrešu, cik bija maksimālais gadījumu skaits.

Pēc tam šīs adreses nemainās: tās tiek piešķirtas vienreiz un turpina pastāvēt visu pakalpojuma kalpošanas laiku ražošanā. IP adreses seko konteineriem visā tīklā. Ja konteiners tiek nodots citam minionam, tad adrese tam sekos.

Tādējādi pakalpojuma nosaukuma piesaiste tā IP adrešu sarakstam mainās ļoti reti. Ja vēlreiz aplūkojat pakalpojumu gadījumu nosaukumus, kurus minējām raksta sākumā (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), mēs pamanīsim, ka tie atgādina DNS izmantotos FQDN. Tieši tā, lai pakalpojumu gadījumu nosaukumus kartētu ar to IP adresēm, mēs izmantojam DNS protokolu. Turklāt šis DNS atgriež visas rezervētās IP adreses visiem konteineriem — gan tiem, kas darbojas, gan apturēti (pieņemsim, ka tiek izmantotas trīs kopijas, un mums tur ir rezervētas piecas adreses — visas piecas tiks atgrieztas). Klienti, saņēmuši šo informāciju, mēģinās izveidot savienojumu ar visām piecām replikām un tādējādi noteikt tās, kas darbojas. Šī pieejamības noteikšanas iespēja ir daudz uzticamāka; tā neietver ne DNS, ne pakalpojumu atklāšanu, kas nozīmē, ka nav grūti atrisināt problēmu, nodrošinot šo sistēmu informācijas atbilstību un kļūdu toleranci. Turklāt kritiskajos pakalpojumos, no kuriem ir atkarīga visa portāla darbība, mēs vispār nevaram izmantot DNS, bet vienkārši ievadiet konfigurācijā IP adreses.

Šādas IP pārsūtīšanas īstenošana aiz konteineriem var nebūt nenozīmīga — un mēs apskatīsim, kā tas darbojas, izmantojot šādu piemēru:

Pieņemsim, ka viena mākoņa meistars dod komandu minionam M1 palaist 1.ok-web.group1.web.front.prod ar adresi 1.1.1.1. Strādā uz miniona BIRD, kas reklamē šo adresi īpašiem serveriem maršruta atstarotājs. Pēdējiem ir BGP sesija ar tīkla aparatūru, kurā tiek tulkots M1.1.1.1 adreses 1 maršruts. M1 maršrutē paketes konteinerā, izmantojot Linux. Ir trīs maršruta atspoguļošanas serveri, jo šī ir ļoti kritiska viena mākoņa infrastruktūras daļa - bez tiem tīkls vienā mākonī nedarbosies. Mēs ievietojam tos dažādos plauktos, ja iespējams, atrodas dažādās datu centra telpās, lai samazinātu iespēju, ka visas trīs atteices vienlaicīgi.

Tagad pieņemsim, ka savienojums starp viena mākoņa meistaru un M1 minionu ir zudis. Viena mākoņa meistars tagad rīkosies, pieņemot, ka M1 ir pilnībā izgāzies. Tas nozīmē, ka tas dos komandu M2 minionam palaist web.group1.web.front.prod ar to pašu adresi 1.1.1.1. Tagad tīklā 1.1.1.1 ir divi konfliktējoši maršruti: pa M1 un M2. Lai atrisinātu šādus konfliktus, mēs izmantojam Multi Exit Discriminator, kas norādīts BGP paziņojumā. Šis ir skaitlis, kas parāda reklamētā maršruta svaru. Starp konfliktējošajiem maršrutiem tiks atlasīts maršruts ar zemāku MED vērtību. Viena mākoņa meistars atbalsta MED kā konteinera IP adrešu neatņemamu sastāvdaļu. Pirmo reizi adrese tiek rakstīta ar pietiekami lielu MED = 1 000 000. Šādas avārijas konteinera pārsūtīšanas situācijā kapteinis samazina MED, un M2 jau saņems komandu reklamēt adresi 1.1.1.1 ar MED = 999 999. Instancē, kas darbojas uz M1, paliks šajā gadījumā savienojuma nav, un viņa tālākais liktenis mūs maz interesē, līdz tiks atjaunota saikne ar meistaru, kad viņš tiks apturēts kā vecs.

Nelaimes gadījumi

Visas datu centru pārvaldības sistēmas vienmēr pieņemami apstrādā nelielas kļūmes. Konteinera pārplūde ir norma gandrīz visur.

Apskatīsim, kā mēs rīkojamies ārkārtas situācijās, piemēram, strāvas padeves pārtraukuma gadījumā vienā vai vairākās datu centra telpās.

Ko negadījums nozīmē datu centra vadības sistēmai? Pirmkārt, tā ir liela vienreizēja daudzu iekārtu kļūme, un vadības sistēmai vienlaikus ir jāmigrē daudz konteineru. Bet, ja katastrofa ir ļoti liela mēroga, tad var gadīties, ka visus uzdevumus nevar pārdalīt citiem minioniem, jo ​​datu centra resursu ietilpība nokrītas zem 100% no slodzes.

Bieži negadījumus pavada kontroles slāņa atteice. Tas var notikt tā aprīkojuma kļūmes dēļ, bet biežāk tāpēc, ka avārijas netiek pārbaudītas, un palielinātās slodzes dēļ nokrīt pats kontroles slānis.

Ko jūs varat darīt ar šo visu?

Masveida migrācija nozīmē, ka infrastruktūrā notiek liels skaits darbību, migrāciju un izvietošanu. Katrai migrācijai var būt nepieciešams zināms laiks, lai piegādātu un izsaiņotu konteineru attēlus minioniem, palaistu un inicializētu konteinerus utt. Tāpēc ir vēlams, lai svarīgāki uzdevumi tiktu palaisti pirms mazāk svarīgiem.

Vēlreiz apskatīsim mums pazīstamo pakalpojumu hierarhiju un mēģināsim izlemt, kurus uzdevumus vēlamies izpildīt vispirms.

Protams, tie ir procesi, kas ir tieši saistīti ar lietotāju pieprasījumu apstrādi, t.i., prod. Mēs to norādām ar izvietojuma prioritāte — numurs, ko var piešķirt rindai. Ja rindai ir augstāka prioritāte, tās pakalpojumi tiek novietoti vispirms.

Prod mēs piešķiram augstākas prioritātes, 0; uz partijas - nedaudz zemāks, 100; tukšgaitā - vēl zemāk, 200. Prioritātes tiek piemērotas hierarhiski. Visiem uzdevumiem, kas atrodas zemāk hierarhijā, būs atbilstoša prioritāte. Ja mēs vēlamies, lai prod kešatmiņas palaistu pirms priekšgaliem, mēs piešķiram prioritātes kešatmiņai = 0 un priekšējām apakšrindām = 1. Ja, piemēram, vēlamies, lai galvenais portāls tiktu palaists vispirms no priekšpuses un tikai mūzikas fronte. tad pēdējam varam piešķirt zemāku prioritāti - 10.

Nākamā problēma ir resursu trūkums. Tātad sabojājās liels daudzums aprīkojuma, veselas datu centra zāles, un mēs atsākām tik daudz pakalpojumu, ka tagad visiem nepietiek resursu. Jums ir jāizlemj, kurus uzdevumus upurēt, lai nodrošinātu galveno kritisko pakalpojumu darbību.

Atšķirībā no izvietojuma prioritātes, mēs nevaram bez izšķirības upurēt visus pakešu uzdevumus; daži no tiem ir svarīgi portāla darbībai. Tāpēc mēs esam izcēluši atsevišķi pirmpirkuma prioritāte uzdevumus. Ja tas ir novietots, augstākas prioritātes uzdevums var novērst, t.i., apturēt zemākas prioritātes uzdevumu, ja vairs nav brīvu minionu. Šādā gadījumā uzdevums ar zemu prioritāti, iespējams, paliks neizvietots, t.i., tam vairs nebūs piemērota miniona ar pietiekami daudz brīvu resursu.

Mūsu hierarhijā ir ļoti vienkārši norādīt priekšpirkuma prioritāti tā, lai ražošanas un pakešu uzdevumi novērstu vai apturētu dīkstāves uzdevumus, bet ne viens otru, norādot dīkstāves prioritāti, kas vienāda ar 200. Tāpat kā izvietojuma prioritātes gadījumā, mēs var izmantot mūsu hierarhiju, lai aprakstītu sarežģītākus noteikumus. Piemēram, norādīsim, ka mēs upurējam mūzikas funkciju, ja mums nav pietiekami daudz resursu galvenajam tīmekļa portālam, iestatot attiecīgo mezglu prioritāti zemāku: 10.

Visas līdzstrāvas avārijas

Kāpēc viss datu centrs var neizdoties? Elements. Bija labs ieraksts viesuļvētra ietekmēja datu centra darbu. Elementus var uzskatīt par bezpajumtniekiem, kuri savulaik sadedzināja optiku kolektorā, un datu centrs pilnībā zaudēja kontaktu ar citām vietām. Neveiksmes cēlonis var būt arī cilvēcisks faktors: operators izdos tādu komandu, ka viss datu centrs nokritīs. Tas varētu notikt lielas kļūdas dēļ. Kopumā datu centru sabrukšana nav nekas neparasts. Pie mums tas notiek reizi dažos mēnešos.

Un tas ir tas, ko mēs darām, lai neļautu nevienam čivināt #alive.

Pirmā stratēģija ir izolācija. Katrs viena mākoņa gadījums ir izolēts un var pārvaldīt mašīnas tikai vienā datu centrā. Tas nozīmē, ka mākoņa zudums kļūdu vai nepareizu operatora komandu dēļ ir tikai viena datu centra zaudējums. Mēs esam tam gatavi: mums ir atlaišanas politika, saskaņā ar kuru lietojumprogrammas un datu kopijas atrodas visos datu centros. Mēs izmantojam defektu izturīgas datu bāzes un periodiski pārbaudām, vai nav kļūdu.
Kopš šodienas mums ir četri datu centri, kas nozīmē četrus atsevišķus, pilnībā izolētus viena mākoņa gadījumus.

Šī pieeja ne tikai pasargā no fiziskas kļūmes, bet arī var aizsargāt pret operatora kļūdām.

Ko vēl var darīt ar cilvēcisko faktoru? Kad operators dod mākonim kādu dīvainu vai potenciāli bīstamu komandu, viņam pēkšņi var lūgt atrisināt nelielu problēmu, lai redzētu, cik labi viņš domā. Piemēram, ja šī ir sava veida daudzu kopiju masveida apturēšana vai vienkārši dīvaina komanda - reprodukciju skaita samazināšana vai attēla nosaukuma maiņa, nevis tikai versijas numurs jaunajā manifestā.

Rezultāti

Viena mākoņa atšķirīgās iezīmes:

• Pakalpojumu un konteineru hierarhiskā un vizuālā nosaukšanas shēma, kas ļauj ļoti ātri noskaidrot, kas ir uzdevums, ar ko tas attiecas un kā tas darbojas un kas par to ir atbildīgs.
• Mēs pielietojam mūsu ražošanas un partijas kombinēšanas tehnikauzdevumus minioniem, lai uzlabotu mašīnu koplietošanas efektivitāti. Cpuset vietā mēs izmantojam CPU kvotas, koplietošanu, CPU plānotāja politikas un Linux QoS.
• Nebija iespējams pilnībā izolēt konteinerus, kas darbojas vienā un tajā pašā mašīnā, bet to savstarpējā ietekme saglabājas 20% robežās.
• Pakalpojumu organizēšana hierarhijā palīdz nodrošināt automātisku atkopšanu pēc avārijas izvietošanas un pirmpirkuma prioritātes.

FAQ

Kāpēc mēs nepieņēmām gatavu risinājumu?

• Dažādām uzdevumu izolācijas klasēm ir nepieciešama atšķirīga loģika, ja tās tiek novietotas uz minioniem. Ja ražošanas uzdevumus var ievietot, vienkārši rezervējot resursus, tad ir jāievieto pakešu un dīkstāves uzdevumi, izsekojot faktisko resursu izmantošanu minionu mašīnās.
• Nepieciešamība ņemt vērā resursus, ko patērē uzdevumi, piemēram:
  • tīkla joslas platums;
  • disku veidi un “vārpstas”.
• Nepieciešamība norādīt dienestu prioritātes avārijas seku likvidēšanas laikā, resursu komandu tiesības un kvotas, kas tiek risināta, izmantojot hierarhiskas rindas vienā mākonī.
• Nepieciešamība pēc cilvēka nosaukumiem konteineriem, lai samazinātu reaģēšanas laiku uz negadījumiem un starpgadījumiem
• Vienreizējas plaši izplatītas pakalpojumu atklāšanas ieviešanas neiespējamība; nepieciešamība ilgstoši pastāvēt līdzās ar uzdevumiem, kas mitināti aparatūras resursdatoros - kaut kas tiek atrisināts ar “statiskām” IP adresēm, kas seko konteineriem, un līdz ar to nepieciešamība pēc unikālas integrācijas ar lielu tīkla infrastruktūru.

Visas šīs funkcijas prasītu būtiskas esošo risinājumu modifikācijas, lai tās būtu mums piemērotas, un, novērtējot darba apjomu, sapratām, ka varam izstrādāt savu risinājumu ar aptuveni tādām pašām darbaspēka izmaksām. Taču jūsu risinājums būs daudz vieglāk vadāms un attīstāms – tas nesatur nevajadzīgas abstrakcijas, kas atbalsta funkcionalitāti, kas mums nav nepieciešama.

Tiem, kas lasa pēdējās rindiņas, paldies par pacietību un uzmanību!

Avots: www.habr.com