Требования к железу:
— процессор с поддержкой виртуализации и x64
— 2 сетевые карты с поддержкой 802.1q
Представим, что у нас уже имеется системник с установленным windows hyper-v server 2012 r2 и виртуальной машиной второго поколения. Начнем с настроек хоста hyper-v.
Первым делом настроим объединение сетевых карт. Открываем оснастку диспетчер серверов, щелкаем правой кнопкой по нашему серверу и выбираем «настройка объединения сетевых карт»:
все манипуляции с оснастками windows проводятся под windows 8.1
Настройки могут меняться в зависимости от инфраструктуры. Объединение карт сделано для доступности шлюза в случае выхода из строя сетевой карты или свитча.
Далее создадим виртуальные коммутаторы для локальной сети и интернета. Сделать это можно через оснастку «диспетчер hyper-v» или через powershell.
Открываем оснастку, выбираем наш сервер и в правой части оснастки щелкаем «диспетчер виртуальных коммутаторов». Нам нужно создать 2 внешних виртуальных коммутатора.
Назначаем имя свитчу и выбираем соответствующие сетевые карты. Microsoft networkadapter multiplexor driver — наши объединенные сетевухи. Бывают случаи, когда сетевые карты называются одинаково и различаются они лишь номером в конце. Для определения соответствия можно использовать коммандлет powershell get-netadapter и определить карту по mac адресу, либо статусу up -down. Для виртуального свитча интернета снимаем галочку «разрешить управляющей операционной системе ...», для локальной сети оставляем, если, конечно, у вас нет отдельной сетевой карты для управления гипервизором. Это опция необходима для того, чтобы операционная система гипервизора могла использовать эту сетевую карту для доступа к сети.
Создать виртуальный свитч так же можно через командлет powershell new-vmswitch.
Далее необходимо создать сетевые адаптеры для нашей виртуальной машины. Через оснастку, либо командлет powershell add-vmnetworkadapter.
Создание сетевого адаптера не представляет сложности и, как мне кажется, описания не требует. Если в вашей сети используются VLAN, то вам нужно настроить интерфейсы для каждой сети. Это можно сделать несколькими способами:
- создание виртуальных интерфейсов на уровне хоста гипервизора
- создание интерфейсов на уровне виртуальной машины
- создание подинтерфейсов на уровне виртуальной машины
Первый способ не для нас, т.к. в server core версии и мне не удалось открыть эти настройки в графическом режиме, а редактируя реестр вручную можно что-нибудь да поломать. И если я не ошибаюсь, такой способ не рекомендуем самой майкрософт.
Второй способ удобен и прост. Мы можем создать необходимое нам количество сетевых адаптеров и указать нужный нам vlan в настройках.
Единственное, чем неудобен этот способ, при появлении нового vlan добавление сетевого адаптера возможно только при выключенной виртуальной машине.
Третий способ нас устраивает всем. На нем и остановимся.
Для того, чтобы трафик из всех vlan, которые мы хотим маршрутизировать, нам нужно настроить транк на сетевой карте виртуальной машины. Сделать это можно только через powershell.
Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "100" -VMName "router" -VMNetworkAdapterName "localnet" -NativeVlanId 0
Так уж случилось, что когда я устроился на работу, в сети использовался только 1 vlan, а всё оборудование, находившееся в сети, включая сервера и пк, ходили без тега. При настройке транка я долго не мог понять, почему нетегированный трафик не доходит до моей виртуальной машины, пока не наткнулся на пост, в котором увидел команду powershell с vlan 0, поэтому в качестве native vlan и указан 0.
Далее нам нужно настроить виртуальную машину.
Начнем с адресации.
Пример файла /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
# подинтерфейс для маршрутизацияя трафика из 100 vlan
auto eth0.100
iface eth0.100 inet static
address 192.168.100.1
netmask 255.255.255.0
vlan_raw_device eth0
#internet
auto eth1
iface eth1 inet dhcp
далее разрешим нашей виртуальной машине делать forwarding. Изменим значение net.ipv4.ip_forward на 1 в файле /etc/sysctl.conf и применим изменения путем выполнения команды sysctl -p /etc/sysctl.conf.
И последним штрихом будет настройка nat при помощи iptables.
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source xxx.xxx.xxx.xxx
где xxx.xxx.xxx.xxx ваш ip адресс. Хоть в моем случае и используется dhcp внешний адрес назначается всегда один.
Для динамических адресов следует использовать
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
Для того, чтобы правила iptables сохранялись после перезагрузки, установим пакет iptables-persistent. Название может отличатся в зависимости от дистрибутива.
Теперь пользователи имеют доступ в интернет и всё работает, осталось только настроить репликацию. Делается это через ту же оснастку Диспетчер hyper-v. Открываем оснастку, выбираем наш гипервизор и заходим в параметры hyper-v через панель действие. В параметрах выбираем конфигурация репликации. Далее подробнее:
Включаем реплику.
Использовать Встроенную проверку подлинности Windows — менее безопасная. Работает только в домене active directory и не требует дополнительных настроек.
Использовать проверку на основе сертификатов (HTTPS) — более безопасная. Используйте ее в режиме паранойи и вне домена.
Можно разрешить репликацию со всех серверов hyper-v либо только с указанных. Выбираем второй вариант и указываем там сервер реплику с установленным hyper-v. Группа может иметь произвольное название. Далее делаем аналогичные настройки на сервере реплике.
Чтобы при Переключении машины на сервер реплику не возникло проблем, виртуальные коммутаторы должны называться так же, как и на основном сервере.
Комментарии (26)
Ivan_83
11.07.2016 13:18Странный подход.
Денег типа нет а венду и виртуалки значит ставим, оно ведь не за даром.
Если есть уже какие то системники то и венда и виртуализация не нужны, просто перетыкаем винт или делаем сходную по настройкам систему.
Для роутера два физ адаптера не нужны, хватит и одного при наличии управляемого коммутатора, просто растаскиваем по вланам инет и локалку.
Я в одной организации поднял роутер на фре под гиперви, но там оно имело смысл потому что винда была купленная, сервер мощный и бездействовал, а рядом стоял отдельный старенький системник чисто для выхода в инет. Также там был управляемый коммутатор, поэтому одной сетевушки хватило всем.
HappyGroundhog
11.07.2016 13:55Hyper-V официально бесплатный. Ubuntu 14.04 тоже. Где требуются деньги? =)
pytker
11.07.2016 15:35Сумма потраченая на это всё не считая системников со склада 1080 рублей на покупку двух сетевух с 802.1q.
Shaz
11.07.2016 13:54Ну а при наличии вменяемого multilayer (L2\L3) коммутатора можно VLAN`ы и через него развести.
LoadRunner
11.07.2016 15:08Эм… А Hyper-V нужен лишь для репликации? А чем плохи варианты с двумя шлюзами в режиме Active-Passive? Например, на бесплатном pfSense, или даже сразу на FreeBSD?
Чем в принципе обоснован такой странный выбор?pytker
11.07.2016 15:30Hyper-v был выбран для того чтоб избавится от привязки к железу и беспроблемной ее замены. Про freebsd были мысли но не хотелось плодить зоопарк. Хотя одна из важнейших причин это то что с текущим уровнем зарплат специалист который придет в эту контору после меня просто не разгребет всё в приемлемый срок в случае поломки. keep it simple.
Shaz
11.07.2016 16:07Keep it simple — это как раз про одну железку на pfSense. Из всего выше прочитанного не сложно сделать вывод что контора не слишком богатая, или управляется слишком не умными людьми. Разумеется резервирования внешних каналов связи тут нету. Шанс того что упадет шлюз — крайне мал, если беспокоится за дисковую систему — вполне хватит RAID1, если за сетевые карты — сами написали про LACP. Ну а если допустить что оно таки всеже умерло — то при наличии хорошей документации по сети, развернуть заново тот-же pfSense займет не очень много времени.
А вот шанс того, что неграммотный «специалист» развалит hyper-V (особенно Core-версию) — по моему очень велик.pytker
11.07.2016 17:29Резервирование есть, писать об этом не стал т.к. пост не об этом. Про рейд совсем из головы вылетело когда статью писал. С pfSense не работал так что про простоту ничего не могу сказать. Но со стопроцентной уверенностью скажу что на реплику перейти быстрее. А по поводу того что специалист может сломать hyper-v, тут уж ничего не поделаешь для остальных виртуалок используется тоже он и тоже core версия. Это кстати тоже одна из причин выбора его для шлюза, наверно надо было указать это в статье.
Shaz
11.07.2016 17:50А собрать кластер возможности вообще не было? Это еще быстрее чем реплика. а pfSense — по сути веб-морда к фряхе из которой выпилено все что не касается сети.
pytker
11.07.2016 20:21Для кластера нужна схд которая стоит денег.
Shaz
11.07.2016 20:48Ну можно сколхозить на обычном сервере, ISCSI-таргет легко поднимается как на винде так и на линуксе. С кластером vSphere у меня такая связка нормально работает больше года.
pytker
12.07.2016 07:28Можно, но идея то была в быстром переключении между серваками и ухода от зависимости по железу.
LoadRunner
12.07.2016 10:26Ну теперь вы знаете на ещё один способ больше.
Всё же пощупайте pfSense — он довольно прост в освоении.
А по поводу резервирования — можно как выключенную железку иметь и просто бэкпортировать туда настройки в случае их изменения, так и в режиме High Availability Sync настроить.
Ivan_83
11.07.2016 21:28Бредятина!
Винт/флешку с линухом/фрёй достаточно переткнуть в другой системник и подправить пару текстовиков и оно продолжит пахать как ни в чём не бывало, а если заранее всё правильно настроить то и вообще ничего править не придётся.
Венда же сетапится пол часа, не считая накатки обновлений и дрочива мышкой для конфигуряния.
Обслуживать такой зоопарк совсем не проще.
Надо было воткнуть тплинк за 800 руб и обмыть бы осталось :)
Сетевухи с 802.1q не нужны, собственно сейчас почти все с этим, с другой стороны все ОС уже давно сами умеют работать с тэгами.pytker
12.07.2016 07:32Строить вашу инфраструктуру на флешках вам никто не запрещает и использовать способ описанный выше тоже.
Am0ralist
12.07.2016 15:56Перетыкать жесткие физически? Очень удобное решение, ага. С флешкой тогда уж можно предложить ставить какую живую сборку а-ля Slax — вообще проблем с переносом не будет. Но это все хорошо, если ты физически можешь это быстро сделать.
Вот только виртуалку можно в любой момент перекинуть на другой комп с установленным Hyper-V и через минуту она будет работать.
Так же в любой «момент» это все превращается в отказоустойчивый кластер (+ машина с Huper-V + san на линуксе каком-нибудь чтоб схдшку не покупать), где миграция между узлами несколько секунд, а в случае падения одной машины — в течении секунд 30 виртуалка перезапустится сама.
Обслуживать зоопарк, если в нем уже используется Hyper-V — никаких усложнений. Накатывать можно с образов с интегрированными обновлениями. Не говоря уже о возможности развернуть из образа установленной системы (для одинаковых конфиг). То есть аргументы мимо пролетают.
«Мышка для конфигурирования» — это конечно верх сложности. Куда же лучше через консоль. Ой, powershell под винду уже давно работает и через него люди, представьте себе, все тоже самое могут настроить (даже на хабре выкладывалась минимум одна статья по настройке через powershell). Так что если вы любите именно сиреневый фломастер (читай консоль под линукс) — не надо это на всех распространять: человеку банально может просто удобнее с своего рабочего компа мышкой настраивать сервер.
С сетевухами, кстати, вопрос: где-то встречал комментарий, что под винду объединение в группу силами ОС работает хуже чем через драйверы сетевых карт, но сам не проверял. Если кто знает точно — было бы интересно уточнить этот вопросIvan_83
13.07.2016 10:24Не хочешь — не перетыкай.
Делается ххх одинаковых машин и всё, лазай удалённо.
У меня нет никаких проблем с тем куда ставить фрю: диск, ссд, флешка. Не понимаю зачем нужен какой то особый дистр линуха специально для флешек.
Роутинг — это сверх простая и сверх не затратная задача (на скоростях до гигабита включительно), нахрена нужно городить такие огороды с виртуалками не совсем не понятно.
Нет там ничего такого, от силы 5-6 текстовых файлов конфигов которые добавили/поправили, не стоит оно того чтобы возится с виртуалками.
Про конфигурацию мышой венды было к тому, что там нельзя взять и просто скопировать нужные настройки с одной машины на другую, каждый раз это какой ацкий ад, что проще или АД поставит или руками с нуля.
Насчёт объединения — хз, винда исключительно клиентская машина приминительно к сети, для неё идеально иметь одну сетвуху с одним адресом и тогда никаких проблем.Am0ralist
13.07.2016 11:46Человек сделал виртуалку, которую можно в любой момент запустить на любой свободной машине (при наличии на ней по для работы с виртуалками). Вы предлагаете либо каждый раз диск перетыкать, если железо сломалось, либо кучу одинаковых машин сделать. И кто после этого занимается велосипедостроительством?
Ну раз вы не понимаете — значит точно никому не нужно.
А чего там возиться? Сама виртуалка создается пару минут, а дальше стандартная процедура установки ОС. Возня-то в чем? Забекапить виртуалку после настроек?
Куда копировать, зачем копировать, что копировать? Вы вообще о чем касаемо виртуалок и данной статьи?
Последний пассаж вообще за гранью и попахивает исключительно фанатизмом. Вот уж год, как два сервака с 6 интерфейсами каждый работают в отказоустойчивом кластере и в душе не знают, что оказывается для виндоуз идеально одна сетевуха с одним адресом, надо пойти им об этом сказать что ли.Ivan_83
13.07.2016 14:00Сейчас виртуалят всё подряд без разбору надо оно вообще или нет.
Виртуалки это мастхэв для работы с виндами в качестве гостя, как самое адекватное средство переноса на другое железо и бэкапа который 100% заработает.
Для не винды есть некоторая грань когда виртуализация системы обретает смысл, поскольку проблемы переезда на другое железа практически нет, а настройки все на виду и легко переносятся. Я бы виртуалил разве что всякие биллинги и прочее где тонны настроек в куче мест и времени на разбирательства мало.
Виртуализировать роутер на линухе только ради переноса на другое железо — это ТУПО.
Он там и десятка файлов не поменял после сетупа, да и проблемы с перетыканием в др железо нет.
Если же у него оно в виртуалке загнётся то всё равно нужно быть в пределах локалки чтобы поднять.
При некотором желании можно сделать автоматически подымающийся второй роутер, но это с виртуализацией никак не связано.
Те как ни крути а виртуализация тут лишняя сущность, если только не идёт речи о том, чтобы железа стало меньше.
Да хоть 100 интерфейсов, пока конфигурация простая оно работает, как только хочется чуть больше чем от десктопа с одной сетевушкой начинаются чудеса.
Я приключений избегаю потому не горожу на винде ничего сложного.Am0ralist
13.07.2016 15:23«Виртуализировать роутер на линухе только ради переноса на другое железо» — вы очень внимательно отвечаете на свои же слова и не слушаете других. Вопрос и в том, что одновременно и отвязано от железа и перенос осуществляется «мгновенно», т.е. если железяка упала — мгновенно поднял виртуалку на другой железяке. Не надо ничего ставить, настраивать и прочее. Не надо держать запас.
«Если только не идёт речи о том, чтобы железа стало меньше» — железа может не быть меньше, но вот в запасе можно не хранить + одну железяку. Т.е. какое-то время виртуалка может поработать в паре с другой, сами говорите — не настолько задача требовательна.
«Если же у него оно в виртуалке загнётся то» можно будет просто запустить виртуалку из бекапа сразу при обнаружении проблем.
«пока конфигурация простая оно работает» — насколько сложная конфигурация вас устроит? одна сеть для миграции между серваками, одна для работы с схд, одна для подключения пользователей к серверу (т.е. все по рекомендациям мс) — это все еще просто или все таки уже отличается от «одна сетвуха с одним адресом»? Или вы так и будете отодвигать границы простоты увеличивая и количество интерфейсов, и количество сетей, и прочее? И да, у меня и на простом декстопе было по две сетевых (и с мостом, и в разных сетях) — никаких проблем особых не возникало.
pytker
13.07.2016 17:55С каждым комментарием всё больше начинаю сомневаться в вашей компетентности и даже адекватности. То что вы говорите больше похоже на троллинг в стиле «я сделал по другому и у меня всё работает, а у вас херня какая то». Вы с такой уверенностю говорите о количестве измененных конфигов хотя я нигде не упоминал что в статье полностю приведена конфигурация моего шлюза включая каждый измененный файл. успокойтесь уже, избавьте людей от своих комментариев не по существу.
pytker
13.07.2016 17:58комментарий был посвящен пользователю Ivan_83 но автор был слишком уставшим и промахнулся по кнопке «ответить».
Shaz
Велосипед однако. Особенно радует объединение сетевых карт. Как минимум тут следовало бы указать что оно требует поддержки со стороны коммутатора к которому мы подключаемся, и совершенно неясно чем оно поможет при выходе этого самого коммутатора из строя?
А к чему этот вариант? Тем более что он в принципе не возможен после объединения сетевух. И в добавок те физические адаптеры на которых создается VirtualSwitch по умолчанию переводятся в транк?
HappyGroundhog
в Тиминге 2012 R2 есть 3 способа агрегации. Два из них не требуют поддержки со стороны коммутатора. Приведенный на скриншоте вариант тоже. При выходе из строе коммутатора не поможет, но никто не мешает разнести на два коммутатора.
pytker
Если внимательно посмотреть на скриншот номер 2 то можно увидеть что в данном случае настройка коммутатора не требуется. Кабели из двух сетевых карт подключены в разные коммутаторы. При выходе из строя коммутатора или сетевухи пакеты продолжат ходить и связь с космосом сохранится.