Я работаю над большим развертыванием на AWS, которое имеет высокие требования к времени безотказной работы и переменную нагрузку в течение дня. Очевидно, это идеальный вариант использования ELB (Elastic Load Balancer) и автомасштабирования.
Однако мы также полагаемся на лак для кеширования вызовов API. Моим первоначальным побуждением было структурировать стек так, чтобы varnish использовал ELB в качестве бэкэнда, который, в свою очередь, попадал в appGroup.
Varnish -> ELB -> AppServers
Однако, по мнению а несколько источники это невозможно, поскольку ELB постоянно меняет IP-адрес своего DNS-имени хоста, что при запуске покрывает кеши, что означает, что изменения IP не будут приняты лаком.
Однако, читая вокруг, похоже, что люди делают это, поэтому мне интересно, какие обходные пути существуют? Может быть, скрипт для периодической перезагрузки vcl?
В случае, когда это действительно просто не лучшая идея, есть идеи других решений?
Это абсолютно возможно, но нужно сделать несколько шагов, чтобы все заработало! Когда нам нужна такая конфигурация, мы делаем это здесь:
Создайте VPC. Это нужно делать в VPC, потому что в них нужно делать подсети.
Создайте одну подсеть в каждой зоне доступности, в которой у вас будут экземпляры, зарегистрированные в ELB. Вы должны подсеть так, чтобы у вас было небольшое количество IP-адресов в каждой подсети, так как каждый IP-адрес станет накладным. (В настоящее время мы используем подсети a / 26)
Начните создавать серверную часть DNS Director в вашем VCL лака. Добавьте 3 подсети, которые вы создали выше. (https://www.varnish-cache.org/docs/3.0/reference/vcl.html#the-dns-director)
Установите параметр хоста в бэкэнде DNS Director равным имени хоста, который Varnish должен ожидать. (например, если ваша внешняя служба называется, скажем, front-end-service.subdomain.example.com, поместите front-end-service.example.com в качестве параметра Host в VCL.)
Установите суффикс в DNS Director на то, что вы можете разрешить. Продолжая приведенный выше пример, вы можете легко использовать «-varnish.example.com» в качестве суффикса. Когда запрос достигает varnish, varnish будет смотреть на HTTP-заголовок Host, и если имя совпадает с тем, что varnish имеет в VCL DNS Director Backend для настройки Host-заголовка, varnish добавит суффикс и выполнит DNS-поиск для имени хоста, которое результат объединения содержимого заголовка Host с суффиксом. Таким образом, в этом примере поиск DNS будет выполняться с помощью varnish для хоста с именем "front-end-service.subdomain.example.com-varnish.example.com"
Создайте серверную часть балансировщика нагрузки и прикрепите его к каждой созданной вами подсети.
Установите DNS-запись для результата конкатенации как CNAME для DNS-имени, которое amazon предоставляет вам для вашего балансировщика нагрузки.
Начните лак, при желании посмотрите на varnishstat, чтобы проверить количество бэкэндов.
Проверьте свою настройку, выполнив
curl -H "Хост: front-end-service.subdomain.example.com" http://varnish-server-hostname.example.com/whatever-path
Посмотрите, как поступает запрос с varnishlog, чтобы убедиться, что все работает.
Возможно, будет полезно отметить, что AWS рекомендует иметь подсеть с не менее 20 неиспользуемыми IP-адресами в ней, если вы собираетесь разместить в этой подсети балансировщик нагрузки. (Видеть http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html)
Мы сделали это для недавнего проекта, который нуждался в ELB для спецификации требований, но мы обеспокоены тем, как это масштабируется с точки зрения простоты управления, и изучаем подходы, основанные на обнаружении сервисов, наряду с чем-то вроде автоматического обновления VCL плюс автоматизированный VCL развернуть через что-то вроде Varnish Agent (https://github.com/varnish/vagent2)
Однако, если вы не против управления подсетями VPC, приведенное выше описание работает очень хорошо.
Ура!
Varnish действительно может работать как балансировщик нагрузки. Ты должен попытаться Varnish -> AppServers.
Просто определите каждый сервер приложений как бэкэнд в директоре в конфигурации Varnish.
Вы даже можете добавить зонды для проверки доступности серверной части, повторных попыток переключения на другой сервер, когда один из них выходит из строя во время процесса запроса и т. Д.
Где размещен ваш экземпляр Varnish? ASW тоже? Вы можете попробовать Varnish hash Director и разместить Varnish на тех же серверах, что и приложения. Каждый экземпляр будет обрабатывать запросы, которые он должен обрабатывать, и перенаправлять другие в правый бэкэнд. Каждый уникальный URL-адрес будет кэшироваться только на 1 (доступном) сервере, а ваша кеш-память будет умножена на количество экземпляров Varnish, в то время как промахи в кеше будут ограничены.
Частично цель ELB - пережить перебои в работе хоста. Даже с автоматическим масштабированием и CloudWatch, если необходимо заменить мертвый экземпляр, возможно, вы ожидаете нескольких минут простоя.
Я рекомендую:
[Front End ELB] -> [Varnish] -> [Back End ELB] -> [AppServers]
Я знаю, что вы хотите максимально эффективно использовать кеширование, но вы действительно должен распределять нагрузку по всем зонам доступности. Это означает наличие равного количества экземпляров в зонах A, B и C для региона (а), в котором находится ваш стек (то есть 3x Varnish). Это, конечно, будет стоить дороже, но даст вам возможность пережить все перебои в зоне доступности *. Снижение этой стоимости будет означать, что в какой-то момент вам, вероятно, потребуется время простоя. Это ваше решение, но, по крайней мере, вы можете принять его осознанное решение.
Имейте две группы безопасности, одну для Varnish и одну для AppServers. Настройте каждый так, чтобы только связанный ELB мог получить к нему доступ через соответствующий порт.
Для конфигурации Varnish установите для DNS-директора низкий TTL. Установите его равным (или половиной) TTL CNAME, которое Amazon предоставляет для Back End ELB. Этого должно быть достаточно, чтобы Varnish оставался в курсе последних событий.
* И если вы хотите добиться максимальной доступности. используйте Route53 с многорегиональным резервированием по нескольким направлениям.