How Does Solr Disaster Recovery Work with SearchStax?

25 juillet 2022

Thomas DiLascio

5 min de lecture

Nous recevons des questions sur le fonctionnement du processus de reprise après sinistre (DR) de SearchStax avec Recherche gérée D'un point de vue opérationnel, nous détaillons les détails dans cet article. SearchStax propose trois options de reprise après sinistre pour les déploiements Solr afin de répondre à divers besoins métier : reprise à chaud, reprise à chaud et reprise à froid. Pour en savoir plus sur la reprise après sinistre SearchStax, consultez notre Article de blog sur les options Solr DR.

Que sont le RTO et le RPO pour la reprise après sinistre ?

Avant d'aborder le fonctionnement de Solr Disaster Recovery dans SearchStax, voici un bref rappel sur deux termes essentiels de la reprise après sinistre : le RTO et le RPO. Consultez notre article de blog sur Les R importants pour un plan de reprise après sinistre Solr pour plus de détails sur ces concepts importants.

Objectif de temps de récupérationLe RTO (ou RTO) correspond à la durée pendant laquelle votre service Solr peut être indisponible en cas d'urgence. Il définit le délai maximal acceptable d'échec des requêtes Solr de votre application avant la restauration d'un état sain.

Objectif du point de récupérationLe RPO (ou RPO) définit la durée pendant laquelle vos données de reprise après sinistre peuvent être obsolètes par rapport à celles stockées dans le déploiement de production au moment d'un incident de reprise après sinistre. Si votre entreprise peut tolérer la perte de quatre heures de documents récents ajoutés, mis à jour et/ou supprimés de Solr, un RPO de quatre heures est considéré comme acceptable.

Comment les index Solr sont-ils mis à jour lors d'un déploiement DR ?

Dans cet exemple, nous supposerons un déploiement Solr avec une stratégie DR à chaud qui comprend un RPO de 24 heures et un RTO de 10 minutes.

Pour atteindre ces objectifs commerciaux, nous effectuons une sauvegarde toutes les 24 heures. Cette sauvegarde inclut tous les fichiers de configuration Solr, les collections Solr, les alias, les fichiers de sécurité et les fichiers JAR personnalisés. Une fois la sauvegarde effectuée, un processus de restauration est lancé dans l'environnement de reprise après sinistre. Ce processus de sauvegarde/restauration se poursuit jour après jour afin de respecter le RPO de 24 heures.

SearchStax envoie-t-il une notification concernant l'indisponibilité du déploiement Solr et le lancement du mécanisme de basculement ?

Nous utilisons plusieurs canaux de notification pour les événements de reprise après sinistre. Tout d'abord, les utilisateurs du compte affectés aux alertes Heartbeat seront avertis par e-mail lorsque les nœuds Solr seront inaccessibles. Après 5 minutes d'inaccessibilité des deux nœuds Solr, un événement de reprise après sinistre sera déclenché. Un ticket d'assistance SearchStax sera alors créé et notre équipe mettra en copie les utilisateurs spécifiés pour les informer de la survenue d'un événement de reprise après sinistre. Un lien de réunion sera inclus pour permettre aux utilisateurs de rejoindre la réunion et de collaborer avec notre équipe sur l'incident.

Comment les offres SearchStax DR gèrent-elles le routage du trafic ?

Les offres de reprise après sinistre SearchStax s'appuient sur un DNS personnalisé (ou CName) pour acheminer le trafic du cluster principal vers l'environnement secondaire et inversement. Une fois SearchStax DR entièrement configuré, une URL personnalisée est attribuée au cluster principal. Le mécanisme de reprise après sinistre déclenche une mise à jour de l'entrée DNS derrière cette URL personnalisée en cas d'événement de reprise après sinistre. Toutes les requêtes adressées à cette URL personnalisée sont alors acheminées vers l'environnement secondaire tant que le cluster principal est défaillant.

Une application client peut toujours se connecter à l'URL standard de Solr, mais l'URL personnalisée doit être utilisée pour exploiter les fonctionnalités de reprise après sinistre. Lors du processus d'intégration, il est important de mettre à jour l'application pour qu'elle se connecte à Solr via l'URL personnalisée avant la mise en service ou le test de reprise après sinistre avec votre équipe d'intégration SearchStax.

