что такое кластер маршрутизаторов
Отказоустойчивый кластер из MikroTik’ов
Предистория
Сегодня я расскажу историю о том, как быть когда нужен стабильный интернет в режиме 24/7, руки и оборудование позволяют, а твой провайдер и его ближайшие соседи — имбецилы.
Дело было в далёком 2017 году в замечательный городе «С», который отличается несколькими достопримечательностями:
— Свежий воздух;
— Мягкий климат;
— Бесхребетный people (без обобщений).
Русскоязычный онлайн-курс по MikroTik от нашего коллеги Дмитрия Скромнова. Здесь можно изучить MikroTik и RouterOS самостоятельно по курсу «Настройка оборудования MikroTik». Курс основан на официальной программе MTCNA, но содержит больше информации. Это 162 видеоурока и большая практическая задача, разбитая на 45 лабораторных работ. Время на изучение неограниченно – все материалы передаются бессрочно и их можно пересматривать сколько нужно. Первые 25 уроков можно посмотреть бесплатно, оставив заявку на странице курса.
C первыми двумя пунктами всё замечтательно, но вот последний, без преувеличения и обобщения являет собой корень зла сей географической точки. Это тебе и пообещал — проставил, и сервис ниже плинтуса, и нахамить клиенту — ачивмент. Одним словом — печаль! Естественно, не обошло стороной сие горе и сферу телекоммуникаций. Здесь тебе и дропы в полный рост, и купленный абонетом «белый» IP пилят в тихую на 100-500 хомячков, и медные воздушки между домами #over100метров, короче всё как полагается!
Спустя пару лет мытарств с оператора на оператора, я пришел к неутешительному выводу, что судьбинушка помяла их всех без разбора. Выход был один — прекратить попытки сбора сливок на говне и заняться делом. К тому времени, в нагрузку к бэдам с провайдерами на меня свалился шквал лагов со стороны моего домашнего серванта на какинтоше. Так как на нём помимо файлопомоек, плюха (Plex) и контроллера домена крутился ещё и DHCP с DNS, любой отвал серванта приводил к понятным последствиям. Дело пахло керосином и пора уже было что то решать, ибо роль сапожника без сапог уже изрядно утомила. Благо первый опыт написания скриптов для MikroTik не прошёл бесследно, да и к этому времени уже много чего было написано для данной платформы. На тот момент я оброс вторым таким же маршрутизатором и дело оставалось за малым — начать действовать.
Задача
Стала необходимость обеспечения отказоустойчивости домосетки как извне так и изнутри. Что предстояло сделать:
Условия
1. VRRP кластер
Суть работы VRRP кластера достаточно проста. На двух или более маршрутизаторах создаются одинаковые VRRP интерфейсы, имеющие одинаковые MAC и IP адреса. Отличаются эти интерфейсы только лишь приоритетом, у кого выше — тот главный. В момент когда основной интерфейс активен, второстепенные не активны. К примеру маршрутизатор №1 имеет IP 10.0.0.2, а маршрутизатор №2 имеет IP 10.0.0.3, при этом IP VRRP интерфейса на обоих маршрутизаторах 10.0.0.1. Таким образом, для клиентского устройства маршрутизатором по факту является то усройство, на котором активен VRRP интерфейс. В своём случае я создал 5 VRRP интерфейсов, для каждой из сетей.
VRRP интерфейсы на маршрутизаторе №1 
VRRP интерфейсы на маршрутизаторе №2
Это собственно и всё что касается конфигурации VRRP. Теперь зверушки начали общаться друг с другом, что говорит об успехе мероприятия.
VRRP анонс
Вот так выглядит пакет анонса:
Теперь нужно обеспечить «переезд» VRRP интерфейса (и не только) в случае отключения интернет соединения, чем как раз и занимается мой скрипт.
2. Обеспечение переезда сервисов маршрутизатора (PPTP/L2TP) при сбое
Помимо очевидного, на маршрутизаторе дополнительно подняты PPTP/L2TP соединения. Соответственно их тоже нужно мигрировать, ибо держать поднятыми все PPTP/L2TP на двух маршрутизаторах одновременно на мой взгляд не спортивно да и не всегда получается. Теперь разберём сам скрипт по частям:
— Для начала объявляем переменные.
beep frequency=1760 length=10ms; :local scriptName «Failover»; # Задаем имя скрипта :if ([len [/system script job find where script=$scriptName]]>1) do= < # Проверяем на наличее уже запущенного # скрипта. Если скрипт уже запущен, выходим, если нет, работаем. log error "$scriptName: Single instance"; beep frequency=440 length=1000ms; >else=< delay 60s; # При старте вместе с системой лучше подождать, иначе возможны грабли, проверено. :local globalIPArray <"8.8.8.8";"77.88.8.8";"193.58.251.251";"114.114.115.115">; # Определяем адреса # которые скрипт пингует для проверки интернет соединения. Кол-во адресов может быть любое. В примере указано 4 # публичных DNS сервера (Google, Yandex, SkyDNS, 114dns). :local localIPArray <"10.0.0.4";"10.0.1.4";"10.0.2.4";"172.16.0.4";"192.168.0.4">; # Определяем адреса # которые скрипт пингует для проверки локального соединения. Кол-во адресов может быть любое. :local restoreDelays <600;7200;21600;43200;86400>; # Определяем тайм-ауты восстановления аплинка в # секундах. Кол-во и значения могут быть любые. :local filePath «disk1/var/log/full_log.0.txt»; # Указываем файл высылаемый на почту при сбое. :local email «mail@example.com»; # Куда спамить письмами. :local displayOnError «bond1.0»; # Что отображаем на дисплее при сбое. :local displayOnRestore «uplink0»; # Что отображаем на дисплее в нормальном режиме. :local uplink «uplink0″; # Указываем интерфейс аплинка. :local pingCount 5; # Кол-во пингов на один IP. :local conA 0; :local conB 0; :local conD 0; :local conC 0; :local once 0; :local pingResA 0; :local pingResB 0; :local mailSubject ([/system identity get name].»::».$scriptName); # Тема отправляемого E-Mail. # Вводим глобальные переменные для отображения текущего статуса в environment. :global FailoverState 0; # Отображает текущий статус скрипта, всего их 5, от 0 до 4. :global UplinkIPCurrentScan «waiting. «; # Отображает IP в интернет который скрипт пингует в # данный момент. :global LocalIPCurrentScan «waiting. «; # Отображает локальный IP который скрипт пингует в # данный момент. :global RestoreDelay 0; # Номер следующего тайм-аута восстановления аплинка. :global RestoreDelayTime «0 s»; # Длительность следующего тайм-аута. :global RestoreDelayTimeRemaining «0 s»; # Отображает оставшеся время до восстановления аплинка # без учёта длительности основного цикла. :global UplinkDrops 0; # Количество потерянных пакетов на аплинке. :global UplinkDisabled «false»; # Статус аплинк интерфейса. :global UplinkFailoverTimes 0; # Кол-во падений аплинка. :global UplinkFailoverLastTime «-«; # Дата и время последнего падения аплинка. :global UplinkRestoreTimes 0; # Кол-во восстановлений аплинка. :global UplinkRestoreLastTime «-«; # Дата и время последнего восстановления аплинка. :global LocalDrops 0; # Количество потерянных пакетов в локалке. :global LocalDisabled «false»; # Статус локального интерфейса. :global LocalFailoverTimes 0; # Кол-во падений локалки. :global LocalFailoverLastTime «-«; # Дата и время последнего падения локалки. :global LocalRestoreTimes 0; # Кол-во восстановлений локалки. :global LocalRestoreLastTime «-«; # Дата и время последнего восстановления локалки.
Вывод глобальных переменных в environment
— Объявляем функции.
*И вот именно в этот момент я полез править работающий скрипт. Как результат — 2 функции вместо 6 и минус 2 часа жизни :р. Потом мне не понравились 4 функции звуковых сигналов… Спустя 2 часа осталась одна, продолжаю. 
В процессе эксплуатации были обнаружены эпические «грабли» с мостами, для решения которых пришлось как обычно «прикручивать костыли». Подробнее об этих и прочих «граблях», а так же о их решениях можно почитать здесь, а в данном случае, плюс ещё одна функция и трафик между VRRP интерфейсами и мостами начинает ходить. Для того чтобы «разбудить» мосты, при изменении состояния VRRP интерфейсов, меняется параметр Edge с «auto» на «yes» и наоборот.
— Следующий цикл проверяет физическое подключение аплинк-нтерфейса. Задача цикла очень проста. Вытащили кабель из порта — получили статус «4», воткнули — получили статус «0». Таким образом мы активируем процесс проверки соединения при подключенном кабеле и останавливаем при отключенном.
— Пингуем «Интернет» и фиксируем результат.
— На основании полученного результата, включаем/отключаем интерфейсы. Концепция следующая. Если из всех попыток пинга ни одна не привела к успеху, то отключаем все VRRP (+ PPTP/L2TP) интерфейсы и переходим в статус «2», если попытка пинга удалась, то включаем все VRRP (+ PPTP/L2TP) интерфейсы и переходим в статус «0». Дополнительно предусмотрена защита от «забора». Часто бывает так, что соединение с интернет может пропасть и снова появиться несколько раз с высокой периодичностью. Чтобы избежать прыжков с маршрутизатора на маршрутизатор, устанавливается тайм-аут. Если падение произошло более чем 1 раз, активируется алгоритм, который выдерживает заданные в массиве тайм-ауты последовательно, плюс время выполнения основного цикла. В моём случае один цикл равен примерно одной минуте. Это зависит от количества пингуемых IP адресов и выделенного для каждого пинга промежутка времени. Исчерпав все возможные тайм-ауты, отключаем аплинк интерфейс и шлём письмо о том, что «Бобик сдох».
— Управляем PPTP/L2TP интерфейсами и «будим» мосты по состоянию VRRP интерфейсов.
— Управление локальными сервисами. В самом начале, в массиве я задал IP адреса своего домашнего сервера в разных сетях «10.0.0.4», «10.0.1.4» и тд. Идея следующая. Если с сервером беда — то начинаем выдавать IP с DHCP сервера MikroTik’а где в качестве DNS указан IP VRRP интерфейса этого MikroTik’а. Все DHCP-сервера на MikroTik’е я назвал именами IP адресов своего сервера (в соответствии с адресацией для каждой сети) и назначил на соответствующие VRRP интерфейсы.
DHCP сервера на MikroTik’е
Таким образом, мне не нужно задавать отдельно имена DHCP-серверов MikroTik’а, а отключать их по номеру подобно VRRP интерфейсам мне показалось не совсем правильным, так как возможно что помимо искомых DHCP серверов могут быть и другие, работающие отдельно от основной инфраструктуры.
Основной цикл этой функции выполняется при условии отсутствия изменений в конфигурации VRRP интерфейсов. Если же таковые обнаружены, цикл прерывается. Это нужно для того, чтобы в момент «переезда» VRRP интерфейсов, не включались локальные DHCP-сервера из-за отсутствия пинга на сервер. Как выяснилось, в момент изменений на VRRP в MikroTik’е практически всё «замирает» на некоторое время (последствия всё той-же проблемы с мостами).
Вот собственно и всё. Такой вот не замысловатый скрипт спас ситуацию с систематическими падениями сети и сэкономил кучу времени и нервных клеток. Теперь, даже в случае стандартного «выходного» в работе той или иной сети на наличии интернет соединения у меня дома это ни как не влияет.
Коротко о статусах
0 — Работа в штатном режиме.
1 — Утеряно соединение с интернет, переход в режим отключения интерфейсов.
2 — Интерфейсы отключены, режим ожидания возобновления соединенеия.
3 — Соединение с интернет восстановлено, переход в режим включения интерфейсов.
4 — В аплинк интерфейс не подключен кабель или проблемы с физическим соединением.
PS. Думаю внимательный читатель смог заметить и озадачится вопросом, как же скрипт отправит почту если соединение с интернет разорвано? Элементарно Ватсон! Напоминаю, что активным шлюзом является VRRP интерфейс, а это означает что он там, где есть интернет. Соответственно, если прописать статический маршрут для IP почтового сервера и DNS на IP VRRP интерфейса, то почта будет отправлена через активное соединение на соседнем маршрутизаторе.
Статические маршруты для отправки почты
UPD: Дальнейшее развитие скрипта смотрите здесь.
Лучшие практики отказоустойчивости от Дмитрия Скромнова в русскоязычном онлайн-курсе по MikroTik для самостоятельного изучения. Курс по настройке MikroTik и RouterOS основан на официальной программе MTCNA, однако содержит намного больше полезной информации. 162 видеоурока и большая практическая задача, разбитая на 45 лабораторных работ. Время на изучение неограниченно – все материалы передаются бессрочно и их можно пересматривать сколько нужно. Первые 25 уроков можно посмотреть бесплатно, оставив заявку на странице курса.
Создание отказоустойчивой ИТ инфраструктуры. Часть 3. Организация маршрутизации на роутерах VyOS
Основная цель статьи – показать процесс установки и настройки виртуальных маршрутизаторов VyOS на кластере oVirt, для организации связи на уровне L3 между внутренними и внешними сетями.
Также в статье будут рассмотрены вопросы, связанные с особенностями настройки выхода в Интернет через двух провайдеров, и повышения отказоустойчивости межсетевой маршрутизации.
Вводная часть
Основываясь на двух предыдущих статьях:
Мы к этому времени создали отказоустойчивый кластер oVirt, с подключенным к нему СХД для хранения виртуальных дисков ВМ. При этом все сетевые устройства и хосты коммутируются в стек из двух коммутаторов второго уровня Cisco C2960RX, на котором настроены соответствующие порты в транковом или статическом режимах, и к которым привязаны идентификаторы VLAN.
С формальной и практической точек зрения, у нас имеется полная связность на уровне L2 между устройствами и ВМ в пределах одного и тоже VLAN’а.
VLAN – это «виртуальная» локальная сеть, в которой все хосты взаимодействуют друг с другом в пределах одной широковещательной области (или сети). Обычно широковещательные области изолируются друг от друга с помощью VLAN, настраиваемых на портах коммутатора, хотя давным-давно сети разделяли физически, а не логически, подключая хосты из определённой группы доступа, к своим сетевым концентраторам, или хабам.
Для взаимодействия хостов из разных широковещательных областей (VLAN’ов) между собой, нам необходимо устройство, которое может соединить их на третьем уровне OSI, или по-простому – маршрутизатор. Это устройство, в свою очередь, также может использоваться для подключения к внешним сетям, обеспечивая выход из внутренних сетей в Интернет.
Основная наша задача – это создание отказоустойчивой ИТ инфраструктуры, в том числе и сетевой, поэтому нам потребуется связка из двух маршрутизаторов, где один маршрутизатор является ведущим, а второй ведомым. В случае выхода из строя ведущего маршрутизатора, в дело вступает ведомый, и весь трафик начинает идти через него.
Главное требование к такой схеме – она должна быть устойчивой и абсолютно прозрачной для всех сетевых потребителей, т.е. они не должны страдать от каких-либо потерь во время таких переключений, и тем более на них ничего не нужно дополнительно настраивать, кроме IP адреса, маски и шлюза по умолчанию.
В качестве маршрутизатора был выбран VyOS версии 1.2.2, по причине уже довольно длительной эксплуатации (в нашей организации), в ходе которой он показал себя только с положительной стороны, работая как на физических серверах, так и в виде виртуальных машин под управлением гипервизора KVM.
VyOS содержит в себе много полезного для сетевого администрирования функционала – работу с динамическими протоколами маршрутизации, VPN и IPSec туннелями, WAN load balancing, VRRP, QoS, и т.д.
В основе VyOS лежит ядро Debian, а CLI (командный интерфейс), очень напоминает таковой у Juniper, так что особой сложности у тех, кто с ним уже знаком, он не вызовет.
О наличии GUI (графической оболочки) конкретно для VyOS на сегодняшний момент ничего не известно, но работа в его консоли для любого Linux/Cisco/Juniper администратора, не должна вызывать затруднений, тем более что «под капотом» у него Debian, в котором можно при необходимости запускать знакомые системные утилиты, хотя конечно же необходимо использовать в первую очередь CLI самого VyOS.
Как вариант, если без GUI никак не обойтись, можно использовать Web GUI от роутера Vyatta, и попробовать export, а потом import конфигурации в VyOS — но такое решение на полную совместимость команд не проверялось, и неизвестно, будет ли оно работать сразу, или придётся что-то руками менять в конфиге.
Как всегда, перед началом работы с новым ПО, желательно ознакомиться с документаций на него – VyOS User Guide, чтобы дальнейшее чтение статьи прошло без сложностей. К тому же на Habr имеется свежая обзорная статья про VyOS, надеюсь что автор будет не против ссылки на неё 🙂
Дистрибутив VyOS доступен в следующих вариантах:
Для ускорения процесса развёртывания маршрутизаторов, в статье будет использоваться свежий rolling release VyOS 1.2.2, как вариант можно использовать бесплатную предыдущую LTS версию VyOS 1.1.8.
Протоколы и технологии (применительно к VyOS), которые будут задействованы в статье:
Подключение датацентра к Интернет с помощью протокола BGP в этой статье не рассматривается, так как у большинства организаций обычно нет такой необходимости, но при наличии технических возможностей и поддержке со стороны провайдеров, его можно без проблем реализовать.
Итак, после небольшого вступления, перейдём к основной теме статьи. Чтобы было удобно ориентироваться, приведу основные главы статьи:
Описание тестового стенда
Для тестового стенда в качестве внешних IP адресов и сетей, везде указаны приватные IP адреса, что конечно же никак не меняет сути нашей задачи и правил, по которым работают протоколы маршрутизации и функционирует Интернет. Ничто не помешает затем вместо приватных адресов использовать публичные адреса, и подключить нашу инфраструктуру к сети Интернет.
Для реализации отказоустойчивого подключения к сети Интернет и внутренним сетям, будут использоваться:
Все виртуальные маршрутизаторы и клиентские ВМ, будут работать на кластере oVirt. Это не значит, что весь тестовый стенд «заточен» именно под oVirt, его можно реализовать на чём угодно – на ВМ под управлением обычного KVM, VMware, Hyper-V, и даже на физических хостах.
Общая схема сети на уровне L3 для тестового стенда:
На этой схеме имеется несколько допущений:
В составе тестового стенда будут использованы следующие сети, с соответствующими идентификаторами VLAN:
В процессе развёртывания тестового стенда, нам придётся настраивать протокол BGP на роутерах Provider-1, Provider-2 и Provider-3, чтобы обеспечить связность между «публичными» сетями 172.16.1.0/24, 172.16.2.0/24 и 172.16.3.0/24
Задачи, которые сетевому администратору предстоит реализовать:
Подготовительные работы.
Перед развёртыванием проекта, необходимо создать 9 виртуальных машин в oVirt:
Все необходимые идентификаторы VLAN были созданы на коммутаторах и назначены на соответствующие сетевые порты ещё в самой первой статье из цикла.
Из подготовительных работ, нужно ещё сделать следующее:
1) Создать все используемые выше логические сети в административном портале oVirt, а затем назначить их на хосты кластера.
Делаем всё по инструкциям из предыдущей статьи, а также по официальной документации. Результат этой работы можно посмотреть на скриншотах, настройки сети у обоих хостов кластера должны быть идентичны:
2) Установить ОС на виртуальные маршрутизаторы с пакетом Quagga, а также ОС на клиентские ВМ.
После подключения ВМ к соответствующим логическим сетям, устанавливаем на них ОС, и настраиваем IP адреса и шлюзы в соответствии со списком ВМ и со схемой сети.
Добавлять установочные образы с ОС и создавать виртуальные машины мы научились в предыдущей статье, поэтому особых затруднений этот процесс не должен вызвать.
Дальнейшая настройка этих виртуальных машин будет выполнена далее, по ходу статьи.
Начальная настройка маршрутизаторов VyOS.
Для установки маршрутизатора VyOs в качестве виртуальной машины под управлением oVirt:
После включения ВМ и загрузки с ISO, заходим в консоль ВМ и вводим команду для начала установки ОС:
После завершения установки ОС, отсоединяем CD от ВМ, и перезагружаем её:
Логин и пароль по умолчанию для входа в виртуальный маршрутизатор VyOS: vyos / vyos
После перезагрузки виртуального маршрутизатора, заходим в консоль роутера (из административного портала oVirt), и проверяем образ, с которого он загрузился, и с которым мы теперь будем работать.
Для входа в режим конфигурирования роутера (по аналогии с «configure terminal» для устройств Cisco), вводим команду:
Настройка сетевых интерфейсов и других параметров маршрутизатора, может производиться только в режим конфигурирования.
Команды для просмотра сетевых интерфейсов и их настроек:
Настройка сетевого интерфейса VLAN17:
Чтобы удалить IP адрес с интерфейса:
Настройка сетевого интерфейса VLAN30:
Настройка сетевого интерфейса VLAN31:
Настройка сетевого интерфейса VLAN32:
Настройка сетевого интерфейса VLAN40:
Настройка сетевого интерфейса VLAN17:
Настройка сетевого интерфейса VLAN30:
Настройка сетевого интерфейса VLAN31:
Настройка сетевого интерфейса VLAN32:
Настройка сетевого интерфейса VLAN40:
Включение SSH для удалённого управления маршрутизатором
Настройка DNS forwarder для разрешения внешних имён с роутера
Настройка имени роутера и уровня логирования
Добавление ключа SSH для аутентификации пользователя на роутере
Настройка ntp сервера и временной зоны
Ускорение медленной работы по SSH (если нет доступа к DNS серверам)
Для сохранения всех сделанных изменений, выполняем команды
Для отказа от всех сделанных изменений, выполняем команду
Приведённые выше настройки, являются минимально достаточными для начала работы с VyOS через SSH, с аутентификацией по паролю или SSH ключу.
Помимо этих базовых настроек, существует ещё множество других, которые могут пригодиться при дальнейшей работе с VyOS, например, для:
Все дополнительные настройки в рамках этой статьи описать нереально, так как потребуется ещё добавлять информацию о шаблонах и параметрах системы мониторинга Zabbix, поэтому их внедрение и использование может быть темой одной из будущих статей.
Настройка правил на файерволе.
Ссылка на документацию – Firewall.
VyOS использует для фильтрации сетевых пакетов netfilter.
Политика для файервола в VyOS может применяться двумя способами:
В статье будет использоваться политика, применяемая к интерфейсу.
Политика для файервола управляется через наборы правил – это раздельные группы правил, пронумерованные от 1 до 9999. Правила выполняются последовательно, в соответствии с номером правила. Если трафик соответствует правилу, действие правила выполняется; если нет, то система переходит к следующему правилу.
Правила выполняют следующие действия:
Наборы правил обычно применяются к интерфейсу, или к нескольким интерфейсам, в следующих направлениях:
Пример настроек правил:
Строка 1 – создает политику файервола с именем «OUTSIDE-IN» для блокировки трафика по умолчанию.
Строка 2 – создает правило файервола (#10), которое разрешает трафик, соответствующий правилу.
Строка 3 – указывает, что правило применимо, когда существует установленный сеанс для трафика.
Строка 4 – указывает, что правило применимо, когда трафик относится к этому соединению.
Пример настройки файервола для блокировки трафика, направленного на сам маршрутизатор:
В этом примере весь трафик отбрасывается по умолчанию.
Пример применения правил для файервола к интерфейсам, в нужных направлениях:
Строка 1 – привязка политики файервола «OUTSIDE-IN» к интерфейсу eth0, для входящего трафика с внутренних адресов.
Строка 2 – привязка политики файервола «OUTSIDE-LOCAL» к интерфейсу eth1, для трафика, направляемого на сам маршрутизатор.
Настройка локальных правил файервола
Переходим к настройке локальных правил файервола (для трафика, направляемого на сам маршрутизатор).
Основные правила, которые будут использоваться:
Настройка правил файервола между защищаемыми внутренними сетями
Создаём политику для входящего трафика из сетей VLAN32 и VLAN17 – политика, которая устанавливается для трафика, который входит на интерфейс из локальной сети, защищаемой файерволом, с последующим его транзитом к другим сетям (снаружи, или защищаемым этим же файерволом).
С целью упрощения конфигурации тестового стенда и диагностики сети, политики для сетей VLAN30, VLAN31 и VLAN40 настраивать не будем, но можете создать правила для них самостоятельно.
Помните, что в производственной среде, отсутствие политики файервола на внешнем интерфейсе недопустимо!
Важное примечание
Все наборы политик для файервола, описанные в этой статье, даны для случаев обычной маршрутизации. Для случаев асимметричной маршрутизации (asymmetric routing), правила будут выглядеть немного по-другому, без поддержки SPI (stateful packet inspection).
Не забываем, что после создания политик, и их применения к интерфейсам, нужно сделать commit и save.
Настройка vrrp для отказоустойчивой маршрутизации
После выполнения базовых настроек маршрутизаторов VyOS, перейдём к настройке отказоустойчивой связи между хостами во внутренних сетях и их шлюзами по умолчанию.
Достигается это с помощью протокола vrrp, настраиваемого на обоих маршрутизаторах, в результате чего появляется виртуальный высокодоступный IP адрес — HAIP (Highly Available IP), являющийся шлюзом по умолчанию для внутренней сети. Этот адрес активируется на ведущем роутере, и через него идёт обмен трафиком между подключенной к нему какой-либо внутренней сетью, с остальными внутренними или внешними сетями. В случае сбоя ведущего роутера, этот HAIP автоматически переключается на ведомый (резервный) роутер, и трафик начинает идти через него.
Если вы когда-либо использовали HAIP, настраиваемый в keepalived, то это практически тоже самое, но ещё интересным и полезным может отказаться тот факт, что такая связка вполне работает между VyOS и обычным хостом с Linux, на котором настроен HAIP и keepalived (конечно же с идентичными настройками). Такая возможность может пригодиться при каких-то миграциях, или при отладке конфигурации на роутере или другом устройстве.
Для более глубокого погружения в детали настроек vrrp, рекомендуется статья от IBM, она относится к виртуальному маршрутизатору Vyatta 5600 от Brocade, но нам подойдёт, так как корни VyOS растут из проекта Vyatta (который в 2012 году был перекуплен Brocade).
VLAN17, HA VIP – 172.20.1.1/24
VLAN32, HA VIP – 172.20.32.1/23
VLAN40, HA VIP – 172.20.40.1/23
Команды для просмотра информации о работе vrrp:
Настройка выхода в Интернет через двух провайдеров.
Балансировка исходящего трафика из датацентра к внешним сетям (в Интернет), может производиться между двумя и более внешними интерфейсами, понятно, что для этого датацентр должен быть подключен как минимум к двум независимым провайдерам.
В случае потери доступа к кому-либо из провайдеров, происходит балансировка трафика между оставшимися рабочими линиями связи, а после восстановления работоспособности канала, ранее сбоивший маршрут автоматически добавляется обратно в таблицу маршрутизации, для его дальнейшего использования балансировщиком. Балансировщик автоматически добавляет маршруты для каждого внешнего интерфейса в таблицу маршрутизации и балансирует трафик между ними, в зависимости от их состояния и веса.
Наша задача состоит в том, чтобы обеспечить выход в Интернет одновременно через двух провайдеров (балансировку нагрузки), для хостов из внутренних сетей: VLAN17, VLAN32 и VLAN40.
Установку и настройку IP адресов на «внешних» (провайдерских) роутерах, мы должны были выполнить ещё в самом начале, сейчас нам нужно будет настроить между ними маршрутизацию с помощью протокола BGPv4 и сервиса bgpd, являющегося составной частью пакета Quagga.
Установка пакета Quagga делается относительно просто, а управление ею производится через CLI, вызываемый командой vtysh. Сам CLI довольно простой, и если сетевой администратор уже знаком с маршрутизаторами Cisco, то никаких проблем он не вызовет.
Безусловно, правильнее было бы на «внешних» (провайдерских) роутерах тоже установить VyOS и настраивать BGP на них, но целью статьи это не является, чтобы не перегружать читателей лишней информацией. Показать, как на VyOS настраивается BGP и политики маршрутизации, это возможная тема одной из следующих статей, поэтому в целях экономии времени и упрощения настройки тестового стенда, используется самый обычный CentOS и Quagga.
После настройки BGP, не забываем также про настройку iptables на «внешних» маршрутизаторах, если это необходимо.
Если всё было сделано правильно, то таблица маршрутизации на Provider-3 должна выглядеть так:
То есть мы должны получать на этот роутер анонсы по BGP о сетях 172.16.1.0/24 и 172.16.2.0/24, и маршруты к ним должны присутствовать в таблице маршрутизации.
Соответственно, на маршрутизаторах Provider-1 и Provider-2, маршрут к сети 172.16.3.0/24 также должен находиться в таблице маршрутизации.
Примечание:
eth+ используется как алиас (или псевдоним), который относится ко всем сетевым интерфейсам.
Проверка работы балансировки нагрузки:
Тестирование работы внутренней маршрутизации и выхода в Интернет, при различных условиях
Во время тестирования каждого пункта, указанного выше, обычно проверяется:
Для балансировки нагрузки можно задавать и другие параметры – вес и ограничение пропускной способности для канала, а также различные проверки для определения доступности внешнего канала. Можно самостоятельно разобраться с этими настройками, и даже протестировать как они работают – не зря же мы строили наш тестовый стенд.
Публикация в Интернет внутренних ресурсов через NAT, специально не рассматривалась, чтобы читатель имел возможность самостоятельно выполнить такую настройку, благо вся подготовительная работа для этого сделана (не забываем только про настройку политик файервола).
Также вполне может иметь место вариант, когда кто-либо из провайдеров, или даже оба провайдера, выдали не по два публичных адреса, а по одной подсети каждый, например, c префиксами /27.
В этом случае, чтобы иметь возможность выхода с хоста с двумя публичными адресами от двух разных провайдеров в Интернет, а также для подключения из Интернета к его публичным адресам, на нём необходимо будет настроить PBR (policy-based routing) и multipath routing. Впрочем, это уже тема для другой статьи (не разбирайте тестовый стенд, может ещё пригодится :)).
Заключение
В этой статье мы вкратце рассмотрели настройку виртуальных маршрутизаторов VyOS, и довольно часто встречающийся вариант выхода в Интернет через двух независимых провайдеров – в принципе, без надёжной связи, датацентр со всей инфраструктурой в нём, не может считаться отказоустойчивым.
В частном случае, если необходима публикация большого числа каких-то внутренних ресурсов в Интернет, то можно рассмотреть аренду у какого-либо провайдера блока публичных IP адресов с префиксом не меньше /24, и анонсирование их по протоколу BGP через двух независимых провайдеров.
Такой вариант подключения нашего датацентра к Интернет может быть даже более интересным и предпочтительным, чем описанная в этой статье балансировка нагрузки на внешних каналах, так как позволяет организации в дальнейшем подключить второй датацентр с использованием публичных адресов из уже имеющегося блока адресов. Второй датацентр конечно же повысит не только отказоустойчивость, но и катастрофоустойчивость всего проекта в целом, понятно что нужно будет выполнять доработку проекта, но это уже другая история.
С формальной точки зрения, цикл статей о создании отказоустойчивой ИТ инфраструктуры можно было бы и закончить, так как все задачи, которые стояли перед нами в самом начале, были успешно выполнены:
Обычно ко времени начала развёртывания аппаратной инфраструктуры, разработчики уже должны иметь как минимум черновой вариант веб-проекта, который вероятно уже тестировался где-то в облаке. Так что пришло время начать развёртывать виртуальные машины, устанавливать на него ПО и настраивать публикацию ресурсов наружу.
Конечно, у нормального администратора неизменно возникнут вопросы про мониторинг и резервное копирование всего нашего хозяйства… В этом цикле статей такие вопросы не поднимались, но наверняка в будущих статьях мы к ним ещё вернёмся. Необходимо сразу отметить, что всем известный Veeam – НЕ поддерживает резервное копирование oVirt/RHEV и вообще виртуальных машин KVM, от слова никак, поэтому придётся использовать или другие коммерческие решения (Veritas NetBackup, Acronis Cyber Backup, TrilioVault, Bacula Enterprise Edition, SEP, etc.), или «ваять» что-то своё, или «допиливать» какие-то уже имеющиеся OpenSource решения, найденные на просторах Интернета.
Ну а что касается мониторинга железа и виртуальных машин, то тут дело вкуса и личных предпочтений, обычно на проектах используется Zabbix – бесплатное и довольно надёжное решение, с массой доступных шаблонов на любой вкус и цвет.
Но, впрочем, вернёмся обратно к нашей инфраструктуре – напомню, что в первой статье в составе железа была указана пара замечательных коммутаторов Cisco 3850, и было бы очень странно не использовать их по прямому предназначению – скоростной маршрутизации трафика между сетями. Поэтому в следующей статье мы и рассмотрим их интеграцию в нашу инфраструктуру, так как работа для них обязательно найдётся.