Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit artikel worden twee voorbeelden beschreven Azure IoT-bewerkingen implementaties die gegevens verzamelen van edge en deze overdragen naar de cloud. Deze voorbeelden zijn gebaseerd op praktijkscenario's die rekening houden met hardwaremogelijkheden en gegevensvolumes. Gebruik deze voorbeelden om beter te begrijpen hoeveel gegevens Azure IoT-bewerkingen met bepaalde hardware kunnen verwerken.
Microsoft vergelijkbare configuraties en gegevensvolumes gebruikt om Azure IoT-bewerkingen te valideren en de prestaties ervan te meten.
Cluster met één knooppunt
In dit voorbeeld ziet u de mogelijkheden van Azure IoT-bewerkingen wanneer deze wordt uitgevoerd op een host met relatief lage hardwarespecificatie. In dit voorbeeld wordt Azure IoT-bewerkingen geïmplementeerd in één knooppuntcluster. Gegevens die worden gegenereerd op basis van assets worden eerst samengevoegd met een PLC en vervolgens verzonden naar de Azure IoT-bewerkingen-connector voor OPC UA.
Configuratie
Voorbeeld hardwarespecificaties:
K3s op Azure VM (Standard_D4ds_v5 met Intel Xeon Platinum 8370C), 4 core (4 vCPU), 16 GB geheugen, 30 GB opslagruimte.
AKS-EE op P3 Tiny Workstation (13e generatie Intel® Core™ i7-13700 vPro® Processor), 16 kernen (24 threads), 32 GB geheugen, 1 TB opslag.
Belangrijk
Momenteel zijn K3's op Ubuntu 24.04 en vSphere Kubernetes Service de enige platforms voor het implementeren van Azure IoT-bewerkingen in productie. Zie Ondersteunde omgevingen voor meer informatie.
In de volgende tabel ziet u de MQTT-brokerconfiguratie voor het voorbeeld van één knooppunt:
| Kenmerk | Waarde |
|---|---|
| frontend-replicas | 1 |
| voorkantprocessen | 2 |
| backendRedundancyFactor | 2 |
| backendmedewerkers | 1 |
| backend-partities | 1 |
| geheugenprofiel | Laag |
De end-to-end gegevensstroom in het voorbeeld ziet er als volgt uit:
Assets -> PLC -> Connector for OPC UA -> MQTT broker -> Data flows -> Event Hubs
De gegevensvolumes in het voorbeeld zijn:
- 125 assets samengevoegd door één OPC UA-server.
- 6.250 tags op basis van 50 tags voor elk asset. Elke tag wordt 2/seconde bijgewerkt en heeft een gemiddelde grootte van 20 bytes.
- De connector voor OPC UA verzendt 125 bericht/seconde naar de MQTT-broker.
- Eén gegevensstroompijplijn pusht 6.250 tags naar een Event Hubs-eindpunt.
In dit voorbeeld raadt Microsoft aan om Event Hubs te gebruiken, omdat u slechts één data flow-exemplaar kunt maken met een CPU met vier kernen. Als u Event Grid kiest, kan dit slechts 100 berichten per seconde verwerken.
Prestaties
Belangrijke prestatiegegevens voor dit voorbeeld zijn onder andere:
- Azure IoT-bewerkingen en de afhankelijkheden verbruiken tussen 6 GB en 8 GB RAM.
- Azure IoT-bewerkingen en de afhankelijkheden verbruiken gemiddeld 2.400-2.600 millicores.
- 100% van de gegevens wordt naar Event Hubs gepusht.
- De latentie van end-to-endgegevensprocessen is minder dan 10 seconden, gezien de ideale netwerkomstandigheden.
Cluster met meerdere knooppunten
Wanneer Azure IoT-bewerkingen wordt uitgevoerd op een cluster met meerdere knooppunten, kan het meer gegevens verwerken en profiteren van de mogelijkheden voor hoge beschikbaarheid van Kubernetes. In dit voorbeeld wordt Azure IoT-bewerkingen gehost op een cluster met vijf knooppunten en verwerkt ongeveer 50.000 gegevenspunten per seconde uit twee verschillende gegevensbronnen.
Configuratie
Voorbeeld hardwarespecificaties:
K3's met 5 knooppunten met Azure VM's (Standard_D8d_v5 met Intel Xeon Platinum 8370C), 8 kernen (8 vCPU), 32 GB geheugen, 30 GB.
5-knooppunt K3S met P3 Tiny Workstations (13e generatie Intel® Core™ i7-13700 vPro® Processor), 16 kernen (24 threads), 32 GB geheugen, 1 TB opslag.
Belangrijk
Momenteel zijn K3's op Ubuntu 24.04 en vSphere Kubernetes Service de enige platforms voor het implementeren van Azure IoT-bewerkingen in productie. Zie Ondersteunde omgevingen voor meer informatie.
In de volgende tabel ziet u de MQTT-brokerconfiguratie voor het voorbeeld met meerdere knooppunten:
| Kenmerk | Waarde |
|---|---|
| frontend-replicas | 5 |
| voorkantprocessen | 4 |
| backendRedundancyFactor | 2 |
| backendmedewerkers | 4 |
| backend-partities | 5 |
| geheugenprofiel | Hoog |
In dit voorbeeld zijn er twee typen gegevensbronnen. Eén maakt verbinding via de connector voor OPC UA en één maakt verbinding via de MQTT-broker.
In dit voorbeeld vertegenwoordigt een asset geen echt apparaat, maar is een logische groepering waarmee gegevenspunten worden samengevoegd en berichten worden verzonden.
De eerste end-to-end-gegevensstroom in het voorbeeld ziet er als volgt uit:
Assets -> PLC -> Connector for OPC UA -> MQTT broker -> Data flows -> Event Hubs
De gegevensvolumes in de eerste gegevensstroom in het voorbeeld zijn:
- 85 assets, geaggregeerd door vijf OPC UA-servers.
- 85.000 tags op basis van 1.000 tags voor elk asset. Elke tag wordt 1/seconde bijgewerkt en heeft een gemiddelde grootte van 8 bytes. Ongeveer 50% van de tagwaarden wijzigen elke cyclus. De updatesnelheid van het gegevenspunt is 45.000 per seconde.
- De connector voor OPC UA verzendt 85 bericht/seconde naar de MQTT-broker.
- Eén gegevensstroompijplijn pusht 85.000 tags naar een Event Hubs-eindpunt.
De tweede end-to-end-gegevensstroom in het voorbeeld ziet er als volgt uit:
MQTT client (Paho) -> MQTT Broker -> Data flows -> Event Hubs
De gegevensvolumes in de tweede gegevensstroom in het voorbeeld zijn:
- Twee MQTT-clients die rechtstreeks zijn verbonden met MQTT Broker.
- Elke client publiceert 10.000 waarden per seconde.
- Ongeveer 1/3 van de tagwaarden veranderen elke cyclus.
- Gecodeerd met JSON-indeling. Elk item (waarde) met een geschatte grootte van 180 bytes.
Prestaties
Belangrijke prestatiegegevens voor dit voorbeeld zijn onder andere:
- Azure IoT-bewerkingen en de bijbehorende afhankelijkheden verbruiken tussen 25 GB en 30 GB RAM.
- Azure IoT-bewerkingen en de afhankelijkheden verbruiken gemiddeld 2500-3.000 millicores.
- 100% van de gegevens wordt naar Event Hubs gepusht.
- De latentie van end-to-endgegevensprocessen is minder dan 10 seconden, gezien de ideale netwerkomstandigheden.