none
Hyper-V,VLAN и Nic Team Вопросы и ответы. RRS feed

  • Вопрос

  •  Доброе утро Уважаемые специалисты!В продолжении предыдущей темы хотелось бы остановить внимание на некотором моменте, а именно:

     На данный момент у меня есть сервер с Hyper-V у которого есть управляющий интерфейс с айпи адресом самого сервера и есть еще один физический адаптер-который добавлен в новый созданный NIC Team, в следствии чего образован Multeplexor адаптер и на котором нет айпи адреса!.Создан виртуальный коммутатор и  привязан к multeplexor адаптеру.

    Соответственно есть некоторое количество виртуальных машин, которые находятся в разных VLAN и у которых стоит галочка использовать соответствующий VLAN ID.

    На физике отдается транк на циске данному серверу, что позволяет виртуальным машинам взаимодействовать.

    Вопросы относящиеся в рамках работы ВМ в разных VLAN:

     1.Обязателен ли айпи адрес на Multiplexor адаптере, если есть управляющий интерфейс ?

     2.Если я убираю конфигурацию Nic Team , то почему у меня взаимодействие между ВМ в разных VLAN продолжает действовать, ведь со стороны между двумя коммутаторами (циской и vSwitch) должен быть транк (то есть транк создается автоматически когда я создаю NIC Team для Default Mode Default VLANs),либо тегирование трафика у меня происходит на уровне физических NIC -даже если я просто его привяжу к виртуальному коммутатору без обвязки в NIC Team?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!




    • Изменено rеstless 18 ноября 2013 г. 6:16
    18 ноября 2013 г. 6:06

Ответы

  • Кроме отказоустойчивости и балансировки, тиминг от Майкрософт позволяет еще и конвергентные фабрики строить с разнесением трафика по разным виртуальным интерфейсам.

    Но ничего не мешает использовать виртуальный коммутатор на основе единственного физического адаптера. Главное, чтобы у Вас физический порт был в режиме Trunk — идентификаторы VLAN Вы все равно будете указывать на уровне сетевых карт виртуальных машин.

    • Помечено в качестве ответа rеstless 18 ноября 2013 г. 7:58
    18 ноября 2013 г. 7:12
    Модератор
  • Коммутатор Hyper-V поддерживает стандарт 802.1q, что позволяет гипервизору правильно маршрутизировать исходящие пакеты с определенным идентификатором от портов физического оборудования до надлежащих виртуальных портов. Как построен виртуальный коммутатор — на одиночном адаптере или тиминговом интерфейсе, неважно, главное, чтобы физическое оборудования поддерживало 802.1q и порты были доставлены в Trunk.

    Вам нужно знать, как виртуальный коммутатор работает с тегированными пакетами?

    • Помечено в качестве ответа rеstless 18 ноября 2013 г. 12:23
    18 ноября 2013 г. 10:13
    Модератор
  • а что значит конвергентные фабрики строить с разнесением трафика по разным виртуальным интерфейсам?

    http://www.aidanfinn.com/?p=12646 и http://www.youtube.com/watch?v=N1nsc_iHJYw

    Но, разумеется, вы должны понимать, что при упаковке всего трафика в один тиминг и в случае отключения всех физ. сетей ваш кластер потеряет коммуникации между нодами и может немного сойти с ума от переживаний (актуально когда нод больше двух-трёх - десяток нод поднимать обратно придётся долго - решается отдельными дополнительными pNIC в отдельный свич для хартбитов, как вариант).


    Active Directory? Ask me how.


    • Помечено в качестве ответа rеstless 18 ноября 2013 г. 7:58
    • Изменено AndricoRusEditor 18 ноября 2013 г. 7:59
    18 ноября 2013 г. 7:55
    Отвечающий

  • Вам нужно знать, как виртуальный коммутатор работает с тегированными пакетами?

    Да поглубже капнуть не мешало бы для самообразования!


     А то тут уже спор зашел, между цискарями и нами.Цискари уверяют что тегирование на уровне физических pNIC происходит, а виртуальный коммутатор это "тупой" коммутатор но уровня 2.

     Я так понял виртуальный коммутатор все таки позиционируется как второго уровня и управляемый и как раз он и определяет теги входящих и исходящий фреймов для VM!

    Спасибо Денис! Вам как эксперту грех не поверить!




    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!





    • Помечено в качестве ответа rеstless 18 ноября 2013 г. 10:44
    • Изменено rеstless 18 ноября 2013 г. 10:54
    18 ноября 2013 г. 10:30

