FRsAG

frsag@frsag.org

7 participants
2575 discussions

Avis d'admin sys sur supermicro
by Aurélien 27 Sep '21

27 Sep '21

Bonjour à tous/toutes. Dans le cadre de nouveau projet, on est en train de chercher à diversifier nos fournisseurs de serveurs (historiquement, on a du Dell, du Dell et encore du Dell). On a commencé les quotes chez quelques uns (Cisco, HP, Lenovo pour ne citer qu'eux), mais on a été vachement étonnés des prix pratiqués par supermicro, sur lesquels on arrive à sortir des config 20 à 40% moins cher qu'avec Dell (et globalement, que tous). Ma question est la suivante : sachant que si c'est pas cher, c'est qu'il y a un problème, quel est-il chez Supermicro? Avez-vous un retex en terme de fiabilité sur leur produit? Sur leur service support? Le remplacement de pièces (d'ailleurs, envoie t-il un tech, où c'est à nous de gérer?) Merci d'avance pour vos retour, et bonne journée. -- Aurélien DUCLOS 06 31 94 17 95

13 17

VMWARE / Debian 10 / Problème interruptions sur cartes réseau
by Fabien H 15 Sep '21

15 Sep '21

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

9 23

KVM IP simple
by Wallace 14 Sep '21

14 Sep '21

Bonjour, Pour des besoins de dépannages de serveurs on utilise un petit boitier KVM IP simple qui marche très bien depuis plus de 10 ans : https://www.lantronix.com/products/lantronix-spider/ En gros on arrive on branche sur le réseau sur les ports du serveur et on peut prendre la main dessus. On préfère cela au clavier écran sur un chariot au datacenter. Néanmoins la gestion de la souris dedans et du mapping clavier pose problème et ce boitier n'est plus vraiment supporté. On chercher un équivalent avec les fonctionnalités suivantes - vga minimum, hdmi en option - idéalement auto alimenté par les ports usb, pas besoin de tirer un câble d'alimentation - sans dépendance sur java - sans dépendre de logiciel tiers sur le poste de travail ou en passant par un serveur. En gros ce que l'on a déjà mais à jour des dernières technologies. Merci par avance pour vos suggestions

5 8

Prise électrique pilotable
by elpablodelcasata＠netcourrier.com 14 Sep '21

14 Sep '21

Bonjour, Je cherche une prise électrique pilotable, le but est de redémarrer l'équipement connecté dessus (RAD opérateur) à distance sans rebooter toute la baie info. Soit l'équipement est rackable soit il s'agit d'une prise unique connectée en RJ45. Merci de vos conseils. Tobi

8 12

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

FRsAG