Le but de cette série d'articles est, à travers un scénario, de pouvoir se familiariser avec quelques technologies ( différentes de celles d'OpenStack ) permettant de répondre au contraintes de scalabilité et de High Availability. Ce scénario consiste en une appli web avec des millions de requêtes, ce qui demande des performances énormes, ainsi qu'une disponibilité exemplaire.

Il nous faut donc décomposer au maximum les différentes composantes de notre site web, afin de pouvoir optimiser chacune d'elles. En plus de ça il nous faudra redonder chacun des services…

Le but de cette série d'articles sera d'expliquer et de mettre en place chacun des points de cette infrastructure WEB un peu hors norme ¹⁾:

Hésitez pas à cliquer sur l'image pour l'agrandir, sinon on voit pas des masses.

Note : on peut faire du DNS Roud Robin si on a envie de load balancer le premier load balancer… A partir d'un certain débit, on est obligé d'en avoir plusieurs, et je vois pas comment faire autrement. Pour des raisons pratiques, les autres load-balanceurs n'apparaissent pas sur le schéma²⁾…

Note : j'ai délibérément choisit d'utiliser des technologies “old school”. Je sais que tout serais plus simple avec OpenStack. Mais la question qui a amené cette série d'articles était “J'aimerais avoir une idée de comment faire ce type d'architecture simplement, sans utiliser les possibilités de Neutron”.

La redondance des routeurs est pensée en HSRP qui est un protocole de chez cisco. En gros les deux routeurs en regard se partagent une adresse ip virtuelle et en cas de panne d'un d'entre eux, l'autre prend le relais.

La redondance du firewall est obtenue grâce à CARP. CARP est un autre protocole de partage d'ip virtuelle développé par BSD. conntackd permet de synchroniser les conntracks des deux pare-feux.

Les serveurs sont branchés en link aggregation sur au moins deux switchs d'une stack (par exemple des 3750…). Voici par ailleurs pour le coté switch.

La synchronisation des données entre data-centers peut se faire par l'intermédiaire de VXLAN (par exemple) que nous routerons séparément.

Un premier point est d'utiliser les vues DNS de BIND pour faire que chaque client accède au data-center le plus proche³⁾.

Je vais essayer de fournir un CDN libre autre que celui d'Openstack. C'est étrangement très dur à trouver sur Google. Toute aide / conseil sera le bienvenu.

Concernant l'architecture web :

• Les load balanceurs agissent en couche 4, et sont basés sur HAproxy. Pour les redonder, nous allons utiliser une ip virtuelle avec le protocole VRRP. Keepalived s'en chargera pour nous. Si un jour vous avez envie de redonder un truc pas en TCP, je vous propose d'utiliser soit du DNS Round Robin soit avec keepalived utilisé en mode load balancer. Le load balancing des loads balancers peut aussi être réalisé par DNS round robin.

• Les reverse proxys sont basés sur NGinx, ou bien sur Varnish.

• Une grille NoSQL peut être utilisée afin d'accélérer les requêtes. Je vous redirige vers la page wiki sur Elastic search, réalisée par François Monniot.

• Enfin, niveau SQL, je propose de détailler un cluster de SQL avec MySQL Galera. Par ailleurs des noeuds de réplication peuvent être mis en place afin de permettre une étude des données sans perturber les clients.

Cette infrastructure a certes de quoi faire rêver, mais elle implique des contraintes en terme de programmation. Cette page a pour but de présenter celles auxquelles je pense.

Car une série d'artcles sans un seul troll est une mauvaise série d'articles, je vais vous présenter une solution de load-balancing au niveau IP sur laquelle je suis tombé pendant mes recherches sur les autres topics… C'est osé comme concept, et dégueu… Il s'agit de multipath routing.

Et comme chacun le sait je suis un fou du stockage Et il semblerait bien que je ne sois pas arrivé mentalement sain à l'issue de cette série d'articles. Alors, comme il faut mélanger les plaisirs, je vais vous préparer un petit artcile sur comment faire du failover sur des serveurs NFS c'est pas beau ça?

Je vous propose une découverte de quelques Systèmes de fichiers distribués. Nous parlerons par exemple de CEPH, de GlusterFS. C'est assurément plus “propre” que les bricolages du chapitre du dessus quand il s'agit d'obtenir du failover… Et c'est pensé pour être scalable. Que demande le peuple. ⁴⁾

• Retour d'expérience d'une entreprise aillant dû supporter 18 fois sa charge habituelle pendant une soirée. Ils avaient du temps pour anticiper. C'est par ici.

— Benoit Tellier 2014/01/25 16:06