ThinApp 4.6.1

Кроме обновления View  - VMware View 4.6 - произошло и обновление ThinApp. В новой версии, в частности, улучшили совместимость с Office 2010.

Если кто балуется виртуализацией этого приложения, полезным может оказаться пост - Quick-start guide for deploying Office 2010 using ThinApp 4.6.1.

На случай если кто не знает, что это и как это едят - Виртуализация приложений.

vCenter DB backup with SQL 2005 Express

Недавно на форуме VMware появилась тема Допустим умер vCenter.

Как я когда-то писал - Data Migration Tool - ничего кардинально страшного при этом не произойдет, хотя лучше бы слегка напрячься и избежать продолжительных падений.

Как?

Организовать резервное копирование базы данных vCenter.

В вышеупомянутой ветке форума углядел интересную ссылку - Scheduling vCenter Backups.

Как настроить резервное копирование по расписанию для SQL 2005 Express.

SecureIT Mobile Enterprise, Secure HyperCell, OKL4 Microvisor

Не так давно VMware показала свой гипервизор для смартфонов -VMware MVP, Mobile Virtualization Platform.

Вот тут - Open Kernel Labs releases its mobile client hypervisor - сообщают, что компания  Open Kernel Labs (в нее вроде как инвестировал Citrix) объявила о готовности своего варианта гипервизора для мобильных устройств. Вот ссылка на первоисточник - Open Kernel Labs Fortifies Enterprise Mobility with SecureIT Mobile Enterprise
.

На дубе сундук, в сундуке - утка, в утке - SecureIT Mobile Enterprise, в SME - Secure HyperCell, в HyperCell - OKL4 Microvisor. Это я так пытаюсь пошутить над запутанностью названий в анонсе.

В отличии от MVP, данная штука является гипервизором первого рода, работающим непосредственно на железе, притом железо может быть архитектуры ARM, MIPS и Intel.

Видео:

OK Labs Demo: First Virtualized Phone from OK Labs on Vimeo.


.

VMware Compatibility Guide

У VMware есть очень полезная страничка - vmware.com/go/hcl.
Это онлайн список совместимости, в котором можно проверять разного рода оборудование и комплектующие на совместимость с разными версиями продуктов VMware.

Углядел что обновился интерфейс - новый доступен по кнопке 2.0 Preview.

intel vt vs amd-v

В начале декабря вышла статья Миф 3. Концепции работы аппаратной виртуализации у разных производителей — одинаковы!?

Суть ее в том, что коварный Intel внедрил в своих процессорах такую аппаратную виртуализацию, что не может обосновать безопасность ее использования - теоретически вроде как есть возможность что-то плохое cделать. Я догадываюсь, что эта коротка аннотация далек от идеала :), поэтому лучше процитирую:

... 
Оценивая архитектуру организации режима хоста компании INTEL с точки зрения информационной безопасности, можно сделать вывод о наличии принципиальной слабости защиты программ хоста от внешней модификации и контроля, а также наличии недокументированных возможностей, используя которые можно поставить ядра гипервизоров под скрытый внешний контроль.

Вышло продолжение этой статьи - Миф 3 (продолжение). Cравнение технологий виртуализации режима системного менеджмента на платформах AMD и Intel.

VMware View 4.6

Кратенько - обновился VMware View.
VMware View 4.6 Release Notes.

Самое главное нововведение - PCoIP теперь может тунелироваться через Securtiy Server.

Хороший пост на эту тему - VMware View 4.6 PCoIP Software Gateway (PSG).

Еще видео:

VMware View 4.6 PCoIP Remote Access from Mark Benson on Vimeo.

А еще в связи с этим обновлением Mike Laverick сделал честно бесплатно доступной pdf версию своей книги Administering VMware View 4.5.

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 мегабайт - причин не делать так нет, а такой размер блока применим всегда.

примеры тестов VMware Cerified Advanced Professional, VCAP

По обоим адвансед тестам VMware доступны демонстрации - что они из себя представляют.

Администраторский тест VCAP DCA - VCAP4-DCA Exam UI Demo.

Архитекторский тест VCAP DCD - VCAP4-DCA Exam UI Demo

vCenter XVP Manager and Converter

