Балансировка нагрузки на сервера с помощью Cisco ACE. Часть 2: Общие принципы балансировки нагрузки на сервера.

В прошлой части мы получили информацию о том, что такое система балансировки на сервера (ACE), для чего нужна эта система и как происходит сопряжение данного модуля с Catalyst 6500. В это части мы узнаем общие принципы балансировки и её типы,так же рассмотрим пример конфигурации балансировки серверов.

Общая схема балансировки трафика приведена на рис.1.

Рисунок 1 — Общая схема балансировки нагрузки на сервера

Сервера, на которые нужно балансировать нагрузку, объединяются в серверную ферму (severfarm). Проверка доступности серверов в серверной ферме осуществляется с помощью — probe. Таким образом, ACE «узнает» в рабочем ли состоянии необходимый сервис на некотором сервере в ферме.

Клиентские запросы идут на виртуальный IP адрес кластера (VIP), грубо говоря, на адрес серверной фермы. Этот адрес прописывается на ACE. Как только запросы достигают VIP, ACE «смотрит» на политики балансировки (class-map, policy-map), которые привязаны к данному VIP и балансирует трафик на сервера согласно этим политикам.

По умолчанию, ACE балансирует сессии по методу round-robin. Другими словами, система балансировки распределяет сессии между серверами в зависимости от их веса (weight). Чем больше значение — «weight» сервера, тем большее количество сессий направляются к серверу. Например, если у первого сервера вес — 8, а у другого — 1, то на каждую одну сессию второму серверу будет приходиться восемь сессий первому. По умолчанию, вес серверов в серверной ферме одинаковый и равен — 8.

Теперь рассмотрим пример (рисунок 2). Нам нужно настроить балансировку нагрузки на web сервера. Выбор серверов в серверной ферме будет происходить по методу — round-robin (по умолчанию). Проверка доступности серверов с помощью протокола tcp по 80 порту. У серверов в качестве маршрута по умолчанию будет выступать ACE.

Рисунок 2 — Пример балансировки серверов

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

Для начала, создадим «resource-class», с именем — «SERVERS-RES-CLASS», который будет ограничивать ресурс будущего «балансировочного» контекста. Когда мы применим данный «resource-class» на контекст, это будет означать, что он (контекст) будет использовать 10 процентов ресурсов физического ACE. Советую прочитать о ресурсах здесь, т.к. останавливаться на этом не буду.

ACE/Admin# conf term
ACE/Admin(config)# resource-class SERVERS-RES-CLASS
ACE/Admin(config-resource)# limit-resource all minimum 10.00 maximum unlimited
ACE/Admin(config-resource)#ex
ACE/Admin(config)#

Далее, создадим контекст, с именем — «SERVERS-CONTEXT», назначим ему необходимые вланы и «resource-class». В нашем случае, нужно назначить только один влан (VLAN 10), который используется для серверов. Согласно нашей топологии, сервера и VIP будут находиться в одном влане. Ниже будет представлена схема примера балансировки:

ACE/Admin# conf term
ACE/Admin(config)# context SERVERS-CONTEXT
ACE/Admin(config-context)# allocate-interface vlan 10
ACE/Admin(config-context)#member SERVERS-RES-CLASS
ACE/Admin(config-context)#exit
ACE/Admin(config)#

Теперь, необходимо зайти на данный контекст и уже настраивать его. Замечу, что таким образом (конфигурация ниже) и происходит перемещение между контекстами:

ACE/Admin# change to SERVERS-CONTEXT
ACE/SERVERS-CONTEXT#

По умолчанию, ACE не принимает на свой интерфейс трафик, чтобы он начал это делать, необходимо написать лист контроля доступа (access list). Создадим «простенький» access list с именем «CLIENT-SERVER-LIST». Данный лист пропускает весь трафик который будет приходить на интерфейс. Позже, когда мы создадим на ACE интерфейс, мы «привяжем» данный лист контроля доступа на него.

ACE/SERVERS-CONTEXT#
ACE/SERVERS-CONTEXT# conf t
ACE/SERVERS-CONTEXT(config)# access-list CLIENT-SERVER-LIST line 2 extended permit ip any any
ACE/SERVERS-CONTEXT(config)#

Далее, опишем способ проверки доступности серверов — probe, с именем «SERVERS-PROBE». Т.к. У нас web сервера, то нужно быть уверенными, что именно данный сервис доступен на серверах. Поэтому, сделаем tcp пробу, которая будет отправлять tcp запросы на порт 80 с определенным интервалом времени. Более подробно о пробах тут.

ACE/SERVERS-CONTEXT(config)#probe tcp SERVERS-PROBE
ACE/SERVERS-CONTEXT(config-probe-tcp)#port 80
ACE/SERVERS-CONTEXT(config-probe-tcp)#exit
ACE/SERVERS-CONTEXT(config)#

Из нашей топологии (рисунок 2) видно, что необходимо определить два сервера и объединить их в серверную ферму. Так же, нужно присвоить серверной ферме проверку доступности серверов (SERVERS-PROBE).

ACE/SERVERS-CONTEXT(config)#rserver SERVER-001
ACE/SERVERS-CONTEXT(config-rserver-host)#ip address 10.0.8.101
ACE/SERVERS-CONTEXT(config-rserver-host)#inservice
ACE/SERVERS-CONTEXT(config-rserver-host)#exit
ACE/SERVERS-CONTEXT(config)#rserver SERVER-002
ACE/SERVERS-CONTEXT(config-rserver-host)#ip address 10.0.8.102
ACE/SERVERS-CONTEXT(config-rserver-host)#inservice
ACE/SERVERS-CONTEXT(config-rserver-host)#exit
ACE/SERVERS-CONTEXT(config)#
ACE/SERVERS-CONTEXT(config)#serverfarm SERVERS-SRF
ACE/SERVERS-CONTEXT(config-sfarm-host)#probe SERVERS-PROBE
ACE/SERVERS-CONTEXT(config-sfarm-host)#rserver SERVER-001
ACE/SERVERS-CONTEXT(config-sfarm-host-rs)#inservice
ACE/SERVERS-CONTEXT(config-sfarm-host-rs)#exit
ACE/SERVERS-CONTEXT(config-sfarm-host)#rserver SERVER-002
ACE/SERVERS-CONTEXT(config-sfarm-host-rs)#inservice
ACE/SERVERS-CONTEXT(config-sfarm-host-rs)#exit
ACE/SERVERS-CONTEXT(config-sfarm-host)#

Команда «inservice» переводит в рабочий режим. То есть, данная команда является аналогом — «no shutdown». Подробней о rservers и serverfarm можно прочитать тут и тут.

Далее, нужно создать виртуальный интерфейс VIP, на который будут обращаться клиенты (подробней тут). Это делается с помощью карты классификации (class-map) 3, 4 уровней (сетевая модель OSI).

Во всех классовых картах есть строчка «match-any», которая означает, что должен выполняться хотя бы один критерий описанный в данной карте или строчка «match-all», который говорит о том, что должны выполняться все критерии.

Настраиваем VIP таким образом, чтобы клиенты обращались только по web (80) порту:

ACE/SERVERS-CONTEXT(config)#class-map match-any SERVERS-VIP
ACE/SERVERS-CONTEXT(config-class)#2 match virtual-address 10.0.8.10 tcp eq www
ACE/SERVERS-CONTEXT(config-class)#exit
ACE/SERVERS-CONTEXT(config)#

Далее нужно создать политику балансировки (policy-map) 7 уровня. В нашем случае создадим общую (generic) политику балансировки с именем — «SERVERS-POL». Типов политик существует несколько (generic, http, ftp, rdp, radius, sip). Смысл заключается в том, что для трафика определенного протокола можно использовать соответствующую политику. Остальной тип трафика может быть описан политикой generic. Более детально можно прочитать здесь.

Когда мы создали политику, необходимо к ней «привязать» карту классификации трафика (class-map) 7 уровня. Её можно описать или использовать карту по умолчанию (class-default).

Главным образом нужно понять, что если необходимо, то картой можно классифицировать трафик по определенному протоколу (http, radius, rtsp, sip), есть возможность классифицировать, так называемый, общий трафик (generic). Например, в «class-map generic» можно классифицировать трафик по определенными IP адресами источника. Если есть желание, то подробно можно почитать тут об общих картах классификации и тут о картах классификации по протоколам.

Как отмечено выше, есть класс — class-default. Дело в том, что мы можем не создавать определенную class-map не классифицируя таким образом клиентские запросы. Тогда весь трафик который будет направлен к VIP будет соответствовать class-default.

После того, как мы вписали классификацию трафика в политику, нужно определить серверную ферму на которую будет отправлены запросы.

ACE/SERVERS-CONTEXT(config)# policy-map type loadbalance generic first-match SERVERS-POL
ACE/SERVERS-CONTEXT(config-pmap-lb)# class class-default
ACE/SERVERS-CONTEXT(config-pmap-lb-c)#serverfarm SERVERS-SRF
ACE/SERVERS-CONTEXT(config-pmap-lb-c)#exit
ACE/SERVERS-CONTEXT(config-pmap-lb)# exit
ACE/SERVERS-CONTEXT(config)#

Далее, необходимо создать политику (policy-map) 3, 4 уровня, с именем SERVERS-POL-MULTI. Она содержит в себе действия, в том числе политики балансировки 7 уровня, которые связаны с виртуальным интерфейсом VIP. Более детально о данных политиках можно прочитать тут.

ACE/SERVERS-CONTEXT(config)#policy-map multi-match SERVERS-POL-MULTI
ACE/SERVERS-CONTEXT(config-pmap)#class SERVERS-VIP
ACE/SERVERS-CONTEXT(config-pmap-c)#loadbalance policy SERVERS-POL
ACE/SERVERS-CONTEXT(config-pmap-c)#loadbalance vip inservice
ACE/SERVERS-CONTEXT(config-pmap-c)#exit
ACE/SERVERS-CONTEXT(config-pmap)#exit
ACE/SERVERS-CONTEXT(config)#

Настройкой — «loadbalance policy SERVERS-POL» мы привязали данную политику с нашим VIP. Строчка — «loadbalance vip inservice» означает, что мы перевели VIP в рабочее состояние.

Теперь, нужно создать интерфейс (VLAN 10), провести все необходимые настройки и назначить на него данную политику (SERVERS-POL-MULTI).

ACE/SERVERS-CONTEXT(config)# interface vlan 10
ACE/SERVERS-CONTEXT(config-if)#ip address 10.0.8.2 255.255.248.0
ACE/SERVERS-CONTEXT(config-if)#access-group input CLIENT-SERVER-LIST
ACE/SERVERS-CONTEXT(config-if)#service-policy input SERVERS-POL-MULTI
ACE/SERVERS-CONTEXT(config-if)#exit
ACE/SERVERS-CONTEXT(config)#

Строчкой — «access-group input CLIENT-SERVER-LIST» мы назначаем на интерфейс список контроля доступа, а настройкой — «service-policy input SERVERS-POL-MULTI» связываем нашу политику 3 и 4 уровня (SERVERS-POL-MULTI) с данным интерфейсом.

Теперь нужно не забыть о маршруте по умолчанию:

ACE/SERVERS-CONTEXT(config)#ip route 0.0.0.0 0.0.0.0 10.0.8.1

Для удобства, приведу конфигурацию выполненной настройки. Считаю, что так будет наглядней.

access-list CLIENT-SERVER-LIST line extended permit ip any any

probe tcp SERVERS-PROBE
port 80
interval 15
faildetect 2
passdetect interval 15
passdetect count 2
open 1

rserver host SERVER-001
ip address 10.0.8.101
inservice
rserver host SERVER-002
ip address 10.0.8.102
inservice

serverfarm host SERVERS-SRF
probe SERVERS-PROBE
rserver SERVER-001
inservice
rserver SERVER-002
inservice

class-map match-any SERVERS-VIP
2 match virtual-address 10.0.8.10 tcp eq www

policy-map type loadbalance generic first-match SERVERS-POL
class class-default
serverfarm SERVERS-SRF

policy-map multi-match SERVERS-POL-MULTI
class SERVERS-VIP
loadbalance vip inservice
loadbalance policy SERVERS-POL

interface vlan 10
ip address 10.0.8.2 255.255.248.0
access-group input c CLIENT-SERVER-LIST
service-policy input SERVERS-POL-MULTI
no shutdown

ip route 0.0.0.0 0.0.0.0 10.0.8.1

После рассмотренного примера мы уже должны понимать некоторую суть настройки балансировки нагрузки, поэтому можно перейти к рассмотрению типов балансировки и примеров конфигурации.

Существуют такие режимы балансировки:

1. Режим моста (Bridged mode);
2. Режим роутера (Routed mode): Inline и On-a-stick (One-Arm-Mode);
3. Асимметричный режим (Asymmetric server normalization).

Пример Bridged mode приведен на рисунке 3. Смысл данного режима заключается в том, что ACE является мостом между двумя вланами, которые находятся в одной IP подсети. Т.е. по сути, есть влан со стороны клиентов и влан со стороны серверов. При использовании этого метода создается виртуальный интерфейс (BVI), который соединяет эти вланы в одну группу — bridge-groupe (необходимо вручную занести виртуальные интерфейсы в одну группу).

