Translation(s): English - Français

Debian > Debian GNU > Debian GNU/kFreeBSD > kFreeBSD Conseils


Recommandations, meilleurs pratiques et choses essayées qui fonctionnent bien. Elles se réfèrent aux fonctionnalités de Wheezy ou ultérieures.

ZFS

ZFS a toujours son propre Guide des Meilleurs Pratiques.

Snapshots

Si /boot est dans le système de fichier ZFS, vous pouvez faire des instantanés avant ou après le changement de noyau. GRUB est capable de démarrer un noyau et ses modules depuis de vieux instantanés. (:TODO: syntaxe).

Le schéma autosnap décrit dans /etc/default/zfs est incoryablement utile et efficient pour la donnée utilisateur often-changing tel que /home. Les schémas 'Tours d'Hanoï' ou 'logarithmique' déplacent l'espace pris par les instantanés, avec le désir d'avoir une longue histoire de sauvegarde, préférant garder de récents instantanés qui seront plus rapprochés dans le temps.

Les sauvegardes de base de données sont mieux écrites en tant que copies de texte brut tels que pour SQL, pour lesquelles ZFS peut appliquer une compression. Si vous faites des instantanés quotidiens, ré-écrivez simplement le même fichier chaque jour. Le schéma autosnap est adapté ici aussi.

L'option 'dateext' de logrotate.conf peut être une bonne idée. Cela évite de renommer les vieux fichiers journaux chaque jour, et permet de trouver plus facilement un journal particulier d'un jour dans l'instantané. Cette duplication n'est pas nécessaire si le même fichier journal a un instantané sur plusieurs jours.

L'option 'nocompress' peut être utilisé pour les journaux sauvés du système de fichier qui sont toujours compressés. Cela ne vaut probablement pas la peine de les compresser à nouveau, à moins que vous ayez un meilleur taux de compression, tel qu'avec l'usage de "xz".

Déduplication

Faites très attention avec cela ! La quantité de RAM peut être très importante ; je pense à quelque chose comme (taille de l'ensemble des données / taille d'enregistrement) * 512 octets. Ainsi, pour 1 TiB de données allouées dans des enregistrements de 128 KiB (valeurs par défaut pour les systèmes de fichiers) : 4 GiO de RAM additionnelles. Mais pour un zvol de 100 GiO (soit la valeur par défaut de refrecordsize=8KiB) : il faudra plus de 6 GiO !

Si vous manquez de mémoire (telle que 2 GiO de RAM), cela peut encore fonctionner durant un certain temps, mais :

* les écritures, suppression sont très lentes car la table dedup doit être vérifiée en premier ; si cela ne rentre pas dans le cache ARC avec tout le reste, il y aura beaucoup de petites opérations de lectures. Vous pouvez améliorer la vitesse en ajoutant un petit, rapide périphérique (typiquement SSD) qui servira de cache pour L2ARC, et peut-être paramétrer secondarycache=metadata ainsi l'espace réservé de manière prioritaire à cet effet.

* supprimer un instantané énorme, ce qui arrive de manière asynchrone, nécessitera d'allouer beaucoup de mémoire au noyau (qui ne peut pas être envoyé sur des disques swap) et peut être crasher votre système de manière inattendu quelques temps plus tard ; après suffisamment de temps et quelques cycles de redémarrage, la situation devrait se corriger, mais cela reste très effrayant, et est une raison d'utiliser dedup+snapshots *seulement* quand vous avez assez de mémoire : http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/47531

Les économies d’espace typiques de la déduplication peuvent aller de 5 à 20%, à moins que vos données soient *réellement* dupliquées chaque fois, pensez à déterminez si cela est nécessaire. Ajouter un peu plus de disques peut être le meilleur moyen d’augmenter l’espace de stockage, plutôt que d’ajouter un cache SSD pour contrer la perte de performance, ou encore de la mémoire vive supplémentaire pour éviter les temps d’arrêt décrits ci-dessus.

Chiffrement

Un pool ZFS peut fonctionner sur des partitions ou des disques chiffrés par GELI. Vous ne pouvez pas directement démarrer depuis, mais vous pouvez attacher des périphériques GELI au début du processus de démarrage, alors 'zpool import' le zpool chiffré et les systèmes de fichiers seront montés.

Partitionnement

Il est préférable de formater de tels disques (par exemple, /dev/da0, /dev/da1) ZFS, mais cela n'est pas toujours possible. Vous ne pouvez pas installer le chargeur de démarrage GRUB à un disque sans le partitionner.

Partitions MSDOS

Les tables de partitions msdos fonctionnent, mais avec des mises en garde :

Vous ne pouvez pas partitionner plus de 2 TiB d'espace sur un disque ayant 512 octets par secteur. (4096 octets par secteur de disque allouent 16 TiB). Sinon, utilisez GPT.

L'alignement sur des médias Flash ou SSD ne devrait pas être un problème plus que ça pour Wheezy puisque la plupart des outils s'alignent à une limite de 1 MiO. Cela devrait également laisser une zone d’incorporation suffisamment grande pour GRUB avant la première partition.

