One-cloud - OS peringkat pusat data dalam Odnoklassniki

Aloha, rakyat! Nama saya Oleg Anastasyev, saya bekerja di Odnoklassniki dalam pasukan Platform. Dan selain saya, terdapat banyak perkakasan yang berfungsi di Odnoklassniki. Kami mempunyai empat pusat data dengan kira-kira 500 rak dengan lebih daripada 8 ribu pelayan. Pada satu ketika, kami menyedari bahawa pengenalan sistem pengurusan baharu akan membolehkan kami memuatkan peralatan dengan lebih cekap, memudahkan pengurusan akses, mengautomasikan (semula) pengagihan sumber pengkomputeran, mempercepatkan pelancaran perkhidmatan baharu dan mempercepatkan respons. kepada kemalangan berskala besar.

Apa yang datang daripadanya?

Selain saya dan sekumpulan perkakasan, terdapat juga orang yang bekerja dengan perkakasan ini: jurutera yang terletak terus di pusat data; perangkaian yang menyediakan perisian rangkaian; pentadbir, atau SRE, yang menyediakan daya tahan infrastruktur; dan pasukan pembangunan, setiap daripada mereka bertanggungjawab untuk sebahagian daripada fungsi portal. Perisian yang mereka cipta berfungsi seperti ini:

Permintaan pengguna diterima kedua-duanya di bahagian hadapan portal utama www.ok.ru, dan pada yang lain, contohnya pada bahagian hadapan API muzik. Untuk memproses logik perniagaan, mereka memanggil pelayan aplikasi, yang, apabila memproses permintaan, memanggil perkhidmatan mikro khusus yang diperlukan - satu graf (graf sambungan sosial), cache pengguna (cache profil pengguna), dll.

Setiap perkhidmatan ini digunakan pada banyak mesin, dan setiap daripada mereka mempunyai pembangun yang bertanggungjawab yang bertanggungjawab ke atas fungsi modul, operasi dan pembangunan teknologinya. Semua perkhidmatan ini dijalankan pada pelayan perkakasan, dan sehingga baru-baru ini kami melancarkan satu tugas setiap pelayan, iaitu ia khusus untuk tugas tertentu.

Kenapa begitu? Pendekatan ini mempunyai beberapa kelebihan:

• Lega pengurusan massa. Katakan tugas memerlukan beberapa perpustakaan, beberapa tetapan. Dan kemudian pelayan ditugaskan kepada satu kumpulan tertentu, dasar cfengin untuk kumpulan ini diterangkan (atau ia telah diterangkan), dan konfigurasi ini secara berpusat dan secara automatik dilancarkan ke semua pelayan dalam kumpulan ini.
• Dipermudahkan diagnostik. Katakan anda melihat peningkatan beban pada pemproses pusat dan menyedari bahawa beban ini hanya boleh dijana oleh tugas yang dijalankan pada pemproses perkakasan ini. Pencarian seseorang untuk dipersalahkan berakhir dengan cepat.
• Dipermudahkan pemantauan. Jika ada yang salah dengan pelayan, monitor melaporkannya, dan anda tahu dengan tepat siapa yang harus dipersalahkan.

Perkhidmatan yang terdiri daripada beberapa replika diperuntukkan beberapa pelayan - satu untuk setiap satu. Kemudian sumber pengkomputeran untuk perkhidmatan diperuntukkan dengan sangat mudah: bilangan pelayan yang dimiliki oleh perkhidmatan, jumlah maksimum sumber yang boleh digunakan. "Mudah" di sini tidak bermakna ia mudah digunakan, tetapi dalam erti kata peruntukan sumber dilakukan secara manual.

Pendekatan ini juga membolehkan kami melakukannya konfigurasi besi khusus untuk tugasan yang dijalankan pada pelayan ini. Jika tugasan menyimpan sejumlah besar data, maka kami menggunakan pelayan 4U dengan casis dengan 38 cakera. Jika tugas itu adalah pengiraan semata-mata, maka kita boleh membeli pelayan 1U yang lebih murah. Ini adalah cekap dari segi pengiraan. Antara lain, pendekatan ini membolehkan kami menggunakan mesin empat kali lebih sedikit dengan beban yang setanding dengan satu rangkaian sosial yang mesra.

Kecekapan sedemikian dalam penggunaan sumber pengkomputeran juga harus memastikan kecekapan ekonomi, jika kita meneruskan dari premis bahawa perkara yang paling mahal adalah pelayan. Untuk masa yang lama, perkakasan adalah yang paling mahal, dan kami meletakkan banyak usaha untuk mengurangkan harga perkakasan, menghasilkan algoritma toleransi kesalahan untuk mengurangkan keperluan kebolehpercayaan perkakasan. Dan hari ini kita telah mencapai tahap di mana harga pelayan tidak lagi menjadi penentu. Jika anda tidak menganggap eksotik terkini, maka konfigurasi khusus pelayan dalam rak tidak penting. Sekarang kita mempunyai masalah lain - harga ruang yang diduduki oleh pelayan di pusat data, iaitu ruang di rak.

Menyedari bahawa ini adalah kesnya, kami memutuskan untuk mengira sejauh mana keberkesanan kami menggunakan rak.
Kami mengambil harga pelayan yang paling berkuasa daripada yang wajar dari segi ekonomi, mengira bilangan pelayan sedemikian yang boleh kami letakkan dalam rak, berapa banyak tugas yang akan kami jalankan pada mereka berdasarkan model lama "satu pelayan = satu tugas" dan berapa banyak tugas boleh menggunakan peralatan. Mereka mengira dan menitiskan air mata. Ternyata kecekapan kami dalam menggunakan rak adalah kira-kira 11%. Kesimpulannya adalah jelas: kita perlu meningkatkan kecekapan menggunakan pusat data. Nampaknya penyelesaiannya jelas: anda perlu menjalankan beberapa tugas pada satu pelayan sekaligus. Tetapi di sinilah kesukaran bermula.

Konfigurasi jisim menjadi lebih rumit secara mendadak - kini mustahil untuk menetapkan mana-mana satu kumpulan ke pelayan. Lagipun, kini beberapa tugas arahan berbeza boleh dilancarkan pada satu pelayan. Selain itu, konfigurasi mungkin bercanggah untuk aplikasi yang berbeza. Diagnosis juga menjadi lebih rumit: jika anda melihat peningkatan penggunaan CPU atau cakera pada pelayan, anda tidak tahu tugas mana yang menyebabkan masalah.

