Bagikan melalui

Laporan Resmi untuk Protokol Ketersediaan Tinggi Bawaan untuk HPC Pack 2019

Ikhtisar

Dengan rilis HPC Pack 2019, kami telah menambahkan model HA baru, yang bergantung pada instans SQL always-on. Dibandingkan dengan implementasi berbasis Service Fabric sebelumnya:

  • HPC Pack akan memiliki kemampuan HA yang sama ketika salah satu simpul kepala gagal.
  • Hanya 2 simpul yang diperlukan untuk memiliki kemampuan HA.
  • Lapisan tipis pustaka HA disediakan dengan HPC Pack yang bergantung pada SQL always-on alih-alih Service Fabric.

Perbandingan model HA

Karakter \ model HA Tidak ada KETERSEDIAAN TINGGI Service Fabric Berdasarkan SQL
Mekanisme yang mendasar Tidak Service Fabric SQL always-on
Simpul paling sedikit diperlukan 1 3 2
Failover ketika simpul utama saat ini gagal Tidak Ya Ya
Beroperasi saat server SQL gagal Tidak Tidak Tidak

Arsitektur

Kita dapat mengilustrasikan arsitektur menggunakan HPC Scheduler sebagai contoh. Arsitekturnya sendiri sederhana. HPC Scheduler menggunakan salah satu implementasi klien yang disediakan (SQL secara default) untuk berkomunikasi dengan salah satu implementasi server (juga SQL secara default).

diagram memperlihatkan arsitektur Penjadwal H P C.

Picture 1 - Arsitektur Layanan Penjadwal HA HPC

Sebagian besar layanan lain dalam HPC Pack menggunakan protokol KETERSEDIAAN TINGGI bawaan dengan cara yang sama seperti layanan Scheduler, kecuali layanan stateless. Alasannya adalah layanan stateless berjalan pada semua simpul kepala sehingga mereka tidak perlu melalui proses pemilihan pemimpin. Meskipun biasanya kami hanya menggunakan instans layanan stateless yang berjalan pada node yang sama dengan layanan Scheduler.

Detail Protokol

Desain

Parameter

  • I: interval untuk heartbeat (misalnya 1 detik)
  • T: batas waktu heartbeat (misalnya 5 detik)
  • T > 2 * I

Data Informasi

  • Heartbeat Table: Tabel dalam sistem KETERSEDIAAN TINGGI eksternal berisi entri heartbeat.
  • Heartbeat Entry: dalam format {uuid, utype, timestamp}
  • ha_time: waktu tanggal saat ini dari sistem KETERSEDIAAN TINGGI eksternal
  • Sepanjang waktu dalam waktu UTC

Prosedur

  • UpdateHeartBeat(uuid, utype):

    Untuk setiap jenis, perbarui entri {old_uuid, utype, old_timestamp} dalam tabel heartbeat dengan {uuid, utype, ha_time}.

    Untuk setiap jenis, jika uuid tidak sama dengan old_uuid, maka (ha_time – old_timestamp > T) harus dipenuhi.

    Proses pembaruan menggunakan kontrol konkurensi optimis. misalnya jika entri heartbeat telah diperbarui sebelum heartbeat lain mencapai, heartbeat selanjutnya dibuang.

  • GetPrimary(utype):

    Mengembalikan (uuid, utype) dalam entri heartbeat dengan utype kueri yang sesuai jika (ha_time - timestamp <= T). Jika tidak, kembalikan nilai kosong.

