Parce que sa mise en oeuvre semble facile, la réplication synchrone intégrale est généralement retenue pour la haute disponibilité avec le stockage externe. En effet, nous recherchons tous une solution de réplication de sous-système disque où les données ne sont jamais en retard et jamais désynchronisées. Dans une solution bien
Réplication synchrone : reprise complète du système après sinistre
conçue avec journalisation de la base de données pour la reprise, pas question de rater un seul enregistrement qui a été écrit sur disque.
Pourtant, beaucoup de sites qui ont essayé d’instaurer la réplication synchrone intégrale, constatent qu’elle ne fournit pas la disponibilité attendue, voire qu’elle alourdit le travail du système. Ils voient des sessions batch allongées de 100 % ou plus, et une interactivité qui se traîne. A tel point que les services lab IBM Systems and Technology Group (STG) conseillent aux sites qui envisagent une solution de réplication intégrale d’effectuer un benchmark avant d’acheter le matériel. En effet, ils risquent fort d’être déçus par la solution après l’achat.
La seconde raison pour laquelle les utilisateurs jugent insuffisante la réplication synchrone intégrale est que la reprise sur le système cible est plus ardue que prévu. Dans un environnement de démonstration théorique et contrôlé, il est facile de montrer un IPL système après un basculement. Mais lors d’une défaillance réelle, avec des centaines ou des milliers de fichiers ouverts et des fonctions OS actives, la reprise peut prendre plusieurs heures. De plus, le système d’exploitation peut être partiellement abîmé (par exemple les ID utilisateurs système) et exiger une installation « slip » de SLIC ou i5/OS. Le système d’exploitation souffre souvent dans un environnement de stockage parce que chaque failover déplace le disque sur un autre système, lequel n’a pas le stockage principal du système primaire pour appliquer au moment de l’IPL, ce qui équivaut à une perte d’alimentation du système. Sans une reprise du stockage principal, tout le contenu de la mémoire est perdu, avec beaucoup plus de dégâts qu’une simple coupure de courant du système, causée par une défaillance logicielle ou matérielle.
Compte tenu du temps nécessaire pour la reprise et le risque de beaucoup d’interventions manuelles, cette solution ne saurait être classée dans la catégorie HA (high availability). Tout au plus appartient-elle à la catégorie DR (disaster-recovery), c’est-à-dire reprise après sinistre.
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
