Panduan Alimei: Bahtera (bahtera) Cainiao adalah pengelolaan sumber daya dan platform operasi dan pemeliharaan untuk semua penelitian dan pengembangan Cainiao. Ia bertanggung jawab atas pengelolaan dan kontrol sumber daya infrastruktur Cainiao untuk mendukung kebutuhan sumber daya harian dan skala besar. Penjadwalan yang fleksibel adalah bagian penting dari Tabut Cainiao, dan ini juga merupakan fitur penting dari Tabut.
Melalui penjadwalan yang fleksibel, aplikasi dapat memperluas sumber daya pada saat tekanan bisnis meningkat, dan melepaskan sumber daya saat tekanan bisnis turun, untuk mencapai efisiensi pemanfaatan sumber daya sebanyak mungkin sambil memastikan stabilitas. Di masa mendatang, setelah memperkenalkan tugas offline untuk mencampur atau menentukan harga resource yang detail, model ini akan sangat mengurangi biaya IT pemula secara keseluruhan. Hari ini, mari kita bahas secara mendetail tentang teknologi di balik Sistem Penjadwalan Fleksibel Ark Cainiao, berharap dapat menginspirasi Anda.
Mengapa pemula membutuhkan penjadwalan yang fleksibel?
Sebelum munculnya penjadwalan yang fleksibel, tingkat pemanfaatan sumber daya secara keseluruhan Cainiao berada pada tingkat yang relatif rendah. Ini karena:
1. Aplikasi on-line umumnya menentukan jumlah kontainer yang dibutuhkan dengan melakukan satu uji tekanan kinerja alat berat dan menggabungkan pengalaman untuk memperkirakan aliran bisnis. Metode ini sebagian besar dipengaruhi oleh faktor subjektif penilai, dan biasanya mempertahankan redundansi yang lebih besar saat memperkirakan lalu lintas bisnis.
2. Dalam mode sebelumnya, frekuensi operasi ekspansi dan kontraksi paket aplikasi sangat rendah, sehingga perlu dilakukan estimasi aliran bisnis dengan mengambil aliran puncak harian dan perkembangan bisnis di periode waktu mendatang (biasanya dalam bulan). Kriteria evaluasi. Secara umum, periode lalu lintas puncak mungkin hanya menyumbang sebagian kecil dari seluruh hari, dan sejumlah besar pemborosan sumber daya terjadi selama periode non-puncak.
Dilihat dari kinerja pengelompokan aplikasi fleksibel akses, evaluasi kapasitas yang tidak akurat adalah fenomena yang sangat umum, dan penyimpangan dari nilai sebenarnya sangat besar. Penjadwalan elastis adalah sistem yang secara dinamis mengevaluasi status operasi sistem dan membuat keputusan tentang perluasan dan kontraksi. Ini memungkinkan pengembang aplikasi serta personel operasi dan pemeliharaan untuk fokus pada sumber daya dari jumlah kontainer yang lebih konkret ke tingkat abstraksi yang lebih tinggi. "Sasaran" (seperti target pemanfaatan sumber daya yang wajar, target rt yang masuk akal untuk layanan) mengurangi pengaruh faktor subjektif yang secara tak terelakkan diperkenalkan selama evaluasi manual. Selain itu, dikombinasikan dengan kemampuan ekspansi dan kontraksi yang andal dan efisien yang disediakan oleh platform Ark, ketepatan waktu operasi ekspansi dan kontraksi untuk grup aplikasi dapat mencapai level menit, sehingga mewujudkan "penggunaan sesuai permintaan" sumber daya dalam arti yang sebenarnya. Untuk pemula, penjadwalan yang fleksibel adalah cara paling efektif untuk meningkatkan pemanfaatan sumber daya.
Mengapa pemula lebih cocok untuk penerapan yang fleksibel?
Meskipun penjadwalan fleksibel dapat membawa manfaat penggunaan yang lebih besar, ini tidak cocok untuk semua perusahaan atau organisasi. Keberhasilan penerapannya di Cainiao terutama bergantung pada alasan berikut:
-
Karakteristik bisnis Cainiao menentukan bahwa sistem akan mengoordinasikan aliran informasi antara pedagang, cp, dan konsumen, dan karakteristik tautan panjang dan multi-interaksi dari aliran pesanan logistik juga menentukan bahwa aliran informasi lebih besar daripada aliran sebenarnya, sehingga sistem kami menghadapi pemandu belanja. Sistem penjadwalan fleksibel Ark spike-in puncak pendatang baru Ark minimal.
-
Setelah Cainiao merealisasikan containerization sepenuhnya dan terhubung ke sistem arsitektur cloud hybrid pada awal tahun 2017, Cainiao telah menyelesaikan transformasi manajemen resource dari "berorientasi mesin" menjadi "berorientasi aplikasi", dan operasi inti serta proses pemeliharaan seperti penerapan dan perluasan dan penyusutan aplikasi telah diperoleh. Penyederhanaan dan peningkatan efisiensi yang hebat. Sebagai platform manajemen dan kontrol sumber daya kontainer, platform Ark telah menjalani pengujian 618 dan Double Eleven pada tahun 2017, dan stabilitasnya telah diverifikasi sepenuhnya, yang telah menciptakan landasan teknis yang memadai untuk implementasi penjadwalan yang fleksibel.
-
Sebagian besar aplikasi inti Cainiao adalah aplikasi komputasi online tanpa kewarganegaraan, dan kesenjangan antara nilai puncak dan lembah tekanan bisnis harian terlihat jelas, yang memberikan dasar skenario bisnis yang memadai untuk implementasi penjadwalan yang fleksibel.
-
Penjadwalan yang fleksibel bukanlah proyek independen, ini membutuhkan bantuan dari banyak layanan dasar, dan bergantung pada lingkungan sistem yang terpadu dan terstandarisasi. Aplikasi Cainiao sesuai dengan spesifikasi Alibaba Group. Penjadwalan yang fleksibel dapat langsung membaca operasi pemantauan dan data pemeliharaan yang disediakan oleh alat seperti alimonitor, Hawkeye, dan alimetrics, dan tumpukan teknologi yang digunakan oleh aplikasi inti pada dasarnya telah disatukan. Pendaratan memberikan landasan lingkungan yang memadai.
Berdasarkan empat poin di atas, rookie dapat dengan cepat mencapai penjadwalan yang fleksibel dengan biaya yang kecil.
Apa bedanya dengan produk sejenis?
Banyak tim dalam grup telah mengembangkan produk penjadwalan yang fleksibel untuk domain bisnis tertentu, dan beberapa penyedia layanan cloud publik di industri juga menyediakan layanan skalabilitas yang fleksibel. Masalah yang dihadapi oleh penjadwalan fleksibel Cainiao dan ide produk terkait terkait dengan ini Apa perbedaan antara produk sejenis?
Pertama-tama, rentang aplikasi yang diharapkan untuk mencakup penjadwalan elastis Cainiao adalah semua aplikasi inti tanpa kewarganegaraan dari Cainiao. Tautan bisnis, karakteristik logika, kecenderungan sumber daya, dan karakteristik lalu lintas bisnis yang terlibat dalam aplikasi inti ini sangat berbeda. Sulit untuk mengabstraksi model bisnis umum untuk menggambarkan aplikasi ini. Oleh karena itu, tidak seperti penjadwalan fleksibel untuk domain bisnis tertentu, penjadwalan fleksibel Cainiao tidak dapat membuat terlalu banyak asumsi bisnis saat merancang, dan keserbagunaan yang memadai harus dipertimbangkan saat merancang algoritme penjadwalan dan mode strategi; kebutuhan konfigurasi Memberi pengguna kemampuan personalisasi yang memadai untuk mengatasi skenario bisnis yang berbeda, ketika merancang struktur sistem, perlu mempertimbangkan kapabilitas ekspansi horizontal dari strategi. Ketika skenario bisnis khusus baru muncul, ia dapat melakukan ekspansi linier yang cepat.
Kedua, ketika berhadapan dengan skenario yang kompleks, semakin fleksibel sistemnya, semakin banyak opsi konfigurasi yang dibawanya. Layanan penjadwalan yang fleksibel di cloud publik biasanya menyediakan banyak parameter konfigurasi, justru karena mereka ingin menyelesaikan masalah Pendekatan "lempar ke pengguna" mengimbangi kompleksitas masalah dan memungkinkan pengguna bertanggung jawab atas stabilitas dan biaya mereka sendiri. Risiko stabilitas dan efek penghematan biaya yang ditimbulkan oleh penjadwalan fleksibel semacam ini sepenuhnya bergantung pada pemahaman pengguna tentang teknologi ini. Sebaliknya, sebagai tim teknis dasar Cainiao, kami mendefinisikan peran kami sebagai pemecah masalah stabilitas dan biaya, daripada memberikan lebih banyak masalah kepada pengguna kami. Kami berharap dapat menyediakan semua pemilik aplikasi Cainiao. Ini bukan hanya fungsi manajemen sumber daya baru seperti elastisitas di cloud publik, tetapi juga mengurangi biaya dan meningkatkan stabilitas bagi pengguna kami. Oleh karena itu, pada awal desain produk, kami berharap sebagian besar grup aplikasi dapat mencapai fleksibilitas akses sekali klik, menyelesaikan sebagian besar masalah konfigurasi aplikasi sebelum pengguna melihatnya, dan memasukkan konfigurasi parameter kebijakan ke dalam Dalam ruang lingkup tanggung jawab inti. Dan untuk aplikasi dengan persyaratan khusus, berikan saran tambahan untuk membantu mereka dengan sejumlah kecil konfigurasi untuk menyelesaikan pengenalan fleksibilitas.
Status aplikasi penjadwalan fleksibel saat ini
Sejauh ini, Cainiao pada dasarnya telah menyadari akses fleksibel ke grup aplikasi tanpa negara dengan lebih dari 15 kontainer (sebelum akses), dan tingkat penggunaan CPU rata-rata keseluruhan grup aplikasi akses telah mencapai lebih dari 20% (metode penghitungan) Untuk mengambil rata-rata tertimbang penggunaan CPU pengelompokan dan jumlah wadah pengelompokan). Jumlah total peti kemas yang diperluas dan dikontrak per hari lebih dari 3.000. Pada saat Double Eleven tahun 2017, penjadwalan fleksibel digunakan sebagai metode tambahan untuk mengecilkan beberapa grup aplikasi dari 0:00 pada 12 November, yang secara signifikan mengurangi rasio jumlah inti CPU fisik dengan jumlah paket yang ditempati oleh pemula.
Gambar 1 berikut menunjukkan perbandingan kurva perubahan penggunaan CPU dan jumlah container dalam satu hari dari suatu grup aplikasi; Gambar 2 menunjukkan kurva perubahan aliran layanan inti tertentu dari grup aplikasi pada saat yang sama:
Pengenalan Program Penjadwalan Fleksibel Bahtera Cainiao
Mode dasar penjadwalan fleksibel
Seperti yang disebutkan sebelumnya, penjadwalan fleksibel Ark berharap untuk memberikan pengguna tidak hanya kemampuan untuk memanipulasi sumber daya cluster secara fleksibel, tetapi juga bertanggung jawab atas pengoptimalan biaya dan stabilitas untuk semua pengguna. Karena aplikasi target sangat berbeda dalam semua aspek, ada ribuan item konfigurasi yang terlibat dan selalu dalam keadaan dinamis. Sangat tidak realistis untuk mengandalkan manajemen konfigurasi manual kami.
Akibatnya, penjadwalan fleksibel Ark mengusulkan mode umpan balik loop tertutup (seperti yang ditunjukkan pada gambar di atas). Kemampuan dasar penjadwalan fleksibel didasarkan pada kondisi operasi grup aplikasi dan parameter konfigurasi kebijakan grup aplikasi yang berbeda, membuat keputusan perluasan dan kontraksi, dan menyesuaikan jumlah kontainer cluster melalui layanan operasi kontainer Ark; cluster pengelompokan aplikasi dipengaruhi oleh perubahan jumlah kontainer cluster, yang akan menghasilkan Perilaku kinerja yang berbeda (misalnya, penggunaan CPU rata-rata kluster akan berubah selama perluasan, layanan rt akan turun dalam rentang tertentu, dll.); Kinerja pengelompokan aplikasi disediakan dengan data waktu nyata untuk pengambilan keputusan yang fleksibel, dan data historis juga akan offline Penyimpanan (Alimonitor / EagleEye dan sistem pemantauan standar grup lainnya menyediakan layanan data tersebut); konfigurasi strategi otomatis akan secara berkala mendapatkan data historis ini, dan menurut algoritme tertentu, grup aplikasi yang berbeda akan dikonfigurasi dengan strategi berbeda, yang akan mempengaruhi lagi Keputusan untuk strategi penjadwalan yang fleksibel.
Keunggulan model ini adalah:
1. Memiliki tingkat kemampuan evolusi diri tertentu. Ketika pengelompokan aplikasi hanya dikaitkan dengan elastisitas, sebagian besar parameter strateginya adalah nilai default; dan setelah operasi elastis untuk jangka waktu tertentu, dikombinasikan dengan metode evaluasi otomatis, berbagai parameter akan terus direvisi untuk mencapai elastisitas yang lebih baik. Ambil strategi keamanan layanan sebagai contoh: strategi keamanan layanan pada tahap pengambilan keputusan secara real-time adalah membandingkan layanan saat ini rt dengan ambang batas layanan sla. Ketika elastisitas baru diakses, sla layanan diperoleh berdasarkan rt historis sebelum elastisitas akses layanan Ya, secara umum, kinerja layanan rt dalam keadaan inelastis sangat berbeda dengan kinerja layanan rt dalam keadaan elastis. Pada awalnya, layanan sla mungkin diset secara tidak wajar (umumnya terlalu kecil). Ada fenomena "perluasan ganda", dan perluasan yang disebabkan oleh sla pelanggaran rt layanan akan menjelaskan sebagian besar alasan perluasan secara keseluruhan. Fenomena ini akan ditangkap oleh tugas analisis yang dilakukan secara teratur setiap hari, dan dinilai bahwa pengaturan sla tidak masuk akal, dan sla layanan dihitung ulang berdasarkan status berjalan beberapa hari terakhir, sehingga meningkatkan rasionalitas pengaturan ambang batas;
2. Konfigurasikan parameter besar pada tingkat abstraksi yang lebih tinggi untuk memecahkan masalah umum. Atau ambil sla threshold dari layanan rt sebagai contoh. Ketika kita fokus pada layanan tertentu dari perspektif konfigurasi, kita mungkin terjerat dalam logika bisnis spesifik dari sebuah layanan, apa saja call link yang dilibatkannya, dan layanan upstream Toleransi dan detail lainnya, jadi dengan cara ini, menghadapi ribuan layanan yang disediakan oleh aplikasi Cainiao yang berbeda, tidak mungkin untuk mengkonfigurasinya satu per satu (Catatan: Setiap hari, layanan akan online dan offline, dan layanan akan Logika bisnis juga dapat berubah, dan konfigurasi perlu sering diperbarui, yang tidak diragukan lagi membuat konfigurasi manual menjadi lebih tidak realistis). Logika konfigurasi kebijakan otomatis melihat berbagai parameter pada tingkat abstraksi yang lebih tinggi. Untuk layanan rt, ini didasarkan pada asumsi yang berlaku secara umum: "Layanan rt berada dalam keadaan yang wajar hampir sepanjang hari", dan melalui distribusi probabilitas Hitung (distribusi sebenarnya dari layanan rt juga dapat diperoleh melalui statistik data historis), dan Anda bisa mendapatkan ambang batas matematika (ambil distribusi normal sebagai contoh, temukan rata-rata rt dan deviasi standar dari distribusi rt selama periode waktu tertentu, yaitu Bisa mendapatkan ambang batas yang harus ditetapkan di bawah probabilitas yang berbeda).
Seperti yang ditunjukkan pada kurva distribusi normal pada gambar di atas, jika kita menetapkan threshold sebagai rata-rata rt + 2 standar deviasi, maka menurut perhitungan probabilitas kasar, kita asumsikan bahwa ada hampir 33 menit layanan dalam sehari dengan rt tinggi (1440 menit * (1-0,9544) ) / 2), dan dengan demikian mendapatkan ambang batas yang wajar secara matematis (bagian logika ini hanya sebagian kecil dari logika kebijakan keamanan layanan, yang akan dijelaskan secara rinci saat kebijakan tersebut diperkenalkan nanti). Dengan cara ini, untuk berbagai layanan, selama data pemantauan historis dapat diperoleh, ambang batas matematika ini dapat diperoleh secara otomatis dan cepat.
Sistem arsitektur penjadwalan yang fleksibel
Bagian ini tidak akan menjadi interpretasi yang terlalu berlebihan di sini, bagian lain dari artikel ini akan lebih atau kurang terlibat.
Mengapa mengadopsi model pengambilan keputusan tiga tingkat?
Pertama, kami akan memperkenalkan pengambilan keputusan tiga tingkat untuk penjadwalan kapal yang fleksibel:
1. Lapisan pertama adalah pengambilan keputusan strategis Lapisan pengambilan keputusan strategis terdiri dari beberapa strategi yang berbeda dan mendukung perluasan yang cepat. Logika antara strategi benar-benar terisolasi.Setelah setiap perhitungan strategi selesai, tindakan (ekspansi, penyusutan, tidak berubah) dan kuantitas akan menjadi keluaran secara independen. Untuk dapat beradaptasi dengan heterogenitas antar aplikasi yang berbeda, setiap kelompok aplikasi juga dapat memulai atau menutup strategi yang berbeda sesuai dengan situasi sebenarnya.
2. Lapisan kedua adalah pengambilan keputusan agregat. Pengambilan keputusan gabungan mengumpulkan hasil keputusan dari semua strategi di lapisan pertama, dan memperoleh hasil gabungan sesuai dengan aturan agregasi < Tindakan, kuantitas > kelompok. Aturan pada level ini sangat sederhana: ketika ada hasil keputusan ekspansi dan penyusutan, ekspansi akan berlaku dan hasil penyusutan harus diabaikan; bila ada beberapa hasil ekspansi, hasil dengan jumlah ekspansi terbesar akan menjadi hasil akhir; bila ada lebih banyak Dalam hal hasil pengurangan, hasil dengan jumlah pengurangan yang lebih kecil akan menjadi hasil akhir.
3. Lapisan ketiga adalah keputusan eksekusi Bagian keputusan ini terutama akan mempertimbangkan beberapa aturan, dan akhirnya memberitahu layanan perluasan: apakah akan memperluas atau mengontrak, berapa banyak kontainer untuk diperluas atau dikontrak, dan jika menyusut, angka mana yang harus diskalakan? Wadah, jika itu adalah ekspansi, maka spesifikasi wadah tertentu, perluasan ruang komputer, dll. Aturan yang perlu diperhatikan saat membuat keputusan dan penilaian sangatlah rumit. Berikut beberapa aturan yang relatif penting:
-
Aturan untuk berbagi ruang peralatan;
-
Aturan perluasan dan status kontraksi pengelompokan aplikasi saat ini, misalnya, jika ini adalah perluasan: Jika jumlah target perluasan saat ini lebih besar dari jumlah target perluasan saat ini, ambil selisihnya dan mulai perluasan lain, sehingga mencapai perluasan paralel; Jika jumlah target perluasan kurang dari jumlah target perluasan, permintaan perluasan diabaikan; jika perluasan sedang berlangsung, penskalaan akan segera dihentikan, dan perluasan akan dimulai sesuai dengan target jumlah kontainer dan jumlah kontainer saat ini.
-
Aturan mode: Penjadwalan fleksibel saat ini mendukung mode perluasan dan kontraksi otomatis serta mode persetujuan manual. Jika pengelompokan saat ini dalam mode persetujuan manual, administrator perlu menyetujui keputusan ini.
-
Aturan perlindungan maksimum dan minimum: Grup aplikasi dapat dikonfigurasi dengan nilai maksimum dan minimum. Keputusan pelaksanaan akan memastikan bahwa tugas penskalaan yang dimulai dengan penjadwalan fleksibel tidak akan menyebabkan jumlah penampung akhir melebihi maksimum atau kurang dari minimum.
Selain itu, lapisan keputusan eksekusi sangat konsisten untuk satu grup, dan keluaran hasil keputusan oleh lapisan kedua adalah jumlah target kontainer yang perlu dicapai cluster. Desain ini adalah bahwa dua lapisan pertama dapat sepenuhnya tanpa kewarganegaraan dan idempoten. Faktor utama.
Pengambil keputusan tiga tingkat membuat setiap lapisan hanya perlu memperhatikan logika keputusannya sendiri, memisahkan logika bisnis "perubahan dan tidak berubah", dan memverifikasi penentuan akhir perluasan dan kontraksi lapis demi lapis, yaitu untuk mencapai "mencakup sebagian besar aplikasi pemula" Dasar dari tujuan tersebut.
Bagaimana cara mencapai komputasi tanpa kewarganegaraan, idempoten, dan ketersediaan tinggi?
1. Penjadwalan fleksibel Ark sangat bergantung pada ISS. ISS, sebagai middleware dengan ketersediaan tinggi yang telah mengalami promosi besar dan menyediakan layanan penjadwalan tugas asinkron untuk banyak bisnis inti Cainiao, sangat andal dalam hal fungsi, kinerja, dan stabilitas. Penjadwalan fleksibel Ark mengadopsi mode "tarik aktif periodik frekuensi pendek" untuk akuisisi data online. Melalui fungsi panggilan tugas asinkron periodik yang disediakan oleh ISS, periode ISS independen secara otomatis terdaftar untuk setiap grup aplikasi saat mengakses elastisitas. tugas. Saat ISS memulai tugas, ISS memilih secara acak dari cluster target, mengelola siklus hidup eksekusi tugas, dan mendukung percobaan ulang tugas. Selain itu, klien ISS juga menyediakan kapabilitas perlindungan sumber daya, ketika tekanan suatu proses dalam cluster terlalu tinggi, maka mesin target akan diganti dan dicoba lagi.
2. Data perhitungan online dari penjadwalan fleksibel Ark berasal dari alimetri sistem pemantauan internal. Alimetrics adalah sistem metrik tertanam yang menyertai penampung web, yang berisi banyak item pemantauan. Jika diperlukan untuk mendapatkan data pemantauan yang sangat rinci dari pengelompokan aplikasi, kueri data, pembacaan, dan tekanan transmisi dialokasikan ke setiap kontainer target, bukan ke pusat data terpusat. Desain ini membuat sumber data tidak ada Intinya, keandalan dan toleransi stres sumber data jauh lebih unggul daripada mengandalkan layanan data terpusat.
3. Untuk memfilter gangguan, semua kalkulasi didasarkan pada jendela waktu geser yang lebih besar atau lebih kecil. Memperoleh data dalam jangka waktu singkat (dalam 1 jam) melalui alimetrics dapat memiliki kinerja yang sangat tinggi dan memiliki sedikit gangguan pada aplikasi, yang mengurangi biaya percobaan ulang penghitungan. Berdasarkan kemampuan ini, tugas komputasi penjadwalan fleksibel dapat mengambil semua data pemantauan dalam jendela waktu setiap kali dijalankan, tanpa mempertahankan jendela geser di memori mereka sendiri, yang merupakan basis stateless dari komputasi penjadwalan fleksibel;
4. Dalam pembuat keputusan tiga tingkat untuk penjadwalan yang fleksibel, tingkat ketiga dan dua tingkat lainnya diterapkan dalam cluster yang berbeda. Terlepas dari status pengelompokan aplikasi, lapisan pertama dan kedua harus melakukan penghitungan periodik frekuensi pendek, dan hanya ketika perluasan dan kontraksi diperlukan (hanya sebagian kecil hari) tugas akan dikirim ke lapisan ketiga. Oleh karena itu, kisaran konsistensi yang kuat terbatas pada lapisan ketiga, yang memiliki dampak paling kecil pada kinerja sekaligus memastikan keandalan. Jumlah keluaran keputusan dari lapisan kedua ke lapisan ketiga diberikan dalam bentuk "nomor penampung target" daripada "kapasitas penskalaan", sehingga meskipun ada beberapa tugas keputusan yang fleksibel untuk grup aplikasi pada saat yang sama Selama eksekusi, mengeluarkan beberapa hasil keputusan ke lapisan ketiga tidak akan memengaruhi perilaku ekspansi dan kontraksi akhir.
Strategi keputusan
Strategi pengambilan keputusan penjadwalan fleksibel Ark mendukung ekspansi horizontal yang cepat. Saat ini, berisi beberapa strategi pengambilan keputusan, dan beberapa strategi sedang dalam tahap pengujian dan verifikasi. Berikut adalah beberapa strategi online paling inti dan paling awal:
Strategi keamanan sumber daya
Kebijakan keamanan sumber daya berfokus pada penggunaan sumber daya sistem. Saat ini, berdasarkan pengalaman pengoperasian dan pemeliharaan sebelumnya serta karakteristik bisnis Cainiao, strategi keamanan sumber daya berfokus pada tiga parameter sistem CPU, LOAD1, dan antrian Proses Berjalan. Ketika lebih dari satu dari mereka, rata-rata cluster dalam jendela waktu terakhir (untuk menghilangkan dampak gangguan dan lalu lintas yang tidak rata) melanggar ambang batas atas (mendukung konfigurasi yang dipersonalisasi), memulai perluasan. Jika ada beberapa pelanggaran, ambil salah satu dengan jumlah ekspansi terbesar sebagai hasil keputusan kebijakan saat ini (metode penghitungan angka diberikan nanti).
Gambar di atas adalah penggunaan sumber daya ketika kebijakan keamanan sumber daya mendapatkan hasil perluasan.
Strategi pengoptimalan sumber daya
Strategi pengoptimalan sumber daya juga memperhatikan penggunaan sumber daya sistem, tetapi ada untuk memulihkan sumber daya saat sistem tidak aktif. Perhatikan juga ketiga parameter sistem di atas, ketika ketiga item ini lebih rendah dari ambang bawah pada saat yang sama, mulailah penyusutan. Perhatikan bahwa karena keberadaan pembuat keputusan tingkat kedua, ketika pembuat keputusan lain meminta perluasan kapasitas, permintaan yang menyusut yang dihasilkan oleh strategi pengoptimalan sumber daya akan ditekan.
Gambar di atas adalah penggunaan resource ketika strategi pengoptimalan resource mengalami penyusutan.
Strategi waktu
Model pengambilan keputusan elastis saat ini adalah a posteriori, yaitu perluasan dimulai setelah terjadi pelanggaran ambang batas. Untuk beberapa bisnis, ada lonjakan lalu lintas reguler, seperti beberapa tugas komputasi terjadwal. Konfigurasi kebijakan otomatis didasarkan pada riwayat perubahan lalu lintas aplikasi. Jika ditentukan bahwa perubahan lalu lintas bersifat periodik dan perubahan terlalu besar, dan elastisitas posterior tidak dapat mengikuti waktu, konfigurasi kebijakan waktu akan dibuat untuk grup ini, yaitu, dalam harian Pertahankan jumlah wadah klaster di atas jumlah yang ditentukan dalam jangka waktu tertentu. Karena keberadaan pengambil keputusan tingkat kedua, ketika strategi lain menentukan bahwa jumlah kontainer yang dibutuhkan selama periode waktu ini lebih besar dari jumlah konfigurasi yang ditentukan, maka yang lebih besar akan digunakan sebagai hasilnya; dan selama ini, karena strategi waktu akan Terus menghasilkan hasil perluasan (jika angkanya sudah terpenuhi, maka buat keputusan perluasan, tetapi jumlahnya 0), dan hasil keputusan penyusutan lainnya akan terus ditekan.
Kebijakan keamanan layanan
Strategi keamanan layanan saat ini merupakan strategi yang paling rumit. Saat ini, layanan mencakup antrian pesan Konsumen, layanan RPC, dan layanan HTTP. Setidaknya setengah dari tugas perluasan setiap hari diprakarsai oleh kebijakan keamanan layanan.
Pilih qps atau rt?
Banyak sistem penjadwalan yang fleksibel akan memilih qps dari layanan sebagai pertimbangan yang paling penting. Namun, setelah serangkaian pemikiran dan diskusi awal, kami memutuskan untuk meninggalkan qps dan menggunakan rt, terutama karena alasan berikut:
1. Qps adalah variabel layanan, dan perubahannya dibatasi oleh penggunaan pengguna. Anda dapat menilai apakah qps pada saat ini masuk akal untuk bisnis xx, tetapi untuk sistem, selama dapat dijalankan, tingkat keberhasilan layanan dan rt berada dalam kisaran yang wajar, nilai qps apa pun masuk akal. Dengan kata lain, qps total saat ini dapat digunakan sebagai dasar untuk menilai kesehatan bisnis, tetapi tidak dapat digunakan sebagai dasar untuk menilai kesehatan sistem (dalam arti sempit) (qps maksimum yang dapat diterima dari satu mesin berbeda dari itu, perhatikan perbedaannya). rt dan tingkat keberhasilan layanan adalah karakteristik kinerja yang paling mendasar dari suatu layanan.
2. Jumlah kontainer saat ini diperoleh melalui qps saat ini dan qps maksimum yang dapat diterima dari satu mesin. Hal ini hanya berlaku jika sumber daya benar-benar terisolasi dan sumber daya yang digunakan oleh setiap kueri hampir sama. Untuk aplikasi pemula:
-
Banyak aplikasi inti merupakan tautan lintas bisnis dan berfungsi dalam berbagai cara. Layanan kueri data dan layanan yang melibatkan operasi bisnis kemungkinan besar muncul dalam grup aplikasi yang sama. Pada saat ini, konsep qps total menjadi tidak berarti, dan tidak mungkin untuk mendapatkan hubungan antara permintaan individu dan sumber daya untuk layanan yang berbeda.
-
Efek isolasi wadah saat ini tidak terlalu sempurna. Dalam uji tegangan tautan penuh, fenomena penggunaan sumber daya homogen dengan wadah mesin fisik sering kali tampak bersaing satu sama lain, yang membuat lingkungan operasi online aktual dan lingkungan uji tegangan kinerja mesin tunggal tidak mungkin Selain itu, signifikansi referensi dari data uji tekanan kinerja yang berdiri sendiri meragukan.
-
Servis dapat berubah kapan saja, dan uji tekanan kinerja mesin yang berdiri sendiri tidak dapat menindaklanjuti setiap kali terjadi perubahan, dan ketepatan waktu tidak dapat dijamin.
Perbandingan ambang batas dan pemungutan suara multi-layanan
Cara mengkonfigurasi ambang batas secara otomatis untuk rt untuk layanan massal telah diperkenalkan pada contoh sebelumnya, dan tidak akan diulangi di sini. Tetapi perlu dicatat bahwa: karena pengaturan ambang batas ini hanya merupakan "ambang batas wajar" matematis, cara lain diperlukan untuk memodifikasinya. Oleh karena itu, kami memperkenalkan asumsi lain: jika rt melanggar ambang batas yang disebabkan oleh sumber daya yang tidak mencukupi, semua layanan dalam grup akan terpengaruh. Ini karena sumber daya yang digunakan antara layanan dalam grup aplikasi tidak terisolasi. Mereka menggunakan lingkungan sistem yang sama (terpengaruh tidak berarti bahwa semua layanan akan melanggar ambang batas. Layanan yang berbeda bergantung pada jenis sumber daya yang berbeda. Toleransi kekurangan sumber daya juga berbeda).
Oleh karena itu, kami mengadopsi model "pemungutan suara multi-layanan" untuk membuat penilaian rt. Setiap layanan melakukan perbandingan threshold yang independen. Ketika proporsi rt yang melanggar threshold dari total layanan mencapai level tertentu, maka diambil keputusan perluasan. Jumlah keputusan perluasan jaminan keamanan layanan ditentukan oleh pelanggaran threshold (dihitung dari persentase pelanggaran). Keputusan layanan.
Dilihat dari situasi operasi sebenarnya, ketika beroperasi dalam mode "perluasan selama layanan melanggar ambang batas", frekuensi ekspansi palsu dan beberapa ekspansi sangat tinggi. Setelah pengenalan mode "pemungutan suara multi-layanan" ini, ekspansi palsu , Multi-perluasan pada dasarnya dihilangkan (pada kenyataannya, ini sering digunakan untuk menilai secara manual apakah sebuah perluasan adalah perluasan yang salah, dan mode ini sering digunakan untuk beberapa perluasan. Ketika rt dari beberapa layanan ditemukan tinggi pada saat yang sama, perluasan dianggap masuk akal). Selain itu, semakin banyak layanan yang disediakan grup aplikasi, semakin baik efek mode ini.
Analisis hilir
Tidak semua ambang batas pelanggaran rt memerlukan perluasan. Jika peningkatan rt disebabkan oleh middleware atau layanan hilir yang bergantung, perluasan tidak akan menyelesaikan masalah, dan bahkan dapat menyebabkan efek yang lebih buruk (misalnya, kumpulan utas db penuh) . Oleh karena itu, selama penghitungan kebijakan keamanan layanan, jika layanan ditemukan melanggar ambang batasnya, layanan tersebut akan menanyakan layanan yang bergantung pada hilir terlebih dahulu dan apakah panggilan middleware rt melanggar sla masing-masing. Hanya jika layanan itu sendiri melanggar ambang batas, tetapi layanan hilir dan Jika middleware tidak melanggar ambang batas, ia akan berpartisipasi dalam pemungutan suara perluasan. Saat tugas luring menghitung sla layanan berdasarkan data historis, tugas luring juga menghitung ambang middleware dan layanan dependennya. Data struktur tautan berasal dari data luring Eagle Eye.
Beberapa masalah khusus lainnya
Bagaimana cara menangani gerinda?
Penjadwalan yang fleksibel perlu memastikan bahwa perluasan cukup tepat waktu, tetapi juga harus memiliki toleransi yang memadai terhadap gangguan sistem, jika tidak maka akan menyebabkan perluasan dan penyusutan yang salah. Glitch adalah fenomena umum di lingkungan aktual. Tidak hanya masalah lingkungan seperti lalu lintas yang tidak rata dan gangguan jaringan yang dapat menyebabkan gangguan, tetapi juga potensi kelainan dan bug dalam sistem statistik pemantauan juga dapat menyebabkan gangguan.
Untuk alasan ini, penjadwalan fleksibel Ark akan memperkenalkan data jendela waktu sebagai sumber penghitungan saat melakukan penghitungan apa pun, dan data setiap blok waktu berisi data dari semua penampung dalam sebuah kluster:
Saat menghitung, untuk setiap item pemantauan yang diperlukan, nilai maksimum dan minimum di jendela waktu akan dihapus, dan kemudian rata-rata akan dihitung untuk menghapus dampak gerinda. Selain itu, ukuran jendela waktu berdampak besar pada deburring dan ketepatan waktu. Saat ini, ada dua jendela waktu yang berbeda yaitu 5 menit dan 10 menit dalam penjadwalan fleksibel Ark. Untuk strategi yang dapat mengarah pada perluasan kapasitas, pilih jendela waktu yang lebih kecil, dan untuk strategi yang dapat menyebabkan kontraksi, pilih jendela waktu yang lebih besar (kami berharap perluasan lebih radikal daripada kontraksi).
Bagaimana cara menghitung jumlah ekspansi dan kontraksi?
Setelah menentukan apakah akan melakukan ekspansi atau kontrak, langkah kedua adalah menentukan jumlah ekspansi. Pertama perkenalkan penyusutan, karena kecepatan penyusutan relatif cepat dibandingkan dengan ekspansi, dan penyusutan yang lambat tidak mempengaruhi stabilitas, sehingga penjadwalan elastis Ark menyusut penggunaan metode "langkah kecil dan lari cepat", selama penyusutan diputuskan, kemudian Jumlah container dengan penyusutan tetap adalah 10% dari jumlah container saat ini di cluster.
Penilaian jumlah ekspansi jauh lebih rumit daripada penyusutan Di sini kita mengambil keputusan kuantitatif strategi perbandingan ambang batas yang paling umum sebagai contoh. Pertama, tentukan prinsip besar: jumlah maksimum ekspansi setiap kali tidak boleh melebihi 50% dari jumlah container saat ini di cluster. Dalam rentang ini, semakin tinggi pelanggaran ambang, semakin besar jumlah container yang diperluas. Oleh karena itu, kami memperkenalkan fungsi sigmoid di sini, membuat hasil perhitungan antara 0 dan 0,5 melalui konversi tertentu, dan mengganti persentase pelanggaran ambang batas sebagai masukan ke dalam fungsi sigmoid (tentu saja akan dilakukan beberapa penyesuaian parameter) untuk mendapatkan persentase pemuaian .
Fungsi sigmoid adalah kurva yang bervariasi antara 0 dan 1, dan sering digunakan dalam kalkulasi normalisasi data. Untuk f (x) = sigmoid (x) -0.5, saat x > Pada 0, nilai fungsi ini antara 0 dan 0,5.
Untuk data seperti penggunaan CPU, satu perbedaan adalah nilai maksimum item ini tidak melebihi 100, dan ada batas atas; sedangkan data seperti service rt tidak memiliki batas atas. Jelas, menggunakan rumus yang sama akan menyebabkan jumlah ekspansi yang dipicu oleh CPU menjadi lebih sedikit daripada jumlah ekspansi yang dipicu oleh layanan rt. Saat ini yang perlu ditetapkan hanya satu goal saja, misalnya kita berharap pada saat penggunaan CPU mencapai 80% yaitu pada saat nilai pelanggarannya (80% -threshold) / threshold maka expansion ratio mendekati 50%. Berdasarkan tujuan tersebut maka f (x) dibalik. Koefisien a dapat diperoleh dengan perhitungan, dan hasil yang diharapkan dapat diperoleh dengan memasukkan koefisien a saat menghitung jumlah ekspansi untuk CPU.
Bagaimana mewujudkan fleksibilitas kapasitas tautan?
Selama semua paket aplikasi pada tautan memiliki akses ke fleksibilitas, sudah dapat dianggap bahwa kapasitas tautan ini juga fleksibel.
Bagaimana menghadapi panggung promosi besar?
Ark menyediakan solusi manajemen sumber daya lengkap untuk promosi besar melalui kerjasama "rencana kontainer" dan penjadwalan yang fleksibel. Rencana kontainer memungkinkan setiap pemilik aplikasi untuk mengajukan kapasitas dalam periode waktu tertentu promosi (termasuk uji tekanan dan periode promosi). Ketika akses ke grup aplikasi fleksibel memasuki periode promosi, mode perluasan dan kontraksi penjadwalan elastis akan segera diubah ke mode konfirmasi manual, dan jumlah kontainer klaster akan ditambah ke jumlah yang diminta oleh rencana kontainer. Ketika periode promosi besar berakhir, grup aplikasi tidak elastis akan langsung dikurangi ke jumlah asli wadah; sedangkan grup aplikasi elastis perlahan akan mendaur ulang sumber daya melalui strategi elastis.
Selama periode promosi besar, meskipun penjadwalan yang fleksibel tidak secara otomatis meluas atau menyusut, keputusan untuk menambah atau mengurangi masih dalam proses. Penjadwalan yang fleksibel akan terus mengeluarkan saran perluasan dan kontraksi kontainer kepada administrator atau tim pengambil keputusan promosi besar. Di satu sisi, ketika lalu lintas melebihi harapan dan sumber daya tidak mencukupi, itu akan segera memperingatkan dan memberikan jumlah perluasan yang disarankan, dan itu juga dapat membantu administrator dalam implementasi beberapa sumber daya tepat waktu. Daur ulang, untuk membantu keputusan yang menyusut.
Bagaimana penjadwalan yang fleksibel mendorong evolusi bisnis itu sendiri?
Penjadwalan yang fleksibel untuk mempromosikan evolusi bisnis itu sendiri telah menjadi tujuan kami.Bagi kami, hanya dengan cara ini kami dapat membentuk lingkaran tertutup bisnis yang nyata. Promosi ini terutama dilakukan melalui analisis data.Saat ini, penjadwalan yang fleksibel akan menghasilkan jenis data berikut:
-
rt | Relevansi sumber daya mencerminkan tingkat korelasi antara layanan rt dan CPU dan tingkat penggunaan sumber daya sistem lainnya. Semakin tinggi tingkat korelasinya, semakin sensitif penggunaan layanan terhadap sumber daya, dan semakin jelas manfaat menggunakan penjadwalan yang fleksibel;
-
Stabilitas middleware mencerminkan pelanggaran rt layanan yang disebabkan oleh middleware rt yang melebihi ambang batas. Karena peningkatan layanan rt secara langsung mempengaruhi ketersediaan layanan, ketika data ini terlalu tinggi, disarankan untuk memeriksa penggunaan middleware dan mengoptimalkannya;
-
Stabilitas hilir mencerminkan pelanggaran layanan rt yang disebabkan oleh layanan hilir rt melebihi ambang batas. Jika data ini terlalu tinggi, ini akan merekomendasikan aplikasi saat ini untuk mempromosikan peningkatan stabilitas layanan hilir, atau untuk mempromosikan fleksibilitas hilir;
-
Ketepatan waktu startup aplikasi, tugas perluasan dianggap berhasil hingga instance aplikasi dimulai, dan dapat diservis secara normal ke dunia luar. Semakin pendek waktu startup aplikasi, semakin tepat waktu perluasan penjadwalan elastis, dan perlindungan tercepat saat terjadi puncak lalu lintas
-
Konfigurasi pembatas arus yang wajar. Kami menemukan bahwa banyak aplikasi terhubung telah memicu batas konfigurasi mereka sendiri saat ini ketika layanan rt berada dalam kisaran normal dan penggunaan sumber daya sistem sangat rendah. Dalam hal ini, kami akan merekomendasikan aplikasi untuk melakukan analisis bisnis yang wajar Dan uji untuk menyesuaikan konfigurasi batas saat ini.
pengembangan masa depan
Saat ini, penjadwalan Ark yang fleksibel masih dalam proses pengembangan dan pertumbuhan, dan efek penjadwalan dari beberapa aplikasi perlu ditingkatkan lebih lanjut. Kami juga menantikan lebih banyak sepatu anak-anak yang mengetahui lebih banyak tentang wadah, penjadwalan, dan teknologi middleware untuk bergabung dan bekerja sama. Lanjutkan email pengiriman: jian.weng@alibaba-inc.com Kami menantikannya ~
- Kegagalan terbesar Rockets ditemukan dalam Perang Dunia I, dan Paul sangat marah! Apakah Morey masih memeliharanya untuk Tahun Baru?
- "Wembia" mendekat, Distrik Jinshan segera mengalirkan air untuk membuat kapasitas penyimpanan, mengevakuasi dan menempatkan penduduk
- Manik terbesar dari Piala Asia Sepak Bola Nasional! Dia tidak bermain selama 1 menit, tetapi para penggemar telah menantikannya!
- Sohu memiliki peternakan selain situs web? Kemarin, pengendara Pentium X40 berada di sana sepanjang hari
- Real Madrid akan melakukan dua hal besar musim panas ini? Cristiano Ronaldo meninggalkan BBC untuk hancur, dan sekarang beberapa anggota juga mempertimbangkan untuk pergi
- Houston Clippers? Absennya Harden dari Rockets memperlihatkan bahaya tersembunyi yang mematikan! Bisakah Paul melakukannya sendiri?
- Penghargaan Golden Globe Piala Dunia menjadi hadiah hiburan? Diberikan kepada pemain non-juara selama 5 kali berturut-turut, akan diproduksi di antara tiga