Показаны сообщения с ярлыком доставка приложений. Показать все сообщения
Показаны сообщения с ярлыком доставка приложений. Показать все сообщения

четверг, 25 ноября 2010 г.

Критерии выбора контроллера доставки приложений

Контроллеры доставки приложений (ADC) набирают популярность по мере того как компании переходят от серверных к дата-центрам, от зооппарка инфраструктуры к консолидации и от разномастных серверов и приложений к виртуализации.
Вопрос, какие факторы нужно рассматривать выбирая балансировщик нагрузки или контроллер доставки приложений для центра обработки данных волнует многих дизайнеров и проектировщиков. На сегодня на этот счет имеется не много рекомендаций, поэтому публикую один из подходов который имеет право на жизнь.
 
Параметр
Комментарий
Функционал
Включение процессорно-затратных функций не должно влиять на пиковую производительность устройства
Производительность
Для ADC ключевые параметры – кол-во сессий которые он может устанавливать в секунду и максимальное поддерживаемое число установившихся соединений
Интеграция/совместимость
ADC должен соответствовать стандартам и прозрачно интегрироваться с любыми видами оборудования других производителей
Масштабируемость
Как добавление функционала влияет на производительность? На сколько легко увеличить пропускную способность системы за счет добавления модулей или доп. устройств?
Функциональная интеграция (консолидация)
Для дата-центров важно упростить архитектуру и количество вспомогательных устройств требуемых для обслуживания сети. Консолидация функционала позволяет уменьшить сложность и повысить управляемость ЦОД, что ведет к снижению TCO
Виртуализация
Поддержка виртуализации – необходимое условие при выборе ADC. Поддерживается ли совместная работа с гипервизорами? Есть ли функционал позволяющий автоматически перемещать виртуальные машины? Поддерживает ли ADC контексты?
Безопасность
Необходима совместимость со всеми средствами безопасности организации включая файрволы и IPS. Сам контроллер не должен привносить дополнительные уязвимости, а так же должен поддерживать базовые функции обеспечения безопасности в рамках функциональной консолидации
Доступность приложений
Для контроллера это означает поддержку отказоустойчивых конфигураций, а так же отслеживание и своевременное отключение недоступных ресурсов с переключением трафика пользователей на резервные источники.
Простота внедрения
Не только простота установки и настройки, но так же простота добавления новых приложений

Рассматривая возможных кандидатов которые удовлетворяют увловиям нельзя не отметить балансировщики нагрузки Brocade ADX, функционал, производительность и масштабируемость которых вызывают интерес и уважение на рынке.

суббота, 4 сентября 2010 г.

Базовая настройка балансировщиков нагрузки Brocade

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

Основная задача решаемая коммутаторами ServerIron – балансировка нагрузки на сервера (Server Load Balancing или SLB) базируется на сопоставлении между реальными (физическими) серверами установленными в дата-центре  и виртуальными серверами, которые видны пользователям подключающимся через сеть. Реальные сервера это сервера приложений предоставляющие свои сервисы пользователям. Виртуальные сервера характеризуются виртуальным IP-адресом (VIP) который задается на балансировщике для приема запросов от клиентов. Именно VIP указывают пользователи для доступа к тому или иному сервису и VIP должен быть указан в DNS в случае если доступ к сервисам осуществляется по доменному имени. Механизм SLB создает соответствие каждого VIP с несколькими реальными серверами. Схема подключения фермы серверов через коммутатор ServerIron представлена на следующем рисунке:
Предположим что компания разработала сайт www.alterego.com. В DNS адрес сайта привязан к IP адресу 207.95.55.1 который настроен как VIP на коммутаторе ServerIron. Каждый запрос на этот адрес обрабатывается одним из реальных серверов компании, установленных во внутренней сети, и имеющем адрес из диапазона публичных или частных адресов.
SLB работает по методу трансляции адресов (Network Adress Translation). Каждый пакет поступающий на VIP транслируется в пакет имеющий в качестве назначения реальный IP-адрес одного из серверов, который назначается в соответствии с выбранным механизмом балансировки.

