Vue d’ensemble de la continuité d'activité et de la reprise d'activité

La continuité d’activité et la reprise d’activité dans Azure Data Explorer permettent à votre entreprise de continuer à fonctionner face à une interruption. Cet article détaille plusieurs configurations de récupération d’urgence en fonction des exigences de récupération d’urgence (RPO et RTO), des efforts et des coûts nécessaires.

Pour plus d’informations sur les options de fiabilité disponibles pour Azure Data Explorer, notamment la prise en charge de zone de disponibilité, la sauvegarde et la protection contre certains types d’erreurs humaines, consultez Reliability in Azure Data Explorer.

Configuration de la récupération d'urgence

L’objectif de délai de récupération (RTO) fait référence au délai nécessaire pour procéder à une récupération après une interruption. Par exemple, un RTO de 2 heures signifie que l’application doit être en cours d’exécution dans les deux heures qui suivent une interruption. L’objectif de point de récupération (RPO) fait référence à l’intervalle de temps qui peut s’écouler pendant une interruption avant que la quantité de données perdues au cours de cette période dépasse le seuil autorisé. Par exemple, si le RPO est de 24 heures et qu’une application contient des données remontant à 15 ans, elles sont toujours dans les paramètres du RPO convenu.

Les processus d’ingestion, de traitement et d’intégration nécessitent une conception diligente au moment de la planification de la récupération d’urgence. L’ingestion fait référence aux données intégrées aux Azure Data Explorer de diverses sources ; le traitement fait référence aux transformations et aux activités similaires ; la curation fait référence à des vues matérialisées, des exportations vers le lac de données, et ainsi de suite.

Voici les configurations populaires de récupération d’urgence :

• Configuration Active-Active-Active (Toujours en marche)
• Configuration active-active
• Configuration de secours active
• Configuration de cluster de récupération de données à la demande

Configuration Active-Active-Active

Cette configuration est également appelée always-on. Pour les déploiements d’applications critiques sans tolérance aux pannes, vous devez utiliser plusieurs clusters Azure Data Explorer entre les régions jumelées Azure. Configurez l’ingestion, le traitement et l’intégration en parallèle pour tous les clusters. La référence SKU du cluster doit être la même dans toutes les régions. Azure garantit que les mises à jour sont déployées et réparties entre les régions jumelées Azure. Une panne de région Azure n'entraîne pas de panne d'application. Vous pouvez rencontrer une certaine latence ou dégradation des performances.

Configuration active-active

Cette configuration est identique à la configuration active-active-active, mais implique uniquement deux régions jumelées Azure. Configurez l’ingestion, le traitement et la curation doubles. Les utilisateurs sont acheminés vers la région la plus proche. La référence SKU du cluster doit être la même dans toutes les régions.

Configuration de secours en veille active

La configuration Active-Hot est similaire à la configuration active-active en matière d’ingestion, de traitement et de curation en double. Bien que le cluster de secours soit en ligne pour l'ingestion, le traitement et la conservation, il n'est pas disponible pour les requêtes. Le cluster de secours n’a pas besoin d’être dans la même référence SKU que le cluster principal. Il peut s'agir d'un SKU plus petit et d'une échelle plus petite, ce qui peut résulter en des performances réduites. Dans un scénario de sinistre, les utilisateurs sont redirigés vers le cluster de secours, ce qui peut éventuellement être mis à l’échelle pour augmenter les performances.

Configuration de la récupération des données à la demande

Cette solution offre la récupération la plus faible (le RPO et le RTO les plus élevés), est la moins coûteuse et nécessite le plus d'effort. Dans cette configuration, il n’existe aucun cluster de récupération de données. Configurez l’exportation continue de données organisées (sauf si des données brutes et intermédiaires sont également requises) sur un compte de stockage configuré pour le stockage géoredondant (GRS). Un cluster de récupération de données est lancé s’il existe un scénario de récupération d’urgence. Dès lors, les DDL, la configuration, les stratégies et les processus sont appliqués. Les données sont ingérées à partir du stockage avec la propriété kustoCreationTime pour remplacer l'heure d'ingestion par défaut, qui est l'heure système.

Résumé des options de configuration de récupération d'urgence

Bonnes pratiques

Quelle que soit la configuration de récupération d’urgence choisie, suivez les meilleures pratiques suivantes :

• Tous les objets de base de données, stratégies et configurations doivent être conservés dans le contrôle de code source de manière à pouvoir être utilisés dans le cluster à l’aide de votre outil d’automatisation de lancement. Pour plus d’informations, consultez la prise en charge d'Azure Data Explorer par Azure DevOps.
• Concevez, développez et implémentez des routines de validation pour vous assurer que tous les clusters sont synchronisés en termes de données. Azure Data Explorer prend en charge les jointures inter-clusters. Un simple nombre de lignes dans les tables peut faciliter la validation.
• Les procédures de mise en œuvre doivent impliquer des mécanismes de contrôle et d'équilibre de gouvernance afin de garantir la réplication des clusters.
• Soyez pleinement conscient de ce qu'il faut pour construire un cluster depuis zéro.
• Créez une liste de contrôle des unités de déploiement. Votre liste est unique à vos besoins, mais doit inclure les scripts de déploiement, les connexions d’ingestion, les outils décisionnels et d’autres configurations importantes.

Étape suivante