Mengelola konsumsi sumber daya dan beban dalam Service Fabric dengan metrik

  • Artikel

Metrik adalah sumber daya yang diperhatikan oleh layanan Anda dan yang disediakan oleh simpul dalam kluster. Metrik adalah segala hal yang ingin Anda kelola untuk meningkatkan atau memantau performa layanan Anda. Misalnya, Anda mungkin menonton penggunaan memori untuk mengetahui apakah layanan Anda kelebihan beban. Penggunaan lain adalah untuk mencari tahu apakah layanan dapat dipindahkan di tempat lain tempat memori kurang terkendala untuk mendapatkan performa yang lebih baik.

Berbagai hal seperti Memori, Disk, dan penggunaan CPU adalah contoh metrik. Metrik ini adalah metrik fisik, sumber daya yang sesuai dengan sumber daya fisik pada simpul yang perlu dikelola. Metrik juga dapat berupa (dan umumnya) metrik logika. Metrik logika adalah berbagai hal seperti "MyWorkQueueDepth" atau "MessagesToProcess" atau "TotalRecords". Metrik logika ditentukan aplikasi dan secara tidak langsung sesuai dengan beberapa konsumsi sumber daya fisik. Metrik logika bersifat umum karena mungkin sulit untuk mengukur dan melaporkan konsumsi sumber daya fisik berdasarkan setiap layanan. Kompleksitas untuk mengukur dan melaporkan metrik fisik Anda sendiri juga menjadi alasan Service Fabric menyediakan beberapa metrik default.

Metrik default

Misalnya Anda ingin mulai menulis dan menyebarkan layanan Anda. Pada titik ini, Anda tidak tahu sumber daya fisik atau logika apa yang akan digunakan. Tidak apa-apa! Service Fabric Cluster Resource Manager menggunakan beberapa metrik default ketika tidak ada metrik lain yang ditentukan. Metrik ini adalah:

  • PrimaryCount - jumlah replika Utama pada simpul
  • ReplicaCount - jumlah total replika stateful pada simpul
  • Count - jumlah semua objek layanan (tanpa status dan stateful) pada simpul
Metrik Beban Instans Tanpa Status Beban Sekunder Stateful Beban Utama Stateful Beban
PrimaryCount 0 0 1 Tinggi
ReplicaCount 0 1 1 Medium
Jumlah 1 1 1 Rendah

Untuk beban kerja dasar, metrik default menyediakan distribusi pekerjaan yang layak di kluster. Dalam contoh berikut, mari lihat apa yang terjadi ketika membuat dua layanan dan mengandalkan metrik default untuk menyeimbangkannya. Layanan pertama adalah layanan stateful dengan tiga partisi dan ukuran set replika target yang berjumlah tiga. Layanan kedua adalah layanan tanpa status dengan satu partisi dan jumlah instans tiga.

Berikut yang Anda dapatkan:

Tata Letak Kluster dengan Metrik Default

Yang perlu diperhatikan:

  • Replika utama untuk layanan stateful didistribusikan di beberapa simpul
  • Replika untuk partisi yang sama ada pada simpul yang berbeda
  • Jumlah total primer dan sekunder didistribusikan dalam kluster
  • Jumlah total objek layanan dialokasikan secara merata pada setiap simpul

Bagus!

Metrik default berfungsi dengan baik sebagai permulaan. Namun, metrik default hanya akan digunakan sampai langkah ini. Misalnya: Apa kemungkinan skema partisi yang Anda pilih menghasilkan pemanfaatan yang sempurna oleh semua partisi? Apa kemungkinan bahwa beban untuk layanan tertentu konstan dari waktu ke waktu, atau bahkan sama di beberapa partisi sekarang?

Anda dapat menjalankan hanya dengan metrik default. Namun, melakukannya biasanya berarti bahwa pemanfaatan kluster Anda lebih rendah dan lebih tidak merata daripada yang Anda inginkan. Ini karena metrik default tidak adaptif dan menganggap semuanya setara. Misalnya, Primer yang sibuk dan yang tidak keduanya berkontribusi "1" ke metrik PrimaryCount. Dalam kasus terburuk, hanya menggunakan metrik default juga dapat mengakibatkan simpul yang terlalu terjadwal yang mengakibatkan masalah performa. Jika Anda tertarik untuk memaksimalkan kluster dan menghindari masalah performa, Anda harus menggunakan metrik kustom dan pelaporan beban dinamis.