На сайте с экспериментальными продуктами VMware - VMware Labs - появился новый продукт.

vCenter XVP Manager and Converter.

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

Устанавливаем XVP на выделенный Windows сервер, физический и виртуальный. Настраиваем взаимодействие с vCenter 4.x, и добавляем в его консоль до 50 хостов Hyper-V, и SCVMM.


Теперь в клиенте vSphere (после установки соответствующего плагина) у нас появляется возможность управлять хостами Hyper-V, и осуществлять базовые манипуляции с виртуальными машинами на нем.


Более того, в названии продукта не зря есть слово "and Converter":
можно прямо сразу же инициировать миграцию виртуальных машин с "Настоящего гипервизора™" на vSphere.


Правда, судя по этому официальному видео ролику - запускается простое конвертирование по сети, с установкой агента внутрь ВМ.

шутка юмора

Вполне вероятно что не все читатели моего блога застали старую шутку:

Флудить так флудить!! :)
Картинка:

 Это старкон2, запущенный в DosBox, под иксами в Дебиане, который запущен в VMWare, которая в WinXP
Куда мне вопрос о неработающем звуке задавать? )))))

цитата 59325

VMFS troubleshooting

Введение
Наш любимый ESX(i) использует файловую систему VMFS, для размещения на ней виртуальных машин.

Все хорошо, кроме одного - для нее не существует обслуживающих утилит. Никаких undelete, unformat и т.п. Мораль - не делать бекапы еще более опасно, чем обычно.

Вот один из примеров проблемы и шаманства с решением - Пропал VMFS раздел - что делать?

Но проблемы бывают разные. Не очень давно по почте ко мне обращались со схожими вопросами сразу несколько человек: ESX выключился (некорректно, обычно по пропаже питания), после включения VMFS на месте, а вот файлы виртуальных машин заблокированы. Притом заблокированы так, что не то что включить - скопировать(!) не дают.

Перебрав все известные мне способы попиннать по колесам, я развел руками и посоветовал обратиться в поддержку.

В одном случае обратились - и проблема быстро была решена, путем внесения правок в структуру файловой системы.
(кстати, для тех кто не имеет привычки обращаться в поддержку - у VMware первая линия стала русскоязычной, а продукты VMware без поддержки не продаются - так что обращаемся резко, решительно в случае странных проблем.)

А во втором случае поддержки не было, и нужда заставила найти выход :-)
По результатам изысканий и успешного выколупования данных со мной поделились ранее мне незнакомой утилитой vmfs-tools из состава лайв сд. Эта утилита позволяет подмонтировать раздел VMFS к другой операционной системе.
Запустив ESX сервер с этого live cd  данные с VMFS тома удалось вытянуть.


Монтирование VMFS из под Linux
Разумеется, мне стало интересно, и я поигрался с этой утилитой.
На локальном диске тестового ESX располагается очень нужная мне виртуальная машина (рис.1).

Рис.1. ВМ на локальном диске ESX

Скачал ISO этого live cd, загрузил с него свой тестовый ESX, и вот что увидел (рис.2):

Рис.2. Свежезагрузившийся Live CD

Так как видеть только командную строку лично мне достаточно грустно - я порадовался :-)
Итак, моя задача - получить доступ к разделу VMFS. Посмотрим информацию по разделам соответствующей утилитой - она единственная в местном трее (рис. 3)

Рис.3. Просмотр информации об имеющихся разделах

Следующий шаг - подмонтировать этот раздел.Создадим каталог - точку монтирования, у меня это будет каталог vmfs в корне (рис. 4).

Рис.4. Раздел vmfs создан (слева), и пуст(справа)

Я не большой любитель командной строки, поэтому воспользовался Midnight Commander.
Но к командной строке обратиться все таки придется - откроем терминал и воспользуемся командой "vmfs":

root@PartedMagic:~# vmfs /dev/sda5 /vmfs

Здесь выполнена данная команда, первым параметром на вход ей передан путь к диску с VMFS (здесь это локальный диск сервера), вторым - точка монтирования (ранее мною созданная папка vmfs в корне диска).
И - вуаля (рис.5).

Рис.5. Данные с тома VMFS доступны из под Linux

Сравните правую часть рис.5 с рис.1.
Монтирование осуществляется в read-only режиме - для вытаскивания данных более чем достаточно.

Недолгое гугление нашло мне еще одну ссылку по использованию этой утилиты - из под Ubuntu - Using linux vmfs-tools package to access virtual machines. Там немного другие названия и использование - то ли разные версии с описываемым live cd, то ли что.

Однако на этом мои опыты не закончились.

Монтирование VMFS из под Windows, в том числе

Я вспомнил, что ранее встречал упоминание о каком-то java-драйвере под vmfs. Года три назад я даже пробовал его в деле - но не заработало. Решил попробовать еще раз.

Я нашел его тут - Open Source VMFS Driver.

Эта штука позволяет получить доступ к разделу VMFS с сервера Windows/Linux/Mac OS, где достаточно установленной Java.

Вооружившись Microsoft iSCSI Initiator, я подключился со своего ноутбука к iSCSI LUN с VMFS. Таким образом, в Дистпетчере Дисков я увидел еще один диск (рис.6).

Рис.6. Диск с VMFS, подмонтированный к Windows XP

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

C:\Program Files\Java\jre6\bin>;java -jar D:\vmfs_r95\fvmfs.jar VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35) http://www.fluidops.com Arguments: VMFSVolume info VMFSVolume dir path VMFSVolume dirall path VMFSVolume cat path VMFSVolume fileinfo path VMFSVolume filecopy path [newname position size] VMFSVolume filedump path position size VMFSVolume showheartbeats VMFSVolume webdav [host port] VMFSVolume can be any mounted VMFS volume, or a volume reachable by SSH/SFTP. Multiple VMFS extents can be specified using a comma-separated list. Examples: \\sambaserver\luns\bigdisk dir /Linux_VMs ssh://root:passwd@linuxhost/mnt/vmfslun fileinfo /disks/SwapDisk-flat.vmdk \\.\PhysicalDrive3,\\.\PhysicalDrive4 filecopy /Windows-Template/W2008.vmdk x:\recover\W2008.vmdk C:\Program Files\Java\jre6\bin>;

Таким образом, надо выполнить команду

java -jar D:\vmfs_r95\fvmfs.jar

передав ей первым параметром путь к диску с vmfs, а вторым - действие.
Я путь ей буду передавать как путь к диску Windows.

Для начала - получим информацию о разделе:

C:\Program Files\Java\jre6\bin>java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive1 info VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35) http://www.fluidops.com VMFS label = iSCSI_LUN_1_main VMFS creation date = Fri Jul 24 23:08:51 MSD 2009 VMFS capacity = 14.50 GB VMFS UUID = 4ba75d25-3be4b8df-c372-000c29e78205 VMFS block size = 1.00 MB VMFS version = 3.33 VMFS # of FD/PB/SB = 30720 / 14600 / 3968 VMFS volume type = VMFS volume UUID = 4ba75d25-28b9a16d-2f81-000c29e78205 VMFS volume size = 14.50 GB VMFS volume ver = 4 C:\Program Files\Java\jre6\bin>

Вот когда это у меня получилось - я обрадовался. Вау, работает! :-)

Затем получим список содержимого:

C:\Program Files\Java\jre6\bin>java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive1 dir / VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35) http://www.fluidops.com 10/20/10 05:19:19 (dir) /.dvsData 07/24/09 23:08:51 163а840 /.fbb.sf 07/24/09 23:08:51 63а143а936 /.fdc.sf 07/24/09 23:08:51 60а817а408 /.pbc.sf 07/24/09 23:08:52 260а374а528 /.sbc.sf 07/24/09 23:08:52 4а194а304 /.vh.sf 02/02/11 19:27:13 (dir) /File_Server_Win2008_1 10/01/10 13:18:34 (dir) /main_win2003_template C:\Program Files\Java\jre6\bin>

Все так и есть - если заглянуть из интерфейса vSphere, увидим все то же самое (рис. 7).

Рис.7. Просмотр содержимого раздела VMFS средствами vSphere

Следующий шаг - получение доступа к данным. Не вопрос:

C:\Program Files\Java\jre6\bin>java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive1 filecopy /File_Server_Win2008_1/File_Server_Win2008.vmdk VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35) http://www.fluidops.com Size = 626.00 Bytes Copied 626 bytes in 0s throughput was 39 KB/s C:\Program Files\Java\jre6\bin>java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive1 filecopy /File_Server_Win2008_1/File_Server_Win2008-flat.vmdk VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35) http://www.fluidops.com Size = 10.00 GB Copying file -- bytes left=10663493632 throughput=29393 KB/s ETA=362s ... тут типа прогресс бар, но я сделал монтаж ... C:\Program Files\Java\jre6\bin>

Здесь не совсем монтирование раздела - здесь команда выгрузки конкретного файла.
Получаем наши vmdk(рис.8)

Рис.8. Бекап удался

Насчет "бекап удался" я слегка соврал - на середине процесса копирование оборвалось - но я не стал разбираться пока, разовая это проблема или нет.

Напоследок расшарим подмонтированный VMFS:

C:\Program Files\Java\jre6\bin>java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive1 webdav VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35) http://www.fluidops.com *** Serving WebDAV/HTTP at http://localhost:50080/vmfs log4j:WARN No appenders could be found for logger (org.mortbay.log). log4j:WARN Please initialize the log4j system properly.

К сожалению, подключить к Windows как сетевой диск мне не удалось, хотя в хелпе написано что можно; а вот браузером зашлось нормально(рис.9,10).

Рис.9. Просмотр содержимого vmfs раздела через браузер, корень раздела

Рис.10. Просмотр содержимого vmfs раздела через браузер, каталог ВМ

В общем, за сегодня я значительно прокачал свои навыки неклассических доступов к разделам VMFS.

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

VCAP Datacenter Administration Experience

Ну и в предварительное заключение про тест VCAP Datacenter Administration, который я попробовал сдать вчера:

1) все тестирование - только  лабораторные работы. На экране компьютера видишь что-то вроде:

Вопрос 12:
На ВМ "PowerShell" создайте каталог scripts в корне диска C. Напишите скрипт на PowerShell, который делает выборку ВМ по <некий критерий>, и список ВМ помещает в файл с таким-то именем. Сохраните скрипт в ранее созданном каталоге, и выполните.

Прочитав вопрос, нажимаем на панельку в верхней части, на экране вместо вопроса появляется RDP сессия. На рабочем столе доступны: клиент vSphere, RDP клиент, Putty, Adobe Reader.
И приводятся параметры доступа к виртуальной инфраструктуре:

2) У нас будут vCenter, два хоста - на них установленны ESX и ESXi, и десятка полтора ВМ. vMA, ВМ с PowerShell, и ВМ для всяких заданий. Это именно лаборатория - все наши действия влияют на нее весь тест. То есть собрав кластер в начале, мы работает с этим кластером впоследствии. Забавное предупреждение перед началом теста - "Если вы убьете управляющую сеть ESX(i), то на этом все, починить ее способа не будет".

Adobe Reader нам дается для доступа к документации(!). По ходу теста можно обращаться к пятку основных официальных документов по vSphere.Разумеется, man в putty тоже никто не отменял.

На самом деле, внимательный глаз может обнаружить официальную  демонстрацию всего этого на странице теста.

3) Большая часть лаб - графический интерфейс(!!). Есть лабы и на локальную командную строку, и на удаленную из vMA, и на PowerCLI - но их меньше половины.

4) Всего лаб у меня было 34. Переходить к следующему заданию можно в любой момент, как и возвращаться. Времени дается 3.5 часа + 0.5 за неродной язык, так что всего 4. Этого времени не дофига!

5) В заданиях на графический интерфейс неприятны некая заторможенность некоторых действий. Например, когда HA собирается полторы-две две минут в реальности - это ок. А вот когда каждая минута на счету :-). Особенно если что-то пошло не так (а там регулярно есть палки в колесах, не все из которых заранее сообразишь проверить) - приходится повторять действия.
А еще было одно задание, которое я просто не понял что имелось в виду. Суть там в том, что "есть вот эти пять ВМ, они якобы образуют некую систему, вот надо для них сеть организационно правильно сделать" - не имею права сказать конкретнее. Я в общем не понял что от меня хотели. Поясню - не из за английского, а из за или хреновой постановки задачи, или протупил.

6) задания на командную строку показались относительно несложными - просто надо знать как делается запрашиваемое :-). Мне попадались довольно базовые вещи, думаю это так и есть в принципе. Для меня сложным оказалось только задание, связанное с VMware PSA.

UPD. Проходной балл я так понял - 300 из 500 баллов. Написано в блупринте.

VCAP - как назначить тест

Коллеги, немного наглядных иллюстраций как организационно выглядит процесс сдачи VCAP тестов.

Шаг 1.
Идем на сайт VMware - http://vmware.com/certification/ - и регистрируемся как желающий сдать VCAP DCA или VCAP DCD.

Какое-то время идет проверка, что мы уже обладаем статусом VCP, когда все ок - на почту падает письмо с темой Scheduling Your VCAP4-DC# Exam. Это означает, что можно переходить к шагу 2.

Шаг 2.
Идем на сайт тестовой системы VUE - http://www.pearsonvue.com/vmware/.
И выбираем что мы хотим Schedule a Test -> VCAP Exam. Надо будет авторизоваться, и в своей учетной записи мы увидим доступность к заказу соответствующего теста.

Затем Next.
Выбираем подходящий учебный центр (кстати, с его менеджером лучше бы заранее согласовать дату и время. При сдаче в Микроинформе позвоните +7 495 953 00 06).Next.
Выбираем дату и время.Next.

Если вдруг будут какие коды на скидку или ваучеры - указываем. Next.

Указываем данные пластиковой карты для оплаты теста. Next, и на этом все.

Шаг 3.
Приходим в тестовый центр. Сканкопия паспорта, цифровая фотография, подпись на планшете (для фиксации в электронном виде). Сдаем все вещи, и идем сдавать тест.

jabuin

Коллеги, тут со мной поделились ссылкой на калькулятор-сайзер vSphere - vSphere 4 sizing.

VCAP DCA

Самое неприятное, конечно, 10 дней ждать результата

Ну и фотка стремная :-)

реклама в уютной жежешечке

Коллеги, у кого есть проблемы с сетью на vSphere - особенное если вы уже успели провести изыскания к решению, и неудачно - вам наверняка поможет это.

Обратите внимание - решение вендоро- и гипервизоро-независимо.

SIOC, Storage IO Control

В vSphere 4.1 появилась фича Storage IO Control, SIOC. Я про нее упоминал уже не раз, и еще раз поднимаю эту тему в связи с выходом пары новых документов на эту тему.

Первый - Storage I/O Control Technical Overview and Considerations for Deployment. Небольшой описательный документ. Что это, как включить, рекомендации по настройке.

А вот второй - Managing Performance Variance of Applications Using Storage I/O Control - поинтереснее.

Приводятся результаты нескольких тестов.
Первый:
1) взяли два сервера, создали 4 одинаковых ВМ с Windows 2008 SP1, и приложением DVD Store Version 2. Это тестовое приложение для создания нагрузки, характерной для БД. В состав приложения входят база данных, веб-сервер и что-то там на уровне драйверов, ссылка на сайт. Для каждой из ВМ был создан системный диск, диск с данными приложения и RDM для логов базы (Рис.1). Диски трех типов расположены на отдельных LUN, и нас интересует LUN, или хранилище VMFS, на котором лежат диски с данными.

Рис.1. Схема организации тестированя

Обратите внимание - из четырех тестовых ВМ одна выбрана как критичная.

Задача теста - понять, как SIOC сможет сделать хорошо для критичной ВМ, здесь это VM2.

Первый тест:
Дали нагрузку только для ВМ2 (которая критичная). Полученные цифры используются как точка отсчета - сколько она может получить без конкуренции.
Затем, нагрузку дали на все ВМ одновременно, и померили скорость при выключенном SIOC.
Далее, включили SIOC и замеряли производительность при разных значениях shares для критичной ВМ2. Результаты см. на рис.2.

Рис.2. Результаты теста 1

Как видим, за счет SIOC критичные ВМ, для которых мы выставили большие shares, способны втоптать в пол конкурентов на их iops. Когда у критичной ВМ 4000 shares, а у трех конкурирующих по 200, производительность критичной достигает 94% от ситуации когда она ни с кем не конкурирует (напомню, что речь идет о нагрузочном тестировании - если ВМ2 захочет меньше она будет получать меньше).

Второй тест.
В рамках подготовки ко второму тесту была добавлена еще одна виртуальная машина, еще на одном сервере ESXi, но расположенная на тех же LUN (рис.3).

Рис.3. Схема организации тестов 2 и 3

Теперь эта пятая ВМ была выбрана критичной, и были настроены shares для этой и других ВМ не по умолчанию (рис. 4).

Рис.4. Настройки Shares для теста 2

Затем было начато тестирование, состоящее из трех фаз:
Фаза 1: на всех пяти ВМ была создана нагрузка, в течении 360 секунд.
Фаза 2: на пятой ВМ нагрузка была прекращена, 345 секунд ВМ 5 простаивала.
Фаза 3: пятая ВМ опять получила нагрузку, еще на 360 секунд. Остальные четыре ВМ так же продолжают быть под нагрузкой.

Производительность всех пяти ВМ в этих трех фазах вы видите на рис. 5. Она зависит от shares с рис.4.

Рис.5. Данные теста 2

Вот зачем нужен SIOC.

Если слегка углубиться в подробности работы, то стоит сказать за счет чего работает эта функция. Работает она за счет динамического изменения глубины очереди на HBA серверов. Меньше очередь -> меньше IOps можно отправить на СХД -> решена задача сделать кому-то больше кому-то меньше.

Вот как менялась глубина очереди на трех серверах из теста 2 (рис.6).

Рис.6. Изменение глубины очереди HBA серверов

 Когда пятая ВМ начала простаивать, глубина очереди третьего сервера (где работала она одна) была снижена с 32 до 4.

Третий тест.

В третьем тесте была имитирована такая нагрузка, когда часть пиков нагрузки на ВМ приходится на разные время суток.
Были взяты те же 5 ВМ, пятая была нагружена все время, а остальные четыре - как будто обслуживали разные часовые пояса.
Без SIOC проседания все время нагруженной и важной ВМ 5 составляло до 42% (рис. 7).

Рис.7. Данные третьего теста без SIOC

А с SIOC - вполовину меньше (рис. 8).

Рис.8. Данные третьего теста с SIOC

Ну и связанный с этим показатель - производительность пятого виртуального сервера в это время (рис.9).

Рис.9. Разница в производительности критичного сервера с и без SIOC

Выводы:
Если производительности дисковой подсистемы по факту не достаточно для удовлетворения пиков загрузки нашей виртуальной инфраструктуры, то SIOC позволит существовать в такой ситуации максимально комфортно.

Troubleshooting Performance Related Problems in vSphere 4.1 Environments

У вас есть виртуальные машины, которые тормозят?

Документ Troubleshooting Performance Related Problems in vSphere 4.1 Environments, возможно, не поможет вам. Однако вполне вероятно что поможет, и если вы не ознакомились с его блок-схемами решения проблем, то это не особо профессионально - сначала надо убедиться что стандартные способы решить проблему не помогают, и уже потом идти в гугл\форумы\саппорт.

Всего 68 страниц, и много картинок.

Сначала высокоуровневый подход:

Это первая схема, объясняющая подход

1) определяем критерии решения проблемы
2) применяем базовые способы решения
3) применяем продвинутые способы решения
4) или проблема решена, или что-то с ней не так

Затем что надо проверить при проблемах с той или иной подсистемой или в общем:

Основные параметры для проверки в случае проблем производительности

Ну и много инструкций что и как проверять, с конкретными цифирками:

Например, про процессор

thin shrink, VMFS blocksize

Думаю, большинство читателей в курсе что такое тонкие(thin) диски, их плюсов и минуса. И как с этим минусом бороться.

Вкратце - тонкие диски растут по факту потребления места гостем, но не уменьшаются. Существуют способы, пусть не очень красивые, их "схлопнуть" - основной(раз) и неосновной(два). Суть основного способа в том, что надо обнулить блоки, ранее занятые а потом освобожденные гостем, и затем осуществить Storage vMotion виртуальной машины.

Внезапно, Duncan Epping написал - Blocksize impact?, а Антон Жбанков перевел - Влияние различных размеров блока VMFS, почему первый способ не всегда работает.

