FastNetMon

понедельник, 24 ноября 2014 г.

Обработка и фильтрация 80GE трафика на дешевом железе

Итак, стоит хитрая задача - имеется бордер-роутер Juniper MX 240, на который неким образом подведено несколько сотен гигабит интернета через несколько аплинков. 

Стоить задача обсчитать 80GE из этого трафика и пропустить его к клиентам имея лишь 4 сервера (будем звать их фильтр-1/2/3/4 соответственно) с двумя 10GE картами (20GE на 1 сервер). За фильтр серверами стоит один диапазон /24. При этом, трафик даже на 1 IP (/32) должен распределяться по ВСЕМ машинам фильтрам.

Как это реализовать?

Очевидно, входящий трафик должен разделять исключительно роутер, поэтому мы должны выдать каждому фильтр-серверу отдельный IP и создать 4 идентичных правила роутинга по аналогии с Linux:
ip route add 31.xx.xx.xx/24 via 10.10.10.101
ip route add 31.xx.xx.xx/24 via 10.10.10.102
ip route add 31.xx.xx.xx/24 via 10.10.10.103
ip route add 31.xx.xx.xx/24 via 10.10.10.104
Но Juniper тут себя поведет не особо предсказуемо - он будет лить трафик только в один из путей, так как он устроен так :) Но это поведение легко поменять! С помощью директивы - load-balance per-packet которая активирует равномерное распределение трафика по всем путям. Таким образом, все фильтр серверы начнут получать одинаковый объем трафика.

А далее фильтр-серверы передают трафик клиентам через обычные правила роутинга (они должны быть в том же vlan).

Но как сделать чтобы трафик исходящий также балансировался? Тут нам поможет Линукс! А именно вот этот гайд - http://lartc.org/howto/lartc.rpdb.multiple-links.html Схема простая - машина должна получить все 4 фильтр-сервера как дефалт гейтвеи с идентичным weight. Тогда и исходящий трафик размажется пропорционально.

Также полагаю хорошим вариантом решения проблемы был бы MLAG, но с ним могут возникнуть проблемы.

11 комментариев :

  1. 1. Если один из серверов 1/2/3/4 ложится - трафик сам размажется между 3-мя серверами?
    2. Какие проблемы с MLAG?

    ОтветитьУдалить
    Ответы
    1. 1. Не думаю, надо поидее делать мониторинг самому и оперативно вычищать руками померший бэкэнд. Но можно сделать OSPM/iBGP, чтобы в случае отвала одной из машин трафик на нее идти переставал
      2. Я с ним не работал на таком уровне, чтобы понимать, как поведет себя MLAG будучи скрещенным с LACP/BOND на Linux.

      Удалить
    2. 1. Ок. Это ж сколько пакетов убьется если делать мониторинг самому. И тоже много убъется через OSPF и BGP.
      2. А что тут понимается под MLAG-ом?

      Удалить
    3. 1.Тут, увы, ничего не поделать. Но в принципе, если будет фильтроваться tcp, то потерю одного пакета - он отлично переживет.
      2. Multi-Chassis Link Aggregation Group

      Если хочется надежность, можно каждую из логических фильтр-машин представить как кластер из пары машинок с VRRP/keepalived, но они тоже не мгновенные.

      Я думаю правильнее было бы разбрасывать пакеты на уровне Ethernet, в принципе можно взять обычный статический LACP/BOND и воткнуть как клиента не 1 машину, а 4. Но тут тоже будут проблемы, если оно отвалится. В статическом режиме уже никто не скажет, как отвалилось и что.

      Удалить
  2. Hi Pavel,

    Spasibo za ochen interesnyi blog :) Potratil kak minimum paru chasov chitaya vashi statji.

    Just my 2c: Per flow load-balancing is not a Juniper's specific, but general best practice. Per-packet load-balancing is not recommended because it will result in packets being re-ordered on a receiving end (Internet clients), decreasing TCP performance as a result!

    P.S. Had a lot of bad experience with keepalived :)

    ОтветитьУдалить
    Ответы
    1. Hi Igro,

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

      Удалить
  3. Sorry for language, doesn't have proper keyboard and transliteration looks ugly.

    This is an experience that comes from operating multiple DC's across the globe. Majority of our clients are connecting from mobile/home networks. The assumption about performance is based on the fact that if the particular flow is going, for example, to Asia from North America, than overall latency that client experiences (if per-packet load-blancing is used) is equal to the latency of the slowest ISP that is not well peered in the region, thus passing through multiple AS's and possibly via sub-optimal paths.
    NY-Chicago-LA-Europe-Aisa is one of the examples.

    Obviously, increased latency will affect bandwidth-delay product.
    http://en.wikipedia.org/wiki/Bandwidth-delay_product

    Cheers!

    ОтветитьУдалить
    Ответы
    1. То есть я правильно Вас понял - реордеринг не при чем?
      При чем только то, что latency больше через некоторых провайдеров?

      Удалить
    2. Da, re-ordering is just a symptom.

      Удалить
    3. https://www.idc-online.com/technical_references/pdfs/data_communications/Recovery%20of%20loss.pdf

      "Packet reordering is generally attributed to transient conditions, pathological behavior and erroneous implementation."

      Удалить
    4. Спасибо за ссылку - ознакомлюсь.
      Также еще в исходники TCP загляну - интересно стало.
      Вот не встречал я в современном TCP плохого поведения из-за packet reordering.

      Удалить

Примечание. Отправлять комментарии могут только участники этого блога.