Коммутаторы Brocade ServerIron ADX на уровне L2-L3 представляют собой производительный коммутатор третьего уровня и поддерживают весь необходимый функционал, настройка которого выходит за рамки данной статьи. Мы рассмотрим пошаговую конфигурацию коммутатора непосредственно для балансировки нагрузки.
На первом этапе необходимо определить реальные сервера которые будут принимать нагрузку. Затем указать виртуальный IP, и привязать VIP к указанным ранее физическим серверам.
Зададим реальные сервера указанные выше для обработки веб-трафика:
ServerIronADX(config) # server real Web1 207.95.55.21
ServerIronADX(config-rs-Web1) # port http
ServerIronADX(config-rs-Web1) # server real Web2 207.95.55.22
ServerIronADX(config-rs-Web2) # port http
ServerIronADX(config-rs-Web2) # server real Web3 207.95.55.23
ServerIronADX(config-rs-Web3) # port http
ServerIronADX(config-rs-Web3) # server real Web4 207.95.55.24
ServerIronADX(config-rs-Web4) # port http
Далее определяем виртуальный сервер (VIP)
ServerIronADX(config-rs-Web4) # server virtual-name-or-ip www.alterego.com  207.95.55.1
ServerIronADX(config-vs-www.alterego.com) # port http
И, наконец, привязываем реальные сервера к виртуальному серверу
ServerIronADX(config-vs-www.alterego.com) # bind http Web1 http
ServerIronADX(config-vs-www.alterego.com) # bind http Web2 http
ServerIronADX(config-vs-www.alterego.com) # bind http Web3 http
ServerIronADX(config-vs-www.alterego.com) # bind http Web4 http
Все. Наш балансировщик готов к работе. Трафик поступающий на 80 порт VIP по протоколу http будет перенаправляться на реальные сервера.
Далее нужно осуществить тонкие настройки коммутатора. Определить метод используемый для балансировки, выбрать параметры Helth Check для отслеживания состояния серверов, задать параметры защиты от DDos атак, задать группы серверов для настройки отказоустойчивой конфигурации и т.д. Подробные инструкции по настройке ADX на английском языке можно найти на сайте Brocade.


Предположим что компания разработала сайт www.alterego.com. В DNS адрес сайта привязан к IP адресу 207.95.55.1 который настроен как VIP на коммутаторе ServerIron. Каждый запрос на этот адрес обрабатывается одним из реальных серверов компании, установленных во внутренней сети, и имеющем адрес из диапазона публичных или частных адресов.
SLB работает по методу трансляции адресов (Network Adress Translation). Каждый пакет поступающий на VIP транслируется в пакет имеющий в качестве назначения реальный IP-адрес одного из серверов, который назначается в соответствии с выбранным механизмом балансировки.

Коммутаторы Brocade ServerIron ADX на уровне L2-L3 представляют собой производительный коммутатор третьего уровня и поддерживают весь необходимый функционал, настройка которого выходит за рамки данной статьи. Мы рассмотрим пошаговую конфигурацию коммутатора непосредственно для балансировки нагрузки.
На первом этапе необходимо определить реальные сервера которые будут принимать нагрузку. Затем указать виртуальный IP, и привязать VIP к указанным ранее физическим серверам.

Зададим реальные сервера указанные выше для обработки веб-трафика:
ServerIronADX(config) # server real Web1 207.95.55.21
ServerIronADX(config-rs-Web1) # port http
ServerIronADX(config-rs-Web1) # server real Web2 207.95.55.22
ServerIronADX(config-rs-Web2) # port http
ServerIronADX(config-rs-Web2) # server real Web3 207.95.55.23
ServerIronADX(config-rs-Web3) # port http
ServerIronADX(config-rs-Web3) # server real Web4 207.95.55.24
ServerIronADX(config-rs-Web4) # port http

Далее определяем виртуальный сервер (VIP)
ServerIronADX(config-rs-Web4) # server virtual-name-or-ip www.alterego.com  207.95.55.1
ServerIronADX(config-vs-www.alterego.com) # port http

И, наконец, привязываем реальные сервера к виртуальному серверу
ServerIronADX(config-vs-www.alterego.com) # bind http Web1 http
ServerIronADX(config-vs-www.alterego.com) # bind http Web2 http
ServerIronADX(config-vs-www.alterego.com) # bind http Web3 http
ServerIronADX(config-vs-www.alterego.com) # bind http Web4 http

Все. Наш балансировщик готов к работе. Трафик поступающий на 80 порт VIP по протоколу http будет перенаправляться на реальные сервера.

Далее нужно осуществить тонкие настройки коммутатора. Определить метод используемый для балансировки, выбрать параметры Helth Check для отслеживания состояния серверов, задать параметры защиты от DDos атак, задать группы серверов для настройки отказоустойчивой конфигурации и т.д. Подробные инструкции по настройке ADX на английском языке можно найти на сайте Brocade.

суббота, 26 июня 2010 г.

Brocade Application Resource Broker

Компания Brocade анонсировала новое приложение Application Resource Broker которое позволит оптимизировать работу дата-центров построенных с применением виртуализации (VMWare). При помощи связки балансировщиков нагрузки ServerIron ADX и Resource Broker появляется возможность оптимизировать работу датацентра подгружая виртуальные машины по мере роста нагрузки и выгружая их когда нагрузка падает.









Флешка про Application Resource Broker на сайте Brocade