Вкратце перескажу и чутка дополню.

Идея в том, что у ESX(i) есть два механизма для переноса данных - старый и новый. Новый более оптимален, но он _НЕ_схлопывает_ тонкий диск по способу раз. Старый механизм переноса - менее оптимален, но тонкие диски схлопывает.

Красивая картинка про различия старого и нового механизмов переноса данных:

Уровни работы трех механизмов копирования данных

Как видно, выделяется даже три механизма - старый (fsdm, наверху), новый (fs3dm, в середине), и новый с аппаратной поддержкой (= VAAI) внизу (последний механизм называется fs3dm – hardware offload).

ESX(i) задействует новый механизм всегда, когда может - а не может когда данные переносятся между LUN с разным размером блока VMFS.

Так что при переносе тонкого диска между хранилищами с одним размером блока ESX(i) выберет новый механизм - и перенос будет произведен быстрее, но без схлопывания.
А при переносе между хранилищами с разным размером блока - медленнее, но со схлопыванием.

В комментариях к первоисточнику делятся опытом:

1) ЛУН1 и ЛУН2, оба с блоком = 4 Мб.
2) Создается ВМ с толстым диском = 35 ГБ, внутрь ставится Windows.

3.1) перенос thick диска между LUN с конвертацией его в thin
35 Гб толстый диск до
14.5 ГБ тонкий диск после

3.2) Внутрь тонкого диска дописывается гигабайт данных, затем удаляется. Тонкий диск становится размером 15.5 Гб. Применяется sdelete, обнуляющий все блоки. Тонкий диск вырастает до 100%(!, такой побочный эффект данного промежуточного шага может быть неприятным сюрпризом). Осуществляется SvMotion между LUN, thin -> thin.
35 Гб тонкий диск до
35 Гб тонкий диск после (вот этот факт и является краеугольным)

3.3) Еще одна миграция, с конвертацией тонкого диска в толстый

35 Гб тонкий диск до
35 ГБ толстый диск после

3.4) Обратная миграция, с конвертацией толстый -> тонкий

35 Гб толстый диск до
35 ГБ тонкий диск после (вот опять неприятный момент).

Мораль: если "схлопнуть" тонкий диск надо, то может помочь миграция не просто между хранилищами, а между хранилищами с разным размером блока. А для диска размером больше террабайта, лежащего на хранилище с блоком в 8 Мб, схлопывание таким образом вообще невозможно.

UPD.  Надо бы проверить, но возможно схлопывание будет происходить при миграции между стораджами, или, например, между СХД и локальными дисками.

Или, непроверенный способ, в комментариях к первоисточнику упоминается настройка:
есть такая оболочка vsish - только в составе ESXi, вот с ее помощью можно пнуть настройку

VMFS/EnableDataMovement
1 = yes
0 = no
Description – Whether VMFS should handle data movement requests by leveraging FS3DM

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

Список доступных через vsish настроек, в том числе скрытых - vSphere ESXi 4.1 - Complete vsish configurations.

ITQ Infrastructure Client

Наткнулся на упоминание ранее неизвестной мне утилиты - ITQ Infrastructure Client (скачать).В принципе, потенциал у нее есть. Вот смотрите что она умеет делать:
Во-первых, разумеется, подключаться к vCenter:

Подключение к vCenter

Следующий шаг - выбор жертв. Жертвами выступают сервера ESX(i) (зачем утилита отображает и ВМ я не понял). Следующий шаг - из выпадающего меню в правой части выбрать желаемое действие:

Следует выбрать целевые сервера, затем действие над ними

Список возможных действий не очень велик:

Действия, выполняемые при помощи описываемой утилиты

Два примера.

Сначала выполнение произвольной команды локальной командной строки:

Указание команды для выполнения на выбранных серверах, и результат

Затем - создание группы портов.
Действие:

Результат:

Созданная утилитой группа портов на указанном вКоммутаторе и с указанным vlan

Cisco Nexus 1000v

Если кто будет разбираться, что это за зверь - распределенный виртуальный коммутатор для vSphere от Cisco, Cisco 1000V, то может быть полезна инструкция по вводу в эксплуатацию - Standing Up The Cisco Nexus 1000v In Less Than 10 Minutes. По соотношению картинок и текста это даже можно назвать комиксом :).

