Passer d'un hébergement mutualisé à un VPS Cloud 1 OVH

Pourquoi changer d'hébergement ?

Vu que je suis sur le point de repasser mon hébergement drupal mutualisé de chez OVH vers leur offre VPS 2013, je me suis dit que ce serait bien de rédiger pas à pas la façon dont je m'y prend.

Mon site drupal n'accueillant quasiment que des visiteurs anonymes, je pourrais garder mon mutu car avec le module Boost ça dépote. Le problème, c'est que dès que j'ai la moindre tâche d'administration à effectuer, le site rame, mais d'une force ! 

Et là j'en peux plus. J'ai essayé d'optimiser mon site en l'allégeant de certains modules, et en retravaillant un peu le code custom: j'y ai pas mal gagné en performances, mais pour moi cela reste quasiment impraticable, ce qui fait que j'en suis réduit à n'effectuer que les tâches vitales pour le bon maintient du site.

J'ai même réfléchi à migrer mes sites sous Wordpress, vu que ce dernier semble bien moins gourmand en ressources, mais finalement j'ai trop peur d'y perdre en souplesse, d'autant qu'il faudrait que je réécrive mes modules customs à la sauce Wordpress. Bref.

VPS CLOUD 2013

Phase 1: Réflexion

Si vous souhaitez vous lancer dans cette petite aventure, je vous conseille de bien réfléchir à ce que vous allez faire: passer du mutualisé au dédié, ce n'est pas forcément quelque chose qui va de soi. Par exemple, le mutualisé vous offre une grande tranquilité d'esprit, dans la mesure ou vous n'avez que vos sites à vous occuper.

En passant au dédié ou au VPS, vous serez seul maître à bord. Il faudra constamment veiller au points suivants :

  • Sécurité - Pare-feu
  • Mises à jour du noyau Linux ou Windows 
  • Fonctionnement opérationnel de la base de données (MySQL en ce qui me concerne)
  • Fonctionnement opérationnel du serveur web (apache)
  • Analyse des logs

Vous devrez en outre être capable de maîtriser un minimum l'environnement d'exploitation de votre serveur (Linux ou Windows), ou vous payer des services d'infogérance.

Je vous conseille également de rédiger un plan de migration qui contiendra la liste des étapes indispensables à une migration sans douleur.

Référencement google

Si votre site est bien référencé dans les moteurs de recherche google, vous devrez prendre quelques précautions:

Sur votre serveur cible, créez un fichier robots.txt qui permettra d'indiquer aux moteurs que vous ne voulez pas indexer votre site. Pourquoi ? Parce que pendant la phase de migration de votre site, il existera à deux endroits différents: sur votre mutualisé, avec votre nom de domaine, et sur votre VPS tout neuf, avec une adresse ip et un nom de domaine automatique du genre vpsxxxxx.ovh.net. Il serait dommage de subir des pénalités, ou pire que le contenu en pleine phase de migration commence à être indexé par les moteurs: risque de contenu dupliqué et autres déboires.

Votre robots.txt contiendra donc ces informations:

User-Agent: *
Disallow: /

Par contre, lors du switch final, n'oubliez surtout pas de remettre votre ancien robots.txt sur votre VPS, sans quoi votre site ne serait plus indexé !

Quel type de serveur choisir: VPS ou dédié ?

Je me suis longuement posé la question, et j'ai finalement opté pour le VPS (virtual private server), du moins dans un premier temps. Le serveur dédié physique est censé être beaucoup réactif et puissant que le VPS, mais il est aussi beaucoup plus cher. En outre s'il subit une panne matèrielle, le site risque d'en pâtir, tandis que sur du VPS, c'est beaucoup plus souple et transparent.

Je suis conscient que les performances du VPS seront moindres que celles d'un dédié, j'ai donc prévu la location d'un vps pour une période d'un mois, période durant laquelle je validerai ou non le fait de garder un vps ou de passer au dédié. Mais vu que mon site principal accueille entre 1500 et 2000 visiteurs par jour, la charge ne sera pas un problème.

Si je fais ce changement, c'est surtout pour être plus à l'aise en mode admin, et pouvoir installer mes propres outils tels que drush (drupal en ligne de commande), varnish (au lieu de boost), APC, authcache, etc, bref tout un tas d'outils permettant d'améliorer les performances globales du site web.