Vous trouverez ci-dessous un exemple de l'apparence d'une URL Solr standard par rapport à une URL Vanity.

URL Solr standard – https://ss922224-65jkma1y-westus-azure.searchstax.com/solr/
URL de vanité – https://clientname-prod.searchstax.com/solr/

Comment SearchStax teste-t-il le processus Solr DR ?

Lorsque nous effectuons un test de reprise après sinistre ponctuel lors de l'intégration, nous nous efforçons de le rendre aussi réaliste que possible. Pour commencer, nous vérifions quels utilisateurs doivent être informés d'un événement de reprise après sinistre en direct afin que notre procédure opérationnelle standard (POS) puisse être mise à jour en conséquence.
Pour tenir votre équipe informée des événements de reprise après sinistre, vous devez également vous assurer que tous vos utilisateurs critiques sont configurés pour recevoir des alertes Heartbeat et que nous disposons d'une liste complète des utilisateurs qui doivent être informés des événements d'échec de reprise après sinistre.
Lors d'un test de reprise après sinistre, une catastrophe simulée se produit, durant laquelle l'équipe rend le cluster principal indisponible. Nous effectuons une liste de contrôle côté SearchStax, mais pour le client, il est judicieux de vérifier depuis l'application que les objectifs RTO et RPO sont respectés.
Nous utilisons la liste de contrôle suivante pour confirmer un test DR réussi avec les clients.

Quelles mesures prenons-nous lors d’un véritable incident Solr DR ?

Voici les étapes que nous suivons lors d’un véritable incident de reprise après sinistre :

L'équipe SearchStax reçoit une alerte d'indisponibilité de nœud et commence à travailler sur le problème
SearchStax tente de redémarrer le nœud Solr et de ramener les collections à un état sain
Si tous les nœuds Solr d'un cluster deviennent indisponibles pendant 5 minutes, cela déclenche un basculement DR
SearchStax reçoit un ticket d'assistance qui nous informe que DR a été déclenché et qu'un changement DNS va se produire
La propagation DNS prend 1 à 2 minutes après les 5 premières minutes. Notre objectif est d'atteindre un RTO inférieur à 10 minutes pour les DR tièdes et à chaud.
L'étape suivante de SearchStax consiste à informer votre équipe via le ticket d'assistance qu'un basculement DR s'est produit et à fournir un lien de réunion pour que vos utilisateurs puissent se joindre et résoudre le problème ensemble.
SearchStax continue de travailler pour mettre en service les nœuds Solr du cluster principal et attendre que les collections se rétablissent
Si nous recevons des réponses par e-mail ou via la salle de réunion, nous travaillons avec l'équipe du client pour coordonner le retour du DNS au cluster principal.
Si nous ne recevons aucune réponse de vos équipes, nous vous redéplaçons vers le serveur principal dès que toutes les collections sont saines.
Si vous avez souscrit à l'abonnement Platinum ou Platinum Plus, SearchStax propose des analyses rétrospectives en complément. Nous vous envoyons un rapport d'analyse rétrospective sous 3 jours ouvrés et prenons rendez-vous avec votre équipe pour analyser la situation, répondre à vos questions et identifier les prochaines étapes.

Maintenant que vous disposez d'une explication claire des options DR de SearchStax et du fonctionnement de la reprise après sinistre, vous serez en mesure de décider vous-même quelle option correspond le mieux à votre cas d'entreprise et à vos besoins.

Comment Solr Disaster Recovery fonctionne-t-il avec SearchStax ?

Que sont le RTO et le RPO pour la reprise après sinistre ?

Comment les index Solr sont-ils mis à jour lors d'un déploiement DR ?

SearchStax envoie-t-il une notification concernant l'indisponibilité du déploiement Solr et le lancement du mécanisme de basculement ?

Comment les offres SearchStax DR gèrent-elles le routage du trafic ?

Comment SearchStax teste-t-il le processus Solr DR ?

Quelles mesures prenons-nous lors d’un véritable incident Solr DR ?

Par Thomas DiLascio

Chef de produit senior

« …la recherche ne devrait pas être réservée uniquement aux organisations disposant de budgets de recherche massifs… »

Recevez notre newsletter

Vous aimerez peut-être aussi :

Produits

Tarification

Ressources

Services

Ressources

Tarification

Entreprise