Pull to refresh

Mikrotik. Failover. Load Balancing

Network technologies *
Sandbox
Когда у меня встала необходимость разобраться, как сделать failover или load balancing, имея два и более каналов в мир, я нашел множество статей и инструкций, в которых описывались рабочие конфигурации. Но почти нигде не нашел разъяснения, как все работает, и описания отличий разных вариантов. Хочу исправить эту несправедливость и собрать простейшие варианты построения failover и load balancing конфигураций в одной статье.

Итак, у нас есть роутер, который соединяет нашу локальную сеть и два канала в интернет (основной ISP1 и резервный ISP2).

Давайте рассмотрим что же мы можем сделать:

Сразу предупрежу: несмотря на то, что в этой статье буду все описывать для mikrotik, не буду касаться темы скриптов
Читать дальше →
Total votes 30: ↑28 and ↓2 +26
Views 258K
Comments 45

Разные подходы к балансировке трафика

SENETSY corporate blog System administration *Network technologies *
Технологии MPLS сегодня стали де-факто стандартом построения сетей операторов связи. Некоторые участники начальных разработок утверждают, что работа была направлена на получение протокола с фиксированной длинной заголовка чтобы упростить процесс принятия решений маршрутизации, однако революционных изменений в этом смысле не произошло, а после после появления аппаратных реализаций коммутационных чипов проблема производительности отошла на второй план. Зато по мере того как стандарт обрастал мышцами, становилось понятно, что применение нескольких меток, названных впоследствии стеком, позволяет взглянуть на MPLS как на технологию с унифицированными методами предоставления и обеспечения сервисов. Так, метки в стеке условно поделили на сервисные и транспортные. Для больших сетей этого оказалось недостаточно и вскоре появилась собственная иерархия транспортных меток. Транзитные маршрутизаторы в общем не обязаны понимать какой именно сервис они передают, их задача в самом общем смысле ограничивается работой с верхней меткой своей иерархии, а что там находится внутри стека совершенно не их забота. Такой подход позволяет транзитным маршруитзаторам передавать трафик сотен тысяч и даже миллионов потоков разных сервисов.

Казалось бы, чего еще желать… правило «разделяй и властвуй» работает безотказно, но вот эффективно разделять как раз не очень то получалось, в том смысле, что трафик хочется балансировать как можно равномернее в рамках ограниченного количества каналов связи силами неторопливых, с точки зрения изменений, аппаратных решений. В статье вы найдете некоторые аспекты разных методов решения этой задачи.
Читать дальше →
Total votes 14: ↑14 and ↓0 +14
Views 9.2K
Comments 1

Container LSP

SENETSY corporate blog System administration *Network technologies *
В первой части статьи я попытался описать возможности некоторых подходов к балансировке трафика в MPLS домене, идея была в том чтобы показать уникальные требования к аппаратной реализации чипа, которые позволяют достигнуть успеха, в том или ином случае. Вторая часть будет посвящена рассказу об относительно свежем драфте [Multi-path Label Switched Paths Signaled Using RSVP-TE] от Kireeti Kompella, и описанию применения его реализации от Juniper к решению некоторых задач.
Читать дальше →
Total votes 8: ↑8 and ↓0 +8
Views 4K
Comments 0

Архитектура сетевого балансировщика нагрузки в Яндекс.Облаке

Яндекс corporate blog High performance *Network technologies *Cloud services

Привет, я Сергей Еланцев, разрабатываю сетевой балансировщик нагрузки в Яндекс.Облаке. Раньше я руководил разработкой L7-балансировщика портала Яндекса — коллеги шутят, что чем бы я ни занимался, получается балансировщик. Я расскажу читателям Хабра, как нужно управлять нагрузкой в облачной платформе, каким мы видим идеальный инструмент достижения этой цели и как движемся к построению этого инструмента.
Читать дальше →
Total votes 47: ↑47 and ↓0 +47
Views 17K
Comments 5

Blackbox-мониторинг в Clos-сетях. Доклад Яндекса

Яндекс corporate blog IT Infrastructure *Network technologies *Network hardware
Топология современных дата-центров и устройства в них уже не позволяют довольствоваться исключительно whitebox-мониторингом. С течением времени понадобился инструмент, который покажет работоспособность конкретных устройств, исходя из реальной ситуации с передачей трафика (dataplane) в любом месте Clos-сети. Несколько недель назад на конференции Next Hop сетевой инженер Яндекса Александр Клименко поделился опытом решения этой проблемы.



— Я работаю в отделе эксплуатации и развития сети Яндекса, и меня иногда заставляют решать какие-то проблемы, вместо того чтобы рисовать на листочках красивые облачка или изобретать светлое будущее. Приходят люди и говорят, что у них что-то не работает. Если это дело мониторить, если наши дежурные инженеры будут видеть, что именно не работает, то мне самому будет легче. Так что эти полчаса будут посвящены мониторингу.
Читать дальше →
Total votes 18: ↑17 and ↓1 +16
Views 3.4K
Comments 0