Phase 2: commande du serveur et installation

Comme je suis plutôt à l'aise sur Ubuntu, j'ai choisi de prendre cette distribution. Ce cera une Ubuntu 12.04 Server en 64 bits. J'ai pris un VPS Cloud 1 de chez OVH à 9,99 € HT/mois.

OVH VPS Cloud 1

Quinze minutes après avoir lancé ma commande, hop je reçois un mail d'OVH qui m'indique que mon serveur est prêt, avec les identifiants de connexion. Pour m'y connecter, c'est via ssh, je lance donc un ssh -l root adresse_ip_vps depuis mon MAC. Si vous êtes sous Windows, Il vous suffira d'utiliser un logiciel tel que Putty pour vous connecter.

Installation

Pour commencer, j'installe Apache, Php, MySQL et PhpMyAdmin:

apt-get install apache2 php5 mysql-server libapache2-mod-php5 php5-mysql phpmyadmin

Suite à cette installation je teste dans mon navigateur que tout s'est passé correctement: http://vpsxxxxx.ovh.net et en retour j'ai droit à un beau It Works ! 

Je vais également sur http://vpsxxxxx.ovh.net/phpmyadmin pour vérifier que tout est ok. J'en profite pour créer ma base de donnée depuis l'interface de PhpMyAdmin.

Ensuite j'active la réecriture d'url d'apache car je vais en avor besoin, pour que mon site ait de belles url :

a2enmod rewrite

Je redémarre apache pour que ce soit pris en compte:

service apache2 restart

Je vais copier, via scp, tous les fichiers et dossiers de mon poste local vers le VPS:

scp -r * [email protected]:/var/www

J'importe un dump de ma base MySQL:

mysql -hlocalhost -uuser -ppass NomBase < NomDump.sql

Sur mon site drupal, malgré le fait que j'ai activé la réécriture d'url, je n'arrive pas a atteindre les pages du site car les clean urls sont activées, mais il y a un problème: si je vais sur monsite.fr/user, il me met un joli 404. Pire, quand je fait un monsite.fr/?q=user, il me redirige vers monsite.fr/user, qui lui ne marche pas !

C'est dû certainement au module pathredirect que je pourrais désactiver en changeant le status de ce module à 0 dans la table system. Mais il s'agit d'un simple défaut de configuration de mon serveur Apache. J'édite donc le fichier :

/etc/apache2/sites-enabled/000-default

Dans la section <Directory /var/www/> je remplace la directive

AllowOverride None 

par

AllowOverride All 

Un petit service apache2 restart et le tour est joué: J'accède tranquillement à mes urls simplifiées. J'ai dans mon .htaccess certaines directives qui me redirigent sur mon site de production. J'en fais donc une copie et je commente les directives dont je n'ai pas besoin pour le moment.

cp /var/www/.htaccess /var/www/.htaccess.sav 

Une fois mon .htaccess modifié, je me log en admin drupal puis je met de suite mon site en mode maintenance afin qu'il soit à l'abri des regards indiscrets.

Phase 3: optmisation des performances du site

Suite à cette installation, la vitesse d'affichage en tant qu'admin laisse à désirer. Mais à ce stade, je n'ai encore rien optimisé (pas d'APC, pas d'optimisation MySQL, etc). Je vais donc tester pas à pas toutes ces choses pour voir ce que ça donne.

APC : un atout indispensable pour la vitesse de votre site !

Pour installer APC et pour faire mes tests, je me suis aidé du blog de petitchevalroux que j'apprécie beaucoup.

Je commence donc mon petit test de perfs :

ab -n 10 http://vpsxxxxx.ovh.net/ 

Et là, c'est vraiment la cata au niveau performances:

Time per request: 4774.348 [ms] (mean) Time per request: 4774.348 [ms]

A ce stade, l'affichage du site est très lent. Je vais donc installer APC (Alternative PHP Cache). Pour faire bref, c'est un système qui met en RAM l'exécution de tous vos scripts Php.

A chaque fois qu'un script est appelé (et sous Drupal il y en a une tonne à chaque rendu de page), au lieu de le parser, le compiler et l'exécuter, il est immédiatement exécuté depuis la mémoire vive de votre serveur. Le gain au niveau des performances est si hallucinant qu'il faudrait être fou pour ne pas l'utiliser, d'autant plus qu'il est une extrême facilité à configurer !

