September 2021 - FRsAG

Don de matériels
by Guillaume Bourbon 14 Sep '21

14 Sep '21

Bonjour, On se sépare de 2 machines qui traînent chez nous : - 1 Dell PowerEdge SC 1425 (No Disk - SATA) - 1 Dell PowerEdge 2850 (No Disk - SCSI) En terme de CPU/RAM, je sais pas ce qu'il y a dedans mais les machines démarrent. On préfère les donner à une école/asso mais toute personne est la bienvenue. Pour plus d'info contact en mp Bonne journée :) -- Guillaume

4 7

Recherche prestataire expert en bases de données
by David Durieux 11 Sep '21

11 Sep '21

Bonjour à tous, Je suis à la recherche d'un prestataire qui serait expert en bases de données pour du N2 & N3. Les bases de données sont : * MySQL * Oracle * Postgresql * SQLServer * autres (4D, filemaker...) Le but c'est d'être pro-actif et réactif. Il faudra s'interfacer avec l'outil de supervision en place (il va être changé, possible que ça soit Zabbix, mais pas encore sûr). Cela concerne l'administration de ces bases de données, le maintient en conditions opérationnel, le support... le truc habituel en somme Je n'ai pas le volume exact, mais les bases de données sont utilisées par environ 350 serveurs applicatifs. Si vous avez ça dans votre chapeau ;) En vous remerciant. Cordialement, David Durieux

6 8

Reassign licence sur des switchs Cisco
by Antoine THOMASSIN 10 Sep '21

10 Sep '21

Hello la liste, Je suis à la recherche urgente d'un moyen de réassigner des licences Cisco. J'ai un Cisco 9132T qui est arrivé avec 24 ports licenciés mais pas les bons : Cisco a nous confirmé que par default le switch 9132T arrivent avec la License attribué sur les ports 17-32 ( 16 ports ) Pour arriver aux 24 ports commandé ils ont ajouté une License supplémentaire de 8 port (en particulier port de 1 à 8). Mais j'ai absolument besoin des ports 9 à 16, savez-vous comment reaffecter les licences des ports 25 à 32 sur les ports 9 à 16 ? Merci d'avance

1 0

