Manajemen cluster yang efisien dan andal pada skala apa pun dengan Tupperware
Hari ini di kami memperkenalkan Tupperware, sistem manajemen cluster kami yang mengatur container di jutaan server yang menjalankan hampir semua layanan kami. Kami pertama kali menerapkan Tupperware pada tahun 2011, dan sejak itu infrastruktur kami berkembang hingga keseluruhan . Selama ini Tupperware tidak tinggal diam dan berkembang bersama kami. Kami akan menunjukkan kepada Anda bagaimana Tupperware menyediakan manajemen cluster kelas satu, termasuk dukungan nyaman untuk layanan stateful, panel kontrol tunggal untuk semua pusat data, dan kemampuan untuk mendistribusikan kapasitas antar layanan secara real time. Kami juga akan berbagi pembelajaran yang telah kami peroleh seiring dengan berkembangnya infrastruktur kami.
Tupperware melakukan tugas yang berbeda. Pengembang aplikasi menggunakannya untuk mengirimkan dan mengelola aplikasi. Ini mengemas kode aplikasi dan dependensi ke dalam gambar dan mengirimkannya ke server sebagai wadah. Kontainer menyediakan isolasi antar aplikasi di server yang sama sehingga pengembang menangani logika aplikasi dan tidak perlu khawatir dalam menemukan server atau mengelola pembaruan. Tupperware juga memantau kinerja server, dan jika ditemukan kegagalan, Tupperware akan mentransfer container dari server yang bermasalah.
Insinyur perencanaan kapasitas menggunakan Tupperware untuk mengalokasikan kapasitas server ke tim berdasarkan anggaran dan batasan. Mereka juga menggunakannya untuk meningkatkan pemanfaatan server. Operator pusat data beralih ke Tupperware untuk mendistribusikan kontainer dengan benar ke seluruh pusat data dan menghentikan atau memindahkan kontainer selama pemeliharaan. Oleh karena itu, pemeliharaan server, jaringan, dan peralatan hanya memerlukan sedikit campur tangan manusia.
Arsitektur Tupperware
Arsitektur Tupperware PRN adalah salah satu wilayah pusat data kami. Wilayah tersebut terdiri dari beberapa gedung pusat data (PRN1 dan PRN2) yang terletak di dekatnya. Kami berencana membuat satu panel kontrol yang akan mengelola semua server di satu wilayah.
Pengembang aplikasi memberikan layanan dalam bentuk pekerjaan Tupperware. Sebuah pekerjaan terdiri dari beberapa kontainer, dan semuanya biasanya menjalankan kode aplikasi yang sama.
Tupperware bertanggung jawab untuk menyediakan kontainer dan mengelola siklus hidupnya. Ini terdiri dari beberapa komponen:
- Frontend Tupperware menyediakan API untuk antarmuka pengguna, CLI, dan alat otomatisasi lainnya yang dapat digunakan untuk berinteraksi dengan Tupperware. Mereka menyembunyikan seluruh struktur internal dari pemilik pekerjaan Tupperware.
- Penjadwal Tupperware adalah panel kontrol yang bertanggung jawab mengelola kontainer dan siklus hidup pekerjaan. Ini diterapkan di tingkat regional dan global, di mana penjadwal regional mengelola server di satu wilayah dan penjadwal global mengelola server dari wilayah berbeda. Penjadwal dibagi menjadi beberapa bagian, dan setiap bagian mengelola serangkaian pekerjaan.
- Proksi Penjadwal Tupperware menyembunyikan sharding internal dan menyediakan satu panel kaca yang nyaman bagi pengguna Tupperware.
- Pengalokasi Tupperware menugaskan kontainer ke server. Penjadwal menangani penghentian, memulai, memperbarui, dan failover kontainer. Saat ini, satu pengalokasi dapat mengelola seluruh wilayah tanpa terpecah menjadi beberapa bagian. (Perhatikan perbedaan terminologinya. Misalnya, penjadwal di Tupperware berhubungan dengan panel kontrol di , dan pengalokasi Tupperware disebut penjadwal di Kubernetes.)
- Pialang sumber daya menyimpan sumber kebenaran untuk server dan peristiwa layanan. Kami menjalankan satu broker sumber daya untuk setiap pusat data, dan broker ini menyimpan semua informasi tentang server di pusat data tersebut. Pialang sumber daya dan sistem manajemen kapasitas, atau sistem penyediaan sumber daya, secara dinamis memutuskan pengiriman penjadwal mana yang mengontrol server mana. Layanan pemeriksaan kesehatan memantau server dan menyimpan data tentang kesehatannya di broker sumber daya. Jika server mengalami masalah atau memerlukan pemeliharaan, broker sumber daya memberitahu pengalokasi dan penjadwal untuk menghentikan kontainer atau memindahkannya ke server lain.
- Agen Tupperware adalah daemon yang berjalan di setiap server yang menangani penyediaan dan penghapusan kontainer. Aplikasi dijalankan di dalam container, sehingga aplikasi lebih terisolasi dan dapat direproduksi. Pada Kami telah menjelaskan bagaimana masing-masing wadah Tupperware dibuat menggunakan gambar, btrfs, cgroupv2, dan systemd.
Ciri khas Tupperware
Tupperware dalam banyak hal serupa dengan sistem manajemen cluster lainnya seperti Kubernetes dan , tetapi ada juga perbedaannya:
- Dukungan bawaan untuk layanan stateful.
- Panel kontrol tunggal untuk server di pusat data berbeda untuk mengotomatisasi pengiriman kontainer berdasarkan niat, penonaktifan cluster, dan pemeliharaan.
- Hapus pembagian panel kontrol untuk zoom.
- Komputasi elastis memungkinkan Anda mendistribusikan daya antar layanan secara real time.
Kami mengembangkan fitur-fitur keren ini untuk mendukung berbagai aplikasi stateless dan stateful di seluruh armada server bersama global yang besar.
Dukungan bawaan untuk layanan stateful.
Tupperware mengoperasikan berbagai layanan stateful penting yang menyimpan data produk persisten untuk Facebook, Instagram, Messenger, dan WhatsApp. Ini bisa berupa penyimpanan besar pasangan nilai kunci (mis. ) dan memantau repositori data (misalnya, и ). Mempertahankan layanan stateful tidaklah mudah, karena sistem harus memastikan bahwa pasokan kontainer dapat tahan terhadap gangguan berskala besar, termasuk pemadaman jaringan atau pemadaman listrik. Meskipun teknik konvensional, seperti mendistribusikan container di seluruh domain kesalahan, berfungsi dengan baik untuk layanan stateless, layanan stateful memerlukan dukungan tambahan.
Misalnya, jika kegagalan server membuat satu replika database tidak tersedia, haruskah Anda mengaktifkan pemeliharaan otomatis yang akan memperbarui inti pada 50 server dari kumpulan 10 server? Tergantung situasinya. Jika salah satu dari 50 server ini memiliki replika lain dari database yang sama, lebih baik menunggu dan tidak kehilangan 2 replika sekaligus. Untuk membuat keputusan secara dinamis tentang pemeliharaan dan kinerja sistem, kita memerlukan informasi tentang replikasi data internal dan logika penempatan setiap layanan stateful.
Antarmuka TaskControl memungkinkan layanan stateful untuk mempengaruhi keputusan yang mempengaruhi ketersediaan data. Dengan menggunakan antarmuka ini, penjadwal memberi tahu aplikasi eksternal tentang operasi kontainer (mulai ulang, pembaruan, migrasi, pemeliharaan). Layanan stateful mengimplementasikan pengontrol yang memberi tahu Tupperware kapan kondisi aman untuk melakukan setiap operasi, dan operasi ini dapat ditukar atau ditunda untuk sementara. Dalam contoh di atas, pengontrol database dapat memerintahkan Tupperware untuk memperbarui 49 dari 50 server, namun membiarkan server tertentu (X) saja untuk saat ini. Akibatnya, jika masa pembaruan kernel telah berlalu dan database masih tidak dapat memulihkan replika yang bermasalah, Tupperware akan tetap memperbarui X server.
Banyak layanan stateful di Tupperware menggunakan TaskControl tidak secara langsung, namun melalui ShardManager, platform umum untuk membuat layanan stateful di Facebook. Dengan Tupperware, pengembang dapat menentukan tujuan mereka mengenai bagaimana kontainer harus didistribusikan ke seluruh pusat data. Dengan ShardManager, pengembang menentukan maksud mereka tentang bagaimana pecahan data harus didistribusikan ke seluruh kontainer. ShardManager mengetahui penempatan data dan replikasi aplikasinya dan berkomunikasi dengan Tupperware melalui antarmuka TaskControl untuk menjadwalkan operasi kontainer tanpa keterlibatan aplikasi langsung. Integrasi ini sangat menyederhanakan pengelolaan layanan stateful, namun TaskControl mampu melakukan lebih banyak lagi. Misalnya, tingkat web kami yang luas tidak memiliki kewarganegaraan dan menggunakan TaskControl untuk secara dinamis menyesuaikan laju pembaruan pada container. Pada akhirnya per hari tanpa mengurangi ketersediaan.
Mengelola server di pusat data
Ketika Tupperware pertama kali diluncurkan pada tahun 2011, setiap cluster server dikelola oleh penjadwal terpisah. Saat itu, cluster Facebook adalah sekelompok rak server yang terhubung ke satu switch jaringan, dan pusat datanya menampung beberapa cluster. Penjadwal hanya dapat mengelola server dalam satu cluster, artinya pekerjaan tidak dapat tersebar di beberapa cluster. Infrastruktur kami berkembang, kami semakin menghapuskan cluster. Karena Tupperware tidak dapat memindahkan pekerjaan dari cluster yang dinonaktifkan ke cluster lain tanpa perubahan, maka diperlukan banyak upaya dan koordinasi yang cermat antara pengembang aplikasi dan operator pusat data. Proses ini mengakibatkan sumber daya terbuang sia-sia ketika server menganggur selama berbulan-bulan karena prosedur dekomisioning.
Kami menciptakan broker sumber daya untuk memecahkan masalah penonaktifan cluster dan mengoordinasikan jenis tugas pemeliharaan lainnya. Pialang sumber daya melacak semua informasi fisik yang terkait dengan server dan secara dinamis memutuskan penjadwal mana yang mengontrol setiap server. Menghubungkan server ke penjadwal secara dinamis memungkinkan penjadwal mengelola server di pusat data yang berbeda. Karena pekerjaan Tupperware tidak lagi terbatas pada satu cluster, pengguna Tupperware dapat menentukan bagaimana kontainer harus didistribusikan ke seluruh domain kesalahan. Misalnya, pengembang dapat menyatakan niatnya (misalnya: "jalankan pekerjaan saya di 2 domain kesalahan di wilayah PRN") tanpa menentukan zona ketersediaan tertentu. Tupperware sendiri akan menemukan server yang cocok untuk mengimplementasikan niat ini, bahkan jika cluster atau layanan tersebut dinonaktifkan.
Dapat diskalakan untuk mendukung seluruh sistem global
Secara historis, infrastruktur kami telah dibagi menjadi ratusan kumpulan server khusus untuk masing-masing tim. Karena fragmentasi dan kurangnya standar, kami mempunyai biaya operasional yang tinggi, dan server yang menganggur menjadi lebih sulit untuk digunakan kembali. Pada konferensi tahun lalu kami disajikan , yang seharusnya menyatukan infrastruktur kami menjadi satu tempat server yang besar. Namun satu taman server memiliki kesulitan tersendiri. Itu harus memenuhi persyaratan tertentu:
- Skalabilitas. Infrastruktur kami berkembang seiring dengan bertambahnya pusat data di setiap wilayah. Server menjadi lebih kecil dan lebih hemat energi, sehingga jumlahnya lebih banyak di setiap wilayah. Akibatnya, satu penjadwal per wilayah tidak dapat menangani jumlah kontainer yang dapat dijalankan di ratusan ribu server di setiap wilayah.
- Keandalan Bahkan jika penjadwal dapat ditingkatkan sebanyak itu, cakupan penjadwal yang besar berarti terdapat risiko kesalahan yang lebih tinggi dan seluruh wilayah kontainer menjadi tidak dapat dikelola.
- Toleransi kesalahan. Jika terjadi kegagalan infrastruktur yang besar (misalnya, server yang menjalankan penjadwal gagal karena kegagalan jaringan atau pemadaman listrik), konsekuensi negatifnya hanya akan berdampak pada sebagian server di wilayah tersebut.
- Kemudahan penggunaan. Tampaknya Anda perlu menjalankan beberapa penjadwal independen untuk satu wilayah. Namun dari sudut pandang kenyamanan, satu titik masuk ke dalam kelompok bersama di suatu wilayah akan mempermudah pengelolaan kapasitas dan lapangan kerja.
Kami membagi penjadwal menjadi beberapa bagian untuk memecahkan masalah pemeliharaan kumpulan bersama yang besar. Setiap pecahan penjadwal mengelola kumpulan pekerjaannya sendiri di wilayah tersebut, dan hal ini mengurangi risiko yang terkait dengan penjadwal. Seiring bertambahnya kumpulan bersama, kita dapat menambahkan lebih banyak pecahan penjadwal. Bagi pengguna Tupperware, pecahan dan proksi penjadwal terlihat seperti satu panel kontrol. Mereka tidak harus bekerja dengan sekumpulan pecahan yang mengatur tugas. Pecahan penjadwal pada dasarnya berbeda dari penjadwal kluster yang kami gunakan sebelumnya, ketika panel kontrol dipartisi tanpa membagi kumpulan server bersama secara statis sesuai dengan topologi jaringan.
Tingkatkan Efisiensi Penggunaan dengan Komputasi Elastis
Semakin besar infrastruktur kami, semakin penting penggunaan server kami secara efisien untuk mengoptimalkan biaya infrastruktur dan mengurangi beban. Ada dua cara untuk meningkatkan efisiensi penggunaan server:
- Komputasi elastis - memperkecil layanan online selama jam tenang dan menggunakan server yang dikosongkan untuk beban kerja offline, seperti pembelajaran mesin dan pekerjaan MapReduce.
- Kelebihan beban - Tempatkan layanan online dan beban kerja batch di server yang sama sehingga beban kerja batch berjalan pada prioritas rendah.
Hambatan di pusat data kami adalah . Oleh karena itu, kami lebih memilih server kecil dan hemat energi yang bersama-sama memberikan kekuatan pemrosesan lebih besar. Sayangnya, pada server kecil dengan CPU dan memori sedikit, kelebihan beban kurang efektif. Tentu saja, kita dapat menempatkan beberapa kontainer layanan kecil pada satu server kecil hemat energi yang mengkonsumsi sedikit sumber daya prosesor dan memori, namun layanan besar akan memiliki kinerja rendah dalam situasi ini. Oleh karena itu, kami menyarankan pengembang layanan besar kami untuk mengoptimalkannya sehingga mereka menggunakan seluruh server.
Pada dasarnya, kami meningkatkan efisiensi penggunaan menggunakan komputasi elastis. Banyak layanan utama kami, seperti Kabar Beranda, fitur Perpesanan, dan tingkat web front-end, bervariasi tergantung waktu. Kami sengaja mengurangi layanan online selama jam tenang dan menggunakan server yang dikosongkan untuk beban kerja offline, seperti pembelajaran mesin dan pekerjaan MapReduce.
Kami mengetahui dari pengalaman bahwa yang terbaik adalah menyediakan seluruh server sebagai unit kapasitas elastis karena layanan besar merupakan donor utama dan konsumen utama kapasitas elastis, dan dioptimalkan untuk menggunakan seluruh server. Ketika server dilepaskan dari layanan online selama jam tenang, broker sumber daya menyewakan server ke penjadwal untuk menjalankan beban kerja offline di dalamnya. Jika layanan online mengalami beban puncak, broker sumber daya dengan cepat mengingat server yang dipinjam dan, bersama dengan penjadwal, mengembalikannya ke layanan online.
Pelajaran yang didapat dan rencana untuk masa depan
Selama 8 tahun terakhir, kami telah mengembangkan Tupperware untuk mengimbangi pesatnya pertumbuhan Facebook. Kami membagikan apa yang telah kami pelajari dan berharap ini dapat membantu orang lain mengelola infrastruktur yang berkembang pesat:
- Siapkan koneksi fleksibel antara panel kontrol dan server yang dikelolanya. Fleksibilitas ini memungkinkan panel kontrol untuk mengelola server di pusat data yang berbeda, membantu mengotomatisasi penonaktifan dan pemeliharaan cluster, dan memungkinkan alokasi kapasitas dinamis menggunakan komputasi elastis.
- Dengan satu panel kontrol di wilayah ini, bekerja dengan tugas menjadi lebih nyaman dan mengelola armada server bersama yang besar. Perhatikan bahwa panel kontrol mempertahankan satu titik masuk, meskipun struktur internalnya dipisahkan karena alasan skala atau toleransi kesalahan.
- Dengan menggunakan model plugin, panel kontrol dapat memberi tahu aplikasi eksternal tentang operasi kontainer yang akan datang. Selain itu, layanan stateful dapat menggunakan antarmuka plugin untuk menyesuaikan manajemen kontainer. Dengan model plugin ini, panel kontrol memberikan kesederhanaan sekaligus melayani banyak layanan stateful berbeda secara efisien.
- Kami percaya bahwa komputasi elastis, dimana kami mengambil seluruh server dari layanan donor untuk pekerjaan batch, pembelajaran mesin, dan layanan tidak mendesak lainnya, adalah cara optimal untuk meningkatkan efisiensi server kecil dan hemat energi.
Kami baru mulai menerapkannya . Saat ini sekitar 20% server kami berada di kumpulan bersama. Untuk mencapai 100%, banyak masalah yang perlu diatasi, termasuk memelihara kumpulan penyimpanan bersama, mengotomatiskan pemeliharaan, mengelola persyaratan lintas penyewa, meningkatkan pemanfaatan server, dan meningkatkan dukungan untuk beban kerja pembelajaran mesin. Kami tidak sabar untuk menghadapi tantangan ini dan berbagi kesuksesan kami.
Sumber: www.habr.com