Назад | Перейти на главную страницу

Сервер Varnish: как разместить между верхним балансировщиком нагрузки и веб-серверами под EC2?

Я все еще новичок, но теперь я использую AWS / EC2 Redhat Machines. У меня есть:

Что-то вроде:

    LB
    |
 -------
 |     |
Web   Web

Тогда теперь, если я собираюсь поставить 1x Varnish Впереди 2x Web Servers:

Пожалуйста, предложите, и будет ли это так:

    LB
    |
   [V]
 -------
 |     |
Web   Web

Это?
И снова мои вопросы:

Пожалуйста, подскажите мне правильное размещение и поделитесь логикой.
Спасибо тебе.

Как говорит ianjs, ELB все еще может играть роль в вашей настройке ... все зависит от ваших потребностей (автоматическое масштабирование, конечная точка SSL, избыточность и т. Д.). Узнайте, как другие сталкивались с подобными проблемами [1] [2]

Между тем, если вы хотите использовать Varnish в качестве кеша, вам необходимо разместить его между балансировщиками нагрузки, если они есть, и вашими бэкэндами (используя согласованное хеширование [3], если задействовано более одного экземпляра Varnish) , но архитектура может оказаться довольно сложной, если вы захотите масштабировать ее по горизонтали (есть хороший пример с HAProxy [4]).

Итак, если вы собираетесь использовать 1 инстанс Varnish и 2 бэкэнда (без автоматического масштабирования, ssl и никаких дополнительных функций Amazon), вы можете оставаться простым и избавиться от ELB:

  Varnish
     |
 ---------
 |       |
Web1   Web2

Но вам придется:

  • Выберите подходящего режиссера [5]
  • Обработка внутренних проверок работоспособности [6]

Так что вам решать, какую архитектуру лучше всего удовлетворить вашим потребностям.

[1] https://stackoverflow.com/questions/14167561/using-an-aws-elb-behind-varnish-is-it-possible

[2] http://cloudreach.blogspot.com.au/2013/01/varnish-and-autoscaling-love-story.html

[3] http://en.wikipedia.org/wiki/Consistent_hashing

[4] http://blog.exceliance.fr/2012/08/25/haproxy-varnish-and-the-single-hostname-website/

[5] https://www.varnish-cache.org/docs/3.0/reference/vcl.html#directors

[6] https://www.varnish-cache.org/docs/3.0/reference/vcl.html#backend-probes

Доступен ряд конфигураций. Каждая конфигурация имеет определенные преимущества и недостатки, которые необходимо оценить (например, производительность, обслуживание, простота настройки, масштабируемость и т. Д.).

Для балансировщика нагрузки вы можете использовать ELB от Amazon и / или собственное решение Nginx / HAProxy. Вы можете использовать один (или несколько) серверов Varnish, и они могут быть либо на их собственном компьютере, либо Varnish может быть установлен и запущен на том же сервере, что и ваш веб-уровень.

Лак на веб-серверах

Простая установка - это лакировать Установленные на веб-серверах.

           LB
           |
     ---------------
     |             |
Web&Varnish   Web&Varnish

Хотя у этого есть недостаток, заключающийся в том, что вы не можете масштабировать вашу сеть независимо от лака, его быстрее настроить и понять. Это также упрощает вашу архитектуру. Этот подход может вам очень помочь. Я полагаю, что в какой-то момент вы перерастете это, поскольку у него есть некоторые очень очевидные проблемы с масштабируемостью.

ELB по-прежнему может служить цели:

  1. Может быть настроен для автоматической замены сервера Varnish в случае его смерти путем настройки AutoScaling Group.
  2. Позволяет включать и отключать серверы, добавляя новый и удаляя старый. Это означает, что обслуживание клиентов не прерывается.
  3. Может позволить вам легко добавить более одного сервера лака, если ваша нагрузка когда-либо станет достаточно высокой, чтобы в этом нуждаться.
  4. Может выступать в качестве шлюза для вашего внутреннего сервера Varnish, находящегося в виртуальном частном облаке (VPC).

Все это, вероятно, можно настроить без ELB, но решающим аргументом для меня была обработка SSL в балансировщике нагрузки. Лак не будет обрабатывать SSL за вас так что вы можете заставить Load Balancer справиться с этим и передать http с вашим сервером Varnish.