Рекомендации для ESXi

В главе представлены рекомендации по настройкам ESXi, влияющим на производительность и отказоустойчивость гипервизора. Рекомендации отсортированы по следующим тематическим секциям:

Повреждение данных VMware ESX Datastore (VMFS);
Транспорт FC QLogic;
Общие рекомендации.

Повреждение данных VMware ESX Datastore (VMFS)

В секции представлены известные сценарии, при которых возможно повреждение данных VMFS, и рекомендации по их избежанию. При подозрении на повреждение обратитесь в службу поддержки VMware.

Сценарии и рекомендации:

При одновременном использовании LUN несколькими хостами ESXi:
1. Во время продолжительных операций на RAID со стороны СХД, влияющих на уменьшение производительности (например, реконструкция RAID, переключение узлов, исправление SDC, высокая нагрузка на RAID), рекомендуем не мигрировать ресурсы между хостами, не создавать снэпшоты и бэкапы, а также отключить ATS HB.
  
  Если хост ESXi не может обновить метаданные на томе дольше 15 секунд, то из-за специфики ATS HB остальные хосты будут считать, что блокировка тома тем хостом неактуальна.
2. При высокой нагрузке на СХД ошибки CAW (Compare And Write) со статусом MISCPOMPARE на ESXi-хосте могут указывать на то, что хосты не могут согласованно использовать пространство одного тома.
  
  Пример ошибки:
```
Cmd 0x89 to dev "eui.xxxx" failed H 0x0 D 0x2 P 0x0 Valid sense data: 0xe 0x1d 0x0
```
3. Некорректная работа DSswitch (vSphere Distributed Switch) может привести к ошибкам соединения между хостами и vCenter (получение хостом некорректного статуса «Not Responding») и повлечь миграцию ресурсов в кластере ESXi.
  
  Пример ошибки:
```
Hostd[2100937]: [Originator@6876 sub=Statssvc.Vapi.HTTPService.HttpConnection] HTTP Connection read failed while waiting for further requests; <io_obj p:0x000000a458ac4888, h:-1, <TCP '127.0.0.1 : 9131'>, <TCP '127.0.0.1 : 56712'>>, N7Vmacore16TimeoutExceptionE(Operation timed out: Stream: <io_obj p:0x000000a458ac4888, h:-1, <TCP '127.0.0.1 : 9131'>, <TCP '127.0.0.1 : 56712'>>, duration: 00:00:49.404834 (hh:mm:ss.us))
```
4. Ошибки в работе адаптеров инициаторов (например, «false hang»), могут сильно снижать производительность и провоцировать некорректное срабатывание передачи ресурсов между хостами в кластере ESXi.
  
  Пример ошибки:
```
igbn: igbn_CheckRxHang:1414: vmnic1: false hang detected on RX queue 0
```
Лучшая практика перед установкой или обновлением ESXi – отключение от хоста общего хранилища.

Транспорт FC QLogic

В секции представлены настройки, рекомендованные при работе с инициатором ESXi, которые могут быть использованы для решения и минимизации проблем, возникающих при использовании FC Qlogic в качестве транспорта данных между ESXi и СХД под управлением RAIDIX.

: Рекомендации подобраны под систему, в которой в качестве транспорта инициатора используется QLogic FC, а для синхронизации – Mellanox IB SRP.

: Для корректной работы ESXi с Generic RAID отключите VAAI.

При работе ESXi с DC-системой не перезагружайте одновременно оба узла СХД.

Из-за механизма Permanent Device Loss (PDL) на ESXi, устройства, что находятся удалённо, и не отвечают более 10 минут, не будут восстановлены, когда таргет будет снова их отдавать.

Чтобы на ESXi восстановить доступ к таким устройствам, вы можете использовать один из способов:

Перерегистрируйте ВМ или перемонтируйте datastore, использующие такие устройства.
Перезагрузите ESXi-хост.

В случаях потери физических путей от инициатора при использовании Fibre Channel в качестве транспорта во время длительных переездов используйте bus_reset вместо lun_reset (используемый по умолчанию) и target_reset.
```
# esxcfg-advcfg -s 0 /Disk/UseLunReset
# esxcfg-advcfg -s 0 /Disk/UseDeviceReset
```
При использовании конфигурации с 64 LUN рекомендуется установить значение port_down_retry 160 и выше.
```
# esxcli system module parameters set -p qlport_down_retry=160 -m qlnativefc
```
При использовании RDM-дисков рекомендуется запретить использование INQUIRY из кэша ESXi во избежание проблем с нестабильностью из-за неактуальных данных INQUIRY из кэша ESXi (подробнее см. на сайте VMware).
```
# esxcli storage core device inquirycache set --device device id --ignore true
```
При длительных переездах рекомендуется установить порог для LSOM, при котором transient error в 64 команды (либо 0) будет расцениваться как постоянное состояние.
```
# esxcfg-advcfg -s 64 /LSOM/lsomDeviceNeedsRepairCount
```
Для сохранения активности путей при возникновении transient error рекомендуется запретить переключение на пути с меньшим количеством ошибок.
```
# esxcfg-advcfg -s 0 /NmpManageDegradedPaths
# esxcfg-advcfg -s 0 /HppManageDegradedPaths
```
При достижении порога transient error в 20% рекомендуется убрать переключение статуса пути в degraded.
```
# esxcfg-advcfg -s 0 /Misc/NmpDegradedPathThresholdPer
# esxcfg-advcfg -s 0 /Misc/HppDegradedPathThresholdPer
```
Для получения ESXi актуального статуса путей рекомендуется установить повторный опрос о выходе из transient error в 3 секунды (по умолчанию: 20 секунд).
```
# esxcfg-advcfg -s 3 /Nmp/NmpSatpAluaCmdRetryTime
```
Для сохранения производительности при повышенной нагрузке рекомендуется включить алгоритм адаптивной длины очереди при возникновении Queue full detected и Task set full.
```
# esxcfg-advcfg -s 32 /Disk/QFullSampleSize
# esxcfg-advcfg -s 16 /Disk/QFullThreshold
```
При повторяющихся потерях доступа к устройствам без восстановления рекомендуется сократить reset period (по умолчанию: 30 секунд).
```
# esxcfg-advcfg -s 10 /Disk/ResetPeriod
```
При сохранении проблемы вы можете вручную отключить обработку All-Paths-Down (APD) (подробнее см. на сайте VMware).
```
# esxcfg-advcfg -s 0 /Misc/APDHandlingEnable
```
При кратковременном падении производительности всех путей после отключения одного пути рекомендуется включить Action_OnRetryErrors (подробнее см. на сайте VMware) и применить reset_on_attempted_reserve (подробнее см. на сайте VMware) для инициации failover. Для применения изменений потребуется перезагрузка ESXi-хоста:
```
# esxcli storage nmp satp rule add -V <vendor_name> -P VMW_PSP_RR -s VMW_SATP_ALUA -o "enable_action_OnRetryErrors reset_on_attempted_reserve"
# esxcli storage core claimrule load
# reboot
```
- где <vendor_name> – имя вендора СХД (имя можно увидеть, выполнив на СХД команду $ rdcli -V, в конце строки вывода).
При сохранении проблемы рекомендуется удалить и добавить правило повторно без применения reset_on_attempted_reserve:
```
# esxcli storage nmp satp rule remove -V <vendor_name> -P VMW_PSP_RR -s VMW_SATP_ALUA -o "enable_action_OnRetryErrors reset_on_attempted_reserve"
# esxcli storage nmp satp rule add -V <vendor_name> -P VMW_PSP_RR -s VMW_SATP_ALUA -o enable_action_OnRetryErrors
```
- где <vendor_name> – имя вендора СХД (имя можно увидеть, выполнив на СХД команду $ rdcli -V, в конце строки вывода).
Заданные настройки будут применяться по умолчанию для всех существующих и новых устройств.
Во избежание падения производительности рекомендуем задать значение 100 или 200 для iops или 1024 или 2048 для bytes в настройках NativeMultipathPlugin (подробнее см. на сайте VMware) для смены пути.

Задать значение iops:
```
# esxcli storage nmp psp roundrobin deviceconfig set --type=iops --iops=<100or200> --device=eui.<LUN_number>
```
- где <100or200> – значение IOPS, <LUN_number> – номер устройства.
Задать значение bytes:
```
# esxcli storage nmp psp roundrobin deviceconfig set --type=bytes --bytes=<1024or2048> --device=eui.<LUN_number>
```
- где <1024or2048> – значение bytes, <LUN_number> – номер устройства.
Если в системе присутствует большое количество LUN и отсутствуют LUN других СХД, использующих атрибут eui, вы можете задать значения с помощью скрипта.

Скрипт для iops:
```
# for i in `esxcfg-scsidevs -c |awk '{print $1}' | grep eui.`; do esxcli storage nmp psp roundrobin deviceconfig set --type=iops --iops=<100or200> --device=$i; done
```
- где <100or200> – значение IOPS.
Скрипт для bytes:
```
# for i in `esxcfg-scsidevs -c |awk '{print $1}' | grep eui.`; do esxcli storage nmp psp roundrobin deviceconfig set --type=bytes --bytes=<1024or2048> --device=$i; done
```
- где <1024or2048> – значение bytes.
Заданные настройки можно сохранить как значения по умолчанию для всех существующих и новых устройств. Для этого удалите созданное правило SATP (если было создано) и создайте новое правило с рекомендуемым значением для iops или для bytes:

Удаление правила SATP:
```
# esxcli storage nmp satp rule remove -V <vendor_name> -P VMW_PSP_RR -s VMW_SATP_ALUA -o "enable_action_OnRetryErrors reset_on_attempted_reserve"
```
- где <vendor_name> – имя вендора СХД (имя можно увидеть, выполнив на СХД команду $ rdcli -V, в конце строки вывода).
Новое правило со значением iops:
```
# esxcli storage nmp satp rule add -V <vendor_name> -P VMW_PSP_RR -s VMW_SATP_ALUA -o "enable_action_OnRetryErrors reset_on_attempted_reserve" -c tpgs_on -O iops=<100or200>
```
- где <vendor_name> – имя вендора СХД (имя можно увидеть, выполнив на СХД команду $ rdcli -V, в конце строки вывода); <100or200> – значение IOPS.
Новое правило со значением bytes:
```
# esxcli storage nmp satp rule add -V <vendor_name> -P VMW_PSP_RR -s VMW_SATP_ALUA -o "enable_action_OnRetryErrors reset_on_attempted_reserve" -c tpgs_on -O bytes=<1024or2048>
```
- где <vendor_name> – имя вендора СХД (имя можно увидеть, выполнив на СХД команду $ rdcli -V, в конце строки вывода); <1024or2048> – значение bytes.
Обнаружение LUN, отданных по FC QLogic.

Информация на сайте VMware: kb.vmware.com.

Если LUN не отображаются при сканировании устройств через ESXi GUI, попробуйте один из способов ниже:
- Проверьте правила маскирования в ПО RAIDIX.
- Просканируйте устройства через ESXi CLI:
```
# esxcli storage core adapter rescan --all
```
- Выполните принудительное перелогирование (FLOGI) на каждом порту используемых в ESXi адаптеров:
```
# esxcli storage san fc reset -A vmhba<X>
```
  Посмотреть список адаптеров можно с помощью команды
```
# esxcli storage core adapter device list
```
- Перезагрузите ESXi-хост.

Общие рекомендации

Обработка ситуаций с уменьшением производительности в DC.

Если ВМ на ESXi выполняет I/O медленно или с прерываниями, и при этом на DC-системе RAIDIX отсутствует синхронизация между узлами (например, после перезагрузки узла), выполните следующие действия:
1. Проверьте логи ESXi в /var/log/vmkernel.log на наличие сообщений
```
Device <eui.###> performance has deteriorated. I/O latency increased from average value of <val1> to <val2>
```
2. Если собщения присутствуют, отключите функцию «Cквозная запись без синхронизации» на СХД RAIDIX.
Обработка переполнения очереди на канале транспорта.

Включите адаптивную глубину очереди на ESXi, если в логах ESXi в /var/log/vmkernel.log есть строки
- для iSCSI:
```
ScsiDeviceIO: 4124: Cmd(0x45d90ed478c8) 0x28, CmdSN 0x800e000a from world 2120104 to dev "eui.3034343446303039" failed H:0x0 D:0x28 P:0x0
```
  - где после «failed» код ответа «D:0x28» означает, что операция отклонена, очередь операций к выполнению полностью переполнена (Device Status - "TASK_SET_FULL").
- для FC:
```
vmhba5(31:0.1): C0:T0:L1 - FCP command status: 0x15-0x828 (0x0) portid=0000e8 oxid=0x171 cdb=2a00f2 len=32768 rspInfo=0x0 resid=0x8000 fwResid=0x8000 host status = 0x0 device status = 0x28
```
  - где для «FCP command status:» значение «0x828» означает, что операция отклонена, очередь операций к выполнению полностью переполнена (Device Status - "QUEUE FULL").
Чтобы включить адаптивную глубину очереди, выполните
```
# esxcfg-advcfg -s 32 /Disk/QFullSampleSize
# esxcfg-advcfg -s 16 /Disk/QFullThreshold
```
ESXi после корректного удаления LUN и создания нового может продолжить определять новый LUN как удалённый, что влечёт за собой повреждение данных.

Проблема возникает из-за неправильной работы механизма PDL в некоторых версиях ESXi. Для избежания проблемы необходимо вручную выполнять рескан путей на адаптере при любом изменении LUN на системе (подробнее на сайте VMware).

Если проблема уже возникла:
- Отмонтируйте datastore и снимите с регистрации ВМ, которые использовали LUN.
- Выполните рескан адаптеров:
```
# esxcli storage core adapter rescan --all
```
Если проблема сохраняется после рескана, перезагрузите адаптер, на котором отображался удалённый LUN:
```
# esxcli storage san fc reset -A vmhbaX
```
При удалении RAID без нагрузки, LUN продолжают отображаться на ESXi.

Проблема возникает при использовании ESXi версии выше 7.0.3g, когда удалённые LUN были обнаружены ESXi или были добавлены в datastore или ВМ, где сохранилась информация о них (подробнее на сайте VMware).

При возникновении проблемы удалите информацию о LUN:
- Перемонтируйте datastore и снимите с регистрации ВМ, которые использовали LUN.
- Перезагрузите адаптер, на котором отображался удалённый LUN:
```
# esxcli storage san fc reset -A vmhbaX
```
- Выполните рескан адаптеров:
```
# esxcli storage core adapter rescan --all
```
- Проверьте, что пути удалённого LUN не отображаются:
```
# esxcfg-mpath -b
```
Для избежания проблемы используйте на инициаторе конфигурацию Active-Passive SATP вместо ALUA:
- Удалите правило ALUA:
```
# esxcli storage nmp satp rule remove -V <vendor_name> -P VMW_PSP_RR -s VMW_SATP_ALUA
```
- Добавьте правило Active-Passive SATP:
```
# esxcli storage nmp satp rule add -V <vendor_name> -P VMW_PSP_RR -s VMW_SATP_DEFAULT_AP -c tpgs_on
```
На ESXi версий 8.0, 8.0 U1, 8.0 U2 возникают проблемы с запуском ВМ на базе Linux версии 5.18 и выше.

Проблемы актуальны для ВМ с технологией Fault Tolerance и включённой поддержкой VMCI DMA datagrams.

Для избежания проблем отключите поддержку VMCI DMA datagrams на ВМ (подробнее см. на сайте Broadcom). Отключение поддержки доступно через:
- ESXi-хост;
- vCenter.
На ESXi-хосте:
1. В конфигурационном файле ВМ (*.vmx) добавьте строку:
```
vmci.dmaDatagramSupport = FALSE
```
2. Обновите конфигурационный файл.
В интерфейсе vCenter:
- В разделе Advanced Parameters ВМ добавьте параметр vmci.dmaDatagramSupport со значением FALSE и сохраните изменения.
Если после замены компонентов, смены имени таргета, обновления драйверов или замены кабелей ESXi перестал видеть часть Datastore, но LUN, на котором расположен Datastore, доступен, выполните следующие действия:
1. Проверьте логи ESXi /var/vmkernel.log на наличие сообщений типа:
```
vmkwarning: cpu20:2100869)WARNING: VMKAPICore: 1824: unable to validate header
LVM: 8445: Device eui.64784a3271307365:1 detected to be a snapshot:
LVM: 8452: queried disk ID: <type 1, len 12, lun 3, devType 0, scsi 0, h(id) 42832082591475764905>
```
2. Проверьте, видны ли сигнатуры несмонтированных LUN:
```
# esxcfg-volume -l
```
3. Смонтируйте LUN одним из способов:
  - Для временного монтирования, только в текущей сессии и до следующего перезапуска ESXi:
```
# esxcfg-volume -M <UUID/Name>
```
  - Для постоянного монтирования до следующего перезапуска (Non-persistent Mode):
```
# esxcli storage vmfs snapshot mount -n -l  <Datastore_name>
```
  - Для постоянного монтирования с сохранением после перезагрузки (Persistent Mode):
```
# esxcli storage vmfs snapshot mount -l  <Datastore_name>
```
    Сигнатура VMFS не изменяется.
  - Для монтирования с изменением сигнатуры VMFS (Resignature):
```
# esxcli storage vmfs snapshot resignature -l  <Datastore_name>
```
    Или используйте UUID:
```
# esxcli storage vmfs snapshot resignature -u  <Datastore_UUID>
```
    : VMware рекомендует менять сигнатуру LUN во избежание проблем в будущем. Однако смена сигнатуры может привести к ситуации, когда в системе один LUN ассоциируется с двумя сигнатурами. Данные при этом остаются целостными (подробнее см. на сайте Broadcom).