Речь не про хранилища (базы данных и прочее), а про системный раздел виртуалки. Он обычно небольшой и статичный у практически любой системы. А вот память у нагруженной виртуалки по идее меняется настолько быстро, что и 5гб/с может хватить с трудом.
В указанном пункте диски уже единые между двумя ЦОД, так что переместить необходимо только данные в памяти вирт. машины — это единицы гигабайт.
Так и диски обычно не сказать чтобы большие… Диски статичны, в отличие от памяти.
Но спору нет, при наличии 40G езернета live migration единичных машин не проблема. Вопрос — в том распределенном ЦОДе на практике таскали рабочие машины между площадками?
Demon Hunter 23 уровня. Ни малейших глюков. Ностальгия. Хотя да, Diablo сильно изменился. Не могу сказать, в лучшую сторону или в худшую, он просто стал другим.
[blockquote]ну если географически распределенный — это стойки в соседних комнатах с двумя 10Gb линками между блейдовыми свитчами…[/blockquote]
Да, в таких условиях можно перетаскивать виртуалки без их остановки, не спеша, по две-три :)
Если эти серверы виртуальные – начинает работать Live Migration виртуальных машин и можете «на ходу» переводить задачи между ЦОДами
Live Migration между ЦОДами — в теории круто, на на практике слабо выполнимо. Уж больно колоссальные у него требования к пропускной способности сети даже при штатном запуске. А резко перетащить сотню виртуалок на другую площадку методом live migration вообще невозможно, это потребует сотен гигабит емкости между площадками. Проще уж застопить машину и переместить ее диски. А при постоянной репликации СХД и диски тащить не надо, просто подмапил LUN на другом гипервизоре и вперед. А при грамотном использовании балансировщиков падение одной площадки целиком может вообще не потребовать никаких телодвижений. Но такое редко удается сделать.
Ну и L2 DCI (безусловное требование для любых видов VM mobility) — нечто, от чего лучше держаться подальше, если только в нем нет абсолютной необходимости (а обычно ее нет). Не очень здорово даже когда один VLAN растянут на целый ЦОД.
Понятия не имею про SWITCH, я когда-то BCMSN сдавал. Но тогда данный экзамен был не архитектурным, а техническим. Думаю, с тех пор мало что изменилось. И крайне сомневаюсь, что в SWITCH будут вопросы про VSS/vPC, ибо у человека, не администрирующего 6500/N5k, мало шансов потрогать эти технологии.
Более надежным решением тут видится создание топологии беспетельной от природы с использованием Vlan per port например или Private VLAN.
На 4500-м каталисте с 300 портами, с текущей конфигурацией по 48 портов на VLAN, по VLANу на порт? Издеваетесь? Большего бреда в жизни не слышал. Мы вроде как о корпоративной сети говорим, а не о провайдере. И думаю, понятно, почему и private vlan идет лесом по определению.
Еще как ненадежный вариант — portfast trunk
Еще одна глупость. Portfast trunk — тот же обычный portfast, предназначенный для подключения транком конечных устройств, не знающих про STP и неспособных создать петлю. Например, гипервизора. Или роутера с сабинтерфейсами. Но и у гипервизора может поехать крыша, и если он вдруг объединит в бридж оба порта — будет network meltdown по моему сценарию. Где-то про такое писали, у кого-то такое было.
При условии что продавленный арп-штормом control-plane с другой стороны будет в состоянии отправить этот BPDU например.
А вот про это в доках не говорится ни явно, ни намеками. И не каждый догадается, что на обработку BPDU может и не хватить ресурсов.
И что этот BPDU не дропнется на перегруженном порту еще до того как он дойдет до процессора.
Дропнется в направлении «in» на перегруженном порту? Любопытно… А на отправку у него и так безусловный приоритет. Иначе типичный congestion обернулся бы кошмарным расколбасом по всей сети, с постоянными перестроениями топологии.
Нигде не написано что максимальное время броадкаст-шторма при включенном portfast на портах и запетлявшей топологии = 2с. Зачем же это додумывать?
Написано, что порт при получении BPDU проходит через нормальный процесс STP. «Максимум 2 секунды» подразумевается. Не будут же они как для идиотов все разжевывать.
У каждой технологии есть границы применимости, соответственно их нужно либо не нарушать, либо не использовать технологию.
Вы предложили две совершенно бредовые альтернативы.
И уж конечно перед рассмотрением других технологий следует хорошенько изучить первоначальную ;) Например, поставить везде storm-control broadcast level 1 — и сеть при шторме не упадет, будут лишь маленькие глючки с полагающимися на броадкаст сервисами (ARP, DHCP), да и то вряд ли — ресурсы свитча не будут исчерпаны, и он спокойно положит закольцованные порты.
«Не нарушать»? Это никуда не годится. Надо сделать так, чтобы и при кратковременном нарушении ничего плохого не происходило. А для этого для начала надо хорошо знать матчасть.
Вы ведь даже не знали, что portfast'овый порт рассылает BPDU :)
И не вздумайте на собеседовании говорить «а давайте каждому по VLANу создадим»…
А есть альтернативы? Вы сможете, к примеру, обеспечить работу заливки по PXE без portfast? Нет? Значит, исходим из того, что portfast — данность, от которой следует отталкиваться. Но если пользователь соединит патч-кордом две розетки и сегмент ляжет минут на 10, то виноват будет не пользователь, а сетевик. И даже заклинание «spanning-tree portfast bpduguard default» делу не поможет.
Еще раз. В документации по portfast'у где-то пишется, что после получения BPDU порт моментально переходит в blocking, а затем проходит через нормальный процесс STP. И кольцо должно возникнуть максимум на 2 секунды, что называется не «катастрофа», а «инцидент, который скорее всего останется незамеченным». Я же говорю, что на практике все может быть куда хуже. И мало кто об этом знает. В курсе BCMSN (который Вы явно пропустили, судя по «portfast не рассылает BPDU» :) ) про такой исход дела ни слова не было.
Вы сами отключии защиту от дурака
Ну вот представим себе, что portfast на порту абсолютно необходим. Некая система не может ждать по полминуты после поднятия линка. Выходит, кто-то соединил два порта — и приплыли…
Получается, portfast у вас на access портах отключен, раз там bpdu летят?
Вы путаете portfast с bpdufilter.
#show spanning-tree interface fa4/10 detail
Port 202 (FastEthernet4/10) of VLAN0200 is designated forwarding
Port path cost 19, Port priority 128, Port Identifier 128.202.
Designated root has priority 32968, address 001a.a18b.bec0
Designated bridge has priority 32968, address 001a.a18b.bec0
Designated port id is 128.202, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 0 The port is in the portfast mode
Link type is point-to-point by default
Bpdu guard is enabled by default BPDU: sent 1099568, received 0
Вот здоровый аксессный порт. Если соединить его с fa4/11, то с вероятностью 99,999% fa4/10 уйдет в blocking, сразу после получения BPDU, и пользователи ничего не заметят.
Еще раз — should only be enabled on ports connected to a single host. А сдуру можно много чего сломать…
Если человек полагается на «авось», т.е. надеется на то, что никто не соединит соседние порты патч-кордом, то ему вообще нечего делать в IT. Необходимо заранее предусмотреть любые возможные сценарии, ведущие к аварии, и предпринять меры по недопущению как можно большего числа этих аварий. И всегда исходить из того, что пользователь — идиот; вспышки на солнце происходят каждый день; глюк в софте на сетевом железе случается раз в два дня и т.д.
Вы же явно сторонник подхода «если система падает от чиха, то надо запретить чихать, а не устранить источник влияния чиха на стабильность». Так не бывает.
«can cause temporary bridging loops»
Именно что скорее «constant». Циска на моей памяти не говорила, что подобный луп может вынести весь L2 сегмент до того момента, когда администратор руками разъединит кольцо, а не на 2 секунды до первой BPDU.
Мне на самом деле тогда сильно «повезло». Местный умудрился попасть в 2 из 4-х портов, в которые попадать было нельзя.
«вы включили portfast там где включать его было нельзя»
Немного неправильный подход. Сеть должна быть отказо- и дуракоустойчивой. То есть вытыкание или втыкание любого проводка не должно приводить к катастрофе. А то получается на «попал в аварию и не сработала подушка» ответ «не надо было попадать в аварию».
У нас на пользовательском аксессе раз в пару месяцев BPDU guard блокирует порты, потому что кто-то умный втыкает торчащий из розетки патч-корд в соседнюю розетку. Суть моего комментария сводится к тому, что не следует полагаться на механизмы STP в этом случае. Ну ладно, на пользовательском порту можно сказать «sw port-security max 3», это должно помочь, а вот в виртуализированном ЦОДе с этим куда сложнее. Потому всегда нужны дополнительные меры защиты. Но: они не всегда поддерживаются. Взять Nexus 2000 — у них нет никакого storm control. То есть кто-то соединил соседние порты патч-кордом, и минимум кусок сети с большой вероятностью лег.
В комментариях нешуточные дебаты.
Да там даже обсуждать нечего. Любой, кто говорит, что STP хорош хоть чем-то кроме дешевого решения для организации базовой избыточности либо в качестве предохранителя, является ослом.
Хотя смотрю, кому-то хватило мозгов сделать no spanning-tree vlan X, раз как бы теоретически колец нет. Ну-ну… Никто ведь не говорит, что STP надо отключать. Просто он не должен ничего никогда блокировать кроме как на полминуты максимум при появлении физики.
И еще момент. Хорошая сеть — та сеть, где вообще нет STP колец, и ни один линк не блокируется, с сохранением полной отказоустойчивости (STP задействован лишь в качестве предохранительного механизма). Обычно используют агрегацию линков плюс технологии, позволяющие завязать один port-channel на двух или более разных шасси (стеки на 3750, VSS на cat6500, vPC на нексусах и т.д. — у каждого вендора есть нечто подобное). Хардкор — полноценный роутинг на L2, TRILL и протоколы на его основе (у циски — Fabricpath). Но его пока мало где встретишь, и то кроме ЦОДов он нигде не используется.
Не заметил один момент, совершенно критический, и почему-то игнорируемый во всех курсах циски.
Portfast на нагруженных свитчах смертельно опасен!
Суть в следующем.
1) На любых коммутаторах BPDU обрабатываются программно.
2) Частота рассылки BPDU — по дефолту 2 секунды.
3) При втыкании патч-корда порт переходит в forwarding мгновенно.
По меркам коммутатора, через который проходит много (десятков) гигабит, 2 секунды — вечность. За это время мозги свитчу выносятся напрочь, и он уже не может загасить порт (errdisable в случае BPDU Guard или просто stp blocking — неважно), ресурсов для обработки BPDU нет, ибо большинство броадкастов в сети — ARP пакеты, долетающие до CPU свитча. И вот у нас шторм по всему L2 сегменту, который не хочет прекращаться сам по себе.
Это не голая теория, я сам однажды на это нарвался (как дебил сказал человеку «воткни новый свитч в любые два порта»).
Понятно, что на аксессной пользовательской железке с парой сотен мегабит и 100мб интерфейсами до пользователей такая катастрофа маловероятна, я больше про ЦОДы говорю.
Потому ОБЯЗАТЕЛЬНО задействовать Storm Control везде, где только можно. Он реализован аппаратно, и он позволяет коммутатору успешно работать и при шторме. Ведь один из самых мерзких моментов шторма — то, что и добраться до самого свитча при отсутствии out-of-band management крайне непросто.
Кстати — как минимум cat6500 прекрасно отзывается по консоли даже когда шторм выжрал все ресурсы.
Вы статейку-то читали про то, что в айфоне фактически реализовано «приложил палец к экрану => весь мир встал на паузу»? Я с радостью готов пожертвовать, к примеру, плавностью скроллинга грузящейся страницы ради того, чтобы она грузилась быстро. Мне не нужна система, в которой UI вытесняет всё остальное из очереди.
Многомода действительно стоит копейки.
Зачем одиночному серверу 40G? Он и гигабит-то редко когда займет.
Так и диски обычно не сказать чтобы большие… Диски статичны, в отличие от памяти.
Но спору нет, при наличии 40G езернета live migration единичных машин не проблема. Вопрос — в том распределенном ЦОДе на практике таскали рабочие машины между площадками?
Хорошо быть в отпуске :)
hobosti.ru/news/2012/05/diablo
Да, в таких условиях можно перетаскивать виртуалки без их остановки, не спеша, по две-три :)
Live Migration между ЦОДами — в теории круто, на на практике слабо выполнимо. Уж больно колоссальные у него требования к пропускной способности сети даже при штатном запуске. А резко перетащить сотню виртуалок на другую площадку методом live migration вообще невозможно, это потребует сотен гигабит емкости между площадками. Проще уж застопить машину и переместить ее диски. А при постоянной репликации СХД и диски тащить не надо, просто подмапил LUN на другом гипервизоре и вперед. А при грамотном использовании балансировщиков падение одной площадки целиком может вообще не потребовать никаких телодвижений. Но такое редко удается сделать.
Ну и L2 DCI (безусловное требование для любых видов VM mobility) — нечто, от чего лучше держаться подальше, если только в нем нет абсолютной необходимости (а обычно ее нет). Не очень здорово даже когда один VLAN растянут на целый ЦОД.
Для решения архитектурных вопросов следует выйти за рамки сертификаций и читать SRND, где куда более актуальная информация. Вот например про «отказ от STP»:
www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_3_0/DC-3_0_IPInfra.html#wp1044510
Да и вообще советую прочитать всю эту статью, там много полезной информации.
На 4500-м каталисте с 300 портами, с текущей конфигурацией по 48 портов на VLAN, по VLANу на порт? Издеваетесь? Большего бреда в жизни не слышал. Мы вроде как о корпоративной сети говорим, а не о провайдере. И думаю, понятно, почему и private vlan идет лесом по определению.
Еще как ненадежный вариант — portfast trunk
Еще одна глупость. Portfast trunk — тот же обычный portfast, предназначенный для подключения транком конечных устройств, не знающих про STP и неспособных создать петлю. Например, гипервизора. Или роутера с сабинтерфейсами. Но и у гипервизора может поехать крыша, и если он вдруг объединит в бридж оба порта — будет network meltdown по моему сценарию. Где-то про такое писали, у кого-то такое было.
При условии что продавленный арп-штормом control-plane с другой стороны будет в состоянии отправить этот BPDU например.
А вот про это в доках не говорится ни явно, ни намеками. И не каждый догадается, что на обработку BPDU может и не хватить ресурсов.
И что этот BPDU не дропнется на перегруженном порту еще до того как он дойдет до процессора.
Дропнется в направлении «in» на перегруженном порту? Любопытно… А на отправку у него и так безусловный приоритет. Иначе типичный congestion обернулся бы кошмарным расколбасом по всей сети, с постоянными перестроениями топологии.
Нигде не написано что максимальное время броадкаст-шторма при включенном portfast на портах и запетлявшей топологии = 2с. Зачем же это додумывать?
Написано, что порт при получении BPDU проходит через нормальный процесс STP. «Максимум 2 секунды» подразумевается. Не будут же они как для идиотов все разжевывать.
У каждой технологии есть границы применимости, соответственно их нужно либо не нарушать, либо не использовать технологию.
Вы предложили две совершенно бредовые альтернативы.
И уж конечно перед рассмотрением других технологий следует хорошенько изучить первоначальную ;) Например, поставить везде storm-control broadcast level 1 — и сеть при шторме не упадет, будут лишь маленькие глючки с полагающимися на броадкаст сервисами (ARP, DHCP), да и то вряд ли — ресурсы свитча не будут исчерпаны, и он спокойно положит закольцованные порты.
«Не нарушать»? Это никуда не годится. Надо сделать так, чтобы и при кратковременном нарушении ничего плохого не происходило. А для этого для начала надо хорошо знать матчасть.
Вы ведь даже не знали, что portfast'овый порт рассылает BPDU :)
И не вздумайте на собеседовании говорить «а давайте каждому по VLANу создадим»…
Еще раз. В документации по portfast'у где-то пишется, что после получения BPDU порт моментально переходит в blocking, а затем проходит через нормальный процесс STP. И кольцо должно возникнуть максимум на 2 секунды, что называется не «катастрофа», а «инцидент, который скорее всего останется незамеченным». Я же говорю, что на практике все может быть куда хуже. И мало кто об этом знает. В курсе BCMSN (который Вы явно пропустили, судя по «portfast не рассылает BPDU» :) ) про такой исход дела ни слова не было.
Ну вот представим себе, что portfast на порту абсолютно необходим. Некая система не может ждать по полминуты после поднятия линка. Выходит, кто-то соединил два порта — и приплыли…
Получается, portfast у вас на access портах отключен, раз там bpdu летят?
Вы путаете portfast с bpdufilter.
#show spanning-tree interface fa4/10 detail
Port 202 (FastEthernet4/10) of VLAN0200 is designated forwarding
Port path cost 19, Port priority 128, Port Identifier 128.202.
Designated root has priority 32968, address 001a.a18b.bec0
Designated bridge has priority 32968, address 001a.a18b.bec0
Designated port id is 128.202, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 0
The port is in the portfast mode
Link type is point-to-point by default
Bpdu guard is enabled by default
BPDU: sent 1099568, received 0
Вот здоровый аксессный порт. Если соединить его с fa4/11, то с вероятностью 99,999% fa4/10 уйдет в blocking, сразу после получения BPDU, и пользователи ничего не заметят.
Еще раз — should only be enabled on ports connected to a single host. А сдуру можно много чего сломать…
Если человек полагается на «авось», т.е. надеется на то, что никто не соединит соседние порты патч-кордом, то ему вообще нечего делать в IT. Необходимо заранее предусмотреть любые возможные сценарии, ведущие к аварии, и предпринять меры по недопущению как можно большего числа этих аварий. И всегда исходить из того, что пользователь — идиот; вспышки на солнце происходят каждый день; глюк в софте на сетевом железе случается раз в два дня и т.д.
Вы же явно сторонник подхода «если система падает от чиха, то надо запретить чихать, а не устранить источник влияния чиха на стабильность». Так не бывает.
Именно что скорее «constant». Циска на моей памяти не говорила, что подобный луп может вынести весь L2 сегмент до того момента, когда администратор руками разъединит кольцо, а не на 2 секунды до первой BPDU.
Мне на самом деле тогда сильно «повезло». Местный умудрился попасть в 2 из 4-х портов, в которые попадать было нельзя.
«вы включили portfast там где включать его было нельзя»
Немного неправильный подход. Сеть должна быть отказо- и дуракоустойчивой. То есть вытыкание или втыкание любого проводка не должно приводить к катастрофе. А то получается на «попал в аварию и не сработала подушка» ответ «не надо было попадать в аварию».
У нас на пользовательском аксессе раз в пару месяцев BPDU guard блокирует порты, потому что кто-то умный втыкает торчащий из розетки патч-корд в соседнюю розетку. Суть моего комментария сводится к тому, что не следует полагаться на механизмы STP в этом случае. Ну ладно, на пользовательском порту можно сказать «sw port-security max 3», это должно помочь, а вот в виртуализированном ЦОДе с этим куда сложнее. Потому всегда нужны дополнительные меры защиты. Но: они не всегда поддерживаются. Взять Nexus 2000 — у них нет никакого storm control. То есть кто-то соединил соседние порты патч-кордом, и минимум кусок сети с большой вероятностью лег.
Да там даже обсуждать нечего. Любой, кто говорит, что STP хорош хоть чем-то кроме дешевого решения для организации базовой избыточности либо в качестве предохранителя, является ослом.
Хотя смотрю, кому-то хватило мозгов сделать no spanning-tree vlan X, раз как бы теоретически колец нет. Ну-ну… Никто ведь не говорит, что STP надо отключать. Просто он не должен ничего никогда блокировать кроме как на полминуты максимум при появлении физики.
И еще момент. Хорошая сеть — та сеть, где вообще нет STP колец, и ни один линк не блокируется, с сохранением полной отказоустойчивости (STP задействован лишь в качестве предохранительного механизма). Обычно используют агрегацию линков плюс технологии, позволяющие завязать один port-channel на двух или более разных шасси (стеки на 3750, VSS на cat6500, vPC на нексусах и т.д. — у каждого вендора есть нечто подобное). Хардкор — полноценный роутинг на L2, TRILL и протоколы на его основе (у циски — Fabricpath). Но его пока мало где встретишь, и то кроме ЦОДов он нигде не используется.
Portfast на нагруженных свитчах смертельно опасен!
Суть в следующем.
1) На любых коммутаторах BPDU обрабатываются программно.
2) Частота рассылки BPDU — по дефолту 2 секунды.
3) При втыкании патч-корда порт переходит в forwarding мгновенно.
По меркам коммутатора, через который проходит много (десятков) гигабит, 2 секунды — вечность. За это время мозги свитчу выносятся напрочь, и он уже не может загасить порт (errdisable в случае BPDU Guard или просто stp blocking — неважно), ресурсов для обработки BPDU нет, ибо большинство броадкастов в сети — ARP пакеты, долетающие до CPU свитча. И вот у нас шторм по всему L2 сегменту, который не хочет прекращаться сам по себе.
Это не голая теория, я сам однажды на это нарвался (как дебил сказал человеку «воткни новый свитч в любые два порта»).
Понятно, что на аксессной пользовательской железке с парой сотен мегабит и 100мб интерфейсами до пользователей такая катастрофа маловероятна, я больше про ЦОДы говорю.
Потому ОБЯЗАТЕЛЬНО задействовать Storm Control везде, где только можно. Он реализован аппаратно, и он позволяет коммутатору успешно работать и при шторме. Ведь один из самых мерзких моментов шторма — то, что и добраться до самого свитча при отсутствии out-of-band management крайне непросто.
Кстати — как минимум cat6500 прекрасно отзывается по консоли даже когда шторм выжрал все ресурсы.
2.bp.blogspot.com/-XwNs3lmTd4U/T29Va1xVs3I/AAAAAAAABTE/NEVCjTSAZrY/s1600/Motorola-Razr.jpg
Да, он действительно хорош. И производительность на уровне. И официальный ICS на носу.
Вы статейку-то читали про то, что в айфоне фактически реализовано «приложил палец к экрану => весь мир встал на паузу»? Я с радостью готов пожертвовать, к примеру, плавностью скроллинга грузящейся страницы ради того, чтобы она грузилась быстро. Мне не нужна система, в которой UI вытесняет всё остальное из очереди.