Fiabilité dans Azure Data Explorer

Azure Data Explorer est un service d’analyse qui vous permet d’ingérer, de stocker et d’interroger de grands volumes de données avec une faible latence. Il est couramment utilisé pour la charge de travail d'analyse des journaux, de télémétrie et de séries temporelles qui nécessitent des requêtes rapides sur de grands ensembles de données.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Azure Data Explorer résilient à diverses pannes et problèmes potentiels, notamment les erreurs temporaires, les défaillances de zone de disponibilité et les défaillances à l’échelle de la région. Il décrit également les options de sauvegarde et de restauration et la résilience à la maintenance du service, et met en évidence les informations clés relatives au contrat de niveau de service Azure Data Explorer (SLA).

Recommandations de déploiement de production pour la fiabilité

Pour les charges de travail de production, nous vous recommandons d’effectuer les étapes suivantes pour améliorer la fiabilité de votre cluster Azure Data Explorer :

• Déployez un cluster complet. Azure Data Explorer fournit des clusters gratuits à des fins d’essai. Pour les charges de travail de production, déployez un cluster complet.
• Activer la prise en charge des zones de disponibilité. Azure Data Explorer prend en charge les zones de disponibilité. Lorsque la prise en charge des zones de disponibilité est activée, les nœuds de calcul sont répartis entre plusieurs zones de disponibilité et les données sont stockées à l’aide d’un stockage redondant interzone. Cette configuration améliore la résilience aux défaillances de zone de disponibilité.

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

La ressource principale que vous déployez est un cluster, qui représente l’infrastructure dont vous avez besoin pour ingérer, stocker et interroger vos données. Avec un cluster, vous créez des bases de données, qui contiennent à leur tour des tables.

Les clusters effectuent l’ingestion pour récupérer des données à partir d’autres sources de données et les charger dans une table du cluster. Les données peuvent ensuite être interrogées à l’aide de la syntaxe KQL (Kusto Query Language). Les clusters ont également un ensemble d’opérations de gestion que vous pouvez effectuer.

Architecture physique

Un cluster Azure Data Explorer a deux couches principales applicables à sa configuration de fiabilité :

• Couche de calcul : Azure Data Explorer est une plateforme informatique distribuée et peut avoir deux à plusieurs machines virtuelles de nœud en fonction du type de rôle de nœud et de mise à l’échelle. Les nœuds gèrent le travail d’ingestion des données et de traitement des requêtes. Vous ne voyez pas ou ne gérez pas directement les machines virtuelles de nœud. La plateforme gère automatiquement la création d’instances, la surveillance de l’intégrité et le remplacement de nœuds non sains. Lorsque votre cluster est configuré pour utiliser des zones de disponibilité, les nœuds sont répartis entre différents centres de données.

• Couche de stockage : Azure Data Explorer utilise stockage Azure comme couche de persistance durable. Le stockage Azure fournit automatiquement une tolérance de panne, avec le paramètre par défaut offrant un stockage localement redondant (LRS) au sein d’un centre de données. Trois réplicas sont conservés. Si une réplique est perdue pendant son utilisation, une autre est déployée sans interruption. Lorsque votre cluster est configuré pour utiliser plusieurs zones de disponibilité, les réplicas sont répartis entre différents centres de données.

Pour plus d’informations, consultez fonctionnement d’Azure Data Explorer.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Pour renforcer la résilience aux erreurs temporaires lorsque vous utilisez Azure Data Explorer, procédez comme suit :

• Lorsque vous utilisez l’ingestion mise en file d’attente, utilisez le comportement de réessai intégré.
• Utilisez des bibliothèques clientes et des kits sdk fournis par Microsoft, qui réessayent automatiquement lorsque des erreurs temporaires se produisent.
• Si vous utilisez directement des API REST Azure Data Explorer, réessayez les requêtes et les opérations de gestion qui échouent en raison d’une erreur temporaire.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Azure Data Explorer prend en charge deux types de configuration de zone de disponibilité :

• Redondant interzone (recommandé) : Lorsque vous activez des zones de disponibilité sur votre cluster, les nœuds de votre cluster sont répartis entre plusieurs zones. Microsoft gère la distribution des nœuds entre les zones de disponibilité sélectionnées et gère la détection et la réponse aux défaillances des zones de disponibilité. Un cluster redondant interzone est résilient à une panne de zone de disponibilité.

  Lorsque vous configurez votre cluster pour qu’il soit redondant interzone, vos données sont stockées à l’aide du stockage redondant interzone Azure (ZRS), qui réplique de façon synchrone au moins trois copies des données dans plusieurs zones de disponibilité.

  

• Zonale: Vous pouvez éventuellement sélectionner une seule zone lorsque vous activez les zones de disponibilité sur votre cluster. Microsoft place toutes vos notes de calcul dans cette zone. Il s’agit d’un cluster zonal (à zone unique). Cette configuration peut parfois vous aider si vous avez une charge de travail inhabituellement sensible à la latence, mais elle ne fournit pas de résilience aux pannes de zone.

  Important

  L’épinglage à une seule zone de disponibilité est recommandé uniquement lorsque la latence interzone est trop élevée pour vos besoins et après avoir vérifié que la latence ne répond pas à vos besoins. Par elle-même, une ressource zonale ne fournit pas de résilience à une panne d'une zone de disponibilité. Pour améliorer la résilience d’une ressource zonale, vous devez déployer explicitement des ressources distinctes dans plusieurs zones de disponibilité et configurer le routage et le basculement du trafic. Pour plus d’informations, consultez ressources zonales et résilience de zone.

  La sélection de votre zone s’applique uniquement à vos nœuds de calcul. Pour un cluster zonal, vos données de stockage continuent d’utiliser LRS et peuvent être stockées dans une zone différente de vos nœuds de calcul.

  

Si vous n’activez pas les zones de disponibilité, le cluster n’est non zonal, ce qui signifie qu’Azure sélectionne la zone de disponibilité pour chaque nœud et vos données. Si une zone de disponibilité de la région a une panne, elle peut affecter les nœuds, les données ou les deux de votre cluster. Nous déconseillons une configuration nonzonale, car elle ne fournit pas de protection contre les pannes de zone de disponibilité.

Exigences

• Prise en charge de la région : La prise en charge des zones de disponibilité est disponible dans les régions Azure qui prennent en charge les zones de disponibilité.

  Toutefois, certains types et tailles de nœud de calcul sont disponibles uniquement dans des régions spécifiques ou des zones spécifiques au sein d’une région.

• Clusters complets : La prise en charge des zones de disponibilité est disponible avec des clusters complets. Il n’est pas disponible avec des clusters gratuits.

Considérations

Sélection de zone : Pour les nœuds de calcul, vous choisissez les zones de disponibilité à utiliser. Le placement des zones de stockage est géré par Microsoft, et les réplicas de stockage peuvent être placés dans différentes zones par rapport à vos nœuds de calcul.

Coûts

L’activation de la prise en charge des zones de disponibilité entraîne des coûts supplémentaires pour le stockage redondant interzone, qui est facturé à un taux plus élevé que le stockage localement redondant. Pour plus d’informations, consultez Tarification de Stockage Azure.

Les nœuds de calcul sont facturés au même tarif que vous utilisiez la prise en charge de la zone de disponibilité ou non. Pour plus d’informations, consultez Tarification Azure Data Explorer.

Configurez la prise en charge des zones de disponibilité

• Créez un cluster avec prise en charge des zones de disponibilité : Vous pouvez activer la prise en charge des zones de disponibilité lorsque vous créez un cluster Azure Data Explorer. Pour plus d’informations, consultez Créer un cluster et une base de données.

  Lorsque vous créez un cluster activé pour les zones de disponibilité à l’aide du portail Azure, il est doté de redondance de zone automatiquement, et Microsoft sélectionne les zones.

  Pour sélectionner des zones vous-même ou pour créer un cluster zonal, utilisez une autre approche de déploiement comme les API Azure Resource Manager ou Bicep. Dans la plupart des cas, nous vous recommandons de créer un cluster redondant interzone et d’utiliser toutes les zones de la région.

  Note

  Lorsque vous sélectionnez les zones de disponibilité à utiliser, vous sélectionnez en fait la zone de disponibilité logique. Si vous déployez d’autres composants de charge de travail dans un autre abonnement Azure, ils peuvent utiliser un autre numéro de zone de disponibilité logique pour accéder à la même zone de disponibilité physique. Pour plus d’informations, consultez Zones de disponibilité physiques et logiques.

• Activer les zones de disponibilité sur un cluster existant (préversion) : Vous pouvez migrer un cluster nonzonal existant pour utiliser des zones de disponibilité. Cette fonctionnalité est en préversion. Pour plus d’informations, consultez Migrer votre cluster pour prendre en charge plusieurs zones de disponibilité.

• Reconfigurez les zones de disponibilité sur un cluster existant (préversion) : Vous pouvez modifier les zones utilisées pour un cluster. Cette fonctionnalité est en préversion. Pour plus d’informations, consultez Migrer votre cluster pour prendre en charge plusieurs zones de disponibilité.

• Désactivez la prise en charge des zones de disponibilité sur un cluster existant : Une fois qu’un cluster est configuré avec des zones de disponibilité, vous ne pouvez pas modifier le cluster pour ne pas utiliser de zones de disponibilité.