Metrik kustom

Metrik dikonfigurasi berdasarkan per-bernama-service-instance saat Anda membuat layanan.

Setiap metrik memiliki beberapa properti yang menjelaskannya: nama, beban, dan muatan default.

  • Nama Metrik: Nama metrik. Nama metrik adalah pengidentifikasi unik untuk metrik dalam kluster dari perspektif Resource Manager.

Catatan

Nama metrik kustom tidak boleh berupa nama metrik sistem apa pun, yaitu servicefabric:/_CpuCores atau servicefabric:/_MemoryInMB karena dapat menyebabkan perilaku yang tidak ditentukan. Dimulai dengan Service Fabric versi 9.1, untuk layanan yang ada dengan nama metrik khusus ini, peringatan kesehatan dikeluarkan untuk menunjukkan bahwa nama metrik salah.

  • Bobot: Bobot metrik menentukan seberapa penting metrik ini relatif terhadap metrik lain untuk layanan ini.
  • Beban Default: Beban default diwakili secara berbeda tergantung pada apakah layanan tanpa status atau stateful.
    • Untuk layanan tanpa status, setiap metrik memiliki satu properti bernama DefaultLoad
    • Untuk layanan stateful yang Anda tentukan:
      • PrimaryDefaultLoad: Jumlah default metrik ini yang digunakan layanan ini ketika merupakan Primer
      • SecondaryDefaultLoad: Jumlah default metrik ini yang digunakan layanan ini saat merupakan Sekunder

Catatan

Jika Anda menentukan metrik kustom dan ingin juga menggunakan metrik default, Anda harus secara eksplisit menambahkan kembali metrik default dan menentukan bobot dan nilai untuk metrik tersebut. Hal ini karena Anda harus menentukan hubungan antara metrik default dan metrik kustom Anda. Misalnya, mungkin Anda lebih mementingkan ConnectionCount atau WorkQueueDepth daripada distribusi Primer. Secara default, berat metrik PrimaryCount tinggi, jadi Anda ingin menguranginya menjadi Medium saat Anda menambahkan metrik lain untuk memastikan metrik tersebut diprioritaskan.

Menentukan metrik untuk layanan Anda - contoh

Misalnya, Anda menginginkan konfigurasi berikut:

  • Layanan Anda melaporkan metrik bernama "ConnectionCount"
  • Anda juga ingin menggunakan metrik default
  • Anda telah melakukan beberapa pengukuran dan tahu bahwa biasanya Replika utama layanan tersebut menggunakan 20 unit "ConnectionCount"
  • Sekunder menggunakan 5 unit "ConnectionCount"
  • Anda tahu bahwa "ConnectionCount" adalah metrik terpenting dalam hal mengelola performa layanan khusus ini
  • Anda masih ingin agar replika Primer seimbang. Menyeimbangkan replika primer umumnya adalah ide yang baik apa pun risikonya. Hal ini membantu mencegah hilangnya beberapa simpul atau domain kesalahan berdampak pada sebagian besar replika utama bersama dengannya.
  • Jika tidak, metrik default berfungsi dengan semestinya

Berikut adalah kode yang akan Anda tulis untuk membuat layanan dengan konfigurasi metrik tersebut:

Kode:

StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
StatefulServiceLoadMetricDescription connectionMetric = new StatefulServiceLoadMetricDescription();
connectionMetric.Name = "ConnectionCount";
connectionMetric.PrimaryDefaultLoad = 20;
connectionMetric.SecondaryDefaultLoad = 5;
connectionMetric.Weight = ServiceLoadMetricWeight.High;

StatefulServiceLoadMetricDescription primaryCountMetric = new StatefulServiceLoadMetricDescription();
primaryCountMetric.Name = "PrimaryCount";
primaryCountMetric.PrimaryDefaultLoad = 1;
primaryCountMetric.SecondaryDefaultLoad = 0;
primaryCountMetric.Weight = ServiceLoadMetricWeight.Medium;

StatefulServiceLoadMetricDescription replicaCountMetric = new StatefulServiceLoadMetricDescription();
replicaCountMetric.Name = "ReplicaCount";
replicaCountMetric.PrimaryDefaultLoad = 1;
replicaCountMetric.SecondaryDefaultLoad = 1;
replicaCountMetric.Weight = ServiceLoadMetricWeight.Low;

StatefulServiceLoadMetricDescription totalCountMetric = new StatefulServiceLoadMetricDescription();
totalCountMetric.Name = "Count";
totalCountMetric.PrimaryDefaultLoad = 1;
totalCountMetric.SecondaryDefaultLoad = 1;
totalCountMetric.Weight = ServiceLoadMetricWeight.Low;

serviceDescription.Metrics.Add(connectionMetric);
serviceDescription.Metrics.Add(primaryCountMetric);
serviceDescription.Metrics.Add(replicaCountMetric);
serviceDescription.Metrics.Add(totalCountMetric);

await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ConnectionCount,High,20,5”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

Catatan

Contoh di atas dan dokumen lainnya menjelaskan pengelolaan metrik berdasarkan layanan per nama. Ada juga dapat menentukan metrik untuk layanan Anda di tingkat jenis layanan. Hal ini dapat dicapai dengan menentukannya dalam manifes layanan Anda. Menentukan metrik tingkat jenis tidak disarankan karena beberapa alasan. Alasan pertama adalah bahwa nama metrik sering spesifik lingkungan. Kecuali ada kontrak yang tegas, Anda tidak dapat memastikan bahwa metrik "Cores" dalam satu lingkungan bukanlah "MiliCores" atau "CoReS" di lingkungan lain. Jika metrik Anda ditentukan dalam manifes, Anda harus membuat manifes baru per lingkungan. Ini biasanya menyebabkan menjamurnya manifes yang berbeda dengan hanya perbedaan kecil, yang dapat menyebabkan kesulitan manajemen.

Beban metrik biasanya ditetapkan berdasarkan per instans layanan bernama. Misalnya, Anda membuat satu contoh layanan untuk CustomerA yang berencana menggunakannya hanya dengan ringan. Misalnya, Anda juga membuat instans lain untuk CustomerB yang memiliki beban kerja yang lebih besar. Dalam hal ini, Anda mungkin ingin mengubah beban default untuk layanan tersebut. Jika Anda memiliki metrik dan beban yang ditentukan melalui manifes dan Anda ingin mendukung skenario ini, dibutuhkan berbagai jenis aplikasi dan layanan untuk setiap pelanggan. Nilai yang ditentukan pada waktu pembuatan layanan akan menggantikan nilai yang ditentukan dalam manifes, sehingga Anda dapat menggunakannya untuk mengatur default tertentu. Namun, melakukan hal itu menyebabkan nilai yang dinyatakan dalam manifes tidak cocok dengan yang sebenarnya dijalankan oleh layanan. Hal ini dapat menyebabkan kebingungan.

Sebagai pengingat: jika Anda hanya ingin menggunakan metrik default, Anda tidak perlu menyentuh koleksi metrik sama sekali atau melakukan sesuatu yang istimewa saat membuat layanan Anda. Metrik default akan digunakan secara otomatis saat tidak ada orang lain yang didefinisikan.

Sekarang, mari pelajari pengaturan ini secara lebih detail dan bahas tentang perilaku yang dipengaruhinya.

Muat

Inti dari mendefinisikan metrik adalah untuk mewakili beberapa beban. Beban adalah berapa banyak metrik yang diberikan dikonsumsi oleh beberapa instans layanan atau replika pada simpul tertentu. Muat dapat dikonfigurasi di hampir semua titik. Contohnya:

  • Muat dapat didefinisikan ketika layanan dibuat. Jenis konfigurasi beban ini disebut beban default.
  • Informasi metrik, termasuk beban default, untuk layanan dapat diperbarui setelah layanan dibuat. Pembaruan metrik ini dilakukan dengan memperbarui layanan.
  • Beban untuk partisi tertentu dapat direset ke nilai default untuk layanan tersebut. Pembaruan metrik ini disebut mengatur ulang beban partisi.
  • Beban dapat dilaporkan berdasarkan objek per layanan, secara dinamis selama runtime. Pembaruan metrik ini disebut beban pelaporan.
  • Beban untuk replika atau instans partisi juga dapat diperbarui dengan melaporkan nilai beban melalui panggilan Fabric API. Pembaruan metrik ini disebut beban pelaporan untuk partisi.

