View Sidebar

Archive for category: Informatique

Il était une fois … le monitoring de nos services

Il était une fois … le monitoring de nos services

Allez, 6ème (et avant-dernière) partie dédiée au nouveau serveur.

Partie 1 : Présentation de proxmox et de la virtualisation
Partie 2 : Configuration du réseau interne
Partie 3 : Un petit Stress test pour la route
Partie 4 : Quelques optimisations Webserver
Partie 5 : HTTPS et IPV6
Partie 6 : Le Monitoring
Partie 7 : Les Backup

Et oui, je suis de retour … pour vous jouer un mauvais tour.

Ça ne suffit pas les graph de proxmox ou d’ovh ?

C’est bien d’avoir des graphes, mais ce n’est pas ça qui va nous sauver lorsqu’il y aura un problème avec un des softs que l’on utilise.
Aucun logiciel n’est parfait et il arrive assez couramment qu’ils crashs (aucun logiciel n’est épargné).
Qui n’a pas déjà vu un serveur apache en rade où une db qui timeout.

L’idée va donc être de mettre sous surveillance nos différentes machines et leurs processus.
Et lorsqu’un problème est détecté, soit essayer de le corriger (via des restart, reset de config, …), soit envoyer des mails d’alertes pour nous prévenir (attention toutefois à ne pas se spammer).
C’est quand même nettement plus efficace que d’attendre de se rendre compte que ça ne fonctionne plus.

29 août 20130 commentsRead More
Il était une fois, l’activation du HTTPS et de l’IPV6

Il était une fois, l’activation du HTTPS et de l’IPV6

Bon jusque là, les choses se passent plutôt pas mal.

Partie 1 : Présentation de proxmox et de la virtualisation
Partie 2 : Configuration du réseau interne
Partie 3 : Un petit Stress test pour la route
Partie 4 : Quelques optimisations Webserver
Partie 5 : HTTPS et IPV6
Partie 6 : Le Monitoring
Partie 7 : Les Backup

On a un blog qui tourne, un serveur qui va bien. On va pouvoir commencer à ajouter quelques feature avancées.
Comme le nom de l’article l’annonce, on va pouvoir dans cette 5e partie, s’attaquer au HTTPS et à l’IPV6.

Ce moment où tu trouve enfin la solution.

Le HTTPS

Le https, suffit pas de rajouter un s à l’url ?

Pour faire fonctionner le https et donc utiliser ssl, il va falloir plusieurs points :

  • Pouvoir accéder aux sites web sur le port 443
  • Avoir un ou plusieurs certificats
  • Modifier les vhost des sites pour prendre ça en compte

Et ce pour chaque serveur qui a besoin de https.

Autant dire que ça devient vite chiant à gérer dès qu’on a plus de 2~3 sites web où l’on veut activer le https.

Et la solution ?

La solution est assez simple, on va configurer le reverse proxy pour qu’il s’occupe du ssl.
Ainsi, on centralise les certificats et les configurations sur le proxy et on n’a plus besoin de toucher aux différents serveurs web.
L’utilisateur se connecte en https jusqu’à notre reverse proxy, qui lui établit une connexion en http sur notre venet.

28 août 20130 commentsRead More
Il était une fois, de rapides optimisations web

Il était une fois, de rapides optimisations web

Et ça continue,

Partie 1 : Présentation de proxmox et de la virtualisation
Partie 2 : Configuration du réseau interne
Partie 3 : Un petit Stress test pour la route
Partie 4 : Quelques optimisations Webserver
Partie 5 : HTTPS et IPV6
Partie 6 : Le Monitoring
Partie 7 : Les Backup

Il y a trop de tuto contradictoires sur le net dès que ça parle optimisation

Dans cette partie, on va laisser proxmox et le réseau de coté pour se concentrer sur la VM qui fait office de serveur web.
On va s’attaquer à un peu tous les éléments d’un serveur qui impacte le temps de rendu d’un site : Mysql/Apache2/PHP/Wordpress

Bon pour premièrement, on va utiliser une commande assez simple permettant de vérifier nos optimisations.

ab -t30 -c5 //blog.mondomaine.com/

C’est un tools de Apache nommé ApacheBench et qui permet de faire plein de requêtes sur une url unique.
C’est beaucoup moins réaliste et complet que le test précédent, mais ça peut se faire en local et c’est simple à lancer.
Vous pouvez le relancer en boucle à différents point du tuto pour suivre l’évolution de perf.

Ajoutons quelques tools

Installation de Memcache & Xcode :

aptitude install libcache-memcached-perl php5-memcache memcached
aptitude install php5-xcache

Et modifier /etc/php5/conf.d/xcache.ini

