Pull to refresh

Comments 82

в Москве должно быть особенно актуально.
Почему именно в москве? Где угодно должно быть актуально, технология к географии не привязана.
Устойчивый «трэнд» последнего времени на виртуализацию и построение облачных инфраструктур однозначно показывает, что предпочтительнее остальных по многим причинам является вариант с объединением площадок ЦОД по второму (L2) уровню.

И по еще большему количеству причин этот вариант является отвратительнейшим из всех.
Надо отстраивать инфраструктуру так, чтобы в нее изначально было заложено «никакого L2 между ЦОДами». Ибо не существует ни одного сценария, когда без L2 DCI никак нельзя обойтись. Кроме сценария «серверную инфраструктуру проектировали идиоты», что, к сожалению, время от времени встречается.

Сейчас тренд — избавление от L2 сегментов на физическом железе даже в пределах одного ЦОДа. Не спорю, мало кто осилил это, но все к этому стремятся.
устанавливаем по два коммутатора HP серии 5800 и объединяем их в один виртуальный коммутатор

Что будет, когда связь между парами свитчей порвется (варианты — несколько секунд и несколько минут)? Если control plane активного супервизора слегка заглючит, но не настолько, чтобы вызвать фейловер — лягут сразу все площадки? Первый хоп находится в том шасси, в которое пришел пакет, или же строго на шасси с активным супервизором? А каков будет ответ на предыдущий вопрос, если не объединять их в IRF стек между площадками? (ни разу не слышал ни от одного вендора, что подобная конфигурация является не то что рекомендованной, а даже допустимой)
По поводу «никакого L2 между ЦОДами» даже спорить смысла не вижу. Конечно, все ошибаются, стараясь сделать DCI на 2-м уровне. И Cisco с OTV и FabricPath-ом, и Juniper c VPLS, и HP с VPLS и EVI, и все остальные, поддерживающие TRILL, SPB/PBB… Видимо, только Вы уловили тренд. Еще интереснее предложение отказаться от L2 в рамках одного ЦОД. Хочется услышать, как именно вы предлагаете это сделать…

Относительно того, что случится, если произойдет split стэка — варианты могут быть разные. Если настроен MAD, одно из устройств в развалившемся стэке до перезагрузки погасит все порты (чтобы не было в сети двух с одинаковыми параметрами, MAC и т.д.). При этом, трафик будет спокойно идти через второе устройство. Вы что-то видимо недопоняли (или я в статье нечетко выразил). Ситуации, когда, как вы выразились, «control plane активного супервизора слегка заглючит» и «лягут все площадки», здесь быть не может.
Конечно, все ошибаются, стараясь сделать DCI на 2-м уровне. И Cisco с OTV и FabricPath-ом, и Juniper c VPLS, и HP с VPLS и EVI, и все остальные, поддерживающие TRILL, SPB/PBB…

Обратите внимание на следующие моменты.
1) Цискин OTV — наименее кошмарное из решений для L2 DCI, ибо имеет некоторый интеллект, фильтрует лишний трафик и предоставляет серверам правильные первые хопы. VPLS ничего подобного не позволяет делать. С ним пути трафика всегда будут неоптимальными, а шторм на одной площадке затронет всех.
2) Fabricpath (и вообще всё TRILL-образное) предназначен только для работы в пределах одной площадки, не путайте.
3) VPLS уже давно есть у всех. Эта технология — изначально операторская и предназначена для предоставления клиентам прозрачного на L2 транспорта. В вашем случае при наличии двух площадок VPLS играет роль длинного патч-корда. С таким же успехом это мог быть операторский VPLS или даже QinQ, не суть важно. При большем числе площадок VPLS тоже не является панацеей: если терминировать его на одной (логической или физической) железке, то возникает больший риск при глюке этой железки похерить всю площадку. А если резервировать, то надо по-хорошему создать два облака, и как-то разбираться с кольцами в них.
Еще интереснее предложение отказаться от L2 в рамках одного ЦОД. Хочется услышать, как именно вы предлагаете это сделать…

Получайте аббревиатуры: vxlan, nvgre, stt. Иными словами — оверлеи, работающие поверх IP транспорта. Всего-то надо добавить чуть мозгов в виртуальный свитч, и готово.
Вы что-то видимо недопоняли (или я в статье нечетко выразил).

Я, кажется, неправильно понял фразу «на каждой площадке устанавливаем по два коммутатора HP серии 5800 и объединяем их в один виртуальный коммутатор». Хотя на самом деле в предложенной топологии сценарий «авария на одном ЦОДе убивает всех» вполне реален. Вот произошел шторм — и десятки гигабит броадкастов хлынули к соседям, засоряя всю сеть и перегружая хосты. Механизмов, способных снизить урон (вроде цискиного storm control) не увидел.

Кстати, в статье так и не было сказано, зачем нужно иметь L2 DCI с точки зрения виртуализации. Сможете сказать?
Ну и до кучи все-таки расскажите, как решить проблему, связанную с выбором ближайшего к хосту первого хопа. А то не дело гонять трафик от сервера до default GW в другой ЦОД, а потом обратно, если получатель находится в соседнем VLANе на том же свитче.
Также, как и в «наименее кошмарном» OTV, почитайте про VRRP Isolation
1. На OTV свет клином не сошелся, есть EVI, скоро будет MAC VPN и т.д… По поводу штормов: VPLS — это L2 транспорт c сервисами. Если у вас в VLAN-е начался шторм, от него можно и нужно защищаться стандартными механизмами (storm control, описание за рамками этой статьи, вот здесь, например, почитайте bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02648774/c02648774.pdf, стр. 30). А неоптимальные маршруты — это, как правило, от кривых рук. Уверяю вас, отбалансировать трафик так, чтобы он ходил нужными вам путями, в VPLS можно.

2. Что мешает протянуть тот же TRILL между площадками? Чему это противоречит? Больше скажу, некоторые так и делают. Не имею права называть имена заказчиков, но объединение 6 ЦОД при помощи, как вы выразились «TRILL-образных» технологий — работающая реальность.

3. VPLS действительно есть давно и у многих. Именно поэтому и говорю, что это зрелая технология. Cлучай с двумя площадками действительно тривиальный, рассмотрен для упрощения примера. Как только появляется большей одной площадки, возникает вопрос, как их объединять. Терминировать VPLS на одной физической железке не надо, для этого и делается виртуальный свич. Хотите резервировать L3 GW — опять же, пользуйтесь стандартными средствами (VRRP, например). Логических колец в VPLS (при условии правильной настройки) не бывает, а если вы облаком называете vsi, то да, их можно (и, в некоторых случаях, нужно) делать несколько/много.

Как вы, вероятно, понимаете, vxlan, nvgre, stt — это технологии туннелирования L2 трафика через IP сети, позволяют делать как раз обратное предложенному вами — растягивать non-continuous L2 сегменты. Причем здесь отказ от L2 в ЦОД — не понятно…

Зачем L2 DCI для виртуализации можете прочитать вот здесь — pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc_50%2FGUID-3B41119A-1276-404B-8BFB-A32409052449.html.

А неоптимальные маршруты — это, как правило, от кривых рук. Уверяю вас, отбалансировать трафик так, чтобы он ходил нужными вам путями, в VPLS можно.

Ну так расскажите, как в предложенном сценарии реализовать правильный выбор первого хопа для каждой площадки.
Что мешает протянуть тот же TRILL между площадками?

Да потому что не предназначен он для работы между площадками. Хоть он и на базе IS-IS, но там сейчас даже нет L2 арии. Есть драфты, но пока это именно драфты. Что у кого-то оно работает — верю, но сомневаюсь, что кто-то осмелился реализовать подобным образом боевую инфраструктуру. И тем более что объединили по L2 шесть ЦОДов. Они что, психи?
Терминировать VPLS на одной физической железке не надо, для этого и делается виртуальный свич.

А потом, как я уже писал, у активного супервизора слегка съедет крыша (но не настолько, чтобы вызвать фейловер) — и наступает большая беда. Только не говорите, что так не бывает.
Хотите резервировать L3 GW — опять же, пользуйтесь стандартными средствами (VRRP, например).

Речь не про то.
Есть единый броадкастовый домен, растянутый по 6-и площадкам. Внимание, вопрос: каким образом сделать так, чтобы сервер из ЦОДа «Б» считал своим DGW L3 интерфейс в ЦОДе «Б», а не в ЦОДе «А»? Это ведь критический момент.
Логических колец в VPLS (при условии правильной настройки) не бывает

Логической кольцо может быть на одной площадке, и эта площадка может начать слать много мусора соседям.
позволяют делать как раз обратное предложенному вами — растягивать non-continuous L2 сегменты. Причем здесь отказ от L2 в ЦОД — не понятно…

Как это не понятно? На физическом оборудовании само понятие «VLAN» может запросто исчезнуть. А виртуальные свитчи уже могут делать uRPF на L2 и много чего другого.
Зачем L2 DCI для виртуализации можете прочитать вот здесь

Вполне ожидаемый ответ — vmotion. Снова спрашиваю, чуть другими словами: зачем делать vmotion между площадками? Только пожалуйста, не надо говорить «чтобы таскать виртуалки между ЦОДами без их остановки», я спрашиваю про конечную цель данного действа.
(и я правильно понимаю, что этим надобность в L2 DCI и исчерпывается?)
Ну так расскажите, как в предложенном сценарии реализовать правильный выбор первого хопа для каждой площадки.

Вроде бы, говорил уже в предыдущем посте, используйте для этого стандартные средства, VRRP. OTV, который кажется вам «наименее кошмарным», делает тоже самое, только фильтры там встроенные. Ну вот здесь, например, почитайте, как VRRP Isolation настраивается… Или вы говорите про MPLS, как там оптимально LSP построить? Это делается при помощи MPLS TE (RSVP, в частности). Сам VPLS, как правило, делают full mesh, там никаких suboptimal path априори нет, все через один хоп. Что еще рассказать про неоптимальные пути?
Да потому что не предназначен он для работы между площадками
No comments. Вам кажется, что TRILL для этого не предназначен — не используйте. Все психи, только вы в белом и на коне.
Логической кольцо может быть на одной площадке, и эта площадка может начать слать много мусора соседям.
Для этого на CE запускают STP, используют storm control, loop protection, механизмы управления MAC в VPLS…
На физическом оборудовании само понятие «VLAN» может запросто исчезнуть. А виртуальные свитчи уже могут делать uRPF на L2 и много чего другого.
Простите, вспомнил старое кино, "… когда вы говорите, Иван Васильевич, впечатление такое, что вы бредите..". Куда исчезнет понятие «VLAN» (видимо, заодно и понятие «broadcast»)? Причем здесь unicast Reverse Path Forwarding, если вы про него (да еще и на L2)? Как это все, в вашем понимании, должно работать? Вы уж объяснитесь, а то правда, как в старом кино…
Вполне ожидаемый ответ — vmotion
Если знаете — зачем спрашиваете?
Зачем делать vmotion между площадками
Действительно, проще загасить виртуальную машину, перелить ее по FTP, засинхронизировать руками настройки и запустить.
и я правильно понимаю, что этим надобность в L2 DCI и исчерпывается?
Вообще, зачем компании ЦОД, да еще и 2 площадки? Сидели бы все из дома на 2400 baud с UUCP и были счастливы, нет, придумывают всякую ерунду, business continuity, cloud computing, High Availability, Fault Tolerance , кластеры разные…
Долго я писал пост…

Это — решения, а не задачи. Как и vmotion. Я хочу услышать задачу, оптимальным решением которой будет миграция виртуалок с площадки на площадку как минимум с сохранением адресации. Пока я так ничего и не услышал.

FT — это пять… Ни разу в жизни не слышал о том, чтобы кто-то на практике им пользовался.
Я хочу услышать задачу, оптимальным решением которой будет миграция виртуалок с площадки на площадку
К чему этот вопрос? Хотите сказать, что миграция не нужна? Так расскажите, как вы управляете виртуальной инфраструктуру, может и правда, у вас есть идеи лучше. Или это такой способ самообразовываться — задать вопрос с вызовом, чтобы вам сразу объяснили, как это делается?

FT — это пять… Ни разу в жизни не слышал о том, чтобы кто-то на практике им пользовался.

Если вы не слышали, это не значит, что им не пользуются. Приходите к нам на семинары, на курсы, проведем ликбез по инфраструктуре современного ЦОД
Хотите сказать, что миграция не нужна?

Конечно! Вы ведь тоже не можете назвать ни одной причины, по которой миграция виртуалок с сохранением адресации имеет смысл.
Так расскажите, как вы управляете виртуальной инфраструктуру

Немного не понял вопрос. Переформулируете?
Попробую ответить на вопрос так, как я понял. Есть виртуальная инфраструктура. Все более-менее критичные системы резервированы в режиме active-active (либо на уровне подсовывания клиенту адресов с разных площадок, если он корректно умеет с этим работать, либо использованием аппаратных балансировщиков, но это всегда независимые виртуалки с кластеризацией на уровне приложения). Если дергуть рубильник на одном из ЦОДов — емкость всех систем снизится, но они не сломаются, фейловер произойдет либо незаметно для пользователя, либо потребует нажатия на F5. И на каждой площадке, разумеется, своя адресация.
Перенос виртуалок — не проблема, ибо все диски находятся в SAN, у которого свои механизмы репликации. Если нужно перенести какую-то из них, то она просто гасится в одном месте и запускается в другом — с минимальной нагрузкой на сеть и без простоя сервиса. В отличие от vmotion, который требует передачи весьма существенных объемов данных в процессе миграции, а если каналы недостаточно широки, то миграция запросто может провалиться. И который абсолютно никак не годится для disaster recovery, о котором я говорил ранее. Более того, резервирование A/S средствами гипервизора — вообще не резервирование. Как можно назвать это резервированием, когда сервис падает на период даже штатного перезапуска одной ноды?
Так что я совершенно искренне чешу в затылке и не могу понять, на кой черт растягивать один L2 сегмент по нескольким площадкам. Разве что архитектор решения совершенно некомпетентен в своей области.
Если вы не слышали, это не значит, что им не пользуются.

Но им действительно никто не пользуется. Колоссальное количество ресурсов вылетает в трубу, при этом оно помогает защититься только от падения хоста, что куда большая редкость, чем падение виртуалки по какой-либо причине. А уж поднимать это дело между ЦОДами = напрочь загадить линки между ними паразитным трафиком.
Приходите к нам на семинары, на курсы, проведем ликбез по инфраструктуре современного ЦОД

Вы лучше сами сначала узнайте, что и как делается, и не плодите в народе убогие от рождения идеи :) Я все понимаю, вендору надо впарить глупым людям не менее глупое решение, но все-таки совесть надо иметь…

Знаете, когда-то те самые серверные админы считали хорошей идеей концепцию «follow-the-sun datacenter». Это когда компания, имеющая ЦОДы по всему миру, раз в несколько часов мигрирует все виртуалки с одной площадки (где световой день заканчивается) на другую, западнее, а предыдущая гасится. Преимущества вроде очевидны: ресурсы всегда находятся близко к большинству конечных пользователей, экономится энергия и т.д. Надеюсь, мне не нужно объяснять, почему эта красивая на бумаге концепция была признана всеми соображающими людьми абсолютно убогой и непригодной к реальной жизни? Однако, не исключаю, что кто-то на короткое время внедрил ее в продакшн, см. правило 95%.
Все, вопросов больше не имею. Думаю, дискуссию можно закрывать. Очевидно, что все, кроме Автора — психи, глупые и бесхребетные. И все идеи, кроме идей самого Автора (чего стоит одна только фантасмагория об отказе с помощью vxlan, stt и uRPF от L2 в ЦОД!), убоги. Только автор светоч, он точно знает, куда движется мир, а заодно может легко объяснить, как на коленке с помощью репликации в SAN и «подсовывания адресов клиентам» построить отказоустойчивую инфраструктуру…

Вы почитайте себя внимательно, уважаемый Автор, вы же сами себе противоречите — "… гасится в одном… и запускается в другом без простоя сервиса (!)", зачетная идея… Бросьте читать Интернет и попробуйте реализовать своим идеи руками, возможно, тогда вы научитесь отличать «маркетинг булшит» от мэинстрим технологий. Поиграетесь со своими «наколенными технологиями», поломаете ЦОД пару раз, получите «премию» от начальства — и вам перестанет казаться, что вендоры впаривают глупым людям убогие идеи…
как на коленке с помощью репликации в SAN и «подсовывания адресов клиентам» построить отказоустойчивую инфраструктуру…

Я вот тоже думаю, что дискуссию можно закрывать. Вы не знаете абсолютно ничего кроме краткого содержания одной маркетинговой брошюрки.
"… гасится в одном… и запускается в другом без простоя сервиса (!)", зачетная идея…

Вы никогда не слышали про то, что сервис может быть не завязан на физический сервер, и что вполне можно сделать так, что ни один пользователь не заметит отключение любого из поддерживающих сервис серверов, а то и нескольких? Это уже профнепригодность, заметьте. Вы просто не знаете, что такое «архитектура».
Уже можно больше не повторять про убогость, незнание и психическое нездоровье. Вас обидел намек, что вы смутно разбираетесь в предмете, о котором пытаетесь говорить и поэтому говорите ерунду? Уже успокойтесь, все услышали, что вы Д'Артаньян, а остальные дураки, подростковые комплексы, уважаемый Автор, могут стать причиной многих необдуманных поступков.
И не судите людей по себе. Если для вас истоник знаний — брошюры и мусор из Инета (о чем я подозревал с самого начала), не следует думать, что остальные питаются тем же.
Почему у меня возникает ощущение, что я разговариваю с натуральным ребенком, который не может составить ни одного конструктивного слова и, будучи загнанным в угол, мгновенно переходит на личности?

В принципе, куда копать — я сказал. Изучайте, как работают балансировщики (например, Cisco ACE, линейка F5 BIG-IP), как организуется репликация сессий между разнообразными сервисами (к примеру, Apache/Tomcat), и вообще каковы принципы построения распределенных и отказоустойчивых ЦОДов. Не исключено, что когда-нибудь вас и допустят до критической инфраструктуры. Хотя с такой бараньей упертостью и любовью повторять чужие слова не вникая в их смысл — не факт.

Топик покидаю. Вернусь разве что если наконец-то услышу, каким таким волшебным образом vmotion способен повысить отказоустойчивость сервисов — ибо никто в мире этого не знает :)
Не горячитесь, вас явно кто-то серьезно обидел :). Почему у вас возникают разные ощущения, вам лучше спросить в другом месте, думаю, понятно в каком :). На личности, кстати, перешли вы, не я.

А топик давно пора покинуть, прямо после первой же сказанной ерунды, и не позориться дальше не весь Инет.
Как разгребете в голове кашу из технологических терминов, маркетинговых лозунгов и зачатков технических знаний — приходите, поговорим про архитектуры современных ЦОД и сети для них :).
И вы вернитесь в 21 век, какие репликации сессий в Apachе, вы о чем? Балансировщики зачем-то сюда приплели, вы еще про round-robin в dns-е здесь расскажите… Вы вот этого, что-ли, начитались, вы Cisco любите, кажется? Дружище, этому документу уже лет 10!

Прежде, чем кому-то ставить диагнозы, вы поучитесь, посмотрите сначала, как современный мир живет чуть дальше, за пределами вашего горизонта… Ну вот тут по ссылкам походите, что-ли, почитайте. Может, перестанете увеличивать энтропию идеями 10-летней давности про то, как прикрываться балансировщиками и за ними гасить машины в одном месте и поднимать в другом…
Ну что же, сочту это за попытку аргументировать свое мнение (как всегда, получилось не очень).
Балансировщики зачем-то сюда приплели, вы еще про round-robin в dns-е здесь расскажите…

Балансировщики
DNS балансировка (нет, не round robin)
Вы, конечно, не в курсе, но 100% глобальных высоконагруженных сервисов используют комбинацию обоих решений. Кто-то в виде программного решения, кто-то в виде железок. Иначе почему-то не получается…
Кстати — хорошая выжимка есть здесь.
Ну вот тут по ссылкам походите, что-ли, почитайте.

Облака — так модно, так молодежно… Жаль, что дети не понимают, что такое «облака»…
Во всех касающихся дизайна документах упоминается SLB, в том числе на ACE/CSS.

Но вернемся к нашим баранам.
Малыш, ну расскажи мне, каким же все-таки образом L2 DCI (в лице работающих поверх него vmotion и тому подобных решений) улучшает отказоустойчивость сервисов :) Слово вылетело — вперед объяснять. А то как-то нехорошо, что все заданные мной неудобные вопросы игнорируются.
Ну а если кто-то считает, что «FT пара в vsphere» = «зарезервированный и отказоустойчивый сервис», то такому человеку не место в IT.
Малыш, ну расскажи мне
«Малыш»..., улыбнуло :). И этот человек говорит мне, что я перехожу на личности…

Вы, конечно, не в курсе..
Опять двадцать пять, «все дураки — один я умный», я же уже признал вас Д'Артаньяном :)

каким же все-таки образом L2 DCI (в лице работающих поверх него vmotion и тому подобных решений) улучшает отказоустойчивость сервисов
Вместо того, чтобы кидаться в меня ссылками пятилетней давности (ну реально, Design Guide от декабря 2007 года староват для аргументации, «получилось не очень», как вы выразились:), если вас правда интересует, как работает L2 DCI — приходите, я вас приглашаю. У нас периодически проводятся мероприятия, на которых вживую, на стэнде, мы показываем то, о чем изначально статья. vMotion не помню, есть в программе или нет, но VM HA/FT точно есть. А то вы, судя по всему, видите и любите только Cisco, а HP для вас компания, которая выпускает принтеры…

В ответ хотелось бы получить приглашение посмотреть на то, как устроена ваша виртуальная инфраструктура. Если вы в Москве — готов к вам с колегами подъехать, посмотрим, обсудим вопросы вживую.

Но вернемся к нашим баранам.

Ну а если не хотите — возвращайтесь к «своими баранами», видимо, вам эти животные нравятся :)
И этот человек говорит мне, что я перехожу на личности…

«Ты первый начал» (с)
Вместо того, чтобы кидаться в меня ссылками пятилетней давности

Забавно… Открываем вторую ссылку из habrahabr.ru/company/hp/blog/150725/?#comment_5129641, выбираем четвертый результат, щелкаем «DC Infrastructure», затем «launch the design guide» — и опаньки — «Cisco Data Center Infrastructure 2.5 Design Guide»! Или выбираем «Virtualized Multi-Service Data Center», жмем «view document» — и видим второй гайд! Кажется, циска считает их актуальными…
если вас правда интересует, как работает L2 DCI — приходите, я вас приглашаю

Беда в том, что я это прекрасно знаю, в отличие от вас :) Я все мечтаю услышать, зачем же он нужен… Неужели простой адепт не в силах ответить на вроде бы простой вопрос, и вынужден переслать меня к Гуру? У вас там что, секта?
vMotion не помню, есть в программе или нет, но VM HA/FT точно есть.<.blockquote>
Все еще считаете HA/FT резервированием? Ну-ну.
HP для вас компания, которая выпускает принтеры…

Скажите — а когда HP наконец-то избавились от цискиного железа в собственной сети? Год назовете? Или еще не до конца избавились?
С другой стороны, логично, что вендор, не имеющий собственных балансировщиков, попытается убедить окружающих, что они и не нужны.
Спросите старших коллег — а то мне nslookup говорит, что и hp.com балансируется DNS раунд-робином (кто бы мог подумать, что и HP настолько отстали от моды?), а по выдаваемым адресам наверняка стоят или Cisco ACE, или F5 BigIP.
В ответ хотелось бы получить приглашение посмотреть на то, как устроена ваша виртуальная инфраструктура.

Ох уж эти риторические вопросы… Вроде я уже дал вполне подробное описание — и все равно непонятно. Хотя что там может быть непонятного? А я все тешу себя надежной услышать, зачем же виртуальной инфраструктуре нужен L2 DCI… Видимо, так никогда и не услышу.
готов к вам с колегами подъехать, посмотрим, обсудим вопросы вживую.

Ну конечно же один вендор с удовольствием попробует переманить крупного клиента другого вендора, тем более такой мелкий вендор, как HP (который даже для своих корзин продает цискины свитчи). Однако боюсь, что судя по написанному тут попытка обречена на провал. Вот спрошу я на встрече «зачем нам L2 DCI?» — и ваши коллеги так же будут мямлить и жевать сопли?
циска считает их актуальными…
Да, у циски на сайте авгиевы конюшни, там про FDDI еще можно почитать. По вашему подходу он, видимо, тоже еще актуален…

Беда в том, что я это прекрасно знаю, в отличие от вас :) Я все мечтаю услышать, зачем же он нужен… Неужели простой адепт не в силах ответить на вроде бы простой вопрос, и вынужден переслать меня к Гуру?
Ах ну да, я забыл, вы же Д'Артаньнян и все знаете :)

… вендор с удовольствием попробует переманить крупного клиента другого вендора..
Смешно...:) А где вы работаете, если не секрет?

Вот спрошу я на встрече «зачем нам L2 DCI?»
Ой, не пугайте :)

Вас по-человечески пригласили посмотреть вживую на работающий стэнд и выяснить интересующие вопросы, если эта тема вам интересна. Боитесь после всего, что вы тут понаписали — так и признайте, нечего брызгать слюной в монитор, всезнайка вы наш. Все знаете — тем более, нечего задавать дурацкие вопросы.
у циски на сайте авгиевы конюшни, там про FDDI еще можно почитать

Не надо про их сайт. Их сайт — лучшая в мире база знаний по сетевым технологиям. Только никакого FDDI в современных гайдах нет.
А где вы работаете, если не секрет?

Разумеется, секрет. Скажу лишь, что мы — очень крупный клиент для циски.
Вас по-человечески пригласили посмотреть вживую на работающий стэнд и выяснить интересующие вопросы, если эта тема вам интересна.

Я прекрасно понимаю, как оно будет работать, тем более на стенде. Однако, эта тема мне неинтересна — так как я не увидел ни намека на то, зачем оно нам надо. Хотите заинтересовать? Тогда скажите, на кой нашей вполне катастрофоустойчивой виртуальной инфраструктуре сдался L2 DCI, и почему нас не устраивает текущая схема «по одному блоку адресов на площадку».
Боитесь после всего, что вы тут понаписали

Скорее — вижу для себя более интересные дела, чем общение с маркетологами, не способными ни слова сказать по технической части :)
Их сайт — лучшая в мире база знаний по сетевым технологиям.
Оборжаться :)
У вас настолько основательно промыт мозг маркетинговой машиной от Cisco, что вы, видимо, правда считаете их сайт лучшей в мире базой по сетевым технологиям… no comments. :)
вижу для себя более интересные дела, чем общение с маркетологами
Удачи вам в более интересных делах, учите мат. часть, Большой Технический Специалист :) CCIE не забудь сдать, в октябре, кажется, следующая мобильная лаба :)
У вас настолько основательно промыт мозг маркетинговой машиной от Cisco, что вы, видимо, правда считаете их сайт лучшей в мире базой по сетевым технологиям… no comments. :)

А все-таки прокомментируйте. У кого лучше?
CCIE не забудь сдать, в октябре, кажется, следующая мобильная лаба :)

Ходил уже пару лет назад, но то ли у них проверочные скрипты глючат (вполне вероятно, ибо когда из 25-и человек успешно сдают трое, а среди заваливших имеется ветеран с 20-летним опытом, умудрившийся набрать 20% на L2 части, то что-то явно нехорошо), то ли надо долго дрессироваться на тренировочных или ворованных лабах. Нет, пожалуй — обожду.
Разумеется, секрет.
Боитесь? Ну разумеется, молоть чушь в Инете просто, пока никто не знает, откуда такой герой :)
Боюсь, что корпоративная политика не позволяет мне называть своего работодателя, так что звиняйте ;)
Вот еще одна чушь — "… корпоративная политика не позволяет..". Вы у HR своего спросите, думаю, он вам разрешит…

Ладно, дружище, правда больше времени на это нет, живите счастливо, любите Cisco, приходите в гости :)

правда больше времени на это нет

А все-таки пригласите сюда Гуру. Может, хоть тот сможет сказать, зачем нужно растягивать L2 между площадками и каким образом данное действо не понизит, а наоборот повысит отказоустойчивость, вопреки всякому здравому смыслу. А то прямо чудеса какие-то…
Ну и полюбопытствуйте у своих, обслуживающих внутреннюю сеть — есть ли у вас растянутые между площадками VLANы. Что-то думается мне, что ни одного нет…
зачем нужно растягивать L2 между площадками
Вы же в Cisco верите? Ну хотя бы вот это, научно-популярное, прочитайте, начиная с обзаца Business Reasons for Implementing LAN Extension Between Multiple Data Centers. Там есть еще, поройте, если вы не прикидываетесь и действительно не понимаете, зачем это нужно. А у меня правда больше нет времени вам это объяснять…
Вы же в Cisco верите?

Нет.
Они — обычный вендор, который тоже заинтересован пропихнуть свое решение.
Но: "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."
Да, циске не нравится L2 DCI. Как и всем кроме нескольких крайне упертых товарищей :)
«Some network communication between members of high-availability clusters1 requires some clusters to be Layer 2»
Но нормальные кластеры любого сервиса прекрасно общаются внутри себя по L3 мультикасту. Расположение нод не имеет значения. VRRP считается немасштабируемым и ненадежным решением, все вендоры всегда советуют задействовать выделенные балансировщики.
Workload Mobility

Не аргумент — при нормальном дизайне смена адресации у нод — плёвое дело.

И… всё.
Про отказоустойчивость ни слова, даже совсем наоборот. По сути, циска сказала «если вы м**аки и сервисы у вас м**ацкие, то можете попробовать вот так, но лучше не стоит».
если вы не прикидываетесь и действительно не понимаете, зачем это нужно.

До сих пор не понимаю. Вы тем более.
Не понимаете, ибо не хотите (или не можете) ничего понимать. Вы просили список, зачем нужен L2 DCI — вот вам список от любимого вами (или уже не любимого? а как же CCIE?) вендора: High-availability clusters, server migration, and application mobility are important use cases that require Layer 2 extension..
Список тоже оказывается не годится, вы сами решили, что им нравится, а что нет. И кластеры, которые работают не так, как вы хотите, не нормальные, и workload mobility не аргумент… Именно поэтому я не хотел даже начинать с вами никаких дискуссий.

До сих пор не понимаю. Вы тем более
Конечно, если вы не поняли, куда всем остальным, как вас заело-то :). И на CCIE вас такого умного тоже несправедливо завалили :)
вы м**аки и сервисы у вас м**ацкие
Ну все, понеслась душа в рай… Дальше матом будем общаться?

Дискуссия закрыта. Хотите материться — открывайте свой блог, там высказывайте свои суперидеи в любой форме, может, кто будет читать, здесь для этого не место
High-availability clusters, server migration, and application mobility are important use cases that require Layer 2 extension… Список тоже оказывается не годится

Конечно не годится. По всем трем пунктам «L2 extension» не требуется. Ни для нормально собранных кластеров (которым вообще по барабану адресация отдельных нод), ни для «server migration» (адрес сервера сменить не проблема, это не вызывает падение сервиса), ни для «application mobility» (см. п.1). Всего-то нужно реализовать нормальную серверную архитектуру. Ну а если мозгов не хватило — вперед собирать мину замедленного действия, которая рано или поздно рванет и разнесет все площадки разом.
И кластеры, которые работают не так, как вы хотите, не нормальные

Любая нормальная кластеризация подразумевает задействование балансировщика. Альтернативы — ущербные от рождения решения вроде MS NLB (сам MS писал, что если >500мб/с трафика или около того, то только железные балансеры и никак иначе), или не менее ущербные решения на базе VRRP и аналогичных протоколов, в 99% случаев подразумевающие A/S, что недопустимо.
Так что нет, я так и не увидел ни малейшей причины растягивать L2 по площадкам.
И уж тем более не могу понять, какие вещества нужно употреблять, чтобы считать L2 DCI необходимым для виртуальной инфраструктуры настолько, что без этого ну прямо никак. Это как раз и говорит о полной некомпетентности.
Ну а циске надо впаривать весьма недешевые нексусы линейки 7к. Одна из их главных фич — тот самый OTV. Разумеется, циска должна его расхваливать. Но уважения достойно то, что они честно говорят «L2 DCI — это отстой».
Именно поэтому я не хотел даже начинать с вами никаких дискуссий.

Но вам явно захотелось шлепнуться задницей в лужу — на здоровье :)
Дальше матом будем общаться?

Как пожелаете. Я, как известно, матом не ругаюсь.
Дискуссия закрыта.

Она даже не начиналась. Дискуссия — это когда один из дискутирующих не игнорирует хотя бы часть вопросов второго дискутирующего.
считать L2 DCI необходимым для виртуальной инфраструктуры настолько, что без этого ну прямо никак.
Между необходимым и предпочтительным есть разница, не улавливаете? Опять, как обычно, фантазируете?

Кроме пространных вопросов типа "… кому нужен L2, когда есть L3?", нецензурных определений и обвинений в некомпетентности от вас ничего не исходит. Из аргументов только рассуждения типа «я так думаю» и ссылки на документы 2007 года. Не сотрясайте эфир, не о чем говорить, все, садитесь, двойка.
Между необходимым и предпочтительным есть разница, не улавливаете?

Циска заявляет, что L2 DCI не является НИ необходимой, НИ предпочтительной фичей для виртуальной инфраструктуры, более того — растянутые L2 сегменты всегда опасны. L2 DCI можно и нужно всеми силами избегать. И, как я уже писал — не верю, что HP для своей собственной инфраструктуры применяет данное решение. Вы ведь так и не поинтересовались у старших коллег, что и как?
Вы, помнится, недоумевали, как же так — виртуальная инфраструктура без спанящихся между площадками L2 сегментов, просили показать… Ну что же, это в вас говорит отсутствие малейшего опыта по этой части. Эх, молодость :)
Кроме пространных вопросов типа "… кому нужен L2, когда есть L3?"

Опять же, все любят L3, и никто не любит L2. Если есть гораздо более красивое L3 решение — зачем руководствоваться устаревшими на десятилетия методиками и растягивать L2 сегменты? От этого все давно отказываются. Раньше — да, маршрутизация требовала ресурсов, желательно было как можно больше коммутировать, сейчас же с L3 свитчами это уже не проблема.
Вы, видимо, предложите при построении территориально распределенной сети из сотен локаций растянуть один VLAN с /20 маской по всем локациям — ибо это VPLS, это модно :)
ссылки на документы 2007 года.

Галлюцинации?
Напомню: в предложенном вами документе открытым текстом писалось «держитесь от L2 DCI подальше». Тот документ, видимо, тоже устарел?
Все-таки учите матчасть. Надоело объяснять настолько банальные вещи, чесслово.
Вы все еще не угомонились? У вас катарсис случится, если показать вам, какого масштаба компании растягивают в своей инфраструктуре VLAN-ы между ЦОД-ами… Всем ясно, что ситуации бывают разные и много таких, в которых L2 DCI предпочтительнее, уже можно больше не подпрыгивать.