Semua strategi ini dapat digunakan dalam layanan yang sama selama masa pakainya.

Beban default

Beban default artinya jumlah metrik yang digunakan setiap objek layanan (instans tanpa status atau replika stateful) dari layanan ini. Cluster Resource Manager menggunakan nomor ini untuk memuat objek layanan hingga menerima informasi lain, seperti laporan beban dinamis. Untuk layanan yang lebih sederhana, beban default adalah definisi statis. Beban default tidak pernah diperbarui dan digunakan untuk masa pakai layanan. Beban default sangat cocok untuk skenario perencanaan kapasitas simpel di mana sejumlah sumber daya tertentu ditujukan khusus untuk beban kerja yang berbeda dan tidak berubah.

Catatan

Untuk informasi selengkapnya tentang manajemen kapasitas dan menentukan kapasitas untuk simpul di kluster Anda, harap lihat artikel ini.

Cluster Resource Manager memungkinkan layanan yang dinyatakan untuk menentukan beban default yang berbeda untuk Primer dan Sekundernya. Layanan tanpa status hanya dapat menentukan satu nilai yang berlaku untuk semua instans. Untuk layanan stateful, beban default untuk replika Primer dan Sekunder biasanya berbeda karena replika melakukan berbagai jenis pekerjaan dalam setiap peran. Misalnya, Primer biasanya melayani bacaan dan tulisan, dan menangani sebagian besar beban komputasi, sementara sekunder tidak. Biasanya beban default untuk replika primer lebih tinggi dari beban default untuk replika sekunder. Angka nyatanya harus tergantung pada pengukuran Anda sendiri.

Beban dinamis

Misalnya, Anda telah menjalankan layanan untuk sementara waktu. Dengan beberapa pemantauan, Anda telah memperhatikan bahwa:

  1. Beberapa partisi atau instans layanan tertentu menggunakan lebih banyak sumber daya daripada yang lain
  2. Beberapa layanan memiliki beban yang bervariasi dari waktu ke waktu.

Ada banyak hal yang dapat menyebabkan jenis fluktuasi beban ini. Misalnya, layanan atau partisi yang berbeda dikaitkan dengan pelanggan yang berbeda dengan persyaratan yang berbeda. Beban juga bisa berubah karena jumlah pekerjaan yang dilakukan layanan bervariasi sepanjang hari. Terlepas dari alasannya, biasanya tidak ada satu nomor yang dapat Anda gunakan untuk default. Hal ini terutama berlaku jika Anda ingin mendapatkan pemanfaatan terbanyak dari kluster. Nilai apa pun yang Anda pilih untuk beban default terkadang salah. Beban default yang salah mengakibatkan Cluster Resource Manager baik di atas atau di bawah mengalokasikan sumber daya. Akibatnya, Anda memiliki simpul yang sering atau jarang dimanfaatkan meskipun Cluster Resource Manager menganggap kluster seimbang. Beban default masih bagus karena mereka memberikan beberapa informasi untuk penempatan awal, tetapi mereka bukan cerita lengkap untuk beban kerja nyata. Untuk secara akurat menangkap perubahan persyaratan sumber daya, Cluster Resource Manager memungkinkan setiap objek layanan untuk memperbarui bebannya sendiri selama runtime. Hal ini disebut pelaporan beban dinamis.

Laporan beban dinamis memungkinkan replika atau instans untuk menyesuaikan alokasi/beban metrik yang dilaporkan selama masa pakainya. Replika layanan atau instans yang jarang digunakan dan tidak melakukan pekerjaan apa pun biasanya akan melaporkan sedikit penggunaan metrik yang diberikan. Replika atau instans yang sering digunakan akan melaporkan penggunaan yang lebih banyak.

Melaporkan beban per replika atau instans memungkinkan Cluster Resource Manager untuk mengatur ulang objek layanan individual dalam kluster. Mengatur ulang layanan membantu memastikan bahwa mereka mendapatkan sumber daya yang mereka butuhkan. Layanan yang sibuk secara efektif dapat "mengklaim ulang" sumber daya dari replika atau instans lain yang saat ini dingin atau melakukan lebih sedikit pekerjaan.

