Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Bonjour, Le dimanche 25 février 2024, Hugues MORIN-TRENEULE a écrit... > Néanmoins, il me reste un espace non utilisé en fin de disque. > Quand j'aurai un moment, je rajouterai quelques giga sur / afin de ne plus > me retrouver en difficulté par manque d'espace. Je ne sais pas si c'est faisable compte tenu de l'espace qui te reste, ni si c'est pertinent d'ailleurs, mais l'utilisation de LVM permet un peu de souplesse dans la gestion de l'espace disque (quand il reste de l'espace disque à allouer). Personnellement, j'ai depuis longtemps /usr, /var/, /home et /tmp sur des volumes logiques. -- jm
Re: Stretch vers Bullseye - Probleme lors du apt full-upgrade
Bonjour Désolé pour ce retour tardif. Je vous confirme que tout est OK, mon système fonctionne normalement et je n'ai pour l'heure rencontré aucun probleme. Oui effectivement, les partitions sont complètement entremêlées et réparties sur 3 partitions. sda1 qui contient / sda2 qui contient sda5 => /boot, sda6 => swap, sda7 => /tmp, sda8 => /usr, sda9 => /var, sda10 => /opt sda3 qui contient /home Néanmoins, il me reste un espace non utilisé en fin de disque. Quand j'aurai un moment, je rajouterai quelques giga sur / afin de ne plus me retrouver en difficulté par manque d'espace. Bonne soirée Cordialement Hugues Le sam. 17 févr. 2024 à 23:47, Michel Verdier a écrit : > Le 17 février 2024 Alban Vidal a écrit : > > > Pour éviter des soucis d'espace disque à l'avenir, je pense qu'il serait > > judicieux de redimensionner un peu les partitions, en en retirant un peu > dans > > le /opt ou /home pour en mettre un peu plus sur la racine (/), 2 ou 3G > par > > exemple. > > Je pense que ce serait pas mal au passage de supprimer des > partitions. Mais comme les partition ssont assez emmêlées je crois que ça > risque d'être coton et que ce sera plus simple de tout sauvegarder et > refaire le formattage complètement. > >
Re: utilisation de nis et nfs pour un réseau de 32 postes
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
Re: utilisation de nis et nfs pour un réseau de 32 postes
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
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 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/,`.'"'"'`'
