52
VPC (virtual port-channel) - это технология, которая позволяет
пользоваться технологией port-channel, но при этом использовать 2
коммутатора Cisco Nexus со стороны сети. Для устройства, подключенного по
такой технологии конфигурация выглядит так же, как при использовании
обычного port-channel.
Рисунок 3.2: Физическая топология
53
На коммутаторах будет использовано несколько Vlan. Vlan5 для
подключения серверов к балансировщикам, vlan6 для объединения устройств
внутри датацентра (роутеры и балансировщики), Vlan7 для соединения
датацентров №1, vlan8 для соединения датацентров №2. Vlan9 для внешнего
стыка в DC1 и vlan10 для внешнего стыка в DC2. Конфигурация Коммутаторов
описана в приложении, в примере Б.
Рисунки 3.3, 3.4, 3.5 изображают логическую топологию с учётом
подсетей, vlan и маршрутизации. Таблица 3 описывает ip-адреса устройств в
топологии. Конфигурация маршрутизации для всех устройств описана в
приложении, в примере В.
Рисунок 3.3: ip-адреса устройств в топологии
54
Рисунок 3.4: Логическая топология с учётом VLAN
Рисунок 3.5: Схема маршрутизации
55
Server 1
10.1.5.11/24
Server 2
10.1.5.12/24
Server 3
10.2.5.13/24
Server 4
10.2.5.14/24
DC1-SLB
10.1.5.1/24
10.1.6.3/24
1.1.1.3
DC2-SLB
10.2.5.1/24
10.2.6.3/24
2.2.2.3
DC1-R1
10.1.9.1/24
10.1.6.1/24
1.1.1.1
10.0.7.1/24
DC2-R1
10.2.10.1/24
10.2.6.1/24
2.2.2.1
10.0.7.2/24
DC1-R2
10.0.8.1/24
10.1.6.2/24
1.1.1.2
DC2-R2
10.0.8.2/24
10.2.6.2/24
2.2.2.2
Таблица 3.1: Адресация тестовой схемы
3.3 Конфигурация сервера
На сервера установлена операционная система Ubuntu 16.04. Для
возможности использования port-channel с LACP нам понадобится пакет
ifenslave. Если данный пакет отсутствует, то его нужно установить с помощью
команды "apt-get install ifenslave"(сеть уже должна быть настроена). Далее нам
понадобится настроить port-channel. Для этого нам необходимо добавить
конфигурацию в файл /etc/network/interfaces. Пример такой конфигурации
указан в приложении, в примере Г.
Далее, устанавливаем пакет apache2 с помощью команды "apt-get install
apache2". Данный пакет является веб-сервером и будет использован нами в
целях тестирования балансировщиков. После установки и запуска apache2
проверяем, что сервис “слушает” на порту 80 с помощью команды "netstat -
tulpen".
56
root@ubuntu:/home/terskikh# netstat -tulpen
Активные соединения с интернетом (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program
name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 11803 983/sshd
tcp6 0 0 :::80 :::* LISTEN 0 236873 5847/apache2
tcp6 0 0 :::22 :::* LISTEN 0 11805 983/sshd
udp 0 0 0.0.0.0:33176 0.0.0.0:* 0 12292 1103/snmpd
udp 0 0 0.0.0.0:43574 0.0.0.0:* 0 9984 737/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 11165 737/dhclient
udp 0 0 127.0.0.1:161 0.0.0.0:* 0 12294 1103/snmpd
udp6 0 0 :::60818 :::* 0 9985 737/dhclient
Как показано в примере, сервис слушается. Дополнительно проверяем с
помощью команды "telnet localhost 80".
root@ubuntu:/home/terskikh# telnet 127.0.0.1 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Как мы видим по строке "Connected to 127.0.0.1", соединение
открывается.
Так как данный хост будет использован для балансировки нагрузки, то
полезно бы было отделить трафик, приходящий от балансировщика и весь
остальной трафик (Например, менеджмент). Пример конфигурации с
использованием двух адресов (менеджмент и адрес для балансировки) описан
в приложении в примере Г. На этом конфигурация сервера завершена.
3.4 Конфигурация балансировщиков
Для балансировщиков нам потребуется несколько пакетов.
Устанавливаем их с помощью команды "apt-get install vlan ifenslave keepalived
quagga". Также, необходимо выполнить команду "modprobe dummy" и
команду "echo dummy >> /etc/modules". Меняем конфигурацию сети с
помощью изменений в файле /etc/network/interfaces. Сама конфигурация
описана в приложении, в примере Е.
57
Включаем демоны quagga с помощью изменения строчки в файле
/etc/quagga/daemons следующим образом:
zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
Перезапускаем quagga:
service quagga restart
Проверяем запущены ли демоны:
root@ubuntu:/home/terskikh# ps aux | grep quagga
quagga 7011 0.0 0.2 3660 2244 ? Ss 04:01 0:00 /usr/lib/quagga/zebra -
-daemon -A 127.0.0.1
quagga 7015 0.0 0.0 3988 548 ? Ss 04:01 0:00 /usr/lib/quagga/ospfd -
-daemon -A 127.0.0.1
root 7020 0.0 0.1 2956 1676 ? Ss 04:01 0:00 /usr/lib/quagga/watchquagga
--daemon zebra ospfd
root 7025 0.0 0.2 4720 2116 pts/0 S+ 04:01 0:00 grep --color=auto
quagga
Создаём файлы zebra.conf и ospfd.conf в директории /etc/quagga/:
root@ubuntu:/home/terskikh# touch /etc/quagga/zebra.conf
root@ubuntu:/home/terskikh# touch /etc/quagga/ospfd.conf
Копируем файл vtysh.conf для простоты управления:
root@ubuntu:/home/terskikh#cp
/usr/share/doc/quagga/examples/vtysh.conf.sample /etc/quagga/vtysh.conf
Меняем владельца и права для файлов:
root@ubuntu:/home/terskikh# chown quagga:quaggavty /etc/quagga/*.conf
58
root@ubuntu:/home/terskikh# chmod 640 /etc/quagga/*.conf
перезапускаем quagga:
service quagga restart
Переходим к конфигурации Keepalived. После установки Keepalived в
папке /etc/keepalived/ появляется файл keepalived.conf. Команды необходимые
для настройки нашей схемы описаны далее:
vrrp_sync_group "ИМЯ" - необходимо, если мы используем несколько
балансировщиков в hot-standby и несколько vrrp групп.
notify_master "путь" - в случае, если нода является vrrp мастером
исполняется скрипт.
notify_backup "путь" - в случае, если нода является vrrp backup
исполняется скрипт.
notify_fault "путь" - в случае, если происходит ошибка в определении
VRRP статуса.
vrrp_instance "ИМЯ" - создаёт процесс vrrp для определённого
интерфейса. Внутри vrrp_instance настраиваются следующие
параметры:
State - "Master или backup". Резервный или основной балансировщик.
interface "название интерфейса" - задаёт интерфейс где будет запущен
vrrp.
virtual_router_id - задаёт идентификатор балансировщика в vrrp.
virtual_ipaddress - задаёт адрес и интерфейс для которого этот адрес
будет назначен на мастер ноду.
priority - задаёт Master приоритет балансировщика.
advert_int - задаёт интервал сообщений vrrp в секундах.
nopreempt - отключает функцию "preemption", которая позволяет
мгновенно реагировать на изменение значения priority.
Далее идут настройки балансировки.
virtual_server "VIP" - начало конфигурации балансировки для
конкретного VIP.
delay_loop - задаёт значение в секундах между проверками.
lb_algo rr|wrr|lc|wlc|sh|dh - задаёт алгоритм балансировки.
rr - round robin
wrr - round-robin, но с заданием веса
lc - наименьшее кол-во соединений
wlc - то же самое, но только с использованием весов
sh - хеш отправителя
59
dh - хеш получателя
protocol TCP|UDP - задаёт протокол, который будет использован при
балансировке.
lb_kind NAT|DR|TUN - задаёт каким образом будет происходить
балансировка. Destination NAT, Direct server return, или с помощью
туннелирования.
alpha - задаёт настройку, при которой, в случае, когда процесс keepalived
запускается все сервера считаются неработающими до того момента
пока не пройдут проверки.
omega - задаёт настройку, при которой, в случае, когда процесс
keepalived административно или из-за ошибки останавливается,
исполняет эвент quorum_down для выбранного VIP.
persistance_timeout - задаёт таймаут привязки конкретного
пользователя к конкретному real серверу.
quorum - задаёт weight при достижении которого будет произведено
действие quorum_up. В случае, если общее значение weight всех
серверов в пуле меньше значения quorum выполняется действие
quorum_down.
quorum_up "действие" - выполняется при достижении weight значения
quorum.
quorum_down "действие" - выполняется, в случае, если значение weight
меньше значения quorum.
real_server "ip" "порт" - задаёт адрес и порт сервера на который будет
происходить балансировка.
TCP_CHECK|HTTP_GET|MISC_CHECK - задаёт тип проверки для
сервера.
connect_timeout - задаёт интервал между проверками.
В данной конфигурации, логика должна быть настроена таким образом,
чтобы в случае, если проверки проходят корректно, ip-адрес VIP назначался
dummy интерфейсу балансировщика. Далее, с помощью команды “redistribute
connected subnets route-map VIP_IPV4” в quagga необходимо перераспределить
маршруты, чтобы балансировщик начал анонсировать данный адрес в OSPF.
Конфигурацию, которая будет использована в работе можно найти в
приложении, в примере Е, также в примере В находится конфигурация Quagga.
После настройки проверяем, что балансировка работает с помощью
команды “ipvsadm –L –n”.
root@DC1-SLB:/home# ipvsadm -L -n
60
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 5.0.0.1:80 rr
-> 10.1.5.11:80 Masq 1 0 0
-> 10.1.5.12:80 Masq 1 0 0
TCP 5.0.1.1:80 rr
-> 10.1.5.11:80 Masq 1 0 0
-> 10.1.5.12:80 Masq 1 0 0
Также проверяем, что адреса появились на интерфейсе dummy0, и что
они анонсируются в OSPF.
root@DC1-SLB:/home# ipvsadm -L –n
### Часть конфигурации упущена для упрощения.
dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UNKNOWN group default
link/ether 76:f9:db:09:5c:74 brd ff:ff:ff:ff:ff:ff
inet 5.0.0.1/32 scope global dummy0
valid_lft forever preferred_lft forever
inet 5.0.1.1/32 scope global dummy0
valid_lft forever preferred_lft forever
root@DC1-SLB:/home# vtysh
DC1-SLB#
DC1-SLB# show ip route 5.0.0.1
Routing entry for 109.235.165.160/32
Known via "connected", distance 0, metric 0, best
* directly connected, dummy1
DC1-R2# show ip route 5.0.0.1
Routing entry for 5.0.0.1/32
Known via "ospf", distance 110, metric 11, best
61
Last update 22h ago
* 10.1.6.3, via vlan6
3.5 Конфигурация маршрутизации
Конфигурация маршрутизации на DC1-R2 и DC2-R2 достаточно
примитивна. Вся конфигурация заключается в простом включении OSPF area
0 на всех интерфейсах маршрутизатора. Конфигурация же DC1-R1 и DC2-R1
отличается тем, что используется BGP. В конфигурации, от внешних
операторов принимается “full view”, внутрь дата-центров, с каждого из
маршрутизаторов, имеющих внешние стыки, в OSPF анонсируется “маршрут
по умолчанию”. Конфигурация eBGP полностью зависит от внешней
маршрутизации и необходимости балансировки трафика.
3.6 Описание механизма работы территориально
распределенных дата-центров
Основная идея данной схемы заключается в простоте балансировки
внешнего трафика и высокой отказоустойчивости. Изначально были выбраны
2 сети: 5.0.0.0/24 и 5.0.1.0/24. Каждая из этих сетей будет считаться
“домашней” для одного дата-центра и “удалённой” для другого. Пусть подсеть
5.0.0.0/24 считается домашней для DC1, а 5.0.1.0/24 считается домашней для
DC2. В главе 3.4 описана настройка балансировщика, в которой мы
производим балансировку с адресов 5.0.0.1 и 5.0.1.1 на одну и ту же пару
серверов (Server 1 и Server 2). В DC2 с тех же адресов производится
балансировка на сервера Server 3 и Server 4. Веб-ресурс example.com в DNS
имеет 2 A-записи: 5.0.0.1 и 5.0.1.1. Теперь наша задача сделать так, чтобы
трафик приходящий на 5.0.0.1 всегда попадал в DC1, и только в том случае,
когда DC1 недоступен, трафик попадал в DC2. Аналогичная ситуация для DC2
и адреса 5.0.1.1. Один из методов для достижения этой цели – это приём,
который называется “AS_PATH Prepending”. Идея его заключается в том,
чтобы искусственно увеличить длину AS_PATH для “удалённого” префикса в
каждом дата-центре, при обмене маршрутами с ASN10 и ASN20.
Для настройки данной функции нам понадобится создать два prefix-list
с описанными в них подсетями, а также route-map с функцией “as-path
prepending”. Для DC1-R1 конфигурация будет выглядеть следующим образом:
ip prefix-list Local_Prefix seq 5 permit 5.0.0.0/24
ip prefix-list Remote_Prefix seq 5 permit 5.0.1.0/24