понедельник, 15 декабря 2008 г.

Task timeout expired

При выполнении длительных операций, как например накат снапшота, часто вызникает ситуация "Task timeout expired" и задача помечается как "failed", хотя реально все продолжает работать. По умолчанию в Virtual Center таймаут на задачи стоит 15 минут, но его можно увеличить, правда всего до 30 минут - это жесткий максимум.

"C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg"
<config>
...
<task>
<timeout>1800</timeout>
</task>
</config>

Время указывается в секундах.
После изменения данного параметра необходимо рестартовать Virtual Center.

Настройка VCB

Простой способ настроить VCB.

Для начала производим все манипуляции с VCB Proxy, НЕ подключая LUN'ы с VMFS.
Отключаем автоназначение буквенных идентификаторов дискам (C:, D: etc). В командной строке Windows выполняем

c:\diskpart
DISKPART> automount disable
DISKPART> automount scrub
DISKPART> exit

Перезагружаемся. Только после этого можно подключать LUN'ы к VCB Proxy.
Далее добавляем в PATH путь к VCB, по умолчанию это "C:\Program Files\VMware\VMware Consolidated Backup Framework\"
Предположим, что бэкап виртуальных машин будет производиться на диск D:

Создаем директории D:\VMBackup, D:\VCB и D:\VCB\vm
VMBackup - место для складывания готовых бэкапов, после окончания работы VCB можно будет скидывать их на ленточку или еще куда.
VCB - скрипты
VCB\vm - временная директория для текущего бэкапа (в настоящий момент)

А теперь скрипты:
D:\VCB\start.bat
date /T > d:\vcb\date.lst
for /f %%a in (d:\vcb\date.lst) do call d:\vcb\backup.bat %%a
D:\VCB\backup.bat
d:
cd \VMBackup
mkdir %1
for /f "eol=; tokens=1 delims=, " %%a in (d:\vcb\list.lst) do call d:\vcb\backupvm.bat %%a %1
D:\VCB\backupvm.bat
d:
cd d:\vcb\vm
for /d %%a in (d:\vcb\vm\*) do rd /s /q %%a
vcbmounter -h vCenter -u vcb -p password -a name:%1 -r d:\vcb\vm\%1 -t fullvm -m "san" >> d:\VMBackup\%2\vcb.log
d:\vcb\rar m -m5 -mt8 d:\VMBackup\%2\%1 %1 >> d:\VMBackup\%2\vcb.log
А так же будет использоваться вспомогательный файл list.lst, в котором будет находиться список виртуальных машин, подлежащих бэкапу. Крайне желательно при подобной схеме работы придерживаться правила уникальности имен виртуальных машин.

Для запуска используется start.bat, а по окончании работы мы имеем красиво упакованные виртуальные машины в директории D:\VMBackup\<Дата бэкапа>\

HA и самопроизвольный рестарт машин

Вопрос:
У меня периодически самопроизвольно перезагружаются виртуальные машины, что делать?

Ответ:
Проверить свойства кластера. Если кластер является HA и включен мониторинг состояния виртуальных машин, то мониторинг соотв. выключить.

понедельник, 8 декабря 2008 г.

Почему загрузка процессоров меряется в мегагерцах?

Поспорили тут с товарищем за бутылочкой вина, правомерно ли измерять загрузку процессоров так, как это делается у VMware, в мегагерцах. До полпятого утра спорили :)

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

Уточню. Не совсем загрузку процессоров мы меряем.
Предположим, есть кластер из M ESX серверов с разным количеством процессоров, и с разными частотами. На нем работает N >> M виртуальных машин с количеством виртуальных процессоров от 1 до 4. Для простоты, считаем, что процессоры на хостах все одного семейства, отличаются лишь частотами.

Итого, у нас есть некоторые вычислительные ресурсы под хорошо распараллеливающиеся задачи (много виртуальных машин). Как можно оценить общую вычислительную мощность кластера из трех машин физических, причем на одной 4 ядра по 2.33ГГц, на другой 8 по 3.0, а на третьей 16 по 2.66?

В процентах мерять загрузку явно не получится. Просто потому что взяв одну 1vCPU машину с запущенной числогрызкой (например, SETI@Home), обеспечивающей 100% загрузки виртуального процессора мы получим полностью загруженное ядро на одном из физических процессоров. 25%, 12.5% или 6.25% мощности хоста. Но ведь, что самое интересное, при 100% нагрузке на vCPU мы имеем еще и различную производительность, практически полностью зависящую от частоты процессора. Возьмем другой пример, машину с 4 vCPU и средней нагрузкой на vCPU около 20% (в обоих случаях полагаем отсутствие конкурецнии между машинами за ресурсы). Как посчитать, какой процент ресурсов отъедает машина от кластера?

