|
Доставка приложений в корпоративном ЦОД и облачных средах. Часть 2. Основные принципы настройки ADC
Главная /
Архив номеров / 2016 / Выпуск №09 (62) / Доставка приложений в корпоративном ЦОД и облачных средах. Часть 2. Основные принципы настройки ADC
Рубрика:
ЦОД
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Леонид Шапиро, архитектор ИТ‑систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M.
Доставка приложений в корпоративном ЦОД и облачных средах
Часть 2. Основные принципы настройки ADC
В статье [1] мы рассмотрели целесообразность использования контроллеров доставки приложений. Причем надо отметить, что существующие сегодня решения нередко предлагают нам современный интегрированный подход
Мы говорим не просто о балансировщике нагрузки, работающем с четвертого по седьмой уровни модели OSI [2], но и об эффективном программно-аппаратном комплексе. Он позволяет, помимо стандартной функциональности, предлагать решения для целого ряда сопутствующих задач. Например, обеспечить защиту от атак на уязвимости веб-приложений, оптимизировать веб-трафик, снизить затраты ресурсов серверов приложений при работе с шифрованным трафиком, обеспечить балансировку внешних каналов связи для ЦОДов, защитить подключения клиентов.
Строго говоря, мы получаем практически универсальное устройство или программное решение, повышающее надежность, отказоустойчивость, масштабируемость и эффективность работы ЦОДов компании и снижающее в конечном счете затраты на поддержание инфраструктуры предприятия.
Потребность в балансировке и оптимизации нагрузки возникает с целым рядом известных служб. Например, использование решений на основе ADC может существенно улучшить работу и повысить надежность функционирования Microsoft Exchange, Skype for Business, SharePoint, Internet Information Services, Windows Terminal Services.
Структурно схема применения ADC выглядит достаточно просто (см. рис. 1). Запросы клиентов распределяются на разные серверы, которые их и будут обрабатывать. За счет этого обеспечиваются масштабируемость и высокая доступность.
Рисунок 1. Схема включения ADC в сетевой инфраструктуре
На первый взгляд выглядит неплохо, осталось понять, как это все работает, как настраивается и в конце концов как оценить затраты. Действительно ли то, что говорят нам производители, так уж целесообразно?
В этой статье сделаем обзор основных принципов конфигурирования ADC. В качестве примера будут приводиться конфигурационные настройки Radware Alteon [3], однако ADC других производителей настраиваются похожим образом. Вдальнейшем разберемся и с остальными вопросами.
Принципы настройки ADC
Разберем базовые принципы настройки балансировщика нагрузки без использования дополнительной функциональности ADC (см. рис. 2).
Рисунок 2. Основные этапы настройки балансировщика нагрузки
Нетрудно заметить, что у нас есть четыре основных этапа настройки, выполняемых последовательно: базовое развертывание, установка и настройка параметров канального уровня, настройка параметров сетевого уровня, и основная часть –настройка балансировки нагрузки.
Базовая установка
После монтажа оборудования, если мы говорим об аппаратном решении или развертывании виртуальной машины ADC, необходимо обеспечить возможность контроля и управления системой на низком уровне. Здесь может помочь консольное подключение к системе, например простое подключение кабелем к устройству.
Когда речь заходит о нескольких устройствах, то разумно использовать специализированный сервер управления, позволяющий подключаться и управлять сразу большим количеством устройств.
Современные консольные серверы обеспечивают доступ для управления и мониторинга устройствами, которые могут быть расположены на разных площадках, используя как специализированные консольные порты, так и стандартные сетевые (при поддержке такой возможности производителем). То есть, имея возможность такого подключения, мы можем управлять устройством даже при серьезных сбоях в его работе. С виртуальными машинами вопрос может быть решен и с помощью различных программных методов, например через консоль управления гипервизора.
Разумеется, необходимо обеспечить возможность настройки и управления ADC и на более высоком уровне. Для этого предоставляется определенный уровень доступа к системе и ее компонентам, организуется доступ с помощью интерфейсов управления (management access). Для этой цели, как правило, применяются специальные выделенные порты.
Современные ADC обычно поддерживают возможность тройного управления: с помощью коммандного интерпретатора (CLI) [4], веб-интерфейса и централизованной системы управления, позволяющей работать сразу со многими устройствами и/или виртуальными машинами. Здесь же решается вопрос предоставления соответствующего уровня доступа эксплуатирующему персоналу.
Обычно, помимо собственной службы каталога ADC, использование которой при инфраструктурах, состоящих из многих ADC, неэффективно, можно применять сторонние варианты. Для этого применяется интеграция с RADIUS [5] иTACACS [6].
После того как все предварительные настройки будут выполнены и доступ организован, можно переходить к настройкам канального уровня модели OSI.
Вариант предварительной настройки порта управления и начальных параметров ADC. Видим статическое назначение IP-конфигурации на порт управления, настройку синхронизации с внешним сервером времени, разрешение telnet и SSH-подключения и изменение параметров строки приглашения командного интерфейса.
/c/sys/mmgmt
dhcp disabled
addr 192.168.1.100
mask 255.255.255.0
broad 192.168.1.255
gw 192.168.1.254
ena
tftp mgmt
/c/sys/ntp
on
prisrv 91.226.136.142
secsrv 88.147.254.227
tzone +3:00
/* alteon_test
/c/sys
idle 60
hprompt ena
/c/sys/access
snmp r
tnet ena
/c/sys/access/sshd/sshv1 dis
/c/sys/access/sshd/on
/c/sys/ssnmp
name "LB_for_tests"
Канальный уровень
На этом шаге выполняются настройка VLAN и привязка портов устройств к соответствующим виртуальным сетям. Важно понимать, что физический порт может иметь привязку к нескольким VLAN. В этом случае возникает необходимость настройки тагирования портов.
Для повышения пропускной способности порты могут объединяться в транк- группы (trunk groups), тем самым создается виртуальный канал высокой производительности.
Для предотвращения появления «петель» на втором уровне исполь-зуется протокол STP (Spanning Tree Protocol), параметры работы с которым настраиваются на этом этапе.
/c/port 1
pvid 11
/c/port 2
pvid 12
/c/l2/vlan 1
dis
learn ena
def 0
/c/l2/vlan 2
dis
learn ena
def 0
/c/l2/vlan 11
ena
name "VLAN 11"
learn ena
def 1
/c/l2/vlan 12
ena
name "VLAN 12"
learn ena
def 2
/c/l2/stg 1/clear
/c/l2/stg 1/add 1 2 11 12
Сетевой уровень
Настройка сетевого уровня подразумевает создание сетевых интерфейсов для каждой сети, которую предполагается непосредственно подключить к ADC, назначение им IP-конфигурации и взаимодействие с соответствующими VLAN.
Важно иметь в виду, что в данном контексте сетевой интерфейс является логическим понятием, не имеющим отношения к физической составляющей, то есть к портам устройства, привязка осуществляется к VLAN, к которым, в свою очередь, привязываются порты устройства, что мы и видели в предыдущем разделе.
Вопросы настройки как статической, так и динамической маршрутизации также необходимо учесть на этом этапе. Здесь же решаются вопросы поддержки работы смешанных схем IPv4 и IPv6, если таковые присутствуют в рамках разворачиваемой инфраструктуры.
Здесь мы видим настройку двух сетевых интерфейсов, назначение IP-конфигурации и подключение к VLAN.
/c/l3/if 1
ena
ipver v4
addr 10.10.10.252
mask 255.255.255.0
broad 10.10.10.255
vlan 11
peer 10.10.10.242
descr "Interface for VLAN 11"
/c/l3/if 2
ena
ipver v4
addr 172.16.1.112
mask 255.255.255.0
broad 172.16.1.255
vlan 12
descr "Interface for VLAN 12"
Балансировка нагрузки
После выполнения первых трех этапов конфигурирования системы переходим непосредственно к настройке балансировки нагрузки. Ее основные цели – распределить трафик между несколькими серверами, повысить эффективность имеющихся ресурсов, уменьшить время реакции сервисов на запросы клиентов, избавиться от «узких мест» при предоставлении сервиса и в конечном счете снизить совокупную стоимость владения информационной системой.
Предстоит выполнить несколько задач. Во-первых, определить те серверы, трафик между которыми будет перераспределяться, добавить их адреса и настроить метрику выбора сервера. Эти серверы называют «Real Server», а их адреса –«real IP address или RIP». Данная информация дает возможность ADC понять, между какими серверами осуществляется балансировка.
Создается группа, в которую включаются эти серверы, и определяется схема выбора сервера в группе для перенаправления трафика. Подобный критерий выбора называется метрикой SLB.
Рисунок 3. Схема настройки балансировки
Существует множество вариантов. Наряду с простой технологией Round-robin, можно оценивать, скажем, уровень загруженности серверов в группе или количество имеющихся сессий и перенаправлять запрос серверу, который наилучшим образом подходит для его обслуживания. Есть возможность учитывать необходимость установки сессий клиентом со строго определенным сервером (persistency) и т.д. Также можно строить сложные варианты выбора, учитывающие целый комплекс параметров.
Во-вторых, контроллер доставки приложений может определить доступность сервера и работоспособ-ность интересующего нас сервиса на нем, прежде чем перенаправить на него трафик клиента. В случае если этот сервер недоступен илисервис неработоспособен, нужно перенаправить трафик на другой доступный в группе сервер.
Эта проверка называется проверкой «состояния здоровья» серверов или health check. Настраивается она на уровне группы и может содержать не только какие-то простые варианты, например выполнять ICMP-запрос на IP- адреса серверов, но и использовать более сложные задания, проверяя работоспособность конкретного сервиса или приложения с помощью сложных логических выражений.
В-третьих, потребуется указать виртуальный IP-адрес, который будет служить точкой входа для подключающихся к соответствующему сервису клиентов. Этот адрес называется адресом виртуального сервера или VIP. Клиент должен иметь возможность определить данный адрес исходя из стандартной процедуры разрешения имен, а значит, на сервере DNS должна присутствовать необходимая запись. Наконец, указывается сервис, для которого и настраивается балансировка.
Последний, четвертый, этап в предлагаемой схеме – непосредственное включение обработки запросов и балансировки.
/c/slb/real 1
ena
ipver v4
rip 172.16.1.11
name "RV1"
/c/slb/real 2
ena
ipver v4
rip 172.16.1.12
name "SRV2"
/c/slb/group web_server_group
ipver v4
metric roundrobin
health icmp
add 1
add 2
/c/slb/port "1"
client ena
server ena
proxy ena
/c/slb/port "2"
client ena
server ena
proxy ena
/c/slb/virt 1
ena
ipver v4
vip 10.10.10.200
/c/slb/virt 1/service 80 http
group web_server_group
rport 80
/c/slb/virt 1/service 80 http/pip
mode address
addr v4 172.16.1.199 255.255.255.255 persist disable
Описанные в статье принципы настройки контроллера доставки приложений (ADC) предлагают лишь базовую схему, которую необходимо реализовать в любом случае, и не учитывают такие аспекты, как, например, обеспечение отказоустойчивости и надежности самого балансировщика. В дальнейшем мы разберем детали реализации доставки приложений на практических примерах.
- Шапиро Л. Доставка приложений в корпоративном ЦОДе и облачных средах. Часть 1. Выбор ADC. // «БИТ», №3, 2016 г. – С. 30-34 (http://bit.samag.ru/archive/article/1632).
- Модель OSI – https://en.wikipedia.org/wiki/OSI_model.
- Radware Alteon – http://www.radware.com/Products/Alteon.
- Интерфейс командной строки – https://ru.wikipedia.org/wiki/Интерфейс_командной_строки.
- [5] Remote Authentication Dial In User Service (RADIUS) – https://ru.wikipedia.org/wiki/RADIUS, https://tools.ietf.org/html/rfc2865.
- TACACS – http://www.cisco.com/russian_win/warp/public/3/ru/solutions/sec/mer_tech_ident-tacacs.html, https://tools.ietf.org/html/rfc1492.
В начало⇑
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Комментарии отсутствуют
Комментарии могут отставлять только зарегистрированные пользователи
|
_cover.jpg)
_cover.jpg)
_cover.jpg)
_cover.jpg)
