Concepten voor het opnieuw inrichten van IoT Hub-apparaten
Tijdens de levenscyclus van een IoT-oplossing is het gebruikelijk om apparaten tussen IoT-hubs te verplaatsen. De redenen voor deze verplaatsing kunnen de volgende scenario's bevatten:
Geolocatie/GeoLatency: Als een apparaat tussen locaties beweegt, wordt de netwerklatentie verbeterd door het apparaat te migreren naar een dichtere IoT-hub.
Multitenancy: Een apparaat kan worden gebruikt binnen dezelfde IoT-oplossing en opnieuw worden toegewezen aan een nieuwe klant of klantsite. Deze nieuwe klant kan worden onderhouden met behulp van een andere IoT-hub.
Oplossingswijziging: Een apparaat kan worden verplaatst naar een nieuwe of bijgewerkte IoT-oplossing. Deze toewijzing vereist mogelijk dat het apparaat communiceert met een nieuwe IoT-hub die is verbonden met andere back-endonderdelen.
Quarantaine: vergelijkbaar met een oplossingswijziging. Een apparaat dat defect, gecompromitteerd of verouderd is, kan opnieuw worden toegewezen aan een IoT-hub die alleen kan worden bijgewerkt en weer compatibel kan worden. Zodra het apparaat goed functioneert, wordt het weer gemigreerd naar de hoofdhub.
Het opnieuw inrichten van ondersteuning binnen Device Provisioning Service voldoet aan deze behoeften. Apparaten kunnen automatisch opnieuw worden toegewezen aan nieuwe IoT-hubs op basis van het beleid voor opnieuw inrichten dat is geconfigureerd op de inschrijvingsvermelding van het apparaat.
Apparaatstatusgegevens
Apparaatstatusgegevens bestaan uit de mogelijkheden van de apparaatdubbel en het apparaat. Deze gegevens worden opgeslagen in het Device Provisioning Service-exemplaar en de IoT-hub waaraan een apparaat is toegewezen.
Wanneer een apparaat in eerste instantie wordt ingericht met een Device Provisioning Service-exemplaar, worden de volgende stappen uitgevoerd:
Het apparaat verzendt een inrichtingsaanvraag naar een Device Provisioning Service-exemplaar. Het service-exemplaar verifieert de apparaat-id op basis van een inschrijvingsvermelding en maakt de eerste configuratie van de apparaatstatusgegevens. Het service-exemplaar wijst het apparaat toe aan een IoT-hub op basis van de inschrijvingsconfiguratie en retourneert die IoT-hubtoewijzing aan het apparaat.
Het exemplaar van de inrichtingsservice geeft een kopie van de initiële apparaatstatusgegevens aan de toegewezen IoT-hub. Het apparaat maakt verbinding met de toegewezen IoT-hub en begint bewerkingen.
Na verloop van tijd kunnen de apparaatstatusgegevens op de IoT-hub worden bijgewerkt door apparaatbewerkingen en back-endbewerkingen. De initiële apparaatstatusgegevens die zijn opgeslagen in het Device Provisioning Service-exemplaar blijven ongewijzigd. Deze ongewijzigde apparaatstatusgegevens zijn de eerste configuratie.
Afhankelijk van het scenario, is het mogelijk dat als een apparaat tussen IoT-hubs wordt verplaatst, ook de apparaatstatus moet worden gemigreerd die is bijgewerkt op de vorige IoT-hub naar de nieuwe IoT-hub. Deze migratie wordt ondersteund door het opnieuw inrichten van beleid in Device Provisioning Service.
Beleid voor opnieuw inrichten
Afhankelijk van het scenario kan een apparaat een aanvraag verzenden naar een exemplaar van de inrichtingsservice bij het opnieuw opstarten. Het biedt ook ondersteuning voor een methode voor het handmatig activeren van inrichting op aanvraag. Het herinrichtingsbeleid voor een inschrijvingsvermelding bepaalt hoe het exemplaar van de device provisioning service deze inrichtingsaanvragen verwerkt. Het beleid bepaalt ook of apparaatstatusgegevens moeten worden gemigreerd tijdens het opnieuw inrichten. Hetzelfde beleid is beschikbaar voor afzonderlijke inschrijvingen en inschrijvingsgroepen:
Gegevens opnieuw inrichten en migreren: dit beleid is de standaardinstelling voor nieuwe inschrijvingsvermeldingen. Dit beleid neemt actie wanneer apparaten die zijn gekoppeld aan de inschrijvingsvermelding een nieuwe aanvraag indienen (1). Afhankelijk van de inschrijvingsvermeldingsconfiguratie kan het apparaat opnieuw worden toegewezen aan een andere IoT-hub. Als het apparaat IoT-hubs wijzigt, wordt de apparaatregistratie met de eerste IoT-hub verwijderd. De bijgewerkte apparaatstatusgegevens van die eerste IoT-hub worden gemigreerd naar de nieuwe IoT-hub (2). Tijdens de migratie wordt de status van het apparaat gerapporteerd als Toewijzen.
Opnieuw inrichten en opnieuw instellen op de eerste configuratie: dit beleid neemt actie wanneer apparaten die zijn gekoppeld aan de inschrijvingsvermelding, een nieuwe inrichtingsaanvraag indienen (1). Afhankelijk van de inschrijvingsvermeldingsconfiguratie kan het apparaat opnieuw worden toegewezen aan een andere IoT-hub. Als het apparaat IoT-hubs wijzigt, wordt de apparaatregistratie met de eerste IoT-hub verwijderd. De initiële configuratiegegevens die het inrichtingsservice-exemplaar heeft ontvangen toen het apparaat werd ingericht, wordt geleverd aan de nieuwe IoT-hub (2). Tijdens de migratie wordt de status van het apparaat gerapporteerd als Toewijzen.
Dit beleid wordt vaak gebruikt voor het terugzetten van de fabrieksinstellingen zonder ioT-hubs te wijzigen.
Nooit opnieuw inrichten: het apparaat wordt nooit opnieuw toegewezen aan een andere hub. Dit beleid wordt geboden voor het beheren van compatibiliteit met eerdere versies.
Notitie
DPS roept altijd de aangepaste toewijzingswebhook aan, ongeacht het beleid voor opnieuw inrichten in het geval er nieuwe ReturnData voor het apparaat is. Als het beleid voor opnieuw inrichten is ingesteld op nooit opnieuw inrichten, wordt de webhook aangeroepen, maar wordt de toegewezen hub niet gewijzigd op het apparaat.
Bij het ontwerpen van uw oplossing en het definiëren van een herinrichtingslogica moet u rekening houden met een aantal zaken. Bijvoorbeeld:
- Hoe vaak u verwacht dat uw apparaten opnieuw worden opgestart
- De DPS-quota en -limieten
- Verwachte implementatietijd voor uw vloot (gefaseerde implementatie versus allemaal tegelijk)
- Mogelijkheid voor opnieuw proberen geïmplementeerd in uw clientcode, zoals beschreven in de algemene richtlijnen voor opnieuw proberen in het Azure Architecture Center
Fooi
We raden u aan het apparaat niet in te richten bij elke herstart van het apparaat, omdat dit problemen kan veroorzaken bij het opnieuw inrichten van meerdere duizenden of miljoenen apparaten tegelijk. In plaats daarvan moet u proberen de opzoek-API voor apparaatregistratiestatus te gebruiken en verbinding te maken met die informatie met IoT Hub. Als dat mislukt, probeert u de inrichting opnieuw in te stellen, omdat de IoT Hub-gegevens mogelijk zijn gewijzigd. Houd er rekening mee dat het uitvoeren van query's voor de registratiestatus wordt meegeteld als een nieuwe apparaatregistratie, dus u moet rekening houden met de limiet voor apparaatregistratie. Overweeg ook het implementeren van een geschikte logica voor opnieuw proberen, zoals exponentieel uitstel met randomisatie, zoals beschreven in de algemene richtlijnen voor opnieuw proberen. In sommige gevallen, afhankelijk van de mogelijkheden van het apparaat, is het mogelijk om de IoT Hub-gegevens rechtstreeks op het apparaat op te slaan om rechtstreeks verbinding te maken met IoT Hub nadat de eerste keer dat dps is ingericht. Als u ervoor kiest om dit te doen, moet u ervoor zorgen dat u een terugvalmechanisme implementeert voor het geval u specifieke fouten van Hub krijgt, bijvoorbeeld de volgende scenario's:
- Voer de hubbewerking opnieuw uit als de resultaatcode 429 (Te veel aanvragen) of een fout in het bereik 5xx is. Probeer niet opnieuw voor andere fouten.
- Voor 429-fouten moet u het alleen opnieuw proberen na de tijd die wordt aangegeven in de header Opnieuw proberen na.
- Voor 5xx-fouten gebruikt u exponentieel uitstel, waarbij u ten minste 5 seconden na het antwoord opnieuw probeert.
- Bij andere fouten dan 429 en 5xx kunt u zich opnieuw registreren via DPS
- In het ideale geval moet u ook een methode ondersteunen voor het handmatig activeren van inrichting op aanvraag.
We raden u ook aan rekening te houden met de servicelimieten bij het plannen van activiteiten zoals het pushen van updates naar uw vloot. Als u bijvoorbeeld de vloot in één keer bijwerkt, kan dit ertoe leiden dat alle apparaten opnieuw worden geregistreerd via DPS (die eenvoudig boven de limiet voor het registratiequotum kunnen komen). Voor dergelijke scenario's kunt u overwegen om apparaatupdates in fasen te plannen in plaats van uw hele vloot tegelijkertijd bij te werken.
Compatibiliteit met eerdere versies beheren
Vóór september 2018 hadden apparaattoewijzingen aan IoT-hubs een plakgedrag. Wanneer een apparaat teruggaat via het inrichtingsproces, wordt het alleen toegewezen aan dezelfde IoT-hub.
Voor oplossingen die afhankelijk zijn van dit gedrag, bevat de inrichtingsservice achterwaartse compatibiliteit. Dit gedrag wordt momenteel onderhouden voor apparaten volgens de volgende criteria:
De apparaten maken verbinding met een API-versie vóór de beschikbaarheid van systeemeigen herinrichtingsondersteuning in Device Provisioning Service. Raadpleeg de onderstaande API-tabel.
Voor de inschrijvingsvermelding voor de apparaten is geen beleid voor opnieuw inrichten ingesteld.
Deze compatibiliteit zorgt ervoor dat eerder geïmplementeerde apparaten hetzelfde gedrag ervaren dat aanwezig is tijdens de eerste test. Als u het vorige gedrag wilt behouden, slaat u geen beleid voor opnieuw inrichten op voor deze inschrijvingen. Als een herinrichtingsbeleid is ingesteld, heeft het herinrichtingsbeleid voorrang op het gedrag. Door toe te staan dat het beleid voor opnieuw inrichten voorrang krijgt, kunnen klanten het gedrag van het apparaat bijwerken zonder dat het apparaat opnieuw hoeft te worden ingesteld.
In het volgende stroomdiagram kunt u zien wanneer het gedrag aanwezig is:
In de volgende tabel ziet u de API-versies vóór de beschikbaarheid van systeemeigen herinrichtingsondersteuning in Device Provisioning Service:
| REST-API | C SDK | Python SDK | Node SDK | Java-SDK | .NET SDK |
|---|---|---|---|---|---|
| 2018-04-01 en eerder | 1.2.8 en eerder | 1.4.2 en eerder | 1.7.3 of eerder | 1.13.0 of eerder | 1.1.0 of eerder |
Notitie
Deze waarden en koppelingen worden waarschijnlijk gewijzigd. Dit is slechts een tijdelijke aanduiding om te bepalen waar de versies kunnen worden bepaald door een klant en wat de verwachte versies zijn.