Hiji-awan - tingkat puseur data OS di Odnoklassniki

Aloha, jalma! Nami abdi Oleg Anastasyev, abdi damel di Odnoklassniki dina tim Platform. Sareng sajaba ti kuring, aya seueur hardware anu damel di Odnoklassniki. Simkuring gaduh opat puseur data kalawan ngeunaan 500 rak kalawan leuwih ti 8 sarébu server. Dina titik nu tangtu, urang sadar yén bubuka sistem manajemen anyar bakal ngidinan urang pikeun muka parabot leuwih éfisién, mempermudah manajemén aksés, ngajadikeun otomatis (deui) distribusi sumberdaya komputasi, nyepetkeun peluncuran jasa anyar, sarta nyepetkeun réspon. kana kacilakaan skala badag.

Naon asalna tina eta?

Di sagigireun kuring jeung kebat hardware, aya ogé jalma anu gawé bareng hardware ieu: insinyur anu lokasina langsung di puseur data; networkers anu nyetél software jaringan; administrator, atawa SREs, anu nyadiakeun resiliency infrastruktur; sarta tim ngembangkeun, unggal sahijina tanggung jawab bagian tina fungsi portal urang. Parangkat lunak anu aranjeunna ciptakeun damel sapertos kieu:

Paménta pangguna ditampi duanana dina payuneun portal utama www.ok.ru, sareng anu sanésna, contona dina payuneun API musik. Pikeun ngolah logika bisnis, aranjeunna nyauran server aplikasi, anu, nalika ngolah pamundut, nyauran microservices khusus anu diperyogikeun - hiji-grafik (grafik sambungan sosial), cache pangguna (cache profil pangguna), jsb.

Unggal jasa ieu disebarkeun dina seueur mesin, sareng masing-masing gaduh pamekar anu tanggung jawab pikeun fungsi modul, operasi sareng pamekaran téknologi. Sadaya jasa ieu dijalankeun dina server hardware, sareng dugi ka ayeuna urang ngaluncurkeun persis hiji tugas per server, nyaéta khusus pikeun tugas khusus.

Почему так? У такого подхода было несколько плюсов:

• Lega manajemén massa. Hayu urang nyebutkeun hiji tugas merlukeun sababaraha perpustakaan, sababaraha setélan. Lajeng server ditugaskeun persis hiji grup husus, kawijakan cfengine pikeun grup ieu digambarkeun (atawa eta geus dijelaskeun), sarta konfigurasi ieu centrally tur otomatis digulung kaluar ka sadaya server di grup ieu.
• Disederhanakeun diagnostik. Hayu urang nempo kana ngaronjat beban dina processor sentral jeung nyadar yén beban ieu ngan bisa dihasilkeun ku tugas anu dijalankeun dina processor hardware ieu. Pilarian pikeun batur pikeun ngalepatkeun ends pisan gancang.
• Disederhanakeun ngawaskeun. Upami aya anu lepat sareng server, monitor ngalaporkeun éta, sareng anjeun terang saha anu kedah disalahkeun.

Ladenan anu diwangun ku sababaraha réplika dialokasikeun sababaraha server - hiji pikeun masing-masing. Lajeng sumberdaya komputasi pikeun layanan ieu dialokasikeun pisan basajan: jumlah server jasa boga, jumlah maksimum sumberdaya eta bisa meakeun. "Gampang" di dieu henteu hartosna yén éta gampang dianggo, tapi dina harti yén alokasi sumberdaya dilakukeun sacara manual.

Pendekatan ieu ogé ngamungkinkeun urang pikeun ngalakukeun konfigurasi beusi husus под задачу, выполняющуюся на этом сервере. Если задача хранит большие объёмы данных, то мы используем 4U-сервер с шасси на 38 дисков. Если задача чисто вычислительная, то можем купить более дешёвый 1U-сервер. Это эффективно с точки зрения вычислительных ресурсов. В том числе такой подход позволяет нам использовать в четыре раза меньше машин при нагрузке, сопоставимой с одной дружественной нам социальной сетью.

Такая эффективность использования вычислительных ресурсов должна обеспечить и эффективность экономическую, если исходить из посылки, что самое дорогое — это серверы. Долгое время дороже всего стоило именно железо, и мы вложили много сил в уменьшение цены железа, придумывая алгоритмы обеспечения отказоустойчивости для снижения требований к надёжности оборудования. И сегодня мы дошли до стадии, на которой цена сервера уже перестала быть определяющей. Если не рассматривать свежайшую экзотику, то конкретная конфигурация серверов в стойке не имеет значения. Сейчас у нас возникла другая проблема — цена занимаемого сервером места в дата-центре, т. е. места в стойке.

Nyadar yén ieu masalahna, urang mutuskeun pikeun ngitung sabaraha efektif kami ngagunakeun rak.
Kami nyandak harga pangladén pangkuatna tina anu dibenerkeun sacara ékonomis, ngitung sabaraha server sapertos anu tiasa kami tempatkeun dina rak, sabaraha tugas anu bakal kami jalankeun dumasar kana modél lami "hiji server = hiji tugas" sareng sabaraha sapertos kitu. tugas bisa ngamangpaatkeun parabot. Aranjeunna ngitung sareng ngeclak cipanon. Tétéla efisiensi urang dina ngagunakeun rak téh ngeunaan 11%. Kacindekan jelas: urang kedah ningkatkeun efisiensi ngagunakeun pusat data. Éta sigana yén solusina écés: anjeun kedah ngajalankeun sababaraha pancén dina hiji server sakaligus. Tapi ieu dimana kasusah dimimitian.

Konfigurasi massa janten nyirorot leuwih pajeulit - ayeuna teu mungkin keur napelkeun salah sahiji grup kana server a. Barina ogé, ayeuna sababaraha pancén paréntah anu béda tiasa diluncurkeun dina hiji server. Sajaba, konfigurasi bisa jadi conflicting pikeun aplikasi béda. Diagnosis ogé janten langkung rumit: upami anjeun ningali kanaékan CPU atanapi konsumsi disk dina server, anjeun henteu terang tugas mana anu nyababkeun masalah.

