Комментарии 30
Первая треть статьи про пользу открытых решений, последняя про рекламу проприетарного решения. Мое личное мнение, что SDN нужны не пользователям, а производителям сетевого оборудования. Например, IOS для Cisco 2651XM весил около 20 мегабайт и умел, в принципе, все необходимое для построения сети любого масштаба. Сейчас IOS для Cisco ASR 1000-й серии весит около 300 мегабайт. Этот сколько нужно индусов поддерживать такой код и писать что-то новое? А с SDN все просто: оставим, кто поумнее, писать код контроллера, остальных разгоним, коммутаторы станут набором микросхем, что спокойно можно делать на заводах КНР и все, проблема решена, жизнь с начала, смотрите как здорово.
Первая треть статьи про пользу открытых решений, последняя про рекламу проприетарного решения.Последняя часть статьи про рекламу НЕ проприетарного решения: — «В основе решения HP – открытая и стандартизированная архитектура HP FlexNetwork»
А с SDN все просто: оставим, кто поумнее, писать код контроллера, остальных разгонимКроме контроллера нужно еще писать приложения, т.ч. места всем хватит.
Сейчас IOS для Cisco ASR 1000-й серии весит около 300 мегабайт.
А внутре него
Да, я знаю. А так же меня бесит вывод "show platform health", из которого, по моему мнению, стало трудно что-то понять о том, что же нагружает процессор в данный момент.
НЛО прилетело и опубликовало эту надпись здесь
Ну можно начать с того, что ASR1k умеет, мягко говоря, побольше, чем 2651. Хотя если ограничивать свой объем знаний о возможностях железок официальными курсами — тогда да, они примерно равны :) Ну и да, IOS-XE устроен иначе по сравнению с классическим IOS.
Еще можно заметить, что ASR1k — аппаратная платформа (control plane и data plane реализованы разными чипами) с навороченным сетевым процессором, соответственно — радикально меняется подход к траблшутингу (в сторону усложнения этого дела). К примеру, если железка теряет часть проходящих через нее пакетов, то смотреть «show proc cpu» обычно бесполезно. Пакеты передает совершенно другое железо.
Еще можно заметить, что ASR1k — аппаратная платформа (control plane и data plane реализованы разными чипами) с навороченным сетевым процессором, соответственно — радикально меняется подход к траблшутингу (в сторону усложнения этого дела). К примеру, если железка теряет часть проходящих через нее пакетов, то смотреть «show proc cpu» обычно бесполезно. Пакеты передает совершенно другое железо.
Текст писал маркетолог HP: «HP упрощает архитектуру сети с трёхуровневой (характерной для традиционных сетевых архитектур Cisco) », ага. Cisco FabricPath, 2012 год, архитектура ЦОД уже давно не трехуровневая, STP никто подавно не использует. HP, мягко говоря, в своих предпосылках немного отстала.
Тем не менее, в «живых» DC проектах Cisco довольно часто предлагает именно трехуровневую архитектуру — ToR (N2K) — EoR (N6K) — Core (N7K). Автор, судя по всему, руководствуется практикой.
В живых проектах Cisco предлагает полносвязную пару Aggregation-Access, при том ставить туда 6к или 7к — зависит исключительно от нагрузок. Best Practice для ЦОД у них как раз полносвязный по L3 Core — Aggregation на N7K от которых вниз до Access полносвязный VPC/FP. Это практика. Cisco уже давно идет в сторону отказа от классической трехуровневой модели. Даже по Campus Network уже развивается в направление спуска сервисов ядра до клиентских портов — 6800ia (Instant Access) в связке c 6500. Так что HP не новатор, а уж на практике — тем более. И я не защищаю Cisco, просто немного странно приводить такой подход, как великую новацию в сетевой архитектуре.
Все верно, но access зачастую 2х уровневый — N2K рабочая лошадка. А по поводу рекламы, так это общий подход — сравнивать то, что предлагает вендор сейчас с тем что стоит у клиента сейчас (т.е. было у конкурента несколько лет назад).
>но access зачастую 2х уровневый — N2K рабочая лошадка
С какого перепуга вы выносите обычную (пусть и необычно выглядящую — болтающуюся на оптическом патч-корде) линейную карту на отдельный уровень? Давайте так же поступим с вашими модульными свитчами. А если мы так делать не станем — получим ту же самую двухуровневую leaf-spine архитектуру с чем-то TRILL-образным посередине.
И нет, N2K не рабочая лошадка. Он тупее большинства линейных карт.
С какого перепуга вы выносите обычную (пусть и необычно выглядящую — болтающуюся на оптическом патч-корде) линейную карту на отдельный уровень? Давайте так же поступим с вашими модульными свитчами. А если мы так делать не станем — получим ту же самую двухуровневую leaf-spine архитектуру с чем-то TRILL-образным посередине.
И нет, N2K не рабочая лошадка. Он тупее большинства линейных карт.
И нет, N2K не рабочая лошадка.Лошадка в том смысле, что в каждом первом проекте вы ее найдете :)
С какого перепуга вы выносите обычную (пусть и необычно выглядящую — болтающуюся на оптическом патч-корде) линейную карту на отдельный уровень? Давайте так же поступим с вашими модульными свитчами.Да можно и так, тогда получится, сравнение 4х уровневой архитектуры (N2K-N6K-модульный_N7K) и 3х уровневой от HP.
«Да можно и так, тогда получится, сравнение 4х уровневой архитектуры (N2K-N6K-модульный_N7K) и 3х уровневой от HP.»
Но проблема: это будет очередной лживый маркетинг, напрочь оторванный от реальности :) Реальность — что уровень определяется по control plane платформы. Иначе придется вникнуть в архитектуру железок и добавить еще кучу уровней. К примеру, единый ASR9K можно было бы объявить трехуровневой железкой, карта-фабрика-карта (любые транзитные пакеты, даже между соседними портами, всегда ходят через фабрику).
Но проблема: это будет очередной лживый маркетинг, напрочь оторванный от реальности :) Реальность — что уровень определяется по control plane платформы. Иначе придется вникнуть в архитектуру железок и добавить еще кучу уровней. К примеру, единый ASR9K можно было бы объявить трехуровневой железкой, карта-фабрика-карта (любые транзитные пакеты, даже между соседними портами, всегда ходят через фабрику).
Реальность — что уровень определяется по control plane платформы.Что же тогда получается, что есть Fabric Extender, что нет — разницы никакой? А то, что наш кадр вместо локальной коммутации сходит в «голову», а потом вернется обратно через оптическую веревку это совсем не учитываем? От понимания того факта, что в «голове» он тоже сходит через фабрику задержки меньше не станут и легче никому не станет.
Иначе придется вникнуть в архитектуру железок и добавить еще кучу уровней. К примеру, единый ASR9K можно было бы объявить трехуровневой железкой, карта-фабрика-карта (любые транзитные пакеты, даже между соседними портами, всегда ходят через фабрику).Ну так в чем проблема, можно и так считать
>А то, что наш кадр вместо локальной коммутации сходит в «голову», а потом вернется обратно через оптическую веревку это совсем не учитываем? От понимания того факта, что в «голове» он тоже сходит через фабрику задержки меньше не станут и легче никому не станет.
Но ведь надо понимать, что везде разные требования. Увеличение задержки там меньше микросекунды, и я не знаком ни с одной инфраструктурой, которая это заметит. Где заметят — просто не ставят фексы и вообще берут специализированные low-latency свитчи с задержкой в пару сотен наносекунд.
А дальше начинаются сплошные преимущества. Вот вам например с какой платформой приятнее работать — с распределенной (где линейные карты самостоятельно принимают решение о форвардинге) или с централизованной (единая группа чипов обрабатывает весь трафик)? Что проще траблшутить? Я вот предпочитаю централизованные во всех случаях, когда они не упрутся по емкости. Снижение вероятности появления багов, связанных с рассинхронизацией форвардеров, единые счетчики, единое место откуда брать трафик для анализа, простота с QoS в рамках всей платформы с возможностью гарантировать 0 потерь внутри железки (миссия невыполнима на платформах с egress forwarding, а с egress forwarding надо много костылей) и т.д.
>Ну так в чем проблема, можно и так считать
А можно считать, что крокодил — это летающий холодильник. Или же просто не искажать смысл общепринятых понятий.
Но ведь надо понимать, что везде разные требования. Увеличение задержки там меньше микросекунды, и я не знаком ни с одной инфраструктурой, которая это заметит. Где заметят — просто не ставят фексы и вообще берут специализированные low-latency свитчи с задержкой в пару сотен наносекунд.
А дальше начинаются сплошные преимущества. Вот вам например с какой платформой приятнее работать — с распределенной (где линейные карты самостоятельно принимают решение о форвардинге) или с централизованной (единая группа чипов обрабатывает весь трафик)? Что проще траблшутить? Я вот предпочитаю централизованные во всех случаях, когда они не упрутся по емкости. Снижение вероятности появления багов, связанных с рассинхронизацией форвардеров, единые счетчики, единое место откуда брать трафик для анализа, простота с QoS в рамках всей платформы с возможностью гарантировать 0 потерь внутри железки (миссия невыполнима на платформах с egress forwarding, а с egress forwarding надо много костылей) и т.д.
>Ну так в чем проблема, можно и так считать
А можно считать, что крокодил — это летающий холодильник. Или же просто не искажать смысл общепринятых понятий.
Ну N2K — это же extender и без «папиного» N5K в общем-то не нужен. Ну да, вместе с «отцом» образуют Access, только он не двухровневый, а просто с выносными модулями (дабы портовую емкость «размазать» по ЦОДу). Они там даже SFP-сборки копеечные под эти связки выпускают. Насчет рекламы уверенно спорить не буду, но мне показалось, что технология претендует на новаторство, коего, как оказалось, здесь нет :)
«Например, по данным одного из опросов, 67% заказчиков считают, что проприетарных продуктов по возможности следует избегать, 32% допускают их использование. Лишь 1% респондентов уверены, что проприетарные продукты и средства обеспечивают лучшую интеграцию и совместимость, чем стандартные. То есть в теории большинство заказчиков предпочитает основанные на стандартах решения, но предлагаются в основном проприетарные сетевые продукты.»
Вы полностью переврали результаты опроса.
Переведу более правильно. 100% опрошенных допускают использование проприетарных продуктов. Из них 67% постараются перейти на открытые стандарты по мере возможности, 32% открытость/закрытость по барабану.
Ах да, проприетарные фичи поначалу всегда опережают стандартные. Просто потому что разработка стандарта требует кучи времени на согласования с другими представителями индустрии. А кастомные (своими силами реализованные под себя) фичи опережают проприетарные, но мало кто может себе это позволить.
«HP разработаны и активно развиваются фирменные технологии эффективного объединения географически распределенных ЦОД в единую L2 сеть.»
Когда весь мир уже отказывается от этого безумия, HP начинает его рекламировать :)
Кстати, EVI разве не проприетарщина? Какое существующее в природе оборудование других вендоров может его терминировать?
Вы полностью переврали результаты опроса.
Переведу более правильно. 100% опрошенных допускают использование проприетарных продуктов. Из них 67% постараются перейти на открытые стандарты по мере возможности, 32% открытость/закрытость по барабану.
Ах да, проприетарные фичи поначалу всегда опережают стандартные. Просто потому что разработка стандарта требует кучи времени на согласования с другими представителями индустрии. А кастомные (своими силами реализованные под себя) фичи опережают проприетарные, но мало кто может себе это позволить.
«HP разработаны и активно развиваются фирменные технологии эффективного объединения географически распределенных ЦОД в единую L2 сеть.»
Когда весь мир уже отказывается от этого безумия, HP начинает его рекламировать :)
Кстати, EVI разве не проприетарщина? Какое существующее в природе оборудование других вендоров может его терминировать?
Когда весь мир уже отказывается от этого безумия, HP начинает его рекламировать :)Кто отказался? Зачем же тогда все ведущие вендоры продолжают «рекламировать» решения этого класса? Вот вам тема доклада с коннекта: — «Построение катастрофоустойчивыхи распределённых ЦОД (часть 2). Объединение сетей ЦОД на 2 уровне».
>Зачем же тогда все ведущие вендоры продолжают «рекламировать» решения этого класса?
Обычно следует оговорка «лучше так не делать». У вас такой оговорки не вижу.
Например:
www.cisco.com/c/en/us/products/collateral/data-center-virtualization/data-center-interconnect/white_paper_c11_493718.html#wp9000089
«Cisco recommends isolating and reducing Layer 2 networks to their smallest scope, usually limiting them to the access layer. Layer 2 connectivity is required for server-to-server communication, high-availability clusters, networking, and security.
However, in some situations, Layer 2 must be extended beyond the single data center. Specifically, this happens when the framework or scenario developed for a campus has been extended beyond its original geographic area, and is now spread over multiple data centers and across long distances.»
Или, если более коротко, «лучше никогда так не делайте, но если ваши архитекторы — идиоты, то вот вам сравнительно работающее решение».
Ну и всё-таки — какое не принадлежащее HP оборудование поддерживает EVI? Или разговоры про открытые стандарты — фикция?
Обычно следует оговорка «лучше так не делать». У вас такой оговорки не вижу.
Например:
www.cisco.com/c/en/us/products/collateral/data-center-virtualization/data-center-interconnect/white_paper_c11_493718.html#wp9000089
«Cisco recommends isolating and reducing Layer 2 networks to their smallest scope, usually limiting them to the access layer. Layer 2 connectivity is required for server-to-server communication, high-availability clusters, networking, and security.
However, in some situations, Layer 2 must be extended beyond the single data center. Specifically, this happens when the framework or scenario developed for a campus has been extended beyond its original geographic area, and is now spread over multiple data centers and across long distances.»
Или, если более коротко, «лучше никогда так не делайте, но если ваши архитекторы — идиоты, то вот вам сравнительно работающее решение».
Ну и всё-таки — какое не принадлежащее HP оборудование поддерживает EVI? Или разговоры про открытые стандарты — фикция?
Вот тут вполне четко написано:
However, in some situations, Layer 2 must be extended beyond the single data center.Про архитекторов в приведенном абзаце нет ни слова. Кейсы от заказчиков есть, поверьте на слово :)
>Про архитекторов в приведенном абзаце нет ни слова. Кейсы от заказчиков есть, поверьте на слово
Про архитекторов сказано в фразе «when the framework or scenario developed for a campus has been extended beyond its original geographic area». Что кейсы есть — верю, принцип 95% никто не отменял :) Конечно же на первый взгляд вколотить костыль проще, чем собрать встречу с заказчиком L2 DCI и убедиться, что он сам не понимает смысла этого решения.
>Придерживаясь принципов открытости и совместимости сейчас HP реализует в своих продуктах VXLAN, все отличие в инкапсуляции (UDP вместо GRE), остальной функционал будет точь-в-точь как на EVI. Причем VXLAN в HP реализован с IS-IS control plane.
Ну ок, тогда цискин OTV предельно открыт. IS-IS на control plane. На data plane совершенно стандартный EoMPLSoGREoIP.
Про архитекторов сказано в фразе «when the framework or scenario developed for a campus has been extended beyond its original geographic area». Что кейсы есть — верю, принцип 95% никто не отменял :) Конечно же на первый взгляд вколотить костыль проще, чем собрать встречу с заказчиком L2 DCI и убедиться, что он сам не понимает смысла этого решения.
>Придерживаясь принципов открытости и совместимости сейчас HP реализует в своих продуктах VXLAN, все отличие в инкапсуляции (UDP вместо GRE), остальной функционал будет точь-в-точь как на EVI. Причем VXLAN в HP реализован с IS-IS control plane.
Ну ок, тогда цискин OTV предельно открыт. IS-IS на control plane. На data plane совершенно стандартный EoMPLSoGREoIP.
Конечно же на первый взгляд вколотить костыль проще, чем собрать встречу с заказчиком L2 DCI и убедиться, что он сам не понимает смысла этого решения.Еще бывают случаи, когда L2 растягивают между залами одного ЦОД. Совсем недавно работал с таким запросом. Ну и я себе не представляю насколько нужно переоценить себя, чтобы назвать проектировщиков этого ЦОД «архитекторами — идиотами», ибо люди вменяемые и уважаемые, да и интегратор уверенно входит в ТОП-10.
Ну ок, тогда цискин OTV предельно открыт. IS-IS на control plane. На data plane совершенно стандартный EoMPLSoGREoIP.Тогда встречный вопрос — вы сможете что-нибудь кроме циски подключить к OTV сети? VXLAN туннель между HP и не HP построить можно.
>Еще бывают случаи, когда L2 растягивают между залами одного ЦОД.
Всегда возникают вопросы вида «зачем?» («какая задача требует этого?»). Но в такой ситуации можно и без лишних оверлеев обойтись. Или наоборот — делать оверлеи на уровне гипервизора, а под ним — исключительно L3.
>ибо люди вменяемые и уважаемые, да и интегратор уверенно входит в ТОП-10.
Я с разными интеграторами работал. Единственный вменяемый (где сотрудники знают свое дело) не входит в топ-10, и вообще они сотрудничали с нами не по моему направлению. К топовым интеграторам претензии выражаются словами «бездарные, некомпетентные раз****яи». Доходило до того, что человек по невежеству рушит систему и первым делом идет удалять логи (в тот раз его поймали за руку, собственные инженеры чуть раньше открыли те же логи). Ситуация понятна — в стране давно и прочно кризис, интеграторы страдают сильнее всех, нечем платить грамотным людям.
Есть кстати крупные, уважаемые, транснациональные компании, которые внедряли подход «follow the sun» — в целях экономии энергии ресурсы постоянно переносятся между ЦОДами, гаснут там, где наступает ночь, поднимаются там, где день. Переносятся нередко vmotion'ами. Разумеется, все очень быстро отказались от этой идеи. Но кто-то ведь ее придумал, внедрял даже…
>вы сможете что-нибудь кроме циски подключить к OTV сети? VXLAN туннель между HP и не HP построить можно.
А про какую такую надстройку с IS-IS над VXLAN шла речь? Она ведь тоже не совсем стандартная?
Всегда возникают вопросы вида «зачем?» («какая задача требует этого?»). Но в такой ситуации можно и без лишних оверлеев обойтись. Или наоборот — делать оверлеи на уровне гипервизора, а под ним — исключительно L3.
>ибо люди вменяемые и уважаемые, да и интегратор уверенно входит в ТОП-10.
Я с разными интеграторами работал. Единственный вменяемый (где сотрудники знают свое дело) не входит в топ-10, и вообще они сотрудничали с нами не по моему направлению. К топовым интеграторам претензии выражаются словами «бездарные, некомпетентные раз****яи». Доходило до того, что человек по невежеству рушит систему и первым делом идет удалять логи (в тот раз его поймали за руку, собственные инженеры чуть раньше открыли те же логи). Ситуация понятна — в стране давно и прочно кризис, интеграторы страдают сильнее всех, нечем платить грамотным людям.
Есть кстати крупные, уважаемые, транснациональные компании, которые внедряли подход «follow the sun» — в целях экономии энергии ресурсы постоянно переносятся между ЦОДами, гаснут там, где наступает ночь, поднимаются там, где день. Переносятся нередко vmotion'ами. Разумеется, все очень быстро отказались от этой идеи. Но кто-то ведь ее придумал, внедрял даже…
>вы сможете что-нибудь кроме циски подключить к OTV сети? VXLAN туннель между HP и не HP построить можно.
А про какую такую надстройку с IS-IS над VXLAN шла речь? Она ведь тоже не совсем стандартная?
А про какую такую надстройку с IS-IS над VXLAN шла речь? Она ведь тоже не совсем стандартная?На HP ее можно отключить, а на Cisco можно отключить IS-IS?
Отключить IS-IS на VXLAN? Серьезно? Что-то я не встречал упоминаний данного протокола в RFC7348, ну а решения, где наворотили отдельных протоколов над VXLAN, не называются VXLAN, у них иные названия. Да, многие цискины платформы умеют и бриджинг, и роутинг VXLAN в соответствии со стандартом.
Вообще, у вас какие-то проблемы с пониманием сарказма, например во фразе «цискин OTV предельно открыт. IS-IS на control plane. На data plane совершенно стандартный EoMPLSoGREoIP» :) Это был пример, показывающий, что самодельная сборка открытых протоколов ни разу не обязана сама быть открытой и стандартной, просто вендорам удобнее задействовать те инкапсуляции и те протоколы, которые уже известны железу. Заканчивайте назвать такие сборки открытыми, это очередная ложь.
Вообще, у вас какие-то проблемы с пониманием сарказма, например во фразе «цискин OTV предельно открыт. IS-IS на control plane. На data plane совершенно стандартный EoMPLSoGREoIP» :) Это был пример, показывающий, что самодельная сборка открытых протоколов ни разу не обязана сама быть открытой и стандартной, просто вендорам удобнее задействовать те инкапсуляции и те протоколы, которые уже известны железу. Заканчивайте назвать такие сборки открытыми, это очередная ложь.
Ну и всё-таки — какое не принадлежащее HP оборудование поддерживает EVI? Или разговоры про открытые стандарты — фикция?EVI технология проприетарная, никто не крывает, в статье это указано: —
HP разработаны и активно развиваются фирменные технологии...Придерживаясь принципов открытости и совместимости сейчас HP реализует в своих продуктах VXLAN, все отличие в инкапсуляции (UDP вместо GRE), остальной функционал будет точь-в-точь как на EVI. Причем VXLAN в HP реализован с IS-IS control plane.
чувствую, опять поднимается старая тема — L2 DCI или не L2 DCI :)
уважаемый JDima, мир он цветной, а не черно белый и обзывать идиотами всех, кому L2 DCI удобен/привычен/подходит под задачи и т.д., как минимум, по моему скромному мнению, некорректно :)
уважаемый JDima, мир он цветной, а не черно белый и обзывать идиотами всех, кому L2 DCI удобен/привычен/подходит под задачи и т.д., как минимум, по моему скромному мнению, некорректно :)
Руководствуюсь опытом отбивания запросов «дай L2 между ЦОДами». Такие запросы до сих пор периодически приходят. Каждый случай индивидуально рассматривается, и всегда оказывается, что если выкинуть «L2» из списка допустимых вариантов, то какой-то из оставшихся подходов обязательно окажется со всех сторон лучше — проще, надежнее, безопаснее, дешевле.
Но конечно же проще не пытаться включить мозг, а просто растянуть решение, нормально работающее в пределах стойки, на полстраны. А потом удивляться возникающим проблемам.
Но конечно же проще не пытаться включить мозг, а просто растянуть решение, нормально работающее в пределах стойки, на полстраны. А потом удивляться возникающим проблемам.
Ну-ну-ну, мы когда в свое время на EMC VNX хотели отказоустойчивые сайты при помощи VPLEX развернуть там как бы основным условием было (тогда по-крайней мере) прямая FC видимость стораджей, ибо там синхронная репликация (active-active резервирование таки), синхронизация состояний и еще тонна каких-то условий. И как вариант (помимо прямых волокон) рассматривался metro L2 чтобы по FCoE гонять все эти радости. Сейчас, конечно, все немного поменялось (в т.ч. по бизнес-требованиям), но осадочек остался.
Конечно, всегда есть выбор. Если смертельно ненавидеть L2, то с позиции, «все что угодно, только не L2 DCI», почти всегда можно придумать выход и сделать как-то без L2.
Мой опыт говорит, что L2 в ряде случаев оказывается самым простым и надежным вариантом, а все остальные попадают в разряд «левой рукой почесать правое ухо» :).
Вообще, мне кажется, надо как-то терпимее относится к тому, что лично вам кажется неправильным. А то у вас две градации — «либо не L2, либо вы идиоты» :)
Мой опыт говорит, что L2 в ряде случаев оказывается самым простым и надежным вариантом, а все остальные попадают в разряд «левой рукой почесать правое ухо» :).
Вообще, мне кажется, надо как-то терпимее относится к тому, что лично вам кажется неправильным. А то у вас две градации — «либо не L2, либо вы идиоты» :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новые сетевые архитектуры: открытые или закрытые решения?