L2 DCI не является НИ необходимой, НИ предпочтительной фичей для виртуальной инфраструктуры, более того — растянутые L2 сегменты всегда опасны.
Вот фантазер-то, откуда вы это берете…
Галлюцинации
У вас? Я об этом не подумал, а это многое объясняет…
… в предложенном вами документе открытым текстом писалось «держитесь от L2 DCI подальше».
Это вы вот это "...in some situations, Layer 2 must be extended beyond the single data center..." и вот это "...Such scenarios are becoming more prevalent, as... так перевели? У вас с английским еще хуже, чем с сетями.

Правда, будет уже нудеть «L3 лучше чем L2», ваше мнение все услышали, спасибо. Посчитают нужным — позовут вас строить L3 DCI из балансировщиков.
У вас катарсис случится, если показать вам, какого масштаба компании растягивают в своей инфраструктуре VLAN-ы между ЦОД-ами…

Вы просто не знаете ни одной :) Ну и конечно как всегда не можете назвать ни одной причины для такой архитектуры (ну ладно, помимо «подстраиваться под изначально убогую архитектуру»).
Все-таки поспрашивайте хоть немного соображающих коллег по этому вопросу.
ситуации бывают разные и много таких, в которых L2 DCI предпочтительнее

Только когда серверную инфраструктуру проектировали идиоты. Иных случаев нет.
Вот фантазер-то, откуда вы это берете…

Наверное, из опыта. Рекомендую — полезная штука.
.in some situations, Layer 2 must be extended beyond the single data center

О том и речь — «if the server infrastructure was designed by idiots».
...Such scenarios are becoming more prevalent, as… так перевели?

И снова демонстрируете серьезные проблемы с пониманием письменной речи.
«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. Such scenarios are becoming more prevalent, as high-speed service provider connectivity becomes more available and cost-effective.»
То есть примерно дословно повторяют то, что я говорил. Архитектуру, предназначенную исключительно для одной локации, решают размазать по нескольким. Это и есть идиотизм. При правильно построенной инфраструктуре, которая не «campus», а «distributed», задач, требующих растягивания L2 на сетевом оборудовании, возникнуть не может в принципе.
Что до понравившегося вам слова «prevalent», так правило «95%» никто не отменял. Я совершенно уверен, что как минимум половина компаний как минимум в нашей стране создает статические NAT трансляции наружу на порты SMB и RPC до своих виндовых серверов. Вы, надеюсь, не рекомендуете клиентам так делать на основании «Such scenarios are becoming more prevalent»? Хотя если да — я не слишком удивлюсь. Ребенок без малейшего опыта наверняка не увидит в этом ничего плохого. Удобно же!
позовут вас строить L3 DCI из балансировщиков.

И снова рекомендую изучить абсолютно любую документацию по построению масштабируемых и отказоустойчивых сервисов, а также опыт любой крупной компании. Вы так пугаетесь балансировщиков, потому что никогда с ними не работали. Однако, они используются везде, где хоть чуточку важны те самые «масштабируемость» и «отказоустойчивость». Ну а тех, кто рекомендует клиентам резервировать критические системы между площадками средствами FT или VRRP, я бы на месте вашего руководства увольнял с пометкой «безнадежен».

Для общего развития можете почитать blog.ioshints.info/2011/12/decouple-virtual-networking-from.html.
«VLAN-based virtual networking uses bridging (which doesn’t scale)»
«Hypervisor hosts would appear as simple IP hosts to the transport network»
Вам явно не с кем поговорить. Пять раз уже вам сказали — все, достаточно, разговор закончен. Нет, опять… Видимо, никто в жизни ваши «замечательные идеи» не слушает, вот и ходите по блогам проповедовать L3, пристаете с фантазиями своими. А их у вас немало, каждый раз что-то новенькое :). То причудится, что вам порекомендовали вебсервер резервировать средствами vMotion, то критические системы при помощи VRRP резервировать… Это не вы здесь кричали фальцетом, что OTV позволяет выбрать первый хоп? Вам сказали, что VPLS позволяет сделать также с VRRP. Точка. Дальше идеи в вашей голове причудливо исказились…

И не стройте здесь из себя Гуру, кого-то учить он все порывается… советы кому-то тут еще дает, «Я, на месте руководства ..»… Таких пионеров не то что увольнять, вообще нужно изолировать от ИТ. Иначе они начитаются «передовых идей» из Инета, половину не поймут или поймут не так (как с VRRP или c FT), и начнут ломать инфраструктуру в потраву своему юношескому идеализму.

И опять, все вокруг вас идиоты, один вы знаете, как правильно жить. Как в анекдоте "- Дорогой, будь осторожнее, передали, что там у тебя кто-то едет по встречке. — Дорогая, здесь их тысячи!". Так обычно бывает, когда ситуация ровно обратная. Все нормальные люди, а вот один… Правильно боитесь свою компанию называть. Узнают, что вы тут мелете — прогонят грязными тряпками.

Это мой последний пост вам. Больше не вижу смысла время на вас тратить, бороться с вашими некомпетентностями/недопониманиями, да еще и в таком тоне. Счастливо оставаться в мире фантазий.
Пять раз уже вам сказали — все, достаточно, разговор закончен

Все заметили, что ребенок произносил «разговор закончен» каждый раз, когда его тыкали носом в собственную лужицу, и аргументы кончились? :) А главное, какая ярость, какая обида…
Видимо, я вас приковал к батарее и под дулом пистолета заставляю писать очередные опусы, раз вам никак не удается завершить разговор.
пристаете с фантазиями своими

Ох, как все запущено… Малыш так и не добрался до любого рода документации по построению катастрофоустойчивых сервисов? Жаль.
Это не вы здесь кричали фальцетом, что OTV позволяет выбрать первый хоп? Вам сказали, что VPLS позволяет сделать также с VRRP.

А это лишь одно из преимуществ. Еще OTV, к примеру, рубит лишние броадкасты и unknown unicast'ы, не ломая при этом сервис. Ну-ка расскажите про способности VPLS с любого рода костылями в этом сценарии. Storm-control? Ну я же сказал — не ломая сервис. Вы ведь, надеюсь, в курсе, что любой броадкаст тратит ресурсы гипервизора, а в крупной распределенной нфраструктуре на сотни тысяч виртуалок броадкастов могут быть сотни мегабит?
кого-то учить он все порывается

Да, я пытаюсь научить крайне упертого ребенка, ни дня не работавшего в этой сфере. Вроде не очень удается :(
Правильно боитесь свою компанию называть. Узнают, что вы тут мелете — прогонят грязными тряпками.

Ради интереса — назовите свою компанию, название отдела, свое ФИО и контакты непосредственного руководителя. Я думаю, он очень обрадуется, посмотрев, каким образом его стажер (или сынок стажера, бездумно повторяющий услышанное от отца?) общается с потенциальным клиентом и в каком виде выставляет свою компанию… Я вот например из опыта общения с вами вынес, что сотрудники HP — безмозглые бараны, не умеющие даже читать английским по белому, а их оборудование можно покупать лишь в последнюю очередь — когда все дэлинки на планете закончатся, не говоря уже о хорошем железе. Весь интернет — аналогично.
Это мой последний пост вам.

Принимаются ставки: болезненная гордыня ребенка не позволит ему оставить последнее слово за кем-либо кроме себя :)
Про отказоустойчивость ни слова
Да, ни слова… High-availability clusters это не отказоусточивость…
Да, ни слова… High-availability clusters это не отказоусточивость…

Вы все-таки учитесь читать не только то, что вам нравится, но и остальное.
Some network communication between members of high-availability clusters1 requires some clusters to be Layer 2 (Figure 3):
• Private interprocess communication (such as heartbeat and database replication) used to maintain and control the state of the active node
• Public communication (virtual IP of the cluster)

Смотрим по сноске:
1Cluster vendors (Microsoft, Veritas, Sun, etc.) offer geographical high-availability clusters based on Layer 3 interconnection.

Так кому нужен L2, когда есть L3?
Общение между нодами — как я уже говорил, юникастом или L3 мультикастом. VIP даст балансировщик, заодно предоставив массу других крайне вкусных фич по управлению распределением трафика.
Итого получается, что кластеризация на L2 является решением для бедных и/или умственно ущербных, не осиливших собрать кластер по-человечески. А если серверная инфраструктура изначально дерьмовая, то придется применять не менее дерьмовые решения на уровне сети, например — L2 DCI средствами VPLS.

(разумеется, ожидаю увидеть ниже саркастичный комментарий — не подведите!)
До кучи, про DNS round-robin:

Скрытый текст
C:\>nslookup
Default Server: google-public-dns-a.google.com
Address: 8.8.8.8

> google.com
Server: google-public-dns-a.google.com
Address: 8.8.8.8

Non-authoritative answer:
Name: google.com
Addresses: 2a00:1450:400f:801::1003
173.194.35.198
173.194.35.194
173.194.35.192
173.194.35.193
173.194.35.196
173.194.35.206
173.194.35.199
173.194.35.195
173.194.35.197
173.194.35.200
173.194.35.201

