Résumé

  • Cold Vault prévoit un minimum facturable de 256 Ko par objet et une durée minimale de 90 jours. Pour un objet hypothétique de 4 Ko, l’assiette de capacité atteint donc 64 fois sa taille.
  • Le nombre d’objets, leur durée de vie et leur mode de lecture peuvent peser davantage que la remise affichée au gigaoctet. Regrouper les données déplace aussi le travail de lecture, de suppression et de restauration.

Le prix du vide

Un fichier minuscule peut avoir un train de vie considérable. Déposez un objet de 4 Ko dans Cold Vault, la classe de stockage d’IBM Cloud Object Storage, et sa surface facturable commence à 256 Ko. Le locataire tient dans un coin ; le bail couvre toute la pièce.

Le petit objet de cet exemple est fictif. Le minimum, lui, figure dans la documentation d’IBM, avec une durée minimale de stockage de 90 jours. Vault fixe ses propres seuils à 128 Ko et 30 jours. Standard et Smart Tier n’ont ni minimum de taille ni minimum de durée, et ne facturent pas la récupération des données. Les autres postes, notamment les requêtes et les transferts vers l’internet public, gardent leur existence.Classes de stockage

Le calcul est simple : 256 divisé par 4 donne 64. C’est le multiplicateur de l’assiette de capacité pour cet objet. La facture complète dépend encore du tarif, du temps et des opérations. Le chiffre est assez intéressant sans lui faire dire que tous les clients paient soixante-quatre fois plus.

Supposons une population composée uniquement de ces objets de 4 Ko, conservés assez longtemps pour satisfaire la durée minimale. Pour que le seul poste de capacité soit moins cher dans Cold Vault que dans Standard, le tarif de Cold Vault doit être inférieur au soixante-quatrième du tarif de Standard. Voilà la comparaison utile à demander dans un devis. Le qualificatif « froid » ne fait pas le calcul à la place de l’acheteur.

Une somme de données, plusieurs sommes à payer

Le budget informatique aime les volumes agrégés. Il prévoit tant de données cette année, tant l’année suivante, puis applique un prix. Un stockage à minimum par objet ajoute une question : en combien de morceaux ces données arrivent-elles ?

Imaginez des enregistrements identiques conservés séparément, puis les mêmes enregistrements assemblés dans des objets plus gros. Dans le premier cas, chaque petit objet rencontre son propre plancher. Dans le second, chaque paquet rencontre le sien. Les informations n’ont pas changé ; l’unité vendue, elle, se présente moins souvent.

La moyenne ne suffit pas à décrire ce phénomène. Quelques très gros objets peuvent relever la taille moyenne tout en laissant une multitude de petits objets sous le seuil. Il faut une distribution : combien d’objets dans chaque tranche de taille, et quelle part de la capacité facturable ces tranches produisent-elles ? Additionner, pour chaque objet, le plus grand de sa taille réelle et du minimum applicable rend le mécanisme visible.

IBM précise que l’utilisation d’une même classe est regroupée entre les compartiments d’une instance. Ce regroupement comptable ne transforme pas les planchers individuels en un minimum unique pour tout le compartiment. La documentation distingue aussi le stockage, les requêtes et les transferts publics : trois postes qu’une économie de capacité ne réduit pas nécessairement ensemble.Facturation

La compression fournit un exemple particulièrement irritant. Réduire encore un objet déjà inférieur à 256 Ko allège son contenu, mais laisse intact le minimum facturable de Cold Vault. L’équipe technique peut avoir réussi son optimisation et l’équipe financière attendre en vain son dividende. Elles mesurent deux choses différentes.

Les paquets ne se défont pas tout seuls

Le regroupement paraît alors une bonne affaire. Moins d’objets, moins de planchers. Mais chaque objet indépendant emportait aussi une liberté : le nommer, le lire, le modifier ou le supprimer sans nécessairement toucher aux autres.

Une fois les enregistrements empaquetés, cette liberté doit être reconstruite. L’application a besoin de savoir où se trouve chaque élément. Elle doit maintenir cet index, traiter les mises à jour et organiser les suppressions. Selon le format et la façon de lire, retrouver un petit élément peut demander un accès ciblé ou déplacer davantage de données. Le paquet n’offre pas gratuitement l’ancien comportement.

L’arbitrage devient très concret lorsqu’un enregistrement change souvent. Une organisation par grands objets peut imposer des réécritures qu’une organisation fine évitait. Une restauration doit retrouver les bons éléments, avec le bon index. Un gain sur le stockage peut donc financer davantage de requêtes, de lectures ou de travail d’exploitation.

Le choix reste parfaitement défendable. Il faut simplement acheter le résultat complet. Le responsable du stockage peut compter les objets supprimés de la facture ; celui de l’application doit compter les nouvelles opérations nécessaires pour rendre le même service.

Changer de classe n’est pas non plus une simple retouche de l’étiquette. IBM indique que la classe est choisie lors de la création du compartiment et ne peut être changée sur celui-ci. Les objets doivent être déplacés ou copiés dans un autre compartiment de la classe voulue.Configuration des classes Règles des compartiments

Le futur changement de prix comporte ainsi un présent chantier de migration : destination, copies, références utilisées par les applications et vérification des résultats. La possibilité de partir conserve sa valeur, à condition de lui attribuer un coût et un responsable.

Acheter la bonne quantité

Il manque ici la distribution des tailles, les durées de conservation, les habitudes de lecture et le devis applicable à un client précis pour chiffrer son économie réelle.

L’ordre des questions, en revanche, est déjà établi. Décrire les objets avant de comparer les tarifs. Séparer les petits objets durables des petits objets jetables. Distinguer les données rarement lues de celles dont chaque élément doit rester accessible indépendamment. L’expression « données froides » est trop vaste pour servir de modèle financier.

IBM publie les seuils. L’acheteur peut donc les calculer avant de signer. Le défaut d’organisation consiste à laisser l’équipe produit fabriquer les unités facturables pendant que les achats ne négocient que leur prix. Chacun optimise sa colonne ; la facture additionne les deux.

Documents d’origine

Les règles proviennent des documents IBM cités. Le registre des membres de RIPE NCC sert uniquement à vérifier l’identité d’International Business Machines Corporation dans l’annuaire. L’objet de 4 Ko est une hypothèse de calcul.