Reprise du message précédent :

 Nous on fais des expand/gros de zpool, mais on est en solaris/sparc... Notre procedure (si ca vous aide):
 
Contexte: on a des disques dans un SAN, donc quand on presente un LUN de 80GB et qu'on fait un expand dans la baie de disque, il faut ensuite instruire l'OS que ses disques sont plus gros.
 

Je pense que je vais me diriger vers du ZFS.
Questions sur le RAIDZ3 :
Bien, pas bien ?
Trop jeune ou pas ?
Stable ?
Pour finir : je vais créer un serveur de stockage avec 8 disques, raidz2 ou raidz3 ?
Je ne trouve pas de recommandation pour 8 disques.
6 disques c'est raidz2 conseillé et 9 disques c'est raidz3, mais je trouve pas pour 8.

EDIT : j'avais pas vu le "AFTER VIAGRA:" ^^

 
Moi je fais
 

 
Et ça marche très bien, pas besoin de format et tout le toutim.

Tu presentes surement le s2 (ou simplement, tout le disque) a ton pool -> c'est niet dans ma boite. On slice le disque pour n'avoir qu'un s0 qui fait toute la taille du disque et on l'inclu dans le pool.

Edit: et apres un test (avec un pool qui utilise un s0) -> ca ne fait rien

ça y est j'ai retrouvé la recomandation type de raidz/nombre de disque (ou inversement) :

http://www.solarisinternals.com/wi [...] mendations

Comme 8 disques c'est plus proches de 9 que de 6 je vais me baser sur de la triple parité.

EDIT :
Je trouve pas grand chose sur la fragmentation des fichiers avec du ZFS.
Vos avis ?

Non pour 8 disques tu peux rester sur du raidz2 (6+2)
 
du raidz3 avec 8 disques c'est pas terrible comme configuration (5+3)

 
Pourquoi c'est niet ? C'est beaucoup mieux pour zfs d'avoir tout le disque...

 
Parce qu'ils présentent des LUN et pas des disques a ZFS, leurs baies n'est pas une JBOD sur laquelle il font tourner ZFS : c'est un SAN qu'ils fractionnent pour présenter les LUN a leurs stations solaris/sparc (ou serveurs).
 
En gros, ils font des Zpool de LUN <_<. T'as déjà vue inception ? Ben c'est pareil : un cube dans un cube dans un cube ... xD
Se qu'il appelle disque c'est une LUN. (qui soit dit en passant doit très certainement être un container logique mais les disques doivent être formattés en ZFS en natif suivant la marque du SAN <_< )

Ben nous on a ça aussi, dell compellent ou emc clariion, SAN FC. Y a pas de filesystem sur la baie, et un disque = 1 LUN, et on crée un zpool dessus. Opérationnellement c'est beaucoup plus simple.

 
Le firmware de ton SAN a forcément un FS sur les disques, mais ça t'es pas forcément censé le savoir. Souvent, c'est du ZFS ou assimilé (OneFS/Celerra/SFS pour EMC, IntelliSnap/FluidFS pour Dell par exemple.) Un disque ne peut être utilisé en mode "raw" dans un SAN.
Niveau perf, c'est assez bof au final, vue l'overhead de faire 1 disque = 1 lun. A ce tarif, autant prendre des baies JBOD en direct parce que tu rajoute l'overhead du SAN + overhead IB/FC/ethernet dessus + exposition + overhead ZFS, au final sur le disque en lui même tu perd 40% de perfs a cause de ces overheads qui s'empilent.
ZFS c'est fait pour être exposé en direct, ou au pire a faire un SAN derrière un FS type Lustre.  
 
 

Je vérifierai ça me paraît louche ton histoire de fs, jamais entendu parler de ça.
 
Sinon quand je dis un disque = une lun je parle pas d'un disque physique. Sur une compellent par exemple, une lun va être composée de blocks répartis sur tous les disques physiques d'un même tier, pour maximiser le nombre d'axe.
 
C'est côté OS (en faisant echo | format) que tu verras 1 disque par lun ajoutée. Et c'est recommandé par Dell ET Oracle de créer un seul zpool sur chacune de ces luns (et pas au niveau des slices).

 
Comme ça c'est plus clair ... Et évite de me prendre pour une quiche, je connais bien les termes LUN etc ... Puisque j'en ai conçue des SAN.    
Donc, quand a l'origine tu dis un disque = 1 LUN, c'est un abus de langage, utilise les bons termes.
 
