воскресенье, 15 мая 2011 г.

VMworld 2011

Как вы, вполне вероятно, знаете, в конце августа должна состояться большая конференция VMware - VMworld.

В этом году ждать ее особенно интересно, так как ходят слухи про релиз vSphere 5 в тех же числах (хотя, если мне склероз не изменяет, релиз четверки откладывался чуть не год, так что все может быть).

А еще в этом году на VMworld может выступить многим знакомым Антон Жбанков - так что голосуем за его сессию! :-)

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


PCoIP Server Offload Card

Интересная штука - PCIe плата для аппаратного ускорения PCoIP, PCoIP Server Offload Card. С поддержкой VMware View начиная с версии 4.5, без ограничений к клиентам.

Обещают плаг-энд-плей, разве что после установки платы\плат в сервера потребуется поставить галочку "использовать аппаратное ускорение PCoIP".

Заявлено, что каждая плата поддерживает до 64 дисплеев в разрешении1920x1200, или до 32 с разрешением 2560x1600.

SSL certificates in VMware View environments

Если нужны свои ssl сертификаты для VMware View, краткая инструкция - SSL certificates in VMware View environments.

vCap - кепка + 10 ко всем параметрам

На прошлой неделе пришел бумажный сертификат VCAP DCA. Самый обычный, выглядит точно как сертификат VCP.

Так же, как к сертификату VCP, к нему полагается честная лицензия на VMware Workstation. Не очень круто, уж для Advanced Professional'ов можно было бы и на честный кейген разориться ;-).

Ну а мне еще обломилась модная кепочка, в стандартный комплект не входящая. VMware обязала своих инструкторов сдать этот тест до 31 марта. Как это не удивительно, но большинство забило\не успело. Поэтому дедлайн подвинули на лето, а успевших премировали кепкой :-)

Кстати, коллеги, кто собирается сдавать тест на VCP - получение бесплатной второй попытки:



Хотя актуальность сдачи сейчас VCP по четвертой версии vSphere под вопросом.

четверг, 12 мая 2011 г.

command-line cheat sheet

Углядел тут маленькую шпаргалку по командной строке для тех, кто собирается сдавать VCAP DCA - VMware VCAP-DCA exam command-line cheat sheet.
Впрочем, может быть полезно кому угодно.

вторник, 10 мая 2011 г.

esx2esxi?

Сегодня, в четвертой версии vSphere, присутствуют две версии гипервизора VMware - ESX и ESXi. Ваша компания использует какой-то один из них.

Завтра, в пятой версии, останется только ESXi.

VMware рекомендует использовать ESXi уже сейчас не только тем, кто только начинает разворачивать vSphere, но и уже живущим с ESX - т.е. мигрировать с ESX на ESXi

Хотя у VMware есть документы, книги, онлайн и оффлайн курсы по этому делу - миграция, обычно, штука не сложная. См. картинку:

Ситуация сложнее в случае если используются продукты, интегрирующиеся в всферу. Этими продуктами могут быть как продукты, поддерживающие оба гипервизора, так и только ESX.

В первом случае, например при использовании vShield или Nexus1000v, просто чуть больше работы при миграции.

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

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

Нет, правда, зачем? Вернее, причины-то можно найти, я вижу основными узкоспециализированность ESXi и (возможно!) более простую миграцию на vSphere 5.

А вот оправданно ли затевать миграцию нормально работающей инфраструктуры ради не совсем конкре ной выгоды - я не уверен. Первую заповедь админа никто не отменял ;-).




Project “Lightning”

В посте Understanding Project “Lightning”, про перспективы использования твердотельных накопителей в EMC, углядел полезную картинку:

сам пост посвящен, в первую очередь, анонсу решения, представляющего из себя распределенный кеш на ssd, притом распределенный и между серверами, и между СХД.

среда, 4 мая 2011 г.

Monitoring vSphere

На официальном форуме как-то появилась ветка Чем глобально мониторить почти сотню esx(i), и в ней я углядел ссылку на обзор нескольких средств мониторинга - Обзор основных продуктов мониторинга.

