Bagikan melalui

Integrasi manajer sumber daya klaster dengan manajemen klaster Service Fabric

  • Artikel

Service Fabric Cluster Resource Manager tidak mendorong peningkatan dalam Service Fabric, tetapi terlibat. Cara pertama yang membantu Manajer Sumber Daya Klaster dengan manajemen adalah dengan melacak keadaan klaster yang diinginkan dan layanan di dalamnya. Manajer Sumber Daya Klaster mengirimkan laporan kesehatan ketika tidak dapat menempatkan klaster ke dalam konfigurasi yang diinginkan. Misalnya, jika kapasitas yang tidak mencukupi, Manajer Sumber Daya Klaster mengirimkan peringatan dan kesalahan kesehatan yang menunjukkan masalah. Bagian lain dari integrasi ada hubungannya dengan cara kerja peningkatan. Manajer Sumber Daya Klaster mengubah perilakunya sedikit selama peningkatan.

Integrasi kesehatan

Manajer Sumber Daya Klaster terus melacak aturan yang telah Anda tentukan untuk menempatkan layanan Anda. Ini juga melacak kapasitas yang tersisa untuk setiap metrik pada node dan di klaster dan di klaster secara keseluruhan. Jika tidak dapat memenuhi aturan tersebut atau jika kapasitasnya tidak mencukupi, peringatan kesehatan dan kesalahan dipancarkan. Misalnya, jika node melebihi kapasitas dan Manajer Sumber Daya Klaster akan mencoba memperbaiki situasi dengan memindahkan layanan. Jika tidak dapat memperbaiki situasi itu memancarkan peringatan kesehatan yang menunjukkan node mana yang melebihi kapasitas, dan untuk metrik mana.

Contoh lain dari peringatan kesehatan Manajer Sumber Daya adalah pelanggaran kendala penempatan. Misalnya, jika Anda telah menentukan batasan penempatan “NodeColor == Blue” (seperti) dan Manajer Sumber Daya mendeteksi pelanggaran terhadap batasan tersebut, itu memancarkan peringatan kesehatan. Ini berlaku untuk batasan kustom dan batasan default (seperti batasan Domain Kesalahan dan Pemutakhiran Domain).

Berikut adalah contoh dari salah satu laporan kesehatan tersebut. Dalam hal ini, laporan kesehatan adalah untuk salah satu partisi layanan sistem. Pesan kesehatan menunjukkan replika partisi tersebut untuk sementara dikemas ke dalam terlalu sedikit Domain Pemutakhiran.

PS C:\Users\User > Get-ServiceFabricPartitionHealth -PartitionId '00000000-0000-0000-0000-000000000001'


PartitionId           : 00000000-0000-0000-0000-000000000001
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='System.PLB', Property='ReplicaConstraintViolation_UpgradeDomain', HealthState='Warning', ConsiderWarningAsError=false.

ReplicaHealthStates   :
                        ReplicaId             : 130766528804733380
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577821
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528854889931
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577822
                        AggregatedHealthState : Ok

                        ReplicaId             : 130837073190680024
                        AggregatedHealthState : Ok

HealthEvents          :
                        SourceId              : System.PLB
                        Property              : ReplicaConstraintViolation_UpgradeDomain
                        HealthState           : Warning
                        SequenceNumber        : 130837100116930204
                        SentAt                : 8/10/2015 7:53:31 PM
                        ReceivedAt            : 8/10/2015 7:53:33 PM
                        TTL                   : 00:01:05
                        Description           : The Load Balancer has detected a Constraint Violation for this Replica: fabric:/System/FailoverManagerService Secondary Partition 00000000-0000-0000-0000-000000000001 is
                        violating the Constraint: UpgradeDomain Details: UpgradeDomain ID -- 4, Replica on NodeName -- Node.8 Currently Upgrading -- false Distribution Policy -- Packing
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : Ok->Warning = 8/10/2015 7:13:02 PM, LastError = 1/1/0001 12:00:00 AM