Re: [FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau
by Fabien H 10 Sep '21

10 Sep '21

Donc j'ai regardé avec htop, très intéressant, au niveau irq, je n'ai vu que des soft-irq et sur 2 CPU (#4 et #5) : je ne sais pas pourquoi ces CPU, je ne vois pas dans /proc/interrupts ce qui pourrait expliquer cela.. > 10 septembre 2021 12:21 "Fabien H" <frnog.fabien(a)gmail.com> a écrit: > > > D'accord je vais jeter un oeil à cela merci. > > > > irqbalance est bien installé, d'ailleurs je vois remonter les process > ksoftirqd/2 et ksoftirqd/3 > > lors des fortes charges. > > > > J'ai lu dans la littérature que de toute façon, les interrupt d'une > carte réseau ne seraient pas > > réparties par irqbalance mais seraient justement tout le temps traité > par le même CPU virtuel pour > > des raisons de performance..? > > Je ne sais pas si il y a un comportement spécifique sur du virtuel mais > avec un OS sur un hôte physique il est important que les IRQ soit réparties > sur l'ensemble des cœurs sinon on fini par perdre des connexions car un > cœur sature en passant son temps a gérer les interruptions alors que les > autre se tournent les pouces. > > Le tunning nginx (si je ne me trompe pas) est bon ? Par exemple > worker_rlimit_nofile, worker_connections ou bien worker_processes, > worker_cpu_affinity. Logiquement vous avez gardé la même conf je suppose > > Par contre le tuning de la stack réseau n'a peut etre pas été reporté sur > le nouvel OS ? (somaxconn, ip_local_port_range, et si il y a aussi du tcp > tcp_fin_timeout..) ? > > > > > Le ven. 10 sept. 2021 à 12:16, Guillaume Vassal <guillaume(a)vass.al> a > écrit : > > > >> Bonjour, > >> > >> J'ai eu ce genre problème sur de la machine physique qui encaisse > vraiment beaucoup de trafic, mais > >> ça doit être valable sur du virtuel. > >> > >> Dans un premier temps, pour voir si les IRQ sont mal réparties sur les > différents cœurs sans se > >> prendre la tête tu peux utiliser simplement htop > F2 > Display Options > > [x] Detailed CPU time > >> (.....) > >> > >> De visu si tout s'empile sur seulement sur certains cœur c'est qu'il y > a surement un problème de > >> répartition. > >> > >> Une piste peut être de vérifier que le service irqbalnce est bien > installé et démarré. Il fait le > >> café tout seul en théorie > >>> systemctl status irqbalance.service > >> > >> Cdt, > >> -- > >> Guillaume Vassal > >> > >> 10 septembre 2021 11:55 "Fabien H" <frnog.fabien(a)gmail.com> a écrit: > >>> Bonjour, > >>> > >>> je vais essayer de vous expliquer le problème que nous rencontrons en > essayant d’être concis :Nous > >>> avons utilisé pendant des années sur 2 VM un applicatif open source > très connu qui fonctionne > >>> massivement en multi-threadé, en quasi temps réel, et en gateway UDP > avec mal un trafic UDP qui va > >>> en augmentant selon la charge (les plus perspicaces devineront !) : > >>> > >>> - ESXI : 6.5.0 update 3 > >>> - OS invité : Debian 8 > >>> - Interfaces réseau : E1000 > >>> - 8 vCPU / 16 Go RAM > >>> > >>> Cela a fonctionné très bien même en cas de montée en charge assez > importante. Le load average > >>> depasse rarement 0,8 et très stable dans le temps. Pourtant nous > étions bien conscients que les > >>> conditions n’étaient pas optimales sur la type de carte E1000 > utilisées. > >>> > >>> Récemment, nous avons déployé 2 nouvelles VM avec le même applicatif > mais en version plus récente > >>> et sur un OS plus récent : > >>> - ESXI 6.5.0 update 3 > >>> - OS invité : Debian 10 > >>> - Interface réseau : VMXNET3 (driver integré au noyau 4.19.0-16) > >>> - 8 vCPU / 16 Go RAM > >>> - VMWARE Tools installé > >>> > >>> Nous avons constaté assez rapidement des problèmes de montée en > charge, avec une charge moderée, le > >>> load average est quasi à 0,00. Lors d’une montée en charge en journée, > le load est plutôt en > >>> moyenne sur 2 ou 3, et lors de certains pics de charge part à 4 ou 6, > puis retombe à 2-3. Lorsque > >>> la charge retombe. > >>> Je constate que le load average s’envole surtout quand le si est non > nul sur les 2 CPU qui gèrent > >>> les interruptions des 2 cartes réseau IN et OUT : > >>> > >>> %Cpu2 : 1.5 us, 1.1 sy, 0.0 ni, 96.6 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st > >>> %Cpu3 : 1.1 us, 1.1 sy, 0.0 ni, 97.4 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st > >>> > >>> 16: 0 0 529091347 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 16-fasteoi ens34, > vmwgfx > >>> 17: 0 0 0 453037316 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 17-fasteoi ens35 > >>> > >>> J’en déduit que la charge augmente à cause d’un problème > d’interruptions. Pourtant la charge de > >>> trafic UDP n’est pas énorme, surtout par rapport à l’ancienne > installation sur Debian 8 + > >>> E1000.Nous avons essayé le CPU Pinning => Pas vraiment d’amélioration. > >>> Nous avons essayé de revenir à E1000 => Amélioration en charge basse > mais pas d'amélioration en > >>> charge elevée > >>> > >>> Mes questions : > >>> > >>> - Avez-vous déjà rencontré ce genre de comportements sur le réseau et > les interruption sur Vmware + > >>> Linux Debian ? > >>> - Comment être sur que le load average vient bien des interruptions ? > Faut-il mesurer un nombre > >>> d’interruptions / seconde pour confirmer ? > >>> - Avez-vous des idées pour faire un bench de VM vierge sur du trafic > UDP ? iperf par exemple entre > >>> 2 VM ? > >>> -Avez-vous des idées sur la possible résolution du problème indiqué ? > (j’ai pensé testé en noyau > >>> 5.X mais sans conviction) > >>> > >>> Merci pour votre aide, > >>> Fabien >

1 0

VMWARE / workspaceone / service wns déconnecté
by Rémy ANGEL 10 Sep '21

10 Sep '21

Bonjour la liste . Nous utilisons ws1 pour enroller et déployer nos machines et depuis plusieurs semaines on se retrouve à devoir attendre jusqu'à plusieurs jours ! Pour que nos applications descendent sur nos postes Windows . Aucun problème sur les mac. Le problème est lié au service wns qui remonte comme déconnecté dans la console. Je n'ai pas encore trouve pourquoi d'un coup il passait en connecté. Pour isoler un problème réseau nous avons essayé depuis plusieurs network avec et sans filtrage etc... Le problème semble être connu chez VMware d'aprzq des forums mais les solutions proposées ne fonctionne pas . Ou du moins pas chez nous. Après ouverture d'un ticket chez vmware et analyse des log rien d'anormal. Quelqu'un serait il dans le même cas que nous ? Merci Rémy.

1 0

Re: [FRsAG] VMWARE / Debian 10 / Problème interruptions sur cartes réseau
by Fabien H 10 Sep '21

10 Sep '21

D'accord je vais jeter un oeil à cela merci. irqbalance est bien installé, d'ailleurs je vois remonter les process ksoftirqd/2 et ksoftirqd/3 lors des fortes charges. J'ai lu dans la littérature que de toute façon, les interrupt d'une carte réseau ne seraient pas réparties par irqbalance mais seraient justement tout le temps traité par le même CPU virtuel pour des raisons de performance..? Le ven. 10 sept. 2021 à 12:16, Guillaume Vassal <guillaume(a)vass.al> a écrit : > Bonjour, > > J'ai eu ce genre problème sur de la machine physique qui encaisse vraiment > beaucoup de trafic, mais ça doit être valable sur du virtuel. > > Dans un premier temps, pour voir si les IRQ sont mal réparties sur les > différents cœurs sans se prendre la tête tu peux utiliser simplement htop > > F2 > Display Options > [x] Detailed CPU time (.....) > > De visu si tout s'empile sur seulement sur certains cœur c'est qu'il y a > surement un problème de répartition. > > Une piste peut être de vérifier que le service irqbalnce est bien installé > et démarré. Il fait le café tout seul en théorie > > systemctl status irqbalance.service > > Cdt, > -- > Guillaume Vassal > > > 10 septembre 2021 11:55 "Fabien H" <frnog.fabien(a)gmail.com > <frnog.fabien@gmail.com?to=%22Fabien%20H%22%20%3Cfrnog.fabien@gmail.com%3E>> > a écrit: > > Bonjour, > > je vais essayer de vous expliquer le problème que nous rencontrons en > essayant d’être concis : > Nous avons utilisé pendant des années sur 2 VM un applicatif open source > très connu qui fonctionne massivement en multi-threadé, en quasi temps > réel, et en gateway UDP avec mal un trafic UDP qui va en augmentant selon > la charge (les plus perspicaces devineront !) : > - ESXI : 6.5.0 update 3 > - OS invité : Debian 8 > - Interfaces réseau : E1000 > - 8 vCPU / 16 Go RAM > > Cela a fonctionné très bien même en cas de montée en charge assez > importante. Le load average depasse rarement 0,8 et très stable dans le > temps. Pourtant nous étions bien conscients que les conditions n’étaient > pas optimales sur la type de carte E1000 utilisées. > > Récemment, nous avons déployé 2 nouvelles VM avec le même applicatif mais > en version plus récente et sur un OS plus récent : > - ESXI 6.5.0 update 3 > - OS invité : Debian 10 > - Interface réseau : VMXNET3 (driver integré au noyau 4.19.0-16) > - 8 vCPU / 16 Go RAM > - VMWARE Tools installé > > > Nous avons constaté assez rapidement des problèmes de montée en charge, > avec une charge moderée, le load average est quasi à 0,00. Lors d’une > montée en charge en journée, le load est plutôt en moyenne sur 2 ou 3, et > lors de certains pics de charge part à 4 ou 6, puis retombe à 2-3. Lorsque > la charge retombe. > Je constate que le load average s’envole surtout quand le si est non nul > sur les 2 CPU qui gèrent les interruptions des 2 cartes réseau IN et OUT : > > %Cpu2 : 1.5 us, 1.1 sy, 0.0 ni, 96.6 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st > %Cpu3 : 1.1 us, 1.1 sy, 0.0 ni, 97.4 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st > > 16: 0 0 529091347 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 16-fasteoi ens34, > vmwgfx > 17: 0 0 0 453037316 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 17-fasteoi ens35 > > > J’en déduit que la charge augmente à cause d’un problème d’interruptions. > Pourtant la charge de trafic UDP n’est pas énorme, surtout par rapport à > l’ancienne installation sur Debian 8 + E1000. > Nous avons essayé le CPU Pinning => Pas vraiment d’amélioration. > Nous avons essayé de revenir à E1000 => Amélioration en charge basse mais > pas d'amélioration en charge elevée > Mes questions : > > - Avez-vous déjà rencontré ce genre de comportements sur le réseau et les > interruption sur Vmware + Linux Debian ? > - Comment être sur que le load average vient bien des interruptions ? > Faut-il mesurer un nombre d’interruptions / seconde pour confirmer ? > - Avez-vous des idées pour faire un bench de VM vierge sur du trafic UDP ? > iperf par exemple entre 2 VM ? > -Avez-vous des idées sur la possible résolution du problème indiqué ? > (j’ai pensé testé en noyau 5.X mais sans conviction) > > Merci pour votre aide, > Fabien > >

2 2

Recherche Expert Ms Teams
by Hugo SIMANCAS 10 Sep '21

10 Sep '21

Bonjour J'ai besoin d'un expert teams pour du paramétrage simple, un peu de débug et de la formation end user. A distance ou mieux à Toulouse. MP si intéressé. Merci Hugo / ::1 \ Hugo SIMANCAS Directeur Technique Associé https://www.data-expertise.com [https://www.data-expertise.com/] 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 !Utilisez notre plateforme visio libre & gratuite : https://conf.data-expertise.com/ [https://conf.data-expertise.com/] !Pad collaboratif libre & gratuit sécurisé https://pad.data-expertise.com/ [https://pad.data-expertise.com/] Les informations contenues dans ce courrier électronique sont confidentielles et protégées par le secret professionnel. En tout état de cause, elles ne sont destinées qu'à la personne ou entreprise dont le nom est mentionné ci-dessus. Veuillez aviser l'expéditeur de toute difficulté ou de toute erreur dans la transmission de ce document. Si vous n'êtes pas le destinataire du présent courrier, vous n'êtes pas autorisé, sous peine de poursuites à en prendre des copies, le divulguer ou le diffuser. La présence de cette note prouve également que ce message électronique a été vérifié par un logiciel anti-virus.

1 0

Apéro Lyonnais : lundi 06 septembre 2021
by cam.lafit 06 Sep '21

06 Sep '21

Bonjour tout le monde On n’arrête plus le beau temps, alors on continue à en profiter. Comme la situation n'a pas bougé, que les bars continue à être ouverts, qu'on se balade tous avec notre passe sanitaire je pense qu'on peut se voir sans trop de risque pour un apéro lyonnais et ses environs ce soir au : Malting-Pot 263 Grande Rue de la Guillotiere, 69007 soit le lundi 06 septembre 2021 dès 19h. Bien entendu on continue à faire attention à soit et aux autres et surtout on pense à son passeport sanitaire pour avoir le droit de boire et manger en bonne compagnie. Et toujours vaguement des infos sur : http://www.agendadulibre.org/tags/araas https://www.meetup.com/fr-FR/Auvergne-Rhone-Alpes-Apero-Admin-Sys/ Km

1 0