Les cahiers de l’admin : vis ma vie à Clichy

Cela faisait un moment que Nicolas et moi-même avions pensé à écrire des articles narrant une partie de notre travail et plus généralement détaillant le fonctionnement de l’environnement de production. J’inaugure aujourd’hui cette nouvelle série d’articles par une présentation générale.

Un datacenter sécurisé

Toutes nos applications (Maestro, Capico, nos différents sites, le wiki commercial, SugarCRM…) sont sur des serveurs hébergés dans le datacenter de Globalswitch à Clichy. C’est l’entreprise Ecritel qui s’occupe de notre baie et ils nous apportent un support complet : nous leur louons une baie entière de 47U, qui nous permet d’avoir suffisamment de place pour toutes nos machines. La sécurité est garantie et optimale : notre baie est fermée à clef et est située dans une vaste salle climatisée. Pour accéder à la salle, nous devons porter sur nous un badge. Ainsi, les risques d’intrusion sont nuls.
Ecritel nous fournit un support rapide et performant : en cas de problème sur un de nos serveurs, il nous suffit d’ouvrir un ticket (de la même manière que vous le faites sur support.excilys.com) ou de passer un coup de fil, et un agent s’acquittera de la tâche demandée. Il s’agit le plus souvent de redémarrer un serveur planté. Ils nous préviennent aussi en cas de panne non critique d’une de nos machines (disque dur en panne sur un RAID 1 par exemple).

L’infrastructure de ces dernières années

Nous fonctionnons depuis quelques années avec un ensemble de machines physiques :

  • Romulus et Remus pour la production.
  • Pre-Romulus et Pre-Remus pour la pré-production.
  • Janus est une machine d’administration qui s’occupe de certaines tâches, notamment la livraison de mises à jour de nos applications.
  • Hrund est une autre machine d’administration, qui nous sert de machine de monitoring.
  • Skuld est une machine dédié aux backups.
  • Une baie de disque iSCSI stocke toutes nos données.

Comme vous pouvez le constater, la mythologie nordique a marqué certains esprits. ;)

La production est composée de deux machines, nommées Romulus et Remus. Elle héberge toutes  les applications. Elles fonctionnent en actif-passif. Cela signifie qu’une seule machine à la fois a les ressources et fait fonctionner nos applications, tandis que l’autre reste en stand-by et attend une éventuelle défaillance de la machine active pour prendre la main. La technologie utilisée est Hearbeat. Heartbeat monitore constamment les deux machines et dès que la machine active tombe (panne réseau, électrique…), les ressources (données de la baie de disque) sont transférés, et les applications relancées (apache pour les sites, jboss, etc.). Il faut à peu près cinq minutes pour relancer la production en cas de défaillance de la machine hôte. Malheureusement, la technologie n’est pas parfaite, il arrive que la machine active plante (CPU à 100% par exemple) et que Hearbeat ne transfère pas les ressources : en effet, la liaison entre les machines étant opérationnelle le programme ne détecte pas la défaillance ! Il nous faut alors intervenir manuellement pour désactiver la machine active afin que la passive prenne le relais.

La pre-production, est à l’image de la production et fonctionnait de la même manière. Fonctionnait oui, car le serveur passif est maintenant utilisé comme firewall (j’y reviendrai plus tard), la criticité de la Pre-production étant moindre. Elle permet à nos développeurs de tester dans des conditions identiques à la production leurs applications, afin de savoir si on peut faire la mise à jour sans crainte de bug ou de mauvaise surprise.