Tetapi perkara utama ialah tidak ada pengasingan antara tugas yang dijalankan pada mesin yang sama. Di sini, sebagai contoh, ialah graf purata masa tindak balas tugas pelayan sebelum dan selepas aplikasi pengiraan lain dilancarkan pada pelayan yang sama, sama sekali tidak berkaitan dengan yang pertama - masa tindak balas tugas utama telah meningkat dengan ketara.

Jelas sekali, anda perlu menjalankan tugas sama ada dalam bekas atau dalam mesin maya. Memandangkan hampir semua tugas kami dijalankan di bawah satu OS (Linux) atau disesuaikan untuknya, kami tidak perlu menyokong banyak sistem pengendalian yang berbeza. Oleh itu, virtualisasi tidak diperlukan; disebabkan oleh overhed tambahan, ia akan menjadi kurang cekap daripada kontena.

Sebagai pelaksanaan bekas untuk menjalankan tugas secara langsung pada pelayan, Docker ialah calon yang baik: imej sistem fail menyelesaikan masalah dengan konfigurasi yang bercanggah dengan baik. Hakikat bahawa imej boleh terdiri daripada beberapa lapisan membolehkan kami mengurangkan dengan ketara jumlah data yang diperlukan untuk menempatkannya pada infrastruktur, memisahkan bahagian biasa kepada lapisan asas yang berasingan. Kemudian lapisan asas (dan paling banyak) akan dicache dengan agak cepat di seluruh infrastruktur, dan untuk menyampaikan pelbagai jenis aplikasi dan versi, hanya lapisan kecil perlu dipindahkan.

Selain itu, pendaftaran siap sedia dan penandaan imej dalam Docker memberi kami primitif siap sedia untuk membuat versi dan menghantar kod kepada pengeluaran.

Docker, seperti mana-mana teknologi serupa yang lain, memberikan kami beberapa tahap pengasingan kontena di luar kotak. Sebagai contoh, pengasingan memori - setiap bekas diberi had penggunaan memori mesin, yang melebihinya ia tidak akan digunakan. Anda juga boleh mengasingkan bekas berdasarkan penggunaan CPU. Bagi kami, bagaimanapun, penebat standard tidak mencukupi. Tetapi lebih lanjut mengenai itu di bawah.

Menjalankan kontena secara langsung pada pelayan hanyalah sebahagian daripada masalah. Bahagian lain berkaitan dengan kontena pengehosan pada pelayan. Anda perlu memahami bekas mana yang boleh diletakkan pada pelayan mana. Ini bukan tugas yang mudah, kerana bekas perlu diletakkan pada pelayan sepadat mungkin tanpa mengurangkan kelajuannya. Peletakan sedemikian juga boleh menjadi sukar dari sudut toleransi kesalahan. Selalunya kami ingin meletakkan replika perkhidmatan yang sama di rak yang berbeza atau bahkan di bilik pusat data yang berbeza, supaya jika rak atau bilik gagal, kami tidak kehilangan semua replika perkhidmatan dengan serta-merta.

Mengedarkan bekas secara manual bukan pilihan apabila anda mempunyai 8 ribu pelayan dan 8-16 ribu kontena.

Di samping itu, kami mahu memberikan pembangun lebih kebebasan dalam peruntukan sumber supaya mereka boleh mengehos perkhidmatan mereka dalam pengeluaran sendiri, tanpa bantuan pentadbir. Pada masa yang sama, kami ingin mengekalkan kawalan supaya sesetengah perkhidmatan kecil tidak akan menggunakan semua sumber pusat data kami.

Jelas sekali, kita memerlukan lapisan kawalan yang akan melakukan ini secara automatik.

Oleh itu, kami mendapat gambaran yang mudah dan mudah difahami bahawa semua arkitek memuja: tiga petak.

master satu awan ialah gugusan failover yang bertanggungjawab untuk orkestrasi awan. Pembangun menghantar manifes kepada induk, yang mengandungi semua maklumat yang diperlukan untuk mengehoskan perkhidmatan. Berdasarkan itu, tuan memberikan arahan kepada minions terpilih (mesin yang direka untuk menjalankan kontena). Minion mempunyai ejen kami, yang menerima arahan, mengeluarkan arahannya kepada Docker, dan Docker mengkonfigurasi kernel linux untuk melancarkan bekas yang sepadan. Selain melaksanakan arahan, ejen secara berterusan melaporkan kepada tuan tentang perubahan dalam keadaan kedua-dua mesin minion dan bekas yang berjalan di atasnya.

Peruntukan sumber

Sekarang mari kita lihat masalah peruntukan sumber yang lebih kompleks untuk banyak minion.

Sumber pengkomputeran dalam satu awan ialah:

• Jumlah kuasa pemproses yang digunakan oleh tugas tertentu.
• Jumlah memori yang tersedia untuk tugas itu.
• Trafik rangkaian. Setiap minion mempunyai antara muka rangkaian tertentu dengan lebar jalur terhad, jadi mustahil untuk mengagihkan tugas tanpa mengambil kira jumlah data yang mereka hantar melalui rangkaian.
• Cakera. Di samping itu, jelas sekali, kepada ruang untuk tugasan ini, kami juga memperuntukkan jenis cakera: HDD atau SSD. Cakera boleh menyediakan bilangan permintaan yang terhad sesaat - IOPS. Oleh itu, untuk tugasan yang menjana lebih banyak IOPS daripada yang boleh dikendalikan oleh satu cakera, kami juga memperuntukkan "spindle" - iaitu peranti cakera yang mesti dikhaskan secara eksklusif untuk tugas itu.

Kemudian untuk sesetengah perkhidmatan, contohnya untuk cache pengguna, kami boleh merekodkan sumber yang digunakan dengan cara ini: 400 teras pemproses, 2,5 TB memori, trafik 50 Gbit/s dalam kedua-dua arah, 6 TB ruang HDD yang terletak pada 100 gelendong . Atau dalam bentuk yang lebih biasa seperti ini:

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

