2 Le stockage objet a profondément changé la manière dont les entreprises gèrent leur infrastructure de sauvegarde. Au lieu des hiérarchies SAN ou NAS traditionnelles, le stockage objet distribué répartit les données sur plusieurs serveurs et sites, offrant une résilience, une évolutivité et une économie que les architectures plus anciennes ne peuvent égaler. Pour les administrateurs de sauvegarde et les responsables de la protection des données, comprendre le stockage objet distribué n’est plus facultatif. C’est l’architecture qui sous-tend la plupart des cibles de sauvegarde modernes — des services cloud aux appliances sur site. La question n’est pas de savoir s’il faut utiliser le stockage objet distribué, mais comment le concevoir et l’exploiter efficacement. Explorer les cas d’usage du stockage objet (en anglais) permet de mieux saisir les avantages de cette approche pour les charges de sauvegarde et d’archivage. Cet article explique le fonctionnement du stockage objet distribué, pourquoi il est devenu la cible de sauvegarde privilégiée et ce qu’il faut comprendre sur le plan opérationnel pour réussir. En quoi le stockage objet distribué diffère fondamentalement du stockage traditionnel Les architectures de stockage traditionnelles (SAN, NAS) sont centralisées. Vous achetez une baie de stockage, la connectez à votre réseau et la gérez comme une unité unique. La capacité est limitée par la taille de la baie. Pour davantage de capacité, vous ajoutez des disques (dans certaines limites) ou achetez une autre baie et gérez les deux séparément. Le stockage objet distribué traite le stockage comme un ensemble de serveurs indépendants. Chaque serveur gère une partie de vos données. Lorsque vous écrivez des données, elles sont stockées sur plusieurs serveurs. Si un serveur tombe en panne, vos données restent accessibles sur les autres. Voici pourquoi c’est important : Évolutivité horizontale : vous ajoutez de la capacité en ajoutant des serveurs, et non en remplaçant des baies. Commencez avec trois serveurs de 10 To chacun et passez à cinquante serveurs de 100 To chacun. Le stockage traditionnel ne peut pas évoluer aussi facilement. Une résilience par la distribution : le stockage traditionnel assure sa résilience par la redondance (RAID, mise en miroir). Le stockage distribué l’assure en répartissant les données sur de nombreux nœuds. Si un nœud tombe en panne, de nombreux autres en détiennent des copies. C’est fondamentalement différent, et bien plus résilient à grande échelle. Efficacité économique : le stockage distribué utilise du matériel standard (serveurs et disques courants). Vous ne payez pas le prix fort d’appliances spécialisées. Cela le rend rentable pour des volumes de données massifs. Répartition géographique : le stockage objet distribué s’étend sur plusieurs data centers, régions ou continents. Les données sont répliquées géographiquement de manière automatique. Cela protège contre les sinistres régionaux qui paralyseraient un stockage traditionnel. Fédération d’espaces de noms : plusieurs clusters se fédèrent en un espace de noms logique unique. Du point de vue de l’utilisateur, cela ressemble à un seul système de stockage massif. En interne, les données sont réparties entre des clusters distincts. Ces caractéristiques font du stockage objet distribué la solution idéale pour la sauvegarde à l’échelle de l’entreprise. Comprendre la répartition des données : réplication ou erasure coding Le stockage objet distribué protège les données grâce à deux mécanismes : La réplication : l’approche la plus simple. Lorsque vous stockez un objet, des copies sont créées et réparties sur plusieurs nœuds. Avec une réplication à trois voies, trois copies de chaque objet existent. Si un nœud tombe en panne, les deux autres restent accessibles. La réplication est simple, mais elle exige un surcoût de stockage important (stocker trois copies signifie trois fois la capacité brute pour une seule copie des données). L’erasure coding : une approche plus sophistiquée. Les données sont découpées en fragments (par exemple 10) et encodées de sorte que 7 fragments sur 10 suffisent à les reconstituer. Les 3 fragments manquants sont perdus, mais les 7 restants suffisent. On obtient une protection contre les pannes de nœuds avec un surcoût inférieur à celui de la réplication : 10/7, soit 1,43 fois la capacité au lieu de 3 fois. L’erasure coding est plus complexe à mettre en œuvre et consomme un peu plus de CPU, mais il est bien plus efficace en termes de stockage. La plupart des systèmes modernes de stockage objet distribué prennent en charge les deux : la réplication pour les données chaudes (fréquemment consultées, qui bénéficient de copies multiples) et l’erasure coding pour les données d’archive (rarement consultées, qui bénéficient de l’efficacité du stockage). Pour les architectes de sauvegarde, comprendre ce compromis est essentiel. Utiliser une réplication à trois voies pour toutes les sauvegardes revient à tripler le coût de stockage effectif. Utiliser l’erasure coding (par exemple 10+4, où 10 fragments sur 14 suffisent) revient à 1,4 fois le coût. Ce choix a un impact direct sur le budget d’infrastructure. Fédération d’espaces de noms : gérer plusieurs clusters comme un seul L’un des défis du stockage objet distribué est la gestion des données sur plusieurs sites. Si vous disposez de clusters de sauvegarde dans trois data centers géographiquement éloignés, vous pouvez gérer chacun séparément (les utilisateurs doivent alors savoir quel cluster contient quelles données) ou les fédérer. La fédération d’espaces de noms rend cela transparent. Les utilisateurs voient un espace de noms de stockage objet unique et unifié. En interne, les écritures sont réparties automatiquement entre les clusters. Les lectures retrouvent les données où qu’elles soient stockées. Cette abstraction simplifie la gestion et permet un placement intelligent des données : les données fréquemment consultées sont mises en cache localement, les données rarement consultées sont stockées à distance. Pour les architectes de sauvegarde, la fédération d’espaces de noms est précieuse, car elle permet : L’optimisation de la localité des données (en anglais) : les tâches de sauvegarde de toute l’organisation envoient les données vers le cluster local. Les données sont ensuite automatiquement hiérarchisées ou répliquées vers d’autres clusters pour la diversité géographique. Les utilisateurs n’ont pas à comprendre cette complexité. La déduplication globale : un espace de noms fédéré détecte si des données existent déjà quelque part et évite de stocker des doublons. C’est particulièrement utile pour la déduplication des sauvegardes, où de nombreuses sauvegardes contiennent des données similaires. Un basculement géographique transparent : si un cluster devient indisponible, l’espace de noms fédéré redirige automatiquement le trafic vers un autre cluster. C’est transparent pour le logiciel de sauvegarde (en anglais). Déduplication et compression à la volée dans le stockage objet Le stockage objet distribué intègre souvent la déduplication (identifier les données en double et ne les stocker qu’une fois) et la compression (réduire la taille des données). La déduplication consiste à calculer une empreinte de chaque objet. Si deux objets ont la même empreinte, ils sont probablement identiques. Le système stocke les données une seule fois et conserve des métadonnées qui font pointer les deux références vers elles. Pour la sauvegarde, cela réduit considérablement la consommation de stockage. Si la sauvegarde de votre base de données est très similaire d’un jour à l’autre (avec seulement des changements incrémentaux), la déduplication élimine la redondance. La déduplication a des implications opérationnelles : Moment de la déduplication : certains systèmes dédupliquent immédiatement (à la volée). D’autres le font de manière asynchrone (après l’écriture des données). La déduplication à la volée consomme plus de CPU mais économise immédiatement du stockage et de la bande passante. La déduplication asynchrone consomme moins de CPU pendant les écritures, mais peut prendre des heures (pendant lesquelles vous utilisez plus de stockage que nécessaire). Périmètre de la déduplication : certains systèmes dédupliquent au sein d’un seul cluster. D’autres dédupliquent sur l’ensemble d’un espace de noms fédéré. La déduplication inter-clusters économise davantage de stockage, mais exige plus de coordination et elle est plus complexe à exploiter. Récupération de l’espace : lorsque des données sont supprimées, le système doit finir par supprimer les blocs de stockage sous-jacents si aucun autre objet n’y fait référence. Ce processus de récupération doit être efficace (une collecte trop fréquente consomme des ressources) sans être paresseux (une collecte trop tardive gaspille du stockage). C’est un détail opérationnel subtil qui influe sur l’efficacité d’utilisation de votre stockage. Pour les architectes de sauvegarde, comprendre la déduplication est essentiel, car elle détermine directement si votre infrastructure de sauvegarde est efficace ou gaspilleuse. Un système mal configuré peut promettre une compression de 10:1 mais ne fournir que 2:1 en pratique. Immuabilité et WORM : la protection contre les ransomwares « Write Once, Read Many » (WORM) est un mode de protection dans lequel les données, une fois écrites, ne peuvent être ni modifiées ni supprimées. Certains systèmes de stockage objet distribué prennent en charge le WORM via des politiques d’immuabilité. Lorsque vous écrivez des données avec une politique d’immuabilité, le système garantit que personne — pas même les administrateurs — ne peut les supprimer ou les modifier pendant une période donnée. C’est une protection forte contre les ransomwares : même si des attaquants compromettent des identifiants d’administrateur, ils ne peuvent pas supprimer vos sauvegardes. La mise en œuvre de l’immuabilité varie : Immuabilité au niveau de l’objet : chaque objet peut avoir sa propre politique d’immuabilité. Un objet de sauvegarde peut être configuré pour rester immuable pendant 30 jours. Pendant cette période, aucune suppression n’est possible. Rétention en mode gouvernance ou conformité : certains systèmes distinguent la rétention en mode gouvernance (que des utilisateurs à privilèges élevés peuvent lever avec une justification appropriée) et la rétention en mode conformité (qui ne peut jamais être levée). La rétention en mode conformité est plus forte, mais plus restrictive. Gels juridiques : certains systèmes prennent en charge le gel juridique — les administrateurs peuvent placer un gel sur des données pour empêcher leur suppression, même si la période de rétention normale a expiré. Le gel juridique est indispensable pour les litiges et les enquêtes réglementaires. Pour les administrateurs de sauvegarde, l’immuabilité est de plus en plus importante. Les ransomwares sont l’une des menaces les plus sérieuses pour l’infrastructure de sauvegarde. Des sauvegardes immuables donnent l’assurance que la reprise reste toujours possible — même si votre infrastructure principale est entièrement compromise. Considérations opérationnelles : supervision, performances et dépannage Exploiter un stockage objet distribué à grande échelle pose des défis opérationnels : Opérations de rééquilibrage : lorsqu’un nœud est ajouté ou retiré, les données doivent être rééquilibrées entre les nœuds. Ce rééquilibrage consomme de la bande passante réseau et des E/S disque. Sur un système de sauvegarde en production, un rééquilibrage pendant les heures ouvrées peut pénaliser les performances des sauvegardes. La plupart des opérateurs le planifient en heures creuses. Pannes de nœuds et reprise : lorsqu’un nœud tombe en panne, le système doit reconstruire les données perdues à partir des nœuds restants (autres réplicas ou fragments d’erasure coding). Cette reconstruction consomme de la bande passante réseau et des E/S disque. Si plusieurs nœuds tombent en panne simultanément, la reconstruction peut s’avérer impossible (ce qui impose une restauration depuis une sauvegarde secondaire). Supervision : le stockage objet distribué génère de nombreuses métriques : santé du cluster, état des nœuds, progression du rééquilibrage, latence des API, utilisation du stockage par nœud. Une supervision efficace est essentielle. Si vous ne savez pas qu’un nœud est défaillant avant qu’il soit complètement hors ligne, vous perdez en résilience. Formation des opérateurs : le stockage objet distribué est plus complexe que le stockage traditionnel. Votre équipe doit comprendre le rééquilibrage, l’erasure coding et la déduplication. Cela peut nécessiter des formations ou le recrutement de profils expérimentés dans les systèmes distribués. Sauvegarde et reprise après sinistre : les clusters de stockage objet distribué doivent eux-mêmes être sauvegardés. Si l’ensemble de votre cluster tombe en panne et que tous les nœuds sont perdus (peu probable mais possible), vous devez pouvoir restaurer. Cela implique généralement de sauvegarder séparément les métadonnées et la configuration du cluster, indépendamment des données. Planification de la capacité du stockage objet distribué La planification de la capacité (en anglais) est différente pour le stockage distribué (en anglais) : Capacité brute et capacité utile : si vous déployez 100 To de disques avec une réplication à trois voies, votre capacité utile est de 33 To. Avec l’erasure coding (par exemple 10+4), elle est de 71 To. Comprendre cette différence est essentiel pour bien dimensionner. Croissance et marge : la plupart des opérateurs maintiennent l’utilisation sous 80 à 85 %. Au-delà, les performances se dégradent, le rééquilibrage se complique et la reprise après panne devient risquée. Si vous prévoyez 100 To de sauvegardes avec une réplication à trois voies, il vous faut 300 To de capacité brute, plus une marge. Prévoyez 400 To. Hiérarchisation : toutes les données n’ont pas besoin d’être en ligne. Les données d’archive peuvent être stockées sur un stockage objet plus lent et moins cher. Les sauvegardes chaudes (récentes, fréquemment consultées) peuvent l’être sur un stockage objet plus rapide. La planification de la capacité doit tenir compte de cette hiérarchisation. Coûts d’egress : si vous utilisez un stockage objet distribué dans le cloud, les coûts d’egress (frais de sortie des données du cloud) peuvent être considérables. La planification de la capacité doit tenir compte du volume de récupération prévu et des coûts d’egress associés. Migrer vers le stockage objet distribué De nombreuses organisations migrent de leur stockage de sauvegarde traditionnel vers le stockage objet distribué. C’est un exercice difficile : Migration des données : vous devez déplacer des téraoctets ou des pétaoctets de données de sauvegarde existantes de l’ancien stockage vers le nouveau. Cela prend du temps et consomme de la bande passante. La plupart des migrations se font progressivement, sur des semaines ou des mois. Fonctionnement en parallèle : pendant la migration, vous faites généralement fonctionner les deux systèmes en parallèle. Les sauvegardes écrivent simultanément sur l’ancien et le nouveau stockage jusqu’à la fin de la migration. Cela augmente temporairement les coûts de stockage et la complexité opérationnelle. Bascule : à un moment donné, vous basculez vers le nouveau système. Les tâches de sauvegarde écrivent désormais sur le nouveau système, et la reprise se fait depuis celui-ci. Cette bascule est risquée et doit être soigneusement planifiée. Données héritées : les anciennes données de sauvegarde peuvent rester sur le système hérité à des fins d’archivage, ou être migrées vers le nouveau système. Le coût de la migration (en stockage, en réseau et en temps opérationnel) doit être mis en balance avec le bénéfice opérationnel d’un système unifié. Bien démarrer avec le stockage objet distribué pour la sauvegarde Si vous évaluez le stockage objet distribué pour la sauvegarde : Commencez par les sauvegardes non critiques. Menez un pilote sur des données secondaires ou une nouvelle application. Vérifiez que votre logiciel de sauvegarde s’intègre bien, que les performances répondent à vos besoins et que l’exploitation est gérable. Envisagez de mettre en œuvre une architecture de cible de sauvegarde évolutive (en anglais) d’abord pour les charges non critiques. Comprenez les capacités de déduplication, d’erasure coding et d’immuabilité du système. Vérifiez qu’elles fonctionnent comme documenté. De nombreuses promesses de fournisseurs sur les ratios de déduplication ne reflètent pas les performances réelles. Établissez des procédures opérationnelles : comment ajouter et retirer des nœuds, surveiller les pannes et y répondre. Ces procédures doivent être documentées et testées. Comprenez les solutions de cible de sauvegarde disponibles et la manière dont elles s’intègrent à votre infrastructure. Planifiez votre migration de manière progressive. Migrez d’abord les sauvegardes non critiques. Validez la réussite. Étendez ensuite aux systèmes critiques. Lorsque vous vous étendez sur plusieurs sites géographiques, planifier votre architecture multisite (en anglais) est essentiel pour la résilience. La décision d’adopter le stockage objet distribué pour la sauvegarde est de plus en plus évidente : c’est le bon choix pour la plupart des organisations. Le défi est de bien le mettre en œuvre : comprendre ses caractéristiques, le dimensionner correctement et l’exploiter efficacement. Les organisations qui y parviennent bénéficient d’une infrastructure de sauvegarde bien plus efficace. Le stockage objet distribué n’est plus une technologie de pointe. C’est le socle des architectures de sauvegarde modernes. Votre infrastructure de sauvegarde devrait reposer sur lui. Pour aller plus loin Architecture de cible de sauvegarde évolutive (en anglais) Stratégie de sauvegarde d’entreprise (en anglais) La stratégie de sauvegarde 3-2-1-1-0 expliquée (en anglais) Stockage immuable et défense contre les ransomwares (en anglais) Durabilité des données dans les systèmes de stockage haute densité (en anglais) Le stockage objet pour les data lakes (en anglais) Qu’est-ce que le stockage immuable ? (en anglais)
