Как многие из вас знают, в виртуальной инфраструктуре VMware vSphere некоторое количество программного обеспечения распространяется в виде виртуальных модулей (Virtual Appliances), представляющих собой готовые виртуальные машины с необходимыми сервисами внутри.

К ним, например, относятся следующие вспомогательные модули от самой VMware:

• vCenter Server Virtual Appliance 5.5 (VCVA) - главный сервер управления виртуальной инфраструктурой vSphere на базе ОС SUSE Linux.
• vCenter Orchestrator 5.5 (vCOva) - средство автоматизации операций для виртуальных машин и хост-серверов.
• vCenter Operations Manager 5.7.1 (vCOPs) - средство комплексного мониторинга и анализа виртуальной среды.
• vCenter Infrastructure Navigator 2.0 (VIN) - решение для автоматического обнаружения и визуализации компонентов приложений и зависимостей инфраструктуры.
• vCloud Automation Center Virtual Appliance 6.0 (vCACva) -  средство управления облачной инфраструктурой предприятия (SaaS, PaaS, IaaS) за счет единого решения, построенного поверх VMware vCloud Director.
• vCenter Management Assistant (vMA) - вынесенная "сервисная консоль" за пределы хост-серверов ESXi в отдельный виртуальный модуль, с которого удобно выполнять консольные команды RCLI (например, мониторинга - resxtop), а также хранить и запускать различные скрипты. 
• VMware Log Insight - централизованное средство сбора и анализа логов, о нем мы уже писали тут.
• Horizon Workspace Manager 1.5 (наша статья тут) -  средство автоматизации инфраструктуры виртуальных и физических ПК.
• vCloud Connector 2.5.1 (vCC) - средство миграции виртуальных машин на платформе VMware vSphere из частного облака предприятия в публичное хостинг-провайдера и обратно.

Все эти модули (а также и модули от сторонних производителей), будучи неотъемлемыми компонентами виртуальной среды, нуждаются в защите. Чтобы облегчить эту задачу пользователям, компания VMware выпустила документ "Hardened Virtual Appliance Operations Guide", в котором на 16 страницах вкратце рассказывают о том, как нужно защищать эти виртуальные модули в следующих контекстах:

• Root password - поставить нормальный пароль (сменить дефолтный!).
• Password Expiry - поставить нормальную политику устаревания паролей.
• Выполнить скрипт повышенной безопасности для параноиков (Dodscript.sh - сделан для Минобороны США). Там же написано про то, как поменять Security Banner (то есть скрин логина в консоль ESXi, на котором вывешено предупреждение об ответственности за несанкционированный доступ).
• Secure Shell, Administrative Accounts, and Console Access - использовать защищенный доступ к консоли виртуальных модулей.
• Time Sourcing and Synchronization - применять синхронизацию времени с доверенным источником.
• Log Forwarding – Syslog-ng and Auditd - перенаправлять собираемые логи на отдельный защищенный сервер.
• Boot Loader (Grub) Password - поставить пароль на загрузчик, исключающий также загрузку в Single user mode.
• Отключить сервисы NFS и NIS.

Начинание это, безусловно, является хорошим шагом со стороны VMware в плане обеспечения безопасности виртуальных модулей и инфраструктуры в целом. Но как-то маловато 16 страниц, вы не находите?

Для тех из вас, кто по причине отсутствия купленной подписки, лени или еще какой другой, использует старую версию платформы виртуализации VMware vSphere 5.1, компания VMware выпустила обновление VMware vCenter Server 5.1 Update 2.

Что нового в Update 2:

• vCenter Server 5.1 теперь поддерживается на платформе Windows Server 2012 R2.
• Возможность кастомизации нескольких дополнительных гостевых ОС через vCenter:
  • Windows 8.1
  • RHEL 6.4
  • Windows Server 2012 R2
  • SLES 11 Service Pack 3
• Добавлена поддержка СУБД Microsoft SQL Server 2012 Service Pack 1.
• Обновление протокола OpenSSL до версии openssl-0.9.8y.
• Исправления ошибок, которые можно найти вот тут.

Скачать VMware vCenter Server 5.1 Update 2 можно по этой ссылке.

Кроме этого, вышел также и VMware ESXi 5.1 Update 2, где почти ничего не изменилось:

• Появилась поддержка новых гостевых ОС (их список есть в VMware Compatibility Guide).
• Было исправлено несколько ошибок, список которых приведен вот тут.

Скачать VMware ESXi 5.1 Update 2 можно по этой ссылке.

Несколько недель назад компания VMware выпустила обновление ESXi 5.5.0 Driver Rollup 1, представляющее собой ISO-образ с самим ESXi 5.5 и дополнительными драйверами. Этот образ подходит только для чистой установки на хост и не поддерживает режим обновления (Upgrade).

VMware ESXi 5.5.0 Driver Rollup 1 содержит в себе драйверы IOVP certified drivers (IOVP  - I/O Vendor Partner Program), то есть драйверы от производителей, которые добавились или обновились с момента выхода ESXi 5.5.

Обновлены были драйверы оборудования следующих производителей:

• Broadcom
• Cisco
• Emulex
• Fusion-io
• HP
• Hitachi
• Intel
• LSI Corporation
• QLogic
• Virident Systems

Release Notes для ESXi 5.5.0 Driver Rollup 1 доступны по этой ссылке.

Мы уже немало писали про кластеры хранилищ VMware Virtual SAN (последнее - тут и тут), а сегодня рассмотрим механизм работы запросов на чтение блоков, который описал в своем блоге Duncan Epping.

Итак, схема кластера VMware Virtual SAN:

Здесь мы видим такую картину - виртуальная машина находится на хосте ESXi-01, а ее блоки размером 1 МБ размещаются на хранилищах разных хостов. При этом блоком 1 владеет ESXi-01, а блоком 2 - ESXi-03. Хост ESXi-02 не принимает участия в обработке запросов ввода-вывода.

Схема работы запроса на чтение проста - сначала проверяется наличие блока в кэше на чтение (Read cache), и если там блока не оказывается, то проверяется Write buffer на хранилище SSD (если блок еще не успел записаться на HDD) и непосредственно сам HDD-диск. В данном случае блок 1 нашелся на SSD-диске в кэше на чтение.

Второй же блок обслуживается хостом ESXi-03, но его не оказалось в кэше на чтение, и он читается с HDD-диска. Тут надо отметить, что кластер Virtual SAN помещает блоки в кэш на чтение только на тех хостах, которые активно обслуживают этот блок и владеют им, а те хосты, которые просто хранят копию данных - в Read cache таких блоков не помещают.

В небольших инсталляциях виртуальной инфраструктуры VMware vSphere может оказаться оправданным сделать один из серверов VMware ESXi сервером NTP, чтобы с ним синхронизировали свое время другие хосты.

Интересно, что немногие знают о том, что NTP-клиент сервера VMware ESXi 5.x (NTP-демон /sbin/ntpd) работает по-умолчанию не только как клиент, но и отдает время по запросу другим серверам как NTP-сервер. Поэтому достаточно лишь указать адрес хоста ESXi в качестве целевого хоста для синхронизации времени - и все будет работать.

Загвоздка тут одна - по умолчанию фаервол сервера ESXi блокирует входящие NTP-запросы по протоколу UDP на порт 123. Чтобы это исправить, нужно добавить собственное правило в сетевой экран. К сожалению, в Firewall GUI этой возможности не предусмотрено, поэтому придется лезть в конфиг-файл.

Для начала выведем список всех активных правил фаервола ESXi командой:

esxcli network firewall ruleset list

Создаем файл ntpd.xml с конфигурацией сервиса NTP со следующим содержимым (подробнее о процессе - тут):

