Как стать провайдером. Часть четвертая. Резервирование и балансировка

Приветствую вас! В данной части я хочу рассказать про реализацию распределения нагрузки и резервирования внешних каналов в интернет.

Как я уже упоминал в первой части - я, опираясь на реальные факты, постараюсь убедить вас использовать коммерческие продукты нашего производства. Вы можете назвать это откровенной рекламой и отчасти будете правы, но я советую эти продукты не просто так. Все дело в том, что изначально данные продукты были придуманы и написаны сугубо для личного использования в корпоративном и провайдерском направлении. Опять же для создания данных продуктов (на то время: самописных скриптов и правил) послужило отсутствие надежных и рабочих решений. С момента выхода первой рабочей версии уже прошло 7 лет. За эти 7 лет, благодаря учету пожеланий наших пользователей, данные продукты обрели самые востребованные алгоритмы работы и необходимый дополнительный функционал. Работы по улучшению данных продуктов и внедрению нового функционала ведутся и сегодня. Каждый раз, когда мы выпускаем очередную версию продукта, нам кажется, что это все чего можно было пожелать и сделать в данном направлении. Но как оказалось - даже в самых простых начинаниях нет пределу совершенства. И через некоторое время мы выпускаем уже новую версию, с новыми улучшениями и функциями.

В то время когда появились данные идеи, в интернете не было такого обилия информации даже на официальных ресурсах, какое есть сейчас. Зато сейчас, куда не плюнь, орава анонимных специалистов и говнокодеров расскажут вам, как все быстро, бесплатно, круто и с нуля все настроить, или написать.
Вот об этом и поговорим.

Плоскогубцы
Помните, как в школе на уроках труда нам давали напильник с чаще всего слетающей ручкой и стальные половинки заготовки для плоскогубец, которые необходимо было обработать?
Потом эти половинки точили, закаляли, собирали и на ручки надевали обрезки трубок ПВХ.
Так было не только потому, что нас учили труду, а потому что нас надо было чем то занять эти два урока по 40 минут.
Если вам в данный момент понадобятся плоскогубцы, которых у вас нет, я очень сомневаюсь, что вы возьмете заготовку и станете изготавливать их самостоятельно.
Все просто, это трудно, долго и дорого. Кроме этого и качество будет сомнительным.
Вместо этого вы пойдете в хозяйственный магазин и купите качественный инструмент, который хорошо выглядит, удобно лежит в руке, нравится вам и самое главное выполняет возложенные на него функции.

Сколько стоит ваше время? Я полностью уверен, если вы читаете эту статью - это значит что с руками у вас все в порядке. И исходя из этого: вам наверняка часто приходится выбирать, на что потратить свое время. Некоторые из нас имеют возможность изготовить плоскогубцы самостоятельно, убив на это уйму времени. Другие их просто купят, а время используют более рационально, например, для заработка значительно большего количества денег, чем было потрачено на их покупку.

Но есть еще и другая категория людей, которые забили на своих родных и близких, на свое будущее и будущее своей семьи. Я сейчас говорю про людей с неудержимым альтруизмом в крови, про тех, кто тратит свой талант и вкалывает сутками на пролет за всеобщее спасибо и кратковременное почитание.
Почему кратковременное? Спросите у подрастающего поколения: "Кто такие Линус Торвальдс и Билл Гейтс?". Почему когда 5 октября 2011 года, умер Стив Джобс, об этом написали в газетах, интернете и показали по телевизору? Но когда спустя три дня, скончался Деннис Ритчи, который наиболее известен как создатель языка программирования "C" о нем не сказали, ни слова? Почему Microsoft Word подчеркнул фамилии и имена Торвальдса и Ритчи красным, а Гейтса и Джобса нет?
Ответ опять же прост - потому что всем плевать кто они такие и что их вклад в чем-то значительно больше всем известных персон.
Я не имею ничего против такого настроя, кто-то работает за деньги, кто-то за "спасибо". Но, если вам приятен такой образ оставайтесь в нем в пределах вашей группы, а унижать людей которые не согласны работать за идею и агитировать встать на "путь истинный" явно не стоит.
Я помню тот момент, когда я впервые столкнулся с Linux, до этого работал только в Windows. Огорчению моему не было предела, операционная система, состоящая из различных модулей написанных разными разработчиками. Уже не помню, как назывался тот пакет для управления временем и часовым поясом, в общем, единственное средство кроме командной строки для изменения даты и времени в системе. И в нем такой детский баг который свел к нулю предназначение данной программы. В майкрософте за такое бы расстреляли бы. Но тут другая схема: "Сейчас я вам выдам заготовки и напильники и в течении 80 минут вы будете делать плоскогубцы"