Трафик, в данном режиме, проходит через ACE как от клиент-сервер, так и от сервер-клиент.

Рассмотрим как идет запрос клиента и ответ от сервера на данном примере. Клиент обращается на виртуальный адрес (VIP 10.0.8.10), далее ACE отправляет этот запрос на один из серверов в серверной ферме (например, 10.0.8.101), при этом, изменяя IP адрес назначения на адрес данного сервера. Ответ от сервера идет на настроенный маршрут по умолчанию (10.0.8.1), но проходит через нашу систему балансировки, которая изменяет IP адрес источника (10.0.8.101) на адрес виртуального интерфейса (VIP 10.0.8.10).

Данный режим логично использовать в той ситуации, когда сеть уже существует и нет возможности перенастраивать сервера.

Рисунок 3 — ACE в режиме Bridge mode

Приведу пример конфигурации Bridge mode:

access-list CLIENT-SERVER-LIST extended permit ip any any

rserver host SERVER-001
ip address 10.0.8.101
inservice
rserver host SERVER-002
ip address 10.0.8.102
inservice

serverfarm SERVERS-SRF
rserver SERVER-001
inservice
rserver SERVER-002
inservice

class-map SERVERS-VIP
match virtual-address 10.0.8.10 any

policy-map type loadbalance first-match SERVERS-POL
class class-default
serverfarm SERVERS-SRF

policy-map multi-match SERVERS-POL-MULTI
class SERVERS-VIP
loadbalance policy SERVERS-POL
loadbalance vip inservice

interface bvi 1
ip address 10.0.8.2 255.255.248.0
no shutdown

interface vlan 10
bridge-group 1
mac-sticky enable
access-group input CLIENT-SERVER-LIST
service-policy input SERVERS-POL-MULTI
no shutdown

interface vlan 30
bridge-group 1
no shutdown

ip route 0.0.0.0 0.0.0.0 10.0.8.1

Примечание: строчка «mac-sticky enable» (привязывает MAC адрес источника) используется для того, чтобы ACE обеспечил обратный трафик (ответ от серверов к клиентам) через интерфейс на который пришел запрос (от клиента к серверу).

На рисунке 4 приведен пример Routed-mode (Inline). В этом режиме ACE является маршрутом по умолчанию для серверов. Здесь, так же как и в предыдущем режиме, есть влан со стороны клиентов (VLAN 40) и со стороны серверов (VLAN 10), но в отличии от Bridged mode эти два влана находятся в разных IP сетях. В остальном, все схоже: трафик проходит от клиента серверу и обратно через ACE; при попадании запроса от клиента на систему балансировки, ACE изменят IP адрес назначения (VIP 192.168.0.10) на IP адрес одного из серверов (например, 10.0.8.101), в обратном направлении изменяется адрес источника (сервера) на виртуальный интерфейс (VIP).

Рисунке 4 — ACE в режиме Routed mode (Inline)

Приведу пример конфигурации Routed mode (Inline):

access-list CLIENT-SERVER-LIST extended permit ip any any

rserver host SERVERS-001
  ip address 10.0.8.101
  inservice
rserver host SERVERS-002
  ip address 10.0.8.102
  inservice

serverfarm SERVERS-SRF
  rserver SERVERS-001
    inservice
  rserver SERVERS-002
    inservice

class-map match-any SERVERS-VIP
  match virtual-address 192.168.0.10 any

policy-map type loadbalance first-match SERVERS-POL
  class class-default
   serverfarm SERVERS-SRF

policy-map multi-match SERVERS-POL-MULTI
  class SERVERS-VIP
    loadbalance policy SERVERS-POL
   loadbalance vip inservice

interface vlan 10
  ip address 10.0.8.1 255.255.248.0
  no shutdown

interface vlan 40
  ip address 192.168.0.2 255.255.255.0
  access-group input CLIENT-SERVER-LIST
  service-policy input SERVERS-POL-MULTI
  no shutdown

ip route 0.0.0.0 0.0.0.0 192.168.0.1