<!-- Firewall configuration information for NTP Daemon -->
<ConfigRoot>
  <service>
      <id>NTP Daemon</id>
      <rule id='0000'>
          <direction>inbound</direction>
          <protocol>udp</protocol>
          <porttype>dst</porttype>
          <port>123</port>
      </rule>
      <enabled>false</enabled>
      <required>false</required>
  </service>
</ConfigRoot>

Далее кладем этот файл в папку на хосте ESXi /etc/vmware/firewall/ntpd.xml и выполняем команду:

esxcli network firewall refresh

После этого мы увидим новое правило в конфигурации сетевого экрана ESXi (в командной строке его можно проверить командой list, приведенной выше):

Однако, к сожалению, пользовательская конфигурация фаервола ESXi не сохраняется при перезагрузке хоста, о чем написано в KB 2007381. Поэтому можно просто положить ntpd.xml на общее хранилище и добавить в /etc/rc.local команду по копированию ntpd.xml в нужную папку хоста и комнду рефреша правил фаервола. Однако это ненадежно, поскольку зависит от доступности общего хранилища.

Поэтому, все-таки, лучше сделать это правило постоянным с помощью процедуры, описанной у Андреаса, заметка которого и стала основой этой статьи. Для этого нужно будет создать и установить VIB-пакет (как сделать это для любого случая описано в той же KB 2007381).

Ну а используя готовый пакет от Андреаса, можно установить созданный им VIB для добавления правила в фаервол для NTP-сервера:

esxcli software acceptance set --level CommunitySupported
esxcli software vib install -v http://files.v-front.de/fwenable-ntpd-1.2.0.x86_64.vib

Все это работает как для ESXi 5.0/5.1, так и для ESXi 5.5.

Мы уже много писали о технологии VMware Virtual SAN (VSAN), которая позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бетаэтого решения, кроме того мы не так давно писали о производительности VSAN тут.

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

Итак, в нормальном режиме функционирования, при значении параметра FailuresToTolerate равном 1, который означает, какое количество отказов хостов может пережить кластер хранилищ, реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно заметить 5 особенностей кластера VMware VSAN:

• Виртуальный диск VMDK и его реплика всегда находятся на разных хост-серверах VMware vSphere.
• ВМ не обязательно должна исполняться на том хосте ESXi, на дисках которого находятся ее хранилища.
• Компонент witness находится на третьем по отоношению к виртуальному диску и его реплике хосте, чтобы создать определенность на случай разделения сети VSAN (где окажется 2 компонента из набора "vmdk-реплика-witness" - тот сегмент и будет определяющим).
• Сеть VSAN используется для операций ввода-вывода и определения доступности.
• Реплика VMDK-диска вместе с основной копией образуют RAID-1 массив, который увеличивает производительность операций чтения в виртуальной машине, так как для чтения используются оба хранилища.

Кроме того, вследствие особенностей реализации кластера VSAN, надо понимать, что команды ввода-вывода не применяются к диску данных виртуальной машины, пока не пришло подтверждение об их записи на реплике. Но подтверждение приходит не от HDD-диска, где находятся данные ВМ (это было бы очень медленно), а от SSD-диска, который используется как энергонезависимый Write Buffer для команд ввода вывода. Таким образом, этот буфер (и данные, само собой) зеркалирован в рамках дисковой группы на другом хосте ESXi.

Теперь рассмотрим различные виды сбоев в кластере VSAN.

1. Ломается диск дисковой группы, где исполняется виртуальная машина.

Выглядит это так:

В этом случае такой диск сразу же помечается как "degraded", а команды ввода-вывода перенаправляются на другой хост-сервер VMware ESXi. При этом виртуальная машина этого не замечает, так как переключается на работу с SSD-буфером/кэшем и HDD-дисками другого хоста мгновенно (данные на момент сбоя были синхронизированы, ничего не потерялось).

Одновременно с этим сразу же начинается процесс построения реплики на другом хосте ESXi в рамках его дисковой группы, при этом проверяется, достаточно ли там свободных дисковых ресурсов. Если их недостаточно, то механизм VSAN будет ожидать. Как только вы добавите диски/дисковые группы на хостах - сразу же начнется процесс построения реплики (до его окончания машина будет помечена как "degraded").

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

2. Отказывает хост VMware ESXi целиком.

В этом случае запускать процесс восстановления сразу же, конечно, не нужно - мало ли что могло случиться с хостом, например, его случайно перезагрузили, или временно пропало сетевое соединение.

В этом случае происходит ожидание в течение 60 минут, и если отказавший хост ESXi не оживет, то начнется процесс создания реплики виртуального диска VMDK на другом хосте. Это время можно изменить в расширенной настройке кластера VSAN.ClomRepairDelay, но пока не известно будет ли это поддерживаться со стороны VMware.

3. Отказ SSD-диска в дисковой группе.

В кластере VMware Virtual SAN поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп.

В данном случае Failure Domain - это вся дисковая группа, включающая в себя SSD-диск, который используется для двух типов операций:

• Read Cache (70% емкости) - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering (30% емкости) - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Таким образом, при отказе SSD-диска, виртуальная машина начинает использовать реплику на уровне всей дисковой группы на другом хосте VMware ESXi. Вот почему выгодно делать две дисковых группы 3HDD+1SSD, чем одну  6HDD+1SSD.

Вот, в общем-то, и все. Более подробно об использовании SSD-дисков, их производительности и ресурсе можно прочитать вот в этой статье.

Мы очень много писали о том, как с помощью утилиты esxtop можно собирать с хостов VMware ESXi данные о производительности и различные метрики (например, тут и тут). Данные, полученные с помощью этой утилиты, очень часто помогают разобраться в источнике проблем в части вычислительных ресурсов, хранилищ и сетевого взаимодействия.

В этой заметке мы поговорим немного о визуализации данных esxtop. Не так давно мы писали об утилите VisualEsxtop, которая как раз тем самым и занимается - строит графики по наборам данных. Но недавно мы наткнулись на простой способ, позволяющий с помощью Windows Perfmon сравнивать наборы данных esxtop с разных хостов ESXi.

1. Итак, сначала нужно собрать данные с хоста ESXi в пакетном режиме в файл .csv. Например:

Здесь:

• -b - означает пакетный режим работы утилиты.
• -d (delay) - промежуток между срезами сбора данных.
• -n - число число таких срезов (сэмплов).

В данном случае будет собрано 360 сэмплов данных с промежутком в 10 секунд, то есть сбор займет 1 час.

Можно сжать результаты, чтобы экономить место на хосте, командой:

esxtop -b -d 10 -n 360 | gzip > esxtopresults.csv.gz

2. Загружаем данные в Windows Perfmon, выбрав источник - наш файл csv:

Визуализируем нужные счетчики:

3. Пробуем добавить еще один csv с другого хоста ESXi (с которым мы хотим сравнить данные первого хоста), но нам говорят, что так нельзя - можно такие файлы смотреть только по одному:

Не беда - сохраняем данные как бинарный файл с расширением *.blg, выбрав нужные счетчики:

Дальше просто удаляем этот файл из источников данных Perfmon, добавляем второй csv-файл и так же сохраняем его как *.blg.

Ну а дальше оба этих файла добавляем по одному - и все работает:

Добавляем сохраненные счетчики:

И данные с обоих хостов показываются на одном графике:

Источник заметки: www.viktorious.nl.

Не так давно мы уже писали про новые возможности технического релиза vGate R2 версии 2.6 - продукта, предназначенного для защиты виртуальных инфраструктур VMware. Там мы описали основные новые фичи решения, которое уже, кстати, доступно для загрузки в демо-версии, а в этой статье рассмотрим их подробнее, приведем несколько скриншотов и комментариев.

Многие администраторы и разработчики для своих целей используют VMware ESXi, работающий в виртуальной машине (так называемый Nested ESXi). Туда даже можно ставить свои VMware Tools.

При этом, когда требуется использовать виртуальные ESXi, как правило, их требуется несколько штук. Есть три способа получить их:

• Поставить заново и настроить - самый надежный, но долгий.
• Использовать процедуру автоматической установки и настройки Kickstart. Но тут надо знать, как это делается.
• Склонировать существующий экземпляр ESXi - самое простое решение, но сделать это нужно правильно.

Вильям Лам описал третий вариант процедуры подготовки ESXi к клонированию, после проведения которой можно развертывать эти инстансы легко и просто. В результате у новых ESXi будут свои MoRef ID, UUID, BIOS UUID и MAC-адреса.

Итак, что нужно сделать:

1. Смена MAC-адреса VMkernel при смене MAC-адреса сетевого интерфейса VM Network.

Если развертывать новый ESXi с новым MAC-адресом Virtual machine network, то необходимо также поменять MAC-адрес VMkernel. Для этого есть настройка FollowHardwareMac, которая позволяет делать это автоматически.

Для этого выполняем команду консоли ESXCLI:

esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1

2. Удаляем упоминание об UUID из esx.conf.

Запись о системном UUID сервера ESXi хранится в основном конфигурационном файле esx.conf (/etc/vmware/esx.conf). Нужно удалить строчку с упоминанием этого UUID - и тогда он сгенерируется при следующей загрузке.

После этого можно выключать ВМ с виртуальным VMware ESXi и клонировать ее. При загрузке новой ВМ, естественно, нужно поменять IP-адрес и прочую сетевую идентификацию.

В комментариях к заметке Вильяма пишут, что такой способ можно использовать для клонирования LUN, содержащего образ для загрузки ESXi по SAN.

Как многие знают, в VMware vSphere 5.5 появились возможности Virtual SAN, которые позволяют создать кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бета этого решения, кроме того мы не так давно писали о производительности VSAN тут и тут.

Сегодня же мы поговорим о том, как нужно сайзить хранилища Virtual SAN в VMware vSphere, а также немного затронем тему отказоустойчивости. Более детальную информацию можно найти в VMware Virtual SAN Design & Sizing Guide, а ниже мы расскажем о подходе к планированию хранилищ VSAN вкратце.

Объекты и компоненты Virtual SAN

Начнем с простого ограничения по объектам (objects) и компонентам (components), которое есть в VSAN. Виртуальные машины, развернутые на vsanDatastore, могут иметь 4 типа объектов:

• Домашняя директория виртуальной машины Virtual Machine ("namespace directory").
• Объект файла подкачки - swap object (для включенной ВМ).
• Виртуальный диск VMDK.
• Дельта-диски для снапшотов. Каждый дельта-диск - это отдельный объект.

Каждый объект, в зависимости от типа RAID, рождает некоторое количество компонентов. Например, один VMDK, размещенный на двух томах страйпа (RAID 0) рождает два объекта. Более подробно об этом написано вот тут.

Так вот, ограничения тут следующие:

• Максимальное число компонентов на 1 хост ESXi: 3000.
• Максимальное число компонентов для одного объекта: 64 (это включает в себя тома страйпов и также реплики VMDK с других хостов).

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

Сколько дисков потребуется для Virtual SAN

Во второй бета-версии VSAN (и, скорее всего, так будет в релизной версии) поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп. Таким образом, на хосте поддерживается до 5 SSD-дисков и до 35 HDD-дисков. Надо убедиться, что контроллеры хоста поддерживают необходимое количество дисков, а кроме того нужно проверить список совместимости VSAN HCL, который постоянно пополняется.

Также надо учитывать, что кластер хранилищ Virtual SAN поддерживает расширение как путем добавления новых дисков, так и посредством добавления новых хостов в кластер. На данный момент VMware поддерживает кластер хранилищ максимум из 8 узлов, что суммарно дает емкость в дисках в количестве 40 SSD (1*5*8) и 280 HDD (7*5*8).

Сколько дисковой емкости нужно для Virtual SAN (HDD-диски)

Необходимая емкость под размещение VMDK зависит от используемого параметра FailuresToTolerate (по умолчанию 1), который означает, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1, то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно сказать о том, как работает отказоустойчивость кластера Virtual SAN. Если отказывает хост, на котором нет виртуальной машины, а есть только VMDK или реплика, то виртуальная машина продолжает работу с основной или резервной копией хранилища. В этом случае начнется процесс реконструкции реплики, но не сразу - а через 60 минут, чтобы дать время на перезагрузки хоста (то есть если произошел не отказ, а плановая или внеплановая перезагрузка), а также на короткие окна обслуживания.

А вот если ломается хост, где исполняется ВМ - начинается процедура восстановления машины средствами VMware HA, который перезапускает ее на другом хосте, взаимодействуя при этом с Virtual SAN.

Более подробно этот процесс рассмотрен вот в этой статье и вот в этом видео:

Однако вернемся к требующейся нам емкости хранилищ. Итак, если мы поняли, что значит политика FailuresToTolerate (FTT), то требуемый объем хранилища для кластера Virtual SAN равняется:

Capacity = VMDK Size * (FTT + 1)

Что, в принципе, и так было очевидно.

Сколько дисковой емкости нужно для Virtual SAN (SSD-диски)

Теперь перейдем к SSD-дискам в кластере VSAN, которые, как известно, используются для вспомогательных целей и не хранят в себе данных виртуальных машин. А именно, вот для чего они нужны (более подробно об этом тут):

• Read Cache - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Так каковы же рекомендации VMware? Очень просты - под SSD кэш и буфер неплохо бы выделять 10% от емкости HDD-дисков хоста. Ну и не забываем про значение FailuresToTolerate (FTT), которое в соответствующее число раз увеличивает требования к емкости SSD.

Таким образом, необходимая емкость SSD-хранилищ равна:

Capacity = (VMDK Size * 0.1) * (FTT + 1)

Ну и напоследок рекомендуем отличнейший список статей на тему VMware Virtual SAN:

• VSAN Part 1 – A first look at VSAN
• VSAN Part 2 – What do you need to get started?
• VSAN Part 3 – It is not a Virtual Storage Appliance
• VSAN Part 4 – Understanding Objects and Components
• VSAN Part 5 – The role of VASA
• VSAN Part 6 – Manual or Automatic Mode
• VSAN Part 7 – Capabilities and VM Storage Policies
• VSAN Part 8 – The role of the SSD
• VSAN Part 9 – Host Failure Scenarios and vSphere HA interop
• VSAN Part 10 – Changing VM Storage Policy on-the-fly

То, о чем думали многие экспериментаторы и разработчики, но боялись попросить - на сайте проекта VMware Labs появились VMware Tools для виртуального VMware ESXi. Они поддерживают VMware vSphere версий 5.0, 5.1 и 5.5. 

Как многим стало понятно, это пакет ПО, предназначенный для установки в консоли сервера ESXi, когда он установлен в виртуальной машине, запущенной на уже физической платформе с ESXi (по аналогии с VMware Tools для виртуальных машин).

Вот какие возможности есть в VMware Tools for Nested ESXi:

• Предоставляет в консоли vSphere Client информацию о виртуальной машине с Nested ESXi (IP-адрес, имя хоста и прочее).
• Позволяет виртуальному ESXi быть правильно перезапущенным или выключенным (restart и shut down, соответственно) при операциях через vSphere Client (толстый клиент) или vSphere API.
• Возможность выполнения скриптов во время изменения хостом ESXi состояний питания (включение, выключение и т.п.).
• Поддержка Guest Operations API (бывший VIX API) для операций внутри ВМ (т.е. в консоли вложенного ESXi).

Порядок установки:

• Вариант 1 - скачиваем VIB-пакет, кладем его на датастор и ставим:

esxcli system maintenanceMode set -e true  esxcli software vib install -v /vmfs/volumes/[VMFS-VOLUME-NAME]/esx-tools-for-esxi-9.7.0-0.0.00000.i386.vib -f

esxcli system shutdown reboot -r "Installed VMware Tools" - See more at: http://www.virtuallyghetto.com/2013/11/w00t-vmware-tools-for-nested

esxi.html#sthash.f89qps1O.dpuf

• Вариант 2 - устанавливаем VIB прямо с сайта VMware:

esxcli network firewall ruleset set -e true -r httpClient 

esxcli software vib install -v http://download3.vmware.com/software/vmw-tools/esxi_tools_for_guests/esx-tools-for-esxi-9.7.0-0.0.00000.i386.vib -f

Далее нужно перезагрузить виртуальный VMware ESXi.

Чтобы удалить эти VMware Tools, используйте команду:

esxcli software vib remove -n esx-tools-for-esxi

С выходом обновленной версии платформы виртуализации VMware vSphere 5.5 компания VMware ввела новую модель Native Device Driver Architecture, которая позволяет использовать нативные драйверы для VMkernel вместо драйверов под Linux.

Однако, помимо этого нововведения, VMware также убрала и неофициальную поддержку многих SATA-контроллеров, которые раньше и не заявлялись как работающие, но вполне нормально функционировали на whitebox-конфигурациях (например, контроллеры ASMedia и Marvell). Теперь многие SATA-контроллеры в ESXi 5.5 просто не работают.

Но не все так плохо. Поскольку поддержка старой модели драйверов еще осталась (неизвестно будет ли она в следующей версии ESXi, но скорее всего будет, так как не все партнеры успеют перейти на новую модель), то можно заставить работать некоторые неподдерживаемые контроллеры SATA AHCI, поскольку сам драйвер AHCI остался в виде модуля VMkernel (ahci). Andreas Peetz не только написал хорошую статью о том, как это сделать, но и сделал кастомные VIB-пакеты для добавления поддержки некоторых SATA-контроллеров AHCI.

Суть такая - автор раньше думал, что команда vmkload_mod ahci заставляет ESXi загружать драйверы для всех обнаруженных PCI-устройств, то оказалось, что она конфигурирует только устройства, которые есть в файле /etc/vmware/driver.map.d/ahci.map. А там неподдерживаемых девайсов не появляется. Поэтому надо сделать отдельный map-файл и добавить ссылки соответствующих устройств (их PCI ID) на драйвер AHCI.

Андреас сделал VIB-пакет позволяющий добавить поддержку ESXi следующих SATA-контроллеров:

• ASMedia Technology Inc. ASM1061 SATA IDE Controller (1b21:0611)
• ASMedia Technology Inc. ASM1062 Serial ATA Controller (1b21:0612)
• Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (1b4b:9123)
• Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (1b4b:9172)

В каментах Андреас принимает заявки на добавление поддержки нужных SATA-контроллеров, так что если их в приведенном выше списке - пишите ему и он добавит.

Процедура добавления поддержки контроллеров такова. Добавляем возможность использования кастомных драйверов на ESXi:

esxcli software acceptance set --level=CommunitySupported

Разрешаем использование http на хосте в фаерволе:

esxcli network firewall ruleset set -e true -r httpClient

Устанавливаем VIB-пакет:

esxcli software vib install -v https://esxi-customizer.googlecode.com/files/sata-xahci-1.0-1.x86_64.vib

Пакет sata-xahci предоставляется как в виде VIB-файла, так и в виде Offline Bundle. Включить драйверы в состав установщика ESXi можно с помощью инструментов ESXi-Customizer или ESXi-Customizer-PS.

Те из вас, кто интересуется облачными технологиями, наверняка знают инициативу OpenStack, которая представляет собой комплекс проектов свободного программного обеспечения, предназначенного для построения облачной инфраструктуры.

Open Stack - это не продукт, не платформа и не фреймворк. Это некий набор "кирпичиков", с помощью которых может строиться инфраструктура облака, в том числе гетерогенная:

OpenStack называют еще облачной операционной системой, хотя, строго говоря, она таковой не является. Эту инициативу в той или иной степени поддерживают 150 компаний (это активных, а пассивных намного больше), хотя большинство архитектур OpenStack используют в качестве ОС Ubuntu (в 80% случаев), а в качестве гипервизора KVM.

Но поскольку основной целью OpenStack провозглашается открытость и вендоронезависимость при построении частного или публичного облака, то вы можете использовать в качестве гипервизора, например, VMware ESXi, а в качестве хранилищ Microsoft Windows Server 2012 R2, используя при этом компоненты OpenStack, предназначенные для комплексного управления облачными сервисами (многие из них, кстати ориентированы на средства самообслуживания пользователей, которые сами могут запрашивать себе ресурсы облака). В этом смысле средства OpenStack чем-то похожи на решение vCloud Director от компании VMware.

Еще летом 2013 года компания VMware объявила о скором запуске виртуального модуля vSphere OpenStack Virtual Appliance (VOVA), который позволит наладить интеграцию с такими компонентами OpenStack, как Nova (контроллер вычислительных ресурсов) and Cinder (облачные блочные хранилища).

А совсем недавно VMware объявила о новой версии vSphere OpenStack Virtual Appliance (VOVA), которое можно использовать для дистрибутива Mirantis OpenStack (компании Mirantis).

Однако, скажем сразу, что этот модуль не является официальным решением VMware, это просто способ показать, как именно можно интегрировать компоненты VMware vSphere в архитектуру OpenStack.

Вот что можно делать с помощью VOVA:

• В качестве OpenStack Compute service (Nova) использовать VMware vCenter Server
• В качестве OpenStack Networking service (Neutron) использовать VMware NSX (пока недоступно в текущей версии)
• В качестве OpenStack Block Storage service (Cinder) использовать виртуальные диски формата VMware VMDK
• Возможность совместимости с дистрибутивом OpenStack Havana в будущих релизах

Видеодемонстрация решения vSphere OpenStack Virtual Appliance:

Для тех, кто дочитал до конца, бонус - лабораторная работа, где можно самостоятельно потыкать Вову и ознакомиться с архитектурой OpenStack: http://labs.hol.vmware.com/HOL/#lab/698.

Ну и постоянная ссылка на инициативы VMware для OpenStack - http://www.vmware.com/go/openstack.

Продолжаем вас знакомить с продуктом vGate R2, предназначенным для защиты виртуальных сред VMware vSphere. Напомним, что он позволяет производить автоматическую настройку конфигурации безопасности хост-серверов VMware ESX / ESXi средствами политик, защищать инфраструктуру от несанкционированного доступа, а также имеет все необходимые сертификаты ФСТЭК (включая сертификаты на vSphere 5.1).

Мы уже писали про распределенный кэш на SSD-накопителях локальных дисков серверов ESXi, который имел рабочее название vFlash, а затем превратился в полноценную функцию VMware vSphere Flash Read Cache платформы VMware vSphere 5.5.

Сегодня мы хотим обратить внимание на два интересных документа, которые раскрывают подробности использования этой технологии.

Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение. Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.

Итак, первый документ о том как работает технология Flash Read Cache - "What’s New in VMware vSphere Flash Read Cache":

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

Второй документ - это официальный FAQ VMware по технологии Flash Read Cache - "VMware vSphere Flash Read Cache 1.0 FAQ". Так как она появилась впервые, и не все технические особенности ясны администраторам, в документе даны ответы аж на 67 вопросов.

Интересные факты из этого FAQ:

