ghetto VCB upgrade

Из переписки:

Михаил, добрый день!

Широко известный скрипт для резервного копирования виртуальных машин ghetto VCB для копирования файлов c ESXi на NFS-сторадж использует Linux-команду "cp".

Недостаток этой команды заключается в том, что cp на ESXi'e очень медленно работает, давая скорость копирования в среднем 5-7 Мегпабайт в сек. Это особенно критично для тяжёлых виртуальных машин, копирование жёсткого диска на 100 Гб будет выполняться не менее 5-и часов.

Команда cat выполняется в разы быстрее, у меня данная команда полностью покрывает по скорости пропускную способность сети и жёстких дисков, давая в итоге 50-70 Мегабайт в сек, т.е. в 10 раз быстрее cp.

Единственный недостаток команды cat - нельзя указать для копирования группу файлов, но это легко обходится. Я не стал править оригинальный скрипт, а разработал свой собственный:

#!/bin/sh
#------------------------------Переменные------------------
NFS=/vmfs/volumes/DebShare/
Datastore=/vmfs/volumes/BigStore/
VMid=96
VMName=SBS
PathNFS=$NFS$VMName/1/`date +%d.%m.%Y`


#------------------------------Подготовка каталогов на NFS-сервере--------
rm -R $NFS$VMName/5
mv $NFS$VMName/4 $NFS$VMName/5
mv $NFS$VMName/3 $NFS$VMName/4
mv $NFS$VMName/2 $NFS$VMName/3
mv $NFS$VMName/1 $NFS$VMName/2


mkdir $NFS$VMName/1
mkdir $PathNFS

#-----------------------------Создание снепшота
vim-cmd vmsvc/snapshot.create $VMid disksnap 0 1

cat $Datastore$VMName/$VMName-flat.vmdk > $PathNFS/$VMName-flat.vmdk
cat $Datastore$VMName/$VMName.vmdk > $PathNFS/$VMName.vmdk

vim-cmd vmsvc/snapshot.removeall $VMid

#-----------------------------Копирование файлов
cat $Datastore$VMName/$VMName.nvram > $PathNFS/$VMName.nvram
cat $Datastore$VMName/$VMName.vmx > $PathNFS/$VMName.vmx
cat $Datastore$VMName/$VMName.vmsd > $PathNFS/$VMName.vmsd
cat $Datastore$VMName/$VMName.vmxf > $PathNFS/$VMName.vmxf


Thx Egros

- пост с мобильного устройства, сорри за краткость и опечатки.

vSphere Virtual Storage Appliance

Итак, VSA, виртуальная система хранения для вСферы – это продукт, позволяющий взять два или три сервера ESXi, настроить зеркалирование между их локальными дисками, и эти зазеркалированные диски сделать доступными всем серверам как NFS-ресурсы. Таким образом, мы получаем программный общий сторадж, что позволяет нам использовать функции живой миграции и высокой доступности имея только 2-3 сервера и все, без аппаратной системы хранения.
На сегодняшний день это решение обладает довольно большими ограничениями, и я не верю в массовость его использования, однако штука интересная и разобраться в ней хочется.

Кстати - очень качественное демо продукта доступно тут - vSphere Storage Appliance - Offline Demo for your use.. По сути - интерактивный флеш-ролик.

Условия

2 или 3 сервера ESXi, на которых будут работать виртуальные машины VSA. Эти сервера и эти ВМ образуют  VSA-кластер. Этот кластер предоставляет NFS-ресурсы, а подключаться к ним могут как хосты-участники кластера, так и любые хосты ESXi.
Если vCenter в ВМ, то эта ВМ не должна использовать VSA-хранилище или работать на сервере ESXi, который участвует в VSA-кластере.
Для ВМ на VSA-хранилище рекомендуется выравнивание по границе 4 КБ, и размер одной операции IO равным или кратным 4 КБ.
В серверах ESXi должно быть минимум 6 ГБ ОЗУ, 4\6\8 дисков в RAID10, 4 гигабитных порта Ethernet.
Сервера должны быть с настройками сети по умолчанию, как сразу после установки.

Архитектура

Суть довольно простая – поднимаем ВМ VSA на каждом сервере VSA-кластера. VSA ВМ использует локальные диски сервера где работает, и зеркалирует эти диски с другими VSA-ВМ этого кластера. За счет зеркалирования мы имеем отказоустойчивость – наши данные не теряются при плановом или неплановом выключении одного сервера ESXi.
Конфигурация кластера VSA на двух и на трех серверах ESXi различается. В случае двухузлового кластера на сервер vCenter необходимо будет установить вспомогательную службу VSA cluster service, которая будет выступать арбитром при обработке спорных ситуаций между двумя VSA-ВМ. Когда VSA-ВМ три – они сами разберутся
Два узла:


Три узла:

Подготовка инфраструктуры

