Solrcloud Disaster Recovery – Alternative à CDCR

Solrcloud CDCR

Solrcloud Cross Data Center Replication – CDCR de Solrcloud permet de répliquer en temps réel un Cluster Solrcloud vers un ou plusieurs autres cluster. Le CDCR est principalement utilisé pour traiter deux besoins.

• Le premier besoin concerne la gestion des Disaster Recovery après un événement grave. Le CDCR permet de disposer d’une copie d’un cluster Solrcloud dans un datacenter différent. Il est alors possible de basculer sur le second cluster en cas d’indisponibilité prolongée du cluster principal et ainsi subir une indisponibilité la plus courte possible.
• Le second besoin est de disposer d’un cluster proche géographiquement des utilisateurs. Un cluster principal est mis à jour et est utilisé pour des recherches locales. Des clusters secondaires dans d’autres zones géographiques se synchronisent sur le cluster principal. Ils sont utilisés pour les recherches de leur zone géographique.

Le CDCR disparaît dans la version 9 de Solr et à ce jour aucune solution de remplacement n’est annoncée. Dans cet article, nous proposons une solution alternative afin de couvrir le premier besoin : la gestion des Disaster Recovery.

Disaster Recovery : RTO et RPO

Lors de la mise en place d’un plan de Disaster Recovery, deux objectifs sont à définir :

• Le RTO (Recovery Time Objective) qui est l’objectif de durée maximale d’interruption du service
• Le RPO (Recovery Point Objective) qui est l’objectif de quantité maximum de perte des modifications des données.

La solution présentée dans cet article optimise le RTO. Elle permet en temps réel de disposer dans un datacenter « secondaire » d’une copie des données du cluster SolrCloud. Le but est de ne perdre au maximum que quelques secondes de mise à jour.

Les types de replica SolrCloud

Depuis la version 7 de Solr, il est possible de mettre en place Les 3 types de réplicas de Solrcloud. En voici une description simplifiée :

• Les replicas NRT : Ce sont des replica qui réalisent l’indexation des données (analyse des données, création et écritures des segments, merges). Pour un shard, il existe toujours au minimum un replica NRT qui est le leader.
• Les replicas TLOG : Ce sont des réplicas qui ne réalisent pas l’indexation des données mais qui se synchronisent auprès du réplica leader. Un replica TLOG peut devenir leader.
• Les replicas PULL : Tout comme les replicas TLOG sont des réplicas qui ne réalisent pas l’indexation des données mais qui se synchronisent auprès du réplica leader. Un replica PULL ne peut pas devenir leader.

Le délai de réplication d’un replica TLOG ou PULL avec le leader est définie ainsi :

• 50% du maxTime du autoCommit
• Si il n’y a pas de autoCommit configuré, alors 50% du maxTime du autoSoftCommit
• à défaut, 15 secondes

La quantité maximum de perte des modifications des données en cas de panne grave correspond donc au maximum à deux fois ce délai (car la panne peut intervenir durant un réplication).

Pour une description très complète de ces 3 types de replicas et de leur fonctionnement, nous conseillons la lecture de ces deux très bons articles en Anglais :

• Solr 7 – New Replica Types
• Solr’s replication modes in details

Il existe deux cas d’usage pour une collection :

• Besoin de recherches NRT (Near Real Time Searching)
  Dans ce cas, les replicas sont de type NRT. Les indexations sont réalisées par chaque réplica et donc l’organisation de leurs fichiers segments sont différents. Si aux replicas NRT s’ajoutent un ou plusieurs replicas PULL, une ré-élection de leader impose une synchronisation complète des données du nouveau leader vers les replicas PULL.
• Pas besoin de recherches NRT
  Dans ce cas, les replicas sont de type TLOG. Les indexations sont réalisées par un seul replica et donc l’organisation de leurs fichiers segments sont identiques par synchronisation. Si aux replicas TLOG s’ajoutent un ou plusieurs replicas PULL, une ré-élection de leader n’impose pas une synchronisation complète des données du nouveau leader vers les replicas PULL puisque le nouveau leader est une copie de l’ancien.

Near Real Time Searching

Petite parenthèse au sujet de la notion de « recherche NRT » ou « Near Real Time Searching ».

Comme le dit la documentation Solr, « Near Real Time (NRT) Searching » signifie que les documents sont disponibles rapidement après leur indexation. Les mots importants ici sont « Near » et « rapidement ». Jamais avec Solr (et pas plus avec elasticsearch d’ailleurs) les documents peuvent être disponibles immédiatement apres leur indexation. En effet, les étapes entre la requête d’indexation d’un document et la possibilité de le voir apparaître dans les résultats sont multiples :

1. La requête d’indexation prend un certain temps qui correspond à l’indexation par le leader qui a lui-même attendu la confirmation des indexations par les replicas NRT.
2. Après le retour positif de la requête d’indexation, il est nécessaire qu’un softCommit soit exécuté sur chaque replica. Le délai va de quelques millisecondes à quelques centaines de millisecondes selon la configuration et selon le moment où est indexé le document.
3. A l’issue de ce softCommit, un searcher doit être ouvert sur chaque réplica et éventuellement préchauffé.