• В качестве интерфейсов накопителей поддерживаются SATA, SAS и PCI Express.
• До 8 устройств vFlash на один хост ESXi и до 4 ТБ емкости на устройство (до 400 ГБ на один VMDK). На один контейнер VFFS (то есть на хост) поддерживается до 32 ТБ.
• В качестве хранилищ ВМ механизмом поддерживаются тома VMFS/NFS/vRDM (pRDM не поддерживается).
• Настраивается только через Web Client.
• При изменении настроек vFlash все кэши для дисков сбрасываются.
• Thin provisioning не поддерживается технологией vFlash.
• При миграции виртуальной машины средствами vMotion можно использовать 2 политики: Always migrate the cache contents (copy) - кэш копируется вместе с ВМ и Do not migrate the cache contents (drop) - кэш очищается. Техники VMware HA / SVMotion также полностью поддерживается.
• Механизм VMware DRS при миграции не затрагивает машины с включенным Virtual Flash Read Cache.
• Операции, которые очищают кэш ВМ: suspend, изменение конфигурации, удаление, перезапуск машины или хоста, восстановление из снапшота. Операции, которые не очищают кэш: снятие снапшота, клонирование, миграция vMotion, fast suspend/resume.
• В vCenter есть 3 специальных метрики для мониторинга vFlash (IOPS, Latency и объем кэша).
• Кэшем vFlash можно управлять через ESX CLI: get –m <module> -c <cache file name>
• Файлы кэша vFlash находятся в следующей директории на хосте: /vmfs/volumes/vffs/vflash

Информацию об официально поддерживаемых механизмом VMware vSphere Flash Read Cache устройствах можно найти по этой ссылке: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vfrc

Не так давно мы писали о том, что компания VMware обкатывает бета-версию своего руководства по обеспечению безопасности виртуальной среды, а вчера этот документ VMware vSphere 5.5 Hardening Guide был выпущен в окончательной редакции. Если говорить об изменениях по сравнению с бета-версией, то в основном были сделаны добавления в части vSphere Web Client.

Традиционно в документе, который представляет собой Excel-файл с несколькими вкладками, присутствуют следующие разделы:

• Virtual Machines
• ESXi hosts
• Virtual Network
• vCenter Server (а также различные БД и клиенты)
• vCenter Web Client
• vCenter SSO Server
• vCenter Virtual Appliance (VCSA) и различные аспекты его использования
• vCenter Update Manager
• vSphere Management Assistant (vMA)
• различные аддоны

По поводу большинства рекомендаций есть необходимые команды CLI или PowerCLI, которые приведут компоненты VMware vSphere в желаемое состояние. Рекомендуется обращать внимание на колонку Negative Functional Impact, которая описывает возможные негативные последствия для инфраструктуры.

Кроме того, некоторые параметры разделены по "профилям риска":

• Risk Profile 1 - для суперзащищенных систем (обработка гостайны, информация особой важности). Надо учитывать, что применение этих рекомендаций может повлечь за собой то, что некоторые функции платформы перестанут работать.
• Risk Profile 2 - рекомендации среднего уровня защиты, которые необходимо применять при работе с чувствительными данными.
• Risk Profile 3 - то, что должны (по-хорошему) применять все.

Также, по традиции, есть и лог изменений с предыдущей версии:

Некоторые вещи были изменены совсем недавно, поэтому многим будет интересно этот док посмотреть.

Скоро VMware vSphere 5.5 Hardening Guide появится вот на этой странице, где собираются все версии руководств Security Hardening Guides (там пока есть доки для vCloud Director и Configuration Manager).

Прямые ссылки на скачивание:

• HardeningGuide-vSphere5.5-GA-Released.xlsx (157.8 K)
• HardeningGuide-vSphere5.5-GA-Released-changelog.xlsx (17.0 К)

Также порекомендуем здесь комплексное средство для обеспечения безопасности виртуальной инфраструктуры vGate R2, которое (помимо всего прочего) позволит применить необходимые политики Security Hardening Guide и обеспечить защиту от НСД.

Немногие знают, что с выходом обновленной платформы виртуализации VMware vSphere 5.5 компания VMware поменяла архитектуру драйверов, которые использует гипервизор для взаимодействия с аппаратным обеспечением. Теперь эта архитектура называется Native Device Driver Architecture, и она позволяет использовать нативные драйверы для VMkernel вместо драйверов под Linux.

William Lam написал хороший пост на эту тему. Изложим здесь его основные моменты вкратце.

Раньше VMware ESX / ESXi использовал архитектуру драйверов Linux, но поскольку ядро гипервизора VMkernel - это не Linux, то VMware пришлось сделать модуль vmklinux, который находится между VMkernel и драйверами:

Эта архитектура позволяет драйверам "Linux-происхождения" общаться с VMkernel через API, предоставляемый vmklinux.

Однако очевидно, что у такой архитектуры есть множество недостатков:

• Дополнительный уровень трансляции команд добавляет багоемкости и потерь производительности.
• Необходима совместимость драйверов с ядром Linux, хотя требуется-то всего лишь совместимость с VMkernel.
• Ограниченность функциональности драйвера - он может сделать для VMkernel не больше, чем может сделать для Linux.

Ввиду всего этого в VMware ESXi 5.5 и была введена новая архитектура, в которой отсутствует ненужная прослойка:

Теперь VMware предоставляет своим партнерам средство разработки Native Driver Development Kit (NDDK), которое позволяет производителям аппаратного обеспечения делать нативные драйверы для VMware ESXi / VMkernel как для отдельной ОС. Доступна эта возможность только партнерам уровня TAP (Technology Alliance Partner).

С одной стороны это все выглядит позитивно, если бы не одно но. Если раньше Linux-драйверы, которые выпускались под лицензией GPL, были доступны как open source, то и исходные коды драйверов для ESXi (в соответствии с лицензией GPL) были также доступны публично.

Поэтому независимые разработчики могли использовать их для разработки собственных и доработки существующих драйверов к устройствам, официально неподдерживаемым VMware ESXi (для так называемого "Whitebox-железа").

Теперь же VMware не планирует выпускать драйверы как Open Source, что сильно ограничит возможности по поддержке аппаратных компонентов и платформ, отсутствующих в списке совместимости HCL.

Платформа виртуализации VMware vSphere 5.5 на данный момент поддерживает как legacy-модель драйверов, так и Native Device Driver Architecture в целях обратной совместимости. Однако рано или поздно VMware откажется от поддержки Linux-драйверов, и многим пользователям такое не понравится.

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

И вот еще хороший пост про исключение драйверов Realtec из ESXi 5.5.

Больше двух лет назад (ого, давно же!) мы писали о том, что вышел VMware vCenter Converter Standalone 5.0, который был заточен под миграцию серверов еще на платформу VMware vSphere 5.0. С тех пор компания VMware выпустила решения vSphere 5.1 и vSphere 5.5, соответственно уже очень давно было пора обновить главное средство для P2V-миграции физических серверов в виртуальные машины.

На днях было объявлено о выпуске VMware vCenter Converter Standalone 5.5:

Новых возможностей за два года у конвертера существенно прибавилось, хотя вряд ли все два года над ним велась напряженная работа. Итак, что нового в vCenter Converter Standalone 5.5:

• Поддержка VMware vSphere 5.5.
• Поддержка virtual machine hardware version 10, а значит и таких фич, как диски по 62 ТБ, виртуальные SATA-контроллеры и прочее.
• Поддержка виртуальных машин RedHat KVM в качестве источника для миграции на платформу vSphere.
• Новая опция по выбору типа сетевого адаптера для целевой машины на хосте ESXi.
• Поддержка новых гостевых ОС (см. ниже).
• Параллельная миграция нескольких дисков одной машины, что существенно ускоряет процесс миграции.
• Поддержка целевых хранилищ VMware Virtual SAN.

Converter Standalone поддерживает следующие гостевые ОС (как источники для миграции):

