Так это вы про него вспомнили, не я. Вам вроде нравилось, что OTV умеет так делать, а VPLS, как вам показалось, нет.
Как это сделать в условиях абсолютного хаоса
"- Доктор, когда я делаю ТАК, у меня болит ЗДЕСЬ, как мне быть? — А вы не делайте." Я говорил уже, проблема не клозетах, а в головах. Нужно хаос привести в порядок и дизайн инфраструктуты сделать по-человечески, тогда все станет на свои места. И костыли, глядишь, не понадобятся.
Теоретически, это можно реализовать и на физической инфраструктуре
Чувствуется, что вы теоретик
Скажите, что вы всем этим пытаетесь донести? Что ЦОД не надо соединять по L2? Что броадкаст скоро превратится в L3 мультикаст, VLAN-ов не будет и L2 в ЦОД тоже не будет? Что vmotion не нужен, а нужно как-то реплицироваться средствами SAN? Вы предложите что-то реально конструктивное, не ваши теоритические мечтания, а практический опыт — вот я делаю так, у меня получается вот это и это хорошо потому и потому, а то, что вы предложили, плохо потому и потому. Пока все, что я от вас услышал — это горячее желание доказать, что L2 DCI не годится, а надо как-то иначе. Как и почему — не внятно, какое-то кидание из темы в тему и приплетание, в основном не к месту, аббревиатур и технологий.
Я хочу услышать задачу, оптимальным решением которой будет миграция виртуалок с площадки на площадку
К чему этот вопрос? Хотите сказать, что миграция не нужна? Так расскажите, как вы управляете виртуальной инфраструктуру, может и правда, у вас есть идеи лучше. Или это такой способ самообразовываться — задать вопрос с вызовом, чтобы вам сразу объяснили, как это делается?
FT — это пять… Ни разу в жизни не слышал о том, чтобы кто-то на практике им пользовался.
Если вы не слышали, это не значит, что им не пользуются. Приходите к нам на семинары, на курсы, проведем ликбез по инфраструктуре современного ЦОД
Я хочу услышать задачу, оптимальным решением которой будет миграция виртуалок с площадки на площадку
К чему этот вопрос? Хотите сказать, что миграция не нужна? Так расскажите, как вы управляете виртуальной инфраструктуру, может и правда, у вас есть идеи лучше. Или это такой способ самообразовываться — задать вопрос с вызовом, чтобы вам сразу объяснили, как это делается?
FT — это пять… Ни разу в жизни не слышал о том, чтобы кто-то на практике им пользовался.
Если вы не слышали, это не значит, что им не пользуются. Приходите к нам на семинары, на курсы, проведем ликбез по инфраструктуре современного ЦОД
Ну так расскажите, как в предложенном сценарии реализовать правильный выбор первого хопа для каждой площадки.
Вроде бы, говорил уже в предыдущем посте, используйте для этого стандартные средства, 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 , кластеры разные…
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 на 2-м уровне. И Cisco с OTV и FabricPath-ом, и Juniper c VPLS, и HP с VPLS и EVI, и все остальные, поддерживающие TRILL, SPB/PBB… Видимо, только Вы уловили тренд. Еще интереснее предложение отказаться от L2 в рамках одного ЦОД. Хочется услышать, как именно вы предлагаете это сделать…
Относительно того, что случится, если произойдет split стэка — варианты могут быть разные. Если настроен MAD, одно из устройств в развалившемся стэке до перезагрузки погасит все порты (чтобы не было в сети двух с одинаковыми параметрами, MAC и т.д.). При этом, трафик будет спокойно идти через второе устройство. Вы что-то видимо недопоняли (или я в статье нечетко выразил). Ситуации, когда, как вы выразились, «control plane активного супервизора слегка заглючит» и «лягут все площадки», здесь быть не может.
Так это вы про него вспомнили, не я. Вам вроде нравилось, что OTV умеет так делать, а VPLS, как вам показалось, нет.
"- Доктор, когда я делаю ТАК, у меня болит ЗДЕСЬ, как мне быть? — А вы не делайте." Я говорил уже, проблема не клозетах, а в головах. Нужно хаос привести в порядок и дизайн инфраструктуты сделать по-человечески, тогда все станет на свои места. И костыли, глядишь, не понадобятся.
Чувствуется, что вы теоретик
Скажите, что вы всем этим пытаетесь донести? Что ЦОД не надо соединять по L2? Что броадкаст скоро превратится в L3 мультикаст, VLAN-ов не будет и L2 в ЦОД тоже не будет? Что vmotion не нужен, а нужно как-то реплицироваться средствами SAN? Вы предложите что-то реально конструктивное, не ваши теоритические мечтания, а практический опыт — вот я делаю так, у меня получается вот это и это хорошо потому и потому, а то, что вы предложили, плохо потому и потому. Пока все, что я от вас услышал — это горячее желание доказать, что L2 DCI не годится, а надо как-то иначе. Как и почему — не внятно, какое-то кидание из темы в тему и приплетание, в основном не к месту, аббревиатур и технологий.
Если вы не слышали, это не значит, что им не пользуются. Приходите к нам на семинары, на курсы, проведем ликбез по инфраструктуре современного ЦОД
Если вы не слышали, это не значит, что им не пользуются. Приходите к нам на семинары, на курсы, проведем ликбез по инфраструктуре современного ЦОД
VRRP Isolation
High Availability
Fault Tolerance,
Вроде бы, говорил уже в предыдущем посте, используйте для этого стандартные средства, 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» (видимо, заодно и понятие «broadcast»)? Причем здесь unicast Reverse Path Forwarding, если вы про него (да еще и на L2)? Как это все, в вашем понимании, должно работать? Вы уж объяснитесь, а то правда, как в старом кино…
Если знаете — зачем спрашиваете? Действительно, проще загасить виртуальную машину, перелить ее по FTP, засинхронизировать руками настройки и запустить.
Вообще, зачем компании ЦОД, да еще и 2 площадки? Сидели бы все из дома на 2400 baud с UUCP и были счастливы, нет, придумывают всякую ерунду, business continuity, cloud computing, High Availability, Fault Tolerance , кластеры разные…
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.
Относительно того, что случится, если произойдет split стэка — варианты могут быть разные. Если настроен MAD, одно из устройств в развалившемся стэке до перезагрузки погасит все порты (чтобы не было в сети двух с одинаковыми параметрами, MAC и т.д.). При этом, трафик будет спокойно идти через второе устройство. Вы что-то видимо недопоняли (или я в статье нечетко выразил). Ситуации, когда, как вы выразились, «control plane активного супервизора слегка заглючит» и «лягут все площадки», здесь быть не может.