Как стать автором
Обновить

Комментарии 15

Я не знаю, кто эту статью писал, но этот человек явно далёк от того, о чём пишет.

Причина: скорость схождения stp важна не для «то важно если на виртуальных машинах работают критически-важные приложения с максимальными требованиями к доступности», а потому, что внутри этой сети ходит трафик к хранилищам, и эти несколько секунд могут привести либо к slow start у TCP, либо к фиксации потери пакета, либо, что самое страшное, к фиксации ошибки операции с диском, транслирующимся в виртуалку, после чего виртуалка сваливает свою ФС в ридонли.

Как бы пишется о хорошей, наверное, вещи, но совершенно не о том и не по сути проблемы.
Не понятна ваша претензия.
Вы просто описываете, что может произойти при медленном схождении.
А в самом блоге говорится, что это негативно влияет на виртуальные машины.
Претензия в том, что пишите не понимая. Вот, например, вопрос, если мы по такой сетке NFS будем юзать, эти секунды схождения будут важны или нет? И если да, то почему?
Если честно, я не помню что такое NFS…

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

Поэтому, это все, на мой взгляд, абсолютно не важно, я думаю не стоит уходить в сторону от обсуждаемого вопроса стекирования IRF. Так как в действительности существует огромная масса существующих протоколов и сетевых приложений, к одним из них в силу специфики их работы важна скорость сходимости, к другим, напротив, не важна.

Главное, что раз требования бизнеса современных ЦОД ставят задачи по быстрой сходимости, значит их необходимо решать.

Хотя… Если предположить, что NFS это Network File System – сетевой протокол доступа к файлам в UNIX системах…

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

Второй важный момент — отсутствие вендор лока, то есть отсутствие зависимости от железа конкретного производителя. Разорилась циска? Поставили экстримы без изменения конфигурации и без ситуации, «шеф, всё пропало». Сломался экстрим — поставили HP. Не понравились условия HP — поставили ещё кого-то. Возможность заменить одного вендора на другого — важнейший фактор, определяющий гибкость получившегося решения.
Думаю, фраза «разорилась циска» в этом топике и блоге будет воспринята на ура. :)
э… с учётом, что пишу о вреде вендор лока — общий комментарий им скорее не понравится, потому что то, что они предлагают — это вендор лок на их коммутаторы. Сплошные проприентарные стандарты, которые должны заменить плохие, но таки стандарты (STP).
сроке нет. Cisco уважаемая компания имеющая долю рынка и исторически автор многих фундаментальных разработок.
… и конкурент HP…
в чём?
Сейчас особенно в сетевом сегменте.

Затем Cisco выходила на рынок серверного оборудования, и по услугам есть общие рынки.
ну это как обычно — все компании где-то да пересекаются… какие-то решения удачны, какие-то среднего уровня…
прошу читать «скорее нет» ( автомат правописания, чтоб ему)
Стандартный протокол Spanning Tree (синонимы 802.1D, STP..) служит для того, чтобы на канальном уровне между группой коммутаторов или мостов образовался однозначный путь для пересылки пользовательских пакетов без зацикливаний.

Причем особенность протокола состоит в том, что пока однозначная топология не образовалась т.е. сходимость не наступила – трафик между коммутаторами не передается.

Протокол сходится очень продолжительное время – несколько десятков секунд без применения RSTP и несколько секунд в случае его применения, что для множества современных сетевых приложений просто неприемлимо, для них это фактически отказ в обслуживании. И эти приложения, зачастую, являются еще и бизнес критичными, то есть их остановка даже на непродолжительное время может привести к финансовым потерям в бизнесе, недополучении прибыли, отрицательно сказаться на имидже компании предоставляющая услуги через свою сетевую инфраструктуру.

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

Отдельно хотелось бы сказать о проприетарности протокола IRF.

Тут стоит начать именно с того, что пояснить в двух словах “как оно работает?”

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

Что будет если мы будем объединять коммутаторы в стек по технологии IRF?

Ответ – наша топология существенно упростится, так как благодаря IRF многие элементы сети состоящие из нескольких физических устройств превратятся в элементы из одного логического устройства. При этом все двойные резервные подключения превратятся в линки точка-точка аггрегированные при помощи стандартного протокола 802.3ad, при этом побочным явлением возникает тот факт, что в такой новой топологии исчезает возможность зацикливания, таким образом протокол Spanning Tree больше не нужен!

Физические же коммутаторы объединенные в стек, при этом работают как одно модульное устройство. Функции IRF при этом можно представить как функции обмена link-state информацией между членами стека, похожими на процедуры программирования интеллектуальных линейных карт управляющим модулем или синхронизации управляющей информации между активным и резервным управляющим модулем в модульных коммутаторах. При этом, совершенно естественно, что скорее всего такой протокол не будет стандартным. Так как маловероятно, что шассийные коммутаторы когда нибудь будет возможно набивать линейными картами различных вендоров.
дополню немножко:
муви:http://www.youtube.com/watch?v=J1s_9i0hdJI
Зарегистрируйтесь на Хабре, чтобы оставить комментарий