Très concrètement, l'infrastructure d'ARN c'est une armoire de matériel. Faisons un inventaire. Il y a des photos au milieu de la page, aussi. :)

• 2 PDU (multiprise programmable) APC AP7911 achetées d'occasion. Une PDU par arrivée électrique. L'installation et la configuration sont décrites ici : pdu.

• 2 switchs réseaux de récup'. 2 Cisco 3500XL series. Leur configuration est décrite ici : l2
  • Un Cisco WS-C3524-XL-EN, 24 ports qui est utilisé au quotidien.
  • Un Cisco WS-C3548-XL-EN, 48 ports qui sera utilisé dès que le premier switch tombera en panne. La configuration du premier est exportée sur le second.

• 4 serveurs 2U achetés d'occasion (exception faite des SSD achetés neufs). Ces machines sont à la fois nos routeurs et nos hyperviseurs. Nous utilisons Debian GNU/Linux stable. Leur configuration “bas niveau”/matérielle est décrite ici : Configuration "bas niveau" de nos serveurs.
  • Dell PowerEdge R710 (2U) : Documentation .PDF Doc RAM
    • En fonctionnement: hwhost-1
    • Double alimentation électrique
    • CPU : 2 * Intel Xeon X5550 (quad core @ 2.66 - 3.06 GHz)
    • RAM : ~193 G DDR3 1333 MHz ECC
    • Stockage : contrôleur PERC H200 (8x6Gb/s) + chariots pour supports de stockage 2,5 pouces + 4 * Samsung SSD 850 PRO 1To + 2 SSD 512G + 1 HDD 4,6T
    • BMC : iDRAC 6 Enterprise
    • necessite un firmware proprio non fourni dans l'iso debian : bnx2-mips-09-6.2.1b.fw (indispensable pour avoir du réseau)
    • 5 prises ethernet
  • IBM X3650 M2 7947 (2U) Documentation
    • En fonctionnement: hwhost-2
    • Double alimentation électrique
    • CPU : 2 * Intel Xeon X5550 (quad core @ 2.66 - 3.06 GHz)
    • RAM : ~161 G DDR3 ECC
    • Stockage : contrôleur M1015 (8x3Gb/s peut être 6) + chariots pour supports de stockage 2,5 pouces + 5 * Samsung SSD 850 PRO 512GB (+1 spare ?!) + 2 * Samsung SSD 860 PRO 512GB + 1 HDD 4,6 TiB
    • BMC : Integrated Management Module (IMM)
    • 3 prises ethernet
  • HP ProLiant DL380 G6 (2U) Doc
    • En fonctionnement: hwhost-3
    • Double alimentation électrique
    • CPU : 2 * Intel Xeon X5550 (quad core @ 2.66 - 3.06 GHz)
    • RAM ; 16x8GB ⇒ 128GB
    • Stockage : contrôleur P410i (8x3Gb/s peut être 6) + chariots pour supports de stockage 2,5 pouces + 3 * Crucial MX500 + 2 * Samsung SSD 870 EVO 4TB + 1 * Samsung SSD 860 PRO 512GB)
    • BMC : ILO 2 Advanced
    • 5 prises ethernet
  • Dell PowerEdge R710 (2U) : Documentation .PDF Doc RAM
    • En fonctionnement: hwhost-4
    • Double alimentation électrique
    • CPU : 2 * Intel Xeon E5645 (six core @ 2.40 - 3.06 GHz)
    • RAM : 67G
    • Stockage: contrôleur PERC H200 (8x6Gb/s) + chariots pour supports de stockage 2,5 pouces + 3 * Crucial MX500 4To + 2 * Samsung SSD 870 EVO 4TB
    • BMC : iDRAC 6 (?) Enterprise
    • necessite un firmware proprio non fourni dans l'iso debian : bnx2-mips (indispensable pour avoir du réseau)
    • 5 prises ethernet
  • Dell poweredge 1950 (1U)
    • RAM : 39G
    • CPU : 4 * Intel Xeon 5110 1.6GHz
    • sans disque dur
    • Origine: don de redisded
  • HP Proliant 580G5 (4U)
    • RAM : 32x2G

Les deux machines actives travaillent de concert et se partagent les mêmes rôles : routage et hyperviseur.

• Nous avons aussi 2 SSD Samsung 850 PRO 512GB, un installé dans chaque machine active, en spare pour parer les pannes.

• Nous avons un écran LCD Samsung SyncMaster 940T 19 pouces de récup' ainsi qu'un clavier USB afin de dépanner les machines quand l'accès réseau est impossible. Il sont stockés en permanence dans la baie.

• Nous avons également des fournitures diverses stockées dans la baie : serre-câbles sur lesquels il est possible d'écrire, un marqueur noir, un câble réseau (en cas d'oubli de l'admin qui vient dépanner), un câble série pour configurer les switchs, des adaptateurs prises électrique format C14↔standard français,…

Pour avoir des infos sur le coût d'acquisition de tout ça, c'est ici : Page récapitulant tous les frais du FAI.

Tout ce matériel est installé dans une demi-baie (une bête armoire) dans le datacenter Cogent de Schiltigheim (banlieue de Strasbourg). Un datacenter est un bâtiment dans lequel sont installées les infrastructures des opérateurs réseaux (Orange, Free), celles des hébergeurs (OVH, Online, 1&1,…) ainsi que celles des fournisseurs de services (Google, CloudFlare, Facebook,…). Ces datacenters ont pour principaux avantages une bonne gestion de l'énergie (arrivées électriques secourues et bonne évacuation des calories) et du réseau informatique.

Une entreprise peut garder son datacenter pour son usage propre (exemples : OVH, Online,…) ou sous-louer des bouts (salle, cage (morceau de salle), baie, demi-baie, U (unité de mesure dans une baie)). Pour avoir seulement quelques U, il faut généralement faire appel à une société commerciale (opérateur ou fournisseur de services) qui loue déjà une baie ou plus et qui pourra sous-louer quelques U pour un ou deux serveurs.

Voici la demi-baie d'ARN (vue de face) en décembre 2015 :

Faisons les présentations (de haut en bas) :

• Patch-panel (aka panneau de brassage). Délimitation entre Cogent (propriétaire du datacenter donc de notre baie) et nous pour ce qui est des interconnexions externes. Permet de relier notre matériel où qu'il soit dans la baie aux câbles qui sortent de notre baie. Ainsi, l'exploitant du datacenter n'a pas à se préoccuper de la longueur des câbles et autres tracas si le locataire de la baie souhaite déplacer son matériel au sein de celle-ci.
• Dell R710
• HP DL380G6
• IBM X3650 M2
• Châssis d'un vieux serveur qui nous sert à poser/fixer les machines de nos abonné-e-s au format libre (Briques Internet, Intel NUC,…).
• Switch WS-C3548-XL-EN.
• Au milieu, on voit du rabe de câbles électriques C13/standard français.

Voici la demi-baie d'ARN (vue arrière) en décembre 2015 :

Faisons les présentations (de haut en bas) :

• Switch Cisco WS-C3524-XL-EN
• Dell R710
• HP DL380G6
• IBM X3650 M2
• Châssis d'un vieux serveur qui nous sert à poser/fixer les machines de nos abonné-e-s au format libre (Briques Internet, Intel NUC,…).
• Les PDU APC AP7911. Pourquoi ils ne sont pas rackés ? On gagnerait un peu de place au détriment de la simplicité pour brancher/débrancher des câbles.

Pour ceux et celles qui s'interrogent sur les couleurs des câbles, voici le code :

• Câbles réseaux :
  • Bleu : interconnexion directe des deux machines de l'association qui travaillent de concert (iBGP et Ganeti utilisent ce câble). Ce câble est le plus critique. Son absence provoque la séparation du réseau d'ARN en deux entités (split-AS), ce qui provoquera une panne bien visible de tous les services.
  • Rouge : il s'agit d'une interconnexion externe. Très probablement d'un transitaire. Donc critique même si nous avons deux transitaires et qu'il faut donc débrancher les 2 câbles rouge pour isoler ARN du reste des Internets.
  • Jaune : il s'agit d'un câble servant au management (BMC, PDU,…). Toujours critique (car ça permet le debug à distance) mais moins car les services que l'on propose à nos membres ne seront pas impactés.
  • Vert : il s'agit d'une machine appartenant à l'association. Débrancher un câble durant une maintenance est sans impact (l'autre serveur prend le relais).
  • Blanc : il s'agit d'une machine appartenant à un-e abonné-e. Câble critique puisqu'il y a interruption du service d'un membre de l'association.

• Câbles électriques :
  • Blanc : relié à la première arrivée électrique.
  • Noir : relié à la deuxième arrivée électrique.

• Notre demi-baie a une contenance standard de 21U.
• À la mi-juillet 2016, nous utilisions 10U (2 pour les arrivées de câbles venant de l'extérieur, 6 pour l'infra d'ARN, 2 pour l'hébergement de petits serveurs d'abonné⋅e⋅s).
• Mi-décembre 2017, une machine 1U de housing a été rajoutée.
• Il reste donc 10U libres.

L'homogénéité simplifie l'administration mais ce que nous recherchons, c'est la montée en compétence et la redondance. Or, tous les assembleurs ont des concepts différents (installer des rails Dell n'a rien à voir avec des rails IBM, ILO versus iDrac,…) et tous les assembleurs ont connus une période durant laquelle leurs machines n'étaient pas fiables/optimales.

Exemples :

• La BMC de notre machine HP fait des caprices, pas celle de notre Dell. Voir : http://shaarli.guiguishow.info/?ZtZvYg
• Notre ancienne infrastructure, mutualisée avec LDN, était entièrement basée sur Supermicro donc nous avons été impacté par un problème d'horloge défectueuse ainsi que par la virtualisation KVM qui s'emballe.

Car il faut savoir s'arrêter. :)

Pour les SSD : un mauvais SSD castre littéralement les performances d'une machine à tel point qu'un des admins ARN a déjà connu plusieurs cas où il valait mieux remplacer le SSD foireux par un HDD 7200 rpm pour sauver les performances… Un admin connaissait le modèle de SSD que nous avons choisi et son efficacité/comportement aussi bien en solo qu'en RAID 0. Nous voulions donc limiter les risques en optant pour un modèle connu en interne.

Pour le CPU : bien que KVM est une abstraction, un des admins ARN a déjà connu des cas où la migration à chaud de machines virtuelles KVM permise par Ganeti échoue quand le CPU de l'hyperviseur source et celui de l'hyperviseur de destination sont de marques différentes. Là aussi, nous ne voulions prendre aucun risque.

Le choix d'un seul modèle de CPU parmi les gammes d'Intel est déjà plus discutable mais disons qu'un bug dans le microcode serait connu donc on aurait trouvé des traces sur le web avant d'acheter.

Nous avons fait avec le matériel que nous avons pu récupérer. C'est avec grand plaisir que nous aurions utilisé du Juniper (un des admins ARN en est fan) ou autre chose.

Visiblement, d'autres équipementiers ont des trous de sécurité à l'instar de ceux découverts fin 2015 dans certains pare-feux Juniper et Fortinet. :)

Nous envisagerons un switch libre voire open hardware lorsque l'achat d'un switch gigabit deviendra nécessaire. En attendant, le budget de l'association ne nous permet pas d'envisager de virer nos switchs Cisco de récup'.