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, притом распределенный и между серверами, и между СХД.

Monitoring vSphere

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

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



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

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 ГБ?), и менее вероятно для ВМ с меньшими объемами.

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

cloud, vcloud, vcloud director, it-grad

Помните, я как-то упоминал про конкретный вариант "облаков" на основе VMware vCloud Director - cloud, vcloud, vcloud director, it-grad?
Серия постов на эту тему пополнилась.

Как приручить облака: примеры практического использования.

• Начало.
• Проблемы облаков.
• Первый созвон.

VMware Compliance Checker for vSphere

Один из важных типов документов VMware - это Security Hardering Guide, бест практис по безопасности.

Сегодня их три - для vSphere, View и vCloud Director.

Наличие такого документа - это хорошо. Прочесть его - познавательно, интересно, но, если жесткого требования к безопасности нет - многовато букв.

А вот воспользоваться средством автоматической проверки своей vSphere на соответствие бест практис, притом официальным средством - это намного проще и быстрее.

Так что рекомендую - VMware Compliance Checker for vSphere.
11 МБ, халява, устанавливается и работает быстро, требует лишь указать адрес и учетку для доступа на vSphere.

Windows 2008 as Storage for vSphere

Недавно мне попались на глаза два способа сделать сетевое хранилище из Windows Server 2008.

Во-первых - стал честно бесплатно доступен Microsoft iSCSI target.

• Устанавливаем его на Windows 2008 R2 Std\Ent\Datacenter 
• создаем "iSCSI Target" 
• добавляем "device" - им может быть только файл vhd
• указываем идентификаторы iSCSI инициаторов серверов ESX(i) на вкладке "iSCSI Initiators" в свойствах таргета.

Все, теперь данный Windows-сервер представляет из себя систему хранения iSCSI.

Во-вторых, на сайте xtravirt стала доступна инструкция по установке NFS службы - NFS Storage Configuration for vSphere using Windows 2008.

• Добавляем на Windows-сервер роль File Server, 
• затем роль AD Domain Services
• а еще мне потребовалось поднять домен - без этого Identity Management for UNIX ставится не стал. Можно ли заставить его завестись не поднимая домен я не разбирался.
• теперь создаем группу в AD, слегка меняем ее настройки по умлочанию
• и расшариваем по nfs требуемый каталог:

 Я опробовал оба варианта - с iSCSI target вообще проблем не было, nfs что-то нестабильно работал :( - при попытке мигрировать на него ВМ процесс долго висит и завершается ошибкой.
Может быть, что-то в моем стенде не так срослось.

VDI stress test

Из переписки:

Михаил, добрый день.

..

Если кратко, я создал некоторую утилиту (можно скачать с vdi-sizing.com), которая имитирует пользовательский workload и меряет время различных событий (старт приложений, создание rdp сессии и т.д.). Собственно идея не нова и используется в Login VSI (www.loginconsultants.com) и Microsoft Terminal Services Scalability (tbscript.exe из Windows 2003 resource kit). Мое решение, как мне кажется, работает проще и стабильнее.

 

 В общем-то все довольно просто: внутри ВМ устанавливается программка, которая ждет установления соединения с удаленным контроллером нагрузки (LoadMaster). после этого внутри ВМ начинается нагрузка (старт приложений, создание документов и т.д.). Сам контроллер (LoadMaster) стартует последовательно RDP сессии и устанавливает соединение с программкой внутри ВМ. Он же собирает всю статистику о временах операций (установление RDP соединения, старт приложений и т.д.). Т.е. вся эта система просто эмулирует нагрузку на сервер и попутно меряет user experience (время отклика).

каких-либо whitepapers с результатами пока нету (ну кроме примера полученных результатов http://vdi-sizing.com/documentation/benchmarking-overview) . была идея сравнить VDI решения от Citrix и VMware, если будет интерес со стороны коммьюнити - скорее всего сделаю.

Вообще, меня останавливает муторный процесс benchmark approval у vmware - без него, согласно их eula, нельзя публиковать результаты тестов производительности.

главное хочется понять насколько это интересно тем же системным интеграторам или администраторам (при выборе VDI решения). если интересно, то во-первых планируются измерения. ну а во-вторых, в зависимости от потребностей пользователей, есть примерный список фич, которые можно реализовать (есть здесь http://vdi-sizing.com/contacts)

ESXi 4.1 Scripted Installation

К вопросу об установке ESXi по сети и с файлом ответов, используя Windows Deployment Server в качестве сервера сетевой установки - ESXi 4.1 Scripted Installation.
.