VMware – Page 34

vSphere 5.x vs IBM SVC(Storwize) vs Multipathing

Продолжаем тему тонкой настройки политики выбора путей. Сегодня разбираем систему хранения IBM SAN Volume Controller и ближайших родственников IBM Storwize v7000/3700/3500.

Что имеем:

сеть хранения FC-SAN;
несколько IBM BladeCenter HS22V;
систему хранения IBM SVC с прошивкой 6.3.x;
систему хранения IBM Storwize V7000 с прошивкой 6.4.x;
vSphere 5.1b.

Для данного семейства используется Storage Array Type Plug-in (SATP) со следующей политикой по умолчанию VMW_PSP_FIXED. Данная политика подтверждена VMware на HCL, но имеет пометку “посмотрите рекомендации производителя”. Соответственно, смотрим какую политику рекомендует IBM в документе “VMware vSphere best practices for IBM SAN Volume Controller and IBM Storwize V7000 disk family“.

Как и ожидалось, для Аctive-Аctive систем хранения рекомендуется Round Robin.

Теперь необходимо выполнить два действия:

заменить на всех хостах политику по умолчанию;
для используемых устройств изменить политику выбора путей.

Для упрощения используем PowerShell. Готовые шаблоны есть на сайте сообществ VMware либо смотрите пошаговые инструкции.

#### Variables
$VC = "vcenter"

$psp = "VMW_PSP_RR"
$satp = "VMW_SATP_SVC"

 #### Connect to Your vCenter
Connect-viserver -Server $VC

 #### Change existing luns to Round Robin
Write-Host "Setting the existing luns to Round Robin" -ForegroundColor Cyan
#$vchosts = Get-Cluster $cluster | Get-VMHost
$vchosts = Get-VMHost
foreach ($vmhost in $vchosts)
 {
Get-VMHost $vmhost | Get-ScsiLun -CanonicalName "naa.6005*" | Where {$_.MultipathPolicy -ne "RoundRobin"} | Set-ScsiLun -MultipathPolicy “roundrobin”
}

#### Change the default PSP for my SATP
Write-Host "Setting the default PSP to Round Robin" -ForegroundColor Cyan
foreach ($vmhost in $vchosts)
 {
$esxCli = Get-EsxCli -VMHost $vmhost
$esxCli.storage.nmp.satp.set($false,$psp,$satp) 
 }

#### Disconnect from Your vCenter
Disconnect-VIServer $VC -Confirm:$false

#### Variables

$VC = "vcenter"

$psp = "VMW_PSP_RR"

$satp = "VMW_SATP_SVC"

#### Connect to Your vCenter

Connect-viserver -Server $VC

#### Change existing luns to Round Robin

Write-Host "Setting the existing luns to Round Robin" -ForegroundColor Cyan

#$vchosts = Get-Cluster $cluster | Get-VMHost

$vchosts = Get-VMHost

foreach ($vmhost in $vchosts)

{

Get-VMHost $vmhost | Get-ScsiLun -CanonicalName "naa.6005*" | Where {$_.MultipathPolicy -ne "RoundRobin"} | Set-ScsiLun -MultipathPolicy “roundrobin”

}

#### Change the default PSP for my SATP

Write-Host "Setting the default PSP to Round Robin" -ForegroundColor Cyan

foreach ($vmhost in $vchosts)

{

$esxCli = Get-EsxCli -VMHost $vmhost

$esxCli.storage.nmp.satp.set($false,$psp,$satp)

}

#### Disconnect from Your vCenter

Disconnect-VIServer $VC -Confirm:$false

VMware vSphere 5.1 vs EMC VNX vs Multipathing vs MSCS(WSFC)

Изрядно нахлебавшись, решил раскрыть тему, ранее отданную читателям блога на самостоятельное изучение, – какие нюансы могут всплыть при настройке виртуальной среды VMware vSphere при использовании кластеризации в Windows Server 2008(R2). Также советую прочитать обзор Андрея “Поддержка кластеризации в виртуальных средах“.

Тема очень обширна, поэтому рассмотрю проблемы и их решения в моей инфраструктуре.

Что имеем:

сеть хранения FC-SAN;
несколько IBM BladeCenter HS22V;
кластер MSCS(WSFC) with Shared Disk;
систему хранения EMC VNX 5700 с прошивкой 05.31.000.5.726;
vSphere 5.1b.

Проблема первая. Суровая.

