Multi-path routing

Je vous propose ici une solution de load balancing légeremnt osée … En fait ça tient plus du hack qu'autre chose… En effet il n'y a pas :

  1. de helf check pour les serveurs back-end qui demanderont d'être redondés.
  2. Une configuration de tous les clients potentiels qui demande une route ip…
  3. Et enfin, on a pas des masse le choix, il y a un mapping entre clients et serveur backend. Et à priori pas des masses de moyens de contourner ça.

Je vous le met car :

  1. ça m'a fait sourire
  2. c'est une solution qui me semble “dégueu” mais marche
  3. ça me semble dans le sujet et c'est pour l'instant le seul exemple de load balancing de niveau 3 que j'ai trouvé.

Clairement je mettrais pas ça en prod. C'est tout juste bon à faire mumuse en DEV… Je préfererais même le DNS round robin…

Voici le principe :

Les clients demandent l'ip commune à tous les serveurs back-end.

Le “load balanceur” se contente de router le client vers un des serveurs back-end.

Les serveurs back-end ensuite se forwardent le messages à eux mêmes grâce à cette ip commune…

Pour parvenir à ceci, il faut :

Activer le forward sur le load-balancer, et sur les serveurs back-end.

Sur les clients : 

  ip route add 192.168.150.0/24 via 192.168.102.136

Et sur le “load balancer ip” : 

  192.168.150.0/24 nexthop via 192.168.103.167 nexthop via 192.168.103.166

Voilà voilà…

Note :

C'est plus propres si l'ip commune à ce groupe de serveur appartient à un réseau différent, mais ça demande des contraintes très fortes sur l'architecture de votre réseau…

Personnellement, je pense que temps qu'à avoir une solution sale, autant que ce soit sal jusqu'au bout 1). Le but de l'ip commune c'est qu'un serveur back-end puisse se reconnaître. Il ne s'en sert jamais pour communiquer avec qui que ce soit. Donc pourquoi prendre la peine de séparer les réseau? Oui c'est contre les best pratique élémentaires 2), mais ça n'a aucune incidence : cette solution est restée en place pendant deux heures sans se faire griller par arpwatch et ses horribles flip-flops…

Et je ne signerais pas cet article… Question de principe.

1)
c'est pas destiné à la prod non? De toute façon sur le cluster de DEV proxmox j'avais pas des masses le choix
2)
de toute façon cet article est complètement trollesque, autant aller jusqu'au bout…