четверг, 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 :) Будем дальше, так сказать, углУбить :)