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 :
- Haute disponibilité et récupération d’urgence IoT Hub :
- Comment obtenir une haute disponibilité inter-région avec IoT Hub
- Comment cloner un hub IoT Azure dans une autre région
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
ouMQTT
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
ouOperationCancelledException
) 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
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour