FRsAG

frsag@frsag.org

4 participants
2599 discussions

Apéro Lyonnais : lundi 02 septembre 2019
by cam.lafit＠azerttyu.net 31 Aug '19

31 Aug '19

Bonjour tout le monde Pour information le prochain apéro lyonnais et ses environs se fera à : Malting-Pot 263 Grande Rue de la Guillotiere, 69007 T4 lycée Colbert métro D Sans soucis lundi 02 septembre 2019 dès 19h. Profitons de cette rentrée scolaire pour parler de nos devoirs à venir. Et toujours sur : http://www.agendadulibre.org/tags/araas https://www.meetup.com/fr-FR/Auvergne-Rhone-Alpes-Apero-Admin-Sys/ Km

1 0

[TECH] Monitoring mise à jour d'agents icinga2
by Pierrick CHOVELON 30 Aug '19

30 Aug '19

Bonjour la liste, On utilise Icinga2 pour du monitoring interne. On fait un peu de tout comme tests et ça marche très bien. On a également quelques agents d'installés sur des machines Linux ou Windows (distributed monitoring). Pour le moment nous n'avons que très peu d'agents pour se poser la question de l'update automatique de ceux-ci. Mais on va probablement en rajouter d'autres... beaucoup d'autres. D'où ma question : Quels outils utilisez-vous pour mettre à jour les agents/packages Icinga2 ? Me viennent à l'esprit Ansible, Puppet et confrères. Peut-être que vous avez préféré une solution "maison". Autant pour l'update des packages Linux ça me fait pas trop peur. Par contre, pour les agents Windows (installés par un .msi), j'ai bien peur que ce soit plus compliqué ... Plus globalement quel est votre retour d'expérience des outils d'automation ? Des trucs auxquels vous n'avez pas pensé et qui vous ont posés soucis par la suite ? D'avance merci pour vos réponses. Pierrick *Cordialement / Regards* *Cordialement / Regards* *Pierrick CHOVELON* Administrateur Systèmes *Département Infrastructure & Production* *A-SIS - 04 77 49 47 00* *pierrick.chovelon(a)a-sis.com <pierrick.chovelon(a)a-sis.com>*

1 0

Re: [FRsAG] [FRSAG] ordonnanceur de job
by Remy Dernat 29 Aug '19

29 Aug '19

Bonjour,Effectivement, je pense qu'il y a de plus en plus une confusion des genres sur ce qui signifie un "Job Scheduler" ou un "orchestrateur". D'autant qu'on a pas encore parlé des orchestrateurs de conteneurs ! D'où l'importance de bien préciser le "use case" au départ. Effectivement au vu de ton besoin, j'opterai pour rundeck. Personnellement, je fais ce qui est décrit avec du SaltStack (cron states), mais il n'y a pas l'interface Web ;)Cdlmt. -------- Message d'origine --------De : Raphael Mazelier <raph(a)futomaki.net> Date : 28/08/2019 10:24 (GMT+01:00) À : frsag(a)frsag.org Objet : Re: [FRsAG] [FRSAG] ordonnanceur de job On 28/08/2019 10:12, yk+frsag(a)64.re wrote:>>> N'y a t-il pas un 'must have' sur le marché dans l'ordonnancement ? Un>> Veeam de l'orchestration ?>> Comment sont géré les jobs d'administration sur des parcs de 100-1000>> serveurs ou plus ?> Les plus connus des logiciels de « configuration management » sont> Ansible et Puppet. Je ne suis cependant pas la bonne personne pour te> dire s'ils conviennent à ton cahier des charges.Je pense qu'on mélange un peu tout.Configuration management et Orchestration de job.Si ton besoin c'est d'avoir un "cron" distribué avec interface je regarderais dans l'ordre : rundeck, stackstorm, airflow.--Raphael Mazelier_______________________________________________Liste de diffusion du FRsAGhttp://www.frsag.org/

4 3

[JOB] Recherche sysadmin Linux sur Grenoble (CDI)
by Jean Weisbuch 28 Aug '19

28 Aug '19

