Implementatieplanning voor Azure IoT-bewerkingen

Veel Azure IoT-bewerkingen-instellingen zijn opgelost tijdens de implementatie en kunnen alleen worden gewijzigd door opnieuw te implementeren. Voordat u implementeert, plant u uw clustertopologie, het aantal brokers, het geheugenprofiel en de optionele brokerinstellingen die u nodig hebt. In dit artikel vindt u een overzicht van de beslissingen die u moet nemen.

Inzicht in de architectuur

Azure IoT-bewerkingen is een set modulaire, systeemeigen Kubernetes-services die zijn geïmplementeerd op een cluster met Azure Arc ingeschakeld. Belangrijke onderdelen zijn:

In de documentatie worden twee termen gebruikt:

• Implementatie : het exemplaar, Arc-extensies, aangepaste locaties en alle configureerbare resources (assets, apparaten, gegevensstromen).
• Instantie — De bovenliggende bron die de diensten bundelt.

Uw clustertopologie kiezen

Voordat u implementeert, moet u beslissen of u een cluster met één knooppunt of meerdere knooppunten nodig hebt. Deze beslissing bepaalt de hardwarevereisten en de instellingen voor de brokerkardinaliteit.

Begrijp de kardinaliteit van brokers

Kardinaliteit is het aantal frontend-replica's, frontend-workers, backend-partities en backend-workers in de brokerimplementatie. Kardinaliteit bepaalt hoe de broker horizontaal wordt geschaald en hoe tolerant deze is voor pod- of knooppuntfouten.

De MQTT-broker heeft een architectuur met twee lagen: front-endpods verwerken clientverbindingen en protocolverwerking, terwijl back-endpods berichtenopslag en -bezorging verwerken. Begrijpen hoe elke laag wordt geschaald, is belangrijk voor capaciteitsplanning.

Front-end

Front-endpods accepteren MQTT-clientverbindingen en sturen berichten door naar de back-end. Frontend-pods slaan zelf geen berichten op. Er zijn twee hoofdinstellingen voor de front-endlaag:

• Replica’s: het aantal frontend-pods dat moet worden uitgerold. Het toevoegen van meer frontendreplica’s verhoogt het aantal gelijktijdige clientverbindingen dat de broker kan verwerken en biedt een hoge beschikbaarheid als een van de frontendpods uitvalt.
• Werknemers: het aantal logische werkrollen per front-endpod. Door meer werkrollen toe te voegen, kan de front-endpod meer CPU-kernen gebruiken. Elke worker kan maximaal één CPU-kern gebruiken.

Back-end keten

Backendpods zorgen voor de opslag en aflevering van berichten. Er zijn drie hoofdinstellingen voor de back-endlaag:

• Partities: het aantal partities dat moet worden geïmplementeerd. Partities zijn de eenheid van horizontaal schalen voor berichtdoorvoer. Via een proces met de naam sharding verwerkt elke partitie een deel van de berichten, geshard op onderwerp en sessie. De frontendpods verdelen het berichtverkeer over de partities. Door meer partities toe te voegen, neemt de totale berichtdoorvoer toe die de broker kan verwerken.
• Redundantiefactor: Het aantal backend-pods dat per partitie moet worden uitgerold. Het verhogen van de redundantiefactor verhoogt het aantal gegevenskopieën om tolerantie te bieden tegen knooppuntfouten in het cluster.
• Workers: het aantal workers per backend-pod. Workers vormen de eenheid van verticale schaalvergroting binnen een partitie — door meer workers toe te voegen, kan de backend-pod meer CPU-kernen op hetzelfde knooppunt gebruiken. Elke werkrol kan maximaal twee CPU-kernen verbruiken, dus wees voorzichtig wanneer u het aantal werkrollen per replica verhoogt om het aantal CPU-kernen in het cluster niet te overschrijden.

Schatting van doorvoer

De prestaties van een afzonderlijke partitie zijn sterk afhankelijk van de CPU-kenmerken van het knooppunt waarop deze wordt uitgevoerd. Als vuistregel verwacht u ongeveer 5.000 tot 6.000 QoS 1-berichten per seconde per partitie met nettoladingen van 8 kB op een CPU van 2 GHz (~4-GHz turbo). Prestaties in de praktijk zijn afhankelijk van veel factoren, dus gebruik dit nummer alleen als uitgangspunt voor capaciteitsplanning.

