Вступление

Понадобилось мне на домашней лабе с ESX погонять vSAN. Однако прежде, чем все переделывать на Intel NUC 9, решил отработать будущую конфигурацию и пробежаться по основным шагам на ноуте, предназначенном для кратких частых экспериментов.

Поскольку для vSAN нужно диск для capacity, диск для cache tier, да еще и загрузиться с чего-то надо, даже для NUC с двумя дисками требуется еще и третий носитель, часто SD-карта. Вот эту загрузку с мелкого носителя я захотел отработать.

Конечно, у ноута только 1 диск, значит два устройства по USB подключить придется, ну да ладно. Проблема вылезла, откуда не ждал. Несмотря на то, что гугл выдавал кучу рекомендаций, как установить ESX на флешку/карту, в том числе непосредственно с сайта VMware, флешка категорически отсутствовала в опциях установки.

Оказалось, что совсем недавно такая возможность стала deprecated, и даже на весьма популярном сайте появился пост от фаната vSAN: Considerations for future vSphere Homelabs due to upcoming removal of SD card/USB support for ESXi.

Собственно, в этой статье я опишу, как мне все-таки удалось загрузиться с флешки. Может быть какое-то время еще получится грузиться с USB, но в большей степени я рассчитываю на дискуссию в комментариях, как дальше жить, и, если отказываться от vSAN в домашней лабе, на что именно.

Установка

Загружаюсь с DVD (это мне позволяет Zalman с VMware-VMvisor-Installer-7.0U3-18644231.x86_64.iso на нем). Вижу NVMe диск в ноуте, а вот флешки не вижу. Ибо на флешку ESX больше не желает ставиться. Вспомнив, как когда-то Windows не хотел устанавливаться на флешку, но определенными манипуляциями удавалось сделать ее похожей на диск, решил попробовать такой же трюк.

Первое, что гуглилось - lexar_usb_tool. Однако Flip removable bit не помог. Попробовал традиционный rufus – тоже не удалось обмануть систему. В итоге с помощью RMPrepUSB сделал из флешки USB диск, записав для этого Free DOS (хотя и неважно, что именно записывать).

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

Появился DataTraveler:

На него и установим.

Есть такая же флешка 16GB, но хватило и 8GB. Также пробовал «безродную» флешку, тоже распозналась.

Первоначальная установка

Поскольку в ноуте только один диск, пришлось подключить еще и USB диск именно для vSAN. Для NUC это не потребуется. Я взял опять же имеющийся под рукой мелкий 128GB GB SSD mSATA («большая быстрая флешка»).

Но по умолчанию VMware USB диски отдает в виртуальные машины. Чтобы она его увидела для своих нужд, следует отключить USB арбитр. Также нужно «разрешить» использовать USB диск для vSAN:

/etc/init.d/usbarbitrator stop
chkconfig usbarbitrator off
esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

Однако проверка показывает, что диски еще не готовы для использования с vSAN. Ineligible for use by VSAN, поскольку Has partitions:

#vdq -q
{
"Name" : "mpx.vmhba32:C0:T0:L0",
"VSANUUID" : "",
"State" : "Ineligible for use by VSAN",
"Reason" : "Has partitions",
"IsSSD" : "0",
"IsCapacityFlash": "0",
"IsPDL" : "0",
"Size(MB)" : "7502",
"FormatType" : "512n",
"IsVsanDirectDisk" : "0"
},

{
"Name" : "t10.NVMe____SAMSUNG_MZVPV512HDGL2D00000______________S1XXNYAH701533______00000001",
"VSANUUID" : "",
"State" : "Ineligible for use by VSAN",
"Reason" : "Has partitions",
"IsSSD" : "1",
"IsCapacityFlash": "0",
"IsPDL" : "0",
"Size(MB)" : "488386",
"FormatType" : "512e",
"IsVsanDirectDisk" : "0"
},

{
"Name" : "mpx.vmhba34:C0:T0:L0",
"VSANUUID" : "",
"State" : "Ineligible for use by VSAN",
"Reason" : "Has partitions",
"IsSSD" : "0",
"IsCapacityFlash": "0",
"IsPDL" : "0",
"Size(MB)" : "120832",
"FormatType" : "512n",
"IsVsanDirectDisk" : "0"
}

Для того, чтобы vSAN распознал диски, они должны быть пустыми, без разделов. Обычно их можно хоть из клиента стереть (Storage | Devices | Disk XXX | Actions | Clear partition table). Но если, как в моем случае, на NVMe в ноуте ранее стояла VMware ESX, этот диск «захватится», и один из разделов удалить не получится.

Пробовал через стандартные

partedUtil delete /dev/disks/t10.NVMe____SAMSUNG_MZVPV512HDGL2D00000______________S1XXNYAH701533______00000001 7

И даже

dd if=/dev/zero of="/dev/disks/t10.NVMe____SAMSUNG_MZVPV512HDGL2D00000______________S1XXNYAH701533______00000001" bs=512 count=34 conv=notrunc

ничего не помогало, ругалось на read-only filesystem. В итоге загрузился с LiveCD с Ubunta, и с него все почистил.

 Собственно, это было основное, дальше можно устанавливать, как обычно, специалисты лучше расскажут. Для меня же VMware – инструмент для стендов (наравне с vagrant и т.п.). И среда, в которую мы свои решения интегрируем, поэтому основные моменты, конечно, я должен знать, но оптимизации и тонкие настройки не по моей части.

Для полноты картины опишу, с какими сложностями еще пришлось столкнуться, а закончу вопросами :)

vSAN

Установка

Есть возможность после установки ESX запустить установку vCenter и выбрать «на новый vSAN кластер». Но у меня почему-то висло на 9%. В логах после «debug: Vsan has been enabled» шло «error: Cannot change the host configuration.»

Так что я «покривил душой» и установил vSAN на внешний Datastore, подмонтированный по iSCSI (можно и NFS). Впоследствии мигрировал его на vsanDatastore. Так что все честно, загружаюсь с флешки, vSAN на ноуте, 1-node, без внешних хранилищ.

Distributed Switch

Создал Distributed switch, традиционно перевел на него сеть, удалил стандартный vSwitch0.

Поскольку при миграции кратковременно теряется сетевая связность, vCenter откатывает изменения назад. Так что временно нужно отключить Rollback

На vCenter: в /etc/vmware-vpx/vpxd.cfg в секции <network> у параметра <rollback> нужно установить false и перезагрузить vCenter. Потом лучше вернуть обратно.

Запустил Quick Start для vSAN. Почему-то Use existing switch мой distributed switch не показывал. И vmk для vMotion/vSAN создавал в отдельных vlan – все бестолку.

Так что откатил обратно к vSwitch, и попросил визард создать мне Distributed Switch, как он считает нужным. Получилось:

Зачем он создал портгруппы и со статикой (dsPrimary-VM) и с эфемерным биндингом (dsPrimary-VM-ephemeral) – не знаю. Ну немудрено, что мой свич его не удовлетворял, у меня такой красоты не было :)

Потом я уже под себя его переделал, конечно, и все перевeл на него (опять без vSwitch).

Tolerance

Хотя все и установилось, писать на vsanDatastore было невозможно, ибо “1 usable fault domain… requires 2 more…”

Что сделал:

esxcli vsan policy setdefault -c cluster -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))"

esxcli vsan policy setdefault -c vdisk -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))"

esxcli vsan policy setdefault -c vmnamespace -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))"

esxcli vsan policy setdefault -c vmswap -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))"

esxcli vsan policy setdefault -c vmem -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))"

 Поскольку не сработало, усугубил:

esxcli vsan policy setdefault -c cluster -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1) (\"stripeWidth\" i1))"

esxcli vsan policy setdefault -c vdisk -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1) (\"stripeWidth\" i1))"

esxcli vsan policy setdefault -c vmnamespace -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1) (\"stripeWidth\" i1))"

esxcli vsan policy setdefault -c vmswap -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1) (\"stripeWidth\" i1))"

esxcli vsan policy getdefault

В итоге все стало хорошо после дополнительной правки Fault tolerance: 0 (вместо 1 по умолчанию) в Edit VM Storage Policy.

И новые машинки стали создаваться, и мигрировать vCSA удалось.

Нечто подобное было и со стартом VM. С vCenter не запускались: «Insufficient resources to satisfy configured failover level», хотя непосредственно с хоста нормально стартовали.

Чтобы заработало, отключил Admission Controller.

Что получилось

куча скриншотов

У ESX хоста есть предупреждение, вполне оправданное. Да, стоит логи переназначить на внешний хост для разбора полетов в случае чего. Но на работу это не влияет.

И еще про производительность:

Интересно было бы сравнить с тем же USB диском, что я использую в качестве capacity tier при подключении к физическому серверу. Наиграюсь с vSAN, разберу его, тогда и проверю.

Мысли и вопросы

Как организовать Remote datastore и стоит ли делать vSAN для лабы?

Если нужно именно vSAN посмотреть, как в данном случае – само собой. Но вот для постоянной лабы (NUC с двумя NVMe), как лучше?

Обычный Datastore (VMFS на обоих дисках)

К примеру, Tanzu развернуть вроде можно и на одном хосте, поправив minmasters в /etc/vmware/wcp/wcpsvc.yaml. Но хочется ведь более реального. И даже при использовании Nested virtualization уже нужен datastore, доступный с разных хостов.

А) Поднять виртуалку с большим вторым диском и отдавать как NFS или iSCSI.

Немного странно выглядит: взяли диск, сделали на нем VMFS, из виртуалки его разбили на разделы, презентуем по iSCSI, а внутри делаем опять VMFS.

Если не разбивать на разделы и вместо direct-store сделать backing-store, получается не менее странно (VMFS, ext4, файл для LUN, внутри которого VMFS).

Или норм?

Passthrough диск целиком в вируталку

Сейчас у меня на NUC второй NVMe так и проброшен. На нем два равных раздела презентуются по iSCSI (Viper1, Viper2).

Смущает последовательность запуска. Вроде как сначала надо эту «файлсерверную» виртуалку поднять (на ней еще всякие графаны в докере), потом vCenter. Но есть еще виртуалка Router (DHCP, DHCPv6, SLAAC, DNS…) с кучей VLAN (в т.ч. vSAN VLAN отдельно от vMotion, Management…). По идее ее самой первой поднимать надо.

В общем, бывает так, что раздел Viper1 полностью нормально поднимается, а Viper2 (точно такой же) – attached, not consumed. Datastore для heartbeat недоступен, предупреждения… Лечится через vmkfstool -V, но напрягает.

В принципе логично, на самом хосте есть отсылка к этому датастору, который станет доступным только после старта виртуалки. Некрасиво ввыглядит.

vSAN

Собственно потому и задумался о vSAN, что он первый поднимется и отдастся нативно. А для всего остального уже отдельная виртуалка (VMware ESX agent) отдаст и SMB, и NFS, и iSCSI.

Даже если загрузку с USB совсем запретят, не смертельно, NUC и с маленького iSCSI поднимется. Но вот если пойдут какие-то ошибки на vSAN, не представляю, как лечить. В норме-то должно быть несколько серверов с примерно одинаковыми дисками. А тут «умерла, так умерла».

Из плюсов – помимо «родной, встроенный» имеется кеширование. Можно было бы NVMe 512GB отдать под кеширование, и по USB подцепить capаcity обычный хороший большой HDD и иметь вполне нормальную производительность. Но сдается мне, что с отключенным USB arbitrary я в виртуалки потом USB не проброшу, если вдруг понадобится.

NFS vs iSCSI

В отношении надежности и удобства мне NFS в качестве remote datastore нравится больше, чем iSCSI. Вот они файлики, если что – не все виртуалки скопом умрут. Да и вообще операционная система знает, когда пишется «что-то внутри конкретного vmdk», а когда апдейтятся важные области в таблице файлов на хосте (и надо поаккуратнее). А в случае iSCSI хост понятия не имеет, что там внутри творится. Мне кажется, на NFS меньше шансов, что весь диск (datastore целиком) логически умрет.

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

Опять же, на NFS можно и бэкапы слать, хоть тот же Veeam Community Edition. Собственно, так у меня сейчас и сделано. Но не годится рабочие системы держать на том же диске, что и бэкапы, и домашние терабайты, надо отдельно.

С чего грузиться?

Конечно, вышеперечисленные проблемы решаются установкой Synology DS920+. Тут и пара гигабитных интерфейсов для LAG, и SSD кеш, и iSCSI. Но цена…

Есть возможность просто древний ноут (или даже RPi?) поставить в качестве iSCSI. Не для быстрого датастора, а только грузить ESX. При этом оба NVMe диска можно сделать passthrough.

Или даже на них собрать vSAN (capacity – 2TB с не очень большим количеством циклов перезаписи; cache 128-256 GB, но более живучий и быстрый).

В общем, буду рад комментариям, как у вас лаба реализована, где я слишком заморачиваюсь, и можно проще.

Как бы вы организовали лабу из NUC 9 (Xeon, 8 cores, 16 threads), 2 NVMe, 64GB RAM, чтобы это хозяйство и Nested virtualization поддерживало?

Update: Пока статья была на модерации

1) Нашел таки, как в своем NUC 9 добавить третий NVMe диск. Так что смогу поднять vSAN на нем без извращений

2) На vSAN ноута столкнулся с тем, что его "родной" iSCSI не может быть подмонтирован другим VMware (а также другими гипервизорами - это не глюк, а так и задумано). Ну т.е. с Win10 прекрасно цепляется как диск, разбивается на разделы, все, что угодно. А вот с VMware на NUC не монтируется. А я хотел как датастор объявить, чтобы туда виртуалки смигрировать на момент переустановки, а потом обратно забрать.

Не смертельно, как NFS datastore работает нормально. Но удивился.

3) Производительность диска как capacity в vSAN datastore оказалась выше, чем при непосредственном подключении к физической Linux машинке. Видимо благодаря cache tier в vSAN. Этот момент понравился.

И визуально виртуалки, физически расположенные на ноутбучном vSAN, но запускаемые на NUC как с NFS datastore, стартуют и работают вполне себе шустренько. Не хуже, чем на приаттаченном USB HDD.