Bonjour,
J’ai un client qui souhaite partager des fichiers, une base Cassandra et voir une base MySQL entre plusieurs environnements sans avoir à recopier les données à chaque fois. L’idée n’est pas d’avoir de la performance mais plutôt de pouvoir tester des migrations de données ou de pouvoir mettre à disposition les données dans des environnements de recette.
Pour cela, nous avons penser à utiliser overlayfs pour avoir une couche immutable et partageable au niveau inférieure et une couche en R/W « minimaliste » au niveau supérieur. L’autre composant dans la boucle est NFS pour partager ces données au travers du réseau.
La solution doit fonctionner on-prem et sur un socle ubuntu - si qqn a des retours sur overlayfs/NFS ou sur une solution alternative, je suis preneur.
J’ai déjà : - lu la doc officielle : https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt - vu que certaines fonctionnalités d’overlayfs comme l’aggrégation de « lower » demande un noyau 4+ ou le support de nfs_export est arrivé dans le noyau 4.16 - pu voir qu’il y avait eu des regressions autour du noyau 4.2 et qui ont ensuite été corrigées - je m’attends donc à pouvoir avoir des comportements étranges suivant le noyau déployé
Bonne journée, Nicolas
On 30/05/2018 09:14, Nicolas Steinmetz wrote:
Bonjour,
J’ai un client qui souhaite partager des fichiers, une base Cassandra et voir une base MySQL entre plusieurs environnements sans avoir à recopier les données à chaque fois. L’idée n’est pas d’avoir de la performance mais plutôt de pouvoir tester des migrations de données ou de pouvoir mettre à disposition les données dans des environnements de recette.
ZFS (onlinux) snapshot & clone btrfs snapshot read-write.
testé pour vous ok
Pour cela, nous avons penser à utiliser overlayfs pour avoir une couche immutable et partageable au niveau inférieure et une couche en R/W « minimaliste » au niveau supérieur. L’autre composant dans la boucle est NFS pour partager ces données au travers du réseau.
La solution doit fonctionner on-prem et sur un socle ubuntu - si qqn a des retours sur overlayfs/NFS ou sur une
MySQL over NFS ?
Cordialement.
Le 30 mai 2018 à 10:17 +0200, un+FRsAG@pontesprit.net, a écrit :
ZFS (onlinux) snapshot & clone btrfs snapshot read-write.
testé pour vous ok
L’idée n’est pas de changer les FS sous-jacents pour le moment, mais je conserve l’idée.
MySQL over NFS ?
Pour des besoins simples et non prod, ça marche correctement pour le moment. Pour l’utilisation attendue, c’est suffisant. La priorité dans notre cas est plutôt de gérer des cas en append only (files, C*) - si on arrive à faire fonctionner en plus MySQL, ce sera la cerise sur le gâteau.
Nicolas
Bonjour,
On 30/05/2018 09:14, Nicolas Steinmetz wrote:
Bonjour,
J’ai un client qui souhaite partager des fichiers, une base Cassandra et voir une base MySQL entre plusieurs environnements sans avoir à recopier les données à chaque fois. L’idée n’est pas d’avoir de la performance mais plutôt de pouvoir tester des migrations de données ou de pouvoir mettre à disposition les données dans des environnements de recette.
Pour cela, nous avons penser à utiliser overlayfs pour avoir une couche immutable et partageable au niveau inférieure et une couche en R/W « minimaliste » au niveau supérieur. L’autre composant dans la boucle est NFS pour partager ces données au travers du réseau.
La solution doit fonctionner on-prem et sur un socle ubuntu - si qqn a des retours sur overlayfs/NFS ou sur une solution alternative, je suis preneur.
Nous utilisons ici singularity http://singularity.lbl.gov/ , dans un cadre de portage d'application vers du HTC/HPC sous forme de conteneur. Ce n'est pas du docker (pas de démon, images qui peuvent être lancées en tant que simple utilisateur...), mais vous pouvez importer des images docker. Singularity a son propre langage de recette, mais il existe des convertisseurs depuis/vers docker. Les images peuvent être transportées très facilement (soit par dépôt/registre, soit par (s)cp / ftp ...); une fois produite, l'image est un simple fichier exécutable.
Si j'ai bien compris ton besoin, cette solution permet d'avoir ce que tu recherches (même si, dans notre cas (HPC), nous portons rarement des applis type bdd) : - une image immuable en read-only par défaut au format squashfs (peut être transformé en sandbox ou ext3), - des overlayfs au besoin, - plusieurs formes de lancement (image en démon avec image.start ou bien le temps de l'exécution avec run ou exec).
Nous utilisons NFS pour partager nos images. Par contre, en cas d'installation de singularity par NFS, il faut penser à créer un dossier local (localstatedir) pour les données temporaires sur chaque client NFS.
J'ai produit un TP accessible ici pour se former rapidement à cette solution : http://mbb.univ-montp2.fr/ust4hpc/tpSingu.html
En terme de performances, il n'y a pas de perte et les recettes sont claires (le contenu est découpé en sections commençant par "%" et les les lignes qui suivent sont en bash).
En terme de répétabilité, c'est également assez appréciable d'avoir des recettes propres qui incluent des sections %test. Dans ce cadre, l'utilisation des overlayfs au-dessus de l'image (qui ne sont pas sous la forme d'une recette), diminuent la lisibilité du conteneur (attention à l'effet boîte noire avec le temps).
Cordialement, Rémy.
J’ai déjà :
- lu la doc officielle :
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
- vu que certaines fonctionnalités d’overlayfs comme l’aggrégation de
« lower » demande un noyau 4+ ou le support de nfs_export est arrivé dans le noyau 4.16
- pu voir qu’il y avait eu des regressions autour du noyau 4.2 et qui
ont ensuite été corrigées - je m’attends donc à pouvoir avoir des comportements étranges suivant le noyau déployé
Bonne journée, Nicolas
Liste de diffusion du FRsAG http://www.frsag.org/
Le 30 mai 2018 à 12:07 +0200, Remy Dernat remy.dernat@univ-montp2.fr, a écrit :
Nous utilisons ici singularity http://singularity.lbl.gov/ , dans un cadre de portage d'application vers du HTC/HPC sous forme de conteneur. Ce n'est pas du docker (pas de démon, images qui peuvent être lancées en tant que simple utilisateur...), mais vous pouvez importer des images docker. Singularity a son propre langage de recette, mais il existe des convertisseurs depuis/vers docker. Les images peuvent être transportées très facilement (soit par dépôt/registre, soit par (s)cp / ftp ...); une fois produite, l'image est un simple fichier exécutable.
Si j'ai bien compris ton besoin, cette solution permet d'avoir ce que tu recherches (même si, dans notre cas (HPC), nous portons rarement des applis type bdd) : - une image immuable en read-only par défaut au format squashfs (peut être transformé en sandbox ou ext3), - des overlayfs au besoin, - plusieurs formes de lancement (image en démon avec image.start ou bien le temps de l'exécution avec run ou exec).
Nous utilisons NFS pour partager nos images. Par contre, en cas d'installation de singularity par NFS, il faut penser à créer un dossier local (localstatedir) pour les données temporaires sur chaque client NFS.
J'ai produit un TP accessible ici pour se former rapidement à cette solution : http://mbb.univ-montp2.fr/ust4hpc/tpSingu.html
En terme de performances, il n'y a pas de perte et les recettes sont claires (le contenu est découpé en sections commençant par "%" et les les lignes qui suivent sont en bash).
En terme de répétabilité, c'est également assez appréciable d'avoir des recettes propres qui incluent des sections %test. Dans ce cadre, l'utilisation des overlayfs au-dessus de l'image (qui ne sont pas sous la forme d'une recette), diminuent la lisibilité du conteneur (attention à l'effet boîte noire avec le temps).
Intéressant, merci !
Bilan rapide de la journée : - overlayfs en local, ça marche bien - monter un partage nfs en overlay : ça marche mais pour une raison étrange, je ne peux pas mettre à jour un fichier. Je peux par contre en supprimer un et en créer un nouveau - monter un overlay puis le monter en nfs : KO pour le moment - il faut attendre le nfs_export dispo en 4.16 d’une part et d’autre part, pour créer un overlayfs de type lower, il faut agréger 2 chemins minimums et pas uniquement un.
Bonne soirée, Nicolas
-
Nicolas Steinmetz -
Remy Dernat -
un+FRsAG＠pontesprit.net