Баг с переименование NIC при клониковании или разворачивании из темплейта

При  клонировании или разворачивании из темплейта виртуальной машины с гостевой ОС Windows 2008 R2 и сетевой картой vmxnet3 изменяется имя сетевого соединения в ОС (например, было "Local Area Connection", стало "Local Area Connection 2"), в Device Manager также меняется имя устройства сетевой карты (VMXNET Device 2). Этот баг лечится установкой на исходную виртуальную машину хотфикса от Microsoft:

• 2344941 для гостевых ОС Windows 2008 R2, Windows 7 без SP1,
• 2550978  для гостевых ОС Windows 2008 R2, Windows 7 с SP1.

Процедура "лечения" исходной виртуальной машины:

1. Удалить из конфигурации виртуальной машины сетевую карту.
2. Включить виртуальную машину.
3. Установить хотфикс, перезагрузить виртуальную машину.
4. Выключить виртуальную машину.
5. Добавить в конфигурацию сетевую карту.

Источник KB1020078.

Как работает vMotion

Последовательность действий vMotion:

1. На целевом хосте создается теневая виртуальная машина.
2. Копируется каждая страница памяти из источника в целевую виртуальную машину через сеть vMotion. Эта операция называется preCopy.
3. Следующая итерация - это копирование страниц памяти, которые изменились во время выполнения  последней операции preCopy.
4. Итерации preCopy продолжаются до тех пор пока не будет измененных страниц памяти.
5. "Глушится" виртуальная машина на хосте-источнике и разблокируется на целевом хосте.

В большинстве случаев итерации копирования работают прекрасно, при условии если хост передает страницы памяти по сети vMotion быстрее, чем они успевают меняться виртуальной машиной.
Однако, иногда виртуальная машина изменяет страницы памяти быстрее, чем vMotion может передать их, и возможна ситуация, когда итерации preCopy не могут сойтись.
Если preCopy не сходится, vMotion должен решить потерпит миграция неудачу или будет завершена. Решение принимается на основе оценки времени необходимого для копирования оставшихся страниц памяти. По умолчанию, если это время не превышает 100 секунд, то миграция будет завершена. Если время превышает 100 секунд, vMotion завершится ошибкой без воздействия на виртуальную машину.
Если оценка укладывается в 100 секунд, vMotion "заглушит" источник и запустит целевую виртуальную машину. Когда виртуальная машина уже будет работать на целевом хосте, источник еще будет передавать оставшиеся страницы памяти, используя технологию "Quick Resume", которая появилась в vSphere 4.1.
В vSphere 5 подобная технология называется  "Stun During Page Send". Эта технология, "замедляя" vCPU на источнике, управляет скоростью изменения страниц памяти в зависимости от пропускной способности сети vMotion и позволяет завершить миграцию. Также Stun During Page Send делает возможным vMotion при задержках сети до 10 мс (Metro vMotion).
Подчеркнем несколько ключевых моментов:

• Для миграции любой нагрузки необходимо, чтобы пропускная способность сети vMotion была выше скорости изменения страниц памяти.
• vMotion перемещает виртуальную машину только если уверен, что сможет выполнить копирование памяти.
• Если vMotion не может выполнить копирование памяти, миграция закончится неудачей без воздействия на виртуальную машину.

Источники:
VMware Uptime Blog: vMotion - what's going on under the covers?
Yellow Bricks: vSphere 5.0 vMotion Enhancements
+Презентация VMware vMotion in VMware vSphere 5.0: Architecture, Performance and Best Practices

Растянутый HA\DRS кластер vSphere 5

Ранее тема растянутых кластеров vSphere затрагивалась в посте об обеспечении катастрофоустойчивости. С тех пор вышла vSphere 5 и появились новшества, связанные в том числе и с растянутыми кластерами:

• технология vSphere Metro Storage Cluster, которая призвана работать в растянутыми VMware HA кластерами;
• vMotion стал возможен на сетях с большими задержками (для Metro vMotion допустима задержка до 10мс);
• переработана технология VMware HA (нет зависимости от DNS,  нет принципа разделения  хостов на primary / secondary и связанных с ним ограничений, появился datastore heartbeating).

В настоящий момент единственным устройством, которое сертифицировано для  vSphere Metro Storage Cluster является VLEX.
EMC VPLEX - решение виртуализации сети хранения данных.

• VPLEX позволяет  объединить ресурсы различных дисковых массивов (необязательно производства EMC) в единый логический пул внутри одного сайта (VPLEX Local) и между сайтами (VPLEX Metro).
• VPLEX обеспечивает репликацию данных между сайтами синхронную (VPLEX Metro до 150 км) и асинхронную (VPLEX Geo ~ 1000 км).
• VPLEX Metro позволяет осуществлять чтение\запись локально на массивы обоих сайтов, тома которых входят в пул распределенного тома (технология AccessAnywhere).

Защита от split brane распределенного тома в VPLEX Metro осуществляется с помощью компонента VPLEX Cluster Witness и назначения для каждого распределенного виртуального тома prefered site и non-prefered site. При разрыве синхронизации между устройствами VPEX  возможность чтения\записи на распределенный том остается только на prefered site,  а non-prefered site останавливает операции ввода\вывода. Виртуальная машина Cluster Witness располагается на третьем независимом сайте, связывается с VPLEX по IP и координирует обработку сбоев.

Плюсы схемы с растянутым кластером vSphere и VPLEX Metro очевидны:

• Наиболее полное использование кластерных технологий vSphere: DRS, HA, vMotion, Storage DRS, т. е. возможна балансировка нагрузки между сайтами, более гибкая балансировка нагрузки на дисковые массивы, и, конечно же, катастрофоустойчивость.
• Защита от аварий дисковых массивов на сайте.
• Обеспечивается непрерывность доступности сервисов при необходимости обслуживания сайта либо его плановой недоступности (предупреждение отказов).

Моменты, на которые следует обратить внимание при проектировании растянутых HA\DRS кластеров:

• Наличие нескольких адресов изоляции (isolation addresses) поможет более четко определять изоляцию хостов. Это важно при работе на двух сайтах, когда есть вероятность разделения сети.
• На каждом сайте должен быть heartbeat datastore, расположенный на нераспределенном (локальном для сайта) томе.
• С помощью предпочтительных (Should) правил DRS VM-Host Affinity возможно\нужно распределять виртуальные машины по сайтам так, чтобы операции ввода\вывода на распределенный том выполнялись локально на сайте. Такая рекомендация есть в KB2007545, где говорится, что предпочтительно, чтобы виртуальные машины были запущены на стороне prefered site. Это поможет снизить влияние аварий, когда разделяются системы хранения или полностью разделяются сайты. Правда, такое правило ограничит автоматическую балансировку нагрузки между сайтами.
• Для сервисов, состоящих из нескольких виртуальных машин, группировать эти виртуальные машины на одном сайте правилами DRS VM-Host Affinity, т.е не разносить отдельный сервис по сайтам.
• Для vmkernel и виртуальных машин требуется растянутая сеть на уровне L2. Вещь довольно сложная и дорогая.
• В этой схеме есть только один vCenter, и доступность его при аварии сайта нужно как-то обеспечить (располагать на третьем сайте; использовать VMware Heartbeat, и если это виртуальная машина,  не располагать ее на распределенном томе).

Источники:
Yellow Bricks: vSphere 5.0 HA and metro / stretched cluster solutions
Deshifrator's blog: vSphere 5: High Availability - Промежуточные итоги
blog.scottlowe.org: Updated Stretched Cluster Presentation
Vierual Geek: VMworld 2011 content: BCO2479 - Understanding vSphere Stretched Clusters, Disaster Recovery, and Planned Workload Mobility

Оптимизация дисковой производительности с помощью EMC Fast Suite

Оптимизация производительности сервиса с использованием технологий EMC Fast VP (Virtual Pool) и Fast Cache на примере Microsoft SQL Server 2008 R2 (failover cluster и standalone), платформа VMware vSphere 5, дисковый массив EMC VNX5700 (видео от EMCProvenSolutions, короткая версия видео).
UPD. Новая ссылка.

Veeam: восстановление отдельных файлов гостевой ОС для виртуальной машины с vRDM

В официальной документации Veeam Backup&Replication 5 о восстановлении из бэкапа виртуальной машины, у которой есть диски RDM Virtual Compatibility Mode, ничего не говорится. Между тем есть некоторые нюансы.
Например, если пользоваться стандартным визардом для файлового восстановления для гостевых систем Windows, то содержание vRDM-раздела не отображается. Для восстановления отдельных файлов гостевой ОС для виртуальной машины с vRDM используем Multi-OS File Level Restore Wizard:

• Запускаем Multi-OS File Level Restore Wizard (Tools - File Level Restore - Other OS или Restore - Guest files (other OS).
• Выбираем виртуальную машину.
• Выбираем точку восстановления.
• До нажатия кнопки Finish жмем кнопку Customize и настраиваем временные расположение и сетевые настройки для FLR Appliance.
• Жмем кнопку Finish. Получаем вспомогательную виртуальную машину VeeamFLR_<name VM> и окно File Level Restore (подобие Windows-проводника), содержащее состояние файловой структуры виртуальной машины на требуемую точку восстановления.
• Восстанавливаем необходимые файлы. Закрываем окно File Level Restore. Вспомогательная виртуальная машина будет выключена и удалена автоматически.

Если восстанавливать vRDM-раздел не отдельными файлами, а полностью, то он восстанавливается как обычный виртуальный диск на Datastore, а не RDM. Чтобы получить RDM, конвертируем vmdk в RDM (для ESX\ESXi 3.x-4.x см. KB3443266).

Лимиты CPU для виртуальных машин

KB2009408 объясняет, что  и почему мы видим при выборе лимитов CPU в свойствах виртуальных машин.

Максимальные значения CPU лимитов виртуальных машин различны для Standalone хостов и DRS-кластеров.

Для Standalone хоста
maxCPUlimit =  numVMCPUs * GHzPerHostCore.
Пример: на хосте 8 ядер с чатотой 2GHz.

• виртуальная машина с 2 vCPU имеет максимальный лимит CPU 4GHz = 2 vCPU * 2GHz
• виртуальная машина может иметь до 8 vCPU, при этом ее максимальный лимит CPU 16GHz = 8 vCPU * 2GHz

DRS-кластер может состоять из хостов с разными CPU, виртуальные машины могут мигрировать между хостами с разной скоростью ядер CPU. Максимальное значение на движке лимита будет общая кластерная емкость. Это значение указывает, что виртуальная машина может работать на любом хосте в кластере, а ресурсы DRS-кластера абстрагированы от физических хостов в отличии от Standalone хоста.

Т.е. для DRS-кластера

maxCPUlimit =  Сумма (numVMCPUs * GHzPerHostCore) всех хостов.

Пример: в DRS-кластере, состоящем из хоста с 8 ядрами по 2GHz и хоста с 4 ядрами по 2,5GHz, виртуальная машина может иметь 12 vCPU и лимит CPU 26GHz = (8 vCPU * 2GHz) + (4 vCPU * 2.5GHz).

Значение, которое мы видим будет ниже из-за накладных расходов.

Обновление ESX(i) 4.1 до 4.1 Update2

В разделе Support&Download на www.vmware.com нет пакета обновления ESX(i) 4.1 до 4.1 Update2 для VMware vCenter Update Manager.
Пакет можно найти на странице Download Patches.

VMware vSphere 5: лицензирование, цены, пакеты

Обзор VMware vSphere 5: Licensing, Pricing and Packaging. White paper
Редакции Compare vSphere 5.0 Editions
Американские цены Compare VMware vSphere Pricing
Пакеты Compare vSphere 5.0 Kits

Failover Cluster: перенос кластерной группы на другой узел

Скрипт для миграции (переноса) кластерной группы на другой узел кластера:
cluster /cluster:<cluster name> group <group name> /move

или с указанием конкретного узла:
cluster /cluster:<cluster name> group <group name> /moveto:<node name>

Using EMC VSI 5 VMware vCenter Plug-In

Управление дисковым массивом EMC c использованием бесплатного плагина EMC VSI (Virtal Storage Integrator) 5 для VMware vCenter (видео от EMCProvenSolutions).

"Error: XML document empty" при настройке EMC MirrorView Adapter for VMware Site Recovery Manager

Настраиваем VMware Site Recovery Manager 4.1.1 с адаптером EMC MirrorView Adapter for VMware Site Recovery Manager 1.4.
При попытке соединения с дисковым массивом в Array Managers получаем ошибку Error: XML document empty.
KB1016149 подсказывает, что необходимо использовать 32-bit версию EMC Solution Enabler.

Установка драйвера для HBA-адаптера Brocade 825 на ESXi 5 и ESX(i) 4.1

К сожалению ни ESX(i) 4.1, ни ESXi 5.0 не распознают HBA-адаптер Brocade 825, адаптер не отображается в доступных устройствах Storage Adapters. Необходима установка драйвера.

Для ESXi 5.0:

1. Качаем драйвер с сайта VMware или с сайта Brocade, я скачал от Brocade пакет VMware ESXi 5.0 FC / FCoE Driver Offline Bundle, BCD-bfa-3.0.0.0-00000-offline_bundle-465342.zip.
2. Разархивируем. Копируем файл Brocade_bootbank_scsi-bfa_3.0.0.0-1OEM.500.0.0.406165.vib на datastore1 в папку vib через клиент vSphere.
3. В локальной консоли или через ssh (соответственно включаем ESXi Shell или SSH в Troubleshootng Mode Option в DCIU) выполняем команду: esxcli software vib install -v /vmfs/volumes/datastore1/vib/Brocade_bootbank_scsi-bfa_3.0.0.0-1OEM.500.0.0.406165.vib.
4. Перезагружаем хост.

Для ESX(i) 4.1:

1. Качаем драйвер с сайта VMware.
2. Из скаченного iso забираем файл BCD-bfa-2.3.0.0-00000-offline_bundle-310895.zip, копируем его на сервер vMA с помощью утилиты WinSCP в папку /tmp/distr/.
3. В vMA выполняем команду: vihostupdate -server <ESX name> --install --bundle /tmp/distr/BCD-bfa-2.3.0.0-00000-offline_bundle-310895.zip.
4. Перезагружаем хост.

Тестовая лаборатория VMware vSphere

Делаем тестовую лабораторию на железном ESX 4.
Создаем виртуальную машину для виртуального vESX с параметрами:

• Virtual Machine Version 7
• Guest OS: Linux / Red Hat Enterprise Linux 6 (64-bit)
• 2 VCPUs, 2GB RAM
• NIC - e1000
• LSI Logic Parallel

В Advanced Settings виртуальноq машины vESX добавляем параметр monitor_control.restrict_backdoor со значением true, чтобы на vESX можно было запускать виртуальные машины (виртуализация внутри).
Устанавливаем на виртуальной машине ESX(i)4/5.

PowerCLI: список виртуальных машин с RDM-дисками

Connect-VIServer <vCenter Name>
$report = @()
$vms = Get-VM | Get-View
foreach($vm in $vms){
  foreach($dev in $vm.Config.Hardware.Device){
    if(($dev.gettype()).Name -eq "VirtualDisk"){
 if(($dev.Backing.CompatibilityMode -eq "physicalMode") -or
    ($dev.Backing.CompatibilityMode -eq "virtualMode")){
   $row = "" | select VMName, HDDeviceName, HDFileName, HDMode
          $row.VMName = $vm.Name
   $row.HDDeviceName = $dev.Backing.DeviceName
   $row.HDFileName = $dev.Backing.FileName
   $row.HDMode = $dev.Backing.CompatibilityMode
   $report += $row
 }
}
  }
}
$report

vMotion architecture, Performance and best practices in VMware vSphere 5

Новый официальный документ whitepaper от VMware.
Vroom! blog  опубликовал новый официальный документ, содержащий рекомендации по vMotion и производительности в vSphere 5.
vMotion в vSphere 5 включает в себя ряд улучшений производительности, которые позволяют использовать vMotion с минимальными накладными расходами даже для самых тяжелых виртуальных машин и корпоративных приложений.
Новый документ vMotion architecture, Performance and best practices in VMware vSphere 5 описывает архитектуру vMotion и представляет функции и улучшения, которые появились в vMotion vSphere 5.
Среди улучшений возможность использовать несколько сетевых адаптеров для vMotion, эффективное использование полосы 10Gb, Metro vMotion, уменьшение влияния на производительность приложений.
После обзора и описания функций  vMotion в vSphere 5 предлагается комплексно взглянуть на выполнение миграции виртуальных машин с типичными приложениями Web Server, MS Exchange, MS SQL Server и VMware View.
Тесты измеряли такие характеристики, как время миграции и работы приложения во время vMotion.
Результаты испытаний показывают: 

• Уменьшение воздействия на производительность гостевых приложений при vMotion.
• Выигрыш в производительности до 30% во время vMotion.
• Серьезный прирост производительности по сравнению с vSphere 4.1 при использовании нескольких сетевых адаптеров в vSphere 5 (продолжительность миграции уменьшается более чем в три раза).

Наконец, даны несколько рекомендаций при работе с vMotion.

Автор, Sreekanth Setty, сотрудник команды VMware Performance Engineering. Его работа сфокусирована на производительности, с акцентом на построение сети и виртуализацию. Он публиковал свои выводы в ряде официальных документах и на различных конференциях.
Источник Vroom!.

PowerCLI: поиск виртуальной машины по MAC-адресу

Get-vm | Select Name, @{N="Network";E={$_ | Get-networkAdapter | ? {$_.macaddress -eq "<required MAC>"}}} |Where {$_.Network-ne ""}

На выходе получаем:

Name         Network
----           -------
VM2         Network adapter 1

PowerCLI: массовая смена портгрупп

Массовое переключение виртуальных машин с старой подгруппы на новую:

1) в отдельной папке