• Windows XP Professional SP3 (32-bit и 64-bit)
• Windows Server 2003 R2 SP2 (32-bit и 64-bit)
• Windows Vista SP2 (32-bit и 64-bit)
• Windows Server 2008 SP2 (32-bit и 64-bit)
• Windows Server 2008 R2 (64-bit)
• Windows 7 (32-bit и 64-bit)
• Windows 8 (32-bit и 64-bit)
• Windows Server 2012 (64-bit)
• Red Hat Enterprise Linux 3.x (32-bit и 64-bit)
• Red Hat Enterprise Linux 4.x (32-bit и 64-bit)
• Red Hat Enterprise Linux 5.x (32-bit и 64-bit)
• Red Hat Enterprise Linux 6.x (32-bit и 64-bit)
• SUSE Linux Enterprise Server 9.x (32-bit и 64-bit)
• SUSE Linux Enterprise Server 10.x (32-bit и 64-bit)
• SUSE Linux Enterprise Server 11.x (32-bit и 64-bit)
• Ubuntu 10.04 LTS (32-bit и 64-bit)
• Ubuntu 12.x (32-bit и 64-bit)
• Ubuntu 13.04 (32-bit и 64-bit)

Windows 8.1 и Windows Server 2012 R2 пока остаются за бортом, здесь надо будет ждать обновления.

С каких платформ можно производить миграцию средствами VMware vCenter Converter Standalone 5.5:

• Физические машины с гостевой ОС и вышеприведенного списка
• Настольные платформы:
  • Workstation 7.x, 8.x, 9.x и 10.x
  • Fusion 3.x, 4.x, 5.x и 6.x
  • Player 3.x, 4.x, 5.x, и 6.x
• Машины под управлением VMware vCenter:
  • vSphere 5.5
  • vSphere 5.1
  • vSphere 5.0
  • vSphere 4.1
  • vSphere 4.0
• Сторонние образы резервного копирования и платформы виртуализации:
  • Acronis True Image Echo 9.1 и 9.5, а также Acronis True Image Home 10 и 11 (.tib).
  • Symantec Backup Exec System Recovery (бывший LiveState Recovery) 6.5, 7.0, 8.0, и 8.5, а также LiveState Recovery 3.0 и 6.0 (только формат .sv2i).
  • Norton Ghost version 10.0, 12.0 и 14.0 (только формат .sv2i).
  • Parallels Desktop 2.5, 3.0 и 4.0 (.pvs и .hdd). Сжатые (compressed) диски не поддерживаются.
  • Parallels Workstation 2.x (.pvs). Сжатые (compressed) диски не поддерживаются. Контейнеры Parallels Virtuozzo Containers также не поддерживаются.
  • StorageCraft ShadowProtect Desktop, ShadowProtect Server, ShadowProtect Small Business Server (SBS), ShadowProtect IT Edition, versions 2.0, 2.5, 3.0, 3.1 и 3.2 (формат .spf)
  • Виртуальные машин на дисках Microsoft VHD со следующих источников:
    • Microsoft Virtual PC 2004 и Microsoft Virtual PC 2007 (.vmc)
    • Microsoft Virtual Server 2005 и 2005 R2 (.vmc)

Ну а в качестве целевых ВМ могут быть использованы машины на следующих платформах VMware:

• Машины на хост-серверах под управлением VMware vCenter:
  • ESX 4.0 и 4.1
  • ESXi 4.0, 4.1, 5.0, 5.1 и 5.5
  • vCenter Server 4.0, 4.1, 5.0, 5.1 и 5.5
• Машины на хост-платформах под управлением следующих настольных систем:
  • VMware Workstation 7.x, 8.x, 9.x и 10.x
  • VMware Player 3.x, 4.x, 5.x и 6.x
  • VMware Fusion 3.x, 4.x, 5.x и 6.x

Скачать VMware vCenter Converter Standalone 5.5 можно по этой ссылке. Напомним, что продукт полностью бесплатен.

За множеством анонсов VMworld Europe 2013 пользователи платформы виртуализации VMware vSphere могли упустить несколько полезных релизов.

Во-первых, вышла новая версия VMware vSphere 5.0 Update 3:

Это сервисный релиз, включающий в себя следующие возможности:

• Поддержка новых гостевых ОС (более детальная информация в Guest OS Customization Support Matrix).
• Добавлена поддержка БД  Microsoft SQL Server 2012 Service Pack 1.
• Множество исправлений (подробнее в Resolved Issues).

Информация о гипервизоре ESXi 5.0 Update 3 и остальных компонентах приведена по этим ссылкам: esx-base, misc-drivers, scsi-hpsa, tools-light

Во-вторых, обновилась и VMware vSphere 5.1:

• Вышел vCenter 5.1 Update 1c
• Обновились компоненты VMware ESXi 5.1: esx-base and misc-drivers, net-ixgbe, tools-light, 

В этом билде были только исправлены баги и не добавилось новых возможностей. Кстати, для интересующихся есть интересная матрица билдов, позволяющая сверить версии компонентов своей виртуальной инфраструктуры.

Кроме всего прочего обновился и HP Customized ESXi 5.0.

В-третьих, вышел HP Customized ESXi 5.5 ISO

Это хорошая новость для тех, кто использует серверы HP и все ждет, как бы начать развертывать на них образы ESXi. Сам образ HP Customized ESXi 5.5 ISO доступен тут. Традиционно, драйверы устройств и различные бандлы доступны в VIB-репозитории HP.

Кстати, ранее этот образ уже выкладывала HP, но там была бага с CIM-провайдерами, которая поправлена в этом билде. Что нового в HP Customized ESXi 5.5 :

• Убрана поддержка старых серверов, а именно: всех моделей G5 и множества G6 (более подробно в ProLiant Server VMware Support Matrix).
  Но это не значит, что там ESXi 5.5 не будет работать.
• Утилита hpacucli для конфигурации контроллеров хранилищ из командной строки ESXi была заменена на утилиту hpssacli, которая поддерживает больше контроллеров.
• Новая утилита hptestevent, которая теперь может посылать тестовые события WBEM, что может пригодиться для проверки корректности работы механизма WBEM/CIM (проверка, что хост правильно зарегистрирован в HP SIM для мониторинга аппаратного обеспечения).

Процедура обновления HP-сервера с образа vSphere 5.0 или 5.1 на HP customized ESXi 5.5:

• Загружаем HP Customized ESXi 5.5 Offline bundle (zip-файл) отсюда.
• Загружаем его на датастор хоста ESXi и выполняем команду:

esxcli software profile install -d /vmfs/volumes/<datastore>/VMware-ESXi-5.5.0-1331820-HP-5.71.3-Sep2013-depot.zip -p HP-ESXi-5.5.0-5.71.3

• Перезагружаем хост VMware ESXi.

Мы уже писали о технологии VMware VSAN, которая позволяет построить распределенный кластер хранилищ на базе локальных дисков серверов VMware ESXi. Этот кластер позволяет отказоустойчиво хранить виртуальные машины и обращаться к ним с любого из хостов. Недавно компания VMware опубликовала результаты тестов работы ВМ в VDI-инфраструктуре на базе хранилищ VSAN.

Не так давно компания Veeam Software объявила о скором выпуске новой версии пакета Management Pack for VMware v6.5, который может быть использован совместно со средством мониторинга инфраструктуры Microsoft System Center Operations Manager (SCOM).

Напомним, что Veeam Management Pack for VMware позволяет осуществлять комплексный мониторинг виртуальной инфраструктуры VMware vSphere посредством SCOM в рамках единого подхода к мониторингу и решению проблем в ИТ-инфраструктуре предприятия (как физической, так и виртуальной). Напомним, что о прошлой версии Veeam Management Pack for VMware 6.0, которая вышла в апреле этого года, мы уже писали вот тут.

Итак, новые возможности Veeam Management Pack for VMware 6.5:

• New enhanced fault tolerance - возможность автоматического перенаправления сбора данных с сервера vCenter на хосты ESXi, если первый по каким-то причинам оказался недоступен. То есть если vCenter упал, сбор данных идет напрямую с ESXi, если поднялся - автоматически восстанавливается сбор данных с vCenter, без прерывания процесса мониторинга.
• New configuration tracking and alert correlation - теперь Veeam MP отслеживает все происходящие в виртуальной инфраструктуре vSphere изменения и позволяет отследить на какие ее аспекты эти изменения повлияли.
• New monitoring and reporting for Veeam Backup & Replication - теперь появилась возможность мониторинга не только платформы VMware vSphere, но и инфраструктуры резервного копирования Veeam Backup and Replication, включая его прокси-серверы, серверы с репозиториями, WAN-акселераторы, непосредственно сами задания резервного копирования и многое другое.
• New platforms support - теперь Veeam Management Pack for VMware 6.5 поддерживает ОС Windows Server 2012 R2 + System Center 2012 R2 Operations Manager, vCenter Server 4.x и более поздних версий, а также ESX 4.x и более поздние. Само собой, новая версия MP от Veeam поддерживает VMware vSphere 5.5.

Больше о возможностях Veeam Management Pack for VMware 6.5 (особенно об интеграции с Veeam B&R) можно прочитать в документе "Veeam Management Pack for VMware. What’s New in v6.5".

Как многие знают, еще в прошлых версиях VMware vSphere появилась такая возможность, как задание нескольких виртуальных ядер для vCPU виртуальных машин (cores per socket), которое требуется, в основном, для случаев хитростей с лицензированием. То есть, например, для случаев, когда требуется покрыть лицензиями только виртуальные сокеты, а производительности нужно больше (как вариант - так можно поступать с лицензиями Windows Server не Datacenter Edition).

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

Рекомендации тут просты:

• Оставлять по одному ядру на виртуальный процессор машин.
• Если все-таки приходится изменять число ядер на vCPU, то нужно знать особенности организации архитектуры сервера.

Про второй пункт и идет речь ниже. Дело в том, что в VMware vSphere есть такая технология как vNUMA, которая работает при количестве vCPU равном 8 и больше для одной виртуальной машины и позволяет самым оптимальным образом отображать физическую архитектуру сервера на топологию NUMA-узлов виртуальной машины (по количеству и размеру).

Например, для процессора AMD Opteron 6174, который имеет два 6-ядерных процессора, объединенных в единый сокет - такая архитектура представляет собой 8 NUMA-узлов (две пары на один процессор). Таким образом для конфигурации без изменения cores per cpu для виртуальной машины технологией vNUMA будет поддерживаться 8 vNUMA узлов, что отлично отражает физическую архитектуру:

Это для случая, когда мы не изменяем количество ядер на vCPU. В VMware прогнали тест в гостевой ОС (какая-то внутренняя утилита) и получили базовое время исполнения этого бенчмарка для указанной конфигурации:

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

Получаем 2 vNUMA-узла, что не совпадает с конфигурацией оборудования:

Поэтому тест выполняется подольше:

А вот если сделаем целых 24 ядра на один сокет:

То получим всего один узел vNUMA:

И как следствие, самую низкую производительность ВМ:

65 секунд против 45 в первом тесте, что означает падение производительности на 31% для данного случая. Поэтому не меняйте просто так число ядер на процессор. Само же количество процессоров можно менять смело.

Дополнительную информацию по этому вопросу можно найти тут:

• KB 1010184
• The CPU Scheduler in VMware vSphere 5.1
• Check out VSCS4811 Extreme Performance Series: Monster Virtual Machines in VMworld Barcelona

Многие администраторы виртуальной инфраструктуры VMware vSphere сталкиваются с необходимостью копировать файлы в гостевую ОС виртуальных машин. Делают они это путем копирования на системную шару или обычный общий ресурс, пробросом дисков через RDP и прочими методами.

Но многое из этого оказывается неприемлемым по тем или иным причинам. Чтобы этого всего избежать, Manfred Meier выложил на сайте VMware Directory утилиту vGuestExplorer, которая позволяет получить доступ к файловой системы гостевой ОС виртуальной машины даже без непосредственного сетевого соединения с ней.

Делается это посредством соединения по PowerCLI / PowerShell через VIX API к гостевой ОС виртуальной машины. Можно подключаться к серверу VMware vCenter, а можно к отдельному хосту VMware ESXi. Обязательно наличие установленных VMware Tools в гостевой ОС.

Работает vGuestExplorer как для Windows, так и для Linux.

Установка утилиты проста:

• Устанавливаем PowerCLI и выставляем параметр Set-Executionpolicy как Unrestricted.
• Выполняем PowerCLI как Administrator и запускаем команду:
  Set-PowerCLIConfiguration -InvalidCertificateAction ignore -ProxyPolicy NoProxy -Confirm:$False
  
• Запускаем установку vGuestExplorer.
• Убедитесь, что VMware Tools установлено в той ВМ, в которую вы будете копировать файлы.

Скачать vGuestExplorer можно по этой ссылке.

Многие пользователи VMware vSphere применяют репликацию уровня хоста (host-based) для защиты виртуальных машин и их хранилищ. Сама эта технология появилась еще в версии VMware vSphere 5.1 и активно используется в vSphere 5.5. Напомним также, что функции vSphere Replication используются в решении VMware Site Recovery Manager для построения катастрофоустойчивой инфраструктуры небольших компаний.

На днях компания VMware выпустила виртуальный модуль (Virtual Appliance) под названием vSphere Replication Capacity Planning Appliance, который призван помочь при планировании пропускной способности канала сети под репликацию.

Эта бесплатная утилита, доступная на сайте проекта VMware Labs, позволяет смоделировать воздействие vSphere Replication на продуктивную сеть без реальной генерации трафика.

Возможности vSphere Replication Capacity Planning Appliance:

• Интерфейс командной строки для настройки репликации в режиме "preview mode", без реального потребления хранилища.
• Веб-страница, представляющая графики по потреблению канала для каждой репликации.
• Не требует ресурсов сети и хранилищ.

Как начать пользоваться:

1. Установить виртуальный модуль.
2. Как только он загрузится, залогиниться по SSH или в консоль с логином/паролем - root/vmware.
3. Выполнить команду:
cd /opt/vmware/hbrtraffic/
4. Выполнить команду для симуляции репликации конкретной ВМ (VM_name):
   ./bin/configureReplication --vc --vcuser Administrator --vcpass --lwd <IP_of_the_Appliance> --vmname <VM_name>

После того, как операция будет выполнена (10-15 минут) получившиеся графики можно посмотреть по адресу:

https://IP_of_the_Appliance:5480/vr-graphs/

Скачать vSphere Replication Capacity Planning Appliance можно по этой ссылке.

Мы уже не раз писали (тут и тут) про расширенные настройки (Advanced Settings) кластеров VMware HA в VMware vSphere (до версии 5.0 включительно). Эти настройки позволяют гибко настраивать различные параметры кластеров, их поведение, определять сетевые настройки и т.п. В этой статье мы приведем все эти настройки в единую таблицу и актуализуем для версии VMware vSphere 5.5.

Как многие помнят, у компании VMware был TCO-калькулятор (который она делала совместно с компанией Alinean), позволявший посчитать совокупную стоимость владения виртуальной инфраструктурой (Total Cost of Ownership, TCO) как для серверной инфраструктуры VMware vSphere, так и для VDI-среды VMware View.

Теперь на его базе компания VMware создала утилиту VMware Cloud Compass Tool (также совместно с Alinean), которая рассчитывает не только показатели TCO, но и умеет определять необходимый пользователю тип облака: приватное, публичное или гибридное:

VMware Cloud Compass предназначен для следующих целей:

• Расчет и сравнение моделей TCO (с учетом CapEx и OpEx) для различных вариантов платформ и параметров для онпремизной инсталляции, а также для различных типов облаков.
• Оценка устойчивости инфраструктуры к различным рискам, включая такие параметры как доступность, соответствие требованиям отраслевых стандартов, безопасность и т.п.
• Оценка необходимых параметров публичного или приватного облака для построения облачного решения в своей организации, а также оценка затрат на эту активность.

Результаты расчетов VMware Cloud Compass доступны онлайн, но при желании их можно скачать в формате PDF и обсудить с коллегами и руководством.

