[alger]

Приветствую.

Подскажите какой вариант лучше выбрать при планировании сети в ДЦ, без привязки к конкретному вендору.

Планируется размещение порядка 320 серверов, соответственно сеть не большая.
Вариант 1: упрощенная трехзвенная L2 архитектура, только Core & Access. Все просто и понятно. Коммутаторы парами объединены в виртуальный стэк, линки объединены в LAG. Core на 2*32 порта, используются только по 20 портов, что оставляет существенный запас по расширению.

Вариант 2: Spine/Leaf. Коммутаторы не стэкируются. Из минусов схема существенно сложнее в реализации поддержке т.к. используется VXLAN, да и дороже если VXLAN по доп.лицезии. Из плюсов вижу легкое обслуживание любого коммутатора.

Т.к. кол-во серверов небольшое, и существенного расширения не предвидится, необходимости в внедрении второго варианта не вижу. Может я что-то упустил ?

Edited March 17, 2023 by alger

[alger]

Кстати, всегда считал что коммутация быстрее маршрутизации.
А сейчас, некоторые заявляют, что многие L3 коммутаторы имеют оптимизацию, и маршрутизация не уступает. А как же упаковать/распаковать в VXLAN, это же тоже время занимает ?

[jffulcrum]

VXLAN - это просто еще один заголовок разобрать. На современном железе оверхед надо еще поискать в электронный микроскоп. 

 

320 - это железа в стойках, или виртуалок будет?

[alger]

320 физических серверов.

[jffulcrum]

Ключевой вопрос - если это сдача в аренду, то клиенты захотят QinQ. И в первом варианте это все просто и отработано, и разруливается даже на Access, второй, с трансляциями из Dot1q в VXLAN - сложнее, и потребует либо DCB на Access, либо софтсвитчей на самих серверах. и если для vStack/Openstack это решаемо колхозом, а для VmWare - за деньги, то c Hyper-V или Nutanix можно попасть в область неизвестного. 

[Saab95]

У вас каждый сервер будет подключаться к двум разным устройствам для резервирования?

 

Ставите везде L3 коммутаторы / роутеры, навешиваете IP адреса какие нужно, поверх всего можно OSPF запустить и будет все отлично работать, схема простая.

[alger]

Сервера на vSphera, и все резервирование линков средствами Distributed Switch. Но я не про то как это сделать. Тут, вроде, все понятно.
Я про то в чем целесообразность использования архитектуры Spine/Leaf для сетей среднего размера?

Логически я понимаю, что все зависит от планируемого трафика. Но кто же знает заранее какой он может быть ?
Если теоретически считать что на серверах 10Г порты будут утилизироваться хотя бы на 80%, то с коммутатора на 48 портов 10Г, один аплинк на 100Г это мало, получается надо 4*100Г.
Раз у меня на access 8 пар коммутаторов, то надо 16*4=64 порта на ядро. В варианте 1 это сложно реализуемо, т.к. у некоторых вендоров бывают отграничения в два коммутатора в стэке.
Если рассматривать вариант 1, с ядром в два коммутатора по 32 порта на 100Г, отнять по 4 порта на объединение самого ядра, то остается по 28 портов, значит можно подключить 7 пар коммутаторов access. 7 по 48 это 336 пар портов 10Г. Но надо еще учитывать что куда-то придется подключать другие устройства (маршрутизаторы, провайдеров, L2 линки и пр.) Вообще, под это в идеале выделить отдельную пару коммутаторов а-ля бордеры.
Получается что  предел это 6 пар коммутаторов доступа, что позволяет подключить 6*48=288 серверов максимум. В противном случае надо будет добавлять еще один уровень - агрегацию.
Хотя.. где вы видели чтобы на коммутаторе все порты доступа были в загрузке 80% одновременно ?

С вариантом 2 и его горизонтальном расширением также не все просто, если исходить из утилизации портов в 80%, то скорее всего без Super Spine не обойтись.

 

Так в чем смысл тогда в Spine/Leaf ?
 

Edited March 19, 2023 by alger

[Saab95]

Если уйдете от коммутаторов и примените маршрутизаторы схема сильно упрощается.

[fractal]

5 часов назад, Saab95 сказал:

Если уйдете от коммутаторов и примените маршрутизаторы схема сильно упрощается.

