Switch applicatif avec OpenBSD, un Altéon à la maison ?…

Dans une infrastructure informatique sensible, la disponiblité des applicatifs est primordiale.

Pour répondre à cette exigence, les solutions mises en oeuvre se basent donc sur de la haute-disponibilité et de l’équilibrage de charge (communément appelé LoadBalancing).

J’avais déjà évoquer la haute-disponibilité sous Linux dans ce billet et abordé ce type d’architecture dans celui ci.

Je vais donc aller un peu plus loin dans ce concept et tenter de mettre en oeuvre un équivalent « open-source » d’un produit commercial.

Ceux qui d’entre vous travaillent ou ont travaillé dans ce genre d’environnement, doivent avoir de fortes chances d’avoir croiser dans les baies des boitiers « Alteons ».

(merci à Morgan pour les Altéons :-)))

(merci à Morgan pour les Altéons :-)))

Alteon WebSytems est une société américaine spécialisée dans la haute-disponibilité et rachetée par Nortel fin 2000.

Les produits s’appellent désormais AS (pour Application Switch) et vous trouverez un comparatif des boiboites ICI, mais par facilité, le terme « Alteon » est toujours employé.

Sachez que chez CISCO également il existe ce genre de solution (ACE).

Je ne rentrerais pas dans les arcanes d’un altéon mais en voir rapidement le principe et d’en construire un équivalent chez soi.

Globalement, le principe est le suivant :

(source image IBM)

(source image IBM)

La configuration se fait sur 4 points principaux donc je vais vous détailler la configuration ci-dessous.

Il s’agit d’une configuration de base pour un loadbalancing en haute-dispo sur 2 serveurs web.

Spécial grand Merci à Steven pour son aide sur l’Alteon 😀

1 – Les serveurs réels

Il s’agit des applications à « load balancer ».

/cfg/slb/real 1
enable
rip aa.bb.cc.dd     #l'ip du serveur réel 1
retry 2     #nombre d'essai avant de considérer le serveur comme down
restr 2     #nombre d'essai avant de considérer le serveur comme up
inter 15     #intervalle entre 2 checks en secondes
name lenom
/cfg/slb/real 2
enable
rip aa.bb.cc.ee
retry 2
restr 2
inter 15
name lenom

2 – Le groupe

On regroupe ensuite les applications à « load balancer » au sein d’un même groupe. Le groupe comprend les Real Servers ainsi que le « jeu » de test permettant de vérifier leur bon état.

cfg/slb/group 1
health http     #service concernée, ici http mais peut être : link|arp|icmp|tcp|http|httphead|dns|pop3|smtp|
nntp|ftp|imap|sslh|radius-auth|radius-acc|radius-aa|script|udpdns|wsp|wtp|wtls|ldap|snmp|tftp|rtsp|sip|wts|dhcp
viphl disable     #désactive le check VIP lié au DSR (Direct Server Return)
content "/status.html"     #la page a checker
add 1     #ajout du serveur réel 1 dans le groupe
add 2     #ajout serveur 2 dans le groupe
name lenomdugroupe

3 – Le virtual server

Un Virtual Server se caractérise par son adresse virtuelle (VIP), son port d’écoute virtuel (service), le groupe de Real server auquel il est associé et les ports d’écoute des Real Servers

/cfg/slb/virt 1
enable
vip 10.1.1.1
 
/cfg/slb/virt 1/service 80
group 1
hname lenom
epip ena     #on force la sélection par egress ou VLAN

4 – le virtual router

Le routeur virtuel qui contient la VIP, le groupe, l’interface physique et la priorité par rapport à son « voisin ».

/cfg/l3/vrrp/vr 1 (avec le chiffre égale au virt associé)
ena
vrid n     # le numero du Virtual Routeur
if 1     # l'interface
prio 99     #la priorité (plus le chiffre est haut plus l'atéon est prioritaire par rapport a l'altéon de backup)
addr 10.1.1.1     #la VIP
share dis     #on désactive l'extension Nortel VRRP

Un dessin valant toujours mieux qu’un long discours 😉 , nous allons imaginer l’architecture suivante :

  • 2 Altéons
  • 1 VLAN dédié aux IP loadbalancées en 10.0.0.0/24
  • 1 VLAN dédié aux serveurs Web en 192.168.1.1/24
  • 2 serveurs Web

C’est forcément simplifié au maximum mais cela donne une idée de ce que nous allons mettre en place.

Avec des « Altéons », nous aurions donc ce genre de schéma :

Shématisation Alteon

Shématisation Alteon

Le but étant de reproduire a peu près la même chose chez soi, il y a un système d’exploitation qui contient déjà tout ce qu’il faut pour cela : OpenBSD.

Alors, oui, on pourrait faire la même chose avec Linux, en se tapant l’installation d’Ucarp, Balance, LVS et/ou autres joyeusetés, mais personnellement, je préfère laisser cela a OpenBSD qui peut le faire nativement et qui a fait ses preuves en environnement réseau critique.

Après tout, OpenBSD est amour, avec du poil autour, et c’est tout.

Reprenons notre schéma et adaptons le à une solution basée sur 2 serveurs sous OpenBSD pour remplacer les « Altéons » :

