По работе столкнулся с продуктом SCVMM. Хочу поделиться своими ощущениями от знакомства с ним.
О новой версии 2012 R2 можно найти довольно много информации и в основном это описание возможностей. Как правило такие описания строятся по схеме - создайте нужный вам тип сети и будет вам счастье.
Основной упор в описаниях новой версии продукта делался на виртуальные сети - как там теперь всё круто и можно делать всякие разные сети быстро и удобно.
Для понимания построения сетей в SCVMM нужно усвоить, что необходимо настроить две категории сетей - логические (которые в разделе фабрики) и виртуальные (которые в разделе ВМ). Логические должны отражать нашу физическую сеть. Виртуальные сети уже используются для подключения к ним наших виртуальных машин.
Как обещает нам реклама, есть три типа виртуальных сетей - без изоляции, с изляцией на вланахи с новой изоляцией на виртуализации сети средствами самого SCVMM.
Какую вам сеть? Выбирайте!
Сети без изоляции подразумевают привязку виртуальной сети к конкретной логический.
Виртуальная сеть без изоляции может быть только одна для каждой логический сети. С этим типом сети проблем обычно не возникает - она настраивается и работает вполне себе нормально.
Второй тип сети с изоляцией на вланах уже интереснее. Мне так и не удалось настроить на базе одной логической сети, к которой уже была привязана одна виртуальная сеть без изоляции, ещё одну сеть с изоляцией на вланах. Пришлось создавать новую логическую сеть.
А адаптеров у вас хватит?
Для каждой логической сети необходимо назначить внешний сетевой адаптер. Это и понятно - надо же как то этой сети общаться с внешним миром. Всё верно, но если вдруг я хочу вывести наружу несколько логических сетей через один адаптер? Было бы разумно, но микрософт так не считает и прописывает нам болт.
Это была бы не такая уж проблема, если бы не одно маленькое "но" - у меня по 4 сетевых адаптера на хостах Hyper-V и все они объединены в тиминг.
Причём тиминг средствами того же самого SCVMM. Получается, две технологии микрософта противоречат друг другу. А как красиво всё начиналось...
В общем, при помощи бубна и какой то матери удалось этот косяк обойти.
Дальше с изоляцией сети при помощи вланов всёболее-менее прозрачно - привязываем к логический сети виртуальную и в последней создаём подсети с нужными вланами.
Третий тип сетей с изоляцией на виртуализации сети меня интересовал больше всего. Была задача разворачивать (в идеале - с одной кнопки) группы виртуалок для тестировщиков и каждая группа должна быть в собственной изолированной сетке. Вланы для этого дела не подходят ибо требуют поддержки вланов снаружи, а тестировщикам надо подключаться к своим машинам со своих рабочих компов. В итоге решил делать сети на этом типе изоляции, разместить ещё одну машину с сетевой картой в каждой изолированной сетке и настроить маршрутизацию. Кратко принцип этой изоляции в запаковке пакетов с адресами источника и назначения уровня виртуальной сети (адреса, которые видят виртуальные машины) в пакеты с другими адресами уровня логической сети (адреса, которые видно в трафике между хостами Hyper-V). Каждому адресу ВМ должен быть поставлен в соответствие "внешний" адрес. Соответственно, чтобы этот механизм работал, при создании логической сети (нетрудно догадаться, что необходима отдельная логическая сеть) нужно настроить пул адресов, из которых будут назначаться "внешние" (PA) адреса.
Как создать сеть, не создавая пул?
Далее привязываем к ней виртуальную сеть и в ней настраиваем необходимое количество пулов "внутренних" адресов (каждый пул будет являться отдельной изолированной сеткой). К сожалению, обойтись без этих пулов никак нельзя. Тут, на мой взгляд инженеры микрософта поторопились, объединив в одной субстанции две сущности. Да, изолированная сеть мне нужна, но вот пул как раз наоборот. И сейчас вы поймёте, почему.
Несмотря все описания продукта, в которых говорится о возможности назначать "внутренние" адреса вручную и не создавать пулы, в действительности такая конфигурация не работает - при попытке запустить машину она падает в ошибку, сообщая что ей неоткуда взять CA адрес. И нам приходится создавать пул. К тому же, чтобы выбрать, к какой же изолированной сети будет принадлежать наша машина, нам необходимо выбирать именно из пулов.
Какой такой шлюз?
Далее, при создании пула, первый адрес из пула резервируется под шлюз. Тема шлюза в SCVMM огромна. Замечу лишь, что для использования этой технологии необходима физическая машина для маршрутизации каждой изолированной сети. А поскольку у меня эти сети должны возникать и исчезать пачками (тестовые среды) меня такой расклад не устраивает. К тому же что это за идея с физическими хостами в век виртуализации?
Итак, первым адресом из пула мы воспользоваться не можем. Но это только начало беды - оказывается вместе с пулом поднимается DHCP-сервер. Отключить его нельзя. Вообще! Никак! Это просто финиш... И шлюзом по умолчанию он раздаёт зарезервированный первый адрес из пула.
Это делает такой тип изолированной сети вообще непригодным для работы.
А что, если...?
Далее мною была проделана операция, которая не предвиделась микрософтом совершенно. Удалив одну из машин из одной изолированной сети (удалив адаптер, который смотрел в эту сеть), для которой был задан статический айпишник, я добавил другую машину и также назначил ей айпишник руками. При этом назначил тот же самый айпишник. По мнению микрософта так делать нельзя. Все машины из этой же сети никак не пинговали этот айпишник т.к. он резолвился в мак адрес предыдущего адаптера. При этом всякие перезагрузки и ipconfig /flushdns ни к каким результатам не приводили - SCVMM сам выдавал на все запросы этого айпишника старый мак. Покопавшись, нашёл команду для повершела Revoke-что-то-там. Разобрался с синтаксисом и вернул в скоуп выделенный айпишник а заодно и мак. Но не тут то было! В общем, после долгих танцев с бубном нашёл только один способ решения такой ситуации - полное удаление предыдущей виртуалки, которая заняла адрес.
Такой вот косяк. В общем, насколько я понял, нам предстоит наблюдать ещё довольно продолжительное допиливание SCVMM. Версия 2012R2 пока что видится мне таким зародышем, особенно в части сетей.Ситуация с сетями, на мой взгляд, находится на уровне организаций, которым нужна обычная виртуализация на 10-30 виртуалок без особых изысков. Но как только мы пытаемся организовать работу группы тестировщиков, создающих изолированные среды для тестирования - мы сразу понимаем, что имеющегося функционала крайне недостаточно. Мне даже как-то неудобно употреблять здесь слово "облако". Ну не тянет SCVMM на облако даже с сильной натяжкой - ещё не реализован полноценно даже самый необходимый функционал.
Каков итог?
У SCVMM 2012R2 явно есть серьёзные проблемы. Способность микрософта их осознать и исправить определит в будущем судьбу данного продукта. На данный момент имеется три основных проблемы, мешающие нормальному использованию SCVMM:
1. неграмотная привязка логических сетей к физическим адаптерам. нет возможности вывести несколько логических сетей через один адаптер.
2. неграмотная реализация сетей с изоляцией, основанной на виртуализации сети. нет возможности создать сеть не создавая пул. нет возможности использовать первый айпи адрес в пуле; либо изменить шлюз по умолчанию на адрес, отличный от первого в пуле; либо отключить внутренний dhcp сервер.
3. неграмотная реализация виртуализации сети, проявляющаяся в невозможности использовать адрес из пула другой виртуальной машиной; либо ошибка в реализации взаимодействия мак-адресов.