PolyLAN : l'envers des cores

La 23ème édition de PolyLAN s’est terminée le lundi de Pâques après 4 jours de compétition intensive. Plus de 800 adeptes de jeux en réseau se sont rassemblés au niveau du Garden du tout nouveau centre de congrès de l’EPFL, chacun avec son ordinateur, ses jeux et son sac de couchage. Un rassemblement hors du commun –le plus grand de Suisse - qui a nécessité une organisation technique minutieuse. En effet, les défis ne manquaient pas. Il s’agissait tout d’abord de la première édition de cette envergure, la polyLAN accueillant habituellement 400 joueurs deux fois par année. Cette fois, plus du double ! Et le nouveau centre de congrès se tenait à peine sur ses jambes que déjà on lui demandait de danser au rythme de centaines de connexions simultanées. Une véritable prouesse de la part des organisateurs de l’évènement, des services de l’EPFL concernés – DII Exploitation et DIT Réseau – et de la nouvelle équipe en charge du STCC, surtout lorsque l’on sait que les besoins journaliers en bande passante de PolyLAN équivalent aux besoins journaliers de tout le campus de l’EPFL !

Une LAN, ça consomme

Rassembler 800 gamers dans une même salle, c’est tout d’abord fournir de l’électricité à autant d’ordinateurs. Selon Joël Pittet, chef adjoint du DII Exploitation et responsable de la coordination avec PolyLAN, il a fallu fournir à la manifestation une capacité électrique de 400 ampères, l’équivalent en électricité d’un immeuble de 80 appartements. Ce courant a ensuite été divisé en 3 niveaux de distribution, qui alimentaient 50 sous-tableaux électriques pour un total de 600 multiprises. Cette importante installation temporaire a nécessité l’installation d’un grand nombre de câbles d’alimentation et une sécurité électrique en béton armé. Un challenge intéressant selon Joël Pittet, d’autant plus que les équipements neufs n'avaient évidemment pas encore pu être testés dans leurs limites. Les électriciens et ingénieurs qui travaillaient sur place se disaient souvent : « Si ça doit péter, c’est maintenant ».

Réseau et défi architectural

Pour pouvoir jouer en ligne, une simple connexion internet suffit. Mais pour que 800 personnes puissent s’affronter en même temps, les besoins en bande passante atteignent des sommets. Robert Ritter est informaticien au DIT et fait partie de l’équipe en charge du réseau informatique de l’EPFL. « Le centre de congrès offre un réseau câblé d’une bande passante de 50 Mbit/s géré par Swisscom, ce qui n’était clairement pas suffisant pour les membres du comité de PolyLAN. Selon eux, il fallait un minimum de 4Gbit/s. Du coup, l’EPFL a accepté de participer et nous leur avons fourni la liaison par fibre optique qu’ils demandaient, plus 4 Gbit/s en backup. Et nous leur avons également proposé un service de piquet ». Et en analysant les flux du weekend de la manifestation, le service de piquet a constaté que le flux journalier en entrée a été triplé par rapport à celui d’un weekend normal, ce qui correspond à un jour de semaine bien chargé pour l’ensemble de l’EPFL.

Bénéficier d’une large bande passante est une condition nécessaire pour le bon fonctionnement d’une LAN, mais il faut pouvoir la distribuer correctement. « Le nœud du problème est de trouver une architecture réseau qui marche. C’est le souci principal ! Il faut tout d’abord avoir accès à du matériel de qualité et ensuite le configurer correctement », affirme Yann Beaud, le président de PolyLAN. La première condition a été remplie notamment grâce à la participation de CISCO, leur partenaire technique, qui a prêté aux organisateurs quelques 1,8 millions de francs de matériel. La deuxième condition, elle, fut étudiée et mise au point par les meilleurs spécialistes réseaux de l’association (Pour les détails, lire ci-après l’interview d’Etienne Ischer, Co-responsable technique du réseau de PolyLAN). « Mais au final, tout s’est relativement bien déroulé. Nous avons eu quelques problèmes durant la première journée, mais ensuite tout a bien fonctionné » conclut Yann Beaud, visiblement satisfait.

