Як ви переконуєте керівництво в тому, що 3560/3750-ті - це погана ідея у вашому DC?

3560/3750 мають невеликі буфери і добре спрацьовують шафи-вимикачі. Однак я дуже часто бачу ці комутатори, що сидять в постійних токах. Багато людей, як правило, використовують їх, оскільки вони, як правило, здатні 1 Гбіт та L3.

Чи є спосіб довести, наскільки вони погані в розгортанні постійного струму? Я досить часто чую, як люди говорять про те, що вони усунули свої 3750, як тільки могли, але я ще не почув фактичний сценарій відмов, який міг би бути використаний, щоб повідомити керівництву, щоб їх вийти.

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

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

Керівництво хоче бачити дані , і якщо у вас немає ресурсів для повного тестування вікна (придумайте план тестування, підключіть його до деякого обладнання для генерації трафіку, повністю розгорніть його і напружте тест на специфікацію проекту, тощо) це буде важко зробити. Вони не будуть вражені анекдотичними доказами, і знайти подібні важкі дані може виявитись важким, оскільки я впевнений, що люди, що публікують подібні речі, порушували б усі види NDA.

Усі інші, хто опублікував відповідь на це, досить добре окреслили "проблемні області" платформи 3750: складання та дивні режими відмови, притаманні їй, розміри буфера тощо. Існує також це питання, яке окреслює проблеми зі збиранням статистики SNMP щодо крапель вихідної черги - буфери поділяються по всіх ASIC, тому будь-яка статистика, отримана за допомогою SNMP, буде однаковою для певних діапазонів портів (це може бути однією точкою стикання, яку ви можете підключити до ланцюга управління).

Підводячи підсумок, я б сказав, що 3750/3560 був «чудовим» для більшості розгорнень, навіть у дещо великих масштабах. Якщо не можете укладати їх, то я б сказав, що це не дуже жахливо, щоб зробити це в дуже малих та керованих кількостях.

Це дійсно залежить від сценарію розгортання. 3560/3750 - це чудові комутатори, мають гідні буфери, і вони, як правило, добре працюють для більшості застосунків. Якщо у вашому центрі обробки даних бачать потоки трафіку, які потребують більших буферів, ви повинні мати можливість виводити статистику з комутаторів, як використання буфера та краплі пакетів. Переконання керівництва відмовитися від перемикачів, які скидають свої пакети, не повинно бути занадто складним завданням. Я думаю.

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

У невеликих центрах обробки даних стек 3750 являє собою відносно недорогий варіант отримати щільність портів без вартості комутатора на базі шасі. Я сам щойно встановив для меншого клієнта рішення центру обробки даних, що включає декілька серверів Cisco UCS C220 M3 з Netapp FAS2240, і я використав стек 3750-х, щоб забезпечити надмірність ефірного каналу з декількома шасі для кожного нового пристрою, а також усіх їх старих серверів під час переходу. Це спрацювало дуже, дуже добре.

Отже - чи має 3750 проблеми? Напевно, такий самий, як і будь-який інший перемикач, який існував так довго. У 6500 виникли проблеми на ранніх етапах її життєвого циклу, а тепер, коли він минув роками та роками, це не так вже й погано. Рекомендую подивитися, що ви збираєтеся кинути на це, і якщо показники ефективності підтримуються, то переконайтесь, що ви стежите за їхньою ефективністю.

Чесно кажучи, найпоширенішим способом, який я бачив, як ударив 3750 у бордюр, було, коли основні комутатори були модернізовані до Nexus 7k. Зазвичай (але не завжди) частиною цього оновлення є переміщення TOR до Nexus 2000 FEXs або Nexus 5000s.

Незважаючи на те, що в 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. Функції постійного струму (ISSU, DCB, сховище, певні скриптові елементи сценарію) не є - і не будуть - на орієнтованих на кампусі пристроях. Механізми управління та масштабування розширення L2 також розумним способом (тобто FabricPath / TRILL, OTV, VXLAN тощо) також, як правило, відсутні як у теперішньому стані, так і в дорожніх картах поза продуктами постійного струму. Список буде лише зростати - віртуалізація, підтримка механізмів допомоги HW тощо.

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

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

Я також хотів би вказати на різні керівництва по дизайну (CVD тощо), які викладають обґрунтування для типів комутаторів, що використовуються в різних точках мережі. Щось можна сказати для рішень, які, як правило, нагадують найкращу загальну практику в галузі, а комутатори, про які ви згадуєте, як правило, не мають місця в постійному струмі - окрім мереж управління або певних ситуацій локального підключення.

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

У того ж замовника є два інших 3750 стека в тому ж постійному струмі для інших мереж, і всі вони чисті.

TL; DR: Це дійсно залежить від типу трафіку, який ви збираєтеся прокладати через стек, та де ваші вузькі місця.

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

Також напрямок вентилятора на 3560-х / 3750-х роках стає проблемою з проходом / холодним проходом та іншими налаштуваннями охолодження. Встановлення вимикачів, коли порти комутаторів стикаються з тильною стороною серверів, створює ситуацію, коли вентилятори комутаторів дмуть у неправильному напрямку. Це перегріває перемикач, що робить більш ймовірним вихід з ладу / необхідність його заміни.