xcache.size = 64M
23 août 20131 commentRead More
Il était une fois, Le nouveau serveur et le test de charge

Il était une fois, Le nouveau serveur et le test de charge

Wololo,

Partie 1 : Présentation de proxmox et de la virtualisation
Partie 2 : Configuration du réseau interne
Partie 3 : Un petit Stress test pour la route
Partie 4 : Quelques optimisations Webserver
Partie 5 : HTTPS et IPV6
Partie 6 : Le Monitoring
Partie 7 : Les Backup

Et voilà 3eme partie, qui celle-là sera bien plus courte que les deux autres, mais sûrement la plus fun.
Ça va consister à vérifier si ce qu’on a fait jusque-là roox du poney ou non, et voir quel est le point de faiblesse de cette infra.

Difficile de se concentrer sur le cablage …

Comment on test chef ?

Il existe plein de moyen compliqué pour faire de vrai stresstests, mais vu qu’on est faignant et qu’on va juste faire un ou deux tests, osef.
Allez, pour ça je vais vous présenter un site loadimpact.com qui va s’occuper de ça pour nous.
C’est un site payant, mais qui propose des comptes gratuits avec lesquels on peut déjà faire quelques tests sympathiques.
Pour schématiser, ce service utilise plein de VM situé chez amazon, et fait des requêtes sur votre siteweb pour en vérifier le comportement.
Il compile les résultats et vous fourni des graphiques clef en main, pas besoin de se faire chier.

Allez, c’est parti on va lancer un premier test, voyons ce que ça donne :

small_test

Et ça test … Et ça test …

Voici le détail : http://loadimpact.com/load-test/blog.ganbaranai.fr-1fdd577124e8d3878896760c9059e236

Alors, essayons de décrypter un peu tout ça, voici les infos les plus importantes :

  • SBU :Nombre de visiteurs simulé (ça reste des scripts, il ne font qu’imiter le comportement d’un visiteur).
  • Requete par Seconde
  • Tcp Connexion
  • Et le plus important de tous, « User load Time », le temps de réponse du serveur.

Si vous avez un système parfait, l’ « User load Time » doit être plat, du début à la fin du test peut importe l’augmentation du nombre de requêtes et de SBU.
Ça veut simplement dire que le temps de réponse du serveur reste stable et que celui-ci n’est pas submergé par la charge.
Comme on peut le voir plus haut, l’infra a l’air de tenir, et effectivement les serveurs ont l’air de se toucher la nouille coté graph proxmox.
Donc je pourrais me satisfaire de ça et me dire que mon blog à l’air de tenir facile pour 50 visiteurs simultanés (je ne les aurais sûrement jamais sur ce blog de toute façon :D)

22 août 20131 commentRead More
Il était une fois, Proxmox derrière une IP unique …

Il était une fois, Proxmox derrière une IP unique …

Amis du soir bonsoir,

Partie 1 : Présentation de proxmox et de la virtualisation
Partie 2 : Configuration du réseau interne
Partie 3 : Un petit Stress test pour la route
Partie 4 : Quelques optimisations Webserver
Partie 5 : HTTPS et IPV6
Partie 6 : Le Monitoring
Partie 7 : Les Backup

Voilà la suite du post d’hier sur proxmox et la virtualisation. Après la présentation, je vais rapidement présenter l’infra et les grandes lignes concernant la configuration.

J’aurai du l’appeler navi le datacenter 😛

L’infrastructure

J’étais pour le coup soumis à quelques contraintes externes, par exemple Kimsufi sur l’offre 2013 ne permet plus la prise en charge des IP-failover.
Cela aurait permis de faire pointer plusieurs IP sur un même serveur et ainsi de pouvoir attribuer une IP à certaines VM.

J’étais donc contraint d’avoir l’ip sur mon host et de devoir gérer moi-même le trafic entrant.
J’ai donc décidé assez simplement :

  • De mettre toutes mes VM en venet (donc sur un VLAN interne) et donc sans accès au net.
  • Ajouter une interface sur la machine Hote pour qu’elle puisse accéder au venet
  • Configurer la machine hôte pour autoriser le forwarding VLan<->Internet
  • Et finalement gérer les connections externe via du Nat et Iptables.

Donc depuis le réseau interne, les VM ont accès à internet sans problèmes.
Depuis internet, une IP (celle de la machine hôte) et en fonction des requêtes et du port utilisé on arrivera sur la VM adéquate.
Cela permet également de cacher son infra à des bots/robots qui tenterait de scanner les machines pour y trouver des failles.
Je vais donc vous décrire dans la suite de l’article, les différentes étapes permettant d’arriver à ce résultat.