Zie MQTT Broker-prestatiebenchmarking voor gedetailleerde benchmarkgegevens.

Aanbevelingen voor één knooppunt

• Frontend-replica's: Zijn ingesteld op 1.
• Front-endwerkers: stel in op de helft van het aantal CPU-kernen per knooppunt.
• Backendreplica's (redundantiefactor): Stel in op ten minste 2, zodat de broker gefaseerde updates kan uitvoeren.

Voorbeeld: één knooppunt, 4 CPU-kernen

Aanbevelingen voor meerdere knooppunten

De volgende waarden worden aanbevolen voor optimale prestaties. Voor grote clusters met weinig verkeer kunnen deze waarden lager worden ingesteld dan de aanbevelingen zonder problemen te veroorzaken. In de volgende secties worden meer overwegingen besproken, zoals geheugen (RAM) en prestatiekenmerken. Test uw configuratie altijd met de verwachte workload om de prestaties te bevestigen.

• Frontendreplica’s: Stel dit gelijk aan het aantal knooppunten in het cluster.
• Front-endwerkers: stel in op de helft van het aantal CPU-kernen per knooppunt.
• Backendreplica's (redundantiefactor): ingesteld op 2 voor redundantie en ondersteuning van rolling updates.
• Backendpartities: Stel deze in op het aantal knooppunten in het cluster.
• Back-endmedewerkers: ingesteld op de helft van het aantal CPU-kernen per knooppunt.

Voorbeeld: cluster met 3 knooppunten, 8 CPU-kernen per knooppunt

Voorbeeld: cluster met 5 knooppunten, 16 CPU-kernen per knooppunt

Limieten voor CPU-resources

Om resource-uitputting in het cluster te voorkomen, kan de broker zodanig worden geconfigureerd dat het Kubernetes CPU-resourcelimieten aanvraagt op basis van de kardinaliteitsinstellingen. Wanneer deze functie is ingeschakeld, verhoogt het schalen van het aantal replica's of werkrollen proportioneel de vereiste CPU-resources.

De standaardwaarde voor REST API-, Bicep- en ARM-sjablonen wordt gedefinieerd in de broker-API-specificatie.

De MQTT-broker vraagt CPU-resources per pod aan op basis van het aantal geconfigureerde werkrollen:

• Front-endpods: 1,0 CPU per werkrol
• Back-endpods: 2.0 CPU per werknemer

Gebruik de volgende formules om de totale CPU-vereisten te berekenen:

Voorbeeld: klein cluster

Overweeg een cluster met 2 knooppunten met 4 CPU-kernen per knooppunt (totaal 8 kernen) met de volgende kardinaliteit:

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

De makelaar vraagt:

• Front-end CPU: 2 replica's × 2 werkers × 1,0 = 4,0 CPU
• Back-end CPU: 1 partitie × 2 RF × 1 werkrol × 2,0 = 4,0 CPU
• Totale broker-CPU: 8.0 CPU

Deze configuratie vraagt 8.0 CPU op een cluster aan met slechts 8 kernen, waardoor er niets voor andere Azure IoT-bewerkingen onderdelen (200-300m) of voor Kubernetes-systeempods blijft. De broker-pods blijven in de status Pending met Insufficient cpu fouten.

U kunt dit oplossen door meer knooppunten toe te voegen, kernen per knooppunt te verhogen of de kardinaliteit van de broker te verminderen.

Voorbeeld: grotere implementatie

De volgende kardinaliteit vraagt aanzienlijk meer CPU-resources aan:

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

• Front-end CPU: 3 replica's × 2 werkrollen × 1,0 = 6,0 CPU
• Back-end CPU: 3 partities × 2 RF × 2 werkers × 2,0 = 24,0 CPU
• Totale CPU van broker: 30,0 CPU

Een cluster heeft minimaal 30 CPU-kernen nodig die alleen beschikbaar zijn voor brokerpods, plus ruimte voor andere Azure IoT-bewerkingen onderdelen en Kubernetes-systeempods.

Configuratie van CPU-resourcelimiet

CPU-resourcelimieten worden bepaald door het generateResourceLimits.cpu veld in de Broker-resource. Deze configuratie wordt alleen ondersteund door de --broker-config-file vlag te gebruiken wanneer u Azure IoT-bewerkingen implementeert met behulp van de az iot ops create opdracht. Zie Azure CLI ondersteuning voor geavanceerde MQTT-brokerconfiguratie voor meer informatie.