> google.com
Server: google-public-dns-a.google.com
Address: 8.8.8.8

Non-authoritative answer:
Name: google.com
Addresses: 2a00:1450:400f:801::1003
173.194.35.229
173.194.35.232
173.194.35.224
173.194.35.238
173.194.35.231
173.194.35.225
173.194.35.227
173.194.35.228
173.194.35.233
173.194.35.226
173.194.35.230


Как же так — гугл пользуется настолько устаревшей методикой балансировки! Чем они думали? Неужели они глупее некоторых детишек и не догадались, что достаточно выдавать всего один адрес, принадлежащий одному вебсерверу, и каким-то образом резервировать его средствами vmotion? :)
Говорю же, каша… Или это тема с в подростковым оппортунизмом вас как-то больно затронула, вы никак не успокоитесь. Откуда вы взяли эту идею с «резервированием вебсервера средствами vmotion»? Я вам привел ссылку на него просто как пример, зачем может быть нужен L2 DCI, как вы связали эти две вещи?

И что вы привязались к round robin? Еще раз доказать, что вы не дурак и Гугл тоже так делает? Разговор идет про современные технологии, балансировщикам вашим и раун-робину сто лет в обед, всем понятно, как это работает и как это использовать. Вы еще расскажите здесь, как IP работает и что Гугл (вот это да!) его тоже использует. Весь посыл того, что вы говорите, сводится к «нечего пользовать всякие непонятные мне вещи, а давайте делать так, как научила нас Cisco N лет назад».

Один словом — приглашаю вас, 20 сентября следующий технический event для заказчиков. Хотите — приходите (зарегистрироваться только надо), вам там расскажут и про vmotion и про L2 DCI. Нет — больше тратить время на бестолковый разговор смысла не вижу.
Откуда вы взяли эту идею с «резервированием вебсервера средствами vmotion»?

Ну очевидно, что раз «L2 DCI нужен для отказоустойчивости», «L2 DCI нужен для vmotion» и «отказоустойчивость достигается резервированием», то…
Разговор идет про современные технологии, балансировщикам вашим и раун-робину сто лет в обед

А это — недостаток? Это недостаточно модно для молодого поколения?
Весь посыл того, что вы говорите, сводится к «нечего пользовать всякие непонятные мне вещи, а давайте делать так, как научила нас Cisco N лет назад».

О том и речь — с пониманием русского языка у вас проблемы.
вам там расскажут и про vmotion и про L2 DCI.

То есть, как я и писал выше, простой адепт секты не в силах рассказать это, и нужна помощь гуру.
Спасибо, не надо.
Ну очевидно, что раз «L2..
Да, фантазия у вас безгранична, это примерно как про скорое исчезновение понятия «VLAN»

То есть, как я и писал выше, простой адепт секты не в силах рассказать это, и нужна помощь гуру.
Вот смотрите, вы ведете себя как растревоженный подросток в протуберантный период (может, так оно и есть :)?). Я вас лично не трогал, сектантом не называл (хотя вы явный аппологет Cisco и, думаю, «засланный казачок»), пригласил в гости обсудить и посмотреть, вы же несете разную ерунду без разбора и остановки.

Не думаю, что вы услышите мои объяснения, даже если я напишу вам развернутый пост, почему нужен именно L2 DCI, а не все остальные варианты. Таких, как вы, можно убеждать только ткнув носом в очевидное (видимо, недаром, бараны у вас в постоянном лексиконе). Поэтому и пригласил вас посмотреть вживую, на работающее решение. Испугались — понятно. Как достойно отказаться Д'Артаньяну — сказать «да вы секта, а я и так все знаю!». Ну так и до свиданья, нечего тратить электричество и место на Хабре. Читайте дальше сайты Cisco, зомбрируйтесь и живите счатсливо в своих заблуждениях.
Вот смотрите, вы ведете себя как растревоженный подросток в протуберантный период

Вы же очень смахиваете на попугая…
Я вас лично не трогал, сектантом не называл

А я назвал, и даже обосновал, почему. Вы очень смахиваете на представителей свидетелей иеговы, которые сначала пристают, что-то впаривают, а потом, получив несколько крайне неудобных вопросов, переводят стрелки на гуру и предлагают прийти на бесплатную встречу.
Не думаю, что вы услышите мои объяснения, даже если я напишу вам развернутый пост, почему нужен именно L2 DCI
Да хоть пару тезисов. Ни одного не было. Ни намека на то, каким образом L2 DCI повышает отказоустойчивость виртуальной инфраструктуры. Ибо FT — курам на смех, оно не масштабируется и мощно тратит то самое ценное электричество, не защищая примерно ни от чего.
Поэтому и пригласил вас посмотреть вживую, на работающее решение.

Где это?
Вы пригласили посмотреть на стенд. Это не работающее решение. Вот если пригласите посмотреть на реальную боевую инфраструктуру довольно крупной транснациональной корпорации HP — я еще подумаю.
которые сначала пристают,
Вы не забыли, что это вы пришли в блог HP и начали здесь троллить неуклюжим образом? Именно так и ведут себя сектанты, которые свидетели Cisco :)

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

Но я критикую не HP, а решение. Которое реализовано в том числе и у циски. И которое я тоже считаю паршивым (и даже один из client solutions architect'ов, работающих в Cisco, согласен, что L2 между ЦОДами хоть средствами OTV, хоть средствами VPLS — отстой и от этого следует держаться подальше).
Если правда серьезные люди — подумаю, куда вас пригласить.

А не получится. Мы в любом случае не собираемся отказываться от принципа «моновендорная сеть», а тем более выкидывать много сотен единиц сетевого железа. И HP не может предложить абсолютно ничего такого, чего нельзя сделать на цисках. Так что если я и откликнусь на приглашение, то лишь как любопытное частное лицо и не более того, в свободное от работы время. А такого, конечно, никто не пригласит.
Мы в любом случае не собираемся отказываться от принципа «моновендорная сеть»,
Чем больше вы говорите, тем больше понимаю, насколько глубоко вы заблуждаетесь…
Чем больше вы говорите, тем больше понимаю, насколько глубоко вы заблуждаетесь…

Почему же? В той статье единственный нормальный аргумент — цена. Циска любит задирать цены, это всем известны, однако, их цены нас устраивают. Остальное — чушь какая-то.
Нет, зоопарк железа разных вендоров по определению сложнее в поддержке (а значит, опаснее), чем железо одного вендора. Недавно даже статья была про хостера, который полдня валялся в процессе перехода с цисок на жуниперы из-за каких-то проблем в стыковке каких-то протоколов. И вполне вероятно, что суммарный ущерб от простоя превысил стоимость тех самых жуниперов.
Да, если все железо одного вендора — любые комплексные проблемы решаются гораздо быстрее по причине отсутствия футбола со стороны саппорта и наличия мощной документации по любым моментам.
Сравнивая стоимость железа и риски, связанные с простоем инфраструктуры, напрашивается одноначный вывод: переплата при закупке позволит много денег сэкономить в перспективе.
А статья Gartner напомнила мне своим стилем когда-то прочитанную статью «HP начал переходить с цискиного железа на свое собственное! Спустя несколько лет после покупки 3com! Ура!!!».

Скажите — а в HP сейчас чье сетевое железо используется? А то я уже спрашивал, но вы по привычке ушли от ответа.
Так вы предлагаете всем использовать архитектуру Google для построения DC? Автор познакомил читателя с одним из многочисленных инструментов, реализованных в сетевом оборудовании HP. В статье, насколько я понимаю, никто не предлагал использовать этот функционал (да еще на 5800 :) ) в датацентрах масштаба Google.
Так вы предлагаете всем использовать архитектуру Google для построения DC?

В целом, с точки зрения сети все используют нечто похожее. Недавно стало известно, что их железо строится по их заказу, и основным транспортом является вариация на тему MPLS TE. Ну а снаружи балансировщики, тот самый DNS round robin и т.д.
А недавно была статья на тему того, насколько инфраструктура гугла опережает свое время.
В статье, насколько я понимаю, никто не предлагал использовать этот функционал (да еще на 5800 :) ) в датацентрах масштаба Google.

Подход гугла (точнее — всего мира) масштабируется от маленьких ЦОДов до колоссальных. Ваш годится только для маленьких, причем сопряжен с большими рисками (L2 = «single failure domain») и не дает никаких видимых преимуществ. Или дает? Но тогда бы вам удалось сказать хоть что-то кроме общих слов «отказоустойчивость» и «vmotion». Я ведь так и не понял, зачем нужно vmotion'ом таскать машины между площадками.
Жизнь, она ведь цветная, и это замечательно. Автор отметил, что заказчики, требующие L2 между площадками есть. И дискутировать на тему «а зачем» имеет смысл только тогда, когда предложить нечего.