Все ответы

  • На данный момент у меня есть сервер с Hyper-V у которого есть управляющий интерфейс с айпи адресом самого сервера и есть еще один физический адаптер-который добавлен в новый созданный NIC Team, в следствии чего образован Multiplexor адаптер и на котором нет айпи адреса!.
    Это нормально, поскольку у вас к нему привязан vSwitch. Соответственно если на vSwitch у вас разрешено его использование хостовой системой, то будет создан vNIC, на котором и будет вся конфигурация.
    Обязателен ли айпи адрес на Multiplexor адаптере, если есть управляющий интерфейс?
    нет, см. выше - на нём не только нет IP, но и вообще отвязаны IP-протоколы :)
    Если я убираю конфигурацию Nic Team, то почему у меня взаимодействие между ВМ в разных VLAN продолжает действовать, ведь со стороны между двумя коммутаторами (циской и vSwitch) должен быть транк (то есть транк создается автоматически когда я создаю NIC Team для Default Mode Default VLANs), либо тегирование трафика у меня происходит на уровне физических NIC -даже если я просто его привяжу к виртуальному коммутатору без обвязки в NIC Team?
    Именно - на уровне pNIC. Ни тиминг, ни vSwitch тут непричём.

    Active Directory? Ask me how.

    18 ноября 2013 г. 6:51
    Отвечающий
  • На данный момент у меня есть сервер с Hyper-V у которого есть управляющий интерфейс с айпи адресом самого сервера и есть еще один физический адаптер-который добавлен в новый созданный NIC Team, в следствии чего образован Multiplexor адаптер и на котором нет айпи адреса!.

    Это нормально, поскольку у вас к нему привязан vSwitch. Соответственно если на vSwitch у вас разрешено его использование хостовой системой, то будет создан vNIC, на котором и будет вся конфигурация.
    Обязателен ли айпи адрес на Multiplexor адаптере, если есть управляющий интерфейс?
    нет, см. выше - на нём не только нет IP, но и вообще отвязаны IP-протоколы :)
    Если я убираю конфигурацию Nic Team, то почему у меня взаимодействие между ВМ в разных VLAN продолжает действовать, ведь со стороны между двумя коммутаторами (циской и vSwitch) должен быть транк (то есть транк создается автоматически когда я создаю NIC Team для Default Mode Default VLANs), либо тегирование трафика у меня происходит на уровне физических NIC -даже если я просто его привяжу к виртуальному коммутатору без обвязки в NIC Team?

    Именно - на уровне pNIC. Ни тиминг, ни vSwitch тут непричём.

    Active Directory? Ask me how.

     Да пардон, я имел в виду айпишник на vEthernet после привязки Multiplexor адаптера к виртуальному коммутатору. То есть здесь необходимо обязательно иметь айпишник, или нет ?  На данный момент у меня конфигурация когда на vEthernet нет айпишника-то есть его не прописывали, а прописали только на управляющем NIC! То есть в такой конфигурации трафик от ВМ будет в физику будет уходить через какой физический NIC (управляющий у которого есть айпи) ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 18 ноября 2013 г. 7:00
    18 ноября 2013 г. 6:58
  • Да пардон, я имел в виду айпишник на vEthernet после привязки Multiplexor адаптера к виртуальному коммутатору. То есть здесь необходимо обязательно иметь айпишник, или нет ?  На данный момент у меня конфигурация когда на vEthernet нет айпишника-то есть его не прописывали, а прописали только на управляющем NIC! То есть в такой конфигурации трафик от ВМ будет в физику будет уходить через какой физический NIC (управляющий у которого есть айпи) ?
    Если у вас есть отдельный management-интерфейс, то не обязательно. Но лучше тогда уж убрать галку в настройках vSwitch - vNIC исчезнет :) а вообще я сторонник сценария converged network - оно интереснее на vNIC'ах всё разводить... один тиминг на всё, а дальше несколько vNIC'ов и QoS...

    Active Directory? Ask me how.

    18 ноября 2013 г. 7:03
    Отвечающий
  •  Тогда сама суть создания NIC Team состоит только в отказоустойчивости и агрегации и не более ? То есть я могу создать конфигурацию без NIC Team с одним физическим NIC и при этом создать виртуальные машины из разных VLAN (естественно при условии отдачи транка от физической железки)?

     Или все таки NIC Team так же создает  конфигурацию транка для Default Mode/Default VLAN - именно если у меня используется несколько VLAN для некоторого количества виртуалок на Hyper-V ?  


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 18 ноября 2013 г. 7:05
    18 ноября 2013 г. 7:04
  • Кроме отказоустойчивости и балансировки, тиминг от Майкрософт позволяет еще и конвергентные фабрики строить с разнесением трафика по разным виртуальным интерфейсам.

    Но ничего не мешает использовать виртуальный коммутатор на основе единственного физического адаптера. Главное, чтобы у Вас физический порт был в режиме Trunk — идентификаторы VLAN Вы все равно будете указывать на уровне сетевых карт виртуальных машин.

    • Помечено в качестве ответа rеstless 18 ноября 2013 г. 7:58
    18 ноября 2013 г. 7:12
    Модератор
  • Да пардон, я имел в виду айпишник на vEthernet после привязки Multiplexor адаптера к виртуальному коммутатору. То есть здесь необходимо обязательно иметь айпишник, или нет ?  На данный момент у меня конфигурация когда на vEthernet нет айпишника-то есть его не прописывали, а прописали только на управляющем NIC! То есть в такой конфигурации трафик от ВМ будет в физику будет уходить через какой физический NIC (управляющий у которого есть айпи) ?

    Если у вас есть отдельный management-интерфейс, то не обязательно. Но лучше тогда уж убрать галку в настройках vSwitch - vNIC исчезнет :) а вообще я сторонник сценария converged network - оно интереснее на vNIC'ах всё разводить... один тиминг на всё, а дальше несколько vNIC'ов и QoS...

    Active Directory? Ask me how.

     То есть если я правильно понимаю, то вся конфигурация что бы поддерживать возможность использовать виртуальные машины из несколько VLAN на Hyper-V не обязательна должна строиться именно на NIC Team так ?

    NIC Team скорее как  раз придает отказоустойчивость и агрегацию с возможностью на нем все данное дело (VLAN) так же реализовывать , так ?

     Просто изначально у меня бытовало ошибочное мнение, что обязательная схема при использовании VLAN и транка должна реализовываться именно при помощи NIC Team...


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 18 ноября 2013 г. 7:15
    18 ноября 2013 г. 7:15
  • То есть если я правильно понимаю, то вся конфигурация что бы поддерживать возможность использовать виртуальные машины из несколько VLAN на Hyper-V не обязательна должна строиться именно на NIC Team так ?

    NIC Team скорее как  раз придает отказоустойчивость и агрегацию с возможностью на нем все данное дело (VLAN) так же реализовывать , так ?

    Нет, NIC Teaming - это рекомендуемое и оч. приятное дополнение, но не обязательное к использованию.

    Active Directory? Ask me how.

    18 ноября 2013 г. 7:17
    Отвечающий
  • Кроме отказоустойчивости и балансировки, тиминг от Майкрософт позволяет еще и конвергентные фабрики строить с разнесением трафика по разным виртуальным интерфейсам.

    Но ничего не мешает использовать виртуальный коммутатор на основе единственного физического адаптера. Главное, чтобы у Вас физический порт был в режиме Trunk — идентификаторы VLAN Вы все равно будете указывать на уровне сетевых карт виртуальных машин.

     То есть если я правильно понял, то сам физический адаптер сервера должен смотреть в транковый порт циски. Но тогда как входящий трафик на Hyper-V хосте понимает что он принадлежит именно тому VLAN, которому нужен ? Или это делается уже на уровне самого порта со стороны физического свича ? И если мы добавили NIC Team то зачем тогда нужен режим Default Mode/Default VLAN -только для того что бы этот функционал поддерживал Microsoft ?

     Ну и второй вопрос: а что значит конвергентные фабрики строить с разнесением трафика по разным виртуальным интерфейсам. ? 

     


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!






    • Изменено rеstless 18 ноября 2013 г. 7:55
    18 ноября 2013 г. 7:52
  • а что значит конвергентные фабрики строить с разнесением трафика по разным виртуальным интерфейсам?

    http://www.aidanfinn.com/?p=12646 и http://www.youtube.com/watch?v=N1nsc_iHJYw

    Но, разумеется, вы должны понимать, что при упаковке всего трафика в один тиминг и в случае отключения всех физ. сетей ваш кластер потеряет коммуникации между нодами и может немного сойти с ума от переживаний (актуально когда нод больше двух-трёх - десяток нод поднимать обратно придётся долго - решается отдельными дополнительными pNIC в отдельный свич для хартбитов, как вариант).


    Active Directory? Ask me how.


    • Помечено в качестве ответа rеstless 18 ноября 2013 г. 7:58
    • Изменено AndricoRusEditor 18 ноября 2013 г. 7:59
    18 ноября 2013 г. 7:55
    Отвечающий
  • а что значит конвергентные фабрики строить с разнесением трафика по разным виртуальным интерфейсам?

    http://www.aidanfinn.com/?p=12646 и http://www.youtube.com/watch?v=N1nsc_iHJYw

    Active Directory? Ask me how.

    Спасибо! Первую статейку читал уже!

     Значит режим Default Mode в NIC Team для того что бы корректно отрабатывал трафик между разными VLAN.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 18 ноября 2013 г. 7:58
    18 ноября 2013 г. 7:57
  • Ок, спасибо!С кластером ясно!

     Я все таки не уловлю до конца- при использовании NIC Team будет как то задействован в обмене трафика из разных VLAN, я имел в виду в отношении Deafult Mode ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!




    • Изменено rеstless 18 ноября 2013 г. 8:05
    18 ноября 2013 г. 8:04
  • Но, разумеется, вы должны понимать, что при упаковке всего трафика в один тиминг и в случае отключения всех физ. сетей ваш кластер потеряет коммуникации между нодами и может немного сойти с ума от переживаний
    Ещё немного дополню вопросом к размышлению на случай использования VLAN'ов в кластерных коммуникациях - где именно "окрашивается" трафик между нодами в вашей сети. Тегированный ли будет трафик на оконечных свичах, если умрёт ядро вашей сети?

    Active Directory? Ask me how.

    18 ноября 2013 г. 8:05
    Отвечающий
  • Но, разумеется, вы должны понимать, что при упаковке всего трафика в один тиминг и в случае отключения всех физ. сетей ваш кластер потеряет коммуникации между нодами и может немного сойти с ума от переживаний

    Ещё немного дополню вопросом к размышлению на случай использования VLAN'ов в кластерных коммуникациях - где именно "окрашивается" трафик между нодами в вашей сети. Тегированный ли будет трафик на оконечных свичах, если умрёт ядро вашей сети?

    Active Directory? Ask me how.

    Тогда есть несколько вопросов:

    1.Изначально у подрядчика имеется некоторое железо- которое и отдает транк серверу Hyper-V.

    2.Что понимается под ядром сети ?


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    18 ноября 2013 г. 8:14
  • Закрывая тему хочу представить все это вот таким набором мыслей:

    Просто если вообще забыть о виртуализации и представить два физических свитча, то соединение между ними обычно конфигурируется в транк(дополнительно может быть агрегация каналов), а аксес порты этих свичей помещаются в необходимые VLAN. Собственно, MS требует тоже самое, только один из физических свичей - это vSwitch, транк порты - это физические сетевушки, а аксес порты - это vNIC.

     Все остальное будь то с NIC Team это дополнительное преимущество. Но сам функционал "разруливания" VLAN никак не связан с NIC Team и его режимом Default Mode/VLAN Mode , либо это фича просто при объединении хоть 32 NICs должна сказать Hyper-V , что это как бы один NIC но с возможностью пропускать все VLAN-ны? 



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!




    • Изменено rеstless 18 ноября 2013 г. 8:30
    18 ноября 2013 г. 8:19
  • либо это фича просто при объединении хоть 32 NICs должна сказать Hyper-V , что это как бы один NIC но с возможностью пропускать все VLAN-ны?
    эта фича ничего не говорит Hyper-V... трафик будет балансироваться под сетевым стеком HV - часть соединений пойдёт на один подлежащий NIC, часть - на другой (как именно - см. механизмы балансировки в настройках тиминга), для Hyper-V это прозрачно... главное, чтобы на все pNIC приходили транки с одинаковым набором VLAN'ов...

    Active Directory? Ask me how.

    18 ноября 2013 г. 8:41
    Отвечающий
  • либо это фича просто при объединении хоть 32 NICs должна сказать Hyper-V , что это как бы один NIC но с возможностью пропускать все VLAN-ны?

    эта фича ничего не говорит Hyper-V... трафик будет балансироваться под сетевым стеком HV - часть соединений пойдёт на один подлежащий NIC, часть - на другой (как именно - см. механизмы балансировки в настройках тиминга), для Hyper-V это прозрачно... главное, чтобы на все pNIC приходили транки с одинаковым набором VLAN'ов...

    Active Directory? Ask me how.

    Тогда по другому сформулирую свой вопрос:

     Где определяется сама принадлежность фрейма к определенному VLAN, который должен попасть на определенную виртуальную машину находящейся на хосте Hyper-V ?

     Уже сразу на транк порте физического свича, или на физических  NIC- которым отдается транк ? То есть сами физические NIC это уже и есть транк со стороны Hyper-V сконфигурированный при помощи циски?

     И наоборот, фрейм исходя из виртуальной машины тегируется именно на уровне vNIC -где прописан VLAN ID?

     Я понял, что тег входящего фрейма-который пришел на хост виртуализации проверяется именно изначально физическим адаптером pNIC так как должен иметь подержку 802.1q и далее уже к кнкретной ВМ-которой задан VLAN ID.

    Но в случае если pNIC не понимает 802.1q, то я могу это организовать на уровне NIC Team ? То есть программно ?

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!







    • Изменено rеstless 18 ноября 2013 г. 9:40
    18 ноября 2013 г. 9:13
  • Где определяется сама принадлежность фрейма к определенному VLAN, который должен попасть на определенную виртуальную машину находящейся на хосте Hyper-V?
    Глубину запроса понял - вам, думаю, проще попробовать wireshark в promiscuous mode на гипервизоре запустить и понаблюдать :)
    в этом прелесть работы с технологиями Microsoft - не нужно заморачиваться на лишней информации, последний раз меня разбор трафика интересовал году в 2008 :) теперь достаточно в общих чертах понимать как происходит разбор на физ. сетевом интерфейсе и не лезть глубже :)

    Active Directory? Ask me how.

    18 ноября 2013 г. 9:45
    Отвечающий
  • Где определяется сама принадлежность фрейма к определенному VLAN, который должен попасть на определенную виртуальную машину находящейся на хосте Hyper-V?

    Глубину запроса понял - вам, думаю, проще попробовать wireshark в promiscuous mode на гипервизоре запустить и понаблюдать :)
    в этом прелесть работы с технологиями Microsoft - не нужно заморачиваться на лишней информации, последний раз меня разбор трафика интересовал году в 2008 :) теперь достаточно в общих чертах понимать как происходит разбор на физ. сетевом интерфейсе и не лезть глубже :)

    Active Directory? Ask me how.

    Вы будете смеяться, я не хочу заморачиваться, мне нужно только одно знать:

     Как гипервизор понимает к какой виртуалке предназначен определенный тег ? И все!

    Работу VLAN  я отлично себе представляю, так как сам конфигурил циску-тут все ясно.

    Неясно как ведет себя пришедший тегированный пакет от циски на гипервизор.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 18 ноября 2013 г. 9:57
    18 ноября 2013 г. 9:55
  • В настройках каждой виртуальной машины можно выставить к какому влан она относится, тэг просматривается с помощью драйвера физической карты. То есть не каждая сетевая карта подойдет и не с каждый драйвером будет работать.
    18 ноября 2013 г. 9:58
  • В настройках каждой виртуальной машины можно выставить к какому влан она относится, тэг просматривается с помощью драйвера физической карты. То есть не каждая сетевая карта подойдет и не с каждый драйвером будет работать.

     Спасибо, меня это и интересовало!

    То есть если драйвер pNIC не поддерживает 802.1q то и более никак не получится разделить трафик на VLAN в данном случае ? 

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    18 ноября 2013 г. 10:05
  • Именно так.
    • Помечено в качестве ответа rеstless 18 ноября 2013 г. 10:12
    • Снята пометка об ответе rеstless 18 ноября 2013 г. 10:55
    18 ноября 2013 г. 10:11
  • Все, спасибо! Меня удовлетворил ответ.

    А вообще надо бы книжонку Aidan Finn почитать о конфигурации Hyper-V Server 2012, там по моему есть практически все!

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    18 ноября 2013 г. 10:13
  • Коммутатор Hyper-V поддерживает стандарт 802.1q, что позволяет гипервизору правильно маршрутизировать исходящие пакеты с определенным идентификатором от портов физического оборудования до надлежащих виртуальных портов. Как построен виртуальный коммутатор — на одиночном адаптере или тиминговом интерфейсе, неважно, главное, чтобы физическое оборудования поддерживало 802.1q и порты были доставлены в Trunk.

    Вам нужно знать, как виртуальный коммутатор работает с тегированными пакетами?

    • Помечено в качестве ответа rеstless 18 ноября 2013 г. 12:23
    18 ноября 2013 г. 10:13
    Модератор

  • Вам нужно знать, как виртуальный коммутатор работает с тегированными пакетами?

    Да поглубже капнуть не мешало бы для самообразования!


     А то тут уже спор зашел, между цискарями и нами.Цискари уверяют что тегирование на уровне физических pNIC происходит, а виртуальный коммутатор это "тупой" коммутатор но уровня 2.

     Я так понял виртуальный коммутатор все таки позиционируется как второго уровня и управляемый и как раз он и определяет теги входящих и исходящий фреймов для VM!

    Спасибо Денис! Вам как эксперту грех не поверить!




    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!





    • Помечено в качестве ответа rеstless 18 ноября 2013 г. 10:44
    • Изменено rеstless 18 ноября 2013 г. 10:54
    18 ноября 2013 г. 10:30