Потребуется 2 или 3 сервера ESXi (плюс еще на одном должен работать vCenter).
ESXi – по сути – должны быть свежепоставленные! В частности, конфигурация сети должна быть по умолчанию.
Потребуется по два IP адреса на VSA-ВМ, и по два IP-адреса для каждого сервера ESXi. Один IP на каждый VSA – для приватной сети, какая-нибудь отдельная подсеть, остальные – из management подсети.

Внедрение VSA

Первый шаг – установка VSA manager на vCenter.
Ничего сложного – setup.exe –> next,next,finish.
После установки в клиенте vSphere появляется вкладка VSA для объекта Datacenter.

На шаге Select Hosts нам потребуется выбрать два или три сервера – будущих участников кластера VSA.
Следующий шаг – настройка сети.

Нам потребуется указать:
VSA Cluster IP – адрес ведущего узла кластера VSA. Используется в сервисных целях.
Если узлов в кластере VSA только два, то в спорных ситуациях будет необходим VSA Cluster service на vCenter. Ему потребуется VSA Cluster Service IP.
VSA management IP – кроме названия пока ничего про него не могу сказать.
VSA Datastore IP – с этого адреса будет подключен NFS-ресурс. Указывается для каждой ВМ в кластере VSA.
VSA Featured IP – будет создан интерфейс vmkernel c этим адресом. Через этот интерфейс будет производится vMotion обычных ВМ (т.е. напрямую к работе кластера VSA этот интерфейс не относится). Указывается для каждого сервера – участника кластера VSA.

В документации указано не использовать для этих адресов диапазон 192.168.xxx.xxx Почему – хз.

Так же, я пока не до конца понял через какой интерфейс ESXi подключает NFS ресурс. Пока что получается что через свой management?
В принципе, все. Ввод VSA в эксплуатацию весьма прост. Мастер сам развернет VSA-ВМ на хосты, сам создаст дополнительный вКоммутатор и группы портов, интерфейсы VMkernel, подключит ресурсы NFS.
После завершения работы мы увидим три хранилища NFS:

(или два, если в VSA-кластере у вас только два сервера).
Ну и статус кластера на соответствующей вкладке.

Необходимые элементы сети будут созданы автоматически:

Через верхний вКоммутатор (Front End) идет управление и NFS трафик , через нижний (Back End) – узлы VSA кластера обмениваются сигналами пульса и реплицируют диски.

Эксплуатация

С точки зрения использования VSA – это просто два или три хранилища, на которых можно создавать ВМ.
А что с обслуживанием?
Если ломается Front End сеть одного из хостов, то одно из NFS хранилищ отваливается. ВМ, расположенные на нем, становятся недоступными. И, в общем-то, все. Пруф, видео.
А если ломается Back End – то не происходит ничего, ВМ просто продолжают работать – так как хранилища зеркалируются между VSA-ВМ, и в этому случае отрабатывает failover. Пруф, видео. Сюда же попадает ситуация когда ломается один из серверов ESXi целиком.
В случае проблем один из узлов кластера VSA можно заменить штатными средствами, из GUI.
Однако добавить в кластер их двух узлов третий узел нельзя – следует сразу создавать VSA-кластер из требуемого количества узлов. Также, добавив дисковых ресурсов на сервера ESXi, нельзя добавить их в VSA.

Размышления про применимость

VSA обладает некоторыми особенностями, многие из которых попадают, к сожалению, в разряд минусов.
Видимая вендором схема использования VSA – инфраструктура с тремя-четырьмя серверами, которую развертывают и сразу начинают использовать с VSA.
Большая головная боль –
1) vCenter необходим.
2) vCenter должен работать на отдельном сервере, где VSA компонентов нет!
Ну, или хотя бы не использовать VSA хранилище для себя – т.е. лежать на локальном хранилище какого-то их хостов – тоже не айс, и решение не поддерживаемое.
Получается, если у нас два или три сервера ESXi в кластере VSA – то требуется еще один сервер. Этот “еще один” или

• с физическим vCenter
• или с ESXi – на котором работает vCenter (vCenter может быть расположен на VSA хранилище). Этот сервер может использовать VSA хранилище и быть объединенным в кластер HA с остальными серверами.

VSA использует локальное хранилище серверов ESXi, однако из за зеркалирования только половина места доступно для размещения ВМ. Если учесть, что поддерживаемая конфигурация требует чтобы на серверах использовался RAID 10 – то в  итоге мы получаем доступным для ВМ только одну четвертую от общего объема дискового пространства на серверах-участниках кластера VSA.
Подобные размышления применимы и к производительности – когда одна из ВМ генерирует запрос на запись, этот один запрос пишется на 4 диска (так как он уходит на две VSA-ВМ, а затем каждая VSA-ВМ записывает его на массив RAID 10).
И да – VSA сильно не бесплатна. Если не удается выбить хорошую скидку, то купить сервера без дисков плюс аппаратное хранилище часто окажется дешевле, чем сервера с хорошими raid контроллерами и дисками на тот же объем и производительность.

Хаки

