Reprise du message précédent :
Disons que lz4 c'est de loin le meilleur compromis entre la perf (utilisation cpu) et le taux de compression
 
Sinon ZFS on Linux (ZoL) vient de sortir en version 0.6.5 avec pas mal de changements.
 
Le changelog ici: https://github.com/zfsonlinux/zfs/r [...] /zfs-0.6.5

Xubuntu 14.04 + ZoL + 14x WD SE 2To

• Asus x79 Extreme 11
• Xeon E5 2687w
• 32 Go ECC 4x 8 Go
• 2x m1015 flashed in LSI iT p19
• 14x 2 TB WD SE (7200rpm)
• Intel 10GbE XFP+

... en 7x vdev mirrored
 
Client : Windows 8.1, en Intel 10GbE XFP+
 
 

Même pas de SSD en L2ARC ?

Ecc ou Ecc reg ? Je me questionne sur la compatibilité de ram ecc /ecc reg avec le chipset x79 et jusque là j'ai pas trouvé de réponse

Je suis surpris par ces chiffres : habituellement c'est la vitesse de lecture qui est plus grande.
Serais-ce l'effet d'un cache d'écriture ?

Nop : je l'utilise qu'en Samba / CIFS pour des transferts séquentiels (serveur de fichiers vidéo)
La problématique : OmniOS est en SMB 1 ... les transferts étaient de 435 Mo/s en écriture / 135 Mo/s en lecture
Avec Xubuntu en SMB 3.xx, ça trace déjà bien mieux !

Avant, : ECC REG : les Asrock x79 Extreme peuvent fonctionner avec cette mémoires mais pas avec toutes les barettes.
Avec des barrettes  
-> Nanya 4GB DDR3 ECC REG 1333 :  NT4GC72B4NAN1NL-CG 0944TW 4GB 2RX4 PC3 10600R-9-10 1333 ECC : KO
-> Kingston 4GB DDR3 ECC REG DDR3 1333 KVR1333D3D8R9S : OK

Je doute.
Dans toutes les solutions de stockages en ZFS que j'ai testé, la vitesse d'écriture a toujours été plus grande que celle de lecture.