Pour être parfaitement exacte on parle de slice : on ne slice pas sous ZFS, soit pas de slice de LUN, ni de disques. Et on évite les LUN de 20 disques (connerie en branche).
 
Plus l'infra est grosse, moins on a intérêt a utiliser du SAN si on a du ZFS, la finalité étant d'avoir 16 baies jbod raccordées en SAS de 240 disques (exemple des baies fujitsu eternus JX60) sur un node et qu'il envoie son steak en IB.
1 baie = 1 vdev.

 
Je te prends pas pour une quiche. Désolé mais je vois pas pourquoi tu m'as repris alors si je me base sur ce que tu dis (et notamment "on ne slice pas sur zfs" ), c'est exactement ce que j'ai répondu à ktulu.

LimDul : pour ma part je suis en RAIDZ3 depuis 2 ans.

Au début 1 vdev de 19*2To. Le plus efficient d'après mes calculs.

J'ai récemment ajouté 2 vdev : 2*19*4To.

Et là je suis en train de remplacer un par un les 2To d'origine par des 3To. ça resilver à 2,5Go/s, mais chaque resilver lit toute l'array donc ça reste un poil long.

Par contre c'est du ZFS natif (OpenIndiana).

je vote mystx ... mais bon, comme en SAN j'y connais rien, je me melerais pas à ce débat d'experts.

Merci asmono.

 
Choisis ton camp camarade

 
J'ai juste repris les termes étymologiquement exacts (tant qu'a faire, autant utiliser le bon vocabulaire, parce que ça peut être trompeur de dire qu'un disque c'est une LUN et inversement : c'est ton mode de fonctionnement et ce cas particulier ne s'applique qu'a toi )

 
Tu peu aller plus vite pour le resilver : tu change les disques a parité max, et une fois que t'as changer tout les disques, seulement tu resilver, vue ta volumétrie, ça fait 4 changements de disques et 1 resilver. Sinon, tu change tes spares en premier et tu bascule les données dessus et tu resilver au dernier changement de disque.

 

 
Mais du coup, je capte toujours pas pourquoi il associe pas son zpool à une LUN, et comme ça il pourrait faire
 
zpool online -e <pool> c0tXXXd0
 
