Failover de SQL Server

pour configurer les machines SQL Server, personnaliser les scripts, et créer une nouvelle spécification pour mirrorer les répertoires de données de SQL Server pour permettre un failover efficace. Après avoir constaté des discordances entre les scripts et les exemples de scripts de la documentation, j’ai demandé une clarification à  Legato. Un technicien d’assistance m’a envoyé un jeu simplifié d’instructions et une mise à  niveau pour passer à  Octopus 4.2, build 330b, qui m’a permis d’utiliser SASO – Alias pour accomplir le failover SQL Server. Après le processus de failover manuel de 30 secondes, un message d’erreur m’a informé que certains fichiers étaient ouverts pendant le failover et qu’il était donc prudent de les inspecter avant de les mettre en service. Le processus de failover et de rétablissement a semblé facile après quelques essais, mais je recommande un test approfondi et une bonne documentation des procédures propres à  votre environnement, pour garantir le succès.

Comme je l’ai indiqué dans la section Installation et configuration, BrightStor High-Availability Manager charge Application Notes sur le serveur pendant une installation classique. Pour configurer les serveurs en vue de tests de failover de SQL Server, j’ai consulté Application Notes for Microsoft SQL Server 6.5 and 7.0. J’ai exécuté le Replication Task Wizard pour établir les paramètres initiaux d’une tâche (c’est-à -dire, sélectionner les dossiers répliqués et valider le failover IP), puis j’ai cliqué sur Advanced Edit pour ouvrir la fenêtre Editing Task et la console BrightStor High-Availability Manager, illustrée dans la figure 3. Dans le Task Editor, j’ai créé un Workload pour répliquer mon répertoire de données SQL Server, indiqué des chemins de destination pour les données et attribué le script SQL Server fourni, aux actions de failover et de restauration sur les deux serveurs. (Le script contient du code pour le failover et la restauration.) Les temps de failover ont été identiques à  ceux des tests du serveur de fichiers, mais le test de perte de connectivité a entraîné la perte de plus de transactions que le test de failover manuel. Les processus de failover et de restauration pour SQL Server se sont effectués impeccablement, avec peu de préparation ou d’intervention.

Pour configurer SQL Server et Double-Take dans mon environnement de test, j’ai téléchargé les notes d’application High Availability for Microsoft SQL Server Using Double-Take 4.x et les scripts associés à  partir du site Web de NSI Software et j’ai simplement suivi les instructions. La configuration du failover et du failback de SQL Server de Double-Take a demandé davantage d’opérations manuelles que BrightStor High-Availability Manager, mais les opérations étaient claires et simples. Cependant, j’aurais aimé que la documentation dise plus clairement sur quel serveur je devais effectuer certaines actions. J’ai ouvert le Failover Control Center et cliqué sur Edit Monitor. Dans la fenêtre Monitor Settings, j’ai modifié les deux scripts téléchargés et j’ai précisé quand Double-Take devait les exécuter.

Double-Take a répondu par un processus de failover rapide. Au terme du timeout du failover, le serveur cible a supposé l’identité du serveur source, les services SQL Server ont démarré et le serveur cible a entamé les transactions de traitement. Pour faire un « failback » vers le serveur source, j’ai suivi les mêmes étapes que pour le failback du serveur de fichiers mais cette fois-ci j’ai utilisé le Restoration Manager pour restaurer tout le jeu de données de réplication du système cible sur le source. Le logiciel a restauré sur le serveur source toutes les opérations de fichier qui n’avaient pas été perdues pendant la période de timeout du failover.