$vCenter = "<vCenter Name>"
$Folder = "<Folder Name>" 

$OldNetwork = "<Old Port Group Name>" 

$NewNetwork = "<New Port Group Name>"

connetct-viserver -server $vCenter

Get-Folder $Folder |Get-VM |Get-NetworkAdapter |Where {$_.NetworkName -eq $OldNetwork } |Set-NetworkAdapter -NetworkName $NewNetwork -Confirm:$false

2) в кластере

$vCenter = "<vCenter Name>"
$Cluster = "<Cluster Name>" 

$OldNetwork = "<Old Port Group Name>" 

$NewNetwork = "<New Port Group Name>"

connetct-viserver -server $vCenter

Get-Cluster $Cluster |Get-VM |Get-NetworkAdapter |Where {$_.NetworkName -eq $OldNetwork } |Set-NetworkAdapter -NetworkName $NewNetwork -Confirm:$false

Параметр -Confirm:$false позволяет выполнять изменения без подтверждений.

Первоисточник.

Не выключается виртуальная машина на ESXi-хосте

Если виртуальная машина не выключается с помощью VMware vSphere Client на ESXi 4.1 и ESXi 5, то зависший процесс можно убить с помощью esxtop.

1. Подключиться напрямую к консоле ESXi, жмем Alt+F1 (должен быть включен режим Local Tech Support), или подключиться к ESXi через ssh (должен быть включен режим Remote Tech Support).
2. Запустить esxtop.
3. Нажать с для переключения в экран CPU resource utilization. Если виртуальная машина не отображается в списке, пробуем переключится в экран Memory, жмем m.
4. Нажать f , добавить колонку world ID.
5. Нажать k, набрать соответствующий world ID, нажать Enter.

Источник.

Failover Cluster: настройка сердцебиения (Configure Heartbeat)

В Failover Cluster на Windows Server 2008 есть возможность настраивать "чувствительность" кластера к пропаданиям сети. Настраиваются частота сердцебиения (hearbeat) и число потерянных сердцебений (порог срабатывания failover):
Частота сердцебиений по умолчанию 1000 мс, изменяется:

• от 250 до 2000 мс для узлов кластера из одной подсети, параметр SameSubnetDelay;
• от 250 до 4000 мс для узлов кластера в разных подсетях, параметр CrossSubnetDelay.

Число потерянных сердцебиений по умолчанию 5, изменяется от 3 до 10 (параметры SameSubnetTreshold и CrossSubnetDelayTreshold).

Параметры задаются из командной строки (Run as administrator):

cluster /cluster:<ClusterName> /prop SameSubnetDelay=<value>
cluster /cluster:<ClusterName> /prop SameSubnetThreshold=<value>
cluster /cluster:<ClusterName> /prop CrossSubnetDelay=<value>
cluster /cluster:<ClusterName> /prop CrossSubnetThreshold=<value>

Проверяем то, что получилось
cluster /cluster:<ClusterName> /prop

Источники:

http://technet.microsoft.com/en-us/library/dd197562(WS.10).aspx

http://technet.microsoft.com/en-us/library/dd197575(WS.10).aspx

http://support.microsoft.com/kb/2494036

Ошибка при назначении разрешения на объект в Inventory vCenter

При назначении доменному пользователю разрешения на объект в Inventory получаю ошибку "Call "UserDirectory.RetrieveUserGroups" for object "UserDirectory" on vCenter Server "vCenter name" failed".
KB1027107 предлагает запускать службы VirtualCenter Server и VirtualCenter Management Webservices от доменной учетной записи. У меня службы запущены от локальной учетной записи.
Т. к. админы далеко (новую доменную учетку создать некому) пытаюсь запустить службы от Local System (сам сервер, расположен vCenter в домене). Проблема решена.

PowerCLI: создание стандартных свичей и портгрупп

1) на одном хосте

connect-viserver -server <vCenter> -user <user> -password <pwd>
 Get-VMHost <Host> | New-VirtualSwitch -name <New Switch> -nic <VMNIC> (например, vmnic1)
Get-VMHost <Host> | Get-VirtualSwitch -name <New Switch> | New-VirtualPortGroup -name <New PortGroup> -vlanid <VLAN ID>

2) на всех хостах

новый свич, в нем новая подгруппа
connect-viserver -server <vCenter> -user <user> -password <pwd>
 Foreach ($vmhost in (get-cluster -name <My Cluster> | get-vmhost))
 {
  $vmhost | New-VirtualSwitch -Name <New Switch> | New-VirtualPortGroup -Name <New PortGroup>  -vlanid <VLAN ID>
 }
новая портгруппа в существующем свиче
connect-viserver -server <vCenter> -user <user> -password <pwd>
 Foreach ($vmhost in (get-cluster -name <My Cluster> | get-vmhost))
 {
  $vmhost | Get-VirtualSwitch -Name <Existing vSwitch> | New-VirtualPortGroup -Name <New PortGroup>  -vlanid <VLAN ID>
 }

3) копирование свичей с одного хоста на другой хост (интерактивный)

$VISRV = Connect-VIServer (Read-Host "Имя vCenter")
$BASEHost = Get-VMHost -Name (Read-Host "Имя ESX(i)-образца (как оно отображено в vSphere Client)")
$NEWHost = Get-VMHost -Name (Read-Host "Имя настраиваемого ESX(i) (как оно отображено в vSphere Client)")
$BASEHost |Get-VirtualSwitch |Foreach {
$vSwitch = $_
If (($NEWHost |Get-VirtualSwitch -Name $_.Name-ErrorAction SilentlyContinue)-eq $null){
       Write-Host "Creating Virtual Switch $($_.Name)"
       $NewSwitch = $NEWHost |New-VirtualSwitch -Name $_.Name-NumPorts $_.NumPorts-Mtu $_.Mtu
       $vSwitch = $_
    }
   $_ |Get-VirtualPortGroup |Foreach {
       If (($NEWHost |Get-VirtualPortGroup -Name $_.Name-ErrorAction SilentlyContinue)-eq $null){
           Write-Host "Creating Portgroup $($_.Name)"
           $NewPortGroup = $NEWHost |Get-VirtualSwitch -Name $vSwitch |New-VirtualPortGroup -Name $_.Name-VLanId $_.VLanID
        }
    }
}


Скачать этот скрипт.
Плюс подобный скрип с более удобным интерфейсом.

Источники:
http://communities.vmware.com/docs/DOC-4210
http://searchvmware.techtarget.com/tip/Bulk-VMware-administration-Using-PowerCLI-with-standard-switches
http://www.virtu-al.net/

Расчет (сайзинг) VMFS LUN

Duncan Epping (Yellow Bricks) обновил рекомендации к определению конфигурации VMFS LUN.

Ранее он предлагал (оригинал тут) рассчитывать размер VMFS LUN, исходя из максимального количества виртуальных машин на LUN MaxVMs и среднего размера виртуальной машины  avgSize:

(MaxVMs * avgSize) + 20%,

20% - резерв на файл подкачки и снэпшоты.

Сейчас Duncan предлагает (пост VMFS-5 LUN Sizing) рассчитывать VMFS LUN, учитывая и требования по IOPS:

((IOpsPerLUN – 20%) / AVGIOpsPerVM) ≤ (MaxVMsWithinRTO),

где

IOpsPerLUN - IOPS, которые может обработать LUN в зависимости от физической конфигурации (тип RIAD, количество шпинделей, тип дисков);

AVGIOpsPerVM - среднее число IOPS на виртуальную машину;

MaxVMsWithinRTO - максимальное число виртуальных машин, которые будут одновременно восстанавливаться с заданным значением RTO;

20% - резерв на всплеск IOPS со стороны виртуальных машин (снэпшоты, файл подкачки).

По сути, первая половина формулы определяет максимальное количество виртуальных машин на раздел MaxVMs. 

Duncan оговаривается, что значение резерва 20% не является идеалом и зависит от "физики" VMFS LUN.

Размер VMFS LUN рекомендуется определять формулой:

(((MaxVMs * AvgDisksVMs) * AvgSizeVMDK) + (MaxVMs * AvgMemSize)) + SlackSpace ≥ MinSize,

где

AvgDisksVMs - среднее количество дисков у виртуальной машины;

AvgSizeVMDK - средний размер диска виртуальной машины;

AvgMemSize - средний размер памяти виртуальной машины;

SlackSpace - резерв (в данном случае под снэпшоты);

MinSize - минимальный размер VMFS-раздела 1,2G.

Тут ничего нового, только более детально расписан старый параметр  avgSize. Такие частности, как Reservation для памяти или хранение swap-файла на отдельном LUN, формула не учитывает.

Хотя в названии поста используется VMFS-5, логика верна и для VMFS-3.

Сетевые настройки Service Console ESX (утилита console-setup)

Для смены сетевых настроек Service Console ESX вместо шаманства с консольными командами (http://www.vladan.fr/how-to-change-ip-address-of-the-esx-server-console/, http://www.geekshangout.com/node/17, KB Article 4309499, KB Article1000258) можно воспользоваться утилитой командной строки console-setup (KB Article 1022078), которая доступна начиная с версии ESX 4.0 Update2.

Утилита позволяет просматривать, создать заново или изменить существующие настройки Service Console: ip-адрес, маску, шлюз по умолчанию, VLAN ID, vmnic.
Меню утилиты:

1. Show Current Service Consoles (vswif)
2. Show Network Adapters
3. Show vSwitch/vDS Information
4. Delete Service Console
5. Configure Service Console
6. Exit

Подменю "Configure Service Console" имеет пункты:

1. vswif ID
2. Name of service console port group: default to “Service Console”
3. vSwitch for service console, default to vSwitch0
4. IP Address
5. Subnet mask
6. Default gateway
7. VLAN ID
8. vmnic to use for the service console
9. Save Changes
10. Return to Menu

В свете скорого выхода vSphere 5 и отсутствия в ней ESX этот функционал начинает терять актуальность, но мне вчера пригодилось )).

Материалы по Veeam Backup&Replication

Видеоуроки от Владимира Ескина:
Создание и запуск задания
Создание и запуск задания SureBackup
Восстановление объекта

Восстановление объектов Exchange

Пост на VM Press.

WWN HBA-адаптера в ОС Windows

WWN HBA-адаптера в ОС Windows без установки утилит производителя позволяет узнать утилита от Microsoft  Fibre Channel Information Tool (fcinfo).
Источник vMind.ru.

upd.
Get-InitiatiorPort в PowerShell

Обеспечение катастрофоустойчивости для виртуальной инфраструктуры VMware vSphere 4

Так или иначе катастрофоустойчивые решения для среды VMware vSphere, завязаны на реплицируемые системы хранения данных. Не принимая во внимание кластреризацию отдельных виртуальных машин и отдельных сервисов, рассмотрим варианты обеспечения катастрофоустойчивости виртуальной инфраструктуры VMware в пределах двух площадок с использованием EMC VPLEX и VMware vCenter Site Recovery Manager.

EMC VPLEX

Немного рекламы

EMC VPLEX — это аппаратно-программная платформа, которая размещается в сети SAN между узлами и системой хранения и позволяет распространять данные на дальние расстояния. VPLEX – это решение для объединения ресурсов хранения данных от корпорации EMC и других производителей.

EMC VPLEX – первая в мире платформа, которая обеспечивает как локальное, так и распределенное объединение. Локальное объединение обеспечивает прозрачное взаимодействие физических элементов хранения данных в пределах одной площадки, а распределенное объединение распространяет данную концепцию на две площадки, которые находятся на определенном расстоянии. Распределенное объединение реализовано благодаря революционной технологии AccessAnywhere™ в составе решений VPLEX, которая обеспечивает совместное использование одной копии данных, доступ к ней и ее перемещение на определенное расстояние.

Наиболее интересны следующие возможности VPLEX:

·         перемещение виртуализированных приложений в пределах центров обработки данных;

·         балансировка и перемещение рабочих нагрузок между площадками;

·         объединение центров обработки данных и обеспечение непрерывной доступности.

VPLEX обеспечивает неоспоримые преимущества благодаря возможности…

·         динамически перемещать приложения и данные между разными ресурсами хранения и между разными площадками одного центра обработки данных, на территории комплекса зданий или удаленно;

·         создать архитектуру высокой доступности в нескольких регионах.

Семейство VPLEX состоит из трех моделей.

·         EMC VPLEX Local— обеспечивает беспрепятственное перемещение и высокую доступность данных внутри центра обработки данных. Кроме того, это решение позволяет управлять несколькими разнородными массивами с помощью одного интерфейса.

·         EMC VPLEX Metro— обеспечивает мобильность данных, обладает более эффективными функциями высокой доступности и совместной работы между двумя площадками на расстояниях для синхронной передачи. VPLEX Metro также включает уникальную возможность, при которой удаленный узел VPLEX Metro может представлять логические устройства без необходимости наличия физических ресурсов хранения данных для этих логических устройств на самом удаленном узле.

·         EMC VPLEX Geo— обеспечивает мобильность данных, обладает функциями высокой доступности и совместной работы между двумя площадками на расстояниях для асинхронной передачи.

Состав оборудования:

Кластер VPLEX состоит из одного, двух или четырех узлов. Узел отвечает за объединение потока операций ввода-вывода и подключается к серверам и ресурсам хранения данных, используя подключения по Fibre Channel в качестве канала передачи данных. Один кластер VPLEX состоит из узла, который включает следующие компоненты:

·         два директора, которые работают на базе программного обеспечения GeoSynchrony и подключены к ресурсам хранения данных, серверам и другим директорам в кластере с помощью подключений по Fibre Channel и Gigabit Ethernet;

·         один резервный источник питания, который обеспечивает резервное питание для поддержания работы узла при краткосрочном отключении напряжения;

·         два управляющих модуля, которые содержат интерфейсы для удаленного управления узлом VPLEX.

Каждый кластер также включает:

·         управляющий сервер, который осуществляет управление кластером и обеспечивает интерфейс для удаленной управляющей станции;

·         стандартный шкаф EMC типоразмера 40U для монтажа всего оборудования кластера.

Кроме того, кластеры, которые содержат более одного узла, включают:

·         пару коммутаторов Fibre Channel для связи между директорами различных узлов;

пару источников бесперебойного питания, которые обеспечивают резервное питание коммутаторов Fibre Channel и позволяют системе работать во время кратковременного отключения напряжения.

Схема реализации

В нашем случае интересна модель EMC VPLEX Metro.

Хосты ESX расположены на разных площадках. Им выделяется распределенный виртуальный том, состоящий из устройств хранения, также расположенных на разных площадках. При этом на каждой площадке находится синхронизированная копия данных (т.е. фактически имеем зеркало, распределенное по площадкам).

Работа распределенного тома VPLEX имеет следующую логику:

Для каждого распределенного тома VPLEX площадки имеют статусы  preferred site и non-preferred site. При проблемах синхронизации между площадками доступ запись-чтение открыт только на устройствах хранения preferred site, а устройства хранения non-preferred site доступны только на чтение. При аварии на preferred site устройства хранения non-preferrred site также доступны только на чтение, для перевода их в режим запись-чтение необходимо вмешательство администратора VPLEX.

Варианты построения HA/DRS-кластеров на двух площадках c распределенным томом:

·         растянутый» кластер;

·         кластер на каждой площадке.

«Растянутый» кластер

Требования:

• Необходимо обеспечить требования VMotion между площадками.
• Необходим, чтобы подсети, в которых работают виртуальные машины были доступны на обеих площадках.

Ограничение:

• Неболее 4 хостов на каждой площадке, и того неболее 8 хостов в кластере.

Плюсы:

• Балансировка нагрузки между площадками (DRS).
• Использование технологии VMware HA при катастрофе non-preferrred site.

Минусы:

•  Катастрофа preferrred site влияет на все виртуальные машины:  виртуальные машины на preferrred site выключатся из-за аварии, виртуальные машины на non-preferrred site перейдут в неопределенное состояние из-за того, что устройства хранения будут доступны только на чтение. Технология VMware HA при этом не сможет отработать.
• Восстановление на non-preferrred site требует вмешательства администраторов VPLEX и vSphere. Время восстановления сложно прогнозировать.
• Проблемы синхронизации VPLEX между площадками оказывают влияние на виртуальные машины на non-preferrred site, т.к. устройства хранения non-preferrred site будут доступны только на чтение.
• Изоляция хостов при проблемах связи между площадками.

Кластер на каждой площадке

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

Требования:

• Хосты объединяются в кластеры по территориальному признаку (на каждой площадке свой кластер).
• Распределенные тома доступны всем хостам.
• Виртуальные машины каждого кластера, располагаются на отдельных распределенных томах. Каждому распределенному тому назначен соответствующий preferred site (например, Site A – vSphere Cluster A – Distributed volume A – preferred site A).
• Необходимо обеспечить требования VMotion.
• Необходимо, чтобы подсети, в которых работают виртуальные машины были доступны на обеих площадках.
•  Необходимо учесть вопрос доступности vCenter Server. Либо располагать его на третьей площадке, либо иметь его копию на второй площадке (VMware Heartbeat или репликация Veeam).

Ограничение:

• Балансировка нагрузки между площадками только вручную с помощью vMotion.
• Единовременно доступна только одна миграция vMotion между кластерами (в нашем случае между площадками).

Плюсы:

• Доступен VMotion между площадками.
• Катастрофа на одной из площадок влияет только на виртуальные машины, расположенные на соответствующем распределенном томе.
• Проблемы синхронизации VPLEX между площадками не оказывают влияние на виртуальные машины.
• Отсутствует проблема изоляции хостов при потере связи между площадками.

Минусы:

• Чтобы восстановить потерянные виртуальные машины после катастрофы одной из площадок, необходимо регистрировать их на уцелевшем vSphere Cluster либо вручную, либо с помощью скрипта, который необходимо постоянно актуализировать в соответствии с расположением виртуальных машин. Время восстановления сложно прогнозировать.

VMware vCenter Site Recovery Manager

Опять реклама

VMware vCenter Site Recovery Manager является неотъемлемой частью VMware vSphere и обеспечивает следующее.

·         Ускоренное восстановление виртуальной среды благодаря автоматизации.

·         Гарантированное надежное восстановление за счет поддержки тестирования без прерывания работы.

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

Ускорение восстановления

VMware vCenter Site Recovery Manager исключает медленные выполняемые вручную этапы восстановления, превращая сложные инструкции, используемые в традиционном аварийном восстановлении, в неотъемлемую часть системы управления виртуальной инфраструктурой.

Гарантия надежного восстановления

За счет автоматизации восстановления VMware vCenter Site Recovery Manager исключает чреватые ошибками выполняемые вручную процессы восстановления и гарантирует согласованное выполнение процессов восстановления в соответствии с планом.  Кроме того, VMware vCenter Site Recovery Manager обеспечивает удобное тестирование планов восстановления в изолированной среде, обеспечивающей актуальность таких планов и успешность и выполнения.

Упрощение аварийного восстановления

Приложение VMware vCenter Site Recovery Manager поддерживает прозрачную интеграцию с VMware Infrastructure и VMware vCenter Server, существенно упрощая администрирование и обновление планов восстановления. Кроме того, Site Recovery Manager интегрируется с ПО репликации хранилища от ведущих поставщиков, упрощая совместную работу такого ПО с VMware vSphere.

Схема реализации

Требования:

• На каждой площадке должены быть свои vCenter Server и SRM Server.
• Совместимость версии SRM c версиями vCenter и ESX.
• Наличие синхронизации дисковых массивов между площадками.
• Совместимость SRM и storage replication adapter дискового массива.

Минусы:

• Восстановление на другой площадке (перенос на другую площадку) отдельной виртуальной машины возможно только, если эта виртуальная машина расположена на отдельном Datastore (LUN),  т.к. синхронизация ведется на уровне дискового массива для конкретного LUN, и после восстановления этот LUN будет недоступен для работы на первой площадке.
• После выполнения сценария восстановления с первой площадки на вторую площадку, вторая площадка становится основной. Чтобы вернуть инфраструктуру назад на первую площадку, необходимо составить новый сценарий восстановления, и только после этого выполнить обратное восстановление.
• Невозможна балансировка нагрузки между площадками без прерывания работы виртуальной машины. VMotion недоступен.

Плюсы:

• Предварительно настроенные сценарии восстановления.
• Тестирование восстановления без воздействия на рабочую среду. Время восстановления легко прогнозируется.
• Изменение IP-адресов виртуальных машин в соответствии с конфигурацией сети резервной инфраструктуры.
• Возможность перекрестной защиты площадок, т. е. обе площадки одновременно могут быть и protected, и recovery (реализуется с помощью разных сценариев восстановления).

Заключение

Основными достоинствами использования EMC VPLEX является консолидация устройств хранения, единая точка управления и доступа к дисковым ресурсам, возможность строить географически распределенные кластеры с общим диском, возможность миграции данных между различными устройствами хранения без прерывания работы.
        При всей привлекательности, использование VMware High Availability в варианте с «растянутым» кластером содержит много подводных камней: виртуальные машины будут реагировать на все сбои сети между площадками или синхронизации между кластерами VPLEX, возможна ситуация, когда авария на одной площадке прерывает работу всех виртуальных машин.

Решение с одним vCenter и кластерами на каждой площадке лишено недостатков «растянутого» кластера, но повышаются требования к доступности vCenter. Основной минус – отсутствие четкого плана восстановления, при наличии скриптов для восстановления необходимо поддерживать их в актуальном состоянии.

Оба варианта с использованием EMC VPLEX требуют, чтобы на обеих площадках были доступны подсети, в которых работают виртуальные машины.

Решение на VMware vCenter Site Recovery Manager, на мой взгляд, является более прозрачным и логичным. Его основной минус по сравнению с решением на EMC VPLEX – это отсутствие VMotion между площадками.

Источники

Site Recovery Manager Administration Guide. vCenter Site Recovery Manager 4.1
Site Recovery Manager Storage Partner Compatibility Matrix

Compatibility Matrixes for VMware® vCenter Site Recovery Manager 4.0 and Later

EMC CLARiiON Integration with VMware ESX

Использование платформ виртуализации VMware с системами EMC VPLEX. Передовые практики планирования

EMC VPLEX Metro. Технические характеристики.

Understanding vSphere Disaster Recovery/Avoidance options – Part I

Understanding vSphere Disaster Recovery/Avoidance options – Part II (understanding EMC VPLEX partition and VM HA)

Understanding vSphere Disaster Recovery/Avoidance options – Part III (areas of development)

KB Article: vMotion over Distance support with EMC VPLEX Metro

KB Article: Using VPLEX Metro with VMware HA

Презентация по "растянутым" кластерам
Одновременные миграции vMotion между пулами ресурсов в vSphere