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
Attachment:
signature.asc
Description: OpenPGP digital signature