Tata kelola sumber daya
Ketika Anda menjalankan beberapa layanan pada node atau kluster yang sama, ada kemungkinan bahwa satu layanan mungkin menggunakan lebih banyak sumber daya, yang menghabiskan sumber daya pada layanan lain dalam prosesnya. Masalah ini disebut sebagai masalah "tetangga yang berisik". Azure Service Fabric memungkinkan pengembang mengontrol perilaku ini dengan menentukan permintaan dan batasan per layanan untuk membatasi penggunaan sumber daya.
Sebelum Anda melanjutkan artikel ini, sebaiknya pelajari model aplikasi Service Fabric dan model hosting Service Fabric.
Metrik tata kelola sumber daya
Tata kelola sumber daya didukung dalam Service Fabric sesuai dengan paket layanan. Sumber daya yang ditugaskan ke paket layanan dapat dibagi lebih lanjut antara paket kode. Service Fabric mendukung tata kelola CPU dan memori per paket layanan, dengan dua metrik bawaan:
CPU (nama metrik
servicefabric:/_CpuCores): Core logis yang tersedia di mesin host. Semua core di semua simpul memiliki beban yang sama.Memori (nama metrik
servicefabric:/_MemoryInMB): Memori diekspresikan dalam megabyte, dan memetakan memori fisik yang tersedia di mesin.
Untuk kedua metrik ini, Cluster Resource Manager (CRM) melacak total kapasitas kluster, beban pada setiap simpul dalam kluster, dan sisa sumber daya dalam kluster. Kedua metrik ini setara dengan metrik pengguna atau kustom lainnya.
Catatan
Nama metrik kustom tidak boleh berupa salah satu dari dua nama metrik ini karena akan menyebabkan perilaku yang tidak terdefinisi.
Semua fitur yang ada dapat digunakan dengannya:
- Kluster ini dapat diseimbangkan sesuai dengan dua metrik ini (perilaku default).
- Kluster ini dapat didefragmentasi sesuai dengan dua metrik ini.
- Saat menjelaskan kluster, kapasitas buffer dapat diatur untuk dua metrik ini.
Catatan
Pelaporan beban dinamis tidak didukung untuk metrik ini; beban untuk metrik ini didefinisikan pada waktu pembuatan.
Mekanisme tata kelola sumber daya
Dimulai dengan versi 7.2, runtime Service Fabric mendukung spesifikasi permintaan dan batasan untuk sumber daya CPU dan memori.
Catatan
Versi runtime Service Fabric yang lebih lama dari 7.2 hanya mendukung model di mana satu nilai berfungsi baik sebagai permintaan dan batas untuk sumber daya tertentu (CPU atau memori). Ini digambarkan sebagai spesifikasi RequestsOnly dalam dokumen ini.
Permintaan: Nilai permintaan CPU dan memori mewakili beban yang digunakan oleh Cluster Resource Manager (CRM) untuk metrik
servicefabric:/_CpuCoresdanservicefabric:/_MemoryInMB. Dengan kata lain, CRM menganggap konsumsi sumber daya layanan sama dengan nilai permintaannya dan menggunakan nilai-nilai ini saat membuat keputusan penempatan.Batas: Nilai batas CPU dan Memori menunjukkan batas sumber daya aktual yang diterapkan saat proses atau kontainer diaktifkan pada simpul.
Service Fabric memungkinkan RequestsOnly, LimitsOnly dan spesifikasi RequestsAndLimits untuk CPU dan memori.
- Ketika spesifikasi RequestsOnly digunakan, kain layanan juga menggunakan nilai permintaan sebagai batas.
- Ketika spesifikasi LimitsOnly digunakan, service fabric menganggap nilai permintaan adalah 0.
- Saat spesifikasi RequestsAndLimits digunakan, nilai batas harus lebih besar dari atau sama dengan nilai permintaan.
Untuk lebih memahami mekanisme tata kelola sumber daya, mari kita lihat contoh skenario penempatan dengan spesifikasi RequestsOnly untuk sumber daya CPU (mekanisme untuk tata kelola memori setara). Pertimbangkan simpul dengan dua core CPU dan dua paket layanan yang akan ditempatkan di atasnya. Paket layanan pertama yang akan ditempatkan, hanya terdiri dari satu paket kode kontainer dan hanya menentukan permintaan satu core CPU. Paket layanan kedua yang akan ditempatkan, hanya terdiri dari satu paket kode berbasis proses dan juga hanya menentukan permintaan satu core CPU. Karena kedua paket layanan memiliki spesifikasi RequestsOnly, nilai batasnya diatur ke nilai permintaannya.
Pertama paket layanan berbasis kontainer yang meminta satu core CPU ditempatkan pada node. Runtime mengaktifkan kontainer dan mengatur batas CPU ke satu core. Kontainer tidak akan dapat menggunakan lebih dari satu core.
Selanjutnya, paket layanan berbasis proses yang meminta satu core CPU ditempatkan pada node. Runtime mengaktifkan proses layanan dan menetapkan batas CPU-nya ke satu core.
Pada titik ini, jumlah permintaan sama dengan kapasitas node. CRM tidak akan menempatkan lagi kontainer atau proses layanan dengan permintaan CPU pada node ini. Pada node, proses dan kontainer berjalan dengan satu inti masing-masing dan tidak akan bersaing satu sama lain untuk CPU.
Sekarang mari kita kunjungi kembali contoh kami dengan spesifikasi RequestsAndLimits. Kali ini paket layanan berbasis kontainer menentukan permintaan satu inti CPU dan batas dua core CPU. Paket layanan berbasis proses menentukan permintaan dan batas satu core CPU.
- Pertama paket layanan berbasis kontainer ditempatkan pada simpul. Runtime mengaktifkan kontainer dan mengatur batas CPU ke dua core. Kontainer tidak akan dapat menggunakan lebih dari dua core.
- Selanjutnya, paket layanan berbasis proses ditempatkan pada simpul. Runtime mengaktifkan proses layanan dan menetapkan batas CPU-nya ke satu core.
Pada titik ini, jumlah permintaan CPU paket layanan yang ditempatkan pada simpul sama dengan kapasitas CPU simpul. CRM tidak akan menempatkan lagi kontainer atau proses layanan dengan permintaan CPU pada node ini. Namun, pada simpul, jumlah batas (dua core untuk kontainer + satu core untuk proses) melebihi kapasitas dua core. Jika kontainer dan proses meledak pada saat yang sama, ada kemungkinan pertikaian untuk sumber daya CPU. Ketidakcocokan tersebut akan dikelola oleh OS yang mendasar untuk platform. Untuk contoh ini, kontainer dapat meledak hingga dua inti CPU, sehingga permintaan proses satu inti CPU tidak dijamin.
Catatan
Seperti yang diilustrasikan dalam contoh sebelumnya, nilai permintaan untuk CPU dan memori tidak mengarah pada reservasi sumber daya pada simpul. Nilai-nilai ini mewakili konsumsi sumber daya yang dipertimbangkan Cluster Resource Manager saat membuat keputusan penempatan. Nilai batas mewakili batas sumber daya aktual yang diterapkan saat proses atau kontainer diaktifkan pada simpul.
Ada beberapa situasi di mana mungkin ada persaingan untuk CPU. Dalam situasi ini, proses dan kontainer dari contoh kami mungkin mengalami masalah tetangga yang bising:
Mencampur layanan dan kontainer yang diatur dan tidak diatur: Jika pengguna membuat layanan tanpa tata kelola sumber daya yang ditentukan, runtime melihatnya sebagai tidak menggunakan sumber daya, dan dapat menempatkannya pada simpul dalam contoh kami. Dalam hal ini, proses baru ini secara efektif menggunakan beberapa CPU dengan mengorbankan layanan yang sudah berjalan pada simpul. Ada dua solusi untuk masalah ini. Jangan mencampur layanan yang diatur dan tidak diatur pada kluster yang sama, atau gunakan batasan penempatan sehingga kedua jenis layanan ini tidak berakhir pada serangkaian simpul yang sama.
Ketika proses lain dimulai pada simpul, di luar Service Fabric (misalnya, layanan OS) : Dalam situasi ini, proses di luar Service Fabric juga bersaing untuk CPU dengan layanan yang ada. Solusi untuk masalah ini adalah mengatur kapasitas simpul dengan benar untuk memperhitungkan overhead OS, seperti yang ditunjukkan pada bagian berikutnya.
Ketika permintaan tidak sama dengan batas: Seperti yang dijelaskan dalam contoh RequestsAndLimits sebelumnya, permintaan tidak mengarah pada reservasi sumber daya pada simpul. Ketika layanan dengan batas yang lebih besar dari permintaan ditempatkan pada simpul, layanan dapat menggunakan sumber daya (jika tersedia) hingga batasnya. Dalam kasus seperti itu, layanan lain pada simpul mungkin tidak dapat menggunakan sumber daya hingga nilai permintaan mereka.
Penyiapan kluster untuk mengaktifkan tata kelola sumber daya
Ketika sebuah node dimulai dan bergabung dengan kluster, Service Fabric mendeteksi jumlah memori yang tersedia dan jumlah core yang tersedia, dan kemudian mengatur kapasitas simpul untuk dua sumber daya tersebut.
Untuk meninggalkan ruang buffer untuk sistem operasi, dan untuk proses lain yang mungkin berjalan pada simpul, Service Fabric hanya menggunakan 80% dari sumber daya yang tersedia pada simpul. Persentase ini dapat dikonfigurasi, dan dapat diubah dalam manifes kluster.
Berikut adalah contoh cara menginstruksikan Service Fabric untuk menggunakan 50% CPU yang tersedia dan 70% memori yang tersedia:
<Section Name="PlacementAndLoadBalancing">
<!-- 0.0 means 0%, and 1.0 means 100%-->
<Parameter Name="CpuPercentageNodeCapacity" Value="0.5" />
<Parameter Name="MemoryPercentageNodeCapacity" Value="0.7" />
</Section>
Untuk sebagian besar pelanggan dan skenario, deteksi otomatis kapasitas simpul untuk CPU dan memori adalah konfigurasi yang direkomendasikan (deteksi otomatis diaktifkan secara default). Namun, jika memerlukan pengaturan manual penuh kapasitas simpul, Anda dapat mengonfigurasinya per jenis node menggunakan mekanisme untuk menggambarkan simpul di kluster. Berikut adalah contoh cara mengatur jenis simpul dengan empat core dan memori 2 GB:
<NodeType Name="MyNodeType">
<Capacities>
<Capacity Name="servicefabric:/_CpuCores" Value="4"/>
<Capacity Name="servicefabric:/_MemoryInMB" Value="2048"/>
</Capacities>
</NodeType>
Ketika deteksi otomatis sumber daya yang tersedia diaktifkan, dan kapasitas node ditentukan secara manual dalam manifes kluster, Service Fabric memeriksa bahwa simpul memiliki sumber daya yang cukup untuk mendukung kapasitas yang telah ditentukan pengguna:
Jika kapasitas node yang didefinisikan dalam manifes kurang dari atau sama dengan sumber daya yang tersedia pada simpul, Service Fabric menggunakan kapasitas yang ditentukan dalam manifes.
Jika kapasitas node yang didefinisikan dalam manifes lebih besar dari sumber daya yang tersedia, Service Fabric menggunakan sumber daya yang tersedia sebagai kapasitas simpul.
Deteksi otomatis sumber daya yang tersedia dapat dimatikan jika tidak diperlukan. Untuk menonaktifkannya, ubah pengaturan berikut:
<Section Name="PlacementAndLoadBalancing">
<Parameter Name="AutoDetectAvailableResources" Value="false" />
</Section>
Untuk mendapatkan performa optimal, pengaturan berikut juga harus diaktifkan dalam manifes kluster:
<Section Name="PlacementAndLoadBalancing">
<Parameter Name="PreventTransientOvercommit" Value="true" />
<Parameter Name="AllowConstraintCheckFixesDuringApplicationUpgrade" Value="true" />
</Section>
Penting
Dimulai dengan Service Fabric versi 7.0, kami telah memperbarui aturan tentang bagaimana kapasitas sumber daya simpul dihitung dalam kasus di mana pengguna secara manual menyediakan nilai untuk kapasitas sumber daya simpul. Mari pertimbangkan skenario berikut:
- Ada total 10 core CPU pada simpul
- SF dikonfigurasi untuk menggunakan 80% dari total sumber daya untuk layanan pengguna (pengaturan default), yang meninggalkan buffer 20% untuk layanan lain yang berjalan pada simpul (termasuk layanan sistem Service Fabric)
- Pengguna memutuskan untuk secara manual mengganti kapasitas sumber daya simpul untuk metrik core CPU, dan mengaturnya ke 5 core
Kami telah mengubah aturan tentang bagaimana kapasitas yang tersedia untuk layanan pengguna Service Fabric dihitung dengan cara berikut:
- Sebelum Service Fabric 7.0, kapasitas yang tersedia untuk layanan pengguna akan dihitung menjadi 5 core (buffer kapasitas 20% diabaikan)
- Dimulai dengan Service Fabric 7.0, kapasitas yang tersedia untuk layanan pengguna akan dihitung menjadi 4 core (buffer kapasitas 20% tidak diabaikan)
Tentukan tata kelola sumber daya
Permintaan dan batasan tata kelola sumber daya ditentukan dalam manifes aplikasi (bagian ServiceManifestImport). Mari kita lihat beberapa contoh:
Contoh 1: Spesifikasi RequestsOnly
<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="1"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="1024" />
</Policies>
</ServiceManifestImport>
Dalam contoh ini, CpuCoresatribut digunakan untuk menentukan permintaan 1 core CPU untuk ServicePackageA. Karena batas CPU (CpuCoresLimit atribut) tidak ditentukan, Service Fabric juga menggunakan nilai permintaan yang ditentukan sebesar 1 core sebagai batas CPU untuk paket layanan.
ServicePackageA hanya akan ditempatkan pada node di mana kapasitas CPU yang tersisa setelah mengurangi jumlah permintaan CPU dari semua paket layanan yang ditempatkan pada simpul tersebut lebih besar dari atau sama dengan 1 core. Pada simpul, paket layanan akan dibatasi untuk satu core. Paket layanan berisi dua paket kode (CodeA1 dan CodeA2), dan keduanya menentukan atribut CpuShares. Proporsi CpuShares 512:256 digunakan untuk menghitung batas CPU untuk paket kode individual. Dengan demikian, CodeA1 akan dibatasi hingga dua pertiga dari core, dan CodeA2 akan dibatasi hingga sepertiga dari core. Jika CpuShares tidak ditentukan untuk semua paket kode, Service Fabric membagi batas CPU secara merata di antaranya.
Sementara CpuShares yang ditentukan untuk paket kode mewakili proporsi relatif dari batas CPU keseluruhan paket layanan, nilai memori untuk paket kode ditentukan dalam istilah absolut. Dalam contoh ini, atribut MemoryInMB digunakan untuk menentukan permintaan memori 1024 MB untuk CodeA1 dan CodeA2. Karena batas memori (atribut MemoryInMBLimit) tidak ditentukan, Service Fabric juga menggunakan nilai permintaan yang ditentukan sebagai batas untuk paket kode. Permintaan memori (dan batas) untuk paket layanan dihitung sebagai jumlah permintaan memori (dan batas) nilai paket kode penyusunnya. Dengan demikian untuk ServicePackageA, permintaan dan batas memori dihitung sebagai 2048 MB.
ServicePackageA hanya akan ditempatkan pada simpul di mana kapasitas memori yang tersisa setelah mengurangi jumlah permintaan memori dari semua paket layanan yang ditempatkan pada simpul tersebut lebih besar dari atau sama dengan 2048 MB. Pada simpul, kedua paket kode akan dibatasi hingga 1024 MB memori masing-masing. Paket kode (kontainer atau proses) tidak akan dapat mengalokasikan lebih banyak memori daripada batas ini, dan mencoba melakukannya akan menghasilkan pengecualian memori habis.
Contoh 2: Spesifikasi LimitsOnly
<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCoresLimit="1"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMBLimit="1024" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMBLimit="1024" />
</Policies>
</ServiceManifestImport>
Contoh ini menggunakan atribut CpuCoresLimit dan MemoryInMBLimit, yang hanya tersedia di SF versi 7.2 dan yang lebih baru. Atribut CpuCoresLimit digunakan untuk menentukan batas CPU 1 core untuk ServicePackageA. Karena permintaan CPU (atribut CpuCores) tidak ditentukan, maka dianggap 0. Atribut MemoryInMBLimit digunakan untuk menentukan batas memori 1024 MB untuk CodeA1 dan CodeA2 dan karena permintaan (atribut MemoryInMB) tidak ditentukan, nilainya dianggap 0. Permintaan memori dan batas untuk ServicePackageA dihitung sebagai 0 dan 2048. Karena permintaan CPU dan memori untuk ServicePackageA adalah 0, hal ini tidak memberikan beban bagi CRM untuk dipertimbangkan penempatan, untuk metrik servicefabric:/_CpuCores dan servicefabric:/_MemoryInMB. Oleh karena itu, dari perspektif tata kelola sumber daya, ServicePackageA dapat ditempatkan pada simpul apa pun terlepas dari kapasitas yang tersisa. Mirip dengan contoh 1, pada simpul, CodeA1 akan dibatasi hingga dua pertiga memori inti dan 1024 MB, dan CodeA2 akan dibatasi hingga sepertiga dari core dan memori 1024 MB.
Contoh 3: Spesifikasi RequestsAndLimits
<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="1" CpuCoresLimit="2"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" MemoryInMBLimit="3072" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="2048" MemoryInMBLimit="4096" />
</Policies>
</ServiceManifestImport>
Dibangun berdasarkan dua contoh pertama, contoh ini menunjukkan menentukan permintaan dan batasan untuk CPU dan memori. ServicePackageA memiliki permintaan CPU dan memori masing-masing sebesar 1 core dan 3072 (1024 + 2048) MB. Ini hanya dapat ditempatkan pada simpul yang memiliki minimal 1 inti (dan 3072 MB) kapasitas yang tersisa setelah mengurangi jumlah semua permintaan CPU (dan memori) dari semua paket layanan yang ditempatkan pada node dari total kapasitas CPU (dan memori) simpul. Pada simpul, CodeA1 akan dibatasi hingga dua pertiga dari 2 core dan memori 3072 MB sementara CodeA2 akan dibatasi hingga sepertiga dari 2 core dan memori 4096 MB.
Menggunakan parameter aplikasi
Saat menentukan setelan tata kelola sumber daya, dimungkinkan untuk menggunakan parameter aplikasi untuk mengelola beberapa konfigurasi aplikasi. Contoh berikut menunjukkan penggunaan parameter aplikasi:
<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
<Parameters>
<Parameter Name="CpuCores" DefaultValue="4" />
<Parameter Name="CpuSharesA" DefaultValue="512" />
<Parameter Name="CpuSharesB" DefaultValue="512" />
<Parameter Name="MemoryA" DefaultValue="2048" />
<Parameter Name="MemoryB" DefaultValue="2048" />
</Parameters>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="[CpuCores]"/>
<ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="[CpuSharesA]" MemoryInMB="[MemoryA]" />
<ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="[CpuSharesB]" MemoryInMB="[MemoryB]" />
</Policies>
</ServiceManifestImport>
Dalam contoh ini, nilai parameter default ditetapkan untuk lingkungan produksi, di mana setiap Paket Layanan akan mendapatkan 4 core dan 2 GB memori. Dimungkinkan untuk mengubah nilai default dengan file parameter aplikasi. Dalam contoh ini, satu file parameter dapat digunakan untuk menguji aplikasi secara lokal, yang akan mendapatkan lebih sedikit sumber daya daripada dalam produksi:
<!-- ApplicationParameters\Local.xml -->
<Application Name="fabric:/TestApplication1" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="CpuCores" DefaultValue="2" />
<Parameter Name="CpuSharesA" DefaultValue="512" />
<Parameter Name="CpuSharesB" DefaultValue="512" />
<Parameter Name="MemoryA" DefaultValue="1024" />
<Parameter Name="MemoryB" DefaultValue="1024" />
</Parameters>
</Application>
Penting
Menentukan tata kelola sumber daya dengan parameter aplikasi tersedia dimulai dengan Service Fabric versi 6.1.
Ketika parameter aplikasi digunakan untuk menentukan tata kelola sumber daya, Service Fabric tidak dapat diturunkan ke versi sebelum versi 6.1.
Memberlakukan batas sumber daya untuk layanan pengguna
Meskipun menerapkan tata kelola sumber daya pada layanan Service Fabric Anda menjamin bahwa layanan yang dikelola sumber daya tersebut tidak dapat melebihi kuota sumber daya mereka, banyak pengguna masih perlu menjalankan beberapa layanan Service Fabric mereka dalam mode yang tidak diatur. Ketika menggunakan layanan Service Fabric yang tidak diatur, dimungkinkan untuk mengalami situasi di mana layanan yang "melarikan diri" tidak diatur menggunakan semua sumber daya yang tersedia pada node Service Fabric, yang dapat menyebabkan masalah serius seperti:
- Kekurangan sumber daya dari layanan lain yang berjalan pada simpul (termasuk layanan sistem Service Fabric)
- Simpul berakhir dalam status tidak sehat
- API manajemen kluster Service Fabric yang tidak responsif
Untuk mencegah situasi ini terjadi, Service Fabric memungkinkan Anda menerapkan batas sumber daya untuk semua layanan pengguna Service Fabric yang berjalan pada node (baik yang diatur maupun yang tidak diatur) untuk menjamin bahwa layanan pengguna tidak akan pernah menggunakan lebih dari jumlah sumber daya yang ditentukan. Ini dicapai dengan menetapkan nilai untuk konfigurasi EnforceUserServiceMetricCapacities di bagian PlacementAndLoadBalancing dari ClusterManifest ke true. Setelan ini dinonaktifkan secara default.
<SectionName="PlacementAndLoadBalancing">
<ParameterName="EnforceUserServiceMetricCapacities" Value="false"/>
</Section>
Keterangan tambahan:
- Penerapan batas sumber daya hanya berlaku untuk metrik sumber daya
servicefabric:/_CpuCoresdanservicefabric:/_MemoryInMB - Penerapan batas sumber daya hanya berfungsi jika kapasitas node untuk metrik sumber daya tersedia untuk Service Fabric, baik melalui mekanisme deteksi otomatis, atau melalui pengguna yang menentukan kapasitas node secara manual (seperti yang dijelaskan dalam bagian Penyiapan kluster untuk mengaktifkan bagian tata kelola sumber daya). Jika kapasitas simpul tidak dikonfigurasi, kemampuan penegakan batas sumber daya tidak dapat digunakan karena Service Fabric tidak dapat mengetahui berapa banyak sumber daya yang harus dicadangkan untuk layanan pengguna. Service Fabric akan mengeluarkan peringatan kesehatan jika "EnforceUserServiceMetricCapacities" benar tetapi kapasitas simpul tidak dikonfigurasi.
Sumber daya lain untuk kontainer
Selain CPU dan memori, dimungkinkan untuk menentukan batas sumber daya lain untuk kontainer. Batas ini ditentukan pada tingkat paket kode dan diterapkan ketika kontainer dimulai. Tidak seperti CPU dan memori, Cluster Resource Manager tidak mengetahui sumber daya ini, dan tidak akan melakukan pemeriksaan kapasitas atau penyeimbangan beban untuk sumber daya tersebut.
- MemorySwapInMB: Jumlah total memori swap yang dapat digunakan, dalam MB. Harus berupa nilai bilangan bulat positif.
- MemoryReservationInMB: Batas umum (dalam MB) untuk tata kelola memori yang diberlakukan hanya ketika konten memori terdeteksi pada simpul. Harus berupa nilai bilangan bulat positif.
- CpuPercent: Persentase yang dapat digunakan dari CPU yang tersedia (khusus Windows). Harus berupa nilai bilangan bulat positif. Tidak dapat digunakan dengan CpuShares, CpuCores, atau CpuCoresLimit.
- CpuShares: Berat CPU relatif. Harus berupa nilai bilangan bulat positif. Tidak dapat digunakan dengan CpuShares, CpuCores, atau CpuCoresLimit.
- MaximumIOps: Jumlah maksimal IO (baca dan tulis) dalam hal IOps yang dapat digunakan. Harus berupa nilai bilangan bulat positif.
- MaximumIOBandwidth: IO maksimum (byte per detik) yang dapat digunakan (baca dan tulis). Harus berupa nilai bilangan bulat positif.
- BlockIOWeight: Berat blok IO, relatif terhadap paket kode lainnya. Harus menjadi bilangan bulat positif antara 10 dan 1000.
- DiskQuotaInMB: Kuota disk untuk kontainer. Harus berupa nilai bilangan bulat positif.
- KernelMemoryInMB: Batas memori kernel dalam byte. Harus berupa nilai bilangan bulat positif. Perhatikan bahwa ini khusus Linux dan docker di Windows akan menampilkan kesalahan jika diatur demikian.
- ShmSizeInMB: Ukuran /dev/shm dalam byte. Jika dihilangkan, sistem menggunakan 64MB. Harus berupa nilai bilangan bulat positif. Perhatikan bahwa ini khusus Linux, namun docker hanya akan mengabaikan (dan tidak menampilkan kesalahan) jika diatur demikian.
Sumber daya ini dapat dikombinasikan dengan CPU dan memori. Berikut adalah contoh cara menentukan sumber daya tambahan untuk kontainer:
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="FrontendServicePackage" ServiceManifestVersion="1.0"/>
<Policies>
<ResourceGovernancePolicy CodePackageRef="FrontendService.Code" CpuPercent="5"
MemorySwapInMB="4084" MemoryReservationInMB="1024" MaximumIOPS="20" />
</Policies>
</ServiceManifestImport>
Langkah berikutnya
- Untuk mempelajari lebih lanjut tentang Cluster Resource Manager, baca Memperkenalkan manajer sumber daya kluster Service Fabric.
- Untuk mempelajari selengkapnya tentang model aplikasi, paket layanan, dan paket kode --dan bagaimana replika memetakannya -- baca Model aplikasi di Service Fabric.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk