Share via


IoT Hub et fiabilité

Azure IoT Hub est un service managé, hébergé dans le cloud, qui joue le rôle de hub de messages central pour la communication entre une application IoT et les appareils attachés. Vous pouvez connecter des millions d’appareils et leurs solutions back-end de manière fiable et sécurisée. Presque tous les appareils peuvent être connectés à un hub IoT.

IoT Hub prend en charge le monitoring pour vous aider à effectuer le suivi de la création des appareils, de leurs connexions et de leurs défaillances.

IoT Hub prend également en charge les modèles de messagerie suivants :

  • Télémétrie appareil-à-cloud
  • Chargement de fichiers à partir d’appareils
  • Méthodes demande-réponse pour contrôler vos appareils à partir du cloud

Pour plus d’informations sur IoT Hub, consultez Concepts d’IoT et Azure IoT Hub.

Pour comprendre comment IoT Hub prend en charge une charge de travail fiable, consultez les rubriques suivantes :

Les sections suivantes sont spécifiques à Azure IoT Hub et à la fiabilité :

  • Remarques relatives à la conception
  • Liste de contrôle de la configuration
  • Options de configuration recommandées

Remarques relatives à la conception

Pour plus d’informations sur le Contrat de niveau de service (SLA) pour Azure IoT Hub, consultez Contrat SLA pour Azure IoT Hub.

Check-list

Avez-vous configuré Azure IoT Hub en tenant compte de la fiabilité ?

  • Provisionnez un deuxième hub IoT dans une autre région et configurez une logique de routage sur l’appareil.
  • Utilisez le protocole AMQP ou MQTT lors de l’envoi fréquent d’événements.
  • Utilisez uniquement des certificats validés par une autorité de certification racine dans l’environnement de production si vous utilisez des certificats X.509 pour la connexion de l’appareil.
  • Pour un débit maximal, utilisez le nombre maximal de partitions (32) lors de la création du hub IOT si vous envisagez d’utiliser le point de terminaison intégré.
  • Pour la mise à l’échelle, augmentez le niveau et les unités IoT Hub allouées au lieu d’ajouter plusieurs hubs IoT par région.
  • Dans les scénarios à débit élevé, utilisez des événements par lot.
  • Si vous devez minimiser la latence, n’utilisez pas le routage et lisez les événements à partir du point de terminaison intégré.
  • Dans le cadre de votre stratégie de disponibilité et de reprise d’activité après sinistre à l’échelle de la solution, envisagez d’utiliser l’option de reprise d’activité après sinistre inter-région d’IoT Hub.
  • Lors de la lecture de la télémétrie de l’appareil à partir du point de terminaison compatible Event Hub intégré, reportez-vous à la recommandation pour les consommateurs Event Hub.
  • Quand vous utilisez un kit SDK pour envoyer des événements à des hubs IoT, vérifiez que les exceptions levées par la stratégie de nouvelle tentative (EventHubsException ou OperationCancelledException) sont correctement interceptées.
  • Pour éviter les interruptions de télémétrie dues à la limitation et à un quota entièrement utilisé, envisagez d’ajouter une solution de mise à l’échelle automatique personnalisée.

Recommandations relatives à la configuration

Tenez compte des recommandations suivantes pour optimiser la fiabilité lors de la configuration d’Azure IoT Hub :

Recommandation Description
Provisionnez un deuxième hub IoT dans une autre région et configurez une logique de routage sur l’appareil. Ces configurations peuvent être encore améliorées avec un service Concierge.
Utilisez le protocole AMQP ou MQTT lors de l’envoi fréquent d’événements. AMQP et MQTT présentent des coûts réseau plus élevés lors de l’initialisation de la session, mais HTTPS nécessite un temps de traitement TLS supplémentaire pour chaque requête. AMQP et MQTT offrent des performances plus élevées pour les éditeurs courants.
Utilisez uniquement des certificats validés par une autorité de certification racine dans l’environnement de production si vous utilisez des certificats X.509 pour la connexion de l’appareil. Vérifiez que des processus sont en place pour mettre à jour les certificats avant leur expiration.
Pour un débit maximal, utilisez le nombre maximal de partitions (32) lors de la création du hub IOT si vous envisagez d’utiliser le point de terminaison intégré. Le nombre de partitions appareil-à-cloud pour le point de terminaison compatible Event Hub reflète le degré de parallélisme en aval que vous pouvez atteindre. Vous pourrez ainsi effectuer un scale-up avec 32 entités de traitement simultanées et bénéficier de la disponibilité en envoi/réception la plus élevée. Ce nombre ne peut pas être modifié après la création.
Pour la mise à l’échelle, augmentez le niveau et les unités IoT Hub allouées au lieu d’ajouter plusieurs hubs IoT par région. L’ajout de plusieurs hubs IoT par région n’offre pas de résilience supplémentaire, car tous les hubs peuvent s’exécuter sur le même cluster sous-jacent.
Dans les scénarios à débit élevé, utilisez des événements par lot. Le service fournira un tableau avec plusieurs événements aux consommateurs, au lieu d’un tableau avec un seul événement. L’application consommatrice doit traiter ces tableaux.
Si vous devez minimiser la latence, n’utilisez pas le routage et lisez les événements à partir du point de terminaison intégré. Lors de l’utilisation du routage des messages dans IoT Hub, la latence de la remise des messages augmente. En moyenne, la latence ne doit pas dépasser 500 ms, mais il n’existe aucune garantie quant à la latence de la livraison.
Dans le cadre de votre stratégie de disponibilité et de reprise d’activité après sinistre à l’échelle de la solution, envisagez d’utiliser l’option de reprise d’activité après sinistre inter-région d’IoT Hub. Cette option déplace le point de terminaison IoT Hub vers la région Azure appairée. Seul le registre de l’appareil est répliqué. Les événements ne sont pas répliqués dans la région secondaire. Le RTO pour le basculement lancé par le client varie entre 10 minutes et quelques heures. Pour un basculement lancé par Microsoft, le RTO est de 2-26 heures. Confirmez que ce RTO répond aux exigences du client et s’inscrit dans la stratégie de disponibilité plus large. Si un RTO plus élevé est requis, envisagez d’implémenter un modèle de basculement côté client.
Quand vous utilisez un kit SDK pour envoyer des événements à IoT Hub, vérifiez que les exceptions levées par la stratégie de nouvelle tentative (EventHubsException ou OperationCancelledException) sont correctement interceptées. Quand vous utilisez HTTPS, implémentez un modèle de nouvelle tentative approprié.

Étape suivante