К чему я написал про все это?
Думаю, намеков было дано вполне достаточно и большинство сделали свои выводы. Но я лишь хотел сказать этим, что важно понимать, зачем и для чего вы занимаетесь тем, чем занимаетесь. Важно понимать, где находится тот баланс между "сделать самому и это окупится" и "проще купить, чем убивать столько времени и сил".

Резервирование каналов (Failover)
Когда у вас один жирный канал, беспокоится особо не о чем, кроме тех случаев, когда он выходит из строя. И в данной ситуации вы в большинстве случаев ничего не можете сделать.
Решить данную проблему можно добавлением еще одного резервного канала в интернет.
Просто воткнуть еще один кабель не получится, необходимо так же произвести необходимые настройки и выбрать технологию определения падения/восстановления основного канала и переключения на резерв.

Решений данной проблемы в среде Mikrotik Router OS великое множество. Есть способы определения отвала канала и переключения на резерв с помощью фейковых маршрутов, с помощью пресловутого NetWatch, с помощью скриптов различного качества и различных калибров.

Способ с созданием фейковых маршрутов довольно прост, но при этом нарушает порядок в системе, и список маршрутов выглядит как помойка. Данная схема не просто похожа на костыль, это и есть огромный костыль, который будет многократно увеличиваться с ростом числа каналов. Основным достоинством этого костыля является не менее корявое умозаключение: "Зато без скриптов!". Окей! Для чего тогда вообще нужны скрипты и какая бы веселая жизнь была бы без них? Разве много ресурсов жрет утилита ping запущенная скриптом и меняющая шлюзы в маршрутах? Как ваш костыль "без скриптов" облажается при смене шлюза ввиду отсутствия статики? В общем, данный способ полная лажа, которую даже на домашнем роутере настраивать не стоит, т.к. тема "без скриптов" не оправдывает себя ни по надежности, ни по производительности. При изменении шлюзов, адресов, добавлении или удалении каналов вы обретете дополнительную головную боль при перенастройке данного костыля.

Второй способ это использование утилиты Netwatch из пакета advanced-tools системы ROS. Очередной глупый способ заменить утилиту ping. В данной утилите два окна, в первом: выполнить "вот этот скрипт" при пропадании интернета и выполнить второй скрипт при появлении. И нам дают два скрипта определяющих, что упало, а что поднялось и что нужно сделать. Жесть наступит, когда появится третий и четвертый каналы. Никакого определения приоритетов и прочих прелестей. Само по себе это - скрипты со вставленным по середине костылем в виде Netwatch. Зачем такие страдания, когда всего несколько строк кода отделяют вас, от чистого скрипта, который надежнее и проще в масштабировании?

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

На просторах интернета можно найти разнообразные скрипты для обеспечения резервирования, но большинство из них написаны за пять минут на коленке и имеют сомнительное качество. Это видно по коду, отсутствие элементарных кавычек и скобок при обозначении переменных, лишние переменные в коде, отсутствие дополнительных проверок и многое другое.
На самом деле скрипты в ROS всегда были капризной штукой и от версии к версии с ними могли возникать проблемы. Разработчики ROS привыкли, не предупреждая менять синтаксис языка для скриптов (он у них свой) и имена системных переменных.

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

