Как вы убеждаете руководство, что 3560/3750 - плохая идея в вашем округе?

3560/3750 имеют небольшие буферы и делают хорошие коммутаторы шкафа проводки. Однако я очень часто вижу эти переключатели, сидящие в DC. Многие люди склонны использовать их, поскольку они, как правило, способны на 1 Гб и L3.

Есть ли способ доказать, насколько они плохи в развертывании DC? Я часто слышу, как люди говорят, что они сняли свои 3750-е как можно скорее, но мне еще не приходилось слышать реальный сценарий сбоя, который можно было бы использовать, чтобы руководство узнало, чтобы вытащить их.

FWIW У меня был опыт работы с 3750 (3750G, а затем и 3750E / 3560E) в масштабе в настройке TOR; сначала с L2 port-channel / GLBP (варианты 2x1G и 2x2G и редкие 2x4G для стоек дб), а затем с L3 до TOR (пошло с этим для 3750E / 3560E и 10G до ядра). Я говорю о тысячах из них. Мы видели проблемы только с буферами для сервисов с наибольшей пропускной способностью, и в тот момент мы все равно смотрели на 10G на хост (и плотные коробки для пиццы с 24-48 SFP +).

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

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

Все остальные, которые опубликовали ответ на этот вопрос, довольно хорошо обрисовали «проблемные области» платформы 3750: режимы стекирования и странных отказов, присущие ей, размеры буферов и т. Д. Есть также этот вопрос, который описывает проблемы со сбором статистики SNMP при отбрасывании очереди вывода. - буферы распределяются между ASIC, поэтому любая статистика, которую вы получите с помощью SNMP, будет одинаковой для определенных диапазонов портов (это может быть одним из препятствий, которые вы могли бы затронуть в своей цепочке управления).

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

Это действительно зависит от вашего сценария развертывания. 3560/3750 - отличные коммутаторы, имеют достойные буферы, и они обычно работают нормально для большинства приложений. Если ваш центр обработки данных видит потоки трафика, которые требуют больших буферов, вы должны иметь возможность получать статистику от коммутаторов, например, использование буфера и отбрасывание пакетов. Убедить руководство отбросить коммутаторы, которые отбрасывают их пакеты, не должно быть слишком большой проблемой. Я думаю.

В первые дни 3750, особенно технологии стекирования, которая была выпущена до 2010 года или около того, было много проблем со сбоями коммутатора, которые приводили к отказу стека не так грациозно. В сочетании с тем фактом, что обновление стека было не самым интуитивно понятным процессом (с тех пор он улучшился), 3750 действительно получил плохую репутацию, которая с тех пор застряла.

В небольших центрах обработки данных стек 3750 представляет собой относительно недорогой вариант получения плотности портов без затрат на коммутатор на основе шасси. Я сам только что установил для небольшого клиента решение для центра обработки данных, включающее несколько серверов Cisco UCS C220 M3 с Netapp FAS2240, и я использовал стек из 3750 для обеспечения многоканального резервирования Ethernet на каждом новом устройстве, а также на всех его старых серверах. во время перехода. Это сработало очень хорошо.

Итак, у 3750 есть проблемы? Вероятно, так же, как и любой другой переключатель, который был вокруг в течение столь длительного времени. У 6500 были свои проблемы на ранних этапах жизненного цикла, и теперь, когда он вышел годами, он не так уж и плох. Я рекомендую взглянуть на то, что вы собираетесь использовать, и, если показатели производительности сохранятся, убедитесь, что вы внимательно следите за их производительностью.

Честно говоря, самый распространенный способ, которым я видел 3750-х, - это когда основные коммутаторы были обновлены до Nexus 7k. Обычно (но не всегда) частью этого обновления является перемещение TOR на Nexus 2000 FEX или Nexus 5000.

Хотя у 3750 нет самых больших буферов, по мнению большинства людей, они работают «достаточно хорошо» в большинстве корпоративных сред постоянного тока.

Если вы не сможете оценить долларовую стоимость проблем, вызванных наличием 3560-х / 3750-х в DC, я сомневаюсь, что вы сможете убедить руководство заменить их вне обычного цикла обновления продукта.

@mellowd, безусловно, прав, эти коммутаторы не очень удобны в использовании, поскольку из-за очень ограниченного количества буферов они могут микроборозить и отбрасывать трафик.

Предположим, у вас есть 2 * 1GE вход и 1 * 1GE выход. В худшем случае выходной порт начинает сбрасываться после одновременной отправки входных портов в течение 2 мс. В лучшем случае, вы можете справиться с 8 мс.