Inilah yang dikatakan pesan kesehatan ini kepada kami adalah:

  1. Semua replika itu sendiri sehat: Masing-masing memiliki AggregatedHealthState : Ok
  2. Batasan distribusi Domain Pemutakhiran saat ini sedang dilanggar. Ini berarti Domain Peningkatan tertentu memiliki lebih banyak replika dari partisi ini daripada yang seharusnya.
  3. Node mana yang berisi replika yang menyebabkan pelanggaran. Dalam hal ini adalah node dengan nama Node.8
  4. Apakah pemutakhiran saat ini terjadi untuk partisi ini ("Sedang Memutakhirkan -- false")
  5. Kebijakan distribusi untuk layanan ini: "Kebijakan Distribusi -- Pengepakan". Ini diatur oleh kebijakan RequireDomainDistribution penempatan. Pengepakan menunjukkan bahwa dalam hal ini DomainDistribution tidak diperlukan, jadi kami tahu bahwa kebijakan penempatan tidak ditentukan untuk layanan ini.
  6. Ketika laporan terjadi - 8/10/2015 7:13:02 PM

Informasi seperti ini mendukung pemberitahuan. Anda dapat menggunakan pemberitahuan dalam produksi untuk memberi tahu Anda bahwa ada yang tidak beres. Pemberitahuan juga digunakan untuk mendeteksi dan menghentikan peningkatan yang buruk. Dalam hal ini, kami ingin melihat apakah kami dapat mengetahui mengapa Manajer Sumber Daya harus mengemas replika ke dalam Domain Pemutakhiran. Biasanya pengepakan ber sementara karena node di Domain Pemutakhiran lainnya turun, misalnya.

Katakanlah Manajer Sumber Daya Klaster mencoba menempatkan beberapa layanan, tetapi tidak ada solusi yang berfungsi. Ketika layanan tidak dapat ditempatkan, biasanya karena salah satu alasan berikut:

  1. Beberapa kondisi sementara telah membuatnya tidak mungkin untuk menempatkan instans layanan ini atau replika dengan benar
  2. Persyaratan penempatan layanan tidak dapat puas.

Dalam kasus ini, laporan kesehatan dari Manajer Sumber Daya Klaster membantu Anda menentukan mengapa layanan tidak dapat ditempatkan. Kami menyebut proses ini sebagai urutan penghapusan batasan. Selama itu, sistem berjalan melalui batasan yang dikonfigurasi mempengaruhi layanan dan mencatat apa yang mereka hilangkan. Dengan cara ini ketika layanan tidak dapat ditempatkan, Anda dapat melihat node mana yang dihilangkan dan mengapa.

Tipe Batasan