Sumber perkhidmatan cache pengguna hanya menggunakan sebahagian daripada semua sumber yang tersedia dalam infrastruktur pengeluaran. Oleh itu, saya ingin memastikan bahawa secara tiba-tiba, disebabkan oleh ralat pengendali atau tidak, cache pengguna tidak menggunakan lebih banyak sumber daripada yang diperuntukkan kepadanya. Iaitu, kita mesti mengehadkan sumber. Tetapi untuk apa kita boleh mengikat kuota?

Mari kembali kepada rajah interaksi komponen kami yang sangat dipermudahkan dan lukis semula dengan lebih terperinci - seperti ini:

Apa yang menarik perhatian anda:

• Bahagian hadapan web dan muzik menggunakan kluster terpencil dari pelayan aplikasi yang sama.
• Kita boleh membezakan lapisan logik kepunyaan kluster ini: bahagian hadapan, cache, storan data dan lapisan pengurusan.
• Bahagian hadapan adalah heterogen; ia terdiri daripada subsistem berfungsi yang berbeza.
• Cache juga boleh tersebar di seluruh subsistem yang datanya dicache.

Mari lukis semula gambar itu:

Bah! Ya, kita melihat hierarki! Ini bermakna anda boleh mengagihkan sumber dalam bahagian yang lebih besar: tetapkan pembangun yang bertanggungjawab kepada nod hierarki ini yang sepadan dengan subsistem berfungsi (seperti "muzik" dalam gambar), dan lampirkan kuota pada tahap hierarki yang sama. Hierarki ini juga membolehkan kami mengatur perkhidmatan dengan lebih fleksibel untuk memudahkan pengurusan. Sebagai contoh, kami membahagikan semua web, kerana ini adalah kumpulan pelayan yang sangat besar, kepada beberapa kumpulan yang lebih kecil, ditunjukkan dalam gambar sebagai kumpulan1, kumpulan2.

Dengan mengalih keluar baris tambahan, kita boleh menulis setiap nod gambar kita dalam bentuk yang lebih rata: kumpulan1.web.depan, api.muzik.depan, user-cache.cache.

Ini adalah bagaimana kita sampai kepada konsep "barisan berhierarki". Ia mempunyai nama seperti "group1.web.front". Kuota untuk sumber dan hak pengguna diberikan kepadanya. Kami akan memberi orang daripada DevOps hak untuk menghantar perkhidmatan ke baris gilir, dan pekerja sedemikian boleh melancarkan sesuatu dalam baris gilir, dan orang daripada OpsDev akan mempunyai hak pentadbir, dan kini dia boleh menguruskan baris gilir, menugaskan orang di sana, berikan hak orang ini, dsb. Perkhidmatan yang dijalankan pada baris gilir ini akan dijalankan dalam kuota baris gilir. Jika kuota pengkomputeran baris gilir tidak mencukupi untuk melaksanakan semua perkhidmatan sekali gus, maka ia akan dilaksanakan secara berurutan, sekali gus membentuk baris gilir itu sendiri.

Mari kita lihat lebih dekat perkhidmatan. Sesuatu perkhidmatan mempunyai nama yang layak sepenuhnya, yang sentiasa menyertakan nama baris gilir. Kemudian perkhidmatan web hadapan akan mempunyai nama ok-web.group1.web.front. Dan perkhidmatan pelayan aplikasi yang diaksesnya akan dipanggil ok-app.group1.web.front. Setiap perkhidmatan mempunyai manifes, yang menyatakan semua maklumat yang diperlukan untuk penempatan pada mesin tertentu: berapa banyak sumber yang digunakan oleh tugas ini, konfigurasi yang diperlukan untuknya, berapa banyak replika yang sepatutnya ada, sifat untuk mengendalikan kegagalan perkhidmatan ini. Dan selepas perkhidmatan diletakkan terus pada mesin, kejadiannya muncul. Mereka juga dinamakan dengan jelas - sebagai nombor contoh dan nama perkhidmatan: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

Ini sangat mudah: dengan melihat hanya pada nama bekas yang sedang berjalan, kita boleh segera mengetahui banyak perkara.

Sekarang mari kita lihat dengan lebih dekat apa yang sebenarnya dilakukan oleh keadaan ini: tugasan.

Kelas Pengasingan Tugas

Semua tugas dalam OK (dan, mungkin, di mana-mana) boleh dibahagikan kepada kumpulan:

• Tugasan Kependaman Pendek - prod. Untuk tugas dan perkhidmatan sedemikian, kelewatan respons (latensi) adalah sangat penting, seberapa cepat setiap permintaan akan diproses oleh sistem. Contoh tugasan: bahagian hadapan web, cache, pelayan aplikasi, storan OLTP, dsb.
• Masalah pengiraan - kelompok. Di sini, kelajuan pemprosesan setiap permintaan khusus tidak penting. Bagi mereka, adalah penting berapa banyak pengiraan yang akan dilakukan oleh tugas ini dalam jangka masa tertentu (panjang) (throughput). Ini akan menjadi sebarang tugas MapReduce, Hadoop, pembelajaran mesin, statistik.
• Tugas latar belakang - melahu. Untuk tugasan sebegitu, kependaman mahupun pemprosesan adalah sangat penting. Ini termasuk pelbagai ujian, migrasi, pengiraan semula dan penukaran data daripada satu format ke format yang lain. Di satu pihak, ia adalah serupa dengan yang dikira, sebaliknya, ia tidak begitu penting kepada kami seberapa cepat ia disiapkan.

Mari lihat bagaimana tugas sedemikian menggunakan sumber, contohnya, pemproses pusat.

Tugasan kelewatan yang singkat. Tugas sedemikian akan mempunyai corak penggunaan CPU yang serupa dengan ini:

Permintaan daripada pengguna diterima untuk diproses, tugas mula menggunakan semua teras CPU yang tersedia, memprosesnya, mengembalikan respons, menunggu permintaan seterusnya dan berhenti. Permintaan seterusnya tiba - sekali lagi kami memilih semua yang ada, mengiranya, dan menunggu yang seterusnya.

Untuk menjamin kependaman minimum untuk tugasan sedemikian, kita mesti mengambil sumber maksimum yang digunakan dan menyimpan bilangan teras yang diperlukan pada minion (mesin yang akan melaksanakan tugas itu). Maka formula tempahan untuk masalah kami adalah seperti berikut:

alloc: cpu = 4 (max)

dan jika kita mempunyai mesin minion dengan 16 teras, maka tepat empat tugas sedemikian boleh diletakkan di atasnya. Kami terutamanya perhatikan bahawa purata penggunaan pemproses tugas sedemikian selalunya sangat rendah - yang jelas, kerana sebahagian besar masa tugas itu menunggu permintaan dan tidak melakukan apa-apa.

Tugas pengiraan. Corak mereka akan berbeza sedikit:

Purata penggunaan sumber CPU untuk tugasan tersebut agak tinggi. Selalunya kita mahu tugas pengiraan diselesaikan dalam jangka masa tertentu, jadi kita perlu menempah bilangan pemproses minimum yang diperlukan supaya keseluruhan pengiraan selesai dalam masa yang boleh diterima. Formula tempahannya akan kelihatan seperti ini:

alloc: cpu = [1,*)

"Sila letakkannya pada minion di mana terdapat sekurang-kurangnya satu teras bebas, dan kemudian seberapa banyak yang ada, ia akan memakan segala-galanya."

Di sini kecekapan penggunaan sudah jauh lebih baik daripada tugasan dengan kelewatan yang singkat. Tetapi keuntungan akan menjadi lebih besar jika anda menggabungkan kedua-dua jenis tugas pada satu mesin minion dan mengagihkan sumbernya semasa dalam perjalanan. Apabila tugas dengan kelewatan yang singkat memerlukan pemproses, ia menerimanya dengan segera, dan apabila sumber tidak diperlukan lagi, ia dipindahkan ke tugas pengiraan, iaitu sesuatu seperti ini:

Tetapi bagaimana caranya?

Mula-mula, mari kita lihat prod dan peruntukannya: cpu = 4. Kita perlu menempah empat teras. Dalam Docker run ini boleh dilakukan dalam dua cara:

• Menggunakan pilihan --cpuset=1-4, iaitu memperuntukkan empat teras khusus pada mesin kepada tugas.
• Guna --cpuquota=400_000 --cpuperiod=100_000, tetapkan kuota untuk masa pemproses, iaitu menunjukkan bahawa setiap 100 ms masa nyata tugas itu menggunakan tidak lebih daripada 400 ms masa pemproses. Empat teras yang sama diperolehi.

Tetapi kaedah manakah yang sesuai?

cpuset kelihatan agak menarik. Tugas ini mempunyai empat teras khusus, yang bermaksud bahawa cache pemproses akan berfungsi dengan cekap yang mungkin. Ini juga mempunyai kelemahan: kita perlu mengambil tugas untuk mengagihkan pengiraan merentasi teras mesin yang tidak dimuatkan dan bukannya OS, dan ini adalah tugas yang agak tidak remeh, terutamanya jika kita cuba meletakkan tugas kelompok pada seperti itu. mesin. Ujian telah menunjukkan bahawa pilihan dengan kuota lebih sesuai di sini: dengan cara ini sistem pengendalian mempunyai lebih kebebasan dalam memilih teras untuk melaksanakan tugas pada masa semasa dan masa pemproses diagihkan dengan lebih cekap.

Mari kita fikirkan cara membuat tempahan di Docker berdasarkan bilangan teras minimum. Kuota untuk tugasan kelompok tidak lagi terpakai, kerana tidak perlu mengehadkan maksimum, cukup hanya menjamin minimum. Dan di sini pilihannya sesuai dengan baik docker run --cpushares.

Kami bersetuju bahawa jika kumpulan memerlukan jaminan untuk sekurang-kurangnya satu teras, maka kami menunjukkan --cpushares=1024, dan jika terdapat sekurang-kurangnya dua teras, maka kami menunjukkan --cpushares=2048. Saham cpu tidak mengganggu apa-apa cara dengan pengagihan masa pemproses selagi ia mencukupi. Oleh itu, jika prod tidak menggunakan keempat-empat terasnya pada masa ini, tiada apa-apa yang mengehadkan tugas kelompok, dan mereka boleh menggunakan masa pemproses tambahan. Tetapi dalam keadaan kekurangan pemproses, jika prod telah menggunakan keempat-empat terasnya dan telah mencapai kuotanya, baki masa pemproses akan dibahagikan secara berkadar kepada cpushares, iaitu dalam situasi tiga teras bebas, satu akan menjadi diberikan kepada tugasan dengan 1024 cpushares, dan baki dua lagi akan diberikan kepada tugasan dengan 2048 cpushares.

Tetapi menggunakan kuota dan saham tidak mencukupi. Kita perlu memastikan bahawa tugasan dengan kelewatan yang singkat mendapat keutamaan berbanding tugasan kelompok apabila memperuntukkan masa pemproses. Tanpa keutamaan sedemikian, tugas kelompok akan mengambil semua masa pemproses pada masa ini apabila ia diperlukan oleh prod. Tiada pilihan keutamaan kontena dalam Docker run, tetapi dasar penjadual CPU Linux berguna. Anda boleh membaca tentang mereka secara terperinci di sini, dan dalam rangka artikel ini kami akan membincangkannya secara ringkas:

• SCHED_OTHER
  Secara lalai, semua proses pengguna biasa pada mesin Linux menerima.
• SCHED_BATCH
  Direka untuk proses intensif sumber. Apabila meletakkan tugas pada pemproses, apa yang dipanggil penalti pengaktifan diperkenalkan: tugas sedemikian kurang berkemungkinan menerima sumber pemproses jika ia sedang digunakan oleh tugas dengan SCHED_OTHER
• SCHED_IDLE
  Proses latar belakang dengan keutamaan yang sangat rendah, malah lebih rendah daripada bagus -19. Kami menggunakan perpustakaan sumber terbuka kami one-nio, untuk menetapkan dasar yang diperlukan apabila memulakan bekas dengan memanggil

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

Tetapi walaupun anda tidak memprogramkan dalam Java, perkara yang sama boleh dilakukan menggunakan arahan chrt:

chrt -i 0 $pid

Mari kita ringkaskan semua tahap pengasingan kita ke dalam satu jadual untuk kejelasan:

Kelas penebat
Contoh Alloc
Pilihan larian Docker
sched_setscheduler chrt*

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

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

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