Si cette édition spéciale a nécessité une enveloppe exceptionnelle de 150'000 francs, le budget annuel moyen de l’association s’élève à quelques 70'000 francs. Un montant malheureusement insuffisant pour permettre aux prochaines éditions de se dérouler à nouveau au SwissTech Convention Center.

------------------------------------------------------------

INTERVIEW technique

Etienne Ischer, Co-responsable technique du réseau de PolyLAN

Comment fait-on pour connecter 1'000 joueurs durant un event tel que PolyLAN?
Une des premières problématiques était de choisir la meilleure architecture autant physique que logique. 1'000 joueurs, cela demande un grand besoin en bande passante vers internet, mais cela signifie également des liaisons potentiellement longues entre le cœur du réseau et le switch le plus éloigné. Pour ces deux raisons, nous avons choisis d'interconnecter nos équipements avec de la fibre optique 10Gb. Et pour éviter d'avoir à tirer des fibres trop longues nous avons opté pour un réseau sur trois niveaux, soit core / distribution / access. Ainsi, grâce à deux paires de fibres, le cœur du réseau (composé de deux switches Cisco 6504-E) était relié à chacune des 7 distributions (Cisco 4500) et celles-ci étaient reliées à chacun des 60 switch access (Cisco 3750x) avec une fibre. Avec ce design, nous avions 10G de bande passante par switch d'accès et 20Gb par distribution ce qui fait que nous avons eu aucun problème de bande passante durant l'évènement.

Concernant l'aspect logique, nous avons séparés les joueurs en 4 VLAN différents. La raison principale est de limiter les différents types de broadcasts. Les jeux génèrent un grand nombre de trafic et nous avons ainsi pu le limiter. Pour tous les jeux qui utilisent le broadcast pour découvrir des serveurs en LAN, nous avons autorisés leurs ports respectifs pour que cela fonctionne entre les différents VLAN.

La seconde raison est que cette configuration permettait plus facilement de répartir les charges (load balancing) sur différentes IP de sorties. En effet, une seule IP ne suffit pas à natter 1'000 personnes. Nous avons donc alloué une IP public par VLAN de joueur et ça a juste suffit. Une des adresse avait ~60k d'entrées NAT en moyenne.

Au niveau de l'authentification, comment faire pour s'assurer que seul les joueurs autorisés puissent avoir accès au réseau?
Il nous fallait un système qui puisse fonctionner quel que soit le système d'exploitation. Nous avons donc choisis d'utiliser 802.1x. Cette norme est déjà utilisée dans plusieurs endroits et elle a l'avantage d'être utilisable sur n'importe quel système d'exploitation. Nous avons donc mis en place l'infrastructure nécessaire pour qu’un username et un mot de passe soit demandé lorsqu’une personne se connecte au réseau. Ceux-ci correspondaient évidemment à ceux demandés aux joueurs pour s'inscrire à l'event. Une fois l’authentification réussie, le poste obtient une IP et peut avoir accès au serveur en LAN et à internet. Dans le cas contraire, le port sur lequel il est connecté étant bloqué, il ne pouvait rien faire.

Pour les machines ne supportant pas l'authentification par 802.1x (consoles de jeux principalement), nous avons mis en place un autre système. Avant de demander à la personne connectée ses identifiants, le switch va envoyer une requête sur le serveur RADIUS afin de savoir si l'adresse MAC est autorisée à se connecter (MAC Address Bypass). Si tel est le cas, le port est débloqué et la machine obtient une adresse, dans le cas contraire, il lui demande ses identifiants. Ce système permet aux machines ne gérant pas le 802.1x de se connecter sans qu'aucune modification ne soit apportée à la configuration du switch. Il suffit donc d'avoir une interface web permettant facilement d'ajouter une adresse mac à la liste des adresses autorisées.

Et comment s’assurer que le réseau va fonctionner correctement?
Avec autant de liens internes et autant d'équipements, il nous fallait un système de monitoring complet pour s’en assurer. Nous avons donc utilisé principalement deux outils : Observium pour la surveillance SNMP, les différents graphes et les alertes ; et Logstash pour la gestion des syslog. Grâce à ces 2 outils, il était facile de savoir si un ventilateur ne fonctionnait plus, si une fibre était défectueuse ou encore l'état d'utilisation de n'importe quel lien du réseau.