Reprise du message précédent :
4k Vlan, quand tu héberges des clients et que tu automatise correctement, ça peut devenir limité...

La virtu tt simplement

Clair, y'a tout le côté "le trafic est encapsulé entre tes HV par eux et t'a pas à gérer tous tes vlans sur tes ports data de tes HV, juste un LAN (et encore, me semble que c'est routable ?).

Je découvre hein (besoin client pour dev VXLAN dans XCP-ng, car besoins sur des DC avec 800+ machines…) J'ai pas beaucoup d'XP en réseau de manière générale, et j'ai jamais eu à administrer par moi-même des trucs très complexes en terme network.

Ici mon but à moi c'est de faire joujou avec OVS et faire parler des VMs sur différents hôtes dans un même réseau segmenté (cross-server private network), sans aucune configuration de switch physique entre eux et en toute transparence au niveau de la VM (0 configuration spécifique). Donc création de tunnel avec les VXLAN, sachant que je peux utiliser GRE si je veux pas les VXLAN, sur le bridge OVS sur lequel les VMs vont se brancher.

edit : ça marche même « pool wide », par contre si c'est entre plusieurs DC, soit ta une fibre dédiée, soit faut sécuriser ça si tu passes sur Internet.

 
Solarwinds Orion.  
 
no redface.

pour plam je sais pas, mais un use case majeur de vxlan c'est EVPN, conceptuellement ça fait la même chose que VPLS (ie fournir un service ethernet basé sur un réseau IP de topologie arbitraire) mais en mieux, non seulement sur la partie niveau 2 (ARP suppression, possibilité de faire du MC-LAG...) mais aussi ça permet en plus de fournir du niveau 3 de façon efficace (Distributed IP Anycast Gateway).

Typique d'un support US, on est formidable notre produit est merveilleux, sans bug. Et si tu as un problème c'est à toi de prouver que leur produit à un problème et pas ton systèmes.

Ptin les tunnels VXLAN en mesh faut du STP/RSTP sinon tu fais des boucles (et puis en full mesh c'est passablement relou de créer la config à la main, le nombre de tunnel explose rapidement)
 
J'ai pas fini de bouffer de la doc

 
tu plaisantes, ou y'a vraiment des gens qui font ça comme ça ?

J'ai monté un PoC pour vérifier une chose : que ça pouvait bien s'intégrer dans XCP-ng (ça marche bien avec RSTP, bref l'ajout de VXLAN via l'API est faisable maintenant que je sais comment ça marche dans OVS = c'était le but initial).

Par contre, c'était mon approche « naïve »/simple pour valider le fonctionnement. J'imagine (enfin j'espère) qu'il y a des approches plus simple Utiliser flow directement pour éviter de faire un mesh « statique » ? Comment tu ferai toi pour avoir n hôtes dans le même réseau virtuel (au niveau des bridges de l'hôte comme ça c'est transparent pour les VMs).

edit : cette PoC c'est pas pour de la prod hein Mais j'suis bien curieux de connaître la « bonne façon » de faire ce genre de réseau logique via OVS

rien compris
 
Pour moi ton réseau d'hote est un réseau à plat standard et tu fais du LACP et sur les liens L3 de l'ECMP

 
je ne pourrais pas te dire comment faire avec OVS spécifiquement (je ne connais pas OVS), mais d'une façon plus générale, sur un réseau à overlay moderne il y a 2 choses :  
- un protocole de dataplane, ie un machin (souvent basé sur un réseau IP) qui encapsule les paquets quand ils entrent dans l'overlay et les décapsule à la sortie. VXLAN par exemple
- un protocole de control plane, qui a connaissance de ta topologie réseau entre les différents noeuds de ton overlay, qui calcule la (ou les) meilleures routes et provisionne les chemins (les tunnels VXLAN en l'occurence). Dans le monde du réseau le protocole à la mode pour ça c'est EVPN (qui peut fonctionner avec VXLAN d'ailleurs), avant ça il y avait VPLS, ou MPLS (qui transporte des paquets IP et pas des trames ethernet mais conceptuellement c'est presque pareil). Faire porter le control plane par les hyperviseurs (au lieu des switchs comme on fait "classiquement" ) se fait déjà.
Là si je comprends bien tu n'as pas de control plane donc en dernier recours tu as spanning tree. Après si le but était juste de valider VXLAN en lab tout va bien tant qu'on est d'accord pour dire que c'est seulement une partie de la solution et qu'à côté de ça il y aura un protocole pour faire le calcul de chemins et la signalisation.

Oui voilà donc faut un controleur pour créer les chemins à la volée en fonction des besoins

 Si t'as 5min, tu peux détailler un peu les raisons qui te font quitter scom?

Redfish @ dell, ça parle à quelqu'un https://www.dell.com/support/articl [...] sh?lang=en ?

 
Merci pour vos infos,
 
C'était un peu galère car le support de CentOS 7 n'est pas assuré. Mais ça a l'air de fonctionner (testé par la CLI Centreon avec --plugin=hardware::server::dell::openmanage::snmp::plugin --mode=hardware --verbose)
 
Pour info, voilà ce que j'ai fait (enfin au final, car j'ai pas mal tatonné):
 

 
C'est le coup des installations de paquets qui m'a mis dedans (recherche google du rpm, installations individuelles par yum). Il y en a une quarantaine, essentiellement des perl-*

merci du retour

y'a que 2 niveaux de listes ?  

double quote ou 8 espace pour un codeblock dans une liste

et maintenant la conversion via pandoc qui me fait nawak (évidemment c'était moi le fautif )

 
Tu devrais écrire avec vscode tu a une prévisualisation en directe.
Franchement je pense à dedrap, sans vouloir faire d'attaque je trouve que tu pourri un peu le topic avec tous tes posts à la chaine.

 ok je note

Merci pour vos réponses sur vxlan, je vais étudier tout ça... EVPN est effectivement un bon point.

 
Je suis pas encore parti mais évite le post compulsif entre ici, proxmox et Debian, j'ai l'impression de lire que toi    
L'avantage c'est que tu fais vivre les topics, donc voilà puis ça engage que moi.  
 
Il y a du monde qui fait du Kubernetes ici ou qui bosse avec AWS/GCP ? ou alors je trouve pas les bons topics  

 
Kubernetes / AWS / GCP / Cloud, tu en aura pas bcp et y'aura pas de posts ici.
Moi, j'ai déjà pas le temps de faire la doc interne au taf, alors poster ici ce que je fais ...   (et puis j'ai l'impression que personne comprend ce que je dis )
 
Malheureusement, je trouve plus de choses côté Reddit qu'ici, bcp plus roots :
ça parle quand même de boucles de fibre éclairée, de prise de tête avec l'électricité qui sait pas faire des prises correctes, de raccord PC-téléphone, ...

 
Oui moi non plus j’ai pas le temps en journée, j’ai quitté la fonction publique    
Je suis aussi sur Reddit c’est plus technique que ici.  
Ça m’étonne juste que ça ne parle pas trop IaC , automatisation, api, etc...  
 
Perso au quotidien pour moi c’est du OpenShift, Ansible, Kubernetes, Terraform, GCP, Prometheus, OVS, RedHat

Remarque déjà faite. Mais c'est un peu le buzztopic Xatrixien. Et puis à en lire certains, y'a plus la place pour du bas niveau dans l'admin et t'es automatique rétrograder en techos. L'avenir est aux devops, que voulez vous.

Je comprends ta remarque et je vais essayer de regrouper mes posts et éviter d'en faire un blog perso

Le topic est totalement ouvert aux "Kubernetes / AWS / GCP / Cloud, OpenShift, Ansible, Kubernetes, Terraform, GCP, Prometheus, OVS, RedHat" et j'encourage même les membres à en discuter au quotidien
N'hésitez pas à poser des questions ou faire un petit post sur quelques trucs, ça peut aider à la bonne route du topic, à la découverte de technos pour certains et peut-être que vous aurez des réponses
Mais de manière générale je trouve que les cats type OSA ont ralentis et que ce genre de topics manquent d'intervenants

Mais la par exemple j'ai bien aimé VXLAN, donc tout n'est pas perdu

Tous les niveaux et tous les sujets sont acceptés ici, l'aigritude par contre c'est un autre topic
Le côté buzz c'est pour la déconne hein

depuis la création du topik j'ai pu échanger avec d'autres sur ansible, saltstack, gitlab ci, automatisation en tout genre, pas eu l'impression que c'était que des discussions autour de tâches de sysadmin à l'ancienne, ou alors vous avez sauté des pages
 
Maintenant, je pense pas qu'il y ait encore une majorité de participants qui soit full-cloud, on est encore bcp à travailler sur du on-premise ou de l'hybride et à devoir gérer encore des problématiques qui ont disparu chez ceux qui ont totalement perdu la main sur leur infra
 
en parlant de reddit, je suis inscrit sur /devops et /sysadmin, et c'est d'ailleurs marrant de voir avec quel dénigrement un sub traite l'autre, les gars se sentent pousser des ailes parce qu'ils ont réussi à aligner 50 lignes de yaml

 
quel rapport entre le fait d'être en on premise et le fait d'utiliser des méthodes de travail modernes ? ici on est très majoritairement en on premise et pour autant on entend parler d'ansible, de ci/cd et compagnie dans toutes les discussions.

Je crois comprendre que le conf mgmt et l'automation sont des outils de base désormais pour les sysadmin

edit: Et j'ai envie de dire que ce topic est là aussi pour essayer de sortir du sysadmin à l'ancienne pour ceux qui y sont encore

Je reviens sur la supervision, est ce que certains d'entre vous utilisent une archi distribué ? Avec plus d'un serveur de supervision en gros.
Comment vous gérez la propagation de vos scripts ou plugins ?

 
pas de rapport ?
 
je parlais du fait de ne pas trop parler ici de gcp/aws/azure en prod et de toutes les problématiques associées à la manipulations de leurs api, services managés etc.

En utilisant un système de supervision concu pour ca, autour d'un concept novateur de centralisation qu'on a nommé "base de données"

Configuration du système de sup != Scripts/modules/plugins de supervision...

J'ai du Centreon avec des pollers externes, et effectivement y'a rien by design pour déployer les scripts de sup depuis le central vers les pollers. Après, t'a pleins de solutions :
1) tu met en place un vrai déploiement de tes scripts de sup (genre git+Ansible, ou tu fait du ci/cd de tes scripts de sup)
2) tu les mets sur un nfs et tu montes le nfs sur tous tes pollers
3) GitlabRunner ?

Rsync depuis le central ? J'ai plein de solutions en tête, j'essayais de voir ce que vous utilisez et avoir éventuellement des retours d'expériences

 
Si Seulement mon pauv'
 
Je suis dans une pme ESN et on en est encore loin. la taille de la structure et la clientele visé y joue clairement.
 
A titre d'exemple, on doit créer, aller, 1 a 2 VMs par semaine (et c'est bien possible que y en autant qui saute dans le meme intervalle), le temps a deployer pr automatiser le process, il faut qu'on le trouve nous meme, il n'est clairement pas une priorité pr la direction, resultat, ça n'avance pas.
 
On est guere que 2 dans toute l'equipe a s'etre penché sur ce que sont ansible/puppet/chef/terraform  ou encore Kubernetes, le HCI,l'IaC etc etc. On le fait sur notre temps libre, possiblement parce que ça nous plait/passionne.
J'en apprends bien plus en lisant vos post HFR que dans le quotidien de mon boulot.
 
On m'y demande de reprendre en main un Cloud privé. y a 1Vcenter et 8ESXi, tu pisses pas loin avec ça... et pourtant, ça doit bien faire 1 semaine que j'y ai pas mis le nez parce demandé sur d'autres dossier qui s'approchent plus du tech n1/2 que de l'admin.
C'est con a dire, mais j'ai plus souvent eté l'initiateur de solution technique/technologique au sein de ma boite que le suiveur, simplement parce que j'en avais pris connaissance ici et que j'avais creusé le sujet.
 
La discussion sur VXLAN et EVPN, j'ai pas tout saisi, mais je note je cherche je me renseigne, je vais voir les page wikipedia correspondante, jme dis que peut etre ça pourrait servir dans tel ou tel situation etc. mais j'en entendrais pas parlé au boulot avant 1an au moins voir meme plus, sauf si j'aborde le sujet moi-meme. AWS,GCP,Azure, on l'aborde tres peu, jsute pour dire que ça nous bouffe des clients qui partent dessus mais c'est tout. J'y ai jamais mis les pieds (ou la souris plutot) personnellement, et je doute tres tres fortement que ça soit le cas de mes collegues...
 
Bref, la couverture est large sur HFR, tu auras des cas tres basique, comme des as tres pointu dans leur domaine. Et le On Premise, le bare metal et les install a la main sont encore repandus j'en suis certains.

Il faut pas se mentir mais aller sur le coud aws/GCP/Azure pour une pme ça à peu d'interêt je pense.
 
Je suis dans une multi-nationale, on va tous passer dans le cloud, mais ça coute plus chère au final   (faut former le personnel, que faire des data center actuel... etc) mais clairement on gagne en vitesse, tu élimines beaucoup de problème, le flux va plus vite, et tu déploie sur une nouvelle région très rapidement.  
90% des boites n'auront pas ce besoin. Et on fera surement du cloud hybride pour ne pas dépendre que dans seul cloud provider.  
 
Conclusion ça va aller à plusieurs vitesse en fonction des clients, il faut bien choisir en fonction de la carrière souhaité. Mais le sys admin qui fait les choses "à la main" aura toujours du boulot. J'évite de faire trop de technique ici à cause des accords de confidentialité

Mouais, le "cloud pour une pme a peu d'intérêt" je partage pas trop.
Je vois pas trop l'intérêt d'une PME dont l'informatique n'est pas le métier de se faire chier avec des serveurs, gérer les pb, un réseau complexe, à devoir faire du capex sur des serveurs, gérer une salle serveur, la sécurité de l'infra physique etc. alors que ça peut être héberger sur qq vm dans chez un cloud provider.

Je pense tout l'inverse après ça se discute selon les cas, mais c'est plus intéressant pour la pme que pour la multinationale car elle pourra se focus sur son métier et ne pas essayer de tout faire avec deux mecs.