Catégorie : Open-source

Catégories
Developpement Open-source Planet-libre Systeme

MySQL Cluster – Tutoriels 1/5

Ce billet est le premier d’une série de 5 articles sur Cluster MySQL écrite par Rémy Verger (auteur invité).

La problématique de répartition des données est un problème majeur des infrastructures de gestion de l’information. Alors que l’approche historique consiste à dimensionner un seul serveur de façon à ce qu’il absorbe toute la charge, on observe depuis plusieurs années une tendance inverse, inspirée des techniques de RAID pour les volumes de stockage, qui consiste a prendre un très grand nombre de machines a faible coût pour former un cluster de stockage.

Il existe plusieurs façons différente de mettre en place un Clusteur de Stockage avancé, que je vais vous faire découvrir. Cette série de billet va se focaliser sur la solution MySQL Cluster, la base de données distribuée de MySQL.

 J’installerais MySQL Cluster sur une distribution CentOS, qui peut également être adapter a une distribution RedHat, comme il s’agit de paquet disponible dans les dépôts ReDHat Cluster Suite.

De plus vous trouverez des machines virtuelles sous VMware avec l’ensemble de l’architecture .

Voici le sommaire des 5 billets:

1. Introduction

2. Concepts de base de MySQL Cluster / Configuration simple-multi serveurs

3. Installation

4. Demarrage du MySQL Cluster

5. Commande d’administration

On commence de ce pas par le premier article !

Introduction

Dans le domaine des systèmes de gestion de bases de données,MySQL fournit une solution élégante pour réaliser un cluster à faible coût permettant d’atteindre un niveau de disponibilité proche des 99,999% annuel.

 Un Cluster MySQL est un groupe de processus qui s’exécutent sur plusieurs serveurs MySQL, des noeuds NDBCluster, et des processus d’administration, ainsi que des processus d’accès spécialisés. Tous ces programmes fonctionnent ensemble pour former un Cluster MySQL. Lorsque les données sont stockées dans le moteur NDBCluster, les tables sont réparties sur les noeuds NDBCluster. Ces tables sont directement accessibles depuis tous les autres serveurs MySQL faisant partie du Cluster. Par conséquent, si une application met à jour une ligne, tous les autres serveurs le verront immédiatement.

Les données stockées dans le moteur de table de MySQL Cluster peuvent être dupliquées, et sont capables de gérer une indisponibilité d’un noeud sans autre impact que l’annulation des transactions qui utilisaient ces données.

Elle permet de répartir des données sur plusieurs serveurs sans avoir de point individuel de défaillance. Contrairement aux moteurs MyISAM et InnoDB généralement utilisés avec MySQL, l’exploitation effective du cluster nécessite l’utilisation du moteur NDB, qui contient plusieurs restrictions, comme l’absence d’index FULLTEXT.

 MySQL est capable, depuis la version 4.1 et grâce au moteur de stockage NDB de gérer une grappe de serveurs complète.

  • augmenter la disponibilité
  • faciliter la montée en charge
  • permettre une répartition de la charge
  • faciliter la gestion des ressources (processeur, mémoire vive, disques dur, bande passante réseau).

Sa structure repose sur la duplication données, c’est-à-dire que chaque nœud fera partie d’un groupe de nœud qui posséderont tous la totalité de la base

Un protocole implémenté dans chaque nœud s’occupe d’adresser chaque transaction aux différents nœuds concernés dans la grappe, il faut un minimum de 3 machines pour établir une solution de clustering MySQL et une machine (qui peut elle-même intégrer un serveur MySQL) qui va jouer le rôle de répartiteur de charge en redirigeant les requêtes sur les nœuds disponibles et les moins occupés.

Par rapport à un système de réplication, la redondance est améliorée : si un nœud tombe en panne, sa charge est automatiquement reprise par les autres nœuds.

L’ajout d’un nouveau nœud peut se faire sans avoir besoin de repartitionner la base, il suffit de le faire reconnaître par la grappe et le redémarrage d’un nœud peut se faire sans avoir à redémarrer la grappe.

Du point de vue de MySQL, chaque nœud fait partie d’un ensemble qui pourrait être reconnue comme une seule machine.

Pour le programmeur, il doit programmer son application pour communiquer avec le répartiteur de charge.

Cette solution s’adapte parfaitement lorsque la disponibilité et la sécurité des données est un problème critique et que l’on recherche un partitionnement technique responsable de l’écriture. Couplé a des fonctionnalités temps réel et a une API de programmation asynchrone NDB Cluster s’adresse principalement aux exigences du marché des télécommunications.

Vous pouvez vous rendre sur la page suivante pour voir la liste exhaustive des fonctions proposées dans la version communautaire (gratuite et open-source) de MySQL Cluster.

Catégories
Developpement Open-source Planet-libre Reseau Systeme Web

VnStat.js, un node pour VnStat

Mes derniers billets traitaient de VnStat (le logiciel pour surveiller les débits de vos interfaces Ethernet) et de Node.js (le framework permettant de créer facilement des applications réseaux coté serveur). C’est donc dans ma logique toute cartésienne, que j’ai développé un javascript permettant de disposer d’une interface Web pour consulter ces statistiques de débits sans avoir à installer un serveur Web et son plugin PHP (comme c’est le cas avec le VnStat PHP frontend).

Ce script, disponible sous licence GPL v3, s’appelle VnStat.js est disponible dans mon GitHub à l’adresse suivante:


https://github.com/nicolargo/vnstat.js

Installation

Pour fonctionner correctement, VnStat.js nécessite:

  • une installation de VnStat fonctionnelle. Je vous conseille la lecture de ce billet pour effectuer une installation « from-scratch » sur une machine tournant sous Debian / Ubuntu.
  • que le framework Node.js soit installé sur cette même machine. Le script a été validé avec la dernière version stable de Node.js (0.4.12).

On commence par récupérer la dernière version de VnStat.js depuis le dépôt Git:

[cce lag= »bash »]

cd ~

git clone git://github.com/nicolargo/vnstat.js.git

cd vnstat.js

[/cce]

Pour les personnes utilisant NPM (le package manager de Node.js), vous pouvez l’utiliser pour installer VnStat.js. Suivre les instructions de cette page.

Lancement de VnStat.js

Pour lancer le noeud VnStat.js, il suffit de saisir les commandes suivantes:

[cce lag= »bash »]

cd ~/vnstat.js

node ./vnstat.js

[/cce]

Le « node » va se mettre en écoute sur le port TCP 1337 de votre serveur (il faut donc ajouter une règle pour autoriser les requêtes entrantes vers ce port si vous avez un firewall).

A l’ouverture de l’URL http://adressedevotremachine:1337/ dans un navigateur compatible HTML5, la page principale suivante va s’afficher:

Elle affiche le résumé des statistiques de VnStat ainsi que le top 10 des journées. Le menu du haut permet de naviguer vers des statistiques plus ciblés.

Par heures (avec à la fois la vue graphique et textuelle):

Et ainsi de suite pour les jours, semaines (à noter qu’il n’y a pas de graphe spécifique par semaine généré par vnstati) et enfin par mois.

Configuration de VnStat.js

Le design de VnStat.js peut bien entendu être adapté à vos besoins en éditant le fichier css/style.css (CSS3). Si vous avez besoin de changer le port TCP d’écoute du node, il y a une variable pour cela dans le fichier lib/server.js.

C’est mon premier développement avec le framework Node.js, il y a sûrement des améliorations à faire mais la structure reste assez didacticiel pour servir de base pour d’autre développement du même type.

Lancement automatique de VnStat.js au démarrage de votre machine

 Comme vous avez pu le remarquer, le node VnStat.js est lancé à la main dans ce billet. Si vous souhaitez mettre en production ce script et le lancer automatiquement au démarrage de votre machine, je vous conseille la lecture du billet de Vincent sur son blog qui regorge d’information sur ce superbe framework qu’est Node.js.

Catégories
Developpement Open-source Planet-libre Web

Une introduction à node.js

Node.js est un framework implémentant, coté serveur, la version 8 du moteur Javascript de Google (pour une présentation rapide, je vous conseille de parcourir ces quelques slides).

L’objectif de ce billet est d’installer Node.js sur votre machine GNU/Linux et d’exécuter votre premier programme (hello.js).

Installation de Node.js depuis les sources

Il n’existe pas, à l’heure à laquelle je rédige ce billet, de « package » officiel de Node.js pour Debian/Ubuntu (voir le chapitre suivant pour une installation depuis un PPA). L’installation est cependant assez simple. Pour installer la dernière version (stable) depuis le dépôt officiel GIT, il suffit de saisir les commandes suivantes:

mkdir ~/src
cd ~/src
git clone https://github.com/joyent/node.git
cd ~/src/node
git checkout v0.8.0
sudo mkdir /opt/node
./configure --prefix=/opt/node
make
sudo make install
echo 'export PATH=$PATH:/opt/node/bin' >> ~/.profile
echo 'export NODE_PATH=/opt/node:/opt/node/lib/node_modules' >> ~/.profile
source ~/.profile

L’installation va se faire dans le répertoire /opt/node.

Pour vérifier que Node.js est bien installé sur votre machine:

# node -v
v0.8.0

Les modules avec NPM

Pour étendre les fonctions de bases de Node.js, il faut utiliser l’utilitaire NPM (Node Package Manager). Grâce à lui il est possible d’ajouter des packages à Node.js.

Pour installer Node.js depuis les sources (voir le chapitre suivant pour une installation depuis un PPA):

curl http://npmjs.org/install.sh | sudo sh -c 'export PATH=$PATH:/opt/node/bin ; export NODE_PATH=/opt/node:/opt/node/lib/node_modules ; sh'

Je vous laisse ensuite regarder la documentation puis la liste des packages disponibles.

Installation depuis un PPA

Si vous êtes sous Ubuntu, il existe un PPA maintenant les dernières versions de Nodejs et de NPM. Pour installer le PPA sur votre système:

sudo add-apt-repository ppa:chris-lea/node.js

Puis l’installation de Nodejs et NPM:

sudo apt-get update && sudo apt-get install nodejs npm

Un premier exemple, ou le fameux « Hello world ! »

On commence par éditer un fichier ‘hello.js‘ contenant le code suivant:

//
// A JavaScript based on Node.js
//
// Nicolas Hennion (aka) Nicolargo
//
// GPL v3.0
//

var http = require('http');
var url = require('url');
var spawn = require ('child_process').spawn;

//**********
// Variables
//**********

var listenport = 1337;

//**********
// Functions
//**********

// Chomp function (delete the \n)
String.prototype.chomp = function () {
return this.replace(/(\n|\r)+$/, '');
};

// HTTP request
function onRequest(req, res) {
console.log("New request: "+req.url);
res.writeHead(200, {'Content-Type': 'text/plain'});
res.write('Hello World');
res.end();
};

//*************
// Main program
//*************

// Create the HTTP server
http.createServer(onRequest).listen(listenport);

// Get the hostname (FQDN)
var listenaddress = spawn('hostname', ['-f']);
listenaddress.stdout.on('data', function (data) {
var fqdn = new String(data);
console.log('Server running listenning http://'+fqdn.chomp()+':'+listenport+'/');
});

Puis on lance le noeud (node) avec la commande:

# node ./hello.js
Server running listenning http://VotreMachine:1337/

Il ne reste plus (après avoir autorisé les requêtes vers le port TCP 1337 si vous avez un Firewall sur votre machine de test) qu’à pointer une navigateu Web vers l’URL donnée par la commande pour voir affiché le résultat:

Détail du code

On commence par initialiser les fonctions de Node.js dont on a besoin (voir la liste dans la documentation officielle). Pour notre exemple, nous avons besoin de générer un serveur HTTP (http) et de lancer une commande système (spawn) récupérant le nom FQDN de la machine.

[cc lang= »javascript »]

var http = require(‘http’);

var spawn = require (‘child_process’).spawn;

[/cc]

Après la définition d’une variable globale (contenant le numéro TCP du port d’écoute du serveur) ainsi que d’une fonction enlevant le caractère de retour à la ligne du chaine (chomp), on passe au vif du sujet en générant un serveur HTTP:

[cc lang= »javascript »]

// Create the HTTP server

http.createServer(function (req, res) {

res.writeHead(200, {‘Content-Type’: ‘text/plain’});

res.end(‘Hello World\n’);

}).listen(listenport);

[/cc]

Cette commande est « forké » (elle génère donc un daemon HTTP écoutant sur le port ‘listenport’ et renvoyant le message texte ‘Hello World’). Enfin on affiche dans la console l’URL du serveur:

[cc lang= »javascript »]

// Get the hostname (FQDN)

var listenaddress = spawn(‘hostname’, [‘-f’]);

listenaddress.stdout.on(‘data’, function (data) {

var fqdn = new String(data);

console.log(‘Server running listenning http://’+fqdn.chomp()+’:’+listenport+’/’);

});

[/cc]

Aller plus loin

Bien évidement, ce billet n’est qu’une simple introduction à ce framework (d’ou le titre :)). Le code donnée en exemple est sûrement « optimisable » mais à un objectif pédagogique.  Je reviendrai rapidement sur ce sujet en proposant des développement basée sur Node.js pour la supervision de nos belles machines. Stay tuned…

Sources ayant inspirées ce billet:

Catégories
Open-source Planet-libre Reseau

Installation de VNStat sous Debian

VNStat est un outil bien utile pour surveiller le débit des interfaces réseaux de ses machines. Il se présente sous la forme d’un processus tournant en tache de fond (les versions plus anciennes se basaient sur crontab) et surveillant les flux transitant sur vos interfaces.

Nous allons détailler l’installation et l’utilisation de cet outil sur un système GNU/Linux Debian Squeeze.

Installation de VnStat

Dans une console root (ou en utilisant sudo), il faut saisir les commande suivantes:

[cce lang= »bash »]

apt-get install vnstat vnstati

vnstat -u -i eth0 –nick « LAN0″

/etc/init.d/vnstat start

[/cce]

La configuration de VnStat est centralisé dans le fichier /etc/vnstat.conf. Par défaut, le rafraîchissement se fait toutes les 5 minutes et surveille l’interface eth0. Cette configuration est bien sûr à adapter à vos besoins.

Si vous saisissez la commande suivante dans les 5 minutes qui suivent l’installation, il est normal d’avoir le message d’erreur:

[cce lang= »bash »]

vnstat

eth0: Not enough data available yet.

[/cce]

Les premières statistiques sont disponibles 5 minutes après l’installation.

Utilisation de VnStat

Statistiques instantanées basées sur les 5 dernières secondes:

[cce lang= »bash »]

# vnstat -tr

[/cce]

Statistique de la dernière journée avec une granularité par heure:

[cce lang= »bash »]

# vnstat -h

[/cce]

Statistique sur la dernière journée:

[cce lang= »bash »]

# vnstat -d

[/cce]

Statistique sur la dernière semaine:

[cce lang= »bash »]

# vnstat -w

[/cce]

Statistique sur le dernier mois:

[cce lang= »bash »]

# vnstat -m

[/cce]

Utilisation de VnStati (pour générer des graphes)

VnStati est un logiciel qui perme, à partir de la base de données renseignée par VnStat, de générer des rapports au format images (PNG) que l’on peut facilement intégrer dans une page Web de supervision (à noter qu’il existe un script PHP permettant de générer automatiquement des rapports).

Pour créer une image au format PNG contenant le rapport des dernières heures, il suffit de saisir la commande suivante:

[cce lang= »bash »]

# vnstati -h -o h.png

[/cce]

Le fichier h.png contiendra:

Comme vous pouvez le voir, VnStati utilise les mêmes arguments que VnStat (un petit man vnstat vous sera utile pour avoir la liste exhaustive).

Catégories
Blog Nagios Open-source Planet-libre Reseau Systeme Web

Supervision d’un serveur Web/WordPress avec Shinken

Les serveurs hébergeant des services « Web » deviennent de plus en plus critique: un problème technique sur un site marchand fait baisser le chiffre d’affaire, un autre sur un site d’information peut faire passer le lecteur à la concurrence un dernier sur un blog personnel/professionnel peut impacter directement la crédibilité de l’auteur.

Il est donc important de surveiller ces serveurs comme le lait sur le feu. Les outils de supervision permettent de s’acquitter de cette tache de manière plus ou moins automatique en recevant les alertes par mail, Twitter, SMS…

Nous allons dans ce billet configurer un serveur Shinken (étant un fork de Nagios, le billet est également valable pour la configuration d’un serveur sous Nagios) pour surveiller un blog WordPress tournant sur le pile HTTP Varnish+Nginx.

Avant de commencer

Nous partons sur l’hypothèse ou vous disposer d’un serveur sous Debian avec la pile Varnish+Nginx+Wordpress et un serveur Shinken correctement installé et fonctionnel. Idéalement, la brique Shinken sera installé sur un autre serveur lui même hébergé chez un autre hébergeur. Dans ce cas il faudra mettre en place la couche NRPE entre les deux pour que Shinken puisse correctement collecter les informations sur le serveur Web.

Pour simplifier la configuration et que vous puissiez facilement la tester sur vos blogs/sites personnels, j’ai choisi de réunir les deux briques (Web + Supervision) sur une même machine.

Quoi surveiller ?

C’est la question que j’ai posé sur Twitter il y a quelques jours et j’ai reçu un grand nombre de réponses allant toutes dans le même sens. Faute de temps, je n’ai pas pu exploiter toutes les pistes mais je garde cela sous le coude et je ferai sûrement évoluer ce billet dans le futur.

J’ai donc découpé la supervision en deux groupes de services: système / web.

