Bagikan melalui

Mengonfigurasi perilaku buffer pesan yang didukung disk

Penting

Pengaturan ini mengharuskan Anda memodifikasi sumber daya Broker. Ini hanya dikonfigurasi pada penyebaran awal dengan menggunakan Azure CLI atau portal Azure. Penyebaran baru diperlukan jika perubahan konfigurasi Broker diperlukan. Untuk mempelajari selengkapnya, lihat Menyesuaikan Broker default.

Fitur buffer pesan yang didukung disk digunakan untuk manajemen antrean pesan yang efisien dalam broker MQTT terdistribusi. Manfaatnya mencakup:

  • Manajemen antrean yang efisien: Dalam broker MQTT, setiap pelanggan dikaitkan dengan antrean pesan. Kecepatan pemrosesan pesan pelanggan secara langsung memengaruhi ukuran antrean. Jika pelanggan memproses pesan secara perlahan atau jika terputus tetapi meminta sesi persisten MQTT, antrean dapat tumbuh lebih besar dari memori yang tersedia.
  • Pelestarian data untuk sesi persisten: Fitur buffer pesan yang didukung disk memastikan bahwa ketika antrean melebihi memori yang tersedia, itu di-buffer dengan mulus ke disk. Fitur ini mencegah kehilangan data dan mendukung sesi persisten MQTT, memungkinkan pelanggan untuk melanjutkan sesi mereka dengan antrean pesan mereka utuh saat mereka terhubung kembali. Disk digunakan sebagai penyimpanan sementara dan berfungsi sebagai tumpahan dari memori. Data yang ditulis ke disk tidak tahan lama dan hilang saat pod keluar. Jika setidaknya satu pod di setiap rantai backend tetap berfungsi, broker secara keseluruhan tidak kehilangan data apa pun.
  • Menangani tantangan konektivitas: Konektor cloud diperlakukan sebagai pelanggan dengan sesi persisten yang dapat menghadapi tantangan konektivitas ketika mereka tidak dapat berkomunikasi dengan sistem eksternal seperti broker Azure Event Grid MQTT karena jaringan terputus. Dalam skenario seperti itu, pesan (PUBLISHes) terakumulasi. Broker MQTT dengan cerdas buffer pesan ini ke memori atau disk sampai konektivitas dipulihkan, yang memastikan integritas pesan.

Secara default, fitur buffer pesan yang didukung disk dinonaktifkan. Dalam hal ini, pesan tetap dalam memori, dan tekanan balik diterapkan pada klien karena kumpulan pembaca atau kumpulan awal mencapai batas seperti yang didefinisikan oleh batas antrean pelanggan.

Mengonfigurasi buffer pesan yang didukung disk sangat penting untuk mempertahankan sistem antrean pesan yang kuat dan andal, terutama dalam skenario di mana kecepatan pemrosesan pesan dan konektivitas sangat penting.

Catatan

Broker MQTT menulis data ke disk persis seperti yang diterima dari klien, tanpa menambahkan enkripsi. Mengamankan disk sangat penting untuk melindungi data yang disimpan broker.

Opsi konfigurasi

Untuk mengonfigurasi buffer pesan yang didukung disk, edit bagian diskBackedMessageBuffer di sumber daya Broker. Saat ini, konfigurasi ini hanya didukung dengan menggunakan --broker-config-file bendera saat Anda menyebarkan Operasi Azure IoT dengan menggunakan az iot ops create perintah .

Untuk memulai, siapkan file konfigurasi Broker dengan mengikuti referensi API DiskBackedMessageBuffer .

Misalnya, konfigurasi paling sederhana hanya melibatkan menentukan ukuran maksimum. Dalam hal ini, emptyDir volume dipasang. Nilai maxSize digunakan sebagai batas emptyDir ukuran volume. Tetapi opsi ini adalah opsi yang paling tidak disukai emptyDir karena keterbatasan volume.

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>"
  }
}

Untuk mendapatkan konfigurasi buffer pesan yang didukung disk yang lebih baik, tentukan volume sementara atau klaim volume persisten untuk memasang volume penyimpanan khusus untuk buffer pesan Anda. Contohnya:

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

