Manajemen kluster sing efisien lan dipercaya ing skala apa wae karo Tupperware
Dina iki kita ngenalake Tupperware, sistem manajemen kluster sing ngatur kontaner ing jutaan server sing mlaku meh kabeh layanan. Kita pisanan nyebarake Tupperware ing 2011, lan wiwit iku infrastruktur kita wis thukul saka kanggo kabèh . Kabeh wektu iki, Tupperware ora mandheg lan berkembang karo kita. Kita bakal nuduhake sampeyan carane Tupperware nyedhiyakake manajemen kluster kelas siji, kalebu dhukungan trep kanggo layanan stateful, panel kontrol siji kanggo kabeh pusat data, lan kemampuan kanggo nyebarake kapasitas antarane layanan ing wektu nyata. Kita uga bakal nuduhake pelajaran sing wis kita sinau nalika infrastruktur kita berkembang.
Tupperware nindakake tugas sing beda-beda. Pangembang aplikasi nggunakake aplikasi kasebut kanggo ngirim lan ngatur aplikasi. Iku paket kode aplikasi lan dependensi menyang gambar lan ngirim menyang server minangka wadhah. Wadah nyedhiyakake pamisahan antarane aplikasi ing server sing padha supaya pangembang ngatasi logika aplikasi lan ora kudu kuwatir babagan nemokake server utawa ngatur nganyari. Tupperware uga ngawasi kinerja server, lan yen nemokake gagal, iku nransfer kontaner saka server masalah.
Insinyur perencanaan kapasitas nggunakake Tupperware kanggo nyedhiyakake kapasitas server menyang tim adhedhasar anggaran lan kendala. Dheweke uga nggunakake kanggo nambah panggunaan server. Operator pusat data nguripake Tupperware kanggo nyebarake wadhah kanthi bener ing pusat data lan mungkasi utawa mindhah wadhah sajrone pangopènan. Thanks kanggo iki, njaga server, jaringan lan peralatan mbutuhake campur tangan manungsa minimal.
Arsitektur Tupperware
Arsitektur Tupperware PRN minangka salah sawijining wilayah pusat data kita. Wilayah kasebut kalebu sawetara bangunan pusat data (PRN1 lan PRN2) sing ana ing sacedhake. Kita rencana nggawe siji panel kontrol sing bakal ngatur kabeh server ing siji wilayah.
Pangembang aplikasi ngirim layanan ing wangun proyek Tupperware. A proyek kasusun saka sawetara kontaner, lan kabeh padha biasane mbukak kode aplikasi padha.
Tupperware tanggung jawab kanggo nyedhiyakake kontainer lan ngatur siklus uripe. Iku kasusun saka sawetara komponen:
- Frontend Tupperware nyedhiyakake API kanggo antarmuka panganggo, CLI, lan alat otomatisasi liyane sing bisa digunakake kanggo sesambungan karo Tupperware. Dheweke ndhelikake kabeh struktur internal saka pamilik proyek Tupperware.
- Tupperware Scheduler minangka panel kontrol sing tanggung jawab kanggo ngatur wadhah lan siklus urip proyek. Iki disebarake ing tingkat regional lan global, ing ngendi panjadwal regional ngatur server ing sawijining wilayah lan panjadwal global ngatur server saka macem-macem wilayah. Penjadwal dipérang dadi pecahan, lan saben beling ngatur sakumpulan proyek.
- Proksi Penjadwal Tupperware ndhelikake sharding internal lan nyedhiyakake panel kaca tunggal sing trep kanggo pangguna Tupperware.
- Allocator Tupperware menehi kontaner menyang server. Penjadwal nangani mungkasi, miwiti, nganyari, lan failover saka kontaner. Saiki, siji allocator bisa ngatur kabeh wilayah tanpa dibagi dadi pecahan. (Elinga prabédan ing terminologi. Contone, panjadwal ing Tupperware cocog karo panel kontrol ing , lan alokasi Tupperware diarani panjadwal ing Kubernetes.)
- Broker sumber daya nyimpen sumber bebener kanggo acara server lan layanan. Kita mbukak siji broker sumber daya kanggo saben pusat data, lan nyimpen kabeh informasi babagan server ing pusat data kasebut. Broker sumber daya lan sistem manajemen kapasitas, utawa sistem penyediaan sumber daya, kanthi dinamis mutusake pangiriman panjadwal sing ngontrol server endi. Layanan mriksa kesehatan ngawasi server lan nyimpen data babagan kesehatane ing makelar sumber daya. Yen server duwe masalah utawa mbutuhake pangopènan, broker sumber ngandhani allocator lan panjadwal kanggo mungkasi kontaner utawa pindhah menyang server liyane.
- Agen Tupperware minangka daemon sing mlaku ing saben server sing nyiapake lan mbusak wadhah. Aplikasi mbukak ing wadhah, sing menehi isolasi lan reproducibility luwih akeh. On Kita wis nerangake carane wadhah Tupperware individu digawe nggunakake gambar, btrfs, cgroupv2 lan systemd.
Fitur khas Tupperware
Tupperware meh padha karo sistem manajemen kluster liyane kayata Kubernetes lan , nanging uga ana bedane:
- Dhukungan sing dibangun kanggo layanan stateful.
- Panel kontrol siji kanggo server ing pusat data sing beda kanggo ngotomatisasi pangiriman kontaner adhedhasar maksud, decommissioning kluster lan pangopènan.
- Divisi sing jelas saka panel kontrol kanggo zoom.
- Komputasi elastis ngidini sampeyan nyebarake daya ing antarane layanan kanthi wektu nyata.
Kita ngembangake fitur-fitur keren iki kanggo ndhukung macem-macem aplikasi stateless lan stateful ing armada server bareng global sing gedhe.
Dhukungan sing dibangun kanggo layanan stateful.
Tupperware ngoperasikake macem-macem layanan stateful kritis sing nyimpen data produk sing terus-terusan kanggo Facebook, Instagram, Messenger lan WhatsApp. Iki bisa dadi toko gedhe saka pasangan nilai kunci (contone. ) lan ngawasi repositori data (contone, и ). Njaga layanan stateful ora gampang, amarga sistem kudu mesthekake yen pasokan kontainer bisa tahan gangguan gedhe-gedhe, kalebu gangguan jaringan utawa mati listrik. Lan nalika teknik konvensional, kayata nyebarake wadhah ing domain kesalahan, bisa digunakake kanthi apik kanggo layanan tanpa kewarganegaraan, layanan stateful mbutuhake dhukungan tambahan.
Contone, yen gagal server nggawe siji replika database ora kasedhiya, sampeyan kudu ngaktifake pangopènan otomatis sing bakal nganyari intine ing 50 server saka blumbang 10? Gumantung ing kahanan. Yen salah siji saka 50 server iki duwe tiron liyane saka database padha, iku luwih apik kanggo ngenteni lan ora ilang 2 replika bebarengan. Kanggo nggawe keputusan kanthi dinamis babagan pangopènan lan kinerja sistem, kita butuh informasi babagan replikasi data internal lan logika penempatan saben layanan stateful.
Antarmuka TaskControl ngidini layanan stateful pengaruhe pancasan sing mengaruhi kasedhiyan data. Nggunakake antarmuka iki, panjadwal menehi kabar marang aplikasi eksternal babagan operasi wadah (restart, nganyari, migrasi, pangopènan). Layanan stateful ngetrapake pengontrol sing ngandhani Tupperware nalika aman kanggo nindakake saben operasi, lan operasi kasebut bisa diganti utawa ditundha kanggo sementara. Ing conto ing ndhuwur, pengontrol database bisa ngandhani Tupperware supaya nganyari 49 saka 50 server, nanging saiki mung ninggalake server tartamtu (X). Akibaté, yen wektu nganyari kernel liwat lan database isih ora bisa mulihake replika masalah, Tupperware bakal tetep nganyari server X.
Akeh layanan stateful ing Tupperware nggunakake TaskControl ora langsung, nanging liwat ShardManager, platform umum kanggo nggawe layanan stateful ing Facebook. Kanthi Tupperware, pangembang bisa nemtokake tujuane kanggo persis carane wadah kudu disebarake ing pusat data. Kanthi ShardManager, pangembang nemtokake maksude babagan carane pecahan data kudu disebarake ing wadhah. ShardManager ngerti babagan penempatan data lan replikasi aplikasi lan komunikasi karo Tupperware liwat antarmuka TaskControl kanggo jadwal operasi wadhah tanpa keterlibatan aplikasi langsung. Integrasi iki banget nyederhanakake manajemen layanan stateful, nanging TaskControl bisa luwih akeh. Contone, undakan web ekstensif kita ora duwe kewarganegaraan lan nggunakake TaskControl kanggo nyetel tingkat nganyari menyang wadhah kanthi dinamis. wekasane saben dina tanpa kompromi kasedhiyan.
Ngatur server ing pusat data
Nalika Tupperware pisanan diluncurake ing 2011, saben kluster server dikelola dening panjadwal sing kapisah. Ing wektu iku, klompok Facebook minangka klompok rak server sing disambungake menyang saklar jaringan, lan pusat data duwe sawetara klompok. Penjadwal mung bisa ngatur server ing siji kluster, tegese proyek ora bisa nyebar ing pirang-pirang kluster. Infrastruktur kita tambah akeh, kita tambah akeh ngilangi klompok. Wiwit Tupperware ora bisa mindhah proyek saka kluster decommissioned kanggo kluster liyane tanpa owah-owahan, iku mbutuhake akèh gaweyan lan koordinasi ati-ati antarane pangembang aplikasi lan operator pusat data. Proses iki nyebabake sumber daya boros nalika server nganggur nganti pirang-pirang wulan amarga prosedur decommissioning.
Kita nggawe broker sumber daya kanggo ngatasi masalah decommissioning kluster lan koordinasi jinis tugas pangopènan liyane. Broker sumber daya nglacak kabeh informasi fisik sing ana gandhengane karo server lan kanthi dinamis mutusake panjadwal sing ngontrol saben server. Nghubungake server kanthi dinamis menyang penjadwal ngidini panjadwal ngatur server ing pusat data sing beda. Wiwit proyek Tupperware ora diwatesi maneh ing siji kluster, pangguna Tupperware bisa nemtokake carane wadah kudu disebarake ing domain sing salah. Contone, pangembang bisa ngumumake maksude (ayo ngomong: "nglakokake proyekku ing 2 domain fault ing wilayah PRN") tanpa nemtokake zona kasedhiyan tartamtu. Tupperware dhewe bakal nemokake server sing cocog kanggo ngleksanakake maksud iki, sanajan kluster utawa layanan dinonaktifake.
Scalable kanggo ndhukung kabeh sistem global
Secara historis, infrastruktur kita wis dipérang dadi atusan pool server khusus kanggo tim individu. Amarga fragmentasi lan kurang standar, kita duwe biaya operasional sing dhuwur, lan server nganggur luwih angel digunakake maneh. Ing konferensi taun kepungkur kita presented , sing kudu nggabungake infrastruktur kita dadi taman server tunggal sing gedhe. Nanging taman server siji duwe kesulitan dhewe. Sampeyan kudu nyukupi syarat tartamtu:
- Skalabilitas. Infrastruktur kita tuwuh amarga kita nambahake pusat data ing saben wilayah. Server wis dadi luwih cilik lan luwih irit energi, saengga ana luwih akeh ing saben wilayah. Akibaté, panjadwal siji saben wilayah ora bisa nangani jumlah kontaner sing bisa mbukak ing atusan ewu server ing saben wilayah.
- Reliability Sanajan panjadwal bisa digedhekake, ruang lingkup panjadwal sing gedhe tegese ana risiko kesalahan sing luwih dhuwur lan kabeh wilayah wadhah bisa dadi ora bisa diatur.
- Toleransi kesalahan. Yen ana kegagalan infrastruktur sing gedhe (contone, server sing nglakokake panjadwal gagal amarga gagal jaringan utawa pemadaman listrik), akibat negatif kudu mengaruhi mung bagean saka server ing wilayah kasebut.
- Penake panggunaan. Koyone sampeyan kudu mbukak sawetara penjadwal independen kanggo siji wilayah. Nanging saka sudut pandang sing gampang, siji titik mlebu menyang kolam sing dienggo bareng wilayah nggawe luwih gampang ngatur kapasitas lan pakaryan.
We dibagi panjadwal menyang shards kanggo ngatasi masalah ngramut blumbang sambungan gedhe. Saben shard scheduler ngatur pesawat dhewe proyek ing wilayah, lan iki nyuda resiko gadhah panjadwal. Nalika blumbang bareng mundak akeh, kita bisa nambah shards panjadwal liyane. Kanggo pangguna Tupperware, shards lan proksi panjadwal katon kaya siji panel kontrol. Dheweke ora kudu nggarap akeh pecahan sing ngatur tugas. Shards scheduler dhasar beda saka schedulers kluster kita digunakake sadurunge, nalika panel kontrol iki partitioned tanpa statis misahake blumbang sambungan server miturut topologi jaringan.
Ningkatake Efisiensi Panggunaan kanthi Komputasi Elastis
Sing luwih gedhe infrastruktur kita, luwih penting nggunakake server kanthi efisien kanggo ngoptimalake biaya infrastruktur lan nyuda beban. Ana rong cara kanggo nambah efisiensi panggunaan server:
- Komputasi elastis - nyuda layanan online sajrone jam sepi lan nggunakake server sing dibebasake kanggo beban kerja offline, kayata sinau mesin lan proyek MapReduce.
- Overloading - Selehake layanan online lan beban kerja batch ing server sing padha supaya beban kerja batch ora dadi prioritas.
Kemacetan ing pusat data kita yaiku . Mulane, kita luwih seneng server cilik, hemat energi sing bebarengan nyedhiyakake daya pangolahan luwih akeh. Sayange, ing server cilik karo CPU lan memori cilik, overloading kurang efektif. Mesthi, kita bisa nyelehake sawetara kontaner layanan cilik ing siji server hemat energi cilik sing nganggo sumber daya prosesor lan memori cilik, nanging layanan gedhe bakal duwe kinerja sing kurang ing kahanan iki. Mula, kita menehi saran para pangembang layanan gedhe kanggo ngoptimalake supaya bisa nggunakake kabeh server.
Sejatine, kita nambah efisiensi panggunaan nggunakake komputasi elastis. Akeh layanan utama, kayata News Feed, fitur Olahpesen, lan tingkat web ngarep, beda-beda gumantung ing wektu. Kita sengaja nyuda layanan online sajrone jam sepi lan nggunakake server sing dibebasake kanggo beban kerja offline, kayata sinau mesin lan proyek MapReduce.
Kita ngerti saka pengalaman sing paling apik kanggo nyedhiyakake kabeh server minangka unit kapasitas elastis amarga layanan gedhe minangka donor utama lan konsumen utama kapasitas elastis, lan dioptimalake kanggo nggunakake kabeh server. Nalika server dibebasake saka layanan online sajrone jam sepi, broker sumber daya nyewa server menyang panjadwal kanggo mbukak beban kerja offline. Yen layanan online ngalami beban puncak, broker sumber daya cepet ngelingi server sing dipinjam lan, bebarengan karo panjadwal, bali menyang layanan online.
Piwulang sing disinaoni lan rencana kanggo masa depan
Sajrone 8 taun kepungkur, kita wis ngembangake Tupperware supaya bisa terus berkembang kanthi cepet ing Facebook. Kita nuduhake apa sing wis kita sinau lan ngarep-arep bisa mbantu wong liya ngatur infrastruktur sing berkembang kanthi cepet:
- Nggawe sambungan fleksibel antarane panel kontrol lan server sing ngatur. Fleksibilitas iki ngidini panel kontrol ngatur server ing pusat data sing beda-beda, mbantu ngotomatisasi decommissioning lan pangopènan kluster, lan ngidini alokasi kapasitas dinamis nggunakake komputasi elastis.
- Kanthi panel kontrol siji ing wilayah kasebut, dadi luwih trep kanggo nggarap tugas lan luwih gampang ngatur armada server sing dienggo bareng. Elinga yen panel kontrol njaga siji titik entri, sanajan struktur internal dipisahake kanthi alasan ukuran utawa toleransi fault.
- Nggunakake model plugin, panel kontrol bisa ngabari aplikasi eksternal babagan operasi wadah sing bakal teka. Kajaba iku, layanan stateful bisa nggunakake antarmuka plugin kanggo ngatur manajemen wadhah. Kanthi model plugin iki, panel kontrol nyedhiyakake kesederhanaan nalika nglayani akeh layanan stateful kanthi efisien.
- Kita percaya yen komputasi elastis, sing njupuk kabeh server saka layanan donor kanggo proyek batch, learning machine, lan layanan non-urgent liyane, minangka cara sing paling optimal kanggo nambah efisiensi server cilik lan efisien energi.
Kita mung miwiti kanggo ngleksanakake . Saiki udakara 20% server kita ana ing kolam renang sing dienggo bareng. Kanggo entuk 100%, akeh masalah sing kudu ditanggulangi, kalebu njaga kolam panyimpenan sing dienggo bareng, ngotomatisasi pangopènan, ngatur syarat penyewa silang, ningkatake panggunaan server, lan ningkatake dhukungan kanggo beban kerja mesin. Kita ora sabar ngenteni tantangan kasebut lan nuduhake sukses.
Source: www.habr.com