5.1 – Page 5 – vMind.ru

Обновление хостов с vSphere 4.1 до vSphere 5.1 и миграция с распределенного коммутатора на стандартный

Дошли у меня руки до обновления версии своих хостов до 5.1. Лицензии на vSphere 5 куплены в редакции Enterprise, поэтому пришлось заодно отказываться и от распределенного коммутатора.

Итак, поехали.

Continue reading “Обновление хостов с vSphere 4.1 до vSphere 5.1 и миграция с распределенного коммутатора на стандартный”

Миф о неограниченном размещении ВМ на VMFS-хранилище с VAAI

Оригинал этой статьи написан Jason’ом Boche.

Два года назад, в октябре 2010 года, увидел свет vSphere 4.1, и мы радовались потрясающим нововведениям и повышению масштабируемости инфраструктуры. Два года спустя у нас есть vSphere 5.0 и vSphere 5.1, а также куча других продуктов, сформировавших vCloud Suite.

Я намеренно начал рассказ с vSphere 4.1. В vSphere 4.1 Enterprise Edition появилась такая функция как vSphere API for Array Integration (VAAI). Кстати, это произносится как ‘vee double-ehh eye’. 🙂

Эти API предлагают три различных механизма (примитива) для блочных СХД, позволяющих отдавать отдельные операции на выполнение СХД. Один из этих механизмов мы с вами сегодня и рассмотрим.

Одним из старейших споров является “сколько ВМ VMware можно разместить на одном хранилище VMFS”? Проверенный временем ответ – 10/15/20. Наиболее аккуратный – “столько, сколько вам подходит”, обычно переводящийся в “это зависит от…”

С появлением VAAI я отметил пугающий тренд, что механизм Atomic Test and Set (ATS) или Hardware Assisted Locking раз и навсегда дал ответ на этот вопрос. Якобы вы можете запускать любое количество виртуальных машин на одном LUN’е, так как SCSI-блокировок больше нет.

С появлением vSphere 5.0 VAAI стал поддерживаться большим количеством СХД, и были добавлены новые механизмы как в СХД с блочным типом доступа, так и в NFS-СХД. Также VMware добавила поддержку VMFS-хранилищ размером до 64Тб без использования экстентов. Эта поддержка прекрасно объединяется с мифом о волшебстве ATS. Соответственно, мы не должны были иметь проблем с размещением сотен (если не тысяч) ВМ на одном большом блочном (VMFS) хранилище, как если бы это был NFS, и мы были свободны от ограничений SCSI.

ATS был разработан для устранения задержек LUN, связанных со SCSI-блокировками. Эти блокировки устанавливались при выполнении таких операций как создание/удаление файлов и т.п. Мы сталкиваемся с этими операциями при включении ВМ, создании снимков или разворачивании ВМ из шаблона. Эти операции имеют общую черту – им требуется изменить метаданные VMFS-раздела, для чего требуется его блокировка (SCSI-блокировка) хостом, выполняющим эту операцию. Эта блокировка, хоть она и достаточно короткая по времени, приводит к заметным задержкам операций ввода/вывода, если на одном VMFS-хранилище находится много ВМ, и к нему подключено много хостов. ATS передает механизм блокировки на откуп СХД, которая блокирует только изменяемые данные вместо блокировки целого LUN. Любое окружение, которое ранее оперировало этими задачами, получит от VAAI выигрыш за счет снижения задержек. Continue reading “Миф о неограниченном размещении ВМ на VMFS-хранилище с VAAI”

vSphere 5.1 vs Round Robin vs I/O operation limit

Очередной этап тонкой настройки политик выбора пути в vSphere 5.1.

Виталий Волнянский около полутора лет назал писал обзор “Настройка значения IOOperationLimit для RoundRobin на нескольких виртуальных хранилищ одновременно“, но есть небольшие изменения в vSphere 5.1, да и скрипты на PowerShell попривлекательней.

Одним из самых эффективных методов увеличения скорости доступ к системам хранения, поддерживающих для Native Multipathing (NMP) Path Selection Plug-ins (PSP) режим работы Round Robin, и снижения задержек является уменьшение значения по умолчанию параметра I/O operation limit с 1000 операций ввода-вывода до 1-10. Данный параметр регулирует “такт” перехода к следующему активному пути(для ALUA по умолчанию с учетом оптимального пути, регулируется параметром useano), то есть через сколько операций переключиться на следующий путь.