Mari kita bicara tentang masing-masing kendala yang berbeda dalam laporan kesehatan ini. Anda akan melihat pesan kesehatan yang terkait dengan batasan ini saat replika tidak dapat ditempatkan.

  • ReplicaExclusionStatic dan ReplicaExclusionDynamic: Kendala ini menunjukkan bahwa solusi ditolak karena dua objek layanan dari partisi yang sama harus ditempatkan pada node yang sama. Ini tidak diperbolehkan karena kegagalan node itu akan terlalu berdampak pada partisi itu. ReplicaExclusionStatic dan ReplicaExclusionDynamic adalah aturan yang hampir sama dan perbedaannya tidak terlalu penting. Jika Anda melihat urutan penghapusan batasan yang berisi batasan ReplicaExclusionStatic atau ReplicaExclusionDynamic, Manajer Sumber Daya Klaster berpikir bahwa tidak ada cukup node. Ini membutuhkan solusi yang tersisa untuk menggunakan penempatan yang tidak valid ini, yang tidak diizinkan. Kendala lain dalam urutan biasanya akan memberi tahu kita mengapa node dihilangkan di tempat pertama.
  • PlacementConstraint: Jika Anda melihat pesan ini, itu berarti bahwa kami menghilangkan beberapa node karena mereka tidak cocok dengan batasan penempatan layanan. Kami melacak batasan penempatan yang saat ini dikonfigurasi sebagai bagian dari pesan ini. Ini normal jika Anda memiliki batasan penempatan yang ditentukan. Namun, jika batasan penempatan salah menyebabkan terlalu banyak node dihilangkan, ini adalah bagaimana Anda akan melihat.
  • NodeCapacity: Batasan ini berarti bahwa Manajer Sumber Daya Klaster tidak dapat menempatkan replika pada node yang ditunjukkan karena hal itu akan membuatnya melebihi kapasitas.
  • Afinitas:Kendala ini menunjukkan bahwa kami tidak dapat menempatkan replika pada node yang terpengaruh karena akan menyebabkan pelanggaran terhadap kendala afinitas. Informasi selengkapnya tentang afinitas ada di artikel ini
  • FaultDomain dan UpgradeDomain: Batasan ini menghilangkan node jika menempatkan replika pada node yang ditunjukkan akan menyebabkan pengepakan dalam kesalahan atau domain pemutakhiran tertentu. Beberapa contoh yang membahas batasan ini disajikan dalam topik tentang kesalahan dan meningkatkan batasan domain dan perilaku yang dihasilkan
  • PreferredLocation: Anda biasanya tidak boleh melihat batasan ini menghapus node dari solusi karena berjalan sebagai pengoptimalan secara default. Batasan lokasi yang disukai juga ada selama peningkatan. Selama peningkatan, digunakan untuk memindahkan layanan kembali ke tempat mereka berada ketika peningkatan dimulai.

Node Pemblokiran

Pesan kesehatan lain yang dilaporkan Cluster Resource Manager adalah ketika node diblokir. Anda dapat menganggap pemblokiran sebagai batasan sementara yang secara otomatis diterapkan untuk Anda. Node diblokir ketika mengalami kegagalan berulang saat meluncurkan instans jenis layanan tersebut. Node diblokir berdasarkan per-service-type. Node dapat diblokir untuk satu jenis layanan tetapi tidak yang lain.

Anda akan sering melihat tendangan pemblokiran selama pengembangan: Beberapa bug menyebabkan host layanan Anda macet saat startup, Service Fabric mencoba membuat host layanan beberapa kali, dan kegagalan terus terjadi. Setelah beberapa upaya, node akan diblokir, dan Cluster Resource Manager akan mencoba membuat layanan di tempat lain. Jika kegagalan itu terus terjadi pada beberapa node, ada kemungkinan bahwa semua node yang valid di klaster akhirnya diblokir. Pemblokiran juga dapat menghapus begitu banyak node sehingga tidak cukup dapat berhasil meluncurkan layanan untuk memenuhi skala yang diinginkan. Anda biasanya akan melihat kesalahan atau peringatan tambahan dari Cluster Resource Manager yang menunjukkan bahwa layanan berada di bawah jumlah replika atau instans yang diinginkan, serta pesan kesehatan yang menunjukkan apa kegagalan yang mengarah ke pemblokiran di tempat pertama.

Pemblokiran bukan kondisi permanen. Setelah beberapa menit, node dihapus dari daftar blokir dan Service Fabric dapat mengaktifkan layanan pada node itu lagi. Jika layanan terus gagal, node diblokir untuk tipe layanan tersebut lagi.

Prioritas batasan

Peringatan

Mengubah prioritas batasan tidak disarankan dan mungkin memiliki efek samping yang signifikan pada klaster Anda. Informasi di bawah ini disediakan untuk referensi prioritas batasan default dan perilaku mereka.

Dengan semua batasan ini, Anda mungkin telah berpikir "Hei - saya pikir batasan domain kesalahan adalah hal yang paling penting dalam sistem saya. Untuk memastikan kendala domain kesalahan tidak dilanggar, saya bersedia melanggar batasan lain."