Schématisation OpenBSD

Schématisation OpenBSD

Ne reste qu’a configurer tout cela 😀

  • CARP + VLAN (optionnel)

Définir une VIP sur nos OpenBSD (une interface CARP sur interface physique ou sur interface VLAN)

/etc/sysctl.conf
 
net.inet.carp.preempt=1
net.inet.carp.allow=1
 
#ifconfig carp0 create
 
#ifconfig carp0 vhid 1 pass motdepasse carpdev em0 advskew 1 10.0.0.1 netmask 255.255.255.0
 
Pour un VLAN (exemple):
cat /etc/hostname.vlan3
inet 10.0.0.3 255.255.255.0 vlan 3 vlandev em0
 
cat /etc/hosname.carp0
inet 10.0.0.1 255.255.255.0 10.0.0.255 vhid 1 carpdev vlan3 advskew 1 pass motdepasse

Je ne m’attarde pas la dessus, en ayant déjà parler sur CE BILLET.

  • PFSYNC
ifconfig pfsync0 syncpeer "ip openbsd en face" syncdev em1
ifconfig pfsync0 up
  • Partie PF / Hoststated
/etc/pf.conf
 
rdr-anchor "hostatetd/*"
 
table  persist { 192.168.1.1, 192.168.1.2 }
 
rdr on $carp0 from any to $ipcarp port 80 ->  round-robin sticky-address
 
# la variable sticky-address signifie que PF maintient la session du client sur le même serveur
 
/etc/hoststated.conf
 
real1="192.168.1.1"
real2="192.168.1.2"
vip="10.0.0.1" # VIP CARP
 
interval 5 #on vérifie l'état des serveurs toutes les 5 secondes
 
table messerveurs {
check http "/status.html" code 200
timeout 300
real port 80
host $real1
host $real2
}
 
service www {
virtuel ip $vip port 80
table messerveurs
}

Petite explication :

On utilise une table « messerveurs » qui contient la liste des serveurs à « loadbalancer ».
PF redirige les requètes entrantes sur la VIP (10.0.0.1) alternativement (round-robin) et maintient la session du client sur le même serveur (sticky-address).
Bien évidemment, tout cela est optionnel et à vous d’adapter selon vos applis (man pf 😉 ).

Le démon Hoststated vérifie que les serveurs réels sont bien vivants en appelant la page status.html sur chacun des serveurs de sa liste.
En cas de non réponse (code retour http différent de 200), il considérera le serveur comme down et le retirera de la table « messerveurs ».

C’est pas beau tout cela ? 😀

La commande # hoststatectl show vous donnera l’état des serveurs et vous pouvez manuellement les sortir ou les remettre dans le pool (# hoststatectl host disable/enable 192.168.1.x).

Et petit bonus, vous pouvez agir directement sur la couche 7 😉

Exemple de relais load-balancé HTTPS :

protocol monchteuteupeucrypte {
protocol http
header append "$REMOTE_ADDR" to "X-Forwarder-For"
header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarder-By"
header change "Keep-Alive" to "$TIMEOUT"
url hash "sessid"
cookie hash "sessid"
path filter "*command=*" from "/cgi-bin/index.cgi"
 
ssl { sslv2, ciphers "MEDIUM:HIGH" }
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
}
 
relay wwwssl {
listen on $vip port 443 ssl
protocol monchteuteupeucrypte
table messerveurs loadbalance
}

Maintenant que je vous ai titillé avec tout cela, je vous invite, outre à manger les MAN d’OpenBSD, mais aussi à lire cet excellent ouvrage :

The Book of PF
A No-Nonsense Guide to the OpenBSD Firewall
Par Peter N.M. Hansteen

Vous le trouverez chez Amazon par exemple :
http://www.amazon.fr/Book-PF-No-nonsense-Guide-Firewall/dp/1593271654

Conclusion :

Loin de moi l’idée de vous dire qu’une architecture comme celle-ci sera tout aussi efficace qu’un Switch Applicatif hors de prix, il existe des fonctions sur ces boitiers que l’on peut évidemment reproduire mais qui demanderons du temps…

Par contre, ce type d’architecture n’a pas a rougir en Production pour load-balancer des applications se prétant à ce jeu.

Amusez vous bien 😉

Ce billet a été posté dans architecture, cisco, OpenBSD et taggé , . Bookmark ce permalink.

5 commentaires sur “Switch applicatif avec OpenBSD, un Altéon à la maison ?…

  1. Avoue le, tous tes schémas sont fais avec visio sous windows !!!!!

    Merci encore pour toutes ces infos

  2. J’avoue sans problèmes 😀

    En fait, c’est bien un des rares produits de Microsoft que je trouve bien fait et joli 🙂
    A quand les mêmes « stencil » dans Dia 😀

    De rien Pascal 😉

  3. Salut,

    Merci, interessant ton post. Je voulais juste dire qu’avec keepalived on peut faire la même chose. Pas besoin d’installer UCarp ou autre chose…

    La configuration est simple est lisible. Je l’ai déjà utilisé pour la redondance de routeur/firewall.