Заслуживает внимания, имхо.



- пост с мобильного устройства, сорри за краткость и опечатки.

вторник, 3 мая 2011 г.

vm4.ru/view

Blogger тут прикрутил новую фичу - если к адресу блога приписать /view , то блог начнет отображаться в одном из нескольких новых вариантах отображения, с возможностью выбора.

Возможно, они будут вам более удобны, скорее всего дефолтный вариант Sidebar
http://www.vm4.ru/view/sidebar:


Transparent memory page sharing, vdi, large pages

Как вы, должно быть, знаете, у ESX(i) есть несколько технологий для повышения эффктивности использования памяти. (если кто не до конца в теме см. тут - Memory management).

Одна из технологий - Transparent memory page sharing, дедупликация оперативной памяти.
Гипервизор подсчитывает контрольную сумму страниц памяти виртуальных машин, находит одинаковые - и одинаковые страницы разных виртуалок в реальной оперативной памяти адресует в единственную копию.



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

Однако вот тут - Increase VDI consolidation ratio with TPS tuning on ESX - описывается мнение что для VDI имеет смысл уменьшить частоту сканирования (с 60 до 10 минут). И довольно внушающая аргументация - часто много виртуальных рабочих станций одновременно включается, примерно в одно время на них начинают и заканчивают работать пользователи, часто в одно время случаются пики из за старта антивирусов и другого ПО. Если сканирование памяти будет быстрее отлавливать эти массовые изменения - экономия будет более эффективной.

Это первая часть поста.

Однако, есть нюанс касательно page sharing в целом, актуальный и для VDI при использовании Windows 7 - Large Pages.

Современные серверы позволяют операционным системам использовать большие страницы памяти (Large Pages). Операционные системы могу адресовать память страницами по два мегабайта, а не по четыре килобайта.
Это значительно сокращает размер таблицы адресов страниц, ускоряя работу с памятью когда этой памяти много. Обычно говорят о 10-20% повышении эффективности (см. Large Page Performance.)

Интересно, что сам ESX(i) вроде как поддерживает работу с большими страницами, и старается их использовать для памяти даже тех гостей, что сами по себе их использовать не обучены. (в том смысле что cам ESX(i) использует большие страницы для той памяти, что он выделил этому гостю, а сам гость работает по старинке "внутри" выделенного куска памяти). Правда, непонятно как это влияет на эффективность TPS.

Однако при использовании Large Pages эффективность дедупликации начинает уменьшаться, и очень значительно - найти абсолютно идентичные 2 мегабайта намного сложнее, чем идентичные 4 килобайта (см. немного подробнее на русском тут - Продолжаем говорить о памяти – Page Sharing).

Интересно, что при недостатке свободной ОЗУ на сервере ESX(i) начинает сам разбивать большие страницы на маленькие 4хкилобайтные, для возвращения эффективности Page Sharing.
(см. Transparent Page Sharing is not utilized under normal workloads on Nehalem based Xeon 5500 series CPUs.)


Известная мне теория гласит, что:
1) При использовании серверов на последней платформе (Nehalem у Intel и не знаю как называется у AMD), которые обладают поддержкой EPT\RVI
и при запуске современных ОС, умеющих работать с большими страницами

эти большие страницы используются, что приводит к околонулевой эффективности Page Sharing (исключая пустые страницы памяти, если они есть).

2) Можно отключить использование Large Pages.
Можно отключить  использование LP для всех ВМ хоста, при помощи настройки

Mem.AllocGuestLargePage to 0
Можно отключить использование LP для отдельной ВМ правкой ее конфига:
monitor_control.disable_mmu_largepages = TRUE

В этом  случае есть немалая вероятность что сервер начнет показывать, что свободной памяти стало больше - за счет дедупликации. Но может снизиться производительность. Однако, снижение производительности вероятно для ВМ с большим объемом ОЗУ (от 4 ГБ? от 8 ГБ?), и менее вероятно для ВМ с меньшими объемами.

Коллеги, если в теории я нигде не ошибся, остается тестировать ;-)