Configuration non optimale, c'est grave docteur ?

[dav57480]

Bonjour,
je mets en place un freenas 6x4To + 2x4to de sauvegarde externe (suffisant actuellement pour la sauvegarde et de la marge pour le raidZ) + LTO
Usage Home et TPE, je voudrais me limiter à 1 disque de tolérance de panne pour garder le système dispo au cas ou.
Plus le temps passe, et plus il deviendra irréaliste de vouloir récupérer les anciens disques d'où le manque d’intérêt à vouloir multiplier les parités, sans compter les autres soucis qui peuvent foudroyer tout l'ensemble.

Problème, 6 disques en RaidZ n'est pas jugé comme optimal pas le système. C'est basé sur quoi ?
Performances ? Problème de parité ? Trouve que ça serait mieux en RaidZ2 ?

Autre question, Comment agréger deux liens, je ne trouve pas de menu LAAG.

Merci de m'éclairer,

Cordialement.

 

[durdur]

Salut !

Alors pour les optimisations, à priori cela serait lié à une petite diminution des performances, cela dit ça ne veux pas dire que ça ne fonctionne pas, juste que le débit ou le nombre d'opérations maxi par secondes sera un peu plus faible.

Il est assez difficile de trouver des infos là dessus, surtout que ça dépend pas mal de l'utilisation. Un usage home par exemple est plutôt orienté vers des fichiers de taille importante à écrire ou lire en streaming, etc. C'est très différent d'un usage base de données par exemple avec de petits fichiers ou de très petites écritures mais assez nombreuses.

Le mieux à mon avis est d'essayer : monte un raidz à 6 disques, tu le teste avec une utilisation typique et tu essaye la même chose avec 5 disques ensuite.

Je suis désolé, j'ai pas compris le problème avec le temps qui passe et la réutilisation des disques.

 

[dav57480]

Ce que je veux dire sur l'âge des disques, c'est que je pars sur des disques neufs de 4To.
Si un disque meurt dans les 6 mois, un disque de parité devrait suffire pour reconstruire.
Si un disque lâche dans 4 ans, le risque qu'un deuxième ne supporte pas la reconstruction est plus grand, mais sera t-il encore intéressant de conserver un pool avec des "petits" disques de 4To, si toutefois les disques sont encore d'actualité.
Le rapport prix/capacité HD/SSD diminue, on en est à une équivalence SSD / HD SAS.
J'essaie de tenir compte de la valeur résiduelle du pool à plus ou moins long terme, ainsi que la robustesse toute relative du système, tant soft que hard.

D'ailleurs, en parlant de risques, comment se situe un freenas par rapport à un syno et ses attaques/chiffrement contre rançon ?

Tant que j'y suis, je suis habitué à gérer mes partages ainsi dans le /etc/exports :
/home/serveur/NFS/Photos 192.168.5.10(ro,sync,subtree_check) 192.168.5.20(ro,sync,subtree_check) 192.168.5.30(ro,sync,subtree_check) 192.168.5.40(ro,sync,subtree_check) 192.168.5.50(ro,sync,subtree_check) 192.168.5.51(ro,sync,subtree_check) 192.168.5.52(ro,sync,subtree_check) 192.168.5.53(ro,sync,subtree_check) 192.168.5.54(ro,sync,subtree_check) 192.168.5.55(ro,sync,subtree_check) 192.168.5.56(ro,sync,subtree_check) 192.168.5.57(ro,sync,subtree_check) 192.168.5.58(ro,sync,subtree_check) 192.168.5.59(ro,sync,subtree_check) 192.168.5.60(ro,sync,subtree_check) 192.168.5.70(ro,sync,subtree_check) 192.168.5.33(rw,sync,subtree_check) 192.168.5.80(rw,sync,subtree_check) 192.168.5.81(rw,sync,subtree_check) 192.168.5.82(rw,sync,subtree_check) 192.168.5.83(rw,sync,subtree_check) 192.168.5.84(rw,sync,subtree_check) 192.168.5.85(rw,sync,subtree_check) 192.168.5.86(rw,sync,subtree_check) 192.168.5.87(rw,sync,subtree_check) 192.168.5.88(rw,sync,subtree_check) 192.168.5.89(rw,sync,subtree_check) 192.168.5.180(rw,sync,subtree_check)

Dans l'esprit Freenas 9.2, ça se traduit comment ?
J'ai un peu tourné en rond entre les droits utilisateurs, les "lier tout le monde"...

Je continue à manipuler pour arriver au système que j'utilise actuellement.
J'ai un lecteur réseau Playon AC Ryan, je n'ai pas encore réussi à lui faire monter un partage du NAS.

David.

 

[durdur]

