Hébergement de serveurs de jeu sur bare metal

Un serveur de jeu dédié sur bare metal est une machine physique qui exécute vos processus de jeu directement sur le CPU, sans hyperviseur intermédiaire et sans autre locataire en concurrence sur les mêmes cœurs. Vous disposez de chaque cycle d’horloge que la puce peut produire et d’un accès root complet pour installer tout ce dont le jeu a besoin.

Pour les jeux, cela compte davantage que pour la plupart des charges de travail. Un tick de jeu a une échéance fixe : à 20 ticks par seconde, un serveur Minecraft dispose de 50 millisecondes pour simuler le monde entier avant le tick suivant, et un seul thread en fait l’essentiel. Un hébergement partagé ou virtualisé vous donne une fraction de cœur et un voisin capable de vous la prendre au mauvais moment. Le bare metal supprime ces deux variables.

Nouveau dans l’exploitation de vos propres machines de jeu ? Consultez notre guide pour faire tourner des serveurs de jeu sur bare metal.

Pourquoi le bare metal l’emporte sur une VM pour les serveurs de jeu

Le goulot d’étranglement de presque tout serveur de jeu est la performance CPU mono-thread. La boucle de simulation principale, la physique, les ticks d’entités et la génération du monde tournent sur un cœur, et ajouter des cœurs n’y change rien. Ce qui aide, c’est une fréquence plus élevée et un CPU qui ne partage son cache et sa bande passante mémoire avec personne.

Une machine virtuelle ne vous offre aucune de ces deux garanties. L’hyperviseur planifie votre vCPU face à d’autres invités, les fréquences boost sont plafonnées ou masquées, et un voisin bruyant qui sature la bande passante mémoire se traduit dans votre jeu par des saccades et des ticks perdus alors même que votre propre graphe CPU paraît au repos. Sur bare metal, la fréquence est à vous, le cache est à vous, et les temps de tick restent plats sous la même charge.

• Fréquence boost pleine, maintenue sous charge soutenue plutôt que bridée à un plafond partagé
• Aucun steal time : l’ordonnanceur ne met jamais votre simulation en pause pour exécuter la VM d’un autre
• Cache et bande passante mémoire dédiés à vos processus, si bien que le timing des frames et des ticks reste prévisible
• Accès root pour épingler les threads, régler le noyau et passer le gouverneur CPU en performance

Ce à quoi le matériel convient

Il s’agit de bare metal non infogéré. Vous installez et faites tourner les serveurs de jeu vous-même ; nous vous remettons la machine, le réseau et root. Les configurations à haute fréquence correspondent proprement aux jeux que les gens hébergent réellement :

• Réseaux Minecraft, d’un simple serveur Paper à une proxy Velocity ou BungeeCord desservant une douzaine de backends
• Titres de survie et bac à sable comme Rust, ARK: Survival Ascended, Valheim et Palworld, qui s’appuient fortement sur un cœur rapide par instance
• Shooters compétitifs comme CS2, où le timing des ticks et subticks dépend de la capacité du CPU à terminer chaque frame à l’heure
• Des panels comme Pterodactyl et son fork Pelican, qui transforment une machine en un hôte en self-service pour de nombreuses instances de jeu

Non infogéré, et c’est justement l’intérêt

Rien de tout cela n’est exploité par nous à votre place. C’est ce dans quoi une machine mono-locataire rapide excelle, et avec root vous installez exactement les versions, mods et panels que vous voulez, selon votre propre calendrier, sans qu’un panneau de contrôle en décide pour vous.

Choisir un CPU pour un serveur de jeu

Partez de la fréquence. L’AMD Ryzen 9950X et le 7950X montent tous deux à 5,7 GHz en boost, aussi rapides que tout ce que nous avons en stock, et c’est pourquoi ils sont en tête de la liste ci-dessus. Seize cœurs suffisent largement à faire tourner plusieurs instances côte à côte ; c’est la fréquence qui décide du ressenti de chacune pour les joueurs.

Les pièces EPYC à grand nombre de cœurs sont le mauvais outil ici. Un EPYC 9354P à 32 cœurs l’emporte sur le débit agrégé pour des conteneurs ou des bases de données, mais chaque cœur individuel est plus lent, si bien qu’un unique serveur de jeu chargé y tourne moins bien que sur un Ryzen. Ne visez un grand nombre de cœurs que lorsque vous entassez des dizaines de petites instances et qu’aucune n’est limitée par le CPU.

Associez le CPU à assez de RAM pour votre nombre d’instances et à du NVMe pour des E/S de monde et de chunks rapides. Une douzaine de serveurs Minecraft moddés veut bien plus de mémoire qu’un seul monde vanilla, alors dimensionnez la RAM selon les instances prévues plutôt que selon le nombre de cœurs.

Réseau, latence et rester en ligne sous attaque

La latence, c’est la géographie plus le routage. Un serveur dans la mauvaise région ajoute un temps d’aller-retour qu’aucun CPU ne peut rattraper, alors placez la machine près des joueurs : pour une base de joueurs européenne, cela signifie notre emplacement d’Amsterdam. Vérifiez vous-même le chemin réel depuis notre looking glass avant de vous engager.

Tout tourne sur notre propre réseau, AS55285, avec une mitigation DDoS permanente inline devant l’interface publique. Les serveurs de jeu sont une cible fréquente, et les profils ici sont conçus pour garder les ports de jeu UDP répondant à travers un flood volumétrique plutôt que de blackholer votre adresse pour protéger tous les autres. Vous contrôlez vous-même les règles de pare-feu et de mitigation, si bien qu’ouvrir une plage de ports pour un nouveau jeu ou en resserrer une pendant une attaque n’attend pas un ticket de support.

Réseau privé pour les topologies multijoueur

Un réseau multijoueur est rarement une seule machine. Le réseau privé entre vos serveurs vous permet de placer une proxy, un front Velocity ou BungeeCord pour Minecraft, sur l’interface publique et de garder les serveurs de jeu backend sur un segment privé que les joueurs ne peuvent pas atteindre directement. Une DMZ client n’expose que la proxy tandis que la réplication, le RCON et le trafic backend restent entièrement hors de l’internet public.

Réinstallation et netboot entre les déploiements

Comme le provisioning est en moins d’une minute, une machine est jetable au sens utile : effacez-la et redéployez une image propre entre deux déploiements de jeu, ou utilisez une configuration iPXE personnalisée pour démarrer par netboot une image préparée avec votre panel et vos fichiers de jeu déjà intégrés, y compris un root sans disque uniquement en RAM si vous ne voulez rien écrire sur le stockage local. Pour tout autre support amorçable, le montage d’ISO via la console KVM vous laisse installer à la main et suivre le démarrage.