Возможно хотели сказать примените маршрутизацию? в уровне ЦОД маршрутизаторы живут в виде border bgp для связи с внешним миром или fusion, а большая часть коммутаторов уровня ЦОД и коммутирует и маршрутизирует на уровне порта

[Saab95]

При коммутации нужно сначала собрать все порты (а это +цена оборудования), потом подать на маршрутизаторы (+ это тоже цена оборудования), дальше маршрутизаторы каким-то образом подключить к внешним каналам.

 

Если коммутаторы исключить из схемы, а установив только маршрутизаторы и сразу к ним подключать сервера. То маршрутизаторы уже можно соединить через коммутаторы для обмена информацией между собой (это дополнительно даст резервирование), и туда же внешние каналы.

 

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

 

И вот вместо первых коммутаторов и установить маршрутизаторы сразу.

[sirmax]

18 часов назад, fractal сказал:

Возможно хотели сказать примените маршрутизацию? в уровне ЦОД маршрутизаторы живут в виде border bgp для связи с внешним миром или fusion, а большая часть коммутаторов уровня ЦОД и коммутирует и маршрутизирует на уровне порта

Я не то что бы сильно понимаю, но в опенстек клиенты часто хотят l2 (c тем что бы пихать туда свои вланы) между инстансами. Как это решать кроме опенфлоу я не знаю. Но в целом опыт с такими дц у меня ограниченный 

[alger]

Не пойму как тут цитировать, не работает у меня ни "цитата" ни "Ответить с цитированием"

Saab95 видимо вы не понимаете задачи. У меня физ.сервера, на которых крутятся виртуальные под vSphere, следовательно мне надо подать несколько vlan. Сделать это на маршрутизаторе сложнее чем на коммутаторе. К тому же, порт маршрутизатора в разы дороже коммутатора. Да и вопрос был не в выборе оборудования, а про технологию Spine/Leaf.

[fractal]

19 часов назад, Saab95 сказал:

При коммутации нужно сначала собрать все порты (а это +цена оборудования), потом подать на маршрутизаторы (+ это тоже цена оборудования), дальше маршрутизаторы каким-то образом подключить к внешним каналам.

 

Если коммутаторы исключить из схемы, а установив только маршрутизаторы и сразу к ним подключать сервера. То маршрутизаторы уже можно соединить через коммутаторы для обмена информацией между собой (это дополнительно даст резервирование), и туда же внешние каналы.

 

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

 

И вот вместо первых коммутаторов и установить 

 где Вы видели маршрутизатор на 48 портов для целей цод? Там маршрутизор нужен для выхода наружу, для интерконнекта с другими цод

[sirmax]

12 часов назад, alger сказал:

Saab95 видимо вы не понимаете задачи

Он наркоман и его наркотик - микротик 😉 

все что нельзя или неудобно делать на микротиках - « не нужно» 

(я тоже не против микротика но дц не его ниша, может пока не его) 

[fractal]

2 часа назад, sirmax сказал:

Он наркоман и его наркотик - микротик 😉 

все что нельзя или неудобно делать на микротиках - « не нужно» 

(я тоже не против микротика но дц не его ниша, может пока не его) 

И не будет, для цод нужны коммутаторы с низким уровнем задержки и большим буфером, с неблокируемой матрицей и способные роутить/форвардить на уровне порта

 

В 19.03.2023 в 14:42, alger сказал:

Сервера на vSphera, и все резервирование линков средствами Distributed Switch. Но я не про то как это сделать. Тут, вроде, все понятно.
Я про то в чем целесообразность использования архитектуры Spine/Leaf для сетей среднего размера?

Логически я понимаю, что все зависит от планируемого трафика. Но кто же знает заранее какой он может быть ?
Если теоретически считать что на серверах 10Г порты будут утилизироваться хотя бы на 80%, то с коммутатора на 48 портов 10Г, один аплинк на 100Г это мало, получается надо 4*100Г.
Раз у меня на access 8 пар коммутаторов, то надо 16*4=64 порта на ядро. В варианте 1 это сложно реализуемо, т.к. у некоторых вендоров бывают отграничения в два коммутатора в стэке.
Если рассматривать вариант 1, с ядром в два коммутатора по 32 порта на 100Г, отнять по 4 порта на объединение самого ядра, то остается по 28 портов, значит можно подключить 7 пар коммутаторов access. 7 по 48 это 336 пар портов 10Г. Но надо еще учитывать что куда-то придется подключать другие устройства (маршрутизаторы, провайдеров, L2 линки и пр.) Вообще, под это в идеале выделить отдельную пару коммутаторов а-ля бордеры.
Получается что  предел это 6 пар коммутаторов доступа, что позволяет подключить 6*48=288 серверов максимум. В противном случае надо будет добавлять еще один уровень - агрегацию.
Хотя.. где вы видели чтобы на коммутаторе все порты доступа были в загрузке 80% одновременно ?

