Назад | Перейти на главную страницу

Реальный сервер, несколько IP-адресов, виртуальный сервер HyperV, разделение IP-адресов между реальными и виртуальными сетевыми адаптерами

Эту проблему немного сложно объяснить без той же базовой справочной информации - я постараюсь уточнить вопрос позже, если потребуется.


Изначально у меня был один размещенный сервер (Win 2008R2) со следующим диапазоном из 8 IP-адресов.

- Single NIC ( IP: x.x.128.72 -> x.x.128.79 // Subnet: x.x.255.192 // GW: x.x.128.65 )

После установки Hyper-V и настройки одного виртуального сервера на том же компьютере, я хотел назначить один из IP-адресов виртуальному серверу, оставив все остальное работать нормально.

-

Во-первых, я попытался использовать «Внешнюю» сеть, но (даже после установки IP-адресов на «Виртуальном адаптере», как и Вот но изо всех сил пытался запустить сеть вообще).

Мне нужно было, чтобы сервер работал (иначе я бы потратил больше времени на реализацию этого подхода)

Q1 ... Было ли это разумным поступком? Стоило ли мне продолжать этот путь?

-

Затем я решил попробовать другой подход - установите для сети HyperV значение «Внутренняя» (видимая для ОС управления).

- Physical NIC ( IP: x.x.128.72 to .75 // Subnet: x.x.255.192 // GW: x.x.128.65 )
- Virtual NIC ( IP: x.x.128.78 // Subnet: x.x.255.252 // GW: x.x.128.72 ) 
     - Gateway was the same as the IP of the physical NIC )
- Virtual OS-NIC ( IP: x.x.128.77 // Subnet: x.x.255.252 //  GW: x.x.128.78 ) 
     - Gateway was the same as the IP of the host virtual-NIC )

-

Как ни странно, этот подход действительно работал, и я смог подключиться со всего следующего: - Интернет к / от физического сетевого адаптера (x.x.128.72) - физический сетевой адаптер (x.x.128.72) к виртуальному-OS-NIC (x.x.128.77), например. тестирование через ping + FTP - Интернет в / из виртуальной ОС-NIC (x.x.128.72)

-

У меня проблема в том, что такой подход, кажется, длится недолго (несколько часов).

По прошествии этого времени кажется, что я теряю возможность подключаться от Virtual-OS-NIC к / из Интернета (но я все еще могу подключиться из хост-ОС к виртуальной-ОС и из хост-ОС в Интернет)

Я перепроверил это пару раз с теми же результатами ... Я оставляю сервер включенным на несколько часов (например, на ночь), и когда я возвращаюсь утром, Virtual-OS теряет возможность маршрутизации к интернет

-

Я не совсем уверен, на что смотреть дальше (или я ошибаюсь в этом)

Один «возможный соответствующий элемент» заключается в том, что ОС хоста также использует RRAS (маршрутизация и удаленный доступ), но это только для запуска простой VPN.

-

Q2 - Пшеницу стоит ли искать дальше? (Любые хорошие ссылки / рекомендации, что попробовать)

Буду признателен за любые мысли или комментарии (даже если вы скажете мне, что я ошибаюсь)

-

* РЕДАКТИРОВАТЬ - Вторая попытка использования «Внешнего» *

Попробовав еще раз с "внешним" подходом, я снова НЕ получил доступа к сети ...

Затем я снял галочку с «Включить идентификацию виртуальной локальной сети для операционной системы управления» ... Эй, престо, все ожило.

Критическая формулировка была скрыта в ссылке «подробнее об управлении виртуальными сетями», в которой говорится

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

Конечный результат ... УСПЕХ (но без объяснения того, почему это ЧАСТИЧНО работало в течение ограниченного времени)

Позже я нашел интересным следующий пост в блоге MSDN ... Общие сведения о виртуальных локальных сетях Hyper-V

Hyper-V на самом деле вообще не является надстройкой к Windows, это фактически полноценный гипервизор, который берет на себя. Первоначально установленная ОС становится корневым разделом, подчиненным Hyper-V. Так что то, что было базовой ОС, теперь технически является особой виртуальной машиной. В этом случае «особая» виртуальная машина может иметь аппаратное обеспечение (чтобы все еще выглядела как обычная ОС). Это конфигурация по умолчанию почти для всего оборудования после включения Hyper-V. Однако когда вы создаете виртуальную сеть для Hyper-V, которая подключена к физическому сетевому адаптеру, Hyper-V становится владельцем сетевого адаптера, и он больше не проходит через нее.

Конфигурация вашей сетевой карты должна быть следующей:

На физическом сетевом адаптере должен быть включен только протокол «Microsoft Virtual Network Switch» (за исключением случаев, когда это не физический сетевой адаптер, например, группа, настроенная на программное обеспечение, у вас обычно есть какой-то другой протокол, который не может быть отключен).

В диспетчере виртуальной сети Hyper-V Manager; создайте «Сеть», это создаст виртуальный сетевой коммутатор в Hyper-V. Сделайте его внешним, подключенным к физической сетевой карте, также установите флажок, чтобы разрешить доступ ОС управления. Это создаст новый vNIC для базовой ОС (помните, что на самом деле это специальная виртуальная машина, поэтому вы добавляете vNIC к этой виртуальной машине ...). Новый сетевой адаптер может быть настроен для IP-адресов, снятых со старого физического сетевого адаптера (зависит от версии Hyper-V, которую вы используете, будет ли он делать это автоматически или нет).

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

Внешние виртуальные сети подключены к физическому сетевому адаптеру. Они позволяют виртуальным машинам подключаться к физическим сетевым адаптерам. Внутренние виртуальные сети всегда создают новый vNIC для ОС управления (флажка нет, это всегда делается). Это позволяет виртуальным машинам связываться с базовой ОС, но не с физическими сетевыми адаптерами. Частные виртуальные сети предназначены только для виртуальных машин и никоим образом не подключаются к ОС управления.

Вы также упомянули проблемы с поддержанием работы. Если вы не используете микросхемы сетевых карт серверного уровня (особенно Intel, Broadcom, QLogic, Emulex, NexGen, Mellanox и т. Д.), Ожидайте проблем. Точно так же убедитесь, что у вас последняя прошивка. Если вы используете чипы Via или Realtek, вы можете сэкономить свое время и отказаться от идеи надежных гипервизоров уровня 1 (Hyper-V, ESXi, KVM и т. Д.).