AWS ELB en tant que backend pour Varnish Accelerator

C'est absolument possible, mais il faut quelques étapes pour que cela fonctionne correctement! La manière dont nous le faisons ici lorsque nous avons besoin de ce type de configuration est la suivante:

• Créez un VPC. Vous devez le faire dans un VPC car vous devez y créer des sous-réseaux.

• Créez un sous-réseau dans chaque zone de disponibilité où vous aurez des instances enregistrées avec l'ELB. Vous devez sous-diviser de manière à avoir un petit nombre d'adresses IP dans chaque sous-réseau, car chaque adresse IP deviendra un surcoût. (Nous utilisons actuellement des sous-réseaux de /26)

• Commencez à créer un backend de DNS Director dans votre VCL varnish. Ajoutez les 3 sous-réseaux que vous avez créés ci-dessus. (https://www.varnish-cache.org/docs/3.0/reference/vcl.html#the-dns-director)

• Définissez le paramètre host dans le backend de DNS Director comme le nom d'hôte que varnish devrait s'attendre à voir. (par exemple, si votre service frontal s'appelle, disons, front-end-service.subdomain.example.com, mettez front-end-service.example.com comme paramètre Host dans le VCL.)

• Définissez le paramètre de suffixe dans le DNS Director sur quelque chose que vous pouvez résoudre. Poursuivant l'exemple ci-dessus, vous pourriez facilement utiliser '-varnish.example.com' pour votre suffixe. Lorsqu'une demande atteint varnish, varnish examinera l'en-tête HTTP Host, et si le nom correspond à ce que varnish a dans le backend de DNS Director du VCL pour le paramètre d'en-tête Host, varnish ajoutera le suffixe et effectuera une recherche DNS sur le nom d'hôte qui est le résultat de la concaténation du contenu de l'en-tête Host avec le suffixe. Ainsi, dans cet exemple, une recherche DNS sera effectuée par varnish pour l'hôte nommé "front-end-service.subdomain.example.com-varnish.example.com"

• Créez votre backend de répartiteur de charge et attachez-le à chaque sous-réseau que vous avez créé.

• Définissez un enregistrement DNS pour que le résultat de la concaténation soit un CNAME pour le nom DNS que Amazon fournit pour votre répartiteur de charge.

• Démarrez varnish, regardez éventuellement varnishstat pour vérifier le nombre de backends.

• Testez votre configuration en émettant une

  curl -H "Host: front-end-service.subdomain.example.com" http://varnish-server-hostname.example.com/whatever-path

• Regardez la demande arriver avec varnishlog pour vérifier que tout fonctionne.

Il peut être utile de noter qu'AWS recommande que vous ayez un sous-réseau avec au moins 20 adresses IP inutilisées si vous allez placer un répartiteur de charge dans ce sous-réseau. (Voir http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html)

Nous avons fait cela pour un projet récent qui nécessitait des ELBs pour une spécification requise, mais nous nous préoccupons de la façon dont cela évolue en termes de facilité de gestion et examinons des approches basées sur la découverte de service ainsi que sur une mise à jour automatique VCL, plus un déploiement automatique VCL via quelque chose comme Varnish Agent (https://github.com/varnish/vagent2)

Cependant, si vous ne vous souciez pas de gérer vos sous-réseaux VPC, la description ci-dessus fonctionne très bien.

Santé!

Une partie de l'objectif de l'ELB est de survivre aux pannes d'hôtes. Même avec le dimensionnement automatique et CloudWatch, si une instance morte doit être remplacée, vous pouvez vous retrouver avec plusieurs minutes d'arrêt.

Je recommande:

[ELB Frontal] -> [Varnish] -> [ELB d'arrière-plan] -> [Serveurs d'application]

Je sais que vous voulez tirer le meilleur parti possible du caching, mais vous devriez vraiment répartir la charge sur toutes les zones de disponibilité. Cela signifie avoir un nombre égal d'instances dans les zones A, B et C pour la ou les régions où se trouve votre pile (donc 3x Varnish). Cela coûtera bien sûr plus cher, mais cela vous donnera la possibilité de survivre à des pannes d'une zone entière*. Réduire ce coût signifiera qu'à un moment donné, vous devrez probablement subir un arrêt. C'est à vous de décider, mais au moins vous pourrez prendre une décision éclairée.

Avoir deux groupes de sécurité, un pour Varnish et un pour les Serveurs d'application. Configurez chacun pour que seul l'ELB associé puisse y accéder sur le port approprié.

Pour la configuration de Varnish, définissez le directeur DNS avec un faible TTL. Réglez-le pour qu'il soit égal (ou moitié) du TTL du CNAME fourni par Amazon pour l'ELB d'arrière-plan. Cela devrait suffire pour que Varnish reste à jour.

* Et si vous voulez aller vers une disponibilité ultime, utilisez Route53 avec une redondance multi-région, multi-az.

Varnish peut en fait fonctionner comme un répartiteur de charge. Vous devriez essayer Varnish -> AppServers.

Il suffit de définir chaque serveur d'application comme une backend dans un directeur de la configuration de Varnish.

Vous pouvez même ajouter des sondes pour vérifier la disponibilité des backends, des réessais pour passer à un autre serveur en cas d'échec lors d'un processus de requête, etc.

Où est hébergée votre instance de Varnish ? AWS également ? Vous pourriez essayer le directeur de hachage de Varnish et héberger Varnish sur les mêmes serveurs que les applications. Chaque instance traitera les requêtes qui lui sont attribuées et redirigera les autres vers le bon backend. Chaque URL unique ne sera mise en cache que sur 1 serveur (disponible) et votre mémoire cache sera multipliée par le nombre d'instances de Varnish, tandis que les ratés de cache seront limités.