Créer un caching HTTP façon CDN

C’est la mode au tout Cloud. Je ne m’étalerais pas sur mon avis très critique à cette mode commerciale. Cependant, le fonctionnement des sites en eux-mêmes changent peu et la mode du Cloud n’entache en rien le besoin de performance. C’est le service proposé par de nombreuses société de part de le monde avec des services de livraison de contenu (CDN) qui inclus :

• distribution HTTP de contenus statiques
• accélération HTTP de contenus statiques
• streaming audio/vidéo live ou on-demand

Je vais donc me focaliser sur comment monter une plateforme minimale de livraison HTTP et d’accélération HTTP. Attention, il y a plusieurs pages (menu sous les liens de partage).

Avant propos et plateforme HTTP

L’accélération web consiste en la fourniture d’un service HTTP fiable, perfomant, et allégeant la charge sur la plateforme web du client : tout le contenu statique doit être fournit par la plateforme d’accélération ou au maximum, alors que les pages dynamiques sont services par la plateforme du client. Une plateforme d’accélération est simple à mettre en place. La problèmatique par contre, va résider principalement dans les performances (systèmes et réseaux) et dans les fonctionnalités avancées offertes aux clients.

La distribution HTTP repose sur le même principe à la différence que l’on doit héberger le contenu. Il est important qu’une machine qui fait de la distribution ne fasse pas d’accélération et inversement. Cette restriction est importante car les optimisations divergent quelques peu. Je ne m’attarderais pas sur l’installation des systèmes en eux-même.

Le matériel

Les performances dépendent aussi bien des logiciels et de leurs configurations, que du matériel choisi. Selon les moyens, on choisira entre l’aggrégat d’interface en gigabit ou la mise en place de cartes 10 Gbps. Il est à noté que les temps d’accès sont différents entre de l’optique et du cuivre, à l’avantage de l’optique.

De même, des SSD sont à privilégier pour le cache disque lors que des disques en 15k rpm ou 10k rpm peuvent suffire sur la partie distribution.

Pourquoi je me refuse à prendre des appliances ?

• limitées dans les fonctions additionnelles (ou sous licenses trop chères)
• peu évolutives
• performances largement en retrait par rapport à du home-made

Le logiciel

Il est intéressant de privilégier pour les noeuds de cache, des machines diskless, au système démarré en PXE et mis en Ramdisk. Si vous avez besoin d’un article sur ce point, laissez-moi savoir. L’avantage est de réduire les I/O disques lié au système.

Côté mise en cache des objets, on se penchera sur un gros RAID0 de disques en SSD, le tout avec un formatage en XFS. Pourquoi pas en Ram ? simplement parce qu’il est facile de saturer les accès concurrents en Ram dans le cas d’un CDN et que les performances sont largement suffisantes avec une belle grappe de SSD.

Côté service HTTP, on utilisera nginx, aussi bien pour la distribution que pour le caching.  Pourquoi pas d’autres ?

• varnish en caching : il est moins extensible que nginx, un chouillat plus lourd et je le trouve clairement moins agréable à l’utilisation
• squid en caching : monolithique et non multithreadé, on y perd en performance et en optimisation ; de plus sa configuration est trop lourde et ses performances sont au final en retrait
• apache en caching ou en distribution : oui, pourquoi ne pas utiliser une gros usine à gaz polluante, archaïque et peu performante à la place de solution légère et performante ?

On n’écrit rien en local niveau log : on mettra en place un syslog distant et centralisé. L’attrait est double : réduire les I/O locales et pouvoir facilement générer les statistiques HTTP.

La plateforme HTTP

Celle-ci regroupe donc à minima (et hors volonté de redondances sur tout) :

• un serveur PXE pour fournir les OS aux machines diskless (non détaillé ici) (pxe)
• un serveur syslog et statistiques (stats)
• un serveur de base de données pour le backoffice offrant aux clients ou à l’équipe les outils pour le déploiement des configurations par vhosts (non détaillé ici) (db)
• les serveurs de monitoring et management (master)
• les serveurs de caching (on parle d’edges) ; il y aura 2 niveaux, donc on détaillera en edge / source
• les serveurs origins HTTP

Pour des raisons de disponibilité (et de proximité), on sera amené à dupliquer autant de fois qu’il le faut chaque élément sur des sites distants. La plateforme est duplicable à volonté.

L’architecture est une pyramide inversée, à savoir à minima :

• 4 serveurs edge qui attaquent
• 2 serveurs source qui attaquent
• la plateforme du client ou 2 serveurs origin

Les autres serveurs sont mis en parallèle de ce déploiement.

Le réseau

Les VIP en mode DSR seront gérées par des LVS déployés sur les masters. On peut aussi investir dans des cartes ACE. Sur la partie GSLB (load balancing géolocalisé) je vous conseille de vous référer à votre ingé réseau sur les possibilités de votre infra au niveau déclaration des entêtes & co. En effet, faire du GSLB en DNS pour la plateforme en elle-même est un peu moins efficace :

• à cause des serveurs DNS des FAI qui ne respectent pas les TTL (Free par ex …)
• à cause des utilisateurs passant par des serveurs DNS tiers (Google, OpenDNS) qui faussent le calcul de géolocalisation
• du fait que le site mis en cache doit aussi l’appliquer dans sa zone DNS et que c’est parfois compliqué de motiver un client

La qualité du transit et des peerings est un point important pour assurer d’excellentes performances du CDN.

On note :

• X.X.A.0/24 le range d’IP public du datacenter A
• X.X.B.0/24 le range d’IP public du datacenter B
• 10.0.A.0/8 le range d’IP privé du datacenter A
• 10.0.B.0/8 le range d’IP privé du datacenter B

Les zones privées communiquent entre elles.

Pages: 1 2 3 4 5 6