Algoritma

  1. Setelah klien S dimulai, ia menghasilkan ID instans unik uuid untuk mengidentifikasi dirinya sendiri dan menandai dirinya dengan utypeyang tepat , yang akan berfungsi seperti di masa depan.

  2. S memanggil GetPrimary(utype) setiap I detik.

  3. Jika GetPrimary(utype) mengembalikan nilai kosong, S memanggil UpdateHeartbeat(uuid, utype).

  4. Terus panggil GetPrimary(utype) setiap I detik.

    sebuah. Jika panggilan berikutnya ke GetPrimary(utype) mengembalikan (uuid, utype) yang dihasilkan dalam 1, S kemudian akan berfungsi sebagai primer.

    b. Jika panggilan berikutnya ke GetPrimary(utype) mengembalikan ID unik yang berbeda dari uuid dan jenis yang sama dengan utype yang dihasilkan dalam 1, kembali ke 2.

    c. Jika panggilan berikutnya ke GetPrimary(utype) mengembalikan nilai kosong/pesan yang rusak, kesalahan terjadi di 3. Coba lagi 3.

  5. S memanggil UpdateHeartBeat(uuid, utype) dan GetPrimary(utype) setiap I detik.

    sebuah. Jika GetPrimary(utype) mengembalikan apa pun kecuali (uuid, utype), atau tidak kembali untuk (T - I) detik, keluar dari dirinya sendiri dan memulai ulang.

Pelaksanaan

Implementasi HA bersumber terbuka di GitHub

Menyebarkan

Lihat dokumentasi penyebaran HPC Pack 2019.

Konfigurasi

Ada dua konfigurasi yang terkait dengan protokol KETERSEDIAAN TINGGI bawaan.

  • ServiceAffinity (default ke 1)

    • ServiceAffinity berarti jika layanan HPC lainnya harus berjalan pada node yang sama HPC Scheduler berjalan. Nilai defaultnya adalah 1, yang berarti afinitas aktif. Ini juga merupakan nilai yang direkomendasikan.
    • Untuk memeriksa pengaturan, jalankan perintah PowerShell Get-HpcClusterRegistry dan temukan ServiceAffinity dalam output.
    • Untuk mengubah pengaturan, jalankan perintah PowerShell Set-HpcClusterRegistry -PropertyName ServiceAffinity -PropertyValue <new-value>
    • Setelah pengaturan afinitas diubah, semua simpul kepala perlu dimulai ulang.

  • HeartBeatTimeOut (ms, default ke 10000)

    • Ini adalah waktu detak jantung habis yang digunakan oleh algoritma di atas.
    • Pengaturan ini juga memengaruhi interval heartbeat. Interval diatur ke floor(HeartBeatTimeOut / 5). Jadi nilai ini tidak pernah dapat diatur ke kurang dari 5, jika tidak, server SQL akan dibanjiri oleh pesan heartbeat.
    • Satu-satunya cara untuk memeriksa dan mengubah nilai ini adalah melalui tabel SQL [HPCHAWitness].[dbo].[ParameterTable].

    Catatan: TIDAK disarankan untuk mengubah nilai HeartBeatTimeOut. Satu-satunya pengecualian adalah selama penurunan performa jaringan server SQL Always-on. Saat mengubah nilai ini, pastikan semua Layanan HPC dihentikan.

Ganti Salah Satu Simpul Kepala

Hapus simpul kepala yang perlu diganti di manajer kluster. Kemudian, instal head node baru setelah proses penginstalan head node HPC HA normal. Untuk informasi selengkapnya, lihat dokumentasi penyebaran HPC Pack 2019.

Proses dan Alat Diagnostik

Proses diagnostik sama dengan Kluster HPC lainnya. Jika failover layanan tidak normal, kita perlu memeriksa log layanannya.

Periksa di sini tentang cara mengumpulkan log layanan dan alat yang tersedia untuk membaca log biner.

Rekomendasi

  • Dalam kluster HA, server simpul kepala harus cukup kuat untuk menjalankan semua timer yang diinstruksikan tepat waktu. Ini berarti pada simpul kepala, beban CPU harus kurang dari 90% setiap saat.
  • Di kluster HA, kami sarankan Anda menghapus peran simpul komputasi dan simpul broker dari semua simpul kepala.
  • Kluster HPC, dengan atau tanpa HA, membutuhkan server SQL yang mendasar berfungsi dengan baik untuk berfungsi. Jika server SQL terus-menerus di bawah beban berat, kami sarankan Anda untuk meningkatkan instans server. Sama untuk jaringan antara simpul kepala dan server SQL.