[Из песочницы] Динамическое перенаправление сетевого трафика13.01.2017 08:04

Речь в статье пойдет о том, как организовать возможность динамического переключения между сетевыми интерфейсами.

Корни вопроса начали расти из предыдущего проекта socmetr.ru, где понадобилось собирать большой объем информации из социальных сетей, и таким образом забивая единственный канал с интернетом. Анализ показал, что даже при наличии сжатия, объем поступающей информации так велик, что происходит его блокировка, при этом мощности CPU и Memory не задействованы и на 20%, а дисковая подсистема почти все время простаивает, то есть мы упёрлись в ширину канала, которую нам предоставляет провайдер.

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

Настройка сервера

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

    A1 это первый сетевой интерфейс, A2 — второй… AN — поcледний
    IP1 это IP-адрес связанный с сетевым интерфейсом A1, IP2 — адрес связанный с A2… IPN — адрес связанный c AN
    GW1 это IP-адрес шлюза провайдера P1 (Provider 1), GW2 — адрес шлюза провайдера P2… GWN — адрес шлюза PN
    GW1_NET это IP-адрес сети провайдера P1, GW2_NET IP-адрес сети провайдера P2… GWN_NET IP-адрес сети провайдера PN

Тогда настройку можно осуществить следующим образом:

Создаем N-таблиц маршрутизации (где N - это количество подведенных каналов с интернетом)
  ip route add {GW1_NET} dev {A1} src {IP1} table T1
  ip route add default via {GW1} table T1
  ...
  ip route add {GWn_NET} dev {An} src {IPn} table Tn
  ip route add default via {GWn} table Tn

Описываем маршруты в основной таблице маршрутизации:
  ip route add {GW1_NET} dev {A1} src {IP1}
  ...
  ip route add {GWn_NET} dev {An} src {IPn}
  ip route add default via {GW1}

Описываем правила:
  ip rule add from {IP1} table T1
  ...
  ip rule add from {IPn} table Tn 

И дело в шляпе, получаем конфигурацию, которая гарантирует что все запросы к конкретному интерфейсу получат от него ответ.

Использование

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

socket.bind(new InetSocketAddress(InetAddress.getByName("network-adapter"), port));

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

Плюсы:

• возможность гибкого масштабирования интернет-канала (мы получаем возможность в любой момент нарастить или уменьшить общий интернет канал, как за счёт подключения новых провайдеров, так и за счет увеличения полосы пропускания текущих, появляется возможность планировать и прогнозировать его мощность)
• возможность управления нагрузкой, каждого из них
• возможность использования любого канала или их последовательности в любой момент времени любой подсистемой

Минусы:

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

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

Комментарии (10)

• zoonman

  12 января 2017 в 19:32

  +2

  ↑

  ↓

  В вашем решении отсутствует балансировка и обработка отказов провайдеров.
  

  • blutovi

    12 января 2017 в 22:14

    0

    ↑

    ↓

    Что есть то есть, как сделать балансировку подсказал yosemity
    А с обработкой отказов — мы держим один канал всегда свободным, на тот случай если один из провайдеров откажет, это конечно не спасет если резервный канал тоже будет не доступным, но вероятность события значительно меньше.

• 0×18h

  12 января 2017 в 19:44

  +2

  ↑

  ↓

  А почему на картинке Интернет ни к чему не подключен?

  • blutovi

    12 января 2017 в 22:15

    0

    ↑

    ↓

    Я все таки надеюсь, вы догадались что связь с интернетом всё таки нужна? (Улыбка)

• yosemity

  12 января 2017 в 21:20 (комментарий был изменён)

  +1

  ↑

  ↓

  Хм. http://www.opennet.ru/docs/RUS/LARTC/x348.html

  • blutovi

    12 января 2017 в 22:02

    0

    ↑

    ↓

    Похоже в сообщество надо было обращаться значительно раньше, а то мы себе мозги над стандартными вещами съели) (вот оригинал указанной ссылки http://lartc.org/howto/lartc.rpdb.multiple-links.html)

    • yosemity

      12 января 2017 в 23:44

      0

      ↑

      ↓

      Ну если честно, вы тут абзац из «букваря» описали. Особенно забавляют плюсы и минусы. Например, минус работы через нескольких провайдеров — необходимость нескольких провайдеров.

      • blutovi

        13 января 2017 в 07:34

        0

        ↑

        ↓

        Например, минус работы через нескольких провайдеров — необходимость нескольких провайдеров.

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

        Возможно требуется пояснение:
        «Чтобы в принципе иметь возможность реализовать данную схему, необходимо наличие нескольких независимых провайдеров, а поскольку это не везде достижимо, то и не везде применимо».
        

• sergeysakirkin

  13 января 2017 в 03:06

  0

  ↑

  ↓

  Вопрос, зачем, есть стандартные решения балансировки трафика в BGP например:
  http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13762–40.html
  

  • blutovi

    13 января 2017 в 07:48

    0

    ↑

    ↓

    Знание — сила!