Dalam Layanan yang Andal, kode untuk melaporkan beban secara dinamis terlihat seperti ini:

Kode:

this.Partition.ReportLoad(new List<LoadMetric> { new LoadMetric("CurrentConnectionCount", 1234), new LoadMetric("metric1", 42) });

Layanan dapat melaporkan salah satu metrik yang ditentukan untuknya pada waktu pembuatan. Jika laporan layanan dimuat untuk metrik yang tidak dikonfigurasi untuk digunakan, Service Fabric mengabaikan laporan tersebut. Jika ada metrik lain yang dilaporkan pada saat yang sama yang valid, laporan tersebut akan diterima. Kode layanan dapat mengukur dan melaporkan semua metrik yang diketahuinya caranya, dan operator dapat menentukan konfigurasi metrik yang akan digunakan tanpa harus mengubah kode layanan.

Melaporkan beban untuk partisi

Bagian sebelumnya menjelaskan bagaimana replika layanan atau instans melaporkan dimuat sendiri. Ada opsi tambahan untuk melaporkan pemuatan replika atau instans partisi secara dinamis melalui API Service Fabric. Saat melaporkan beban untuk partisi, Anda dapat melaporkan untuk beberapa partisi sekaligus.

Laporan tersebut akan digunakan dengan cara yang sama persis seperti laporan beban yang berasal dari replika atau instans itu sendiri. Nilai yang dilaporkan akan berlaku hingga nilai beban baru dilaporkan, baik oleh replika maupun instans atau dengan melaporkan nilai beban baru untuk partisi.

Dengan API ini, ada beberapa cara untuk memperbarui beban di kluster:

  • Partisi layanan stateful dapat memperbarui beban replika utamanya.
  • Baik layanan tanpa status maupun stateful dapat memperbarui beban semua replika atau instans sekundernya.
  • Layanan tanpa status dan stateful dapat memperbarui beban replika atau instans tertentu pada simpul.

Anda juga dapat menggabungkan pembaruan tersebut per partisi pada saat yang sama. Kombinasi pembaruan beban untuk partisi tertentu harus ditentukan melalui objek PartitionMetricLoadDescription, yang dapat berisi daftar pembaruan beban yang sesuai seperti yang ditunjukkan pada contoh di bawah ini. Pembaruan beban diwakili melalui objek MetricLoadDescription, yang dapat berisi nilai beban saat ini atau diprediksi untuk metrik, yang ditentukan dengan nama metrik.

Catatan

Nilai beban metrik yang diprediksi saat ini merupakan fitur pratinjau. Fitur pratinjau memungkinkan nilai beban yang diprediksi untuk dilaporkan dan digunakan di sisi Service Fabric, tetapi fitur tersebut saat ini tidak diaktifkan.

Memperbarui beban untuk beberapa partisi dimungkinkan dengan satu panggilan API, dalam hal ini output akan berisi respons per partisi. Jika pembaruan partisi gagal diterapkan karena alasan apa pun, pembaruan untuk partisi tersebut akan dilewati, dan kode kesalahan yang sesuai untuk partisi yang ditargetkan akan disediakan:

  • PartitionNotFound - ID partisi yang ditentukan tidak ada.
  • ReconfigurationPending - Partisi saat ini sedang dikonfigurasi ulang.
  • InvalidForStatelessServices - Upaya dilakukan untuk mengubah beban replika utama untuk partisi milik layanan tanpa status.
  • ReplicaDoesNotExist - Replika atau instans sekunder tidak ada pada simpul tertentu.
  • InvalidOperation - Dapat terjadi dalam dua kasus: memperbarui beban untuk partisi yang termasuk dalam aplikasi Sistem atau memperbarui beban yang diprediksi tidak diaktifkan.

Jika beberapa kesalahan tersebut muncul kembali, Anda dapat memperbarui input untuk partisi tertentu dan mencoba lagi memperbaruinya.

Kode:

Guid partitionId = Guid.Parse("53df3d7f-5471-403b-b736-bde6ad584f42");
string metricName0 = "CustomMetricName0";
List<MetricLoadDescription> newPrimaryReplicaLoads = new List<MetricLoadDescription>()
{
    new MetricLoadDescription(metricName0, 100)
};

string nodeName0 = "NodeName0";
List<MetricLoadDescription> newSpecificSecondaryReplicaLoads = new List<MetricLoadDescription>()
{
    new MetricLoadDescription(metricName0, 200)
};

OperationResult<UpdatePartitionLoadResultList> updatePartitionLoadResults =
    await this.FabricClient.UpdatePartitionLoadAsync(
        new UpdatePartitionLoadQueryDescription
        {
            PartitionMetricLoadDescriptionList = new List<PartitionMetricLoadDescription>()
            {
                new PartitionMetricLoadDescription(
                    partitionId,
                    newPrimaryReplicaLoads,
                    new List<MetricLoadDescription>(),
                    new List<ReplicaMetricLoadDescription>()
                    {
                        new ReplicaMetricLoadDescription(nodeName0, newSpecificSecondaryReplicaLoads)
                    })
            }
        },
        this.Timeout,
        cancellationToken);

Dengan contoh ini, Anda akan melakukan pembaruan beban terakhir yang dilaporkan untuk partisi 53df3d7f-5471-403b-b736-bde6ad584f42. Beban replika utama untuk metrik CustomMetricName0 akan diperbarui dengan nilai 100. Pada saat yang sama, beban untuk metrik yang sama untuk replika sekunder tertentu yang terletak di simpul NodeName0, akan diperbarui dengan nilai 200.

Memperbarui konfigurasi metrik layanan

Daftar metrik yang terkait dengan layanan, dan properti metrik tersebut dapat diperbarui secara dinamis saat layanan digunakan. Hal ini memungkinkan eksperimen dan fleksibilitas. Beberapa contoh momen saat berguna adalah:

  • menonaktifkan metrik dengan laporan bug untuk layanan tertentu
  • mengonfigurasi ulang bobot metrik berdasarkan perilaku yang diinginkan
  • mengaktifkan metrik baru hanya setelah kode telah digunakan dan divalidasi melalui mekanisme lain
  • mengubah beban default untuk layanan berdasarkan perilaku dan konsumsi yang diamati

API utama untuk mengubah konfigurasi metrik ada di FabricClient.ServiceManagementClient.UpdateServiceAsync C# dan Update-ServiceFabricService di PowerShell. Informasi apa pun yang Anda tentukan dengan API ini akan segera menggantikan informasi metrik yang ada untuk layanan ini.

Mencampur nilai beban default dan laporan beban dinamis

Beban default dan beban dinamis dapat digunakan untuk layanan yang sama. Saat layanan menggunakan laporan beban default dan beban dinamis, beban default berfungsi sebagai perkiraan hingga laporan dinamis muncul. Beban default bagus karena memberi Cluster Resource Manager beban untuk dikerjakan. Beban default memungkinkan Cluster Resource Manager menempatkan objek layanan di lokasi yang baik saat dibuat. Jika tidak ada informasi beban default yang disediakan, penempatan layanan secara efektif acak. Ketika laporan beban tiba nanti penempatan acak awal sering salah dan Cluster Resource Manager harus memindahkan layanan.

Mari kita ambil contoh kami sebelumnya dan lihat apa yang terjadi ketika kita menambahkan beberapa metrik kustom dan pelaporan beban dinamis. Dalam contoh ini, kita menggunakan "MemoryInMb" sebagai contoh metrik.

Catatan

Memori adalah salah satu metrik sistem yang dapat diatur oleh Service Fabric Layanan, dan melaporkannya sendiri biasanya sulit. Kami tidak mengharapkan Anda untuk melaporkan penggunaan Memori; Memori digunakan di sini sebagai bantuan untuk mempelajari kemampuan Cluster Resource Manager.