Batasan dapat dikonfigurasi dengan tingkat prioritas yang berbeda. Ini adalah:

  • “hard” (0)
  • “soft” (1)
  • “optimization” (2)
  • “off” (-1).

Sebagian besar batasan dikonfigurasi sebagai batasan keras secara default.

Mengubah prioritas batasan tidak jarang terjadi. Ada saat-saat di mana prioritas batasan diperlukan untuk berubah, biasanya untuk mengatasi beberapa bug atau perilaku lain yang berdampak pada lingkungan. Umumnya fleksibilitas infrastruktur prioritas batasan telah bekerja dengan sangat baik, tetapi tidak diperlukan sering. Sebagian besar waktu semuanya berada di prioritas default mereka.

Tingkat prioritas tidak berarti bahwa batasan yang diberikan akan dilanggar, juga tidak akan selalu terpenuhi. Prioritas batasan menentukan urutan di mana batasan diberlakukan. Prioritas mendefinisikan tradeoff ketika tidak mungkin untuk memenuhi semua batasan. Biasanya semua batasan dapat dipenuhi kecuali ada hal lain yang terjadi di lingkungan. Beberapa contoh skenario yang akan menyebabkan batasan pelanggaran adalah batasan yang bertentangan, atau sejumlah besar kegagalan bersamaan.

Dalam situasi lanjutan, Anda dapat mengubah prioritas batasan. Misalnya, Anda ingin memastikan bahwa afinitas akan selalu dilanggar ketika diperlukan untuk menyelesaikan masalah kapasitas node. Untuk mencapai ini, Anda dapat menetapkan prioritas batasan afinitas menjadi "lunak" (1) dan meninggalkan batasan kapasitas diatur ke "keras" (0).

Nilai prioritas default untuk batasan berbeda ditentukan dalam konfigurasi berikut:

ClusterManifest.xml

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PlacementConstraintPriority" Value="0" />
            <Parameter Name="CapacityConstraintPriority" Value="0" />
            <Parameter Name="AffinityConstraintPriority" Value="0" />
            <Parameter Name="FaultDomainConstraintPriority" Value="0" />
            <Parameter Name="UpgradeDomainConstraintPriority" Value="1" />
            <Parameter Name="PreferredLocationConstraintPriority" Value="2" />
        </Section>

melalui ClusterConfig.json untuk penyebaran Mandiri atau Template.json untuk klaster yang dihosting Azure:

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PlacementConstraintPriority",
          "value": "0"
      },
      {
          "name": "CapacityConstraintPriority",
          "value": "0"
      },
      {
          "name": "AffinityConstraintPriority",
          "value": "0"
      },
      {
          "name": "FaultDomainConstraintPriority",
          "value": "0"
      },
      {
          "name": "UpgradeDomainConstraintPriority",
          "value": "1"
      },
      {
          "name": "PreferredLocationConstraintPriority",
          "value": "2"
      }
    ]
  }
]

Domain kesalahan dan batasan domain peningkatan

Cluster Resource Manager ingin menjaga layanan tetap tersebar di antara domain kesalahan dan peningkatan. Ini model ini sebagai kendala di dalam mesin Cluster Resource Manager. Untuk informasi selengkapnya tentang cara mereka digunakan dan perilaku spesifiknya, lihat artikel tentang konfigurasi klaster.

Cluster Resource Manager mungkin perlu mengemas beberapa replika ke domain peningkatan untuk menangani peningkatan, kegagalan, atau pelanggaran batasan lainnya. Mengemas ke dalam domain kesalahan atau peningkatan biasanya terjadi hanya ketika ada beberapa kegagalan atau churn lain dalam sistem mencegah penempatan yang benar. Jika Anda ingin mencegah pengepakan bahkan selama situasi ini, Anda dapat menggunakan RequireDomainDistribution kebijakan penempatan. Perhatikan bahwa melakukannya dapat memengaruhi ketersediaan dan keandalan layanan sebagai efek samping, jadi pertimbangkan dengan hati-hati.

