Azure IoT İşlemleri için dağıtım planlaması

Birçok Azure IoT İşlemleri ayarı dağıtım zamanında düzeltilir ve yalnızca yeniden dağıtılarak değiştirilebilir. Dağıtmadan önce küme topolojinizi, aracı kardinalitenizi, bellek profilinizi ve ihtiyacınız olan isteğe bağlı aracı ayarlarını planlayın. Bu makale, vermeniz gereken kararları özetlemektedir.

Mimariyi anlama

Azure IoT İşlemleri, Azure Arc özellikli bir kümeye dağıtılan modüler, Kubernetes'e özel hizmetler kümesidir. Önemli bileşenler şunlardır:

Bileşen Purpose
MQTT aracısı Uç mesajlaşma için yüksek performanslı MQTT 3.1.1 ve 5 aracısı
OPC UA bağlayıcısı OPC UA sunucularından veri toplar ve MQTT'de yayımlar
Veri akışları Verileri bulut uç noktalarına yönlendirir, dönüştürür ve iletir
Azure Cihaz Kayıt Defteri Cihazlar, varlıklar ve şemalar için bulut tabanlı kayıt defteri
Akri hizmetleri Cihaz bulma ve protokol bağdaştırıcıları
Durum deposu MQTT aracısında anahtar-değer kalıcılığı katmanı

Belgelerde iki terim kullanılır:

  • Dağıtım — Örnek, Arc uzantıları, özel konumlar ve yapılandırılabilir tüm kaynaklar (varlıklar, cihazlar, veri akışları).
  • Örnek — Hizmetleri paketleyen üst kaynak.

Küme topolojinizi seçin

Dağıtmadan önce tek düğümlü veya çok düğümlü bir kümeye ihtiyacınız olup olmadığına karar verin. Bu karar, donanım gereksinimlerini ve aracı kardinalite ayarlarını belirler.

Topoloji Kullanım örneği En düşük donanım
Tek düğümlü Yüksek kullanılabilirlik gerektirmeyen daha küçük dağıtımlar 4 vCPU, 16 GB RAM, 30 GB depolama alanı
Çok düğümlü (3-5 düğüm) Yüksek kullanılabilirlik ve daha yüksek aktarım hızı gereksinimleri 8 vCPU, düğüm başına 32 GB RAM

Important

Kardinalite yalnızca dağıtım zamanında ayarlanır. Kardinalite ayarlarının değiştirilmesi gerekiyorsa yeni bir dağıtım gereklidir.

Aracı kardinalitesini anlamak

Kardinalite, broker dağıtımındaki ön uç replikalarının, ön uç çalışanlarının, arka uç bölümlerinin ve arka uç çalışanlarının sayısıdır. Kardinalite, aracının yatay olarak nasıl ölçeklendirileceğini ve pod ya da düğüm arızalarına karşı ne kadar dayanıklı olacağını belirler.

MQTT aracısı iki katmanlı bir mimariye sahiptir: ön uç podları istemci bağlantılarını ve protokol işlemeyi, arka uç podları ise ileti depolamayı ve teslimi işler. Her katmanın ölçeğini anlamak, kapasite planlaması için önemlidir.

Frontend

Ön uç podları MQTT istemci bağlantılarını kabul eder ve iletileri arka uça iletir. Ön uç podları iletileri kendileri depolamaz. Ön uç katmanı için iki ana ayar vardır:

  • Replika: Dağıtılacak ön uç podlarının sayısı. Daha fazla front-end replikası eklemek, broker’ın işleyebileceği eşzamanlı istemci bağlantılarının sayısını artırır ve front-end pod’larından biri arızalanırsa yüksek kullanılabilirlik sağlar.
  • Çalışanlar: Ön uç podu başına mantıksal çalışan sayısı. Daha fazla çalışan eklemek, ön uç podunun daha fazla CPU çekirdeği kullanmasına olanak tanır. Her çalışan en fazla bir CPU çekirdeği kullanabilir.

Arka uç zinciri