*Jika anda melakukan chrt dari dalam bekas, anda mungkin memerlukan keupayaan sys_nice, kerana secara lalai Docker mengalih keluar keupayaan ini apabila memulakan bekas.

Tetapi tugas menggunakan bukan sahaja pemproses, tetapi juga lalu lintas, yang menjejaskan kependaman tugas rangkaian lebih daripada peruntukan sumber pemproses yang salah. Oleh itu, kami sememangnya mahu mendapatkan gambaran yang sama untuk trafik. Iaitu, apabila tugas prod menghantar beberapa paket ke rangkaian, kami mengehadkan kelajuan maksimum (formula peruntukan: lan=[*,500mbps) ), dengan mana prod boleh melakukan ini. Dan untuk kumpulan kami hanya menjamin daya pengeluaran minimum, tetapi tidak mengehadkan maksimum (formula peruntukkan: lan=[10Mbps,*) ) Dalam kes ini, trafik prod harus mendapat keutamaan berbanding tugas kelompok.
Di sini Docker tidak mempunyai sebarang primitif yang boleh kami gunakan. Tetapi ia datang untuk membantu kita Kawalan Trafik Linux. Kami dapat mencapai keputusan yang diinginkan dengan bantuan disiplin Keluk Perkhidmatan Adil Hierarki. Dengan bantuannya, kami membezakan dua kelas trafik: prod keutamaan tinggi dan kelompok/terbiar keutamaan rendah. Akibatnya, konfigurasi untuk trafik keluar adalah seperti ini:

di sini 1:0 ialah “root qdisc” bagi disiplin hsfc; 1:1 - kelas kanak-kanak hsfc dengan jumlah had lebar jalur 8 Gbit/s, di mana kelas kanak-kanak semua bekas diletakkan; 1:2 - kelas anak hsfc adalah biasa untuk semua tugasan kelompok dan terbiar dengan had "dinamik", yang dibincangkan di bawah. Kelas anak hsfc yang selebihnya adalah kelas khusus untuk bekas prod yang sedang dijalankan dengan had yang sepadan dengan manifesnya - 450 dan 400 Mbit/s. Setiap kelas hsfc diberikan baris gilir qdisc fq atau fq_codel, bergantung pada versi kernel Linux, untuk mengelakkan kehilangan paket semasa trafik pecah.

Biasanya, disiplin tc berfungsi untuk mengutamakan trafik keluar sahaja. Tetapi kami mahu mengutamakan trafik masuk juga - lagipun, beberapa tugas kelompok boleh memilih keseluruhan saluran masuk dengan mudah, menerima, sebagai contoh, kumpulan besar data input untuk peta&kurangkan. Untuk ini kami menggunakan modul ifb, yang mencipta antara muka maya ifbX untuk setiap antara muka rangkaian dan mengubah hala trafik masuk daripada antara muka kepada trafik keluar pada ifbX. Selanjutnya, untuk ifbX, semua disiplin yang sama berfungsi untuk mengawal trafik keluar, yang mana konfigurasi hsfc akan sangat serupa:

Semasa percubaan, kami mendapati bahawa hsfc menunjukkan hasil terbaik apabila kelas 1:2 bagi kumpulan/trafik terbiar bukan keutamaan dihadkan pada mesin minion kepada tidak lebih daripada lorong bebas tertentu. Jika tidak, trafik bukan keutamaan mempunyai terlalu banyak kesan pada kependaman tugas prod. miniond menentukan amaun semasa lebar jalur percuma setiap saat, mengukur purata penggunaan trafik bagi semua prod-tugas minion tertentu dan menolaknya daripada lebar jalur antara muka rangkaian dengan margin kecil, i.e.

Band ditakrifkan secara bebas untuk trafik masuk dan keluar. Dan mengikut nilai baharu, miniond mengkonfigurasi semula had kelas bukan keutamaan 1:2.

Oleh itu, kami melaksanakan ketiga-tiga kelas pengasingan: prod, batch dan melahu. Kelas ini sangat mempengaruhi ciri prestasi tugas. Oleh itu, kami memutuskan untuk meletakkan atribut ini di bahagian atas hierarki, supaya apabila melihat nama baris gilir hierarki ia akan segera jelas apa yang kami hadapi:

Semua kawan kita web и muzik bahagian hadapan kemudiannya diletakkan dalam hierarki di bawah prod. Sebagai contoh, di bawah kumpulan, mari letak perkhidmatan katalog muzik, yang secara berkala menyusun katalog trek daripada set fail mp3 yang dimuat naik ke Odnoklassniki. Contoh perkhidmatan dalam keadaan terbiar ialah pengubah muzik, yang menormalkan tahap kelantangan muzik.

Dengan baris tambahan dialih keluar semula, kami boleh menulis nama perkhidmatan kami dengan lebih rata dengan menambahkan kelas pengasingan tugas pada penghujung nama perkhidmatan penuh: web.front.prod, catalog.music.batch, transformer.music.idle.

Dan sekarang, melihat nama perkhidmatan, kami memahami bukan sahaja fungsi apa yang dilakukannya, tetapi juga kelas pengasingannya, yang bermaksud kritikalnya, dsb.

Semuanya hebat, tetapi ada satu kebenaran yang pahit. Adalah mustahil untuk mengasingkan sepenuhnya tugas yang dijalankan pada satu mesin.

Perkara yang kami berjaya capai: jika kumpulan menggunakan secara intensif sahaja Sumber CPU, kemudian penjadual CPU Linux terbina dalam menjalankan tugasnya dengan baik, dan boleh dikatakan tiada kesan pada tugas prod. Tetapi jika tugas kumpulan ini mula berfungsi secara aktif dengan ingatan, maka pengaruh bersama sudah muncul. Ini berlaku kerana tugas prod "dihapuskan" daripada cache memori pemproses - akibatnya, cache terlepas meningkat, dan pemproses memproses tugas prod dengan lebih perlahan. Tugas kelompok sedemikian boleh meningkatkan kependaman bekas prod biasa kami sebanyak 10%.

Mengasingkan trafik adalah lebih sukar kerana fakta bahawa kad rangkaian moden mempunyai baris gilir dalaman paket. Jika paket daripada tugas kelompok sampai ke sana dahulu, maka ia akan menjadi yang pertama dihantar melalui kabel, dan tiada apa yang boleh dilakukan mengenainya.

