Dela via

Azure IoT Operations inbyggd lokal MQTT-koordinator

  • Artikel

Viktigt!

Den här sidan innehåller instruktioner för att hantera Azure IoT Operations-komponenter med hjälp av Kubernetes-distributionsmanifest, som finns i förhandsversion. Den här funktionen har flera begränsningar och bör inte användas för produktionsarbetsbelastningar.

Juridiska villkor för Azure-funktioner i betaversion, förhandsversion eller som av någon annan anledning inte har gjorts allmänt tillgängliga ännu finns i kompletterande användningsvillkor för Microsoft Azure-förhandsversioner.

Azure IoT Operations har en MQTT-mäklare som är i företagsklass och kompatibel med standarder. MQTT-koordinatorn är skalbar, högtillgänglig och Kubernetes-inbyggd. Den tillhandahåller meddelandeplanet för IoT-åtgärder, möjliggör dubbelriktad gräns-/molnkommunikation och driver händelsedrivna program vid gränsen.

MQTT-efterlevnad

MQTT har dykt upp som det gemensamma språk som används bland protokoll i IoT-utrymmet. MQTT:s enkla design gör det möjligt för en enda mäklare att betjäna tiotusentals klienter samtidigt, med lätt publiceringsprenumerering, skapande och hantering av ämnen. Många IoT-enheter har stöd för MQTT internt. Underordnade översättningsgatewayer rationaliserar den långa svansen av IoT-protokoll till MQTT.

MQTT-asynkron meddelandekö ligger till grund för meddelandelagret i IoT Operations och stöder både MQTT v3.1.1 och MQTT v5. Mer information om MQTT-funktioner som stöds finns i MQTT-funktionsstöd i MQTT Broker.

Arkitektur

MQTT-asynkron meddelandekö har två huvudlager:

  • Tillståndslöst klientdelslager
  • Tillståndskänsligt och fragmenterat serverdelslager

Klientdelsskiktet hanterar klientanslutningar och begäranden och dirigerar dem till serverdelen. Serverdelslagret partitioneras data efter olika nycklar, till exempel ett klient-ID för klientsessioner och ett ämnesnamn för ämnesmeddelanden. Den använder kedjereplikering för att replikera data inom varje partition.

Arkitekturens mål är:

  • Feltolerans och isolering: Meddelandepublicering fortsätter om serverdelspoddar misslyckas och förhindrar att fel sprids till resten av systemet.
  • Återställning av fel: Automatisk felåterställning utan operatörsintervention.
  • Ingen meddelandeförlust: Leverans av meddelanden om minst en klientdelspodd och en serverdelspodd i en partition körs.
  • Elastisk skalning: Horisontell skalning av publicering och prenumererande dataflöde för att stödja gräns- och molndistributioner.
  • Konsekvent prestanda i stor skala: Begränsa kostnaderna för meddelandefördröjning på grund av kedjereplikering.
  • Drifts enkelhet: Minsta beroende av externa komponenter för att förenkla underhåll och komplexitet.

Konfiguration

För konfiguration består MQTT-asynkronisering av flera kubernetes-anpassade resurser som definierar olika aspekter av mäklarens beteende och funktioner:

  • Huvudresursen är Broker, som definierar globala inställningar som kardinalitet, minnesanvändningsprofil och diagnostikinställningar.
  • En Broker-resurs kan ha upp till tre BrokerListeners, som var och en lyssnar efter inkommande MQTT-anslutningar på den angivna tjänsttypen (NodePort, LoadBalancereller ClusterIP). Varje BrokerListener-resurs kan ha flera portar.
  • Varje port i en BrokerListener-resurs kan associeras med en BrokerAuthentication-resurs och en BrokerAuthorization-resurs . Dessa autentiserings- och auktoriseringsprinciper avgör vilka klienter som kan ansluta till porten och vilka åtgärder de kan utföra på koordinatorn.

Relationen mellan Broker och BrokerListener är en-till-många. Relationen mellan BrokerListener och BrokerAuthentication/BrokerAuthorization är många-till-många. Ett entitetsrelationsdiagram för dessa resurser är:

Diagram som visar koordinatorresursmodellen.

Som standard distribuerar IoT Operations en standard broker, en standard BrokerListener och en standard BrokerAuthentication. Alla dessa resurser heter standard. Tillsammans tillhandahåller dessa resurser en grundläggande MQTT-koordinatorkonfiguration som krävs för att IoT-åtgärder ska fungera. Standardinställningen är:

Diagram som visar standard asynkrona resurser och relationer mellan dem.

Viktigt!

För att förhindra oavsiktliga avbrott i kommunikationen mellan interna IoT Operations-komponenter rekommenderar vi att du inte ändrar någon standardkonfiguration.

Om du vill anpassa MQTT-koordinatordistributionen lägger du till nya resurser som BrokerListeners, BrokerAuthentication och BrokerAuthorization till standard broker.

Själva Broker-resursen är oföränderlig och kan inte ändras efter distributionen, men den behöver bara anpassas i avancerade scenarier. Mer information om hur du anpassar Broker-resursen finns i Anpassa standardutjämning.

I en fullständig distribution kan du ha flera BrokerListeners, var och en med flera portar, och varje port kan ha olika BrokerAuthentication- och BrokerAuthorization-resurser associerade med den.

Om du till exempel börjar med standardkonfigurationen lägger du till:

  • En LoadBalancer BrokerListener med namnet example-lb-listener, med de två portarna 1883 och 8883.
  • En NodePort BrokerListener med namnet example-nodeport-listener, med den enda porten 1884 (nodePort 31884).
  • En BrokerAuthentication-resurs med namnet example-authn med en anpassad autentiseringsmetod.
  • En BrokerAuthorization-resurs med namnet example-authz med dina anpassade auktoriseringsinställningar.

Om du sedan konfigurerar alla nya portar med samma BrokerAuthentication- och BrokerAuthorization-resurser ser konfigurationen ut så här:

Diagram som visar en fullständig distribution av anpassad koordinator och relationer mellan var och en.

På så sätt behåller du standardkonfigurationen intakt och lägger till nya resurser för att anpassa MQTT-koordinatordistributionen efter dina behov.

Standardresurs för asynkron koordinator

Varje IoT Operations-distribution kan bara ha en broker och den måste ha namnet standard. Standardresursen broker krävs för att IoT-åtgärder ska fungera. Den är oföränderlig och kan inte ändras efter distributionen.

Varning

Ta inte bort standardresursen broker. Detta stör kommunikationen mellan interna IoT Operations-komponenter och distributionen slutar fungera.

Anpassa standardutjämning

Det krävs inte att du anpassar standardresursen broker för de flesta installationer. Inställningarna som kräver anpassning är:

  • Kardinalitet: Avgör koordinatorns kapacitet att hantera fler anslutningar och meddelanden och förbättrar hög tillgänglighet om det uppstår podd- eller nodfel.
  • Minnesprofil: Anger den maximala minnesanvändningen för asynkron meddelandekö och hur du hanterar minnesanvändning när asynkron meddelandekö skalar upp.
  • Diskbackad meddelandebuffert: Konfiguration för buffring av meddelanden till disk när RAM-minnet fylls.
  • Diagnostikinställningar: Konfiguration för diagnostikinställningar som loggnivå och slutpunkt för mått.
  • Avancerade MQTT-klientalternativ: Konfiguration för avancerade MQTT-klientalternativ som sessionsförfallodatum, meddelandeförfallodatum och inställningar för att hålla vid liv.
  • Kryptering av intern trafik: Konfiguration för kryptering av intern trafik mellan klientdels- och serverdelspoddar för koordinatorer.

Du kan endast anpassa standardkoordinatorn under den inledande distributionstiden med hjälp av Azure CLI eller Azure Portal. En ny distribution krävs om du behöver olika konfigurationsinställningar för Broker.

Så här anpassar du standardutjämningen under distributionen:

När du följer guiden för att distribuera IoT-åtgärder går du till avsnittet Konfiguration och tittar under MQTT-koordinatorkonfiguration. Här kan du anpassa inställningar för kardinalitet och minnesprofil. Om du vill konfigurera andra inställningar, inklusive diskstödd meddelandebuffert och avancerade MQTT-klientalternativ, använder du Azure CLI.

Visa standardinställningar för asynkron meddelandekö

Så här visar du inställningarna för standardsynkron meddelandekö:

  1. I Azure Portal går du till din IoT Operations-instans.
  2. Under Komponenter väljer du MQTT Broker.
  3. Under Koordinatorinformation väljer du JSON-vy.

Relaterat innehåll