2 La réplication des données est l’une des décisions d’infrastructure les plus lourdes de conséquences pour votre organisation. Bien conçue, elle vous permet de survivre à la panne d’un data center entier et de maintenir le service pendant les opérations de maintenance. Mal conçue, elle vous fait découvrir des modes de défaillance catastrophiques en plein incident de production. Ce guide présente les stratégies de réplication des données, des modèles synchrone et asynchrone aux architectures actif-actif et actif-passif, avec leurs implications sur vos objectifs de temps et de point de restauration, et des recommandations pour les charges de travail où l’échec n’est pas permis. Le compromis fondamental : cohérence ou disponibilité La réplication des données répond à un problème fondamental : comment garantir que les données survivent aux pannes ? La réponse, conserver plusieurs copies sur des systèmes physiques distincts, crée un nouveau problème : maintenir ces copies cohérentes. Cette tension définit toutes les stratégies de réplication. La réplication synchrone attend que toutes les répliques aient confirmé l’écriture avant de valider l’opération. Elle garantit une cohérence forte, mais ajoute de la latence d’écriture. Si une réplique est lente ou indisponible, c’est tout le système qui ralentit ou échoue. La réplication asynchrone valide les écritures immédiatement et propage les modifications en arrière-plan. Elle offre des écritures rapides et une bonne tolérance aux pannes, mais crée une vulnérabilité : si le système principal tombe avant la propagation des modifications, ces écritures sont perdues, et pendant la propagation, les répliques contiennent des données périmées. Votre stratégie doit refléter les exigences métier, et non des préférences théoriques. Un système financier peut exiger une réplication synchrone : le coût en latence est acceptable, car perdre des transactions serait catastrophique. Un réseau de diffusion de contenu peut préférer la réplication asynchrone : les utilisateurs acceptent un délai de propagation, mais le système doit absorber des millions de requêtes simultanées. La réplication synchrone : quand la cohérence ne se négocie pas Avec la réplication synchrone, une écriture n’est terminée que lorsque toutes les répliques (ou un quorum d’entre elles) l’ont confirmée. La cohérence est garantie, mais au prix de coûts opérationnels. Votre infrastructure attend la réplique la plus lente du groupe. Répliquer entre régions géographiques signifie que tout le système est bridé par la liaison la plus lente. De nombreuses organisations combinent donc une réplication synchrone au sein d’un même data center (faible latence, bande passante élevée) et une réplication asynchrone vers des sites distants (latence plus élevée, bande passante limitée). La vraie force de la réplication synchrone est sa capacité à absorber les défaillances en cascade. Si votre data center principal tombe entièrement, le site secondaire dispose déjà de chaque écriture validée. Vous pouvez basculer immédiatement sans aucune perte de données, ce qui est indispensable lorsque la perte de données est inacceptable. La réplication synchrone exige toutefois une gestion soignée des pannes. Que se passe-t-il si une réplique devient indisponible ? Le système doit choisir : attendre indéfiniment (au détriment de la disponibilité), retirer la réplique défaillante (au détriment temporaire de la durabilité) ou dégrader temporairement la réplication (en réduisant la redondance). La plupart des systèmes de production utilisent une réplication synchrone à quorum, où une majorité de répliques doit confirmer les écritures, ce qui permet à une réplique de tomber sans bloquer les écritures. La réplication asynchrone : optimiser les performances et la tolérance aux pannes La réplication asynchrone valide les écritures immédiatement et les propage en arrière-plan. La latence d’écriture est découplée de la latence de réplication, ce qui accélère les écritures. Elle soulève en revanche la question du RPO (objectif de point de restauration). Si votre système principal tombe, toutes les écritures non encore propagées sont perdues. Le délai entre la fin d’une écriture et sa réplication détermine le RPO : avec une réplication toutes les 10 secondes, vous perdez au plus 10 secondes ; avec une réplication toutes les heures, jusqu’à une heure. La plupart des systèmes de production utilisent une réplication asynchrone à fréquence définie. Vous pouvez par exemple répliquer toutes les 5 minutes, ce qui garantit qu’une panne du système principal ne fera pas perdre plus de 5 minutes de données. Ce RPO convient à de nombreuses charges et offre un compromis clair entre fréquence de réplication (qui consomme de la bande passante) et risque de perte de données. La réplication asynchrone gère bien les défaillances de répliques. Une réplique lente ou hors ligne n’affecte pas la latence d’écriture : le système principal continue, et la réplique rattrape son retard lorsqu’elle revient. Cette résilience rend la réplication asynchrone populaire pour les déploiements sur plusieurs data centers aux conditions imprévisibles. Elle introduit toutefois une complexité : la gestion du rattrapage après une panne du système principal. Si celui-ci tombe alors que la réplication accuse du retard et que vous basculez vers une réplique, celle-ci devient le nouveau système principal avec des données périmées. Lorsque le système d’origine revient, il faut le réconcilier avec la réplique qui a pris le relais. Certains systèmes utilisent des types de données répliqués sans conflit (CRDT) ou la règle de la dernière écriture ; d’autres exigent une intervention manuelle, ce qui complique la restauration. Les architectures actif-passif et actif-actif Au-delà du choix entre synchrone et asynchrone, il faut choisir un modèle d’architecture : actif-passif ou actif-actif. Dans une architecture actif-passif, une réplique (le système principal) reçoit toutes les écritures. Les répliques secondaires sont en lecture seule. Les applications lisent sur le système principal ; s’il tombe, vous basculez vers un système secondaire. L’architecture actif-passif est simple : toutes les écritures vont au même endroit, sans la complexité du consensus distribué. Mais la bascule n’est pas automatique : il faut détecter la panne, choisir le système secondaire à promouvoir et reconfigurer les applications, ce qui prend généralement plusieurs minutes. Pendant ce temps, votre système est indisponible. Bien connaître vos objectifs de RTO et de RPO (en anglais) est indispensable pour concevoir des procédures de bascule adaptées à vos exigences métier. Dans une architecture actif-actif, plusieurs répliques acceptent simultanément des écritures. Les applications répartissent les écritures entre plusieurs systèmes principaux, et n’importe quelle réplique peut servir les lectures. Si l’un des systèmes principaux tombe, les autres continuent sans procédure de bascule. L’architecture actif-actif est plus complexe, mais offre une meilleure disponibilité : sans point de défaillance unique, pas de délai de bascule. Elle soulève en revanche des difficultés de cohérence. Si deux systèmes principaux acceptent simultanément des écritures contradictoires, comment les réconcilier ? La littérature sur les systèmes distribués propose des solutions (horloges vectorielles, transformation opérationnelle, cohérence causale), mais chacune a un coût opérationnel et une complexité propres. La plupart des systèmes actif-actif reposent sur une cohérence à terme : les répliques peuvent diverger temporairement, mais convergent avec le temps. Les applications doivent tolérer la lecture de données légèrement périmées, ou accepter qu’une écriture soit annulée si un conflit est résolu en faveur d’une autre réplique. Réplication géographique et déploiements multirégions De nombreuses entreprises répliquent leurs données entre régions géographiques pour la reprise après sinistre ou pour rapprocher les données des utilisateurs. La réplication géographique pose des problèmes de latence. La vitesse de la lumière limite la vitesse de réplication entre continents : une écriture sur la côte est des États-Unis ne peut pas être répliquée en Asie-Pacifique en moins de 130 ms, rien que pour la propagation sur le réseau. C’est pourquoi la réplication géographique synchrone est rarement réaliste : chaque écriture subirait une latence intercontinentale. La réplication géographique s’appuie donc sur une propagation asynchrone, avec des objectifs de RPO et de RTO bien définis. Vous pouvez répliquer toutes les 5 minutes et tolérer jusqu’à 5 minutes de perte de données, avec une procédure manuelle de bascule de 30 minutes pour désigner une région distante comme principale. C’est acceptable pour la reprise après sinistre, mais pas pour la haute disponibilité au sein d’une même région. Certaines organisations adoptent une réplication hiérarchique : synchrone au sein d’un data center (contre la panne d’un nœud), asynchrone entre data centers d’une même région (contre la panne d’un data center) et asynchrone plus espacée entre régions (contre les sinistres régionaux). Elles disposent ainsi de plusieurs couches de protection, chacune avec un RPO et un RTO adaptés. RPO et RTO : fonder les décisions de réplication sur les données Votre stratégie de réplication doit reposer sur des exigences métier réelles. L’objectif de point de restauration (RPO) est la perte de données maximale tolérable en cas de panne, mesurée en temps. Avec un RPO d’une heure, la réplication doit garantir qu’aucune panne ne fera perdre plus d’une heure de données. Cela peut impliquer une réplication synchrone au sein d’un data center (RPO nul) et une réplication asynchrone toutes les 60 minutes vers un site de secours. L’objectif de temps de restauration (RTO) est la durée maximale tolérable sans accès aux données. Avec un RTO de 15 minutes, les mécanismes de bascule doivent rétablir le service en 15 minutes, ce qui peut exiger une bascule automatisée et une capacité de secours immédiatement disponible. Chaque charge de travail a ses propres exigences. Un système de paiement orienté client peut exiger un RPO de quelques secondes et un RTO de quelques minutes, alors qu’un système d’analytique interne peut tolérer un RPO de plusieurs heures et un RTO de plusieurs jours. Les exigences réglementaires imposent souvent des objectifs précis. Votre équipe d’infrastructure doit documenter le RPO et le RTO de chaque grand système de données, puis vérifier que l’architecture les atteint. De nombreuses organisations découvrent lors des tests de reprise après sinistre que les RPO et RTO théoriques ne correspondent pas à la réalité : la détection est plus lente, la bascule plus longue, ou la restauration comporte des étapes manuelles non documentées. Modèles de cohérence et implications pour les applications Chaque modèle de réplication offre des garanties de cohérence différentes. La cohérence forte : toutes les répliques contiennent des données identiques, et les lectures voient toujours les écritures les plus récentes. Elle s’obtient avec une réplication synchrone, au prix de la latence. Elle simplifie la logique applicative, mais n’est pas toujours nécessaire. La cohérence à terme : les répliques divergent temporairement, mais convergent avec le temps. Les applications peuvent voir temporairement des données périmées. Elle offre une meilleure disponibilité et tolérance aux pannes, mais exige des applications qu’elles tolèrent des incohérences passagères. La cohérence causale : les opérations respectent l’ordre causal. Si l’écriture B dépend de l’écriture A, toutes les répliques voient A avant B. Plus cohérente que la cohérence à terme et moins coûteuse que la cohérence forte, elle convient bien à de nombreuses applications. La cohérence de session : au sein d’une session utilisateur, les applications voient des données cohérentes, tandis que des sessions différentes peuvent voir des versions différentes. C’est un compromis entre cohérence et disponibilité. Votre stratégie doit définir explicitement le modèle de cohérence fourni. Des applications conçues pour une cohérence forte mais exécutées sur une réplication à cohérence à terme révèlent des bogues subtils en cas de panne. À l’inverse, des applications conçues pour la cohérence à terme tolèrent la divergence des répliques, ce qui réduit la charge de réplication. Architecturer la réplication en entreprise Pour votre organisation, répondez à plusieurs questions : quelles sont vos exigences réelles de RPO et de RTO pour chaque système de données ? De quel périmètre géographique avez-vous besoin (un data center, plusieurs data centers, plusieurs régions) ? Quelle latence de réplication pouvez-vous tolérer ? Que se passe-t-il lorsque la réplication prend du retard ? Comment vérifiez-vous que la réplication fonctionne réellement ? La plupart des grandes entreprises adoptent une approche par couches : réplication à cohérence forte au sein d’un data center (en tolérant une latence modérée pour les systèmes critiques), cohérence plus faible entre data centers (en acceptant une divergence pour une meilleure tolérance aux pannes) et réplication asynchrone entre régions (optimisée pour la reprise après sinistre). Mettre en œuvre une architecture de réplication multisite (en anglais) exige une planification et des tests rigoureux. Cela suppose une coordination entre les équipes d’infrastructure, d’applications et d’exploitation. Les applications doivent connaître leurs exigences de cohérence, l’infrastructure doit fournir la réplication correspondante et l’exploitation doit comprendre les modes de défaillance et disposer de procédures de restauration testées. Protéger les répliques grâce à des stratégies de sauvegarde résistantes aux ransomwares (en anglais) garantit par ailleurs que les systèmes compromis pourront être restaurés, et maintenir une haute disponibilité (en anglais) protège contre les défaillances en cascade. En fondant votre stratégie de réplication sur les exigences métier et en la testant rigoureusement, vous transformez la réplication des données, d’une infrastructure théorique, en un véritable mécanisme de résilience qui protège réellement votre organisation. Pour aller plus loin RTO ou RPO : les principales différences (en anglais) La haute disponibilité (HA) (en anglais) Le plan de continuité d’activité (en anglais) Survivre à une panne de data center : planifier la résilience (en anglais) DRaaS : la reprise après sinistre en tant que service (en anglais) Stratégie de sauvegarde d’entreprise (en anglais) Durabilité ou disponibilité des données (en anglais)
