Рекомендации по настройке ESXi

В главе представлены настройки, рекомендованные при работе с инициатором 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.

Если VM на 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 есть строки вида
```
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).
Чтобы включить адаптивную глубину очереди, выполните
```
# esxcfg-advcfg -s 32 /Disk/QFullSampleSize
# esxcfg-advcfg -s 16 /Disk/QFullThreshold
```
На 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).