Если хочется установить VSA на сервера ESXi, где уже есть работающие ВМ - How to Install VMware VSA with Running VMs.
Если хочется установить VSA на сервера ESXi, которые сами работают в виртуальных машинах (для демостенда самое то) – How to Install VMware VSA in Nested ESXi 5 Host Using the GUI.
Для обращения в локальную консоль – svaadmin\svapass.

По материалам

Useful Links – vSphere Storage Appliance (VSA).
vSphere Storage Appliance (VSA) - Useful Links [Updated].
vSphere Storage Appliance (VSA) Resilience - Network Outage Videos
vSphere Storage Appliance (VSA) Resilience - Network Outage Scenario #1: Back End
vSphere Storage Appliance (VSA) Resilience - Network Outage Scenario #2: Front End
How to Install VMware VSA in Nested ESXi 5 Host Using the GUI
How to Install VMware VSA with Running VMs

Как использовать Solaris 10 с его ZFS как NFS хранилище для ESX

Как использовать Solaris 10 с его ZFS как NFS хранилище для ESX - инструкция в посте Solaris 10 with ZFS as NFS target for VMware ESX.

Процитирую оттуда аргументы за NFS и за ZFS для использования с ESX:

First, I will show you the benefits of NFS:

* You can use NFS fore free
* You dont need new hardware or something like FC-Switches
* Easy administration
* Use your infrastructure
* ...

Now I will show you some benefits of ZFS:

* Filesystem and Volumemanger in one system
* Easy administration with only 2 commands - #zpool and #zfs
* advanced raid level and functions
* snapshots
* automatic checksum over all data
* 128 Bit
* automatic shrinking and growing volumes
* ...

Сравнение производительности FC, програмного iSCSI и NFS под VI3

Сравнение производительности FC, програмного iSCSI и NFS под VI3 - совместный гайд от VMware и NetApp.

Задачей тестирования считалось:
сравнить разные типы СХД при низкой нагрузке.
сравнить разные типы СХД при высокой нагрузке.
Оценить нагрузку на процессоры серверов.

Для тестов использовали ВМ с Win2003 SP2.

Обратите внимание, что не все настройки ESX были по умолчанию:
в частности, для iSCSI и FC глубину очереди увеличили до 128.

Достаточно сложно было организовано распределение дисковых ресурсов(LUN'ы, RAID группы и прочее.) - за подробностями идите в документ. В самом конце ссылки на ресурсы, в частности, на NetApp Best practice.

Результаты, признаться, очень похожие на результаты whitepaper от VMware без участия NetApp:

FC самый быстрый и без накладных расходов, программный iSCSI и NFS очень похожи по скорости, притом в разных ситуациях быстрее то один то другой. Но нагрузка на CPU от NFS заметно меньше, чем от программного iSCSI.

thin vmdk shrik. Как уменьшить размер тонкого (thin) диска

Мне захотелось проверить и резюмировать то, как же можно схлопнуть тонкий диск.

Сначала резюме:
После стандартных действий по обнулению выделенных, а затем освобожденных блоков, следует выполнить миграцию "схопываемого" диска с выполнением одного из следующих условий:

• миграция должна происходить между хранилищами на разных системах хранения.
  SAN -> NAS
  SAN -> локальные диски
  один SAN сторадж -> другой SAN сторадж;
• миграция должна происходить пусть внутри одной системы хранения, но у VMFS хранилищ должны быть блоки разного размера;
• миграция может происходить внутри одной СХД, между хранилищами с одинаковыми блоками - но с изменением кое-какой глубинной настройки. Только для ESXi.

А теперь подробности.
С недавно полученных гонораров за книгу я прикупил аж двухтеррабайтный диск в свою тестовую лабораторию, и ставши куда менее ограниченным в дисковом пространстве, решил поиграться со "схопыванием" тонкого диска, о нюансах которого был большой пост недавеча - thin shrink, VMFS blocksize.

Организация теста
Я создал 3 LUN на iSCSI СХД,
на двух из них VMFS с блоком = 8 МБ,
и на одном с блоком = 4 МБ.
Плюс к тому, добавил локальный диск с блоком размером 8 МБ на один из хостов.
И еще создал NFS-хранилище.

Развернул из шаблона виртуальную машину, с тонким диском, на хранилище с блоком в 8МБ. Диск тонкий, данных мало (рис.1).

Рис.1. тестовая ВМ, занимает мало места на хранилище с блоком 8 МБ

Следующий шаг - имитация разрастания тонкого диска и повода к схлопыванию. Копирую на диск ВМ данные объемом около 3 Гб, затем удаляю их (рис.2).

Рис.2. Добавление данных на диск ВМ, затем удаление

Очевидно, тонкий диск увеличивается, и не уменьшается(рис.3).

Рис.3. Тонкий диск увеличился

 Загружаем sdelete, применяем его внутри этой ВМ:

C:\>sdelete -c c:\ SDelete - Secure Delete v1.51 Copyright (C) 1999-2005 Mark Russinovich Sysinternals - www.sysinternals.com SDelete is set for 1 pass. Free space cleaned on c:\ C:\>

И теперь необходимо выполнить Storage vMotion (ну или миграцию выключенной ВМ) для того, чтобы диск ВМ уменьшился.

Тестирование
Сама суть моего тестирования - проверить, а куда и откуда нужно мигрировать ВМ для того, чтобы SVmotion схлопнул ее тонкий диск.

Сейчас ВМ использует хранилище с iSCSI SAN, блок 8 МБ.
Тесты я планирую такие
1) Между LUN одной схд, один размер блока. SAN 8 MB -> SAN 8 MB
2) Между LUN одной схд, разный размер блока. SAN 8 MB -> SAN 4 MB
3) Между LUN схд и локальным хранилищем, один размер блока. SAN 8 MB -> local 8 MB
4) Между LUN схд и NFS-хранилищем. SAN 8 MB -> NFS
5)  Между LUN одной схд, один размер блока. SAN 8 MB -> SAN 8 MB, но попробовать через глубинную опцию принудительно использовать старый механизм копирования, схопывающий тонкие диски.

Для того чтобы слегка упростить себе задачу - я клонировал на исходном хранилище подготовленную к "схлопыванию" ВМ.

Итак, поехали.
1) миграция - внутри СХД, блоки на хранилищах одного размера. Схлопывания не произошло (рис.4).

Рис.4. Тест 1

2) миграция внутри СХД, блоки на хранилищах разного размера. Тонкий диск схлопнулся (рис.5).

Рис.5. Тест 2

3) миграция между СХД (между СХД и локальным диском), блок одного размера. Диск схлопнулся (рис. 6).

Рис.6. Тест 3

4) миграция с VMFS хранилища на NFS хранилище. Схлопывание произошло(рис.7).

Рис.7. Тест 4

5) Наконец, повторяем первый тест, но сначала зайдем на ESXi по ssh и выполним следующие команды:

~ # vsish /> set /config/VMFS3/intOpts/EnableDataMovement 0

Эта настройка предписывает использовать только старый механизм перемещения данных - который решает нашу задачу.

Теперь запускаем миграцию между хранилищами внутри одной СХД, с одинаковым размером блока. Схлопывание произошло(!) (рис. 8).

Рис.8. Тест 5

Потом только стоит не забыть вернуть в ssh и восстановить значение ранее измененной настройки:

~ # vsish /> set /config/VMFS3/intOpts/EnableDataMovement 1

Комментарии

Обратите внимание на связанный момент:
во всех случаях, кроме первого, использовался менее производительный механизм для миграции данных. Напомню картинку из исходных постов:

Вот если задействуется механизм, показанный красной линией, старый - он схлопывает тонкие диски.
А два более новых механизма - не схлопывают, зато работают быстрее.
Вот интересная страница коммьюнити VMware - Blocksize matters!
А там таблица:

Миграция между LUN одного стораджа, с задействованием нового и старого механизмов.
Разница в 4-5 раз. И это даже без VAAI.

Мораль - для скорости лучше, чтобы использовались новые механизмы.
Для "схлопывание" тонких дисков - обязательно нужно старый.

А для того, чтобы обычно использовались новые механизмы -  
блоки VMFS на всех наших хранилищах должны быть одного размера.
 И лучше, чтобы этот размер был бы 8 мегабайт - причин не делать так нет, а такой размер блока применим всегда.

jumbo frames не поддерживаются для NFS\iSCSI в ESX 3.5.

Вычитал на форуме - jumbo frames не поддерживаются для NFS\iSCSI в ESX 3.5.
Однако работают.
В указанной теме публикуется даже самопальное тестирование работы VM на сетевых СХД, по результатам которых вывод примерно следующий - (при использовании 2x QLogic 4050c iSCSI HBA) - софтовый iSCSI дает больше i\o (!), но и ощутимо большую нагрузку на CPU.
Так же имейте в виду - для NFS не работает round-robin балансировка нагрузки, т.е. при использовании несколькими ВМ одного NFS ресурса трафик будет идти через один pNic вне зависимости от их кол-ва. iSCSI же в такой ситуации раскидает нагрузку.

Windows 2008 as Storage for vSphere

Недавно мне попались на глаза два способа сделать сетевое хранилище из Windows Server 2008.

Во-первых - стал честно бесплатно доступен Microsoft iSCSI target.

• Устанавливаем его на Windows 2008 R2 Std\Ent\Datacenter 
• создаем "iSCSI Target" 
• добавляем "device" - им может быть только файл vhd
• указываем идентификаторы iSCSI инициаторов серверов ESX(i) на вкладке "iSCSI Initiators" в свойствах таргета.

Все, теперь данный Windows-сервер представляет из себя систему хранения iSCSI.

Во-вторых, на сайте xtravirt стала доступна инструкция по установке NFS службы - NFS Storage Configuration for vSphere using Windows 2008.

