AWS ELB в качестве бэкенда для Varnish Accelerator
Я работаю над широким развертыванием на AWS, которое требует повышенного времени работы и переменных нагрузок в течение дня. Очевидно, это идеальный вариант использования для ELB (Elastic Load Balancer) и автоматического масштабирования.
Однако мы также полагаемся на лак для кэширования вызовов API. Мой первоначальный инстинкт был структурировать стек так, чтобы лак использовал ELB в качестве бэкенда, который, в свою очередь, затрагивал группу приложений.
Varnish -> ELB -> AppServers
Однако, согласно нескольким источникам, это невозможно, поскольку ELB постоянно меняет IP-адрес своего DNS-имени хоста, который при запуске кеширует лак, то есть изменения в IP не будут приниматься лаком.
Однако, читая вокруг, похоже, что люди делают это, поэтому мне интересно, какие существуют обходные пути? Возможно, скрипт для периодической перезагрузки vcl?
В случае, когда это действительно просто не очень хорошая идея, есть идеи о других решениях?
3 ответа
Это абсолютно возможно, но нужно несколько шагов, чтобы все заработало! То, как мы делаем это здесь, когда нам нужна такая конфигурация:
Создать VPC. Вы должны сделать это в VPC, потому что вам нужно создать в них подсети.
Создайте одну подсеть в каждой зоне доступности, экземпляры которой будут зарегистрированы в ELB. Вы должны подсеть так, чтобы у вас было небольшое количество IP-адресов в каждой подсети, так как каждый IP-адрес станет служебным. (В настоящее время мы используем подсети, которые /26)
Начните создавать бэкэнд DNS Director в своем VCL-лаке. Добавьте в 3 подсети, которые вы создали выше. ( https://www.varnish-cache.org/docs/3.0/reference/vcl.html)
Задайте настройку хоста в бэкэнде DNS Director как имя хоста, которое должен увидеть лак. (Например, если ваша служба переднего плана называется, скажем, front-end-service.subdomain.example.com, поместите front-end-service.example.com в качестве параметра Host в VCL.)
Установите параметр суффикса в DNS Director на то, что вы можете разрешить. Продолжая приведенный выше пример, вы можете легко использовать "-varnish.example.com" в качестве суффикса. Когда запрос достигает лака, лак просматривает заголовок HTTP Host, и, если имя совпадает с тем, что имеет лак в настройке заголовка DNS-директора VCL для параметра Host, лак добавляет суффикс и выполняет поиск DNS для имени хоста, которое является результат объединения содержимого заголовка Host с суффиксом. Таким образом, в этом примере поиск DNS будет выполняться лаком для хоста с именем "front-end-service.subdomain.example.com-varnish.example.com"
Создайте свой бэкэнд-балансировщик нагрузки и прикрепите его к каждой подсети, которую вы создали.
Задайте запись DNS для результата объединения как CNAME для имени DNS, которое amazon предоставляет для вашего loadbalancer.
Запустите лак, при желании посмотрите на лакистат, чтобы проверить количество бэкэндов.
Проверьте свои настройки, выдав
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 ( https://github.com/varnish/vagent2)
Однако, если вы не против управления своими подсетями VPC, приведенное выше описание работает очень хорошо.
Ура!
Часть цели ELB состоит в том, чтобы пережить отказы хоста. Даже с автоматическим масштабированием и CloudWatch, если нужно заменить мертвый экземпляр, вы наблюдаете, возможно, несколько минут простоя.
Рекомендую:
[Front End ELB] -> [Varnish] -> [Back End ELB] -> [AppServers]
Я знаю, что вы хотите максимально использовать преимущества кэширования, но вам действительно следует распределить нагрузку по всем зонам доступности. Это означает наличие равного количества экземпляров в зоне A, B и C для региона (районов), в котором находится ваш стек (таким образом, 3x Varnish). Это, конечно, будет стоить дороже, но даст вам возможность выжить во всех отключениях AZ *. Сокращение этой стоимости будет означать, что в какой-то момент вам, вероятно, придется понизить время простоя. Это ваше решение, но, по крайней мере, вы можете принять это обоснованное решение.
Имейте две группы безопасности, одну для Varnish и одну для AppServers. Настройте каждый так, чтобы только связанный ELB мог получить к нему доступ через соответствующий порт.
Для конфигурации Varnish установите для DNS-директора низкий TTL. Установите его равным (или половине) TTL CNAME, который Amazon предоставляет для внутреннего ELB. Этого должно быть достаточно, чтобы Varnish оставался в курсе событий.
* И если вы хотите получить максимальную доступность. используйте Route53 с многозонной избыточностью по нескольким азам.
Лак действительно может работать как балансировщик нагрузки. Тебе стоит попробовать Varnish -> AppServers,
Просто определите каждый сервер приложений как бэкэнд в директории в конфигурации Varnish.
Вы даже можете добавить зонды для проверки доступности бэкэнда, попыток переключения на другой сервер при сбое во время процесса запроса и т. Д.
Где находится ваш экземпляр Varnish? ASW тоже? Вы можете попробовать хэш-директор Varnish и разместить Varnish на тех же серверах, что и приложения. Каждый экземпляр будет обрабатывать запросы, которые он должен обрабатывать, и перенаправлять других в правый бэкэнд. Каждый уникальный URL-адрес будет кэшироваться только на 1 (доступном) сервере, а ваша кэш-память будет умножена на количество экземпляров Varnish, а количество пропусков кэша будет ограничено.