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). При резервном копировании ВМ создается снапшот, после чего он полностью копируется. По окончании копирования снапшот удаляется (накатываются изменения).

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

Большая компания, сотни тысяч серверов, десятки датацентров потребляющих мегаваты электроэнергии.
Озаботился тут как-то Очень Большой Босс (ОББ) тем, что вентиляторы у серверов впустую воздух гоняют, вносят свою лепту в дело глобального потепления, так сказать. Указ издал - чтоб все сервера до конца года использовали 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, так вы уже поняли кем будете :)

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 и включен мониторинг состояния виртуальных машин, то мониторинг соотв. выключить.

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

Поспорили тут с товарищем за бутылочкой вина, правомерно ли измерять загрузку процессоров так, как это делается у 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 :) Будем дальше, так сказать, углУбить :)

Платформа 2009

Через 5 часов отбываю на Платформу 2009.

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.

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

Проблемы переезда VI

Перечень проблем при переезде VI в одной из компаний. Принимал непосредственное участие в решении.

• После включения VI, луны с VMFS оказались заблокированными.

Выглядит на практике это примерно так:

Nov 14 13:29:43 frasvmhst06 vmkernel: 0:00:03:34.249 cpu4:1045)WARNING: SCSI: 5519: Failing I/O due to too many reservation conflicts
Nov 14 13:29:43 frasvmhst06 vmkernel: 0:00:03:34.249 cpu4:1045)WARNING: SCSI: 5615: status SCSI reservation conflict, rstatus 0xc0de01 for vmhba2:0:0. residual R 919, CR 0, ER 3
Nov 14 13:29:43 frasvmhst06 vmkernel: 0:00:03:39.086 cpu4:1045)FSS: 343: Failed with status 0xbad0022 for f530 28 2 453782fc 6b8bc9e9 1700770d 1d624ca 4 4 1 0 0 0 0 0

Лечение:

[root@esx2 root]# vmkfstools -L lunreset /vmfs/devices/disks/vmhba2:0:0

• Не штатная проблема. После включения ESX хостов, у меня не оказалось DataStore's. LUN'ы видны, а DataStore нет. А точнее луны пустые.

Лечение описано в предыдущем посте.

На правах рекламы

it4business.ru - портал для IT-менеджеров: для тех кто руководит, принимает решения и отвечает за результат.

Пропал VMFS раздел - что делать?

Бывает, случается непредвиденное. Скажем, глобальный переезд оборудования. Все выключили корректно, все сохранили. Поставили на новом месте, подключили, включаем, а VMFS разделы исчезли. И виртуальных машин соответственно тоже не видно. Хотя все LUN'ы видны.
Причем если начать создавать новый VMFS раздел на этих LUN'ах, будет указано, что они пустые и никакого VMFS там нет (только осторожнее с этим, не нажмите случайно "создать"). Если при переезде не были физически убиты диски и ничего страшного не случилось, то скорее всего немножко слетело разбиение разделов, которое можно быстро и просто поправить.

Уточним ситуацию (все манипуляции производятся с ESX сервера).
Определяем какой именно раздел надо править.

[root@esx2 root]# esxcfg-vmhbadevs
vmhba0:0:0 /dev/cciss/c0d0
vmhba1:0:1 /dev/sda
vmhba1:0:15 /dev/sdb
vmhba1:0:16 /dev/sdc
vmhba1:0:23 /dev/sdd
vmhba1:0:26 /dev/sde
vmhba1:0:27 /dev/sdf

[root@esx2 root]# fdisk /dev/sda

The number of cylinders for this disk is set to 127482.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sda: 1048.5 GB, 1048577048064 bytes
255 heads, 63 sectors/track, 127482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

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

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-127482, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-127482, default 127482):
Using default value 127482

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): fb
Changed system type of partition 1 to fb (Unknown)

Command (m for help): x

Expert command (m for help): b
Partition number (1-4): 1
New beginning of data (63-2047998329, default 63): 128

Expert command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

[root@esx2 root]# vmkfstools -V

Теперь проверяем, VMFS раздел должен появиться.

!!! Внимание !!!
Все манипуляции необходимо проводить на снапшоте LUN'а, если есть поддержка данной функциональности на вашей SAN.
Первое, что необходимо сделать после восстановления доступа к VMFS разделу со снапшота - полный бэкап всех виртуальных машин (ну или только особо нужных) путем простого копирования. И только после этого можно проводить операцию на "живом" LUN'е.

P.S. у вас до сих пор не настроены бэкапы?

ESX Memory features - фишки ESX при работе с памятью

Основных фишек ESX две: memory overcommitment и transparent page sharing.

1. Memory Overcommitment.
При старте виртуальной машины под нее выделяется оперативная память на хосте в размере заявленной для виртуальной машины (указанной в конфигурации). Но ведь далеко не всегда загрузка ВМ по памяти составляет 100% - хотя бы просто потому что если загрузка памяти 100%, то памяти выделено явно недостаточно. Иными словами, в любой момент времени есть достаточно много выделенной для машин памяти, но ими не используемой. А следовательно можно ее использовать для других машин.
В этом и состоит суть данной технологии - когда на хосте с 2 ГБ физической памяти совершенно без проблем работают 4 виртуальных машины с памятью по 1 ГБ.
Изначально, при избытке ресурсов, память резервируется под виртуальную машину. Memory overcommitment вступает в дело при старте очередной машины и условии (сумма памяти виртуальных машин > физической памяти на хосте). Новая виртуальная машина запрашивает блок памяти, и ESX выделяет ей этот блок из области, выделенной ранее для другой виртуальной машины, но не используемой. Безопасность обеспечивается "вытиранием" содержимого данного блока памяти перед передачей его новой ВМ.

2. Transparent Page Sharing.
Если подумать, то даже в пределах области памяти одной виртуальной машины можно найти много совершенно одинаковых страниц памяти. Если же хост большой и запущено на нем пара десятков машин, то дублированной памяти становится очень много. На ESX запущен фоновый процесс, сканирующий память на дублированные страницы. Когда этот процесс находит дублированные страницы, то оставляет лишь одну, а остальные освобождает, оставляя ссылку. Соотв. это экономит физическую память, позволяя добиваться более высоких коэффициентов консолидации.
Насколько эффективно работает данная технология, могу показать на примерах.
1) ESX хост с двумя виртуальными машинами (512MB памяти у каждой).
Виртуальные машины одинаковые - работают как кластер. Софт: Win2003R2, Oracle 10g Client + кое-что еще.
Memory Granted: 1200 MB (всего выделено)
Memory Shared Common: 151MB (объем найденных общих страниц памяти)
Memory Shared: 540MB (суммарный объем найденных общих страниц памяти)
Т.е. даже в этой ситуации сэкономлено 540-151 = 389 MB памяти. С учетом оверхеда на каждую машину, получается около 30% эффективности. Т.е. даже без учета memory overcommitment, при запуске идентичных виртуальных машин на ESX и, скажем, Hyper-V, на ESX будет использоваться на 30% меньше памяти, что оставляет возможность запуска как минимум еще одной такой же машины. Эта технология особенно эффективно себя покажет на фермах с большим количество идентичных машин, таких как инфраструктура VDI.
2) ESX хост с 16GB оперативной памяти, запущено 14 машин (WinXP, Win2003, RHEL) с разным набором софта.
Memory Granted: 19000 MB (всего выделено)
Memory Shared Common: 634MB (объем найденных общих страниц памяти)
Memory Shared: 9400MB (суммарный объем найденных общих страниц памяти)
Memory Usage: 10500MB (65%)
Сами считайте уровень загрузки хоста по памяти без transparent page sharing.

Насколько мне известно, обе фишки уникальны для ESX среди остальных гипервизоров (transparent page sharing точно, но я не уверен насчет memory overcommitment) и не требуют дополнительного лицензирования. Т.е. Вы всегда их получаете, даже в случае бесплатного ESXi.

Немного финансовых соображений.
Указанный выше сервер - HP BL460c с двумя 4хядерными Xeon. Коэффициенты загрузки 5.75% CPU, 65% Memory. Иными словами, по процессорам я могу вообще не бояться - не нагружу, а коэффициент консолидации (соотношение виртуальных серверов к физическим хостам) ограничен лишь объемом физической памяти.
VMware VI Enterprise лицензируется по процессорным сокетам и стоит примерно 7k$ / 2 CPU.
С учетом одного лишь Transparent Page Sharing на сервере с 16GB памяти мы спокойно запустили нагрузку, требующую 24 GB памяти. Т.е. смело можем записывать в экономию 8GB памяти, а это порядка 610/1150$ (2*4GB или 1*8GB модули). Т.е. уже и не 7k$, а 6k$ :)
Впрочем, если подумать, то один процессор при данной нагрузке можно смело вынуть и стоимость лицензии будет уже не 7-1k$, а 3.5-1 = 2.5k$ на сервер при ожидаемой 12-13% загрузке CPU. Если же физической памяти на сервере будет не 16, а побольше, то в определенных условиях может оказаться, что лицензия VMware нам достанется вообще бесплатно :)

Hyper-V и высокая доступность

Решение Hyper-V высокой доступности не требует покупки лицензии на саму эту функциональность, как, скажем, VMware HA. Но реализуется при помощи Failover Clustering, входящего в состав Windows Server 2008 Enterprise и Datacenter.
И вот парадокс, вроде бы Hyper-V бесплатен, но Hyper-V сам по себе средство виртуализации первого поколения - "Консолидация серверов". Как только требуется что-то большее, мы сталкиваемся, что у VMware не такие уж и дорогие продукты, у все остальных цены вполне сравнимы. В случае же Microsoft цены вполне сравнимы, а вот продукт пока сиииильно не дотягивает.

Совсем недавно Microsoft сняла ограничения по Quick Migration, а именно "1 VM = 1 LUN". Теперь можно размещать несколько VM на 1 LUN. Но к чему это приводит? Лишь к увеличению простоя "высокодоступных" серверов. Ввиду того, что Microsoft до сих пор не имеет кластерной файловой системы, при начале процесса Quick Migration замораживаться и переноситься будут ВСЕ VM, расположенные на этом LUN. Т.е. вместо 30 заявленных секунд при 10 машинах мы получим 300 секунд. Данная ситуация уже вызывает вопрос: а зачем Quick Migration? Может проще машины выключить, и включить уже на дргуом хосте? Но где здесь высокая доступность?

Относительно Live Migration, заявленного на 2010 год в комплекте 2008 R2: на текущий момент представители Microsoft совершенно не стесняются заявлять - да оно вам не надо. Господа, позвольте, но я представитель конечного пользователя и заявляю - оно надо! На каком основании вы мне рассказываете сказки?
Да, есть ситуации, когда Live Migration, оно же VMotion в терминологии VMware, действительно не нужно. Обычно, правда, там и High Availability тоже не требуется. Но это, извините, сегмент малого бизнеса. У Hyper-V еще нос по факту не дорос до Enterprise решений, и первые шажки он будет делать в 2010 году.

Вчера был на TechDays, но так и не увидел работу Failover Clustering. При выключении физического хоста машина так и осталась в дауне, без каких-либо признаков жизни. Впрочем, почти ни одна презентация вчера так и получилась у представителей Microsoft. Не буду придумывать причины, но показательно ведь.

Невозможность создать VMFS Datastore

Бывает, при переключении уже использовавшихся где-то LUN'ов на дисковом массиве к ESX'ам возникает ошибка: "Unable to read partition information from this disk"

Решение:
[root@esx2 root]# esxcfg-vmhbadevs
vmhba0:0:0 /dev/cciss/c0d0
vmhba1:0:1 /dev/sda
...
vmhba2:2:13 /dev/sdt

[root@esx2 root]# fdisk /dev/sdt

Command (m for help): o
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


The number of cylinders for this disk is set to 36643.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Теперь можно создавать VMFS Datastore.

Бездисковый ESXi и HA

При попытке включения HA на бездисковом ESXi (который на флэшке), выдается ошибка "Host in HA Cluster must have userworld swap enabled".

Решение: установить параметр Configuration / Advanced Settings / ScratchConfig / ScratchConfig.ConfiguredScratchLocation
Следует указать путь до datastore, открытого на запись. Т.е. нечто вроде /vmfs/volumes/4815cfef-9846d1c6-3a4b-001b783137c8, и перезагрузить хост.

Там появится файлик uwswap. В случае нескольких хостов разумнее будет создать на datastore директорию для таких файлов, причем у каждого хоста директория должна быть уникальна. Т.е. /swap/host1, /swap/host2

Грабли с Virtual Center - не получается залогиниться

Проблема: свежеподнятый домен, розданы permissions, а человек не может залогиниться для работы на VirtualCenter.

Резюме: для успешного логина необходимо, чтобы не стояло "сменить пароль при следующем входе" для пользователя.

Грабли с ESXi Embedded

Есть ESXi на флэшке - был воткнут в один сервер, а потом в другой. А серверы соотв. воткнуты в разные коммутаторы. И начались проблемы. Сеть на том сервере, в который была флэшка воткнута сначала - не работает. И точка.
Проверяем с Cisco-водом - MAC адреса первого сервера каким-то образом оказались на втором по отчету коммутатора. А такое просто невозможно, поскольку там сетевые карты даже разных производителей. Гашу второй сервер - на первом сеть появляется и ходят пинги. Поднимаю - пропадает. В настройках сети на втором сервере MAC показываются правильные.

Резюме проблемы: при первом запуске ESXi съедает MAC адреса сервера и больше не интересуется железом, соотв. физические адаптеры он использует в качестве дырок в сеть, а вот пакеты и все остальное, формирует сам - со старыми MAC'ами. В итоге коммутаторам сносит крышу. Если требуется перенести ESXi на другой сервер, то производится страшное колдунство: сетевые интерфейсы в management network поочередно гасятся и поднимаются с сохранением настроек. Тогда ESXi съест новые адреса и будет жить долго и счастливо.

Особенности раздачи permission в VMware VI

Ситуация.
Есть два кластера ESX-серверов. Есть человек с правами Virtual Machine Administrator на одном из кластеров. Новые виртуалки создаются от его лица без проблем, а вот клонировать или развернуть из шаблона не получается. При выборе Datastore возникает исключение "No permission".

Решение.
Создается роль "Browse Datastore" и применяется к "Main" БЕЗ наследования (Propagate = off).

Виртуальность от Sun

Вчера вышел долгожданный Sun xVM Server.