Tapi hal utama nyaéta yén teu aya isolasi antara tugas anu dijalankeun dina mesin anu sami. Di dieu, contona, mangrupa grafik tina waktu respon rata-rata tugas server saméméh jeung sanggeus aplikasi komputasi sejen diawalan dina server sarua, dina no way patali jeung kahiji - waktu respon tina tugas utama geus ngaronjat sacara signifikan.

Jelas, anjeun kedah ngajalankeun tugas boh dina wadah atanapi dina mesin virtual. Kusabab ampir sakabéh tugas urang ngajalankeun dina hiji OS (Linux) atawa diadaptasi pikeun eta, urang teu perlu ngarojong loba sistem operasi béda. Sasuai, virtualization henteu diperlukeun; alatan overhead tambahan, éta bakal kirang efisien ti containerization.

Salaku palaksanaan wadah pikeun ngajalankeun tugas langsung dina server, Docker mangrupakeun calon alus: Gambar sistem file ngajawab masalah sareng konfigurasi conflicting ogé. Kanyataan yén gambar tiasa diwangun ku sababaraha lapisan ngamungkinkeun urang sacara signifikan ngirangan jumlah data anu diperyogikeun pikeun nyebarkeunana dina infrastruktur, misahkeun bagian umum kana lapisan dasar anu misah. Lajeng lapisan dasar (jeung paling voluminous) bakal sindangan cukup gancang sapanjang sakabéh infrastruktur, sarta pikeun nganteurkeun loba tipena béda aplikasi jeung versi, ngan lapisan leutik bakal perlu ditransfer.

Tambih Deui, pendaptaran anu siap-siap sareng tag gambar di Docker masihan kami primitif anu siap-siap pikeun versi sareng ngirim kode ka produksi.

Docker, sapertos téknologi anu sami, nyayogikeun kami sababaraha tingkat isolasi wadahna tina kotak. Contona, isolasi memori - unggal wadahna dibéré wates dina pamakéan memori mesin, saluareun eta moal meakeun. Anjeun ogé tiasa ngasingkeun wadah dumasar kana pamakean CPU. Pikeun urang, kumaha oge, insulasi baku teu cukup. Tapi langkung seueur ngeunaan éta di handap.

Ngajalankeun wadah langsung dina server mangrupikeun bagian tina masalah. Bagian anu sanés aya hubunganana sareng wadah wadah dina server. Anjeun kedah ngartos wadah mana anu tiasa disimpen dina server mana. Ieu sanés tugas anu gampang, sabab wadahna kedah ditempatkeun dina pangladén salaku padet-gancang tanpa ngirangan lajuna. panempatan sapertos ogé tiasa hésé ti sudut pandang kasabaran sesar. Sering urang hoyong nempatkeun réplika tina jasa anu sami dina rak anu béda-béda atanapi bahkan di kamar anu béda-béda pusat data, ku kituna upami rak atanapi kamar gagal, urang henteu langsung kaleungitan sadaya réplika jasa.

Ngadistribusikaeun wadahna sacara manual sanés pilihan nalika anjeun gaduh 8 rébu server sareng 8-16 rébu wadah.

Salaku tambahan, kami hoyong masihan pamekar langkung mandiri dina alokasi sumberdaya supados aranjeunna tiasa nyayogikeun jasa dina produksi sorangan, tanpa bantosan ku administrator. Dina waktos anu sami, urang hoyong ngajaga kontrol supados sababaraha jasa minor henteu bakal meakeun sadaya sumber daya pusat data urang.

Jelas, urang peryogi lapisan kontrol anu bakal ngalakukeun ieu sacara otomatis.

Sangkan datang ka gambar basajan tur kaharti yén sakabéh arsiték adore: tilu kuadrat.

master hiji-awan mangrupakeun klaster failover jawab orchestration awan. Pamekar ngirimkeun manifest ka master, anu ngandung sadaya inpormasi anu dipikabutuh pikeun nyayogikeun jasa. Dumasar kana éta, master masihan paréntah ka minions anu dipilih (mesin anu dirancang pikeun ngajalankeun wadah). Minions gaduh agén kami, anu nampi paréntahna, ngaluarkeun paréntahna ka Docker, sareng Docker ngonpigurasikeun kernel linux pikeun ngaluncurkeun wadah anu saluyu. Salian ngalaksanakeun paréntah, agén terus-terusan ngalaporkeun ka master ngeunaan parobihan dina kaayaan mesin minion sareng wadah anu dijalankeun dina éta.

Alokasi Sumberdaya

А теперь разберёмся с задачей более сложного распределения ресурсов для множества миньонов.

Sumberdaya komputasi dina hiji awan nyaéta:

• Jumlah kakuatan processor dikonsumsi ku tugas husus.
• Jumlah memori sadia pikeun tugas.
• Lalu lintas jaringan. Masing-masing minions gaduh antarmuka jaringan khusus sareng rubakpita kawates, janten mustahil pikeun ngadistribusikaeun tugas tanpa ngitung jumlah data anu dikirimkeun dina jaringan.
• Disk. Salaku tambahan, écés, pikeun rohangan pikeun tugas-tugas ieu, kami ogé nyayogikeun jinis disk: HDD atanapi SSD. Disk tiasa ngalayanan sajumlah pamundut per detik - IOPS. Ku alatan éta, pikeun tugas anu ngahasilkeun leuwih IOPS ti hiji disk tunggal, urang ogé allocate "spindles" - nyaeta, alat disk nu kudu ditangtayungan éksklusif pikeun tugas.

Teras pikeun sababaraha jasa, contona pikeun cache-pamaké, urang tiasa ngarékam sumberdaya anu dikonsumsi ku cara kieu: 400 inti prosesor, 2,5 TB mémori, 50 Gbit / s lalu lintas dina dua arah, 6 TB rohangan HDD anu aya dina 100 spindles. Atanapi dina bentuk anu langkung akrab sapertos kieu:

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

Sumberdaya jasa cache-pamaké ngan ukur nganggo sabagian tina sadaya sumber daya anu aya dina infrastruktur produksi. Ku alatan éta, abdi hoyong mastikeun yén ujug-ujug, alatan kasalahan operator atawa henteu, pamaké-cache teu meakeun leuwih sumberdaya ti anu disadiakeun pikeun eta. Hartina, urang kudu ngawatesan sumberdaya. Tapi naon anu urang tiasa dasi kuota?

Hayu urang uih deui ka diagram interaksi komponén anu saderhana pisan sareng ngagambar deui kalayan langkung rinci - sapertos kieu:

Naon nyekel panon anjeun:

• Web frontend sareng musik nganggo klaster terasing tina server aplikasi anu sami.
• Urang bisa ngabedakeun lapisan logis nu klaster ieu milik: fronts, caches, neundeun data jeung lapisan manajemén.
• Фронтенд неоднороден, это разные функциональные подсистемы.
• Кеши тоже можно раскидать по подсистеме, данные которой они кешируют.

Hayu urang ngagambar deui gambarna:

Bah! Sumuhun, urang ningali hiji hirarki! Ieu ngandung harti yén anjeun bisa ngadistribusikaeun sumberdaya dina sakumpulan gedé: napelkeun pamekar jawab hiji titik hirarki ieu pakait jeung subsistem fungsi (kawas "musik" dina gambar), sarta ngagantelkeun kuota ka tingkat sarua hirarki nu. Hierarki ieu ogé ngamungkinkeun urang pikeun ngatur jasa sacara langkung fleksibel pikeun ngagampangkeun manajemén. Salaku conto, urang ngabagi sadaya wéb, sabab ieu mangrupikeun grup pangladén anu ageung pisan, kana sababaraha grup anu langkung alit, dipidangkeun dina gambar salaku group1, group2.

Ku ngahapus garis tambahan, urang tiasa nyerat unggal titik gambar dina bentuk anu langkung datar: group1.web.hareup, api.music.hareup, user-cache.cache.

Ieu kumaha urang datang ka konsép "antrian hirarki". Mibanda ngaran kawas "group1.web.front". Kuota pikeun sumber daya sareng hak pangguna ditugaskeun ka éta. Kami bakal masihan jalma ti DevOps hak pikeun ngirim jasa ka antrian, sareng karyawan sapertos kitu tiasa ngaluncurkeun hiji hal dina antrian, sareng jalma ti OpsDev bakal gaduh hak admin, sareng ayeuna anjeunna tiasa ngatur antrian, napelkeun jalma di dinya, masihan hak jalma ieu, jsb jasa ngajalankeun on antrian ieu bakal ngajalankeun dina kuota antrian urang. Upami kuota komputasi antrian henteu cekap pikeun ngaéksekusi sadaya jasa sakaligus, maka aranjeunna bakal dieksekusi sacara berurutan, sahingga ngabentuk antrian sorangan.

Рассмотрим сервисы подробнее. У сервиса есть полное имя, которое всегда включает в себя имя очереди. Тогда сервис web фронта будет иметь имя ok-web.group1.web.front. А сервис сервера приложений, к которому он обращается, станет именоваться ok-app.group1.web.front. Masing-masing jasa ngagaduhan manifest, anu netepkeun sadaya inpormasi anu dipikabutuh pikeun panempatan dina mesin khusus: sabaraha sumber daya anu dianggo pikeun tugas ieu, konfigurasi naon anu diperyogikeun, sabaraha réplika kedah aya, sipat pikeun nanganan gagal jasa ieu. Sareng saatos jasa disimpen langsung dina mesin, instansi na muncul. Éta ogé dingaranan sacara jelas - salaku nomer conto sareng nami jasa: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

Ieu pisan merenah: ku ningali ngan dina ngaran wadahna ngajalankeun, urang bisa langsung manggihan loba.

Ayeuna hayu urang ningal langkung caket kana naon anu leres-leres dilaksanakeun ku instansi ieu: tugas.

Kelas Isolasi Tugas

Sadaya tugas dina OK (sareng, sigana, dimana-mana) tiasa dibagi kana grup:

• Tugas Latency pondok - prod. Для таких задач и сервисов очень важна задержка ответа (latency), как быстро каждый из запросов будет обработан системой. Примеры задач: web фронты, кеши, серверы приложений, OLTP хранилища и т. п.
• Masalah itungan - bets. Di dieu, speed processing unggal pamundut husus teu penting. Pikeun aranjeunna, penting sabaraha itungan tugas ieu bakal dilakukeun dina jangka waktu anu tangtu (panjang) (throughput). Ieu bakal janten tugas MapReduce, Hadoop, pembelajaran mesin, statistik.
• Tugas latar - dianggurkeun. Pikeun tugas sapertos kitu, teu latency atanapi throughput penting pisan. Ieu ngawengku rupa tés, migrasi, recalculations, sarta konversi data tina hiji format ka nu sejen. Di hiji sisi, aranjeunna sami sareng anu diitung, di sisi anu sanés, éta henteu penting pisan pikeun urang kumaha gancangna réngsé.

Hayu urang tingali kumaha tugas sapertos meakeun sumber daya, contona, prosesor sentral.

Tugas reureuh pondok. Tugas sapertos kitu bakal ngagaduhan pola konsumsi CPU anu sami sareng ieu:

Paménta ti pangguna ditampi pikeun ngolah, tugas mimiti nganggo sadaya inti CPU anu sayogi, ngolah éta, ngabalikeun réspon, ngantosan pamundut salajengna sareng eureun. Paménta salajengna sumping - deui kami milih sadayana anu aya, ngitung éta, sareng ngantosan anu salajengna.

Pikeun ngajamin latency minimum pikeun tugas sapertos kitu, urang kedah nyandak sumber daya maksimum anu dikonsumsi sareng cagar jumlah inti anu diperyogikeun dina antek (mesin anu bakal ngalaksanakeun tugas). Lajeng rumus reservasi pikeun masalah urang bakal kieu:

