Wbudowany lokalny broker MQTT operacji usługi Azure IoT
Ważne
Ta strona zawiera instrukcje dotyczące zarządzania składnikami operacji usługi Azure IoT przy użyciu manifestów wdrażania platformy Kubernetes, które są w wersji zapoznawczej. Ta funkcja jest udostępniana z kilkoma ograniczeniami i nie powinna być używana w przypadku obciążeń produkcyjnych.
Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.
Usługa Azure IoT Operations oferuje broker MQTT klasy korporacyjnej zgodny ze standardami, który jest skalowalny, wysoce dostępny i natywny dla platformy Kubernetes. Zapewnia płaszczyznę obsługi komunikatów dla operacji usługi Azure IoT, umożliwia dwukierunkową komunikację brzegową/chmurę i obsługuje aplikacje sterowane zdarzeniami na brzegu sieci.
Zgodność Z MQTT
Transport telemetrii kolejki komunikatów (MQTT) pojawił się jako franka w protokołach w przestrzeni IoT. Prosty projekt MQTT umożliwia jednemu brokerowi jednoczesne obsługiwanie dziesiątek tysięcy klientów z uproszczonym tworzeniem tematów publikowania i subskrybowania. Wiele urządzeń IoT obsługuje natywnie gotowe do użycia MQTT, a długi ogon protokołów IoT jest racjonalizowany do MQTT przez bramy tłumaczenia podrzędnego.
Broker MQTT stanowi podstawę warstwy obsługi komunikatów w operacjach IoT i obsługuje zarówno MQTT v3.1.1, jak i MQTT v5. Aby uzyskać więcej informacji na temat obsługiwanych funkcji MQTT, zobacz Obsługa funkcji MQTT w brokerze MQTT.
Architektura
Broker MQTT ma dwie główne warstwy:
- Warstwa frontonu bezstanowego.
- Warstwa zaplecza stanowego i podzielonego na fragmenty.
Warstwa frontonu obsługuje połączenia i żądania klientów oraz kieruje je do zaplecza. Warstwa zaplecza partycjonuje dane według różnych kluczy, takich jak identyfikator klienta dla sesji klienta i nazwa tematu dla komunikatów tematu. Używa replikacji łańcucha do replikowania danych w ramach każdej partycji.
Cele architektury to:
- Odporność na uszkodzenia i izolacja: publikowanie komunikatów będzie kontynuowane, jeśli zasobniki zaplecza kończą się niepowodzeniem i uniemożliwiają propagację awarii do pozostałej części systemu
- Odzyskiwanie po awarii: Automatyczne odzyskiwanie po awarii bez interwencji operatora
- Brak utraty komunikatów: Dostarczanie komunikatów, jeśli co najmniej jeden zasobnik frontonu i jeden zasobnik zaplecza w partycji jest uruchomiony
- Elastyczne skalowanie: skalowanie w poziomie publikowania i subskrybowania przepływności w celu obsługi wdrożeń brzegowych i w chmurze
- Spójna wydajność na dużą skalę: ogranicz obciążenie opóźnienia komunikatów z powodu replikacji łańcuchowej
- Prostota operacyjna: Minimalna zależność od składników zewnętrznych w celu uproszczenia konserwacji i złożoności
Konfigurowanie
W przypadku konfiguracji broker MQTT składa się z kilku zasobów niestandardowych platformy Kubernetes, które definiują różne aspekty zachowania i funkcjonalności brokera.
- Głównym zasobem jest Broker, który definiuje ustawienia globalne, takie jak kardynalność, profil użycia pamięci i ustawienia diagnostyczne.
- Broker może mieć do trzech elementów BrokerListener, z których każdy nasłuchuje przychodzących połączeń MQTT w określonym typie usługi (NodePort, LoadBalancer lub ClusterIP). Każdy element BrokerListener może mieć wiele portów.
- Każdy port w elemecie BrokerListener może być skojarzony z zasobem BrokerAuthentication i zasobem BrokerAuthorization . Są to zasady uwierzytelniania i autoryzacji, które określają, którzy klienci mogą łączyć się z portem i jakie akcje mogą wykonywać na brokerze.
Tak więc relacja między brokerem i brokerlistenerem to jeden do wielu, a relacja między brokerlistener i brokerAuthentication/BrokerAuthorization to wiele do wielu. Diagram relacji jednostki (ERD) dla tych zasobów jest następujący:
Domyślnie operacje usługi Azure IoT wdraża domyślnego brokera, domyślnego elementu BrokerListener i domyślnego brokeraAuthentication. Wszystkie te zasoby mają nazwę domyślną. Razem te zasoby zapewniają podstawową konfigurację brokera MQTT wymaganą do działania operacji usługi Azure IoT. Domyślna konfiguracja jest następująca:
Ważne
Aby zapobiec niezamierzonym przerwom w komunikacji między składnikami wewnętrznymi operacji usługi Azure IoT, zalecamy, aby nie modyfikować żadnej konfiguracji domyślnej.
Aby dostosować wdrożenie brokera MQTT, dodaj nowe zasoby, takie jak BrokerListeners, BrokerAuthentication i BrokerAuthorization, do domyślnego brokera.
Sam zasób brokera jest niezmienny i nie można go modyfikować po wdrożeniu, ale wymaga tylko dostosowania w zaawansowanych scenariuszach. Aby dowiedzieć się więcej na temat dostosowywania zasobu brokera, zobacz Dostosowywanie domyślnego brokera.
W pełnym wdrożeniu może być wiele elementów BrokerListener, z których każdy ma wiele portów, a każdy port może mieć skojarzone różne zasoby BrokerAuthentication i BrokerAuthorization.
Na przykład, począwszy od domyślnej konfiguracji, należy dodać:
- Element BrokerListener loadBalancer o nazwie example-lb-listener z dwoma portami 1883 i 8883
- Element NodePort BrokerListener o nazwie example-nodeport-listener z pojedynczym portem 1884 (nodePort 31884)
- Zasób BrokerAuthentication o nazwie example-authn z niestandardową metodą uwierzytelniania
- Zasób BrokerAuthorization o nazwie example-authz z niestandardowymi ustawieniami autoryzacji
Następnie, jeśli skonfigurujesz wszystkie nowe porty, użyjesz tych samych zasobów BrokerAuthentication i BrokerAuthorization, konfiguracja będzie wyglądać następująco:
Dzięki temu można zachować domyślną konfigurację bez zmian i dodać nowe zasoby, aby dostosować wdrożenie brokera MQTT do własnych potrzeb.
Domyślny zasób brokera
Każde wdrożenie operacji usługi Azure IoT może mieć tylko jednego brokera i musi mieć nazwę domyślną. Domyślny zasób brokera jest wymagany do działania operacji usługi Azure IoT. Jest niezmienny i nie można go modyfikować po wdrożeniu.
Uwaga
Nie usuwaj domyślnego zasobu brokera. Spowoduje to zakłócenia komunikacji między składnikami wewnętrznymi operacji usługi Azure IoT, a wdrożenie przestanie działać.
Dostosowywanie domyślnego brokera
Dostosowywanie domyślnego zasobu brokera nie jest wymagane w przypadku większości konfiguracji. Ustawienia, które wymagają dostosowania, obejmują:
- Kardynalność: określa pojemność brokera w celu obsługi większej liczby połączeń i komunikatów oraz zwiększa wysoką dostępność, jeśli występują błędy zasobnika lub węzła.
- Profil pamięci: ustawia maksymalne użycie pamięci brokera i sposób obsługi użycia pamięci w miarę skalowania brokera w górę.
- Bufor komunikatów oparty na dysku: konfiguracja buforowania komunikatów na dysku w miarę wypełniania pamięci RAM.
- Ustawienia diagnostyki: Konfiguracja ustawień diagnostycznych, takich jak poziom dziennika i punkt końcowy metryk.
- Zaawansowane opcje klienta MQTT: konfiguracja zaawansowanych opcji klienta MQTT, takich jak wygaśnięcie sesji, wygaśnięcie komunikatu i ustawienia zachowania aktywności.
- Szyfrowanie ruchu wewnętrznego: konfiguracja szyfrowania ruchu wewnętrznego między zasobnikami frontonu brokera i zaplecza.
Dostosowywanie domyślnego brokera należy wykonać podczas początkowego wdrażania przy użyciu interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal. Nowe wdrożenie jest wymagane, jeśli potrzebne są różne ustawienia konfiguracji brokera.
Aby dostosować domyślnego brokera podczas wdrażania:
Korzystając z poniższego przewodnika po wdrażaniu operacji usługi Azure IoT, w sekcji Konfiguracja zapoznaj się z sekcją Konfiguracja brokera MQTT. W tym miejscu można dostosować ustawienia kardynalności i profilu pamięci. Aby skonfigurować inne ustawienia, w tym bufor komunikatów oparty na dysku i zaawansowane opcje klienta MQTT, użyj interfejsu wiersza polecenia platformy Azure.
Wyświetlanie domyślnych ustawień brokera
Aby wyświetlić ustawienia domyślnego brokera:
- W witrynie Azure Portal przejdź do wystąpienia operacji usługi Azure IoT.
- W obszarze Składniki wybierz pozycję Broker MQTT.
- W obszarze Szczegóły brokera wybierz pozycję Widok JSON.
Następne kroki
Wdrażanie operacji usługi Azure IoT w klastrze Kubernetes z obsługą usługi Arc