Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les mécanismes de réplication d’Azure HDInsight peuvent être intégrés à une architecture de solution hautement disponible. Dans cet article, une étude de cas fictive pour Contoso Retail est utilisée pour expliquer les approches possibles de récupération d’urgence à haute disponibilité, les considérations relatives aux coûts et leurs conceptions correspondantes.
Les recommandations de récupération d’urgence à haute disponibilité peuvent avoir de nombreuses permutations et combinaisons. Ces solutions doivent être arrivées après avoir délibérer les avantages et inconvénients de chaque option. Cet article traite uniquement d’une solution possible.
Architecture du client
L’image suivante illustre l’architecture principale de Contoso Retail. L’architecture se compose d’une charge de travail de diffusion en continu, d’une charge de travail par lots, d’une couche de service, d’une couche de consommation, d’une couche de stockage et d’un contrôle de version.
Charge de travail de diffusion en continu
Les appareils et les capteurs produisent des données sur HDInsight Kafka, qui constitue l’infrastructure de messagerie. Un consommateur HDInsight Spark lit les rubriques Kafka. Spark transforme les messages entrants et les écrit dans un cluster HBase HDInsight sur la couche de service.
Charge de travail par lot
Un cluster Hadoop HDInsight exécutant Hive et MapReduce ingère des données à partir de systèmes transactionnels locaux. Les données brutes transformées par Hive et MapReduce sont stockées dans des tables Hive sur une partition logique du lac de données soutenu par Azure Data Lake Storage Gen2. Les données stockées dans des tables Hive sont également mises à la disposition de Spark SQL, qui effectue des transformations par lots avant de stocker les données organisées dans HBase pour le service.
Couche de service
Un cluster HDInsight HBase avec Apache Phoenix est utilisé pour servir des données aux applications web et aux tableaux de bord de visualisation. Un cluster HDInsight LLAP est utilisé pour répondre aux exigences de création de rapports internes.
Couche de Consommation
Une couche d'API Apps et de Gestion des API Azure soutient une page web accessible au public. Les exigences de création de rapports internes sont remplies par Power BI.
Couche de stockage
Azure Data Lake Storage Gen2 partitionné logiquement est utilisé comme lac de données d’entreprise. Les metastores HDInsight sont soutenus par Azure SQL DB.
Système de contrôle des versions
Un système de contrôle de version intégré à Azure Pipelines et hébergé en dehors d’Azure.
Exigences en matière de continuité d’activité des clients
Il est important de déterminer la fonctionnalité métier minimale dont vous aurez besoin en cas de sinistre.
Exigences de continuité d’activité de Contoso Retail
- Nous devons être protégés contre une défaillance régionale ou un problème régional de santé des services.
- Mes clients ne doivent jamais voir une erreur 404. Le contenu public doit toujours être disponible. (RTO = 0)
- Pour la majeure partie de l’année, nous pouvons afficher du contenu public qui date de 5 heures. (RPO = 5 heures)
- Pendant la saison des fêtes, notre contenu public doit toujours être à jour. (RPO = 0)
- Mes exigences de création de rapports internes ne sont pas considérées comme essentielles à la continuité de l’activité.
- Optimisez les coûts de continuité d’activité.
Solution proposée
L’image suivante montre l’architecture de récupération d’urgence à haute disponibilité de Contoso Retail.
Kafka utilise la réplication active - passive pour mettre en miroir les rubriques Kafka de la région primaire vers la région secondaire. Une alternative à la réplication Kafka pourrait consister à produire sur Kafka dans les deux régions.
Hive et Spark utilisent des modèles de réplication Primaire Actif – Secondaire à la demande pendant les périodes normales. Le processus de réplication Hive s’exécute régulièrement et accompagne la réplication du metastore Azure SQL Hive et du compte de stockage Hive. Le compte de stockage Spark est répliqué régulièrement à l’aide d’ADF DistCP. La nature temporaire de ces clusters permet d’optimiser les coûts. Les réplications sont planifiées toutes les 4 heures pour atteindre un RPO qui est largement dans les cinq heures.
La réplication HBase utilise le modèle Leader – Follower pendant les heures normales pour s’assurer que les données sont toujours servies indépendamment de la région et que le RPO est très faible.
En cas d’échec régional dans la région primaire, la page web et le contenu principal sont servis à partir de la région secondaire pendant 5 heures avec un certain degré d’obsolescence. Si le tableau de bord d’intégrité du service Azure n’indique pas d’ETA de récupération dans la fenêtre de cinq heures, Contoso Retail crée la couche de transformation Hive et Spark dans la région secondaire, puis pointe toutes les sources de données en amont vers la région secondaire. Rendre la région secondaire accessible en écriture provoquerait un processus de restauration qui implique la réplication vers la région principale.
Pendant une période de pointe des achats, l’ensemble du pipeline secondaire est toujours actif et en fonctionnement. Les producteurs Kafka produisent dans les deux régions, et la réplication HBase est changée de Leader -Suiveur à Leader - Leader pour s’assurer que le contenu public est toujours à jour.
Aucune solution de basculement n’a besoin d’être conçue pour les rapports internes, car elle n’est pas essentielle à la continuité de l’activité.
Prochaines étapes
Pour en savoir plus sur les fonctionnalités présentées dans cet article, voir :