L’indexation par chaque réplica qui ont des cycles de softCommit non synchronisés fait que le document indexé sera disponible plus ou moins rapidement sur chaque réplica. Deux requêtes lancées simultanément et rapidement après l’indexation pourront remonter ou pas le document en fonction du replica utilisé.
Au final, le délai de mise à disposition du document peut parfois (rarement) être inférieur au délai configuré dans le softCommit, mais le plus souvent être bien supérieur. Autant dire que le rapidement signifie généralement plusieurs centaines de millisecondes.

Principe de la solution

La solution proposée s’appuie sur la mise en place d’un replica dans le datacenter secondaire pour chaque shard des collections du datacenter principal.
Pour les indexations, si un problème ou un arrêt temporaire d’un nœud Solr se produit, il ne faut pas que les nouveaux leaders soient élus parmi les replicas du datacenter secondaire. Ces replicas sont donc de type « PULL ».
Pour les recherches, il n’est pas souhaitable que les replicas du datacenter secondaire soient utilisés. Les requêtes utiliseront le paramètre « shards.preference » pour l’indiquer à Solr.

Mise en oeuvre de la solution

Traitement du RPO – La sauvegarde des données

Au Solrcloud installé dans le datacenter principal, on ajoute un nœud Solr dans le datacenter secondaire. Ce nœud a pour vocation d’héberger les réplicas de type PULL. Il est nécessaire de disposer de suffisamment d’espace disque, mais pas nécessairement d’une puissance CPU ou d’une quantité de mémoire importante. Par contre, il est impératif que la bande passante réseau entre les deux datacenters soit importante surtout en cas de ré-élection de leaders avec des replicas de type NRT.

Le schéma ci-dessous montre les deux datacenters. Le datacenter principal avec les serveurs Zookeeper et les nœuds Solr qui hébergent les replicas NRT ou TLOG. Le datacenter secondaire et le nœud Solr qui héberge les replicas PULL. Le nœud Solr du datacenter secondaire fait partie du Cluster SolrCloud et se connecte à l’ensemble Zookeeper.

La création d’une collection

La création d’un collection se fait en deux étapes :

• La création des shards et replicas NRT ou TLOG dans le datacenter principal. Les nœuds cibles sont indiqués au moyen du paramètre « createNodeSet »

curl 'http://localhost:8983/solr/admin/collections?action=CREATE&name=sirene&numShards=4&tlogReplicas=2&createNodeSet=solr_p1:8983_solr,solr_p2:8983_solr,solr_p3:8983_solr,solr_p4:8983_solr&maxShardsPerNode=-1&wt=json'

• La création des replicas PULL dans le datacenter secondaire. Pour chaque shard, on ajoute un replica en spécifiant le nœud cible au moyen du paramètre « createNodeSet »

curl 'http://localhost:8983/solr/admin/collections?action=ADDREPLICA&collection=sirene&shard=shard1&createNodeSet=solr_s1:8983_solr&type=pull&wt=json'

Les recherches

Afin que les recherches ne soient pas pénalisées par les replicas de type PULL (délais réseau, faible puissance CPU, faible mise en cache des index, …), il est nécessaire de les exclure de la recherche. Pour cela, les requêtes spécifient une préférence pour les shards à utiliser au moyen du paramètre « shards.preference » et au choix des propriétés « replica.type » ou « replica.location »

Pour indiquer de ne pas utiliser de replica PULL pour traiter la requête

shards.preference=replica.type:NRT,replica.type:TLOG 

Pour indiquer la liste des nœuds Solr à utiliser pour traiter la requête

shards.preference=replica.location:http://solr_p1,replica.location:http://solr_p2:http://solr_p3,replica.location:http://solr_p4 

Traitement du RTO – Remettre en route un Cluster SolrCloud

Lors d’un événement grave impliquant la non disponibilité prolongée du datacenter principal, il va être nécessaire de mettre en route un cluster SolrCloud dans le datacenter secondaire. Chaque société décidera de la stratégie à mettre en place selon ses contraintes et ses procédures internes. Cependant, il y a quelques principes à respecter au moment de la mise en place des données sauvegardées.

Imaginons que la solution est de disposer dans le datacenter secondaire d’un cluster SolrCloud identique à celui du datacenter principal. Ce cluster en sommeil (VM éteintes) est démarré. Les collections sont créées et les données sauvegardées mise en place. Pour cela, la procédure suggérée est la suivante :

• Démarrage du Cluster Solrcloud
• Création des collections avec le même nombre de shards, mais avec un unique replica NRT ou TLOG. Ce replica est de fait un leader.
• Arrêt des nœuds Solr.
• Effacement du contenu des répertoires index des différents shards des collections
• Copie dans les répertoires index des différents shards des données sauvegardées
• Redémarrage nœuds Solr
• Ajout des replicas aux shards des collections

Conclusion

La solution proposée dans cet article permet d’atteindre un RPO piloté par la configuration autoCommit / autoSoftCommit des collections, soit de quelques secondes à quelques minutes pour la quantité maximum de perte des modifications des données. Le RTO pour la durée maximale d’interruption du service correspond au temps de prise de décision, à la durée de démarrage du cluster dans le datacenter secondaire et au délai de mise en place des données sauvegardées.

Attention, cette solution ne protège pas d’erreurs de manipulations telles que la suppression massive de documents ou la suppression d’une collection !

Vous souhaitez bénéficier d’une expertise Solr ou intégrer une ressource ponctuelle à vos projets ? Rendez vous sur la page Contact