Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
stocker et rendre accessibles des données multimédia: musiques, photos, vidéos
archiver toutes sortes de documents: des textes, feuilles de calcul, présentations, des factures, des bulletins de paye, des doc administratifs en tous genres, des mails
des logiciels: images, codes sources, dépôts d'outils divers et variés
etc...
Je prévoie des services pour enregistrer et diffuser/rendre accessibles rapidement ces typologies de doc:
accès réseau NFS (j'ai que du linux à la maison), peut-être du samba pour des invités 
un kodi raccordé à la TV/ampli en HDMI: films, photo
un lecteur audio réseau: Raspberry/DAC "motorisé" avec moode audio raccordé à la chaîne Hi-fi, qui lit des fichiers FLAC sur le NAS (NFS devrait convenir)
des services web de plusieurs natures: Wiki, Nexcloud, Shaarli, SGBD, outils de sauvegarde, etc..
une forge genre Gitea
...
... et plus généralement tout service qui a du sens à être mutualisé/partagé/centralisé sur un serveur...
Je vais tenter chaque fois de définir ces services de façon virtualisée, de sorte qu'ils ne soient pas dépendants du socle logiciel de base afin d'éviter des conflits potentiels entre les services (version d'outils ou de librairies incompatibles par exemple).
Donc ajout d'outils de virtualisations: Machines virtuelles avec KVM et LXC, containers Docker ou Podman. Et les services cités plus haut seront donc dans des VM ou plus souvent des containers.
Donc l'OS serait installé de base, avec le minimum d'outils pour l'adminstration et la définition des services: mdadm, kvm, nuts, lxc, podman, etc... C'est tout, plus d'autres installations prévues ensuite, seulement des update/upgrade au cours du temps. Dans mon idée, tout le reste des services va à l'intérieur de VMs et/ou containers.
Et donc j'en viens à l'objet du message: Comment organiser la mémoire de masse dans ces conditions et pour ces usages, avec 4 tiroirs/disques et des ports USB en nombre ?
L'organisation d'origine est la suivante (commande lsblk avec des disques Western Digital de 4To ):
Tel que je l'interprète:
chacun des disques est organisé en 3 partitions
sdx1 pour le swap système: pour un serveur, çà fait «un peu riche» non ? 485 Mo x 4 ?
sdx2 c'est pour accueillir l'OS dans un RAID 1 de 4.7 G (cette taille ... «ajustée» m'interdit un upgrade avec une distribution récente, plus «grasse»). A ce propos, un RAID 1 qui est du miroir m'échappe avec 4 disques: on à 4 fois la même chose, qui bouge 4 fois de façon synchronisée ?
sdx3 c'est un RAID 5 pour accueillir les données
sde est une clé USB branchée directement sur la carte mère et qui contient l'image nécessaire à l'installation (initiale ou réinstallation), clé bootable donc. Cette image démarre un serveur WEB qui permet l'installation à distance. La clé contient donc la solution obsolète, amenée à disparaître a priori, ou à recevoir autre chose...
Je pense que la conception de cette organisation est motivée par le fait que Ve-Hotech proposait des NAS avec 2, 4, 6 et 8 disques. Du coup celle-ci est commune et demeure, quel que soit le nombre de disques; seul le «niveau» du RAID dédié aux données (sdx3/md3) est construit en JBOD, RAID 1, 5, 6 ou 10 choisi par l'utilisateur et en fonction des possibilités associées au nombre de disques. Cette configuration unique simplifiait sans doute construction, maintenance et support aux clients...
A ce stade, il me semble que j'ai plusieurs options pour ma cible avec un nouvel OS:
je reconduis à l'identique: il va pas falloir que je me goure dans l'utilisation de l'installateur Debian et la construction des partitions, de leurs dimensions (en particulier sdx2 qu'il faudra augmenter), la définitions des RAID, etc... Sur papier d'abord sans doute 
Ou alors me faire un preseed bien ficelé, testé dans une VM.
Pourquoi pas, je suis sûr que çà va fonctionner. Mais je m'interroge sur l'efficacité, les performances, la longévité dans l'usage des disques de cette organisation:
à quoi sert un swap de ~ 500Mo (x 4) pour un serveur ?
est-il bien utile et performant de mettre un OS en RAID (4 fois aussi): calculer de la parité, synchroniser, etc... pour des logs, des dossiers/fichiers temporaires, etc... ? Y a-t-il plus ? En même temps, l'OS sera vraiment disponible - c'est tout l'intérêt du RAID, et le seul selon ma compréhension: la disponibilité des données reste en cas de disque(s) HS. Il devrait pouvoir démarrer à tous les coups. Depuis 2015, j'ai toujours pu atteindre mon serveur via ssh - même s'il m'est arrivé quelques pépins, mais toujours et seulement sur le RAID 5 des données.
Pourrais-je envisager de mettre l'OS et de booter la machine depuis une clé USB ? Je me dis qu'une fois que l'installation est complète, j'en fais une sauvegarde et quand (pas si...) la clé est morte, je branche la sauvegarde, je redémarre et c'est reparti sans rien faire d'autre... Et j'évite un RAID/Swap pour l'OS sur les disques durs et je prolonge un peu leur durée de vie ? Cela vous parait-il jouable/raisonnable ? Est-ce une vue de l'esprit d'y voir un gain réel ?
Dans ces conditions, peut-on réaliser une configuration pour prolonger quand même la durée de vie de la clé. Par exemple: FS ext2 (pas de journalisation) ? swap tout petit (pas de besoin) ? dossiers en ram (/tmp, ...) pour minimiser les écritures sur mémoire flash ? Config. ''fstab'' «aux petits oignons»: noatime, noctime, no<je sais pas quoi>...? C'est possible et efficace/opérationnel ce genre de chose ?
Sur le périmètre des datas, il ne me semble pas qu'il ait de sujet: RAID 5 sur les 4 disques. Sauf si vous me dites «RAID is dead» (comme dirait l'autre...). D'autres technos et/ou organisations permettent-elles la disponibilité des données de manière plus efficace dans les actions et pour la longévité des disques ?
En revanche, j'ai des interrogations pour les services et leurs localisations. En gros, où et comment est-il pertinent de définir les disques virtuels des machines ou des containers qui vont faire tourner les services ? Dans le RAID avec les datas, ça fonctionne. Mais...
Si on considère qu'une VM ou un container est construit, détruit, reconstruit dans des manip fréquentes et avec par ailleur en run un comportement d'OS, un stockage en RAID sollicite-t-il trop le mécanisme de parité et la durée de vie des disques ? Par ailleurs je me dis qu'en cas de soucis, la reconstruction d'un RAID prend des heures, voire des semaines selon la taille des disques... Du coup, dispo bof: même si sur le papier, les données restent accessibles pendant la reconstruction, çà rame tout de même sérieusement.
Pourrait-on ici se dispenser du calcul de parité d'un RAID pour ces composants-là ?
Je me demande donc s'il ne serait pas intéressant de dédier un des disques aux VM/containers (éventuellement plus petit, éventuellement un SSD). Ces services se reconstruisent assez rapidement et on sauve le mode opératoire de leur construction, pas leur contenu. Les éventuelles données que ces VM/containers manipulent ou génèrent pourraient être localisées sur le RAID des datas si besoin. Cerise sur le gâteau: on définirait ce disque avec LVM, qui nous donnerait la maitrise des tailles et extensions/réductions potentielles des espaces occupés...
Bref ! Voyez le genre de questions que je me pose...
J'espère avoir précisé correctement et clairement l'environnement et du coup je sollicite vos zavis zéclairés...
OS sur clé USB intéressant, possible, avec quelles précautions ?
Le RAID pour les data est-il toujours la bonne solution pour la disponibilité des données (perte d'un disque sans impact dans mon cas) ?
Une solution appropriée pour le stockage des VM: disque dédié, LVM, autre chose ?
Je m’apprête à redéfinir complètement mon serveur NAS. J'espère que le sujet intéressera et que des pistes vont fuser pour m'y aider 
Merci, @+
Dernière modification par Cram28 (24-09-2022 17:02:13)
Travaille du chapeau: "Je sais que vous croyez comprendre ce que vous pensez que j'ai dit, mais je ne suis pas certain que vous réalisiez que ce que vous avez entendu n'est pas exactement ce que je voulais dire..."
Hors ligne
sdx1 pour le swap système: pour un serveur, çà fait «un peu riche» non ? 485 Mo x 4 ?
Au contraire : seulement 2 Go de swap pour 16 Go de RAM, soit un ratio d'un ordre de grandeur, c'est un peu radin, limite ridicule.
Mais le plus gros problème de ce swap, c'est qu'il n'est pas en RAID donc à la merci de la défaillance d'un disque. Or un swap défaillant c'est un peu comme une portion de RAM défectueuse. Cela va totalement à l'encontre de la disponibilité du système que le RAID est censé apporter.
un RAID 1 qui est du miroir m'échappe avec 4 disques: on à 4 fois la même chose, qui bouge 4 fois de façon synchronisée ?
Exactement. Qu'est-ce qui t'échappe ? Le "gaspillage" d'espace disque ? Tu ne vas pas pleurer pour 5 Go sur 4 To ? Par rapport au RAID 5 le RAID 1 est simple (pas de calcul de parité), fiable, et assez performant en accès aléatoire (les lectures sont réparties sur tous les disques, l'écriture n'a pas besoin de lecture-modification-écriture pour mettre à jour la parité). Parfait pour le système. Le RAID 10 offrirait de meilleures performances en accès séquentiel, mais je ne suis pas sûr qu'on y gagne beaucoup.
Pourrais-je envisager de mettre l'OS et de booter la machine depuis une clé USB ?
Les clés USB ne sont pas fiables et supportent mal les écritures répétitives. D'autre part elles sont souvent bien plus lentes qu'un disque, notamment en écriture. Ce n'est pas un support idéal pour contenir un système "normal" (pas u système live avec plein de trucs en tmpfs ou zram).
Il existe des systèmes de fichiers dits "structurés en log" comme F2FS ou NILFS2 qui sont censé être plus adaptés aux clés USB et cartes SD que les systèmes de fichers traditionnels comme ext2/3/4.
Sur le périmètre des datas, il ne me semble pas qu'il ait de sujet: RAID 5 sur les 4 disques. Sauf si vous me dites «RAID is dead» (comme dirait l'autre...). D'autres technos et/ou organisations permettent-elles la disponibilité des données de manière plus efficace dans les actions et pour la longévité des disques ?
LVM a son propre RAID qui est plus souple que celui de mdadm (on peut créer des volumes logiques de différents niveaux de RAID dans un même groupe de volumes). Certains systèmes de fichiers (btrfs, ZFS) ont aussi du RAID. Mais je ne connais pas la fiabilité et la robustesse de tout ça. Il n'y a pas si longtemps, le RAID 5 de btrfs n'était pas encore considéré comme stable, j'ignore ce qu'il en est actuellement.
Une solution appropriée pour le stockage des VM: disque dédié, LVM, autre chose ?
Si tu veux découper l'espace disque en plusieurs volumes, LVM ou équivalent (ZFS) me semble incontournable.
Il vaut mieux montrer que raconter.
Hors ligne
j'avais vu qu'il n'était pas dans le RAID 1, mais comme çà allait dans le sens de «un swap sert pas beaucoup», je me disais que Ve-Hotech proposait un truc qui tient la route... Donc c'est ballot !
j'avais en effet en tête que le swap, sur un serveur, n'avait pas une grande utilité: s'il y en besoin c'est que la machine est mal dimensionnée en RAM - je t'accordes que c'est sans doute un peu court, on n'est pas à l'abri d'avoir un pic de besoin en RAM. Mais surtout que le swap servait avec l'interface graphique et la mise en veille prolongée: je suis en veille, je stocke l'environnement sur disque et je restaure au réveil... Puis-je supposer que l'hibernation concerne aussi les machines sans environnements graphiques ?
Donc OK: ça reste bon d'en avoir. Avec 16Go de RAM je prends... 4Go ? Et 20Go si hibernation active ? (https://websetnet.net/fr/how-much-swap- … -in-linux/)
RAID 1:
Meuh nan, je pleurniche pas pour le «gaspillage» 
! Juste je voyais pas, j'imaginais un miroir, et donc un disque et son image.... 
Bref, pas vu, donc OK, là mon disque est entouré de 3 miroirs (on le voit sous toutes les coutures )
Donc OS - et swap - en RAID 1 c'est bien pour le système: je vais garder çà.
OS sur clé USB::
OK, j'abandonne l'idée: cela va supposer des manip. et des config. alambiquées (ou en tous cas non standards). Ça n'en vaut pas la chandelle.
LVM:
Ah ben mince: j'en était resté à du LVM utilisé conjointement avec mdadm... Une espèce d'«empilage» LVM sur RAID logiciel!
Je m'en va donc investiguer, car si je peux faire à la fois de la dispo. pour les données et de la gestion des allocations pour les VM, avec un même outils, sur les mêmes espaces physiques...
Aurais-tu des liens / tutos que tu juges bien faits ?
Pour BTRFS, ce n'est semble-t-il toujours pas stable sur RAID 5/6: "the feature should not be used in production, only for evaluation or testing." (https://btrfs.readthedocs.io/en/latest/ … -practices).
ZFS, le fait qu'il soit un «grand bouffeur de mémoire devant l'éternel» me refroidit un peu: les dernières reco. que j'avais lues c'était je crois 1Go de RAM par To de disque. Avec en plus de la RAM ECC recommandée... Je préfère garder la RAM pour faire tourner les services. Cela dit, peut-être que ça marche très bien quand même sur des config. moins ambitieuses ? (faudrait que j'aille fouiller des retours d'expérience sur TrueNAS, qui propose aussi Debian maintenant, et OpenZFS...)
Bon, y a pu qu'à...
Encore merci pour ton éclairage.
@+
Travaille du chapeau: "Je sais que vous croyez comprendre ce que vous pensez que j'ai dit, mais je ne suis pas certain que vous réalisiez que ce que vous avez entendu n'est pas exactement ce que je voulais dire..."
Hors ligne
j'avais en effet en tête que le swap, sur un serveur, n'avait pas une grande utilité: s'il y en besoin c'est que la machine est mal dimensionnée en RAM - je t'accordes que c'est sans doute un peu court, on n'est pas à l'abri d'avoir un pic de besoin en RAM.
En effet, et ça m'est arrivé quelques fois au point que j'ai dû ajouter un fichier de swap en urgence pour ne pas faire échouer une opération plus gourmande que prévu (mais la machine n'avait pas 16 Go de RAM).
En fonctionnement normal, le swap peut servir à stocker les pages mémoire "inactives" et utiliser la mémoire disponible de façon plus efficace, par exemple comme cache pour des fichiers "actifs".
Tu peux dire que tu n'as pas besoin de swap seulement si le système n'a jamais besoin de relire des données sur disque qu'il a déjà lues ou écrites auparavant, ce qui signifierait qu'il a dû évincer ces données du cache donc qu'il n'avait pas assez de mémoire pour les conserver à un moment donné.
Mais surtout que le swap servait avec l'interface graphique et la mise en veille prolongée: je suis en veille, je stocke l'environnement sur disque et je restaure au réveil... Puis-je supposer que l'hibernation concerne aussi les machines sans environnements graphiques ?
L'hibernation n'a rien à voir avec les environnements graphiques. On peut utiliser l'hibernation avec un serveur, par exemple pour effectuer une opération qui nécessite d'interrompre l'alimentation sans arrêter le système et tout ce qui tourne dessus.
Donc OK: ça reste bon d'en avoir. Avec 16Go de RAM je prends... 4Go ? Et 20Go si hibernation active ?
Il n'y a pas de valeur magique. Ça dépend vraiment de l'usage, et pas seulement de la quantité de RAM. L'affirmation selon laquelle la taille du swap doit être au moins égale à la taille de la RAM pour l'hibernation est fausse. Une taille de swap égale à la taille de la RAM est une heuristique applicable dans le cas général, quand la taille de la RAM est cohérente avec l'usage de la machine.
j'imaginais un miroir, et donc un disque et son image
Le RAID 1 ne fait pas de réplication. Ce n'est pas un processus qui répercute le contenu d'un disque vers les autres. Les écritures sont effectuées simultanément sur tous les disques.
Ah ben mince: j'en était resté à du LVM utilisé conjointement avec mdadm... Une espèce d'«empilage» LVM sur RAID logiciel!
C'est une recette simple et éprouvée. Je n'ai jamais utilisé le RAID intégré à LVM que je n'ai mentionné que par souci d'exhaustivité. Je me dis que ça peut être intéressant si on a besoin de beaucoup de flexibilité dans les tailles et niveaux de RAID (plusieurs volumes de niveaux de RAID différents avec des tailles variables), sachant que le RAID traditionnel n'est pas très souple de ce côté.
De même je n'ai mentionné ZFS que par souci d'exhaustivité, je ne m'y suis jamais intéressé.
Dernière modification par raleur (12-09-2022 10:03:03)
Il vaut mieux montrer que raconter.
Hors ligne
Travaille du chapeau: "Je sais que vous croyez comprendre ce que vous pensez que j'ai dit, mais je ne suis pas certain que vous réalisiez que ce que vous avez entendu n'est pas exactement ce que je voulais dire..."
Hors ligne