Bereid een Broker-configuratiebestand voor door de Api-verwijzing GenerateResourceLimits te volgen. In de volgende voorbeelden ziet u de twee mogelijke waarden:

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

Of

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

Uw geheugenprofiel kiezen

Het geheugenprofiel bepaalt de maximale MQTT-berichtgrootte die de broker accepteert, niet-actief geheugengebruik en het maximale geheugengebruik van elke pod. Bepaal het juiste geheugenprofiel voordat u implementeert op basis van de verwachte berichtgrootten en doorvoer.

Binnenkomende buffer en tegendruk

Elk geheugenprofiel definieert een maximale binnenkomende buffergrootte voor PUBLISH-gegevens per back-endwerkrol. Wanneer de buffer 75% capaciteit bereikt, activeert de broker backpressuremechanismen en begint de binnenkomende berichten te weigeren. Geweigerde pakketten ontvangen een PUBACK-antwoord met een quotum overschreden foutcode.

De volgende tabel toont de grootten van de binnenkomende buffers per worker voor elk profiel:

Wanneer u een geheugenprofiel kiest, kunt u het volgende overwegen:

• Klein: Er moet slechts één front-end worden gebruikt. Alleen pakketten verzenden die kleiner zijn dan 4 MiB.
• Laag: Er moeten slechts één of twee front-ends worden gebruikt. Alleen pakketten verzenden die kleiner zijn dan 16 MiB.
• Gemiddeld: geschikt voor de meeste productieworkloads met gemiddelde berichtgrootten.
• Hoog: Gebruik deze optie wanneer u grote berichten of hoge doorvoer met grote buffers moet verwerken.

Het totale brokergeheugen is afhankelijk van zowel het geheugenprofiel als de kardinaliteit (aantal front-endreplica's, back-endpartities en redundantiefactor). Meer pods betekenen in totaal meer geheugen. Zie Basislijnresourceprofielen voor gemeten verbruik van basislijnresources in verschillende configuraties.

Het totale geheugengebruik berekenen

U kunt het totale geheugengebruik berekenen met deze formule:

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

Where:

Als u bijvoorbeeld het profiel Gemiddeld geheugen kiest, heeft het profiel een front-endgeheugengebruik van 1.9 GiB en een back-endgeheugengebruik van 1,5 GiB. Stel dat de brokerconfiguratie bestaat uit 2 frontend-replica's, 2 backend-partities en een backend-redundantiefactor van 2. Het totale geheugengebruik is:

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

Ter vergelijking: het tiny geheugenprofiel heeft een front-endgeheugengebruik van 99 MiB en een back-endgeheugengebruik van 102 MiB. Met dezelfde brokerconfiguratie is het totale geheugengebruik:

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

Configuratie van geheugenprofiel

Wanneer u IoT-bewerkingen implementeert met behulp van de az iot ops create opdracht, geeft de --broker-mem-profile parameter de instellingen voor het geheugenprofiel op.

Met de volgende opdracht wordt bijvoorbeeld het geheugenprofiel Tiny ingesteld op (andere parameters worden weggelaten om kortheid te bepalen):

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

Zie az iot ops create optionele parameters voor meer informatie.

Optionele brokerinstellingen

De volgende brokerinstellingen worden ook geconfigureerd tijdens de implementatie en kunnen daarna niet meer worden gewijzigd. Controleer deze als ze van toepassing zijn op uw scenario:

• Schijfgebaseerde berichtbuffer — Buffer berichten op schijf wanneer abonneewachtrijen groter worden dan het beschikbare geheugen. Handig voor permanente sessies en connectiviteitsproblemen.
• Persistentie : schrijf kritieke brokergegevens naar de schijf om deze tijdens het opnieuw opstarten te behouden.
• Diagnostische gegevens: configureer metrische gegevens, logboeken en zelfcontroletests voor de MQTT-broker.
• Geavanceerde MQTT-opties : het verlopen van sessies, het verlopen van berichten, de limieten voor de abonneewachtrij en de instellingen voor keep alive aanpassen.
• Interne verkeersversleuteling: configureer versleuteling van intern verkeer tussen broker-front-end- en back-endpods (standaard ingeschakeld).

Volgende stappen 

• Uw cluster voorbereiden
• Implementeren in een productiecluster
• Waarneembaarheid configureren
• Uw implementatie beveiligen