Tupperware: Pembunuh Kubernetes Facebook?

Pengurusan kluster yang cekap dan boleh dipercayai pada sebarang skala dengan Tupperware

Hari ini pada Persidangan Sistem@Skala kami memperkenalkan Tupperware, sistem pengurusan kluster kami yang mengatur kontena merentas berjuta-juta pelayan yang menjalankan hampir semua perkhidmatan kami. Kami mula-mula menggunakan Tupperware pada tahun 2011, dan sejak itu infrastruktur kami telah berkembang dari 1 pusat data kepada keseluruhan 15 pusat data teragih geo. Selama ini, Tupperware tidak berdiam diri dan berkembang bersama kami. Kami akan menunjukkan kepada anda cara Tupperware menyediakan pengurusan kluster kelas pertama, termasuk sokongan mudah untuk perkhidmatan stateful, panel kawalan tunggal untuk semua pusat data dan keupayaan untuk mengagihkan kapasiti antara perkhidmatan dalam masa nyata. Kami juga akan berkongsi pelajaran yang telah kami pelajari semasa infrastruktur kami berkembang.

Tupperware menjalankan tugas yang berbeza. Pembangun aplikasi menggunakannya untuk menghantar dan mengurus aplikasi. Ia membungkus kod aplikasi dan kebergantungan ke dalam imej dan menghantarnya ke pelayan sebagai bekas. Bekas menyediakan pengasingan antara aplikasi pada pelayan yang sama supaya pembangun berurusan dengan logik aplikasi dan tidak perlu risau tentang mencari pelayan atau mengurus kemas kini. Tupperware juga memantau prestasi pelayan, dan jika ia mendapati kegagalan, ia memindahkan bekas dari pelayan yang bermasalah.

Jurutera perancangan kapasiti menggunakan Tupperware untuk memperuntukkan kapasiti pelayan kepada pasukan berdasarkan bajet dan kekangan. Mereka juga menggunakannya untuk meningkatkan penggunaan pelayan. Pengendali pusat data beralih kepada Tupperware untuk mengedarkan bekas dengan betul ke seluruh pusat data dan menghentikan atau mengalihkan bekas semasa penyelenggaraan. Terima kasih kepada ini, mengekalkan pelayan, rangkaian dan peralatan memerlukan campur tangan manusia yang minimum.

Seni bina Tupperware

Seni bina Tupperware PRN ialah salah satu kawasan pusat data kami. Wilayah ini terdiri daripada beberapa bangunan pusat data (PRN1 dan PRN2) yang terletak berdekatan. Kami merancang untuk membuat satu panel kawalan yang akan menguruskan semua pelayan dalam satu rantau.

Pembangun aplikasi menyampaikan perkhidmatan dalam bentuk pekerjaan Tupperware. Kerja terdiri daripada berbilang bekas, dan semuanya biasanya menjalankan kod aplikasi yang sama.

Tupperware bertanggungjawab untuk menyediakan bekas dan menguruskan kitaran hayatnya. Ia terdiri daripada beberapa komponen:

• Bahagian hadapan Tupperware menyediakan API untuk antara muka pengguna, CLI dan alat automasi lain yang melaluinya anda boleh berinteraksi dengan Tupperware. Mereka menyembunyikan keseluruhan struktur dalaman daripada pemilik kerja Tupperware.
• Penjadual Tupperware ialah panel kawalan yang bertanggungjawab untuk menguruskan bekas dan kitaran hayat kerja. Ia digunakan di peringkat serantau dan global, di mana penjadual serantau mengurus pelayan dalam satu rantau dan penjadual global mengurus pelayan dari wilayah yang berbeza. Penjadual dibahagikan kepada serpihan, dan setiap serpihan menguruskan satu set kerja.
• Proksi Penjadual Tupperware menyembunyikan serpihan dalaman dan menyediakan satu anak tetingkap kaca yang mudah untuk pengguna Tupperware.
• Pengagih Tupperware memberikan bekas kepada pelayan. Penjadual mengendalikan menghentikan, memulakan, mengemas kini dan failover bekas. Pada masa ini, satu pengalokasi boleh mengurus seluruh rantau tanpa berpecah menjadi serpihan. (Perhatikan perbezaan dalam istilah. Contohnya, penjadual dalam Tupperware sepadan dengan panel kawalan dalam Kubernetes, dan pengagih Tupperware dipanggil penjadual dalam Kubernetes.)
• Broker sumber menyimpan sumber kebenaran untuk acara pelayan dan perkhidmatan. Kami menjalankan satu broker sumber untuk setiap pusat data, dan ia menyimpan semua maklumat tentang pelayan di pusat data tersebut. Broker sumber dan sistem pengurusan kapasiti, atau sistem peruntukan sumber, secara dinamik memutuskan penghantaran penjadual yang mengawal pelayan mana. Perkhidmatan pemeriksaan kesihatan memantau pelayan dan menyimpan data tentang kesihatan mereka dalam broker sumber. Jika pelayan menghadapi masalah atau memerlukan penyelenggaraan, broker sumber memberitahu pengalokasi dan penjadual untuk menghentikan bekas atau mengalihkannya ke pelayan lain.
• Ejen Tupperware ialah daemon yang dijalankan pada setiap pelayan yang mengendalikan peruntukan dan pengalihan bekas. Aplikasi dijalankan di dalam bekas, yang memberikan mereka lebih pengasingan dan kebolehulangan. hidup persidangan Sistem @Skala tahun lepas Kami telah menerangkan cara bekas Tupperware individu dibuat menggunakan imej, btrfs, cgroupv2 dan systemd.

Ciri-ciri tersendiri Tupperware

Tupperware adalah serupa dalam banyak cara dengan sistem pengurusan kluster lain seperti Kubernetes dan Mesos, tetapi terdapat juga perbezaan:

• Sokongan terbina dalam untuk perkhidmatan stateful.
• Panel kawalan tunggal untuk pelayan di pusat data yang berbeza untuk mengautomasikan penghantaran kontena berdasarkan niat, penyahtauliahan kluster dan penyelenggaraan.
• Pembahagian panel kawalan yang jelas untuk mengezum.
• Pengkomputeran elastik membolehkan anda mengagihkan kuasa antara perkhidmatan dalam masa nyata.

Kami membangunkan ciri-ciri hebat ini untuk menyokong pelbagai aplikasi tanpa kewarganegaraan dan stateful merentas kumpulan pelayan kongsi global yang besar.

Sokongan terbina dalam untuk perkhidmatan stateful.

Tupperware mengendalikan pelbagai perkhidmatan stateful kritikal yang menyimpan data produk berterusan untuk Facebook, Instagram, Messenger dan WhatsApp. Ini boleh menjadi simpanan besar pasangan nilai kunci (mis. ZippyDB) dan memantau repositori data (contohnya, Gorila ODS и Scuba). Mengekalkan perkhidmatan stateful bukanlah mudah, kerana sistem mesti memastikan bahawa bekalan kontena dapat menahan gangguan berskala besar, termasuk gangguan rangkaian atau gangguan bekalan elektrik. Dan sementara teknik konvensional, seperti mengedarkan bekas merentas domain kerosakan, berfungsi dengan baik untuk perkhidmatan tanpa negara, perkhidmatan stateful memerlukan sokongan tambahan.

Sebagai contoh, jika kegagalan pelayan menyebabkan satu replika pangkalan data tidak tersedia, adakah anda perlu mendayakan penyelenggaraan automatik yang akan mengemas kini teras pada 50 pelayan daripada kumpulan 10? Bergantung pada keadaan. Jika salah satu daripada 50 pelayan ini mempunyai satu lagi replika pangkalan data yang sama, lebih baik menunggu dan tidak kehilangan 2 replika sekaligus. Untuk membuat keputusan secara dinamik tentang penyelenggaraan dan prestasi sistem, kami memerlukan maklumat tentang replikasi data dalaman dan logik peletakan setiap perkhidmatan stateful.

