Reprise du message précédent :

Dans mon cas c'est pour quelques baies tout au plus avec des trucs qui bougeront peu dès que j'aurais virer toute la merde et refait tout au propre (aujourd'hui c'est un sacré foutoir)

Le stagiaire qui est admin du domaine  

Ben y'a pas de secret, si tu veux du propre, tu patch. Et très franchement, même sur un truc qui bouge très peu, avoir un câblage propre, ça aide quand tu change un noeud. Niveau densité aussi, ça aide.

Oui je me prends pas la tête justement parce que c'est une plateforme de test/validation du bon fonctionnement du code. J'ai juste à monter un cluster k8s avec du Rook/ceph dessus.
J'ai réussi ce matin à faire fonctionner la partie k8s, du coup j'embraye sur Ceph, mais avant je fais un petit Clonezilla histoire de.

Kubernetes tout bête.

Non mais mes Snapshots sont sur un lab linux qui fait tourner k8s/Rook/Ceph, donc rien en prod. Et puis voilà le stagiaire qui a accès à la prod aussi, vous cherchez les emmerdes

Chez toi les archis font le déploiement initial ?! En physique dans les baies ?

Bah... Gke ou équivalent ? Tu te fera moins chier, ça te coûtera moins cher que le temps que t'es en train d'y passer.

Je ne connais pas gke. Pour rappel l'année dernière je n'avais jamais touché à un docker/k8s de ma vie.. Du coup j'ai repris le taf de mon prédécesseur, et j'ai pris la même base que lui.

C'est un peu tard pour passer sur autre chose; je vais pas réapprendre maintenant un autre système...

J'ai mon cluster qui est OK, mais comme je le pressentais c'est maintenant Rook/Ceph qui m'emmerde. Ce qui me flingue c'est que j'ai réussi à faire fonctionner ça sur mon lab, mais avec de vrais serveurs c'est la misère. Pourtant ya juste à appliquer 3 fichiers yaml, et tout est fait automatiquement, mais non, dans mon cas ya des containers qui ne démarrent pas et je ne sais pas pourquoi. Même pas en erreur hein, ils sont simplement pas démarrés. Et vu que je sont des trucs vitaux pour le bon fonctionnement du cluster...

C'est bien ce que je dit. Prend toi un kubernetes as a service chez Google/amazon/azure/OVH et arrête de galérer.

K8S facile, tu fais ça avec un Rancher2 pour allez vite.  
 
Sinon encore plus rapide avec un GKE    
 
Bonus le script pour du test, c'est pas prod ready, il n'y a que 1 zone et c'est du preemptible.
 

C'est ma passion k8s, si tu veux monter en compétence, je te recommande:
https://github.com/kelseyhightower/ [...] e-hard-way
et https://linuxacademy.com/course/clo [...] rator-cka/
 
Et pour être en prod dans une grande entreprise je te dis bon courage  

 
Quand je bossais je faisais du déploiement oui. Après boulot de niche et archi particulières pour besoins pointus. Mais pour moi, un archi doit savoir câbler une baie, à minima aussi bien qu'un tech, sinon il comprendra pas certains besoins quand il fera ses poc. (exemple tout bête : le "switch everywhere" qui fonctionne bien sur un poc, mais qui pour des raisons "obscures" sous perf, au mieux, voir fonctionne carrément pas, AKA le broadcast shitstorm)
T'architecture pas un 4D ou une typologie torus, si tu sais pas la câbler.

La base
Et en bizutage tu lui files une migration le vendredi

Tu m'étonnes

qqn aurait une liste des modules kernel qu'on peut dégager par défaut ? j'ai déjà une petite blacklist sur mes machines mais je suis sur que certains encore là ne servent à rien

Ouai, enfin, que l'archi doive savoir c'est une chose. Maintenant, combien ça coûte de faire câbler X U/baies par un archi vs un tech avec une matrice de câblage ? Quand c'est toi qui vend ta prestation de bout en bout je veux bien, mais quand c'est une boîte plus grosse, je suis pas sur de la valeur ajoutée.

 
Merci pour ces liens  
Oui j'aimerais monter un peu plus en compétences,  vu que j'ai appris les bases seul, il me manque une tonne de connaissance théorique, le mode de fonctionnement précis... Bref Il me manque un peu
GKS est payant? Parce que je peux tout aussi bien faire un lab comme j'ai déjà fait, avec 3 VMs et me dépatouiller dessus non?
 