• Vérifiez la configuration de la zone de disponibilité pour les clusters : Vous pouvez utiliser la propriété d’état de zone du cluster (propriété zoneStatus dans l’API REST) pour vérifier la configuration de la zone de disponibilité d’un cluster.

  Si la valeur est Zonal, cela signifie que le cluster a été configuré pour utiliser des zones de disponibilité. Toutefois, le cluster peut être zonal ou redondant entre zones. Pour déterminer qui, utilisez la propriété zones . Si la liste des zones comporte une zone, le cluster est zonal (zone unique). S’il comporte plusieurs zones répertoriées, il est redondant entre zones.

Planification de capacité et gestion

Lorsqu’une zone de disponibilité n’est pas disponible, tous les nœuds de cette zone peuvent être temporairement indisponibles, ce qui réduit la capacité de calcul de votre cluster jusqu’à ce que la zone récupère.

Si votre cluster ne peut pas tolérer la perte de capacité, envisagez de surprovisionner votre cluster. Cette approche permet à la solution de tolérer une perte de capacité et de continuer à fonctionner sans dégradation des performances. Toutefois, lorsque vous surprovisionnez votre cluster, votre cluster peut avoir un nombre déséquilibré de nœuds entre les zones.

Distribution d’instances entre zones

La couche de calcul du cluster utilise une approche optimale pour répartir uniformément les instances entre les zones que vous sélectionnez.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque vous configurez un cluster pour la prise en charge des zones de disponibilité et que toutes les zones sont opérationnelles.

• Opération interzone : Pendant l’opération normale, Azure Data Explorer utilise tous les nœuds de calcul disponibles pour l’ingestion, le traitement des requêtes et d’autres opérations. Le travail est distribué entre les nœuds, quelle que soit leur zone de disponibilité.

• Réplication des données interzones : Le comportement de réplication des données interzone dépend de la configuration de la zone de disponibilité utilisée par votre cluster.

  • Redondant interzone : Les données sont répliquées de manière synchrone entre les zones de disponibilité à l’aide du stockage redondant interzone Azure. Cela fournit un niveau élevé de cohérence des données et réduit le risque de perte de données lors d’une défaillance de zone.

  • Zonale: Les données sont stockées à l’aide du stockage localement redondant Azure, ce qui signifie que les trois copies peuvent se trouver dans une seule zone de disponibilité.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque vous configurez un cluster pour la prise en charge des zones de disponibilité et qu’il existe une panne dans l’une des zones.

• Détection et réponse : La responsabilité de la détection et de la réponse dépend de la configuration de la zone de disponibilité utilisée par votre cluster.

  • Redondance de zone : Microsoft détecte les défaillances des zones de disponibilité et gère la réponse d'Azure Data Explorer. Vous n’avez rien à faire pour initier un failover de zone.

  • Zonale: Vous êtes responsable de la détection d’une panne qui affecte une zone de disponibilité employée par votre cluster. Vous êtes également responsable de toute réponse que vous décidez de lancer, par exemple passer à un deuxième cluster que vous avez créé précédemment dans une autre zone de disponibilité.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Demandes actives : Les requêtes actives qui s’appuient sur des ressources de calcul ou de stockage dans la zone ayant échoué peuvent être arrêtées et doivent être retentées par le client. Assurez-vous que vos applications sont préparées en suivant l’Guide de gestion des erreurs temporaires.

• Perte de données attendue : La perte de données attendue dépend de la configuration de la zone de disponibilité utilisée par votre cluster.

  • Redondance de zone : Aucune perte de données n’est attendue lors d’une interruption de zone de disponibilité, car les données sont répliquées de manière synchrone entre les zones.

  • Zone: Les données ne sont pas disponibles tant que la zone ne se rétablit pas. Dans le cas peu probable d’une perte permanente d’une zone qui contient tous vos réplicas de stockage, les données peuvent être perdues définitivement.

• Temps d’arrêt attendu : Le temps d’arrêt attendu dépend de la configuration de la zone de disponibilité utilisée par votre cluster.

  • Redondance par zones : Une brève interruption de service peut se produire pendant que le trafic est redirigé vers des zones de disponibilité opérationnelles. Assurez-vous que vos applications sont préparées en suivant l’Guide de gestion des erreurs temporaires.

  • Zonale: Les nœuds de calcul de votre cluster ne sont pas disponibles tant que la zone de disponibilité n’est pas récupérée. Vous risquez également de ne pas pouvoir accéder aux données de votre cluster lors d’une défaillance de zone.

• Redistribution: Le comportement de réacheminement du trafic dépend de la configuration de la zone de disponibilité utilisée par votre cluster.

  • Zone redondante : Azure Data Explorer achemine les nouvelles requêtes vers les ressources de calcul et de stockage situées dans les zones saines restantes.

  • Zonale: Votre cluster n’est pas disponible tant que la zone de disponibilité ne se rétablit pas.

Récupération de la zone