Bare-metal гипервизор с очень серьзной заявленной функциональностью. Поддерживается DRS, HA и VMotion в терминах VMware. Интегрируется в xVM Ops Center для управления инфраструктурой. Все очень неплохо, но...
1. Работает только на x86 процессорах с аппаратной виртуализацией.
2. Пока поддерживается только RHEL 4.6/5.2, Windows 2003/2008 и, разумеется, Solaris в качестве гостевых ОС.
3. Просто так для попробовать его не скачаешь.

Но это в любом случае хороший удар по светлому будущему MS Hyper-V.

Для SPARC у Sun есть два решения: Solaris Containers и Logical Domains. О контейнерах расскажу позже, а вот LDoms ну очень сильно напоминают по архитектуре VMware ESX, с той лишь разницей, что работают поверх ОС. Но вот ничего аналогичного VI клиенту у Sun для LDoms нет, и необходимость конфигурирования всего этого счастья из командной строки как минимум сильно удручает.

Microsoft и Live Migration

Microsoft, как обычно, жжот. И все больше тряпки.

Только что они показали Live Migration, причем каким-то очень странным образом доказали, что это действительно Live. И сразу же отложили релиз на 2 года, до 2010.

Еще забавнее то, что Microsoft по странной совершенно прихоти относит Live Migration, оно же VMotion к разряду High Availability, решений высокой доступности. Что, собственно, заставляет задуматься - какую траву там курят?
High Availabity (HA) - решения, минимизирующие незапланированное время простоя. Т.е. сбой физического сервера, его неожиданное отключение. И к этому VMotion не имеет ровным счетом никакого отношения попросту потому что это решение для минимизации и, в некоторых случаях, вообще ликвидации запланированного простоя для технического обслуживания.

Напомню, что Microsoft не предоставляет кластерной файловой системы для общего хранилища, такую как VMFS у VMware. И по причинам марктетинговой гордости не собирается ее покупать на стороне. В результате мы имеем ситуацию, когда для каждой виртуальной машины необходимо нарезать отдельный LUN для монопольного доступа. Правда интересное решение, особенно в случае с большими VDI фермами в сотни и тысячи виртуальных десктопов? :)

Express патчи выпущены!

Экспресс-патчи для ESX(i)3.5u2 готовы!

http://www.vmware.com/go/esxexpresspatches

Черный вторник для ESX 3.5u2

Сегодня я обнаружил, что не могу включить виртуальную машину. Internal error, и все тут!

Так что же случилось: 12 августа должна была "заэкспайриться" бета для ESX 3.5u2, и в финальной версии просто забыли убрать этот код. Не тратьте свои силы на поиск проблем и workaround'ов, все уже точно известно.

VMware пообещала через несколько часов выпустить соответствующий патч. Если же ждать нет возможности, то включить машину можно, если перевести часы на ESX-сервере назад, чтобы дата была до 12 августа.

Комьюнити полны возмущенных "это подорвало мою веру в VMware" и тому подобных комментариев. Бывает, что же делать... Такова специфика софтварных компаний. Да и Intel, как мы помним, выпускала процессоры с аппаратными проблемами. А сейчас еще и усугубляется положение гонкой вендоров за захват рынка виртуализации. У VMware хотят всеми силами оттяпать побольше кусочек от 70% рынка - времени на тщательное тестирование становится все меньше, а каждая новая функция несет новый код и новые проблемы и баги.

Мораль: не ставьте никогда новые релизы на production. Эта истина умыта потом красноглазых сисадминов, восстанавливаших работу систем бессонными ночами.

Oracle VM templates и VMware VI

Oracle выпустила официальные свободно доступные шаблоны виртуальных машин с Oracle DB в формате Oracle VM. Разумеется, как пройти мимо?
Шаблоны эти по сути всего лишь виртуальные диски в формате img (Xen). За 10 минут гугления было найдено руководство по конвертированию виртуальных машин из формата VMware в Oracle VM. Т.е. нам нужно сделать то же самое, только в обратном порядке.

Скачал, распаковал файл .tar.bz2 в .img. Конвертировать диски можно при помощи пакета qemu.

#qemu-img convert -f raw oracle10g_x86.img -O vmdk oracle10g_x86.vmdk

Заливаю свеженький vmdk, который кстати упаковался с 15ГБ raw до всего 4, на datastore. Добавляю в виртуальную машину диск. Ан нет, не добавляется - это ide диск. IDE HDD в под ESX не поддерживаются. Впрочем, как выяснилось, даже IDE->SCSI конверсия (поменять adaptertype) не поможет, внутренняя разбивка диска под lvm с привязкой к разделам hd*. Подключение к Workstation как IDE Тоже не спасло положения, таблица разделов не видна.

Будет время и железо - поставлю Oracle VM, опишу впечатления.

Ограничения лицензии VDI

Согласно информации от VMware, ограничения лицензии VDI - это все-таки "fair use".

Иными словами, если вы загрузите ESX под лицензией VDI серверными задачами - технически никто и ничто вам не помешает. И нарушение условий лицензии будет целиком на вашей совести.

VDI - краткое введение

VDI - Virtual Desktop Infrastructure, надстройка над Virtual Infrastucture, позволяющая автоматизировать и оптимизировать управление виртуальными дескотопами. Содержательно и очень понятно, правда? :)
А теперь поясню. Виртуальная машина в Virtual Infrastucture, как правило, - сервер. Но что мешает нам делать десктопные машины, с Windows XP? Ничто, разумеется, не мешает. Но возникают сложности с управлением ордой виртуальных машин и несколько иными требованиями к таким машинам, чем к серверным. Вот именно решением этой задачи и занимается VDI.
VDI машина - это VM с установленной Windows XP, VMware Tools и VDM Agent, работающая на ESX сервере.

Из чего состоит VDI?
- VDM - Virtual Desktop Manager
- Virtual Center
- один или более ESX серверов
- VDI клиент

VDM - сервер авторизации клиентов и автоматического их распределения (connection broker) по требуемым виртуальным машинам. При этом совершенно не требуется знать куда и как подключаться, нужен лишь адрес VDM-сервера и логин. Все остальное сделает VDM.
При конфигурировании VDM мы указываем адрес и логин Virtual Center, далее общаются они сами по себе.

Чем же хорош именно VDI и в частности VDM, и чем нехорошо прямое подключение к виртуальным машинам на ESX'ах.
1) VDM - единая точка входа. Пользователям не надо знать ничего кроме адреса VDM и своего логина. Все изменения инфраструктуры за VDM никак не отразятся на процедуре подключения пользователей к своим машинам.
2) VDM можно вынести в DMZ для гостей.
3) VDI клиент инкапсулирует стандартное RDP подключение в SSL туннель.
4) VDM agent на виртуальной машине создает виртуальный USB хаб. А VDI клиент осуществляет редирект USB с клиентской машины на виртуальную. Поддерживаются любые USB 1.1 И USB 2.0 совместимые устройства.
5) VDM автоматизирует процесс создания и предоставления виртуальных десктопов согласно заданным правилам (об этом ниже).
И т.д...

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

1. Individual

Здесь все очень просто, login = vm. Конкретному логину в Active Directory (VDI очень тесно интегрируется с AD) сопоставляется конкретная виртуальная машина. Предпочтительно для единичных машин с индивидуальными настройками - администраторов, менеджеров.

2. Persistent Pool

Группе AD сопоставляется пул машин с расширенными настройками. Пример: группе Office поставили пул OfficePool с настройками 200-10-30. Что это значит? Из указанного при создании пула шаблона (vm template) незамедлительно создается 30 виртуальных машин OfficePool1..OfficePool30. Далее, при подключении каждого нового пользователя из группы Office VDM запоминает его и дает ему его личную машину OfficePool. И с этого момента данный пользователь всегда будет подключаться именно на эту машину, а все изменения, которые он совершит, будут сохраняться. При достижении границы в 20 подключившихся пользователей (30-10) триггер в 10 машин запаса сработает, и как только подключится 21й пользователь, запустится процесс создания из шаблона машины номер 31. Так, чтобы всегда оставалось 10 свободных машин, вплоть до границы в 200 машин, которую мы определили максимум для этого пула. Таким образом нам даже необязательно на 200 человек создавать 200 машин и тратить ресурсы впустую, все ресурсы будут использованы только когда в них возникнет необходимость. Целевая аудитория - массовое использование офисными работниками с постоянными рабочими местами.

3. Non-Persistent Pool

Выглядит примерно так же, как и Persistent, только с тем отличием, что все изменения на виртуальных машинах откатываются, а пары логин/машина не запоминаются. Т.е. при логине можно попасть на любую из виртуальных машин. Целевая аудитория - сотрудники без собственного рабочего места, например, колл-центры. Non-Persistent Pool целесообразно использовать с roaming profile.

Для экономии ресурсов все три вида машин могут выключаться либо замораживаться (suspend) при отключении пользователя. Либо оставаться в рабочем состоянии, в зависимости от потребностей и настроек.

Лицензирование VDI.

VDI лицензируется по количеству одновременных подключений к VDI машинам (виртуальным десктопам). При этом мы можем по лицензии VDI установить столько ESX серверов, сколько нам требуется для работы наших десктопов. Точнее говоря, количество ESX серверов никак не лимитируется. Более того, VDI лицензия дает ESX в комплектации Enterprise (HA+VMotion+DRS). Но, разумеется, ограничения есть: на ESX, лицензированном по VDI, запрещено исполнять серверные задачи (server workload). С одним исключением - VDM сервер на виртуальной машине. К сожалению, так и не удалось выяснить является ли это ограничение техническим и проверяется, либо в данном вопросе лицензия подразумевает принцип "fair use", полагаясь на совесть и честность конечного пользователя.

Возможные комплекты лицензий.

VDI Starter Kit
- VMware Virtual Desktop Manager
- 10 десктопов (одновременных подключений к десктопам)
- VMware Virtual Infrastructure 3, Enterprise Edition для VDI
- VirtualCenter Foundation (ограничение в 3 ESX сервера)

VDI Bundle
- VMware Virtual Desktop Manager
- 100 десктопов (одновременных подключений к десктопам)
- VMware Virtual Infrastructure 3, Enterprise Edition для VDI
- VirtualCenter

VDI Bundle Add-On
- VMware Virtual Desktop Manager
- 10 десктопов (одновременных подключений к десктопам)
- VMware Virtual Infrastructure 3, Enterprise Edition для VDI

При этом очень простая арифметика. Лицензия на 1 десктоп имеет базовую стоимость 150$. Умножаем на требуемое количество десктопов и добавляем стоимость поддержки. VDI, как и все остальные продукты VMware, продается только в комплекте с поддержкой.

VI 3.5u2 & HA

Столкнулся с интересной проблемой.

В HA кластере у меня 2 сервера с 2-мя сетевыми портами и 1 с 4-мя. VI 3.5u1 ругался на сервере с 4-мя, что не хватает избыточности портов сервис-консоли, хотя HA работал. Я добавил еще одну сервис-консоль на другой vSwitch, и все, предупредение исчезло. HA продолжил работу.

После обновления до 3.5u2 HA-агент на сервере с 4-мя портами отказывался работать категорически. После раскопок в логах было выяснено, что этот сервер имеет network that don't exist on cluster members. И указывался порт второй сервис консоли, работавший в сети Service Console 2. Удалил этот порт. HA-агент успешно запустился и никаких предупреждений о недостаточной избыточности сервис-консоли не появилось.

Virtual Infrastructure 3.5 update 2

При обновлении существующей Virtual Infrastructure до 3.5u2 возможна следующая проблема: некая программа dbtool.exe валится с unhandled exception и установка прерывается. Соотв. обновление не представляется возможным.

Это проблема с обновлением Update Manager. Лечится предварительным удалением Update Manager, а потом установкой.

Паравиртуализация в VMware VI

Novell в SUSE Linux Enterprise SP2 включила поддержку VMI - virtual machine interface, нового индустриального стандарта паравиртуализации. Иными словами, SLES10 SP2 будет иметь значительно меньше накладных расходов при работе в виртуальной машине. Также поддержка VMI была включена в ядра начиная с 2.6.21, поэтому любой Linux с ядром не ниже 2.6.21 будет получит ускорение. Для Enterpise уровня Linux обычно очень консервативен и новые ядра включаются в дистрибутивы очень редко и только проверенные, вылизанные и оттестированные со всех сторон, так что все новые "фишки", такие как VMI, необходимо инженерам вручную интегрировать в текущее ядро.

Включается в VMware VI это очень просто: VM / Edit settings / Options / Advanced - Paravirtualization.

Обращаю ваше внимание, что VMI паравиртуализация в VI работает только для 32-битных машин, 64-битная просто выругается и встанет на этапе загрузки.

Кстати, это серьезный аргумент при выборе дистрибутива Linux: RedHat или SUSE. RedHat однозначно не будет включать VMI в RHEL5, и до сих пор не определилась по вопросу включения поддержки VMI в RHEL6.

ESXi будет бесплатным

VMware собирается выпустить на следующей неделе ESXi 3.5 update 2, причем сделать его бесплатным.

• ESXi никак не будет ограничен в функциональности
• Тем, кто купил текущую версию ESXi напрямую в VMware Store, будет предложен возврат денег (rebate)
• ESX, как гипервизор + сервис-консоль, не будет прекращен и продолжит развиваться по крайней мере некоторое время
• Гипервизор для ESX и ESXi останется один и тот же
• VMware сервер не будет прекращен, поскольку VMware видит для него иную нишу, чем для ESXi

Как этот шаг VMware, гранда виртуализации для x86, отразится на рынке? Основным источником дохода для вендоров станет сфера управления серверами и виртуалками, автоматизации, интеграции и тому подобное. С учетом наличия у VMware полного спектра продуктов, некоторым игрокам на рынке станет очень нелегко. Помимо этого, VMware с продуктом класса Enterprise попросту ворвется на рынок решений для малых компаний, серьезно поколебав текущий расклад сил на нем.

ВМ и резервирование IP по DHCP

Иногда хочется, чтобы виртуальная машина получала один и тот же IP, а статически его прописывать на машине нет желания. Тогда приходит на помощь резервирование IP на DHCP сервере, чтобы этот адрес доставался всегда только это конкретной машине. Но DHCP требует MAC адрес для данной процедуры.
В VI клиенте у включенной машины MAC нельзя скопировать из соотв. поля - оно просто заблокировано только для чтения. Вместо ползания по VI клиенту, кликания мышкой и переписывания вручную можно вытащить MAC прямо из конфига виртуальной машины. Особенно это критично для десятков машин разом - стоит лишь набросать простой скриптик.

Открываем ssh сессию на ESX сервер

#cat /vmfs/volumes/DataStore/VirtualMachine/VirtualMachine.vmx | grep Address

ethernet0.generatedAddress = "00:50:56:b7:53:29"

Если сетевых карт несколько, то выведутся MAC адреса для всех карт

ESX и внешний syslog

Централизованный syslog сервер - вещь полезная в сети. И очень бы приятно было на нем и ESX серверы отслеживать.

1. Добавляем в /etc/syslog.conf ESX сервера:

*.* @syslog-ip

2. Перезапускаем syslogd:

#service syslog restart

3. Открываем исходящий порт на файрволле

#esxcfg-firewall -o 514,udp,out,syslog

4. Применяем изменения конфига файрволла:

#esxcfg-firewall -l

Windows XP и VMware ESX

Классическая проблема: инсталлятор Windows XP не видит жесткий диск


Проблема в том, что в стандартном дистрибутиве Windows XP отсутствуют драйверы для используемых VMware SCSI контроллеров - BusLogic и LSI Logic. Поэтому при установке нужно драйверы подсунуть на дискетке. Вот здесь архив (177 kB) с образами флоппи-дисков с драйверами.

Этапы установки:
1) Подмонтируем к машине загрузочный ISO с Windows и образ флоппи-диска с нужным нам драйвером, загружаемся с CD.

2)
Windows спрашивает - а не хотим ли мы установить дополнительные драйверы SCSI? Жмем F6 один раз.

3)

Здесь жмем S.

4) И соотв. выбираем драйвер в меню из одного пункта

5)
Теперь драйверы установлены (показан скриншот для BusLogic) и можно продолжать обычную установку XP.

Увеличение размера системного раздела Windows

Ограничение 1: увеличить раздел можно только если он на базовом, а не динамическом диске.
Ограничение 2: у машины должны отсутствовать снапшоты.

Путь решения:

1) Делаем резервную копию машины (или хотя бы системного диска)
2) Выключаем машину
3) В свойствах диска увеличиваем его размер средствами VMware (VM / Edit settings / Hard disk / New size)
4) В машине загружаемся с CD диска (iso) с Partition Magic или любым иным средством, нормально работающим с NTFS.
5) Увеличиваем размер системного раздела до нужного
6) Перезагрузка

Динамические диски поддерживают расширенную функциональность - spanning, RAID0, 1, 5, но загрузчик винды достаточно туп, чтобы рабтать с чем либо иным, кроме единичного раздела или зеркала. Абсолютное большинство же тулзов по работе с разделами не умеет работать с динамическими дисками.

Хотя вроде бы заявляется, что может помочь Paragon Partition Manager 9.0, но он платный и в доступе у меня отсутствует – потому ничего конкретного не скажу.

Кадровые перестановки в руководстве VMware

8 июля совет директоров VMware уволил соосновательницу и президента - Диану Грин (Diane Greene). Диану сразу же заместили ветераном из Microsoft, Полом Маритцем (Paul Maritz), совсем недавно перешедшим в EMC после приобретения его стартапа - Pi.

Фондовый рынок отреагировал крайне негативно, падением акций на 25%. Вдобавок, Cisco, инвестировавшая в VMware в прошлом году 150 M$, отозвала 78.

Сотрудникам VMware запрещено выступать и комментировать ситуацию. Тем не менее, virtualization.info получили неофициальное интервью от одного из сотрудников. Ключевая мысль, содержащаяся в нем, проста: "Назначать ветерана Miscrosoft руководителем компании, большинство сотрудников которой крайне негативно относятся к Microsoft - не самая лучшая идея, и воспринято будет не лучшим образом".
Если совет директоров так и не сможет успокоить сотрудников, то весьма вероятны массовые увольнения.

К слову, из 8 членов совета директоров VMware против увольнения Дианы Грин голосовали 2. Предствители Cisco и Intel, в то время как 6-ро из EMC единогласно за. Cisco и Intel - две компании, по слухам в последнее время крайне заинтересованные в приобретении VMware.

Выбор серверного оборудования для VMware ESX

Как ни странно, но платформа виртуальных машин работает на машинах физических. И здесь у начинающих виртуальных админов встает задача довольно непростая – как выбрать железо? Нет, понятно, что выбор очень сильно сокращен списком совместимости (HCL), но и там простор довольно широкий.

1. сетевых портов должно быть не менее 2х, причем от 2х сетевых карт. Лучше больше, и нормальная рабочая конфигурация, хотя и немножко экономная – это 2 2х-портовых карты. В виртуальном свитче рекомендуется по-возможности комбинировать порты от разных карт. Почему? Просто потому что одна может сгореть и очень вероятно, что сгорят все ее порты целиком, и у нас тогда останется еще одна.

Сетевая конфигурация в данном случае как best practice: 2 виртуальных свитча, на одном сервис-консоль и vmkernel, на втором виртуальные машины. На каждый свитч два сетевых порта, по одному от каждой физической сетевушки. Причем для свитча с консолью и vmkernel назначить использование следующим образом: для сервис-консоли активная NIC0, standby NIC1, а для vmkernel наоборот.

2. памяти должно быть много. Нет, даже не так. Памяти должно быть МНОГО! С учетом широкого распространения многоядерных процессоров, однопроцессорный хост сейчас может обслужить изрядное количество виртуальных машин, а все они хотят память. Из расчета 4 машины на ядро для 2-сокетного 4-ядерного сервера получается 32 машины, вот сами и считайте сколько нужно гигабайт.

3. с точки зрения резервирования 3 средних сервера лучше, чем 1 супер-зверь. Все иногда умирают, и в случае 3х серверов мы потеряем лишь треть ресурсов, в случае 2х – половину, а с одним супермонстром все сразу. И работа встанет.

4. 2 2х-ядерных или 1 4х-ядерный процессор? Или больше?

Вопрос о лицензировании достаточно простой: хотя VMware продает лицензии только по 2 процессора, разрешается их разбивать для односокетных серверов. По опыту эксплуатации виртуальных машин, собственному и почерпнутому на стороне – процессор для вас не будет лимитирующим фактором. Им станет ПАМЯТЬ.
Разумеется, если задачи у вас общего плана, а не чисто вычислительные, но эту специфику лучше знать вам, я высказываю общие соображения. Приводится зачастую аргумент, что в случае 2*2 у нас может сгореть процессор, и мы будем работать, а вот 1*4 - все, встанем. Встанем в любом случае, Hot-swap процессоров VMware и абсолютного большинство серверов пока не поддерживают, а вот лицензия на все те же 4ядра будет стоить вдвое дороже, посколько лицензируемся мы по сокетам. А что это значит в итоге? А в итоге получается, что при использовании 1*4 серверов мы сможем за те же деньги получить VI Enterprise с VMotion, DRS и т.д… В случае же 2*2 только VI Standard.


5. какие процессоры выбрать?

Ответ простой: если вы точно не знаете, что именно будете делать на этих серверах, то берите процессоры с бОльшей частотой и бОльшим кэшем. Т.е. для Intel Xeon 5x серия для общих задач будет лучше, чем 7x – у них выше частота. Если же вы знаете, что вам нужны именно 7x Xeon, и зачем они вам нужны, то текст явно не для вас.

6. стоечный сервер или блейд?

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

Итак, стоечные серверы HP.

- 1 сетевой порт iLO
- 1 порт сервис-консоли (лучше 2)
- 1 порт vmkernel (лучше 2, и/или 2 порта Fibre Channel). Причем еще лучше
2 VMotion и 2 IP Storage порта.
- 2 порта production

От 5 сетевых портов (минимум) до 7 сетевых и 2х FC портов на один (!) сервер. + ровно такое же количество портов на свитчах и такое же количество кабелей. А у нас ведь есть еще Virtual Center и VCB-Proxy. Согласен, их можно запустить и на виртуальных машинах при определенных условиях, но… Итого 3 порта VC, 3 порта VCB (+ 2 FC) и 3*5 портов ESX (+ 3*2 FC) = 21 Ethernet и 8 FC портов. Это в минимуме, а в хорошо резервированной конфигурации цифры другие: 3+3+3*9 = 33 Ethernet + 8 FC портов. И это лишь для 3х ESX серверов. Что делать, если их станет 5, 8, 10? В кабелях не запутаемся?

У блейдов свои проблемы, да. Кто-то говорит, что не хватает пропускной способности на определенных задачах, коммутаторы захлебываются, а в случае стоечных серверов просто коммутатор сменил на помощнее и вуаля. Решать вам.

Легкий iSCSI для ESX

Обнаружил, что в iSCSI Enterprise Target (ietd) наконец пофиксили проблему с монопольным доступом к таргету. Коротко - если к таргету кто-то уже подключился, то его даже было не видно остальным, не говоря уже о совместном использовании. Зачем это нужно? Коротко: для кластеров.
Конкретно сейчас поставил ietd 0.4.16, работает совместный доступ как минимум с 3х хостов. 

Дешевое решение для shared storage для, например, VMware ESX, если не хочется работать по nfs по какой-то причине. Опять же, для raw device mapping для виртуальной машины требуется в кластере ESX'ов.

На RHEL5 встало легко и беспроблемно, конфигурация заняла 1 минуту.

#make
#make install

#cat /etc/ietd.conf 

Target iqn.2001-04.com.example:storage.disk2.sys1.xyz
Lun 0 Path=/dev/sdb,Type=blockio

# service iscsi-target restart