vCMA experience

Я на днях писал об новом экспериментальном продукте VMware - vCenter Mobile Access, vCMA.

Были интересные мнения в комментариях:

Михаил, я правильно понимаю, что эта шняга (по сравнению с RDP-ремотой на комп с vCenter) хороша лишь тем, что использует браузер, который априори должен быть на любом мобильном устройстве (или вообще в любом интернет-кафе), тогда как RDP-клиент ещё нужно найти под свою мобильную платформу и установить?

…

Ну, даже если эта шнягина управляющая WEB-страница и поместится целиком на экранчике того же иФона/Дроида, то будет ОЧЕНЬ мелко - всё равно придётся смагнифаить актуальную область... а потом скроллиться туда-сюда-обратно, перемещаясь по иным нужным местам (как то: меню сверху, кнопки "комплит/ок" снизу и т.п.). Т.е., от окна RDP-клиента я пока разницы не ощущаю...

…

Дык можно же сделать недоменную вин-VM`ку (зарестрикченную по самое немогу), войдя на которую по RDP, можно только запустить клиент Сферы, который будет коннектиться к машине с vCenter, нет? Так на так и выходит - что эту вин-машинку скомпрометируют (кстати, что имеется ввиду?), что лин-VM`ку с дискутируемым ааплаенсом - остальные кролики не пострадают.

Вот чем vCMA лучше выделенной машины с RDP кроме удобства работы с маленьких экранов – вопрос хороший. Кстати, у кого нибудь есть соображения по этому поводу?

А вот по поводу удобства работы с маленьких экранов есть соображения у меня.
Раз в комментарии были упомянут смартфоны (iPhone\Android), то сначала я расчехлил свой старый Glofiish x800 (опыт не совсем чистый, но айфонов и дроидов у нас в семье нет), подключил к домашнему WiFi и обратился на vCMA. Имхо, результат более чем хорош, доступ к иконкам удобен.
Проиллюстрирую своими фотографиями (со скриншотами заморачиваться было неохота).
Основное меню (рис.1):

Рис.1. Веб-интерфейс vCMA на Glofiish x800

 Он же, но я отрезал все кроме экрана смартфона (рис. 2):

Рис.2. Веб-интерфейс vCMA на Glofiish x800, в кадре только экран

 

 

Список виртуальных машин (Рис.3):

Рис.3. Веб-интерфейс vCMA на Glofiish x800, список виртуальных машин

 Как видите, и сами объекты, и всякая мелочевка типа стрелочек для проматывания списков вполне себе комфортного размера
.

Сравните с клиентом vSphere в RDP сессии с этого же устройства (рис.4):

Рис.4. Клиент vSphere в RDP-сессии со смартфона

А дальше мое любопытство спросило - а что насчет твоего текущего телефона, модели "Нокия за 2000р"?
Не вопрос - делаем доступ к vCMA из интернета (так как в локальную сеть мою нокию не подключишь, а доступ к мобильной сети по EDGE у нее есть). И вуаля (рис.5):

Рис.5. Первый экран - данные для авторизации

 Обратите внимание - основное меню в столбик - но пункты крупные и работать комфортно(рис.6):

Рис.6. Основное меню в

Список виртуальных машин без пиктограмм состояния, но на экране ясно отображается - сейчас показаны 5 из 13 ВМ, доступны стрелки перемотки списка (рис.7):

Рис.7. Список виртуальных машин

 Зайдя в свойства виртуальной машины, сначала видим столбец пиктограмм (рис. 8):

Рис.8. Пиктограммы в свойствах ВМ

 Промотав страницу, здесь же видим данные о виртуалке (рис. 9):

Рис.9. Данные виртуальной машины

 Даже пинг ВМ с этого экрана работает, и данные отображаются достаточно комфортно (рис.10):

Рис.10. Данные пинга виртуальной машины

Лично я имею мнение - данный интерфейс в полный рост применим даже с самых примитивных современных телефонов. С учетом нормально работающего поиска, даже в большой инфраструктуре можно выполнять срочные действия (из тех, разумеется, что доступны в этом интерфейсе. Какие именно доступны см. в первой статье про vCMA).


Как-то так.