![](\"https:\/\/sorex.org\/wp-content\/uploads\/2017\/03\/43dcd8404153459b88245157adecff23.png\")
\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![](\"https:\/\/sorex.org\/wp-content\/uploads\/2017\/03\/a33b409992774c1394ada486e786ad8c.png\")
<\/p>\n
При попытке чтения данных выясняется, имеются ли эти данные в кэше. Если требуемых данных там нет, то чтение происходит с HDD, и попутно данные записываются в кэш (cache miss). Дальнейшее чтение данных будет происходить из кэша (cache hit).
\n
Запись<\/h4>
\n— Режим write-through — когда происходит операция записи, данные записываются и в кэш, и на HDD диск, более безопасный вариант, вероятность потери данных при аварии мала;
\n— Режим write-back — когда происходит операция записи, данные записываются сначала в кэш, после чего сбрасываются на диск, имеется вероятность потери данных при аварии. (Более быстрый вариант, т. к. сигнал о завершении операции записи передается управляющей ОС после получения данных кэшем).<\/p>\n
Так выглядит сброс данных из кэша (write-back) на диски:<\/p>\n
Виртуальная сеть выглядит следующим образом:<\/p>\n Создан новый vSwitch:<\/p>\n К нему через порт группу подключается VMkernel NIC:<\/p>\n Создана порт группа, к которой будет подключена ВМ svm:<\/p>\n Настройка NFS сервера довольно проста:<\/p>\n <\/p>\n Подготавливаем тома кэша и метаданных для включения кэширования тома cl_svm\/data:<\/p>\n <\/p>\n Уведомления о изменении состояния массива:<\/p>\n В конце файла \/etc\/mdadm.conf нужно добавить параметры, содержащие адрес, на который будут отправляться сообщения в случае проблем с массивом, и, если необходимо, указать адрес отправителя:<\/p>\n Чтобы изменения вступили в силу, нужно перезапустить службу mdmonitor:<\/p>\n <\/p>\n Почта с ВМ отправляется средствами ssmtp. Так как я использую RDM в режиме виртуальной совместимости, то проверять состояние дисков будет сам хост.<\/p>\n Подготовка хоста<\/b><\/p>\n Добавляем NFS датастор в ESXi:<\/p>\n Настройка автозапуска ВМ:<\/p>\n Virtual Machines → svm → Autostart → Increase Priority Данная политика позволит ВМ svm запуститься первой, гипервизор примонтирует NFS датастор, после этого будут включаться остальные машины. Выключение происходит в обратном порядке. Время задержки запуска ВМ подобрано по итогам краш-теста, т. к. при малом значении Start delay NFS датастор не успевал примонтироваться, и хост пытался запустить ВМ, которые еще недоступны. Также можно поиграться параметром<\/p>\n .<\/p>\n Более гибко автостарт ВМ можно настроить с помощью командной строки:<\/p>\n <\/p>\n Небольшая оптимизация<\/b><\/p>\n Включить Jumbo Frames на хосте:<\/p>\n В Advanced Settings установить следующие значения:<\/p>\n Включить Jumbo Frames на ВМ svm:<\/p>\n <\/p>\n Используемое ПО на тестовой ВМ:<\/p>\n — ОС CentOS 7.3.1611 (8 vCPU, 12Gb vRAM, 100Gb vHDD) <\/p>\n Полученные результаты представлены в таблицах (* во время тестов отмечал среднюю загрузку ЦП на ВМ svm):<\/p>\n![](\"https:\/\/sorex.org\/wp-content\/uploads\/2017\/03\/8afaf19610324d5782d6793a6dad233e.png\")
<\/a>
\nНастройка системы<\/h3>
\nНа хосте создается SSD датастор. Я выбрал такую схему использования доступного пространства:<\/p>\n220Gb — DATASTORE_SSD\r\n149Gb — Отведено для особых ВМ\r\n61Gb — Том для кэша и метаданных\r\n10Gb — Host Swap Cache<\/code><\/pre><\/p>\nNetworking → Virtual Switches → Add standart virtual switch — указываем желаемое имя виртуального свитча (svm_vSwitch, в названиях я использую префикс svm_), остальное оставляем как есть.<\/code><\/pre>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>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# 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Инициализация диска и расширение группы томов:\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>\nMAILADDR alert@domain.ru\r\nMAILFROM svm@domain.ru<\/code><\/pre>#systemctl restart mdmonitor<\/pre>\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>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>
\n(Автозапуск не сработал, пришлось удалить ВМ из Inventory и добавить заново)<\/p>\nNFS.HeartbeatFrequency<\/code><\/pre>Посмотреть параметры автозапуска для ВМ:\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
Jumbo Frames: Networking → Virtual Switches → svm_vSwitch указать MTU 9000;\r\nNetworking → Vmkernel NICs → vmk1 указать MTU 9000<\/code><\/pre>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># ifconfig ens224 mtu 9000 up\r\n# echo MTU=9000 >> \/etc\/sysconfig\/network-scripts\/ifcfg-ens224<\/pre>\n
\nПроизводительность<\/h3>
\nПроизводительность измерялась синтетическим тестом (для сравнения, я снял показания с кластера на работе (в ночное время)).<\/p>\n
\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