Memperkenalkan Cluster Resource Manager Service Fabric
Mengelola sistem TI atau layanan online secara tradisional berarti mendedikasikan komputer fisik atau virtual tertentu untuk layanan atau sistem tertentu tersebut. Layanan dirancang sebagai tingkatan. Akan ada tingkat "web" dan tingkat "data" atau "penyimpanan". Aplikasi akan memiliki tingkat perpesanan di mana permintaan mengalir masuk dan keluar, serta satu set komputer yang didedikasikan untuk caching. Setiap tingkat atau jenis beban kerja memiliki komputer tertentu yang didedikasikan untuk itu: database mendapat beberapa komputer yang didedikasikan untuk itu, beberapa server web. Jika jenis beban kerja tertentu menyebabkan komputer itu berjalan terlalu panas, maka Anda menambahkan lebih banyak komputer dengan konfigurasi yang sama ke tingkat itu. Namun, tidak semua beban kerja dapat diskalakan dengan begitu mudah - terutama dengan tingkat data Anda biasanya akan mengganti komputer dengan komputer yang lebih besar. Mudah. Jika komputer gagal, bagian dari keseluruhan aplikasi berjalan pada kapasitas yang lebih rendah sampai komputer dapat dipulihkan. Masih terbilang mudah (jika belum tentu menyenangkan).
Sekarang bagaimanapun dunia layanan dan arsitektur perangkat lunak telah berubah. Lebih umum bahwa aplikasi telah mengadopsi desain scale-out. Membangun aplikasi dengan kontainer atau layanan mikro (atau keduanya) adalah hal biasa. Sekarang, meskipun Anda mungkin masih memiliki hanya beberapa komputer, komputer-komputer tersebut tidak hanya menjalankan instans tunggal beban kerja. Mereka bahkan mungkin menjalankan beberapa beban kerja yang berbeda pada saat yang sama. Anda sekarang memiliki lusinan jenis layanan yang berbeda (tidak ada yang mengkonsumsi sumber daya senilai mesin penuh), mungkin ratusan instans yang berbeda dari layanan tersebut. Setiap instans bernama memiliki satu atau beberapa instans atau replika untuk Ketersediaan Tinggi (HA). Tergantung pada ukuran beban kerja tersebut, dan seberapa sibuknya komputer tersebut, Anda mungkin akan mendapati ratusan atau ribuan komputer.
Tiba-tiba mengelola lingkungan Anda tidak sesederhana mengelola beberapa komputer yang didedikasikan untuk jenis beban kerja tunggal. Server Anda virtual dan tidak lagi memiliki nama (Anda telah beralih pola pikir dari hewan peliharaan ke ternak setelah semua). Konfigurasi kurang tentang komputer dan lebih banyak tentang layanan itu sendiri. Perangkat keras yang didedikasikan untuk instans tunggal beban kerja sebagian besar merupakan masa lalu. Layanan itu sendiri telah menjadi sistem terdistribusi kecil yang mencakup beberapa perangkat keras komoditas yang lebih kecil.
Karena aplikasi Anda tidak lagi merupakan serangkaian monolit yang tersebar di beberapa tingkatan, Anda sekarang memiliki lebih banyak kombinasi untuk ditangani. Siapa yang memutuskan jenis beban kerja apa yang dapat berjalan pada perangkat keras mana, atau berapa banyak? Beban kerja mana yang bekerja dengan baik pada perangkat keras yang sama, dan konflik mana? Ketika komputer turun bagaimana kau tahu apa yang berjalan di sana pada komputer itu? Siapa yang bertugas memastikan bahwa beban kerja mulai berjalan lagi? Apakah Anda menunggu komputer (virtual?) kembali atau apakah beban kerja Anda secara otomatis gagal ke komputer lain dan terus berjalan? Apakah intervensi manusia diperlukan? Bagaimana dengan peningkatan di lingkungan ini?
Sebagai pengembang dan operator yang menangani lingkungan ini, kami akan membantu mengelola kerumitan ini. Pesta perekrutan dan mencoba menyembunyikan kompleksitas dengan orang-orang mungkin bukan jawaban yang tepat, jadi apa yang kita lakukan?
Memperkenalkan orkestrator
"Orkestrator" adalah istilah umum untuk perangkat lunak yang membantu administrator mengelola jenis lingkungan ini. Orkestrator adalah komponen yang menerima permintaan seperti "Saya menginginkan lima salinan layanan yang berjalan di lingkungan saya." Mereka mencoba mencocokkan lingkungan dengan kondisi yang diinginkan, apa pun yang terjadi.
Orkestrator (bukan manusia) adalah apa yang mengambil tindakan ketika komputer gagal atau beban kerja berakhir karena beberapa alasan yang tidak terduga. Sebagian besar orkestra melakukan lebih dari sekadar menangani kegagalan. Fitur lain yang mereka miliki adalah mengelola penyebaran baru, menangani peningkatan, dan menangani konsumsi sumber daya dan tata kelola. Semua orkestra pada dasarnya tentang mempertahankan beberapa keadaan konfigurasi yang diinginkan di lingkungan. Anda ingin dapat memberitahu orkestrator apa yang Anda inginkan dan membuatnya melakukan pekerjaan yang berat. Aurora di atas Mesos, Docker Datacenter/Docker Swarm, Kubernetes, dan Service Fabric adalah contoh orkestrator. Orkestrator ini sedang dikembangkan secara aktif untuk memenuhi kebutuhan beban kerja nyata di lingkungan produksi.
Orkestrasi sebagai layanan
Cluster Resource Manager adalah komponen sistem yang menangani orkestrasi dalam Service Fabric. Tugas Cluster Resource Manager dipecah menjadi tiga bagian:
- Menegakkan Aturan
- Mengoptimalkan Lingkungan Anda
- Membantu Proses Lain
Periksa halaman ini untuk video pelatihan untuk memahami cara kerja Azure Resource Manager Kluster:
Apa yang tidak
Dalam aplikasi tingkat N tradisional, selalu ada Load Balancer. Biasanya ini adalah Network Load Balancer (NLB) atau Application Load Balancer (ALB) tergantung di mana ia duduk di tumpukan jaringan. Beberapa penyeimbang muatan berbasis perangkat keras seperti penawaran BigIP F5, yang lain berbasis perangkat lunak seperti NLB Microsoft. Di lingkungan lain, Anda mungkin melihat sesuatu seperti HAProxy, nginx, Istio, atau Envoy dalam peran ini. Dalam arsitektur ini, pekerjaan penyeimbangan beban adalah memastikan beban kerja stateless menerima (kira-kira) jumlah pekerjaan yang sama. Strategi untuk menyeimbangkan beban bervariasi. Beberapa penyeimbang akan mengirim setiap panggilan yang berbeda ke server yang berbeda. Yang lain menyediakan sesi menyematkan / lengket. Penyeimbang yang lebih canggih menggunakan estimasi beban aktual atau pelaporan untuk merutekan panggilan berdasarkan biaya yang diharapkan dan beban alat berat saat ini.
Penyeimbang jaringan atau router pesan mencoba memastikan bahwa tingkat web/pekerja tetap seimbang. Strategi untuk menyeimbangkan tingkat data berbeda dan tergantung pada mekanisme penyimpanan data. Menyeimbangkan tingkat data bergantung pada sharding data, caching, tampilan terkelola, prosedur yang disimpan, dan mekanisme khusus toko lainnya.
Meskipun beberapa strategi ini menarik, Service Fabric Cluster Resource Manager tidak seperti penyeimbang muatan jaringan atau cache. Network Load Balancer menyeimbangkan frontend dengan menyebarkan lalu lintas di frontend. Service Fabric Cluster Resource Manager memiliki strategi yang berbeda. Pada dasarnya, Service Fabric memindahkan layanan ke tempat yang paling masuk akal, mengharapkan lalu lintas atau beban untuk diikuti. Misalnya, mungkin memindahkan layanan ke node yang saat ini dingin karena layanan yang ada di sana tidak melakukan banyak pekerjaan. Node mungkin dingin karena layanan yang hadir dihapus atau dipindahkan ke tempat lain. Sebagai contoh lain, Cluster Resource Manager juga dapat memindahkan layanan dari mesin. Mungkin mesin akan ditingkatkan, atau kelebihan beban karena lonjakan konsumsi oleh layanan yang berjalan di atasnya. Atau, persyaratan sumber daya layanan mungkin telah meningkat. Akibatnya tidak ada sumber daya yang cukup pada mesin ini untuk terus menjalankannya.
Karena Cluster Resource Manager bertanggung jawab untuk memindahkan layanan di sekitar, itu berisi set fitur yang berbeda dibandingkan dengan apa yang akan Anda temukan dalam penyeimbang muatan jaringan. Ini karena penyeimbang muatan jaringan memberikan lalu lintas jaringan ke tempat layanan sudah berada, bahkan jika lokasi itu tidak ideal untuk menjalankan layanan itu sendiri. Service Fabric Cluster Resource Manager menggunakan strategi yang berbeda secara mendasar untuk memastikan bahwa sumber daya dalam klaster dapat digunakan secara efisien.
Langkah berikutnya
- Untuk informasi tentang arsitektur dan alur informasi dalam Pengelola Sumber Daya Klaster, lihat artikel ini
- Cluster Resource Manager memiliki banyak opsi untuk menjelaskan klaster. Untuk mengetahui lebih lanjut tentang metrik, lihat artikel ini tentang menggambarkan klaster Kain Layanan
- Untuk informasi selengkapnya tentang mengonfigurasi layanan, Pelajari tentang mengonfigurasi Layanan
- Metrik adalah cara Service Fabric Cluster Resource Manager mengelola konsumsi dan kapasitas pada klaster. Untuk mempelajari selengkapnya tentang metrik dan cara mengonfigurasinya, lihat artikel ini
- Cluster Resource Manager bekerja dengan kemampuan manajemen Service Fabric. Untuk mengetahui selengkapnya tentang integrasi tersebut, baca artikel ini
- Untuk mengetahui tentang bagaimana Cluster Resource Manager mengelola dan menyeimbangkan beban dalam klaster, lihat artikel tentang menyeimbangkan beban