# Validation storage pour OVH ## CSI-S3 :::info ❌ Non satisfaisant ::: J'ai tout repris calmement depuis le début, tenté de faire marcher geesefs (le mounter conseillé et le seul réellement utilisé par ceux qui développent la solution), j'ai ensuite essayé à nouveau le mounter rclone (sans plus de succès). Pour résumer on a des démontages intempestifs, je suis parvenu à certaines configs moins fragiles que d'autre, mais au final, ça ne fait tenir qu'un peut plus longtemps le mountpoint avant de finir inévitablement par le perdre. Selon Enix (qui utilise cette CSI), c'est lié au S3 d'OVH qui n'est pas vraiment fidèle au protocole S3, eux utilisent des minio locaux. Quoi qu'il en soit, il n'a pas été possible de faire fonctionner cette solution, après avoir épuisé toutes les pistes (dont je pourrais vous retracer le cheminement mais ça serait un peu long et fastidieux, cela dit, dîtes moi si ça vous intéresse on s'en parlera de vive voix), j'ai envisagé une autre piste. ## NFS+Replication via OpenEBS :::info ✅ satisfaisant ::: - POC fonctionel sur ovh-dev et aks-dev - répond bien au besoin de départ : monter un volume dans un déploiement accessible depuis plusieurs noeuds (RWX). - Jiva : bon choix potentiel car priorise la robustesse et l'intégrité vs les performances ### Validations effectuées #### Perfs vs Azure share actuel ✅ ![Capture d’écran_2024-02-01_17-49-09](https://hackmd.io/_uploads/ry5TYVcqp.png) - ovh-files => openebs/jiva - azure-files => azure share conclusion : perfs openebs/jiva très correctes et acceptables #### Sécurité NFS ✅ - on a testé de monter un volume directement en NFS sans passer par la PVC : impossible - ajouter une netpol dans le ns openebs qui n'autorise que les pods du namespace à communique entre eux : ça n'a pas bloqué la lecture/2criture de fichiers sur un volume déjà monté. N.B.: ça a bloqué le montage d'un nouveau volume. Mais autoriser le namespace où l'on crée le PVC dans la netpol n'a pas permis non plus le montage, donc la communication ne vient pas de ce namespace mais est gérée plus bas niveau. #### Github backup ✅ - a fonctionné complètement et correctement à plusieurs reprises - écrit un très grand nombre de petits fichiers et bcp d'opérations de renommage - volume total : environ 30 Go #### Simulation autoscale des noeuds et maj du cluster ✅ Tout en écrivant des données (via dd) : - kill 2 pods de gestion des replicas : remontent très bien et reprennent la réplication normalement - kill du pod primary d'écriture : opérations de lecture et écriture figées le temps que ça reprenne => ralentissement mais ok. - kill du pod de gestion de nfs : idem opérations figées. - kill du primary et d'un replica : bien remonté - suppression d'un PV/PVC de replica : bien remonté - suppression des 3 pods d'un coup : se remonte en read only uniquement, mais possibilité d'accepter aux données en lecture pour recréer un volume et recopier les données. Parvient parfois à se réparer tout seul. Acceptable car la résilience envisagée correspond à N replicas -1, on ne gère pas la cas où 3 noeuds seraient cassés en même temps. #### Redimensionnement (expansion uniquement) - théorique oui car supporté par les volumes persistants OVH - test de propagation sur le volume visible via NFS : ok - mais pas test de remplissage du voume au-delà de la taille initiale ## Procédure de migration Azure -> OVH - produit coupé temporairement - sync des données azure vers un bucket s3 dédié à une backup de migration, via rclone - re sync vers le volume OVH, via reclone - autres migrations (CNPG, etc.) comme effectuées sur les autres produits sans stockage - redémarrer le produit ## Next steps - migration preprod vers nouveau storage, toujours sur Azure. Validation de la lecture/écriture via l'utilisation du produit. - migration prod vers nouveau storage sur azure - migration du produit sur OVH ## Optimisation Evaluer l'intérêt d'avoir 3 replica storage et 3 replica cnpg quand on utilise du block storage déjà répliqué 3 fois par OVH. Avantages de conserver ça : - failover plus rapide en cas de pépin sur un noeud qui contient le primary - portabilité pour utiliser du local storage - portabilité pour de la haute dispo multi datacenter Idéalement : migrer sur du local storage pour améliorer les performances et diminuer le coût d'avoir x3 volumes persistants.