У вас есть 2 МБ выходного буфера на 4 порта, поэтому 2 МБ / (1 Гбит / с) = 16 мс максимум и 16/4 = 4 мс минимум. Разделите это число на количество входящих портов, которые хотите отправить, и вы получите количество времени, которое вы можете обработать. То есть, чем больше входных портов (серверов) вы добавляете, тем меньше микропроцессоров вы можете обрабатывать.

Если вы должны жить с 3750/3560, вы должны прочитать этот документ, чтобы максимизировать использование буфера. И если вы все еще отказываетесь, используйте LACP на выходе, даже если ваши графики показывают, что средний выходной спрос очень низок.

Чтобы доказать своим менеджерам, что буферов недостаточно, монитор / касание / расширение вашей текущей сети переключает все нисходящие линии связи, тогда у вас будут временные метки и размеры пакетов, которые будут выходить, и вы можете рассчитать, сколько на 1 Гбит / с ваше мгновенное требование и сколько буфер вам нужно будет справиться с этим.

Производительность, безусловно, важная проблема, и она хорошо рассмотрена выше, но есть также много различий, основанных на функциях и наборах функций:

1. Потребность во внешних блоках RPS является огромной проблемой во многих установках - коммутатор 1U становится более дорогим с точки зрения первоначальных затрат, потерянного пространства и постоянного управления. Резервная мощность должна считаться абсолютной необходимостью во всех средах, кроме самых маленьких.

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

3. Функции DC (ISSU, DCB, хранилище, некоторые встроенные скриптовые элементы) отсутствуют и не будут присутствовать на устройствах, ориентированных на кампус. Механизмы для управления и масштабирования расширения L2 также нормальным образом (например, FabricPath / TRILL, OTV, VXLAN и т. Д.) Также, как правило, отсутствуют как в текущем состоянии, так и в дорожных картах за пределами продуктов DC. Список здесь будет только расти - встроенная виртуализация, поддержка HW-вспомогательных механизмов и т. Д.

4. Масштабируемость - Как вы развиваете инфраструктуру? Много и много переключателей (дорого управлять)? Укладка (сложная эксплуатация, основные проблемы с кабелями) - беспорядок. Кроме того, гибкость типов интерфейса (например, волокно или медь) при плотности может быть сложной задачей.

В целом различия между постоянным током и переключением между шкафами растут. В мире Cisco существуют отличные операционные системы (NXOS против IOS) по очень веским причинам - очень разные требования приводят к различным решениям. Функция скорости для механизмов аутентификации пользователя (802.1x) или необычная интеграция AV не требуются в центре обработки данных, в то время как в терминале проводов не требуется возможность терминировать тонны 10GE. Разные инструменты для разных работ. Коробка Nexus, соединяющая рабочие столы, также была бы не идеальным планом.

Я бы также указал вам на различные руководства по проектированию (CVD и т. Д.), В которых изложено обоснование типов коммутаторов, используемых в различных точках сети. Есть что-то, что можно сказать о решениях, которые в целом напоминают лучшую общепринятую практику в отрасли, и упомянутые коммутаторы, как правило, не имеют места в DC - кроме сетей управления или некоторых особых случаев локального подключения.

У меня есть клиент, который развернул их как стек коммутаторов SAN (с использованием 3750X) с SAN, подключенным на 10 Гбит, а затем их хосты ESX, подключенные на Гбит (или несколько Гбит с использованием LAG), и количество падений на выходе является астрономическим независимо от того, как вы пытаетесь настроить буферы.

У того же клиента есть два других стека 3750 в одном DC для других сетей, и все они чистые.

TL; DR: Это действительно зависит от типа трафика, который вы собираетесь проходить через стек, и от того, где находятся ваши узкие места.

Блоки питания / вентиляторы в пределах 3560/3750 не поддерживают горячую замену / после того, как коммутатор смонтирован, и происходит неизбежный сбой этих устройств, все серверы должны быть отключены от 3560/3750, пока он отключен и заменен на RMA.

Кроме того, направление вентилятора на 3560-х / 3750-х годах становится проблемой с горячим проходом / холодным проходом и другими настройками охлаждения. Установка коммутаторов там, где порты коммутаторов обращены к задней части серверов, создает ситуацию, когда вентиляторы коммутатора вращаются в неправильном направлении. Это перегревает коммутатор, что повышает вероятность его отказа / необходимости замены.