понедельник, 30 августа 2010 г.

http://www.fstec.ru/ + vSphere

Внезапно:  vSphere получила сертификат ФСТЭК.

..
по результатам сертификационных испытаний, проведенных на основании решения Федеральной службы по техническому и экспортному контролю (ФСТЭК России) № 3046 от 29 апреля 2010 года, программный комплекс «VMware vSphere 4 в составе ESX 4.0 Update 1 и VMware vCenter Server 4.0 Update 1» в редакциях Essentials, Essentials Plus, Standard, Advanced, Enterprise, Enterprise Plus, является программным средством общего назначения со встроенными средствами защиты от несанкционированного доступа к информации, не содержащей сведения, составляющие государственную тайну. Решение соответствует требованиям руководящего документа «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации» (Гостехкомиссия России, 1992) по 5 классу защищенности и может использоваться при создании автоматизированных систем до класса защищенности 1Г включительно, а также для защиты информации в информационных системах персональных данных до 2 класса включительно при выполнении указаний по эксплуатации, приведенных в технических условиях ТУ 501190-0173-82487552-2010.

Полученный сертификат подтверждает безопасность программного комплекса VMware vSphere 4 при проектировании информационных систем на базе данного продукта в государственных учреждениях и организациях, занимающихся обработкой персональных данных в соответствии с требованиями Федерального закона Российской Федерации №152 — ФЗ «О персональных данных».
..
Сертификат соответствия действителен до 9 августа 2013 года.
..

четверг, 26 августа 2010 г.

VMware products

Очень, очень грамотный пост:

Часто, очень часто на форумах задают вопрос типа "а как в VMware можно?". В 85% случаев имеется в виду Workstation, в оставшихся 15 - Server. Но VMware делает помимо Workstation и Server еще целую кучу продуктов.

Решил написать краткий обзор, а что делает VMware, кроме Workstation?

подготовка к VCAP

Появился новый англоязычный блог, и его автор создает подборку материалов для подготовки к VCAP.

Сам блог – http://www.vfail.net/.

Упомянутые страницы на нем - http://www.vfail.net/vcap-dca/ и http://www.vfail.net/vcap-dcd-index/.

вторник, 24 августа 2010 г.

Современные возможности виртуализации

На хабре интересная статья - Современные возможности виртуализации.
Дается базовое понимание основных вещей.

из минусов - без конкретики (позиционируется как платформонезависимое), а реализации конкретных технологий автору знакомы в основном по open-source решениям, про vSphere некоторые фичи не указаны или есть к чему придраться.

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

понедельник, 23 августа 2010 г.

HA Advanced Options

Кластер VMware High Availability, HA — неплохая штука.

Однако есть еще к чему стремиться — меня, например, довольно сильно огорчает то, что он включает все ВМ с отказавшего сервера на каком-то одном другом. Кстати, одновременно могут быть включены до 32 виртуалок.

Последнее я узнал вот отсюда — Two new HA Advanced Settings — тут подсказывают пару интересных опций для HA кластера:

  • das.perHostConcurrentFailoversLimit
    как раз сколько максимум ВМ одновременно можно включать. Значение по умолчанию — 32.
  • das.sensorPollingFreq
    как часто осведомляться — не появилось ли включенных ВМ. ПО умолчанию — раз в 10 секунд. Корректными являются значения из диапазона 1-30.

Первоисточник этих параметров — документ VMware vCenter Server Performance and Best Practices for vSphere 4.1. И там указано, что тргать эти параметры лучше не надо.

шутка юмора

Intel купил McAfee.
по рассказам знающих тему все было вот так:
- Так. Нам нужен антивирус. Купите кто-нибудь McAfee.
Вечером:
- Босс, купили.
- Молодцы. Какую версию?
- Эээ... Версию?...
углядел на ixbt

воскресенье, 22 августа 2010 г.

vSphere 4.1 iSCSI Advanced Settings

Одной из тем для вялых холиворов является тема вида «Можно ли использовать iSCSI для виртуальных машин».

По моим наблюдениям, есть процент людей, свято верящих в «великий FibreChannel, и да не будет ничего другого», и есть процент людей (лично по моему опыту — не очень все таки большой), счастливо и с успехом использующих IP-СХД для инфраструктур размером в десяток хостов и десятки ВМ.

Я это к тому, что для тех, кто использует iSCSI, может оказаться полезным пост — vSphere 4.1 iSCSI Advanced Settings And Their Meanings.

подключение USB к ВМ

Оказывается, есть люди, которым неизвестно о появившейся в ESX(i) 4.1 возможности подключать к ВМ устройства USB, подключенные к серверу.

Так вот, есть такая возможность.

 

Чтобы ей воспользоваться:

1) подключить к серверу USB устройство

2) добавить в конфигурацию виртуальной машины USB Device, и на соответствующем шаге мастера указать устройство из п.1

3) PROFIT
(инструкцию с картинками можно глянуть тут - Поддержка USB в ESX/ESXi 4.1)

Обратите внимание:

1) Возможна живая миграция ВМ с подключенным USB устройством, притом устройство не отваливается(!).

2) Возможно подключение не только накопителей,  но и лицензионных ключей, ключей безопасности и др.

Например, см. вот - USB device passthrough & 3G \ 4G modem.

А еще вот - Список  официально поддерживаемых устройств.

blueprint по новым курсам

Как многие в курсе, вскоре должны появиться тесты для продвинутой сертификации VMware – VMware Certified Advanced Professional, по направлению дизайна (VCAP-DCD) и по направлению администрирования (VCAP-DCA).

По одному появился, а по второму обновился blueprint – официальный список тем для теста:

 

VMware Certified Advanced Professional Datacenter Administration

Тест на способность управлять большой и\или сложной виртуальной инфраструктурой.

Состоит из 40 лабораторных работ(!). 

Каждая лаба состоит из нескольких задач, оцениваемых независимо.

Проходной бал будет определен по данным бета-тестирования. То же самое касается времени на прохождение теста.

Язык теста – только английский.

 

      VMware Certified Advanced Professional Datacenter Design

      Тест на знания и способности создать сложное решение. Несколько площадок, большая инфраструктура.

      Тест содержит xx вопросов (так и написано :), видимо до 99 ;). Вопросы вида “multiple‐items, drag‐and‐drop items and design items using an in‐exam design tool”.

      Проходной бал будет определен по данным бета-тестирования. То же самое касается времени на прохождение теста.

      Язык теста – только английский.

      Auto Deploy

      Интересная штука:
      1) Идем сюда, скачиваем виртуальную машину под названием AutoDeploy (чуть более гигабайта размером).
      2) Импортируем ее к себе на vSphere.
      3) Включаем, выполняем минимальную настройку в локальной консоли.
      4) Включаем [предполагается физический] сервер, указываем загружаться по PXE.
      5) Видим такую картинку на его мониторе сервера из п.4:


      Виртуальная машина AutoDeploy – предварительная версия официального (!) сервера сетевой загрузки ESXi.

      Настройка

      Какие минимальные настройки нужны для выполнения этой самой сетевой загрузки:
      • на шаге 3 AutoDeploy следует подключить к сети из которой есть доступ к управляющей сети vSphere (в частности, к vCenter);
      • в составе AutoDeploy есть сервер DHCP. Если предполагается использовать его, а не внешнего DHCP сервера, то следует выполнить команду
        sudo deploy-cmd dhcpconfig
      • все, программа минимум выполнена.
      Конечно, для реального применения нужно будет настроить поболе –
      • указать vCenter (или несколько), в консоль которых следует добавить сервера, и в которых хранятся Host Profiles для применения
      • создать сами профили настроек
      • и всякое по мелочи
      Вот тут - VMware Auto Deploy Administrator's Guide - доступна документация, единственный документ всего на 30 страниц – так что там несложно.

      Факты:

      • AutoDeploy основан на vMA (внутри 64-битный Linux плюс всякий разный софт).
      • cодержит в себе необходимые службы для организации загрузки (DHCP, TFTP, NFS, HTTP и др.).
      • содержит базу соотношения MAC адресов серверов ESXi и профилей настроек, которые следует к каждому серверу применять.
      • содержит набор специальных команд для настройки – deploy-cmd. Управление текущей версий AutoDeploy только из командной строки.
      • для уникальной настройки каждого сервера ESXi используется механизм Host Profiles (доступен лишь в Enterprise Plus лицензии vSphere).
      Мой демостенд не позволяет запускать 64-битных гостей :(
      Мне пришлось загружать AutoDeploy на vSphere, а затем сразу экспортировать в VMware Workstation, где благополучно и запустилась. Напрямую в Workstation AutoDeploy импортироваться отказался.

      UPD. http://vmpress.blogspot.com/2010/10/vmware-auto-deploy.html

      VMware courses – какое обучение предлагает VMware

       

      Итак, информация по поводу изменения и обновления обучения VMware.

       

      ICM, Install Configure Manage — базовый курс. Ссылка.

      Он становится пятидневным, «по многочисленным просьбам слушателей». В нем будут рассматриваться дополнительные темы —

      • vCenter Linked Mode.
      • Host Profiles.
      • Distributed Power Management, DPM.
      • подробнее про HA.
      • Fault Tolerance.

      Самое, наверное, главное — основан этот пятидневный Install Configure Manage на новой версии 4.1.

      Прослушивание курса дает право на сдачу теста VCP.

       

      Fast Track. Ссылка.

      Курс Fast Track пропадает — читать его будут лишь до конца 2010 года. Fast Track это связка из 4х дневного Install Configure Manage + Manage Availability + Manage Scalability В новый 5ти дневный Install Configure Manage курс Manage Availability не входит, но темы достаточно сильно пересекаются для того, чтобы посетившему новый Install Configure Manage не требовалось посещать Manage Availability . Кроме, разве что, vCenter Heartbeat.

      Про Manage Scalability тоже самое.

      Однако, в Fast Track входит работа в командной строке vSphere CLI (в варианте vMA), и работа с vCenter Heartbeat. Так что де факто Fast Track представляет и будет представлять из себя интересный курс, на который имеет смысл идти вместо Install Configure Manage . Например. в случае если Install Configure Manage не читается в удобные даты, а Fast Track доступен.

      Прослушивание курса дает право на сдачу теста VCP.

       

      Troubleshooting. Ссылка.

      Курс по диагностике и решению проблем с vSphere. Особо интересен тем, чей опыт работы с vSphere невелик или ограничивается посещением базового курса Install Configure Manage.

      Прослушивание курса дает право на сдачу теста VCP.

       

      Manage Performance. Ссылка.

      Объясняются нюансы работы ESX(i) с ресурсами. Дается более полное понимание влияния настроек на производительность. Даются рекомендации.

       

      VMware vSphere: Design Workshop. Ссылка.

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

       

      vSphere: Manage and Design for Security. Ссылка.

      Три дня, посвященные тому, как правильно обезопасить инфраструктуру.
      Полезен тем, кого волнуют вопросы безопасности своей виртуальной инфраструктуры. Какие вопросы имеет смысл поднять? Все ли аспекты учтены? Даются рекомендации для безопасности vSphere от VMware. Работа с VMware vShield Zones.

       

      VMware vSphere Automation with vSphere PowerCLI. Ссылка.

      Двухдневный курс, посвященный применению PowerCLI. Это очень, очень мощное средство автоматизации (например. см. тут — PowerShell PowerCLI Onyx), и курс — хороший способ для вхождения в тему. Разбираются такие темы как:

      • Автоматизация настроек ESX(i)
      • Автоматизация развертывания виртуальных машин
      • Автоматизация внесения изменений в конфигурацию виртуальных машин
      • Автоматизация операций с кластерами
      • Автоматизация отчетности

       

      VMware vSphere: Transition to ESXi. Ссылка.

      VMware не раз уже объявляла о том, что четвертая версия — последняя, в которой присутствует большая версия ESX. В дальнейшем останется только ESXi.
      Таким образом, кто только начинает строить свою инфраструктуру — имеет смысл выбирать ESXi.
      А у кого она уже построена, и построена на ESX — может быть, имеет смысл мигрировать.

      Вот как эти два дела правильно сделать, говорится на этом курсе.
      В том смысле что для тех, кто с ESXi ранее не работал, даются те вещи, в которых он отличается от ESX.

       

      VMware vSphere: What’s new. Ссылка.

      Курс для тех, кто работал с третьей версией, но с четверкой еще нет. Акцент только на новшествах четверки. Этот курс — самый дешевый из тех, чье прослушивание дает право на сдачу теста VCP 4, для тех у кого есть звание VCP 3.

       

      Site Recovery Manager.Ссылка.

      Курс по первой версии SRM. В принципе, актуален и по сию пору, несмотря на то, что сегодня актуальна вторая версия SRM, имеющая номер «4».

      По последним данным, в дальних планах VMware передать этот курс в область вендоров СХД, так как SRM зависит от репликации данных СХД и соответствующего плагина для SRM — а эти компоненты поставляются не VMware.

      Вендоронезависимая версия курса по SRM 4 станет доступна в онлайне в течении какого-то времени. Будет ли эта версия полностью бесплатна, или будут ли какие-либо условия — пока неясно.

       

      VMware View: Install Configure Manage. Ссылка.

      Базовый курс по работе с VMware View 4. Три дня, вся необходимая информация по этому продукту.

       

      VMware View: Design. Ссылка.

      Курс по разработке решений VMware View. Основан на версии View 3 (курса дизайна по View 4 нет), но актуален до сих пор.

       

      Расписания курсов доступны тут.

      Задавать вопросы стоит мне.

      среда, 18 августа 2010 г.

      VCAP

      Есть мнение, что продвинутые сертификации VCAP станут доступны в сентябре.

      VMware Certified Advanced Professional Datacenter Administration (VCAP DCA) – 30 августа.

      VMware Certified Advanced Professional Datacenter Design (VCAP DCD) – 31 сентября.

      Для того, чтобы получить эти сертификации, требование только одно – быть VMware Certified Professional, VCP 4.

      Ну еще заплатить за тест.

      Вот с последним нам могут помочь:

      Для подготовки к VCAP-DCA рекомендуемыми являются курсы

      •    VMware vSphere: Troubleshooting
      •    VMware vSphere: Manage for Performance
      •    VMware vSphere: Manage and Design for Security (новинка, напишу о нем подробнее в ближайшее время)
      •    VMware vSphere: Automation with vSphere PowerCLI (новинка, напишу о нем подробнее в ближайшее время)

      Для подготовки к VCAP-DCD рекомендуемым является курс

      •    VMware vSphere: Design Workshop
      Так вот, если вы посетите один из этих курсов в промежутке от 1 сентября до 30 ноября, то вам дадут ваучер на 50% скидку на сдачу теста VCAP.

      Один ваучер дается на одну попытку сдачи любого VCAP теста, действителен он до 31 марта 2011.

      понедельник, 9 августа 2010 г.

      Linked Clones

      Есть такая хорошая штука — Linked Clones.

      Это — возможность запустить сразу несколько ВМ из одного файл-диска.

      Т.е. создаем одну ВМ, используем ее диск как мастер-диск, с которого стартует сразу несколько ВМ. Конечно, к мастер-диску они обращаются только на чтение, а пишет каждая в свою собственную дельту.

      Такая технология есть в VMware Workstation, вот скриншот одного из шагов мастера клонирования ВМ:

      image

      Такой технологии нет в vSphere. Однако, есть намек на нее: посмотрите на закладку Summary для виртуальной машины. Там есть интересный раздел Storage, и в нем три пункта:

      image

      Provisioning Storage — это «Максимальный объем которого может достичь эта ВМ». Этот размер вычисляется по формуле «номинальный размер диска ВМ + (номинальный размер диска ВМ )*(на число снапшотов) + (объем памяти)-(резерв памяти)».

      Used Storage — сколько места эта ВМ занимает де-факто.

      Not-shared Storage — вот это и есть намек на Linked Clones — если бы ВМ была создана как связанный клон, то тут отображался бы объем места, которое занимают ее файлы, минус размер мастер-образа, который она разделяет с другими ВМ.

      Почему вообще этот пункт присутствует в интерфейсе, если для vSphere Used Storage и Not-shared Storage всегда равны?

      Потому что Linked Clones можно реализовать вспомогательными средствами.

      Формально, их два — это продукты Lab Manager и VMware View.

      А вот тут — How to Create Linked Virtual Machines with vSphere API? — сообщают о варианте номер три — использовании VMware API. В частности, приводится код на Java, реализующий Linked Clones.

      VMDirectPath + VMotion

      Судя по статье № 1022851 в базе знаний VMware, теперь, в 4.1, возможна живая миграция виртуальной машины между серверами не только с подключенным USB устройством, но и с подключенным VMDirectPath.

      Вау, если это так.

      Коллеги, у кого железо поддерживает данную фичу — можете проверить, так ли это?

      Memory on demand.

      Интересный пост на хабре — виртуальная инфраструктура на Xen, и к ней прикручена схема выделения памяти для ВМ по запросу — Memory on demand.

      понедельник, 2 августа 2010 г.

      vmkfstools

      Офигенная история:

      Чувак игрался с утилитой командной строки vmkfstools – это утилита для работы с разделами VMFS и файлами vmdk.

      С ее помощью можно форматировать разделы в VMFS, и удалять разделы. Создавать, увеличивать, уменьшать тип файлов vmdk.

      Так вот, играясь с vmkfstools для ESX 4.1 он обнаружил новый параметр - --fix

      image

      Этот параметр запускает проверку файла vmdk, что следует делать после некорректного выключения.

      image

      Почитав man, чувак обноружил еще один параметр –miscop

      image

      Притом, этот параметр был в man vmkfstools, но его не было в vmkfstools –help.

      Данный факт навел на мысль – может быть, есть еще скрытые от общественности параметры?

      И таки да! После некоторых изысканий был получен список:

      • dumpfs
      • numfiles
      • force
      • recursivelock
      • recover (!!!)
      • vmfsscan
      • physicalmapping
      • logicalmapping
      • allocateblock
      • clearlazyzero
      • parseimage
      • createarro
      • createmirrordisks
      • createmultiextent
      • trackvdisk
      • activehosts

      Плохая новость – хз как всем этим пользоваться.

      Отсюда - vSphere 4.1 Is the Gift That Keeps On Giving.

      Memory management

      В полете из солнечной Москвы в прохладный Баку
      у меня появилось вдохновение для написания сего текста.
      Лично мне он понравился.
      Вот у нас есть сервер ESX(i), для простоты один. У его есть сколько-то оперативной памяти для виртуальных машин (“Доступная память”), и на нем работает сколько-то виртуальных машин. Этим виртуальным машинам выделено сколько-то памяти (“Показанная память” ), и они сколько-то этой памяти потребляют (“Потребляемая память” ). Что можно рассказать про это?


      Несколько общих слов


      Доступная память – это все гигабайты памяти сервера минус:
      1. Память, которую гипервизор тратит на себя. ESXi создает в памяти RAM диск для своей работы. ESX отрезает 300-800 мегабайт для Service Console. Виртуальным коммутаторам, iSCSI инициатору и прочим компонентам так же нужны ресурсы для своей работы.
      2. Память, которую гипервизор тратит для создания процесса виртуальной машины. Overhead, говоря в терминах счетчиков нагрузки. Когда мы создаем виртуалку и “показываем” ей гигабайт памяти, гипервизор ей выдает часть или 100% этого гигабайта. И даже в последнем случае еще 100-150 мегабайт тратит на оверхед.
      3. Еще HA может резервировать сколько-то памяти под свои нужды.
      Показанная память – это тот объем памяти, который мы указываем в настройках ВМ, на закладке Hardware. Именно этот объем видит гостевая ОС. Это максимум, который гостевая ОС может использовать. Однако, гипервизор может выделить для ВМ из реальной оперативки и меньший объем, чем “показал” ей памяти. То, что гостю выделено лишь, например, 400 мегабайт из показанного гигабайта изнутри не заметить.  По каким причинам гипервизор будет так подло поступать поговорим чуть позже.
      Потребляемая память – это сколько реальной оперативной памяти использует виртуальная машина. Или, правильнее сказать, какой объем памяти выделил ей гипервизор. В  терминах мониторинга это Consumed.


      Memory Overcomitment


      Все мы наслышаны про чудесный (без иронии) “Memory Overcomitment”. Что это? Это ситуация, когда “Показанная память” всех ВМ на сервере больше чем “Доступная память”. То есть мы “показали” нашим виртуальным машинам больше памяти, чем есть на сервере. Кстати говоря, и это важно, “Потребляемая память” в такой ситуации может быть как меньше (хороший случай), так и больше чем память “Доступная” (плохой случай).
      Иллюстрация “хорошего” случая:
      image
      Memory Overcomitment достигается на ESX(i) за счет нескольких технологий. Перечислим их:
      • выделение по запросу;
      • transparent memory page sharing:
      • balloon driver или его еще можно обозвать vmmemctl;
      • memory compression (новинка 4.1);
      • vmkernel swap.
      Что это? Каково место этих технологий? Насколько они офигенны? Насколько они бесполезны? Давайте поразмышляем.


      Вводная к размышлениям


      Мы будем рассуждать о потреблении памяти виртуальными машинами, а точнее – гостевыми ОС и приложениями.
      Основная идея в чем – “показанная” серверу (тут неважно – физическому или виртуальному) оперативная память никогда не загружена на 100%. Почему? У вас загружена именно так? Значит вы хреново спланировали этот сервер, согласны?

      Утверждение 1 – мы должны стремиться к тому. что виртуальные машины не должны все время потреблять 100% от “показанной” им памяти. Таким образом, прочие соображения я буду основывать на том, что у вас именно так. То, что некоторые задачи занимают чем-то всю свободную память – здесь не учитываем, так как разговор идет в общем.

      Утверждение 2 – в разное время суток\дни недели наши приложения потребляют память по разному. Большинство задач хотят ресурсов в рабочие часы в будни, с пиками утром или в середине дня или <подставьте данные своей статистики>. Однако бывают приложения с нетипичными для нашей инфраструктуры профилем потребления памяти.

      Утверждение 3 – в вашей инфраструктуре сделан запас по оперативной памяти серверов, то есть “доступной” памяти. Этот запас делается из следующих соображений:

      • архитектор боится промахнуться с необходимым объемом. промахнуться в смысле “продать меньше памяти чем потребуется”;
      • как запас на случай отказа сервера (или нескольких);
      • как запас на случай роста виртуальных машин или нагрузки на существующие виртуальные машины.

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

      • ВМ приложений – сколько памяти вы выделяете (“показываете” в моих определениях тут) своим серверам приложений? При опросах на курсах я слышу цифры 4-8, редко больше.  Вернее, для малого числа ВМ больше. Большинство таких приложений потребляет ресурсы в рабочие часы, однако бывают и исключения (например, сервера резервного копирования, работающие по ночам);
      • Инфраструктурные ВМ – всякие DNS, DC, и т.п. Обычно гигабайт или два. Потребляют ресурсов мало, пики если вообще есть – в рабочие часы;
      • Тестовые ВМ – думаю, гигабайт или два в среднем по больнице, и больше по требованию смотря что тестировать будем. Пики в рабочие часы, где-то бывает куча тестовых виртуалок, простаивающих подавляюще большую часть времени (как крайний случай – кто-то создал и забросил, а удалить виртуалку страшно – вдруг кому нужна).
      Давайте теперь рассмотрим эти группы виртуальных машин в контексте механизмов работы с памятью.


      Выделение по запросу


      То, чего нет у других. Ну или я не знаю что есть. (помните, пост про vDiva – “Вы считаете себя нереально крутым спецом по виртуализации, хотя ни разу в жизни не видели Xen, Hyper-V или KVM”).

      Как это работает
      Виртуальной машине выделили (“показали”) два гигабайта. Виртуальную машину включили. Что происходит дальше?
      Этап 1 – включение. Часто мне приходится слышать о том, что при старте гость забивает нулями всю память – уважаемые читатели, кто в теме просветите меня – так ли это на самом деле, мои изыскания привели к противоречивым выводам. Допустим это так – потому что это самый плохой случай – ведь гость на старте делает вид, что ему нужна вся “показанная” ему память. Ок, гипервизор ему всю выдает. Итак, на этапе 1 “потребляемая” память равна “показанной”, в самом плохом случае.
      Этап 2 – гость стартовал все службы, службы начали работать, создавать нагрузку. Но не сто процентов памяти потребляется, см. утверждение 1. Например, 1200 мегабайт из выделенных 2000. То есть гость 800 мегабайт пометил у себя в таблице памяти как “свободная”. По хорошему, гипервизору надо бы ее забрать. Он и забирает, для этого используется механизм balloon(!). Т.е. одна из задач балон-драйвера (подробности о нем см. ниже) – это отбирать ранее выданною, но сейчас ненужную гостю память. Итак, балон раздулся, затем сразу сдулся. Что получилось – гостю 1200 мегабайт нужно, поэтому они балоном или не отнялись, или сразу вернулись обратно. Но больше памяти гостю, обычно, не нужно – и он больше не просит. А раз не просит, гипервизор ему больше и не дает.

      Насколько часто это применяется к разным группам виртуальных машин
      Работает этот механизм всегда, когда виртуальная машина потребляет не 100% “показанной” памяти.  То есть всегда, кроме первых минут после включения и редких пиков, этот механизм работает, и заметно экономит нам память.
      Если виртуальная машина не потребляет всю память часто – механизм очень полезен. Для некоторых тестовых – 100% времени. Для производственных серверов – как минимум ночью. А если часть серверов нагружается в другое время суток чем оставшаяся часть – вообще шоколадно. Для инфраструктурных – иногда бОльшую часть времени.

      Эффект на производительность
      Если и есть негативный, то не должен быть большим.

      transparent memory page sharing


      Технология с самым сложно звучащим  названием.

      Как это работает
      Гипервизор считает контрольные суммы, хеши, страниц оперативной памяти. Находит одинаковые (для одной или нескольких виртуальных машин) страницы. И одинаковые страницы из разных “виртуальных таблиц памяти” адресует в одну единственную страницу в памяти реальной. Получается, на пустом месте гипервизор делает “потребляемую” память меньше чем она могла бы быть без данного механизма. Ну про “”на пустом месте” я конечно соврал  – гипервизор тратит ресурсы процессоров сервера на подсчет контрольных сумм. Но с учетом того, что, как правило, ресурсов процессора у нас дофига, этот обмен нам очень выгоден.
      Иллюстрация:
      image

      Насколько часто это применяется к разным группам виртуальных машин
      Сложный вопрос. Сложность во все более широко используемом механизме Large Pages. Если у вас Windows 7/2008 + Nehalem, и используются страницы памяти по 2 МБ, теория гласит что эффект от page sharing будет маленьким. Хотя в реальности там довольно сложный алгоритм:
      ESX(i) разбивает 2 МБ страницу на 4 КБ, считает их хеши, но не использует механизм page sharing пока памяти хватает. А вот если перестало хватать – перед тем как включать какой-то из механизмов подкачки начинает делать sharing этих маленьких 4 КБ кусков.
      Что говорит практика по эффективности и безболезненности такого подхода– у меня пока мнения не сложилось.
      А если у вас железо или софт постарее, или эти большие страницы принудительно отключены – эффект обычно офигенный.

      Эффект на производительность
      Именно производительность негативного эффекта не испытывает. Тем более что ESX(i) знает, что такое архитектура NUMA, и если сервер у нас этой архитектуры, то дедупликация страниц памяти идет внутри каждого одного  NUMA узла независимо, чтобы виртуалке не приходилось за отдельными, дедуплицированными страницами лазать в память другого процессора.
      Однако в теории накладные расходы имеют место быть – если какая-то ВМ хочет изменить разделяемую с другими страницу памяти, с помощью технологии Copy-on-write делается копия страницы, которая и отдается приватно данной ВМ. Это медленнее, чем просто дать записать в неразделяемую страницу. Насколько заметен эффект в реальной жизни – сказать очень сложно.
      Официально данные вот какие:
      image
      За единицу выбраны данные тестов с отключенным page sharing. Как видно, средний столбец – со включенным page shring и параметрами по умолчанию, не хуже, а иногда лучше(!) по производительности.Улучшение связывают с тем, что memory footprint у виртуалки становится меньше, и лучше помещается в кэш (видимо, процессорный?).
      Крайние тесты – это число транзакций в секунду, компилирование ядра - время.


      UPD. от июня 2011 - отключение Large Pages позволяет сэкономить треть ОЗУ, есть такое мнение - TPS vs. Large Pages in real life.

      balloon driver / vmmemctl


      Самая радостная для русского уха технология.

      Как это работает
      Один из компонентов VMware tools – это драйвер устройства vmmemctl. По команде ESX(i) он начинает запрашивать у гостевой ОС память, так же как это делают приложения гостевой ОС. Т.е. этот драйвер раздувает тот самый “баллон” внутри, отнимая память у гостя.
      Зачем это надо? Для решения двух задач.
      Первая уже описана выше – если гостю были выделены страницы памяти, которые он уже перестал использовать, то гипервизор не может такие свободные страницы отличить и забрать. А раздувшемуся внутри “баллону” гость сам их отдаст в первую очередь, и затем не попросит у гипервизора их обратно. Страницы памяти, занятые “баллоном”, гипервизор отличит, и перестанет их адресовать для виртуальной машины, которой они были адресованы до сего момента. Посмотрите на иллюстрацию ниже – страницы памяти, гостем для себя помеченные как “свободные”, помечены звездочками слева. А справа, в следующем состоянии описываемого механизма, они уже не занимают железную память сервера.
      Иллюстрация:
       
      image
      Вторая задача – когда гостю выделено, например, два гигабайта, а один гигабайт из них надо отнять. Характерный пример – когда памяти сервера перестало хватать резко увеличившемуся числу виртуальных машин. А число их резко увеличилось из-за сбоя одного из серверов, и рестарта его ВМ на другом.
      Так вот, у ВМ надо отнять память. Гипервизор раздувает баллон, гость начинает свопировать (в свой собственный файл\раздел подкачки. То есть balloon – это способ гипервизору задействовать механизм подкачки гостя). Реальную память, теперь занятую баллоном(с точки зрения гостя), гипервизор отдает другой ВМ. Кстати, в моем примере гипервизор отдаст команду отнять гигабайт. А весь ли гигабайт баллон отнимет? Может быть, и не весь – гость вполне может отказать ему в памяти, если сочтет что другим компонентам память нужнее. Если баллон не справился, то гипервизор доотнимет оставшееся с помощью memory compression и vmkernel swap.

      Насколько часто это применяется к разным группам виртуальных машин
      Первая задача – отнимание незанятой памяти, стабильно актуальна для виртуальных машин любой группы.
      Вторая задача – мне видится мало актуальной. Давайте разберем ее слегка подробнее.
      Итак, из чего может взяться ситуация, когда у одной ВМ память надо отнять, чтобы отдать другой? Я вижу несколько вариантов:

      1. когда у нас memory overcommitment. и сразу у многих ВМ наступили пики нагрузки, что привело к загрузке сервера на 100%. Это, кстати говоря, причина пользоваться MO аккуратно. Впрочем, совсем отказываться от MO, как призывает нас делать Майкрософт, по моему мнению, тоже не стоит.
      2. когда у нас ломается один из серверов кластера HA. Например, у нас 10 серверов, все загружены по памяти(днем, в будни) процентов на 70. Вы знаете, что HA все упавшие ВМ перезапустит на одном из оставшихся серверов? Т.е. виртуалкам потребуется 140% его памяти.

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

        Далее ситуация разветвляется. Если у вас есть DRS, то он быстренько разнесет виртуалки по разным серверам, и баллону работать не придется.
        А вот если DRS нет, или он не в автоматическом режиме – вот тут мы приходим к нехватке на всех физической памяти. И гипервизор отнимет память у части машин с помощью баллона.
        У многих из вас нет DRS?
        У тех, у кого таки нет DRS – часто у вас ломаются серверы?
        Наконец, даже наличие баллона что означает – что запустятся все виртуалки, но всем будет хреново от нехватки памяти (правда, какие-то виртуальные машины могут “остаться на коне”, за счет опускания других ВМ в еще большее свопирование – см. такие настройки как reservation и shares).
      Отсюда вывод – наличие баллона это несомненный плюс для решения задачи один, но не панацея для решения задачи два.

      Эффект на производительность
      Для задачи один незаметный – отнимается только ненужная память.
      Для задачи два разный – см. далее.

      memory compression


      Новинка, этот механизм появился только в 4.1.

      Как это работает
      Гипервизор использует часть памяти под создание эдакого кэша. Теперь, когда встает задача два из описания баллона – впихнуть ВМ в меньший чем им хочется объем памяти, часть их памяти будет сжиматься и помещаться в ранее зарезервированную область.
      Идея в том, что сжать и записать данные в память , или прочитать и разжать – быстрее чем без сжатия читать или писать с диска, из файла подкачки.
      Иллюстрация:
      image
      Состояние “а” – надо выгрузить две страницы памяти из реальной оперативки.
      Состояние “b” – решение вопроса “по старинке”, свопированием.
      Состояние “с” – модерновое решение вопроса. Страницы сжаты и помещены в ранее зарезервированную область памяти сервера.
      Обратите внимание, что память под этот кэш не резервируется на сервере заранее – это часть памяти самой ВМ. Т.е. когда для ВМ перестает хватать памяти, гипервизор отнимает у нее еще немного, и в этом немного размещает сжатые страницы ее памяти.

      Насколько часто это применяется к разным группам виртуальных машин
      Редко – как я выше писал, при адекватном планировании и наличии DRS почти никогда.

      Эффект на производительность
      См. далее.

      vmkernel swap


      Последняя надежда.

      Как это работает
      При включении виртуальной машины гипервизор создает файл .vswp – файл подкачки vmkernel для этой ВМ.
      Теперь, когда гипервизору надо забрать часть памяти у виртуальной машины, он может просто из части страниц скопировать содержимое в данный файл, и перенаправлять обращения ВМ к памяти в файл. Гость ничего про это знать не будет.
      Будет ли гипервизор пользовать vmkernel swap, а не balloon или memory compression? См. ниже.

      Насколько часто это применяется к разным группам виртуальных машин
      См. описание второй задачи для баллона – отнять и поделить. Я думаю, что такая задача встает редко.
      Плюс vmkernel swap в том, что он работает всегда. Гипервизору нет дела ни до чего – ни до наличия vmware tools и vmmemctl в госте, ни до чего другого – задействовать vmkernel swap можно всегда.
      Минус – тормоза будут значительными.

      Эффект на производительность
      См. далее.

      Нехватка памяти на всех – какой механизм будет использован?


      У ESX(i) есть счетчик – процент свободной памяти.
      Его пороговые значения это 6% (high, типа все ок), 4% (soft, типа маловато осталось), 2% (hard, пипец как мало осталось, атас!), и 1%(low, все, приехали).
      • Free RAM>=6%. Пока свободной памяти остается не меньше 6 процентов (состояние high) задействуется только page sharing.
      • Free RAM<6%. Свободной памяти меньше чем хотелось бы. Начинаем использовать balloon.
      • Free RAM<4%. Свободной памяти мало. Используем еще и compression и vmk swap.
      • Free RAM<1%. Полный пипец. В доке вот что написано: “..в дополнение к balloon, swap и compression, гипервизор делает еще and additionally blocks the execution of all virtual machines that consume more memory than their target memory allocations”. Я пока не понял что это значит.
      Balloon и vmkernel swap и memory compression делают одну и ту же работу. Но ballon делает ее более оптимально – позволяет гостю самому выбрать что класть в своп. Данные тестов:
      image
      Крайняя правая позиция – когда из 512 мегабайт памяти у гостя оставалось только 128. Красная линия – скорость компиляции когда до 384 мегабайта памяти отнимается только balloon, зеленая – только vmkernel swap.
      Специфика компиляции в том, что самому процессу память особо не нужна – основной объем занят под кэш данных. Так вот, в случае balloon гость понимал, что в своп лучше положить сначала данные, чем ядро ОС. А в случае vmkernel swap такой выбор сделать нельзя, и в своп идет “что-то”.
      А вот данные при похожих условиях для базы данных Oracle, нагруженной соответствующей утилитой:
      image
      Обратите внимание – пока balloon отнимал меньше чем 1792 мегабайта из 3840, производительность практически не падала. Это опять же специфика приложения, но приложения характерного.
      А вот для каких-то приложений разницы не будет:
      image
      И в начальном диапазоне vmkernel swap даже меньше негатива оказывает на производительность ВМ. Впрочем, процент приложений вот так использующих память весьма мал. Здесь использовалась бенчмарка SPECjbb.
      А вот для Exchange разница кардинальна:
      image
      Если отнять 9 из 12 гигабайт памяти баллоном, то это даст удвоение latency, в то время как отнятие двух гигабайт из двенадцати при помощи vmkernel swap – утридцетитворение.

      Таким образом, если свопирование неизбежно, balloon это меньшее зло.
      Однако, еще разок замечу – по моему мнению, вам редко придется оказаться в ситуации, когда balloon будет работать из за нехватки памяти. И даже если такая ситуация случится, balloon даст снижение производительности, просто почти всегда меньшее снижение, чем использование vmkernel swap.
      А теперь сравним это еще и с compression:
      image
      image

      Вкратце – compression не панацея, но если уж памяти жестко не хватает, то с compression лучше чем без него (только с vmkernel swap, если быть точным). Нагрузка на процессоры увеличивается на 1-2%, что неощутимо.
      Все.

      P.S.

      За кадром остались limit, reservation и shares. Первым пользоваться для памяти не надо, вторым – лишь для самых требовательных к памяти ВМ, третьим – в двух словах не скажешь.
      Первоисточник картинок и данных тестирования - Understanding Memory Resource Management in VMware ESX 4.1.
      Я тут сделал несколько утверждений – буду рад комментариям.

      воскресенье, 1 августа 2010 г.

      MS support for MS Clusters + VMware vSphere

      Коллеги, практически первоисточник информации виртуализации в контексте Майкрософт, не только про Hyper-V сообщает -  Поддержка кластеров в виртуальных машинах VMware.

      Суть – VMware поддерживает продукты Майкрософт, в частности кластерную службу MSCS Windows Server 2003. Но конкретно эта поддержка значит “Мы обещаем, что работать будет так же, как на физическом железе”. Акцент тут вот на чем – “если глючит, но глючит так же как на физическом железе – с нашей т.зрения все ок, обращайтесь в поддержку Майкрософт”.
      А что говорит Майкрософт? Вот по ссылке и написано.

      Добавлю немного от себя:
      Каждый курс я опрашиваю слушателей про их отношения с поддержкой (это от пары десятков человек в месяц).
      И вот эта собственная статистика говорит мне о том, что в половине компаний куплен Premier Support, а половина пользуется лишь гуглом, и обращаться в поддержку не хочет\не умеет\не привыкла.
      Насколько понимаю я, в случае наличия Premier Support поддержка Майкрософт оказываться будет без оговорок?