Ah oui ok, c'est bon je vois ce que tu veux dire à propos des disques ! En effet, c'est tout à fait vrai et je suis assez d'accord.

L'attaque des Syno, j'en avais même pas entendu parler dis donc, je viens de découvrir ça en te répondant, apparemment c'est lié à une faille dans une ancienne version de leur interface de gestion. Au moins sur ce point là, pas de soucis avec FreeNAS. Dans le cas général et bien le risque est le même que pour une machine FreeBSD et dépend avant tout de son exposition à l'extérieur.

Perso elle est limitée au maximum : presque plus aucun accès à un service avec mot de passe depuis internet, donc entre autre pas d'accès à la GUI sans VPN. Il me reste le FTP (bien sûr chiffré) mais je me tâte pour soit le désactiver et l'activer uniquement à la demande, soit passer en SFTP avec clé. SSH est en authentification par clé uniquement bien sûr. Seuls les ports utilisés par ces services sont redirigés vers le NAS. Bien sûr, au delà de ces sécurité de base il reste toujours les failles comme Heartbleed par encore découverte mais là...


Pour tes partages, visiblement il y a 2 catégories d'utilisateurs : ceux qui ont accès en écriture au dataset et les autres qui ne sont qu'en lecture seule. Je n'utilise pas tellement NFS, mais à mon sens il y a 2 possibilités :
-> Soit au niveau du dataset : tu crées un groupe "Utilisateurs RW" propriétaire du dataset et celui ci a des droits 775. Du coup tous ceux qui ne sont pas dans le groupe sont en lecture seule.
Avantage : Ensuite il n'y a qu'un partage NFS pour tout le réseau et plus d'IP à gérer : chacun aura accès selon ses droits.
Inconvénients : Si il y a d'autres utilisateurs qui ne doivent pas avoir accès à ce dataset c'est raté !

-> Soit pour reprendre ta configuration actuelle tu paramètres 2 partages pour le dataset Photos, l'un limité aux IP du premier groupe. L'autre avec les IP du second et avec l'option lecture seule. Le dataset pouvant alors être en 770 avec tout le monde dans le groupe propriétaire.
Dans ce cas soit tu ne mets rien pour "lier tout le monde à" avec le risque que si quelqu'un se connecte en tant que root au partage il accède à tout (risque à évaluer), soit la doc indique cette méthode :

7.2.2
Sample NFS Share Configuration
By default the Mapall options shown in Figure 7.2a show as
N/A
. This means that when a user connects
to the NFS share, they connect with the permissions associated with their user account. This is a
security risk if a user is able to connect as
root
as they will have
complete
access to the share.
A better scenario is to do the following:
1.
Specify the built-in
nobody
account to be used for NFS access.
2.
In the
permissions
of the volume/dataset that is being shared, change the owner and group to
nobody
and set the permissions according to your specifications.
3.
Select
nobody
in the Mapall User and Mapall Group drop-down menus for the share in Sharing
→ Unix (NFS) Shares.
With this configuration, it does not matter which user account connects to the NFS share, as it will be
mapped to the
nobody
user account and will only have the permissions that you specified on the
volume/dataset. For example, even if the
root
user is able to connect, it will not gain
root
access to the
share.

C'est ce que j'ai compris, mais comme je ne l'utilise pas, je ne peux pas tester, surtout que sous Windows, le NFS... :(

 

[dav57480]

Chacun de mes partages définissait ainsi qui avait accès à quoi, et comment, en fonction de l'aspect privé ou pro, enfant ou adulte.
Un friends passe à 9 ans, un walking dead, moins bien...
Photos, vidéos, films, séries, dessins animés, documentaires, échange réseau... chacun étant une partition initialement sur des disques séparés, s'étant rajoutés au fil du temps.
Maintenant, ce système qui a fait l'affaire pendant des années, n'est peut être pas adapté à un système ZFS avec un bloc où on ne se soucie plus des tailles allouées à chaque partage.
C'est peut-être l'occasion de repenser le système de partage.

pro / privé enfants / privé adultes / partage réseau sont les 4 types d'utilisations que j'ai, le privé enfant tant un accès restreint du privé adulte.

Tous les PCs sont sous Linux.

 

[durdur]

Là où ZFS apporte une grosse facilité de gestion c'est justement sur le fait que tout ce qui était restreint dans des partitions uniques difficilement redimensionnables ou restreintes sur un disque peut être transformé en dataset. Les datasets pouvant ou non être bornés en taille, taille de toute façon simplement modifiable. Ensuite les accès sont gérés en fonction des permissions utilisateurs sur ces datasets.

Peut être effectivement qu'un dataset et un partage par utilisation peuvent être plus simple à gérer du coup.