Manajemén klaster anu cekap sareng dipercaya dina skala naon waé sareng Tupperware
Dinten ayeuna kami ngenalkeun Tupperware, sistem manajemen kluster kami anu ngatur wadah dina jutaan server anu ngajalankeun ampir sadaya jasa kami. Urang mimiti nyebarkeun Tupperware di 2011, sareng ti saprak éta infrastruktur urang parantos ningkat nepi ka gembleng . Sapanjang waktos ieu, Tupperware henteu nangtung sareng ngembangkeun sareng kami. Kami bakal nunjukkeun anjeun kumaha Tupperware nyayogikeun manajemén klaster kelas munggaran, kalebet dukungan anu cocog pikeun jasa stateful, panel kontrol tunggal pikeun sadaya pusat data, sareng kamampuan pikeun ngadistribusikaeun kapasitas antara jasa sacara real waktos. Urang ogé bakal ngabagi pelajaran anu urang pelajari nalika infrastruktur urang mekar.
Tupperware ngalaksanakeun tugas anu béda. Pangembang aplikasi ngagunakeun éta pikeun nganteurkeun sareng ngatur aplikasi. Éta ngarangkep kodeu aplikasi sareng katergantungan kana gambar sareng dikirimkeun ka server salaku wadahna. Wadah nyadiakeun isolasi antara aplikasi dina server sarua ambéh pamekar nungkulan logika aplikasi tur teu kudu salempang ngeunaan manggihan server atawa ngatur apdet. Tupperware ogé ngawas kinerja server, sarta lamun eta manggih gagalna, eta mindahkeun peti tina server masalah.
Insinyur perencanaan kapasitas nganggo Tupperware pikeun ngalokasikeun kapasitas server ka tim dumasar kana anggaran sareng konstrain. Éta ogé ngagunakeun éta pikeun ningkatkeun pamakean server. Operator puseur data giliran Tupperware pikeun leres ngadistribusikaeun peti sakuliah puseur data jeung ngeureunkeun atawa mindahkeun peti salila pangropéa. Hatur nuhun kana ieu, ngajaga server, jaringan sareng alat peryogi campur tangan manusa minimal.
arsitéktur Tupperware
Arsitéktur Tupperware PRN mangrupikeun salah sahiji daérah pusat data urang. Wewengkon ieu diwangun ku sababaraha gedong pusat data (PRN1 sareng PRN2) caket dieu. Kami ngarencanakeun ngadamel hiji panel kontrol anu bakal ngatur sadaya server dina hiji daérah.
Pamekar aplikasi nganteurkeun jasa dina bentuk padamelan Tupperware. Hiji padamelan diwangun ku sababaraha wadah, sareng aranjeunna sadayana biasana ngajalankeun kode aplikasi anu sami.
Tupperware tanggung jawab pikeun nyayogikeun wadah sareng ngatur siklus hirupna. Ieu diwangun ku sababaraha komponén:
- Frontend Tupperware nyayogikeun API pikeun antarbeungeut pangguna, CLI, sareng alat-alat otomatisasi anu sanés anjeun tiasa berinteraksi sareng Tupperware. Aranjeunna nyumputkeun sakabéh struktur internal ti nu boga pakasaban Tupperware.
- Tupperware Scheduler mangrupikeun panel kontrol anu tanggung jawab pikeun ngatur wadah sareng siklus kahirupan padamelan. Éta disebarkeun di tingkat régional sareng global, dimana panjadwal régional ngatur server dina hiji daérah sareng panjadwal global ngatur server ti daérah anu béda. scheduler dibagi kana beling, sarta unggal beling manages susunan jobs.
- Proksi Penjadwal Tupperware nyumputkeun sharding internal sareng nyayogikeun kaca tunggal anu merenah pikeun pangguna Tupperware.
- The Tupperware allocator nangtukeun peti ka server. The scheduler handles stopping, ngamimitian, ngamutahirkeun, sarta failover tina peti. Ayeuna, hiji allocator bisa ngatur sakabéh wewengkon tanpa dibeulah jadi shards. (Perhatikeun bédana terminologi. Contona, scheduler di Tupperware pakait jeung panel kontrol di , sarta allocator Tupperware disebut scheduler di Kubernetes.)
- Calo sumberdaya nyimpen sumber bebeneran pikeun server sareng acara jasa. Urang ngajalankeun hiji calo sumberdaya pikeun tiap puseur data, sarta eta nyimpen sakabeh informasi ngeunaan server di éta puseur data. Calo sumberdaya sareng sistem manajemen kapasitas, atanapi sistem penyediaan sumber daya, sacara dinamis mutuskeun pangiriman jadwal mana anu ngatur server mana. Ladenan pamariksaan kaséhatan ngawas server sareng nyimpen data ngeunaan kaséhatanna dina calo sumberdaya. Upami server ngagaduhan masalah atanapi peryogi pangropéa, calo sumberdaya nyarioskeun ka allocator sareng scheduler pikeun ngeureunkeun wadahna atanapi ngalih ka server anu sanés.
- Agén Tupperware mangrupikeun daemon anu dijalankeun dina unggal server anu ngatur penyediaan sareng ngahapus wadah. Aplikasi dijalankeun di jero wadah, anu masihan aranjeunna langkung isolasi sareng reproducibility. Dina Kami parantos ngajelaskeun kumaha wadah Tupperware individu didamel nganggo gambar, btrfs, cgroupv2 sareng systemd.
Keunggulan Tupperware
Tupperware sarimbag dina sababaraha cara pikeun sistem manajemen klaster anu sanés sapertos Kubernetes sareng , tapi aya ogé bédana:
- Diwangun-di rojongan pikeun layanan stateful.
- Panel kontrol tunggal pikeun server di pusat data anu béda pikeun ngajadikeun otomatis pangiriman wadah dumasar kana hajat, decommissioning klaster sareng pangropéa.
- Divisi jelas tina panel kontrol pikeun ngazum.
- Komputasi elastis ngamungkinkeun anjeun ngadistribusikaeun kakuatan antara jasa sacara real waktos.
Kami ngembangkeun fitur-fitur keren ieu pikeun ngadukung rupa-rupa aplikasi stateless sareng stateful dina armada pangladén global anu ageung.
Diwangun-di rojongan pikeun layanan stateful.
Tupperware ngoperasikeun rupa-rupa layanan stateful kritis nu nyimpen data produk pengkuh pikeun Facebook, Instagram, Messenger jeung WhatsApp. Ieu tiasa janten toko ageung pasangan konci-nilai (misalna. ) jeung ngawaskeun gudang data (contona, и ). Ngajaga jasa stateful teu gampang, sabab sistem kudu mastikeun yén suplai wadahna bisa tahan disruptions badag skala, kaasup outages jaringan atawa outages listrik. Sarta bari téhnik konvensional, kayaning ngadistribusikaeun peti sakuliah domain lepat, dianggo ogé pikeun layanan stateless, jasa stateful perlu rojongan tambahan.
Contona, upami kagagalan server ngajadikeun hiji réplika database teu sadia, naha anjeun kudu ngaktipkeun pangropéa otomatis nu bakal ngamutahirkeun cores on 50 server ti kolam renang 10? Gumantung kana kaayaan. Lamun salah sahiji 50 server ieu boga replica sejen tina database sarua, eta leuwih hade ngadagoan teu leungit 2 réplika sakaligus. Dina raraga dinamis nyieun kaputusan ngeunaan pangropéa sarta kinerja sistem, urang peryogi informasi ngeunaan réplikasi data internal tur logika panempatan unggal layanan stateful.
Antarbeungeut TaskControl ngamungkinkeun jasa stateful mangaruhan kaputusan anu mangaruhan kasadiaan data. Ngagunakeun panganteur ieu, scheduler ngabéjaan aplikasi éksternal ngeunaan operasi wadahna (balikan deui, update, migrasi, pangropéa). Hiji layanan stateful implements a controller nu ngabejaan Tupperware nalika éta aman pikeun ngalakukeun unggal operasi, sarta operasi ieu bisa swapped atawa nyangsang samentara. Dina conto di luhur, controller database bisa ngabejaan Tupperware pikeun ngapdet 49 tina 50 server, tapi ninggalkeun server husus (X) nyalira pikeun ayeuna. Hasilna, upami periode update kernel pas sareng pangkalan data masih teu tiasa mulangkeun réplika masalah, Tupperware masih bakal ngamutahirkeun server X.
Seueur jasa stateful di Tupperware nganggo TaskControl henteu langsung, tapi ngalangkungan ShardManager, platform umum pikeun nyiptakeun jasa stateful dina Facebook. Kalawan Tupperware, pamekar bisa nangtukeun maksud maranéhna pikeun persis kumaha wadahna kudu disebarkeun sakuliah puseur data. Kalawan ShardManager, pamekar nangtukeun maksud maranéhna pikeun kumaha shards data kudu disebarkeun sakuliah peti. ShardManager sadar panempatan data sareng réplikasi aplikasina sareng komunikasi sareng Tupperware ngaliwatan antarmuka TaskControl pikeun ngajadwalkeun operasi wadahna tanpa keterlibatan aplikasi langsung. Integrasi ieu pisan nyederhanakeun manajemén jasa stateful, tapi TaskControl sanggup langkung seueur. Salaku conto, undakan wéb éksténsif kami henteu aya kaayaan sareng nganggo TaskControl pikeun nyaluyukeun sacara dinamis tingkat pembaruan dina wadah. Antukna per poé tanpa compromising kasadiaan.
Ngatur server di puseur data
Nalika Tupperware munggaran diluncurkeun dina 2011, unggal klaster server diurus ku jadwal anu misah. Jaman harita, klaster Facebook mangrupikeun sakumpulan rak server anu nyambung ka hiji switch jaringan, sareng pusat data ngagaduhan sababaraha klaster. scheduler ngan bisa ngatur server dina hiji klaster, hartina pakasaban teu bisa nyebarkeun sakuliah sababaraha klaster. Infrastruktur urang ningkat, urang beuki ngahapus klaster. Kusabab Tupperware teu bisa mindahkeun pakasaban tina klaster decommissioned ka klaster séjén tanpa parobahan, merlukeun loba usaha jeung koordinasi ati antara pamekar aplikasi tur operator puseur data. Prosés ieu nyababkeun sumber daya anu mubazir nalika server dianggurkeun salami sababaraha bulan kusabab prosedur decommissioning.
Urang dijieun calo sumberdaya pikeun ngajawab masalah decommissioning klaster sarta koordinat tipe séjén tugas pangropéa. Calo sumberdaya ngalacak sadaya inpormasi fisik anu aya hubunganana sareng server sareng sacara dinamis mutuskeun jadwal anu ngatur unggal server. Dinamis linking server ka schedulers ngamungkinkeun scheduler pikeun ngatur server di puseur data béda. Kusabab padamelan Tupperware henteu dugi ka hiji klaster tunggal, pangguna Tupperware tiasa netepkeun kumaha wadahna kedah disebarkeun ka sadaya domain kasalahan. Contona, pamekar bisa ngadéklarasikeun maksud na (sebutkeun: "ngajalankeun pakasaban abdi on 2 domain lepat di wewengkon PRN") tanpa nangtukeun zona kasadiaan husus. Tupperware sorangan bakal manggihan server cocog pikeun nerapkeun niat ieu, sanajan klaster atawa jasa ieu decommissioned.
Scalable pikeun ngarojong sakabéh sistem global
Dina sajarahna, infrastruktur urang geus dibagi kana ratusan pools dedicated server pikeun tim individu. Kusabab fragméntasi sareng kurangna standar, kami ngagaduhan biaya operasional anu luhur, sareng server dianggurkeun langkung hese dianggo deui. Dina konferensi taun ka tukang urang dibere , nu kedah ngahijikeun infrastruktur urang kana taman server tunggal badag. Tapi taman server tunggal boga kasusah sorangan. Ieu kudu minuhan sarat nu tangtu:
- Skalabilitas. Infrastruktur kami ningkat nalika kami nambihan pusat data di unggal daérah. Server parantos langkung alit sareng langkung irit énergi, janten langkung seueur deui di unggal daérah. Hasilna, hiji scheduler tunggal per wewengkon teu bisa nanganan jumlah peti nu bisa dijalankeun dina ratusan rébu server di unggal wewengkon.
- Réliabilitas. Sanaos panjadwalna tiasa diskalakeun dugi ka, ruang lingkup ageung tina jadwal hartosna aya résiko kasalahan anu langkung ageung sareng sakumna daérah wadahna tiasa janten teu tiasa diatur.
- Kasalahan toleransi. Upami aya kagagalan infrastruktur anu ageung (contona, server anu ngajalankeun jadwal gagal kusabab kagagalan jaringan atanapi pareum listrik), konsékuansi négatip ngan ukur mangaruhan bagian tina server di daérah éta.
- Genah dianggo. Éta sigana anjeun kedah ngajalankeun sababaraha jadwal mandiri pikeun hiji daérah. Tapi tina sudut pandang anu gampang, hiji titik asup kana kolam renang anu dibagi di daérah ngagampangkeun pikeun ngatur kapasitas sareng padamelan.
Urang ngabagi scheduler kana beling pikeun ngajawab masalah ngajaga hiji kolam renang dibagikeun badag. Unggal beling scheduler ngatur set sorangan tina jobs di wewengkon, sarta ieu ngurangan résiko pakait sareng scheduler nu. Salaku kolam renang dibagikeun tumuwuh, urang bisa nambahkeun leuwih scheduler shards. Pikeun pangguna Tupperware, beling sareng proksi penjadwal sapertos hiji panel kontrol. Aranjeunna henteu kedah damel sareng sakumpulan beling anu ngatur tugas. Shards scheduler dasarna béda ti schedulers klaster kami dipaké saméméh, nalika panel kontrol ieu partitioned tanpa statis ngabagi pool dibagikeun server nurutkeun topology jaringan.
Ningkatkeun Efisiensi Pamakéan sareng Komputasi Elastis
Langkung ageung infrastruktur urang, anu langkung penting nyaéta ngagunakeun server kami sacara éfisién pikeun ngaoptimalkeun biaya infrastruktur sareng ngirangan beban. Aya dua cara pikeun ningkatkeun efisiensi pamakean server:
- Komputasi elastis - ngirangan jasa online salami jam sepi sareng nganggo server anu dibébaskeun pikeun beban kerja offline sapertos diajar mesin sareng padamelan MapReduce.
- Overloading - Tempatkeun jasa online sareng beban kerja bets dina server anu sami supados beban kerja bets dijalankeun dina prioritas anu rendah.
The bottleneck di puseur data urang téh . Ku alatan éta, urang leuwih resep server leutik, hemat energi nu babarengan nyadiakeun kakuatan processing leuwih. Hanjakal, dina server leutik kalawan saeutik CPU jeung memori, overloading kirang éféktif. Tangtu, urang tiasa nempatkeun sababaraha peti ladenan leutik dina hiji server hémat énergi leutik nu meakeun sumberdaya processor saeutik tur memori, tapi jasa badag bakal boga kinerja low dina kaayaan ieu. Ku alatan éta, kami mamatahan pamekar jasa badag urang pikeun ngaoptimalkeun aranjeunna ambéh maranéhanana ngagunakeun sakabéh server.
Dasarna, urang ningkatkeun efisiensi pamakean nganggo komputasi elastis. Seueur jasa utama kami, sapertos News Feed, fitur Olahtalatah, sareng undakan wéb hareup, beda-beda gumantung kana waktos beurang. Kami ngahaja ngirangan jasa online salami jam sepi sareng nganggo server anu dibébaskeun pikeun beban kerja offline, sapertos diajar mesin sareng padamelan MapReduce.
Kami terang tina pangalaman yén langkung saé nyayogikeun sadayana server salaku unit kapasitas elastis sabab jasa ageung mangrupikeun donor utama sareng konsumen utama kapasitas elastis, sareng dioptimalkeun pikeun ngagunakeun sadayana server. Nalika server dileupaskeun tina jasa online salami jam sepi, calo sumberdaya ngajakan server ka penjadwal pikeun ngajalankeun beban kerja offline. Upami ladenan online ngalaman beban puncak, calo sumberdaya gancang ngingetkeun server anu diinjeum sareng, sareng panjadwalna, uih deui ka jasa online.
Palajaran diajar sareng rencana pikeun masa depan
Sapanjang 8 taun katukang, kami parantos ngembangkeun Tupperware pikeun ngiringan kamekaran gancang Facebook. Kami bagikeun naon anu kami pelajari sareng ngarepkeun éta bakal ngabantosan batur ngatur infrastruktur anu ngembang pesat:
- Nyetél sambungan fléksibel antara panel kontrol jeung server eta manages. Kalenturan ieu ngamungkinkeun panel kontrol pikeun ngatur server di pusat data anu béda-béda, ngabantosan otomatis decommissioning sareng pangropéa klaster, sareng ngamungkinkeun alokasi kapasitas dinamis nganggo komputasi elastis.
- Kalayan panel kontrol tunggal di daérah éta, janten langkung merenah pikeun damel sareng tugas sareng langkung gampang ngatur armada server anu ageung. Catet yén panel kontrol ngajaga hiji titik asupna, sanajan struktur internalna dipisahkeun ku alesan skala atawa kasabaran sesar.
- Nganggo modél plugin, panel kontrol tiasa ngabéjaan aplikasi éksternal ngeunaan operasi wadah anu bakal datang. Sumawona, jasa stateful tiasa nganggo antarmuka plugin pikeun ngatur manajemén wadahna. Kalayan model plugin ieu, panel kontrol nyadiakeun kesederhanaan bari éfisién ngalayanan loba jasa stateful béda.
- Kami yakin yén komputasi elastis, dimana urang nyabut sakabéh server tina jasa donor pikeun jobs bets, mesin learning, sarta jasa non-urgent sejenna, nyaeta cara optimal pikeun ngaronjatkeun efisiensi leutik, server efisien énergi.
Urang ngan dimimitian pikeun nerapkeun . Ayeuna sakitar 20% tina server kami aya dina kolam renang anu dibagikeun. Pikeun ngahontal 100%, seueur masalah anu kedah direngsekeun, kalebet ngajaga kolam renang panyimpen anu dibagi, ngotomatisasi pangropéa, ngatur syarat panyewa, ningkatkeun panggunaan server, sareng ningkatkeun dukungan pikeun beban kerja mesin. Kami henteu tiasa ngantosan nyandak tantangan ieu sareng ngabagi kasuksésan urang.
sumber: www.habr.com