• Добавляем на Windows-сервер роль File Server, 
• затем роль AD Domain Services
• а еще мне потребовалось поднять домен - без этого Identity Management for UNIX ставится не стал. Можно ли заставить его завестись не поднимая домен я не разбирался.
• теперь создаем группу в AD, слегка меняем ее настройки по умлочанию
• и расшариваем по nfs требуемый каталог:

 Я опробовал оба варианта - с iSCSI target вообще проблем не было, nfs что-то нестабильно работал :( - при попытке мигрировать на него ВМ процесс долго висит и завершается ошибкой.
Может быть, что-то в моем стенде не так срослось.

NFS и ESX - особое мнение

Есть мнение,что NFS'ом незаслужено пренебрегают, считая подходящими по скорости лишь FC\iSCSI системы хранения.
Отдельно интересна следующая цитата:

People may find this hard to believe, but the performance over NFS is actually better than FC or iSCSI not only in terms of throughtput but also in terms of latency. How can this be people ask? FC is 4Gb and Ethernet is 1Gb. I would say that this is a rather simplistic approach to performance. What folks don't realize is that:

• ESX server I/O is small block and extremely random which means that bandwidth matters little. IOs and response time matter a lot.
• You are not dealing with VMFS and a single managed disk I/O queue.
• You can have a Single mount point across multiple IP addesses
• You can use link aggregation IEEE 802.3ad (NetApp multimode VIF with IP aliases)

Еще, презентация инженеров NetApp на VMworld по этому вопросу.

из новых комментариев

Какое то время назад давал ссылку Как использовать Solaris 10 с его ZFS как NFS хранилище для ESX.
Откомментировали:

Еще Solaris 10 u6 теперь поддерживает загрузку и установку на ZFS. В принципе можно использовать Solaris 10 как NFS зранилище, но есть возможность задействовать и как iSCSI. Програмный target теперь идет в нативной поставке дистрибутива и конфигурируется буквально 1й командой. Вот
здесь приведены инструкции как настроить ZFS-том для использования его в iSCSI среде

# zfs create -V 2g tank/volumes/v2
# zfs set shareiscsi=on tank/volumes/v2
# iscsitadm list target
Target: tank/volumes/v2
iSCSI Name: iqn.1986-03.com.sun:02:984fe301-c412-ccc1-cc80-cf9a72aa062a
Connections: 0

Так же, тот же автор добавил коммент и в пост готовый вариант построения отказоустойчивой СХД за крайне небольшие деньги:

Собственно немножко про Solaris 10 и ZFS я говорил в соответствующей теме, добавлю про дешевые СХД - та же компания Sun продает в своем роде уникальную железку Sun Fire X4500 - это 4U сервер имеющий 2 2хCore процессора Opteron, 8 или 16Gb RAM и 48 SATA дисков емкостью или 0.5 или 1Тб. И стоит это всего 10к$ в максимальной комплектации. Также в прошлом месяце Sun был анонсирован выход СХД на базе этого сервера (из 48 дисков 2 частично используется под модифицированный мариант Solaris 10 оформленый как firmware) стоимостью где-то 12к$. Единственный минус - это получается СХД с 1м SP, что не может не огорчать, но можно 2 Х4500 обьединить в кластер (все средствами "firmware" через web-консоль) и раздавать дисковую емкость как по NFS, так и по програмному iSCSI. Еще один огорчительный момент - напрямую на этот сервер ESX не встает, т.к. не имеет драйверов SAS-контролера, что там установлен.

txh камрад Maniaq.

VMware на NFS: экзотика или новый хит?

Очень и очень интересный, имхо, пост - VMware на NFS: экзотика или новый хит?.
Для затравки:

Характерный комментарий к одному из постов на эту тему:
“Dan Pancamo said:
950 VMs across 35 ESX servers. ALL on Netapp over NFS for more than a year now. FC/iSCSI? No thanks!”

Ну что, убедил посмотреть тему повнимательнее и пересмотреть предубеждения?

VCB в ВМ

VCB в ВМ.
Начиная с VI3.5 VCB может быть установлен внутри ВМ, и стал поддерживать NFS\Local в дополнение к FC\iSCSI. Но важно отметить, что схема его работы изнутри ВМ и с физической машины отличается.

Стоя в ВМ, VCB может бекапить ВМ с :

• Локальных дисков ESX(только того хоста, на котором работает ВМ с VCB)
• iSCSI(если в гостевую винду поставить iSCSI инициатор, и подключим к тем же LUNам, что и ESXы)
• NFS(см. iSCSI)
  

c FC нельзя - ибо ВМ к FC SAN подключить мы не можем.

Бекапить можем на:

• другой NFS\iSCSI раздел
• в vmdk, подключеный к этой ВМ
  

подключить ленточную библиотеку к ВМ сейчас нельзя.

Обзорный pdf по этому вопросу - тут.

ESXi cli

Вот тут — Unknown or Overlooked ESXi4′s Scripts and Commands — приведен интересный список (с кратким описанием) малоизвестных команд локальной консоли ESXi.

Приведу просто список, с описанием самого, на мой взгляд, интересного.

• BootModuleConfig.sh
• auto-backup.sh
  This script is pretty straight forward. It does automatically a backup of you ESXi host. The backup is stored in /bootbank under the name: state.tgz
• backup.sh
  This script allows you to backup the state of the host in a destination you defined as opposed to auto-backup.sh where it is by default in /bootbank
• busybox (про него маленько вот тут есть — all about esxi)
• cim-diagnostic.sh
• dcui
• firmwareConfig.sh
• ft-stats
  This tool gives you stats about VMs that are in FT mode. The tool assists you in troubleshooting issues with FT. One of the parameters allows you to force FT even though it didn’t pass the requirements. that can be useful in a home lab.
  
• hwinfo
• ipkg
• lspci
• net-cdp
• partedUtil
  This tool helps you troubleshooting issues with corrupt partition table for example. First you need to enumerate the storage devices: esxcfg-scsidevs -l Then you type in partedUtil get Devfs Path>
  The output looks like this: 1 128 157276349 251 0. 128 is the offset and 251 is the FB value for a VMFS partition type.
• services.sh
  This script is used to start, stop or restart services listed in /etc/chkconfig.db. You could eventually edit the chkconfig.db to include extra services. On my nested ESXi host, the list contains the following services:
  /etc/init.d/ntpd
  /etc/init.d/hostd
  /etc/init.d/vobd
  /etc/init.d/slpd
  /etc/init.d/wsman
  /etc/opt/init.d/vmware-vpxa
  /etc/init.d/sfcbd-watchdog
  /etc/opt/init.d/vmware-aam
• smbiosDump
  This tool will dump the SMBIOS info and it’s quiet interesting. VMware hypervisor’s BIOS vendor is Phoenix Technologies LTD. Did you know that?
• stat
  This tool comes with Busybox. It displays some interesting stats for files and files systems. Do you want to know the block size set on a VMFS or NFS datastore? Type in stat -f your datatstore here>. I’ve tested that against a NFS and VMFS datastore in my home lab, here is the output:
  
  /sbin # stat -f /vmfs/volumes/QNAPNAS02NFSonSSD/
  File: "/vmfs/volumes/QNAPNAS02NFSonSSD/"
  ID: 0 Namelen: 127 Type: nfs
  Block size: 4096
  Blocks: Total: 38073304 Free: 18364512 Available: 18364512
  Inodes: Total: 9223372036854775807 Free: 9223372036854775807
  
  /sbin # stat -f /vmfs/volumes/QNAPNAS02iSCSI
  File: "/vmfs/volumes/QNAPNAS02iSCSI«
  ID: 0 Namelen: 127 Type: vmfs3
  Block size: 8388608
  Blocks: Total: 34528 Free: 31126 Available: 31126
  Inodes: Total: 9223372036854775807 Free: 9223372036854775807
• vmkperf 
  If you have this kind of error message: «Performance data is currently not available for this entity.», you may use the following command: vmkperf resetall to reset events and counter which are not shared.

Unified Host Utilities Kit 5.0 for ESX Server

Углядел тут интересный пост на блоге про NetApp - Unified Host Utilities Kit 5.0 for ESX Server is Released.

Какая то штука, которая вроде как умеет, в частности:

There's a new utility that has been added, called mbrscan. The purpose of mbrscan is to identify wheather or not a VM has properly aligned partitions.

Ну, и многое другое.

Here's a list of the all the scripts included as part of the Unified Host Utilities Kit v5.0:
# install - Install script for the EHU
# brocade_info - Collects configuration information about Brocade FC switches
# cisco_info - Collects configuration information about Cisco FC switches
# config_hba - Utility used to set HBA parameters for communicating with NetApp storage devices. This script will get run as part of the installation and can be executed subsequently at any time. Support was added for 8GB FC HBAs and well as FCoE CNAs.
# config_mpath - Utility used to determine which of the available paths are primary paths and to set primary paths
# config_nfs - Utility used to set the NetApp recommended NFS Heartbeat settings.
# controller_info - Collects configuration information about NetApp storage devices.
# mbrscan - Utilty used to check vmdk files for proper alignment from the ESX console (for VMFS and NFS datastores), and from unix/linux (NFS datatstores).
# mcdata_info - Collects configuration information about McData FC switches
# qlogic_info - Collects configuration information about QLogic FC switches
# san_version - Prints the EHU version
# sanlun - collects information about the LUNs currently mapped to your host
# uninstall - Uninstall script for the EHU

Видимо, заточена она под NetApp СХД.

И снова про NFS - делаем аналог vcb для NFS

Тут.
Вкратце - ставим NTFS для Linux(ссылка там есть), делаем снапшот ВМ, моунтим этот снапшот к Linux под которым у нас поднят NFS. И обращаемся к его содержимому(NTFS драйвер пригодиться если это Windows ВМ). Обращение(бекап) на уровне vmdk делается легко и естественно без лополнительных действий.

Официальное сравнение FC, hw iSCSI, sw iSCSI и NFS

VMware опубликовала "Comparison of Storage Protocol Performance". Официальное сравнение FC, hw iSCSI, sw iSCSI и NFS.
Краткий вывод - по скорости FC рулит.
На втором месте - аппаратный iSCSI.
На третье встает NFS(!) - по скорости очень близок на iSCSI, особенно софтовому, но намного меньше нагрузка на CPU хоста.
Тут.

Бекап на уровне файлов с NFS хранилищ

File Level Recovery from within a VMDK backup - если у нас есть NFS хранилище, на котором ESX держит ВМ, то можно делать резервное копирование на уровне файлов гостевой ОС. Для этого потребуются VMware Disk Developer's Kit, и больше практически ничего. Ну разве что еще возможность отдавать содержимое NFS хранилища еще и по CIFS.
Подробности по ссылке.

За ссылку спасибо Роману Хмелевскому.

NFS сервер под Windows

NFS сервер для ESX можно поднять и под Windows.
Подробности в видеоподкасте Configuring NFS on W2K3 R2.

VMware vSphere 4.1 Storage Performance: Measuring FCoE, FC, iSCSI, and NFS

VMware и NetApp зарелизили интересный документ - VMware vSphere 4.1 Storage Performance: Measuring FCoE, FC, iSCSI, and NFS.

Взяли кучу железа, кучу ВМ, кучу нагрузки с них на диски и померяли IOps, нагрузку на процессор и latency для разных протоколов (FC 4 Gbit, iSCSI 1\10 Gbit, NFS 1\10 Gbit, FCOE 10 Gbit).

Вывод - разницы нет что использовать :-)

