+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Petit guide des serveurs dédiés (/showthread.php?tid=6830)
Pages :
1
2
Petit guide des serveurs dédiés - MadMass - 12-01-2014
Bonsoir,
Je fait un petit retour d'expérience sur les serveurs dédiés et les VPS, à l'attention des néophytes notamment
N'hésitez pas à commenter et à corriger mes erreurs
I. Un serveur dédié, c'est quoi ?
Deux choses importantes : il y a le serveur logiciel, et le serveur physique, la machine qui fait tourner votre serveur logiciel.
Dans de l'hébergement mutualisé, tout est simple : on place ses fichiers sur le FTP, puis on se connecte à l'adresse indiquée, et tout fonctionne. Mais derrière cette simplicité se trouve un serveur, que vous partagez avec de parfaits inconnus clients du même prestataire que vous. Derrière tout site, il y a un serveur; je me baserai sur un jeu web en php pour ce topic.
Un serveur dédié, ça n'est pas si cher que ça : comptez dans les 12€ HT/mois pour un serveur capable de supporter un jeu par navigateur avec php et mysql.
En outre, l'administration, bien que rebutante sous linux en ligne de commande, s'apprend facilement grâce à la profusion de tutoriaux sur le net. Dans ce topic, je parlerais surtout de matériel, cependant certaines distributions comme ubuntu server sont plébiscitées pour leur simplicité.
Vrai dédié ou VPS ?
La question est très intéressante, surtout dans notre cas.
Le serveur dédié est une machine, hébergeant un système d'exploitation (très souvent linux).
Un VPS est une machine divisée en plusieurs serveurs, sur laquelle tourne plusieurs systèmes d'exploitation : c'est de la virtualisation. Les ressources du serveur sont partagées, mais vous administrez votre VPS comme s'il s'agissait d'une véritable machine physique.
Le serveur dédié physique
En louant un serveur dédié, vous louez une véritable machine. Cela a ses avantages, et ses inconvénients.
Avantages :
- Les ressources sont garanties : vous êtes sûr de pouvoir disposer de toute la puissance de votre machine.
- Les performances d'un serveur dédié sont légèrement supérieures à celles d'un VPS à configuration égale. Cela se ressent sur les applications les plus exigeantes, parmi lesquelles MySQL (grand nombre d'accès disque).
- Les prix sont très inférieurs aux VPS : vous pouvez avoir une configuration dédiée bien plus puissante à prix équivalent.
Inconvénients :
- Très faible tolérance aux pannes : votre dédié possède une configuration matérielle qui n'est pas infaillible : si votre jeu fonctionne plusieurs années, vous aurez à coup sûr une panne à un moment ou à un autre. Les plus fréquentes sont celles de disque dur (avec perte de données), de mémoire (entraînant instabilité et crash à répétition des applications et du système), et très rarement de la carte mère (pouvant flinguer tout le système).
- Les dédiés les moins chers sont des dédiés âgés : les pièces sont donc en usage depuis plusieurs années et plus sujettes aux pannes que celles des dédiés haut de gamme.
- Si une panne matériel survient, tout s'arrête. Vous devrez attendre que votre prestataire intervienne, ce qui peut entraîner une indisponibilité de plusieurs heures. Vous devez également sauvegarder toutes les données de façon très régulières.
- Mauvais scaling : il est nécessaire de changer de serveur dès que le jeu a besoin de plus de ressources. C'est fastidieux car il faut tout reconfigurer.
Le VPS
Les VPS ont un prix beaucoup plus élevé que les dédiés, mais ont une tolérance aux pannes bien supérieure !
Avantages :
- Excellente tolérance aux pannes. Les données de vos VPS sont généralement dupliquées sur plusieurs serveurs de stockage.
- En cas de panne, l'indisponibilité dure quelque seconde. Les VPS tournent sur des serveurs qui fonctionnent en grappes, lesquels sont capables de faire passer un VPS d'une machine à l'autre pour pallier aux défaillances matérielles.
- Il n'y a rien que vous ne pouvez faire sur un dédié que vous ne pouvez pas faire sur un VPS. Le fait que le serveur soit virtuel n'impacte en rien votre capacité à le configurer à votre sauce (ou à le flinguer c'est selon
)- C'est géo-localisable chez certains prestataires : votre prestataire peut vous proposer différents lieux d'hébergement de votre VPS pour vous rapprocher au plus près de vos joueurs cible, et ainsi améliorer leur latence.
Inconvénients :
- C'est bien plus cher qu'un dédié à configuration égale
- Les temps d'accès disque sont généralement mauvais. Cela signifie que des applications comme MySQL subiront une perte de performance.
Informations importantes :
- Méfiez vous ! N'importe qui peut vendre du VPS en deux coup de cuillère à pot. Choisissez un prestataire sérieux car le VPS est très opaque : on peut au final cacher ce que l'on veut derrière la configuration mise en avant.
- Faites attention à l'overselling : beaucoup de petits vendeurs de VPS louent des serveurs à de grands hébergeurs, et y mettent plus de VPS que la machine ne pourrait en supporter. Assurez-vous que vous payez pour la configuration vendue.
- Faites attention à la mémoire : elle doit être garantie, sinon, il y a un risque d'overselling.
Que choisir ?
Tout dépend. Le VPS est très intéressant en terme de disponibilité, car vous n'aurez pas à vous inquiéter d'une potentielle panne matérielle. Cependant, si vous devez conjuguer petit budget et grand nombre de joueurs, le serveur dédié physique est plus intéressant.
Quel prestataire ?
Je vous conseille chaudement OVH et sa filiale kimsufi.
Ils proposent des serveurs dédiés à partir de 8€ HT/mois (n'espérez pas faire fonctionner de façon décente un jeu sur ce type de configuration cependant).
A titre indicatif, viser des configurations à partir de 12€. Les serveurs dédiés à base d'Atom N2800 sont très bons pour ce type d'applications.
Site : http://www.kimsufi.com
Notez que online.net propose un serveur d'entrée de gamme dans ce niveau de prix, mais il me semble mauvais, l'explication est fournie plus bas
Pour les VPS, OVH en fait aussi de très bon :
http://www.ovh.com/fr/vps/
Ils ont une très haute tolérance aux pannes, à moins d'un gros problème, ces VPS là ne tombent jamais
II. Le matériel
Vient le point le plus épineux : le matériel.
Ce qui suit concerne autant les serveurs dédiés physiques que virtuels
La mémoire
Pour la mémoire, le minimum syndical est 1go pour héberger une application Web.
2go ne seront pas de trop, et 4go seront vraiment confortables.
Le SWAP
Lorsque la mémoire est pleine, le système d'exploitation, pour continuer à fonctionner, va mettre à contribution une partie du disque dur pour étendre l'espace de stockage de la mémoire. Là, c'est le drame : votre serveur swappe, il devient super lent, plus rien ne marche.
En fait, si le swap est une bonne chose car il permet la continuité du fonctionnement du système, il entraîne un usage intensif du disque dur. Vos applications seront fortement ralenties car elles devront subir le temps de réponse exorbitant du disque (plusieurs millisecondes contre quelques nanosecondes pour la RAM), tandis que le disque sera accaparé par les données censées être stockées en mémoire, ce qui impactera fortement l'usage courant de celui-ci (l'accès aux fichiers). Quand ça swappe, c'est pas bon :'(
C'est là le gros grief des VPS : la mémoire est très restreinte, il faut optimiser au mieux ses codes.
Le processeur
C'est un point très important !
Deux cas de figure se présenteront :
- Lorsque vous serez sur du dédié d'entrée de gamme, le processeur pourra être un facteur limitant, notamment au niveau des requêtes complexes avec MySQL.
- Si vous passez un jour sur du dédié haut de gamme (plus de 40€ HT/mois), les processeurs commenceront à être optimisés pour les serveurs et fonctionneront très bien, ce sera le disque le facteur limitant.
Nombre de coeurs, nombre de threads
C'est une question épineuse !
Les processeurs ont généralement plusieurs cores : ils peuvent traiter plusieurs tâches en même temps. En clair, dans notre cas, deux tâches peuvent être deux joueurs différents.
Plus le nombre de coeurs est élevé, mieux c'est. Votre serveur sera capable de traiter plus de joueurs à la fois (sinon, il y a une sorte de "liste d'attente" pouvant conduire à un timeout si le serveur est surchargé). Les monocoeurs sont à bannir, c'est beaucoup trop lent pour faire de l'hébergement web, c'est trucs là (et c'est valable pour les VPS).
Les threads sont le nombre de coeurs que percevra votre système d'exploitation. Le système d'exploitation voit le nombre de coeurs du processeur et y distribue les tâches à effectuer pour une utilisation optimale de celui-ci. Un processeur à 8 threads fera que le système d'exploitation verra 8 coeurs et agira en conséquence.
Mais 8 threads ne signifie pas 8 coeurs dans le processeur ! Un processeur peut avoir 4 cores et 8 threads, auquel cas il y aura deux threads par coeurs. Cette combine est utile si votre processeur n'est pas pleinement utilisé : il permet de paralléliser des tâches sur un même coeur. En revanche, si votre processeur est en permanence au bord de la saturation, plus d'un thread par coeur aura tendance à le ralentir !
Donc, pour choisir, avec des pincettes :
- Si vous êtes dans le cas du serveur dédié d'entrée de gamme dont le processeur est beaucoup sollicité, préférez un thread par core (par exemple 4c/4t)
- Si vous avez un serveur dédié haut de gamme, préférez deux threads par core. Le processeur étant peu utilisé, cela permettra une bien meilleure parallélisation des tâches (et donc un traitement plus rapide des pages pour vos joueurs).
Ouf !
Fréquences et architectures
Alors là c'est un piège classique : croire que la puissance d'un processeur dépend de sa fréquence.
C'est faux !
Les processeurs sont conçus d'une certaine façon : c'est leur architecture. Certaines sont plus performantes que d'autres, et fonctionnent avec une cadence inférieure. Par exemple, il est courant de trouver des Xeon à 2Ghz, tandis qu'on peut trouver des processeurs AMD à 3.9Ghz à un prix 4 fois inférieur ! Pourtant, le Xeon reste plus puissant car son architecture est plus efficace que celle d'AMD (l'architecture "Bulldozer" d'AMD étant décrié pour la cadence très élevée qu'elle nécessite, ce qui entraîne une chauffe importante du processeur
)Pour avoir une idée fiable, une chose à faire : se référer aux benchmarks, si possible d'un seul et même site. Par exemple, CPUbenchmark fournit des scores pour chaque processeur qui permet de comparer aisément la puissance relative de ceux-ci l'un par rapport à l'autre.
Si je puis vous donner un petit conseil personnel, le Intel Atom N2800 est très bon sur de petits serveurs. Il contrevient à la règle des threads (2c/4t) mais contrairement aux Atom 2c/2t, il a une architecture plus récente qui le rend ainsi beaucoup plus véloce. Il constitue un très bon rapport puissance/prix idéal pour se lancer sur un petit serveur.
Au delà, laissez tomber les Core2Duo et passez directement aux Core2Quad. Chez Ovh, le N2800 est à 13€, le Core2Duo à 16€ et le Core2Quad à 18€. Pour 2€ de plus, vous doublez votre nombre de coeurs, et ce sont des vrais; vérifiez les benchmark avant toute commande.
Le disque dur
C'est important, et ça le deviendra encore plus avec le temps !
Les serveurs de jeu multijoueurs (FPS, voire les serveurs de WoW, par exemple) ont besoin de processeurs surpuissants, car il gèrent de nombreuses actions en un temps relativement court. Mais ces serveurs diffèrent des jeux par navigateur en php : ils stockent énormément de données en mémoire, et la base de données est utilisée quand elle est disponible, sans impact sur l'expérience des joueurs.
Pour un jeu par navigateur, par contre, chaque page chargée est un grand nombre d'appels de base de donnée, de lectures, d'écritures : le stockage devient une notion importante, non pas dans sa capacité mais dans sa disponibilité, il faut un stockage efficace et véloce !
Disque dur ou SSD ?
On se la refait pas, et pour moi : SSD sans hésiter.
Les SSD sont des disques durs en mémoire flash. D'une capacité très inférieure aux disque durs classiques à plateau, ils ont l'avantage d'avoir un accès en lecture très rapide, et une très bonne durabilité ! Quelques pistes pour éclairer tout ça :
Le disque dur est un ensemble constitué de plusieurs plateaux rotatifs superposés et de têtes de lectures/écriture qui les parcourent.
Lorsque l'on cherche à accéder à une information stockée sur le disque dur, il y a un temps d'accès : celui-ci correspond au déplacement de la tête de lecture au bon endroit du plateau, et au temps que met la tête à parcourir le "sillon magnétique" contenant l'information stockée. Sur un disque dur, cela peut prendre plusieurs dizaines de millisecondes qui mises bout à bout, représentent une charge !
Pire : cela entraîne le phénomène dit "d'iowait". L'iowait est le pourcentage du temps que met le processeur à attendre une information du disque dur. Supposons que le processeur traite votre page : il va avoir besoin d'informations provenant du disque dur (notamment venant de la MySQL). Il va donc les attendre, et ce temps passé à attendre sera rapporté sur le temps total mis à traiter la page, et ce sera l'iowait. Avoir un iowait élevé fait que votre processeur tourne dans le vide...
Le SSD, étant des cellules de mémoire flash, a un temps d'accès quasi-instantané car il n'y a pas de mouvement des têtes de lecture à effectuer.
Cependant, on peut réduire les dégâts en utilisant des disques durs ayant une vitesse de rotation plus rapide. La vitesse classique est de 5400 tours/minute, mais les serveurs sont généralement en 7200 tours/minute, ce qui permet une meilleure réactivité que le vieux disque de la maison :p
Donc ce sera SSD sans hésiter.
Cependant, vous ne trouverez pas de serveur à louer avec un SSD à moins de 50€
mais ne désespérez pas ! Si MySQL souffre de la lenteur des disques, ce n'est pas le cas de PHP. PHP, lorsqu'on lance un script, effectue une compilation de celui-ci; cette compilation requiert d'aller chercher les fichiers sur le disque. Une fois faite, elle est stockée en mémoire, et l'usage du disque dur est ainsi réduit.En outre, il y a une astuce permettant d'augmenter la capacité des disques durs
RAID : y'a bon ?
Le RAID est un sujet complexe mais qui peut s'avérer très intéressant.
Le principe est d'utiliser plusieurs disques durs et les faire travailler ensemble afin d'améliorer les performances de la machine, et assurer la sécurité des données. Il en existe plein de types dont voici les principaux :
- Le RAID 0 : à bannir, pas de ça chez nous, beurk. Il consiste à rassembler plusieurs disques durs au sein d'un seul disque virtuel qui aura une capacité égale à la somme de tous les disques qui le composent. Pourquoi c'est pas bon ? Parce que le RAID 0 va disséquer vos fichiers en autant de lamelles que de disques, et les répartir entre eux. Du coup, si vous perdez un seul disque, toutes vos données sont perdues, absolument toutes.
- Le RAID 1 : c'est une réplication. Il réplique les données sur deux disques différents, lesquels ne seront vus que comme un seul disque par le système. Du coup, si l'un des disque lâche, il suffit d'en remettre un neuf pour que les données y soient restaurées, et rien n'est perdu. En outre, le système peut puiser sur les deux disques pour améliorer les capacités de lecture de ceux-ci (par contre, les capacités en écriture restent inchangées). Avoir un MySQL sur un RAID 1 peut donc améliorer ses performances (théoriquement)
- Le RAID 5 : c'est pas évident à comprendre. En fait, il permet comme le RAID 0, de réunir plusieurs disques, mais il assure la protection des données. Si vous avez 4 disques, vous aurez un disque virtuel dont la capacité correspond à la somme des trois premiers, le quatrième sert à garder une sorte de trace des fichiers. Si un des disque lâche, le système est capable de le reconstruire à partir des 3 autres (par contre si deux disques lâchent, tout est foutu).
- Le RAID 10 : c'est un croisement entre le RAID 1 et le RAID 0 : des disques rassemblés et répliqués.
Le RAID n'est PAS un substitut aux sauvegardes, c'est un CONFORT ! Il permet de limiter ou de programmer les changement de disques en cas de soucis. En outre, en cas de panne de disque, vous épargnez un rollback à vos joueurs en ne perdant pas les données que vous aviez.
Le RAID 1 est donc vivement et chaudement conseillé ! (les autres de toute façon sont pas intéressants dans notre cas).
Raid matériel ou logiciel ?
Il y a deux systèmes de RAID distinct :
- Le RAID matériel est lorsque la gestion du RAID est effectuée par un composant intégré au serveur. Aucun prestataire digne de ce nom ne vous proposera un RAID hard pour moins de 80€/mois. Si vous en trouvez un, c'est des cartes RAID de mauvaise qualité qui, en plus de ne pas améliorer les performances en lecture, peuvent les réduire, et peuvent menancer la sûreté de vos données en cas de dysfonctionnement. Le gros avantage du RAID hard est qu'il est possible d'installer le système d'exploitation dessus : vous pouvez répliquer vos partitions système et ainsi, si un disque lâche, le serveur continue à fonctionner.
- Le RAID logiciel est lorsque le système d'exploitation gère le RAID. Il est très répandu. Les avantages du RAID soft sont une meilleure fiabilité, le système vous informant en cas de dysfonctionnement du RAID. Par contre, il peut induire une utilisation supérieure du bus système (canal par lequel transitent les données en cours de traitement au sein de l'ordinateur). Vu que vous ne manipulez pas d'énormes fichier, ça ne se ressent pas.
Le gros inconvénient est qu'il est impossible d'installer un système d'exploitation sur du RAID soft, car c'est le système lui-même qui le gère. Cela signifie que sur l'un de vos deux disque, vous aurez le système, et une partition en RAID sur les deux. Si par malheur le disque qui lâche était celui du système, vous vous prenez un temps d'indisponibilité (mais vos données sont quand même sauvegardées).
Ici il n'y a pas trop de choix de toute façon, vous aurez très probablement que du RAID soft sous la main. Si vous avez moyen d'avoir du vrai RAID hard de qualité foncez, car vous réduisez le risque d'indisponibilité de votre machine.
Le réseau
On n'y pense pas vraiment, mais la bande passante mérite qu'on s'y intéresse.
Il y a deux types de bande passante :
- La "Best Effort" : c'est le débit théorique maximal que vous aurez avec votre serveur. Mais il peut très bien être inférieur en heure de pointe.
- La garantie : vous êtes certain d'avoir la bande passante pour laquelle vous avez souscrit. Il est en outre possible d'avoir plus, mais ce surplus n'est pas garanti.
La bande passante garantie apparaît sur les serveurs vers 40/50€ HT/mois. Avant, ce sera probablement du best effort. Ce n'est pas gênant si vous prenez un prestataire sérieux, et à condition de configurer correctement vos .htaccess afin de mettre en cache les éléments graphiques non-dynamiques sur le PC du joueur.
III. Systèmes d'exploitation et astuces
Pour faire du PHP, linux est un choix idéal car il est rapide et gratuit.
Les distributions
Linux est sous la forme de distributions, des sortes de versions aux caractéristiques différentes.
Je vous conseille Ubuntu ou Debian. Elles sont toutes deux simples à prendre en main.
Les panels
Certains prestataires (dont OVH) proposent des "panels" qui permettent d'administrer simplement son serveur. Ils sont une aide appréciable.
Pour avoir testé chez OVH, ne prenez pas "Release 2" mais directement "Release 3". La release 2 est basée sur Gentoo, une distribution Linux difficile à prendre en main.
La sécurisation
Avoir un serveur dédié représente des responsabilités du point de vue sécurité. Je vous invite à faire des recherche sur les sujets suivants, qui constituent le minimum syndical en matière de sécurité :
- Mise à jour régulières ("sudo apt-get update" suivi de "sudo apt-get upgrade")
- Création d'un compte utilisateur à votre nom avec un mot de passe fort et les droits super-utilisateur ("adduser votrepseudo" puis "adduser votrepseudo sudo")
- Bloquer le "Root Login" en SSH : empêche de se connecter en "root" (super-utilisateur) sur votre machine à distance
- Changer le port de connexion de SSH : par défaut le port 22, il y a des milliers de bots qui scannent les serveurs sur le port 22 pour essayer de les pénétrer
- Installer fail2ban (il bannit pour plusieurs minutes les IP au comportement suspect vis à vis de votre serveur, notamment ceux essayant de deviner votre mot de passe)
- Limiter les accès tiers au serveur
La virtualisation
C'est un sujet vaste et je n'en ferais pas une explication complète ici. Vous pouvez virtualiser votre serveur physique : vous y installez un système d'exploitation dédié à la virtualisation (je vous conseille Proxmox, gratuit), et y créez un VPS dessus qui hébergera votre jeu.
Cela permet d'héberger plusieurs jeux (un VPS par jeu), mais aussi de changer de serveur facilement : si vous commandez un plus gros serveur, vous n'aurez qu'à transférer le VPS sans devoir tout reconfigurer. Vous pouvez également faire des sauvegarde à la volée (snapshots), voire monter une architecture à plusieurs serveurs si le coeur vous en dit.
Pour ceux qui souhaitent creuser le sujet, cherchez du côté du NAT (pour accéder à plusieurs VPS sur une seule adresse IP), du reverse proxy (dont Pound) pour lier un VPS à un domaine sans avoir à acheter d'IP supplémentaire à votre prestataire, et pourquoi pas les techniques avancées de load balancing
Déporter son SQL
Votre jeu augmente en taille et en joueurs, votre serveur sature. Pourquoi payer un serveur plus cher encore qui sera lui aussi limité ?
Déporter son SQL consiste à isoler son serveur MySQL sur une deuxième machine qui lui sera dédiée. Il aura tout le loisir de l'exploiter au maximum et ne subira pas de concurrence avec Apache et PHP au niveau des ressources. Déporter son SQL nécessite d'y apporter certaines modifications (notamment autoriser les connexions externes). Il faut en outre une bande passante suffisante, le SQL déporté en consommant beaucoup.
Déporter son SQL implique aussi certaines mesures de sécurité : l'interception du flux est toujours possible, même au sein d'un datacenter. Je ne parle pas d'espionnage mais bien d'un dysfonctionnement du réseau : le réseau d'un prestataire de serveurs dédié est articulé autour de switchs, lesquels distribuent les paquets (forme de transit des données sur le réseau) à l'ordinateur cible. Pour ce faire, il a un système informatique minimal lui permettant de déchiffrer la trame (l'adresse de destination) et de transmettre le paquet à destination. Si un serveur sur le même switch que vous subit un DDOS (déni de service distribué, qui consiste à un flood massif du serveur pour le saturer), il y a des chances que son système informatique soit saturé par le flux de données, et passe en mode HUB; dans ce mode, il distribue les paquets qu'il reçoit à tout le monde qui est connecté sur lui sans chercher à les distribuer correctement. Aux serveurs recevant les paquets de ne garder que ceux les concernant. Ces paquets là sont interceptables facilement, et j'ignore si MySQL utilise un protocole chiffré (j'en doute). Veillez donc à bien hasher (et saler) les mots de passe, etc.
Conclusion
Voilà voilà, j'espère avoir pu faire convenablement le tour du monde des serveurs dédiés, libre à vous de vous documenter
je suis dispo pour vos questions, et je rappelle qu'il ne s'agit que d'un retour sur mon expérience en la matière, tout à fait subjectif et aucunement étayé par des calculs stricts.Bonne nuit ! o/
RE: Petit guide des serveurs dédiés - vol-au-vent - 12-01-2014
Wow, merci grâce à toi j'ai appris quelques petites choses, des précisions qui m'aiderons à l'avenir =)
Sinon pas trop mal aux doigts ? Non car le pauvre clavier a dû souffrir hier ^^
RE: Petit guide des serveurs dédiés - MadMass - 12-01-2014
Merci, merci :p
Je tiens (encore) à préciser que si quelqu'un souhaite apporter une précision ou corriger qqch je suis preneur, c'est vraiment basé sur mon expérience et il est possible que certains points soient incorrects ou inadaptés à des situations auxquelles je n'ai pas été confronté
RE: Petit guide des serveurs dédiés - Gogolo34 - 12-01-2014
Un serveur est-il plus dur à configurer qu'un simple hébergement mutualisé ?
RE: Petit guide des serveurs dédiés - MadMass - 13-01-2014
Oui. L'hébergement mutualisé c'est gérer ses fichiers, éventuellement sa configuration de php et ses .htaccess, et ça s'arrête là. Sur un serveur, il faut aussi le faire, mais il faut également administrer la machine (faire ses mises à jour, installer les bons logiciels et les configurer...)
Après y'a deux options pour faciliter les choses :
- Prendre une distribution très documentée en français (ubuntu propose énormément de tutos sur son wiki pour les grands débutants)
- Prendre un panel, où le serveur s'administre avec une interface web.
Concernant le panel, ce sera forcément plus limité que l'administration directe avec SSH, et en cas de bug/défaillance on se retrouve sans savoir comment faire pour reprendre la main
- Installation de lamp (Apache2, MySQL, PHP 5) : http://doc.ubuntu-fr.org/lamp
- Configuration de Apache2 : http://doc.ubuntu-fr.org/apache2 (il faut surtout regarder la partie "Configuration" et le fichier de config). Inutile de compiler soi-même apache soit dit en passant, car aptitude (apt-get) fourni une version à jour. Et il vaut mieux installer apache avec lamp et non tout seul si on souhaite php et mysql, car aptitude configure ainsi le fonctionnement des trois ensemble, sinon il faut le faire à la main :p
- Installation d'un FTP : http://doc.ubuntu-fr.org/proftpd (soit dit en passant lorsqu'on a un serveur dédié, il est préférable d'arrêter le FTP et passer en SFTP, c'est la même chose mais au travers de SSH donc c'est chiffré et y'a diverses sécurités supplémentaires).
Après ça nécessite tout de même une base en matière de fonctionnement réseau, il faut savoir gérer les ports, etc. En outre, il faut bien lire les docs pour sécuriser ses installations (notamment restreindre les droits d'accès en ftp, etc).
RE: Petit guide des serveurs dédiés - starmindfr - 13-02-2014
Bonjour
Interessant ce sujet, par contre ont a donc du dédié tres bas de gamme pas chere du tout, mais de qualité tres médiocre, dans les 10 - 15 euros par mois, et si l'on veut quelque chose de viable (j'ai noter que les testeurs partent vite apres quelques heures sans rien) il faut alors miser au minimum sur 50 euros ttc / mois (je n'ai pas vu grand chose de moins chere chez ovh) ?
edit : sur kimsufi je note 8HT en haut de leur page et rien en dessous de 13 HT + 10 HT de mise en service dans la liste ?
RE: Petit guide des serveurs dédiés - Sephi-Chan - 13-02-2014
Je ne trouve pas que les serveurs dédiés pas chers soient spécialement bas de gamme. JeuWeb tourne avec une petite Dedibox à 17 € (maintenant elle en coûte 12 €) depuis plusieurs années et je n'ai pas eu de problème jusque là.
Je pense que c'est amplement suffisant pour de la bêta ou le production d'un truc assez petit (moins de 50 joueurs connectés en permanence). Bien sûr, ça dépend aussi du niveau d'optimisation de l'application.
RE: Petit guide des serveurs dédiés - srm - 13-02-2014
Je confirme ce que dit Sephi, avant j'avais 2 serveurs à 15€, maintenant j'en ai plus qu'un à 35€ et il y a un paquet de truc qui tournent dessus.
- serveur cs:go
- btsync avec énormément de fichiers
- mongodb
- apache
- java
- nodejs
- postgresql
- proxy
- mysql
- rails
Et le serveur se tourne grave les pouces.
RE: Petit guide des serveurs dédiés - starmindfr - 13-02-2014
oui en fait j'ai lu rapidement et j'avais en tète le commentaire " (n'espérez pas faire fonctionner de façon décente un jeu sur ce type de configuration cependant)." ce qui m'a un peut refroidit.
RE: Petit guide des serveurs dédiés - MadMass - 13-02-2014
Oui sur les serveurs à 8€ de OVH j'entend :p
Les serveurs d'entrée de gamme avec du atom sont vraiment sympa, surtout ceux basés sur le N2800: pas chers et performants (archi récente). Il se murmure (enfin non c'est plus ou moins officiel) que intel est en train de déployer des atom "avotons", c'est à dire des atoms taillés pour les serveurs bas prix (faible conso électrique et TDP réduit notamment). Ca semble vraiment prometteur, ça devrait aller de 2c/4t à 8c/16t sur des archi récentes également, idéal pour des serveurs web et au prix d'environ 30€
Le dedibox ce qui me déplait fortement, c'est le fait que ce soit un monocoeur. Et je ne suis pas familier des architectures de Via, j'ai lu que le nano était équivalent à du atom d'entrée de gamme, reste que j'ai des doutes quand à la capacité de ce truc à bien tenir une montée en charge
mais j'espère me tromper, ça me plairait qu'un nouvel acteur apparaisse dans le monde des CPU x64