Lors de ma première tentative d'installation d'APC, en lançant la commande apt-get install php5-dev php-pear suivie de pecl install apc, j'ai eu droit à un sh: make: command not found et un ERROR: `make' failed. C'est parce que mon serveur est tout neuf et qu'il ne contient pas encore toutes les bibliothèques nécessaires à la compilation de certains programmes. En l'occurence il me manquait le paquet libpcre3-dev.

La commande à lancer dans mon cas est donc:

apt-get install php5-dev php-pear libpcre3-dev

puis

pecl install apc 

 A la fin de l'installation, vous devriez tomber sur ce message: 

You should add "extension=apc.so" to php.ini

Ce message nous indique qu'il faut dire à php que l'on va utiliser APC lors de l'exécution des scripts. On pourrait ajouter cette entrée dans le php.ini, mais comme le fait remarquer petitchevalroux sur son blog, il vaut mieux créer un fichier dédié que l'on nommera apc.ini, c'est beaucoup plus sexy.

on crée donc le fichier apc.ini:

vi /etc/php5/apache2/conf.d/apc.ini

On ajoute dans ce fichier ces informations:

extension=apc.so
apc.shm_size=64M
apc.stat=0

La première ligne active l'extension APC.

La deuxième ligne indique que l'on va allouer 64Mo de RAM pour stocker l'ensemble des fichiers Php, la valeur par défaut étant trop réduite (32M) pour mon installation Drupal. Au début j'avais laissé la valeur de 32Mo par défaut, et les performances étaient pires qu'auparavant !

ab -n 10 http://vpsxxxxx.ovh.net/
Time per request: 8189.543 [ms] (mean, across all concurrent requests)
Transfer rate: 1.17 [Kbytes/sec] received

La troisème ligne (apc.stat=0) est à utiliser avec précaution: elle indique au système de ne pas vérifier sur le disque du serveur si une version plus récente des fichiers Php existe.

Cela signifie que si vous modifiez du code Php qui existe déjà dans la mémoire allouée à APC, ces modifications ne seront pas prises en compte lors de l'exécution du script, puisque c'est celui stocké en RAM qui sera utilisé. Le gain en rapidité ne me semble pas significatif, alors je pense que c'est un paramètre que je supprimerai par la suite.

Pour que les modifications du fichier apc.ini soient effectives, on relance apache:

service apache2 restart

Pour accéder à l'interface d'APC, qui va nous permettre de surveiller son état, on copie un script php à la racine de notre serveur web (ou à l'endroit qui vous convient le mieux):

cp /usr/share/php/apc.php /var/www

Vous noterez que dans la section File Cache Information de apc.php, il y a les Hits et le Misses. Le nombre de Hits doit être supérieur au nombre de Misses, sinon cela signifie qu'il y a un problème avec votre APC. C'est ce qui s'est passé pour moi lorsque j'avais laissé la config d'APC par défaut: plus de Misses (manqués) que de Hits car tous les scripts Php ne pouvaient pas rentrer dans la RAM.

Après avoir configuré APC avec 64Mo de ram, le gain de rapidité est fulgurant !

ab -n 10 http://vpsxxxxx.ovh.net/
Time per request: 6.030 [ms] (mean, across all concurrent requests)
Transfer rate: 1589.28 [Kbytes/sec] received
ab -n 1000 -c30 http://vpsxxxxx.ovh.net/ 
HTML transferred:       9280000 bytes
Requests per second:    283.76 [#/sec] (mean)
Time per request:       105.723 [ms] (mean)
Time per request:       3.524 [ms] (mean, across all concurrent requests)
Transfer rate:          2719.55 [Kbytes/sec] received

Sympas comme résultats non ? 

J'ai oublié de vous dire: Il faut prendre en compte dans ces résultats le fait que le cache de Drupal est activé. En effet, s'il n'était pas activé, ces résultats ne seraient pas aussi significatifs.

Cet article étant déjà assez long, je vais arrêter ici. Mais c'est loin d'être terminé! Dans un prochain article, je vous parlerai de Varnish, que je vais essayer d'installer sur le serveur afin de l'accélerer au maximum. J'aborderais également le sujet de la sécurité sur le serveur, puis je finirai par le pointage du nom de domaine vers le serveur.

Catégories: