перенос nativeboot vhd (vhdx) диска.

Использование VHD/VHDX дисков для установки ОС в режиме nativeboot в теории весьма удобно, но, как оказалось, на практике возникли сложности. Основная сложность - "что вообще с этим делать?" Потребовалось переконфигурировать RAID массив (перетащить данные в другое место, перестроить, вернуть все на место). Все это можно сделать с использованием обычных загрузочных дисков (Win server 2016 iso в моем случае), там есть режим восстановления с командной строкой и он видит мой контроллер без установки дополнительных драйверов.

После создания нового рейд массива (в bios или другими способами) нужно полученный диск инициализировать, создать раздел UEFI (100mb) и раздел для размещения VHDX файла. После копирования VHDX файла нужно примонтировать его и создать в UEFI разделе указатель для загрузки с примонтированного VHDX. Для этого потребуется использовать Diskpart и bcdboot. Речь идет про UEFI, для BIOS похоже, но чуть по другому.

Выдержка из документации Microsoft.

diskpart
list disk

Выбираем из списка нужный нам диск (свежесобранный массив).

select disk 0
clean
convert gpt
rem == 1. создаем системный раздел  и назначаем ему букву S==========
create partition efi size=100
format quick fs=fat32 label="System"
assign letter="S"
rem == 2. Microsoft Reserved (MSR) partition =======
create partition msr size=128
rem == 3. ну и диск для данных  с буквой M===========================
create partition primary
format quick fs=ntfs label="Main"
assign letter="M"

Неплохо бы еще глянуть на разделы

list volume
exit


Есть разбитый на разделы диск, копируем диск VHDX  чем и как угодно. Например
xcopy f:\windows.vhdx m:\

А теперь самое интересное

diskpart
select vdisk file=M:\windows.vhdx
attach vdisk

неплохо бы опять

list volume

Видим что VHDX подключился и на нем есть разделы, выясняем раздел с установленной ОС, пусть будет V:\ к примеру.

V:\
cd v:\windows\system32
bcdboot v:\windows /s S: /f UEFI

Перезагружаемся, все должно работать. За исключением Hyper-v. Для работы гипервизора оказывается надо еще
bcdedit /set hypervisorlaunchtype auto

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

Сменить динамический ip-адрес на статический в SCVMM на работающей VM

Задать тип IP адреса (динамика или статика) можно при создании VM. Но если потребовалось изменить этот тип уже после создания, то можно сделать это через powershell. Здесь мы меняем тип для первого сетевого интерфейса. (Google помог по запросу scvmm change to static ip powershell )

$vm = Get-ScvirtualMachine -Name "имя нашей VM"
$staticIPPool = Get-SCStaticIPAddressPool -Name "имя нашего пула статических адресов"

Grant-SCIPAddress -GrantToObjectType "VirtualNetworkAdapter" -GrantToObjectID $vm.VirtualNetworkAdapters[0].ID -StaticIPAddressPool $staticIPPool

Set-SCVirtualNetworkAdapter -VirtualNetworkAdapter $vm.VirtualNetworkAdapters[0] -IPv4AddressType static

Испробовал - работает. Если машина включена и управляется агентом, то и адрес меняет в VM. Пробовал на Win, на Lin VM так делал, но IP внутри VM менял руками. 

Смена технологий в СХД

Типичное инфраструктурное решение для SMB сейчас это несколько хостов с установленными гипервизорами и некий вариант Shared Storage для возможности кластеризации. И чаще всего эта схема выглядит как пара, тройка хостов подключенных к NAS по iSCSI. Hyper-v сейчас работает по SMB 3.0, и что то там можно накрутить с Clustered Shared Storage в среде Microsoft, что должно по идее дать много плюшек вместе с Storage Spaces. Но сейчас не об этом, я пока не игрался :). Традиционно люди закупают NAS'ы для этих целей или полки с подключением по SAS.

В очередном проекте возникла задача построения кластеров на имеющемся оборудовании, и при этом никаких СХД не было в наличии. Первым решением было поднять на одном из серверов хранилище и завязаться на него. Поскольку сервера были HP, в ходе обновлений прошивок наткнулся на интересное решение - HP StoreOnce VSA.

Уже потом выяснил что для пользователей VMWare даже есть родные решения такого же плана vSAN и еще что то. И что на рынке сейчас много подобных решений StarWind, Nutanix. Технологии имеют маркетинговый шильдик "Гиперконвергентность". Касательно HP StoreOnce  все работает - проверено. Оно до 1ТБ еще и бесплатное теперь, при этом работает не только на серверах HP! А в SMB шансов уместить в 1-1,5 ТБ важные виртуальные машины как раз много.

Суть в том что сервера сами себе СХД, причем распределенное, отказоустойчивое СХД. Берем дисковое пространство, отдаем его в некий общий пул, а потом подключаемся к этому же общему пулу и получаем из него нужное нам пространство.

Решение HP VSA StoreVirtual предоставляемое компанией HP совместно с Intel сроком на 3 года, ограниченное 3мя нодами хранилища и 1 террабайтом дискового пространства на каждой из нод. В результате внедрения получаем общее дисковое пространство до 1,5 Tb (доступное для использования), подключаемое по iSCSI к хостам гипервизоров, используемое для целей создания отказоустойчивого кластера Hyper-V.

На аппаратном хосте создается дисковый аппаратный RAID уровня 10. На нем располагается диск VHDX, который предоставляется виртуальной машине HP VSA. Несколько таких виртуальных машин в свою очередь формируют виртуальную SAN. Сформированные в виртуальной SAN диски предоставляются тем же аппаратным хостам (или любым другим) по iSCSI. На подключенных таким образом дисках гипервизоры могут создавать отказоустойчивые решения (кластеры), как в рамках целей виртуализации, так и в рамках кластерных решений БД, приложений и пр. Чуть позднее вычитал где то что лучше отдавать не готовый VHDX, а выделенный логический диск  сформированный Raid контроллером (ну или LUN). Мы же мигрировать виртуальную машину с хранилищем не будем.

Синим выделены виртуальные машины HP VSA; черным – аппаратные хосты гипервизор; оранжевым – виртуальные машины. 

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

Можно построить на двух, но тогда нужен некий третий сервер, который будет определять - кто из серверов VSA живой, а кто нет в случае конфликта. Третий требует минимальных ресурсов, почти ничего.

Возможно масштабирование увеличением количества нод, но это уже лицензии нужны.

Много вопросов возникло при планировании решения, при тестировании. Как что лучше настроить, подключить. В качестве примера - схема подключения.

В самой СХД участвуют только первые три сервера, четвертый в данном случае не содержит общего пространства. Но подключен к iscsi vlan и может использовать общее хранилище. Суть в том что для подсистемы хранения (виртуальных машин StoreOnce VSA) выделяем отдельные сетевые интерфейсы. Два, поскольку хотим иметь агрегацию и отказоустойчивость.  Подключаем к двум коммутаторам. А коммутаторы связываем между собой агрегацией. Можно все в один коммутатор, тогда коммутаторы практически не нужно настраивать. Вся настройка будет заключаться в выделении для СХД подсети отдельного Vlan. Пакеты дальше этих коммутаторов лучше не гонять, ибо латентность.

Дьявол в деталях, так что на самом деле эта схема ошибочна. 

Тиминги интерфейсов VSA делать не умеет!!! Так что тиминг нужно делать силами гипервизора (vSwitch)

На серверах в данном случае всего 4 интерфейса сетевых, а нужно 6! Потому что лучше отдать VSA пару интерфейсов для своих нужд (и сделать тиминг на уровне Hyper-v), дать самим Hyper-v пару интерфейсов для подключения к хранилищу по iSCSI (уже без тиминга, т.к. здесь уместнее MPIO), и для виртуальных машин тоже нужно что то выделить. С трудом можно совместить траффик VSA и iSCSI на одних и тех же интерфейсах, но в этом случае либо не будет Teaming для VSA, и VSA будет использовать только 1 интерфейс, либо MPIO не использовать. В общем - лучше 6.

Управление VSA осуществляется при помощи ПО HP StoreVirtual Centralized Management Console. Консоль можно установить на созданном для этого виртуальном сервере. Возможна установка консоли на другие сервера, для управления достаточно доступа с этих серверов к сети VSA. Сервер можно свободно перемещать между хостами гипервизоров, не рекомендуется его хранить на самом СХД, а для работы ему требуется доступ к сети VSA.
Гиперконвергентные решения в SMB скорее всего будут обходить по соотношению цена/производительность и цена/емкость и всем кому грозит апгрейд СХД или просто планируется покупка - стоит посмотреть в эту сторону. Конкуренция на этом рынке сейчас есть, есть из чего выбрать.