Четвертый вариант это покупка FailoverEvx модуля или комплекса Evolution целиком, это как раз то, что я тут без ума и памяти вам рекламирую.
Можно очень долго перечислять преимущества данного решения в сравнении с другими способами. Вместо этого я опишу этот модуль немного иначе.
Основной принцип работы данного модуля ничем не отличается от третьего способа. Но и у скриптов есть слабая сторона - это линейность их исполнения, что существенно понижает реакцию скрипта на изменения в системе. Суть в том, что пока вы проверяете каналы вызовом утилиты ping, скрипт ждет результата ее выполнения. В Evolution данные процессы протекают не по очереди, а параллельно, что позволяет компенсировать вносимую задержку и более оперативно реагировать на изменения в системе.
Добавьте к этому свойству дополнительный функционал, в виде проверки времени задержки прохождения пакетов по каналу, контроля дополнительных маршрутов, систему приоритетов, систему контроля актуальности шлюзов при изменении их провайдером, систему автоматического восстановления каналов при зависании сессий, систему контроля времени Uptime/Downtime, которая успешно используется для реализации более правильной балансировки, следовательно, и для повышения отказоустойчивости. Кроме этого настройки модуля позволяют без проблем изменять параметры отдельных каналов, добавлять новые и удалять ненужные. Система оповещений об изменении в конфигурации по email и SMS будет приятным бонусом, встроенная система работы с DynDNS будет держать записи всегда в актуальном состоянии.

Понятное дело, что и такой скрипт вполне реально написать самостоятельно, вопрос только в том, сколько на это уйдет времени и сил.

Подводя итог по теме резервирования с помощью FailoverEvx, можно сделать вывод, что это решение из серии "Поставил и забыл, теперь сплю спокойнее". Кроме этого использование данного модуля дает значительные преимущества при совместной работе с модулем BalancerEvx и QOS, т.к эти три компонента взаимосвязаны и если они не дружат друг с другом то это очень плохо.

Балансировка нагрузки (Load Balance)

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

Но балансировка может быть разной и не всегда полезной. В интернете можно найти несколько методов и способов балансировки нагрузки и если сказать честно - один другого не лучше.

Балансировка на уровне ресурсов (dst-address)
Данный способ балансировки используется крайне редко у субпровайдеров, даже правильнее сказать - в самых крайних случаях.

Суть данного метода заключается в том, что каждый новый пакет от пользователя (src-address) уходит в большую сеть к ресурсу (dst-address) через один из каналов. Как только ресурс ответил (в этот же канал) его ip адрес временно закрепляется за данным каналом и весь последующий обмен пакетами, с этим адресом будет осуществляться только через этот канал. Так будет до тех пор, пока обмен не будет прерван на продолжительное время (timeout). Если пояснить на примере - то, постучавшись впервые на один из web-серверов яндекса наш пакет вылетит из случайного или выбранного балансировщиком по определенному критерию канала. Ответ от яндекса придет именно на тот канал, с которого вышел наш пакет, после этого все общение с яндексом осуществляется через данный канал.

Простыми словами балансировщик разбрасывает новые запросы к внешним серверам по разным каналам, обмен пакетами с уже известными серверами осуществляется согласно привязке.

Недостатки данного способа проявляются, когда происходит обращение одного приложения к нескольким серверам с разными ip адресами.
Выглядит это примерно так.
Социальная сеть вконтакте, страница авторизации находится на сервере 1.1.1.1 в то время как сам сервер авторизации имеет другой адрес 2.2.2.2. На заглавную страницу мы попали с первого канала и засветили белый адрес этого канала, ввели учетные данные и нажали кнопку войти. Далее происходит редирект на сервер 2.2.2.2 с передачей post-запроса, в котором содержатся наши учетные данные и ip адрес первого канала. И т.к. роутер ничего о нем не знает - пакеты к этому серверу, вероятно, пойдут через второй канал. И тут у сервера происходит разрыв шаблона, авторизация была инициирована с первого белого адреса, а данные передает совершенно другой ip адрес.

Схожие проблемы будут возникать при использовании Skype, ICQ, WebMoney Keeper, почти всех файлообменников, клиент-банков, Youtube и пр. На самом деле список значительно больше и пополняется с каждым днем.

Все это происходит по понятной причине, распределение нагрузки между каналами осуществляется маленькими блоками с большой частотой. Чем больше пакетов - тем больше частота.

Плюсами данного способа являются:
Правильный ответ на пинг по любому каналу извне.
Возможность частичного суммирования скоростей каналов для одного пользователеля.

Про способ мы поговорили и для его реализации есть несколько методов:

Распределение по каналам с помощью NTH, Random или ECMP
Чтобы не раздувать материал, скажу просто, эти методы примерно работают по одинаковой схеме: Один пакет в один канал, второй пакет во второй.
Именно эти методы виновники проблем, т.к. именно они делают частые переключения между каналами, по итогу ни о какой стабильной работе не может быть и речи.