Le noyau de FreeBSD ne peut pas utiliser une partition logique en tant que système de fichier racine, ou (probablement ; non confirmé) comme volume dans un pool ZFS. Évitez donc de créer /dev/da0s2 en tant que partition étendue selon la convention de MS-DOS, Windows, et créez à la place jusqu'à quatre (?) partitions primaires.

Limitations des vieux BIOS

Les vieux BIOS des PC (~ +10 ans) pourraient ne pas supporter LBA, et ainsi ne peuvent pas adresser au-delà du 1024ème cylindre. Sur le média flash USB, elle peut être seulement de 1 GiO au début du disque ; sur les autres disques, cela peut monter jusqu'à 8 GiO. Tout ce qui est nécessaire à GRUB (les systèmes de fichiers contenant /boot et les modules /lib) nécessite d'être entierement dans cette région. Autrement, GRUB peut bloquer au démarrage, ou ne pas être capable de trouver ou charger les noyaux ou les modules, cela dépend de sur quels blocs du disque ils sont enregistrés.

La documentation de FreeBSD contient une référence à ce problème datant de 1997 : la limitation s'applique au chargeur de démarrage quand il charge l'image du noyau et les modules : une fois que le noyau lui-même est exécuté, il peut monter les systèmes de fichiers racine et les autres de n'importe où sur le disque : http://svnweb.freebsd.org/base/release/5.0.0/usr.sbin/sysinstall/help/drives.hlp?annotate=23516#l70

Partition /boot séparée

Je recommande que la partition /boot soit la première. Cela a du sens parce que la table de partition et les blocs d'amorçage de GRUB se trouvent dans le premier MiO du disque.

GRUB a probablement besoin de charger les modules du noyau depuis /lib/modules. Vous pouvez soit créer une autre partition dédiée, ou les garder dans le système de fichier racine (sujet aux contraintes de taille, ci-dessus), ou de manière commode, vous pouvez déplacer puis lier symboliquement /lib/modules vers /boot/modules (ce que "update-grub2" détectera).

Bogue #651624

Les partitions pour ZFS peuvent causer un problème si elles sont étendues jusqu'à la fin du disque. Je suggère délibéremment de garder au moins 1 MiO d'espace lors du partitionnement, ou de juste s'assurer que ce ne soit pas la dernière partition.

Exemple

Exemple d'une disque de 80 GiO avec une table de partition msdos :

0-1 MiB

MBR et blocs d'amorçage de GRUB

1-128 MiB

/dev/da0s1

ufs

/boot, contenant /boot/modules (liés symboliquement depuis /lib)

128-1024 MiB

/dev/da0s2

swap

1024 MiB - 81919MiB

/dev/da0s3

zfs

système de fichier racine

81919-81920MiB

gap

Partitions GPT

Les tables de partitions GPT fonctionnent bien.

Malheureusement pour qu'un disque GPT soit bootable, les BIOS des PC peuvent avoir besoin d'une table de partition msdos (héritage) factice, que vous pouvez créer avec "gptsync". La contrainte mentionnée ci-dessus s'applique toujours au vieux BIOS non LBA, ainsi les systèmes de fichiers pour /boot et /lib/modules ont besoin des entrées dans la table de partition historique, et besoin d'être intégré dans le premier GiO du disque (dans le pire des cas).

GRUB a besoin d'installer une partition de démarrage BIOS, il est recommandé qu'elle soit au démarrage du disque. Il est conseillé que les systèmes de fichiers contenant /boot et /lib/modules suivent immédiatement après, pour s'assurer qu'il y ait de l'espace pour eux dans la talbe de partition historique et qu'il soit dans le premier GiO du disque.

Les partitions restantes ne doivent en aucun cas être limitées. Le noyau de FreeBSD comprend le schéma de partitionnement GPT et peut monter la racine et les autres systèmes de fichiers.

Le bogue ZFS mentionné ci-dessus n'a pas lieu avec GPT, parce que la sauvegarde de la table de partition occupera le dernier bloc adressable LBA sur le disque.

NFS

Le serveur NFS sur Wheezy GNU/kFreeBSD (freebsd-nfs-server) refuse les connexions depuis des clients sous Wheezy GNU/Linux quand la version de NFS n'est pas spécifiée. C'est par défaut pour NFS v4, le serveur refuse les requêtes de montage.

La solution est d'ajouter l'option -o vers=3 à la commande mount du client, tel que :

$ sudo mount -t nfs -o vers=3 $SERVER_IP:/path/to/share /local/mount

Assurez-vous d'ajouter -h 0.0.0.0 aux arguments de rpc.lockd, de même dans son fichier init, comme pour le bogue 664812. corrigé dans Wheezy !

L'arrêt par les scripts init pour NFS peut être lente : lisez 664812

Si vous utilisez par exemple un client OpenELEC, vous avez besoin d'ajouter l'activation des connexions TCP à nfsd. Sans cela, le montage des partages NFS sur OpenELEC ne fonctionnera pas (testé avec OpenELEC 2.0). Vous pouvez faire cela en créant un fichier /etc/default/nfsd, contenant : DAEMON_ARGS="-t -u"

Je recommande aussi les options de montage proto=tcp sur les clients (ce qui empêchent les problèmes de path MTU, et bien plus).