Di samping itu, kami setakat ini hanya berjaya menyelesaikan masalah mengutamakan trafik TCP: pendekatan hsfc tidak berfungsi untuk UDP. Dan walaupun dalam kes trafik TCP, jika tugas kelompok menjana banyak trafik, ini juga memberikan kira-kira 10% peningkatan dalam kelewatan tugas prod.

toleransi kesalahan

Salah satu matlamat semasa membangunkan satu awan adalah untuk meningkatkan toleransi kesalahan Odnoklassniki. Oleh itu, seterusnya saya ingin mempertimbangkan dengan lebih terperinci kemungkinan senario kegagalan dan kemalangan. Mari kita mulakan dengan senario mudah - kegagalan kontena.

Bekas itu sendiri boleh gagal dalam beberapa cara. Ini mungkin sejenis percubaan, pepijat atau ralat dalam manifes, akibatnya tugas prod mula menggunakan lebih banyak sumber daripada yang ditunjukkan dalam manifes. Kami mempunyai kes: pembangun melaksanakan satu algoritma yang kompleks, mengolahnya berkali-kali, terlalu memikirkan dirinya sendiri dan menjadi sangat keliru sehingga akhirnya masalah itu menjadi gelung yang sangat tidak remeh. Dan oleh kerana tugas prod mempunyai keutamaan yang lebih tinggi daripada semua yang lain pada minion yang sama, ia mula menggunakan semua sumber pemproses yang ada. Dalam keadaan ini, pengasingan, atau lebih tepatnya kuota masa CPU, menyelamatkan hari itu. Jika tugasan diperuntukkan kuota, tugas itu tidak akan menggunakan lebih banyak. Oleh itu, kumpulan dan tugas prod lain yang dijalankan pada mesin yang sama tidak menyedari apa-apa.

Masalah kedua yang mungkin adalah bekas jatuh. Dan di sini mulakan semula dasar menyelamatkan kami, semua orang tahu mereka, Docker sendiri melakukan kerja yang hebat. Hampir semua tugas prod mempunyai dasar sentiasa dimulakan semula. Kadangkala kami menggunakan on_failure untuk tugasan kelompok atau untuk menyahpepijat bekas prod.

Apa yang boleh anda lakukan jika keseluruhan minion tidak tersedia?

Jelas sekali, jalankan bekas pada mesin lain. Bahagian yang menarik di sini ialah apa yang berlaku kepada alamat IP yang diberikan kepada bekas.

Kami boleh menetapkan bekas alamat IP yang sama seperti mesin minion tempat bekas ini dijalankan. Kemudian, apabila bekas itu dilancarkan pada mesin lain, alamat IPnya berubah, dan semua pelanggan mesti memahami bahawa bekas itu telah berpindah, dan kini mereka perlu pergi ke alamat lain, yang memerlukan perkhidmatan Penemuan Perkhidmatan yang berasingan.

Penemuan Perkhidmatan adalah mudah. Terdapat banyak penyelesaian di pasaran dengan pelbagai tahap toleransi kesalahan untuk mengatur pendaftaran perkhidmatan. Selalunya penyelesaian sedemikian melaksanakan logik pengimbang beban, menyimpan konfigurasi tambahan dalam bentuk storan KV, dsb.
Walau bagaimanapun, kami ingin mengelakkan keperluan untuk melaksanakan pendaftaran berasingan, kerana ini bermakna memperkenalkan sistem kritikal yang digunakan oleh semua perkhidmatan dalam pengeluaran. Ini bermakna bahawa ini adalah titik kegagalan yang berpotensi, dan anda perlu memilih atau membangunkan penyelesaian yang sangat tahan terhadap kesalahan, yang jelas sangat sukar, memakan masa dan mahal.

Dan satu lagi kelemahan besar: agar infrastruktur lama kami berfungsi dengan yang baharu, kami perlu menulis semula sepenuhnya semua tugas untuk menggunakan beberapa jenis sistem Penemuan Perkhidmatan. Terdapat BANYAK kerja, dan di beberapa tempat ia hampir mustahil apabila melibatkan peranti peringkat rendah yang berfungsi pada tahap kernel OS atau secara langsung dengan perkakasan. Pelaksanaan fungsi ini menggunakan corak penyelesaian yang telah ditetapkan, seperti kereta sampingan bermakna di beberapa tempat beban tambahan, di tempat lain - komplikasi operasi dan senario kegagalan tambahan. Kami tidak mahu merumitkan perkara, jadi kami memutuskan untuk menjadikan penggunaan Penemuan Perkhidmatan sebagai pilihan.

Dalam satu awan, IP mengikuti bekas, iaitu setiap contoh tugas mempunyai alamat IP sendiri. Alamat ini "statik": ia diberikan kepada setiap kejadian apabila perkhidmatan pertama dihantar ke awan. Jika perkhidmatan mempunyai bilangan kejadian yang berbeza semasa hayatnya, maka pada akhirnya ia akan diberikan seberapa banyak alamat IP kerana terdapat kejadian maksimum.

Selepas itu, alamat ini tidak berubah: ia diberikan sekali dan terus wujud sepanjang hayat perkhidmatan dalam pengeluaran. Alamat IP mengikut bekas merentas rangkaian. Jika bekas itu dipindahkan ke minion lain, maka alamat akan mengikutinya.

Oleh itu, pemetaan nama perkhidmatan kepada senarai alamat IPnya jarang berubah. Jika anda melihat sekali lagi pada nama contoh perkhidmatan yang kami nyatakan pada permulaan artikel (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), kami akan melihat bahawa ia menyerupai FQDN yang digunakan dalam DNS. Betul, untuk memetakan nama contoh perkhidmatan ke alamat IP mereka, kami menggunakan protokol DNS. Selain itu, DNS ini mengembalikan semua alamat IP yang dikhaskan untuk semua bekas - kedua-duanya berjalan dan berhenti (katakan tiga replika digunakan, dan kami mempunyai lima alamat dikhaskan di sana - kelima-limanya akan dikembalikan). Pelanggan, setelah menerima maklumat ini, akan cuba mewujudkan sambungan dengan semua lima replika - dan dengan itu menentukan mereka yang berfungsi. Pilihan untuk menentukan ketersediaan ini adalah lebih dipercayai; ia tidak melibatkan sama ada DNS atau Penemuan Perkhidmatan, yang bermaksud tiada masalah sukar untuk diselesaikan dalam memastikan perkaitan maklumat dan toleransi kesalahan sistem ini. Selain itu, dalam perkhidmatan kritikal di mana operasi keseluruhan portal bergantung, kami tidak boleh menggunakan DNS sama sekali, tetapi hanya masukkan alamat IP ke dalam konfigurasi.

