Отказоустойчивое подключение клиента в стойке (ToR)

[dignity]

Коллеги, добрый день. У нас случился инцидент, который навел меня на мысль о необходимости изменений. Вкратце, вылетел ToR свич и, хотя мы его быстро поменяли, остались в SLA, но один клиент решил безмолвно сняться. В связи с данным фактом я начал размышлять как бы для таких товарищей сделать качество повыше (понятно, что это не помешает при другом стечении обстоятельств им так же сняться, но все же). Сейчас серверы подключаются к ToR свичу портом 1G и получают статикой IPv4/IPv6, хотелось бы подключать их к двум ядрам разными ToR свичами, тогда не совсем понятно как наиболее просто обеспечить отказоустойчивость и переключение:

 

в1. дополнительный IP с отдельным шлюзом. Клиент настраивает source routing, переключение по DNS, CDN, etc.

Pros: просто для провайдера

Cons: сложно для клиента, плохой failover

 

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

Pros: все стандартно

Cons: сложно для клиента, непонятно как быть с разными ОС, например, Windows, VmWare ESXi, etc.

 

в3. Стекированный коммутатор, LACP клиенту, VRRP, RSTP

Pros: ?

Cons: куча проблем потенциально

 

Может быть кто-то знает как это делается для недоверенных клиентов? Какая практика на оборудовании, которое поддерживает общие стандарты?

 

Спасибо

[alibek]

А какой был то?

ИМХО до десятки в качестве TOR ничего лучше Cisco 49xx не придумали.

 

Что касается отказоустойчивости, то на каком уровне она нужна, на втором или третьем?

ИМХО в дата-центрах лучше L3, так что третий вариант не подходит, хотя это и прозрачно для клиентов.

[dignity]

5 минут назад, alibek сказал:

А какой был то?

Вот это я не понял... Какой ToR? Разные есть, Extreme x450, Force10 s60, C3560.

 

Нужна такая, чтобы было клиенту просто и провайдеру (нам) не сложно.

[zhenya`]

vrrp / hsrp был бы хорошим выбором, если сервером рулил бы ты  (у bond есть режим active / backup, который допускает включение в разные свитчи) иначе мисконфиг и писец. 

 

стэк похоже твой выбор с flex link. 

[dignity]

8 минут назад, zhenya` сказал:

flex link

А как это решает проблему с выходом из строя ToR, стекированием коммутаторов? Все равно VRRP в ядре придется делать, поскольку ядро тоже на двух рутерах с iBGP.

[zhenya`]

Я поправил прошлое сообщение. flex link на стэке конечно же..

[dignity]

Ясно, вот прям хочется сделать EBGP на фейковых AS, чтобы вообще с L2 не морочиться, но тогда надо прям гайд для настройки выдавать и просто не переведешь с одноногового подключения на двуногое....

[zhenya`]

заставлять клиента поднимать quagga/bird тоже не айс. опять же смена адресов. представляешь сколько боли ?:) тебя пошлют с таким решением. 

[dignity]

ага, типа того))

[catalist]

мы сейчас заканчиваем строительство второго ядра сети в связи с той же целью.

резервирование мы будем делать по технологии backup у цыски.

[dignity]

Видимо, самая простая технология, у Extreme тоже есть аналог, на s400 я пользовался. Да, похоже, что это оно.

[uxcr]

vPC, раз циска?

[catalist]

нет говорю же backup interface

[vurd]

5 минут назад, catalist сказал:

нет говорю же backup interface

Принцип работы? Ссылкой, если можно.

[dignity]

Это тот самы flexlink, он же backup interface, позиционируется как замена stp для листов дерева с полным ручным конфигурированием.

[catalist]

ну да один линк активен если он падает то поднимается запасной автоматом.

[Butch3r]

я за стэк+lacp.

[alibek]

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

Мало ли что он может на своей стороне настроить — в лучшем случае стек развалится, в худшем весь коммутатор штормить начнет.

[Butch3r]

Настраивайте фильтры на абонента и ничего не будет.

[catalist]

8 часов назад, Butch3r сказал:

я за стэк+lacp.

лацп при стеке не млаг называется?

шеститонники можно в стек объединять?

vss не предлагать нет хеппи стори.

а если не шеститонники, то как стек передать на несколько км?

 

8 часов назад, alibek сказал:

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

Мало ли что он может на своей стороне настроить — в лучшем случае стек развалится, в худшем весь коммутатор штормить начнет.

лацп с клиентом это жесть, ведь 95% клиентов не смогут его настроить или не имеют соответствующего оборудования

[zhenya`]

Лацп больше телодвижений требует со стороны клиента, ага. Да и часто число езерченелов на железке не такое большое..

 

Lacp на портах между свитчами в одном стэке кроссстэк называется.

 

[dignity]

Пока что L2 стек + FlexLink к клиенту + FlexLink к двум ядрам + VRRP выглядит лучше всего. Альтернативно смотрю на L3 стек + FlexLink к клиенту + OSPF к двум ядрам.

 

Хочу провести тесты обеих топологий на предмет отказов и выяснить какая будет лучше себя вести на 2 x c3750E-48T.

[zhenya`]

В ядра лучше оспф. Флекслинк в ядро не стоит даже рассматривать..

[catalist]

1 час назад, zhenya` сказал:

Флекслинк в ядро не стоит даже рассматривать..

а че? мы именно так и хотим сделать

[rm_]

3 hours ago, catalist said:

лацп с клиентом это жесть, ведь 95% клиентов не смогут его настроить

Вообще-то из всей той мутной фигни которая здесь перечислена, применительно к линукс-серверу клиента настроить LACP это как раз-таки самое простое.