Mengonfigurasi pengaturan broker untuk keandalan tinggi, penskalaan, dan penggunaan memori

Sumber daya Broker adalah sumber daya utama yang menentukan pengaturan keseluruhan untuk broker MQTT. Ini juga menentukan jumlah dan jenis pod yang menjalankan konfigurasi Broker, seperti frontend dan backend. Anda juga dapat menggunakan sumber daya Broker untuk mengonfigurasi profil memorinya. Mekanisme penyembuhan mandiri sudah terintegrasi dalam broker, dan sering kali dapat pulih secara otomatis dari kegagalan komponen. Contohnya adalah jika node gagal dalam kluster Kubernetes yang dikonfigurasi untuk ketersediaan tinggi.

Anda dapat menskalakan broker MQTT secara horizontal dengan menambahkan lebih banyak replika frontend dan partisi backend. Replika frontend bertanggung jawab untuk menerima koneksi MQTT dari klien dan meneruskannya ke partisi backend. Partisi backend bertanggung jawab untuk menyimpan dan mengirimkan pesan kepada klien. Pod frontend mendistribusikan lalu lintas pesan di seluruh pod backend. Faktor redundansi backend menentukan jumlah salinan data untuk memberikan ketahanan terhadap kegagalan simpul dalam kluster.

Untuk daftar pengaturan yang tersedia, lihat Broker referensi API.

Mengonfigurasi pengaturan penskalakan

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 lebih lanjut, lihat Sesuaikan Broker Default.

Untuk mengonfigurasi pengaturan penskalaan broker MQTT, tentukan bidang kardinalitas dalam spesifikasi sumber daya Broker selama penyebaran Operasi Azure IoT.

Kardinalitas penerapan otomatis

Untuk secara otomatis menentukan kardinalitas awal selama penyebaran, hilangkan bidang kardinalitas di sumber daya Broker.

Portal

Kardinalitas otomatis belum didukung saat Anda menggunakan Operasi IoT melalui portal Azure. Anda dapat menentukan mode penyebaran kluster secara manual sebagai Simpul tunggal atau Multi-simpul. Untuk mempelajari lebih lanjut, lihat halaman Menyebarkan Operasi Azure IoT.

Azure CLI

Siapkan file konfigurasi Broker dalam format JSON, yang mencakup properti yang diinginkan dari microsoft.iotoperations/instances/brokers Azure Resource Manager. Pastikan untuk menghapus bidang cardinality. Misalnya, atur hanya profil memori:

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

Kemudian, menyebarkan Pengoperasian IoT dengan menggunakan perintah az iot ops create dengan bendera --broker-config-file, seperti perintah berikut (parameter lain dihilangkan untuk singkatnya):

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

Untuk mempelajari selengkapnya, lihat Dukungan Azure CLI untuk konfigurasi broker MQTT tingkat lanjut.

Operator broker MQTT secara otomatis menyebarkan jumlah pod yang sesuai berdasarkan jumlah simpul yang tersedia pada saat penyebaran. Kemampuan ini berguna untuk skenario nonproduksi di mana Anda tidak memerlukan ketersediaan atau skala tinggi.

Kemampuan ini tidak menskalakan otomatis. Operator tidak secara otomatis menskalakan jumlah pod berdasarkan beban. Operator menentukan jumlah awal pod untuk disebarkan hanya berdasarkan perangkat keras kluster. Seperti disebutkan sebelumnya, kardinalitas diatur hanya pada waktu penyebaran awal. Penyebaran baru diperlukan jika pengaturan kardinalitas perlu diubah.

Mengonfigurasi kardinalitas secara langsung

Untuk mengonfigurasi pengaturan kardinalitas secara langsung, tentukan setiap bidang kardinalitas.

Portal

Saat Anda mengikuti panduan untuk menyebarkan Operasi IoT, di bagian Konfigurasi, periksa Konfigurasi broker MQTT. Di sini, Anda dapat menentukan jumlah replika frontend, partisi backend, dan pekerja backend.

Azure CLI

Saat Anda menerapkan operasi IoT dengan perintah az iot ops create, gunakan parameter --broker-frontend-replicas, --broker-frontend-workers, --broker-backend-part, --broker-backend-rf, dan --broker-backend-workers untuk menentukan pengaturan kardinalitas.