Так же есть еще один метод: PCC (per connection classifier)
Его реализация не требует создания address-list для контроля привязки ресурсов к каналам, данный метод сам разбирает заголовки пакетов и на основе классификатора (в данном контексте по dst-address) следит, чтобы соединения, выпущенные через первый канал работали только через этот канал. К сожалению, использование данного метода никак не улучшит ситуацию, это всего лишь меняет использование адрес листов на контроль с помощью PCC.

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

Снизить количество данных проблем можно только с помощью скриптов, которые обеспечивают обратную связь с текущей нагрузкой на канале.
Изменение схемы заключается в том, что переключение новой нагрузки на канал будет осуществлено только после полной нагрузки первого канала или загрузки большими блоками, например в 10%. Но и это не гарантия от возможных проблем.

Балансировка на уровне портов или типа трафика.
Это один из способов сделать "чем хуже, тем лучше!" суть заключается в разбросе диапазонов портов по разным каналам. Идея на грани полного идиотизма и незнания принципов работы сети на уровне протокола и приложения.
Взять, к примеру, Utorrent который регистрируется на трекере по 80 порту, а качает по совершенно другим портам. И хорошо, что трекеру абсолютно по барабану, что регистрация у вас прошла с одного ip, а качаете вы с другого, т.к. для идентификации используется passkey или вообще все проходит без него. Только вот обратно так не получится, торрент клиент сообщает трекеру адрес первого канала, при получении анонса другие пиры будут пытаться, подключится по этому адресу, но роутер будет отвечать в другой канал и соединения не будет установлено. Кому еще нужны примеры, чтобы понять, что это дурная идея? Так ведь нет, по всем форумам возня, и ведь хором кричат: "У меня так РАБОТАЕТ!". А другие поддакивают: "Мол, спасибо за идею! Так же себе сделаю!" Решение ваше, делайте!

Балансировка на уровне пользователя (src-address)

Суть данного способа заключается в разбросе пользователей на основании их ip адреса по разным каналам. С последующей привязкой к ним.

Тут может быть использовано два метода, это старые и добрые адрес-листы и тот же PCC с установленным классификатором (src-address).

PCC не интересно использовать, только потому, что им нельзя управлять так же гибко как при использовании адрес-листов.

Пользователей можно привязать жестко к определенному каналу статическими записями в адрес-листах, так же можно использовать дополнительные скрипты для реализации обратной связи с каналами и распределять пользователей динамически.

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

Исходя из всего вышеизложенного, можно сказать, что оба способа балансировки (src-address и dst-address) вполне можно использовать, если имеется обратная связь с данными об использовании канала. Эти данные можно получить с интерфейсов с помощью скрипта, который использует системную утилиту monitor-traffic. Запуск данной утилиты дает значительную нагрузку на процессор роутера. Кроме всего этого однократный запуск данной утилиты выдаст нагрузку на канал в текущий момент времени (момент скачка или спада), а нам нужна средняя нагрузка за последние 3-5 секунд. Для получения данного значения требуется запустить утилиту 3-5 раз с интервалом в 500-1000мс, полученные значения суммировать и разделить на количество запусков. При таком подходе, для получения данных с двух каналов потребуется 8-12 секунд. И это очень много, т.к. для оперативного переключения нагрузки требуется реакция балансировщика в районе 500-1000мс. Виновником этого опять же является линейность выполнения скриптов и циклов в них. Кроме этого будет просто дикая нагрузка на процессор при исполнении данного скрипта.

На многих форумах в интернете можно прочитать: "Зачем использовать скрипты для балансировки и тем более покупать их, когда на PCC все прекрасно работает?"
У меня встречный вопрос! Работает где? На вашем домашнем роутере? В вашей конторе на пять машин с вечно падающим 3G? Владелец сети, хотя бы с 50 абонентами с вами согласится что ваше творение не вызывает жалоб и негодований его абонентов? И что толку, что пример взят с вики разработчика ROS?

Запомните навсегда! PCC, NTH, RANDOM, ECMP, BONDING разработаны для работы с ВНУТРЕННИМИ линками, а не для балансировки внешних каналов в интернет! Хотите из коробки и без скриптов балансировать и резервировать каналы? Поднимайте бордер с BGP, делайте анонс вашей сети через провайдеров и не лечите людям голову своими вредными советами. Без скриптов и BGP качественная балансировка возможна только статическим распределением пользователей по каналам. Для качественной динамической балансировки требуются быстрые скрипты с параллельной обработкой данных и никакой PCC вам тут не поможет.

