2 Un pétaoctet équivaut à 1 000 téraoctets, soit environ un million de gigaoctets. C’est la production annuelle de données d’un grand groupe hospitalier. C’est le référentiel de sauvegarde complet d’une société de services financiers du Fortune 500. C’est un jeu de données d’entraînement pour un grand modèle de langage. Et c’est de plus en plus l’échelle minimale des déploiements de stockage à l’échelle du pétaoctet en entreprise. Le stockage à l’échelle du pétaoctet fait apparaître des problèmes opérationnels inexistants à plus petite échelle. Des tâches de sauvegarde qui prenaient des heures sur des gigaoctets prennent des jours sur des téraoctets. Des restaurations qui duraient quelques minutes prennent désormais des heures, voire davantage. La planification de la capacité ne tient plus : les hypothèses de croissance linéaire deviennent non linéaires et imprévisibles. Les erreurs opérationnelles (politiques de sauvegarde mal configurées qui stockent des doublons, tâches de nettoyage oubliées qui saturent la capacité) consomment des centaines de téraoctets et demandent des semaines de correction. Le stockage à l’échelle du pétaoctet exige une réflexion d’architecture qui ne se transpose pas depuis les déploiements plus modestes. Vous devez répartir les données sur plusieurs pools de stockage, paralléliser les opérations, accepter une certaine latence et une cohérence à terme pour atteindre l’échelle, et maintenir une visibilité opérationnelle complète. « Regarder ce qui prend de la place » n’est pas une option pour des systèmes de cette taille. Les pools de stockage distribués : l’architecture clé Un système monolithique unique ne peut pas raisonnablement servir des charges à l’échelle du pétaoctet. Il introduit des risques de fiabilité, des goulots d’étranglement et des difficultés opérationnelles propices aux erreurs. Concevez plutôt vos référentiels à l’échelle du pétaoctet comme des pools de stockage distribués, en vous appuyant sur les 3 exigences clés d’une cible de sauvegarde à l’échelle du pétaoctet (en anglais). Exploitez plusieurs systèmes indépendants, chacun gérant 10 à 50 téraoctets, et répartissez les charges de sauvegarde entre eux : les sauvegardes de bases de données vers le pool A, celles des partages de fichiers vers le pool B, celles de l’infrastructure virtuelle vers le pool C. Cette répartition offre trois avantages. D’abord, la fiabilité dépend du nombre de pools, et non de la capacité totale. Si le pool B tombe en panne, vous ne perdez que les sauvegardes des partages de fichiers, et non tout votre référentiel. Les sauvegardes des bases de données et de l’infrastructure virtuelle restent accessibles, et vous concentrez la remédiation sur la classe de sauvegarde touchée. Ensuite, les performances s’additionnent d’un pool à l’autre. Si chaque pool soutient 1 gigaoctet par seconde de trafic de sauvegarde, cinq pools en soutiennent 5. C’est le seul moyen d’atteindre le débit agrégé nécessaire pour sauvegarder des pétaoctets dans des fenêtres acceptables. Enfin, la planification de la capacité devient maîtrisable. Au lieu de projeter la croissance à l’échelle du pétaoctet sur cinq ans, vous projetez celle de chaque pool. Lorsqu’un pool atteint 80 % de sa capacité, vous en provisionnez un nouveau. Cette approche par étapes permet des prévisions plus précises et des dépenses maîtrisées. Planifier la capacité : une croissance imprévisible Les référentiels à l’échelle du pétaoctet croissent de manière imprévisible. Les données d’entreprise augmentent de 20 à 50 % par an, mais certaines charges de sauvegarde dépassent souvent 50 %. Sous-estimez la croissance, et vous manquerez de capacité en milieu d’année ; surestimez-la, et vous gaspillerez du capital. Suivez rigoureusement la capacité. Surveillez chaque mois la croissance du référentiel pour repérer les pics ou les tendances inattendues. Une croissance soudaine de 20 % en un mois peut signaler la sauvegarde d’une nouvelle application majeure ou une tâche de sauvegarde incontrôlée qui duplique des données. Dans les deux cas, comprendre les tendances est essentiel. Définissez des seuils de capacité. De nombreuses organisations retiennent un seuil d’utilisation de 80 % : lorsqu’un pool l’atteint, l’achat d’un nouveau pool est lancé. Vous disposez ainsi de 6 à 9 mois pour commander le matériel, le recevoir et le déployer avant la saturation. Projetez la croissance de manière prudente. Si la croissance historique est de 30 % par an, retenez 40 % dans vos plans de capacité. Cette marge protège contre les pics inattendus. Un système rempli à 90 % est fragile : aucune place pour une croissance temporaire, des tests de restauration (qui doublent la consommation de capacité) ou des erreurs opérationnelles. Dimensionnez pour une croissance qui vous laisse de l’air. Les performances : changer de raisonnement à grande échelle À l’échelle du pétaoctet, les performances de sauvegarde diffèrent fondamentalement de celles des déploiements plus modestes. Des sauvegardes de 24 heures sont normales, de 48 heures courantes, et des sauvegardes d’une semaine ne sont pas inédites dans les très grands environnements. Cela impose une autre logique opérationnelle. Impossible d’effectuer des sauvegardes complètes quotidiennes : elles dureraient plus de 24 heures et créeraient des trous de couverture. Utilisez plutôt des stratégies incrémentielles : des sauvegardes complètes hebdomadaires ou mensuelles, et des incrémentielles quotidiennes qui ne capturent que les blocs modifiés. Le trafic et la durée des sauvegardes diminuent considérablement. Parallélisez. Un seul flux de sauvegarde qui déplace un pétaoctet prend des semaines. Plusieurs flux simultanés traitant chacun 100 téraoctets en parallèle terminent en quelques jours. Votre logiciel de sauvegarde et vos systèmes de stockage doivent le permettre : évaluez les plateformes sur leurs capacités de parallélisation, et pas seulement sur leur capacité de stockage. La bande passante réseau est déterminante. Une seule connexion à 10 gigabits ne permet de transférer qu’environ 100 téraoctets par jour au maximum (en supposant une utilisation à 100 %, ce qui n’arrive jamais), bien loin de ce qu’exigent des dizaines de pétaoctets. Il vous faut plusieurs connexions haut débit, des routes de sauvegarde distribuées et une ingénierie réseau soignée pour que le réseau ne devienne pas le goulot d’étranglement. Hiérarchisez les performances de sauvegarde. Les systèmes critiques (bases de données, données financières) bénéficient d’un accès prioritaire aux routes à haut débit. Les systèmes moins critiques (développement, données de test) utilisent des chemins à plus faible débit et plus longs. Vos données les plus importantes sont ainsi sauvegardées rapidement, même lorsque le système est en pleine charge. Les techniques d’efficacité du stockage À l’échelle du pétaoctet, la déduplication, la compression et l’efficacité du stockage deviennent indispensables. Un gain d’efficacité de 20 % économise plus de 100 téraoctets de capacité, soit des millions d’investissements évités. Optez pour la déduplication a posteriori. À cette échelle, la déduplication en ligne crée des goulots d’étranglement. Exécutez-la plutôt la nuit : elle identifie et élimine les blocs redondants sur des téraoctets et libère beaucoup d’espace. Compressez de manière sélective. Les sauvegardes de bases de données se compressent avec un taux de 2:1 ou 3:1, les données non structurées (texte, journaux) de 5:1 ou plus, tandis que les images et vidéos se compressent très peu. Plutôt que de tout compresser, compressez selon les caractéristiques réelles des données : vous gagnez en efficacité sans surcharge CPU inutile. Mettez en place plusieurs niveaux. Stockez les différentes classes de sauvegarde sur différents types de stockage. Les sauvegardes récentes, utilisées pour les restaurations fréquentes, résident sur un stockage performant. Les sauvegardes plus anciennes, rarement consultées, migrent vers un stockage économique, et les archives très anciennes vers la bande. Cette hiérarchisation optimise à la fois les performances et les coûts. Visibilité opérationnelle et analytique Exploiter un stockage à l’échelle du pétaoctet exige une visibilité complète. Les méthodes traditionnelles, comme vérifier l’occupation des disques avec du, ne fonctionnent pas à cette échelle. Mettez en place une analytique du stockage. Suivez les tâches de sauvegarde, les flux de données, l’utilisation de la capacité et les indicateurs de performance. Vous devez savoir combien de données sont sauvegardées chaque jour, quelles tâches durent plus longtemps que prévu, quels pools approchent de leur capacité et quel est votre taux de déduplication. Collectez ces métriques en continu et agrégez-les dans une plateforme d’analyse. Automatisez les alertes. Si une sauvegarde traite soudain 50 % de données de plus que d’habitude, c’est le signe d’une politique mal configurée ou d’un véritable afflux de données. Alertez votre équipe pour qu’elle enquête. Automatisez les prévisions de capacité. Calculez à quelle date, au rythme de croissance actuel, un pool atteindra 80 % de sa capacité et quand il faudra provisionner du stockage. Des prévisions automatisées évitent les mauvaises surprises du type « la capacité est pleine ». La gestion des métadonnées : savoir ce que l’on possède À l’échelle du pétaoctet, savoir quelles données vous avez stockées est un défi. Quelle sauvegarde contient le snapshot de la base de données d’il y a trois mois ? Où se trouve telle version d’un fichier de configuration applicatif ? Indexez les métadonnées. Au lieu de stocker les sauvegardes comme des blobs binaires opaques, tenez un index de ce que contient chacune d’elles. Cette couche de métadonnées permet de restaurer sans parcourir des téraoctets : vous interrogez l’index et ne récupérez que les données nécessaires. Envisagez une approche « backup lake ». À l’image des data lakes du big data, ingérez toutes les sauvegardes dans un système de métadonnées distribué qui catalogue leur contenu. Les sauvegardes deviennent interrogeables, et vous pouvez répondre à des requêtes élaborées : quelles sauvegardes contiennent des données clients sur une période donnée ? Lesquelles contiennent des fichiers modifiés entre deux horodatages ? Vous consultez la couche de métadonnées, et non les sauvegardes brutes. La reprise après sinistre à grande échelle À l’échelle du pétaoctet, la restauration devient complexe sur le plan organisationnel. Restaurer un téraoctet est souvent l’affaire d’une seule personne ; restaurer des pétaoctets exige coordination d’équipe, priorisation et gestion des ressources. Créez un comité de reprise après sinistre. Ce comité arbitre les priorités de restauration et l’allocation des ressources. Lorsqu’un incident majeur impose une restauration à l’échelle du pétaoctet, quels systèmes restaurer en premier, et qui décide ? Une gouvernance établie à l’avance évite des décisions chaotiques sous la pression. Définissez des SLA de restauration réalistes. Vous pouvez par exemple garantir la restauration des systèmes critiques en 4 heures et des systèmes non critiques en 48 heures. Ces SLA doivent refléter vos capacités réelles de restauration à l’échelle du pétaoctet, et non des aspirations. Entraînez-vous régulièrement à des restaurations à grande échelle. Chaque trimestre, testez la restauration d’une part importante du référentiel. Vérifiez non seulement que les données sont restaurées, mais aussi les indicateurs opérationnels : combien de temps cela prend-il ? Combien de personnes faut-il mobiliser ? Quels problèmes apparaissent ? Conclusion : faire de l’échelle un enjeu de premier plan Un référentiel de sauvegarde à l’échelle du pétaoctet n’est pas simplement dix fois plus grand qu’un système à l’échelle du téraoctet. Il exige des approches d’architecture, des modes d’exploitation et des pratiques de gestion fondamentalement différents. Les organisations qui opèrent avec succès à cette échelle font de l’échelle un enjeu d’architecture de premier plan, et non une réflexion après coup. Concevez des pools distribués plutôt que des systèmes monolithiques. Planifiez soigneusement la capacité, avec des prévisions de croissance prudentes. Tirez parti de la déduplication et de la compression pour gagner en efficacité. Construisez une visibilité opérationnelle complète. Et entraînez-vous régulièrement aux restaurations à grande échelle pour que votre équipe agisse avec assurance le moment venu. Si vous abordez la sauvegarde à l’échelle du pétaoctet sans architecture délibérée, vous vous exposez à des problèmes opérationnels. Investissez dans l’infrastructure, les outils et les pratiques organisationnelles. Tout en cherchant à augmenter le stockage et réduire les coûts (en anglais), gardez à l’esprit que votre capacité de restauration dépend de cette rigueur. Pour aller plus loin 3 exigences clés pour une cible de sauvegarde à l’échelle du pétaoctet (en anglais) L’architecture de stockage scale-out : transformer la sauvegarde (en anglais) Augmenter le stockage tout en réduisant les coûts (en anglais) Planifier la capacité de stockage : anticiper la croissance pour l’IA (en anglais) Architecture de cible de sauvegarde évolutive (en anglais) La durabilité des données dans les systèmes de stockage haute densité (en anglais)