P.S. А в HP вы воплне себе можете получить решение с использованием BigIP от F5 — партнера HP по альянсу One.
Автор отметил, что заказчики, требующие L2 между площадками есть.

Есть. Как я уже говорил, в основном это падкие на маркетинг и не понимающие сетевые вопросы серверные админы, а также бесхребетные сетевики, не умеющие сказать «нет» и в результате наживающие себе проблем на ровном месте.
Ой не скажите! Я, к примеру, видел обратную ситуацию, когда «бесхребетные сетевики» безуспешно отбивались от политических решений по организации L2 коннективити. Я же говорю, жизнь, она прекрасна своим разнообразием :)
Это все же ненормальная ситуация. В нормальной компании за конечными администраторами всегда последнее слово по поводу «внедрять или нет». Никто не может говорить сетевикам, как должна выглядеть их инфраструктура. Если заказчик хочет чего-то такого, что не нравится сетевикам — он идет лесом. Это логично: если плохой дизайн обернется болезненным ударом черенком грабель по лбу, то кто будет за это отвечать?
:) Это мне напомнило фразу: — «Страна, которая открыла человечеству космос не может делать плохие автомобили… но ведь делает». Медицинский факт заключается в том, что заказчики такие есть и их потребности удовлетворять нужно. Могу сказать что лично я года 3 тому назад сначала убеждал что «так делать не нужно», а потом спокойно себе реализовывал то, что попросили.
Извиняюсь, не обратил внимания на то, что в дискуссию включился новый человек, так что сказанное «тогда бы вам удалось сказать» прошу игнорировать :)
Ну вот здесь, например, почитайте, как VRRP Isolation настраивается

О да, известный костыль. Зафильтровать hello пакеты и принудительно сделать dual active. Как я понимаю, других решений нет? И почему в статье про это не сказано?
А 5800-е это умеют? В доках HP почему-то говорится либо про нексусы, либо про 12500-е…
Или вы говорите про MPLS, как там оптимально LSP построить?

Это как раз проблемой не является.
Что еще рассказать про неоптимальные пути?

Допустим, есть 6 ЦОДов, у каждого аплинки в интернет. Надобно сделать так, чтобы пакет снаружи, предназначенный одной из виртуалок, сразу попадал на правильную плошадку и не бегал между ЦОДами. Как это сделать в условиях абсолютного хаоса по части адресации на каждой площадке?
Для этого на CE запускают STP, используют storm control, loop protection, механизмы управления MAC в VPLS…

Ни один из этих механизмов не гарантирует отсутствия петли.
Как это все, в вашем понимании, должно работать?

Вы в курсе, что, к примеру, даже встроенный в vSphere свитч не выпустит наружу пакет, пришедший не от него собственной виртуалки? А ведь еще при использовании свитча в гипервизоре вполне можно отказаться и от mac learning… Хотя да, букву «u» в uRPF следует считать скорее опечаткой, допущенной по привычке.
Теоретически, это можно реализовать и на физической инфраструктуре, но тут требуется навороченный оркестратор, и о подобных решениях я пока не слышал.
Куда исчезнет понятие «VLAN» (видимо, заодно и понятие «broadcast»)?

Очевидно — с физической инфраструктуры. Броадкаст, посланный с виртуальной машины, с точки зрения физического транспорта превращается в L3 мультикаст. Все довольны.
Если знаете — зачем спрашиваете?

Я хочу услышать сценарий, при котором это потребуется. А то ведь данная технология — натуральный маркетинговый буллшит, ориентированный на не привыкших думать своей головой серверных админов и на бесхребетных сетевиков.
Действительно, проще загасить виртуальную машину, перелить ее по FTP, засинхронизировать руками настройки и запустить.

Вы действительно не можете понять простой вопрос?
Поставлю вопрос еще проще: зачем переносить виртуальную машину с площадки на площадку, тем более без смены адреса, тем более без ее остановки?
Подброшу один из распространенных вариантов ответа: disaster recovery. Вы согласны, что это имеет смысл, или нет? Если да, то опишите, как это будет выглядеть.
С вас другие сценарии.

(vsphere вполне позволяет копировать диски с датасторы на датастору, и более того — так как диски обычно хранятся в SAN, репликацию стоит делать именно средствами SAN. Но зачем?)
Я хочу услышать задачу, оптимальным решением которой будет миграция виртуалок с площадки на площадку
К чему этот вопрос? Хотите сказать, что миграция не нужна? Так расскажите, как вы управляете виртуальной инфраструктуру, может и правда, у вас есть идеи лучше. Или это такой способ самообразовываться — задать вопрос с вызовом, чтобы вам сразу объяснили, как это делается?

FT — это пять… Ни разу в жизни не слышал о том, чтобы кто-то на практике им пользовался.

Если вы не слышали, это не значит, что им не пользуются. Приходите к нам на семинары, на курсы, проведем ликбез по инфраструктуре современного ЦОД
О да, известный костыль

Так это вы про него вспомнили, не я. Вам вроде нравилось, что OTV умеет так делать, а VPLS, как вам показалось, нет.
Как это сделать в условиях абсолютного хаоса
"- Доктор, когда я делаю ТАК, у меня болит ЗДЕСЬ, как мне быть? — А вы не делайте." Я говорил уже, проблема не клозетах, а в головах. Нужно хаос привести в порядок и дизайн инфраструктуты сделать по-человечески, тогда все станет на свои места. И костыли, глядишь, не понадобятся.
Теоретически, это можно реализовать и на физической инфраструктуре
Чувствуется, что вы теоретик

Скажите, что вы всем этим пытаетесь донести? Что ЦОД не надо соединять по L2? Что броадкаст скоро превратится в L3 мультикаст, VLAN-ов не будет и L2 в ЦОД тоже не будет? Что vmotion не нужен, а нужно как-то реплицироваться средствами SAN? Вы предложите что-то реально конструктивное, не ваши теоритические мечтания, а практический опыт — вот я делаю так, у меня получается вот это и это хорошо потому и потому, а то, что вы предложили, плохо потому и потому. Пока все, что я от вас услышал — это горячее желание доказать, что L2 DCI не годится, а надо как-то иначе. Как и почему — не внятно, какое-то кидание из темы в тему и приплетание, в основном не к месту, аббревиатур и технологий.
Вам вроде нравилось, что OTV умеет так делать, а VPLS, как вам показалось, нет.

Так VPLS не умеет. Ломание VRRP — паршивое решение. Броадкасты продолжают бегать. Невозможность оптимальной маршрутизации внешнего трафика остается.
Нужно хаос привести в порядок и дизайн инфраструктуты сделать по-человечески, тогда все станет на свои места. И костыли, глядишь, не понадобятся.

Об этом я с самого начала и говорю. При нормальном дизайне инфраструктуры L2 DCI по определению не нужен.
Скажите, что вы всем этим пытаетесь донести? Что ЦОД не надо соединять по L2?

Конечно. Вы ведь так ни слова и не сказали, зачем оно надо. Ну кроме того, что хочется vmotion ради самого vmotion. Видимо, хорошее развлечение — таскать одну и ту же машину туда-обратно :)
Вы предложите что-то реально конструктивное, не ваши теоритические мечтания, а практический опыт

Чуть выше написал.
Однако… Разве то, что я описал, не очевидно?
Если человек настолько безумен, что реализует отказоустойчивость сервиса средствами того же FT и полагается на vmotion вместо нормальной кластеризации на уровне приложения… Ну что же, операторы связи и производители сетевого железа, а также любого рода маркетологи таких обожают, а вот работодатели ненавидят.
Так VPLS не умеет.
Вы, прежде, чем что-то утверждать, проверьте это или, на крайний случай, почитайте, что пишут в документах, дал же вам ссылку
Вы ведь так ни слова и не сказали, зачем оно надо.
Да, есть такая метода, не слышать то, что в контексте спора не выгодно, сказал и уже не раз — построение отказоустойчивой виртуальной среды.
Если человек настолько безумен, что реализует отказоустойчивость сервиса средствами того же FT и полагается на vmotion вместо нормальной кластеризации на уровне приложения…
Еще раз, не считайте себя умнее всех на свете и попробуйте реализовать свои замечательные идеи руками. Тогда каши в голове будет меньше, понимания технологий больше, а вендоры перестанут казаться врагами.
Вы, прежде, чем что-то утверждать, проверьте это

Вы ведь понимаете, что слово «VPLS» можно заменить на слово «транк», и ровным счетом ничего не поменяется?
сказал и уже не раз — построение отказоустойчивой виртуальной среды.

А я еще раз спрашиваю — каким образом с помощью L2 DCI повысить отказоустойчивость виртуальной среды? Неужели в той брошюрки на тему «как впарить клиенту ненужное» не было про это сказано? Или Вы действительно не понимаете русскую речь?
Ну например скажите «если через полчаса ЦОД будет обесточен, то можно успеть смигрировать десятки тысяч виртуалок на другую площадку без их остановки». Верно?
попробуйте реализовать свои замечательные идеи руками.

