Мікротик. Failover. Load Balancing
Коли у мене виникла потреба розібратися, як зробити failover або load balancing, маючи два і більше каналів у світ, я знайшов безліч статей та інструкцій, в яких описувалися робочі конфігурації. Але майже ніде не знайшов роз'яснення, як усе працює, та опису відмінностей різних варіантів. Хочу виправити цю несправедливість та зібрати найпростіші варіанти побудови failover та load balancing конфігурацій в одній статті.
Отже, у нас є роутер, який з'єднує нашу локальну мережу та два канали в інтернет (основний ISP1 та резервний ISP2).
Давайте розглянемо що ми можемо зробити:
Відразу попереджу: незважаючи на те, що в цій статті все описуватиму для mikrotik, не стосуватимуся теми скриптів
У нас з'явився резервний канал, який можна направити трафік при відмові основного. Але як зробити, щоб mikrotik зрозумів, що канал упав?
Найпростіше резервування каналів
Найпростішийfailoverможна налаштувати, використовуючи пріоритет маршруту (distance у mikrotik/cisco, metric в linux/windows), а також механізм перевірки доступності шлюзу - check-gateway.
Забезпечення failover з більш глибоким аналізом каналу
У минулому прикладі все чудово, окрім ситуації, коли шлюз провайдера видно і пінгується, але інтернету за ним немає. Нам би це здорово допомогло, якби можна було приймати рішення про життєздатність провайдера, пінґуючи не сам шлюз, а щось за ним.
Я знаю два варіанти вирішення цього інженерного завдання. Перший і найпоширеніший — використовувати скрипти, але оскільки в цій статті ми не чіпаємо скрипти, зупинимося докладніше на другому. Він має на увазі не зовсім коректне використання параметраscope, але допоможе нам промацати канал провайдера глибше, ніж дошлюзу. Принцип простий: Замість традиційної вказівки default gateway=шлюз провайдера, ми скажемо роутеру що default gateway це якийсь іззавжди_доступних_вузлів(наприклад 8.8.8.8 або 8.8.4.4) і він у свою черга доступна через шлюз провайдера.
Тепер розберемо, що відбувається трохи докладніше: Хитрість у тому, що шлюз провайдера не знає про те, що 8.8.8.8 або 8.8.4.4 - це роутер і направить трафік звичайним шляхом. Наш mikrotik вважає, що за замовчуванням весь інтернет-трафік потрібно відправляти на 8.8.8.8, який безпосередньо не видно, але через 10.100.1.254 доступний. А якщо пінг на 8.8.8.8 зникає (нагадаю що шлях до нього у нас жорстко вказаний через шлюз від ISP1), то mikrotik почне надсилати весь інтернет трафік на 8.8.4.4, а точніше на рекурсивно визначений 10.200.1.254 (ISP2).
Але у мене кілька разів виникала ситуація, коли інтернет через шлюз провайдера працює, а ось конкретний вузол чи мережа немає. У таких випадках вищеописаний метод не дуже допомагає і для забезпечення безперебійної роботи мені доводилося перевіряти доступність вузла вже за допомогою скриптів. До речі, якщо хтось знає рішення файловера на один зовнішній хост без застосування скриптів і протоколів динамічної маршрутизації — поділіться рецептом.
Load Balancing
Тепер розглянемо іншу схему:
У ній другий другий канал не резервний, а рівноцінний. Чому б не використовувати обидва канали одночасно, підвищивши таким чином пропускну здатність?
Починаємо налаштовувати Load Balancing
Друге, що теж важливо розуміти- потрібно розділяти поняття вхідного та вихідного трафіку. Справа в тому, що для вихідного трафіку роутер може вирішувати, яким шляхом він піде, а вхідний трафік для нього як «трафік Шредінгера».Поки його немає, наш mikrotik не знає, через який інтерфейс він прийде, а коли прийшов – міняти інтерфейс уже пізно.
Третє- балансування каналів не є резервуванням. Це дві окремі функції.
Готуємось прийняти «трафік Шредінгера»
Ділимо вихідний трафік
Для розподілу вихідного трафіку за інтерфейсами, нам потрібно повісити відповідну марку маршруту на з'єднання. Складність у цьому, що треба вирішити яке з'єднання вішати мітку ISP1, але в яке ISP2.
Існує кілька варіантів поділу сполук за групами:
1) Ділимо вихідний трафік, прикручуючи марку намертво
Правила, що балансують трафік ми можемо прописати жорстко: Наприклад, ми хочемо налаштувати важливі для нас протоколи HTTP (80 port), HTTPS (443 port), POP (110 port), SMTP (25 port) через ISP1, а весь решта трафік пустити через другого провайдера:
2) Ділимо вихідний трафік, вибираючи кожне Н-е з'єднання
Можемо ділити з'єднання по порядку. Перші ліворуч, другі - праворуч. Все просто.
3) Ділимо вихідний трафік, використовуючи PCC (per connection classifier)
PCC підходить до поділу трафіку трохи складніше. Він поділяє трафік групами, ґрунтуючись на даних TCP заголовка (src-address, dst-address, src-port, dst-port).
Ділимо вихідний трафік, використовуючи ECMP (equal cost multipath routing)
На мій погляд найпростіший і найсмачніший варіант поділу трафіку:
Mikrotik сам поділить трафік шлюзами, використовуючи round-robin алгоритм.
До речі, у версії 6.Х RouterOS mikrotik поламав check-gateway у ECMP, так що використовувати конструкцію/ip route add gateway=10.100.1.254,10.200.1.254 check-gateway=pingможна і логічно але абсолютно марно. Для позначки неживихмаршрутів в ECMP потрібно створити додаткові маршрути, які використовують кожен з gateway окремо. З включеним check-gateway очевидно. Позначаючи маршрут неактивним, mikrotik робить це для всіх.
І останнє важливе зауваження про швидкість каналів
Візьмемо 2 нерівнозначні канали, наприклад, 100 мбіт і 50 мбіт. Збалансуємо їх через Nth, PCC чи ECMP. Яку сумарну пропускну спроможність отримаємо?
Насправді десь близько 100 мбіт (найслабший канал Х разів). Відбувається це тому, що mikrotik уявлення не має про пропускну здатність каналів, він її не вимірює. Він просто поділяє трафік на відносно рівні групи.
Подолати цей нюанс можна правильно проектуючи групи вихідного трафіку, з урахуванням пропускної спроможності каналів.
У PCC також можна зробити нерівні групи:
Дякую за увагу.
Успіхів у налаштуваннях безвідмовних систем маршрутизації.