Melaksanakan pemindahan IP sebegitu di belakang bekas boleh menjadi bukan perkara remeh - dan kami akan melihat cara ia berfungsi dengan contoh berikut:

Katakan tuan satu awan memberikan arahan kepada minion M1 untuk dijalankan 1.ok-web.group1.web.front.prod dengan alamat 1.1.1.1. Bekerja pada minion BURUNG, yang mengiklankan alamat ini kepada pelayan khas pemantul laluan. Yang terakhir mempunyai sesi BGP dengan perkakasan rangkaian, di mana laluan alamat 1.1.1.1 pada M1 diterjemahkan. M1 laluan paket di dalam bekas menggunakan Linux. Terdapat tiga pelayan pemantul laluan, kerana ini adalah bahagian yang sangat kritikal dalam infrastruktur satu awan - tanpa mereka, rangkaian dalam satu awan tidak akan berfungsi. Kami meletakkannya di rak yang berbeza, jika boleh terletak di bilik yang berbeza di pusat data, untuk mengurangkan kemungkinan ketiga-tiganya gagal pada masa yang sama.

Sekarang mari kita anggap bahawa sambungan antara master satu awan dan minion M1 telah hilang. Induk satu awan kini akan bertindak atas andaian bahawa M1 telah gagal sepenuhnya. Iaitu, ia akan memberi arahan kepada minion M2 untuk melancarkan web.group1.web.front.prod dengan alamat yang sama 1.1.1.1. Sekarang kita mempunyai dua laluan bercanggah pada rangkaian untuk 1.1.1.1: pada M1 dan pada M2. Untuk menyelesaikan konflik tersebut, kami menggunakan Diskriminator Berbilang Keluar, yang dinyatakan dalam pengumuman BGP. Ini ialah nombor yang menunjukkan berat laluan yang diiklankan. Antara laluan yang bercanggah, laluan dengan nilai MED yang lebih rendah akan dipilih. Master satu awan menyokong MED sebagai bahagian penting alamat IP kontena. Buat pertama kalinya, alamat ditulis dengan MED yang cukup besar = 1. Dalam situasi pemindahan kontena kecemasan sedemikian, tuan mengurangkan MED, dan M000 sudah akan menerima arahan untuk mengiklankan alamat 000 dengan MED = 2. Contoh yang berjalan pada M1.1.1.1 akan kekal di dalam kes ini tidak ada kaitan, dan nasib selanjutnya tidak menarik minat kami sehingga hubungan dengan tuan dipulihkan, apabila dia akan dihentikan seperti pengambilan lama.

kemalangan

Semua sistem pengurusan pusat data sentiasa mengendalikan kegagalan kecil dengan boleh diterima. Limpahan bekas adalah perkara biasa hampir di mana-mana.

Mari lihat cara kami mengendalikan kecemasan, seperti kegagalan kuasa dalam satu atau lebih bilik pusat data.

Apakah maksud kemalangan untuk sistem pengurusan pusat data? Pertama sekali, ini adalah kegagalan besar sekali bagi banyak mesin, dan sistem kawalan perlu memindahkan banyak bekas pada masa yang sama. Tetapi jika bencana itu sangat berskala besar, maka mungkin berlaku bahawa semua tugas tidak boleh diperuntukkan semula kepada minions lain, kerana kapasiti sumber pusat data turun di bawah 100% daripada beban.

Selalunya kemalangan disertai dengan kegagalan lapisan kawalan. Ini boleh berlaku disebabkan oleh kegagalan peralatannya, tetapi lebih kerap disebabkan oleh fakta bahawa kemalangan tidak diuji, dan lapisan kawalan itu sendiri jatuh disebabkan oleh peningkatan beban.

Apa yang anda boleh lakukan tentang semua ini?

Penghijrahan besar-besaran bermakna terdapat sejumlah besar aktiviti, migrasi dan penempatan berlaku dalam infrastruktur. Setiap migrasi mungkin mengambil sedikit masa yang diperlukan untuk menghantar dan membongkar imej kontena kepada minion, melancarkan dan memulakan bekas, dsb. Oleh itu, adalah wajar tugas yang lebih penting dilancarkan sebelum tugas yang kurang penting.

Mari kita lihat semula hierarki perkhidmatan yang kita kenali dan cuba tentukan tugasan yang ingin kita jalankan dahulu.

Sudah tentu, ini adalah proses yang terlibat secara langsung dalam memproses permintaan pengguna, iaitu prod. Kami menunjukkan ini dengan keutamaan penempatan — nombor yang boleh diberikan kepada baris gilir. Jika baris gilir mempunyai keutamaan yang lebih tinggi, perkhidmatannya diutamakan.

Pada prod kami menetapkan keutamaan yang lebih tinggi, 0; pada kelompok - sedikit lebih rendah, 100; pada terbiar - lebih rendah, 200. Keutamaan digunakan secara hierarki. Semua tugas yang lebih rendah dalam hierarki akan mempunyai keutamaan yang sepadan. Jika kami mahu cache di dalam prod dilancarkan sebelum bahagian hadapan, maka kami menetapkan keutamaan kepada cache = 0 dan ke baris gilir hadapan = 1. Jika, sebagai contoh, kami mahu portal utama dilancarkan dari hadapan dahulu, dan bahagian hadapan muzik sahaja kemudian, maka kita boleh menetapkan keutamaan yang lebih rendah kepada yang terakhir - 10.

Masalah seterusnya ialah kekurangan sumber. Oleh itu, sejumlah besar peralatan, keseluruhan dewan pusat data, gagal, dan kami melancarkan semula begitu banyak perkhidmatan yang kini tidak mempunyai sumber yang mencukupi untuk semua orang. Anda perlu memutuskan tugas mana yang perlu dikorbankan untuk memastikan perkhidmatan kritikal utama berjalan.