Выше я писал про полностью рабочее решение, внедренное на практике и у нас, и почти везде, где важна катастрофоустойчивость. И, как и примерно везде, это решение не подразумевает растягивания L2 между площадками. При этом защищая как от падения отдельных серверов (в том числе вызванного программными причинами), так и от падения ЦОДа целиком.
Так что закройте свою маркетинговую брошюрку и хоть краем глаза ознакомьтесь с надежными, проверенными, безопасными решениями.
Думаю, градус дисскусии уже зашкаливает, пора ее заканчивать. Вам последний совет — бросьте заниматься эманацией подростковой агрессии в Инет и займитесь своим образованием. От этого лексикон поправится (а то говорите, как в ненавидимых вами брошюрах — «ознакомьтесь с надежными, проверенными, безопасными решениями»), а реальных знаний прибавится.
А можно глупый вопрос. Не холивара ради, а для прояснения.

Вы вот говорили, что L2 через тунели не суть, главное что это L2 и для упрощения картинки это можно представить просто 802.1Q транком или QinQ на худой конец для большей приближенности к реалиям операторского эзернета в масштабах города, например.
Это понятно.
А почему VXLAN чем-то выделяется из этих способов, ведь это просто один из вариантов тунеля, виртуальный патчкорт будет сделан немного по-другому, но это будет все тот же L2, просто по-другому обернутый. Или я что-то недопонимаю?
А почему VXLAN чем-то выделяется из этих способов

VXLAN и тому подобные технологии — это оверлеи поверх IP, с точки зрения которых все виртуалки фактически подключены к одному общему свитчу. Для низлежащего транспорта (который не обладает интеллектом по части L2 и работает лишь по типовым для ethernet методам «mac learning», «unknown unicast flooding» и т.д.) весь трафик становится L3. А гипервизорные свитчи уже имеют мозги — они могут четко знать, на каком хосте находится получатель пакета.
В результате:
1) Радикально снижена вероятность L2 кольца, убийцы ЦОДов (в принципе, без специальных манипуляций с виртуалками вроде поднятия туннеля и создание бриджа между туннелем и реальным интерфейсом я вообще не представляю себе, как его добиться).
2) Ограничено распространение броадкастов (лишняя нагрузка на трансмиссии и на хосты — десятки/сотни мегабит мусора уже могут дать более-менее заметную нагрузку)
3) Ограничено распространение unknown unicast'ов.
Все это действует не только между площадками, но и в пределах площадки.

В общем и целом, если коротко, «оверлей» означает «повышение интеллекта подсистемы передачи данных» и избавление от части недостатков ethernet. В теории.
Хотя опять же, даже при этом непонятно, зачем нужно спанить один L2 по нескольким площадкам — но тут хоть получаем действительно гибкое, безопасное и легко масштабируемое решение.

Есть, кстати, вариант «тянем VPLS прямо между портами отдельных гипервизоров», но это уже совершенно иной разговор.
Правильно ли я понял, что VXLAN — это тунель, точка терминации которого — гипервизор и/или его виртуальная инфраструктура, что позволяет на реальном сетевом железе ЦОДа минимизировать L2, другие же варианты — тоже тунели, но от границ реальной сети ЦОДа, которая при этом вынуждена быть L2?
VXLAN — это тунель, точка терминации которого — гипервизор

Да, примерно так. Вплоть до полного отказа от L2 на физическом железе (L3 до каждого гипервизора).
На самом деле, не суть важно, VXLAN ли это, либо NVGRE, STT или тому подобное. Речь про саму концепцию.
другие же варианты — тоже тунели, но от границ реальной сети ЦОДа, которая при этом вынуждена быть L2?

Если говорить об озвученных вариантах, то тоже да. Свой VPLS дает некоторые преимущества по сравнению с операторским VPLS/EoMPLS или даже прямым транком по темному волокну, но принципиальных отличий нет. Создаваемые гипервизором оверлеи поверх IP отличаются радикально.
Я уже давал выше ссылку на краткий обзор по этой теме: blog.ioshints.info/2011/12/decouple-virtual-networking-from.html. Прямой транк по не-важно-как-сделанному операторскому коннекту между площадками либо терминируемый на своем оборудовании VPLS (речь про периметр, как предложено в топике) — они оба относятся к «VLAN-based solutions».
Пепельняк, кстати, очень много чего интересного пишет по части современных подходов к созданию ЦОДов — он внимательно следит за этой областью, и многие вендоры делятся с ним информацией по грядущей продукции. Я с ним далеко не всегда согласен, но вот по «L2 DCI = отстой» мы оба одинаково категоричны в своих мнениях. Так делать не надо.
Вот, нашел веселые картинки

www.cisco.com/web/UA/virtualization/downloads/1-2_Virtual_Network_vForum_2012_vpodkory.pdf

В конце доклада есть про VXLAN. В этом, имхо, у автора статьи, дискутирующего с вами так рьяно или непонимание или целенаправленное забалтывание вопроса. В каком-то смысле его возглас "чего стоит одна только фантасмагория об отказе с помощью vxlan, stt и uRPF от L2 в ЦОД!" оправдан, если смотреть на вопрос совсем уж общё (но вы этого смысла и не вкладывали, что он, возможно честно, не понимает). А если по существу — то весь вопрос в границе L2. В презенташке видно, что граница по Nexus 1000V проходит. Значит L2 не выходит за границы логических/программных сетей VM. Конечно, раз всяким там vMotion L2 надо, совсем не быть его не может, но в данном случае он (L2) виртуализуется.
если смотреть на вопрос совсем уж общё

А я действительно смотрю на вопрос достаточно общё. На данный момент все виды оверлеев имеют свои недостатки, но у них есть ключевой общий момент: полная виртуализация L2. Потому я говорю не столько про конкретный протокол «VXLAN», сколько про саму концепцию оверлея, которая (при наличии по каким-либо причинам необходимости в растягивании L2 по разным площадкам) работает оптимально, да и даже в пределах одной площадки у нее масса преимуществ перед традиционным «L2 на сетевом железе».
раз всяким там vMotion L2 надо

Сам vMotion (между площадками) не нужен. Действительно не нужен. При грамотном дизайне сервисов необходимость в этом не возникнет никогда.
«vMotion между локациями» радикально отличается от «vMotion в пределах локации». Последний крайне полезен, если нужно вывести хост из эксплуатации — это. А первый? Когда весь ЦОД отключается? Это не просто глупость, это невыполнимо. Если авария уже случилась, то как-то и нечего мигрировать. Если авария вот-вот случится (ну например вводы питания обесточены, бензовозы застряли в пробке, дизеля осталось на полчаса), то времени не хватит перетащить даже несколько десятков виртуалок.
Даже гиганты вроде Amazon не предоставляют возможности перемещать машины между площадками с сохранением адреса (насколько я знаю). Хотя тут скорее не «даже», а «особенно».
Я вот тоже задавался вопросом целесообразности. Ну ладно там — миграция на время обслуживания гипервизоров или еще там какие подобные вещи. Но ЦОДы разделенные WAN или чем-то похожим — это как правило катастрофоустойчивость, по логике. Пожар там, терракт, обрушение здания. Там мигрировать будет поздно. Значит нужен другой подход, постоянная готовность в ЦОДе 2 и изначальный дизайн всех систем, на это рассчитанный. Другой вопрос, что не для всех сервисов все так просто. Но с другой стороны. Если реально происходит катастрофа уровня «ЦОД погребен под обломками» нереальными понтами выглядит ситуация, что кто-то, начиная от юзеров и кончая вип-руководством останется недоволен, что переход произошел не совсем бесшовно. Типа там сеессия отвалилась, из приложения ненадолго выкинуло. Да даже если админу вручную придется стартовать виртуалки (при улосвии актуальных за счет постоянной синхронизации данных на СХД).
постоянная готовность в ЦОДе 2

Выбрасывание ресурсов в трубу — вот как можно назвать FT. Крайне дорогое удовольствие, которое не предотвратит большинство аварий.
ЦОДы должны работать по схеме active/active.
не для всех сервисов все так просто.

Конечно. Это требует более качественной работы архитекторов приложений.
нереальными понтами выглядит ситуация, что кто-то, начиная от юзеров и кончая вип-руководством останется недоволен, что переход произошел не совсем бесшовно. Типа там сеессия отвалилась, из приложения ненадолго выкинуло.

Я не могу представить себе ни одной компании, где есть такое требование к инфраструктуре. Это невыполнимо. Что бы ни было настроено во внутренней сети, но уж с тормознутостью глобальной маршрутизации не удастся побороться никакими средствами. При отказе одной площадки кто-то отвалится всегда.
(если мы говорим о тех приложениях, которые не обладают способностью знать о существовании нескольких нод и бесшовно для пользователя переключаться между ними)
Ну в том смысле, что L2 не выходит за границы в чистом виде. В тунелированном-то конечно выходит.
Так автор вроде и не предлагает IRF между площадками.
Only those users with full accounts are able to leave comments. Log in, please.