alloc: cpu = 4 (max)

sarta lamun urang boga mesin minion kalawan 16 cores, lajeng persis opat tugas misalna bisa disimpen dina eta. Urang utamana dicatet yén konsumsi processor rata-rata tugas sapertos ieu mindeng pisan low - nu atra, saprak bagian signifikan tina waktu tugas waits pikeun pamundut na teu nanaon.

tugas itungan. pola maranéhanana bakal rada béda:

Konsumsi sumberdaya CPU rata-rata pikeun tugas sapertos kitu cukup luhur. Sering urang hoyong tugas itungan réngsé dina sababaraha waktos, ku kituna urang kedah cagar jumlah minimum prosesor anu diperyogikeun supados sadayana itungan réngsé dina waktos anu ditampi. Rumus reservasina bakal katingali sapertos kieu:

alloc: cpu = [1,*)

"Punten nempatkeun éta dina antek dimana sahenteuna aya hiji inti gratis, teras saloba anu aya, éta bakal ngahakan sadayana."

Di dieu efisiensi pamakean parantos langkung saé tibatan tugas-tugas anu telat pondok. Tapi gain bakal jadi loba nu leuwih gede lamun ngagabungkeun duanana jenis tugas dina hiji mesin minion jeung ngadistribusikaeun sumberdaya na dina lebet nu. Nalika tugas kalayan reureuh pondok merlukeun prosésor, eta narima langsung, sarta lamun sumberdaya teu diperlukeun deui, aranjeunna ditransferkeun ka tugas komputasi, nyaéta hal kawas kieu:

Tapi kumaha carana ngalakukeun éta?

Kahiji, hayu urang nempo prod na alloc na: cpu = 4. Urang kudu cagar opat cores. Dina Docker ngajalankeun ieu tiasa dilakukeun ku dua cara:

• Ngagunakeun pilihan --cpuset=1-4, ie allocate opat cores husus dina mesin keur tugas.
• Anggo --cpuquota=400_000 --cpuperiod=100_000, назначить квоту на процессорное время, т. е. указать, что каждые 100 мс реального времени задача потребляет не более 400 мс процессорного времени. Получаются те же самые четыре ядра.

Но какой из этих способов подойдёт?

Довольно привлекательно выглядит cpuset. У задачи четыре выделенных ядра, значит, процессорные кеши будут работать максимально эффективно. У этого есть и оборотная сторона: нам пришлось бы взять на себя задачу распределением вычислений по незагруженным ядрам машины вместо ОС, а это довольно нетривиальная задача, особенно если мы попробуем размещать на такой машине batch-задачи. Тесты показали, что здесь лучше подходит вариант с квотой: так у операционной системы больше свободы в выборе ядра для выполнения задачи в текущий момент и процессорное время распределяется более эффективно.

Hayu urang terang kumaha carana ngadamel reservations di Docker dumasar kana jumlah minimum cores. Kuota pikeun tugas bets geus euweuh lumaku, sabab teu kudu ngawatesan maksimum, cukup ngan ngajamin minimum. Sareng di dieu pilihanna pas docker run --cpushares.

Urang sapuk yén lamun bets merlukeun jaminan pikeun sahanteuna hiji inti, lajeng urang nunjukkeun --cpushares=1024, sarta lamun aya sahanteuna dua cores, lajeng urang nunjukkeun --cpushares=2048. Saham CPU henteu ngaganggu kana distribusi waktos prosésor salami aya cekap. Ku kituna, lamun prod ayeuna teu make sagala opat cores na, euweuh ngawatesan tugas bets, sarta aranjeunna tiasa nganggo waktos processor tambahan. Tapi dina kaayaan dimana aya kakurangan prosesor, lamun prod geus meakeun sakabéh opat cores na geus ngahontal kuota na, sésana waktos processor bakal dibagi proporsional jeung cpushares, nyaéta dina kaayaan tilu cores bébas, hiji bakal jadi. dibikeun ka tugas kalawan 1024 cpushares, sarta dua sésana bakal dibikeun ka tugas kalawan 2048 cpushares.

Tapi ngagunakeun kuota sareng saham henteu cekap. Urang kudu mastikeun yén tugas kalawan reureuh pondok narima prioritas leuwih tugas bets nalika allocating waktos processor. Tanpa prioritization misalna, tugas bets bakal nyandak up sagala waktos processor dina momen lamun diperlukeun ku prod nu. Henteu aya pilihan prioritas wadahna dina ngajalankeun Docker, tapi kawijakan penjadwal CPU Linux tiasa dianggo. Anjeun tiasa maca ngeunaan aranjeunna sacara rinci di dieu, sareng dina kerangka tulisan ieu kami bakal ngaliwat aranjeunna sakedap:

• SCHED_OTHER
  Sacara standar, sadaya prosés pangguna normal dina mesin Linux nampi.
• SCHED_BATCH
  Dirancang pikeun prosés sumberdaya-intensif. Nalika nempatkeun tugas dina prosésor, anu disebut pinalti aktivasina diwanohkeun: tugas sapertos kitu kirang kamungkinan nampi sumber daya prosesor upami ayeuna dianggo ku tugas sareng SCHED_OTHER
• SCHED_IDLE
  Prosés tukang kalayan prioritas pisan low, malah leuwih handap nice -19. Kami nganggo perpustakaan open source kami hiji-nio, Dina raraga nyetel kawijakan diperlukeun nalika ngamimitian wadahna ku nelepon

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

Tapi sanaos anjeun henteu ngaprogram dina Java, hal anu sami tiasa dilakukeun nganggo paréntah chrt:

chrt -i 0 $pid

Hayu urang nyimpulkeun sadaya tingkat isolasi urang kana hiji méja pikeun kajelasan:

Kelas insulasi
conto Alloc
Pilihan ngajalankeun Docker
sched_setscheduler chrt*

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

angkatan
Cpu = [1, *)
--cpushares=1024
SCHED_BATCH

teu jalan
Cpu = [2, *)
--cpushares=2048
SCHED_IDLE

* Upami anjeun ngalakukeun chrt tina jero wadah, anjeun panginten peryogi kamampuan sys_nice, sabab sacara standar Docker ngaleungitkeun kamampuan ieu nalika ngamimitian wadahna.

Tapi tugas meakeun teu ukur processor, tapi ogé lalulintas, nu mangaruhan latency sahiji tugas jaringan malah leuwih ti alokasi lepat sumberdaya processor. Ku alatan éta, urang sacara alami hoyong kéngingkeun gambar anu sami pikeun lalu lintas. Nyaéta, nalika tugas prod ngirimkeun sababaraha pakét ka jaringan, urang ngabatesan laju maksimum (formula alloc: lan=[*,500mbps) ), kalayan prod anu tiasa ngalakukeun ieu. Sareng pikeun bets kami ngajamin ngan ukur throughput minimum, tapi henteu ngawatesan maksimal (rumus alloc: lan=[10Mbps,*) ) Dina hal ieu, lalulintas prod kedah nampi prioritas leuwih tugas bets.
Di dieu Docker henteu ngagaduhan primitif anu tiasa kami anggo. Tapi datang ka bantuan urang Kontrol Lalu Lintas Linux. Kami tiasa ngahontal hasil anu dipikahoyong kalayan bantosan disiplin Kurva Palayanan Adil Hierarki. Kalayan bantosanana, urang ngabédakeun dua kelas lalu lintas: prod prioritas luhur sareng bets/dianggurkeun prioritas rendah. Hasilna, konfigurasi pikeun lalu lintas kaluar sapertos kieu:

di dieu 1: 0 teh "root qdisc" tina disiplin hsfc; 1: 1 - kelas anak hsfc kalawan total wates rubakpita 8 Gbit / s, handapeun mana kelas anak sadaya wadahna disimpen; 1: 2 - kelas anak hsfc umum pikeun sakabéh tugas bets jeung dianggurkeun kalawan wates "dinamis", nu dibahas dihandap. Sésana kelas anak hsfc mangrupikeun kelas khusus pikeun wadah prod anu ayeuna ngajalankeun kalayan wates anu cocog sareng manifestasina - 450 sareng 400 Mbit / s. Unggal kelas hsfc ditugaskeun qdisc antrian fq atanapi fq_codel, gumantung kana versi kernel Linux Ubuntu, pikeun ngahindarkeun leungitna pakét salila bursts lalulintas.

Ilaharna, tc disiplin ngawula prioritas ukur lalulintas kaluar. Tapi urang hoyong prioritas lalulintas asup teuing - sanggeus kabeh, sababaraha tugas bets bisa kalayan gampang milih sakabéh channel asup, narima, contona, bets badag data input pikeun map & ngurangan. Pikeun ieu kami nganggo modul ifb, anu nyiptakeun antarbeungeut maya ifbX pikeun tiap antarbeungeut jaringan sareng alihan patalimarga asup ti antarbeungeut ka lalu lintas kaluar dina ifbX. Salajengna, pikeun ifbX, sadaya disiplin anu sami dianggo pikeun ngontrol lalu lintas kaluar, dimana konfigurasi hsfc bakal sami pisan:

Salila percobaan, urang manggihan yén hsfc nembongkeun hasil pangalusna nalika 1: 2 kelas non-prioritas bets / lalulintas dianggurkeun diwatesan dina mesin minion mun euweuh leuwih ti hiji jalur bebas tangtu. Upami teu kitu, lalulintas non-prioritas boga teuing dampak dina latency tugas prod. miniond nangtukeun jumlah rubakpita bébas ayeuna unggal detik, ngukur rata-rata konsumsi lalu lintas sadaya prod-tugas tina minion nu tangtu. sarta subtracting tina rubakpita panganteur jaringan kalawan margin leutik, i.e.

Pita diartikeun sacara mandiri pikeun lalu lintas asup sareng kaluar. Sarta nurutkeun kana nilai anyar, miniond reconfigures wates kelas non-prioritas 1: 2.

Ku kituna, urang ngalaksanakeun sakabeh tilu kelas isolasi: prod, bets jeung dianggurkeun. Kelas-kelas ieu mangaruhan pisan kana karakteristik kinerja tugas. Ku alatan éta, urang mutuskeun pikeun nempatkeun atribut ieu dina luhureun hirarki, ku kituna lamun nempo ngaran antrian hirarki bakal langsung jelas naon urang keur kaayaan:

Все наши знакомые web и musik фронты тогда помещаются в иерархии под prod. Для примера под batch давайте поместим сервис music catalog, который периодически составляет каталог треков из набора загруженных в «Одноклассники» mp3-файлов. А примером сервиса под idle может служить trafo musik, nu normalizes tingkat volume musik.

Kalayan garis tambahan dihapus deui, urang tiasa nyerat nami jasa kami langkung datar ku nambihan kelas isolasi tugas ka tungtung nami jasa lengkep: web.front.prod, catalog.music.batch, transformer.music.idle.

Sareng ayeuna, ningali nami jasa, urang ngartos henteu ngan ukur naon fungsina, tapi ogé kelas isolasina, anu hartosna kritisitasna, jsb.

Sagalana hébat, tapi aya hiji bebeneran pait. Mustahil pikeun ngasingkeun tugas lengkep dina hiji mesin.

Naon anu urang junun ngahontal: lamun bets intensif meakeun ngan sumberdaya CPU, lajeng diwangun-di Linux Ubuntu CPU scheduler ngalakukeun pakasaban na kacida alusna, tur aya praktis euweuh dampak dina tugas prod. Tapi lamun tugas angkatan ieu dimimitian aktip dianggo kalayan memori, pangaruh silih geus mucunghul. Ieu kajadian sabab tugas prod "dikumbah kaluar" tina caches memori processor urang - salaku hasilna, cache sono kanaékan, sarta prosésor prosés prod tugas leuwih laun. Tugas bets sapertos kitu tiasa ningkatkeun latency wadah prod has urang ku 10%.