Jika lingkungan dikonfigurasi dengan benar, semua batasan sepenuhnya dihormati, bahkan selama peningkatan. Kuncinya adalah Cluster Resource Manager mengawasi kendala Anda. Ketika mendeteksi pelanggaran, ia segera melaporkannya dan mencoba memperbaiki masalah tersebut.

Batasan lokasi yang disukai

Batasan PreferredLocation sedikit berbeda, karena memiliki dua kegunaan yang berbeda. Salah satu penggunaan batasan ini adalah selama peningkatan aplikasi. Cluster Resource Manager secara otomatis mengelola batasan ini selama peningkatan. Ini digunakan untuk memastikan bahwa ketika peningkatan selesai bahwa replika kembali ke lokasi awal mereka. Penggunaan lain dari kendala PreferredLocation adalah untuk PreferredPrimaryDomainkebijakan penempatan. Keduanya adalah pengoptimalan, dan karenanya kendala PreferredLocation adalah satu-satunya batasan yang diatur ke "Optimasi" secara default.

Peningkatan

Cluster Resource Manager juga membantu selama peningkatan aplikasi dan klaster, di mana ia memiliki dua pekerjaan:

  • memastikan bahwa aturan klaster tidak terganggu
  • mencoba membantu peningkatan berjalan lancar

Terus berlakukan aturan

Hal utama yang perlu diperhatikan adalah bahwa aturan - kendala ketat seperti batasan penempatan dan kapasitas - masih diberlakukan selama peningkatan. Kendala penempatan memastikan bahwa beban kerja Anda hanya berjalan di tempat yang diizinkan, bahkan selama peningkatan. Ketika layanan sangat dibatasi, peningkatan dapat memakan waktu lebih lama. Ketika layanan atau nodenya diturunkan untuk pembaruan, mungkin ada beberapa opsi ke mana ia bisa pergi.

Penggantian cerdas

Saat peningkatan dimulai, Resource Manager mengambil snapshot dari pengaturan klaster saat ini. Ketika setiap Upgrade Domain selesai, ia mencoba untuk mengembalikan layanan yang ada di Upgrade Domain ke pengaturan aslinya. Dengan cara ini paling banyak ada dua transisi untuk layanan selama peningkatan. Ada satu langkah keluar dari node yang terpengaruh dan satu bergerak kembali masuk Mengembalikan klaster atau layanan ke bagaimana sebelum peningkatan juga memastikan peningkatan tidak berdampak pada tata letak klaster.

Churn yang dikurangi

Selama upgrade, Cluster Resource Manager juga mematikan balancing. Mencegah penyeimbangan dapat mencegah reaksi yang tidak perlu terhadap peningkatan itu sendiri, seperti memindahkan layanan ke node yang dikosongkan untuk peningkatan. Jika pemutakhiran yang dimaksud adalah pemutakhiran Klaster, maka seluruh klaster tidak seimbang selama pemutakhiran. Pemeriksaan kendala tetap aktif, hanya gerakan yang didasarkan pada keseimbangan proaktif metrik yang dinonaktifkan.

Kapasitas & Pemutakhiran yang Dibuffer

Umumnya, Anda ingin pemutakhiran selesai meskipun klaster dibatasi atau hampir penuh. Bahkan, mengelola kapasitas klaster lebih penting selama peningkatan daripada biasanya. Bergantung pada jumlah domain pemutakhiran, antara 5 dan 20 persen kapasitas harus dimigrasi saat pemutakhiran berlangsung melalui klaster. Tindakan tersebut harus berjalanan pada sistem manapun. Di sinilah gagasan tentang kapasitas yang di-buffer berguna. Kapasitas buffer diterapkan selama operasi normal. Cluster Resource Manager dapat mengisi node hingga kapasitas totalnya (menggunakan buffer) selama peningkatan jika perlu.

Langkah berikutnya