De haut en bas : Romulus, Remus, Donald*, Loulou*, Skuld, Hrund, Pre-Romulus, Duncan*, Janus (qu'on voit à peine)

*voir ci-dessous

Evolution de l’infrastructure

Nos machines de production arrivent au terme de leur garantie, Dell garantit ses machines 5 ans maximum. Il est de même pour la baie de disque. Il nous fallait donc renouveller le parc de machines. Nos applications sont peu gourmandes en puissance brute, c’est la mémoire leur talon d’Achille. Ainsi, il ne nous était pas forcément nécessaire de faire évoluer totalement nos machines, rajouter de la ram aurait suffit. Mais comme il est hors de question d’utiliser des machines non garanties, on a donc décidé de faire évoluer l’architecture.
Nous avons acheté une baie de disque similaire, elle est bien sûr plus performante et dispose de plus d’espace disque qu’auparavant.

La nouvelle baie de disque et l'ancienne, en-dessous.

Nous avons aussi réussi à faire entrer dans le budget alloué un châssis de type Blade. C’est un châssis très avantageux : il est compact et permet le faire fonctionner 16 serveurs dans 10U, son administration est aisée et nous pourrons progressivement changer nos anciennes machines pour les transformer en serveur Blade.

La châssis Blade : 16 emplacements, 2 utilisés pour le moment.

 

Avec la nouvelle architecture matérielle, une nouvelle architecture logicielle va être mise en place : tout notre environnement de production va tourner sous VMWare. C’est une solution de virtualisation performante qui nous permettra d’administrer plus facilement et avec de meilleurs résultats l’infrastructure.

Notre licence VMWare fonctionne avec trois serveurs physiques maximum. Nous avons commandé deux nouveaux serveurs (nommés Riri et Fifi) tandis qu’une ancienne machine performante, encore sous garantie mais inutilisée pour le moment sera utilisée pour être le troisième serveur. Les connaisseurs de l’univers de Disney auront deviné qu’elle a été nommée Loulou.

Riri et Fifi attendant sagement l'arrivée de Loulou, qui à terme se transformera lui aussi en serveur Blade.

Pour administrer ces trois machines, nous avions besoin d’un autre serveur physique, tournant sous… Windows 2008 Server. Hé oui, pas de client Linux chez VMWare ! C’est une machine identique à Loulou qui a été récupérée, Donald prendra donc soin de ces trois serveurs sous ESX (l’OS utilisé par VMWare). On a donc maintenant un serveur Windows au milieu de tous nos Redhat et autres distrib Linux, qui l’eut cru !
Notre travail ces derniers jours a donc été de brancher ces machines. Ce n’a pas toujours été une partie de plaisir (un châssis blade vide pèse quand même 70 kg et est plutôt imposant, quand il faut le soulever à 1 mètre du sol même en étant à deux c’est assez sportif !) et ça nous a fait beaucoup de câbles à rebrancher.

Et le réseau dans tout ça ?

Jusqu’à maintenant, chacune de nos machines avait son propre firewall (via iptables, comme elles sont toutes sous Linux). Maintenant, nous utilisons l’ancienne machine de pré-production comme Firewall, renommée Duncan (on est allé chercher plus loin dans l’arbre généalogique des Duck cette fois-ci comme l’atteste ce lien). Cette machine tourne sous PfSense et représente actuellement le principal SPOF (Single Point of Failure) de l’architecture. Bien sûr, ce n’est que temporaire.

Plusieurs réseaux cohabitent au sein de notre baie :

  • Quatre réseaux pour la baie de disque
  • Réseau d’administration
  • Réseau local

Tout cela impose une organisation particulière des switchs.

Deux de nos switchs. Tout va bien, les étiquettes sont mises...

Il faut aussi faire en sorte que l’accès aux machines soit aisée et que les nombreux câbles soient rangés.

Etre admin, c'est aussi l'art de brancher des câbles avec classe et élégance.

L’objectif est maintenant d’installer les nouveaux serveurs et de migrer petit à petit l’environnement de production dessus. Et ça, c’est une autre histoire ! ;)

VN:R_U [1.9.22_1171]
Rating: +3 (from 3 votes)
Share
Ce contenu a été publié dans Non classé. Vous pouvez le mettre en favoris avec ce permalien.

2 réponses à Les cahiers de l’admin : vis ma vie à Clichy

  1. Impressionnant ! On peut faire la sieste dans un datacenter ?

    Heureusement que c’est sécurisé en tout cas, au moins ça évite que le voisin vienne se brancher sur ta prise électrique… ;-)

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. Ping : Les cahiers de l’admin : comment faire tourner la prod sur du matos de montgallet | Excilys Labs

Laisser un commentaire