Pour les services système:

  • La charge du serveur: cela permet de s’assurer qu’un processus n’occupe pas toute la CPU et que mon serveur Web (pas très consommateur grâce à l’utilisation de Varnish) aura les ressources pour répondre correctement.
  • La mémoire disponible: c’est un des point critique en terme de performance, comme j’utilise des caches en RAM il faut s’assurer que le système dispose toujours d’une marge de manoeuvre au niveau de la mémoire vive disponible.
  • La mémoire Swap disponible: quand le système n’a plus de RAM disponible, il utilise la mémoire Swap (disque). Je contrôle donc que cet espace n’est jamais trop occupé.
  • RAID1: Mon serveur Dedibox dispose de deux disques durs fonctionnant en RAID1. Je contrôle que les deux disques sont fonctionnels avec un plugin maison.
  • Espace libre sur la partition système: j’ai installé mon serveur Web sur un distribution Debian Squeeze avec le partitionnement par défaut qui affecte une seule partition à /. Je surveille donc que l’espace disque disponible ne devienne pas trop bas.
  • Espace libre sur la partition de backup: mon serveur est hébergé chez Online.net qui propose un espace de stockage accessible en FTP ou j’archive avec RSnapShot tous les répertoire critiques de mon serveur. J’ai donc monté cet espace FTP sur un répertoire de mon disque et j’en surveille l’espace disponible.
  • Nombres de processus actifs: Un trop grand nombre de processus tournant sur le serveur peut mettre en évidence un bug sur un des processus. Je contrôle que ce nombre ne soit pas trop important.
  • Nombres d’utilisateurs connectés simultanément: Comme je suis le seul admin de ce serveur, j’ai mis une alerte qui me prévient quand deux utilisateurs sont connectés simultanément.

Pour les services Web:

  • On commence par surveiller que les processus critiques sont lancés: Varnish (2 processus varnishd), NGinx (5 nginx) et SSH (1 sshd). On passage on vérifie que le nombre de processus est conforme à notre configuration.
  • On surveille les ports en écoutes (local): TCP/80 (Varnish), TCP/8080 (NGinx), TCP/22 (SSH)
  • Pour le site Web à surveiller (par exemple www.mondomaine.com), on contrôle que les URLS suivantes sont bien accessibles:
  • http://www.mondomaine.com (home page)
  • http://www.mondomaine.com/sitemap.xml.gz (le sitemap utilise pour votre référencement)
  • http://www.mondomaine.com/googleXXXXXXXXX.html (le fichier fourni par Google pour faire le check vers ces services)
  • Attaques DOS/DDOS: un plugin me permet de détecter si mon site est victime d’une attaque DOS (facile à bloquer) ou DDOS (bon courage… hein Korben :))

Cette liste est bien sûr très restrictive, j’attend vos idées dans les commentaires !

Les confs, les confs !

L’idée est de fournir les configurations « brutes de décoffrages ». Si vous avez des problèmes pour appliquer cette configuration sur votre serveur, je vous conseille de consulter les billet de la page sur la supervision de ce blog.

La configuration des services système:

[cce]

# Define a service to check the disk space of the root partition

# on the local machine. Warning if < 20% free, critical if

# < 10% free space on partition.

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description Root Partition

check_command check_local_disk!10%!5%!/

}

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description Backup Partition

check_command check_local_disk!10%!5%!/mnt/backup

}

 

# Define a service to check the number of currently logged in

# users on the local machine.

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description Current Users

check_command check_local_users!2!3

}

 

# Define a service to check the number of currently running procs

# on the local machine. Warning if > 250 processes, critical if

# > 400 processes.

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description Total Processes

check_command check_local_procs!250!400!RSZDT

}

 

# Check memoire avec script check_memory

# https://blog.nicolargo.com/2008/07/surveiller-la-memoire-de-vos-serveurs-avec-nagios.html

# -w 5% -c 1%

 

define service{

use local-service

host_name localhost

service_description Memory

check_command check_mem!10%!5%

}

 

# Define a service to check the load on the local machine.

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description Current Load

check_command check_local_load!5.0,4.0,3.0!10.0,6.0,4.0

}

 

# Define a service to check the swap usage the local machine.

# Critical if less than 10% of swap is free, warning if less than 20% is free

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description Swap Usage

check_command check_local_swap!20!10

}

 

# Check RAID (hardware)

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description RAID1

check_command check_raid

}

[/cce]

puis les services Web:

[cce]

# Define a service to check SSH on the local machine.

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description SSH

check_command check_ssh

#notifications_enabled 0

}

 

# Varnish process

# /usr/lib/nagios/plugins/check_procs -w 2:2 -c 1:1024 -C varnishd

 

define service{

use local-service

host_name localhost

service_description Varnish process

check_command check_local_process!2:2!1:1024!varnishd

}

 

# Check process

# /usr/lib/nagios/plugins/check_procs -w 5:5 -c 1:1024 -C nginx

 

define service{

use local-service

host_name localhost

service_description Nginx process

check_command check_local_process!5:5!1:1024!nginx

}

 

# Define a service to check Varnish

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description Varnish access

check_command check_url!http://localhost/

}

 

# Define a service to check HTTP on the local machine.

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description Nginx access

check_command check_url!http://localhost:8080/

}

 

# Define a service to check HTTP on the local machine.

 

define service{

use local-service ; Name of service template to use

host_name localhost

service_description URL Blog check

check_command check_url!http://www.mondomaine.com/

}

 

# Define a service to check URL

# http://www.mondomaine.com/googleXXXXXXXX.html

 

define service{

use local-service

host_name localhost

service_description URL Google check file

check_command check_url!http://www.mondomaine.com/googleXXXXXXXXXX.html

service_dependencies localhost,HTTP Blog

}

 

# Define a service to check URL

# https://blog.nicolargo.com/sitemap.xml.gz

 

define service{

use local-service

host_name localhost

service_description URL Sitemap

check_command check_url!http://www.mondomaine.com/sitemap.xml.gz

service_dependencies localhost,HTTP Blog

}

 

# Define a DDOS detection service

# https://blog.nicolargo.com/?p=4100

# Warning: >50 SYN_RECV

# Critical: >70 SYN_RECV

 

define service{

use local-service

host_name localhost

service_description DDOS detect

check_command check_ddos!50!70

}

[/cce]

Et voilà ce que cela donne dans mon Shinken/Thruk:

Catégories
Blog Open-source Planet-libre Web

Configuration Varnish+Nginx pour WordPress

