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

Проблемы переезда 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-менеджеров: для тех кто руководит, принимает решения и отвечает за результат.

www.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. у вас до сих пор не настроены бэкапы?

вторник, 18 ноября 2008 г.

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 нам достанется вообще бесплатно :)

пятница, 14 ноября 2008 г.

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