 Bonjour, je m'appelle Michael Courcy, je suis architecteur de solution à Cast & By V, et aujourd'hui je vais vous montrer comment utiliser le snapshot CSI pour rembacher votre application. Nous allons voir différentes choses. La première chose que nous allons explorer est pourquoi nous avons besoin d'un snapshot, pour faire une bonne backup, plutôt qu'une copie de 5 systèmes. Nous allons voir ce qu'est l'interface de storage des containers. Nous allons utiliser cette partie de la CSI, appelée la partie snapshot, pour prendre un backup de votre espace. Pour finir, nous allons voir la limitation de la solution que nous allons demonstrer pour la protection de long terme. Pourquoi nous avons besoin d'un snapshot plutôt qu'un copie de 5 systèmes, pour prendre une bonne backup ? La raison est simple. Nous allons prendre un PVC de 6,5. À T0, F1 a 4 bananes, F6 a 4 pinapples. À T1, 5. À T2, 6. Nous allons prendre un snapshot. Le snapshot est consistant du crash, ce qui signifie que tous les files sont capturés exactement en même temps. Vous capturez les 6 bananes et vous capturez aussi les 6 pinapples, tout cela en même temps. Consistents avec l'actualité de 5 systèmes avant le crash. Si vous faites un copie de 5 systèmes, vous capterez tous les files, un par un, en même temps que le système est encore évolué. Donc vous pouvez trouver vous-même au moment du backup, prendre les 6 bananes. Mais quand vous finissez le copie, vous finissez avec F6, avec 8 pinapples. Et vous n'êtes pas dans l'actualité de 5 systèmes avant le crash. Donc vous n'êtes pas consistant du crash. C'est pourquoi vous avez besoin d'utiliser le snapshot, pour prendre le backup. Mais le snapshot est consistant du crash, mais pas consistant de l'application. Alors, qu'est-ce que cela veut dire ? Nous allons prendre un exemple d'application comme Kafka. Kafka est en train d'utiliser des messages. C'est en train d'utiliser des topics. Les topics sont en train d'utiliser des partitions. Les partitions sont en train d'utiliser des segments. Et les segments sont les files, dans lesquels vous faites la message de Kafka. Pour obtenir un très haut throughput, Kafka n'est pas en train d'utiliser immédiatement le message de la 5 systèmes. Il utilise l'OS Virtual Memory, pour ouvrir la 5. Et quand vous l'avez écrit, quand Kafka l'a écrit, il l'a écrit dans la RAM, dans l'OS Memory, pas dans la 5 systèmes. C'est seulement quand des conditions sont faites, comme la taille est riche, ou la période est riche, que Kafka prenne la décision d'utiliser la 5. Et puis, la 5 est... Et puis, les messages sont vraiment en train d'utiliser la 5. Mais, qu'est-ce qui se passe, si le snapshot se passe avant le flush ? Alors, votre segment n'est pas dans le backup. Donc, vous pouvez trouver en vous-même une situation où certains partitions ont tout le segment, et certains autres partitions n'ont pas tout le segment. Et, au point de vue de Kafka, ce n'est pas consistant. C'est pourquoi nous avons dit que le snapshot n'est pas consistant, mais pas consistant de l'application. Alors, un quick takeaway, c'est que c'est mieux d'utiliser le snapshot que les 5 systèmes de copie, si vous n'êtes pas capable de freiner. En ce cas, votre backup de 5 systèmes sera consistant de l'application. Et le snapshot est consistant de l'application, et ce n'est pas nécessairement consistant de l'application. Au moins, vous avez un mécanisme pour flush, avant de prendre le snapshot. Pour comprendre pourquoi nous avons besoin d'interface de storage dans les Kubernetes, nous avons besoin de comprendre comment travailler la provision de storage dynamique. Quand les utilisateurs subissent un PVC, les Kubernetes API s'attendent à l'application. Et l'application de l'application va parler d'un provider de storage pour créer un volume. Et en fait, vous avez un PVC dans l'update de la PVC. Ce qui est important de comprendre c'est cette partie qu'on appelle l'application dans le code Kubernetes. Mais cette partie qu'on appelle le provider de storage pour être EBS pourrait être Azure Disk Safe. Beaucoup de providers de storage. Pas beaucoup, comme nous allons le voir dans la version précédente avant le CSI. Et maintenant, quand vous avez besoin d'attacher un code pour votre PV vous soumettez le code plus le PVC request. Et c'est aussi le travail de l'application de travailler sur le code pour attacher le PV au code, où le pote est caduel qui en fait va retourner dans le status de la main et transmettre à un status de pote. Donc l'issue ici était cette partie, le provider. Le provider est au code Kubernetes. Et pour cette raison c'était un nombre limité de providers. Ils sont tous représentés ici, en fait. C'est tout. Et c'est une issue parce que vous êtes NetApp. Et vous voulez communiquer avec Kubernetes. Vous voulez laisser votre customer pouvoir créer un volume NetApp pour leur workload Kubernetes. La seule solution que la team NetApp a à ce moment est d'assurer son code pour la team Kubernetes. Et la team Kubernetes doit s'assurer le code. Et si vous avez un bug dans votre driver vous devez attendre pour la prochaine release Kubernetes. Donc votre release cycle de votre driver est tendu à la release cycle de Kubernetes. Et pour toute cette raison, c'était une issue. Pour les interfaces container storage. Il a introduit votre driver sans dépendre du code Kubernetes. Il définit un certain set de interfaces que vous devez respecter pour communiquer entre Kubernetes et votre driver. Tout d'abord votre driverregistre, déclarer ses capacités et ensuite vous devez underposer tous les requests de PVC. Maintenant, comment termine-t-on ? Tout d'abord votre registre pour la API de Kubernetes. Et maintenant, quand la PVC que vous devez s'assurer par l'utilisateur le provisoiseur s'assure et s'assure à ce qu'on appelle le CSIN point mais le point de CSIN c'est ce qu'a été le driver avant. Et vous follow le path prévu et vous retranslez ça dans la réponse de la création de volume. Et cette partie est générique en fonction de la CSI. Et puis, en termes vous avez un PV sur le niveau PVC. Et quand vous soumettez l'attention il se traduit à un request de volume publié qui suivit le path prévu et à la fin, vous obtenez un point de poste. Donc, vous êtes en retard dans la situation prévue qui peut être brouillée dynamiquement par d'autres providers de storage qui veulent pouvoir travailler avec des Kubernetes. Nous allons prendre un exemple très simple. Vous voyez ici j'ai mis le set state représentant le déploiement de le path CSI. Et bien sûr, je remets juste les choses que je voulais vous montrer. D'abord, vous avez ce cycle qui est basiquement le driveur. Ensuite, vous avez le provisionnel. Le provisionnel est celui qui a de transmettre le request PVC au driveur. Vous avez aussi le registre. Je l'ai dit au 1er place ce genre de storage pour les Kubernetes API. Vous avez le CSI attacheur qui est responsable pour le volume de publication. Donc, quand vous voulez un PVC à un pod et vous avez deux autres snapshots qui belongent aussi au CSI API qui est le snapshotter et le remerciement. Nous ne allons pas parler de le remerciement mais nous allons parler de le snapshotter. Donc, quick takeaway. CSI let any storage vendor register to Kubernetes. CSI decouple storage vendor code to Kubernetes code. And most of the cycles for communicating with Kubernetes can be reused with little configuration change. Only the CSI endpoint which is the driver is the storage vendor responsibility. To create a snap of your volume you create a volume snapshot object. The volume snapshot object is a namespace object. And it's made of two things. First, the source which is the PVC that you want to snap. And the snapshot class name because you may have more than one CSI driver in your cluster and you want to address the snapshot request to the proper driver. When you create this object it will trigger the creation of another object called the volume snapshot content. And it's the volume snapshot content creation that will trigger the real snap on the storage layer. Now, if you want to restore from a snap you create a regular persistent volume claim. But this time, you specify a source as the snapshot that you just created. And once again, you specify the proper storage class name in order to use the proper driver for the restoration. And that will create a clone of the snap. A clone of the PVC when the snap was created. To summarize that in a diagram, I created this small graph. Here is the volume snapshot which is an M-spaced object. And when you create it it trigger the creation of a volume snapshot content. And it's the volume snapshot content that will be responsible for the creation of the snap. Or the driver is going to take the actual volume and do the snap to the storage layer. It's interesting to note that the link to the actual snap is not at the volume snapshot level but at the volume snapshot content level. And inside the volume snapshot content level you're going to have a small attribute called volume snapshot under that will point to the actual snap. Here you have the retention policy delete. So this policy means that if you delete it will cascade the deletion of the volume snapshot content which in turn will cascade the deletion of the actual snap. If you choose written instead of delete the deletion of the volume snapshot content won't delete the actual snap on the storage layer and your actual snap is going to be here for as long as you delete it manually at the storage layer level. If I want to restore or if I want to clone a pvc from an mspace mysql to another mspace mysql restore it here is how I can do. I can create a volume snapshot of my pvc mysql which will trigger a volume snapshot content pointing to this actual snap. And to restore it I create another volume snapshot content pointing to the same volume snapshot on the and I create a volume snapshot in my name space the mysql restore and from this snapshot I create a clone and here I am I have my new pvc with exactly the same data than the pvc that I had originally on mysql. Interesting to not hear that I put retention policy delete and here retention policy written why that it's because my initial action was to create a snap here and I want to keep the control of the addition of that so if for any reason I decide to remove the name space for example if I remove the name space mysql restore it what will happen it will delete the volume snapshot and if here it's not written but delete then it will trigger by cascaling the deletion of the volume snapshot content and the ebs and the left chain here will finish with something that does not exist anymore so when I clone from a name space to another one I always put retention policy here written so that the deletion of this name space does not accidentally delete the original snap now if I want to simply snap a whole name space it's actually very easy now with the CSI API I take the name space and the snapshot class as an argument and for all the pvc in my name space I create the corresponding snapshot and here I am I have all my pvc in my name space snapshot it it's interesting to not hear that I don't use any kind of secret to speak to the storage layer I don't have to provide as your secret or my aws access key with the proper right to create or delete volumes all that is not my preoccupation now I just have to work with API as a quick take away CSI let you create snapshot with Kubernetes API and any application that want to manage backup don't need anymore to have all the secret of your storage layer however you must take some precaution because it becomes very very easy to delete accidentally the data because you just have to delete the API there is limitation to the solution because some obvious limitation the first one that I already discuss is the fact that snap is not application consistent as I show it in the Kafka example the second thing is snap are not durable backup chance is that if you have a disaster your snap will be included in the disaster and you need a way to extract your snap to make them durable backup the first approach would be to to take a clone and from the clone you upload the clone to S3 bucket in another region in another place in another infrastructure another approach could be to replicate the snap to different region or to different infrastructure if that's possible next things is the backup policies you don't want to just punctually backup your project you want to do regular backup to have a RTO RTO is the recover time objective which means the time where you lose the data and you want to reduce that so you need to take regular backup and of course if you take regular backup it means that you have to clean the backup you have to clean the snap that you created and that ask the question of the retention policy the script that I show you of course when we working with Kubernetes we take the application as a wall so we just don't want only the data we want to have the data plus the deployment the state full set the config, the secret and so on even the CRDs and if we wanted to have a proper backup mechanism we should not only capture but also all the configuration and to be able to migrate that to another cluster so that's something of course the solution I show does not handle and last but not least API are good but not for everybody some people don't want to work with the API, with the CLI it's too complicated or they don't want to learn and they expect a single pen of glass to handle all the backup process you may have also some question about multi tenancy how do you handle multi tenancy on a big cluster all this question are of course in the limitation of the solution I show but the tools that that will give you some professional support for your backup will address that thanks a lot and I hope this presentation was helpful and I just have to say see you soon in the next cupcon thanks a lot, bye bye