Симптомы: после настройки MSCS время загрузки хостов увеличилось примерно на 25 минут; стали проявляться проблемы с запуском/рестартом агентов управления на хостах; возникли длительные задержки при вызове свойств дисковых устройств, подключенных в MCSC-кластер на пассивных нодах.

Причины: выяснение причин оказалось делом несложным, в базе знаний VMware есть статья описывающая данное поведение “ESXi/ESX hosts with visibility to RDM LUNs being used by MSCS nodes with RDMs may take a long time to boot or during LUN rescan“. При включении серверов, несущих пасивные ноды, происходит опрос дисков, в это время диски, подключенные к активным нодам, зарезервированы нодами по SCSI.

Решение: достаточно уведомить все хосты о том, что часть дисков находится в SCSI-reservation, для этого необходимо выставить у данных дисков параметр perennially-reserved равный true.

Так как “лень – матушка, да PowerShell – батюшка”, то накидал примитивный скрипт:

Connect-VIServer -Server vcenter
Get-VMHost | foreach 
{
$myesxcli=get-esxcli -VMHost $_
$myesxcli.storage.core.device.setconfig($false,"naa.идентификатор устройства", $true)
}
Disconnect-VIServer -Server * -Force

Connect-VIServer -Server vcenter

Get-VMHost | foreach

{

$myesxcli=get-esxcli -VMHost $_

$myesxcli.storage.core.device.setconfig($false,"naa.идентификатор устройства", $true)

}

Disconnect-VIServer -Server * -Force

Проверить статус можно следующей командой:

$myesxcli.storage.core.device.list("naa.идентификатор устройства")

1	$myesxcli.storage.core.device.list("naa.идентификатор устройства")

Идентификатор устройства получаем кликом правой кнопки мыши по нужному MSCS-диску в хост-Сonfiguration-Storage-Devices и выбором пункта “Copy identifier to clipboard”.

Проблема вторая. Весёлая.

Откуда ноги растут: при выходе vSphere 5.1 EMC и VMware стали поддерживать режима выбора пути RoundRobin для систем VNX. Как это круто читаем статью “FIXED/Round Robin in 5.1 and A Simple PowerCLI Block Pathing Module“. На грабли я встать не успел, но суть в следующем: при обновлении до версии 5.1 политика выбора пути по умолчанию для VNX поменяется с VMW_PSP_FIXED на VMW_PSP_RR. В итоге для MSCS-дисков вы получите неподдерживаемую конфигурацию, так как смена пути приводит к ошибке в работе механизма SCSI reservation. Соль ситуации – всё это получается автоматом.

Решение: установить на MSCS-дисках режим выбора пути в Fixed. Засада возникает при желании сделать это вручную – симптомы описаны в первой проблеме.

Предлагаю очередной примитивный скриптик:

Connect-VIServer -Server vcenter
Get-VMHost | foreach 
{
 $myesxcli=get-esxcli -VMHost $_
 $myesxcli.storage.nmp.device.set($null,"naa.идентификатор устройства","VMW_PSP_FIXED")
 } 
 Disconnect-VIServer -Server * -Force

Connect-VIServer -Server vcenter

Get-VMHost | foreach

{

$myesxcli=get-esxcli -VMHost $_

$myesxcli.storage.nmp.device.set($null,"naa.идентификатор устройства","VMW_PSP_FIXED")

}

Disconnect-VIServer -Server * -Force

Проверить статус можно следующей командой:

 $myesxcli.storage.nmp.device.list("naa.идентификатор устройства")

1	$myesxcli.storage.nmp.device.list("naa.идентификатор устройства")

Напоминалка.

При любых внедрениях Windows Server 2008(R2) MSCS(WSFC) обязательно перечитайте документацию по последней версии vSphere, так как выход каждой новой версии вносит новые требования к дополнительной тонкой настройке:

Последовательность обновления продуктов VMware 5.1

Мы уже делились опытом обновления VMware vCenter до 5.1

VMware выпускает статью, в которой приводит рекомендуемый порядок обновления своих продуктов.

vCloud Director;
vShield Manager;
vCenter Server;
vSphere Replication/vCenter SRM;
vSphere Data Protection;
vSphere Storage Appliance;
ESXi;
vShield Edge;
vShield App;
vShield Endpoint.

Успехов вам с этим нелегким делом.

Обновление VMware Tools в FreeBSD 6.2

Сегодня при обновлении VMware Tools на одной из виртуальных машин, столкнулись со следующей ошибкой:

“Tools is not supported on FreeBSD < 6.3. Detected FreeBSD version 6.2. Execution aborted.”

Continue reading “Обновление VMware Tools в FreeBSD 6.2”

Резерв ресурсов по процентам (admission control) не снижает вероятность перезапуска ВМ

Данная статья является переводом статьи Duncan Epping об использовании резерва ресурсов по процентам. Этот тип резервирования (или Admission control) является любимым у Duncan’а, и я попытаюсь объяснить почему.

Вы все видели настройку HA-кластера, в которой настраивается тип резервирования ресурсов. Лично я предпочитаю резервирование ресурсов по процентам, хотя есть мнение, что это снижает вероятность перезапуска “больших” ВМ. Эти люди считают, что резервирование по слотам (host failures) дает большую вероятность перезапуска “больших” ВМ. ~~Они все неправы 🙂~~ Давайте я приведу пример, который покажет ошибочность этого мнения.

Continue reading “Резерв ресурсов по процентам (admission control) не снижает вероятность перезапуска ВМ”

Ох, уж эти календари

Сегодня вторник, а пост у меня пятничный – про календари и время.

Майя переключились на новый календарь, а все подумали, что Конец Света.

Google забыл месяц “Декабрь” при выходе Android 4.2.

VMware vCenter 5.1 работает со статистикой глубиной только в 1 месяц.

Сегодня нашел косяк в VMware vCenter 5.0, при выводе статистики за год по два раза повторяются последние месяцы:

Veeam Backup creating snapshot Error: The method is disabled by ‘MVDI’

При бэкапе виртуальной инфраструктуры с помощью Veeam Backup and Replication 6.5 одна из виртуальных машин перестала бэкапиться с ошибкой “Creating snapshot Error: The method is disabled by ‘MVDI'”.

Гугление результатов не дало, пошел разбираться…

Continue reading “Veeam Backup creating snapshot Error: The method is disabled by ‘MVDI’”

Восстановление стандартного коммутатора из консоли ESX 4.1

Преамбула: первоначально статья рассматривалась, как памятка по настройке стандартного коммутатора для ESX из консоли, но позже было решено написать более подробную статью.

Достаточно подробное сравнение ESX (“толстый” гипервизор) и ESXi (“тонкий” гипервизор”) версии 4.1 сделано VMware. Стоит также отметить, что в vSphere 5/5.1 остался только ESXi. В рамках этой статьи я затрону два различия:

1) Для управления ESX извне используется подключение к виртуальному интерфейсу Service Console или vswif#. Для настроек из консоли сервера используется команда esxcfg-vswif. Для управления ESXi используется виртуальный интерфейс VMKernel или vmk#. Для настроек из командной строки – esxcfg-vmknic.

2) Для управления из консоли сервера ESXi можно использовать черно-желтый интерфейс DCUI, либо командную строку. Для ESX доступна только командная строка. При использовании распределенного коммутатора совместно с ESXi в DCUI есть пункт меню по восстановлению стандартного коммутатора на сервере ESXi.

После миграции виртуальных сетей на распределенный коммутатор, у вас есть два варианта: мигрировать туда же сети управления, или оставить их на стандартном коммутаторе. Если “лишних” сетевых адаптеров нет, то и выбора, в общем-то, тоже 🙂

Соответственно, иногда могут случаться различные проблемы с доступом к серверу через сеть. Просто поменять адрес или добавить новый виртуальный интерфейс уже не получится, так как вам нужно его добавлять на распределенный коммутатор, а вы не можете туда подключиться. Приходится как раз восстанавливать стандартный коммутатор, что делается элементарно через DCUI у ESXi. А вот как это делать на ESX я сейчас покажу.
Continue reading “Восстановление стандартного коммутатора из консоли ESX 4.1”

Обзор HP Virtualization Performance Viewer

Краткий обзор продукта уже делал портал VMGU.RU.

Я же хочу подробнее остановиться на интерфейсе.

Continue reading “Обзор HP Virtualization Performance Viewer”

Все, что вы хотели узнать о vSphere 5.1 :)

Как вы уже знаете, VMware выпустил обновленную версию своего гипервизора. Мы уже писали об обновлении vCenter до этой версии.

Оказывается, VMware подготовила бесплатный курс на русском языке, в котором за час расскажет о новых возможностях vSphere 5.1. Рекомендуется к ознакомлению.