Discussion :

[slyz0r]

Bonjour à tous,

Je m'occupe actuellement de la partie infrastructure d'un parc de serveurs hébergeant une application web Java. Ce parc se compose de 4 serveurs physiques hébergés dans un data center.

• 1 serveur sous RHEL: Apache + JBoss
• 1 serveur sous RHEL: Apache + JBoss (Backup - Synchronisé)
• 1 serveur sous RHEL pour la base de données: MySQL + Logiciel gérant le failover
• 1 serveur sous RHEL pour la base de données: MySQL + Logiciel gérant le failover (Slave - Backup)

En ce moment, si ma base master tombe, automatiquement l'autre prend le relais. Si mon serveur d'application tombe, je dois manuellement relancer le service sur l'autre serveur.

Afin d'épargner les coûts, faciliter la gestion d'administration et améliorer la disponibilité, je réfléchis à la virtualisation.

Je suis actuellement assez novice dans le domaine et j'ai quelques questions.

Que pensez-vous de cette architecture:

• 1 serveur physique avec 2 machines virtuelles sous RHEL:
  
  1. Apache + JBoss
  2. MySQL master + logiciel gérant le failover

Ces deux machines virtuelles hébergeraient mon application en production.

• 1 serveur physique avec 2 machines virtuelles sous RHEL:
  
  1. Apache + JBoss en standby
  2. MySQL slave + logiciel gérant le failover

Ces deux machines virtuelles seraient en standby.

Faudrait-il un troisième serveur ? Une sorte de station qui superviserait l'état des VM's ? J'imagine qu'il est possible de mettre en place un failover automatique de la VM déployant l'appli web (JBoss) ?

Actuellement, ma base de données fait 150G et j'ai besoin de pas mal de mémoire vive. Je dirais entre 32 et 64 pour le serveur MySQL et entre 16 et 32 pour le serveur d'application. Connaissez-vous un provider fournissant des serveurs dédiés capable de supporter cela ?

Qu'en pensez-vous ? Est-ce réalisable ? Niveau performance, ça va donner quoi ? Voyez-vous une architecture différente ?

Merci de m'avoir lu jusqu'au bout,

Sly-

[Christophe]

Regardes peut-être du coté de Heartbeat pour le failover.

Si tu veux gérer 2 "gros serveur" en virtuel sur 1 seule machine ( et x2 ), c'est peut-être plus pertinent d'utiliser 4 moyens serveurs et sans couche virtuelle ce qui allège quand même la maintenance.

Pour des machines dimensionnés sur mesure c'est plutôt via du cloud, j'entends par là du IaaS, pas forcément du S3 d'Amazon.

[slyz0r]

Merci chrtophe.

Je connais la solution heartbeat, je l'ai déjà testé.

Je pensais que cela serait plus simple de gérer des vm's, surtout point de vue évolution. De plus, un failover vmware ne serait pas plus sûr ?

[Invité]

Salut,

je pense que dans ton cas tu peux te poser la question d'envisager de prendre un seul gros serveur blade. Tu virtualises tout sur cette machine et tu utilises heartbeat/keepalived. Je préfère keepalived perso, plus simple.
Ou sinon comme tu as dis, t'en prends 2 mais çà fait 2 serveurs physiques à maintenir même si çà réduit le risque.

Je ne peux pas te répondre sur la gestion de Haute Dispo de l'hyperviseur. Je ne m'y connais pas assez, mais en général j'ai personnellement tendance à éviter de trop centraliser les tâches et à segmenter et compartimenter. C'est plus facile en cas de problème pour débugger et si un truc plante ça concerne qu'une seule fonctionnalité pas tout. C'est pour ça que même si tu prends 2 serveurs comme des dell poweredge, on peut se demander si tous les masters doivent se mettre sur le même serveur.

Si tu as 2 serveurs physiques y a t"il un intérêt à virtualiser ? T'envisage de compartimenter tes clients et d'associer 1 ou 2 VM pour chacun ? Comment tu vois l'évolution de l'archi ?

Après faut que tu vois les coûts aussi.