e-sup UNR PACA

Vous êtes ici -> ArchiMagine
Home :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-3-218-67-1.compute-1.amazonaws.com

Proposition Avignon

(Thomas) - draft - obsolete
Je vous propose une ébauche d'architecture basée sur LVS & HA. Le but étant que la plate-forme soit redondante et échelonnable.
Pour imager voici un petit croquis.

LVS.png?

Fonctionnement normal : comment le client atteint le service ESUP ?
  1. Le CLIENT se connecte via une URL : ex: http://esup.univ-avignon.fr
  2. Cette URL contient un FQDN associé a une IP virtuelle (VIP) qui est montée sur VS01
  3. VS01 répartit la charge entre les 2 tomcats selon un scheduler quelconque.
  4. Les 2 tomcats vont chercher leurs éventuelles infos sur un filer via NFS (ex: canal stockage)

Mode de fonctionnement LVS : comment retourne-t-on l'info au client ?
Il y a 2 possibilités pour LVS:

  • en NAT donc l'info passe par le VS
    • Avantage : facile a configurer, économie d'IPs publiques
    • Inconvénient: goulot d'étranglement, utilisation CPU pour conntracking, gigue plus grande
  • en DR (Directrouting), le serveur TOMCAT répond directement au client lambda sans passer par le VS
    • Avantage : rapide, débit illimité (X fois carte rezo TOMCAT)
    • Inconvénient : patch du noyau des TOMCATS (patch stackip pour l'ARP parce que les Tomcat auront également la VIP de montée de ce fait ils ne doivent pas répondre au requêtes « Qui a l'IP 'VIP' ». Sinon il y a 2 serveurs qui répondent et de grosses bizarreries apparaîtrons ;-).


Fonctionnement en cas de panne d'un VS : mode dégradé
Le VS02 est relié en HA avec VS01 ainsi si VS01 tombe suite à une panne quelconque, VS02 reprend la main en montant l'adresse VIP.
Quand VS01 revient , VS02 rend la VIP.
Le HA est rendu grace au logiciel HeartBeat? à travers une liaison série permettant de tester le « pouls » de VS01

Fonctionnement en cas de panne d'un TOMCAT : mode dégradé
Sur les VS, il y aura un démon qui pourra sortir du pool un serveur tomcat si celui-ci ne repond plus. Réciproquement, il pourra le reintégrer dès que le service sera à nouveau rendu par le tomcat qui était défecteux. Diverses possibilités : keepalived, lvs-kiss ou bien un script homemade.

Ressources matérielles nécessaires
- Pour la plate-forme TOMCAT
+ 2 serveurs LVS : Celeron 500Mo 128Mo (pas besoin de ressources particulières - je vous donnerai les résultats des tests de charge)
+ 2 serveurs TOMCAT : P4 3Go 512Mo (jabba c'est gourmand ;-)
- Externes a la PF
+ 1 FILER
+ X serveurs LDAP

Mise en garde
Dans l'installation & l'utilisation de LVS, il faut patcher les noyaux linux. Donc pour les utilisateurs de RedHat? AS ou Entreprise, attention à vos eventuels problèmes de support RH!

*UPDATE* J'etais pas au courant mais en fait depuis le 2.4.26 ou 2.6.5, il n'y a plus besoin de patch suffit d'injecter ds valeurs ds /proc

2.4.26pre and 2.6.4pre will come with 2 new device flags for tuning the ARP stack: arp_announce and arp_ignore. All IPVS like setups can use arp_announce=2 and arp_ignore=1/2/3 to solve the "ARP problem" with DR/TUN setups. These flags are going to replace the "hidden" functionality which does not work well for directors when they are changing their role between master/slave for a particular VIP. The risk is that other hosts can probe for VIP using unicast packets which the hidden flag always replies. I'll continue to support the hidden flag for 2.4 and 2.6 to help existing setups but switching to the new device flags (or other solutions) is recommended.




Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]