Anggap saja kita awalnya membuat layanan stateful dengan perintah berikut:

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("MemoryInMb,High,21,11”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

Sebagai pengingat, sintaks ini adalah ("MetricName, MetricWeight, PrimaryDefaultLoad, SecondaryDefaultLoad").

Mari kita lihat seperti apa tata letak kluster yang mungkin terlihat:

Kluster Seimbang dengan metrik Default dan Kustom

Beberapa hal yang perlu diperhatikan:

  • Replika sekunder dalam partisi masing-masing dapat memiliki beban mereka sendiri
  • Secara keseluruhan metrik terlihat seimbang. Untuk Memori, rasio antara beban maksimum dan minimum adalah 1,75 (simpul dengan beban terbanyak adalah N3, paling sedikit adalah N2, dan 28/16 = 1,75).

Ada beberapa hal yang masih perlu kita jelaskan:

  • Apa yang menentukan apakah rasio 1,75 masuk akal atau tidak? Bagaimana Cluster Resource Manager tahu apakah itu cukup baik atau jika ada lebih banyak pekerjaan yang harus dilakukan?
  • Kapan penyeimbangan terjadi?
  • Apa artinya Memori memiliki bobot "Tinggi"?

Bobot metrik

Melacak metrik yang sama di berbagai layanan adalah penting. Pandangan global itulah yang memungkinkan Cluster Resource Manager untuk melacak konsumsi dalam kluster, menyeimbangkan konsumsi di seluruh simpul, dan memastikan bahwa simpul tidak melebihi kapasitas. Namun, layanan mungkin memiliki pandangan yang berbeda tentang pentingnya metrik yang sama. Juga, dalam kluster dengan banyak metrik dan banyak layanan, solusi yang sangat seimbang mungkin tidak ada untuk semua metrik. Bagaimana Cluster Resource Manager harus menangani situasi ini?

Bobot metrik memungkinkan Cluster Resource Manager memutuskan cara menyeimbangkan kluster ketika tidak ada jawaban yang sempurna. Bobot metrik juga memungkinkan Cluster Resource Manager untuk menyeimbangkan layanan tertentu secara berbeda. Metrik dapat memiliki empat tingkat berat yang berbeda: Nol, Rendah, Sedang, dan Tinggi. Metrik dengan berat Nol tidak berkontribusi apa pun saat mempertimbangkan apakah semuanya seimbang atau tidak. Namun, bebannya masih berkontribusi pada manajemen kapasitas. Metrik dengan berat Nol masih berguna dan sering digunakan sebagai bagian dari perilaku layanan dan pemantauan performa. Artikel ini menyediakan informasi selengkapnya tentang penggunaan metrik untuk pemantauan dan diagnostik layanan Anda.

Dampak nyata dari bobot metrik yang berbeda dalam kluster adalah bahwa Cluster Resource Manager menghasilkan solusi yang berbeda. Bobot metrik memberi tahu Cluster Resource Manager bahwa metrik tertentu lebih penting daripada yang lain. Ketika tidak ada solusi sempurna, Cluster Resource Manager dapat lebih memilih solusi yang menyeimbangkan metrik tertimbang yang lebih tinggi dengan lebih baik. Jika layanan menganggap metrik tertentu tidak penting, mungkin disebabkan karena menemukan penggunaan metrik yang tidak seimbang. Hal ini memungkinkan layanan lain mendapatkan distribusi yang merata dari beberapa metrik yang penting.

Mari lihat contoh beberapa laporan beban dan bagaimana bobot metrik yang berbeda menghasilkan alokasi yang berbeda dalam kluster. Dalam contoh ini, kami melihat bahwa mengalihkan bobot relatif metrik menyebabkan Cluster Resource Manager membuat pengaturan layanan yang berbeda.

Contoh Bobot Metrik dan Dampaknya pada Solusi Penyeimbangan

Dalam contoh ini, ada empat layanan yang berbeda, semua melaporkan nilai yang berbeda untuk dua metrik yang berbeda, MetricA dan MetricB. Dalam satu kasus, semua layanan mendefinisikan MetricA adalah yang paling penting (Berat = Tinggi) dan MetricB sebagai tidak penting (Berat = Rendah). Akibatnya, kami melihat bahwa Cluster Resource Manager menempatkan layanan sehingga MetricA lebih seimbang daripada MetricB. "Lebih seimbang" berarti Bahwa MetricA memiliki tingkat yang lebih rendah memiliki simpangan baku yang lebih rendah daripada MetricB. Dalam kasus kedua, kami membalikkan bobot metrik. Akibatnya, Cluster Resource Manager menukar layanan A dan B untuk menghasilkan alokasi di mana MetricB lebih seimbang daripada MetricA.

Catatan

Bobot metrik menentukan bagaimana Cluster Resource Manager harus menyeimbangkan, tetapi tidak ketika penyeimbangan harus terjadi. Untuk informasi selengkapnya tentang penyeimbangan, lihat artikel ini

Bobot metrik global

Misalnya, ServiceA mendefinisikan MetricA sebagai berat Tinggi, dan ServiceB menetapkan bobot untuk MetricA ke Rendah atau Nol. Berapa berat sebenarnya yang akhirnya bisa digunakan?

Ada beberapa bobot yang dilacak untuk setiap metrik. Bobot pertama adalah yang didefinisikan untuk metrik saat layanan dibuat. Bobot lainnya adalah bobot global, yang dihitung secara otomatis. Cluster Resource Manager menggunakan kedua bobot ini saat menilai solusi. Memperhitungkan kedua bobot ini sangatlah penting. Hal ini memungkinkan Cluster Resource Manager menyeimbangkan setiap layanan sesuai dengan prioritasnya sendiri, dan juga memastikan bahwa kluster secara keseluruhan dialokasikan dengan benar.

Apa yang akan terjadi jika Cluster Resource Manager tidak peduli dengan keseimbangan global dan lokal? Sangat mudah untuk membangun solusi yang seimbang secara global, tetapi yang menghasilkan keseimbangan sumber daya yang buruk untuk layanan individu. Dalam contoh berikut, mari kita lihat layanan yang dikonfigurasi hanya dengan metrik default, dan lihat apa yang terjadi ketika hanya saldo global yang dipertimbangkan:

Dampak Global Only Solution

Dalam contoh teratas hanya berdasarkan keseimbangan global, kluster secara keseluruhan memang seimbang. Semua node memiliki jumlah primer yang sama dan replika total angka yang sama. Namun, jika Anda melihat dampak aktual dari alokasi ini, itu tidak begitu baik: hilangnya simpul apa pun berdampak pada beban kerja tertentu secara tidak proporsional, karena mengeluarkan semua primernya. Misalnya, jika simpul pertama gagal, tiga primer untuk tiga partisi yang berbeda dari layanan Circle semuanya akan hilang. Sebaliknya, layanan Triangle dan Hexagon kehilangan replika dari partisinya. Hal ini tidak menyebabkan gangguan, selain harus memulihkan replika yang tidak berfungsi.

Dalam contoh di bawah, Cluster Resource Manager telah mendistribusikan replika berdasarkan saldo global dan per layanan. Saat menghitung skor solusi, kluster memberikan sebagian besar berat untuk solusi global, dan porsi (dapat dikonfigurasi) untuk layanan individu. Keseimbangan global untuk metrik dihitung berdasarkan rata-rata bobot metrik dari setiap layanan. Setiap layanan seimbang sesuai dengan bobot metrik yang ditentukan sendiri. Hal ini memastikan bahwa layanan seimbang dalam diri mereka sendiri sesuai dengan kebutuhan mereka sendiri. Akibatnya, jika node pertama yang sama gagal, kegagalan didistribusikan di semua partisi semua layanan. Dampaknya ke masing-masing sama.

Langkah berikutnya

  • Untuk informasi selengkapnya tentang mengonfigurasi layanan, Pelajari cara mengonfigurasi Layanan(service-fabric-cluster-resource-manager-configure-services.md)
  • Mendefinisikan Metrik Defragmentasi adalah salah satu cara untuk mengonsolidasikan beban pada simpul sebagai ganti menyebarkannya. Untuk mempelajari cara mengonfigurasi defragmentasi, lihat artikel ini
  • Untuk mengetahui cara Cluster Resource Manager mengelola dan menyeimbangkan beban dalam kluster, lihat artikel tentang menyeimbangkan beban
  • Mulai dari awal dan dapatkan Pengantar Service Fabric Cluster Resource Manager
  • Movement Cost adalah salah satu cara memberi sinyal kepada Cluster Resource Manager bahwa layanan tertentu lebih mahal untuk dipindahkan daripada layanan lain. Untuk mempelajari selengkapnya tentang biaya gerakan, lihat artikel ini