Arka uç podları ileti depolama ve ileti teslimini yönetir. Arka uç katmanı için üç ana ayar vardır:

  • Bölümler: Dağıtılacak bölüm sayısı. Bölümler, ileti aktarım hızı için yatay ölçeklendirme birimidir. Parçalama adlı bir işlemle, her bölüm iletilerin konu ve oturuma göre parçalanmış bir bölümünü işler. Ön uç podları, ileti trafiğini bölümler arasında dağıtır. Daha fazla bölüm eklemek, aracının işleyebileceği toplam ileti aktarım hızını artırır.
  • Yedeklilik faktörü: Bölüm başına dağıtılacak arka uç podlarının sayısı. Yedeklilik faktörünün artırılması, kümedeki düğüm hatalarına karşı dayanıklılık sağlamak için veri kopyalarının sayısını artırır.
  • çalışanlar: Arka uç podu başına çalışan sayısı. Çalışanlar bir bölümdeki dikey ölçeklendirme birimidir; daha fazla çalışan eklemek, arka uç podunun aynı düğümde daha fazla CPU çekirdeği kullanmasına olanak tanır. Her çalışan en fazla iki CPU çekirdeği kullanabilir, bu nedenle kümedeki CPU çekirdeği sayısını aşmamak için çoğaltma başına çalışan sayısını artırdığınızda dikkatli olun.

Note

Bölüm ölçeklendirmenin etkinliği, konu alanının bölümlere ne kadar eşit yayıldığına bağlıdır. Yüksek oranda dengesiz bir dağıtım, tek bir bölümde etkin noktalar oluşturabilir.

Important

Arka uç yedeklilik faktörü 2 veya daha büyük olmalıdır. Aracı, yüksek erişilebilirlik ve aşamalı güncelleme desteği için bölüm başına en az iki arka uç replikası gerektirir. Yedeklilik faktörünü 1 olarak ayarlamak, dağıtım doğrulama hatasına yol açar.

Aktarım hızı tahmini

Tek bir bölümün performansı büyük ölçüde üzerinde çalıştığı düğümün CPU özelliklerine bağlıdır. Bir kural olarak, 2 GHz CPU üzerinde 8 KB yük (~4-GHz turbo) ile bölüm başına saniyede yaklaşık 5.000 ila 6.000 QoS 1 ileti bekleyin. Gerçek dünya performansı birçok faktöre bağlıdır, bu nedenle bu sayıyı yalnızca kapasite planlaması için başlangıç noktası olarak kullanın.

Ayrıntılı karşılaştırma verileri için bkz. MQTT Aracısı performans karşılaştırması.

Tek düğümlü öneriler

  • Ön uç çoğaltma sayısı: 1 olarak ayarlayın.
  • Ön uç çalışanları: Düğüm başına CPU çekirdeği sayısının yarısına ayarlayın.
  • Arka uç çoğaltmaları (yedeklilik faktörü): Broker'ın aşamalı güncellemeler gerçekleştirebilmesi için en az 2 olarak ayarlayın.

Örnek: tek düğüm, 4 CPU çekirdeği

Ön uç ayarı Değer Arka uç ayarı Değer
Replikalar 1 Yedeklilik faktörü 2
Çalışanlar 2 Çalışanlar 1
Partitions 1

Çok düğümlü öneriler

En iyi performans için aşağıdaki değerler önerilir. Trafiğin düşük olduğu büyük kümeler için bu değerler sorunlara neden olmadan önerilerden daha düşük olarak ayarlanabilir. Bellek (RAM) ve performans özellikleri gibi diğer önemli noktalar aşağıdaki bölümlerde ele alınmalıdır. Performansı onaylamak için yapılandırmanızı her zaman beklenen iş yüküyle test edin.

  • Ön uç çoğaltmaları: Kümedeki düğüm sayısına eşit olarak ayarlayın.
  • Ön uç çalışanları: Düğüm başına CPU çekirdeği sayısının yarısına ayarlayın.
  • Arka uç çoğaltmaları (yedeklilik faktörü): Yedeklilik ve sıralı güncelleştirme desteği için 2 olarak ayarlayın.
  • Arka uç bölümleri: Kümedeki düğüm sayısına eşit olarak ayarlayın.
  • Arka uç çalışanları: Düğüm başına CPU çekirdeği sayısının yarısına ayarlayın.