Материалы и отчет по встрече от 31 октября 2008

Что же было 31 октября сего года:

TCO.
Сначала был разговор про подсчет стоимости владения. В качестве основы использовался инструмент для подсчета TCO в виде xls документа. Кстати, он на русском языке, поэтому к ознакомлению рекомендуется.
Основная графа расходов - это СХД, по этому пункту возражений не было. Если она уже есть, то стоимость миграции на виртуальную инфраструктуру меркнет перед выгодами от нее. Если ее нет, то цифирки выгоды чуть менее шоколадны. См. еще тут - Хостинг ВМ.
Важный момент - все это здорово для крупных предприятий, где счет серверов до виртуализации идет на сотни, может быть на десятки. Для компаний поменьше и совсем поменьше стоимость СХД, похоже, перебьет любые выгоды. По крайней мере у меня такое впечатление создалось. Хотя, "СХД" понятие растяжимое. Например, тут мне вспомнился пост “Недоступный NetApp”: мифы и разоблачения. В нев автор утверждает, что коробочное решение от NetApp, поддерживающее iSCSI и NFS с 6 ТБ RAW емкости и 2 годами сервиса обойдется ~ 250 000 руб. Вроде бы, не так много.

На встрече в этом месте разгорелась любопытная дискуссия - "middle range storage". Представители двух банков рассуждали, хороши они или не очень под виртуализацию, пока ими практически одновременно не были произнесены фразы:
"Ну от мидл ренжа больших иопсов не добиться!"
"Ну в мидлж ренже очень неплохие иопсы обойдуться достаточно дешево!"
Когда зал просмеялся, дискуссия как то увяла, а жаль. Вопрос СХД применительно к ESX - один из популярных и сложных практически всегда.

