Перейти к содержимому
Калькуляторы

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

Коллеги, добрый день. У нас случился инцидент, который навел меня на мысль о необходимости изменений. Вкратце, вылетел 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: куча проблем потенциально

 

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

 

Спасибо

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

flex link

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

я за стэк+lacp.

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

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

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

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 hours ago, catalist said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.