Сразу после релиза обновленной версии платформы vSphere 5.5 компания VMware выпустила очень интересный и полезный документ Performance Best Practices for VMware vSphere 5.5, в котором рассматриваются аспекты производительности серверов VMware ESXi и виртуальных машин уже с учетом функциональности новой версии.

Например, теперь в документе описаны следующие фичи в контексте производительности:

• Функции кэширования на SSD-накопителях vSphere Flash Read Cache, о которых мы писали вот тут. Они увеличивают производительность за счет применения кэша на чтение для операций ввода-вывода виртуальных машин.
• Возможность VMware Virtual SAN (VSAN), о которой мы писали тут. Она позволяет использовать локальные ресурсы хостов ESXi для построения распределенной инфраструктуры хранения виртуальных машин.
• База данных VMware vFabric Postgres database (vPostgres).

Кроме того, были обновлены и дополнены следующие темы в документе (который уже можно смело называть книгой, так как занимает он 90 страниц):

• Использование нагрузок в ВМ, чувствительных к скорости подсистемы ввода-вывода и сетевому взаимодействию (интересна также статья в тему)
• Техники NUMA и Virtual NUMA (vNUMA)
• Техники экономии памяти хоста (Memory overcommit)
• Технология Large memory pages
• Техника Receive-side scaling (RSS), как в гостевых ОС, так и для адаптеров 10 Gigabit Ethernet
• Средства миграции VMware vMotion, Storage vMotion, а также Cross-host Storage vMotion
• Техники балансировки нагрузки VMware Distributed Resource Scheduler (DRS) и экономии электропитания Distributed Power Management (DPM)
• Обновленный (а точнее полностью переписанный) VMware Single Sign-On Server (об этом у нас тут)

В последнее время мы много писали о новых версиях продуктов компании VMware, таких как vSphere 5.5, vCloud Director 5.5, Site Recovery Manager 5.5 и прочих, анонсированных на конференции VMworld 2013.

Теперь, наконец-то, VMware сделала большинство из них доступными для загрузки и использования в производственной среде предприятий.

Итак, ниже приведены ссылки на загрузки обновленных версий продуктовой линейки.

Все, что относится к платформе виртуализации и средствам управления ею:

• VMware vSphere 5.5 (наше описание - тут, документация - тут)
• ESXi 5.5 (наше описание бесплатной версии - тут)
• vCenter Server 5.5
• Прямая ссылка на скачивание - VMware vSphere Client 5.5
• vSphere Data Protection 5.5.1
• vSphere Replication 5.5
• vSphere App HA 1.0
• Cisco Nexus 1000v for 5.5
• vSphere PowerCLI 5.5
• vCenter Orchestrator Appliance 5.5
• vSphere Management Assistant 5.5
• vCenter Certificate Automation Tool 5.5
• vSphere CLI 5.5

Обновленные компоненты облачной инфраструктуры VMware vCloud Suite (подробнее - тут):

• VMware vCloud Automation Center 5.2.0
• VMware vCloud Director 5.5.0 (наше описание - тут)
• VMware vCenter Site Recovery Manager 5.5.0 (наше описание - тут)
• VMware vCenter Infrastructure Navigator 5.7.0
• VMware vCenter Operations Manager Standard 5.7.2
• VMware vCenter Configuration Manager 5.7.0
• VMware vSphere Big Data Extensions 1.0
• VMware vCloud Networking and Security 5.5.0

Кстати, интересен пост о том, что VMware постепенно укорачивает цикл релизов платформы VMware vSphere. Вот как изменяется число дней от одной мажорной версии до другой:

Также стоит почитать обновленный документ vSphere 5.5 Configuration Maximums.

Напомню, что нет смысла сразу бросаться и устанавливать VMware vSphere 5.5 на свои серверы. Как многие помнят, у VMware с выходом новой версии часто появляются баги (например, тут и тут), иногда весьма критические (многие помнят баг с тайм-бомбой), поэтому лучше немного подождать и почитать блоги и новостные ресурсы (например, наш), где будут появляться записи о серьезных ошибках, если таковые там имеются.

Ну а VMware View 5.5 пока нет - ждем.

Как мы уже недавно писали, одной из новых возможностей VMware vSphere 5.5 стали функции расширенного управления электропитанием серверов vSphere Host Power Management (HPM). Ранее о таких функциях на платформе VMware vSphere мы рассказыали вот тут.

HPM - это совокупность техник, позволяющих оптимизировать потребление электроэнергии хостом VMware ESXi, когда он находится в состоянии простоя или пониженной нагрузки.

Управление электропитанием происходит через интерфейс Advanced Configuration and Power Interface (ACPI), который позволяет управлять состояниями P-states и C-states. В VMware vSphere 5.0/5.1 дефолтная политика управления питанием была основана на технологии dynamic voltage and frequency scaling (DVFS).

Эта технология использует P-states процессора, что позволяет экономить некоторое количество энергии за счет поддержки процессора на более низкой частоте и напряжении. Но, начиная с VMware vSphere 5.5, политика HPM использует расширенный набор состояний halt states (они же C-states) в дополнение к DVFS. Это намного больше увеличивает экономию энергии при сохранении хорошей производительности, так как состояния C-states процессора почти не сказываются на его производительности, а питания потребляют значительно меньше (а иногда производительность даже растет, особенно для легких и средних нагрузок без большого потока операций ввода-вывода).

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

Для того чтобы их включить, например, в серверах HP нужно в BIOS зайти в Power Management Options -> HP Power Profile и выбрать пункт Custom. Затем нужно зайти в Power Management Options->HP Power Regulator, где выбрать пункт OS Control Mode.

Для управления глубокими режимами C-states (C1/C1E, C3 и C6) нужно также разрешить их использование со стороны программного обеспечения в BIOS сервера:

Для VMware HPM есть 4 различных политики электропитания:

• High Performance - в этом состоянии процессор находится в самом высоком P-state все время, а для C-states используется всего 2 режима: running и halted. Это дефолтная политика для vSphere 5.0 и более ранних версий.
• Balanced - вот эта политика и позволяет использовать как P-states для экономии питания, так и, начиная с vSphere 5.5, C-states, выбор которых производится на основе оценки со стороны ESXi с использованием статистического прогноза на время простоя процессора.
• Low Power - в этом режиме хост делает все, чтобы снизить потребление энергии, используя алгоритмы P-states и C-states состояний.
• Custom - по умолчанию эта политика выставлена как Balanced, но ее уже можно крутить для получения нужного результата.

Для политики Custom есть несколько интересных параметров, которые можно покрутить, если очень хочется (их число по сравнению с прошлой версией ESXi возросло):

По результатам тестов использование C-states для режима Turbo mode дает существенный прирост производительности (при том, что само по себе включение турбо-режима прироста почти не дает):

А вот как использование deep C-states позитивно влияет на потребление электроэнергии:

Интересный график экономии питания в зависимости от нагрузки хост-сервера - получается, что максимальная эффективность у HPM - до 30% загрузки CPU:

Остальное - в интереснейшем документе "Host Power Management in VMware vSphere 5.5" компании VMware.

Очень часто при чтении документации VMware приходиться сталкиваться с различного рода сокращениями, большинство из которых, конечно же, понятно опытным администраторам VMware vSphere, но не всегда понятно для новичков.

Andrea Mauro составил неплохой список акронимов VMware, который мы и публикуем здесь (ссылки добавил я - на релевантные статьи):

Если у вас есть что дополнить - пишите в каменты.

Интересны также другие посты на эту тему:

• VMware related acronyms (YellowBricks)
• VMware related Acronyms and Abbreviations (Virten)
• Abbreviations (VMware Directory)
• How to pronounce some of VMware’s acronyms

Последний пост о произношении акронимов особенно интересен. Например, vCAC произносится как "викейк" (v-cake), а vCHS как "вичес" (v-chess).