Теперь расскажу в чем отличительные особенности коммерческого модуля BalancerEvx из состава комплекса Evolution.

Модуль может работать в двух режимах, по ресурсам (dst-address) и по пользователям (src-address)

При выборе режима "по ресурсам" используется основной блок правил привязки адресов к каналам, новые запросы распределяются между каналами с заданным шагом в процентном соотношении от текущей нагрузки канала по скорости и/или количеству пакетов. При установке шага в 10%, первый канал будет нагружен на 10%, произойдет переключение на второй канал, как только второй канал будет загружен до 10%, произойдет переключение на первый канал. Как только нагрузка на первом канале достигнет 20%, произойдет переключение на второй канал. И так по кругу.
При шаге в 90% сначала будет нагружаться первый канал почти до предела и только потом произойдет переключение на второй.
Тем не менее, как бы все сказочно не звучало, я рекомендую использовать данный режим только в крайних случаях. Один из них - это домашнее использование, когда одному или нескольким потребителям нужно частичное сложение скоростей каналов. Второй случай - это когда тарифные планы абонентов больше пропускной способности самого узкого канала.

При выборе режима "по пользователям" используется основной блок правил привязки адресов пользователей к каналам. Вновь подключившиеся пользователи привязываются на самый свободный из каналов. Шаг балансировки в таком режиме устанавливается в 1%. Данными для расчета нагрузки могут быть показания скорости, количество пакетов, задержки на канале, а так же результаты расчета прогнозируемой нагрузки на канал.
Прогнозируемая нагрузка рассчитывается исходя из сопоставления ip адресов пользователей с их тарифными планами. Данная информация может быть задана вручную или автоматически с помощью биллинга. В данном режиме можно принудительно направлять выбранных абонентов в нужный канал. Так же можно заставить балансировщик перенаправлять запросы к определенному ресурсу через определенный канал.
Кроме того балансировка по пользователям дает возможность знать на каком из каналов в данный момент работает тот или иной абонент. Это дает возможность использовать более умный шейпер с распределением по каналам.

Так же BalancerEvx очень хорошо дружит с модулем FailoverEvx и может оперативно получать с него информацию о текущем состоянии каналов, задержках на них и их Uptime/Downtime. Данная информация используется балансировщиком для своевременного перераспределения пользователей с аварийного канала на оставшиеся каналы. Дополнительно балансировщик может принудительно запустить перераспределение пользователей, если канал вернулся в работу и остается стабилен в течение заданного времени.

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

Изменение конфигурации сети или каналов в интернет, а так же их добавление или удаление крайне простое, всего одна запись в файле конфигурации и готово. Никаких дополнительных проблем с переписыванием кода, добавлением правил и маршрутов, все будет сделано автоматически.

Я не говорю вам, что не стоит пробовать сделать, что-то самому. И вопреки моим советам не пробовать настраивать плохо работающие схемы и правила. Пробуйте и тестируйте это очень полезный опыт, по крайней мере, потом будет, с чем сравнить.

Я очень надеюсь, что у меня получилось правильно донести до вас свою точку зрения, относительно тех простых вещей что экономить и тратить свое время нужно там, где это действительно оправдано. И что не стоит изобретать велосипед дважды его дешевле купить, то же самое и с плоскогубцами. ;)

Еще раз напомню, что Evolution это продукт который разрабатывался для своих личных нужд, как инструмент, который негде было купить, а для себя мы делаем только самое лучшее. На протяжении этих семи лет он постоянно совершенствовался и дорабатывался с учетом замечаний и потребностей. Я искренне радуюсь за пользователей Evolution, которые пишут мне после настройки и тестирования комплекса, что теперь у них все работает "на отлично". Надеюсь, что рано или поздно, и вы начнете использовать наши продукты на своем маршрутизаторе и по достоинству оцените нашу работу.

Почитать про Evolution можно сдесь

При использовании материалов ссылка на автора и источник ОБЯЗАТЕЛЬНЫ!

Автор: Григорьев Дмитрий (Inlarion) (C) 20.05.2016