Een IoT-oplossing verplaatsen van test naar productie
Dit artikel bevat een lijst met items die u moet overwegen bij het verplaatsen van een IoT-oplossing naar een productieomgeving.
Implementatiestempels gebruiken
Stempels zijn afzonderlijke eenheden van kernoplossingsonderdelen die ondersteuning bieden voor een gedefinieerd aantal apparaten. Elke kopie wordt een stempel genoemd. of schaaleenheid. Een stempel kan bijvoorbeeld bestaan uit een set apparaatpopulatie, een IoT Hub, een Event Hub of een ander routerings-eindpunt en een verwerkingsonderdeel. Elke stempel ondersteunt een gedefinieerde apparaatpopulatie. U kiest het maximum aantal apparaten dat de zegel mag hebben. Naarmate de apparaatpopulatie groeit, voegt u stempel-exemplaren toe in plaats van onafhankelijk verschillende onderdelen van de oplossing omhoog te schalen.
Als u in plaats van stempels toe te voegen één exemplaar van uw IoT-oplossing naar productie verplaatst, kunnen de volgende beperkingen gelden:
Schaallimieten: Uw enkele instantie kan schaallimieten ondervinden. Uw oplossing maakt bijvoorbeeld gebruik van services die limieten hebben voor het aantal binnenkomende verbindingen, hostnamen, TCP-sockets of andere resources.
Niet-lineaire schaalbaarheid of kosten: Uw oplossingsonderdelen kunnen mogelijk niet lineair worden geschaald met het aantal aanvragen of de hoeveelheid opgenomen gegevens. In plaats daarvan kan er voor sommige onderdelen een afname in de prestaties of hogere kosten optreden zodra aan een drempelwaarde is voldaan. Omhoog schalen met meer capaciteit is mogelijk niet zo goed als uitschalen door stempels toe te voegen.
Scheiding van klanten: Mogelijk moet u de gegevens van bepaalde klanten geïsoleerd houden van de gegevens van andere klanten. Op dezelfde manier hebt u mogelijk een aantal klanten die meer systeemresources nodig hebben voor de service dan andere, en kunt u overwegen om ze op verschillende stempels te groeperen.
Instanties met één tenant en meerdere tenants: Mogelijk hebt u enkele grote klanten die hun eigen onafhankelijke exemplaren van uw oplossing nodig hebben. Mogelijk hebt u ook een groep kleinere klanten die een implementatie met meerdere tenants kunnen delen.
Complexe implementatievereisten: Mogelijk moet u updates voor uw service op een gecontroleerde manier implementeren en op verschillende tijdstippen implementeren op verschillende stempels.
Updatefrequentie: Mogelijk hebt u een aantal klanten die tolerant zijn voor regelmatige updates voor uw systeem, terwijl andere mogelijk risico-averse zijn en niet-frequente updates voor uw service willen.
Geografische of geopolitieke beperkingen: Als u de latentie wilt verminderen of wilt voldoen aan de vereisten voor gegevenssoevereiniteit, kunt u enkele van uw klanten implementeren in specifieke regio's.
Om de voorgaande problemen te voorkomen, kunt u overwegen om uw service in meerdere stempels te groeperen. Stempels werken onafhankelijk van elkaar en kunnen onafhankelijk worden geïmplementeerd en bijgewerkt. Eén geografische regio kan één stempel bevatten of meerdere stempels bevatten om horizontaal uit te schalen binnen de regio. Elke zegel bevat een subset van uw klanten.
Gebruik een back-off wanneer er een tijdelijke fout optreedt
Alle toepassingen die met externe services en bronnen communiceren moeten gevoelig zijn voor tijdelijke fouten. Dit is met name het geval voor toepassingen die worden uitgevoerd in de cloud, waarbij de aard van de omgeving en connectiviteit via internet betekent dat dit soort fouten waarschijnlijk vaker worden aangetroffen. Tijdelijke fouten zijn onder andere:
- Momentverlies van netwerkconnectiviteit met onderdelen en services
- Tijdelijke onbeschikbaarheid van een service
- Time-outs die optreden wanneer een service bezet is
- Bots die worden veroorzaakt wanneer apparaten gelijktijdig verzenden
Deze fouten worden vaak zelf gecorrigeerd en als de actie na een geschikte vertraging wordt herhaald, is de kans groot dat deze slaagt. Het bepalen van de juiste intervallen tussen nieuwe proberen is echter moeilijk. Typische strategieën gebruiken de volgende typen intervallen voor opnieuw proberen:
- Exponentieel af- en uitschakelen. De toepassing wacht korte tijd voor de eerste poging wordt uitgevoerd. Vervolgens neemt het interval tussen de pogingen exponentieel toe. De nieuwe poging kan bijvoorbeeld na 3, 12, 30 seconden enzovoort worden uitgevoerd.
- Regelmatige intervallen. Het interval tussen pogingen is telkens even lang. De bewerken wordt bijvoorbeeld elke drie seconden herhaalt.
- Onmiddellijk opnieuw proberen. Soms is een tijdelijke fout kort, mogelijk als gevolg van een gebeurtenis, zoals een netwerkpakketbotsing of een piek in een hardwareonderdeel. In een dergelijk geval kan de bewerking het beste onmiddellijk opnieuw worden geprobeerd omdat deze kan slagen als de fout al is opgelost gedurende de tijd die het kost om de volgende aanvraag op te stellen en te verzenden. Er mag echter nooit meer dan één directe nieuwe poging zijn en u moet overschakelen naar alternatieve strategieën, zoals exponentieel terugvallen of terugvalacties, als de onmiddellijke nieuwe poging mislukt.
- Randomisatie. Een van de voorgaande strategieën voor opnieuw proberen kan een randomisatie-element bevatten om te voorkomen dat meerdere exemplaren van de client volgende nieuwe pogingen tegelijk verzenden.
Vermijd ook de volgende antipatronen:
- Implementaties mogen geen dubbele lagen code voor opnieuw proberen bevatten.
- Implementeer nooit een mechanisme waarbij eindeloos nieuwe pogingen worden uitgevoerd.
- Voer een onmiddellijke nieuwe poging nooit vaker dan eenmaal uit.
- Vermijd het gebruik van een regelmatig interval voor opnieuw proberen.
- Vermijd dat meerdere instanties van dezelfde client of meerdere instanties van verschillende clients tegelijkertijd nieuwe pogingen verzenden.
Zero Touch-inrichting gebruiken
Inrichten is het inschrijven van een apparaat bij Azure IoT Hub. Inrichting maakt IoT Hub op de hoogte van het apparaat en het attestation-mechanisme dat het apparaat gebruikt. U kunt de Azure IoT Hub Device Provisioning Service (DPS) gebruiken of rechtstreeks inrichten via IoT Hub Registry Manager-API's. Het gebruik van DPS biedt het voordeel van late binding, waardoor veldapparaten kunnen worden verwijderd en opnieuw kunnen worden IoT Hub zonder de apparaatsoftware te wijzigen.
In het volgende voorbeeld ziet u hoe u een overgangswerkstroom voor een test-naar-productieomgeving implementeert met behulp van DPS.
- De ontwikkelaar van de oplossing koppelt de Test- en Production IoT-clouds aan de inrichtingsservice.
- Het apparaat implementeert het DPS-protocol om de IoT Hub als het niet meer is ingericht. Het apparaat wordt in eerste instantie ingericht voor de testomgeving.
- Omdat het apparaat is geregistreerd bij de testomgeving, maakt het daar verbinding en wordt er getest.
- De ontwikkelaar maakt het apparaat opnieuw in de productieomgeving en verwijdert het uit de Test-hub. De Test Hub weigert het apparaat de volgende keer dat het opnieuw verbinding maakt.
- Het apparaat maakt verbinding en onderhandelt opnieuw over de inrichtingsstroom. DPS stuurt het apparaat nu door naar de productieomgeving, en het apparaat maakt daar verbinding en verifieert het.