Mike Uzan, Évangéliste du stockage chez Kaminario
Quelques exemples ci-dessous pour illustrer :
Exemple #1 : Un problème général d'alimentation au sein d'un datacenter rend les données indisponibles. Les données sont là mais vous êtes dans l'incapacité d'y accéder. Il s'agit d'un désastre "physique" provoquant une indisponibilité des données.
Exemple #2 : Un effacement accidentel de fichiers ou transactions (erreur humaine). Il s'agit là d'un désastre "logique" provoquant une perte de données.
Exemple #3 : Un bug dans le logiciel de clustering provoquant un arrêt du service. Il s'agit d'un désastre "logique" avec à la clé une indisponibilité des données.
Préparer la reprise d'un désastre "logique" ne nécessite ni un deuxième datacenter ni du matériel en double pour redémarrer l'activité. Un désastre "physique" en revanche nécessite la mise en place d'un deuxième datacenter (standby) avec le matériel nécessaire pour redémarrer l'activité de l'autre côté, à minima, pour ne pas rester si vous ne pouvez pas
rester OFFLINE plus de quelques heures voire quelques jours.
Mythe #1: Zero dataloss – Zero downtime
Concernant le RTO (Recovery Time Objective), il y a eu beaucoup de progrès ces dernières années (cluster étendu actif/actif) qui ont rendu possible la survie à un désastre "physique" sans même avoir à redémarrer/restaurer la moindre base de données. Mais cela requiert des logiciels/licences couteuses, du matériel supplémentaire (la plupart du temps propriétaire/appliance), des connections "faible latence" sur de longues distances et malheureusement aujourd'hui ces solutions ne couvrent pas la couche "Middleware" (serveur d'application) ce qui engendre de toute façon une indisponibilité. Mais si le business peut supporter quelques minutes d'arrêt (downtime) alors les solutions de clustering active/passive sont beaucoup plus intéressantes économiquement. Cependant cela nécessite d’avoir une conversation avec les interlocuteurs « business/appli » de l’entreprise en mode "Conseil" pour mesurer ce que représente réellement un arrêt business de quelques minutes.
Concernant le RPO (Recovery Point Objective), le consensus a toujours été d'assumer qu'un miroir synchrone (ou réplication) couvrait totalement l’entreprise face au RPO=zéro. Depuis 1995, EMC a été leader en la matière avec SRDF/S. Au niveau du stockage cela garanti "zero- data-loss" (zero perte de donnée) car les I/O en écriture sur la baie primaire (source) ne sont acquittés qu'après envoi et confirmation de réception sur la baie secondaire (target). Tant que le lien inter-site est fonctionnel, les baies source et destination sont 100% équivalentes (RPO=zéro) c'est à dire que toutes les transactions écrites sur la baie primaires sont garanties d'être présentes sur la baie secondaire également. Si un sinistre survenait (désastre physique), alors la base de données passerait en abort (crash) et pourrait redémarrer depuis la destination depuis le miroir synchrone. Pour les autres types de données (hors SGDB) les systèmes de fichiers devraient être remontés sur la cible - mais toutes les données seront présentées exactement dans le même état qu'au moment du crash ("commité" sur disque).
Comment la « loi de Murphy » par exemple est capable de bouleverser ce monde idéal ?
Mythe #2 : Réplication synchrone + FS journalisé = RPO zéro
Par le passé, il était nécessaire de scanner le FS (système de fichier) après un crash pour en vérifier l'intégrité. Pour contourner ces attentes interminables, les systèmes de fichier "modernes" ont implémentés la journalisation qui est assez proche au niveau conceptuel de la fonctionnalité de logging existant sur les SGBD. Ces mécanismes s'assurent que si les métadata du FS changent alors elles sont écrites dans le journal de sorte que si le FS doit être réparé après un crash il ne soit pas nécessaire de tout rescanner. A la place, tous les changements du journal sont "rejoués" et en quelques secondes tout repart. Au final, un FS journalisé prévient des pertes de données (zero-data-loss) cependant la réalité est différente. Exemple à l’appui d’un serveur de fichiers utilisé pour partager des documents de type Word/Excel. L'utilisateur ouvre une présentation PowerPoint de 10MB qu’il a modifié. Une fois terminée, il clique sur "Enregistrer" pour "commiter" les changements vers le serveur de fichiers qui à son tour va "commiter" vers le FS. L'application PowerPoint va commencer à écraser le document original dans son intégralité, mais au même moment (disons à 50%, soit 5MB) intervient un incident majeur et une bascule du serveur de fichier est opérée. Le serveur de fichier secondaire va tenter de remonter le FS répliqué en synchrone, rejouer le journal puis monter le FS qui sera consistant. Mais voilà, le journal va trouver un fichier de 5MB (en cours de sauvegarde). Lorsque l’utilisateur va essayer de l’ouvrir, il ne parviendra pas à charger le fichier. Certains FS ont des mécanismes pour pallier à cela avec par exemple des options de "data-in-log". Cela signifie qu'au-delà des métadonnées (nom, taille date des fichiers...) le journal héberge également les données du fichier. En conclusion, seuls quelques FS modernes sont capables de contourner ce problème car ils écrivent via le journal (ex. SUN/Oracle ZFS...), il demeure toujours un risque d'un fichier écrit à moitié.
Mythe #3 : Répliquer de façon synchrone me protège contre les incohérences
Maintenant imaginons qu'une inconsistance soit causée par l'application elle-même ou par l'architecture (corruption). Bien que toute la chaîne soit conçue pour palier à tout sinistre, personne n’est à l'abri d'un bug provoquant au sein même du système de réplication une inconsistance. Il en va de même pour les serveurs et logiciels. Alors que la réplication se fasse en local ou à distance, la « corruption » se propagera quand même sur les réplicas. Il est possible de conclure que le zero-data-loss est un mythe sauf si d'un point de vue applicatif l'intégrité est gérée de bout en bout, ce qui est rarement le cas.
Mythe #4 : Nous sommes prêts car nous avons envisagé tous les scénarios
A la lecture des présentations marketing des solutions de disaster recovery les scénarii exposés sont souvent "globaux". Les exemples classiques sont le crash d'un avion sur un datacenter, l'explosion de gaz ou l'arrêt électrique. Dans tous ces scénarii l'arrêt est brutal et global. Dans la vrai vie, les sinistres sont bien moins francs, déclenché par des événements en cascade, mineurs au départ et se propageant au fur et à mesure jusqu'à l'arrêt total. Prenons pour exemple un feu dans un datacenter; au début mineur et considéré comme résorbable puis au fur et à mesure provoquant l'arrêt du WAN, d'une part des applications puis du reste de l'infrastructure. Il est tout à fait probable que les applications continues d'écrire leurs données sur des systèmes de stockage qui ne sont plus répliquées, et donc seront perdues après bascule sur le site de repli.
Le résultat est un site arrêté (et en feu) avec des données plus récentes que sur le site secondaire (où le processus est censé redémarrer). On bascule alors avec des pertes de données et donc un RPO différent de 0, assumant donc une perte de business. Dans le cas on l’on parvient à éteindre le feu et réparer les serveurs (en assumant que le stockage est toujours là) comment faire machine arrière ?. Avec des données écrites indépendamment sur les 2 sites, dans la plupart des cas, les systèmes de réplication seront dans l'impossibilité de réconcilier cela; entraînant certainement une corruption des données "dormante" lors du retour au nominal. Il faut aussi garder à l'esprit lors du design d'une solution de D/R que le scénario d'une catastrophe évoluant heure après heure (dormante) cela entraîne un état dans lequel l’administrateur doit faire un choix ManuelL entre "gauche ou droite" pour reprendre l'activité.
Mythe #5 : L'asynchrone ne convient pas dans la plupart des cas
Donc pourquoi continuer à déployer de la réplication synchrone, alors même que les écritures synchrones engendrent une dégradation très importante de la latence ? C'est une question d'héritage durant ces 20 dernières années !
EMC a été le premier et très longtemps le leader en termes de réplication synchrone (depuis 2001), et donc cette réplication synchrone s'est imposée d'elle-même année après année comme la solution de-facto de Disaster/Recovery.
A l'opposé de la réplication synchrone, l'Asynchrone ne nécessite pas d'attendre l'acquittement (ACK) de la cible (baie distante) pour rendre l'acquittement (ACK) local (serveur), donc en théorie la réplication asynchrone n'engendre aucune pénalité sur les latences. Le problème était plutôt la conservation de l'ordre des écritures pour garantir une consistance des données répliquées. (ex. consistance entre un volume de log Oracle et un volume de data Oracle). En résumé, si l'ordre des écritures n'est pas préservé, le site de D/R n’est d'aucune utilité car il ne sera pas possible de redémarrer les applications. Pour contourner cela les constructeurs/éditeurs ont implémenté différentes solutions comme la préservation de l'ordre des écritures en fonction de leur arrivée ou encore en "taggant" chaque IO en écriture avec un sequenceID causant un overhead massif sur les liens de réplication. Ces 2 méthodes se sont révélées impossible à déployer dans les environnements où la latence était clé. Certains systèmes de réplication asynchrone ne disposent pas d'une telle implémentation de la consistance et ne permettent donc pas de préserver l'ordre des écritures rendant votre stratégie D/R inutilisable. C'est sans doute pour cette raison qu'il y a un mythe concernant l'insuffisance de réplication asynchrone.
Aujourd'hui la plupart des baies All-Flash dispose de réplication Asynchrone avec gestion de la consistance
Le RPO (perte tolérée) atteignable par réplication asynchrone correspond à l'écart entre la consistance source et destination. Dans le cas de SRDF/A cela correspond à 60 secondes minimum (2 cycles de 30s) et dans le cas d'un système de shipping des snapshots il est possible d'atteindre 60 secondes. En d'autres termes après failover, il faut compter perdre 60 secondes de transactions avec 100% des données valides et consistantes. Le RTO (temps de remise en service) ne change pas qu'on soit en synchrone ou asynchrone. L'asynchrone est donc suffisant pour la plupart des applications métiers
Mythe #6 : Le métier sait ce dont il a besoin
Donc si la réplication asynchrone garantit la consistance, et n'augmente le RPO que de zéro à quelques minutes, et réduit l'impact sur les performances à zéro, pourquoi la plupart des clients continuent de déployer 100% de réplication synchrone ?
Selon Mike Uzan, pour 95% des SLA, la réplication asynchrone est suffisante. A l'exception de ces environnements dont 1 seconde de transaction représente une valeur métier telle, qu'on ne puisse pas faire autrement. C'est le cas dans les environnements financiers hautement transactionnel ou 1 simple transaction peut représenter plusieurs millions d'euros sans oublier les applications où une simple transaction a également beaucoup de valeur business (ex. jeux de pari en ligne et autres...). Maintenant si le coût de la réplication synchrone (impact sur les performances, liens de réplication très cher, tuning spécifique côté applicatif, matériel et logiciels coûteux...) est plus important que la valeur de ces quelques minutes de transactions perdues, alors il est plutôt recommandé de choisir plutôt une réplication asynchrone (qui convient à plus de 95% des besoins). La clé pour arbitrer revient à comprendre la finalité et donner au business ce dont il a besoin.
Mythe #7 : Il est très peu probable que nous perdions le Datacenter tout entier
Qui aurait imaginé l'annulation de 1150 vols de la compagnie SouthWest Airlines, l'accident nucléaire de Fukushima suite à une catastrophe naturelle, les 300 vols et milliers de passagers de la compagnie Delta scotchés au sol à cause d'un problème électrique sur un DC à Atlanta.
En résumé, comme les problèmes liés aux déclenchements intempestifs des alertes incendies, qui lorsqu'ils sont défectueux, génèrent des ondes de choc (Chorus le 19 juin 2013, ING en Septembre 2016...) et étant donné que le pire est vite arrivé, mieux vaut se prémunir en ayant réfléchi en amont à ces choix stratégiques et aux enjeux qui en découlent.
Exemple #1 : Un problème général d'alimentation au sein d'un datacenter rend les données indisponibles. Les données sont là mais vous êtes dans l'incapacité d'y accéder. Il s'agit d'un désastre "physique" provoquant une indisponibilité des données.
Exemple #2 : Un effacement accidentel de fichiers ou transactions (erreur humaine). Il s'agit là d'un désastre "logique" provoquant une perte de données.
Exemple #3 : Un bug dans le logiciel de clustering provoquant un arrêt du service. Il s'agit d'un désastre "logique" avec à la clé une indisponibilité des données.
Préparer la reprise d'un désastre "logique" ne nécessite ni un deuxième datacenter ni du matériel en double pour redémarrer l'activité. Un désastre "physique" en revanche nécessite la mise en place d'un deuxième datacenter (standby) avec le matériel nécessaire pour redémarrer l'activité de l'autre côté, à minima, pour ne pas rester si vous ne pouvez pas
rester OFFLINE plus de quelques heures voire quelques jours.
Mythe #1: Zero dataloss – Zero downtime
Concernant le RTO (Recovery Time Objective), il y a eu beaucoup de progrès ces dernières années (cluster étendu actif/actif) qui ont rendu possible la survie à un désastre "physique" sans même avoir à redémarrer/restaurer la moindre base de données. Mais cela requiert des logiciels/licences couteuses, du matériel supplémentaire (la plupart du temps propriétaire/appliance), des connections "faible latence" sur de longues distances et malheureusement aujourd'hui ces solutions ne couvrent pas la couche "Middleware" (serveur d'application) ce qui engendre de toute façon une indisponibilité. Mais si le business peut supporter quelques minutes d'arrêt (downtime) alors les solutions de clustering active/passive sont beaucoup plus intéressantes économiquement. Cependant cela nécessite d’avoir une conversation avec les interlocuteurs « business/appli » de l’entreprise en mode "Conseil" pour mesurer ce que représente réellement un arrêt business de quelques minutes.
Concernant le RPO (Recovery Point Objective), le consensus a toujours été d'assumer qu'un miroir synchrone (ou réplication) couvrait totalement l’entreprise face au RPO=zéro. Depuis 1995, EMC a été leader en la matière avec SRDF/S. Au niveau du stockage cela garanti "zero- data-loss" (zero perte de donnée) car les I/O en écriture sur la baie primaire (source) ne sont acquittés qu'après envoi et confirmation de réception sur la baie secondaire (target). Tant que le lien inter-site est fonctionnel, les baies source et destination sont 100% équivalentes (RPO=zéro) c'est à dire que toutes les transactions écrites sur la baie primaires sont garanties d'être présentes sur la baie secondaire également. Si un sinistre survenait (désastre physique), alors la base de données passerait en abort (crash) et pourrait redémarrer depuis la destination depuis le miroir synchrone. Pour les autres types de données (hors SGDB) les systèmes de fichiers devraient être remontés sur la cible - mais toutes les données seront présentées exactement dans le même état qu'au moment du crash ("commité" sur disque).
Comment la « loi de Murphy » par exemple est capable de bouleverser ce monde idéal ?
Mythe #2 : Réplication synchrone + FS journalisé = RPO zéro
Par le passé, il était nécessaire de scanner le FS (système de fichier) après un crash pour en vérifier l'intégrité. Pour contourner ces attentes interminables, les systèmes de fichier "modernes" ont implémentés la journalisation qui est assez proche au niveau conceptuel de la fonctionnalité de logging existant sur les SGBD. Ces mécanismes s'assurent que si les métadata du FS changent alors elles sont écrites dans le journal de sorte que si le FS doit être réparé après un crash il ne soit pas nécessaire de tout rescanner. A la place, tous les changements du journal sont "rejoués" et en quelques secondes tout repart. Au final, un FS journalisé prévient des pertes de données (zero-data-loss) cependant la réalité est différente. Exemple à l’appui d’un serveur de fichiers utilisé pour partager des documents de type Word/Excel. L'utilisateur ouvre une présentation PowerPoint de 10MB qu’il a modifié. Une fois terminée, il clique sur "Enregistrer" pour "commiter" les changements vers le serveur de fichiers qui à son tour va "commiter" vers le FS. L'application PowerPoint va commencer à écraser le document original dans son intégralité, mais au même moment (disons à 50%, soit 5MB) intervient un incident majeur et une bascule du serveur de fichier est opérée. Le serveur de fichier secondaire va tenter de remonter le FS répliqué en synchrone, rejouer le journal puis monter le FS qui sera consistant. Mais voilà, le journal va trouver un fichier de 5MB (en cours de sauvegarde). Lorsque l’utilisateur va essayer de l’ouvrir, il ne parviendra pas à charger le fichier. Certains FS ont des mécanismes pour pallier à cela avec par exemple des options de "data-in-log". Cela signifie qu'au-delà des métadonnées (nom, taille date des fichiers...) le journal héberge également les données du fichier. En conclusion, seuls quelques FS modernes sont capables de contourner ce problème car ils écrivent via le journal (ex. SUN/Oracle ZFS...), il demeure toujours un risque d'un fichier écrit à moitié.
Mythe #3 : Répliquer de façon synchrone me protège contre les incohérences
Maintenant imaginons qu'une inconsistance soit causée par l'application elle-même ou par l'architecture (corruption). Bien que toute la chaîne soit conçue pour palier à tout sinistre, personne n’est à l'abri d'un bug provoquant au sein même du système de réplication une inconsistance. Il en va de même pour les serveurs et logiciels. Alors que la réplication se fasse en local ou à distance, la « corruption » se propagera quand même sur les réplicas. Il est possible de conclure que le zero-data-loss est un mythe sauf si d'un point de vue applicatif l'intégrité est gérée de bout en bout, ce qui est rarement le cas.
Mythe #4 : Nous sommes prêts car nous avons envisagé tous les scénarios
A la lecture des présentations marketing des solutions de disaster recovery les scénarii exposés sont souvent "globaux". Les exemples classiques sont le crash d'un avion sur un datacenter, l'explosion de gaz ou l'arrêt électrique. Dans tous ces scénarii l'arrêt est brutal et global. Dans la vrai vie, les sinistres sont bien moins francs, déclenché par des événements en cascade, mineurs au départ et se propageant au fur et à mesure jusqu'à l'arrêt total. Prenons pour exemple un feu dans un datacenter; au début mineur et considéré comme résorbable puis au fur et à mesure provoquant l'arrêt du WAN, d'une part des applications puis du reste de l'infrastructure. Il est tout à fait probable que les applications continues d'écrire leurs données sur des systèmes de stockage qui ne sont plus répliquées, et donc seront perdues après bascule sur le site de repli.
Le résultat est un site arrêté (et en feu) avec des données plus récentes que sur le site secondaire (où le processus est censé redémarrer). On bascule alors avec des pertes de données et donc un RPO différent de 0, assumant donc une perte de business. Dans le cas on l’on parvient à éteindre le feu et réparer les serveurs (en assumant que le stockage est toujours là) comment faire machine arrière ?. Avec des données écrites indépendamment sur les 2 sites, dans la plupart des cas, les systèmes de réplication seront dans l'impossibilité de réconcilier cela; entraînant certainement une corruption des données "dormante" lors du retour au nominal. Il faut aussi garder à l'esprit lors du design d'une solution de D/R que le scénario d'une catastrophe évoluant heure après heure (dormante) cela entraîne un état dans lequel l’administrateur doit faire un choix ManuelL entre "gauche ou droite" pour reprendre l'activité.
Mythe #5 : L'asynchrone ne convient pas dans la plupart des cas
Donc pourquoi continuer à déployer de la réplication synchrone, alors même que les écritures synchrones engendrent une dégradation très importante de la latence ? C'est une question d'héritage durant ces 20 dernières années !
EMC a été le premier et très longtemps le leader en termes de réplication synchrone (depuis 2001), et donc cette réplication synchrone s'est imposée d'elle-même année après année comme la solution de-facto de Disaster/Recovery.
A l'opposé de la réplication synchrone, l'Asynchrone ne nécessite pas d'attendre l'acquittement (ACK) de la cible (baie distante) pour rendre l'acquittement (ACK) local (serveur), donc en théorie la réplication asynchrone n'engendre aucune pénalité sur les latences. Le problème était plutôt la conservation de l'ordre des écritures pour garantir une consistance des données répliquées. (ex. consistance entre un volume de log Oracle et un volume de data Oracle). En résumé, si l'ordre des écritures n'est pas préservé, le site de D/R n’est d'aucune utilité car il ne sera pas possible de redémarrer les applications. Pour contourner cela les constructeurs/éditeurs ont implémenté différentes solutions comme la préservation de l'ordre des écritures en fonction de leur arrivée ou encore en "taggant" chaque IO en écriture avec un sequenceID causant un overhead massif sur les liens de réplication. Ces 2 méthodes se sont révélées impossible à déployer dans les environnements où la latence était clé. Certains systèmes de réplication asynchrone ne disposent pas d'une telle implémentation de la consistance et ne permettent donc pas de préserver l'ordre des écritures rendant votre stratégie D/R inutilisable. C'est sans doute pour cette raison qu'il y a un mythe concernant l'insuffisance de réplication asynchrone.
Aujourd'hui la plupart des baies All-Flash dispose de réplication Asynchrone avec gestion de la consistance
Le RPO (perte tolérée) atteignable par réplication asynchrone correspond à l'écart entre la consistance source et destination. Dans le cas de SRDF/A cela correspond à 60 secondes minimum (2 cycles de 30s) et dans le cas d'un système de shipping des snapshots il est possible d'atteindre 60 secondes. En d'autres termes après failover, il faut compter perdre 60 secondes de transactions avec 100% des données valides et consistantes. Le RTO (temps de remise en service) ne change pas qu'on soit en synchrone ou asynchrone. L'asynchrone est donc suffisant pour la plupart des applications métiers
Mythe #6 : Le métier sait ce dont il a besoin
Donc si la réplication asynchrone garantit la consistance, et n'augmente le RPO que de zéro à quelques minutes, et réduit l'impact sur les performances à zéro, pourquoi la plupart des clients continuent de déployer 100% de réplication synchrone ?
Selon Mike Uzan, pour 95% des SLA, la réplication asynchrone est suffisante. A l'exception de ces environnements dont 1 seconde de transaction représente une valeur métier telle, qu'on ne puisse pas faire autrement. C'est le cas dans les environnements financiers hautement transactionnel ou 1 simple transaction peut représenter plusieurs millions d'euros sans oublier les applications où une simple transaction a également beaucoup de valeur business (ex. jeux de pari en ligne et autres...). Maintenant si le coût de la réplication synchrone (impact sur les performances, liens de réplication très cher, tuning spécifique côté applicatif, matériel et logiciels coûteux...) est plus important que la valeur de ces quelques minutes de transactions perdues, alors il est plutôt recommandé de choisir plutôt une réplication asynchrone (qui convient à plus de 95% des besoins). La clé pour arbitrer revient à comprendre la finalité et donner au business ce dont il a besoin.
Mythe #7 : Il est très peu probable que nous perdions le Datacenter tout entier
Qui aurait imaginé l'annulation de 1150 vols de la compagnie SouthWest Airlines, l'accident nucléaire de Fukushima suite à une catastrophe naturelle, les 300 vols et milliers de passagers de la compagnie Delta scotchés au sol à cause d'un problème électrique sur un DC à Atlanta.
En résumé, comme les problèmes liés aux déclenchements intempestifs des alertes incendies, qui lorsqu'ils sont défectueux, génèrent des ondes de choc (Chorus le 19 juin 2013, ING en Septembre 2016...) et étant donné que le pire est vite arrivé, mieux vaut se prémunir en ayant réfléchi en amont à ces choix stratégiques et aux enjeux qui en découlent.