Volumes BSU & snapshots
BSU (Block Storage Unit) est le stockage bloc d’Outscale : un volume attaché à une VM de la même Subregion, qui survit à la VM si tu le décides. C’est là que vivent tes bases. Voici ce que bige-ops en pilote, et les chiffres Outscale qui comptent pour bien dimensionner.
flowchart LR VM[VM] --> ROOT["disque racine
gp2 ou io1"] VM --> DATA["volume de données
standard / gp2 / io1"] DATA --> SNAP["snapshot BSU
(régional)"] DATA -.->|dump applicatif| OOS[bucket OOS]
Les trois types BSU
| Type API | Nom Outscale | Performance | Taille |
|---|---|---|---|
standard | Magnetic | environ 250 lectures et 150 écritures par seconde, quelle que soit la taille | 1 à 14 901 GiB |
gp2 | Performance (SSD) | 3 IOPS par GiB (100 au minimum), burst à 3 000 IOPS sous 1 TiB, plafond 10 000 IOPS | 1 à 14 901 GiB |
io1 | Enterprise (SSD) | IOPS provisionnées, de 100 à 13 000 par volume, dans la limite de 300 IOPS par GiB | 4 à 14 901 GiB |
Une VM plafonne à 36 000 IOPS tous volumes confondus (562,5 MiB/s en blocs de 16 KiB), et accepte jusqu’à 40 volumes, racine comprise. Source : À propos des volumes.
Trois calculs qui évitent les surprises
- Le burst gp2 est un crédit. Un volume gp2 de moins de 1 TiB démarre avec 5,4 millions d’IOPS de crédit : de quoi tenir 3 000 IOPS une trentaine de minutes, puis il revient à sa base de 3 IOPS par GiB. Parfait pour un démarrage ou un batch court ; pour une base qui écrit en continu, c’est la base qu’il faut dimensionner.
- Les IOPS io1 dépendent de la taille. 300 IOPS par GiB au maximum : 3 000 IOPS demandent au moins 10 GiB, les 13 000 IOPS du plafond au moins 44 GiB.
- Le plafond de la VM s’applique avant celui des volumes. Trois volumes io1 à 13 000 IOPS donnent 39 000 IOPS sur le papier, la VM en servira 36 000.
Côté facture, un volume io1 se paie au GiB et à l’IOPS provisionnée, chaque mois : sur un petit disque à 3 000 IOPS, ce sont les IOPS qui font l’essentiel de la ligne. L’estimation de bige-ops compte les deux.
Le disque racine
- Sa taille, son type et ses IOPS (en
io1) se règlent dans le formulaire de la VM, ou en YAML (volume_size,volume_type,iops). - Par défaut, le Terraform généré pose un racine
io1à 3 000 IOPS pour les rôles base de données (mongo, postgres, mysql, mariadb, neo4j, weaviate), etgp2pour les autres. - L’estimation chiffre le racine avec le même type et les mêmes IOPS que le Terraform.
- À l’import d’un compte existant, le racine d’une VM reste attaché à sa VM : il n’est pas repris comme composant séparé.
Les volumes de données
Le composant Volume se pose sur le canvas Visual : taille
en GiB, type, IOPS en io1, VM d’attache, nom de device. Il
génère du Terraform, il est importé depuis un compte existant, et il est
compté dans l’estimation, IOPS comprises.
Le nom de device se donne au format /dev/xvdX
(X de b à z). Dans une VM Linux,
le volume apparaît en /dev/sdY selon l’ordre d’attachement ;
les paquets Outscale pour Ubuntu et CentOS recréent le lien
/dev/xvdX, et c’est ce nom que la doc Outscale demande dans
/etc/fstab.
Outscale permet de modifier la taille, le type ou les IOPS d’un volume, racine compris, quel que soit son état (Modifier un volume). Avant d’appliquer un tel changement depuis la simulation, lis le plan Terraform : il indique si le volume est modifié sur place ou recréé.
Snapshots
- Un snapshot BSU est rattaché à la Région : il sert à recréer le volume dans n’importe quelle Subregion de la Région. Pour une autre Région, on l’exporte vers un bucket OOS puis on l’importe (À propos des snapshots).
- Dans bige-ops, le composant Snapshot génère du Terraform et apparaît à l’inventaire.
- Un snapshot présent sur ton compte reste une ligne d’inventaire : il n’est pas réécrit en YAML.
- Il est compté dans l’estimation d’inventaire.
- À ne pas confondre avec les snapshots de configuration, qui sont des sauvegardes locales de tes fichiers.
Sauvegardes
Le snapshot protège le volume ; la sauvegarde applicative (dump de base) part dans OOS via les scripts générés. La rétention et la planification des sauvegardes se règlent dans ton exploitation.