Misalnya, untuk menentukan satu replika frontend, satu pekerja frontend, satu partisi backend, dua replika backend per partisi, dan satu pekerja backend per replika, lihat perintah berikut ini (parameter lain dihilangkan untuk kejelasan).

az iot ops create ... --broker-frontend-replicas 1 --broker-frontend-workers 1  --broker-backend-part 1  --broker-backend-workers 1 --broker-backend-rf 2

Atau, gunakan --broker-config-file bendera untuk menentukan file JSON yang menyertakan pengaturan kardinalitas. Berikut adalah contoh file JSON untuk pengaturan yang sama:

{
  "cardinality": {
    "frontend": {
      "replicas": 1,
      "workers": 1
    },
    "backendChain": {
      "partitions": 1,
      "redundancyFactor": 2,
      "workers": 1
    }
  }
}

Kemudian, menyebarkan Pengoperasian IoT dengan menggunakan perintah az iot ops create dengan bendera --broker-config-file, seperti perintah berikut (parameter lain dihilangkan untuk singkatnya):

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

Memahami kardinalitas

Kardinalitas berarti jumlah instans entitas tertentu dalam satu set. Dalam konteks broker MQTT, kardinalitas mengacu pada jumlah replika frontend, partisi backend, dan worker backend yang akan diterapkan. Pengaturan kardinalitas digunakan untuk menskalakan broker secara horizontal serta meningkatkan ketersediaan yang tinggi jika ada kegagalan pod atau node.

Bidang kardinalitas adalah bidang berlapis, dengan subbidang untuk frontend dan rantai backend. Masing-masing subbidang ini memiliki pengaturannya sendiri.

Ujung depan

Subbidang frontend mendefinisikan pengaturan untuk pod frontend. Dua pengaturan utama adalah:

• Replika: Jumlah replika frontend (pod) yang akan disebarkan. Meningkatkan jumlah replika frontend memberikan ketersediaan yang tinggi jika salah satu pod frontend gagal.
• Pengolah: Jumlah pengolah frontend logika per replika. Setiap pekerja dapat mengonsumsi hingga satu inti CPU paling banyak.

Rantai Backend

Subbidang rantai backend mendefinisikan pengaturan untuk partisi backend. Tiga pengaturan utama adalah:

• Partisi: Jumlah partisi yang akan disebarkan. Melalui proses yang disebut sharding, setiap partisi bertanggung jawab atas sebagian pesan, dibagi dengan ID topik dan ID sesi. Pod frontend mendistribusikan lalu lintas pesan di seluruh partisi. Meningkatkan jumlah partisi meningkatkan jumlah pesan yang dapat ditangani broker.
• Faktor redundansi: Jumlah replika backend (pod) yang akan disebarkan per partisi. Meningkatkan faktor redundansi meningkatkan jumlah salinan data untuk memberikan ketahanan terhadap kegagalan simpul dalam kluster.
• Pekerja: Jumlah pekerja yang akan dideploy pada setiap replika backend. Meningkatkan jumlah tenaga kerja per replika backend dapat meningkatkan jumlah pesan yang dapat ditangani oleh pod backend. Setiap pekerja dapat mengonsumsi hingga dua inti CPU paling banyak, jadi berhati-hatilah ketika Anda meningkatkan jumlah pekerja per replika agar tidak melebihi jumlah inti CPU dalam kluster.

Pertimbangan

Ketika Anda meningkatkan nilai kardinalitas, kapasitas broker untuk menangani lebih banyak koneksi dan pesan umumnya akan meningkat, dan dapat meningkatkan ketersediaan yang tinggi jika terjadi kegagalan pada pod atau node. Peningkatan kapasitas ini juga menyebabkan konsumsi sumber daya yang lebih tinggi. Jadi, ketika Anda menyesuaikan nilai kardinalitas, pertimbangkan pengaturan profil memori dan permintaan sumber daya CPU broker. Meningkatkan jumlah pekerja per replika frontend dapat membantu meningkatkan pemanfaatan inti CPU jika Anda menemukan bahwa pemanfaatan CPU frontend adalah hambatan. Meningkatkan jumlah pekerja backend dapat membantu throughput pesan jika pemanfaatan CPU backend menjadi hambatan.

Misalnya, jika kluster Anda memiliki tiga simpul, masing-masing dengan delapan inti CPU, maka atur jumlah replika frontend agar sesuai dengan jumlah simpul (3) dan atur jumlah pekerja menjadi 1. Atur jumlah partisi backend agar sesuai dengan jumlah simpul (3) dan atur pekerja backend ke 1. Atur faktor redundansi seperti yang diinginkan (2 atau 3). Tingkatkan jumlah pekerja frontend jika Anda menemukan bahwa pemanfaatan CPU frontend adalah hambatan. Ingatlah bahwa pekerja backend dan frontend mungkin bersaing untuk sumber daya CPU di antara mereka sendiri dan pod lainnya.

Mengonfigurasi profil memori

Profil memori menentukan penggunaan memori broker untuk lingkungan terbatas sumber daya. Anda dapat memilih dari profil memori yang telah ditentukan sebelumnya yang memiliki karakteristik penggunaan memori yang berbeda. Pengaturan profil memori digunakan untuk mengonfigurasi penggunaan memori replika frontend dan backend. Profil memori berinteraksi dengan pengaturan kardinalitas untuk menentukan total penggunaan memori broker.

Penting

Pengaturan ini mengharuskan Anda untuk 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 lebih lanjut, lihat Sesuaikan Broker Default.

Untuk mengonfigurasi pengaturan profil memori broker MQTT, tentukan bidang profil memori dalam spesifikasi sumber daya Broker selama penyebaran Operasi IoT.

Portal

Saat Anda menggunakan panduan berikut untuk mengoperasikan IoT, di bagian Konfigurasi, lihat di bagian konfigurasi broker MQTT dan temukan pengaturan profil memori. Di sini, Anda dapat memilih dari profil memori yang tersedia dalam daftar dropdown.

Azure CLI

Saat Anda menyebarkan Operasi IoT dengan menggunakan az iot ops create perintah , gunakan --broker-mem-profile parameter untuk menentukan pengaturan profil memori.

Misalnya, untuk menentukan profil memori sebagai Tiny, lihat perintah berikut (parameter lain dihilangkan untuk brevity):

az iot ops create ... --broker-mem-profile Tiny

Untuk mempelajari selengkapnya, lihat az iot ops create parameter opsional.

Ada profil memori yang telah ditentukan sebelumnya dengan karakteristik penggunaan memori yang berbeda untuk menerbitkan pesan. Tidak ada batasan jumlah sesi atau langganan yang dapat ditangani broker. Profil memori hanya mengatur penggunaan memori untuk lalu lintas PUBLISH.

Kecil

Gunakan profil ini ketika Anda memiliki sumber daya memori terbatas dan lalu lintas penerbitan klien rendah.

Saat Anda menggunakan profil ini:

• Penggunaan memori maksimum dari setiap replika frontend sekitar 99 MiB, tetapi penggunaan memori maksimum aktual mungkin lebih tinggi.
• Penggunaan memori maksimum dari setiap replika backend sekitar 102 MiB dikalikan dengan jumlah pekerja backend, tetapi penggunaan memori maksimum aktual mungkin lebih tinggi.
• Ukuran pesan maksimum adalah 4 MB.
• Ukuran maksimum buffer masuk untuk data PUBLISH adalah sekitar 16 MiB per pekerja backend. Namun, ukuran efektif mungkin lebih rendah karena mekanisme backpressure, yang diaktifkan ketika buffer mencapai 75% kapasitas yang menghasilkan ukuran buffer sekitar 12 MiB. Paket yang ditolak memiliki respons PUBACK dengan kode kesalahan Kuota terlampaui .

Rekomendasi saat Anda menggunakan profil ini:

• Hanya satu frontend yang harus digunakan.
• Klien tidak boleh mengirim paket besar. Anda hanya boleh mengirim paket yang lebih kecil dari 4 MiB.

Kurang Penting

Gunakan profil ini ketika Anda memiliki sumber daya memori terbatas dan klien menerbitkan paket kecil.

