linux
LAMP + monitoring Zabbix sur un serveur virtuel avec 256 Mo de RAM
Est-il possible d’avoir un serveur web avec PHP + MySQL + des virtual hosts, ainsi qu’un service de monitoring (Zabbix), tout ça dans un VPS avec seulement 256 Mo de RAM ? Et en plus pour 4 € / mois ? Difficile, n’est-ce pas ? :-) En fait non, c’est même large… 140 Mo de RAM suffisent ! En m’inspirant d’un article sur lowendbox.com, et en utilisant un VPS chez l’excellent QuickWeb (OpenVZ VPS Germany 256 à $6/mois), voici rapidement la procédure d’installation sur une base d’install Ubuntu 10.10 toute fraiche :
- On fait un peu de ménage en virant rsyslog, et on installe syslog-ng à la place. Dans la foulée on bazarde portmap, ainsi que bind9 (les DNS de QuickWeb font parfaitement l’affaire) :
apt-get install syslog-ng && dpkg --purge rsyslog apt-get remove --purge portmap apt-get remove --purge bind9
- On supprime openssh, et on installe le tout petit dropbear à la place :
touch /etc/ssh/sshd_not_to_be_run apt-get install dropbear sed -i "s/NO_START=1/NO_START=0/" /etc/default/dropbear /etc/init.d/ssh stop && /etc/init.d/dropbear start echo -e "PATH=/usr/bin:/bin:/usr/sbin:/sbin\nexport PATH" >> ~/.bashrc
- Voilà, on a déjà gagné quelques megs. Passons aux poids lourds… Apache en premier, qui va poliment laisser sa place à lighttpd (et son module de gestion des vhosts) :
/etc/init.d/apache2 stop update-rc.d -f apache2 remove apt-get remove --purge apache2 apt-get install lighttpd mkdir -p /var/www/monitoring.monsite.fr/html lighttpd-enable-mod simple-vhost /etc/init.d/lighttpd force-reload
- Que serait le web sans PHP et MySQL ?
apt-get install mysql-server php5-cgi php5-mysql
cat > /etc/lighttpd/conf-enabled/10-cgi-php.conf
server.modules += ("mod_cgi")
cgi.assign = (".php" => "/usr/bin/php5-cgi")
^D
/etc/lighttpd/conf-enabled/10-simple-vhost.conf :
simple-vhost.server-root = "/var/www"
simple-vhost.document-root = "html"
/etc/init.d/lighttpd force-reload
- On va immédiatement calmer le gros apétit de MySQL :
cat > /etc/mysql/conf.d/mon_tuning.cnf [mysqld] key_buffer = 16K max_allowed_packet = 1M table_cache = 4 sort_buffer_size = 64K read_buffer_size = 256K read_rnd_buffer_size = 256K net_buffer_length = 2K thread_stack = 64K query_cache_limit = 256K query_cache_size = 1M ^D
- Au tour de Zabbix !
apt-get install zabbix-server-mysql zabbix-frontend-php zabbix-agent le pass root mysql puis le pass db zabbix mysql puis le pass frontend zabbix ln -s /usr/share/zabbix /var/www/monitoring.monsite.fr/html
- On customise un peu le /etc/php5/cgi/php.ini pour faire plaisir à Zabbix :
date.timezone = Europe/Paris post_max_size = 16M max_execution_time = 300 max_input_time = 300
- Un peu de SSL pour sécuriser le tout :
cd /etc/lighttpd/conf-available/ ln -s /etc/lighttpd/conf-available/10-ssl.conf openssl req -new -x509 -keyout server.pem -out server.pem -days 3650 -nodes du bla bla pour generer le certificat... :-) /etc/init.d/lighttpd restart
- Et voilà, secouez bien fort votre VPS, et Zabbix s’offre à vous :
https://monitoring.monsite.fr
Pour 4 petits € / mois, voilà un beau serveur de monitoring, oui ma bonne dame :-) Et rassurez vous, il reste de la RAM dispo, vous pourrez donc y installer encore quelques vhosts (puisqu’il y a du PHP/MySQL, autant se faire plaisir) :
root@quickweb:~# free -m total used free shared buffers cached Mem: 384 138 245 0 0 0 -/+ buffers/cache: 138 245 Swap: 0 0 0
I/O consommés par un process
/proc regorge d’informations sympathiques. On pourra par exemple y voir les I/O consommés par un process. Pour cela, on va regarder dans le /proc/<pid>/io. En regardant ce « fichier » pour un PID donné, on peut entre autres voir le nombre d’octets lus et écrits sur/depuis les disques, avec les champs rchar et wchar. Voilà un petit exemple :
$ dd if=/dev/zero of=bidon bs=1M count=1000 & [1] 5224 $ cat /proc/5224/io rchar: 793778451 wchar: 1587738016 syscr: 194481 syscw: 388188 read_bytes: 0 write_bytes: 795377664 cancelled_write_bytes: 0
Il s’agit de compteurs incrémentaux, un peu comme dans /proc/net/dev pour mesurer les débits sur les interfaces réseau. En faisant la différence entre deux mesures, divisé par le temps entre les deux mesures, on peut ainsi facilement obtenir les débits en lecture et écriture sur les disques du process mesuré ! Ou bien sinon, plus simple : iotop fait ça très bien. Il permet de voir quels process sont en train de tuer vos disques durs, à la manière de top pour les CPU :-)
MooseFS : filesystem distribué redondant
GlusterFS, Lustre : peut être avez-vous déjà essayé ces systèmes de fichiers distribués. Mais il existe une alternative très intéressante, et encore peu connu : MooseFS. Il s’agit d’un système de fichiers distribué et redondant, c’est-à-dire résistant aux pannes d’un ou plusieurs noeuds de stockage. Il est disponible en open source, développé par la société polonaise Gemius, et dispo pour Linux, FreeBSD, OpenSolaris (ce qu’il en reste) et MacOS X. La version 1.6.20 est disponible depuis le 17/01/2011 : les développeurs sont réactifs et suivent de très près la liste de diffusion et les remontés de bugs de leurs utilisateurs.
Le principe est simple (et très Google-like) : des machines de stockage low-cost, et une duplication des données sur ces différents noeuds. Pas besoin de SAN très onéreux ou de systèmes ultra complexes : des petits serveurs bon marché avec de gros disques font parfaitement l’affaire, même pas besoin de RAID hardware, MooseFS est résistant. Les fichiers sont découpés en morceaux (appelés chunks) puis répartis sur les différents chunkservers (noeuds de stockage) : selon le paramétrage voulu pour ces fichiers, ou pour le répertoire dans lequel ils se trouvent, chaque chunk sera répliqué sur x noeuds (différents). Ainsi, la perte de l’un des noeuds sera totalement transparente pour l’utilisateur, et sans aucune perte de données !
J’ai un « petit » cluster de 12 serveurs de 4 To chacun, soit un volume brut de 48 To, qui tourne depuis plusieurs mois sans jamais avoir eu le moindre problème. Ce cluster a pourtant tout testé : le crash électrique dans la baie, le crash de plusieurs serveurs de stockage successifs, des fichiers effacés par une erreur humaine (et récupérés proprement car MooseFS gère une trash). Pas le moindre octet perdu, et les perfs sont relativement correctes. Bref, un filesystem très intéressant, qui mérite vraiment d’être plus connu, et merveilleux pour du stockage lourd où la sécurité des données est critique. La liste de diffusion compte plusieurs déçus de GlusterFS, qui revivent depuis :-), et un cluster de plusieurs péta-octets est même en cours de mise en service par une société américaine. A suivre…
Update (15/04/2011) : Dans le dernier numéro de GNU Linux Magazine France (n°137, avril 2011), vous trouverez un long article sur MooseFS.
Backups distants sécurisés
Faire des backups, c’est primordial. Sécuriser le stockage de ses backups l’est autant :
- sur la même machine : si le disque dur crash, on perd les données et les backups… bien joué…
- sur un des nombreux sites web dédié au stockage en ligne : pourquoi pas, mais c’est cher, et il faut avoir confiance dans la société qui gère vos données.
- sur un serveur distant qui vous appartient : ouaip, mais encore faut-il avoir un autre serveur (ou un serveur dédié virtuel pas cher !)
- sur un serveur distant qui ne vous appartient pas : un collègue qui vous prête généreusement un bout de disque. Encore une fois, il faut avoir confiance en lui, vous lui confiez (l’accès à) vos données.
Bref, il n’y a pas vraiment de solution idéale : Vos données devront être stockées ailleurs, sur une machine où vous ne serez probablement pas le seul à avoir accès, et là il faut avoir confiance ! Ou pas…
Voici une solution simple : En prenant un serveur dédié virtuel (voir précédent billet) à pas cher :-), vous disposez de quelques dizaines de Go de sauvegarde pour une poignée de centimes d’euros par mois. En général, ce sera sur un serveur OpenVZ aux USA, géré par on ne sait qui, sécurisé on ne sait comment. Vous pouvez alors utiliser openssl pour chiffrer vos données à l’aide d’un algorithme de chiffrement symétrique sur les jolis .tar.gz que vous générez (par exemple), puis les envoyer en scp vers ce VDS de backup. Dans les grandes lignes, voici la marche à suivre :
1) Générer un mot de passe sûr (secure), fiable et que vous pouvez retenir facilement, ou stocker en lui sûr. Si vous êtes en manque d’inspiration, on peut par exemple faire ceci :
$ cat /dev/urandom | tr -cd '[:graph:]' | head -c 20 > mon_pass$ cat mon_pass; echoV+7*Vde|th"h[=fUXc"=$
ATTENTION : Conservez le fichier mon_pass bien au chaud, évidemment, sinon vos données ne seront pas récupérables le jour où vous en aurez besoin !
2) Générer vos fichiers de sauvegarde (disons un bon gros .tar.gz de derrière les fagots)
3) Encodage du fichier en AES-256-ECB, avec votre password :
openssl enc -aes-256-ecb -in mon_backup.tar.gz -out mon_backup.tar.gz.secure -kfile mon_pass
Le fichier mon_backup.tar.gz.secure contient la version chiffrée de vos backups, que vous pouvez maintenant laisser trainer n’importe où :-)
4) Copie du backup sécurisé vers le serveur pas/peu secure
5) En cas de catastrophe, pour décoder votre fichier de backup et en récupérer le contenu (à l’aide de votre fichier de password, que vous aurez eu l’intelligence de bien sauvegarder au chaud) :
openssl enc -d -aes-256-ecb -in mon_backup.tar.gz.secure -out mon_backup.tar.gz -kfile mon_pass
Et hop !
Sinon, deuxième possibilité, dans le même esprit : Utiliser Duplicity avec GnuPG.
Serveur dédié (virtuel) à pas cher
Tout bon geek qui se respecte (et qui ne travaille pas chez un hébergeur) a un dédié, en général du low cost à 15 € par mois chez OVH (Kimsufi) ou chez Free/Iliad (Dedibox). Mais parfois, on a envie de bidouiller, tester, jouer avec IPv6, avoir un petit serveur OpenVPN sous le coude (pour sortir avec une IP américaine, pour prendre un exemple totalement au hasard), avoir un serveur de backup distant, etc… Bref, c’est là qu’entre en jeu le dédié virtuel : ça sent le dédié, ça ressemble au dédié (si on accepte de ne pas toucher à son kernel), mais c’est moins cher que du dédié !
En France, on peut par exemple se tourner vers Phpnux qui propose des VDS de qualité à seulement 8.25 € HT / mois. Mais si on se tourne de l’autre côté de l’Atlantique, les prix s’écroulent :
- 123systems : le VDS (sous OpenVZ) avec 256 Mo de RAM burstable à 512 Mo, 10 Go de disque, une adresse IP(v4) à Dallas (USA) est à $3 / mois ! Et pour le double ($6 / mois), vous avec 512 Mo de RAM burstable à 1 Go, et 20 Go d’espace disque.
- QuickWeb : le VDS (sous OpenVZ) avec 256 Mo de RAM, 12 Go de disque, une adresse IP(v4) en Allemagne, est à $6 / mois (env 4.32 €). C’est un tout petit peu plus cher que les deux suivants (enfin on parle de quelques euros / an…), mais leurs VDS sont d’excellente qualité et surtout ils sont très stables. J’aurais donc tendance à recommander ce prestataire, d’autant qu’il propose des serveurs aux USA, mais également en Europe (en Allemagne), donc avec des pings largement plus raisonnables que New York ou Los Angeles ! ;-)
- Enotch Networks : le VDS (sous OpenVZ) avec 512 Mo de RAM, 20 Go de disque, deux adresses IP(v4) et du net à 10 Mb/s, est à $5.95 / mois (env. 4.31 €), ou bien $50.95 / an (env. 36.91 €) !
- 2Host : le VDS (sous Xen) avec 256 de RAM + 512 Mo de swap, 5 Go de disque, 10 To de transit IP par mois (!!!), une adresse IP(v4), est à $4.99 / mois (env. 3.61€ ), ou bien $47.88 (env. 34.69 €) !
J’ai personnellement testé ces prestataires depuis plusieurs mois (années pour certains), et ça fonctionne très bien, c’est même assez bluffant vu le prix… Bon, bien sûr, il ne faut pas s’attendre à avoir les perfs d’un Bi-Xeon, et il faut accepter les pings > 100 ms (puisque tout est souvent aux USA). Certes, mais pour moins de 4 € par mois on a un serveur de tests (et un VPN) cassable et réinstallable à loisir :-) Et c’est payable mensuellement, sans aucun engagement ! Ils sont forts (des fois) ces américains.
(Mise à jour : 31/01/2012)