Pre-2010

Lorsque l’on envisage de déployer une solution S2D, la première préoccupation du client final est généralement de connaître la volumétrie réellement utilisable dont il disposera. Cette préoccupation est parfaitement légitime.

Microsoft a mis à la disposition des architectes un outil de calcul pour déterminer cette volumétrie utile. Malheureusement, si cet outil est utilisé pour dimensionner la solution, les résultats obtenus sont souvent très optimistes.

L’enjeu se complique lors du déploiement chez le client, car il est nécessaire de lui expliquer que la volumétrie utile qu’il avait demandée n’est pas celle qu’il obtient en réalité.

Après avoir sauvegardé un déploiement, il est maintenant temps de passer à la restauration.

Les déploiements correctement sauvegardés apparaissent  en vert dans la section compliant sur le portail Kasten:

En cliquant sur compliant on arrive sur le détail des applis sauvegardées. Sur chaque appli on verra le nombre de point de restauration s’afficher:

Dans mon cas 2 points car je n’ai eu qu’une exécution qui a fait un backup local et un export:

Dans le billet précédent j’ai installé KASTEN K10. Maintenant il est temps l’utiliser et de planifier des sauvegardes.

Dans K10 les stratégies de sauvegardes sont appelées Policies. Pour créer une nouvelle stratégie de sauvegarde il faut aller dans la partie Policie à partir du portail d’accueil:

On va créer une policy journalière afin d’effectuer un sauvegarde par jour:

On va donc indiquer un nom (daily dans mon cas), une action (snapshot pour sauvegarder) une fréquence(journalière)

Apres l’installation du nouveau cluster vient le moment de la migration.

Pour réaliser cette opération il existe un outil indispensable à toute installation de cluster kubernetes: Kasten

Il permet de réaliser les sauvegardes non seulement des stockages persistants, mais de tout votre déploiement.

Il permet aussi d’exporter les sauvegardes réalisées vers le clous (aws, azure…) ou sur un stockage générique S3 (MinIO ou autre)

Et lors des restaurations, il permet de restaurer en modifiant par exemple le storage-class, se qui permet par exemple d’importer une sauvegarde qui n’aurait pas les memes classes de stockage qu’a la source: donc, no problemo pour sauvegarder un cluster OnPrem, et le restaurer dans le cloud ou vice-versa…

L’histoire

Depuis fin 2020, la chose était connue, le support de Docker au sein de kubernetes allait être abandonné. Cet abandon sera réellement  effectif dans la version 1.24. La version RKE1 quant à elle s’appui sur docker et surement n’évoluera pas. Mais Rancher a une autre version : RKE2.

Cette nouvelle distribution de Kubernetes s’appuie sur ContainerD. Exit docker et dockershim. Donc pas de problème d’évolution future sur cette version. En revanche, il n’existe aucune possibilité a l’heure actuelle de faire une migration dite in-place.