FRsAG

frsag@frsag.org

6 participants
2620 discussions

Start a nNew thread

OVH et OWA
by David Ponzone 17 Jan '24

17 Jan '24

Pour ceux qui n’ont pas vu, OVH éjecte OWA comme webmail pour les emails Mutu/MX-Plan, au profit de Zimbra. David

6 6

selinux (oui je suis en retard de 10 ans) (au moins)
by Jeremy Monnet 12 Jan '24

12 Jan '24

Salut les gens, J'ai une question selinux "un peu" avancée. D'avance je m'excuse parce que oui, j'aurais dû investir du temps dans selinux il y a bien longtemps (qu'on aime ou pas, je devrais être capable de répondre à ce genre de question...) J'ai lu de la doc, regardé des tuto, je maîtrise selinux pour apache... Mon problème c'est une appli métier dans une arborescence dédiée. Quand on active selinux en enforcing, elle ne démarre plus. ls -lZ /application drwxrwxr-x. 3 user group system_u:object_r:unlabeled_t:s0 40 Jan 11 17:56 /application/ restorecon -n -v /application/ Would relabel /application from system_u:object_r:unlabeled_t:s0 to system_u:object_r:default_t:s0 ps -eZ | grep -i appli system_u:system_r:initrc_t:s0 11943 ? 00:00:09 appli Déjà, question bête, est-ce qu'un restorecon (récursif...) suffirait à ce que l'appli démarre ? initrc_t vers default_t ? Ensuite, surtout quelle est la meilleur marche à suivre, je suppose qu'il faut a minima ajouter un contexte, genre semanage fcontext -a -t unconfined_t '/application(/.*)?' Mais dans ce cas précis si on veut faire du selinux "pour de vrai" est-ce qu'il ne faudrait pas ajouter un type dédié genre mon_appli_t ? et c'est là où je sèche complètement, que faudrait-il faire en plus sur le user, sur le process pour que ça fonctionne bien ? Merci d'avance pour toute aide :) Jérémy

2 1

[FRSAG][Tech] Mysql NDB
by Anthony Frnog 11 Jan '24

11 Jan '24

Bonjour à tous, Pour commencer, mes meilleurs vœux pour 2024. Je suis actuellement en train de maquetter un cluster Mysql NDB. De ce que j ai pu voir dans les différentes doc, il semblerait que les data et index sont stockés en RAM. (Je me trompe peut être). Le problème dans ce cas est une saturation de la RAM et de devoir ensuite upgrader le serveur afin de rajouter de la RAM. Est-ce que quelqu'un dans la liste aurait déjà travaillé sur cette techno ? Si oui, comment est il possible de ne pas utiliser la RAM pour les index et data? Merci d avance pour vos conseils/remarques Anthony

2 2

Synology Hybrid Share: des retours ?
by Jérémie Parisel 10 Jan '24

10 Jan '24

Salut la liste, Je cherche à trouver une solution plus efficiente que du VPN inter-sites pour gérer des accès à des serveurs de fichiers Synology depuis différents sites d'une association. Les besoins ne sont pas immenses (usage bureautique principalement - pas trop d'accès concurrents). Je suis tombé sur Hybrid Share qui, sur papier, présente les avantages d'une solution en ligne, tout en gardant les avantages du sur-site (cache local pour rapidité d'accès, on garde un certaine maitrise de ses données, accès résistant à un perte de connexion internet, sauvegardes locales possibles). Au prix d'une dépendance à un service proprio. Est-ce certains d'entre vous ont déjà joué avec? Quels sont vos retours ? Est-ce que ça gère bien les verrous fichiers (lock)? Est-ce qu'il gère de manière censée les situations dans lesquels un ou des sites sont isolés du cloud et continue leur popote pendant ce temps ? Est-ce qu'il traite les conflits de version? Merci d'avance de vos retours d'expérience. Bon week-end à tous, Jérémie

6 6

[BIZ] Revendeur de serveur orienté stockage NAS (TrueNAS) ?
by DUVERGIER Claude 08 Jan '24

08 Jan '24

