ZFS optimisé dans un environnement à faible RAM faisabilité?

Je suis en train de configurer un serveur de fichiers et j'en suis arrivé à configurer réellement les lecteurs de données. Le système dispose de 4 lecteurs (un disque OS, 3 disques de données). Le disque du système d'exploitation est formaté en ext4 et ne sera pas ajouté au pool ZFS (si je choisis d'exécuter ZFS) .Mon souci principal est l'intégrité des données et le risque minimum de perte de données (la mise en cache du lecteur est désactivée dans le BIOS). Pour cela, ZFS semble être le candidat parfait, car il a une version stable pour Linux (correct?), Et prend en charge la duplication de données, la mise en commun et raidz, où les disques durs n'ont pas à être de la même taille.

Mais voici mon problème. Le serveur n'a que 2 Go de RAM et cela ne peut pas être mis à niveau dans un proche avenir, et de manière réaliste, seul 1.5 sera réellement accessible à ZFS après avoir installé tous les autres services. Un maximum d'environ 10 clients l'utiliseront à un moment donné (plus comme 4 en moyenne). Est-ce trop bas pour être considéré comme sûr?

D'après ce que je comprends, ZFS peut planter dans des situations de faible RAM et emporter le pool avec. J'ai entendu des opinions contradictoires sur la question de savoir si le swap contribuera à atténuer ce problème (j'ai un disque dédié au swap de 20 Go). Quelqu'un a-t-il subi une perte de données avec ZFS avec peu de RAM et quelles optimisations avez-vous inclus pour éviter cela?

Compte tenu de ce qui précède, serait-il possible de continuer à exécuter ZFS, bien que réduire la taille de l'ack et le réduire un peu ou est-ce trop risqué?

Spécifications du système: 2 Go de RAM, 20 Go de swap drive OS, Debian 7, installation minimale, avec FTP, et XBMC, DNLA (pour donner une idée des besoins en RAM). Utilisé pour le serveur de stockage et le streaming de musique sur d'autres appareils.

linux memory zfs Thomas E
la source

Je ne suis pas un gourou de ZFS, mais je connais assez bien les systèmes de fichiers en général, et je connais un endroit que vous devrez surveiller - beaucoup de temps - pour la consommation de mémoire est la déduplication des données. Vous ne spécifiez pas la taille de vos disques, ni la quantité de données qui y résidera; c'est énorme, car ZFS doit conserver une table de recherche en mémoire. Je ne peux pas parler d'autres préoccupations, mais je tuerais certainement la déduplication. De plus, btrfs est maintenant assez mature pour les données sauvegardées; l'avez-vous pensé? Consultez arstechnica.com/civis/viewtopic.php?f=16&t=1226135 pour obtenir des informations (avec lesquelles certains seront sans doute en désaccord).

ravenpi

Oh oui, j'ai raté ça. Le pool sera de 3,35 To (à la fois les disques et les données, car il sauvegardera 9 clients par jour, donc je suppose qu'il se remplira rapidement, je suppose que cela signifie au moins aucune duplication, car FreeBSD suggère 5 Go de RAM pour chaque espace de stockage de To) merci d'avoir signalé btrfs, je ne savais pas qu'il était maintenant stable, je suppose que je vais y jeter un coup d'œil.

Thomas E

"Stable" est quelque chose que je ne pourrais pas me précipiter pour l'appeler; on hésite à appeler TOUT système de fichiers nouveau, même un peu comme "stable". Mais ça y arrive. LWN (Linux Weekly News) vient de faire une série à ce sujet; c'est bon - vérifiez-le ici: lwn.net/Articles/576276

ravenpi

Réponses:

Vous déclarez l'intégrité des données et le risque minimum de perte de données comme principales préoccupations. L'exécution de ZFS avec seulement 2 Go de mémoire est risquée et déconseillée. Trop peu de RAM tue les performances et a été la cause de nombreux pools non montables dans le passé. Le projet FreeNAS prévoit au minimum 8 Go de RAM.

De plus, puisque votre préoccupation est la perte de données, vous voudrez utiliser la RAM ECC. Étant donné que votre boîte ne peut prendre en charge que 2 Go de RAM, je suppose que c'est une très vieille boîte qui ne serait pas un bon choix pour ZFS.

Pour répondre à tes questions:

[…] Et prend en charge la duplication des données

Dans la pratique, oubliez la déduplication lorsque vous n'avez pas au moins 32 Go, comme une règle de base. Vous pourriez avoir besoin de beaucoup plus de RAM, selon la taille du pool. Deuxièmement, faites le calcul si les coûts de déduplication + RAM sont moins chers qu'une poignée de disques supplémentaires. Plus souvent qu'autrement, plus de disques sont l'alternative moins chère.

Est-ce trop bas pour être considéré comme sûr?

Oui, c'est beaucoup trop bas.

D'après ce que je comprends, ZFS peut planter dans des situations de faible RAM et emporter le pool avec.

C'est vrai et de nombreuses personnes ont perdu leur pool en raison de la faible RAM.

J'ai entendu des opinions conflictuelles sur la question de savoir si l'échange pourrait aider à atténuer ce problème

Oubliez le swap, votre box ZFS ne devrait jamais utiliser le swap.

EDIT: Si vous vous sentez aventureux et ne craignez pas le risque de paniques occasionnelles ou de perte de données, lisez le guide de réglage ZFS et adaptez les paramètres mentionnés. Voici les exemples de paramètres pour un système de 768 Mo de mémoire.

vm.kmem_size="330M"
vm.kmem_size_max="330M"
vfs.zfs.arc_max="40M"
vfs.zfs.vdev.cache.size="5M"

Sinon, investissez une centaine de dollars dans une bande de mémoire et profitez d'un système stable et performant.

Marco
la source

Je vois. Pour préciser oui, j'ai un ram ecc et la machine est le microserveur hp proliant gen7, qui prend en charge jusqu'à 8 / 16gb de ram, il n'est actuellement pas financièrement viable d'acheter plus de ram. Je savais que freenas recommandait 8 Go, mais la documentation freebsd et Solaris suggère 1 Go au minimum, ce qui est la raison de la question. Je suppose qu'à la lumière de cela, je devrais m'en tenir à ext4 et mettre en miroir manuellement avec rsync et dd sur des disques hors ligne, probablement la solution la plus sûre.

Thomas E

Pouvez-vous expliquer pourquoi ZFS ne devrait pas utiliser SWAP?

CMCDragonkai

Il n'y a aucune raison d'utiliser ZFS sans ECC est plus dangereux que d'exécuter le même matériel avec un autre système de fichiers.

Alicia

Pourquoi la communauté ZFS commente-t-elle toujours avec un tel snobisme arrogant? Tous ceux qui veulent des données fiables n'ont pas droit à 100 $ juste pour répondre à des exigences de conception tout à fait ridicules ! J'ai, par exemple, un petit serveur domestique ARM avec 1 Go de RAM câblée et des disques durs USB. Je veux que les données qui s'y trouvent soient à l'abri de la pourriture des bits, en étant à la fois détectées et corrigées, et aient des instantanés à des fins de sauvegarde. Il n'y a pas besoin de vitesse. Et btrfs est tout simplement cassé par conception. Donc, ZFS serait raisonnable, si un idiot ne l'avait pas conçu pour imploser de dépression chaque fois qu'il a <128 exaoctets de RAM.

Evi1M4chine

Sur les systèmes à haute pression de mémoire (Linux), il est vraiment nécessaire de mettre à niveau la mémoire. Il y a toujours un bug ( lien ) où l'échange bloque l'IO (tâche bloquée par le noyau), ce qui le rend inutilisable à moins qu'il ne soit redémarré. Je crois que le vm.swappiness = X n'a aucun effet sur zfs, donc limiter l'arc à un certain nombre pourrait aider un peu.

satch_boogie
la source