Saat Anda menggunakan profil ini:

• Penggunaan memori maksimum dari setiap replika frontend sekitar 387 MiB, tetapi penggunaan memori maksimum aktual mungkin lebih tinggi.
• Penggunaan memori maksimum dari setiap replika backend sekitar 390 MiB dikalikan dengan jumlah pekerja backend, tetapi penggunaan memori maksimum aktual mungkin lebih tinggi.
• Ukuran pesan maksimum adalah 16 MB.
• Ukuran maksimum buffer masuk untuk data PUBLISH adalah sekitar 64 MiB per pekerja backend. Namun, ukuran efektif mungkin lebih rendah karena mekanisme backpressure, yang diaktifkan ketika buffer mencapai 75% kapasitas yang menghasilkan ukuran buffer sekitar 48 MiB. Paket yang ditolak memiliki respons PUBACK dengan kode kesalahan Kuota terlampaui .

Rekomendasi saat Anda menggunakan profil ini:

• Hanya satu atau dua frontend yang harus digunakan.
• Klien tidak boleh mengirim paket besar. Anda hanya boleh mengirim paket yang lebih kecil dari 16 MiB.

Menengah

Gunakan profil ini saat Anda perlu menangani jumlah pesan klien yang sedang-sedang.

Profil sedang adalah pengaturan default.

• Penggunaan memori maksimum dari setiap replika frontend sekitar 1,9 GiB, tetapi penggunaan memori maksimum aktual mungkin lebih tinggi.
• Penggunaan memori maksimum dari setiap replika backend sekitar 1,5 GiB dikalikan dengan jumlah pekerja backend, tetapi penggunaan memori maksimum aktual mungkin lebih tinggi.
• Ukuran pesan maksimum adalah 64 MB.
• Ukuran maksimum buffer masuk untuk data PUBLISH adalah sekitar 576 MiB per pekerja backend. Namun, ukuran efektif mungkin lebih rendah karena mekanisme backpressure, yang diaktifkan ketika buffer mencapai 75% kapasitas yang menghasilkan ukuran buffer sekitar 432 MiB. Paket yang ditolak memiliki respons PUBACK dengan kode kesalahan Kuota terlampaui .

Tinggi

Gunakan profil ini saat Anda perlu menangani sejumlah besar pesan klien.

• Penggunaan memori maksimum dari setiap replika frontend sekitar 4,9 GiB, tetapi penggunaan memori maksimum aktual mungkin lebih tinggi.
• Penggunaan memori maksimum dari setiap replika backend sekitar 5,8 GiB dikalikan dengan jumlah pekerja backend, tetapi penggunaan memori maksimum aktual mungkin lebih tinggi.
• Ukuran pesan maksimum adalah 256 MB.
• Ukuran maksimum buffer masuk untuk data PUBLISH adalah sekitar 2 GiB per pekerja backend. Namun, ukuran efektif mungkin lebih rendah karena mekanisme tekanan balik, yang diaktifkan ketika buffer mencapai 75% kapasitas sehingga menghasilkan ukuran buffer sekitar 1,5 GiB. Paket yang ditolak memiliki respons PUBACK dengan kode kesalahan Kuota terlampaui .

Menghitung total penggunaan memori

Pengaturan profil memori menentukan penggunaan memori untuk setiap replika frontend dan backend dan berinteraksi dengan pengaturan kardinalitas. Anda dapat menghitung total penggunaan memori menggunakan rumus:

M_total = R_fe * M_fe + (P_be * RF_be) * M_be * W_be

Lokasi:

Variabel	Deskripsi
M_total	Total penggunaan memori
R_fe	Jumlah replika frontend
M_fe	Penggunaan memori setiap replika frontend
P_be	Jumlah partisi backend
RF_be	Faktor redundansi backend
M_be	Penggunaan memori setiap replika backend
W_be	Jumlah pekerja per replika backend

Misalnya jika Anda memilih profil Memori sedang , profil memiliki penggunaan memori frontend 1,9 GB dan penggunaan memori backend 1,5 GB. Asumsikan bahwa konfigurasi broker adalah 2 replika frontend, 2 partisi backend, dan faktor redundansi backend adalah 2. Total penggunaan memori adalah:

