Сегодня в ИТ прочные позиции завоевал подход, основанный на стандартах, – заказчики почти всегда отдают предпочтения стандартным решениям. С уходом эпохи, когда господствовали мейнфреймы, стандарты завоевали прочные позиции. Они позволяют комбинировать оборудование разных производителей, выбирая «лучшие в своем классе» продукты и оптимизировать стоимость решения. Но в сетевой отрасли не все так однозначно.
На сетевом рынке до сих пор доминируют закрытые системы, а совместимость решений разных производителей обеспечивается в лучшем случае на уровне интерфейсов. Несмотря на стандартизацию интерфейсов, стеков протоколов, сетевых архитектур, сетевое и коммуникационное оборудование разных вендоров нередко представляет собой проприетарные решения. Например, даже развертывание современных «сетевых фабрик» Brocade Virtual Cluster Switch, Cisco FabricPath или Juniper QFabric предполагает замену имеющихся коммутаторов, а это не дешевый вариант. Что уж говорить про технологии «прошлого века», которые еще работают, но тормозят дальнейшее развитие сетей и функционирующих в них приложений.
Эволюция сетей. От проприетарных к открытым решениям.
Проводимые в последние годы исследования показывают, что существует разрыв между предложениями вендоров сетевого оборудования и предпочтениями его покупателей. Например, по данным одного из опросов, 67% заказчиков считают, что проприетарных продуктов по возможности следует избегать, 32% допускают их использование. Лишь 1% респондентов уверены, что проприетарные продукты и средства обеспечивают лучшую интеграцию и совместимость, чем стандартные. То есть в теории большинство заказчиков предпочитает основанные на стандартах решения, но предлагаются в основном проприетарные сетевые продукты.
На практике же при покупке нового оборудования или расширении сетевой инфраструктуры заказчики нередко выбирают решения того же вендора или то же семейство продуктов. Причины – инерция мышления, желание свести к минимуму риски при обновлении критичных систем. Однако основанные на стандартах продукты намного проще заменить, даже если это продукты разных производителей. К тому же при определенных условиях комбинация систем разных вендоров позволит получить функциональное сетевое решение за разумную цену и снизить совокупную стоимость владения.
Это не означает, что не стоит покупать проприетарные, фирменные технологии, не описываемые открытым стандартом, а являющиеся уникальной технологией определенного вендора. Именно они обычно реализуют инновационные функции и средства. Использование проприетарных решений и протоколов зачастую позволяет получить лучшие показатели по сравнению с открытыми стандартами, но при выборе подобных технологий, необходимо максимально сокращать (а лучше — исключать) их применение на границах отдельных сегментов или технологических узлов сетевой инфраструктуры, что особенно важно в мультивендорных сетях. Примерами таких сегментов могут служить уровни доступа, агрегации или ядра сети, граница между локальной и глобальной сетями, сегменты, реализующие сетевые с приложения (например, балансировка нагрузки, оптимизация трафика) и т.п.
Проще говоря, применение проприетарных технологий должно ограничиваться их использованием внутри границ сегментов, реализующих специализированные сетевые функции и/или приложения (своего рода типовые «строительные блоки» сети). В случаях, когда нестандартные фирменные технологии используются в качестве основы всей корпоративной сети или больших сетевых доменов, это увеличивает риск «привязки» заказчика к одному производителю.
Иерархические и плоские сети
Цель построения корпоративных сетей передачи данных (КСПД), будь то сеть географически распределенной компании или сеть ЦОД, – обеспечение работы бизнес-приложений. КСПД — один из важнейших инструментов развития бизнеса. В компании с территориально-распределенной структурой бизнес нередко зависит от надежности и гибкости совместной работы ее подразделений. В основе построения КСПД лежит принцип разделения сети на «строительные блоки» – каждый характеризуется свойственными ему функциями и особенностями реализации. Принятые в отрасли стандарты позволяют использовать в качестве таких строительных блоков сетевое оборудование разных вендоров. Частные (проприетарные) протоколы ограничивают свободу выбора для заказчиков, что в результате приводит к ограничению гибкости бизнеса и повышает издержки. Применяя стандартизированные решения, заказчики могут выбрать лучший продукт в интересующей их области и интегрировать его с другими продуктами, используя открытые стандартные протоколы.
Современные крупные сети очень сложны, поскольку определяются множеством протоколов, конфигурациями и технологиями. С помощью иерархии можно упорядочить все компоненты в легко анализируемой модели. Иерархическая модель помогает в разработке, внедрении и обслуживании масштабируемых, надежных и эффективных в стоимостном выражении объединенных сетей.
Трехуровневая архитектура корпоративной сети.
Традиционная архитектура корпоративной сети включает в себя три уровня: уровень доступа, агрегирования/распределения и ядра. На каждом из них выполняются специфические сетевые функции.
Уровень ядра – основа всей сети. Для достижения максимальной производительности функции маршрутизации и политики управления трафиком выносятся на уровень агрегирования/распределения. Именно он отвечает за надлежащую маршрутизацию пакетов, политики трафика. Задачей уровня распределения является агрегирование/объединение всех коммутаторов уровня доступа в единую сеть. Это позволяет существенно уменьшить количество соединений. Как правило, именно к коммутаторам распределения подключаются самые важные сервисы сети, другие ее модули. Уровень доступа служит для подключения клиентов к сети. По аналогичной схеме строились и сети ЦОД.
Устаревшая архитектура трехуровневой сети в центре обработки данных.
Традиционные трехуровневые архитектуры ориентированы на клиент-серверную парадигму сетевого трафика. С дальнейшим развитием технологий виртуализации и интеграции приложений возрастает поток сетевого трафика между серверами. Аналитики говорят (тут тоже) о смене парадигмы сетевого трафика с направления «север—юг», на «восток—запад», т.е. на существенное преобладание трафика между серверами в отличие от обмена между сервером и клиентами.
При рассмотрении сетевой архитектуры ЦОД, уровень доступа соответствует границе серверной фермы. Трехуровневая архитектура сети в данном случае недостаточно оптимизирована для передачи трафика между отдельными физическими серверами, поскольку вместо сокращения пути передачи пакетов до одного (или максимум двух) сетевых уровней, пакет передается по всем трем, увеличивая задержки за счет паразитного трафика в обоих направлениях.
То есть трафик между серверами проходит через уровни доступа, агрегации, ядра сети и обратно неоптимальным образом, за счет необоснованного увеличения общей длины сетевого сегмента и количества уровней обработки пакетов сетевыми устройствами. Иерархические сети недостаточно приспособлены для обмена данными между серверами, не вполне отвечают требованиям современных ЦОД с высокой плотностью серверных ферм и интенсивным межсерверным трафиком. В такой сети обычно используются традиционные протоколы защиты от петель, резервирования устройств и агрегированных соединений. Ее особенности: существенные задержки, медленная сходимость, статичность, ограниченная масштабируемость и т.п. Вместо традиционной древовидной топологии сети необходимо использовать более эффективные топологии (CLOS/ Leaf-Spine/ Collapsed), позволяющие уменьшить количество уровней и оптимизировать пути передачи пакетов.
HP упрощает архитектуру сети с трёхуровневой (характерной для традиционных сетевых архитектур Cisco) до двух- или одноуровневой.
Сейчас тенденция такова, что все больше заказчиков при построении своих сетей ориентируются на построение сетей передачи данных второго уровня (L2) с плоской топологией. В сетях ЦОД переход к ней стимулируется увеличением числа потоков «сервер – сервер» и «сервер – система хранения». Такой подход упрощает планирование сети и внедрение, а также снижает операционные расходы и общую стоимость вложений, делает сеть более производительной.
В ЦОД плоская сеть (уровня L2) лучше отвечает потребностям виртуализации приложений, позволяя эффективно перемещать виртуальные машины между физическими хостами. Еще одно преимущество, которое реализуется при наличии эффективных технологий кластеризации/стекирования – отсутствие необходимости в протоколах STP/RSTP/MSTP. Такая архитектура в сочетании с виртуальными коммутаторами обеспечивает защиту от петель без использования STP, а в случае сбоев сеть сходится на порядок быстрее, чем при использовании традиционных протоколов семейства STP.
Архитектура сети современных ЦОД должна обеспечивать эффективную поддержку передачи больших объемов динамического трафика. Динамический трафик обусловлен существенным ростом количества виртуальных машин и уровня интеграции приложений. Здесь необходимо отметить все возрастающую роль различных технологий виртуализации информационно-технологической (ИТ) инфраструктуры на базе концепции программно-определяемых сетей (SDN).
Концепция SDN в настоящее время широко распространяется не только на уровень сетевой инфраструктуры отдельных площадок, но и на уровни вычислительных ресурсов и систем хранения как в рамках отдельных, так и географически-распределенных ЦОД (примерами последних являются HP Virtual Cloud Networking – VCN и HP Distributed Cloud Networking – DCN).
Ключевой особенностью концепции SDN является объединение физических и виртуальных сетевых ресурсов и их функционала в рамках единой виртуальной сети. При этом важно понимать, что несмотря на то, что решения сетевой виртуализации (overlay) могут работать поверх любой сети, производительность/доступность приложений и сервисов в значительной степени зависят от работоспособности и параметров физической инфраструктуры (underlay). Таким образом, объединение преимуществ оптимизированной физической и адаптивной виртуальной сетевых архитектур, позволяет строить унифицированные сетевые инфраструктуры для эффективной передачи больших потоков динамического трафика по запросам приложений.
Архитектура HP FlexNetwork
Для построения плоских сетей вендоры разрабатывают соответствующее оборудование, технологии и сервисы. В числе примеров – Cisco Nexus, Juniper QFabric, HP FlexFabric. В основе решения HP – открытая и стандартизированная архитектура HP FlexNetwork.
HP FlexNetwork включает в себя четыре взаимосвязанных компонента: FlexFabric, FlexCampus, FlexBranch и FlexManagement. Решения HP FlexFabric, HP FlexCampus и HP FlexBranch оптимизируют сетевые архитектуры, соответственно центров обработки данных, кампусов и филиалов предприятий, позволяя по мере роста поэтапно мигрировать от традиционных иерархических инфраструктур к унифицированным виртуальным, высокопроизводительным, конвергентным сетям или сразу строить такие сети на основе эталонных архитектур, рекомендованных НР.
HP FlexManagement предоставляет возможности комплексного мониторинга, автоматизации развертывания/настройки/контроля мультивендорных сетей, унифицированного управления виртуальными и физическими сетями с единой консоли, что ускоряет развертывание сервисов, упрощает управление, повышает доступность сети, избавляет от сложностей, связанных с применением множества систем администрирования. Причем система может управлять устройствами десятков других производителей сетевого оборудования.
HP FlexFabric поддерживает коммутацию в сетях до 100GbE на уровне ядра и до 40GbE на уровне доступа, использует технологию HP Virtual Connect. Внедряя архитектуру FlexFabric, организации могут поэтапно перейти от трехуровневых сетей на оптимизированные двух- и одноуровневые сети.
Заказчики могут поэтапно переходить от проприетарных устаревших сетей к архитектуре HP FlexNetwork с помощью HP Technology Services. HP предлагает услуги по миграции от проприетарных сетевых протоколов, например Cisco EIGRP (хотя в Cisco этот протокол называют «открытым стандартом»), к действительно стандартным протоколам маршрутизации OSPF v2 и v3. Кроме того, HP предлагает сервисы администрирования FlexManagement и набор услуг, касающихся жизненного цикла каждого модульного «строительного блока» HP FlexNetwork, включая планирование, проектирование, внедрение и сопровождение корпоративных сетей.
HP продолжает улучшать возможности своего оборудования, как на уровне аппаратных платформ, так и на основе концепции Software Defined Network (SDN), внедряя различные протоколы динамического управления коммутаторами и маршрутизаторами (OpenFlow, NETCONF, OVSDB). Для построения масштабируемых Ethernet фабрик в ряде моделей сетевых устройств HP внедрены такие технологии как TRILL, SPB, VXLAN (перечень устройств с поддержкой этих протоколов постоянно расширяется). В дополнение к стандартным протоколам категории DCB (в частности VPLS), HP разработаны и активно развиваются фирменные технологии эффективного объединения географически распределенных ЦОД в единую L2 сеть. Например, текущая реализация протокола HP EVI (Ethernet Virtual Interconnect) позволяет подобным образом объединить до 64-площадок ЦОД. Совместное же использование HP EVI и протокола виртуализации устройств HP MDC (Multitenant Device Context) предоставляет дополнительные возможности по расширению, повышение надежности и безопасности распределенных виртуализированных L2 сетей.
Выводы
В каждом конкретном случае выбор архитектуры сети зависит от множества факторов – технических требований к КСПД или ЦОД, пожеланий конечных пользователей, планов развития инфраструктуры, опыта, компетенции и т.д. Что касается проприетарных и стандартных решений, то первые подчас позволяют справиться с задачами, для которых не подходят стандартные решения. Однако на границе сегментов сети, построенной на оборудовании разных вендоров, возможности их использования крайне ограничены.
Масштабное применение проприетарных протоколов в качестве основы для корпоративной сети, может серьезно ограничить свободу выбора, что в конечно счете влияет на динамичность бизнеса и увеличит его издержки.
Открытые, основанные на стандартах решения помогают компаниям переходить с унаследованных архитектур к современным гибким сетевым архитектурам, отвечающие таким актуальным задачам как облачные вычисления, миграция виртуальных машин, унифицированные коммуникации и доставка видео, высокопроизводительный мобильный доступ. Организации могут выбирать лучшие в своем классе решения, отвечающие потребностям бизнеса. Использование открытых, стандартных реализаций протоколов снижает риски и стоимость изменений сетевой инфраструктуры. Кроме того, открытые сети, с объединенными физическими и виртуальными сетевыми ресурсами и их функционалом, упрощают перенос приложений в частное и публичное облако.
Наши предыдущие публикации:
» Внедрение MSA в виртуализированном окружении предприятия
» Дисковые массивы HP MSA как основа для консолидации данных
» Мультивендорная корпоративная сеть: мифы и реальность
» Доступные модели серверов HP ProLiant (10 и 100 серия)
» Конвергенция на базе HP Networking. Часть 1
» HP ProLiant ML350 Gen9 — сервер с безумной расширяемостью
Спасибо за внимание, готовы ответить на ваши вопросы в комментариях.
Комментарии (30)
norguhtar
02.04.2015 08:02Сейчас IOS для Cisco ASR 1000-й серии весит около 300 мегабайт.
А внутре негонеонкаlinux.
MixaSg
02.04.2015 08:23Да, я знаю. А так же меня бесит вывод "show platform health", из которого, по моему мнению, стало трудно что-то понять о том, что же нагружает процессор в данный момент.
JDima
02.04.2015 12:03Ну можно начать с того, что ASR1k умеет, мягко говоря, побольше, чем 2651. Хотя если ограничивать свой объем знаний о возможностях железок официальными курсами — тогда да, они примерно равны :) Ну и да, IOS-XE устроен иначе по сравнению с классическим IOS.
Еще можно заметить, что ASR1k — аппаратная платформа (control plane и data plane реализованы разными чипами) с навороченным сетевым процессором, соответственно — радикально меняется подход к траблшутингу (в сторону усложнения этого дела). К примеру, если железка теряет часть проходящих через нее пакетов, то смотреть «show proc cpu» обычно бесполезно. Пакеты передает совершенно другое железо.
mms
02.04.2015 12:02+1Текст писал маркетолог HP: «HP упрощает архитектуру сети с трёхуровневой (характерной для традиционных сетевых архитектур Cisco) », ага. Cisco FabricPath, 2012 год, архитектура ЦОД уже давно не трехуровневая, STP никто подавно не использует. HP, мягко говоря, в своих предпосылках немного отстала.
Mishko
02.04.2015 13:22Тем не менее, в «живых» DC проектах Cisco довольно часто предлагает именно трехуровневую архитектуру — ToR (N2K) — EoR (N6K) — Core (N7K). Автор, судя по всему, руководствуется практикой.
mms
02.04.2015 13:43В живых проектах Cisco предлагает полносвязную пару Aggregation-Access, при том ставить туда 6к или 7к — зависит исключительно от нагрузок. Best Practice для ЦОД у них как раз полносвязный по L3 Core — Aggregation на N7K от которых вниз до Access полносвязный VPC/FP. Это практика. Cisco уже давно идет в сторону отказа от классической трехуровневой модели. Даже по Campus Network уже развивается в направление спуска сервисов ядра до клиентских портов — 6800ia (Instant Access) в связке c 6500. Так что HP не новатор, а уж на практике — тем более. И я не защищаю Cisco, просто немного странно приводить такой подход, как великую новацию в сетевой архитектуре.
Mishko
02.04.2015 13:49Все верно, но access зачастую 2х уровневый — N2K рабочая лошадка. А по поводу рекламы, так это общий подход — сравнивать то, что предлагает вендор сейчас с тем что стоит у клиента сейчас (т.е. было у конкурента несколько лет назад).
JDima
02.04.2015 13:55>но access зачастую 2х уровневый — N2K рабочая лошадка
С какого перепуга вы выносите обычную (пусть и необычно выглядящую — болтающуюся на оптическом патч-корде) линейную карту на отдельный уровень? Давайте так же поступим с вашими модульными свитчами. А если мы так делать не станем — получим ту же самую двухуровневую leaf-spine архитектуру с чем-то TRILL-образным посередине.
И нет, N2K не рабочая лошадка. Он тупее большинства линейных карт.Mishko
02.04.2015 14:05И нет, N2K не рабочая лошадка.
Лошадка в том смысле, что в каждом первом проекте вы ее найдете :)
С какого перепуга вы выносите обычную (пусть и необычно выглядящую — болтающуюся на оптическом патч-корде) линейную карту на отдельный уровень? Давайте так же поступим с вашими модульными свитчами.
Да можно и так, тогда получится, сравнение 4х уровневой архитектуры (N2K-N6K-модульный_N7K) и 3х уровневой от HP.JDima
02.04.2015 14:12«Да можно и так, тогда получится, сравнение 4х уровневой архитектуры (N2K-N6K-модульный_N7K) и 3х уровневой от HP.»
Но проблема: это будет очередной лживый маркетинг, напрочь оторванный от реальности :) Реальность — что уровень определяется по control plane платформы. Иначе придется вникнуть в архитектуру железок и добавить еще кучу уровней. К примеру, единый ASR9K можно было бы объявить трехуровневой железкой, карта-фабрика-карта (любые транзитные пакеты, даже между соседними портами, всегда ходят через фабрику).Mishko
02.04.2015 21:05Реальность — что уровень определяется по control plane платформы.
Что же тогда получается, что есть Fabric Extender, что нет — разницы никакой? А то, что наш кадр вместо локальной коммутации сходит в «голову», а потом вернется обратно через оптическую веревку это совсем не учитываем? От понимания того факта, что в «голове» он тоже сходит через фабрику задержки меньше не станут и легче никому не станет.
Иначе придется вникнуть в архитектуру железок и добавить еще кучу уровней. К примеру, единый ASR9K можно было бы объявить трехуровневой железкой, карта-фабрика-карта (любые транзитные пакеты, даже между соседними портами, всегда ходят через фабрику).
Ну так в чем проблема, можно и так считатьJDima
02.04.2015 21:25>А то, что наш кадр вместо локальной коммутации сходит в «голову», а потом вернется обратно через оптическую веревку это совсем не учитываем? От понимания того факта, что в «голове» он тоже сходит через фабрику задержки меньше не станут и легче никому не станет.
Но ведь надо понимать, что везде разные требования. Увеличение задержки там меньше микросекунды, и я не знаком ни с одной инфраструктурой, которая это заметит. Где заметят — просто не ставят фексы и вообще берут специализированные low-latency свитчи с задержкой в пару сотен наносекунд.
А дальше начинаются сплошные преимущества. Вот вам например с какой платформой приятнее работать — с распределенной (где линейные карты самостоятельно принимают решение о форвардинге) или с централизованной (единая группа чипов обрабатывает весь трафик)? Что проще траблшутить? Я вот предпочитаю централизованные во всех случаях, когда они не упрутся по емкости. Снижение вероятности появления багов, связанных с рассинхронизацией форвардеров, единые счетчики, единое место откуда брать трафик для анализа, простота с QoS в рамках всей платформы с возможностью гарантировать 0 потерь внутри железки (миссия невыполнима на платформах с egress forwarding, а с egress forwarding надо много костылей) и т.д.
>Ну так в чем проблема, можно и так считать
А можно считать, что крокодил — это летающий холодильник. Или же просто не искажать смысл общепринятых понятий.
mms
02.04.2015 14:02Ну N2K — это же extender и без «папиного» N5K в общем-то не нужен. Ну да, вместе с «отцом» образуют Access, только он не двухровневый, а просто с выносными модулями (дабы портовую емкость «размазать» по ЦОДу). Они там даже SFP-сборки копеечные под эти связки выпускают. Насчет рекламы уверенно спорить не буду, но мне показалось, что технология претендует на новаторство, коего, как оказалось, здесь нет :)
JDima
02.04.2015 13:19+1«Например, по данным одного из опросов, 67% заказчиков считают, что проприетарных продуктов по возможности следует избегать, 32% допускают их использование. Лишь 1% респондентов уверены, что проприетарные продукты и средства обеспечивают лучшую интеграцию и совместимость, чем стандартные. То есть в теории большинство заказчиков предпочитает основанные на стандартах решения, но предлагаются в основном проприетарные сетевые продукты.»
Вы полностью переврали результаты опроса.
Переведу более правильно. 100% опрошенных допускают использование проприетарных продуктов. Из них 67% постараются перейти на открытые стандарты по мере возможности, 32% открытость/закрытость по барабану.
Ах да, проприетарные фичи поначалу всегда опережают стандартные. Просто потому что разработка стандарта требует кучи времени на согласования с другими представителями индустрии. А кастомные (своими силами реализованные под себя) фичи опережают проприетарные, но мало кто может себе это позволить.
«HP разработаны и активно развиваются фирменные технологии эффективного объединения географически распределенных ЦОД в единую L2 сеть.»
Когда весь мир уже отказывается от этого безумия, HP начинает его рекламировать :)
Кстати, EVI разве не проприетарщина? Какое существующее в природе оборудование других вендоров может его терминировать?Mishko
02.04.2015 13:34Когда весь мир уже отказывается от этого безумия, HP начинает его рекламировать :)
Кто отказался? Зачем же тогда все ведущие вендоры продолжают «рекламировать» решения этого класса? Вот вам тема доклада с коннекта: — «Построение катастрофоустойчивыхи распределённых ЦОД (часть 2). Объединение сетей ЦОД на 2 уровне».JDima
02.04.2015 13:50>Зачем же тогда все ведущие вендоры продолжают «рекламировать» решения этого класса?
Обычно следует оговорка «лучше так не делать». У вас такой оговорки не вижу.
Например:
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? Или разговоры про открытые стандарты — фикция?Mishko
02.04.2015 13:55Вот тут вполне четко написано:
However, in some situations, Layer 2 must be extended beyond the single data center.
Про архитекторов в приведенном абзаце нет ни слова. Кейсы от заказчиков есть, поверьте на слово :)JDima
02.04.2015 14:17>Про архитекторов в приведенном абзаце нет ни слова. Кейсы от заказчиков есть, поверьте на слово
Про архитекторов сказано в фразе «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.Mishko
02.04.2015 20:50Конечно же на первый взгляд вколотить костыль проще, чем собрать встречу с заказчиком L2 DCI и убедиться, что он сам не понимает смысла этого решения.
Еще бывают случаи, когда L2 растягивают между залами одного ЦОД. Совсем недавно работал с таким запросом. Ну и я себе не представляю насколько нужно переоценить себя, чтобы назвать проектировщиков этого ЦОД «архитекторами — идиотами», ибо люди вменяемые и уважаемые, да и интегратор уверенно входит в ТОП-10.
Ну ок, тогда цискин OTV предельно открыт. IS-IS на control plane. На data plane совершенно стандартный EoMPLSoGREoIP.
Тогда встречный вопрос — вы сможете что-нибудь кроме циски подключить к OTV сети? VXLAN туннель между HP и не HP построить можно.JDima
02.04.2015 21:06>Еще бывают случаи, когда L2 растягивают между залами одного ЦОД.
Всегда возникают вопросы вида «зачем?» («какая задача требует этого?»). Но в такой ситуации можно и без лишних оверлеев обойтись. Или наоборот — делать оверлеи на уровне гипервизора, а под ним — исключительно L3.
>ибо люди вменяемые и уважаемые, да и интегратор уверенно входит в ТОП-10.
Я с разными интеграторами работал. Единственный вменяемый (где сотрудники знают свое дело) не входит в топ-10, и вообще они сотрудничали с нами не по моему направлению. К топовым интеграторам претензии выражаются словами «бездарные, некомпетентные раз****яи». Доходило до того, что человек по невежеству рушит систему и первым делом идет удалять логи (в тот раз его поймали за руку, собственные инженеры чуть раньше открыли те же логи). Ситуация понятна — в стране давно и прочно кризис, интеграторы страдают сильнее всех, нечем платить грамотным людям.
Есть кстати крупные, уважаемые, транснациональные компании, которые внедряли подход «follow the sun» — в целях экономии энергии ресурсы постоянно переносятся между ЦОДами, гаснут там, где наступает ночь, поднимаются там, где день. Переносятся нередко vmotion'ами. Разумеется, все очень быстро отказались от этой идеи. Но кто-то ведь ее придумал, внедрял даже…
>вы сможете что-нибудь кроме циски подключить к OTV сети? VXLAN туннель между HP и не HP построить можно.
А про какую такую надстройку с IS-IS над VXLAN шла речь? Она ведь тоже не совсем стандартная?Mishko
02.04.2015 21:13А про какую такую надстройку с IS-IS над VXLAN шла речь? Она ведь тоже не совсем стандартная?
На HP ее можно отключить, а на Cisco можно отключить IS-IS?JDima
02.04.2015 22:10Отключить IS-IS на VXLAN? Серьезно? Что-то я не встречал упоминаний данного протокола в RFC7348, ну а решения, где наворотили отдельных протоколов над VXLAN, не называются VXLAN, у них иные названия. Да, многие цискины платформы умеют и бриджинг, и роутинг VXLAN в соответствии со стандартом.
Вообще, у вас какие-то проблемы с пониманием сарказма, например во фразе «цискин OTV предельно открыт. IS-IS на control plane. На data plane совершенно стандартный EoMPLSoGREoIP» :) Это был пример, показывающий, что самодельная сборка открытых протоколов ни разу не обязана сама быть открытой и стандартной, просто вендорам удобнее задействовать те инкапсуляции и те протоколы, которые уже известны железу. Заканчивайте назвать такие сборки открытыми, это очередная ложь.
Mishko
02.04.2015 14:00Ну и всё-таки — какое не принадлежащее HP оборудование поддерживает EVI? Или разговоры про открытые стандарты — фикция?
EVI технология проприетарная, никто не крывает, в статье это указано: —HP разработаны и активно развиваются фирменные технологии...
Придерживаясь принципов открытости и совместимости сейчас HP реализует в своих продуктах VXLAN, все отличие в инкапсуляции (UDP вместо GRE), остальной функционал будет точь-в-точь как на EVI. Причем VXLAN в HP реализован с IS-IS control plane.
exceed
02.04.2015 15:34чувствую, опять поднимается старая тема — L2 DCI или не L2 DCI :)
уважаемый JDima, мир он цветной, а не черно белый и обзывать идиотами всех, кому L2 DCI удобен/привычен/подходит под задачи и т.д., как минимум, по моему скромному мнению, некорректно :)JDima
02.04.2015 15:41Руководствуюсь опытом отбивания запросов «дай L2 между ЦОДами». Такие запросы до сих пор периодически приходят. Каждый случай индивидуально рассматривается, и всегда оказывается, что если выкинуть «L2» из списка допустимых вариантов, то какой-то из оставшихся подходов обязательно окажется со всех сторон лучше — проще, надежнее, безопаснее, дешевле.
Но конечно же проще не пытаться включить мозг, а просто растянуть решение, нормально работающее в пределах стойки, на полстраны. А потом удивляться возникающим проблемам.mms
02.04.2015 16:15Ну-ну-ну, мы когда в свое время на EMC VNX хотели отказоустойчивые сайты при помощи VPLEX развернуть там как бы основным условием было (тогда по-крайней мере) прямая FC видимость стораджей, ибо там синхронная репликация (active-active резервирование таки), синхронизация состояний и еще тонна каких-то условий. И как вариант (помимо прямых волокон) рассматривался metro L2 чтобы по FCoE гонять все эти радости. Сейчас, конечно, все немного поменялось (в т.ч. по бизнес-требованиям), но осадочек остался.
exceed
02.04.2015 16:26Конечно, всегда есть выбор. Если смертельно ненавидеть L2, то с позиции, «все что угодно, только не L2 DCI», почти всегда можно придумать выход и сделать как-то без L2.
Мой опыт говорит, что L2 в ряде случаев оказывается самым простым и надежным вариантом, а все остальные попадают в разряд «левой рукой почесать правое ухо» :).
Вообще, мне кажется, надо как-то терпимее относится к тому, что лично вам кажется неправильным. А то у вас две градации — «либо не L2, либо вы идиоты» :)
MixaSg
Первая треть статьи про пользу открытых решений, последняя про рекламу проприетарного решения. Мое личное мнение, что SDN нужны не пользователям, а производителям сетевого оборудования. Например, IOS для Cisco 2651XM весил около 20 мегабайт и умел, в принципе, все необходимое для построения сети любого масштаба. Сейчас IOS для Cisco ASR 1000-й серии весит около 300 мегабайт. Этот сколько нужно индусов поддерживать такой код и писать что-то новое? А с SDN все просто: оставим, кто поумнее, писать код контроллера, остальных разгоним, коммутаторы станут набором микросхем, что спокойно можно делать на заводах КНР и все, проблема решена, жизнь с начала, смотрите как здорово.
Mishko
Кроме контроллера нужно еще писать приложения, т.ч. места всем хватит.