au lieu de se faire chier à aller dans format... Typiquement nous on a un script qui fait toute la chaîne (création de lun sur la baie via l'api puis création du zpool), on l'utilise pas parce qu'on a un peu peur que le support fasse nimp avec mais ça fonctionne nickel.

Probablement la dernière question avant que je ne me décide :
Peut-on utiliser des disques au caractéristiques différentes dans un même vdev ?
 
Comme ça je dirais que oui car on peu agrandir un vdev en changeant par des disques plus grands.
Mais là je vais mélanger 3 marques différentes avec des vitesses de rotation et des caches différents ainsi que sata2 et sata3.
Mais je mélange pas sata et sas.
 
Perso je pense que ça vas faire comme avec un mélange de barrettes de mémoire différentes : alignement sur les plus petites performances.
Mais j’aimerai avoir vos avis

 
En gros, il ne rajoute pas un slice a son vdev/pool quand il expand, mais il étend le "slice" existant, sauf qu'on s'en fou un peu dans le topoc, ça tire pas franchement partie de ZFS au final, c'est du stockage "classique" sur SAN au format ZFS (son lun datahub_parking est vue comme un dev simple non slice monté en backup). Il "resilver" via format sur un pool d'un disque au final.
 
En fait pour étendre un dev, t'as deux choix : tu rajoute des disques/lun et tu expand dessus (scrub/silver, se que tu fait), où tu agrandis ton lun existant directement dans le SAN et tu reformate pour dire a l'OS que le disque est plus grand (se qu'il fait).
Les deux choix sont valables même si en SAN, sa solution est plus "propre" (après tout comme j'ai dis, l'intérêt de faire des vdev/zpool de LUNs est quasiment nul). La tienne est valable si tu a du multi baie et que tu veuille par exemple stocker un chunk de parité sur une baie et un chunk sur une autre (=meilleurs résilience si défaillance d'une baie complète).
 
Dans un cas, comme dans l'autre, ça reste assez contre productif ou économiquement non viable sur le long terme (puisque un jour ou l'autre tu sera amené a te passer du SAN et partir sur du node custom pour augmenter tes perfs I/O et mieux contrôler tes disques).

 
Mais moi, j'agrandis mon lun dans le san, et ensuite je fais zpool online -e. Sauf qu'à zfs à la base je lui ai présenté le d0 et pas le d0sX.
 
# créer lun sur baie
# puis
zpool create mypool c0tXXd0
 
# expand lun sur baie
# puis
zpool online -e mypool c0tXXd0
 
Et quand j'agrandis mon lun, je mets pas plus de disque dedans ni rien, et je la stripe pas avec une autre lun non plus. Mon lun est composé de blocks répartis sur tous les disques de la baie (ça c'est transparent pour moi en fait), et je dis juste maintenant tu fais pas 200go mais 250.
 
Je suis d'accord pour le node custom mais faudra l'expliquer à mon CIO (ou attendre qu'il parte à la retraite) parce que pour lui le SAN c'est la vie... Avec genre 10% de données vraiment utiles stockées sur le SAN on continue de capitaliser à mort dessus c'est ridicule.

LOL POLARISE et MysterieuseX>
 
Les raisons d'utiliser des slices au lieu du disques sont et de une, historique (on ne change pas les habitudes d'une boite comme ca) et de deux:
 
Apres des tests sous Solaris 11.1, un zpool sur un LUN comprenant tout le disque (disons c0t0d0 sans preciser de slicing), marche nickel, jusqu'a un expand du LUN -> bizarrement, on a le zpool qui merde et on plante tout, jusqu'a reboot du host -> pas bien!
A la base, j'etais un fervent adepte du -> le disque entier pour le zpool, jusqu'aux tests qui ont revele ce bug. La j'ai en effet vu que c'etait pas une bonne idee, d'ou le slicing.
 
Pour l'idee d'utiliser toute une baie de disque en jbod, c'est une bonne idee mais rendue nulle sur des baies de disque IBM qui virtualisent le brol et mettent du cache partout. On n'a plus de jbod pur contrairement aux anciennes DS. On rajoute a ca que notre infra n'est pas 100% ZFS et on reste donc contraint d'utiliser la methode traditionelle LUN -> host.

c'est légèrement HS, mais vu qu'il y a des gens trapus sur le sujet ici:
j'aimerais avoir plus de connaissances dans les infrastructures de stockage DAS/NAS/SAN/NFS/Backup etc...  
Il y a de bon bouquins à jour sur le sujet ? des site où aller ? des forum anglophones avec des gens compétents ?
 
j'ai l'impression que la catégorie sys & réseaux pro est à moitié morte sur HFR.
 
Un exemple de question que je me pose: je ne comprends pas pourquoi les baie de stockage/extension DAS de Dell sont si chères, c'est juste un boitier, alim redondée et un contrôleur SAS, non ?

 
C'est surtout rempli de gens qui n'y connaissent rien et racontent n'importe quoi ...

 
Un peu comme dans la vraie vie quoi...

spafaux

Quand j'ai demandé, MystX m'a gentiment redirigée vers les formations de M. MystX

s'il y a un lien qui en présente rapidement le contenu/prix je suis preneur  

le mieux ça reste de parcourir les forums spécialisés (anglophones) et les user group sur le domaine.
les groupes de discussion sur LinkedIn aussi (tri à faire néanmoins, parmi les réponses et les interlocuteurs).
sinon, quelques experts de haut niveau peuvent trainer sur ce forum ...

je suis en train de refaire des tests sur zfsonlinux pour voir si je retrouve les mêmes problèmes qu'il y a 6 mois. (normalement ça devrait être corrigé vus les rapports de bug fermés et les commits effectués)
hâte de pouvoir l'utiliser en prod, mais avant il faut que je prouve sa robustesse.
 
 
edit: pour ceux qui seraient intéressé, un de mes testcase: (on récupère les sources de linux et on lance 200 copie du répertoire en // )
 

git clone https://git.kernel.org/pub/scm/linu [...] /linux.git
for i in {1..200}; do cp -R linux linux-$i & done;

c'est barbare mais ça avait bien marché (pour le faire crasher) la première fois
 
config de test: debian stable + zfsonlinux + raidz2 de 6 disques + l2arc sur ssd + cpu 4 cores/8thread
 
edit: ça a l'air de beaucoup mieux marcher maintenant

https://github.com/Traviis/htop/com [...] 2bc615fdee
 
on peut compiler htop pour prendre en compte le cache zfs (ARC), il faut appliquer le patch ci-dessus et rajouter --enable-zfs-cache-awareness au "configure"
 
=> rajouté en première page

 
Quelle baie pour quel prix par exemple ?
 
2 indices possibles : Les prix publics sont souvent largement au dessus du prix final pour tromper l'ennemi. De plus sur certaines baies il y a quand même pas mal de fonctionnalités comme de l'auto-tiering, de la dédup, des migrations à chaud de baie à baie voire de la haute dispo cross-site...

 
Ah ok. Bizarre j'ai jamais eu ce bug, t'es sur que ça a pas été corrigé depuis ? T'as jamais vu avec le support ce qu'ils en disent ?

Bah le support Oracle est plutot bof ces temps-ci, donc...
 
Ca m'avait aussi choque ce bug, moi qui voulais convaincre un collegue """legacy""" que donner le disque c'etait bien... C'est peut-etre du a nos baies? (IBM Storwize) - mais c'etait un franco "je perd le pool" et plus moyen de l'exporter/destroy/nada.
 
J'en ai conclu que le resize touchait au private region du zpool  

genre du MD1200 12 baies le truc est "affiché" à 8k€.  
Et pour la dédup/migration chaud/haute dispo (hormis alim et chemins SAS redondants) je pensais que c'était fait plutôt par des boitiers SAN que par un simple DAS    
 
Et pareil pour le SAN/NAS j'ai du mal à trouver un boitier hard (sans le soft qui va avec) où je peux installer ma linux ou ma BSD custom. Ca serait pour de la PME avec utilisation en interne (pas d'accès par des clients) donc pas besoins de trucs de malades et super cher pour avoir de la ultra haute disponibilité.  (je pourrais détaillé ce que je veux, mais c'est surement pas le bon topic)
 
En vrai je suis un peut perdu par tout ça, je me demande si je ne devrais pas me faire payer une formation ou un consultant formateur.

 
Dedup et tout c'est pour des SAN oui mais tu as mis SAN aussi dans ton post initial. Je connais pas trop les prix des DAS.
 

 
Regarde les boitiers Nexenta je sais pas si ça te conviendrait... Y a une distro qui vient avec basée sur illumos mais tu paies que si tu veux du support je crois. ZFS est natif sur illumos.
 

 
L'idéal ça serait d'avoir un bon support sur un produit que tu as pour le maîtriser à fond, nous on a de très bon contacts avec dell qui nous suivent de très près et mine de rien on monte bien en compétence, bon que sur un seul produit par contre.

Bonjour.
 
J'ai pas mal lu pour tenter de commencer à comprendre ce système de fichiers.
Je voudrai que vous puissiez me confirmer ou corriger ce que je pense avoir compris.
 
Déjà je vais commencer par les "définitions".
 
Pool de stockage ou zpool : un zpool est composé d'un ou plusieurs vdev et contient un ou plusieurs dataset ou jeu de données. Les données sont réparties entre les vdev comme dans un raid0 (mais avec des variation en fonction des performances et capacité des vdev) et donc si un vdev est perdu le zpool l'est aussi, on peux ajouter des vdev à un zpool mais pas en retirer. Il est conseillé d'utiliser dans un zpool des vdev de même types
 
Dataset ou jeu de données : "sorte de répertoire" (ou de partition, j'ai pas vraiment bien compris) permet de gérer les autorisations, les quotas, la compression et la déduplication, est stocké dans un zpool
 
zvol : disque virtuel accessible en iSCSI je n'ai pas compris dans quoi il est stocké (dans un dataset ou un zpool ?)
 
vdev : périphérique logique contenant un ou plusieurs HDD ou partitions, gère le raid0, raid1, raidz1, raidz2, raidz3. On ne peux pas ajouter ou retirer de disque/partition à un vdev (sauf pour le raid1 miroir où on peux en ajouter) le seul moyen pour l'agrandir (mais pas en cas de raid0) est de changer les disques par des plus grand en laissant le raid se reconstruire
 
Strip : type de vdev (comme raid0 ou raidz2), je n'ai pas compris si c'est du JBOD ou raid0 ou raid1
 
ARC : cache de lecture en RAM
 
L2ARC : cache de lecture sur un support rapide (HDD de 10 OU 15k rpm ou mieux SSD)
 
ZIL : cache d'écriture sauf en cas d'écriture synchrone, peux être déporté depuis la grappe zfs vers un support plus rapide, on parle alors de SLOG
 
 
Déjà, je voudrai savoir si j'ai bon ou pas pour ces définitions.
Ensuite, je voudrais des précisions sur les filesystem.
J'ai cru comprendre que l'on peux formater un filesystem dans un autre type : ext, fat, ntfs...
Mais je n'ai pas compris où (dans quoi) il est stocké, ni si on peux l’apparenter à un disque (et donc le partitionner) ou à une partition (et donc non).
Quelle est la différence avec les zvol ? Et donc les avantage de l'un et de l'autre ?
 
 
 
Les datasets.
J'ai cru comprendre que l'on peu ajouter la compression après coup mais que les données présentes ne  seront compressées qu'après leur modification et donc qu'il vaut mieux l'ajouter dés le début, de plus on peux aussi la retirer. Par contre pour la déduplication j'ai cru comprendre que contrairement à la compression que l'on peux ajouter/retirer on doit l'ajouter lors de la création et on ne peux la retirer sans détruire le dataset.
 
 
Merci à vous.

Salut,
 

 
Pour clarifier sur tes questions, filesystem et dataset sont en fait les mêmes choses.
 
Tu as un disque par exemple /dev/dsk/c0t0d0.
Tu crées un zpool dessus : zpool create data c0t0d0
Ensuite tu crées tes datasets (ou filesystem) : zfs create data/home; zfs create data/home/limdul; zfs create data/shares
Ensuite (ou en passant les options à la création) tu peux changer les options :
zfs set mountpoint=/home data/home # par défaut le zfs data/home sera monté dans /data/home ; par ailleurs data est un zpool mais est aussi un zfs, monté dans /data par défaut ; tu peux aussi changer son point de montage
zfs set quota=1g data/home/limdul
zfs set compression=lz4 data # data est un zfs donc on peut lui appliquer la compression à lui ; les zfs "en dessous" hériteront de la propriété
 
un zvol ça sera du style :
zfs create -V 3g data/myzvol
 
Et un fichier /dev/zvol/dsk/data/myzvol apparaîtra que tu pourras formater en ce que tu veux, comme un disque physique, ou l'assigner à une vm, etc.
 
Pour faire du iscsi c'est encore autre chose il faut créer une target et tout, regarde dans les docs je connais pas de tête.
 
Attention pour partager en nfs il suffit pas de le mettre dans dfstab (exportfs sous linux ?) mais il faut aussi faire
zfs set sharenfs=on data/shares
(en samba l'option s'appelle sharesmb)
 

Oula avant de parler des commandes j'en suis encore juste à tenter de comprendre le vocabulaire et les concepts.

Alors là cela me perd encore plus.
Tu me dis que les vdev ça n'existe pas. Mais alors que comprendre de ceci :
http://www.durindel.fr/informatiqu [...] ocabulaire :

De ceci :
https://blog.belfalas.eu/administra [...] -les-vdev/

Et tout le reste que l'on peux trouver en faisant une recherche "ZFS + VDEV"

Ce que tu me dis casse totalement la compréhension en poupées russes que j'avais.

Voila ce que je comprend de ton exemple :
J'ai un disque
je créé un zpool avec (le disque ne contient que ce zpool et le zpool est composé que de ce disque, mais le zpool aurai pu avoir plusieurs disques)
je créé un ou plusieurs datasets/filesystem

Avec ton changement dans ce que j'avais cru comprendre après je suis perdu.
Comment ajouter des disques ?
Qui contient quoi et qui est composé de quoi ?
(sans donner les commandes, dis-moi juste dans quoi je les ajoutes)

Avant j'imaginais ceci :
Les disques 1, 2 et 3 forment le vdev1 en raidz
Les disques 4, 5 et 6 forment le vdev2 en raidz
vdev1 et vdev2 forment le zpool1
zpool1 contient les dataset/jeu de données/zvol
Et donc pour agrandir le zpool1 il y avait deux solutions : soit changer un a un les disques d'un vdev par des plus grands et laisser à chaque fois reconstruire le vdev soit ajouter au zpool un autre vdev (avec sa propre composition)

Là avec ce que tu me dis que les vdev ça n'existe pas ça casse tout et je suis perdu.

EDIT :
Peut-être y a-t-il un problème de "traduction", ne parlant pas englais je me limite aux sources françaises.
Peut-être parlons-nous des mêmes choses mais sous des noms différents ou décalés.