Подключение луна без перезагрузки сервера

Иногда при подключении луна с хранилища, к которому никогда хост не подключался, лун не виден. Рескан не помогает, выручает перезагрузка хоста для того, чтобы он заново обратился в SAN-фабрику. Но есть способ более гуманный:

echo "scsi-qlalip" > /proc/scsi/qla2300/"number" 

esxcfg-rescan vmhba"number"

"number" необходимо заменить на номер vmhba-адаптера.

Ссылка по теме

Masking a LUN from ESX(i) 4.x

Перепостчу интересную статью:

Начиная с версии ESX(i) 4.0, изменилась процедура маскирования LUN'ов на уровне гипрвизора. Вместо прописывания адресов LUN в Advance Settings -> Disk -> Disk.MaskLUNs, в vSphere для все путей переопределятся плагин PSA на специальный - MASK_PATH.

Для начала удаляем из инвентори все объекты, связанные со скрываемым LUN'ом. Далее:

1. esxcfg-scsidevs -l Первой строчкой описания каждого устройства идёт LUN_ID, запоминаем его для скрываемого LUN'а

2. esxcfg-mpath -L | grep Находим все пути для этого раздела. Запоминаем адрес ввиде: vmhba#:C#:T#:L#, в моём случае vmhba2:C0:T2:L0. При желание, это можно сразу посмотреть в vSphere Client.

3. esxcli corestorage claimrule add --rule 123 -t location -A vmhba2 -C 0 -T 2 -L 0 -P MASK_PATHДобавляем правило в конфигурационных файл. Выбираем любой незанятый номер правила, но обязательно из диапазона 101--200.

4. esxcli corestorage claimrule load Загружаем созданное правило в список активных

5. esxcli corestorage claimrule list Проверяем, что в списке есть два одинаковых правила с выбранным номером с параметрами file и runtime.

6. esxcli corestorage claiming reclaim -d Переопределяем текущие правила для путей раздела на только что созданные.

Всё. Считаем до 10 и LUN больше недоступен для добавления datastor'а. Все пути, помеченные MASK_PATH, переходят в состояние Dead.

По статье kb.

Для чего это нужно? Например, для процедуры корректного удаления LUN'а "на лету":

Удаляем всё с LUN'а-> маскируем его-> отменяем презентацию LUN'а хосту средствами стораджа-> удаляем правила маскирования.

Источник

Рекомендации по производительности дисков

Интересное kb по дисковой производительности. В общем то ничего нового нет, но достаточно полезно.

Основные моменты:

Низкая производительность VM может быть связана с недостатком IOPS (на каждую виртуальную машину менее 30) Для расчета оптимального количества VM на массив необходимо поделить общее количество IOPS массива на количество виртуальных машин. Например у нас есть массив из 6 10к HDD 150*6=900. Если на этом массиве запущено 50 VM, то имеем следующее: 900/50=18. Следовательно, 18 IOPS нам явно не хватает, потому и наблюдаем низкую производительность. Для решения проблемы необходимо сократить количество виртуальных машин до 30 штук - 900/30=30.

Disk Spindle Speed (RPM)	Number of IOPS available
7200 RPM	100
10,000 RPM	150
15,000 RPM	230

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

Раз уж речь зашла о производительности - не забываем о ссылке

http://www.vm4.ru/p/performance.html

HP Insight Control Storage Module for vCenter

Модуль мониторинга СХД от HP. С его помощью можно отслеживать состояние HP StorageWorks EVA, P4000, XP, P9500 and P2000.

Модуль бесплатен и состоит из двух частей - Server Module for vCenter (для мониторинга серверов HP через vCenter) и Storage Module for vCenter.

Link