Нужны ли стекируемые коммутаторы?

Question

[Maksim Herasim]

Доброго дня коллеги!
Возникла такая ситуация.
Есть стойка с оборудованием под виртуализацию. Кластер, все дела. Сервера виртуализацию подключены к схд через оптику brocade тут всё ок. Но внутренняя сеть и интернет получаем по меди. Внутренняя сеть также разбита на vlan. Для подключения всех хостов и доп.оборудования в стойке, использовали стекируемые коммутаторы. Объединили 2 коммутатора в стек, всё успешно настроили и успешно забыли. Сейчас произошла такая проблема, один из коммутаторов вышел из строя. И у нас возникает дилемма, а нужны ли нам стекируемые коммутаторы впринципе или нет?
Схема подключения хостов и схема прихода интернет канала выглядит следующим образом. (простите рисовал на коленке)

Мы используем кластер на базе гипервизора vmware.
Что хотим получить - отказоустойчивость ( в случае выхода одного из коммутаторов, чтобы сеть не легла и все продолжило работать) - сейчас же при выходе одного из коммутаторов всё работает, но готовим резерв. Подскажите best practicts?
С какими подводными камнями можем столкнуться, если заменим на нестекируемые коммутаторы ?

Comments

[Valentin Barbolin]

Поэтому cisco ушла от stack, слишком уж непредсказуемо ведут себя коммутаторы при выходе одного из строя.

Смотрите в сторону MLAG или vPC.

Answer 1

[Strabbo]

В вашем случае всё зависит от системы виртуализации, например ESXI сам всё разнесет по портам так что лупа не будет. Так что вы можете даже подключить ваши свичи друг к другу и петли не будет. Но в таком случае усложниться управление- вместо одного стека будете управлять несколькими свичами по отдельности. При добавлении коммутаторов опять таки без стека надо будет много конфигить. Без стека может усложниться подключение к провайдеру и к остальной сети(если она существует).

P.S. Best Practice зависит от многого, так что тут не можеть быть конкретного ответа, многое зависит от разных факторов.

Comments

[Strabbo]

Добавлю. Если у вас возникли сомнения и вы не знаете что вам нужно сейчас, то я бы взял на вашем месте Cisco Catalyst 9k, которые умеют работать в виртулаьном стеке без специальных стек портов. Хотите используйте как обычные свичи, а когда передумаете переделаете в стек. Не обязателньо брать Cisco, можно поискать других вендоров с похожим функционалом. у Cisco это Virtual Stackwise, У Juniper это Virtual chassis.

P.S. А вообще я бы смотрел на те железки, которые преднозначены для работы в DC. Cisco Nexus/Juniper QFX. Они решат любые ваши проблемы

[Валентин]

ESXI сам всё разнесет по портам так что лупа не будет.

А по какой технологии? LAG?

[Strabbo]

Валентин, Насколько я помню это не LAG, у него порты в standalone , которые находятся в одном виртуальном свиче + mac pining, он конкретные маки по конкретным портам разносит.

A DVS and/or VSS-switches offers multiple load-balancing options: by default load balancing based on Virtual Port id (sometimes called Source-MAC pinning) is being used on the VSS and DVS.

Не нашел официального документа, но эта фича работает по дефолту.
тык

Answer 2

[ky0]

Если у вас в серверы приходит по несколько линков от разных устройств, объединённых в агрегированный канал - и в случае выхода из строя одного из свитчей вы не хотите, чтобы это развалилось, очевидно, вам нужно, чтобы свитчи как-то между собой этот вопрос могли разрулить.

Comments

[Maksim Herasim]

Представим, что мы не агрегируем каналы, и каждый линк на хосте - независим. Собственно да, это очевидно . Со стеком коммутаторов они сами согласуют это, в случае же если мы используем не стек, какие варианты этого согласования? Очевидно также, что будут подводные камни, вопрос, какие ? И как все таки будет оптимальнее (правильнее) реализовать схему. Если стекируемые, почему?

[ky0]

Maksim Herasim, предположим, что у вас один линк - основной, а второй резервный. Как хост поймёт, что основной линк стал неработоспособен (если, например, у первого свитча сгорит порт с аплинком)? Нужны какие-то проверки, автоматическое перестроение маршрутизации и т.д.