Antara muka TaskControl membenarkan perkhidmatan stateful mempengaruhi keputusan yang mempengaruhi ketersediaan data. Menggunakan antara muka ini, penjadual memberitahu aplikasi luaran tentang operasi kontena (mulakan semula, kemas kini, penghijrahan, penyelenggaraan). Perkhidmatan stateful melaksanakan pengawal yang memberitahu Tupperware apabila selamat untuk melaksanakan setiap operasi, dan operasi ini boleh ditukar atau ditangguhkan buat sementara waktu. Dalam contoh di atas, pengawal pangkalan data boleh memberitahu Tupperware untuk mengemas kini 49 daripada 50 pelayan, tetapi biarkan pelayan tertentu (X) sahaja buat masa ini. Akibatnya, jika tempoh kemas kini kernel berlalu dan pangkalan data masih tidak dapat memulihkan replika yang bermasalah, Tupperware masih akan mengemas kini pelayan X.

Banyak perkhidmatan stateful dalam Tupperware menggunakan TaskControl bukan secara langsung, tetapi melalui ShardManager, platform biasa untuk mencipta perkhidmatan stateful di Facebook. Dengan Tupperware, pembangun boleh menentukan niat mereka untuk mengetahui cara bekas harus diedarkan ke seluruh pusat data. Dengan ShardManager, pembangun menentukan niat mereka tentang cara serpihan data harus diedarkan merentas bekas. ShardManager mengetahui tentang penempatan data dan replikasi aplikasinya dan berkomunikasi dengan Tupperware melalui antara muka TaskControl untuk menjadualkan operasi kontena tanpa penglibatan aplikasi secara langsung. Penyepaduan ini sangat memudahkan pengurusan perkhidmatan stateful, tetapi TaskControl mampu melakukan lebih banyak lagi. Sebagai contoh, peringkat web kami yang luas adalah tanpa kewarganegaraan dan menggunakan TaskControl untuk melaraskan kadar kemas kini kepada bekas secara dinamik. Akhirnya peringkat web mampu menyelesaikan pelbagai keluaran perisian dengan cepat setiap hari tanpa menjejaskan ketersediaan.

Menguruskan pelayan di pusat data

Apabila Tupperware pertama kali dilancarkan pada 2011, setiap kluster pelayan diuruskan oleh penjadual yang berasingan. Pada masa itu, kluster Facebook ialah sekumpulan rak pelayan yang disambungkan kepada satu suis rangkaian, dan pusat data menempatkan beberapa kluster. Penjadual hanya boleh mengurus pelayan dalam satu kluster, bermakna tugas itu tidak boleh merebak merentasi berbilang kluster. Infrastruktur kami berkembang, kami semakin menghapuskan kluster. Memandangkan Tupperware tidak dapat mengalihkan tugas daripada kluster yang dinyahaktifkan kepada kluster lain tanpa perubahan, ia memerlukan banyak usaha dan penyelarasan yang teliti antara pembangun aplikasi dan pengendali pusat data. Proses ini mengakibatkan sumber terbuang apabila pelayan melahu selama berbulan-bulan disebabkan oleh prosedur penyahtauliahan.

Kami mencipta broker sumber untuk menyelesaikan masalah penyahtauliahan kluster dan menyelaraskan jenis tugas penyelenggaraan yang lain. Broker sumber menjejaki semua maklumat fizikal yang dikaitkan dengan pelayan dan secara dinamik memutuskan penjadual yang mengawal setiap pelayan. Memautkan pelayan secara dinamik kepada penjadual membolehkan penjadual mengurus pelayan di pusat data yang berbeza. Memandangkan tugas Tupperware tidak lagi terhad kepada satu kluster, pengguna Tupperware boleh menentukan cara bekas harus diedarkan ke seluruh domain kerosakan. Sebagai contoh, pembangun boleh mengisytiharkan niatnya (katakan: "jalankan tugas saya pada 2 domain kerosakan di rantau PRN") tanpa menyatakan zon ketersediaan tertentu. Tupperware sendiri akan mencari pelayan yang sesuai untuk melaksanakan hasrat ini, walaupun kluster atau perkhidmatan itu dinyahaktifkan.