Tidak seperti keutamaan penempatan, kami tidak boleh mengorbankan semua tugas kelompok secara sembarangan; sesetengah daripadanya penting untuk pengendalian portal. Oleh itu, kami telah menyerlahkan secara berasingan keutamaan pendahuluan tugasan. Apabila diletakkan, tugas keutamaan yang lebih tinggi boleh mendahului, iaitu berhenti, tugas keutamaan yang lebih rendah jika tiada lagi minion percuma. Dalam kes ini, tugas dengan keutamaan yang rendah mungkin akan kekal tidak ditempatkan, iaitu tidak akan ada lagi minion yang sesuai untuknya dengan sumber percuma yang mencukupi.

Dalam hierarki kami, adalah sangat mudah untuk menentukan keutamaan preemption supaya tugas prod dan batch mendahului atau menghentikan tugasan terbiar, tetapi tidak antara satu sama lain, dengan menentukan keutamaan untuk melahu bersamaan dengan 200. Sama seperti dalam kes keutamaan peletakan, kami boleh menggunakan hierarki kami untuk menerangkan peraturan yang lebih kompleks. Sebagai contoh, mari kita nyatakan bahawa kita mengorbankan fungsi muzik jika kita tidak mempunyai sumber yang mencukupi untuk portal web utama, menetapkan keutamaan untuk nod yang sepadan lebih rendah: 10.

Keseluruhan kemalangan DC

Mengapa keseluruhan pusat data mungkin gagal? unsur. Adalah jawatan yang bagus taufan menjejaskan kerja pusat data. Unsur-unsur itu boleh dianggap sebagai gelandangan yang pernah membakar optik dalam manifold, dan pusat data benar-benar terputus hubungan dengan tapak lain. Punca kegagalan juga boleh menjadi faktor manusia: pengendali akan mengeluarkan arahan sedemikian sehingga keseluruhan pusat data akan jatuh. Ini boleh berlaku kerana pepijat besar. Secara umum, pusat data runtuh bukan perkara biasa. Ini berlaku kepada kita sekali setiap beberapa bulan.

Dan inilah yang kami lakukan untuk menghalang sesiapa daripada tweet #hidup.

Strategi pertama ialah pengasingan. Setiap kejadian satu awan diasingkan dan boleh mengurus mesin dalam satu pusat data sahaja. Iaitu, kehilangan awan akibat pepijat atau arahan operator yang salah adalah kehilangan hanya satu pusat data. Kami bersedia untuk ini: kami mempunyai dasar redundansi di mana replika aplikasi dan data terletak di semua pusat data. Kami menggunakan pangkalan data tahan kesalahan dan menguji kegagalan secara berkala.
Sejak hari ini kami mempunyai empat pusat data, ini bermakna empat kejadian satu awan yang berasingan dan terpencil sepenuhnya.

Pendekatan ini bukan sahaja melindungi daripada kegagalan fizikal, tetapi juga boleh melindungi daripada ralat operator.

Apa lagi yang boleh dilakukan dengan faktor manusia? Apabila pengendali memberikan awan beberapa arahan yang pelik atau berpotensi berbahaya, dia mungkin tiba-tiba diminta menyelesaikan masalah kecil untuk melihat sejauh mana dia berfikir. Contohnya, jika ini adalah sejenis hentian besar-besaran bagi banyak replika atau hanya arahan pelik - mengurangkan bilangan replika atau menukar nama imej, dan bukan hanya nombor versi dalam manifes baharu.

Keputusan

Ciri khas satu awan:

• Skim penamaan hierarki dan visual untuk perkhidmatan dan bekas, yang membolehkan anda mengetahui dengan cepat apakah tugas itu, apa kaitannya dan cara ia berfungsi dan siapa yang bertanggungjawab ke atasnya.
• Kami memohon kami teknik menggabungkan prod dan batch-tugas ke atas minion untuk meningkatkan kecekapan perkongsian mesin. Daripada cpuset kami menggunakan kuota CPU, saham, dasar penjadual CPU dan QoS Linux.
• Tidak mungkin untuk mengasingkan sepenuhnya bekas yang berjalan pada mesin yang sama, tetapi pengaruh bersama mereka kekal dalam 20%.
• Mengatur perkhidmatan ke dalam hierarki membantu dengan pemulihan bencana automatik menggunakan keutamaan penempatan dan pendahuluan.

Soalan Lazim

Mengapa kita tidak mengambil penyelesaian siap sedia?

• Kelas pengasingan tugas yang berbeza memerlukan logik yang berbeza apabila diletakkan pada minion. Jika tugas prod boleh diletakkan dengan hanya menempah sumber, maka tugas kelompok dan terbiar mesti diletakkan, menjejaki penggunaan sebenar sumber pada mesin minion.
• Keperluan untuk mengambil kira sumber yang digunakan oleh tugas, seperti:
  • lebar jalur rangkaian;
  • jenis dan "spindel" cakera.
• Keperluan untuk menunjukkan keutamaan perkhidmatan semasa tindak balas kecemasan, hak dan kuota arahan untuk sumber, yang diselesaikan menggunakan baris gilir hierarki dalam satu awan.
• Keperluan untuk menamakan bekas oleh manusia untuk mengurangkan masa tindak balas terhadap kemalangan dan insiden
• Kemustahilan pelaksanaan Penemuan Perkhidmatan secara meluas sekali; keperluan untuk wujud bersama untuk masa yang lama dengan tugas yang dihoskan pada hos perkakasan - sesuatu yang diselesaikan oleh alamat IP "statik" berikutan bekas, dan, sebagai akibatnya, keperluan untuk penyepaduan unik dengan infrastruktur rangkaian yang besar.

Semua fungsi ini memerlukan pengubahsuaian ketara bagi penyelesaian sedia ada agar sesuai dengan kami, dan, setelah menilai jumlah kerja, kami menyedari bahawa kami boleh membangunkan penyelesaian kami sendiri dengan kos buruh yang lebih kurang sama. Tetapi penyelesaian anda akan menjadi lebih mudah untuk dikendalikan dan dibangunkan - ia tidak mengandungi abstraksi yang tidak perlu yang menyokong fungsi yang tidak kami perlukan.

Kepada mereka yang membaca baris terakhir, terima kasih atas kesabaran dan perhatian anda!

Sumber: www.habr.com