Dans le domaine de la continuité des affaires, deux processus essentiels — le failover et le failback — jouent des rôles complémentaires, mais distincts. Alors que le premier permet de maintenir l’accès à un système en cas de défaillance, le second autorise un retour à l’état normal après une crise. Comprendre cette dynamique est primordial.
Une distinction clé dans le domaine de la récupération après sinistre est celle entre failover et failback. Les deux termes décrivent deux volets d’une même réalité, des processus complémentaires souvent associés.
Cependant, leurs effets et objectifs ne pourraient pas être plus différents. Tous deux jouent des rôles tests dans l’assurance de la continuité des affaires et de la récupération après sinistre, rendant essentiel de comprendre ce qu’ils sont et comment ils diffèrent.
Qu’est-ce que le failover ?
Le failover est une opération de continuité des affaires qui garantit un accès continu à un système en effectuant une transition complète vers une autre instance de ce système. Ce système secondaire est conçu pour être résilient, idéalement non affecté par l’événement qui a compromis le système principal.
En termes simples, le failover se produit lorsque la connectivité est transférée d’une instance système à une autre. Cela peut se faire de diverses manières, notamment :
Note de l’éditeur :
Ce billet de blog invité a été rédigé par l’équipe de Pure Storage, une entreprise technologique cotée en bourse dédiée aux solutions de stockage de données entièrement flash pour les entreprises. Pure Storage maintient un blog très actif, il s’agit de l’un de leurs articles « Purement Éducatifs » que nous reproduisons ici avec leur autorisation.
- Passage d’un système principal à un système de secours
- Transition vers un système de secours chaud ou froid
- Activation d’un système de sauvegarde en cas de défaillance ou à des fins de test
- Changement soit manuellement soit automatiquement
Le point test concernant le failover est qu’il implique une migration complète d’accès logique ou physique depuis le système principal, le serveur, ou le lieu d’hébergement vers un système secondaire.
Bien que d’autres processus, tels que l’équilibrage de charge, puissent distribuer la connectivité partielle entre les instances ou composants systèmes, ils ne constituent pas un failover car ils ne représentent pas une coupure complète.
Qu’est-ce que le failback ?
Le failback est l’opération emblématique de récupération après sinistre. Elle implique une migration complète vers le statut de production d’origine — une récupération en quelque sorte — à la conclusion validée d’une catastrophe.
Le failback se produit lorsqu’un système revient à l’environnement primaire après que la cause d’une perturbation a été réglée. En pratique, cela ressemble à un failover, mais en sens inverse. Une fois que le système primaire est restauré, l’accès est dirigé vers ce système, et le système de secours est désactivé.
Cette reversion est une distinction test. Certaines organisations peuvent avoir des systèmes de secours complets pour des applications essentielles, ce qui permet un fonctionnement complet sur le système de secours. Dans ce cas, le système de secours peut être légitimement considéré comme le principal et l’ancien principal, désormais réparé, le nouveau système de secours.
Le rôle du failover et du failback dans la récupération après sinistre
Le failover est essentiel lors d’un événement de continuité des affaires car il permet de maintenir les opérations. En ayant un système vers lequel votre entreprise peut faire la transition lorsque le système principal est indisponible, vous êtes capable de continuer à faire des affaires. Les employés peuvent travailler, les flux de revenus sont préservés, et les clients peuvent être servis.
Sans le failover, ces fonctions pourraient s’arrêter, entraînant de **significatives perturbations**. De nombreuses organisations dépendent de la technologie pour des processus tests, et lorsque ces processus ne sont pas disponibles, les alternatives analogiques peuvent être insuffisantes ou complètement obsolètes. Le failover garantit que même en cas de catastrophe, l’entreprise continue d’avancer.
Le failback entre en jeu une fois que le besoin de failover prend fin. Lorsque la catastrophe est résolue, le failback permet à l’organisation de reprendre ses opérations normales. En général, le failback est nécessaire lorsque le système de secours ne peut pas soutenir les opérations aussi efficacement que le système principal. Par exemple, un système de secours peut ne pas être une réplique complète du système principal et n’être conçu que pour un usage temporaire pendant une urgence.
Pour les systèmes tests, certaines organisations peuvent créer un système de secours qui est une réplique complète du principal. Bien que coûteuse, cette approche atténue les risques de diminution de fonctionnalité pendant les catastrophes.
Les avantages d’exploiter à la fois le failover et le failback
Dans un monde idéal, chaque entreprise maintiendrait deux environnements pleinement opérationnels : un environnement principal et un environnement de secours identique. Cette configuration permettrait des transitions sans faille durant les catastrophes, garantissant que les opérations commerciales ne soient pas touchées.
Cependant, ce modèle peut en fait doubler un budget informatique : deux ensembles de points de terminaison, deux ensembles de serveurs, deux ensembles d’environnements cloud, deux ensembles de données, du personnel pour soutenir cela tant en informatique qu’en opérations commerciales, etc. C’est coûteux et inefficace pour toute entreprise, au point que aucune entreprise ne maintient vraiment ce modèle de support.
Au lieu de cela, la plupart des organisations optent pour un modèle de failover et de failback car il équilibre coûts et efficacité. Avec cette approche, l’environnement de secours est conçu pour soutenir les opérations tests lors d’une catastrophe, même s’il n’est pas aussi robuste que le système principal. Cela le rend plus économique, moins de travail est dupliqué, et le risque de perte de données ou d’impact est réduit.
Il est crucial de maintenir un environnement secondaire bien conçu. Réduire les coûts trop profondément sur un système de secours peut entraîner des inefficacités ou des pertes financières en cas de perturbation des opérations tests. Trouver le bon équilibre entre coût et fonctionnalité est essentiel.
Si des opérations commerciales ininterrompues sont essentielles, alors un plan stratégique de failover et de failback n’est pas optionnel — c’est une nécessité.