Örnek: 3 düğümlü küme, düğüm başına 8 CPU çekirdeği

Ön yüz ayarı Değer Arka uç ayarı Değer
Replikalar 3 Yedeklilik faktörü 2
Çalışanlar 4 Çalışanlar 4
Partitions 3

Örnek: 5 düğümlü küme, düğüm başına 16 CPU çekirdeği

Ön yüz ayarı Değer Arka uç ayarı Değer
Replikalar 5 Yedeklilik faktörü 2
Çalışanlar 8 Çalışanlar 8
Partitions 5

Important

Düğüm başına ön uç ve arka uç çalışanlarının toplam sayısı, bu düğümde kullanılabilen CPU çekirdeği sayısını aşmamalıdır. Kullanılabilir çekirdek sayısından daha fazla iş parçacığı tahsis etmek, CPU çekişmesine yol açabilir ve performansı düşürebilir.

CPU kaynak sınırları

Kümede kaynak açlığını önlemek için aracı, kardinalite ayarlarına göre Kubernetes CPU kaynak sınırları istemek üzere yapılandırılabilir. Etkinleştirildiğinde, replikalar veya işçi sayısını ölçeklendirmek, gereksinim duyulan CPU kaynaklarını orantılı olarak artırır.

Important

için generateResourceLimits.cpu varsayılan değer dağıtım yöntemine bağlıdır:

  • Azure CLI (az iot ops create): Disabled VARSAYıLAN olarak, CPU isteklerinin kullanılabilir kaynakları aşabileceği tek düğümlü kümeler gibi kaynak kısıtlanmış kümelerde dağıtım hatalarından kaçınmak için.
  • REST API, Bicep ve ARM şablonları: Enabled varsayılan olarak. Açıkça ayarlamadan generateResourceLimits.cpubu yöntemlerle dağıtım yaparsanız, CPU kaynak sınırları otomatik olarak uygulanır.

CPU kaynak sınırlarını etkinleştirirseniz kümenizin kardinalite yapılandırmanıza göre aracının isteklerini karşılamak için yeterli CPU kaynağına sahip olduğundan emin olun.

REST API, Bicep ve ARM şablonları için varsayılan değer Aracı API belirtiminde tanımlanır.

MQTT aracısı, yapılandırılan çalışan sayısına göre pod başına CPU kaynakları ister:

  • Ön uç podları: Çalışan başına 1,0 CPU
  • Arka uç podları: Çalışan başına 2,0 CPU

Toplam CPU gereksinimlerini hesaplamak için aşağıdaki formülleri kullanın:

Bileşen Formula
Ön uç CPU replicas × frontend.workers × 1.0 CPU
Arka uç CPU partitions redundancyFactor × × backend.workers × 2.0 CPU
Toplam aracı CPU Ön Uç CPU + Arka Uç CPU

Caution

Aracı, kümede CPU kullanan tek bileşen değildir. Diğer Azure IoT İşlemleri bileşenleri (veri akışı altyapısı, OPC UA bağlayıcısı ve sistem podları gibi) genellikle toplam 200-300 m olan CPU kaynaklarını da ayırır. Küme kapasitesini planlarken, broker'ın CPU gereksinimlerini göz önünde bulundurarak bu overhead'i hesaba kattığınızdan emin olun. Tüm podlar tarafından istenen toplam CPU, kümenizdeki kullanılabilir CPU'yu aşarsa broker podlar Pending durumunda takılır.

Örnek: küçük küme

Aşağıdaki kardinaliteye sahip düğüm başına 4 CPU çekirdeğine (toplam 8 çekirdek) sahip 2 düğümlü bir küme düşünün:

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

Aracı istekleri:

  • Ön uç CPU: 2 çoğaltma × 2 çalışan × 1.0 = 4.0 CPU
  • Arka uç CPU: 1 bölüm × 2 RF × 1 çalışan × 2.0 = 4.0 CPU
  • Toplam aracı CPU: 8.0 CPU

Bu yapılandırma yalnızca 8 çekirdekli bir kümede 8,0 CPU ister ve diğer Azure IoT İşlemleri bileşenleri (200-300m) veya Kubernetes sistem podları için hiçbir şey bırakmaz. Aracı podları, Insufficient cpu hatalarıyla Pending durumunda kalır.