le COW est censé en théorie transformer les écriture aléatoires en écritures séquentielles. (s'il n'y a pas trop de fragmentation sur l'espace libre). Donc normalement l'écriture est rarement limitante sur ZFS.

SFP+ non ? (ou alors "XFP" tout court mais plus rare)
 
 
Sinon au niveau charge du CPU ça donne quoi ? il doit se tourner les pouces non ?

Le module fibre est intégré.  
 
C'est ce type de carte :
http://www.intel.com/content/www/u [...] brief.html

Config provisoire pour un serveur de Backup, donc pas besoin d'I/O de dingue, quasiment jamais de lectures hors metatada ( ZFS on Linux si les tests ne montrent pas de soucis)
 

 
vous en pensez quoi ? je ne fais pas de connerie ?

Jolie !
 
Utilisaiton en CIFS / Smaba ou NSF / iSCSI ?
 
Xubuntu + ZoL + Nappit me donne entière satisfaction en SAMBA

rsync quotidien uniquement de prévu pour le moment + snapshot pour pouvoir retrouver d'anciennes versions de fichiers (backup de plusieurs gros serveurs et VM)
 
actuellement on a un serveur (rsnapshot sur ext4) qui avait coûté 5 fois moins disques inclus et il est saturé niveau espace de stockage/nombre de baies.

mmm en NFS et pas SMB ?

Dans quel cas, je te recommande plutôt de passer sur Solaris 11.3 ou OmniOS
... toujours avec Nappit
-> tu as une interface web pour gérer les cron / rsync & co !

Sinon avec un autre budget : Nexenta.

Pour la carte mère, les idéales sont
-> X9SRL-F : http://www.supermicro.com/products [...] 9SRL-F.cfm
-> X9SRH-7TF : http://www.supermicro.nl/products/ [...] RH-7TF.cfm
... mais en s2011

je ne compte pas faire de montage (par sécurité).  
La seule communication se fera par rsync over ssh. Pas d'interface web non plus, le truc doit être robuste, script qui appelle rsync + rotation des snapshots + envoie d'un mail de rapport (mode parano).
Pour la carte mère je pense partir au début sur celle sélectionnéeça suffira pour 8 disques (pas envie de commander à droite à gauche et le choix est limité sur LDLC), et si j'ai besoin de bien plus de disque et qu'elle est limite je la changerai.

8 disques ?!
... pourquoi les Seagate ES en SAS et non pas HSGT 7k4000 SATA ?
Tu comptes faire du RaidZ2 en 2 pool de 4 ou 1 pool de 6 disques + 2 spares ?  
ou RaidZ1 en 1 pool de 7 disques + 1 spare ?
 
Le rack supermicro dispose d'un expender ; 1 carte LSI HBA permet de contrôler l'ensemble des hot swap.
 
L'interface web Nappit est redoutable, fiable et stable.
Elle permet en outre sous OmniOS de mirrorer le disque boot.
 
 

je préfère prendre du SAS à cause de l'expander. Mais le site Supermicro dit que les disques SATA de grade "enterprise" passent aussi donc à voir...  
les disque Seagates ont une mauvaise réputation à cause d'une série de barracuda (consumer) et du rapport blackblaze qui n'utilise que des disques low-cost de gamme "consumer"
Leurs disques pro sont solides et n'ont pas de problème. Du moins j'ai rien trouvé en cherchant la dernière fois, à chaque fois le problème vient des barracuda.  
Les disques "enterprise" HGST (ultrastar à la place de deskstar) sont bien plus chers que Seagate et seulement disponibles en SATA chez LDLC. Mais bon ça reste encore à réfléchir.
 

pour le moment j'ai prévu 1 pool de 8 disques en raidz2. C'est du backup quasiment write-only (sauf en cas de problème) en rsync, pas besoin de perf.
 
edit: quoi que en effet le raidz2 c'est mieux avec 6 ou 10 disques
 
et enfin j'ai déjà quelques Seagates 4TB en stock pour potentiellement faire du spare
 

oui j'avais compris ça, je peux controller les 36 baies avec la LSI. Je pars sur un vdev raidz2 de 8HDD car c'est suffisant pour le moment et j'augmenterais progressivement par vdev de 8HDD avec les besoins.
 

Interessant je vais quand même étudier le truc.
Ce qui est prévu pour le moment c'est un linux (debian) qui sera installé sur les SSD en raid1 software classique (mdadm) et avec grub d'installé sur les deux, donc pas de problème pour booter même si le SSD principal lache

Oui, c'est le cas avec Wester Digital : même la gamme entreprise SATA a du mal avec les expander ; ce n'est à priori, justement, pas le cas des HGST

Un prestataire avec qui on bosse, replace régulièrement leurs Seagate Constellation ES... par d'autres Seagate Constellation ES jusqu'à épuisement de leur stock, après quoi, exit Seagate, dixit un chef tech !

Wep ; l'un comme l'autre, la garantie est de 5 ans constructeur.
 
Là je tourne avec un rack 24 hotswap  peuplé de 14 HDD en 7x vdev mirrored de 2 To WD SE, su Xubuntu + ZoL + Nappit ; ça trace bien en SMB
Le backup de ce stockage est un même rack 24 hotswap avec une pool de 3x 3 vdev de 2 To WD SE en RaidZ + une pool 2x 4 vdev de 1 To WD Black, sous OmniOS + Nappit... que je vais devoir réinstaller (j'ai merdé sur le routage de la config réseau + le firmware d'une des cartes contrôleurs, p20, est buggé)
 
Sur un auter serveur de backup, j'ai OpenIndiana + Nappit qui tourne depuis plus de 4 ans, sans soucis.

OpenIndiana est plus trop maintenue si ? Quitte à prendre de l'illumos pour server je prendrais du omnios moi en tout cas.

Tout à fait.
... et bien faire un update / upgrade de OmniOs avant d'y installer Nappit
(bug avec le l2arc, Gea indique les manip sur le site de nappit)

 
On lit un peu partout que ZFS requiert un minimum 1 Go de mémoire par To d'espace de stockage. Je te conseille un peu plus pour être tranquille et laisser de la place à l'OS et ses daemons, surtout si tu comptes activer la dédupe et la compression. Cela à part, cette config de serveur est performante et relativement coûteuse, ce qui me fait dire que je préférerais rogner sur d'autres points pour favoriser la mémoire.
 

 
En ce qui concerne les disques durs j'ai un faible pour les Hitachi, dont j'ai découvert les excellentes critiques sur le blog de backblaze qui les utilise en RAID, et même dans leur version grand public !
Personnellement tous mes disques Seagate Barracuda ES et Constellation ES ont fini à la poubelle pour cause de panne passé le délai de garantie. Par contre j'emmène mes Hitachi version grand public à 70 000 h et je les change par précaution uniquement. Tout est dit.
 
Dans tous les cas un monitoring SMART sérieux permettra de les changer avant qu'ils tombent en panne.

1 Go de ram / To de stockage utile : essentiel uniquement pour la deduplication.

Or, il  me semble que cette fonctionnalité, dans OpenZFS, reste encore buggé (sous Solaris, c'est ok).

Donc si/ vu que on ne s'en sert pas, 32 Go est correct pour du backup avec peu de lecture.

 

-Faux, dépend du read/write cache disponible sur les cartes, si ton os le prend en charge avec ZFS et indirectement de la fréquence max de ton processeur. Exemple, avec 256M/TiO et mes E5 2637x2, j'active dedup et compression sans problèmes sur mes nodes custom (même si le lustre est un cas particulier d'utilisation de ZoL : ZFS ne gère pas les meta, enfin pas comme on l'entend normalement). Ce sont des cas d'usage. Le profil R/W sur les IO est aussi important (archivage etc ...)
-L'OS en lui même si tu maîtrise, prend ... 0 octets de ram active. Cas d'usage encore une fois.
-Elle est clairement coûteuse, mais il pourra brancher moulte baie jbod derrière en SAS sans soucis et augmenter son stockage d'archive, vue que c'est son but. En aura t-il le temps ? Surement pas. Mais cas d'usage également, il te manque des éléments pour en jauger.
-HGST ça te dit quelque chose ? Hitachi n'existe plus, quand t'achète de cette marque qui n'existe plus qu'en GP d'ailleurs, c'est du western digital que t'achète. En gros, t'as plus que Western et Seagate sur le marché, et tu compare deux types de seagate ... Comparaison un peu foireuse sans donner de ref'.  
-Backblaze n'est pas une référence dans le stockage "pro". C'est bien pour le stockage massif, mais pas pour les perfs (basiquement c'est du jbod un peu amélioré)
-70kH = 2900jours environs, soit 8 ans. Comment dire ...
-Monitoring SMART et sérieux dans la même phrase.  

 
Oui, je ne compte pas faire de déduplication, uniquement de la compression, et en effet comme c'est pour un backup seules les metadata doivent être cachées pour avoir un perf suffisante. (pour le delta du rsync...)
En plus il y aura la possibilité de faire un L2ARC sur une partie des SSD et comme le rsync quotidien a un pattern très répétitif à mon avis le cache va bien marcher.  
 
Sinon les plateformes Xeon E3 sont limitées à 32Go de RAM, si je veux aller plus haut il faut passer à du socket 2011 ou 2011-3 (plus cher, plus complexe, je pourrai toujours y passer plus tard s'il y a besoin)
Quand au prix je le trouve tout à fait correct quand on le compare aux solutions équivalentes "clé en main", je pense que ça vaut le coup

bon, du coup je suis perdu, je prends quoi comme disque ? chez mon fournisseur ( ) j'ai le choix entre:
-Constellation ES SAS
-WD RE SAS (un peu plus cher)
-HGST Ultrastar SATA (beaucoup plus cher)
 
j'espère que les constellation ES.3 sont pas si pourris que ça car c'est ce que Dell nous a mis sur un serveur récent (avec comme seul monitoring sérieux smartmontools et un scrub mensuel du RAID )

Evite les Western Digital sur un expendeur.

La baie 24 hdd dont je dispose qui est en WD SE contient 3 cartes LSI...

J'ai pas d'avis, mes disques dur je les payai pas ou presque
Mais sur du stockage plus ou moins froid, du NL SAS serait mieux selon moi.

 
 
Merci pour ton partage. Oui j'ignorais si la déduplication allait être utilisée, et sans elle les 32 Go semblent plus que confortables. Et donc tu penses que ton expérience de ZoL avec Lustre est représentative d'une configuration 100% ZoL en ce qui concerne les besoins mémoire ?
 
Par "ram active" tu veut dire mémoire libre telle qu'on peut la mesurer avec "free" ? C'est un point de vue très courageux que je respecte, même si personnellement je garnis généreusement mes serveurs en RAM pour bénéficier des buffers IO et des cache de fichiers. En utilisant les spécificités du noyau linux on n'a presque plus besoin de mémoire connectée à la carte contrôleur (hors bénéfices liés à sa batterie, le cas échéant).
 
Je ne peux pas juger de quoi ? Que d'une manière générale je préfère être généreux en RAM quitte à rogner sur le reste ? Si c'est précisément mon point de vue, il est connu que Linux aime la mémoire pour ses buffers et caches, en plus des besoins propres à ZFS, même si je dois avouer que j'ignore s'il existe des différences sur ce sujet précis par rapport à ext4. Dans un soucis d'évolutivité (et s'il souhaite connecter tes baies jbod) c'est un point de vue qui se tient il me semble. Là encore, sans la déduplication ls 32 Go semblent confortables.
 
Quel est l'acronyme de HGST ? C'est "Hitachi Global Storage Technologies (a Western Digital Company)". Je le sais, tu le sais alors tu peux probablement comprendre que je parle de HGST quand j'écris Hitachi ou de Westen Digital quand j'écris Western, même si mes raccourcis sont imprécis. La gamme Ultrastar n'est pas grand public à ma connaissance.
 
J'ai évoqué une découverte personnelle, celle des excellentes critiques des disques durs Hitachi Deskstar, lue sur le blog de Backblaze. Cela m'a semblé pertinent puisque silor connaît Backblaze. Voici un lien intéressant pour tirer ses conclusions personnelles. Que fait backblaze ? de la sauvegarde. Que souhaite faire silor avec son a config ? de la sauvegarde. Mon opinion personnelle est que les storage pods de Backblaize sont à connaître pour la culture générale de quiconque s'intéresse au stockage. Et toi, pour être constructive, un avis sur le disque dur du moment à acheter ?
 
Je ne comprends pas. Tu dénigres l'expérience de quelqu'un qui a poussé ses disques durs aussi loin ou tu penses que je mens ?
 
Oui je suis content du monitoring disques durs permis par smartmontools. Je t'invite à lire les statistiques d'usage de ce paquet sur le Debian popularity contest statistics pour comprendre que je ne plaisante pas. J'ai été trop vite en laissant entendre que cela permettait de prévenir toutes les pannes, alors que ce n'est que un outil formidable. Mais je t'en prie, n'essaie pas de tourner en ridicule tout ce qui sort de mon clavier. Par contre je serais très intéressé de savoir ce que vous utilisez pour surveiller vos disques durs !
 
Pour finir, je précise que je ne prétends pas du tout être capable de déterminer ce qui est "vrai" ou "faux" avec les informations données. Mon but était simplement de mettre le doigt sur des points qui me semblent importants pour tenter tant bien que mal d'enrichir la réflexion, quitte à argumenter.
 
Bonne continuation à tous

 deltasight       ... ça va ?!

Prends du recul !!!
On partage des expériences, ce n'est pas une battle

Dans les propos de MysterieuseX, rien ne laisse à penser qu'il a écrit quoique ce soit de mal envers toi.

Keep Calm

ZFS utilise la RAM pour y stocker des métadata ou le fichier ... via un algorithme qui panache le MRU (Most Recently Used) avec le MFU (Most Frequently Used).
Plus il dispose de RAM et plus il est content.
Par contre, au 20.09.2015, ZFS est encore et toujours limité à 128 Go de Ram.

A propos de la déduplication :

 
A propos du L2ARC & de la dédpulication

toujours dans une optique d'utilisation "backup" est-ce que ZFS peut encaisser sans problème une centaine de dataset avec une cinquantaine de snapshot par dataset ? (donc au total ~5000 snapshots)
 
(j'imagine que ce sont des chiffres de petit joueur mais je préfère demander )

 
A voir le profil des dataset (taille, accès). Si t'as du lourd a coté de trucs que tu utilise tout les 2 ans, peut être intéressant de passer se qui est le moins usité sur un NAS relié et accéssible par le(s) node(s) ZFS et sortir les snapshot sur bande (vue la fréquence, ça en pâtira pas trop).
Si la totalité est du même acabit, ouaip mais prévoie de l'espace (le taux de compression entre snapshots et live peut être négatif sur ZFS, et tout dépend si tu fait des snapshot full ou différentiels)
Ma préférence va quand même a séparer le système de snapshots du stockage a chaud vue qu'on commence a partir dans la catégorie du stockage "froid". 'fin après c'est aussi une question de budget (si t'as les compétences 7/7 pour maintenir un ZFS en archivage chaud + froid alors go for it)

c'est pour du backup (pour le moment) donc principalement write-only sauf cas de perte de données. Donc je crois que c'est froid c'est ça ?
 
sinon:
http://list.zfsonlinux.org/piperma [...] 23457.html
 
     

Jvais probablement remplacer un vieux backup sur bande chez un client (trop limité en place) par un ZFS.

En gros le workflow : rsync over SSH ou copie sur NFS (purement en interne), puis chaque nuit la machine en ZFS va faire des snapshots (via un simple script).

C'est fait que pour être utilisé en cas de perte de fichiers de lusers ou en cas de gros pépin. Bref, très rarement en lecture.

Jme tâte à mettre de la dédup, ya des risques ? Sachant que la perf on s'en branle si c'est pour récup un XLS 2 fois par mois (mais ça pourrait probablement sauver de l'espace).

Pour chez nous en interne sur une petite machine, j'avais monté un FreeBSD à l'époque avec ZFS + compression mais pas de dédup : aucun soucis.

edit : on parle d'une petite volumétrie, genre < 5 To

Déjà il faut voir le taux de dédup espéré, évidemment la dédup ça ne marche bien que si les fichiers sont dupliqués, genre tu backups les pc d'une équipe qui bosse sur le même projet...
En dessous d'un certains niveau de dedup il vaut mieux rajouter des disques sans dedup que de la RAM pour la dedup, ça coûte moins cher
 
sinon pour faire les snapshot et gérer leur rotation il y a ça:
https://github.com/khenderick/zfs-snap-manager

c'est mon avis perso, vu la capacité actuelle des disques et les infra capacitives que tu peux monter à vil prix, la dedupe à de moins en moins d'intérêt.
ça dépendra des données et du 'potentiel' de dedupe effectif, pour ma part, s'il est pas significatif, on part sans dedupe.

tu veux le faire tourner sur quoi ton ZFS Plam ?

this point.

 
(le script c'est un script shell que j'utilise mais qui est aussi assez bien fait)
 

 
Donc compression et pas de dédup
 

 
FreeBSD mais ça pourrait être du Linux pourquoi pas.

d'ailleurs il me semble que la dedup ralentis fortement le scrub en le rendant beaucoup moins séquentiel

Quid du niveau de RAID pour du backup de ce genre ? Raidz1 ou 2 ?
 
Le striped mirrored est un peu too much pour du backup

en cas de panne le disque sera changé en combien de temps ? quelle taille des disques ? combien de disques au total ? combien de spare ?