Что даёт и для каких систем рекомендуется/протестировано:

Как включить?

Это самое простое, но грабля есть.

Подаем команду на нужных дисках и готово:

esxcli storage nmp psp roundrobin deviceconfig set -t iops -I 1 -d naa.xxxxxxxxx

1	esxcli storage nmp psp roundrobin deviceconfig set -t iops -I 1 -d naa.xxxxxxxxx

Грабля в vSphere 5.1.

В vSphere 5.1 у команды добавился параметр cfgfile, что повлияло на реализацию функции в PowerShell, сейчас синтаксис такой(2 часа выяснял причину сбоя в работе старых скриптов):

boolean set(long bytes, boolean cfgfile, string device, long iops, string type, boolean useano),

как получить описание функций:

$esxcli=Get-EsxCli 
$esxcli.storage.nmp.psp.roundrobin.deviceconfig|Get-Member|fl

1 2	$esxcli=Get-EsxCli $esxcli.storage.nmp.psp.roundrobin.deviceconfig\|Get-Member\|fl

пример на PowerShell:

$esxcli.storage.nmp.psp.roundrobin.deviceconfig.set($null,$null,'naa.xxx',1,'iops',$false)

1	$esxcli.storage.nmp.psp.roundrobin.deviceconfig.set($null,$null,'naa.xxx',1,'iops',$false)

P.S. Если для вашей системы нет рекомендаций от производителя по уменьшению значения параметра, то вся ответственность за последствия изменений лежит на вас.

P.P.S. Продолжаем изучать PowerShell

Скрипт опроса LUN, подключенных с IBM SVC. Для установки параметра код поправите сами. 😉

#### Variables
$VC = "vcenter"
$psp = "VMW_PSP_RR"
$satp = "VMW_SATP_SVC"

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

#### Get IBM SVC Round Robin's LUNs status
$vchosts = Get-VMHost
foreach ($vmhost in $vchosts)
 {

 $myesxcli=get-esxcli -VMHost $vmhost
 write-host $vmhost.name
 Get-VMHost $vmhost | Get-ScsiLun -CanonicalName "naa.6005*" | Where {$_.MultipathPolicy -eq "RoundRobin"} | %{$myesxcli.storage.nmp.psp.roundrobin.deviceconfig.get($_.CanonicalName)}
}

#### 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

#### Get IBM SVC Round Robin's LUNs status

$vchosts = Get-VMHost

foreach ($vmhost in $vchosts)

{

$myesxcli=get-esxcli -VMHost $vmhost

write-host $vmhost.name

Get-VMHost $vmhost | Get-ScsiLun -CanonicalName "naa.6005*" | Where {$_.MultipathPolicy -eq "RoundRobin"} | %{$myesxcli.storage.nmp.psp.roundrobin.deviceconfig.get($_.CanonicalName)}

}

#### Disconnect from Your vCenter

Disconnect-VIServer $VC -Confirm:$false

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) не снижает вероятность перезапуска ВМ”

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

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

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

HP EVA и VAAI

Нашел плагин от HP, позволяющий использовать VAAI для СХД HP EVA *400/P6000 с версией XCS v1010 0000.

Плагин позволяет разгрузить массив при выполнении стандартных примитивов: Full copy, Block zeroing и Hardware assisted locking. В пятой версии поддерживается ряд примитивов, касающихся Thin Provisioning, но, к сожалению, UNMAP не поддерживается!

Плагин устанавливается только на хосты vSphere 4.1. В пятой версии плагина не требуется. Поддерживается установка как через vCLI, так и через VUM.

UPD: Кстати говоря, EVA второго поколения (4000/6000/8000/4100/6100/8100) не поддерживается с vSphere 5.0. Так что обновляйтесь на свой страх и риск.

P.S. К стыду своему замечу, что плагин стал доступен еще в марте 2012 года. Позор на мои седины 🙂

OFF: Следует отметить, что другая технология – VASA, поддерживает и более старое поколение HP EVA, например, *000/*100.