Comments 5
Спасибо, познавательная статья. Было бы удобно, если бы вы добавили в конец пару ссылок на вендорские материалы, если захочется почитать чего-то еще на эту тему.
Есть неплохая статья на сайте Cisco. Но более глубокая информация была взята из различных презентаций компании Cisco с таких мероприятий, как Cisco Live, Networkers и пр.
>Я даже помню, как приверженцы продукции Cisco мне объясняли, что стекирование – это плохо, и в продакшене данную технологию не стоит использовать. Жаль, уже не помню точных формулировок, но речь шла вроде о стабильности работы.
Ну еще бы. Проблема-то как была, так и осталась, и да, в большинстве реалистичных сценариев стекирование решительно невозможно использовать в продакшне (исключения — либо нулевая критичность сервиса, либо наличие рядом второго стека для резервирования).
А заключается проблема в том, что вы создаете громадную единую точку отказа там, где ее раньше не было. Вы взяли два резервирующих друг друга свитча и превратили их в один свитч с одним control plane. А в control plane в любой момент времени найдется много интереснейших багов. В результате тот несчастный, кто решил объединить важные железки в стек, будет бояться даже смотреть в их сторону, чтобы не попадали разом.
Ходят слухи, что кто-то когда-то слышал о существовании человека, работавшего со стеками и не разу не обжигавшегося на них, но я в такие мифы не верю. Лично меня уже подводили и стеки на 3750, и VSS на 6500. Под «подводили» подразумеваю «без стека сбой либо не произошел бы, либо не оказал бы заметного влияния на сервис».
>Между коммутаторами стека синхронизируются MAC-таблица, а также таблицы Cisco Express Forwarding (CEF), а именно FIB и Adjacency table.
И синхронизации тоже зло, потому что где синхронизации, там и разные любопытные рассинхронизации. Самое надежное решение — самое простое. Например, банальный ECMP роутинг между тупейшими свитчами с централизованным форвардингом. Или что-то вроде TRILL (блин, циска, дай уже FP на каталистах!). Даже STP кольцо лучше стека в плане надежности.
Ну еще бы. Проблема-то как была, так и осталась, и да, в большинстве реалистичных сценариев стекирование решительно невозможно использовать в продакшне (исключения — либо нулевая критичность сервиса, либо наличие рядом второго стека для резервирования).
А заключается проблема в том, что вы создаете громадную единую точку отказа там, где ее раньше не было. Вы взяли два резервирующих друг друга свитча и превратили их в один свитч с одним control plane. А в control plane в любой момент времени найдется много интереснейших багов. В результате тот несчастный, кто решил объединить важные железки в стек, будет бояться даже смотреть в их сторону, чтобы не попадали разом.
Ходят слухи, что кто-то когда-то слышал о существовании человека, работавшего со стеками и не разу не обжигавшегося на них, но я в такие мифы не верю. Лично меня уже подводили и стеки на 3750, и VSS на 6500. Под «подводили» подразумеваю «без стека сбой либо не произошел бы, либо не оказал бы заметного влияния на сервис».
>Между коммутаторами стека синхронизируются MAC-таблица, а также таблицы Cisco Express Forwarding (CEF), а именно FIB и Adjacency table.
И синхронизации тоже зло, потому что где синхронизации, там и разные любопытные рассинхронизации. Самое надежное решение — самое простое. Например, банальный ECMP роутинг между тупейшими свитчами с централизованным форвардингом. Или что-то вроде TRILL (блин, циска, дай уже FP на каталистах!). Даже STP кольцо лучше стека в плане надежности.
Позволю себе чуточку не согласится. На данный момент технологии стекирования достаточно хорошо отработаны. Конечно же, они тоже могут сбоить. Но что не сбоит? У меня как-то четырёхпортовый неуправляемый коммутатор решил, что он «звезда сети», и стал отвечать на все подряд ARP запросы. Поэтому даже если мы разнесём control-plane по разным железкам (например, будем использовать vPC или vPC+), мы всё равно не получаем пилюлю от всех проблем. Тут стоит смотреть больше на то, как часто происходят такие сбои. Лично из своего опыта чаще всего такие стеки (Stackwise и др.) вредничали в основном в моменты обслуживания (например, замены IOS и пр.). При этом большую часть времени никаких претензий к их работе не было.
Безусловно, использовать стекирование в сетях, где требуется минимальное время простоя, не стоит. Для построения таких сетей есть специальные гайды (предлагающие использовать всякие там Nexus’ы, полностью маршрутизируемые сети и пр.), которые выливаются в немаленькие суммы. Но для большинства самых обычных сетей, таких требований нет. При этом цена вопроса является определяющей. И вот тут-то стек, например, на базе 3750X вполне подойдёт.
Что касается вопроса, что лучше: использовать STP или использовать стек. Тут я придерживаюсь второго варианта. Скажем так, дело вкуса. Думаю, обсуждать плюсы/минусы каждого варианта не стоит. Они хорошо известны. Скажу только, что появление технологий стекирования на большинстве коммутаторов наводит на мысль, что второй подход предпочтителен не только для меня.
Безусловно, использовать стекирование в сетях, где требуется минимальное время простоя, не стоит. Для построения таких сетей есть специальные гайды (предлагающие использовать всякие там Nexus’ы, полностью маршрутизируемые сети и пр.), которые выливаются в немаленькие суммы. Но для большинства самых обычных сетей, таких требований нет. При этом цена вопроса является определяющей. И вот тут-то стек, например, на базе 3750X вполне подойдёт.
Что касается вопроса, что лучше: использовать STP или использовать стек. Тут я придерживаюсь второго варианта. Скажем так, дело вкуса. Думаю, обсуждать плюсы/минусы каждого варианта не стоит. Они хорошо известны. Скажу только, что появление технологий стекирования на большинстве коммутаторов наводит на мысль, что второй подход предпочтителен не только для меня.
>На данный момент технологии стекирования достаточно хорошо отработаны.
Это не имеет значения. Софт модульных свитчей тоже хорошо обкатан. И модульный свитч всегда остается единой точкой отказа, даже с двумя супами в SSO, и в нем очень много чего периодически ломается. Стек мало чем принципиально отличается от модульного свитча.
>даже если мы разнесём control-plane по разным железкам (например, будем использовать vPC или vPC+), мы всё равно не получаем пилюлю от всех проблем.
Именно так. vPC жутко уязвим к одинаковым багам одинаковых устройств с одинаковым софтом и одинаковым конфигом. Но это уже шаг в правильную сторону, при правильной топологии одно устройство легко и без влияния на сервис изолируется. Ну и в целом софт NX-OS куда стабильнее IOS.
>Лично из своего опыта чаще всего такие стеки (Stackwise и др.) вредничали в основном в моменты обслуживания
Именно поэтому я и говорю, что администратор будет откладывать кирпичи при одной мысли о каких-то махинациях со стеком. Поведение STP намного предсказуемее — протокол проще, его код по большей части давно отлажен, ничего нового там не происходит. А главное — риски меньше.
Да и вообще говоря большинство багов выстреливает в момент внесения изменения или вскоре после него, остальное — в основном утечки памяти.
> Скажу только, что появление технологий стекирования на большинстве коммутаторов наводит на мысль, что второй подход предпочтителен не только для меня.
Фичи появляются благодаря спросу, циска очень часто реализует хотелки крупных заказчиков. Раньше вы делали обзор OTV. Это — монстр, которого не должно существовать, потому что не должно существовать задачи, которую он решает (L2 между несколькими локациями с большим числом нод на каждой — фу-фу-фу). Но он есть. Кто-то даже пользуется. Зуб даю, что из этих «кто-то» 90% забыли сначала подумать, надо ли оно им вообще, а после внедрения периодически ругаются матом.
Это не имеет значения. Софт модульных свитчей тоже хорошо обкатан. И модульный свитч всегда остается единой точкой отказа, даже с двумя супами в SSO, и в нем очень много чего периодически ломается. Стек мало чем принципиально отличается от модульного свитча.
>даже если мы разнесём control-plane по разным железкам (например, будем использовать vPC или vPC+), мы всё равно не получаем пилюлю от всех проблем.
Именно так. vPC жутко уязвим к одинаковым багам одинаковых устройств с одинаковым софтом и одинаковым конфигом. Но это уже шаг в правильную сторону, при правильной топологии одно устройство легко и без влияния на сервис изолируется. Ну и в целом софт NX-OS куда стабильнее IOS.
>Лично из своего опыта чаще всего такие стеки (Stackwise и др.) вредничали в основном в моменты обслуживания
Именно поэтому я и говорю, что администратор будет откладывать кирпичи при одной мысли о каких-то махинациях со стеком. Поведение STP намного предсказуемее — протокол проще, его код по большей части давно отлажен, ничего нового там не происходит. А главное — риски меньше.
Да и вообще говоря большинство багов выстреливает в момент внесения изменения или вскоре после него, остальное — в основном утечки памяти.
> Скажу только, что появление технологий стекирования на большинстве коммутаторов наводит на мысль, что второй подход предпочтителен не только для меня.
Фичи появляются благодаря спросу, циска очень часто реализует хотелки крупных заказчиков. Раньше вы делали обзор OTV. Это — монстр, которого не должно существовать, потому что не должно существовать задачи, которую он решает (L2 между несколькими локациями с большим числом нод на каждой — фу-фу-фу). Но он есть. Кто-то даже пользуется. Зуб даю, что из этих «кто-то» 90% забыли сначала подумать, надо ли оно им вообще, а после внедрения периодически ругаются матом.
Sign up to leave a comment.
Стекирование коммутаторов Cisco. Часть 1