Как я могу развернуть масштабируемый, надежный haproxy кластер на Amazon EC2?
Цель того флага состоит в том, чтобы смочь определить правила в различных файлах конфигурации, но все еще быть гарантированными, что тот с флагом LAST сделан в последний раз.
Хорошо, я никогда не создавал решение для выравнивания нагрузки AWS с трафиком на уровнях SmugMug сам, но просто размышлением о теории и сервисах AWS, несколько идей приходят на ум.
Исходный вопрос пропускает несколько вещей, которые имеют тенденцию влиять на дизайн выравнивания нагрузки:
- Липкие сессии или нет? Очень предпочтительно не использовать липкую сессию и просто позволить всем подсистемам балансировки нагрузки использование (LB) круговой (RR) или случайный выбор бэкенда. RR или случайные выборы бэкенда просты, масштабируемы, и обеспечивают распределение равномерной нагрузки при всех обстоятельствах.
- SSL или нет? Используется ли SSL или нет, и по которому проценту запросов, обычно оказывает влияние на дизайн выравнивания нагрузки. Часто предпочтительно завершить SSL как можно раньше, упростить обработку сертификата и держать загрузку ЦП SSL отдельно от серверов веб-приложения.
Я отвечаю с точки зрения того, как сохранить сам слой выравнивания нагрузки высоконадежным. При хранении серверов приложений HA просто сделан с проверками состояния, встроенными в подсистемы балансировки нагрузки L7.
Хорошо, несколько идей, которые должны работать:
1) "Путь AWS":
- Первый слой, в очень переднем, использует ELB в режиме L4 (TCP/IP).
- Второй слой, используйте экземпляры EC2 со своей предпочтительной подсистемой балансировки нагрузки L7 (nginx, HAProxy, Apache и т.д.).
Преимущества/идея: подсистемы балансировки нагрузки L7 могут быть довольно простым EC2 AMI's, все клонированные от того же AMI и использования той же конфигурации. Таким образом инструменты Amazon могут обработать все потребности HA: ELB контролирует подсистемы балансировки нагрузки L7. Если L7 LB умирает или становится безразличным, ELB & Cloudwatch вместе порождают новый экземпляр автоматически и приносят его в пул ELB.
2) "Циклический алгоритм DNS с контролирующим путем":
- Используйте основной циклический алгоритм DNS для вывода крупномодульного распределения нагрузки по нескольким IP-адресам. Позвольте нам просто сказать публикацию 3 IP-адресов для сайта.
- Каждый из этих 3 IP является Эластичным IP-адресом (EIA) AWS, связанным с экземпляром EC2, с подсистемой балансировки нагрузки L7 по Вашему выбору.
- Если EC2 L7, LB умирает, совместимый агент пользователя (браузер), должен просто использовать одного из другого дюйм/с вместо этого.
- Настройте внешний контрольный сервер. Контролируйте каждый из 3 EIPs. Если Вы становитесь безразличными, используйте инструменты командной строки AWS и некоторые сценарии для перемещения EIP в другой экземпляр EC2.
Преимущества/идея: Совместимые агенты пользователя должны автоматически переключиться на другой IP-адрес, если Вы становитесь безразличными. Таким образом, в случае отказа, только 1/3 Ваших пользователей должен повлияться, и большинство из них ничего не должно замечать, так как их UA тихо заменяет к другому IP. И Ваше внешнее контрольное поле заметит, что EIP безразличен, и исправьте ситуацию в течение нескольких минут.
3) DNS RR к парам серверов HA:
В основном это - собственное предложение Дона простого heartbeat между парой серверов, но упрощенный для нескольких IP-адресов.
- Используя DNS RR, опубликуйте много IP-адресов для сервиса. При следовании примеру выше, позвольте нам просто сказать публикацию 3 дюйм/с.
- Каждый из них движения IP к паре серверов EC2, таким образом, 6 экземпляров EC2 всего.
- Каждая из этих пар использует Heartbeat или другое решение HA вместе с инструментами AWS для хранения 1 IP-адреса живым в активной/пассивной конфигурации.
- Каждый экземпляр EC2 имеет Вашу предпочтительную установленную подсистему балансировки нагрузки L7.
Преимущества/идея: В полностью виртуализированной среде AW на самом деле не настолько легко рассуждать о сервисах L4 и режимах обработки отказа. Путем упрощения до одной пары идентичных серверов, поддерживающих всего 1 IP-адрес, становится более простым рассуждать об и тест.
Заключение: Снова, я на самом деле не попробовал ни одного из этого в производстве. Только от моего инстинктивного чувства, опция один с ELB в режиме L4 и самоуправляемыми экземплярами EC2, поскольку L7 LBs кажется наиболее выровненным с духом платформы AWS, и где Amazon, скорее всего, вложит капитал и расширится позже. Это, вероятно, было бы моим предпочтительным вариантом.
-
1, Таким образом, я люблю подход № 1, это - направление, которое я склонялся, но существуют все еще некоторые интересные глюки - не, наименьшее количество которого - то, что ELB не обрабатывает весь AZ, переставший работать очень хорошо (что-то мы имели, уже, происходят). Легкое, но yucky, 'решение' там состоит в том, чтобы иметь haproxies позади ELB, настроенного для пересечения AZS (возможно, с резервным кластером в другом AZ) поэтому, если по крайней мере один haproxy произошел в каждом AZ, мы должны быть в порядке. Но это только минимизирует, не устраняет проблему. Какие-либо идеи вокруг этой проблемы? – Don MacAskill 5 December 2010 в 18:56
-
2@Don MacAskill: Я знаю, что AWS имел несколько крупномасштабных сервисных времен простоя, но добивающийся большего успеха, чем надежность AZ на AWS трудна. Перемещение в операцию мультиAZ frontend могло легко быть первым шагом к операции мультиAZ всего стека, и это - целый чайник змей... – Jesper M 5 December 2010 в 20:25
-
3@Don MacAskill: Одна опция была бы геоосведомленным разрешением DNS как DynDNS Dynect-> ELB + L7 LBs в одном AZ с другим ELB+L7 на горячем резервировании в другом AZ (Помимо того, чтобы быть геознающим, Dynect также имеет некоторые проверки состояния.) DynDNS имеет большой послужной список в течение времени работы, но несмотря на это, добавляя, что геоосведомленный DNS является другим SPOF. Имеет ли Dynect + выравнивание нагрузки в 2 AZ лучшее долгосрочное время работы, чем всего один AZ AWS не ясен мне. Посмотрите это для обзора того, что я имею в виду без баз данных мультиAZ: dev.bizo.com/2010/05/improving-global-application.html – Jesper M 5 December 2010 в 20:29
-
4@Don MacAskill: Всего одна последняя вещь - имеет в виду, что единственный экземпляр ELB может охватить несколько AZ. Это не может охватить через регионы EC2. Но если просто использование ELB к LB L7 в двух AZ в том же регионе приемлемо, это было бы безусловно самым простым... Вы записали, что "ELB не обрабатывает весь AZ, переставший работать очень хорошо", возможно, Вы уже знаете больше, чем я. – Jesper M 5 December 2010 в 23:57
-
5Да, если ELB охватывает несколько AZS и имеет своего рода отказ, где это не может добраться ни до одного из узлов базы данных в AZ (они перегружаются, вниз, возвращая 503 с, безотносительно), конечные пользователи видят те ошибки - он не перенаправляет к другому AZ (AZ). Я надеюсь, что это планируется, но это уже укусило нас однажды. – Don MacAskill 6 December 2010 в 08:33
Если Вы не делаете липких сессий, или если Вы используете стиль кота/апача (добавьте идентификатор узла к sessionid, в противоположность хранению состояния в LB), то я использовал бы ELB перед группой haproxies. ELB встроили healthcheck, таким образом, у Вас может быть он, контролируют haproxies и берут любого вниз из пула. Партии меньше для установки, чем обработка отказа heartbeat.
До распространения изменений у меня нет большого ответа. Марионетка является великой для первоначальной конфигурации и реализующих изменений, но для добавления/удаления узлов Вы склонны хотеть более быстрый ответ, чем его 30-минутный интервал опроса.