#DJERFY.com – Nouvelle plateforme

 dans Actus, Linux, Outils, SĂ©curitĂ©, Serveur

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 )

 

 

Articles recommandés

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.