[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: utilisation de nis et nfs pour un réseau de 32 postes



Bonjour,

Les commentaires sont dans le mail.

Pour l’architecture globale, si je comprends bien c’est :
  • Un serveur de fichiers sous un *nix contenant à la fois les boot des PC et leurs données
  • Des postes sans disque (pourquoi ?)
  • un réseau ;-)

Je ne comprends pas bien la notion de PC sans disques, depuis les tests Sun de stations sans disques écroulant tout réseau je n’en vois pas l'intérêt
J’aurais tendance à proposer ce qui est largement utilisé dans les clusters de calculs et les déploiements via réseau c’est à dire :
  • Un boot PXE pour charger l’initramfs
  • la diffusion de l’arborescence système via un Netboot
  • L’OS tourne en RAM avec un disque RAM

https://www.it-connect.fr/installation-et-configuration-dun-serveur-pxe/ : C’est la solution de Netboot Debian qui est prise en exemple mais on peut charger un vrai système. Cela impose suffisamment de RAM…

Pour ce qui est de l’architecture de l’OS sur le PC j’utiliserais un disque local et installerai toutes les données système dessus. Encore une fois, c’est bien plus sur et efficace (voir latence réseau). Du coup, la home dir de l’utilisateur doit rester locale avec un montage NFS de ses données réseau dans un sous répertoire. Comme ça les usages de l’OS dans le répertoire utilisateur ne sont pas ralentis par le montage NFS et les données restent accessibles.

Même si on reste dans le schéma de démarrer les postes avec un disque iSCSI (Boot on SAN) contenant l’OS, ce qui est écrit au dessus reste valable vis-à-vis des accès NFS.


Le 24 févr. 2024 à 23:23, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :

Basile Starynkevitch a écrit :

On 2/23/24 12:02, Erwann Le Bras wrote:

Bonjour

Peut-être faire des essais avec SSHFS? le $HOME des utilisateurs
serait monté sur chaque client au boot.

Mais je ne sais pas si c'est plus efficace que NFS.


J'aurais tendance à imaginer que c'est moins efficace que NFS, qui est
de toute façon lent (car Ethernet est beaucoup plus lent que par exemple
une liaison SATA à un disque local, même rotatif).

NFS (à l'époque lointaine où je l'avais utilisé) ne crypte pas les
données. SSHFS semble les crypter.

Autrefois (avant 2000) j'avais même utilisé des Sun4/110 dont le swap
était une partition NFS distante.

Librement


Bonsoir,

J'ai un réseau complet et hétérogène avec NIS+NFS.

Je ne comprends pas bien ce mélange NIS est une base de services comme LDAP, NFS un système de partage de fichiers.


Un gros serveur sous NetBSD et toutes les stations sont diskless et
bootent sur le réseau. Les disques sont en NFS et les swaps en iSCSI.

Si je comprends bien tu mélange sur un même réseau la 2 technologies iSCSI qui utilise le mode « block » et Ethernet qui utilise le réseau en mode caractères.
Ce n’est pa très bon. 
L’un, iSCSI, serait plus opérationnel avec des trames « Jumbo » (9000 Oc) pour minimiser le découpage des blocks. L’autre, Ethernet, fonctionne mieux avec des trames de 1500 Oc. Et il n’est pas raisonnable de mixer les 2 sur un même commutateur.
L’un, iSCSI, travaille en SAN c’est à dire directement sur un système de fichiers via réseau. L’autre, NFS, réclame un service de niveau haut fourni par un serveur (NAS).

Ça fonctionne parfaitement bien (ça rame lorsqu'il y a de toutes petites
écritures en rafale en raison du protocole réseau TCP, mais l'immense
majorité du temps, ça fonctionne bien).

L’explication est juste au dessus.


Le serveur est relié à un switch Cisco au travers de deux liens
ethernet aggrégés, le reste est en 1 Gbps classique. La qualité du
switch est primordiale. Passer d'un TPLink à un Cisco m'a changé la vie.

Vrai, il n’était pas vraiment nécessaire de passer à un switch Cisco (cher) mais c’est vrai.
Un discriminant est de choisir un commutateur managable.


Le goulot d'étranglement n'est pas le réseau, mais le système de
fichier sur les disques exportés. J'ai fait la bêtise d'utiliser FFSv2
sur lequel il n'est pas possible de mettre un cache. Lorsque j'aurai le
temps, je remplacerai cela par un ZFS+cache.

On en revient au montage par block d’un système de fichiers via un SAN.


NFS à partir de la version 4 chiffre les données (mais n'est pas
interopérable pour l'instant avec NetBSD, donc je n'ai pas testé).

Effectivement


Bien cordialement,

JB

-- 
Pierre Malard
Responsable architectures système CDS DINAMIS/THEIA Montpellier
IRD - UMR Espace-Dev - UAR CPST - IR Data-Terra
Maison de la Télédétection
500 rue Jean-François Breton
34093 Montpellier Cx 5
France

Tél : +33 626 89 22 68

   « Je n'ai jamais séparé la République des idées de justice sociale,
     sans laquelle elle n'est qu'un mot »
                                                                  Jean Jaures - 1887
   |\      _,,,---,,_
   /,`.-'`'    -.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--

Attachment: signature.asc
Description: Message signed with OpenPGP


Reply to: