====== Introduction ======
Gandi propose depuis plusieurs mois une offre d'hébergement en serveur virtuel.
https://www.gandi.net/hebergement/
Cette offre permet de créer un serveur virtuel sur un ensemble de machines physiques en réseau.
La location s'effectue en nombre de parts de puissance pour les ressources matérielles.
Un serveur virtuel permet de moduler la puissance disponible sans changer de serveur physique.
Il est ainsi possible de faire évoluer la puissance disponible si les sites internet deviennent plus populaires.
Cela permet de commencer un site directement sur un hébergement dédié "virtuel" et de monter en charge.
Pour les utilisateurs, le premier piège est de commencer par un hébergement mutualisé et de devoir effectuer une migration technique dès que le site devient top populaire et donc consommateur de ressources.
Ce timing est mauvais car c'est au moment où le site monte en popularité qu'il doit montrer une bonne stabilité technique. Alors que les hébergeurs mutualisés ne prennent pas de gants et coupent le site dès que les resssources demandées sont trop fortes :-P
Toutefois, il faut quand même maîtriser un certain nombre de techniques pour pouvoir gérer sereinement un serveur dédié.
L'interface de Gandi AI permet de gérer des modules typiques pour installer un serveur LAMP rapidement et facilement.
Cela permet de garder le même niveau technique que pour un hébergement mutualisé.
WARNING: Passer en mode root ne permet plus de revenir en arrière (en mode Gandi AI)
http://wiki.gandi.net/fr/hosting/gandi-ai/root
====== Matériel ======
===== 2009 =====
* Machine: Dell PowerEdge 6950
* Processeur: Quadri AMD quad-core
* Mémoire vive: 16 Go DDR
* Connexion: 2 x 1 Gbps
* Disque par machine: 320 Go
* Type de disque: RAID 60 en SAS
Le prestataire technique est Equinix. Et les datacenters sont au Nord de Paris (Seine-Saint-Denis, CDG)
En 2009, il y a eu une grosse panne de plusieurs heures. On a ainsi découvert que Equinix fournissait l'infrastructure technique à Gandi, mais aussi à d'autres acteurs majeurs du web français comme Dailymotion ou Pixmania :-P
====== Prise en main ======
C'est assez impressionnant car en moins de 15 minutes, vous pouvez avoir un serveur web qui tourne :-P
Pour tester, si vous demandez l'arret du serveur, la commande est exécutée dans la minute qui suit.
Pour le re-démarrage, cela prend moins de 5 minutes.
C'est donc très souple!
Le temps de ping de l'adresse IP est en dessous de 1.5ms. (En comparaison, OVH tourne autour de 4.5ms! C'est une bonne surprise de Gandi...)
La suppression d'un serveur est aussi réalisée en moins de 5 minutes. Il est à noter que la suppression du serveur ne supprime pas le disque de données! C'est une bonne surprise de voir que l'on peut séparer le serveur et les données. (Il faudrait aussi tester la ré-utilisation du disque de données sur un autre serveur...)
====== Nombre de parts et de CPU ======
Pour installer le serveur, une part suffit pour installer les composants utiles.
Ensuite, il suffit de suivre l'utilisation du CPU... Si le CPU n'est pas utilisé couramment à plus de 40%, il est inutile de louer une 2è part. La machine utilise moins de 5% du 2è CPU si le premier ne travaille pas plus de 40%. A partir de 60% de travail sur le CPU1, il est utile d'avoir un 2ème CPU. Toutefois, le CPU2 ne montera en charge à plus de 40% que si le CPU1 travaille autour de 80%.
====== Serveur Web ======
===== Fichiers =====
GandiAI installe le serveur web avec un utilisateur différent par nom de domaine. Chaque site est donc protégé en écriture des autres utilisateurs. Il ne faut pas donner des droits en 777, mais plutôt en 660 si besoin au fichiers et 770 aux dossiers.
L'utilisateur "admin" a le droit d'écriture sur tous ces dossiers.
===== Site par défaut =====
Le premier site installé sert de "catch all". Tous les sous-domaines pointent vers la racine du site, ainsi que les autres domaines si on modifie le DNS pour faire pointer les adresses IP vers le serveur.
===== Montée en charge =====
Les tests avec Apache Bench (ab) sont assez bizarres... Le serveur monte en charge sur une concurrence de 300 requêtes, mais le test finit alors que les écritures sur disque ne sont pas encore finalisés (dans le cas d'un fichier créé par requête). Peut-être que le cache apache modifie le comportement ?
Une ligne de test comme
ab -c 300 -n 600 http://citizen-web.com/
peut ne pas être prise en compte complètement et produire une erreur de connexion
apr_socket_recv: Connection reset by peer (104)
La plupart des tests jusqu'à 400 requêtes passent bien:
ab -c 100 -n 100 http://citizen-web.com/
ab -c 200 -n 200 http://citizen-web.com/
ab -c 300 -n 300 http://citizen-web.com/
ab -c 400 -n 400 http://citizen-web.com/
Au delà, on retombe sur l'erreur de socket
Disons que la part de serveur peut accepter jusqu'à 400 requêtes en 1 seconde ?
Il faut pour cela que chaque requête prenne moins de 1 seconde de traitement.
Cela donnerait...
* pour une minute: 400*60 = 24.000 requêtes
* pour une heure: 400*3600 = 1.440.000 requêtes
Ce serait bien si c'était vrai ??? :-P
===== Requête PHP =====
Le temps de réponse pour une requête PHP basique est entre 500ms et 800ms à partir d'un navigateur.
Du côté du serveur, avec quelques logs (dont bbclone avec résolution DNS), le temps de traitement est autour de 300ms et 500ms. En ajoutant la couche Apache et le transport réseau, on arrive au résultat pour le navigateur.
Ce n'est pas extraordinaire comme performances, mais pour une part de puissance, ça reste acceptable.
==== BBCLONE ====
Les performances pour BBCLONE sont très lentes sur Gandi!!!
A corriger...
===== Sécurité Serveur Apache =====
Par défaut, le serveur Apache est trop bavard, il faudrait pouvoir changer les paramètres:
ServerSignature Off
ServerTokens Off
expose_php off
Pour PHP5, avec GandiOS, il est possible de donner ses propres paramètres dans le fichier:
/etc/php5/apache2/conf.d/user.ini
Il est accessible en écriture pour l'utilisateur admin :-P
On peut alors ajouter expose_php=off et puis redémarrer le serveur (en moins de 2 minutes). Les nouveaux paramètres sont alors pris en compte.
===== Performances Serveur Apache =====
Le serveur crée des logs apache pour les accès dans le dossier nom.domaine.com/logs/, mais il n'y a pas de cron pour faire du logrotate, le fichier de log augmente ainsi en taille et finit par peser dans les performances des requêtes.
====== Gandi OS ======
La version de Gandi OS semble être basée sur Ubuntu Gutsy (7.10), si on regarde le fichier /etc/apt/sources.list
C'est une version qui n'est plus gérée et il deviendrait donc urgent que Gandi mette à jour sa version Gandi OS! :-(
Le support client m'a pourtant écrit que la version était Ubuntu 8.04 ??? A VERIFIER...
===== Scripts installés et manquants =====
==== Installés ====
- wget
==== Manquants ====
- unzip
- convert
- ffmpeg
- curl
====== Plusieurs parts en location ======
Si vous louez plusieurs parts, vous pouvez créer plusieurs serveurs. (1 serveur -> 1 part au moins)
Par contre, si vous avez déjà utilisé du quota disque pour créer des disques supplémentaires sur le premier serveur. Il vous en restera moins à disposition pour le 2è serveur.
La création de serveur prend avec GandiAI prend 3Go pour le disque système. Puis il crée un disque pour vos données, de taille 5Go. Mais si votre quota est moindre, il prendra ce qui reste (par exemple, seulement 4Go).
====== Quota Disque ======
- 1 Go 2.87 euros/an TTC
Ce qui donne
- 10 Go => 28.7 euros/an TTC
- 100 Go => 287 euros/an TTC
En comparaison
- 25 Go pour 23.88 eur/an HT (soit 28.56 eur/an TTC) chez OVH Perso
- 100 Go pour 59.88 eur/an HT (soit 71.62 eur/an TTC) chez OVH Pro
====== Gandi AI ======
===== 1.2 =====
Le module apache est mpm-per-user, il crée des threads, mais la configuration des MaxRequestsPerChild est mise à 0. C'est à dire que les process ne sont jamais détruits (pour permettre de limiter les pertes mémoires... et autres bugs qui apparaissent à la longue...) :-(
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxrequestsperchild
Au bout d'un moment, le serveur Apache finit par ne plus répondre alors que le reste du serveur Linux fonctionne correctement... Mais Gandi AI ne propose pas de moyens pour redémarrer seulement Apache... Il faut redémarrer tout le serveur :-(
Il est possible de créer un serveur de monitoring qui surveillera les réponses Apache en envoyant des requêtes "test". Si le serveur ne répond pas, le moniteur déclenche alors une action de reboot par l'API Gandi.
http://wiki.gandi.net/fr/api-xml/docs/hosting#vm_reboot