Héberger plusieurs serveurs de jeu sur un serveur dédié Xeon Gold : FiveM, Minecraft, Rust

Un serveur dédié 40 coeurs pour héberger des serveurs de jeu

Héberger un seul serveur FiveM, Minecraft ou Rust sur un serveur dédié bi-processeur 40 coeurs serait un gaspillage de ressources. L'intérêt de cette puissance de calcul, c'est de faire tourner plusieurs serveurs de jeu isolés sur la même machine physique, chacun avec ses propres coeurs CPU, sa mémoire réservée et ses ports réseau dédiés.

Ce guide explique comment répartir des instances FiveM, Minecraft et Rust sur un serveur dédié Intel Xeon Gold chez ElypseCloud (2 x Xeon Gold 6230, 40 coeurs / 80 threads, 2,1 GHz de base, 3,9 GHz en turbo, de 32 à 512 Go de RAM DDR4 ECC). Il couvre l'épinglage CPU, l'allocation mémoire, la gestion via Pterodactyl et les contraintes réseau. Pour le détail des caractéristiques du processeur, consultez la fiche technique du Xeon Gold 6230.

Serveurs de jeu et fréquence CPU : le thread principal

Un point essentiel pour dimensionner un serveur de jeu : la boucle de jeu (tick loop) s'exécute sur un seul thread principal. C'est le cas de FiveM (FXServer), de Minecraft Java Edition et du serveur Rust (RustDedicated). La performance d'une instance individuelle dépend principalement de la fréquence d'un coeur, pas du nombre total de coeurs.

Le Xeon Gold 6230 affiche une fréquence de base de 2,1 GHz et monte à 3,9 GHz en Turbo Boost sur un nombre réduit de coeurs. En pratique, le turbo ne s'applique que si les conditions thermiques et la charge globale le permettent. C'est une fréquence honnête pour du serveur de jeu, mais elle ne rivalise pas avec un processeur desktop cadencé à 5 GHz en single-thread.

L'avantage du 40 coeurs n'est pas la vitesse d'une instance. C'est la capacité à faire tourner beaucoup d'instances isolées en parallèle, chacune épinglée sur ses propres coeurs physiques, sans qu'elles se disputent les ressources CPU. Un serveur de jeu qui lag n'impacte pas les autres.

Combien d'instances sur 40 coeurs

La répartition dépend du profil de chaque serveur de jeu. Un serveur FiveM RP avec beaucoup de scripts Lua consomme plus de CPU qu'un serveur Minecraft vanilla. Un serveur Rust avec 200 joueurs et des mods Oxide sollicite plus de mémoire qu'un serveur Rust vanilla 50 joueurs.

Le principe de base est simple :

• 2 à 4 coeurs physiques par instance (le thread principal + les threads secondaires pour le réseau, les I/O disque, les tâches de fond) ;
• Réserver 2 à 4 coeurs pour le système d'exploitation (Linux, panel Pterodactyl, base de données, sauvegardes) ;
• Le reste se répartit entre les instances de serveurs de jeu.

Avec 40 coeurs physiques (80 threads avec Hyper-Threading), après réservation système, il reste 36 à 38 coeurs utilisables pour les serveurs de jeu. Cela permet de faire tourner entre 8 et 15 instances selon la charge de chaque serveur, sans surallocation CPU.

Le facteur limitant est souvent la RAM, pas le CPU. Un serveur FiveM RP chargé peut consommer 4 à 8 Go de RAM. Un serveur Minecraft moddé avec Forge ou Fabric peut dépasser 6 Go. Un serveur Rust vanilla avec une carte de taille standard occupe 6 à 12 Go. Avec la configuration SD2-G-64 (64 Go de RAM), comptez 4 à 6 instances confortables. Avec la SD3-G-128 (128 Go), 8 à 12 instances. Avec la SD4-G-256 (256 Go), la RAM cesse d'être le facteur limitant.

FiveM : ce qui consomme sur un serveur RP

Un serveur FiveM (FXServer) exécute sa boucle de jeu principale sur un seul thread. La charge CPU dépend directement du nombre de scripts Lua/JS chargés, du nombre d'entités synchronisées et du nombre de joueurs connectés. Les threads secondaires gèrent le réseau et la synchronisation des entités.

En termes de ressources par instance :

• CPU : 2 à 3 coeurs physiques (1 pour le tick loop + 1-2 pour le réseau et les scripts asynchrones) ;
• RAM : 2 Go pour un serveur léger, 4 à 8 Go pour un serveur RP chargé avec ESX/QBCore, des MLO, des véhicules custom et une base de données MySQL locale ;
• Réseau : port TCP+UDP unique par instance (par défaut 30120), configurable.

Sur un serveur dédié Xeon Gold avec 128 Go de RAM, vous pouvez raisonnablement isoler 5 à 8 instances FiveM, chacune avec son propre répertoire txAdmin, sa base de données et ses ports. Consultez notre guide VPS ou serveur dédié pour un serveur de jeu pour déterminer si un dédié est adapté à votre cas.

Minecraft : Java Edition et mods

Le serveur Minecraft Java Edition (vanilla, Spigot, Paper, Fabric, Forge) repose sur un tick loop monothread de 20 ticks par seconde. Les versions récentes de Paper exploitent des threads secondaires pour les I/O réseau et le chargement de chunks, mais la logique de jeu reste monothread.

Ressources par instance :

• CPU : 2 à 3 coeurs physiques ;
• RAM : 2 Go minimum pour un serveur vanilla, 4 à 8 Go pour un serveur moddé (Forge, Fabric avec mods de contenu). Le flag JVM -Xmx contrôle la taille maximale du heap ;
• Réseau : port TCP 25565 par défaut, un port différent par instance.

Un avantage de Minecraft : les instances sont légères en réseau. La bande passante de 1 Gbit/s incluse dans les serveurs dédiés ElypseCloud suffit largement pour des dizaines d'instances Minecraft simultanées.

Rust : mémoire et I/O

Le serveur Rust (RustDedicated) est le plus gourmand des trois en mémoire et en I/O disque. La taille de la carte, le nombre d'entités construites par les joueurs et les plugins Oxide/Carbon influencent directement la consommation.

Ressources par instance :

• CPU : 3 à 4 coeurs physiques (le thread principal est très sensible à la fréquence, les threads secondaires gèrent le réseau, la sauvegarde et les mods) ;
• RAM : 6 à 12 Go selon la taille de la carte et le nombre de joueurs. Un serveur Rust avec une carte procédurale de 4000 et des plugins lourds peut dépasser 10 Go ;
• Stockage : les sauvegardes automatiques de Rust écrivent plusieurs centaines de Mo à chaque cycle. Un SSD est indispensable pour éviter que les sauvegardes ne provoquent des freezes perceptibles en jeu ;
• Réseau : port UDP 28015 par défaut + port RCON 28016.

Rust est le jeu qui limite le plus la densité d'instances. Sur 128 Go de RAM, 3 à 5 serveurs Rust est un objectif réaliste. Combiné avec des instances FiveM ou Minecraft moins gourmandes, le dédié prend tout son sens.

Tableau récapitulatif par jeu

Ces fourchettes sont des ordres de grandeur pour du dimensionnement. La consommation réelle dépend du nombre de joueurs connectés, des mods installés et de la configuration de chaque serveur. Surveillez les ressources après le déploiement avec htop ou btop.

Gérer les instances avec Pterodactyl

Pterodactyl est un panel open source conçu pour gérer plusieurs serveurs de jeu depuis une interface web. Son architecture Panel + Wings isole chaque instance dans un conteneur Docker, ce qui simplifie le déploiement, la mise à jour et la surveillance des serveurs.

Sur un serveur dédié Xeon Gold, Pterodactyl permet de :

• Créer des instances FiveM, Minecraft et Rust depuis l'interface web avec des eggs préconfigurés ;
• Attribuer une limite CPU et RAM par instance (Wings utilise les cgroups Docker) ;
• Accéder à la console de chaque serveur de jeu sans SSH ;
• Planifier des tâches (redémarrages, sauvegardes) par instance ;
• Déléguer l'accès à des administrateurs de serveur sans leur donner le root.

Pour l'installation complète de Pterodactyl, consultez notre guide Pterodactyl : installer un panel pour gérer ses serveurs de jeu. Le guide couvre l'installation du Panel, de Wings, la configuration des noeuds et la création des premiers serveurs.

Épinglage CPU : isoler les coeurs par instance

Par défaut, le scheduler Linux répartit les processus sur tous les coeurs disponibles. Pour des serveurs de jeu, cette répartition automatique n'est pas idéale : le thread principal d'un serveur FiveM peut se retrouver en compétition avec celui d'un serveur Minecraft sur le même coeur.

L'épinglage CPU (CPU pinning) force chaque instance à n'utiliser que des coeurs précis. Deux approches :

Via Docker et Pterodactyl

Wings utilise Docker sous le capot. Vous pouvez définir l'option --cpuset-cpus dans la configuration Docker de chaque conteneur pour restreindre les coeurs utilisables :

# Exemple : instance FiveM sur les coeurs 0 à 3
docker update --cpuset-cpus="0-3" pterodactyl-fivem-01

# Instance Minecraft sur les coeurs 4 à 6
docker update --cpuset-cpus="4-6" pterodactyl-mc-01

# Instance Rust sur les coeurs 7 à 10
docker update --cpuset-cpus="7-10" pterodactyl-rust-01

Via taskset (hors Docker)

Si vous lancez vos serveurs de jeu sans conteneur, taskset permet d'épingler un processus au lancement :

# Lancer un serveur FiveM sur les coeurs 0 à 3
taskset -c 0-3 ./run.sh +exec server.cfg

Sur un serveur bi-processeur, tenez compte de la topologie NUMA. Les coeurs 0 à 19 appartiennent au premier processeur (noeud NUMA 0) et les coeurs 20 à 39 au second (noeud NUMA 1). Épinglez chaque instance sur des coeurs du même noeud NUMA pour que les accès mémoire restent locaux. Un serveur de jeu qui accède à la mémoire de l'autre noeud NUMA subit une latence supplémentaire mesurable. Notre guide comprendre NUMA sur un serveur dédié bi-processeur détaille cette architecture.

Allocation mémoire et surveillance

Chaque instance de serveur de jeu doit avoir une enveloppe mémoire clairement définie. Pterodactyl permet de fixer une limite RAM par conteneur via les cgroups Docker. Si une instance dépasse sa limite, le noyau Linux tue le processus (OOM kill) plutôt que de laisser la machine entière devenir instable.

Quelques règles pour l'allocation :

• Réservez 4 à 8 Go pour le système (Linux, Pterodactyl Panel, MariaDB, Wings, sauvegardes) ;
• Attribuez la RAM restante aux instances en fonction du jeu et de la charge attendue ;
• Gardez une marge de 10 à 15 % de RAM libre pour absorber les pics ;
• Surveillez avec htop, btop ou free -h après le déploiement.

Exemple de répartition sur un SD3-G-128 (128 Go de RAM) :

Cet exemple laisse 64 Go de marge pour ajouter des instances ou absorber les pics de consommation. Adaptez les allocations après observation de la charge réelle.

Réseau : ports, bande passante et anti-DDoS

Chaque instance de serveur de jeu écoute sur un ou plusieurs ports distincts. Ouvrez uniquement les ports nécessaires avec UFW ou nftables (guide UFW pour serveurs de jeu).

Points réseau à retenir :

• Les serveurs dédiés Xeon Gold ElypseCloud incluent une bande passante de 1 ou 10 Gbit/s, IPv4 + IPv6 et la protection anti-DDoS, indispensable pour des serveurs de jeu exposés ;
• Chaque instance utilise des ports différents. Planifiez vos plages de ports à l'avance (par exemple : 30120-30129 pour FiveM, 25565-25574 pour Minecraft, 28015-28024 pour Rust) ;
• Pterodactyl gère automatiquement l'attribution des ports lors de la création d'un serveur ;
• Pour un serveur FiveM, le port doit être ouvert en TCP et UDP. Pour Rust, le port de jeu est en UDP et le RCON en TCP.

Quelle configuration choisir

Toutes les configurations de la gamme Xeon Gold ElypseCloud embarquent les mêmes 2 x Intel Xeon Gold 6230 (40 coeurs / 80 threads). La différence se fait sur la RAM :

Les estimations d'instances sont des ordres de grandeur pour des serveurs de jeu mixtes (FiveM, Minecraft, Rust). La densité réelle dépend de la charge de chaque serveur.

Pour un budget plus serré ou un nombre d'instances plus réduit, la gamme Xeon E5 (16 coeurs / 32 threads) offre un point d'entrée à partir de 80 € TTC/mois, adapté à 2 à 4 serveurs de jeu.

Questions fréquentes

Faut-il Linux ou Windows pour héberger plusieurs serveurs de jeu ?

Linux (Ubuntu 22.04 LTS ou Debian 12) est le choix standard pour l'hébergement multi-instances. Pterodactyl, Docker, les outils d'épinglage CPU (taskset, cgroups) et la gestion NUMA fonctionnent nativement sous Linux. FiveM (FXServer), Minecraft Java et Rust disposent tous de binaires serveur Linux. Windows Server est possible mais consomme plus de RAM système et offre moins de contrôle sur l'isolation des ressources.

Peut-on mélanger des serveurs FiveM, Minecraft et Rust sur le même dédié ?

Oui, c'est précisément l'intérêt d'un serveur dédié 40 coeurs. Chaque instance est isolée dans son conteneur Docker (via Pterodactyl) avec ses propres coeurs CPU, sa limite RAM et ses ports réseau. Un serveur Rust qui consomme beaucoup de mémoire n'affecte pas les performances d'un serveur FiveM sur les mêmes coeurs, à condition que l'épinglage CPU soit correctement configuré.

L'Hyper-Threading est-il utile pour les serveurs de jeu ?

L'Hyper-Threading (SMT) transforme les 40 coeurs physiques en 80 threads logiques. Pour un serveur de jeu, le thread principal ne bénéficie pas significativement de l'HT : il a besoin de la puissance complète d'un coeur physique. Les threads secondaires (réseau, I/O) peuvent en revanche utiliser les threads HT. En pratique, épinglez chaque instance sur des coeurs physiques et laissez les threads HT correspondants disponibles pour les tâches de fond.

Comment surveiller la charge de chaque instance ?

Depuis le panel Pterodactyl, vous voyez la consommation CPU et RAM de chaque serveur en temps réel. Côté système, htop permet de visualiser la charge par coeur et de vérifier que l'épinglage fonctionne correctement (chaque instance ne doit utiliser que ses coeurs assignés). La commande docker stats affiche la consommation de tous les conteneurs Wings.

Conclusion

Un serveur dédié Xeon Gold 40 coeurs ne rend pas un serveur de jeu individuel plus rapide qu'un processeur à haute fréquence. Son avantage est de permettre l'hébergement de nombreuses instances isolées sur une seule machine physique, avec un contrôle fin sur la répartition des ressources CPU et mémoire. Combiné avec Pterodactyl pour la gestion, l'épinglage CPU pour l'isolation et la protection anti-DDoS incluse, c'est une infrastructure solide pour les administrateurs qui gèrent plusieurs communautés de jeu.

Pour sécuriser votre serveur dédié dès la mise en service, consultez notre guide premiers réglages de sécurité sur serveur dédié.