none
По объедению сетевых карт для последующей настройки HYPER-V RRS feed

  • Вопрос

  • Подскажите пожалуйста, недавно перешел на server 2012 r2, на сервере 2 сетевые карты, планируется установить на Hyper-V, 1 сервер контроллера домена, на второй Hyper-V, почтовый сервер, и на самой хостовой машине есть еще папки для работы сотрудников, я сперва 1 сетевую карту настроил, все в порядке люди с расшаренными папками работают, вторую сетевую создал для виртуальных машин свитч, но так как обе сетевые карты настроены в одной сети, хостовая машина получается сидит на двух IP адресах, что наверное неправильно или для хостовой машины все равно сколько у нее IP???

    Сейчас увидел такую функцию в server 2012 r2, что можно объединить 2 сетевые карты, что обеспечивает дополнительную отказоустойчивость, подскажите пожалуйста, будет так лучше если объединить все таки обе сетевые карты? И дальнейшие действия я правильно понимаю, что после объеденения сетевых карт, создастся новый адаптер (он появиться в устройствах сетевых карт), соответственно хостовая машина будет работать с 1 IP, далее для подключения виртуальных машин необходимо будет создать новый виртуальный свитч на основе нового объедененного устройства (тоесть указать этот новый комутатор объедененных сетевых карт)? Или оставитьбез объеденения ?

Ответы

  • можете объединить, а можете использовать отдельно друг от друга.

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

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

    Если у вас несколько отдельных сетевых план, то вам действительно есть смысл задуматься над объединением адаптеров. Также напоминаю, что отказоустойчивость путем объединения адаптеров вы можете организовать внутри гостевой ОС, это тоже поддерживается.

    почитайте статью, там и инструкция есть: https://habrahabr.ru/company/microsoft/blog/162509/

  • Добрый вечер!

    Вводные данные и цели не понятны на 100%, конечно. Но..

    • Все типы трафика лучше изолировать на канальном уровне
    • Смысла держать хост в одной и той же подсети с 2 IP, как правило, нет. Требования приложений пока опускаем.
    • Хостовая машина может иметь множество адресов. Банальный пример: кластеризация
    • Адаптеры объединять в тиминг для дополнительного FT (тем более, если речь идет о ед-ом сервере)
    • Подобную реализацию возможно так же исп-ть:  https://rlevchenko.com/2014/09/15/simple-smb-share-and-multichannel-for-hyper-v/

    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    6 июля 2016 г. 16:18
  • Одобрю слова Egor Vasilev по поводу объедения в TEAM двух сетевых карт для увеличения скорости.

    Но предложу другой вариант который я реализовал у себя. Так как вы хотите использовать все различные службы одну под одну нужду другую для VM. Для изолированности физических интерфейсов я бы оставил их отдельными, но с одним IP адресом, что Вы получите. Два независимых интерфейсов с одним IP адресом. Как это сделать. Для виртуальной машины создаете новый диспетчер виртуальных коммутаторов и назначаете второй интерфейс физической сетевой платы. Далее одну карту оставляете без изменений, а в второй убираете все данные я Вам привел картинки 

    Что Вы получаете.

    Два раздельных интерфейса с одним IP адресом, не правда ли удобно)

  • Все настройки, которые вы скинули, можно получить очень просто и одним движением - сняв галочку "Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру" в настройках виртуального коммутатора, но я это уже упоминал выше.
    6 июля 2016 г. 10:28

Все ответы

  • можете объединить, а можете использовать отдельно друг от друга.

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

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

    Если у вас несколько отдельных сетевых план, то вам действительно есть смысл задуматься над объединением адаптеров. Также напоминаю, что отказоустойчивость путем объединения адаптеров вы можете организовать внутри гостевой ОС, это тоже поддерживается.

    почитайте статью, там и инструкция есть: https://habrahabr.ru/company/microsoft/blog/162509/

  • Да на сервере 2 сетевые карты! поэтому пока не начал окончательно все устанавливать, задумался стоит ли объеденить сетевые, или как Вы и писали для входа на хостовую машину 1 адаптер использовать для виртуальных машин второй адаптер? Да ту статью как раз и читал на хабре, вот и задумался как лучше то будет...
  • ну если 2 отдельные сетевые карты (не путайте с сетевыми интерфейсами), то тогда можно попробовать объединить. 
  • Одобрю слова Egor Vasilev по поводу объедения в TEAM двух сетевых карт для увеличения скорости.

    Но предложу другой вариант который я реализовал у себя. Так как вы хотите использовать все различные службы одну под одну нужду другую для VM. Для изолированности физических интерфейсов я бы оставил их отдельными, но с одним IP адресом, что Вы получите. Два независимых интерфейсов с одним IP адресом. Как это сделать. Для виртуальной машины создаете новый диспетчер виртуальных коммутаторов и назначаете второй интерфейс физической сетевой платы. Далее одну карту оставляете без изменений, а в второй убираете все данные я Вам привел картинки 

    Что Вы получаете.

    Два раздельных интерфейса с одним IP адресом, не правда ли удобно)

  • Глянь мой ответ, может изменишь подход в этом вопросе
    • Предложено в качестве ответа Vladimir Sizasko 6 июля 2016 г. 8:49
  • Глянь мой ответ, может изменишь подход в этом вопросе
    Какой именно ответ? IT24 ? Вот блин теперь опять запутался, и так будет работать и так, как лучше будет получается ответа нет.
  • Одобрю слова Egor Vasilev по поводу объедения в TEAM двух сетевых карт для увеличения скорости.

    Но предложу другой вариант который я реализовал у себя. Так как вы хотите использовать все различные службы одну под одну нужду другую для VM. Для изолированности физических интерфейсов я бы оставил их отдельными, но с одним IP адресом, что Вы получите. Два независимых интерфейсов с одним IP адресом. Как это сделать. Для виртуальной машины создаете новый диспетчер виртуальных коммутаторов и назначаете второй интерфейс физической сетевой платы. Далее одну карту оставляете без изменений, а в второй убираете все данные я Вам привел картинки 

    Что Вы получаете.

    Два раздельных интерфейса с одним IP адресом, не правда ли удобно)

  • Глянь мой ответ, может изменишь подход в этом вопросе

    я так и не понял что конкретно вы советуете.

    Создать новый "диспетчер виртуальных коммутаторов" невозможно в принципе. Диспетчер он один для всех. Вот создать новый Виртуальный коммутатор можно вполне, но диспетчера создать нельзя.

    Два независимых интерфейса с одним ip-адресом можно получить как раз путем объединения двух адаптеров в группу - при выходе из строя любого из адаптеров у вас все продолжит работать нормально.

  • С виртуальным коммутатором я оговорился, а вот с своей реализацией.

    Я Вас даже Screen скинул, прочитайте внимательно

  • Все настройки, которые вы скинули, можно получить очень просто и одним движением - сняв галочку "Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру" в настройках виртуального коммутатора, но я это уже упоминал выше.
    6 июля 2016 г. 10:28
  • Добрый вечер!

    Вводные данные и цели не понятны на 100%, конечно. Но..

    • Все типы трафика лучше изолировать на канальном уровне
    • Смысла держать хост в одной и той же подсети с 2 IP, как правило, нет. Требования приложений пока опускаем.
    • Хостовая машина может иметь множество адресов. Банальный пример: кластеризация
    • Адаптеры объединять в тиминг для дополнительного FT (тем более, если речь идет о ед-ом сервере)
    • Подобную реализацию возможно так же исп-ть:  https://rlevchenko.com/2014/09/15/simple-smb-share-and-multichannel-for-hyper-v/

    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    6 июля 2016 г. 16:18