Test: pvecm expected 4. Upgrade hardware+ software, remplacement de la bécane. Puis pcevm expected 3. Pour les migrations tu peux partir en IB, 25GB ou 100Gb. Quitte à rebasculer à la main en dernier. Très bonne approche de cluster "versioning" Reproduire avec une infrastructure ce que l'on peut faire en software c'est formateur
Petite question, tu fais en manuel/bash que pour la demo ou même habituellement ? Tu n'as pas d'outil préféré ? ça doit te prendre un temps fou pour tous tes clusters. Et la migration à chaud n'a pas trop d'impacts des fois si la vm est très utilisée en IO ? Cluster Bdd, etc. Merci pour la vidéo.
Hello, pour une mise à jour de version majeure, sauf cas / environnement / client très particulier (grosses fermes identiques, etc.) : jamais. Toujours à la main, pas même un script bash. Après en réalité ça prends relativement peu de temps (sauf problème à debug), et plusieurs peuvent être faits en parallèle. De plus les migrations majeures de version, c’est une fois toutes les x années. Sinon 0 impact sur les perfs, mais en même temps ce sont des raid 10 composés chacun de 6 NVMes..
Je me doute qu'il y a une raison derrière ce choix mais pourquoi ne pas choisir d'avoir une rotation du noeud de spare ? Je m'explique, si le 4 est le spare, alors déplacer 3 vers 4 puis 2 vers 3 et ensuite 1 vers 2. Le 1 devient spare et comme ca il n'y a eu que 3 migrations de VM et pas 6 avec les aller retour qu'implique cette solution
@@romainald9291 comme expliqué en réponse à Arkadia : chaque noeud est situé dans un datacenter / un pays particulier et chaque vm doit retourner à sa place en fonction de son contrat, de l’emplacement de son PRA, etc.
merci pour ta vidéo sa comble mes lacunes de debutant
Au plaisir !
Merci pour cette vidéo migration. ;-)
Avec plaisir 🙂
Test: pvecm expected 4. Upgrade hardware+ software, remplacement de la bécane. Puis pcevm expected 3.
Pour les migrations tu peux partir en IB, 25GB ou 100Gb. Quitte à rebasculer à la main en dernier. Très bonne approche de cluster "versioning" Reproduire avec une infrastructure ce que l'on peut faire en software c'est formateur
❤❤❤❤👍
W l❤
Petite question, tu fais en manuel/bash que pour la demo ou même habituellement ? Tu n'as pas d'outil préféré ? ça doit te prendre un temps fou pour tous tes clusters.
Et la migration à chaud n'a pas trop d'impacts des fois si la vm est très utilisée en IO ? Cluster Bdd, etc.
Merci pour la vidéo.
Hello, pour une mise à jour de version majeure, sauf cas / environnement / client très particulier (grosses fermes identiques, etc.) : jamais.
Toujours à la main, pas même un script bash. Après en réalité ça prends relativement peu de temps (sauf problème à debug), et plusieurs peuvent être faits en parallèle.
De plus les migrations majeures de version, c’est une fois toutes les x années.
Sinon 0 impact sur les perfs, mais en même temps ce sont des raid 10 composés chacun de 6 NVMes..
Je me doute qu'il y a une raison derrière ce choix mais pourquoi ne pas choisir d'avoir une rotation du noeud de spare ? Je m'explique, si le 4 est le spare, alors déplacer 3 vers 4 puis 2 vers 3 et ensuite 1 vers 2. Le 1 devient spare et comme ca il n'y a eu que 3 migrations de VM et pas 6 avec les aller retour qu'implique cette solution
je me posait la même question. pourquoi re-basculer les VM quand tout est finit alors que les nodes sont ISO
@@Arkadia977officiel chaque mode est situé dans un datacenter différent et donc les vms doivent reprendre leur emplacement d’origine.
@@romainald9291 comme expliqué en réponse à Arkadia : chaque noeud est situé dans un datacenter / un pays particulier et chaque vm doit retourner à sa place en fonction de son contrat, de l’emplacement de son PRA, etc.
Moi je vote pour plus de passages « danse » ! 😂
@@paulpascual 😂 😂 😂
Avec peut être le son un peu moins fort pour les musiques ^^ y'a une diff avec ta voix
@@nicolasd2812 😂 : le son n'a pas été ajouté dans la vidéo, c'était le son de mes hauts parleurs qui repassent dans le micro.