> Tech > Réplication synchrone : reprise complète du système après sinistre

Réplication synchrone : reprise complète du système après sinistre

Tech - Par iTPro - Publié le 24 juin 2010
email

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

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 gratuitement cette ressource

Guide Azure Virtual Desktop

Guide Azure Virtual Desktop

Comment optimiser les coûts, gagner en agilité, en sécurité et en conformité avec Azure Virtual Desktop ? Découvrez, dans ce Guide Infographique, les bénéfices clés pour les utilisateurs et les avantages de la mise en œuvre pour les équipes IT.

Tech - Par iTPro - Publié le 24 juin 2010