С вариантом 2 и его горизонтальном расширением также не все просто, если исходить из утилизации портов в 80%, то скорее всего без Super Spine не обойтись.

 

Так в чем смысл тогда в Spine/Leaf ?
 

Мы в основном юзаем spine/leaf архитектуру, два спайна и куча лифов, лифов с восходящими 100g и судя по цод где я был, аналогично построено

[Victor Tkachenko]

@alger действительно, маршрутизация на современных L3-коммутаторах реализована на уровне ASIC, соответственно работает на скорости портов и не вносит существенных задержек (они на уровне десятков-сотен наносекунд).

 

В сегменте коммутаторов с желаемыми портовыми конфигурациями почти все сейчас поддерживают EVPN/VXLAN, их даже больше, чем таких же коммутаторов с поддержкой стекирования.

В среднем с финансовой точки зрения не будет существенной разницы какой из вариантов вы выберете.

 

При этом, конечно, следует использовать тот подход, в котором у вашей команды уже есть опыт, вам же это обслуживать.

Лично с моей точки зрения, первую схему со стекированием следует использовать исключительно в случаях с L2 каналами. Если планируется внедрение L3 в дальнейшем, не стоит использовать стекирование. В конце концов вы и сами отметили, что обслуживание во втором сценарии будет проще - не нужно мучаться с нюансами реализации стека при обновлении ПО или замене/добавлении коммутатора.

 

Второй вариант перспективнее по ряду причин:

1) без проблем сможете внедрить L3VPN

2) проще добавлять и менять коммутаторы в фабрике даже при снятии с продаж уже используемых моделей

3) диагностика проблем в сети хоть и требует большей экспертизы (добавляется underlay маршрутизация и overlay, например, с сигнализацией EVPN), но доступнее, так как используются "стандартные" технологии

[jffulcrum]

Есть, однако, нюансы:

 

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

5) Имеется единый центр управления, позволяющий окирпичить сеть одним движением, обнулить все коробки разом, в результате человеческой ошибки или внешнего воздействия.

[alger]

Victor Tkachenko
 

Цитата

В среднем с финансовой точки зрения не будет существенной разницы какой из вариантов вы выберете

VXLAN обычно это отдельна лицензия за не малые деньги.
 

Цитата

без проблем сможете внедрить L3VPN

Я не провайдер чтобы мне внедрять L3VPN. Если же речь о VXLAN, то в любом случае надо добавить еще один уровень, типа Edge и на них уже поднимать VXLAN. По тем же лицензиям получится дешевле чем для всех устройств приобретать.


fractal 

Цитата

Мы в основном юзаем spine/leaf архитектуру, два спайна и куча лифов, лифов с восходящими 100g и судя по цод где я был, аналогично построено

Так можете объяснить в чем плюс spine/leaf ? При наличии всего двух spine, я вообще не вижу выгоды.

 

Кто-нибуль может мне объяснить как цитирование использовать ?
Нажимаю кнопку ответить с цитированием и ничего не происходит.

Edited March 23, 2023 by alger

[jffulcrum]

@alger Внизу смените тему на Default

[alger]

2 часа назад, jffulcrum сказал:

@alger Внизу смените тему на Default

Огромное спасибо !

 

В 22.03.2023 в 09:59, Victor Tkachenko сказал:

Лично с моей точки зрения, первую схему со стекированием следует использовать исключительно в случаях с L2 каналами. Если планируется внедрение L3 в дальнейшем, не стоит использовать стекирование.

Вопрос бы не про стэкирование. Это может быть тот же MLAG.
Вопрос именно в чем плюс Spine/Leaf решения, перед L2. И на него пока никто не ответил. 

