*/ A. Shih dit -------------- - liens hard "Le seul point où ZFS est un peu plus limité que les FS standard, est les liens hard. Il faut faire attention si tu veux tourner un truc comme rsnapshot (zéro intérêt) ou backupc." - Envoi des snapshots "Second point à faire gaffe avec l'envoi des snapshots, c'est que de temps en temps (coupure réseau etc.) il y a un snapshot en souffrance. Tant que tu ne le détruis pas, il ne peut pas continuer." - NFS et cache ZIL "Avec NFS, c'est indispensable d'avoir un cache zil *si* tu veux faire un partage nfs synchrone (sinon c'est inutilisable). Si tu fais un montage asynchrone le zil n'apporte pas grand chose." - disques SSD et ashift "Ne pas oublier pour cela le ashift. J'oublie chaque fois ce que ça fait, mais je me souviens qu'il faut mettre 12 (si pas par défaut) pour les SSD (sinon tu les fatigues plus)" " C'est une variable du noyau qu'il faut positionner *avant* la création du zpool. Une fois le zpool créé, tu ne peux plus le modifier. C'est un truc lié à la taille des block qui sont différents selon un disque mécanique et un disque SSD" Sous BSD, faire sysctl -a|grep ashift " - taux de remplissage d'un zpool "Il ne faut jamais remplir à 100% un zpool sauf si tu as zéro snapshot, car une fois à 100% tu ne peux plus supprimer de snapshot. Et supprimer un fichier ne fait rien par définition puisqu'il est dans un snapshot. Donc en gros tu es bloqué. Il ne faut jamais non plus remplir à plus de 70-80% car à partir d'un seuil (variable mais au dessus de 70-80%) les perfs tombent très brutalement." - compression "Oui on peut changer l'algo de compression (en tout cas avez un zfs standard), mais lz4 est le plus optimal. Tu as du gzip mais ça bouffe (ralentie donc le write) énormément. Alors que le lz4 a tendance à accélérer le write (moins de données)." */ B. Levasseur dit ------------------- " # comment recevoir une notification sur la prise de snapshots ? Personnellement, j'utilise : https://github.com/zfsonlinux/zfs-auto-snapshot. Le script ne me parait pas très difficile à modifier pour lui faire envoyer un mail....ou directement via l'exécution du cron. ## cache : Dans ton cas d'usage (beaucoup d'écriture, peu de relecture), le cache L2ARC ne sera probablement jamais utilisé… ## Rollback : ``` //show snapshot zfs list -r -t snapshot -o name,creation // revert from snapshot zfs rollback -r / ``` ## Snapshot consumed space ``` zfs list -o space -r ``` ## voir les snapshots depuis Windows (Volume Shadow Copy Service) https://github.com/zfsonlinux/zfs-auto-snapshot/wiki/Samba ## remplissage : - que faut-il penser de l'alerte recue : space usage for pool "sata" is 70%. ZFS fonctionne en Copy On Write et comme beaucoup de système de ficher, il n'aime pas trop se retrouver sans espace libre pour fonctionner. Le 20% d'espace libre me parait une bonne recommandation. ## compression : - est-il possible de changer d'algorithme de compression ? Il faut commencer par vérifier si la compression n'est pas déjà activée (à la création du pool par exemple) ``` zfs get compression NAME PROPERTY VALUE SOURCE tank compression lz4 local ou sudo zpool get feature@lz4_compress NAME PROPERTY VALUE SOURCE tank feature@lz4_compress active local ``` Si ce n'est pas le cas, tu peux l'activer avec l'algorithme de ton choix (gzip|gzip-N|lz4|lzjb|zle) ``` zfs set compression= ``` " */ J. Lecubin dit ----------------- " oici des éléments de réponse « en vrac » en lien avec ton dernier mail et qui pourront peut-être t’aider à aller plus loin avec TrueNAS. Le kit de survie pour les commandes que j’utilise par ssh régulièrement : zpool status -v -> pour voir l’état de mes pools (je vérifie tout cela via du ansible avec notification par mail en cas de soucis sur un pool) camcontrol devlist -> infos sur les disques geom disk list -> avec plus de détail # je cherche mon disque HS ... sesutil locate -u /dev/ses1 da20 on Pour les snaps (j’utilise souvent cette méthode dès que je dois restaurer une donnée) : zfs list -t snapshot $mon-dataset cd $mon-dataset cd .zfs (répertoire caché par défaut) cd snapshot cd $date -> j’accède au snap du dataset à la date selectionée La prise de snap est à faire comme toute la config dans truenas. La notification intervient uniquement en cas de soucis. Mais de toute façon la prise de snap n’est pas vraiment source de pb (ça marche tout le temps sauf si ton FS est plein) Pour la question de voir les snaps dans windows : j’ai souvenir avoir cherché cela il y a longtemps et ça marchait avec FreeNAS. Par contre l’inconvénient dans le cas des $home c’est que tu dois créer autant de $home que de partages CIFS. Pour voir l’espace occupé par les snaps : zfs list -o space $mon-dataset l’utilisation de l’api par un curl pour lister les sharing NFS : curl -k -X GET -H "Authorization: Bearer 1-hjB34PG8OAt9I8eIbKlgDglBn5cxSRr7wSsRoCRyKBa6uIkY8eNyAH" "https://srvstk0l.osupytheas.fr/api/v2.0/sharing/nfs" La clé pour accéder à l'API est à générer depuis l'interface web (petite roue en haut à droite → API Keys → Add) j’ai des scripts en perl basique qui font l’intéroggation de l’api pour sortir un listing des sharings NFS ou CIFS si ça t’intéresse # Lister la config samba : testparm -s J’ai vu que tu posais la question de la replication des sharings entre 2 freenas. Oui c’est possible au travers de l’api (j’avais un script python il y a qques années qui le faisait mais qui ne marche plus car l’API a évolué. Si tu veux je peux te l’envoyer ça pourrait te mettre sur la piste mais il faut le retravailler) Mais sinon tu peux envisager aussi cette solution que je trouve plus simple : de notre côté on est en train de centraliser les accès smb sur une seule vm générique qui redirige les requêtes sur le bon filer Cela permet de communiquer un seul nom aux utilisateurs qui est valable pour tous les partages quelque soit le site / filer qui héberge la donnée (on fait pour cela du samba dfs) La generation des partages sur la VM se fait par intérrogation des APIs sur les différents freenas. Pour la partie NFS j’ai trouvé qques trucs intéressants : # Quel client monte un partage NFS ? showmount -a localhost # Stats des montages NFS - nb clients - quels datasets showmount -a localhost | awk -F: '{print $2}'|sort |uniq -c -> attention c’est juste une visu temps réelle (donc avec autoFS cela peut évoluer) Divers : un mini script à mettre dans la crontab pour automatiser la sauvegarde de ta config sqlite sur un filer distant : #!/bin/bash SCRIPT=${0##*/} HOST=$(hostname -s) SRCEFILE=/data/freenas-v1.db DESTSERV=root@172.20.200.60 DESTDIR=/mnt/r12a/archives/freenas-config DESTFILE=${DESTSERV}:${DESTDIR}/freenas-v1-${HOST}_$(date +%Y%m%d%H%M%S).db LOGDIR=/mnt/md72/.scripts LOGFILE=${LOGDIR}/${SCRIPT}.log RECIPIENT=sysadm@osupytheas.fr MAILCONFIG=y VERSIONS=30 _log() { printf "$(date): ${*}\n" >>${LOGFILE} 2>&1; } _mail() { mailx -s "${SUBJECT}" ${RECIPIENT} < ${LOGFILE}; } if scp ${SRCEFILE} ${DESTFILE}; then _log "PASS: Scp ${SRCEFILE} ${DESTFILE}." else SUBJECT="FAIL: ${HOST}: ${SCRIPT}: scp ${SRCEFILE} ${DESTFILE}." _log "${SUBJECT}" _mail exit 1 fi if grep "FAIL" ${LOGFILE} >/dev/null 2>&1; then RESULT=FAIL else RESULT=PASS fi if [ "${MAILCONFIG:=n}" = "y" ]; then printf "\n" >>${LOGFILE} # uuencode ${DESTFILE} ${DESTFILE##*/} >>${LOGFILE} fi SUBJECT="${RESULT}: ${HOST}: ${SCRIPT}." # _mail Pour la partie réseau c’est un autre collègue qui s’en occupe ; il me semble que l’on fait 2 liens 10 Gb/s bondés cuivre en LACP et on fait passer tous les VLANs dedans "