2 * 1,9 GB + (2 * 2) * 1,5 GB * 2 = 15,8 GB

Sebagai perbandingan, profil memori Tiny memiliki penggunaan memori frontend 99 MiB dan penggunaan memori backend 102 MiB. Jika Anda mengasumsikan konfigurasi broker yang sama, total penggunaan memori adalah:

2 * 99 MB + (2 * 2) * 102 MB * 2 = 198 MB + 816 MB = 1,014 GB.

Penting

Broker MQTT mulai menolak pesan ketika memori 75% penuh.

Kardinalitas dan batas sumber daya Kubernetes

Untuk mencegah kelaparan sumber daya di kluster, broker dikonfigurasi secara default untuk meminta batas sumber daya CPU Kubernetes. Menskalakan jumlah replika atau pekerja secara proporsional meningkatkan sumber daya CPU yang diperlukan. Kesalahan penyebaran akan muncul jika sumber daya CPU yang tersedia di kluster tidak mencukupi. Pemberitahuan ini membantu Anda menghindari situasi di mana kardinalitas broker yang diminta tidak memiliki sumber daya yang cukup untuk berjalan secara optimal. Ini juga membantu menghindari potensi persaingan CPU dan pengusiran pod.

Broker MQTT saat ini meminta satu (1.0) unit CPU per pekerja frontend dan dua unit CPU (2.0) per pekerja backend. Untuk informasi selengkapnya, lihat unit sumber daya CPU Kubernetes.

Misalnya, kardinalitas berikut akan meminta sumber daya CPU berikut:

• Untuk bagian depan: 2 unit CPU per pod di bagian depan, total 6 unit CPU.
• Untuk backend: 4 unit CPU per pod backend (untuk dua pekerja backend), kali 2 (faktor redundansi), kali 3 (jumlah partisi), total 24 unit CPU.

{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

Untuk menonaktifkan pengaturan ini, atur bidang generateResourceLimits.cpu ke Disabled di sumber daya Broker.

Portal

Mengubah kolom generateResourceLimits tidak didukung di Azure Portal. Untuk menonaktifkan pengaturan ini, gunakan Azure CLI.

Azure CLI

Siapkan file konfigurasi Broker dalam format JSON, yang mencakup properti yang diinginkan dari sumber daya Resource Managermicrosoft.iotoperations/instances/brokers, dan atur bidang generateResourceLimits.cpu ke Disabled. Contohnya:

{
  "generateResourceLimits": {
    "cpu": "Disabled"
  }
}

Kemudian, menyebarkan Pengoperasian IoT dengan menggunakan perintah az iot ops create dengan bendera --broker-config-file, seperti perintah berikut (parameter lain dihilangkan untuk singkatnya):

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

Untuk mempelajari selengkapnya, lihat Dukungan Azure CLI untuk konfigurasi broker MQTT tingkat lanjut.

Penyebaran multi-node

Untuk memastikan ketersediaan dan ketahanan tinggi dengan penyebaran multi-simpul, broker IoT Operations MQTT secara otomatis menetapkan aturan anti-afinitas untuk pod backend.

Aturan ini telah ditentukan sebelumnya dan tidak dapat dimodifikasi.

Tujuan aturan anti-afinitas

Aturan anti-afinitas memastikan bahwa pod backend dari partisi yang sama tidak berjalan pada simpul yang sama. Kemampuan ini membantu mendistribusikan beban dan memberikan ketahanan terhadap kegagalan simpul. Secara khusus, pod backend dari partisi yang sama memiliki ketidakcocokan atau anti-afinitas di antara satu sama lain.

Memverifikasi pengaturan anti-afinitas

Untuk memverifikasi pengaturan anti-afinitas untuk pod backend, gunakan perintah berikut:

kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15

Output menunjukkan konfigurasi anti-afinitas, mirip dengan contoh berikut:

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: chain-number
            operator: In
            values:
            - "1"
        topologyKey: kubernetes.io/hostname
      weight: 100

Aturan ini adalah satu-satunya aturan anti-afinitas yang ditetapkan untuk broker.

Konten terkait

• Mengonfigurasi listener untuk broker MQTT