[fractal]

7 часов назад, alger сказал:

Так можете объяснить в чем плюс spine/leaf ? При наличии всего двух spine, я вообще не вижу выгоды.

Дальнейшее масштабирование, уход от STP, количество хопов и задержка меньше (плюс для сетей критичных к задержкам), но я вижу плюсы только при использовании маршрутизируемой архитектуры, то есть фабрика работающая в режиме L3

[alger]

53 минуты назад, fractal сказал:

Дальнейшее масштабирование, уход от STP, количество хопов и задержка меньше (плюс для сетей критичных к задержкам), но я вижу плюсы только при использовании маршрутизируемой архитектуры, то есть фабрика работающая в режиме L3

Это стандартные фразы, которые я уже слышал от коллег. Но среди моих коллег никто не смог аргументировано доказать что L3 лучше.

• Маштабирование: можно пример? Конечно если вы не Яндекс, и у вас до тысячи физ.серверов. 
  При L2 такое же маштабирование. Не хватит двух коммутаторов на ядро, добавьте уровень агрегации, классическая Tier-3 архитектура, а это тоже самое что super-spine в L3 варианте. При добавлении другого ДЦ с VXLAN его можно на Core подключить, сэкономив на лицензиях VXLAN, ведь их надо будет всего две. А лучше добавить два маршрутизатора как Egde. Это будет правильно и при L3 и при L2 сети.
• STP, и так ненужно, нет дублирующих линков, все в LAG (см.схему выше)
• Задержка.. даже если на коммутаторе есть L3 оптимизация, на микросекунды но при L3 будет больше, тот же VXLAN запаковать/распаковать занимает время. Пусть не большое, но время!

В чем я ошибаюсь ?

[fractal]

1 час назад, alger сказал:

Это стандартные фразы, которые я уже слышал от коллег. Но среди моих коллег никто не смог аргументировано доказать что L3 лучше.

У каждого своя правда, а нас aci, намного лучше чем ранее была схема legacy, я много работал с legacy, для меня эти стандартные фразы решили много проблем с откликом в фин секторе (биржа) 

 

1 час назад, alger сказал:

Пусть не большое, но время!

На бирже, нано решает, лишний хоп потеря бабла

 

1 час назад, alger сказал:

STP, и так ненужно, нет дублирующих линков, все в LAG (см.схему выше)

И прям отключаете? 

 

1 час назад, alger сказал:

•  

В чем я ошибаюсь ?

Ни в чем, если не можете для себя определить что лучше, то наверное сидеть на том что для Вас удобно и все

[Saab95]

Цитата

Но среди моих коллег никто не смог аргументировано доказать что L3 лучше.

Лучше тем, что можно перенаправлять трафик куда угодно уже с первого устройства, куда подключен сервер.

 

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

 

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

 

Опять же вы можете все маршрутизаторы соединить через коммутаторы полной звездой и еще уменьшить задержку, повысив отказоустойчивость, т.к. можете что угодно обновлять, перезагружать, отключать, на пропуск трафика это не будет влиять (максимум скорость упадет, задержка увеличится).

[alger]

12 часов назад, Saab95 сказал:

Лучше тем, что можно перенаправлять трафик куда угодно уже с первого устройства, куда подключен сервер.

 

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

 

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

Не понимаю с чего вы решили "что можно перенаправлять трафик куда угодно уже с первого устройства".

Обратите внимание на схему коммутации выше. Между коммутаторами доступа/leaf, в которые подключены сервера, нет прямого линка. Поэтому в обоих схемах весь траффик идет через вышестоящий коммутатор core/spine. Соответственно, если сервер и хранилка подключены на разные коммутаторы, то не важно L2 у вас или L3, связь пойдет через вышестоящий core/spine. 
В случае с хранилкой, в схеме L2, её правильнее подключить на Core, и тогда она будет более в выигрышном положении, т.к. путь от сервера до неё будет короче.
В схеме же L3 она должна быть подключена на leaf,  т.к. иначе на spine придется поднимать vtep, а это не правильно.

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

 

15 часов назад, fractal сказал:

На бирже, нано решает, лишний хоп потеря бабла

Ну, так тогда вы теряете "бабло", ведь L3 медленнее !

Edited March 24, 2023 by alger