Interview de César Jacquet sur la partie technique

< Draltahn > Tout le matériel est situé dans un grand local à Paris c'est bien ça?
< César > Oui, deux salles sont en région parisienne.

< Draltahn > Quel type de pc utilisez-vous dans le cluster comme base ? Est-ce que ce sont des PC spécifiques ou relativement communs?
< César > Plusieurs armoires de Bi-Xéon, est-ce commun ?

< Draltahn > Entre tous les éléments du cluster, il y a des éléments actifs (un élément actif dans un réseau est un élément qui permet à l'information de circuler dans le réseau, il ne comprend pas de câbles qui sont des éléments passifs) pour faire transiter les infos?
< César > Bien entendu, au delà des serveurs, la colonne vertébrale d'une salle machine est son architecture réseau. Nous avons pour celle-ci des contraintes importantes de tolérance aux pannes, en plus des traditionnels soucis de dimensionnement. Nous avons des fonds de paniers au niveau des commutateurs qui tiennent la charge, mais un cluster de cette taille ne souffre pas l'erreur !
Le contexte est assez pénible pour eux car ils reçoivent un grand nombre de petites trames, ce qui coûte généralement cher en temps machine. Dans notre cas, c'est la puissance de commutation qui prime sur la bande passante et cela demande du très haut de gamme.

< Draltahn > Tous les PC sont reliés par de la FO (Fibre Optique) à 2Gbit? (Il me semble que c'est celle qui a le plus gros débit, mais je ne suis pas sûr)
< César > Les liens internes entre les machines de chaque étage des clusters ne seront pas en FO, la liaison cuivre étant bien plus pratique et adaptée. La fibre n'est pas la panacée sur des liaisons courtes en milieu protégé. Par contre, les connexions Télécoms sont en effet en fibre redondée.

< Draltahn > C'est du 1gbit comme cuivre alors?
< César > Oui, mais sur pas mal de liaisons, nos spécifications et nos benches montrent que du 100Mb est bien suffisant, car ce sont les CPU des serveurs qui seront le goulot d'étranglement ! Pas la peine de gaver les switches de liaisons vides.

< Aldéric > En effet.
Au niveau des interventions techniques en cas de panne, cela se passera comment ? On a déjà vu des HDD crasher chez les concurrents avec pour résultat des grosses indisponibilités, voire des retours en arrière. Comment gérerez-vous ce genre de problème ?
< César > Notre politique est de banaliser toutes les unités du cluster, de façon à les remplacer en hot plug. Notre logiciel serveur permet de déconnecter un élément du cluster à chaud et nous n'avons pas de disques de données sur les unités :)
< Aldéric > Dans ce cas, comment stockez-vous les programmes ?
< César > Sur un autre cluster de mastering et de bootstrap, les config sont uploadées au boot des unités, de façon à ne pas se préoccuper de l'installation des serveurs.
< Aldéric > Cela ne risque pas de créer des latences ? Quand les serveurs vont-ils chercher des données ?
< César > Au boot, avant que le joueur n'utilise l'unité en question.

< Aldéric > Admettons que vous n'ayez pas de HDD de données directement sur vos serveurs, vous devez bien avoir une base de données, pour les comptes joueurs etc. En cas de crash de cette base ou d’un système hard la gérant, par exemple, qu'avez-vous prévu ?
< César > Nous avons effectivement une base de données sur l'étage SQL de la ferme de serveur. Mais si cela arrive, car il faut en effet prévoir les situations les plus catastrophiques, on basculera sur une autre salle.

< Aldéric > Vu que vous serez loin des locaux qui sont situés à la Réunion, je suppose que vous avez une succursale à Paris en cas de gros problème technique?
< César > En effet, nous avons des moyens humains sur place.

< Aldéric > Dans un autre registre, certains jeux ont des maintenances (techniques et software) tous les jours, d'autres n'en ont que si nécessaire. Que prévoyez-vous à ce niveau ?
< César > Nous voudrions avoir un rythme régulier pour les patches, car c'est important pour les joueurs et ça a un fort impact sur le rythme et la vie du jeu. Mais nous discutons encore de sa fréquence...

< Draltahn > Avez-vous une partie qui gère la répartition de la charge entre tous les éléments ou c'est fait de manière logiciel entre chaque PC?
< César > C'est matériel sur les premiers niveaux, mais surtout conceptuel au niveau soft, l'équilibrage de charge est au centre de l'évolution du trafic des données au sein du cluster.

< Draltahn > Vous êtes relié à plusieurs backbones publics ou à un seul?
< César > Il est capital à ce niveau de ce débit, de se doter de toutes les garanties. Nous avons en effet plusieurs backbones afin de couvrir au mieux les différentes plaques internationales.

< Aldéric > Au niveau des plateformes de Download, les mises à jour client sont souvent la cause de gros ralentissements, vous avez prévu quelque chose de spécial ?
< César > Notre politique est de déléguer à nos partenaires, qui eux nous proposent un réseau de sites miroirs privés.

< Aldéric > Ok, et donc l'architecture de DL intégrée dans le launcher prendrait en compte ces différents miroirs ?
< César > C'est en effet l'idée.

< Aldéric > Tu penses que l'architecture pourra supporter des rencontres de plusieurs centaines de personnes, où il faut renvoyer a chacune de ces personnes les infos des centaines autres ? Prenons un exemple : une rencontre à 200 personnes implique que les 200 personnes reçoivent les infos des 199 autres. Donc un volume 199 fois plus important pour 200 personnes, le tout simultanément.
< César > L'architecture est faite pour. Nous avons des méthodes de "niveaux de détails réseau" en fonction de la densité et de la distance … Je ne peux pas en dire plus ! Les tests en " live " de montées en charge seront l'épreuve du feu final ... mais au delà de ça, il y a les choix du jeu et du Game Design qui compliquent la chose ...

< Aldéric > Sur le site d'Alchemic ils indiquent qu’ils vous hébergent
< César > Non, mais nous avons des partenaires en commun :-)

Merci à César d'avoir répondu à nos questions qui j’espère répondront à la plupart des nombreuses questions que vous vous posez. :)