Vu le nombre d’articles sur l’utilisation du serveur de cache Varnish pour une utilisation avec le CMS WordPress, force est de constater qu’il est difficile de faire le tri pour en sortir LA configuration. Dans ce billet, je vais donc vous présenter ma configuration qui tourne depuis quelques jours sur le serveur hébergeant le Blog de Nicolargo.

Ce serveur sous Debian Squeeze est composé de:

  • Varnish
  • Nginx avec le module PHP-FPM
  • WordPress avec le plugin « Varnish HTTP Purge »

Je maintiendrai à jour une configuration stable (avec des commentaire en Anglais) de cette pile HTTP dans le GIT suivant:

https://github.com/nicolargo/varnish-nginx-wordpress

Une configuration pour quoi faire ?

Le principal objectif est d’optimiser votre serveur pour supporter une montée en charge pouvant aller jusqu’à plusieurs centaines de requêtes HTTP par seconde. C’est à dire une configuration adaptée pour une grande majorité des blogs personnels à fort trafic.

Avec une pile HTTP classique (c’est à dire sans cache), toutes les requêtes vers WordPress vont entraîner:

  • l’exécution d’un script PHP générant en sortie un fichier HTML
  • des requêtes vers la base de donnée MySQL
  • la lecture sur disque des éléments statiques de la page (fichiers CSS, JS, images…)

Lors de ces premières requêtes il est important d’avoir un thème bien optimisé. Le plugin W3 Total Cache peut vous aider dans cette démarche en optimisant les fichiers CSS (compression / regroupement) et en mettant dans un cache certaine requêtes SQL. Il faut également noter qu’avec un système de cache externe comme Varnish, la première requête va également engendrer ces actions mais pas les suivantes.

Les deux premiers points sont fortement consommateurs de ressources matérielles (CPU et mémoire). Ainsi, la charge globale de votre serveur augmente avec le nombre de requêtes simultanées. Arrivé à saturation, votre serveur ne peut plus répondre correctement aux requêtes et le temps de chargement de vos pages commencent à augmenter jusqu’à arriver au point ou il n’est plus capable de rien faire.

L’utilisation d’un cache comme Varnish permet de fournir directement les fichier HTML au navigateur client sans passer par l’exécution du script PHP et les requêtes MySQL.

Concernant le troisième point, le problème vient de la relative lenteur des accès disques (notamment si vous êtes sur un hébergement de type virtuel (aka) VPS).

Une optimisation possible est de lire les objets statiques non pas depuis le disque mais directement depuis un cache mis en RAM. Deux solutions sont possibles, soit faire effectuer cette tache par Varnish (que l’on peut optimiser en utilisant un disque tmpfs pour le répertoire de travail de Varnish) qui en plus des pages HTML va également « cacher » les objets statiques, soit laisser NGinx gérer cela directement, notamment en utilisant une brique comme Memcached. Si les deux sont comparables en terme de performances pures (c’est à dire la capacité à supporter un grand nombre de requêtes simultanées), il semble que NGinx est une consommation CPU moins importante.

Avant de cacher il faut savoir purger

Les lecteurs attentifs ont déjà dû noter qu’il y avait un trou dans la raquette dans l’exposé précédant. En effet, par définition, WordPress génère des sites dynamiques ou les articles peuvent évoluer, des commentaires peuvent être ajoutés. Il faut donc un mécanisme pour prévenir Varnish de mettre à jour son cache quand certaines actions sont faites sur le blog.

Heureusement pour nous, WordPress dispose d’un grand nombre de plugins permettant d’automatiser cette tache. W3 Total Cache, déjà mentionné dans le premier chapitre dispose d’une option pour  communiquer avec Varnish. Il semble cependant qu’il y est des problèmes quand l’on configure ce plugin avec plusieurs serveurs Varnish (pour faire du partage de charge). Je conseille donc l’utilisation d’un plugin ne faisant que la tache de purge:  Varnish HTTP Purge.

Il faut donc désactiver la fonction de purge Varnish dans W3 Total Cache (si ce dernier est installé):

puis activer le plugin Varnish HTTP Purge:

On passe aux résultats

Pour avoir un « test bed » stable, j’ai installé les briques sur une machine dédiée sous Debian Squeeze. J’ai ensuite rédigé un billet de test comprenant du texte et 3 images.

Test de montée en charge locale avec Apache Bench

Dans un premier temps j’ai utilisé l’utilitaire Apache Bench (utilitaire ab) qui permet de simuler en local (c’est à dire sans les contraintes réseau) un grand nombre de requêtes simultanées sur l’URL du billet de test.

Sans Varnish / Sans W3 Total Cache:

[cce lang= »bash »]

# ab -c 5 -t 30 http://blogtest.nicolargo.com/2011/09/lorem.html