Режим — One-a-stick (One-Arm-Mode) приведен на рисунке 5. В данном режиме ACE использует один влан (VLAN 10) как для получения запросов от клиентов, так и отправки ответов серверов. Но здесь, для того, чтобы ответ от серверов шел на ACE, а не на прямую к клиентам, через «дефолтный» маршрут (192.168.0.1) на балансировщике настраивается «source NAT». Т.е. Клиентский запрос попадает на виртуальный адрес (VIP 10.0.8.10) балансировщика, который, с помощью настроенного «source NAT», изменяет IP адрес источника (клиента) на один из адресов настроенного NAT пула из своего влана (VLAN 10), ну и как писалось ранее, изменяет адрес назначения (VIP) на IP адрес одного из серверов (например, 192.168.0.1) в серверной ферме. Таким образом, сервер отвечает не на IP адрес клиента, а на некий транслированный из пула IP адрес балансировщика. Далее, ACE изменяет адрес источника (сервера) на (VIP), а адрес назначения (адрес из заданного пула NAT) на адрес клиента.

Рисунок 5 — ACE в режиме Routed mode (One-Arm)

Приведу пример конфигурации Routed mode (One-Arm):

access-list CLIENT-SERVER-LIST extended permit ip any any

rserver host SERVERS-001
  ip address 192.168.0.101
  inservice
rserver host SERVERS-002
  ip address 192.168.0.102
  inservice

serverfarm SERVERS-SRF
  rserver SERVERS-001
    inservice
  rserver SERVERS-002
    inservice

class-map match-any SERVERS-VIP
  match virtual-address 10.0.8.10 any

policy-map type loadbalance first-match SERVERS-POL
  class class-default
   serverfarm SERVERS-SRF

policy-map multi-match SERVERS-POL-MULTI
  class SERVERS-VIP
    loadbalance policy SERVERS-POL
    nat dynamic 5 vlan 10
   loadbalance vip inservice

interface vlan 10
  ip address 10.0.8.2 255.255.248.0
  access-group input CLIENT-SERVER-LIST
  service-policy input SERVERS-POL-MULTI
  nat-pool 5 172.16.5.3 172.16.5.3 netmask 255.255.255.255 pat
  no shutdown

ip route 0.0.0.0 0.0.0.0 10.0.8.1

На рисунке 6 приведен пример асимметричного режима (Asymmetric server normalization). Этот метод отличается от предыдущих методов тем, что клиентские запросы идут через ACE, а вот сервер отвечает на прямую к клиентам, минуя балансировщик. Трафик от клиента попадает на виртуальный адрес балансировщика (VIP 192.168.0.10), ACE изменяет MAC адрес назначения, на MAC адрес сервера и отсылает этот запрос на один из серверов (например, 10.0.8.101) в зависимости от правил балансировки. Сервер отвечает, непосредственно, к клиенту, естественно, через маршрут по умолчанию (10.0.8.1).

Рисунок 6 — ACE в режиме Asymmetric server normalization

Приведу пример конфигурации Asymmetric server normalization:

access-list CLIENT-SERVER-LIST extended permit ip any any

rserver host SERVERS-001
ip address 10.0.8.101
inservice
rserver SERVERS-002
ip address 10.0.8.102
inservice

serverfarm host SERVERS-SRF
transparent
rserver real1
inservice
rserver real2
inservice

class-map match-any SERVERS-VIP
match virtual-address 192.168.0.10 any

parameter-map type connection TIMEOUT
set timeout inactivity 120

policy-map type loadbalance first-match SERVERS-POL
class class-default
serverfarm SERVERS-SRF

policy-map multi-match SERVERS-POL-MULTI
class SERVERS-VIP
loadbalance vip inservice
loadbalance policy SERVERS-POL
loadbalance vip icmp-reply active
connection advanced-options TIMEOUT

interface vlan 10
ip address 10.0.8.2 255.255.248.0
no normalization
access-group input CLIENT-SERVER-LIST
service-policy input SERVERS-POL-MULTI
no shutdown

ip route 0.0.0.0 0.0.0.0 10.0.8.1

Примечание: так как ACE в асинхронном режиме не получает ответ от сервера клиенту (сервер посылает ответ непосредственно клиенту), то балансировщик не знает когда закончится сессия, таким образом можно настроить «parameter-map» в котором указывается в секундах время после которого можно оборвать сессию (в нашем случае — 120 секунд); строчкой — «connection advanced-options TIMEOUT» мы задействуем «parameter-map»; команда — «transparent» означает ACE не преобразует IP адрес назначения (VIP) в адрес одного из серверов, когда на ACE приходит запрос от клиента.

В этой части мы рассмотрели общий пример настройки балансировки на Cisco ACE. По ходу примера были приведены ссылки о более детальной информации так как, балансировка на сервера — это достаточно, обширная тема. Целью данной статьи было ознакомить читателя с общими принципами балансировки, так сказать, помочь освоить суть.