Failover du serveur de fichiers

serveur cible vienne remplacer la source. Le temps nécessaire au logiciel pour détecter une défaillance de connexion a représenté 10 secondes sur les 40. Pendant un failover, un stream de copies de fichiers s’écoule vers le serveur de fichiers. Toute opération de copie de fichier touchée par un time out – ou qui ne parvient pas à  s’exécuter – pendant cette période est jugée perdue. Octopus permet d’indiquer une valeur Max Wait Time dans l’option Target Option du menu Switchover. J’ai mis cette valeur à  10 secondes – si le système cible ne peut pas contacter la source en 10 secondes, le système cible en conclut que la source est défaillante. Cette valeur a fonctionné dans mon environnement de test, mais si vous n’utilisez que le mécanisme de déclenchement de failover intégré dans Octopus, une liaison WAN non fiable pourrait compromettre la fiabilité de votre solution. Les failovers manuels ou scriptés sont probablement un choix plus sûr.

Pour revenir aux définitions de serveur originales après un SASO – Alias failover, enlevez le nom du système source de la liste Added Names du système cible, puis revalidez et synchronisez les spécifications appropriées sur le système source. Ce processus est bien plus simple que les processus de reprise SASO et ASO, qui demandent davantage de configuration des noms et des adresses IP.

BrightStor High-Availability Manager s’est bien comporté avec un failover manuel, en perdant une opération de fichier, mais le test de perte de connectivité a abouti à  un délai d’environ 40 secondes avant que le serveur secondaire ne prenne le relais du serveur primaire. Le timing pour détecter des défaillances de communication est un composant du réglage de la vitesse de liaison de la tâche de réplication. CA met en garde contre toute vitesse de liaison excessive, susceptible de détecter à  tort une défaillance. Pour rétablir les serveurs dans leurs rôles d’origine, accédez à  l’écran BrightStor High-Availability Manager principal sur le système cible, allez au menu Server, et exécutez le Reinstate Wizard. Le wizard vous demande de préciser quel serveur vous voulez restaurer. Après quoi, vous pouvez choisir de planifier l’opération, d’avertir les utilisateurs avant l’opération, et de redémarrer la tâche de réplication une fois la restauration terminée.

Les procédures de failover et de restauration effectuent toutes deux une réinitialisation du serveur primaire. C’est sans importance dans le cas d’un failover, mais sachez qu’après la restauration, aucun serveur ne jouera le rôle de serveur primaire tant que le serveur primaire original n’aura pas été entièrement réinitialisé. Dans mon environnement, la restauration et la réinitialisation se sont terminées en moins de 4 minutes. Le processus de failover et de restauration de BrightStor High-Availability Manager est plus automatisé et plus convivial que ceux d’Octopus et de Double-Take.

Le processus de failover manuel de Double-Take est pratiquement instantané. Le failover de perte de connectivité automatique implique une valeur Time to Fail plutôt longue, mais si vous savez que le failover est imminent, vous pouvez cliquer sur le bouton Failover pour raccourcir l’attente. Pendant un failover manuel, le nom et l’adresse IP de l’ordinateur source ne changent pas et l’ordinateur n’est pas retiré du réseau. Il y a donc des conflits d’adresses IP et de noms. Pour revenir à  la normale après un failover, j’ai cliqué sur Failback dans le Failover Control Center. Cette manoeuvre a supprimé immédiatement l’identité du serveur source de la cible, et le logiciel m’a invité à  redémarrer ou à  arrêter la supervision du serveur source. Après avoir redémarré le serveur source, j’ai ordonné à  Double-Take de redémarrer la supervision du serveur. A ce stade, il y avait deux jeux de données différents sur les systèmes source et cible, et je pouvais soit copier des fichiers individuels manuellement à  partir de la cible dans la source, soit utiliser Restoration Manager de Double-Take pour restaurer tout le jeu de réplication. J’ai choisi la méthode de copie manuelle, qui a restauré toutes les opérations de fichier qui n’avaient pas été perdues pendant la période de timeout du failover, du serveur cible vers le serveur source.