Berskala untuk menyokong keseluruhan sistem global

Dari segi sejarah, infrastruktur kami telah dibahagikan kepada ratusan kumpulan pelayan khusus untuk pasukan individu. Disebabkan oleh pemecahan dan kekurangan standard, kami mempunyai kos operasi yang tinggi, dan pelayan terbiar lebih sukar untuk digunakan semula. Pada persidangan tahun lepas Sistem @Skala kami bentangkan infrastruktur sebagai perkhidmatan (IaaS), yang sepatutnya menyatukan infrastruktur kami menjadi taman pelayan tunggal yang besar. Tetapi taman pelayan tunggal mempunyai kesukarannya sendiri. Ia mesti memenuhi keperluan tertentu:

• Kebolehskalaan. Infrastruktur kami berkembang apabila kami menambah pusat data di setiap rantau. Pelayan telah menjadi lebih kecil dan lebih cekap tenaga, jadi terdapat lebih banyak daripada mereka di setiap rantau. Akibatnya, satu penjadual bagi setiap wilayah tidak dapat mengendalikan bilangan bekas yang boleh dijalankan pada ratusan ribu pelayan di setiap rantau.
• Kebolehpercayaan Walaupun penjadual boleh ditingkatkan sebanyak itu, skop besar penjadual bermakna terdapat risiko ralat yang lebih tinggi dan keseluruhan kawasan bekas boleh menjadi tidak terurus.
• Toleransi kesalahan. Sekiranya berlaku kegagalan infrastruktur yang besar (contohnya, pelayan yang menjalankan penjadual gagal disebabkan oleh kegagalan rangkaian atau gangguan bekalan elektrik), akibat negatif hanya akan menjejaskan sebahagian daripada pelayan di rantau ini.
• Kemudahan penggunaan. Nampaknya anda perlu menjalankan beberapa penjadual bebas untuk satu rantau. Tetapi dari perspektif kemudahan, satu titik kemasukan ke kumpulan kongsi rantau menjadikannya lebih mudah untuk mengurus kapasiti dan pekerjaan.

Kami membahagikan penjadual kepada serpihan untuk menyelesaikan masalah mengekalkan kolam kongsi yang besar. Setiap serpihan penjadual mengurus set pekerjaannya sendiri di rantau ini, dan ini mengurangkan risiko yang berkaitan dengan penjadual. Apabila kumpulan kongsi berkembang, kami boleh menambah lebih banyak serpihan penjadual. Bagi pengguna Tupperware, serpihan dan proksi penjadual kelihatan seperti satu panel kawalan. Mereka tidak perlu bekerja dengan sekumpulan serpihan yang mengatur tugas. Serpihan penjadual pada asasnya berbeza daripada penjadual kluster yang kami gunakan sebelum ini, apabila panel kawalan dipisahkan tanpa membahagikan kumpulan pelayan yang dikongsi secara statik mengikut topologi rangkaian.

Tingkatkan Kecekapan Penggunaan dengan Pengkomputeran Elastik

Lebih besar infrastruktur kami, lebih penting adalah untuk menggunakan pelayan kami dengan cekap untuk mengoptimumkan kos infrastruktur dan mengurangkan beban. Terdapat dua cara untuk meningkatkan kecekapan penggunaan pelayan:

• Pengkomputeran elastik - mengurangkan perkhidmatan dalam talian semasa waktu senyap dan gunakan pelayan yang dibebaskan untuk beban kerja luar talian, seperti pembelajaran mesin dan kerja MapReduce.
• Berlebihan - Letakkan perkhidmatan dalam talian dan beban kerja kelompok pada pelayan yang sama supaya beban kerja kelompok berjalan pada keutamaan yang rendah.

Halangan di pusat data kami ialah penggunaan kuasa. Oleh itu, kami lebih suka pelayan kecil yang cekap tenaga yang bersama-sama memberikan lebih kuasa pemprosesan. Malangnya, pada pelayan kecil dengan sedikit CPU dan memori, beban berlebihan kurang berkesan. Sudah tentu, kita boleh meletakkan beberapa bekas perkhidmatan kecil pada satu pelayan cekap tenaga kecil yang menggunakan sedikit sumber pemproses dan memori, tetapi perkhidmatan besar akan mempunyai prestasi rendah dalam situasi ini. Oleh itu, kami menasihati pembangun perkhidmatan besar kami untuk mengoptimumkannya supaya mereka menggunakan keseluruhan pelayan.


Pada asasnya, kami meningkatkan kecekapan penggunaan menggunakan pengkomputeran elastik. Kebanyakan perkhidmatan utama kami, seperti Suapan Berita, ciri Pemesejan dan peringkat web bahagian hadapan, berbeza-beza bergantung pada masa hari itu. Kami sengaja mengurangkan perkhidmatan dalam talian semasa waktu tenang dan menggunakan pelayan yang dibebaskan untuk beban kerja luar talian, seperti pembelajaran mesin dan pekerjaan MapReduce.

Kami tahu daripada pengalaman bahawa adalah lebih baik untuk menyediakan keseluruhan pelayan sebagai unit kapasiti anjal kerana perkhidmatan besar adalah kedua-dua penderma utama dan pengguna utama kapasiti anjal, dan dioptimumkan untuk menggunakan keseluruhan pelayan. Apabila pelayan dilepaskan daripada perkhidmatan dalam talian semasa waktu tenang, broker sumber memajak pelayan kepada penjadual untuk menjalankan beban kerja luar talian padanya. Jika perkhidmatan dalam talian mengalami beban puncak, broker sumber dengan cepat memanggil semula pelayan yang dipinjam dan, bersama-sama dengan penjadual, mengembalikannya kepada perkhidmatan dalam talian.

Pengajaran dan rancangan untuk masa depan

Sepanjang 8 tahun yang lalu, kami telah membangunkan Tupperware untuk mengikuti perkembangan pesat Facebook. Kami berkongsi apa yang telah kami pelajari dan berharap ia akan membantu orang lain mengurus infrastruktur yang berkembang pesat:

• Sediakan sambungan fleksibel antara panel kawalan dan pelayan yang diuruskannya. Fleksibiliti ini membolehkan panel kawalan mengurus pelayan di pusat data yang berbeza, membantu mengautomasikan penyahtauliahan dan penyelenggaraan kluster, dan membolehkan peruntukan kapasiti dinamik menggunakan pengkomputeran anjal.
• Dengan panel kawalan tunggal di rantau ini, ia menjadi lebih mudah untuk bekerja dengan tugas dan lebih mudah untuk mengurus kumpulan pelayan kongsi yang besar. Ambil perhatian bahawa panel kawalan mengekalkan satu titik kemasukan, walaupun struktur dalamannya dipisahkan atas sebab skala atau toleransi kesalahan.
• Menggunakan model pemalam, panel kawalan boleh memberitahu aplikasi luaran tentang operasi kontena yang akan datang. Selain itu, perkhidmatan stateful boleh menggunakan antara muka pemalam untuk menyesuaikan pengurusan kontena. Dengan model pemalam ini, panel kawalan menyediakan kesederhanaan sambil menyediakan perkhidmatan yang berbeza dengan cekap.
• Kami percaya bahawa pengkomputeran elastik, di mana kami mengambil seluruh pelayan daripada perkhidmatan penderma untuk kerja kelompok, pembelajaran mesin dan perkhidmatan tidak mendesak yang lain, ialah cara optimum untuk meningkatkan kecekapan pelayan kecil yang cekap tenaga.

Kami baru mula melaksanakan kumpulan pelayan kongsi global tunggal. Pada masa ini kira-kira 20% daripada pelayan kami berada dalam kumpulan kongsi. Untuk mencapai 100%, banyak isu perlu ditangani, termasuk mengekalkan kumpulan storan dikongsi, mengautomasikan penyelenggaraan, mengurus keperluan penyewa silang, meningkatkan penggunaan pelayan dan menambah baik sokongan untuk beban kerja pembelajaran mesin. Kami tidak sabar untuk menyahut cabaran ini dan berkongsi kejayaan kami.

Sumber: www.habr.com