Je ne sais pas pourquoi je ne peux pas avoir la copie du mail dans la réponse. On va donc copier à la main.
>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 ;-) Oui. Ça permet d'avoir une solution centralisée de sauvegarde et d'archivage. Ça permet aussi de considérer le poste de travail comme jetable, sans aucune donnée des utilisateurs. Changer un poste de travail qui a claqué, c'est une histoire de deux fichiers à éditer côté serveur pour le boot 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 Le réseau n'est jamais écroulé. Au cul du serveur principal, il y a un switch Cisco, chaque machine étant sur un port particulier. Le goulot d'étranglement n'est pas là. >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 Aucun intérêt. Il y a des cibles qui sont des machines pour des clients avec de l'électronique embarquée et qui arrivent péniblement à 512 Mo de mémoire. On ne va pas y mettre un OS en 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. JE NE VEUX PAS DE DISQUES LOCAUX POUR TOUT UN TAS DE RAISON. Là, j'ai un seul endroit à surveiller avec les sauvegardes et archivages. Et ça évite les chouineries du type mon disque a planté et je n'ai pas de sauvegarde ou j'ai eu des alertes smartd mais j'ai oublié de te le dire. Ça évite aussi le "j'ai pas de sauvegarde parce qu'elle passe à 23h05 et que mon poste était coupé". > 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). Les deux fonctionnent avec des blocs de 1500 octets. Il y a des trames de 9000 octets sur un autre sous réseau accédant aux NAS. Et ces 1500 octets permettent de swapper à la vitesse maximale. En d'autres termes, ce n'est pas le facteur limitant et il y a même beaucoup de marge. Le facteur limitant est le serveur (pour swapper à 1 Gbps, l'occupation CPU de istgt monte à 40% d'un coeur en état D). > L’explication est juste au dessus. Ben non. > 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. Non plus. Le TPlink était parfaitement manageable. > On en revient au montage par block d’un système de fichiers via un SAN. Rien à voir. Je ne peux pas me permettre de créer et retirer à la volée des volumes racine pour les différents clients. D'autant que certains OS utilisés ne peuvent utiliser une racine en iSCSI. JB
signature.asc
Description: OpenPGP digital signature