Рынок аппаратных систем балансировки нагрузок и отказоустойчивости для многих видов протоколов и служб включает в себя продукты таких фирм как Cisco, Radware, F5 и других… Но здесь о них речь не пойдет.
Хотелось бы собрать в одну страницу небольшой список популярных систем отказоустойчивости, балансировки нагрузок и кластеризации на основе проектов открытого кода, используемых в инфраструктуре крупных веб сайтов, коммерческих компаниях, провайдерах хостинга и не только. В таком “списке” трудно приравнивать один тип решения к другому — практически все нижеприведенные отличаются друг от друга назначением и свойствами, но всё-же все они могут быть отнесены к роду решений для поддержания высоко нагруженных сервисов с возможностями масштабирования “на лету” и успешно конкурирующими с промышленными продуктами.
Linux Virtual Server позволяет создать кластер из физических (или виртуальных) серверов, распределяющий нагрузку между машинами в зависимости от их состояния, приоритета и других параметров настройки. Поддерживаемые протоколы: TCP, UDP. LVS является по сути коммутатором протоколов 4го уровня. Компоненты проверки аппликативного состояния соединений на более высоком уровне протоколов (к примеру по cookies в HTTP) не доработаны.
Все процессы связи кластера с реальными серверами прозрачны для конечного пользователя — он (или она) увидит только внешний IP адрес кластера. Физические сервера могут находится как в одном сегменте сети с самим сервером LVS (т.н. Директором), так и быть удалены даже географически и связываться разными методами: туннелирование трафика внутри IP пакетов, прямая маршрутизация и NAT. В методе прямой маршрутизации, физические сервера возвращают пакеты напрямую к конечному пользователю дабы не загружать трафиком канал связи кластера и сам Директор сервер, маскируя при этом source адрес возвращенных пакетов под главный адрес кластера (с целью сохранения целостности соединения и TCP сессий). Сам сервер Директора может иметь резервных “рабов” (slave) на случай падения, один из которых заберет на себя все активные соединения. Сервера предоставляющие сам контент не обязательно должны работать на Линуксе, есть возможность работы с *BSD, Windows и Solaris. Разработки проекта LVS используются в других проектах кластеризации, к примеру демон keepalived, Linux-HA, Ultra Monkey, Piranha (Red Hat Cluster Suite).
Нужно отметить что в этом примере изображен метод прямой маршрутизации. «Фронт» сервера обращаются к Динамическим так-же через LVS, для балансировки.
Проект стабилен, довольно прост в установке и настройке, присутствует в большинстве репозиториев крупных сборок Линуксa и хорошо документирован. Код ядра проекта (IPVS) внесен в официальное ядро Линуса в версиях 2.4 и 2.6. Имеет место быть порт на FreeBSD, но сий слабо развит и поддерживает только методы туннелирования и прямой маршрутизации.
Из крупных игроков использующих LVS можно отметить: linux.com, Siemens (siemens.com), Wikimedia, Drupal (drupal.org), SourceForge (sourceforge.net), Zope (www.zope.org), Real Networks (www.real.com), Tiscali Group, ibiblio.org, University of Nottingham и многие другие.
HAProxy является прокси сервером аппликативного (7го) уровня для протоколов HTTP и TCP. Отличительная способность — умение проверять и встраивать в сессию “печеньку” для браузера пользователя, которая впоследствии будет использована для постоянства при направлении соединения на один из фронт или бэкэнд серверов с целью поддержания активных сессий с веб аппликациями. Умеет решать на какую группу серверов будет направлен пользователь в зависимости от любого из параметров HTTP запроса. Способен работать с WebSockets (в виде TCP соединений).
На Линуксе, может быть настроен как “прозрачный” прокси (передавая запросы на обслуживающие сервера оставляя source адреса пакетов полученных от пользователей без изменения на свой главный IP адрес как при стандартном или обратном проксировании). Проверка пакетов на 7ом уровне позволяет фильтровать несанкционированный трафик и протоколы. Многослойная архитектура, планировщик на уровне ядра, оптимизированные протоколы и алгоритмы балансировки позволяют достичь пропускных способностей в несколько терабайт трафика за день. Отказоустойчивость одного прокси сервера обеспечивается через использование демона keepalived проверяющего работоспособность самого прокси и синхронизируясь с резервным сервером (протокол VRRP), обеспечивая дублирование в случае падения первого. Так-же возможна параллельная работа обоих для балансировки, но в такой конфигурации требуется внешний балансер или разброс по roud-robin DNS.
Проект не столь популярен как LVS, но и не слишком от этого страдает. Гордятся стабильностью и безопасностью кода. Установка и настройка тривиальны, в репозиториях не присутствует но есть собранные, стандартные бинарники залинкованные на Glibc 2.2, и естественно сорсы. Официально работает на Линуксе 2.4/2.6, Solaris 8-10, FreeBSD, OpenBSD. Данные о использующих проект не афишируются, замечен у некоторых провайдеров аппликаций и сервисов в сети, так же укомплектован в продуктах: redWall Firewall, ALOHA Load Balancer, Loadbalancer.org.
Varnish недавно попал в ленты новостей IT как проект автор которого (Пол-Хеннинг Камп) объявил о том что “вы делаете это не правильно”. Он имел ввиду реализацию и продуктивность алгоритма btree, доказав свою гипотезу тем что оптимизировал производительность алгоритма бинарных деревьев B-heap в Varnish до десяти раз. Проект и до этого позиционировал себя как полностью модернизированный, построенный с нуля в 2006-ом году и эффективно использующий современные технологии операционных систем в общем, и Виртуальной Памяти в частности. Varnish классифицируется как “обратный” (reverse), кеширующий прокси и акселератор HTTP.
Из отличительных способностей можно отметить возможность настройки кеширования страниц по частям, к примеру собирая только динамические объекты с обслуживающих серверов. Присутствует встроенный механизм проверки работоспособности бэкендов с гибкой настройкой — замер потраченного на ответ времени, настраиваемый предел кол-ва неудавшихся проверок и т.д. Язык конфигурации — динамический, с возможностью писать встраиваемый код на С. Как пример, на сайте проекта дается код для использования GeoIP и еще один для отправления логов в Syslog. Так-же, можно вносить изменения в конфигурацию “на лету” — подключаясь к процессу сервера через контрольный канал. Встроенная возможность переписки и перенаправления URLов (rewrite). Сам сервис Varnish не имеет механизма отказоустойчивости или дублирования на случай падения, предположительно можно добиться этого в связке с другим решением балансировки. Масштабируемость возможна через установку за фронтальной машиной Varnish бэкендов с Varnish установленным в конфигурации ‘Director’ и серверами контента уже за ним.
Проект ярко освещает свою популярность и современный дизайн (“опуская” при этом Squid при любом удобном случае), но всё-же да, есть чем гордится — в одном из примеров две машины Varnish заменили 12 машин Squid’а. Установка стандартная для *NIX, присутствует в некоторых репозиториях и так-же имеет SourceForge страницу с бинарными пакетами под многие сборки. Правильная настройка, из-за подхода столь отличного от классического, достигается через долгие интимные отношения. Официально рекомендуется установка на современных версиях 64х битных Линуксов, FreeBSD или Solaris. Из крупных сайтов признавшихся в использовании: Slashdot, The Pirate Bay, Funny or Die, Wikia. Из неподтвержденных но замеченных: Twitter, Facebook, Photobucket, weather.com, answers.com, Hulu, break.com.
Pound это обратный прокси и балансировщик нагрузки для протоколов HTTP и HTTPS. Отличительные способности включают в себя возможность фронтальной обработки SSL и распределения на обслуживающие сервера в виде HTTP, дезинфекция HTTP и HTTPS на предмет неправильно сформированных запросов, балансировка по состоянию сессии и другим параметрам (URL, идентификации (Basic HTTP), кукам (cookies), HTTP headers). Полная поддержка WebDAV.
Pound имеет встроенный механизм балансировки и проверки работоспособности обслуживающих серверов. Разработчики отмечают что дизайн изначально был спланирован из принципа не вмешиваться в проходящий трафик, исходя из этого не используют методы встраивания “печенек” и т.п. в сессии, довольно таки на прямую намекая на противоположность методам HAProxy. Несмотря на это замечание, может встраивать в хедэры “X-Forwarded-for” для передачи на бэкенд сервера IP адрес пользователя с целью записи в логи и т.п. Изначально проект разрабатывался как фтонтэнд для нескольких серверов Zope (ZEO). Считается легковесным и безопасным так как практически не обращается к диску (кроме чтения сертификатов SSL во время загрузки), может бежать в chroot’е. Встроенных механизмов отказоустойчивости не имеет.
Проект скромен, манией величия не страдает. Установка и настройка не представляют больших сложностей. Существуют неофициальные пакеты под крупные сборки Линукса, на сайте распространяется только в виде сорсов. Официально тестирован на Линуксе, OpenBSD и Solaris. О использующих проект данных не много, но часто упоминается как решение для балансировки HTTPS в связке с другими решениями.
О nginx распространятся особенно не буду. Проект отечественный и широко известен общественности, но, полагающиеся почести отдать в контексте такого обзора обязан — как минимум упомянуть.
Еще о NGINX могу отметить что он используется на фронтальных машинах для обработки статических запросов и балансировки запросов к динамическим объектам в фирме где работает сам автор сих слов (подобно примеру на рис. №1 о LVS).
http://1wt.eu/articles/2006_lb/index.html
http://queue.acm.org/detail.cfm?id=1814327
http://www.apsis.ch/pound/
http://www.linuxvirtualserver.org/VS-DRouting.html
http://www.varnish-cache.org/trac/wiki
Хотелось бы собрать в одну страницу небольшой список популярных систем отказоустойчивости, балансировки нагрузок и кластеризации на основе проектов открытого кода, используемых в инфраструктуре крупных веб сайтов, коммерческих компаниях, провайдерах хостинга и не только. В таком “списке” трудно приравнивать один тип решения к другому — практически все нижеприведенные отличаются друг от друга назначением и свойствами, но всё-же все они могут быть отнесены к роду решений для поддержания высоко нагруженных сервисов с возможностями масштабирования “на лету” и успешно конкурирующими с промышленными продуктами.
LVS — Балансировщик нагрузки и кластеризация
Linux Virtual Server позволяет создать кластер из физических (или виртуальных) серверов, распределяющий нагрузку между машинами в зависимости от их состояния, приоритета и других параметров настройки. Поддерживаемые протоколы: TCP, UDP. LVS является по сути коммутатором протоколов 4го уровня. Компоненты проверки аппликативного состояния соединений на более высоком уровне протоколов (к примеру по cookies в HTTP) не доработаны.
Все процессы связи кластера с реальными серверами прозрачны для конечного пользователя — он (или она) увидит только внешний IP адрес кластера. Физические сервера могут находится как в одном сегменте сети с самим сервером LVS (т.н. Директором), так и быть удалены даже географически и связываться разными методами: туннелирование трафика внутри IP пакетов, прямая маршрутизация и NAT. В методе прямой маршрутизации, физические сервера возвращают пакеты напрямую к конечному пользователю дабы не загружать трафиком канал связи кластера и сам Директор сервер, маскируя при этом source адрес возвращенных пакетов под главный адрес кластера (с целью сохранения целостности соединения и TCP сессий). Сам сервер Директора может иметь резервных “рабов” (slave) на случай падения, один из которых заберет на себя все активные соединения. Сервера предоставляющие сам контент не обязательно должны работать на Линуксе, есть возможность работы с *BSD, Windows и Solaris. Разработки проекта LVS используются в других проектах кластеризации, к примеру демон keepalived, Linux-HA, Ultra Monkey, Piranha (Red Hat Cluster Suite).
Нужно отметить что в этом примере изображен метод прямой маршрутизации. «Фронт» сервера обращаются к Динамическим так-же через LVS, для балансировки.
Проект стабилен, довольно прост в установке и настройке, присутствует в большинстве репозиториев крупных сборок Линуксa и хорошо документирован. Код ядра проекта (IPVS) внесен в официальное ядро Линуса в версиях 2.4 и 2.6. Имеет место быть порт на FreeBSD, но сий слабо развит и поддерживает только методы туннелирования и прямой маршрутизации.
Из крупных игроков использующих LVS можно отметить: linux.com, Siemens (siemens.com), Wikimedia, Drupal (drupal.org), SourceForge (sourceforge.net), Zope (www.zope.org), Real Networks (www.real.com), Tiscali Group, ibiblio.org, University of Nottingham и многие другие.
HAProxy — Высокопроизводительный прокси и балансировка
HAProxy является прокси сервером аппликативного (7го) уровня для протоколов HTTP и TCP. Отличительная способность — умение проверять и встраивать в сессию “печеньку” для браузера пользователя, которая впоследствии будет использована для постоянства при направлении соединения на один из фронт или бэкэнд серверов с целью поддержания активных сессий с веб аппликациями. Умеет решать на какую группу серверов будет направлен пользователь в зависимости от любого из параметров HTTP запроса. Способен работать с WebSockets (в виде TCP соединений).
На Линуксе, может быть настроен как “прозрачный” прокси (передавая запросы на обслуживающие сервера оставляя source адреса пакетов полученных от пользователей без изменения на свой главный IP адрес как при стандартном или обратном проксировании). Проверка пакетов на 7ом уровне позволяет фильтровать несанкционированный трафик и протоколы. Многослойная архитектура, планировщик на уровне ядра, оптимизированные протоколы и алгоритмы балансировки позволяют достичь пропускных способностей в несколько терабайт трафика за день. Отказоустойчивость одного прокси сервера обеспечивается через использование демона keepalived проверяющего работоспособность самого прокси и синхронизируясь с резервным сервером (протокол VRRP), обеспечивая дублирование в случае падения первого. Так-же возможна параллельная работа обоих для балансировки, но в такой конфигурации требуется внешний балансер или разброс по roud-robin DNS.
Проект не столь популярен как LVS, но и не слишком от этого страдает. Гордятся стабильностью и безопасностью кода. Установка и настройка тривиальны, в репозиториях не присутствует но есть собранные, стандартные бинарники залинкованные на Glibc 2.2, и естественно сорсы. Официально работает на Линуксе 2.4/2.6, Solaris 8-10, FreeBSD, OpenBSD. Данные о использующих проект не афишируются, замечен у некоторых провайдеров аппликаций и сервисов в сети, так же укомплектован в продуктах: redWall Firewall, ALOHA Load Balancer, Loadbalancer.org.
Varnish — Kеширующий прокси и акселерация http
Varnish недавно попал в ленты новостей IT как проект автор которого (Пол-Хеннинг Камп) объявил о том что “вы делаете это не правильно”. Он имел ввиду реализацию и продуктивность алгоритма btree, доказав свою гипотезу тем что оптимизировал производительность алгоритма бинарных деревьев B-heap в Varnish до десяти раз. Проект и до этого позиционировал себя как полностью модернизированный, построенный с нуля в 2006-ом году и эффективно использующий современные технологии операционных систем в общем, и Виртуальной Памяти в частности. Varnish классифицируется как “обратный” (reverse), кеширующий прокси и акселератор HTTP.
Из отличительных способностей можно отметить возможность настройки кеширования страниц по частям, к примеру собирая только динамические объекты с обслуживающих серверов. Присутствует встроенный механизм проверки работоспособности бэкендов с гибкой настройкой — замер потраченного на ответ времени, настраиваемый предел кол-ва неудавшихся проверок и т.д. Язык конфигурации — динамический, с возможностью писать встраиваемый код на С. Как пример, на сайте проекта дается код для использования GeoIP и еще один для отправления логов в Syslog. Так-же, можно вносить изменения в конфигурацию “на лету” — подключаясь к процессу сервера через контрольный канал. Встроенная возможность переписки и перенаправления URLов (rewrite). Сам сервис Varnish не имеет механизма отказоустойчивости или дублирования на случай падения, предположительно можно добиться этого в связке с другим решением балансировки. Масштабируемость возможна через установку за фронтальной машиной Varnish бэкендов с Varnish установленным в конфигурации ‘Director’ и серверами контента уже за ним.
Проект ярко освещает свою популярность и современный дизайн (“опуская” при этом Squid при любом удобном случае), но всё-же да, есть чем гордится — в одном из примеров две машины Varnish заменили 12 машин Squid’а. Установка стандартная для *NIX, присутствует в некоторых репозиториях и так-же имеет SourceForge страницу с бинарными пакетами под многие сборки. Правильная настройка, из-за подхода столь отличного от классического, достигается через долгие интимные отношения. Официально рекомендуется установка на современных версиях 64х битных Линуксов, FreeBSD или Solaris. Из крупных сайтов признавшихся в использовании: Slashdot, The Pirate Bay, Funny or Die, Wikia. Из неподтвержденных но замеченных: Twitter, Facebook, Photobucket, weather.com, answers.com, Hulu, break.com.
Pound — Прокси и балансировка http и https
Pound это обратный прокси и балансировщик нагрузки для протоколов HTTP и HTTPS. Отличительные способности включают в себя возможность фронтальной обработки SSL и распределения на обслуживающие сервера в виде HTTP, дезинфекция HTTP и HTTPS на предмет неправильно сформированных запросов, балансировка по состоянию сессии и другим параметрам (URL, идентификации (Basic HTTP), кукам (cookies), HTTP headers). Полная поддержка WebDAV.
Pound имеет встроенный механизм балансировки и проверки работоспособности обслуживающих серверов. Разработчики отмечают что дизайн изначально был спланирован из принципа не вмешиваться в проходящий трафик, исходя из этого не используют методы встраивания “печенек” и т.п. в сессии, довольно таки на прямую намекая на противоположность методам HAProxy. Несмотря на это замечание, может встраивать в хедэры “X-Forwarded-for” для передачи на бэкенд сервера IP адрес пользователя с целью записи в логи и т.п. Изначально проект разрабатывался как фтонтэнд для нескольких серверов Zope (ZEO). Считается легковесным и безопасным так как практически не обращается к диску (кроме чтения сертификатов SSL во время загрузки), может бежать в chroot’е. Встроенных механизмов отказоустойчивости не имеет.
Проект скромен, манией величия не страдает. Установка и настройка не представляют больших сложностей. Существуют неофициальные пакеты под крупные сборки Линукса, на сайте распространяется только в виде сорсов. Официально тестирован на Линуксе, OpenBSD и Solaris. О использующих проект данных не много, но часто упоминается как решение для балансировки HTTPS в связке с другими решениями.
NGINX — Высокопроизводительный веб сервер и балансировка
О nginx распространятся особенно не буду. Проект отечественный и широко известен общественности, но, полагающиеся почести отдать в контексте такого обзора обязан — как минимум упомянуть.
Еще о NGINX могу отметить что он используется на фронтальных машинах для обработки статических запросов и балансировки запросов к динамическим объектам в фирме где работает сам автор сих слов (подобно примеру на рис. №1 о LVS).
http://1wt.eu/articles/2006_lb/index.html
http://queue.acm.org/detail.cfm?id=1814327
http://www.apsis.ch/pound/
http://www.linuxvirtualserver.org/VS-DRouting.html
http://www.varnish-cache.org/trac/wiki