Bu sorunu çözmek için daha fazla düğüm ekleyin, düğüm başına çekirdek sayısını artırın veya aracı kardinalitesini azaltın.

Örnek: daha büyük dağıtım

Aşağıdaki kardinalite önemli ölçüde daha fazla CPU kaynağı ister:

{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}
  • Ön uç CPU: 3 çoğaltma × 2 çalışan × 1.0 = 6.0 CPU
  • Arka uç CPU: 3 bölüm × 2 RF × 2 çalışan × 2.0 = 24.0 CPU
  • Toplam aracı CPU: 30,0 CPU

Bir kümede, yalnızca aracı podları için en az 30 kullanılabilir CPU çekirdeği gerekir; ayrıca diğer Azure IoT İşlemleri bileşenleri ve Kubernetes sistem podları için de ek kapasite payı olmalıdır.

CPU kaynak sınırı yapılandırması

CPU kaynak sınırları, Broker kaynağındaki generateResourceLimits.cpu alanı tarafından kontrol edilir. Bu yapılandırma, Azure IoT İşlemleri’ı az iot ops create komutunu kullanarak dağıtırken yalnızca --broker-config-file bayrağını kullanmanız durumunda desteklenir. Daha fazla bilgi için bkz. Gelişmiş MQTT aracı yapılandırması için Azure CLI desteği.

GenerateResourceLimits API başvuru belgesini takip ederek bir Broker yapılandırma dosyası hazırlayın. Aşağıdaki örneklerde iki olası değer gösterilmektedir:

{
  "generateResourceLimits": {
    "cpu": "Enabled"
  }
}

Veya

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

Bellek profilinizi seçin

Bellek profili, aracı tarafından kabul edilen en yüksek MQTT ileti boyutunu, boşta bellek kullanımını ve her podun maksimum bellek kullanımını denetler. Beklenen ileti boyutlarınıza ve aktarım hızınıza göre dağıtımdan önce doğru bellek profiline karar verin.

Bellek profili İleti boyutu üst sınırı Boşta kalan ön uç belleği (pod başına) Pod başına en fazla ön uç belleği Boşta arka uç belleği (pod başına) Maksimum arka uç belleği (pod başına) Kullanım örneği
Küçük 4 MB ~29 MiB ~99 MiB ~41 MiB ~102 MiB Düşük trafik, yalnızca küçük paketler
Low 16MB ~33 MiB ~387 MiB ~66 MiB ~390 MiB Sınırlı bellek, küçük paketler
Orta (varsayılan) 64 MB ~169 MiB ~1,9 GiB ~211 MiB ~1,5 GiB Trafiği ve ileti boyutlarını denetleme
Yüksek 256MB ~4,9 GiB ~4,9 GiB ~5,8 GiB ~5,8 GiB Yüksek aktarım hızı, büyük iletiler

Note

Tablodaki bellek değerleri pod başınadır. Bir pod içindeki tüm çalışanlar aynı bellek ayırmayı paylaşır; daha fazla çalışan eklemek pod'un bellek sınırını artırmaz.

Warning

Bellek kullanımı 75% kapasiteye ulaştığında aracı iletileri reddeder. Beklenen ileti boyutlarınız ve aktarım hızınız için yeterli boşluk içeren bir profil seçin.

Giriş arabelleği ve geri basıncı

Her bellek profili, her bir arka uç çalışanı için PUBLISH verisinin azami gelen arabellek boyutunu tanımlar. Arabellek kapasitenin %75’ine ulaştığında, aracı geri basınç mekanizmalarını etkinleştirir ve gelen iletileri reddetmeye başlar. Reddedilen paketler , Kota aşıldı hata koduyla bir PUBACK yanıtı alır.

Aşağıdaki tablo, her profil için çalışan başına giriş arabelleği boyutlarını gösterir:

Bellek profili Maksimum gelen tampon (her çalışan için) Etkili arabellek (75% geri basınçta)
Küçük ~16 MiB ~12 MiB
Low ~64 MiB ~48 MiB
Medium ~576 MiB ~432 MiB
Yüksek ~2 GiB ~1,5 GiB

