#DJERFY.com – Nouvelle plateforme

Bonjour à vous 🙂

L’aventure devait commencée début de l’année, en Mars 2013 exactement, mais par grand manque de temps, nous avons pris du retard.
Nous manquons de performances ( surtout niveau CPU et RAM ) et c’est pour cette raison que nous mettons en place cette nouvelle plateforme.

Nous avons aussi des upgrades de version de nos applicatifs comme en gros ( expliqué plus bas dans d’article ) :

• Apache 2.2 -> 2.4
• PHP 5.2 -> PHP-FPM 5.3
• FTP -> SFTP
• + OpenVPN
• + LoadBalancer HA-Proxy
• Varnish 3.0.0 -> 3.0.3
• …

Vous l’aurez compris, nous avons bien de quoi jouer pour les mois à venir 🙂
La location du serveur est effectué chez ONLINE et voici le lien pour les personnes intéressées.

Vous avez envie de plus de détails ? Alors lisez la suite !

FIREWALL ( FW )

Nous rajoutons un nouveau serveur en tête de la plateforme, qui est notre firewall sous le nom de « DJERFY-FW-1 ».
Un second serveur arrivera une fois la plateforme fonctionnelle mais il ne sera pas visible ( failover ).

Ce serveur comporte donc :

• un filtrage du trafic entrant ( via iptables )
• un serveur OpenVPN ( qui partage ensuite vers le réseau privé )
• un LoadBalancer géré via HA-Proxy et qui permet de gérer :
  • la VIP MySQL
  • la VIP HTTP vers les RPC
  • la VIP HTTP vers les WEB ( non actif, uniquement en cas de crash des RPC )
  • la VIP HTTPS vers les RPC
  • la VIP HTTPS vers les WEB ( non actif, uniquement en cas de crash des RPC )
  • la VIP DNS ( LB entre NS1 et NS2, sa peut être utile )
  • la VIP Memcached ( nous avons du Memcached en master/master )

Le serveur slave ( DJERFY-FW-2, arrivera par la suite et sera ISO par rapport à celui-ci, accessible depuis l’IP privée, il faudra simplement monter la carte publique si nécessaire ).

REVERSE PROXY CACHE ( RPC )

Nous avons à présent deux serveurs RPC qui tournent sous VARNISH 3.0.3. Les deux serveurs sont donc totalement ISO.
Nous avons également le service Memcached qui tourne dessus dans le mode « master/master » entre les deux RPC, ce qui permet d’avoir une redondance en cas de crash d’un RPC ( testé et approuvé fonctionnel ).

Nous gardons ( pour le moment ) la même configuration ( VCL ) de l’instance Varnish. Le fonctionnement de cette manière est pleinnement fonctionnelle, nous la toucherons une fois la plateforme terminée ( pour les optimisations ). Nous avons par contre modifié la configuration des backends ( ben oui hein ! ).

Nous avons également le service MEMCACHED qui tourne sur les deux RPC dans le mode « master/master ». En gros, chacun est une réplication de l’autre.
Cette partie est testé aux petits oignons et bien fonctionnelle 🙂

Nous aurons aussi le service BIND qui viendra sur les deux RPC, mais prévue seulement à la fin des migrations car beaucoup de boulot. Je ne vais pas m’avancer sur cette partie ( en plus, rien n’est effectué pour le moment ).

BASES DE DONNEES ( SQL )

Pour les bases de données, nous utilisons MYSQL dans la version 5.5 sur deux serveurs.
Nous restons sur le fonctionnement du « master/master », d’ailleurs nous n’avons plus eu de problème par la suite avec ce mode de fonctionnement.

Le gros changement sera sur la sauvegarde des bases de données ou nous utiliserons la sauvegarde par snapshot LVM. Pas plus de détails pour le moment.

APACHE/PHP ( WEB )

Pour le service Apache, nous passerons toujours par les packages du système ( CentOS 6.4 ), l’avantage, c’est que nous pouvons garantir des correctifs rapide que nous ne pouvons pas réellement avoir lors d’une compilation ! Nous ferons également un upgrade avec un passage de la version 2.2 à la version 2.4, du changement mais pas trop non plus 🙂

Pour le service PHP, nous allons migrer tranquillement vers le PHP-FPM. C’est sur cette partie que nous allons avoir beaucoup de travail. Les configurations des vhosts seront aussi très différentes.
Nous devons donc faire la création d’un script qui permet d’avoir une gestion sur toute cela ( création, suppression, maintenance, check des droits, checks des logs, etc etc ).
Quand à la version, nous passerons sur la version 5.3.3 mais sans réelle confirmation.

Tous les sites seront dans un dossier spécifique qui sera un montage ZFS ( nous allons y venir un peu plus bas ). Donc nous avons avoir seulement les fichiers de logs en local sur les serveurs WEB.
Pour les versions, nous devons confirmer cela dans les semaines à venir 🙂

MONTAGE ZFS ( NAS )

L’ensemble des données de nos sites internet sera dans le dossier « /home/sites_web » qui sera un dossier partagé.
Ce dossier partagé sera maintenue par deux serveurs nommé « NAS », toujours pour avoir un serveur en cas de crash.

Voici un petit résumé de ce que nous allons avoir :

• Mise en place du heartbeat ( un IP privée sera partagée pour nos deux serveurs NAS )
• Mise en place du DRBD pour la redondance des données

Nous n’avons pas encore eu le temps de travailler sur le sujet, c’est donc encore un peu flou sur la configuration du NAS vers les WEB.
Vous devrez avoir donc plus de détails dans les semaines à venirs 🙂

BACK OFFICE ( ADMIN )

Un serveur dédié sera mis en place pour le back office et accessible uniquement depuis l’interface privée. Ce serveur n’est pas pour les CMS mais pour l’administration de la plateforme.
Voici un petit projet de ce que nous allons avoir dessus :

• AJENTI qui permet une rapide configuration, les scripts seront mis en place pour pousser cette configuration sur les frontaux. Nous regardons pour faire un mélange entre AJENTI et PUPPETMASTER.
• PUPPETMASTER, pour déployer nos configurations sur les serveurs ( hosts, postfix, syslog, sshd, etc etc )
• MUNIN Server, pour le traitement de nos graphes de la plateforme

C’est donc cette configuration qui viendra sur le serveur, à voir ensuite avec de meilleurs propositions 🙂

MAILS ( ZIMBRA )

ZIMBRA sera de la partie, logiciel gratuit et OpenSource. Nous avons déjà commencé à l’utiliser sur un environnement de développement.
Pas plus de détails pour le moment non plus car il sera mis en place une fois la plateforme opérationnelle.

DNS ( NS )

D’origine, nous devions mettre deux serveurs DNS ( alias NS ) mais cela ne sera pas possible 🙁
La raison ? Nous sommes réellement restreint par le nombre d’adresses IP ( failover chez ONLINE ). Le service DNS sera mis en place directement sur nos deux serveurs RPC.
Si vous avez suivis un peu l’article, vous avez du le comprendre un peu plus haut.

SAUVEGARDE ( BACKUP )

Notre serveur possède un total de 2To seulement, effectivement, quand nous avons beaucoup de données, cela fait très peu de place.
Nous gardons à l’idée d’avoir un dossier partagé que chaque serveur pourra monter si besoin afin de faire les sauvegardes.

Cette méthode est déjà en place et nous ne pensons pas y toucher.
Les données de la sauvegarde seront par contre réellement définie sur 1 mois ( 31 jours ) pour ne pas prendre trop de place et ne pas avoir une saturation comme nous l’avons eu plusieurs fois déjà…

DEVELOPPEMENT ( DEV )

N’oublions pas notre serveur dédié aux développements. Il sera faible en performances car nous ne serons pas beaucoup à l’utiliser.
Déploiement un peu à l’arrache pour ce serveur 🙂

A bientôt pour la suite de l’aventure !
( n’oubliez pas de me suivre sur Twitter avec @djerfy )