Исходя из предположения о том, что виртуальные машины могут мигрировать по физическим в любом сочетании, остается только одно - брать абстрактную вычислительную мощность кластера. С учетом того, что виртуальные машины отлично параллелятся (причем лучше всего однопроцессорные), а задачи на них непредсказуемы, то остается лишь зависимость производительности от частоты процессора и количества ядер.
Грубо говоря, суммарная мощность = сумме (количество ядер*частоту).

Почему это правомерно? Исходя из архитектуры процессоров x86, у нас есть некоторый поток команд. Причем время исполнения этого потока команд заранее известно - мы точно знаем количество тактов процессора на каждую команду. Чтобы узнать время из количества тактов - ндо знать опять же только частоту процессора.

И что в итоге? В итоге мы получили, что именно в распараллеливаемых задачах общего плана остается единственное средство измерения вычислительной мощности - сумма частот процессоров. Это и есть наш вычислительный ресурс. Несколько парадоксально, конечно. Тем не менее, надо иметь в виду много ограничений и условий.

Итак, перейдем от измерения к управлению. Есть ситуация борьбы за ресурсы - 100% загрузка задачами физического сервера. Как нам делить его процессорное время? И снова можно делить лишь в мегагерцах, ибо в общем случае мы не знаем даже количества процессоров в машине, как и их частоту. А задача стоит именно дать виртуальной машине гарантированную производительность. Итого, мы выставляем резерв (сколько мегагерц, а точнее процессорного времени с учетом частоты процессора и количества ядер, получит виртуальная машина всегда), и дальше выставляем вес машины - какую долю от оставшихся ресурсов (процессорного времени) должна получить машина.

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

Платформа 2009 - мини-отчет

Уфф, вернулся.

Было интересно. Нереально красивое открытие, очень надеюсь, что видео смонтируют и выложат. Но, увы, доклады иногда были просто удручающе хуже.
В особенности по виртуализации, сложилось впечатление, что отдельные докладчики вообще не представляли, о чем рассказывали.
Марк Руссинович совершенно замечательно выступил, и его участие уже спасало всю Платформу целиком в моих глазах.

Кстати, Марк Руссинович и Дмитрий Сотников в докладах использовали для презентации VMware Workstation :)

Одной из новинок (по крайней мере для меня) стала технология "Kidaro" у MS, аналогичная режиму Unity у VMware Worstation, а именно "бесшовная" презентация одного приложения из гостевой системы на хостовой.

Пообщался с представителями Citrix относительно XenServer.
1) Citrix точно так же, как и Microsoft таки не имеет собственной кластерной файловой системы. Проблема с множественным доступом решена на уровне LVM - виртуальным машинам нарезаются LVM разделы.
2) Memory Overcommitment НЕ НУЖНО! Где-то я это уже слышал :) Ну, я понимаю, если вендор не умеет делать Memory Overcommitment и Transparent Page Sharing, то технологии эти явно не нужны клиентам.

Представитель Microsoft открыл всем глаза, что Hyper-V единственный представитель технологий серверной виртуализации, а все остальное по сути попросту фигня. На мой вопрос относительно Virtual Server 2005 вразумительного ответа я так и не получил.

Заодно, в промежутках между докладами, ваш покорный слуга пополнил ряды MCTS :) Будем дальше, так сказать, углУбить :)

вторник, 2 декабря 2008 г.

VMware View (aka VDI3)

Гип-гип-ура! Вышла VMware VDI 3, с сегодняшнего дня именуемая VMware View.

Что появилось нового:

* View Composer — уменьшает потребляемое дисковое пространство и ускоряет разворачивание машин за счет использования Linked Clones (связанных клонов).
* Unified Access — View Manager теперь поддерживает подключения к физическим машинам и терминальным серверам, вдобавок к виртуальным.
* Virtual Printing — предоставляет возомжность печати на локальном или сетевом принтере. View Client автоматически обнаруживает подключенные к клиентской машине принтеры.
* Enhanced User Experience — поддерживает MMR (multi-media redirection) на всех Win XP and Win XPe клиентах. Предоставляет расширенную поддержку кодеков MPEG1, MPEG2, MPEG4 part2, WMV 7/8/9, WMA, AC3, MP3. Позволяет индивидуально настраивать политики перенаправления USB устройств.
* Offline Desktop (Experimental) — самая, пожалуй, интересная возможность, позволяющая загрузить на локальную машину образ виртуальной и продолжить работать в оффлайне, после чего загрузить изменения на центральный сервер. Наиболее интересно мобильным пользователям.

И первые же проблемы:

* View Client with Offline Desktop не может быть установлен на клиентскую машину одновременно с VMware Workstation, VMware ACE, VMware Player и VMware Server.

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