Bonjour, Après avoir résolu mon évolution de routeur (sur FrnOG), j'ai besoin de monter un nouveau serveur de stockage local (NAS). On a déjà des serveurs de stockage, sous TrueNAS SCALE (la variante Debian), mais il nous en faudrait un nouveau. Les besoins utilisateurs sont "simples" : * Stockage de fichiers accédés en CIFS * Environ 15 utilisateurs * Quelques gros fichiers graphiques et vidéos (2/3 monteurs et graphistes qui travaillent en direct sur le réseau) Niveau matériel : * CPU : 1 seul suffira * 64 Go de RAM ECC * Capacité disques : 6 HDD LFF/3.5" pour le stockage, 2 HDD/SSD pour le système * Pas de RAID matériel (cause RAID-Z2 ZFS sur TrueNAS) * Accès IPMI/BMC/iLO/iDRAC/… * 2 ports réseau Ethernet Gigabit avec possibilité d'ajout de SFP+ * Double alimentation électrique * Les rails de montage en rack * Tous les caddy/tray/tiroirs de disque * Compatible TrueNAS (carte LSI typiquement) * **En stock** Je n'ai pas de préférence quand au fabriquant (j'ai déjà du HP et du Dell). J'avais par exemple trouvé le Supermicro SYS-620P-TRT chez un revendeur mais il n'était plus en stock le temps de vérifier quelques détails. Vu mes besoins (que je trouve modestes mais je peux me tromper), du refurbished me convient également si ça permet d'avoir accès à du stock. Donc s'il y a des revendeurs de serveurs, voire des intégrateurs TrueNAS sur la liste ou dans vos contacts, je prends ;) Et je prends aussi les conseils sur du TrueNAS utilisé pour des fichiers vidéos si vous en avez. Merci -- Duvergier Claude

4 3

Re: Recherche solution de backup adaptée à de fortes volumétries
by Denis PUGNERE 04 Jan '24

04 Jan '24

Bonjour Fabien, la liste, Petit retour d'expérience d'un labo de recherche sur EOS que Gilles a mentionné. je gère 2 instances EOS dans 2 contextes d'utilisation différents : * Stockage de données scientifique d'un laboratoire de recherche : Stockage de datasets de données de CMS (https://cms.cern) et de nos autres expériences internes, supportant à la fois les protocoles de transfert de données (XRootD and HTTPS) entre datacenters de la grille WLCG (https://wlcg.web.cern.ch/) et EGI (https://www.egi.eu/) et à la fois des accès locaux (type POSIX via FuseX) * Stockage Online des données qui sortent d'une expérience, sorte de buffer proche du détecteur, pour que les données soient calibrées / traitées / filtrées / nettoyées sur place avant d'être exportées vers les centres de calcul CERN/IN2P3/FNAL... Authentification supportée : kerberos et certificats x509 depuis longtemps, OIDC plus récemment Au niveau du stockage, c'est très versatile : sur du RAID matériel ou logiciel (pas conseillé), sur du JBOD. Tu peux aussi assurer de la redondance via des réplicas ou alors de l'erasure coding, par répertoire. par exemple /eos/stockage/cycle1/exp1/processed en réplica 2 et /eos/stockage/cycle1/exp1/raw en erasure coding. L'erasure coding prends tout son sens sur du JBOD puisque tu assures la redondance des données sur des disques différents et sur des serveurs de stockage différents avec un overhead faible. Quotas par utilisateur, par groupe, par projet (arborescence) Comme stockage distribué c'est bien pensé puisque les meta-données sont distribuées dans QuarkDB (KV store backend en haute dispo) et si tu utilises l'erasure coding avec un nb de FST (serveurs de stockage) > N+P, alors tu continues à avoir accès à tes données même si tu perds un FST. Au niveau de tes critères : * open source * scalable natif. + il y a de serveurs de stockage, mieux c'est. Au niveau du roulement des serveurs : drain du serveur à remplacer (1 commande à taper), on revient + tard quand il a fini de déplacer les n TB vers les autres serveurs de stockage, on traite les cas particuliers, on le sort de prod, on le remplace et le nouveau serveur entré en prod récupère sa part comme avec CEPH. * interfacé avec les bandes via un autre de leurs soft CTA (https://cta.web.cern.ch/cta) * Pas trop complexe / usine à gaz : un peu complexe quand même quand on veut utiliser les fonctionnalités ou modifier le comportement des sous composants, mais une fois qu'on a compris les briques de bases (Namespace MGM + persistance des meta-données dans QuarkDB + stockage des données dans les FST), le reste est de la routine de services de stockage. Au niveau des performances, aucun problème pour saturer des liens a n*10Gb/s, même pour des petits fichiers. NB : Prochain workshop EOS en mars 2024 [ https://indico.cern.ch/event/1353101/ | https://indico.cern.ch/event/1353101/ ] Cordialement Denis ----- Le 3 Jan 24, à 20:43, Gilles Mocellin <gilles.mocellin(a)nuagelibre.org> a écrit : Le mercredi 3 janvier 2024, 18:42:10 CET Fabien Sirjean a écrit : BQ_BEGIN Bonsoir la liste, En ce début d'année, je me creuse la cervelle autour des sauvegardes, alors je vous partage mes questionnements :) Petit topo du contexte : je bosse dans un centre de recherche scientifique, dont les instruments produisent pas mal de données. Ces données sorties des instruments "raw" sont ensuite traitées et transformées pour analyse (données "processed"), en vue de publier des papiers de recherche. Les données raw sont produites pendant des "cycles" de fonctionnement (3 à 4 cycles par an) et l'approche est WORM (c'est la valeur produite par l'institut, les données raw sont impossibles à reproduire). Les données processed sont produites en continu selon l'activité des scientifiques, parfois plusieurs années après la production des données raw associées. Les données processed sont recalculables à partir des données raw, mais ça peut être coûteux (temps et puissance de calcul). On a actuellement 1.3 PiB de data (raw+processed) sur notre stockage primaire. Ça tourne sur une infra Ceph en triple réplication, grosso-merdo ça fait 600 disques mécaniques de 20TB. Évidemment on est sur un scénario loin d'être idéal pour le stockage : on a principalement de très nombreux petits fichiers (<128 KB). Mais on a aussi des fichiers >1TB, sinon c'est pas drôle... Si vous voulez une idée de la tête de l'arborescence, ça ressemble à ça : https://pastebin.com/vVF31cv4 On aimerait changer de solution de backup pour ces données, au profit d'un truc qui coche au moins plusieurs de ces critères (tous, je sens que ça va être compliqué) : * Open Source * Pas trop complexe / usine à gaz * Scalable (marre de changer tout le matos tous les 4-5 ans parce que y'a plus de place...) * Qui permette de gérer indépendamment le backup des données "raw" (ça bouge pas mais on veut vraiment pas les perdre) des données "processed" (ça bouge, on peut se permettre de les perdre, on peut réduire la rétention pour les vieux cycles) * Qui fasse pas nécessairement tourner des tas de disques en permanence (les données raw pourraient très bien être sur de la bande magnétique, vu qu'elles ne bougent plus du tout une fois le cycle terminé) * Qui coûte un prix raisonnable Jusqu'ici on fait du bacula et du rsync sur ZFS (un serveur avec plein de baies JBOD en SCSI). Mais c'est plein, et il faut donc faire évoluer tout ça. Le plus simple pour nous serait probablement de continuer avec la même solution sur le plan logiciel, en passant sur un stockage distribué comme Ceph pour avoir la scalabilité souhaitée. Mais ça fait la même techno pour le stockage primaire et le backup (pas top), et Ceph n'est pas très efficient (même si on peut faire des choses en Erasure Coding). De plus, ça ne permet pas d'intégrer des bandes magnétiques dans l'équation. Voilà, n'hésitez pas à partager vos avis et expériences. Notamment je n'ai jamais bossé avec de la bande magnétique, je me questionne pas mal sur la pertinence et la facilité de gestion. Si des commerciaux passent par là : vous pouvez me contacter sur mon mail pro (sirjean(a)ill.fr) mais je suis plutôt dans une phase exploratoire (il y aura de toutes façon un appel d'offres). Merci pour vos retours, et à bientôt :) Fabien Bonjour, En restant dans le domaine de la recherche, on a évidemment le CERN qui peut être pris comme référence / inspiration. https://home.cern/science/computing/storage Ils ont du Ceph, mais à priori, pas pour les données des expériences, surement pour leur Cloud OpenStack. Leur stockage est fait maison (EOS https://eos-web.web.cern.ch/eos-web/) Et le stockage long terme, archivage est sur bande. PS: Tien, je vois que EOS a plusieurs backends de stockage à proprement dit, et qu'on y retrouve Ceph aussi, en mode RADOS direct ou CephFS... _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ BQ_END -- [ https://www.ip2i.in2p3.fr/ ] Denis PUGNÈRE Institut de Physique des 2 Infinis de Lyon Campus LyonTech la Doua, bâtiment Dirac 4 rue Enrico Fermi , 69622 Villeurbanne +33 (0) 7 89 32 12 46 [ https://twitter.com/ip2ilyon | ] [ https://facebook.com/IP2ILyon ] [ https://www.ip2i.in2p3.fr/ | https://www.ip2i.in2p3.fr ]

1 0

Recherche solution de backup adaptée à de fortes volumétries
by Fabien Sirjean 03 Jan '24

03 Jan '24

Bonsoir la liste, En ce début d'année, je me creuse la cervelle autour des sauvegardes, alors je vous partage mes questionnements :) Petit topo du contexte : je bosse dans un centre de recherche scientifique, dont les instruments produisent pas mal de données. Ces données sorties des instruments "raw" sont ensuite traitées et transformées pour analyse (données "processed"), en vue de publier des papiers de recherche. Les données raw sont produites pendant des "cycles" de fonctionnement (3 à 4 cycles par an) et l'approche est WORM (c'est la valeur produite par l'institut, les données raw sont impossibles à reproduire). Les données processed sont produites en continu selon l'activité des scientifiques, parfois plusieurs années après la production des données raw associées. Les données processed sont recalculables à partir des données raw, mais ça peut être coûteux (temps et puissance de calcul). On a actuellement 1.3 PiB de data (raw+processed) sur notre stockage primaire. Ça tourne sur une infra Ceph en triple réplication, grosso-merdo ça fait 600 disques mécaniques de 20TB. Évidemment on est sur un scénario loin d'être idéal pour le stockage : on a principalement de très nombreux petits fichiers (<128 KB). Mais on a aussi des fichiers >1TB, sinon c'est pas drôle... Si vous voulez une idée de la tête de l'arborescence, ça ressemble à ça : https://pastebin.com/vVF31cv4 On aimerait changer de solution de backup pour ces données, au profit d'un truc qui coche au moins plusieurs de ces critères (tous, je sens que ça va être compliqué) : * Open Source * Pas trop complexe / usine à gaz * Scalable (marre de changer tout le matos tous les 4-5 ans parce que y'a plus de place...) * Qui permette de gérer indépendamment le backup des données "raw" (ça bouge pas mais on veut vraiment pas les perdre) des données "processed" (ça bouge, on peut se permettre de les perdre, on peut réduire la rétention pour les vieux cycles) * Qui fasse pas nécessairement tourner des tas de disques en permanence (les données raw pourraient très bien être sur de la bande magnétique, vu qu'elles ne bougent plus du tout une fois le cycle terminé) * Qui coûte un prix raisonnable Jusqu'ici on fait du bacula et du rsync sur ZFS (un serveur avec plein de baies JBOD en SCSI). Mais c'est plein, et il faut donc faire évoluer tout ça. Le plus simple pour nous serait probablement de continuer avec la même solution sur le plan logiciel, en passant sur un stockage distribué comme Ceph pour avoir la scalabilité souhaitée. Mais ça fait la même techno pour le stockage primaire et le backup (pas top), et Ceph n'est pas très efficient (même si on peut faire des choses en Erasure Coding). De plus, ça ne permet pas d'intégrer des bandes magnétiques dans l'équation. Voilà, n'hésitez pas à partager vos avis et expériences. Notamment je n'ai jamais bossé avec de la bande magnétique, je me questionne pas mal sur la pertinence et la facilité de gestion. Si des commerciaux passent par là : vous pouvez me contacter sur mon mail pro (sirjean(a)ill.fr) mais je suis plutôt dans une phase exploratoire (il y aura de toutes façon un appel d'offres). Merci pour vos retours, et à bientôt :) Fabien

5 4

Re: Journal.....
by Stéphane Rivière 13 Dec '23

13 Dec '23

Le 08/12/2023 à 15:42, Thomas Constans via FRsAG a écrit : > Moi j'aime bien +1000 Ou les priorités fines de services actifs avant de lancer le sien, ou le restart automatique... -- Stéphane Rivière Ile d'Oléron - France

6 10

Journal.....
by David Ponzone 11 Dec '23

11 Dec '23

Dites, c’est moi, ou le remplacement de syslogd par journald est une des plus grandes pitreries de l’histoire de Linux ?

15 21

Debian 12 / ext4 data corruption
by Romain 11 Dec '23

11 Dec '23

Pour ceux qui auraient raté l'actu : - https://twitter.com/debian/status/1733559140914749547 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843 Ne pas installer le paquet 6.1.64-1 du kernel. Romain

4 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

FRsAG