Je ne vise pas la prod dans une grosse entreprise, mais juste à être un peu plus à l'aise, surtout quand ça merde comme là, ou pourquoi j'en chie à mettre mon cluster une une interface réseau spécifique alors que j'en utilise 2..
 

 
Non, j'avoue que pour mon utilisation jusqu'à présent, je me contente de désactiver des services inutiles, mais je ne joue pas avec les modules...

Bah y a quelques K8S on prem sympas et faciles à installer. Genre OKD par exemple.

 
tu ne dégages même pas le pcspkr qui fait "BEEEP" à chaque fois que tu TAB et qu'il ne sait pas quoi faire ?

 
Tout dépend de la boite et du domaine. Dans le HPC/Presta luxe pour DC/Alphabet, la valeur ajoutée existe parce que tu as une deadline, et que sur un projet si y'a du troubleshooting à faire au déploiement, vaut mieux que t'ai des archis qui bossent sur les baies que des techs : pas le temps de retourner sur la planche à dessin. Mais c'est aussi parce qu'il y a d'autres contraintes que seulement faire fonctionner le bousin : bien souvent, le flux d'air est refroidissement est optimisé, l'alimentation en énergie est optimisée, la place est optimisée et les problématiques doivent avoir une réponse dans l'heure.

c'est pas moi qui a autorisé ça tu t'en doutes.J'ai decouvert le mefait quand ils sont venu (lui et son responsable) me voir en disant, "dis voir, y a plus rien qui marche sur le domaine tu peux jeter un coup d'oeil, on sait pas kessisspasse?"
merci les connards!!

Et maintenant, quid des longueurs fibre/rj dans les baies ? Baie unique ici (enfin pour cette salle )
 
J'ai envie de tout reprendre en utilisant un code couleur

Vaut mieux respecter les courbures (diamètre minimum supporté par le câble) que d'essayer de gagner quelques cm dans une baie.
-En RJ parce que tu fais moins souffrir le blindage.
-En RJ toujours parce que généralement les câbles que tu ne bouge pas (switch => patch) sont en monobrin (pas souple du tout) et sujet à cassures. On cherche à limiter la longueur en câbles patch.
-En optique si tu ne respecte pas la courbure des câbles, au mieux tu risque un affaiblissement pour cause de diffraction du signal, au pire une cassure qui ne sera pas nette et un signal intermittent.

Thx. Je pensais pour la fibre mettre des supports sur les côtés de la baie unique pour lover la fibre si nécéssaire.
Maintenant je me pose la question du câble management. Distinction entre power et data ?  
C'est à dire que sur les passages de câbles à gauche, par exemple, je ne fous que du power et à droite que la data ?  
Tin et les mecs qui prennent des serveurs sans l'option à 3€ pour le plateau support de câble à l'arrière.
Pas d'avis sur l'arm pour les câbles par contre, c'est utile ?

Un peu de cable porn avec les 2 machines que je viens de mettre en place dans mon tiroir de bureau
 

c'est quoi ces configs?

Et les câbles rouges à la place de ceux fournis avec les alims ?

Machine du "haut", mini-itx avec core i5-8500, CG Quadro, SSD M2 et 1 disque SATA (windows 10)

Machine du bas avec un céléron moisi underclocké, 2 disques en RAID1 et un SSD pour le système et tournant sur Debian pour du backup

oui, Corsaire pour la modique somme de  

joli !

Salut. Chez nous on n'utilise pas les bras à l'arrière car ca oblige à faire du trop serré pour du cat 6 ou de l'optique.
Ca sent le truc qui date de l'époque où ca servait uniquement pour la partie câbles écrans+clavier+power.
L'origine du bras est de pouvoir tirer ton serveur par devant sans rien débrancher.

 
Jamais utilisé non plus, ça devient chiant quand t'as des serveurs de différentes marques qui se superposent et avec des bras différents. Et ça implique que TOUS les câbles doivent être 2x plus long pour passer dans le bras

