Bonjour à toutes et à tous !
La nuit dernière, une partie de l’équipe de MilkyWan ,composée de Hugues, Gaëtan et moi-même nous sommes prêtés à un exercice assez intense : refaire notre baie de Bourse.
Pour commencer, voici quelques chiffres sur le site de BRS : Une dizaine de clients qui ont leur propre AS (
https://www.peeringdb.com/fac/1782) , une cinquantaine de baies, 250kW de capacité électrique en 2N, 100% de dispo depuis 2013 (donc depuis qu’il est géré par Leonix :
https://lafibre.info/leonix/).
MilkyWan à Bourse, c’est une dizaine de U, avec divers services.
Pour rappel, la disposition de la baie après la précédente upgrade (
https://lafibre.info/milkywan/upgrade-du-coeur-de-reseau/) :
Sur cette photo donc de haut en bas :
U42 : Le PatchPanel (à peine visible) sur lequel arrive les fibres allant vers d’autres sites (topographie du réseau :
https://weathermap.milkywan.fr/milkywan.html).
U41 : Passe-câble. Je ne suis personnellement pas fan d’en mettre, mais sur une baie de 600 (donc peu larges), il n’y a pas vraiment d’autres solutions pour ne pas tout laisser pendouiller en façade.
U40 : Un CCR1072, routeur de 8*10Gbps ayant 72 cores Tilera. Funfact : BGP est monothread sur RouterOS, donc dans ce cas de convergence, il y a un core qui bosse et 71 qui se tournent les pouces. Il me semble que cela doit être changé dans RouteurOS7™. Ce routeur nous sert de core, pour des raisons historiques (le routeur précédent qui n’avait pas assez de port 10G) était en Router on Stick, c’est-à-dire qu’on utilise un Switch avec de la densité pour connecter tous les ports et qu’on fait tout remonter au routeur sur un/plusieurs liens sous forme de VLAN. Cela présente l’avantage d’avoir un grand nombre de ports de haute capacité sur le switch à un coût raisonnable, mais peut poser des limitations supplèmentaires sur certains usages. L’une des raisons de la migration est de changer cela et donc d’utiliser d’avantages de ports du CCR pour la partie uplink/backbone de MilkyWan.
U39 : Un EdgeCore AS5610 de 48*10G + 4*40G tournant sous Cumulus (
https://en.wikipedia.org/wiki/Cumulus_Networks). Ce switch servait donc à la fois pour la partie connectivité des serveurs et pour le backbone via le RoS. Ce matériel n’étant pas à nous, la migration nous a permis de l’échanger contre un autre matériel et vas nous permettre de le rendre a son propriétaire (merci encore à lui pour le prêt de longue durée !).
U38 : Un Cisco-2960G-48-TC-L avec 48 ports 1000Base-T (1GbE donc) et 4 ports SFP qui nous servaient d’uplink. Il servait notamment pour la connectivité des serveurs et du SAN, via des LACP de 4*1GbE pour les serveurs et 3*1GbE pour le SAN.
U37 : Un Cisco 7301 servant de LNS, avec un lien Gbps.
U36 : Un Mikrotik RB3011 qui servait de routeur de collecte pour les tunnels et de service pour les VM.
U35 : Encelade, l’un de nos hyperviseurs HDD, un HP Proliant G6, qui a un mix de VM clients et de services internes. Les HV sont des PVE en cluster multi-site, mais régionalisés, c’est-à-dire un groupe pour l’IDF, et si nous ouvrons d’autres PoP système (à Lyon au hasard), il s’agira d’un autre cluser.
U33-34 : Un SAN Thecus qui contient 12 disques de 3To en RAID6. Pour les VM HDD, nous hébergeons en effet les disques sur le SAN plutôt que sur les HV qui n’ont pas la même capacité de stockage, les disques sont montés en iSCSI.
U32 : Cassini, le second hyperviseur HDD du site, qui est aussi un HP Proliant G6.
La liste des objectifs du rebuild de cette baie étaient donc :
- Passer toute la partie « cœur » sur le CCR1072 ;
- Changer l’AS5610 par un switch FiberStore de 48*10G + 2*40G + 4*100G (on ne sait jamais, on pourrait avoir des idées de choses à faire avec ce genre de débits) ;
- Changer le 2960G par un switch ayant des Uplink 10G. Nous nous sommes procurés un Brocade FastIron GS648P avec une carte 2*10G (merci @Acontios !), et les XFP qui vont avec ;
- Augmenter la capacité disponible sur le LNS en le passant en 4*1G ;
- Mettre un routeur de service avec un peu plus de patate : un RB4011 qui sait faire du 10G ;
- Ajout d’un STS pour les machines mono-alimentées ;
- Ajouter aux hyperviseurs et au SAN des cartes 2*10G pour éviter tout goulot d’étranglement.
Voici donc la pile de matériel à ajouter/échanger dans la baie :
(Ne vous en faites pas pour le STS, il a eu le droit à un coup de chiffon avant d’être racké)
Comme vous vous en doutez, ça fait pas mal de choses pour une seule soirée. Même avec de l’organisation, le planning de prévision a été absolument explosé. L’une des choses les plus importantes pour nous sont la transparence et la proximité avec les gens qui nous suivent depuis le début, on a donc décidé de communiquer en direct pendant toute la durée de l’opération via un thread twitter :
https://twitter.com/milkywan_net/status/1167539202378088451En amont, on a bien entendu préparé pas mal de choses : migration des services essentiels, communication des clients une semaine à l’avance et rappel le jour même, pré-configuration du matériel autant que possible. Pour l’occasion, on s’est même fait un chan spécifique sur notre outil de communication interne, histoire de ne rien louper.
À 22h commence donc notre opération. Si je vous ai parlé plus haut de vider la baie, ça n’était pas une figure de style :
Il ne restait donc plus dans la baie que les PDU et le STS fraichement installé.
Avoir tout enlevé c’est bien, mais maintenant, il faut faire les upgrades et tout remettre !
Voici donc un Geatan qui ajoute les NIC 2*10G aux serveurs :
Pendant ce temps-là, votre serviteur canard re-rack les équipements réseau dans le bon ordre :
Vient ensuite le temps de remettre SAN et serveurs :
Une fois tout ce beau monde remis en place, il faut réalimenter tout le monde et voir si tout a bien fonctionné comme prévu. Certains vont se demander pourquoi le faire à ce stade et pas plutôt tout câbler puis, et une fois fini voir si c’est bon : s’il y a un souci, le savoir plus tôt est systématiquement le mieux, ça permet d’agir aussi efficacement que possible, et de prendre les bonnes décisions aussi vite que possible.
Le câblage électrique est fait de manière définitive. Si vous vous demandez pourquoi les câbles sont scratchés aux alimentations, la réponse est qu’il est possible d’ouvrir un serveur sans l’arrêter. Pour être sur ce ne pas arracher le câble d’alimentation en le faisant glisser dans ses rails, l’accrocher de la sorte oblige à « forcer » et donc se rendre compte qu’on est en limite de câble électrique.
Sur la partie réseau en revanche, un câblage temporaire est fait en façade par Hugues pour me laisser le temps de faire un câblage arrière propre tout en permettant à Gaëtan de vérifier l’état des machines :
Pendant qu’Hugues et Gaëtan s’occupent de la partie réseau et système, je refais le câblage en façade. Je pense qu’à votre goût comme au mien, il n’est pas très propre. Si on veut faire un câblage propre, il faut faire des torons de fibre et se servir de leur rigidité pour les former et leur faire faire des courbes. Mais il y a un désavantage à cela : chaque modification demande plus de temps pour passer une nouvelle jarretière proprement, puisqu’il faut tout refaire. Ici j’ai fait des groupes par « destinations ». Si l’on décide d’ajouter un serveur, je ne dois refaire que le groupe en question, et non tout le toron.
La configuration finale est donc :
U42 : le PP, il n’a pas bougé.
U41 : un câble manager, de même, toujours à la même place.
U40 : Le CCR avec le backbone et un lien vers le switch.
U39 : Le 7301 de LNS.
U38 : le RB4011 de service.
U37 : un câble manager (baie de 600 oblige, et je vous assure que ce n’est pas un plaisir à câbler).
U36 : le switch de core FS, qui a à présent les raccordements 2*10G des HV, et les 2*10G + 10GbE du SAN.
U35 : Encore un câble manager ! Vue la proximité des deux switchs, ça permet de choisir le plus simple pour la destination des fibres qui partent du FS, et permet aux RJ du Brocade de ne pas passer au-dessus d’un autre équipement. C’est la pire des galères lorsqu’on souhaite changer un équipement et qu’il est recouvert par un rideau de câbles qui servent à la prod.
U33-34 : Le switch Brocade de 1.5U. Le form-factor n’est pas super pratique, mais ça répond très bien au besoin, on ne va pas faire la fine bouche, encore plus sur du matériel qui a le bon gout du gratuit.
U31-32 : Le SAN qui peut maintenant théoriquement sortir 30Gbps. En théorie seulement, parce que bonjour les IOPS et les temps de sync sur des HDD 3To qui ne sont pas tout neufs.
U29-30 : Les HV avec maintenant du 2*10G.
U27-28 : Libres. Rien n’est prévu pour eux, mais on ne sait jamais.
U25-26 : Le NAS perso d’un type étrange qui se balade parfois en Kigurumi Licorne (c’est vraiment n’importe quoi cette asso, y’a des types qui se prennent pour des canards aussi !)
La carte 2*10G du SAN n’est pas vue par le système, mais le 10GbE est actif, ce qui permet tout de même d’augmenter la connectivité du SAN.
Après plus 6h30 passées à refaire la baie, tout n’est pas fini : certaines choses ne remontent pas comme prévu sur la partie VxLAN entre les hyperviseurs, et certaines VM ne sont pas capables de communiquer vers l’extérieur. C’est finalement vers 8h du matin, donc après plus de 10 heures de migration que tous les services sont rétablis.
Je tiens ici à rappeler plusieurs choses : MilkyWan est une association à but non lucratif. Même avec cette équipe particulièrement motivée, l’aventure n’est possible que grâce à nos partenaires qui nous offrent matériel, peering, transit, espace dans les baies dont nous usons et abusons. Tout l’argent que nous récupérons en faisant payer les services en servent qu’à faire grandir et améliorer l’infra, nous ne tirons aucun bénéfice de cela (contrairement à ce que dit cette éponge de @miLkYwaN_tEaM sur Twitter), en aucune manière (c’est plutôt un nid à emmerde quand certains trouvent amusant de vous DDoS à 2h du matin).
Mais ça tombe bien, on ne fait pas ça pour que ça soit rentable. On le fait parce qu’on aime ça, parce que même avec ce genre d’inconvénients, on trouve ça sympa. Et en plus ça nous permet d’aider les copains (Grifon, Midway’s , OSM, etc) et de proposer des alternatives aux gros hébergeurs en ayant des trucs fun (essayez donc de les faire annoncer vos IP en étant livrés sur un tunnel GRE).
Bref, on a pas fini de faire parler de nous, on a encore un paquet d’idées dans les cartons et dans le pipe, à vous les studios, et gardez la tête dans les réseaux ! Si vous avez des questions, n’hésitez pas ! Sur ce, je retourne dormir moi…
MilkyWan