{
  "persistentVolumeClaimSpec": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

Sesuaikan opsi buffer pesan broker dengan menyesuaikan pengaturan berikut:

  • Mengonfigurasi volume: Tentukan templat klaim volume untuk memasang volume penyimpanan khusus untuk buffer pesan Anda.
  • Pilih kelas penyimpanan: Tentukan kelas penyimpanan yang diinginkan dengan menggunakan storageClassName properti .
  • Tentukan mode akses: Tentukan mode akses yang Anda butuhkan untuk volume Anda. Untuk informasi selengkapnya, lihat Mode akses volume persisten.

Gunakan bagian berikut untuk memahami mode volume yang berbeda:

  • Volume Ephemeral adalah opsi yang disukai.
  • Volume persisten adalah opsi pilihan berikutnya.
  • volume emptyDir adalah opsi yang paling tidak disukai.

Volume persisten dan sementara umumnya disediakan oleh kelas penyimpanan yang sama. Jika kedua opsi tersedia, pilih ephemeral. Volume Ephemeral memerlukan Kubernetes 1.23 atau lebih tinggi.

Petunjuk / Saran

Saat Anda menentukan templat Klaim Volume Sementara (EVC) atau Klaim Volume Persisten (PVC), Anda dapat menggunakan kelas penyimpanan pilihan Anda, yang meningkatkan fleksibilitas untuk beberapa skenario penyebaran. Misalnya, volume persisten yang disediakan dengan menggunakan templat PVC muncul dalam perintah seperti kubectl get pv, yang berguna untuk memeriksa status kluster.

Jika simpul Kubernetes Anda tidak memiliki ruang disk lokal yang memadai untuk buffer pesan, gunakan kelas penyimpanan yang menyediakan penyimpanan jaringan seperti Azure Blob Storage. Lebih baik menggunakan disk lokal dengan nilai yang lebih maxSize kecil karena buffer pesan mendapat manfaat dari akses cepat dan tidak memerlukan durabilitas.

Menyebarkan Operasi IoT dengan buffer pesan yang didukung disk

Untuk menggunakan buffer pesan yang didukung disk, sebarkan Operasi IoT dengan menggunakan az iot ops create perintah dengan --broker-config-file bendera . Lihat perintah berikut. (Parameter lain dihilangkan untuk brevity.)

az iot ops create ... --broker-config-file <FILE>.json

Pengaturan ini tidak dapat diubah setelah penyebaran. Untuk mengubah konfigurasi buffer pesan yang didukung disk, sebarkan ulang instans Operasi IoT.

Volume Ephemeral

Volume Ephemeral adalah opsi yang lebih disukai untuk buffer pesan Anda.

Untuk volume ephemeral, ikuti saran di bagian Pertimbangan untuk penyedia penyimpanan.

Nilai ephemeralVolumeClaimSpec properti digunakan sebagai ephemeral.volumeClaimTemplate.spec properti volume dalam StatefulSet spesifikasi rantai backend.

Misalnya, untuk menggunakan volume ephemeral dengan kapasitas 1 gigabyte, tentukan parameter berikut di sumber daya Broker Anda:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

Volume persisten

Volume persisten adalah opsi pilihan berikutnya untuk buffer pesan Anda setelah volume sementara.

Untuk volume persisten, ikuti saran di bagian Pertimbangan untuk penyedia penyimpanan.

Nilai persistentVolumeClaimSpec properti digunakan sebagai volumeClaimTemplates.spec properti spesifikasi StatefulSet rantai backend.

Misalnya, untuk menggunakan volume persisten dengan kapasitas 1 gigabyte, tentukan parameter berikut di sumber daya Broker Anda:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "persistentVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

Volume emptyDir

Volume emptyDir adalah opsi yang paling tidak disukai setelah volume persisten.

emptyDir Gunakan volume hanya saat Anda menggunakan kluster dengan kuota sistem file. Untuk informasi selengkapnya, lihat tab kuota proyek Filesystem. Jika fitur tidak diaktifkan, kluster melakukan pemindaian berkala yang tidak memberlakukan batas apa pun dan memungkinkan node host untuk mengisi ruang disk dan menandai seluruh node host sebagai tidak sehat.

Misalnya, untuk menggunakan emptyDir volume dengan kapasitas 1 gigabyte, tentukan parameter berikut di sumber daya Broker Anda:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G"
  }
}

Pertimbangan untuk penyedia penyimpanan

Pertimbangkan perilaku penyedia penyimpanan yang Anda pilih, misalnya, saat Anda menggunakan penyedia seperti rancher.io/local-path. Jika penyedia tidak mendukung batas, mengisi volume akan mengonsumsi ruang disk simpul. Perilaku ini dapat menyebabkan Kubernetes menandai simpul dan semua pod terkait sebagai tidak sehat. Sangat penting untuk memahami bagaimana penyedia penyimpanan Anda berperilaku dalam skenario seperti itu.

Nonaktif

Jika Anda tidak ingin menggunakan buffer pesan yang didukung disk, jangan sertakan diskBackedMessageBufferSettings properti di sumber daya Broker Anda. Perilaku ini juga merupakan default.

Persistensi

Penting untuk dipahami bahwa fitur buffer pesan yang didukung disk tidak identik dengan persistensi. Dalam konteks ini, persistensi mengacu pada data yang bertahan di seluruh pod yang dimulai ulang. Fitur ini menyediakan ruang penyimpanan sementara agar data disimpan ke disk, yang mencegah luapan memori dan kehilangan data selama mulai ulang pod.

  • Last updated on