{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "SOREX.ORG: заметки с тегом esxi", "_rss_description": "Exchange, esx, AD, GPO, veeam, adaptec,lsi megaraid", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/sorex.org\/?go=tags\/esxi\/", "feed_url": "https:\/\/sorex.org\/?go=tags%2Fesxi%2Fjson%2F", "icon": "https:\/\/sorex.org\/user\/userpic@2x.jpg?1618299116", "author": { "name": "sorex", "url": "https:\/\/sorex.org\/", "avatar": "https:\/\/sorex.org\/user\/userpic@2x.jpg?1618299116" }, "items": [ { "id": "67", "url": "https:\/\/sorex.org\/?go=all\/kak-uznat-uuid-v-esxi-5-5\/", "title": "Как узнать UUID в ESXI 5.5", "content_html": "

The vCenter does have a UUID.<\/p>\n

To view it simply go to https:\/\/VC-FQDN\/mob<\/a><\/p>\n

Click on RetrieveServiceContent -> Invoke Method<\/p>\n

The UUID is listed as instanceUuid.<\/p>\n", "date_published": "2021-11-15T06:06:50+00:00", "date_modified": "2021-11-15T06:06:13+00:00", "_date_published_rfc2822": "Mon, 15 Nov 2021 06:06:50 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "67", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "65", "url": "https:\/\/sorex.org\/?go=all\/vcenter-6-7-umenshit-pamyat-dlya-ustanovki\/", "title": "vCenter 6.7 уменьшить память для установки", "content_html": "

В папке установки VMware VCSA перейдите в Vcsa-ui-installer \\ win32 \\ resources \\ app \\ resources.
\nОткройте файл с именем layout.json в Блокноте.
\nВы можете сначала создать копию этого файла.
\nВнутри layout.json файла, прокрутите вниз до «tiny». Существует несколько вариантов, поэтому убедитесь, что вы выбрали вариант с меткой: «Tiny vCenter Server со встроенным PSC», который зависит от размера развертывания, Tiny, размера хранилища, по умолчанию (300 ГБ) и со встроенным PSC.
\nнедостаточно памяти на хосте для выбранного размера
\nИзмените «память» на желаемое значение. 6 ГБ (6144 МБ) в моем случае. Сохраните изменения.
\nВ следующий раз, когда вы запустите установку VCSA, вы увидите, что развертывание Tiny было уменьшено до 6 ГБ (или вашего значения)
\nнедостаточно памяти на хосте для выбранного размера
\nТеперь вы можете продолжить развертывание VCSA.
\nПримечание. Это изменение не отразится на виртуальном оборудовании при создании VCSA (ВМ), его нельзя изменить, и вы по-прежнему видите 10 ГБ. Но из монитора ресурсов вы увидите, что в качестве ограничения используется 6 ГБ.<\/p>\n", "date_published": "2021-09-14T06:24:25+00:00", "date_modified": "2021-09-14T06:24:20+00:00", "_date_published_rfc2822": "Tue, 14 Sep 2021 06:24:25 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "65", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "64", "url": "https:\/\/sorex.org\/?go=all\/perenos-qcow-diska-iz-libvirt-v-esxi\/", "title": "Перенос qcow диска из libvirt в ESXi", "content_html": "

qemu-img convert -f qcow2 myImage.qcow2 -O vmdk myNewImage.vmdk
\nпотом переносим на esxi и в консоли хоста делаем:
\nvmkfstools -i myImage.vmdk outputName.vmdk -d thin
\nна выходе получаем 2 файла один заголовок диска и второй flat диск<\/p>\n", "date_published": "2021-09-06T11:19:24+00:00", "date_modified": "2021-09-06T11:19:20+00:00", "_date_published_rfc2822": "Mon, 06 Sep 2021 11:19:24 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "64", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "47", "url": "https:\/\/sorex.org\/?go=all\/otklyuchaem-soobschenie-the-number-of-vsphere-ha-heartbeat-datas\/", "title": "Отключаем сообщение The number of vSphere HA heartbeat datastores for this host is 1 which is less than required 2 в ESXI 5.X.X", "content_html": "

Данное сообщение появилось с введением в механизм VMware HA функционала Datastore Heartbeating, который позволяет хостам кластера общаться посредством хранилища данных и за счет этого более корректно отрабатывать ситуации, связанные с изоляцией хоста.<\/p>\n

Сообщает оно о том, что для общения хостов используется только 1 общее хранилище, а рекомендуется минимум 2 (для надежности). Это может быть связано либо с тем, что в настройках кластера жестко выставлено использование только 1 хранилища, либо у вас всего 1 общее хранилище.<\/span><\/p>\n

В 1-м случае лучше выставить автоматическое определение используемых датасторов, а во втором случае можно просто отключить сообщение, особенно, если инфраструктура тестовая.<\/p>\n

Отключается так — Правой по кластеру -> Edit Settings -> vSphere HA -> Advanced<\/p>\n

<\/div>

\"The<\/a><\/p>\n

The number of vSphere HA heartbeat datastores for this host is 1 which is less than required 2-01<\/p>\n<\/div>

Дальше добавляем пункт «das.ignoreinsufficienthbdatastore» со значением «true»:<\/p>\n

\"The<\/a><\/p>\n

The number of vSphere HA heartbeat datastores for this host is 1 which is less than required 2-02<\/p>\n<\/div>

 <\/p>\n", "date_published": "2021-04-13T10:18:44+00:00", "date_modified": "2021-04-13T10:18:41+00:00", "_date_published_rfc2822": "Tue, 13 Apr 2021 10:18:44 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "47", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "31", "url": "https:\/\/sorex.org\/?go=all\/uskorenie-domashnego-esxi-6-5-s-pomoschyu-ssd-keshirovaniya\/", "title": "Ускорение домашнего ESXi 6.5 с помощью SSD кэширования", "content_html": "

В данной статье хочу рассказать о том, как немного повысить производительность хоста ESXi с помощью SSD кэширования. На работе и дома я использую продукты от компании VMware, домашняя лаборатория построена на базе Free ESXi 6.5. На хосте запущены виртуальные машины как для домашней инфраструктуры, так и для тестирования некоторых рабочих проектов (как-то мне пришлось запустить на нем инфраструктуру VDI). Постепенно приложения толстых ВМ начали упираться в производительность дисковой системы, а на SDD все не помещалось. В качестве решения был выбран lvmcache. Логическая схема выглядит так:<\/p>\n


\n<\/a>
\nОсновой всей схемы является ВМ svm на базе CentOS 7. Ей презентованы HDD диски средствами RDM и небольшой диск VMDK с датастора SSD. Кэширование и зеркалирование данных реализуются программными средствами — mdadm и lvmcache. Дисковое пространство ВМ монтируется к хосту как NFS датастор. Часть датастора SSD отведена ВМ, которым требуется производительная дисковая подсистема.<\/p>\n

Вычислительный узел собран на десктопном железе:<\/p>\n

MB: Gygabyte GA-Z68MX-UD2H-B3 (rev. 1.0)
\nHDD: 2 x Seagate Barracuda 750Gb, 7200 rpm
\nSSH: OCZ Vertex 3 240Gb<\/p>\n

На материнской плате имеется 2 RAID контроллера:<\/p>\n

— Intel Z68 SATA Controller
\n— Marvell 88SE9172 SATA Controller<\/p>\n

Завести 88SE9172 в ESXi у меня не получилось (There is a bug in the firmware of some Marvell adapters (at least 88SE91xx)), решил оставить оба контроллера в режиме ACHI.
\n

RDM<\/h3>
\nТехнология RDM (Raw Device Mapping) позволяет виртуальной машине обращаться напрямую к физическому накопителю. Связь обеспечивается через специальные файлы «mapping file» на отдельном томе VMFS. RDM использует два режима совместимости:<\/p>\n

— Виртуальный режим — работает так же, как и в случае с файлом виртуального диска, позволяет использовать преимущества виртуального диска в VMFS (механизм блокировки файлов, мгновенные снэпшоты);
\n— Физический режим — предоставляет прямой доступ к устройству для приложений, которые требуют более низкого уровня управления.<\/p>\n

В виртуальном режиме на физическое устройство отправляются операции чтения\\записи. RDM устройство представлено в гостевой ОС как файл виртуального диска, аппаратные характеристики скрыты.<\/p>\n

В физическом режиме на устройство передаются практически все команды SCSI, в гостевой ОС устройство представлено как реальное.<\/p>\n

Подключив дисковые накопители к ВМ средствами RDM, можно избавиться от прослойки VMFS, а в физическом режиме совместимости их состояние можно будет мониторить в ВМ (с помощью технологии S.M.A.R.T.). К тому же, если что-то случится с хостом, то получить доступ к ВМ можно, примонтировав HDD к рабочей системе.
\n

lvmcache<\/h3>
\nlvmcache обеспечивает прозрачное кэширование данных медленных устройств HDD на быстрых устройствах SSD. LVM cache размещает наиболее часто используемые блоки на быстром устройстве. Включение и выключение кэширования можно производить, не прерывая работы.
\n<\/p>\n

При попытке чтения данных выясняется, имеются ли эти данные в кэше. Если требуемых данных там нет, то чтение происходит с HDD, и попутно данные записываются в кэш (cache miss). Дальнейшее чтение данных будет происходить из кэша (cache hit).
\n

Запись<\/h4>
\n— Режим write-through — когда происходит операция записи, данные записываются и в кэш, и на HDD диск, более безопасный вариант, вероятность потери данных при аварии мала;
\n— Режим write-back — когда происходит операция записи, данные записываются сначала в кэш, после чего сбрасываются на диск, имеется вероятность потери данных при аварии. (Более быстрый вариант, т. к. сигнал о завершении операции записи передается управляющей ОС после получения данных кэшем).<\/p>\n

Так выглядит сброс данных из кэша (write-back) на диски:<\/p>\n

<\/a>
\n

Настройка системы<\/h3>
\nНа хосте создается SSD датастор. Я выбрал такую схему использования доступного пространства:<\/p>\n
220Gb — DATASTORE_SSD\r\n149Gb — Отведено для особых ВМ\r\n61Gb — Том для кэша и метаданных\r\n10Gb — Host Swap Cache<\/code><\/pre>
Виртуальная сеть выглядит следующим образом:<\/p>\n
<\/p>\n
Создан новый vSwitch:<\/p>\n
Networking → Virtual Switches → Add standart virtual switch — указываем желаемое имя виртуального свитча (svm_vSwitch, в названиях я использую префикс svm_), остальное оставляем как есть.<\/code><\/pre>
К нему через порт группу подключается VMkernel NIC:<\/p>\n
Networking → VMkernel NICs → Add VMkernel NIC\r\n— Port group — New Port group\r\n— New port group — Имя порт группы — svm_PG\r\n— Virtual switch — svm_vSwitch\r\n— IPv4 settings — Configuration — Static — указываем IP и маску сети<\/code><\/pre>
Создана порт группа, к которой будет подключена ВМ svm:<\/p>\n
Networking → Port Groups → Add port group — указываем имя (svm_Network) и свитч svm_vSwitch<\/code><\/pre>
Подготовка дисков<\/h4>
\nНеобходимо зайти на хост по ssh и выполнить следующие команды:<\/p>\n
Отобразить пути всех подключенных дисков:\r\n\t# ls -lh \/vmfs\/devices\/disks\/\r\nlrwxrwxrwx    1 root     root          72 Feb 22 20:24 vml.01000000002020202020202020202020203956504257434845535433373530 -> t10.ATA_____ST3750525AS_________________________________________9*E\r\nlrwxrwxrwx    1 root     root          72 Feb 22 20:24 vml.01000000002020202020202020202020203956504257434b46535433373530 -> t10.ATA_____ST3750525AS_________________________________________9*F\r\n\r\nПерейти в директорию, где будут размещаться «mapping file»:\r\n\t# cd \/vmfs\/volumes\/DATASTORE_SSD\/\r\n\r\nСоздаем RDM в режиме виртуальной совместимости:\r\n\t# vmkfstools -r \/vmfs\/devices\/disks\/vml.01000000002020202020202020202020203956504257434845535433373530 9*E.vmdk\r\n\t# vmkfstools -r \/vmfs\/devices\/disks\/vml.01000000002020202020202020202020203956504257434b46535433373530 9*F.vmdk\r\n<\/pre>\n
 
\n
Подготовка ВМ<\/h4>
\nТеперь эти диски можно подключить (Existing hard disk) к новой ВМ. Шаблон CentOS 7, 1vCPU, 1024Gb RAM, 2 RDM disk, 61Gb ssd disk, 2 vNIC (порт группы VM Network, svm_Network) — во время установки ОС используем Device Type — LVM, RAID Level — RAID1<\/p>\n
Настройка NFS сервера довольно проста:<\/p>\n
# yum install nfs-utils\r\n# systemctl enable rpcbind\r\n# systemctl enable nfs-server\r\n# systemctl start rpcbind\r\n# systemctl start nfs-server\r\n# vi \/etc\/exports\r\n\t\/data 10.0.0.1(rw,sync,no_root_squash,no_subtree_check)\r\n# exportfs -ar\r\n# firewall-cmd add-service=nfs <\/s>permanent\r\n# firewall-cmd add-service=rpc-bind <\/s>permanent\r\n# firewall-cmd add-service=mountd <\/s>permanent\r\n# firewall-cmd —reload<\/pre>\n
 <\/p>\n
Подготавливаем тома кэша и метаданных для включения кэширования тома cl_svm\/data:<\/p>\n
Инициализация диска и расширение группы томов:\r\n\t# pvcreate \/dev\/sdc\r\n\t# vgextend cl_svm \/dev\/sdc\r\nСоздание тома с метаданными, в «man» написано, что этот том должен быть в 1000 раз меньше тома с кэшем:\r\n\t# lvcreate -L 60M -n meta cl_svm \/dev\/sdc\r\nСоздание тома с кэшем:\r\n\t# lvcreate -L 58,9G -n cache cl_svm \/dev\/sdc\r\nСоздание кэш-пула из томов:\r\n\t# lvconvert type cache-pool <\/s>cachemode writethrough —poolmetadata cl_svm\/meta cl_svm\/cache\r\nСвязываем подготовленный кэш-пул с томом данных:\r\n\t# lvconvert type cache <\/s>cachepool cl_svm\/cache cl_svm\/data \r\nСтатистику можно посмотреть в выводе:\r\n\t# lvs -o cache_read_hits,cache_read_misses,cache_write_hits,cache_write_misses\r\nCacheReadHits    CacheReadMisses  CacheWriteHits   CacheWriteMisses\r\n            421076           282076           800554          1043571<\/pre>\n
 <\/p>\n
Уведомления о изменении состояния массива:<\/p>\n
В конце файла \/etc\/mdadm.conf нужно добавить параметры, содержащие адрес, на который будут отправляться сообщения в случае проблем с массивом, и, если необходимо, указать адрес отправителя:<\/p>\n
MAILADDR alert@domain.ru\r\nMAILFROM svm@domain.ru<\/code><\/pre>
Чтобы изменения вступили в силу, нужно перезапустить службу mdmonitor:<\/p>\n
#systemctl restart mdmonitor<\/pre>\n
 <\/p>\n
Почта с ВМ отправляется средствами ssmtp. Так как я использую RDM в режиме виртуальной совместимости, то проверять состояние дисков будет сам хост.<\/p>\n
Подготовка хоста<\/b><\/p>\n
Добавляем NFS датастор в ESXi:<\/p>\n
Storage → Datastores → New Datastore → Mount NFS Datastore\r\nName: DATASTORE_NFS\r\nNFS server: 10.0.0.2\r\nNFS share: \/data<\/code><\/pre>
Настройка автозапуска ВМ:<\/p>\n
Host → Manage → System → Autostart → Edit Settings\r\nEnabled — Yes\r\nStart delay — 180sec\r\nStop delay — 120sec\r\nStop action — Shut down\r\nWait for heartbeat — No<\/code><\/pre>
Virtual Machines → svm → Autostart → Increase Priority
\n(Автозапуск не сработал, пришлось удалить ВМ из Inventory и добавить заново)<\/p>\n
Данная политика позволит ВМ svm запуститься первой, гипервизор примонтирует NFS датастор, после этого будут включаться остальные машины. Выключение происходит в обратном порядке. Время задержки запуска ВМ подобрано по итогам краш-теста, т. к. при малом значении Start delay NFS датастор не успевал примонтироваться, и хост пытался запустить ВМ, которые еще недоступны. Также можно поиграться параметром<\/p>\n
NFS.HeartbeatFrequency<\/code><\/pre>
.<\/p>\n
Более гибко автостарт ВМ можно настроить с помощью командной строки:<\/p>\n
Посмотреть параметры автозапуска для ВМ:\r\n\t# vim-cmd hostsvc\/autostartmanager\/get_autostartseq\r\nИзменить значения автостарта для ВМ (синтаксис):\r\n\t# update_autostartentry VMId StartAction StartDelay StartOrder StopAction StopDelay WaitForHeartbeat\r\nПример:\r\n\t# vim-cmd hostsvc\/autostartmanager\/update_autostartentry 3 «powerOn» «120» «1» «guestShutdown» «60» «systemDefault»<\/pre>\n
 <\/p>\n
Небольшая оптимизация<\/b><\/p>\n
Включить Jumbo Frames на хосте:<\/p>\n
Jumbo Frames: Networking → Virtual Switches → svm_vSwitch указать MTU 9000;\r\nNetworking → Vmkernel NICs → vmk1 указать MTU 9000<\/code><\/pre>
В Advanced Settings установить следующие значения:<\/p>\n
NFS.HeartbeatFrequency = 12\r\nNFS.HeartbeatTimeout = 5\r\nNFS.HeartbeatMaxFailures = 10\r\nNet.TcpipHeapSize = 32 (было 0)\r\nNet.TcpipHeapMax = 512\r\nNFS.MaxVolumes = 256\r\nNFS.MaxQueueDepth = 64 (было 4294967295)<\/code><\/pre>
Включить Jumbo Frames на ВМ svm:<\/p>\n
# ifconfig ens224 mtu 9000 up\r\n# echo MTU=9000 >> \/etc\/sysconfig\/network-scripts\/ifcfg-ens224<\/pre>\n
 <\/p>\n
 
\n
Производительность<\/h3>
\nПроизводительность измерялась синтетическим тестом (для сравнения, я снял показания с кластера на работе (в ночное время)).<\/p>\n
Используемое ПО на тестовой ВМ:<\/p>\n
— ОС CentOS 7.3.1611 (8 vCPU, 12Gb vRAM, 100Gb vHDD)
\n— fio v2.2.8<\/p>\n
Последовательность команд запуска теста:\r\n\t# dd if=\/dev\/zero of=\/dev\/sdb bs=2M oflag=direct\r\n\t# fio -readonly -name=rr -rw=randread -bs=4k -runtime=300 -iodepth=1 -filename=\/dev\/sdb -ioengine=libaio -direct=1\r\n\t# fio -readonly -name=rr -rw=randread -bs=4k -runtime=300 -iodepth=24 -filename=\/dev\/sdb -ioengine=libaio -direct=1\r\n\t# fio  -name=rw -rw=randwrite -bs=4k -runtime=300 -iodepth=1 -filename=\/dev\/sdb -ioengine=libaio -direct=1\r\n\t# fio -name=rw -rw=randwrite -bs=4k -runtime=300 -iodepth=24 -filename=\/dev\/sdb -ioengine=libaio -direct=1<\/pre>\n
 <\/p>\n
Полученные результаты представлены в таблицах (* во время тестов отмечал среднюю загрузку ЦП на ВМ svm):<\/p>\n
VMFS6 Datastore<\/p>\n<\/caption>
Тип диска<\/p>\n<\/th>
FIO depth 1 (iops)<\/p>\n<\/th>
FIO depth 24 (iops)<\/p>\n<\/th><\/tr>
randread<\/p>\n<\/td>
randwrite<\/p>\n<\/td>
randread<\/p>\n<\/td>
randwrite<\/p>\n<\/td><\/tr>
HDD<\/p>\n<\/td>
77<\/p>\n<\/td>
99<\/p>\n<\/td>
169<\/p>\n<\/td>
100<\/p>\n<\/td><\/tr>
SSD<\/p>\n<\/td>
5639<\/p>\n<\/td>
17039<\/p>\n<\/td>
40868<\/p>\n<\/td>
53670<\/p>\n<\/td><\/tr><\/tbody><\/table>
 <\/p>\n
NFS Datastore<\/p>\n<\/caption>
SSD Cache<\/p>\n<\/th>
FIO depth 1 (iops)<\/p>\n<\/th>
FIO depth 24 (iops)<\/p>\n<\/th>
CPU\/Ready* %<\/p>\n<\/th><\/tr>
randread<\/p>\n<\/td>
randwrite<\/p>\n<\/td>
randread<\/p>\n<\/td>
randwrite<\/p>\n<\/td><\/tr>
Off<\/p>\n<\/td>
103<\/p>\n<\/td>
97<\/p>\n<\/td>
279<\/p>\n<\/td>
102<\/p>\n<\/td>
2.7\/0.15<\/p>\n<\/td><\/tr>
On<\/p>\n<\/td>
1390<\/p>\n<\/td>
722<\/p>\n<\/td>
6474<\/p>\n<\/td>
576<\/p>\n<\/td>
15\/0.1<\/p>\n<\/td><\/tr><\/tbody><\/table>
 <\/p>\n
Рабочий кластер<\/p>\n<\/caption>
Тип диска<\/p>\n<\/th>
FIO depth 1 (iops)<\/p>\n<\/th>
FIO depth 24 (iops)<\/p>\n<\/th><\/tr>
randread<\/p>\n<\/td>
randwrite<\/p>\n<\/td>
randread<\/p>\n<\/td>
randwrite<\/p>\n<\/td><\/tr>
900Gb 10k (6D+2P)<\/p>\n<\/td>
122<\/p>\n<\/td>
1085<\/p>\n<\/td>
2114<\/p>\n<\/td>
1107<\/p>\n<\/td><\/tr>
4Tb 7.2k (8D+2P)<\/p>\n<\/td>
68<\/p>\n<\/td>
489<\/p>\n<\/td>
1643<\/p>\n<\/td>
480<\/p>\n<\/td><\/tr><\/tbody><\/table>
Результаты, которые можно потрогать руками, получились при одновременном запуске пяти ВМ с Windows 7 и офисным пакетом (MS Office 2013 Pro + Visio + Project) в автозагрузке. По мере нагревания кэша, ВМ грузились быстрее, при этом HDD практически не участвовал в загрузке. При каждом запуске отмечал время полной загрузки одной из пяти ВМ и полной загрузки всех ВМ.<\/p>\n
Одновременный запуск пяти ВМ<\/p>\n<\/caption>
№<\/p>\n<\/th>
Datastore<\/p>\n<\/th>
Первый запуск<\/p>\n<\/th>
Второй запуск<\/p>\n<\/th>
Третий запуск<\/p>\n<\/th><\/tr>
Время загрузки первой ВМ<\/p>\n<\/td>
Время загрузки всех ВМ<\/p>\n<\/td>
Время загрузки первой ВМ<\/p>\n<\/td>
Время загрузки всех ВМ<\/p>\n<\/td>
Время загрузки первой ВМ<\/p>\n<\/td>
Время загрузки всех ВМ<\/p>\n<\/td><\/tr>
1<\/p>\n<\/td>
HDD VMFS6<\/p>\n<\/td>
4мин. 8сек.<\/p>\n<\/td>
6мин. 28сек.<\/p>\n<\/td>
3мин. 56сек.<\/p>\n<\/td>
6мин. 23сек.<\/p>\n<\/td>
3мин. 40сек.<\/p>\n<\/td>
5мин. 50сек.<\/p>\n<\/td><\/tr>
2<\/p>\n<\/td>
NFS (SSD Cache Off)<\/p>\n<\/td>
2мин. 20сек.<\/p>\n<\/td>
3мин. 2сек.<\/p>\n<\/td>
2мин. 34сек.<\/p>\n<\/td>
3мин. 2сек.<\/p>\n<\/td>
2мин. 34сек.<\/p>\n<\/td>
2мин. 57сек.<\/p>\n<\/td><\/tr>
3<\/p>\n<\/td>
NFS (SSD Cache On)<\/p>\n<\/td>
2мин. 33сек.<\/p>\n<\/td>
2мин. 50сек.<\/p>\n<\/td>
1мин. 23сек.<\/p>\n<\/td>
1мин. 51сек.<\/p>\n<\/td>
1мин. 0сек.<\/p>\n<\/td>
1мин. 13сек.<\/p>\n<\/td><\/tr><\/tbody><\/table>
Время загрузки одиночной ВМ составило:<\/p>\n
— HDD VMFS6 - 50 секунд\r\n— NFS с выключенным кэшем - 35 секунд\r\n— NFS с включенным и нагретым кэшем - 26 секунд<\/code><\/pre>
В виде графика:<\/p>\n

\n
Краш-тест<\/h3>
\n 
\n
Отключение питания<\/h4>
\nПосле включения и загрузки хоста ВМ svm загрузилась с проверкой ФС (данные остались в кэше), на хосте примонтировался NFS датастор, далее загрузились остальные ВМ, проблем и потери данных не наблюдалось.
\n
Выход из строя HDD (имитация)<\/h4>
\nРешил отключить питание SATA диска. К сожалению, горячая замена не поддерживается, необходимо аварийно выключать хост. Сразу после отключения диска появляется информация в Events.<\/p>\n
<\/a><\/p>\n
Неприятным моментом оказалось, что при потере диска гипервизор просит для ВМ svm ответить на вопрос — «You may be able to hot remove this virtual device from the virtual machine and continue after clicking Retry. Click Cancel to terminate this session» — машина находится в состоянии фриза.<\/p>\n
Если представить, что с диском была временная, незначительная проблема (например, причина в шлейфе), то после устранения проблемы и включения хоста все загружается в штатном режиме.
\n
Выход из строя SSD<\/h4>
\nНаиболее неприятная ситуация — выход ssd из строя. Доступ к данным осуществляется в аварийном режиме. При замене ssd необходимо повторить процедуру настройки системы.
\n
Обслуживание (Замена диска)<\/h3>
\nЕсли с диском вот-вот случится беда (по результатам S.M.A.R.T.), для того чтобы заменить его на рабочий необходимо выполнить следующую процедуру (на ВМ svm):<\/p>\n
Посмотреть общее состояние массива: \r\n\t# cat \/proc\/mdstat \r\nили для каждого устройства: \r\n\t# mdadm —detail \/dev\/md126 \/dev\/md126\r\nПометить разделы неисправными:\r\n\t# mdadm manage \/dev\/md127 <\/s>fail \/dev\/sda1 \r\n\t# mdadm manage \/dev\/md126 <\/s>fail \/dev\/sda2\r\nУдалить сбойные разделы из массива:\r\n\t# mdadm manage \/dev\/md127 <\/s>remove \/dev\/sda1\r\n\t# mdadm manage \/dev\/md126 <\/s>remove \/dev\/sda2<\/pre>\n
 <\/p>\n
В настройках ВМ нужно «оторвать» погибающий vHDD, затем заменить HDD на новый.
\nПосле чего подготовить RDM накопитель и добавить к ВМ svm:<\/p>\n
Перечитать список устройств, где X — номер SCSI шины Virtual Device Node в настройках vHDD:\r\n\t# echo «- — -» > \/sys\/class\/scsi_host\/hostX\/scan\r\nС помощью sfdisk скопировать структуру разделов:\r\n\t# sfdisk -d \/dev\/sdb | sfdisk \/dev\/sdc\r\nДобавить получившиеся разделы в массив, установить загрузчик и дождаться окончания синхронизации:\r\n\t# mdadm manage \/dev\/md127 <\/s>add \/dev\/sdc1\r\n\t# mdadm manage \/dev\/md126 <\/s>add \/dev\/sdc2\r\n\t# grub2-install \/dev\/sdc<\/pre>\n
 <\/p>\n
 
\n
Аварийный доступ к данным<\/h3>
\nОдин из дисков подключается к рабочей станции, далее необходимо «собрать» RAID, отключить кэш и получить доступ к данным, примонтировав LVM том:<\/p>\n
# mdadm assemble <\/s>scan\r\n# lvremove cl_svm\/cache \r\n# lvchanange -ay \/dev\/cl_svm\/data\r\n# mount \/dev\/cl_svm\/data \/mnt\/data<\/pre>\n
 <\/p>\n
Также я пробовал загрузить систему непосредственно с диска, настроил сеть и на другом хосте подключил NFS датастор — ВМ доступны.
\n
Резюме<\/h3>
\nВ итоге, я использую lvmcache в режиме write-through и раздел для кэша размером 60Gb. Немного пожертвовав ресурсами CPU и RAM хоста — вместо 210Gb очень быстрого и 1.3Tb медленного дискового пространства я получил 680Gb быстрого и 158Gb очень быстрого, при этом появилась отказоустойчивость (но при неожиданном выходе из строя диска придется поучаствовать в процессе доступа к данным).<\/p>\n",
            "date_published": "2021-04-13T10:00:03+00:00",
            "date_modified": "2021-04-13T09:59:54+00:00",
            "_date_published_rfc2822": "Tue, 13 Apr 2021 10:00:03 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "31",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "22",
            "url": "https:\/\/sorex.org\/?go=all\/nfs-server-dlya-esxi\/",
            "title": "NFS сервер для ESXi",
            "content_html": "
apt-get install nfs-kernel-server<\/code>\n<\/pre>\n
Создаем папку, которую будем расшаривать<\/p>\n
mkdir ~\/share<\/code>\n<\/pre>\n
Далее, открываем на редактирование файл \/etc\/exports<\/strong><\/p>\n
sudo<\/span> nano \/etc\/exports<\/code>\n<\/pre>\n
Вставляем туда следующую строчку<\/p>\n
\/home\/goodigy\/share 192.168<\/span>.1<\/span>.0<\/span>\/24<\/span>(rw,async<\/span>,insecure,nohide,all_squash,anonuid=1000<\/span>,anongid=1000<\/span>)<\/code>\n<\/pre>\n
Параметры:<\/p>\n