Requests per second: 20.45 [#/sec] (mean)

[/cce]

=> CPU proche de 95% pendant le test.

Sans Varnish / Avec W3 Total Cache:

[cce lang= »bash »]

# ab -c 5 -t 30 http://blogtest.nicolargo.com/2011/09/lorem.html

Requests per second: 232.62 [#/sec] (mean)

[/cce]

=> CPU proche de 85% pendant le test.

On note une augmentation des performances mais la charge CPU reste forte. Les processus PHP-FPM sont nombreux.

Avec Varnish / Sans W3 Total Cache:

[cce lang= »bash »]

# ab -c 5 -t 30 http://blogtest.nicolargo.com/2011/09/lorem.html

Requests per second: 8001.76 [#/sec] (mean)

[/cce]

=> CPU proche de 30% pendant le test.

Le gain est impressionnant par rapport à la configuration sans Varnish. On atteint un nombre de requêtes par seconde très important (> 8000 en moyenne) avec une marge CPU ne dépassant pas les 35% !

Avec Varnish / Avec W3 Total Cache:

[cce lang= »bash »]

# ab -c 5 -t 30 http://blogtest.nicolargo.com/2011/09/lorem.html

Requests per second: 8018.47 [#/sec] (mean)

[/cce]

=> CPU proche de 30% pendant le test.

Comme on n’a pas ou peu de gain supplémentaire en utilisant W3 Total Cache en plus de Varnish. J’ai donc décidé de ne plus utilisé W3 Total Cache sur mon blog WordPress. Il sera remplacé par « Varnish HTTP Purge » pour la gestion des purges de Varnish et « WP Minify » pour la réduction automatique des fichier CSS et JavaScript.

Test de montée en charge online avec Blitz.io

Si vous ne connaissez pas le service Blitz.io, je vous conseille la lecture du très bon billet de Romain sur le sujet.

J’ai utilisé la commande « rush » suivante:

[cce]

–timeout 5000 –region ireland –pattern 1-250:60 http://blogtest.nicolargo.com/2011/09/lorem.html

[/cce]

NGinx seul:

A partir de 50 utilisateurs, le temps de chargement des pages commence à augmenter pour arriver au timeout (limité à 5 secondes pour les tests chez Blitz.io) vers 120 utilisateurs.

NGinx avec Varnish:

Dans cette configuration, je ne rencontre aucune chute de performance avec 250 utilisateurs simultanés.

Grâce à Romain (encore lui) j’ai pu lancer sur le Blog de Nicolargo (Varnish + Nginx) un test avec 500 utilisateurs simultanés (par défaut Blitz.io est limité à 250).

Voici le résultat sur le Blog de Nicolargo:

Pas de problème jusqu’à 500 utilisateurs simultanés !!!

Test des purges

Pour valider que le plugin « Varnish HTTP Purge » fonctionnaite bien j’ai effectué les taches suivantes en vérifiant que la page était bien mise à jour pour un lecteur lambda:

  • Modification d’un billet existant
  • Suppression d’un billet existant
  • Ajout d’un commentaire
  • Modification d’un commentaire
  • Suppression d’un commentaire

Tous les tests ont été concluant.

Conclusion

Le couple Varnish + Nginx est donc une des pile que l’on peut utiliser pour obtenir un blog performant et résistant à une montée en charge bien supérieure aux nombres maximum de visiteurs sur la plupart des sites Internet. Ce n’est bien pas la seule solution et il existe sûrement des piles encore plus optimisé (notamment au niveau statique avec un serveur comme G-WAN), mais il est de mon point de vu, celui qui offre le meilleur ratio stabilité/sécurité/performance.

Pour suivre l’activité de la configuration étudiée dans ce billet, je vous conseille de vous abonnez au projet GitHub.

Quelques unes des sources de ce billet:

Catégories
Blog Open-source Planet-libre Web

Interview d’Aurélien Poncini, père de Web4All !

C’est avec une certaine impatience que j’ai préparé l’interview d’Aurélien. Imaginez un peu un geek n’ayant jamais vu aucun des films des séries de « La guerre des étoiles » ou du « Seigneur des anneaux » et qui s’implique sans compter dans une association proposant des services d’hébergement de site Internet…

Bonjour Aurélien, peux tu nous présenter Web4All ?

Web4all est une association française de loi 1901 créée en octobre 2006 par moi-même. Composée uniquement de bénévoles nous parvenons ainsi à réduire les charges afin d’offrir à nos clients un service d’hébergement optimal pour un prix très convenable.

Nous proposons des services d’hébergements permettant à tous de pouvoir se faire une visibilité sur internet qu’ils soient particuliers, associatifs ou professionnels. Nos offres se veulent relativement complètes, elles incluent un espace de stockage avec accès FTP, une publication via Apache / Php, une gestion des statistiques Awstats, bases de données MySQL, un service mail via la suite Zimbra sans oublier les sauvegardes.

Peux tu nous donner quelques chiffres ?

Aujourd’hui Web4all héberge environ 5000 sites internet et gère 2000 noms de domaines ce qui en fait un des plus gros acteur du marché des hébergeurs associatifs français. L’équipe est composé de 9 personnes, chacune avec ses compétences : administration système, comptabilité, développement… et ne demande qu’à s’agrandir.

Au niveau infrastructure nous avons 7 serveurs physiques chez OVH utilisés ainsi : trois hyperviseurs délivrant 288Go de RAM dotés de deux cartes 10Gbps par serveur, deux serveurs de backups pour les données clients, un serveur MySQL et un serveur de fichiers qui va bientôt disparaître. Elle fait tourner une cinquantaine de machines virtuelles.

Il faut ajouter à cela les 4 NAS utilisées pour la virtualisation.

Nous avons également un serveur de virtualisation chez Online permettant d’héberger un serveur DNS, des serveurs MTA, un serveur de supervision, le tout extérieur au réseau OVH afin d’assurer un service en mode dégradé en cas de soucis chez OVH (ce qui entre nous, n’arrive jamais).

Web4all c’est environ 1To de données clients, 1.5To de machines virtuelles, 2500 bases de données MySQL, 15To de sauvegardes.

Certes ces chiffres sont petits comparés à de très gros hébergeurs mais à notre niveau cela représente une belle évolution de notre association.

Quel est la place des logiciels libres dans cette association ?

Web4all repose majoritairement sur des briques libres mais nous utilisons également des applications non libres, notamment pour la gestion en interne (application de comptabilité).

Ce choix de briques libres permet une réduction des coûts apportant là aussi un intérêt pour le client sur le prix final.

Ce choix n’est pas uniquement basé sur une question de coût, ces applications ont aussi l’avantage d’être réputées stables, fonctionnelles et généralement largement documentées nous permettant de gagner du temps en terme d’administration et formation.

Ainsi nous pouvons approximativement dire que Web4all repose à 95% sur des logiciels libres.

Quelles sont les chantiers en cours chez Web4All ?

 Nous avons beaucoup de projets d’améliorations, d’évolutions. Mais nous souhaiterions aussi aller plus loin en proposant de nouveaux services à nos clients. Actuellement nous travaillons sur la finalisation du projet Zimbra Network Edition, sur la possibilité de commercialiser des serveurs virtuels administrés par nos soins, le but étant pour le client de bénéficier des avantages d’une machine dédié en terme de ressources mais sans avoir à s’occuper des tâches d’administration : vendre du service comme nous le faisons depuis le début mais cette fois-ci très axée “professionnel”.

En te mettant dans la peau d’un commercial, essayes de nous vendre Web4All…

Nous n’inventons rien, que ce soit au niveau des services que nous commercialisons déjà ou ceux à venir nous avons bien conscience qu’ils existent déjà chez de nombreux prestataires. Mais nous avons notre philosophie, une petite structure conviviale où le rapport humain passe avant tout ce qui signifie donc un support le plus adapté possible à nos clients et ce sans surcoût.

 Nous croyons à ce que beaucoup nomment aujourd’hui le Cloud, nous avons toujours privilégié les systèmes permettant de travailler en mode « distant » où toutes les données sont stockées sur le web. Mais nous sommes aussi de fervents défenseurs de la vie privée au sens large. Non pas qu’il faille ou non changer l’existant mais tout simplement en laissant à chacun le choix de ce qu’il souhaite faire de ses données et ce en toutes connaissance de cause. Or aujourd’hui, beaucoup de particuliers et de sociétés utilisent des services (je ne nommerais personnes pour éviter les trolls) sans connaître ce qu’il est fait de leur données ou ce qui pourrait éventuellement en être fait. Nous souhaitons proposer des alternatives à ce genre de services.

De quoi Web4All a besoin pour continuer son développement ?

Tout cela prends du temps, beaucoup de temps et comme dis précédemment nous ne sommes composé que de bénévoles, chacun avec son emploi du temps et un emploi en parallèle. Il nous est difficile de trouver des personnes souhaitant s’investir et en ayant les compétences ou étant en mesure de les acquérir. Tous ces services que nous proposons et que nous serons amenés à proposer ne peuvent exister que si nous avons une équipe forte et compétente pour cela.

 Notre outil de gestion des hébergements est un outil développé en interne par moi-même, ce dernier me prends énormément de temps et nous avons pour objectif d’en faire une nouvelle version que nous souhaiterions à terme diffuser librement. Là aussi il faut… du temps et des personnes prêtes à s’investir.

Ainsi, à défaut de pouvoir bénéficier de plus de temps, ce dernier n’étant malheureusement pas extensible, il nous faut trouver des personnes voulant participer à l’aventure.

Tu recherches actuellement des personnes voulant s’impliquer, peux tu nous donner quelques détails ?

Nous accueillons en permanence des personnes désireuses de nous rejoindre. Quelque soit leurs niveaux nous sommes très ouvert, le plus important étant la motivation, la capacité d’apprentissage et de travail en équipe. Mais surtout un point important : la disponibilité.

 Actuellement nous sommes en effectifs réduits donc je ne cache pas que le mieux seraient de pouvoir “recruter” des personnes ayant déjà un niveau confirmé.

Une liste non exhaustive des postes :

  • administrateurs système : Debian, Ubuntu principalement
  • administrateurs applicatif : Apache, MySQL, Bind, PostgreSQL, PureFTP, Nagios-Centreon, PHP, Ruby… et bien d’autres 😉
  • développeurs : PHP, principalement. Seraient un plus : Shell, Perl, Python…
  • Community manager

Un petit mot à nos lecteurs pour finir ?

 Web4all c’est une équipe composé de personnes de tout niveaux, dans différents domaines. Des personnes qui amènent des compétences, effectuant ainsi un transfert de compétences en interne auprès de celles et ceux intéressées.

En rejoignant l’équipe de Web4all vous aurez la chance de vivre une expérience exeptionnelle : celle d’apprendre toujours plus, de travailler sur un projet concret que vous pourrez mettre en avant lors, pourquoi pas d’un entretien d’embauche comme certains de notre équipe l’ont fait !

C’est avant tout une expérience humaine, un travail d’équipe au service de clients et adhérents qui attendent beaucoup de nous.

 En revanche si vous n’êtes pas vraiment motivé, réfléchissez bien et s’il vous plaît, ne nous contactez pas juste pour voir car nous perdons aussi beaucoup de temps avec des personnes que nous “formons” pendant quelques semaines et qui ne continuent pas l’aventure par manque de motivation.

Si Web4all existe aujourd’hui c’est grâce aux personnes qui composent l’équipe, actuels ou anciens. Mais c’est aussi en grande partie grâce à des sites et blogs comme celui de Nicolargo sur lesquels nous trouvons des ressources documentaires de qualité permettant un gain de temps considérable. Alors je tiens à adresser un grand merci à cette communautée de bloggeurs, du monde Open-Source ou non et tout particulièrement à Nicolas qui sans le savoir nous a beaucoup aidé et nous aide encore grâce à son blog !

 N’hésitez pas à parler de ces blogs autour de vous, n’hésitez pas à parler de nous autour de vous. Nous avons un point commun : une des meilleures manières de nous aider c’est aussi en parlant de nous 🙂

Merci Aurélien !

Catégories
Open-source Planet-libre Systeme

Surveiller l’état de son RAID1 hardware sous Debian

Sur ma Dedibox DC, je dispose en standard de deux disques dur fonctionnant en RAID1 grâce à une carte hardware. Comme le mirroring entre les deux disques est effectué directement depuis la carte hardware, il faut effectuer quelques manipulations au niveau du système d’exploitation pour avoir un état du RAID1.

Installation des utilitaires

On commence par trouver le nom de la carte qui se charge du RAID.

[cc lang= »bash »]

# lspci

01:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)

[/cc]

On ajoute ensuite le dépôt suivant pour prendre en charge les utilitaires pour la carte  Fusion-MPT SAS-2:

Dans un terminal root, il faut saisir la commande suivante:

[cce lang= »bash »]

echo « deb http://hwraid.le-vert.net/debian squeeze main » > /etc/apt/sources.list.d/hwraid.list

[/cce]

Puis mettre à jour ses dépôts et installer le logiciel dédié à cette carte:

[cc lang= »bash »]

apt-get update

apt-get install sas2ircu

[/cc]

Utilisation des utilitaires

Pour avoir la liste des cartes RAID de son système:

[cc lang= »bash »]

# sas2ircu LIST

LSI Corporation SAS2 IR Configuration Utility.

Version 5.00.00.00 (2010.02.09)

Copyright (c) 2009 LSI Corporation. All rights reserved.

Adapter Vendor Device SubSys SubSys

Index Type ID ID Pci Address Ven ID Dev ID

—– ———— —— —— —————– —— ——

0 SAS2008 1000h 72h 00h:01h:00h:00h 1028h 1f1dh

SAS2IRCU: Utility Completed Successfully.

[/cc]

L’information intéressante est le numéro de la carte (0 dans mon cas) qui va servir pour la commande suivante qui va afficher l’état des disques RAID:

[cc lang= »bash »]

# sas2ircu 0 DISPLAY

LSI Corporation SAS2 IR Configuration Utility.

Version 5.00.00.00 (2010.02.09)

Copyright (c) 2009 LSI Corporation. All rights reserved.

 

Read configuration has been initiated for controller 0

————————————————————————

Controller information

————————————————————————

Controller type : SAS2008

BIOS version : 7.11.01.00

Firmware version : 7.15.04.00

Channel description : 1 Serial Attached SCSI

Initiator ID : 0

Maximum physical devices : 39

Concurrent commands supported : 2607

Slot : 1

Segment : 0

Bus : 1

Device : 0

Function : 0

RAID Support : Yes

————————————————————————

IR Volume information

————————————————————————

IR volume 1

Volume ID : 79

Status of volume : Okay (OKY)

RAID level : RAID1

Size (in MB) : 953344

Physical hard disks :

PHY[0] Enclosure#/Slot# : 1:0

PHY[1] Enclosure#/Slot# : 1:1

————————————————————————

Physical device information

————————————————————————

Initiator at ID #0

 

Device is a Hard disk

Enclosure # : 1

Slot # : 0

State : Optimal (OPT)

Size (in MB)/(in sectors) : 953869/1953525167

Manufacturer : ATA

Model Number : WDC WD1003FBYX-1

Firmware Revision : 1V02

Serial No : WDWCAW31480098

Protocol : SATA

Drive Type : SATA_HDD

 

Device is a Hard disk

Enclosure # : 1

Slot # : 1

State : Optimal (OPT)

Size (in MB)/(in sectors) : 953869/1953525167

Manufacturer : ATA

Model Number : WDC WD1003FBYX-1

Firmware Revision : 1V02

Serial No : WDWCAW31419175

Protocol : SATA

Drive Type : SATA_HDD

————————————————————————

Enclosure information

————————————————————————

Enclosure# : 1

Logical ID : 5782bcb0:32624a00

Numslots : 8

StartSlot : 0

Primary Boot Slot : 0

————————————————————————

SAS2IRCU: Command DISPLAY Completed Successfully.

SAS2IRCU: Utility Completed Successfully.

[/cc]

On peut voir l’état du disque RAID ainsi que celui des disques physiques (slot 0 et slot 1).

Pour effectuer une vérification rapide du RAID1, c’est à dire que les deux disques sont fonctionnels, il suffit de sasir la commande suivante:

[cc lang= »bash »]

# sas2ircu 0 STATUS

LSI Corporation SAS2 IR Configuration Utility.

Version 5.00.00.00 (2010.02.09)

Copyright (c) 2009 LSI Corporation. All rights reserved.

 

Background command progress status for controller 0…

IR Volume 1

Volume ID : 79

Current operation : None

Volume status : Enabled

Volume state : Optimal

Physical disk I/Os : Not quiesced

SAS2IRCU: Command STATUS Completed Successfully.

SAS2IRCU: Utility Completed Successfully.

[/cc]

La ligne suivante:

Volume state : Optimal

permet d’identifier un fonctionnement nominal.

Il ne reste plus qu’à intégrer cette commande dans un nouveau plugin Nagios/Shiken pour superviser l’état de votre RAID1 (cela sera surement le sujet d’un prochain billet).

Source: Forum Online.net

Catégories
Blog Open-source Web

Migration du blog vers une Dedibox DC

Ce matin, vers les 10h, j’ai procédé à la migration de mon blog depuis un serveur VPS Gandi 4 parts vers une Dedibox DC.  J’ai choisi un samedi matin car c’est à ce moment là que le trafic est le plus faible sur le site.

Voici la procédure que j’ai suivi:

  • Installation du nouveau serveur en suivant cette procédure
  • Sauvegarde de la base MySQL depuis le serveur VPS Gandi
  • Fermeture des commentaires sur le blog WordPress du serveur VPS Gandi
  • Copie du répertoire wp-contents vers la Dedibox DC
  • Importation de la base MySQL sur la Dedibox DC
  • Test du nouveau serveur
  • Modification des serveurs DNS

 

La migration semble se dérouler comme sur des roulettes. J’ai encore quelques connexions sur l’ancien serveur, depuis des réseaux dont les DNS ne sont pas encore à jour.

Au niveau des performances, les graphes suivants parlent d’eux même, le nouveau serveur résiste beoucoup mieux à la charge, il faut dire que j’utilise un nouveau stack HTTP: Varnish 3 + Nginx.

Performances avant la migration:

Performances après la migration:

Si vous rencontrez des problèmes pour accéder à mon blog, merci de me prévenir :).

Update: Certains lecteurs rencontrent des effets de bord (page non mise à jour après un commentaire et affichage de la version mobile), j’ai donc désactivé Varnish en attendant de trouver LA configuration qui va bien. J’ai refait un test avec Load Impact et l’on voit clairement que l’on perd en perfo…

Update2: Tout est rentré dans l’ordre 🙂

Catégories
Blog Open-source Web

Le panier du marché libre #12

C’est la rentrée, je sais c’est dur… Heureusement un petit panier libre devrait vous redonner courage !

Une bonne pissaladière pour finir l’été ?

« La pâte à pain et l’oignon peuvent suffire, mais la vraie pissaladière ne saurait être faite sans pissalat, sorte de pâte ou de crème salée faite à partir de sardines et d’anchois salés, qui ont d’ailleurs donné son nom à la spécialité (du nissart peis salat = poisson salé). De plus en plus, on remplace le pissalat par de la crème d’anchois ou des filets d’anchois. Enfin, on a coutume d’ajouter à la pissaladière des olives noires, les caillettes (petites olives noires de Nice). » (source: Wikipédia)