La reprise après sinistre avec CDCR offre un RPO en temps quasi réel

Meilleures pratiques Reprise après sinistre Recherche gérée Opérations Solr Service Solr

16 juin 2020

Dipsy Kapoor

6 min de lecture

Solr Reprise après sinistre Grâce au CDCR, vous pouvez synchroniser vos données quasi instantanément et réduire le RPO, un indicateur clé de la reprise après sinistre, à quelques minutes. Découvrez comment le CDCR améliore la reprise après sinistre et découvrez tous ses avantages, ses cas d'utilisation et ses limites.

Comment la reprise après sinistre est-elle améliorée grâce au CDCR ?

Réplication entre centres de données ou CDCR est la capacité de répliquer des données d'un centre de données source vers un ou plusieurs centres de données cibles.

Le concept de Objectif de point de récupération ou RPO est une mesure clé pour reprise après sinistreLe RPO définit la quantité de données que votre entreprise peut tolérer de perdre en cas d’urgence et détermine la fréquence à laquelle vous devez sauvegarder vos données et/ou les synchroniser sur votre infrastructure.

Lors de l'utilisation de CDCR pour la reprise après sinistre, la synchronisation est quasi instantanée et le RPO est mesuré en quelques minutes maximum. Du point de vue de Solr, les centres de données source et cible peuvent traiter les requêtes de recherche lorsque CDCR est opérationnel, et le risque associé à une perte de données ou à une panne est minime.

[Notez que CDCR n'est qu'une fonctionnalité stable dans Solr 7, n'est pas recommandé dans Solr 8 et n'est pas une fonctionnalité dans Solr 9.]

Quelle est la différence entre la reprise après sinistre de base et la reprise après sinistre avec CDCR ?

Chez SearchStax, notre option de reprise après sinistre de base utilise le mécanisme de sauvegarde et de restauration. Cela signifie que la sauvegarde crée un instantané du déploiement, des données de configuration et des métadonnées dans Zookeeper, ainsi que des fichiers JAR personnalisés, et le stocke sous forme de bundle. Ce bundle de sauvegarde est ensuite déplacé vers le cluster cible, un déploiement distinct situé à un emplacement différent du cluster source. Une fois le bundle restauré sur le cluster cible, les collections, les fichiers de configuration et les métadonnées sont reproduits exactement comme sur le cluster source.

Au cours du processus, l'opération copie l'intégralité des données de la collection source et les décompose périodiquement sur la cible. Ce processus présente plusieurs problèmes :

Devient difficile à manier à mesure que le nombre de collections et la taille des données augmentent
Consomme plus de ressources car vous devez sauvegarder toutes les données à chaque fois, au lieu de simplement les modifications delta par rapport au dernier point de sauvegarde.
Pendant la brève période pendant laquelle les données sources sont restaurées, le déploiement secondaire est indisponible pendant une brève période
Le RPO résultant peut aller jusqu'à quelques heures en fonction de la taille des données

Le résultat final de cette approche de cluster DR est une panne sur le cluster secondaire de 5 à 10 minutes généralement (mais cela pourrait être plus long en fonction de la taille des données) due au processus de synchronisation.

D'autre part, la reprise après sinistre avec CDCR offre une alternative simple et efficace pour la réplication de vos données. Imaginez un canal ouvert reliant les fichiers source aux fichiers cible, où toute mise à jour de la source est automatiquement transmise à la cible. La reprise après sinistre avec CDCR est conçue pour être robuste, même en cas de partitions réseau et de pannes de nœuds. Ceci est rendu possible grâce au suivi précis des mises à jour persistantes sur chaque nœud du système et à la réexécution des mises à jour ayant échoué jusqu'à leur transmission.

Il existe deux manières de configurer CDCR :

Unidirectionnel – Le CDCR unidirectionnel circule dans un seul sens, du cluster source vers un cluster cible. Lorsque des mises à jour unidirectionnelles sont configurées, les mises à jour et les suppressions sont d'abord écrites dans le cluster source, puis transmises à un ou plusieurs centres de données cibles.
Bidirectionnel – Le CDCR bidirectionnel démarre avec deux clusters : l'un comme source et l'autre comme cible. Avec les mises à jour bidirectionnelles, l'indexation et les requêtes doivent être effectuées sur un seul cluster à la fois pour garantir la cohérence. Le second cluster n'est utilisé que lorsque le premier est hors service. En termes simples, un cluster peut servir de source et l'autre de cible, mais les deux rôles, source et cible, ne peuvent pas être attribués simultanément à un même cluster.

Avantages de l'utilisation de la reprise après sinistre avec CDCR

Le principal avantage de l’utilisation du CDCR pour la reprise après sinistre est qu’il fournit une réplication plus propre et en temps quasi réel des données entre différents clusters.

Un autre avantage du CDCR pour la reprise après sinistre est sa capacité à réduire la bande passante et sa conception pour tolérer une certaine dégradation de la connectivité ou des situations de bande passante limitée. Le CDCR prend également en charge les mises à jour par lots, ce qui permet d'optimiser les canaux de communication.

Étant donné qu'il n'y a aucun temps d'arrêt du cluster de reprise après sinistre à aucun moment, CDCR fournit une solution de reprise après sinistre meilleure et plus disponible et le RPO sera mesuré en quelques minutes ou moins.

Cas d'utilisation de la reprise après sinistre avec CDCR

Le CDCR est utile lorsque les besoins métier en RPO sont très faibles pour la reprise après sinistre. Cependant, outre des temps de RPO plus courts, le CDCR peut être utile lorsque les données Solr doivent être synchronisées entre des déploiements couvrant un vaste réseau de diffusion de contenu (CDN) et desservant le trafic local.

Les clients pourraient disposer de plusieurs services ou installations d'applications finales à travers le monde pour offrir un service plus rapide. Par exemple, un fournisseur mondial aurait une instance d'application exécutée aux États-Unis, une en Europe et une en Asie-Pacifique. Afin de réduire les temps de réponse et d'accélérer le service, Solr pourrait être déployé dans chacune de ces régions, afin qu'elles communiquent avec les instances d'application locales.

Les déploiements Solr dans ces régions peuvent être synchronisés via CDCR. CDCR n'est pas limité au nombre de déploiements avec lesquels il peut se synchroniser et peut être utilisé pour synchroniser les données entre plusieurs déploiements.

La reprise après sinistre avec CDCR dans SearchStax Service pourrait être configurée comme suit :

Reprise après sinistre à chaud – La reprise après sinistre à chaud utilise les mêmes spécifications que le déploiement principal pour le déploiement secondaire dans une autre région. Il s'agit d'une réplique entièrement évolutive du serveur principal et peut gérer la même charge que ce dernier en cas de basculement.
Récupération de découverte à chaud – La reprise après sinistre à chaud utilise une version à nœud unique du déploiement principal pour le déploiement secondaire dans une autre région. Elle offre les mêmes RPO et RTO qu'une reprise après sinistre à chaud, mais en cas de basculement, le débit est moindre et les performances se dégradent.

Limites de la reprise après sinistre avec CDCR

Il n'existe pas de solution parfaite pour la reprise après sinistre. En termes de coût et de délai de reprise, des compromis seront toujours nécessaires. Par exemple, CDCR nécessite moins de bande passante car la synchronisation est incrémentielle, mais chaque modification de schéma devra être mise à jour manuellement par l'équipe d'assistance SearchStax.

Bien que les limites du CDCR soient relativement mineures, il est important de comprendre comment elles peuvent avoir un impact sur les besoins de votre entreprise :

Le CDCR doit être mis en place pour chaque collection – Cela signifie que chaque fois qu’une nouvelle collection est ajoutée, SearchStax doit être contacté pour ajouter la synchronisation pour la nouvelle collection.
CDCR synchronise uniquement les données – les modifications apportées aux configurations, aux alias ou aux fichiers JAR sur les déploiements doivent être synchronisées manuellement
Les implémentations CDCR actuelles ne prennent pas en charge l'authentification de base – L'implémentation actuelle du CDCR par la communauté Apache Solr ne fonctionne pas si l'authentification de base est activée. Cela reste vrai jusqu'à la version actuelle de Solr, Solr 8.11.
Les sauvegardes sont toujours importantes – CDCR ne dispense pas d'effectuer des sauvegardes régulières. Un index pourrait être supprimé accidentellement ou vos fichiers pourraient être corrompus ; il est donc conseillé de suivre une routine de sauvegarde régulière.
SearchStax ne prend en charge CDCR qu'à partir de la version 7.2.1 de Solr Bien que SOLR 6.6 intègre le CDCR, cette fonctionnalité ne prend pas en charge le bidirectionnel et l'amorçage. Pour ces raisons, SearchStax a décidé de prendre en charge le CDCR à partir de la version 7.2.1 de Solr.

Dipsy Kapoor, vice-président de l'ingénierie et Vignesh KumarIngénieur logiciel, co-auteur de cet article de blog.

Pour plus d'informations sur les options de récupération après sinistre de SearchStax, accédez à Options de reprise après sinistre pour les déploiements Solr.

La reprise après sinistre avec CDCR offre un RPO en temps quasi réel

Comment la reprise après sinistre est-elle améliorée grâce au CDCR ?

Quelle est la différence entre la reprise après sinistre de base et la reprise après sinistre avec CDCR ?

Avantages de l'utilisation de la reprise après sinistre avec CDCR

Cas d'utilisation de la reprise après sinistre avec CDCR

Limites de la reprise après sinistre avec CDCR

Par Dipsy Kapoor

vice-président, ingénierie

« Le principal avantage de l’utilisation du CDCR pour la reprise après sinistre est qu’il fournit une réplication plus propre et en temps quasi réel des données entre différents clusters. »

Recevez notre newsletter

Vous aimerez peut-être aussi :

Produits

Tarification

Ressources

Services

Ressources

Tarification

Entreprise