Изолировать трафик ещё сложнее из-за того, что у современных сетевых карт есть внутренняя очередь пакетов. Если пакет от batch-задачи туда попал первым, значит, он первым и будет передан по кабелю, и тут ничего не поделаешь.

Sajaba ti éta, kami geus jadi jauh ngan junun ngajawab masalah prioritizing lalulintas TCP: pendekatan hsfc teu dianggo pikeun UDP. Komo dina kasus lalulintas TCP, lamun tugas bets dibangkitkeun loba lalulintas, ieu ogé méré ngeunaan 10% kanaékan reureuh tina tugas prod.

toleransi kasalahan

Salah sahiji tujuan nalika ngembangkeun hiji awan nyaéta pikeun ningkatkeun kasabaran kasalahan Odnoklassniki. Ku alatan éta, salajengna Abdi hoyong mertimbangkeun di leuwih jéntré mungkin skenario gagal jeung kacilakaan. Hayu urang mimitian ku skenario basajan - gagal wadahna.

Wadahna sorangan tiasa gagal dina sababaraha cara. Ieu tiasa janten sababaraha jinis ékspérimén, bug atanapi kasalahan dina manifes, kusabab éta tugas prod mimiti ngonsumsi langkung seueur sumber tibatan anu dituduhkeun dina manifest. Kami ngagaduhan pasualan: pamekar ngalaksanakeun hiji algoritma anu rumit, ngerjakeun deui sababaraha kali, mikirkeun dirina sorangan sareng janten bingung anu pamustunganana masalahna janten loop anu teu pati penting. Sarta saprak tugas prod boga prioritas leuwih luhur ti sakabeh batur dina minions sarua, eta mimiti meakeun sagala sumberdaya processor sadia. Dina kaayaan ieu, isolasi, atawa rada kuota waktu CPU, disimpen poé. Lamun tugas dialokasikeun kuota, tugas moal meakeun leuwih. Ku alatan éta, bets jeung tugas prod séjén anu ngajalankeun dina mesin sarua teu aya bewara nanaon.

Masalah kadua kamungkinan nyaéta wadah ragrag. Sareng di dieu balikan deui kabijakan nyalametkeun urang, sadayana terang aranjeunna, Docker nyalira damel padamelan anu saé. Ampir kabéh tugas prod boga kawijakan salawasna balikan deui. Sok we make on_failure pikeun tugas bets atawa pikeun debugging wadah prod.

Naon anu anjeun tiasa laksanakeun upami sadayana antek henteu sayogi?

Jelas, ngajalankeun wadahna dina mesin séjén. Bagian anu pikaresepeun di dieu nyaéta naon anu lumangsung ka alamat IP (es) anu ditugaskeun ka wadahna.

Urang tiasa napelkeun wadahna alamat IP anu sami sareng mesin minion dimana wadahna dijalankeun. Teras, nalika wadahna diluncurkeun dina mesin anu sanés, alamat IPna robih, sareng sadaya klien kedah ngartos yén wadahna parantos pindah, sareng ayeuna aranjeunna kedah angkat ka alamat anu sanés, anu peryogi jasa Papanggihan Layanan anu misah.

Service Discovery nyaeta merenah. Aya seueur solusi dina pasar anu béda-béda tingkat kasabaran kasalahan pikeun ngatur pendaptaran jasa. Mindeng solusi sapertos nerapkeun beban balancer logika, nyimpen konfigurasi tambahan dina bentuk gudang KV, jsb.
Однако, нам хотелось бы обойтись без необходимости внедрения отдельного реестра, ведь это означало бы ввод критической системы, которая используется всеми сервисами в production. А значит, это потенциальная точка отказа, и нужно выбирать или разрабатывать очень отказоустойчивое решение, что, очевидно, очень непросто, долго и дорого.

Sareng hiji deui kalemahan anu ageung: supados infrastruktur lami urang tiasa dianggo sareng anu énggal, urang kedah nyerat deui leres-leres sadaya pancén pikeun ngagunakeun sababaraha jinis sistem Discovery Service. Aya seueur padamelan, sareng di sababaraha tempat ampir teu mungkin upami aya alat tingkat rendah anu tiasa dianggo dina tingkat kernel OS atanapi langsung sareng hardware. Palaksanaan fungsionalitas ieu nganggo pola solusi anu ditetepkeun, sapertos mobil samping bakal hartosna di sababaraha tempat beban tambahan, di batur - komplikasi operasi sarta skenario gagalna tambahan. Kami henteu hoyong ngahesekeun hal, janten kami mutuskeun pikeun ngagunakeun Service Discovery opsional.

Dina hiji awan, IP nuturkeun wadahna, nyaéta unggal conto tugas ngagaduhan alamat IP sorangan. Alamat ieu "statis": ditugaskeun ka unggal conto nalika jasa mimiti dikirim ka méga. Upami jasa ngagaduhan sajumlah instansi anu béda salami hirupna, maka dina tungtungna éta bakal ditugaskeun saloba alamat IP sapertos aya instansi maksimal.

Salajengna, alamat ieu henteu robih: aranjeunna ditugaskeun sakali sareng terus aya sapanjang umur jasa dina produksi. Alamat IP nuturkeun peti di sakuliah jaringan. Upami wadahna ditransfer ka antek anu sanés, maka alamatna bakal nuturkeun éta.

Таким образом, сопоставление имени сервиса со списком его IP-адресов меняется очень редко. Если ещё раз посмотреть на имена экземпляров сервиса, которые мы упоминали в начале статьи (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), urang bakal aya bewara yen aranjeunna nyarupaan FQDNs dipaké dina DNS. Leres, pikeun peta nami instansi jasa kana alamat IPna, kami nganggo protokol DNS. Sumawona, DNS ieu ngabalikeun sadaya alamat IP anu dicadangkeun sadaya wadah - duanana jalan sareng lirén (nyaéta tilu réplika dianggo, sareng urang gaduh lima alamat anu ditangtayungan di dinya - sadayana lima bakal dipulangkeun). Klién, saatos nampi inpormasi ieu, bakal nyobian ngahubungkeun sareng sadaya lima réplika - sahingga nangtukeun anu damel. Pilihan ieu pikeun nangtoskeun kasadiaan langkung dipercaya; éta henteu ngalibetkeun DNS atanapi Service Discovery, anu hartosna teu aya masalah anu sesah pikeun direngsekeun dina mastikeun relevansi inpormasi sareng kasabaran kasalahan sistem ieu. Sumawona, dina jasa kritis dimana operasi sadayana portal gumantung, urang henteu tiasa nganggo DNS pisan, tapi ngan saukur ngalebetkeun alamat IP kana konfigurasi.

Ngalaksanakeun transfer IP sapertos di tukangeun wadah tiasa henteu sepele - sareng urang bakal ningali kumaha jalanna sareng conto ieu:

Hayu urang nyebutkeun master hiji-awan méré paréntah ka minion M1 ngajalankeun 1.ok-web.group1.web.front.prod с адресом 1.1.1.1. На миньоне работает MANUK, nu advertises alamat ieu server husus route reflector. У последних есть BGP-сессия с сетевой железкой, в которую и транслируется маршрут адреса 1.1.1.1 на M1. M1 же маршрутизирует пакеты внутрь контейнера уже средствами Linux. Серверов route reflector три, так как это очень критичная часть инфраструктуры one-cloud — без них сеть в one-cloud работать не будет. Мы размещаем их в разных стойках, по возможности расположенных в разных залах дата-центра, чтобы уменьшить вероятность единовременного отказа всех трёх.

Hayu urang ayeuna nganggap yén sambungan antara master hiji-awan jeung minion M1 leungit. Master hiji-awan ayeuna bakal meta dina asumsi yén M1 tos rengse gagal. Nyaéta, éta bakal masihan paréntah ka minion M2 pikeun ngaluncurkeun web.group1.web.front.prod kalawan alamat sarua 1.1.1.1. Ayeuna kami boga dua ruteu conflicting dina jaringan pikeun 1.1.1.1: on M1 na on M2. Pikeun ngabéréskeun konflik sapertos kitu, kami nganggo Multi Exit Discriminator, anu dijelaskeun dina pengumuman BGP. Ieu mangrupikeun nomer anu nunjukkeun beurat jalur anu diémbarkeun. Diantara rute anu bentrok, jalur anu gaduh nilai MED handap bakal dipilih. Master hiji awan ngadukung MED salaku bagian integral tina alamat IP wadahna. Pikeun kahiji kalina, alamatna ditulis ku MED anu cukup ageung = 1. Dina kaayaan pangiriman wadah darurat sapertos kitu, master ngirangan MED, sareng M000 parantos nampi paréntah pikeun ngiklankeun alamat 000 sareng MED = 2. Instance ngajalankeun on M1.1.1.1 bakal tetep dina hal ieu euweuh sambungan, jeung nasib salajengna na kapentingan urang saeutik dugi sambungan kalawan master dibalikeun, nalika anjeunna bakal dieureunkeun kawas nyokot heubeul.

kacilakaan

Sadaya sistem manajemén puseur data salawasna nanganan gagal minor acceptably. Wadah ngabahekeun nyaéta norma ampir di mana waé.

Hayu urang tingali kumaha urang nanganan kaayaan darurat, sapertos pareum listrik dina hiji atanapi langkung kamar di pusat data.

Naon hartosna kacilakaan pikeun sistem manajemén pusat data? Anu mimiti, ieu mangrupikeun kagagalan hiji-waktos tina seueur mesin, sareng sistem kontrol kedah migrasi seueur wadah dina waktos anu sami. Tapi lamun musibah pisan badag skala, éta bisa lumangsung yén sakabéh tugas teu bisa ulang dialokasikeun ka minions séjén, sabab kapasitas sumberdaya puseur data pakait handap 100% tina beban.

Sering kacilakaan dibarengan ku gagalna lapisan kontrol. Ieu bisa lumangsung alatan gagalna parabot na, tapi leuwih mindeng alatan kanyataan yén kacilakaan teu diuji, sarta lapisan kontrol sorangan ragrag alatan ngaronjat beban.

Naon anu anjeun tiasa laksanakeun ngeunaan sadaya ieu?

Migrasi massal hartosna aya sajumlah ageung kagiatan, migrasi, sareng panyebaran anu aya dina infrastruktur. Masing-masing migrasi butuh sababaraha waktos pikeun nganteurkeun sareng ngabongkar gambar wadahna ka minions, ngaluncurkeun sareng ngamimitian wadahna, jsb. Ku sabab éta, éta pantes yén tugas anu langkung penting diluncurkeun sateuacan anu kirang penting.

Hayu urang tingali deui hierarki jasa anu urang wawuh sareng cobian mutuskeun tugas mana anu urang badé jalankeun heula.

Tangtosna, ieu mangrupikeun prosés anu langsung aub dina ngolah pamundut pangguna, nyaéta prod. Urang nunjukkeun ieu kalawan prioritas panempatan - angka nu bisa ditugaskeun ka antrian. Upami antrian ngagaduhan prioritas anu langkung luhur, jasana ditempatkeun heula.

Dina prod kami napelkeun prioritas luhur, 0; dina bets - saeutik handap, 100; on dianggurkeun - malah leuwih handap, 200. Prioritas dilarapkeun hirarki. Sadaya tugas anu langkung handap dina hirarki bakal ngagaduhan prioritas anu saluyu. Upami urang hoyong caches di jero prod diluncurkeun sateuacan frontends, teras urang napelkeun prioritas ka cache = 0 sareng ka subqueues hareup = 1. Upami, contona, urang hoyong portal utama diluncurkeun ti payun heula, sareng payuneun musik wungkul. teras, teras urang tiasa masihan prioritas anu langkung handap pikeun anu terakhir - 10.

Следующая проблема — нехватка ресурсов. Итак, у нас отказало большое количество оборудования, целые залы дата-центра, а мы поназапускали сервисов столько, что теперь на всех не хватает ресурсов. Нужно решить, какими задачами пожертвовать, чтобы работали основные критичные сервисы.