Bellek profili seçerken şunları göz önünde bulundurun:

  • Küçük: Yalnızca bir ön uç kullanılmalıdır. Yalnızca 4 MiB'den küçük paketleri gönderin.
  • Düşük: Yalnızca bir veya iki ön yüz kullanılmalıdır. Yalnızca 16 MiB'den küçük paketleri gönderin.
  • Orta: Orta düzeyde ileti boyutlarına sahip çoğu üretim iş yükü için uygundur.
  • Yüksek: Büyük iletileri veya büyük arabelleklerle yüksek aktarım hızını işlemeniz gerektiğinde kullanın.

Toplam aracı belleği hem bellek profiline hem de kardinaliteye (ön uç çoğaltmalarının sayısı, arka uç bölümleri ve yedeklilik faktörü) bağlıdır. Daha fazla pod daha fazla toplam bellek anlamına gelir. Farklı yapılandırmalarda ölçülen temel kaynak tüketimi için bkz. Temel kaynak profilleri.

Toplam bellek kullanımını hesaplama

Toplam bellek kullanımını şu formülle hesaplayabilirsiniz:

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

Where:

Variable Description
M_total Toplam bellek kullanımı
R_fe Ön uç çoğaltmalarının sayısı
M_fe Her ön uç replikasının bellek kullanımı
P_be Arka uç bölümlerinin sayısı
RF_be Arka uç yedeklilik faktörü
M_be Her arka uç kopyasının bellek kullanımı
W_be Arka uç kopyası başına düşen çalışan sayısı

Örneğin Orta bellek profilini seçerseniz, profilin ön uç bellek kullanımı 1,9 GiB ve arka uç bellek kullanımı 1,5 GiB olur. Aracı yapılandırmasının 2 ön uç replikası, 2 arka uç bölümü ve 2 arka uç yedekleme çarpanı olduğunu varsayalım. Toplam bellek kullanımı:

M_total = (2 × 1.9 GiB) + (2 × 2 × 1.5 GiB × 2)
        = 15.8 GiB

Buna karşılık , Tiny bellek profili 99 MiB ön uç bellek kullanımına ve 102 MiB arka uç bellek kullanımına sahiptir. Aynı aracı yapılandırmasıyla toplam bellek kullanımı şu şekildedir:

M_total = (2 × 99 MiB) + (2 × 2 × 102 MiB × 2)
        = 198 MiB + 816 MiB
        = 1014 MiB (≈ 1.0 GiB)

Bellek profili yapılandırması

Komutunu kullanarak az iot ops create IoT İşlemlerini dağıttığınızda parametresi --broker-mem-profile bellek profili ayarlarını belirtir.

Örneğin, aşağıdaki komut bellek profilini Tiny olarak ayarlar (diğer parametreler kısa süre için atlanır):

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

Daha fazla bilgi edinmek için bkz az iot ops create . isteğe bağlı parametreler.

İsteğe bağlı aracı ayarları

Aşağıdaki aracı ayarları da dağıtım zamanında yapılandırılır ve daha sonra değiştirilemez. Senaryonuz için geçerliyse bunları gözden geçirin:

  • Disk tabanlı mesaj arabelleği — Abone kuyrukları kullanılabilir belleği aştığında iletileri diskte arabelleğe alın. Kalıcı oturumlar ve bağlantı zorlukları için kullanışlıdır.
  • Kalıcılık — Kritik aracı yazılım verilerini, yeniden başlatmalardan sonra da korumak için diske yazın.
  • Tanılama — MQTT aracısı için ölçümleri, günlükleri ve kendi kendine denetim yoklamalarını yapılandırın.
  • Gelişmiş MQTT seçenekleri — Oturum süre sonunu, ileti süre sonunu, abone kuyruğu sınırlarını ve etkin tutma ayarlarını özelleştirin.
  • İç trafik şifrelemesi — Broker ön uç ve arka uç pod’ları arasındaki iç trafik şifrelemesini yapılandırın (varsayılan olarak etkin).

Sonraki Adımlar

  • Last updated on