zithro a écrit : > On 24 Feb 2024 23:23, BERTRAND Joël wrote: >> 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. > > Peux-tu expliquer ce choix (NFS vs iSCSI) stp ?
Oui, je peux ;-)
> Si je dis pas de conneries, tu pourrais boot root (/) en iSCSI.
Je pourrais. Mais j'ai un gros volume qui contient les racines de
toutes les machines. Si je voulais traiter en iSCSI, il me faudrait un
système de fichiers distribué et supporté par tous les clients. Il me
faudrait aussi des OS capables de démarrer sur un volume iSCSI.
Pour utiliser iSCSI sereinement, il me faudrait aussi un volume par
client, exporté en tant que tel. Les /home sont sur un autre volume. En
revanche, les points de montage des racines (/srv/machine) ne sont
exportables que sur la bonne machine (verrouillé dans /etc/exports, les
IP étant fournies par DHCP en fonction de l'adresse MAC du client).
> Note que je suis autant interessé par ton raisonnement (ton choix
> pratique) que par le débat NFS vs iSCSI (la théorie) !
> (Y'a pas de solutions toutes faites, le forum de FreeNAS est un bon
> exemple).
>
>> La qualité du
>> switch est primordiale. Passer d'un TPLink à un Cisco m'a changé la vie.
>
> Entièrement d'accord avec toi.
> J'en profite pour un coup de gueule, c'est le problème avec le matos
> "grand public".
> Un switch 1Gb/s "grand public" veut dire que tu auras ce débit entre
> DEUX stations ! (Comprendre entre 2 ports physiques).
> Un "vrai" switch 1Gb/s 10 ports devrait tenir au moins 5Gb/s (sans
> uplink) : deux stations à 1Gpbs, fois 5.
> J'ai découvert ce problème par la pratique, chercher "switch backplane"
> sur le net. Même certains switch soit-disant d'entreprise (SOHO) sont
> incapables de tels débits.
> (Mais YMMV comme disent les ricains).
J'ai toutefois été surpris de constater qu'un vieux switch 3Com à 24
ports mettait la pâtée à un TPlink pourtant relativement cher. Comme
j'ai été surpris de constater qu'il était assez intelligent alors qu'il
n'est pas officiellement manageable pour gérer une agrégation de lien de
niveau 2.
>> 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.
>
> AFAIK, le problème de tous réseaux c'est la latence, pas le débit.
> (Toutes proportions gardées).
> Donc améliorer les accès disque(s) n'améliorent pas forcément la
> "réactivité".
> Peux-tu éclairer ma lanterne stp ?
Le NFSv3 n'a pas de cache et travaille en TCP (j'ai essayé UDP, ce
n'est pas franchement mieux). Il est possible de monter les disques en
async, mais je déconseille (côté NetBSD, il vaut mieux ne pas utiliser
async et la journalisation en même temps). Avec l'option async, ça va
nettement plus vite, mais on risque des surprises en cas de coupure de
courant.
Quand il y a des tas de petites écritures, le goulot d'étranglement est
l'accès disque surtout en écriture (là, il vaut mieux des disques CMR
que SMR) parce que le système ne peut pas cacher efficacement ces petits
accès. On s'aperçoit que le paquet ACK met un peu plus de temps à
revenir au client. Ça suffit pour faire tomber les performances.
Sur des lectures, j'atteins sans peine 800 à 900 Mbps. Sur des écriture
de quelques gros fichiers, ça monte à 500 Mbps. Si ce sont des petits
fichiers en écriture, les performances sont ridicules. Un apt install
texlive-full prend des plombes. Attention, je n'attends ces débits
qu'avec des cartes réseau Intel. Les Realtek sont largement moins bonnes
(bon, ça reste utilisable tout de même).
À côté, iSCSI permet d'atteindre 1 Gbps sur le swap.
> PS: j'ai travaillé dans la VoIP, où j'ai -finalement- compris que
> latence et débit n'ont rien à voir. Sans même parler de jitter (la
> variation de latence en bon céfran).
Ben oui, ça n'a rien à voir. Mais le gros problème est d'avoir le
paquet ACK du TCP le plus vite possible. Et ça, ça passe par un cache
côté serveur capable d'accepter les transactions le plus rapidement
possible en résistant aux coupures de courant. C'est pour cela qu'il
faudrait que je teste un ZFS avec un cache sur un SSD sacrificiel.
Bien cordialement,
JB
signature.asc
Description: OpenPGP digital signature