В отличие от приоритета размещения, мы не можем огульно пожертвовать всеми batch-задачами, некоторые из них важны для работы портала. Поэтому мы выделили отдельно prioritas préparasi tugas. Nalika ditempatkeun, tugas prioritas nu leuwih luhur bisa preempt, nyaéta eureun, tugas prioritas handap lamun teu aya deui minions bébas. Dina hal ieu, tugas kalawan prioritas low meureun bakal tetep unplaced, i.e. moal aya deui antek cocog pikeun eta kalawan sumberdaya bébas cukup.

Dina hierarki urang, saderhana pisan pikeun nangtukeun prioritas preemption sapertos prod sareng tugas bets preempt atanapi ngeureunkeun tugas dianggurkeun, tapi henteu silih, ku netepkeun prioritas pikeun dianggurkeun sami sareng 200. Sapertos dina kasus prioritas panempatan, urang tiasa nganggo hirarki urang pikeun ngajelaskeun aturan anu langkung kompleks. Salaku conto, hayu urang nunjukkeun yén urang ngorbankeun fungsi musik upami urang henteu gaduh sumber anu cekap pikeun portal wéb utama, netepkeun prioritas pikeun titik anu saluyu: 10.

Sakabéh kacilakaan DC

Naha sakabéh puseur data bisa gagal? unsur. Éta tulisan anu saé Hurricane mangaruhan karya puseur data. Unsur bisa dianggap jalma homeless anu sakali dibeuleum élmu optik dina manifold, sarta puseur data lengkep leungit kontak jeung situs séjén. Anu ngabalukarkeun gagalna ogé tiasa janten faktor manusa: operator bakal ngaluarkeun paréntah sapertos anu sadayana pusat data bakal murag. Ieu bisa lumangsung alatan bug badag. Sacara umum, puseur data runtuh teu ilahar. Ieu kajadian ka urang sakali unggal sababaraha bulan.

Sareng ieu anu urang lakukeun pikeun nyegah saha waé tina tweeting #alive.

Strategi kahiji nyaéta isolasi. Masing-masing instansi awan diisolasi sareng tiasa ngatur mesin dina ngan hiji pusat data. Nyaéta, leungitna awan kusabab bug atanapi paréntah operator anu salah nyaéta leungitna ngan hiji pusat data. Kami siap pikeun ieu: kami gaduh kawijakan redundansi dimana réplika aplikasi sareng data aya di sadaya pusat data. Kami nganggo basis data toleran-lepat sareng uji périodik pikeun gagal.
Kusabab ayeuna urang gaduh opat pusat data, éta hartosna opat papisah, papisah lengkep tina hiji awan.

pendekatan ieu teu ngan ngajaga ngalawan gagalna fisik, tapi ogé bisa ngajaga tina kasalahan operator.

Naon deui anu tiasa dilakukeun ku faktor manusa? Nalika hiji operator masihan awan sababaraha paréntah aneh atawa berpotensi bahaya, anjeunna bisa ujug-ujug jadi dipenta pikeun ngajawab masalah leutik ningali kumaha ogé ceuk pikir. Contona, upami ieu sababaraha jenis eureun massa loba réplika atawa ngan paréntah aneh - ngurangan jumlah réplika atawa ngarobah ngaran gambar, teu ngan nomer versi dina manifest anyar.

hasil

Отличительные особенности one-cloud:

• Skéma ngaran hirarkis jeung visual pikeun jasa jeung peti, которая позволяет очень быстро узнать, что это за задача, к чему она относится и как работает и кто отвечает за нее.
• Urang nerapkeun urang технику совмещения prod- и batch-tugas dina minions pikeun ngaronjatkeun efisiensi babagi mesin. Gantina cpuset kami nganggo kuota CPU, saham, kawijakan penjadwal CPU sareng Linux QoS.
• Teu mungkin pikeun ngasingkeun lengkep wadah anu ngajalankeun dina mesin anu sami, tapi pangaruh silih tetep aya dina 20%.
• Организация сервисов в иерархию помогает при автоматической ликвидации аварий при помощи panempatan jeung prioritas preemption.

FAQ

Naha urang henteu nyandak solusi anu siap-siap?

• Kelas béda tina isolasi tugas merlukeun logika béda lamun disimpen dina minions. Lamun tugas prod bisa disimpen ku saukur reserving sumberdaya, lajeng bets jeung tugas dianggurkeun kudu ditempatkeun, nyukcruk utilization sabenerna sumberdaya on mesin minion.
• Perlu tumut kana sumber daya anu dikonsumsi ku tugas, sapertos:
  • rubakpita jaringan;
  • jenis jeung "spindles" tina disk.
• Kabutuhan pikeun nunjukkeun prioritas jasa nalika tanggap darurat, hak sareng kuota paréntah pikeun sumber daya, anu direngsekeun nganggo antrian hirarki dina awan.
• Kabutuhan pikeun ngaranan manusa wadah pikeun ngirangan waktos réspon kana kacilakaan sareng kajadian
• The impossibility of a palaksanaan nyebar hiji-waktos Service Discovery; kabutuhan hirup babarengan pikeun lila jeung tugas hosted on hardware host - hal anu direngsekeun ku "statis" alamat IP handap wadahna, sarta, salaku konsekuensi, kabutuhan integrasi unik jeung infrastruktur jaringan badag.

Sadaya fungsi ieu ngabutuhkeun modifikasi anu signifikan tina solusi anu aya pikeun nyocogkeun ka kami, sareng, saatos ditaksir jumlah padamelan, kami sadar yén kami tiasa ngembangkeun solusi sorangan kalayan biaya tenaga kerja anu sami. Tapi solusi anjeun bakal langkung gampang dioperasikeun sareng dikembangkeun - éta henteu ngandung abstraksi anu teu perlu anu ngadukung fungsionalitas anu urang henteu peryogikeun.

Pikeun anu maca baris terakhir, hatur nuhun pikeun kasabaran sareng perhatian anjeun!

sumber: www.habr.com