пятница, 19 декабря 2008 г.

Microsoft и Fault Tolerance

Microsoft, по словам Zane Adam (Senior Director of Virtualization Product Management and Marketing), не видит востребованности в Fault Tolerance и соотв. можно не ждать этого в Hyper-V 2.0.
We don't see this [fault-tolerance software for Hyper-V] as an area of high demand right now, but we are watching this closely.

Собственно, выглядит это ровно так же, как и в ситуации с Live Migration - у всех ключевых игроков в обасти виртуализации x86 есть, кроме Microsoft, а сл-но "это просто реально нужно очень небольшому количеству конечных пользователей" (с) некий сотрудник Microsoft.
Что можно перевести на простой русский язык как: "Мы очень хотим, но никак не успеваем этого сделать в разумный срок". А потом, когда таки будет ответ от инженеров, что они смогут это релизовать, Microsoft радостно заявит о прорыве, новой супертехнологии, которую они выпустят через год-полтора, оставив за кадром, что это есть уже у всех несколько лет как.

Как работают снапшоты (снимки) в VMware VI

Снапшот - это снимок состояния виртуальной машины (содержимое памяти, настройки ВМ, содержимое дисков) в определенный момент времени.

Возврат к снапшоту (revert to snapshot) восстанавливает текущее состояние виртуальной машины до сохраненного.

Снапшоты можно делать много раз, один за другим, причем можно создать достаточно развесистое дерево состояний, до 32 уровней вложенности.

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

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

Соотв. в силу существования снапшотов существуют различные режимы для работы виртуальных дисков. А именно существуют независимые диски (independent), на которые снапшоты никак не влияют. Независимые диски могут работать в persistent (все изменения немедленно записываются на диск, и не откатываются даже при возврате к снашоту) и nonpersistent (все изменения откатываются автоматически при выключении машины или возврате к снапшоту). Обращаю ваше внимание, что nonpersistent диск будет возвращен к тому состоянию, в котором находился, когда мы поставили соотв. галочку в свойствах диска, а не к состоянию на момент снапшота.

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

В момент снапшота состояние диска замороживается, а технически это выглядит как блокирование vmdk файла в режиме RO, и создается новый -delta файл, в который будут записываться все изменения на диске. Дисковое простарноство под дельта-файлы выделяется строго по 16MB с целью уменьшения количества блокировок метаданных VMFS. При большом количестве изменений на диске дельта может достичь размера самого диска, но это предел, дальше расти уже не будет. При множественных снапшотах дельта-файлов соотв. становится много, и в режим RO переходят дельты для родительского снапшота. Крайне не рекомендуется запускать после снапшота процессы с интенсивной записью на диск, как например дефрагментацию, поскольку дельта очень интенсивно будет расти.

При возврате к последнему снапшоту дельта-файл просто удаляется, и все изменения пишутся в новый дельта-файл. При удалении снапшота накатываются изменения из его дельты на родительский диск (родительскую дельту). Процесс этот весьма ресурсоемкий и может сильно повлиять на работу как самой виртуальной машины, так и остальных виртуальных машин на этом хранилище. Причем при достаточном размере дельты мы получим ситуацию, когда задача "Delete snapshot" свалится по таймауту (по умолчанию 15 мин). Но особо беспокоится не стоит - накат изменений будет продолжаться до победного конца, несмотря на статус fail в vCenter.

Не рекомендуется использование долгоживущих снапшотов на production машинах, поскольку помимо перерасхода дискового пространства мы получим еще и снижение производительности + невозможность изменения размера диска.

Механизм снапшотов используется также в VCB (VMware Consolidated Backup). При резервном копировании ВМ создается снапшот, после чего он полностью копируется. По окончании копирования снапшот удаляется (накатываются изменения).

четверг, 18 декабря 2008 г.

Ударим виртуализацией по утилизации!

Большая компания, сотни тысяч серверов, десятки датацентров потребляющих мегаваты электроэнергии.
Озаботился тут как-то Очень Большой Босс (ОББ) тем, что вентиляторы у серверов впустую воздух гоняют, вносят свою лепту в дело глобального потепления, так сказать. Указ издал - чтоб все сервера до конца года использовали CPU на 42% как минимум - и баста. У ОББ масса починенных - сами из себя Большие Боссы и Боссихи (ББиБ). Дипломы MBA, и пр. - все при них. Спустили приказ по команде - и понеслось.

Не, дело конечно хороше. К тому же, всякие VMWare и прочая подоспели, вызрели, так сказать.
Сидим, потеем. Все, что можно консолидируем да виртуализуем. Да не видно счастья на лицах наших манагеров. После очередного разноса выяснили, что ББиБ желают видеть CPU utilization >42% не только на физических, но и на виртуальных серверах.

Да, недооценил ОББ ретивости своих подчиненных. Как говорится, заставь дурака Богу молиться - и результат будет предсказуем.
Мы же теперь по ночам, чтоб никому не мешать, гоняем всякую ерунду на виртуальных серверах. Процессоры кипят, вентиляторы шумят, ББиБ довольны, наши манагеры спят споконо (и к нам с глупыми вопросами не пристают). Идилия.
А глобальное потепление? Ну так и хрен с ним, с глобальным потеплением.


http://blog.not-a-kernel-guy.com/2008/12/16/395

Цена и комплектация VMware View

VMware View поставляется в двух редакциях - Enterprise и Premier, а так же в двух видах - Bundle и Add-On.

Add-On - лицензия на View Manager из расчета количества конкурентных подключений, для разворачиания VDI на уже существующей VI Infrastructure
Bundle = Add-On + vCenter + VI Enterprise

View Enterprise = View Manager
View Premier = View Manager + View Composer + ThinApp + Offline Desktop
View Premier Upgrade = View Composer + ThinApp + Offline Desktop

Цены считаются очень просто, умножением на количество конкурентных подключений

Enterprise Add-On = 50$
Enterprise Bundle = 150$
Premier Add-On = 150$
Premier Bundle = 250$
Premier Upgrade = 100$

ESX серверы под View лицензией, согласно условиям лицензии могут исполнять только "десктопную" нагрузку. Но, по официальной информации от VMware, это ограничение уровня EULA, и никаких технических проверок не производится. Поэтому если вы купите View Bundle для серверных задач, то будете очень нехорошим человеком :)

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

VMware View доступна так же виде комплектов (kits), причем ESX везде идет с лицензией Enterprise:
Starter Bundle = View Manager 3 + vCenter Foundation + 1 ESX (2 CPU) + 10 desktops
100 pack = View Manager 3 + vCenter (полный) + 4 ESX (8 CPU) + 100 desktops
10 pack add-on = 1 ESX (2 CPU) + 10 desktops

vCenter из комплекта View Bundle предназначен для управления только View ESX серверами. Но все опять же ограничено только по EULA, так вы уже поняли кем будете :)

понедельник, 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.

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