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
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Fraude par identité synthétique : comment l’IA peut redonner confiance aux entreprises et à leurs clients
- VirtualBrowser protège la navigation web à la source
- Innovation et performance : le rôle clé du consulting dans la transformation numérique
- Sekoia.io : l’alternative européenne qui s’impose dans la cybersécurité
Articles les + lus
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
À la une de la chaîne Tech
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