Lorsque la zone de disponibilité défaillante récupère, Microsoft recrée les nœuds de cluster et les répliques de stockage dans cette zone et restaure la distribution normale du trafic entre toutes les zones. Aucune action du client n’est nécessaire.

Tester les pannes de zone

Les options de test des défaillances de zone dépendent de la configuration de la zone de disponibilité utilisée par votre cluster.

• Redondance multi-zone : Le basculement et la récupération des zones de disponibilité pour Azure Data Explorer sont entièrement gérés par Microsoft. Vous n’avez pas besoin de lancer ou de valider les processus liés aux défaillances des zones de disponibilité.

• Zonale: Pour simuler partiellement la perte de tous les nœuds de calcul pendant une panne de zone, vous pouvez arrêter votre cluster. Vous pouvez utiliser cette approche pour valider des parties de vos propres processus de détection et de basculement interzone.

Résilience aux défaillances à l’échelle de la région

Un cluster Azure Data Explorer est déployé dans une seule région Azure. Si cette région devient indisponible, le cluster et ses données ne sont pas disponibles.

Solutions multirégions personnalisées pour la résilience

Pour réduire l’impact métier d’une panne de région, vous pouvez déployer des clusters Azure Data Explorer distincts dans plusieurs régions. Chaque cluster est indépendant et vous êtes responsable de la gestion de chaque cluster et de la coordination de la réplication des données, du routage du trafic et du basculement entre les régions.

Vous pouvez choisir entre différents types de configurations de cluster multirégion, qui prennent chacun en charge différents niveaux de temps de récupération, perte de données potentielle, effort et coût. Vous pouvez sélectionner des régions Azure pour chaque cluster qui prennent en charge vos exigences de latence et de résidence des données. Pour plus d’informations sur les configurations et les modèles de cluster multirégion que vous pouvez suivre, consultez Panne d’une région Azure.

Sauvegarde et restauration

Pour la plupart des solutions, vous ne devez pas vous appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités décrites dans ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas. Pour plus d’informations, consultez Que sont la redondance, la réplication et la sauvegarde ?.

Azure Data Explorer ne fournit pas de fonctionnalité de sauvegarde et de restauration native. Si vous avez besoin d’effectuer des sauvegardes de vos données, vous pouvez prendre en compte les approches suivantes :

• Exportation continue, qui exporte régulièrement des données vers un stockage externe et prend en charge exactement une fois l’exportation de données prises en charge.
• Exportation de données vers le stockage cloud, qui vous permet d’exporter manuellement des données vers un stockage externe.
• Ingérer des données brutes dans Azure Data Explorer à partir d’une source en amont, comme un lac de données, que vous pouvez sauvegarder séparément.

Résilience à la suppression accidentelle

Azure Data Explorer inclut plusieurs mécanismes pour vous aider à vous protéger contre la suppression accidentelle de clusters, de bases de données, de tables et de tables externes :

• Suppression accidentelle d’un cluster ou d’une base de données : La suppression accidentelle d’un cluster ou d’une base de données est une action irrécupérable. Vous pouvez empêcher la perte de données en activant un verrou de suppression sur la ressource de cluster ou de base de données.

• Suppression accidentelle de table : Les utilisateurs disposant d’autorisations d’administrateur de table ou supérieurs sont autorisés à supprimer des tables. Si l’un de ces utilisateurs supprime accidentellement une table, vous pouvez la récupérer à l’aide de la commande .undo drop table. Pour que cette commande aboutisse, vous devez d’abord activer la propriété de récupération dans la stratégie de rétention.

• Suppression accidentelle d’une table externe :les tables externes sont des entités de schéma de requête Kusto qui référencent les données stockées en dehors de la base de données. La suppression d’une table externe supprime uniquement les métadonnées de la table. Vous pouvez la récupérer en exécutant à nouveau la commande de création de table.

  Pour Azure Blob Storage et les tables externes Azure Data Lake, utilisez la fonctionnalité de suppression réversible pour vous protéger contre la suppression accidentelle ou le remplacement d’un blob pendant une durée configurée par l’utilisateur.

Résilience à la maintenance du service

Azure Data Explorer applique régulièrement des mises à jour de service et effectue une maintenance de routine. La plateforme Azure gère automatiquement ces activités tout en restant dans les niveaux de disponibilité spécifiés dans le contrat SLA. Assurez-vous que vos applications sont préparées pour une perte occasionnelle de connectivité pendant la maintenance du service en suivant les instructions de gestion des erreurs temporaires.

Pour en savoir plus sur la maintenance à venir, utilisez Azure Service Health.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.

Pour être éligible au contrat SLA de disponibilité d’Azure Data Explorer, votre application doit gérer les erreurs temporaires en réessayant les demandes ayant échoué.

Contenu connexe

• Fiabilité dans Azure
• Vue d’ensemble d’Azure Data Explorer
• Vue d’ensemble de la continuité d'activité et de la reprise d'activité