Perso ça dépend, on en a utilisé, et des fois non. Mais je trouve quand même plus pratique sans, parce que en général quand on fait une opération sur un serveur, il est en général éteint

Les bras ont qu'une utilité : quand tu peux pas accéder à l'arrière de la baie. Autrement c'est presque totalement inutile.

Avec des velcros et le regroupement en tresse individuelle des câbles de chaque serveur, ya moyen de faire un truc assez propre sans bras articulé, facile à s'y retrouver et qui laisse un peu de mou sur la longueur de câble pour éviter les tensions. Ça facilite les maintenances même si on doit débrancher le serveur (souvent éteint comme dit Iskor ) pour l'ouvrir Alims d'un côté, data de l'autre Idéalement chaque câble étiqueté aux 2 extrémités pour savoir d'où il vient et où il va.  
 
Exemples :  
 
 
 
Au niveau air flow, je suis assez fan de la "tresse centrale" pour les câbles réseau, pourtant je vois ça peu souvent. Je trouve que ça optimise le flux plutôt que de faire le passage horizontal pour chaque serveur ce qui finit par former "une barrière". Un exemple qui ressemble pour illustrer, ya pas de tresse séparée par serveur je crois vu que tout est regroupé par couleur de câble  

https://pix.fr/ wut ?

Merci pour vos réponses sur le câble management, arm, séparation data/power.
Aujourd'hui j'ai une baie où j'ai des PDU de chaque côté. Alternativement secouru/non secouru. Les câbles filent dans tous les sens. Je milite pour une nouvelle baie histoire de pas me faire chier avec la vieille merdique et tout faire propre mais ça passe pas ça vaut même pas le prix d'un MBP avec pleins d'options
Je vais essayer de démonter et tout remonter sur le côté droit, où sont les alim en général sur mes serveurs (je crois).
Et faire deux chemin de câbles à gauche, un fibre, un rj. Me faut des codes couleurs pour distinguer data/idrac/mgmt/ceph.

Pour le côté alimenation, quid de ce truc secouru/non secouru. Je met 50% des alims sur l'un et le reste sur l'autre ?
Pourquoi pas tout en secouru ? Si l'onduleur claque ?

J'ai toujours eu la moitié des alims sur onduleur et l'autre non. Une question de sécurité j'imagine, ne pas avoir les oeufs dans le même panier. Si possible, les ondulés/non ondulés doivent être sur un TGBT différent.
Enfin, c'est comme ça qu'on avait refait ma salle info dans mon ancien taf

C'est ce que je me dis aussi, je cherche à valider.
Le truc qui me fait peur c'est que relier directement au réseau c'est potentiellement subir les hausses de tensions et autres qui peuvent tout cramer.
Je préfère un downtime même en jours (j'ai une autre salle serveur) que de claquer le matos

si tu mets tout sur la même source, ça ne sert plus a rien d'avoir du double alim !
donc soit tu fais comme c'est déjà en place, donc un coté secouru et l'autre pas, soit tu mets tout sur secouru mais sur 2 onduleurs différents (idéalement eux même sur 2 arrivées EDF différentes)

Ca semble logique

La console Scaleway a quand même bien évolué, je sais pas qui l'utilise ici.

Elle marche mal avec Firefox

+1,  
Xat, faut aussi faire gaffe lors de l'achat d'alim pour que ca tienne sur la moitié sans perte de perf (constaté anciennement sur x86 Lenovo, service garanti mais CPU à 60% du nominal car alims trop faibles).
Attention aux liens entre alim quand plus de 2 (sur gros switchs par exemple). Chez Brocade, les directeurs SAN ont les alim "en ligne de puissance", donc tu câble l'alim du haut à droite sur la même PDU que celle du haut à gauche, et pareil pour en bas. Naturellement, on avait mis les 2 alim de gauche sur la PDU de gauche du rack et idem à droite, pouf, la moitié du switch éteint lors des tests.