Так же, когда поднялся вопрос про SMB, один из присутствующих признался, что лично он собрал и продал очень дешевое решение - что то вроде пары серверов под ESXi, а в качестве СХД чуть ли не бытовой NFS сторадж с парой SATA дисков. Всех всех очень заинтересовали подробности. И они лично мне были обещаны по мылу - напоминаю об этом публично - к сожалению, я потерял емейл обещавшего :((

Вопрос лицензий тоже достаточно интересен.
Для компаний покрупнее, стоимость лицензий VMware погоды не делает. Ни по деньгам, ни по сложности процесса лицензирования. Чего не скажешь про Майкрософт - опять какое то время было потрачено на вопросы лицензирования ОС и продуктов MS под виртуализацию.


Автоматизация и управление в виртуальной инфраструктуре.
Lab, Stage, Lifecycle и Site recovery Manager'ы.
Доклад представителей VMware. Русскоязычная презентация доступна тут - Презентация M&A. "M&A" означает Management and Automation. Что мне запомнилось из нее:

Lab Manager - продукт для компаний с разработчиками. Предлагает для них:
Быстрое развертывание многомашинных конфигураций.
Библиотеку часто используемых конфигураций.
Портал для пользователей, где они самостоятельно смогут работать с созданием\удалением конфигураций, не дергая IT отдел.
Stage Manager - автоматизация манипуляций с виртуальной инфраструктурой, в первую очередь с ВМ.
Lifecycle Manager - продукт для автоматизации развертывания, в первую очередь. На базе VMware Orchestrator. Пользователь запросил -> админ утвердил -> пользователь получил(в смысле, запрошенную\ые ВМ) -> по истечении срока архивация\удаление ВМ.
Притом, продукт VMware Orchestrator - это офигенно мощная платформа, с помощью которой можно автоматизировать что угодно. Можно прикупить стандартный Lifecycle Manager - тогда он автоматизирует только то, что подготовила VMware - то, что я только что описал. А можно прикупить разблокирование всех возможностей Orchestrator - с его помощью можно автоматизировать хоть захват власти над этой планетой. Были бы разбирающиеся в нем кадры.


Site Recovery Manager(SRM) - решение для упрощения восстановления после катастроф.
Тезисы:
Нужны - резервный ЦОД, репликация СХД. SRM позволяет создать план восстановления, и безопасно оттестировать его. Красноречивый скриншот:

Из минусов для себя отметил необратимость процедуры восстановления, в том смысле что если мы переехали на резервную локацию, то обратно SRM наши ВМ не перетащит сам. Процесс возвращения на основной ЦОД надо будет оформить как восстановление после сбоя резервного ЦОДа.
Был, кстати, вопрос по поводу лицензирования VI на резервном ЦОДе для SRM. Ответить сразу затруднились, сослались на FAQ по SRM. Что то я не нашел этот FAQ %), буду искать.

Далее.
Далее очень здорово выступил Антон Жбанков.
Для начала он рассказал про VDI. Составить впечатление можно по посту на его блоге - VDI - краткое введение и Ограничения лицензии VDI.
Кстати, вопросы лицензирования десктопных ОС под виртуализацию на русском описаны тут и тут.

После этого, рассказал про свой теоретический и практический опыт с разными гипервизорами. К сожалению, в текстовом виде есть разве что его пост Виртуальность от Sun. Надеюсь, он еще осветит этот вопрос.

Была демонстрация беты VI4. За стенд и саму демонстрацию отвечал я. Положа руку на сердце, надо признать, что демо получилось весьма скомканным :(
Т.к. я участвую в бете 4ой версии VI4, я подписывал настолько суровое соглашение о неразглашении, что как только я подумаю, чтобы что то про нее рассказать, как за левым плечом начинает материализовываться фигура безопасника vmware...
так что сошлюсь на данные из общедоступных источников - слухи о VI4, VMware VI и Linux, Некоторые новости VMware.


Коллеги, пока это все, что мне вспомнилось на данный момент.
За любые дополнения и отзывы, которые помогут нам лучше организовывать и проводить подобные мероприятия, буду благодарен.
Хвалительные жду тут в комментариях, ругательные мне на мыло ;)

к вопросу о резервном копировании ESXi с бесплатной лицензией

 

Из переписки:

 

Pavel Alexei:

Добрый день

Читаю уже давно Ваш блог.

Давно бьюсь с задачей backup free версии ESXi, которое бы воспринимало thin файлы. Все коммерческие продукты backup не работают с free версией ESXi, так как в ней отсутствует vStorage APIs for Data Protection.

К сожалению единственное на текущий момент решение, которое я нашел, это ghettoVCB, причем первой версии, которая работает как скрипт на консоли ESXi. Но и тут есть подвох, не могу «вытащить» куда-то на сторону thin vmdk файлы. Даже если монтировать в качестве внешнего datastore NFS шару, то и там -flat.vmdk в виде sparse файлов лежат. А хочется иметь возможность положить куда-то «далеко». Если NFS от линукс, то можно там, на месте, это зажать при помощи tar -S, тогда tar понимает что это sparse файл, и получаем то что хочется. Этот «маленький» tar можно переложить куда хочется.

НО, хочется большего :-) Хочется нормальный GNU tar под ESXi, чтоб делать все там, на месте. Есть где-то «нормальные» портированные gnu утилиты под ESXi?

 

я:

приветствую.

мне такого не встречалось.
впрочем, я и не искал - не вставало такой задачи.

 

Pavel Alexei:

По ходу я нашел. Совсем случайно

http://ftp.cica.es/mirrors/Linux/pramberger.at/vmware/esx4i/IPKGS/

правда установить через ipk не получилось, но зато смог вытащить, ipk это tar.gz.

Теперь могу

tar cvfzS XXX.tgz XXX.vmdk XXX-flat.vmdk

можно свободно переносить XXXX.tgz. Этот tar sparse он точно понимает, из 4GB «пустого» vmdk файла она создала 10KB tgz, хотя ls показывает 4GB

Тут же вижу есть rsync, понимающий sparse файлы.

И еще coreutils с кучей полезностей. 

Может еще пригодиться, чтоб не мучать по чем зря ssh/scp - ftp клиент для vmware (ftpput/ftpget)

http://www.magikmon.com/download/mksbackup/