Какой тип bonding'а выбрать для отказоустойчивой сети?

Question

[cronfy]

Задача: объединить группы серверов на Linux, находящиеся в одном ЦОД, в отказоустойчивую сеть так, чтобы выход из строя любого линка или коммутатора не приводил к потере связности. В качестве бонуса получить увеличение пропускной способности там, где это возможно. У каждого сервера 2 сетевые карты.

Для таких задач в Linux есть bonding. Вот самая полная документация, которую я нашел.

Вопрос: какой режим bonding'а и какую организацию сети между свичами выбрать?

Если следовать документации, то выходит, что для отказоустойчивости подходит только active-backup:

11.2.1 HA Bonding Mode Selection for Multiple Switch Topology

In a topology such as the example above, the active-backup and
broadcast modes are the only useful bonding modes when optimizing for
availability; the other modes require all links to terminate on the
same peer for them to behave rationally.

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

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

  +-------+         +--------------+      +--------------+         +-------+
  | HostA |.........|      Switch1 |......|      Switch3 |.........| HostX |
  +-------+ .     . +--------------+      +--------------+ .     . +-------+
             .   .         .                      .         .   .  
              . .          .                      .          . .   
   bonding     x           .         STP          .           x   bonding
              . .          .                      .          . .  
             .   .         .                      .         .   .  
  +-------+ .     . +--------------+      +--------------+ .     . +-------+
  | HostB |.........|      Switch2 |......|      Switch4 |.........| HostY |
  +-------+         +--------------+      +--------------+         +-------+

Или для этой задачи существует более правильное решение, которое я не увидел?

Answer 1

[alz]

В вашей схеме все зависит от того, как коммутатор отнесется к тому, что один и тот же MAC в его таблице коммутации будет значиться за двумя разными портами. Например, на switch4 MAC HostA будет на портах к Switch1 и Switch3, при условии что STP отключил линк между Switch1 и Switch2

Comments

[cronfy]

Насколько я понял документацию, в режиме balance-alb для каждого слейва используется свой MAC, и драйвер bonding'а применяет магию к arp-запросам, чтобы разным пирам показывать разные MAC и таким образом делать балансировку трафика. То есть, фактически, одни видят наш IP по одному MAC, а другие по другому, а маки между портами не прыгают. И поэтому он «does not require any special switch support». Поправьте меня, если я не прав, пожалуйста.

Answer 2

[tgz]

Если свитчи умеют mLACP, то можно и active/active с линками в разные свитчи.

Comments

[cronfy]

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

Но все-таки хотелось бы понять, будет ли работать приведенная схема с balance-alb, когда свичи вообще ничего не знают про агрегирование. Или у нее есть какие-то подводные камни?

[cronfy]

Просто это был бы идеальный вариант — берешь любые свичи, подключаешь серверы в любые порты, ничего на свичах не настраиваешь, все работает.

[tgz]

Не будет. Свитчи должны обмениваться служебной информацией для этого.

[cronfy]

Если не сложно, можете немного подробнее написать, для чего свичам нужно обмениваться служебной информацией и какой? Буду признателен за ссылку.

[cronfy]

То есть, я опираюсь на следующее:

1. В документации сказано, что balance-alb не требует никакой поддержки на свичах (ни LACP, ни etherchannel, никакой группировки портов, ничего).
2. Судя по описанию balance-alb, чтобы достигнуть поведения, описанного в п. 1, используются разные маки для слейвов и магия с подстановкой мака в пакеты ARP. То есть, для свичей L2 это то же самое, что два разных устройства в сети.
3. Тем не менее, «modes require all links to terminate on the same peer for them to behave rationally», то есть утверждается, что нельзя подключить сервер к разным свичам. Но это противоречит п. 2!

Я, видимо, что-то упускаю, но не понимаю, чего.

[tgz]

Ну как для чего. Падение/появление линков в группе как минимум. От этого зависит хеш, при помощь которого трафик разливается в разные линки.
balance-alb как я понимаю наружу просто разливает по загрузке линков, а внутрь пытается подставлять разные МАС адреса разным пирам. На два разных свитча такое работать не сможет, так как никакой сигнализации тут нет.