Bonjour, Je me permet de re-poster la même annonce qu'il y a quelques mois, l'un des membres de l'équipe nous quittant bientôt pour l'étranger. Nous recherchons actuellement un(e) administrateur(trice) système Linux en CDI sur Grenoble pour accompagner la croissance de notre pole hébergement web mutualisé (~15 personnes). PHPNET est spécialisée dans l'hébergement web depuis 2002, située à Grenoble et fait partie du groupe Magic Online qui regroupe également les hébergeurs Magic Online, Nuxit et Netissime. La principale mission du poste sera d'assurer (avec le reste de l'équipe dont je fais partie) la maintenance, la supervision et l'évolution de l'infrastructure système de nos plateformes d’hébergements mutualisés, semi-mutualisés et VPS. Périmètre précis du poste ainsi que sa rémunération a définir en fonction du profil (débutant accepté), possibilité de faire des astreintes rémunérées, poste sur 35h. Compétences techniques indispensables : Administration système Linux, exploitation de Apache HTTPD et MariaDB/MySQL. Environnement technique très varié, les principales "technos" utilisées (pas nécessaire de toutes les maîtriser) : - Principalement Debian mais également CentOS (OpenVZ) - Apache HTTPD, HAProxy et nginx - PHP/CGI et FPM - MariaDB - Scripting et développement principalement en PHP, mksh, Perl et Python - Ansible, monitoring Zabbix et Sensu - NFS via NetAPP - Conteneurs OpenVZ, LXC et virtualisation VMWare (vSphere) - Postfix, Dovecot, Exim, qmail et SpamAssassin Il faut postuler directement a recrutement(a)phpnet.org <mailto:recrutement@phpnet.org>, vous pouvez par contre me contacter directement si vous voulez plus de détails sur le poste ou l'entreprise.

1 0

Re: [FRsAG] [FRSAG] ordonnanceur de job
by yk+frsag＠64.re 28 Aug '19

28 Aug '19

On Wed, 28 Aug 2019 09:44:02 +0200 Valentin LAGUERRE - Société Serinya Telecom <valentin.laguerre(a)serinyatelecom.fr> wrote: > @yk+frsag@64.re > SGE est plutôt basé sur les jobs pour les clusters de calcul non ? Oui, très clairement. > N'y a t-il pas un 'must have' sur le marché dans l'ordonnancement ? Un > Veeam de l'orchestration ? > Comment sont géré les jobs d'administration sur des parcs de 100-1000 > serveurs ou plus ? Les plus connus des logiciels de « configuration management » sont Ansible et Puppet. Je ne suis cependant pas la bonne personne pour te dire s'ils conviennent à ton cahier des charges.

2 1

[BIZ] Recherche de contacts commerciaux pour fourniture de châssis supermicro
by Benoit SERRA 28 Aug '19

28 Aug '19

Bonjour, Ma société cherche à acheter du matériel blade supermicro. On s'est fixé sur le matériel suivant : * deux châssis SuperMicro MBE-314E-420 avec chacun : * 2 switchs MBM-XEM-002 avec 2 GBic 10Gbps SR dans chaque switch * 4 alimentations * 1 carte d’administration * 5 lames MBI-6128R-T2X chacune équipée de : * 2 SSD de 900 Go * 8 barrettes de 32 Go * 2 CPU Intel Xeon E5-2620v4N'étant pas experts de la solution, on aura aussi besoin d'une prestation pour configurer le matériel et nous fournir les procédures d'exploitation des châssis. Connaissez vous des entreprises apte à fournir ce matériel et venir nous l'installer et nous faire un transfert de compétence dessus ? Avez-vous des retours d'expérience à me faire sur l'utilisation de ces matériels par rapport à des châssis HPe C7000 et les lames équivalentes ? En terme de puissance, de tolérance aux pannes, etc etc. Merci pour vos réponses.

1 0

[FRSAG] ordonnanceur de job
by Valentin LAGUERRE 27 Aug '19

27 Aug '19

Hello tout le monde, J'aimerais connaître vos avis sur les différents ordonnanceurs sur le marché ou job scheduler que vous avez déjà utilisé (Dans le monde UNIX de préférence ) ? Ça sera l'occasion de partager nos expériences sur ce type de logiciel. Le but étant de me faire une idée afin d'avoir un ordonnanceur qui puisse me permettre de lancer des jobs sur une grande quantité de serveurs, d'avoir le code retour des jobs, d'avoir un historique, etc.. Merci d'avance pour vos retours, Cordialement, Valentin.

2 1

Sauvegarde fiable pour Proxmox KVM
by SIMANCAS Hugo 26 Aug '19

26 Aug '19

16 21

Re: [FRsAG] Sauvegarde fiable pour Proxmox KVM
by Sebastien Caps 26 Aug '19

26 Aug '19

-------- Message original -------- Objet: Re: [FRsAG] Sauvegarde fiable pour Proxmox KVM Date: 26-08-2019 09:40 De: Sebastien Caps <s.caps(a)dsx-networks.com> À: Nicolas Girardi <n.girardi(a)gmail.com> Bonjour, La restauration au niveau fichier avec Veeam est bien disponible pour Linux. Il faut ajouter les codes d'accès/clé à la machine et il fait le job. Sébastien Le 25-08-2019 11:23, Nicolas Girardi a écrit : > Bonjour, > > La restauration au niveau fichier n’est pas disponible sur Linux > sauf erreur de ma part. > > Nicolas Girardi. > > Le 25 août 2019 à 00:44, Olivier Vailleau > <olivier.vailleau(a)gmail.com> a écrit : > >> En fait, Veeam sait backuper directement auprès du stockage, pour >> peu que ce soit un système qu'il connaisse (par exemple, les >> grandes marques de baies de disque comme 3par, Netapp, etc.) >> Il déclenche un snap sur l'hyperviseur. Celui-ci déclenche un vss >> sur la vm (windows). Dès que le snap hyperviseur est réalisé, il >> déclenche un snap sur le stockage puis relâche immédiatement le >> snap hyperviseur (moins de delta à rattraper pour l'hyperviseur). >> Il aura ensuite tout le temps d'aspirer les données depuis le >> stockage, sans surcharger l'hyperviseur. C'est quand m^me assez >> efficace, mais il faut être dans la bonne combo >> Edition_veeam_entreprise_plus et matériel connu. >> >> Veeam sait effectivement parcourir un backup et te récupérer un >> fichier, ou même un objet SQL, AD, Exchange. Ca, c'est fort. En >> revanche, il ne sait pas restaurer tous les *.txt de ta vm...(ou >> j'ai pas trouvé) >> >> Je te l'accorde, il peut être lent, mais je crois que c'est surtout >> lié au transfert scp (fastSCP) avec vmware. Sinon, il sait te faire >> un instant-recovery : il monte ton backup directement en NFS et te >> relance la vm très vite (sur un lien un peu mou, mais globalement, >> ca marche). >> Il permet ensuite d'autre trucs assez sympa comme le Sure-backup : >> il peut remonter dans un env. isolé un jeu de vm, les démarrer et >> attendre qu'un http réponde, ou qu'un AD ou sql soit up. Il fait ca >> automatiquement et te prévient si un truc a merdé. C'est bien pour >> être sûr que tes backups tournent. Je ne connais pas de concurrent >> à cette fonction. >> >> Veeam sait aussi envoyer les backups sur bande et gère de façon >> rudimentaire les pools de bande et la rétention GFS. c'est assez >> minimaliste (par exemple, pas de catalogue des guest files quand >> c'est sur bande) mais ca permet au moins de sortir sur LTO tes >> données et de faire plaisir à ton DSI qui ne jure que par la >> bande. >> >> Il lui manque la possibilité d'aller causer avec un kvm/qemu/PVE >> pour chercher les snaps et les backuper.. Je pense que si Veeam fait >> cela un jour, le paysage de la virtu changera dans pas mal >> d'entreprises ! >> Bonne journée aussi ! >> >> Le sam. 24 août 2019 à 18:10, Florent CARRÉ <colundrum(a)gmail.com> >> a écrit : >> >> Hello la liste, >> >> Bon, j'ai beau ne pas utiliser Proxmox (pour l'absence de Xen), il a >> l'avantage d'avoir un Ceph de disponible ... >> Pourquoi ne pas faire du Ceph on Ceph via diff ? >> https://archive.fosdem.org/2018/schedule/event/backup_ceph_at_scale/ >> [2] >> >> Sinon, j'ai vu l'existence de backy2 qui a l'air intéressant et >> supporte également Ceph : https://github.com/wamdam/backy2 [3] >> >> /! Risque de troll >> >> Le jour qu'on aura un Veeam supportant Ceph, je pense qu'il >> méritera pleinement son prix ... >> >> Pourquoi au niveau de Ceph (ou autre stockage) et non de >> l'hyperviseur ? >> >> Je trouve stupide qu'on s'enferme sur une surcouche comme Proxmox, >> XCP ... Il faut que le backup puisse se faire directement sur le >> système de stockage >> >> (rappel : je n'utilise pas Proxmox) >> Si demain, je veux par exemple bouger de Proxmox pour un setup pur >> et dur en Debian ou oVirt ou Red Hat Virtualization, je peux garder >> toutes les vms stockées sur le Ceph, le plus long sera de remettre >> la conf des vms avec les disques ... mais on ne les touche pas >> >> Ensuite l'autre point, c'est le fonctionnement des backups de Veeam >> ? >> Je ne me suis jamais penché entièrement sur le sujet mais je pense >> que le snapshot au niveau du stockage sera toujours bien plus >> efficient. Après, oui on aura toujours des FD open/busy voir même >> qui ont disparus dans les vm/LXC mais ça fait parti du block qui >> est backupé >> >> La seule chose qui manquera c'est la puissance de Veeam pour >> explorer les fichiers dans les différents backups et encore parfois >> il peut être très lent (surtout quand on a un poste de travail qui >> est un laptop a bout de souffle et sous Windows) >> >> Je ne vois l'intérêt de Veeam seulement sur sa facilité >> d'extraction de fichiers bien précis des backups, ríen de plus... >> Je ne trouve pas que ce soit une solution miracle >> >> Pourquoi devrait-on être dépendant de la surcouche de >> virtualisation ? >> >> Bonne journée >> >> On Sat, Aug 24, 2019, 10:09 Olivier Raulin >> <olivier(a)olivier-raulin.fr> wrote: >> >> Bonjour, >> >> Proxmox dispose d'un mode de backup des VM/CT intégré, qui >> produit une image brute de la VM et compressée de la machine. Il >> utilise les outils Qemu pour sauvegarder les VM >> >> Cela marche bien, ça peut se pousser automatiquement dans un >> dossier, un repo NFS, etc. et ça gère un historique paramétrable >> (combien de backups on conserve dans ce dossier) >> En plus ça se configure très simplement dans l'interface, avec >> une planification que l'on choisit pour chaque machine. >> >> Je dirais que c'est plutôt simple à prendre en main, et efficace >> en cas de gros incident (un HV HS, par exemple), mais cela n'a pas >> la souplesse ni la légèreté d'une backup fine au niveau >> applicatif (j'estime que dans pas mal de scénarios il faut mixer >> ces 2 méthodes) >> >> Par ailleurs, si on veut aller plus loin il est tout à fait >> possible, en fonction du stockage que l'on choisit (LVM, ZFS, etc.) >> d'effectuer des snapshots réguliers et de gérer soi-même ces >> snapshots. >> Cela ne se passera par contre pas via l'interface web, mais >> derrière Proxmox c'est une Debian, il n'y a pas de limitation >> particulière pour définir ses propres process. >> >> Je ne suis pas familier de solutions comme VEEAM, je ne saurais >> donc pas comparer les deux. >> >> Proxmox propose des offres de support pour entreprise, mais je ne >> connais pas le périmètre concerné. >> >> On 22/08/2019 16:31, SIMANCAS Hugo wrote: >> >> Bonjour, >> >> Avez-vous du Prodmox/KVM en prod ? Qu’utilisez-vous en sauvegarde >> fiable (avec support entreprise comme VEEAM) >> >> Merci d’avance >> >> Cordialement, Regards, >> >> HUGO SIMANCAS >> >> Directeur Technique Associé >> >> https://www.data-expertise.com/ [4] >> >> Support technique : 09 78 23 20 29 >> Standard : 05 34 26 02 46 | LIGNE DIRECTE : 05 34 26 50 57 | MOBILE >> : 06 95 44 29 64 >> >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ [1] >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ [1] > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ [1] > >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ [1] > > > Links: > ------ > [1] http://www.frsag.org/ > [2] > https://archive.fosdem.org/2018/schedule/event/backup_ceph_at_scale/ > [3] https://github.com/wamdam/backy2 > [4] https://www.data-expertise.com/ > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/

1 0

RAID 1 - md1: 70Mo/s - md2: 220Mo/s - ???
by Frederic Dumas 22 Aug '19

22 Aug '19

Bonjour à tous, Peut-être d'autres ont rencontré ce phénomène sur des grappes en RAID1 logiciel (mdadm) sous Linux et pourront me conseiller. Deux grappes constituées d'un SSD (/dev/sdb) sur un contrôleur et de deux HDD (/dev/sda et /dev/sdd) sur un autre contrôleur: > /dev/md1: > Version : 1.2 > Creation Time : Sat Aug 17 20:43:32 2019 > Raid Level : raid1 > Array Size : 585922560 (558.78 GiB 599.98 GB) > Used Dev Size : 585922560 (558.78 GiB 599.98 GB) > Raid Devices : 2 > Total Devices : 2 > Persistence : Superblock is persistent > > Intent Bitmap : Internal > > Update Time : Mon Aug 19 11:17:20 2019 > State : clean Active Devices : 2 > Working Devices : 2 > Failed Devices : 0 > Spare Devices : 0 > > Consistency Policy : bitmap > > Name : <sanitized>:1 (local to host <sanitized>) > UUID : <sanitized> > Events : 20538 > > Number Major Minor RaidDevice State > 0 8 2 0 active sync /dev/sda2 > 1 8 17 1 active sync /dev/sdb1 > /dev/md2: > Version : 1.2 > Creation Time : Sat Aug 17 20:43:50 2019 > Raid Level : raid1 > Array Size : 585922560 (558.78 GiB 599.98 GB) > Used Dev Size : 585922560 (558.78 GiB 599.98 GB) > Raid Devices : 2 > Total Devices : 2 > Persistence : Superblock is persistent > > Intent Bitmap : Internal > > Update Time : Mon Aug 19 11:17:20 2019 > State : clean Active Devices : 2 > Working Devices : 2 > Failed Devices : 0 > Spare Devices : 0 > > Consistency Policy : bitmap > > Name : <sanitized>:2 (local to host <sanitized>) > UUID : <sanitized> > Events : 12267 > > Number Major Minor RaidDevice State > 0 8 18 0 active sync /dev/sdb2 > 1 8 50 1 active sync /dev/sdd2 L'option --write-mostly n'est pas utilisée. Elle permet de prioriser les accès en lecture sur le SSD. Mais les grappes ont été construites sans cette option. hdparm est le seul outil que je connaisse pour faire un test de débit en lecture sur une grappe en particulier, quelque soit le système de fichiers au-dessus. Voilà l'étrange résultat que hdparm renvoie: > # hdparm -t /dev/md1 /dev/md2 > > /dev/md1: (HDD + SSD) > Timing buffered disk reads: 216 MB in 3.03 seconds = 71.38 MB/sec > > /dev/md2: (SSD + HDD) > Timing buffered disk reads: 672 MB in 3.00 seconds = 223.80 MB/sec /dev/md2 offre le taux de transfert plus ou moins attendu d'un SSD sur un lien SATA bridé à 300Mo/s. Par contre, le résultat de /dev/md1 semble démontrer que la lecture se fait exclusivement sur le HDD, ignorant totalement le SSD. C'est une situation à la fois curieuse et problématique. Comment expliquer ce phénomène ? Le seul début de piste auquel je peux penser, c'est que l'ordre d'assemblage des grappes n'a pas été le même pour md1 et md2: /dev/md1 est composée de HDD1 + SDD /dev/md2 est composée de SDD + HDD2 Quelqu'un a-t-il jamais entendu dire que l'ordre d'assemblage des disques dans la grappe pourrait-il avoir une conséquence sur la priorité de lecture depuis l'un ou l'autre périphérique ? D'autres outils de benchmark plus sophistiqués (bonnie++, iozone3...) écrivant dans le système de fichiers pour faire leurs tests de performance. Comme des volumes logiques LVM sont intercalés entre le système de fichiers et les grappes RAID, je n'ai pas de moyen de restreindre ces tests à l'une ou l'autre grappe sous-jacente. Évidemment, sans confirmation par un autre outil de bench, on ne peut pas exclure complètement que hdparm renvoie des résultats faussés, pour un raison obscure. Mais les valeurs affichées sont quand même signe d'un truc bizarre. J'espère trouver sur la liste quelques indices permettant de comprendre et corriger ce "dysfonctionnement". Merci. -- Frédéric Dumas f.dumas(a)ellis.siteparc.fr

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

FRsAG