Если вкратце, то компоненты vCenter предлагается защищать с помощью следующих решений:
1. Кластер высокой доступности VMware HA и сервис слежения за vCenter - Watchdog.
Сервис HA автоматически перезапускает виртуальную машину с vCenter отказавшего сервера на другом хосте кластера, а сервис Watchdog (он есть как на обычном vCenter, так и на vCenter Server Appliance) следит за тем, чтобы основная служба vCenter работала и отвечала, и запускает/перезапускает ее в случае сбоя.
2. Защита средствами VMware Fault Tolerance.
Теперь технология VMware FT в VMware vSphere 6.0 позволяет защищать ВМ с несколькими vCPU, поэтому данный способ теперь подходит для обеспечения непрерывной доступности сервисов vCenter и мгновенного восстановления в случае сбоя оборудования основного хоста ESXi.
Компания VMware предоставляет специализированный API, который могут использовать партнеры для создания решений, защищающих приложения в гостевой ОС, в частности, сервис vCenter. Одно из таких приложений - Symantec ApplicationHA. Оно полностью поддерживает vCenter, имеет специализированного агента и перезапускает нужные службы в случае сбоя или зависания сервиса.
4. Средства кластеризации на уровне гостевой ОС (с кворумным диском).
Это один из древнейших подходов к защите сервисов vCenter. О нем мы писали еще вот тут.
Для организации данного типа защиты потребуется основная и резервная ВМ, которые лучше разместить на разных хостах vCenter. С помощью кластера Windows Server Failover Clustering (WSFC) организуется кворумный диск, общий для виртуальных машин, на котором размещены данные vCenter. В случае сбоя происходит переключение на резервную ВМ, которая продолжает работу с общим диском. Этот метод полностью поддерживается с vCenter 6.0:
Кстати, в документе есть пошаговое руководство по настройке кластера WSFC для кластеризации vCenter 6.0 (не забудьте потом, где его искать).
Ну и в заключение, сводная таблица по функциям и преимуществам приведенных методов:
Далее идет описание средств высокой доступности в Enterprise-инфраструктуре с несколькими серверами vCenter, где компоненты PSC (Platform Services Controller) и vCenter разнесены по разным серверам. Схема с использованием балансировщика:
Обратите внимание, что для PSC отказоустойчивость уже встроена - они реплицируют данные между собой.
Та же схема, но с кластеризованными серверами vCenter средствами технологии WSFC:
Использование географически распределенных датацентров и сервисов vCenter в них в едином домене доступа SSO (Single Sign-On) за счет технологии Enhanced Linked Mode (каждый сайт независим):
То же самое, но со схемой отказоустойчивости на уровне каждой из площадок:
Ну и напоследок 2 дополнительных совета:
1. Используйте Network Teaming для адаптеров vCenter (физических или виртуальных) в режиме отказоустойчивости, подключенные к дублирующим друг друга сетям.
2. Используйте Anti-affinity rules кластера HA/DRS, чтобы основная и резервная машина с vCenter не оказались на одном хосте VMware ESXi.
Да, и не забывайте о резервном копировании и репликации виртуальной машины с vCenter. Сделать это можно либо средствами Veeam Backup and Replication 8, либо с помощью VMware vSphere Replication/VMware vSphere Data Protection.
На днях компания VMware сделала неожиданный ход: решение VMware vCloud Director, про которое говорилось, что оно будет снято с производства (пруф), получило новую жизнь. Пропустив 6 и 7 версии со времен последней версии vCloud Director 5.6, компания VMware анонсировала скорую доступность бета-версии vCloud Director 8.0.
Заявленные новые возможности продукта:
Полная поддержка vSphere 6.0 и совместимость с решением для виртуализации сетей NSX 6.1.
Шаблоны Virtual Data Center (VDC) для возможности использования портала самообслуживания пользователями самостоятельно.
Улучшения юзабилити виртуальных сервисов (vApp). Также от них ждут поддержки контейнеризованных приложений.
Ограничения параметров ВМ (использование ресурсов), для того чтобы гибко управлять потреблением физических ресурсов в многопользовательской облачной среде.
Поддержка провайдеров аутентификации OAuth
Улучшения процессов развертывания и автоматизации за счет поддержки нового плагина vRealize Orchestrator Plugin.
Записаться в участники бета-программы vCloud Director 8.0 можно на этой странице. Сам продукт будет доступен для скачивания 1 июня. Пока можно записаться на вебинар по этому решению, который также пройдет 1 июня в 18-00 по московскому времени.
Ну и после регистрации в бета-программе вам будет доступен vCloud Director 8.0 User's Guide, где можно почитать о новых возможностях подробнее.
Аналитическая компания Gartner опубликовала свой "Magic Quadrant for Cloud Infrastructure as a Service" за 2015 год. По-сути, этот квадрант отражает реальное состояние дел на рынке облачных решений и IaaS (инфраструктура как услуга, то есть аренда виртуальных машин). Конечно же, учитывались и решения PaaS/SaaS, но они на данный момент больше нишевые платформы (кроме Google) и, все-таки, в плане актуальности для пользователей идут вслед за IaaS.
Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:
полнота видения (completeness of vision)
способность реализации (ability to execute)
Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:
Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
Визионеры (visionaries) — поставщики с положительными оценками только по полноте видения.
Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.
Собственно, сам квадрант:
Лидеры тут ожидаемы: с Амазоном все и так понятно, а вот Microsoft за последние пару лет приложила весьма серьезные усилия как в технологическом, так и в маркетинговом плане для продвижения своей платформы Azure, поэтому и попала в двойку лидеров.
Из квадранта нишевых игроков вы, наверняка, знаете только платформу Rackspace. Ну и надо отметить движение VMware в сектор визионеров, но ей очевидно мешает то, что платформа VMware vCloud Air - это все же больше Enterprise-продукт с ограниченной (на данный момент) географией датацентров.
На днях компания VMware объявила о выходе обновленной версии средства для переноса физических компьютеров в виртуальную среду - vCenter Converter Standalone 6.0. Напомним, что прошлое большое обновление этого продукта вышло достаточно давно - vCenter Converter Standalone 5.5.1 был выпущен больше года назад (а в октябре прошлого года вышла версия 5.5.3).
Давайте посмотрим, что появилось нового в vCenter Converter 6.0, который органично вписывается в линейку продуктов на платформе vSphere версии 6.0:
Поддержка виртуального аппаратного обеспечения (virtual machine hardware) версии 11.
Полная поддержка vSphere 6.0 and Workstation 11.
Поддержка новых гостевых ОС: Red Hat Enterprise Linux 7, Ubuntu 14, CentOS 6-7, Windows Server 2012 R2, Windows 8.1.
Поддержка сетевых окружений, полностью построенных на базе протокола IPv6.
Режим работы через прокси-сервер.
Клонирование данных на уровне файлов для томов файловой системы ReFS в ОС Windows.
Поддержка файловой системы XFS.
Поддержка прописанных заранее имен сетевых интерфейсов.
Исправления ошибок и улучшенная стабильность.
Кстати, заявляется о том, что данная версия vCenter Converter является последней, которая поддерживает сторонние образы и виртуальные машины других платформ в качестве источников для конверсии. Следующая версия Converter будет предназначена только для конверсии изнутри ОС в режиме миграции P2V. Учитывайте это при планировании проектов по миграции систем.
Основной документ VMware vCenter Converter Standalone 6.0 User's Guide можно скачать по этой ссылке. Сам продукт vCenter Converter Standalone 6.0 можно загрузить здесь.
19 мая 2015 в 11:00 (по Московскому времени) Softline и VMware приглашают вас принять участие в бесплатном вебинаре «VMware vSphere with Operation Management vs. VMware vSphere».
VMware vSphere with Operation Management – надежная платформа виртуализации, в состав которой входят средства мониторинга производительности и управления ресурсами. Решение разработано для компаний любых размеров и выполняет задачи по обеспечению высокого уровня обслуживания для корпоративных приложений; снижению расходов на оборудование за счет эффективного использования ресурсов и повышения коэффициентов консолидации.
Программа:
Обзор vSphere with Operation Management;
Преимущества апгрейда с vSphere на vSphere with Operation Management;
Комплектации решения;
Специальные условия апгрейда для пользователей vSphere.
20 мая 2015 года в 11:00 компании Softline и Veeam приглашают вас посетить бесплатный вебинар: «Облачная модель лицензирования Veeam Cloud Provider Program для оптимизации затрат на IT».
В ходе нашего вебинара у Вас будет возможность пообщаться с техническим консультантом компании VEEAM, задать вопросы и узнать::
Что такое VPC
Зачем нужна программа VCP
Как она работает
Как стать участником
Истории успеха использования
Новейшие технологические решения от Veeam под названием Veeam Cloud Connect.
Благодаря программе VCP у Вас появятся следующие преимущества:
широчайший спектр услуг по защите данных и резервному копированию
повышение эффективности и мониторинга виртуальных сред благодаря использованию продуктов Veeam.
Недавно компания EMC сделала доступным виртуальный модуль (Virtial Appliance) vVNX community edition, представляющий собой готовую ВМ в формате OVF, с помощью которой можно организовать общее хранилище для других виртуальных машин.
Видеообзор vVNX с EMC World:
Сам продукт фактически представляет собой виртуальный VNXe 3200. Для его работы вам потребуется:
VMware vSphere 5.5 или более поздняя версия
Сетевая инфраструктура с двумя адаптерами 1 GbE или 10 GbE
Replication – возможность асинхронной репликации на уровне блоков для локальных и удаленных инстансов vVNX. Также поддерживается репликация между vVNX и настоящим VNXe 3200.
Unified Snapshots – поддержка технологии снапшотов как на уровне блоков, так и на уровне файлов. Для этого используется технология Redirect on Write (ROW).
VMware Integration – vVNX предоставляет несколько механизмов интеграции с платформой VMware vSphere, таких как VASA, VAI и VAAI. Это позволяет производить мониторинг хранилищ vVNX из клиента vSphere, создавать хранилища из Unisphere, а также использовать техники compute offloading.
Flexible File Access – к хранилищам можно предоставить доступ через CIFS или NFS. Причем оба протокола можно использовать для одной файловой системы. Также можно использовать FTP/SFTP-доступ.
Для виртуальной машины с Virtual VNX потребуется 2 vCPU, 12 ГБ оперативной памяти и до 4 ТБ хранилища для виртуальных дисков.
Также кое-где на сайте EMC заявляется, что vVNX поддерживает технологию Virtual Volumes (VVOls) от VMware, что позволяет потестировать эти хранилища, не имея физического хранилища с поддержкой этого механизма. Это неверно. Поддержка VVols в vVNX будет добавлена только в третьем квартале этого года (пруф).
Пока можно посмотреть вот это видео на эту тему:
Скачать vVNX и получить бесплатную лицензию к нему можно по этой ссылке. Материалы сообщества, касающиеся vVNX объединены по этой ссылке, а вот тут можно посмотреть видео развертывания продукта и скачать гайд по установке. Ну и вот тут вот доступен FAQ.
Компания VMware в своем блоге затронула интересную тему - обновление микрокода для процессоров платформ Intel и AMD в гипервизоре VMware ESXi, входящем в состав vSphere. Суть проблемы тут такова - современные процессоры предоставляют возможность обновления своего микрокода при загрузке, что позволяет исправлять сделанные вендором ошибки или устранять проблемные места. Как правило, обновления микрокода идут вместе с апдейтом BIOS, за которые отвечает вендор процессоров (Intel или AMD), а также вендор платформы (HP, Dell и другие).
Между тем, не все производители платформ делают обновления BIOS своевременно, поэтому чтобы получить апдейт микрокода приходится весьма долго ждать, что может быть критичным если ошибка в текущей версии микрокода весьма серьезная. ESXi имеет свой механизм microcode loader, который позволяет накатить обновления микрокода при загрузке в том случае, если вы получили эти обновления от вендора и знаете, что делаете.
Надо сказать, что в VMware vSphere 6.0 обновления микрокода накатываются только при загрузке и только на очень ранней стадии, так как более поздняя загрузка может поменять данные, уже инициализированные загрузившимся VMkernel.
Сама VMware использует тоже не самые последние обновления микрокода процессоров, так как в целях максимальной безопасности накатываются только самые критичные апдейты, а вендоры платформ просят время на тестирование обновлений.
Есть два способа обновить микрокод процессоров в ESXi - через установку VIB-пакета и через обновление файлов-пакетов микрокода на хранилище ESXi. Если вы заглянете в папку /bootbank, то увидите там такие файлы:
uc_amd.b00
uc_intel.b00
Эти файлы и содержат обновления микрокода и идут в VIB-пакете cpu-microcode гипервизора ESXi. Ниже опишем процедуру обновления микрокода для ESXi с помощью обоих методов. Предпочтительный метод - это делать апдейт через VIB-пакет, так как это наиболее безопасно. Также вам потребуется Lunix-машина для манипуляций с микрокодом. Все описанное ниже вы делаете только на свой страх и риск.
После распаковки вы получите файл microcode.dat. Это файл в ASCII-формате, его надо будет преобразовать в бинарный. У AMD в репозитории есть сразу бинарные файлы (3 штуки, все нужные).
2. Делаем бинарный пакет микрокода.
Создаем следующий python-скрипт и называем его intelBlob.py:
#! /usr/bin/python
# Make a raw binary blob from Intel microcode format.
# Requires Python 2.6 or later (including Python 3)
# Usage: intelBlob.py < microcode.dat microcode.bin
import sys
outf = open(sys.argv[1], "wb")
for line in sys.stdin:
if line[0] == '/':
continue
hvals = line.split(',')
for hval in hvals:
if hval == '\n' or hval == '\r\n':
continue
val = int(hval, 16)
for shift in (0, 8, 16, 24):
outf.write(bytearray([(val >> shift) & 0xff]))
Тут все просто. Выполним одну из следующих команд для полученных файлов:
cp uc_intel.gz /bootbank/uc_intel.b00
cp uc_amd.gz /bootbank/uc_amd.b00
Далее можно переходить к шагу 5.
4. Метод создания VIB-пакета и его установки.
Тут нужно использовать утилиту VIB Author, которую можно поставить на Linux-машину (на данный момент утилита идет в RPM-формате, оптимизирована под SuSE Enterprise Linux 11 SP2, который и предлагается использовать). Скачайте файл cpu-microcode.xml и самостоятельно внесите в него изменения касающиеся версии микрокода.
Затем делаем VIB-пакет с помощью следующей команды:
Затем проверьте наличие файлов uc_*.b00, которые вы сделали на шаге 2, в директории /altbootbank.
5. Тестирование.
После перезагрузки хоста ESXi посмотрите в лог /var/log/vmkernel.log на наличие сообщений MicrocodeUpdate. Также можно посмотреть через vish в файлы /hardware/cpu/cpuList/*, в которых где-то в конце будут следующие строчки:
Number of microcode updates:1
Original Revision:0x00000011
Current Revision:0x00000017
Это и означает, что микрокод процессоров у вас обновлен. ESXi обновляет микрокод всех процессоров последовательно. Вы можете проверит это, посмотрев параметр Current Revision.
Также вы можете запретить на хосте любые обновления микрокода, установив опцию microcodeUpdate=FALSE в разделе VMkernel boot. Также по умолчанию запрещено обновление микрокода на более ранние версии (даунгрейд) и на экспериментальные версии. Это можно отключить, используя опцию microcodeUpdateForce=TRUE (однако микрокод большинства процессоров может быть обновлен только при наличии цифровой подписи вендора). Кроме того, чтобы поставить экспериментальный апдейт микрокода, нужно включить опции "debug mode" или "debug interface" в BIOS сервера, после чего полностью перезагрузить его.
Перейдите на надежную платформу со скидкой 25% и обновите VMware vSphere Standard, Enterprise или Enterprise Plus до версии vSphere with Operations Management.
Используйте надежную платформу виртуализации с поддержкой интеллектуальных процессов, благодаря которой компании любых размеров могут обеспечить наивысшие уровни обслуживания приложений и добиться максимальной окупаемости инвестиций в оборудование.
По условиям специального предложения предоставляется скидка 25% при обновлении VMware vSphere Standard, Enterprise или Enterprise Plus до версии vSphere with Operations Management.
Получить скидку просто: отправьте запрос менеджеру с сайта интернет-магазина Softline.
Специальное предложение распространяется на заказчиков, которые приобрели VMware vSphere Standard, Enterprise или Enterprise Plus до 1 февраля 2015 г. и имеют действующие договоры подписки и поддержки.
Дополнительные условия:
При переходе с vSphere Standard, Enterprise или Enterprise Plus на равноценную или более полную редакцию vSphere with Operations Management заказчики получают 25-процентную скидку от цены по каталогу.
Специальное предложение доступно всем заказчикам из коммерческого, образовательного и государственного секторов.
Данное специальное предложение нельзя комбинировать с другими специальными предложениями и скидками на продукты VMware.
На днях компания VMware раскрыла подробности своего нового решения Project Enzo, которое предназначено для создания единой точки управления виртуальными ПК и приложениями, которые размещены как в корпоративной инфраструктуре, так и в облаке. Небольшой обзор проекта:
Project Enzo состоит из двух основных компонентов:
Enzo Smart Node - компонент оркестрации операций с виртуальными ПК и приложениями (он отвечает также за поддержку и обслуживание узлов для выполнения виртуальных ПК).
Enzo cloud control plane - веб-панель управления на стороне сервисов VMware.
Панель управления объединяет в себе функции, которые сейчас доступны из следующих разрозненных компонентов инфраструктуры виртуальных ПК:
Выглядеть это будет подобным образом (сейчас похоже выглядит интерфейс AirWatch 8):
Сам доступ к панели управления Project Enzo будет организован через VMware vCould Air. Администратор может создавать образы виртуальных ПК (и физических, если будет поддерживаться VMware Mirage), сами десктопы и пулы приложений, которые потом можно назначать пользователям:
Также будут средства статистики и мониторинга:
Как мы уже сказали, будут поддерживаться не только виртуальные ПК VMware Horizon View, но и облачные ПК, которые сейчас работают на платформе Horizon DaaS (продукт купленной компании Desktone).
С точки зрения аппаратной платформы, технология Smart Node в Project Enzo будет поддерживать архитектуры EVO:RAIL и будущую EVO:RACK.
VMware обещает предоставить ранний доступ к бета-версии решения уже в конце лета, следите за обновлениями.
Как вы все знаете, недавно вышла платформа виртуализации VMware vSphere 6.0, и мы много писали о ее новых возможностях. На одном из блогов появились полезные таблички, в которых просто и понятно описаны численные и качественные улучшения VMware vSphere 6.0 по сравнению с прошлыми версиями - 5.1 и 5.5. Приведем их тут.
Улучшения гипервизора VMware ESXi:
Улучшения на уровне виртуальных машин:
Улучшения на уровне средства управления VMware vCenter:
Компания VMware анонсировала плагин для мониторинга состояния кластера хранилищ - Virtual SAN 6.0 Health Check Plugin. Напомним, что о возможностях VSAN 6.0 мы писали вот тут.
На самом деле, новый плагин от VMware полезен не только тем, что мониторит состояние компонентов решения во время работы, но и позволяет понять, что вы все развернули и настроили правильным образом, а кластер готов к промышленной эксплуатации. Расскажем о новом плагине на основе описания, которое привел Cormac Hogan.
Плагин состоит из двух компонентов: плагин для vCenter и установочные VIB-пакеты для хостов VMware ESXi. Для vCenter под Windows доступен MSI-установщик плагина, а для vCSA есть соответствующий RPM-пакет. По умолчанию Healthcheck-сервис отключен, когда вы нажмете кнопку "Enable" - на все хосты ESXi установится VIB-пакет агента.
После установки VIB'а, если у вас есть DRS-кластер, хосты будут переходить в Maintenance Mode и перезагружаться, поочередно накатывая обновление. Если DRS-кластера нет, то придется делать это вручную.
После установки агентов, вы будете видеть состояние основных компонентов в разделе Monitor > Virtual SAN:
Важный момент - плагин проверяет совместимость вашего оборудования с требованиями VMware Compatibility Guide к кластеру Virtual SAN, что обычно является головной болью администраторов vSphere. Если vCenter имеет доступ в интернет, то можно напрямую загрузить базу данных HCL, если же нет - ее можно скачать вручную и импортировать.
Прикольная функция - каждая проверка привязана к базе знаний VMware, поэтому если у вас загорелось предупреждение или ошибка, можно нажать кнопку "Ask VMware", и откроется страничка с подробной информацией по теме:
Интересно также то, что Virtual SAN Health Check Plugin ведет себя не только реактивно, реагируя на возникающие ошибки, но и способен выполнять набор проактивных тестов. Например, это может быть полезно, когда нужно проверить кластер хранилищ перед его вводом в промышленную эксплуатацию - проверить состояние виртуальных машин, эффективную ширину канала между узлами и т.п. Ну и, конечно, же полезно посмотреть результаты теста производительности, они будут показаны в колонках IOPS и Latency:
Кстати, можно регулировать время выполнения теста.
Также есть еще одна важная и полезная вещь - поддержка Support Assistant. Если у вас есть открытый Service Request (SR), логи могут быть загружены через Support Assistant и ассоциированы с вашим SR.
На сайте проекта VMware Labs появилась очередная полезная для системных администраторов утилита - Horizon View Events Database Export Utility. С помощью этого средства можно экспортировать базу данных VMware View Events Database:
Данные экспортируются в формат .CSV, можно выбрать, какие колонки таблицы событий экспортировать. При экспорте доступны очень широкие возможности по фильтрации экспортируемых событий, а именно:
Временной диапазон событий
Серьезность события
Источник события (модули "Broker", "Admin", "Agent" и "Vlsi")
Тип сессии (application или desktop)
Имена пользователей
Выбранные пулы виртуальных ПК
Тип событий
Данные можно вытаскивать как из live-базы данных, так и из исторических таблиц. Для работы утилиты понадобится Microsoft .NET 3.5 и инфраструктура VMware View 5.x или более поздней версии.
Скачать утилиту Horizon View Events Database Export Utility можно по этой ссылке.
Компания StarWind, производитель лучшего средства для создания программных отказоустойчивых хранилищ Virtual SAN, выпустила два интересных документа на тему поддержки технологий
Второй документ - StarWind Virtual SAN ODX (Off-loaded Data Transfer) Configuration and Performance Tuning Guide - расскажет о том, как можно узнать включена ли поддержка ODX со стороны гипервизора Microsoft Hyper-V. Так же как и VAAI у VMware, технология ODX у Microsoft позволяет передать часть операций гипервизора с хранилищем на сторону дискового массива, что существенно повышает производительность ВМ.
Таги: StarWind, Whitepaper, VAAI, ODX, VMware, Microsoft
Не так давно мы писали про архитектуру и возможности технологии VVols в VMware vSphere 6, которая позволяет использовать хранилища виртуальных машин напрямую в виде томов на дисковом массиве за счет использования аппаратных интеграций VASA (vSphere APIs for Storage Awareness).
На днях компания VMware выпустила на эту тему преинтересный документ "vSphere Virtual Volumes Getting Started Guide", который вкратце описывает саму технологию, а также приводит пошаговое руководство по использованию vSphere Web Client для быстрого старта с VVols:
Основные темы документа:
Компоненты vSphere Virtual Volumes
Требования для развертывания VVols
Настройка VVols на практике
Совместимость VVols с другими продуктами и технологиями VMware
Команды vSphere Virtual Volumes CLI
Интересно также рассматривается архитектура взаимодействия между компонентами VVols:
Документ интересный и полезный, так как составлен в виде пошагового руководства по настройке политик хранения, маппинга хранилищ на эти политики и развертывания ВМ на томах VVols.
Таги: VMware, VVols, Whitepaper, vSphere, Web Client
А знали ли вы, что есть простой путь, как можно открыть виртуальную машину, сделанную в Oracle VirtualBox, в продуктах VMware Workstation или VMware Fusion?
Делается это очень просто. Машину из VirtualBox нужно экспортировать в формате OVA (Open Virtualization Format Archive, файл .ova):
и затем импортировать в VMware Workstation, VMware Fusion или VMware Player (просто открыть ova-файл):
После импорта машины нужно:
Удалить VirtualBox Guest Additions из гостевой ОС через Uninstall/remove.
Некоторое время назад мы писали про обработку гипервизором VMware vSphere таких состояний хранилища ВМ, как APD (All Paths Down) и PDL (Permanent Device Loss). Вкратце: APD - это когда хост-сервер ESXi не может получить доступ к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды, а PDL - это когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось.
Так вот, в новой версии VMware vSphere 6.0 появился механизм VM Component Protection (VMCP), который позволяет обрабатывать эти ситуации со стороны кластера высокой доступности VMware HA в том случае, если в нем остались другие хосты, имеющие доступ к виртуальной машине, оставшейся без "хост-хозяина".
Для того чтобы это начало работать, нужно на уровне кластера включить настройку "Protect against Storage Connectivity Loss":
Далее посмотрим на настройки механизма Virtual Machine Monitoring, куда входят и настройки VM Component Protection (VMCP):
С ситуацией PDL все понятно - хост больше не имеет доступа к виртуальной машине, и массив знает об этом, то есть вернул серверу ESXi соответствующий статус - в этом случае разумно выключить процесс машины на данном хосте и запустить ВМ на других серверах. Тут выполняется действие, указанное в поле Response for a Datastore with Permanent Device Loss (PDL).
Со статусом же APD все происходит несколько иначе. Поскольку в этом состоянии мы не знаем пропал ли доступ к хранилищу ВМ ненадолго или же навсегда, происходит все следующим образом:
возникает пауза до 140 секунд, во время которой хост пытается восстановить соединение с хранилищем
если связь не восстановлена, хост помечает датастор как недоступный по причине APD Timout
далее VMware HA включает счетчик времени, который длится ровно столько, сколько указано в поле Delay for VM failover for APD (по умолчанию - 3 минуты)
по истечении этого времени начинается выполнение действия Response for a Datastore with All Paths Down (APD), а само хранилище помечается как утраченное (NO_Connect)
У такого механизма работы есть следующие особенности:
VMCP не поддерживает датасторы Virtual SAN - они будут просто игнорироваться.
VMCP не поддерживает Fault Tolerance. Машины, защищенные этой технологией, будут получать перекрывающую настройку не использовать VMCP.
На днях компания VMware выпустила документ "VMware AlwaysOn Desktop", который будет интересен всем тем, кто использует или планирует инфраструктуру виртуальных ПК на базе решения VMware Horizon View. Особенно, если вы хотите добиться непрерывной доступности ваших десктопов и приложений.
В данном документе из 30 страниц рассматривается VDI-архитектура, обеспечивающая постоянную доступность виртуальных ПК за счет Active/Active-конфигурации датацентров (View Pods). В каждом из сайтов есть два кластера - для управления (Active Directory, View Connection Manager, Security Server и т.п.) и для размещения, собственно, виртуальных ПК. Кроме того, есть третий сайт (Site C), который содержит legacy-приложения, к которым происходит доступ с машин как первого, так и второго сайтов.
В синхронизированном состоянии (за счет ПО для репликации) находятся как мастер-образы виртуальных ПК (base image), так и пользовательские данные, чтобы пользователи VDI-инфраструктуры могли получить к ним доступ со стороны любого сайта. Интересно, что репликацию предлагается организовать средствами продукта Veeam Backup and Replication.
В документе рассматривается не только реализация этой архитектуры, но и такие вещи как мониторинг состояния инфраструктуры средствами VMware vCenter Operations Manager for View, а также обеспечение безопасности средствами продуктов vShield.
В феврале этого года VMware приобрела компанию Immidio, которая выпуска продукт Immidio Flex+, предназначенный для управления пользовательскими окружениями в виртуальной и физической инфраструктуре. Теперь этот продукт переименован в VMware User Environment Manager (UEM) и добавлен в состав продуктовой линейки VMware Horizon.
В понятие окружение (user environment) включаются:
настройки приложений
параметры групповых политик (на базе ADMX-файлов)
сетевые ресурсы и ярлыки
настройки принтеров
С помощью VMware User Environment Manager можно сделать все это доступным пользователю, как в физическом или виртуальном ПК предприятия, так и в "облачном десктопе" (например, через решения Desktone).
Основные возможности VMware UEM:
Средства для управления профилями пользователей и политиками Windows XP/7/8.x/Server 2008/12
Настройки пользователя переезжают за ним на другие устройства и географические локации
Поддержка физических, виртуальных и облачных инфраструктур
Возможность быстрого добавления и удаления профиля пользователя
Настройки окружения динамически адаптируются к устройству пользователя и его операционной системе и приложениям (Just-in-time-settings)
Напомним, что у VMware уже был продукт View Persona Management, но он покрывал только виртуальные ПК, а с помощью VMware User Environment Manager можно использовать все существующие ПК предприятия, причем одновременно. Да и UEM весьма проще в настройке и эксплуатации.
Вот таким решение Immidio Flex+ было перед покупкой VMware:
Ну а о том, как оно позиционируется сейчас, можно посмотреть на сайте VMware:
VMware User Environment Manager доступен как часть VMware Horizon Enterprise, кроме того для пользователей Citrix он доступен как часть VMware Horizon Application Management Bundle. Также он доступен к заказу и как standalone-продукт.
Основные компоненты решения VMware UEM:
FlexEngine – часть клиентского ПО Flex+ client, которое нужно установить на все компьютеры, которые будут управляться UEM.
SyncTool – утилита для синхронизации настроек пользователей, в основном для медленных соединений. Она синхронизирует ресурсы профиля и конфигурационные файлы, что позволяет пользователю работать офлайн.
Active Directory – средство настройки FlexEngine через Group Policy. Шаблоны предоставляются в форматах .ADM и .ADMX.
Central Config share – это центральное хранилище файлов конфигурации, которые могут быть в форматах .XML и .INI.
Network folder per user – это общая папка пользователя, которая содержит ресурсы профиля, в том числе архивы, бэкапы и логи в ZIP-формате.
Management Console – центральная консоль управления, которую можно поставить на любой десктоп или сервер.
Application Profiler – профилировщик приложений, который упрощает создание конфиг-файлов с преднастроенной конфигурацией.
Helpdesk Support Tool – утилита, которая предоставляет возможности технической поддержки, включая средства по работе с бэкапами, а также средства анализа текущих профилей и просмотра логов.
Для тех из вас, кто не смог виртуально присутствовать на ивенте, доступна полноценная запись сессий форума:
Среди докладов и сессий вопросов и ответов можно найти актуальную информацию о различных продуктах VMware, таких как vSphere, VSAN, NSX, vRealize Operations, Horizon View и других.
Приятно, что интерфейс доступа к материалам сделали в интерактивном формате, а не скучным списком записанных сессий. Запись доступна для всех желающих после простой регистрации.
На днях компания VMware сделала пару интересных анонсов в сфере облачных вычислений. Одним из таких анонсов стал Project Photon - легковесная ОС, построенная на базе Linux-ядра, предназначенная для использования в облачных инфраструктурах.
Project Photon - это ОС для так называемых cloud-native applications, то есть приложений, изначально созданных для облачной инфраструктуры и запакованных в контейнеры виртуальных машин. Напомним, что VMware уже делала шаги в этом направлении с инициативой CoreOS, а также интеграцией с механизмом Docker (также см. вот тут). Теперь же VMware дошла и до создания своей ОС на базе компонентов с открытым исходным кодом, чтобы обеспечить пользователям полный набор инструментов для создания приложений, которые просто масштабируются в облачной среде.
Project Photon будет обладать следующими возможностями:
Поддержка большинства форматов Linux-контейнеров приложений, таких как Docker, rkt и Garden от компании Pivotal (дружественная VMware компания, ее директор, Пол Мориц, был раньше директором VMware).
Минимальный размер машины на диске (около 300 МБ).
Инструменты для миграции приложений в контейнерах из среды разработки в производственную среду.
Возможности обеспечения безопасности, централизованного управления и оркестрации операций на базе инструментов, доступных для платформы VMware vSphere.
Обзор решения Project Photon для запуска контейнеров на базе движков Docker и Rocket Containers (от создателей CoreOS):
На данный момент код Project Photon доступен для всех желающих на GitHub. Вот тут можно прочитать небольшой обзор процесса развертывания.
Одновременно с Project Photon был запущен и Project Lightwave, который призван решать задачи аутентификации и управления доступом в среде контейнеризованных приложений с сотнями пользователей. Это средство позволит централизованно управлять идентификацией пользователей через интеграцию с VMware vSphere и vCloud Air, а также осуществлять управление сертификатами и ключами в облачной среде. Lightwave поддерживает большинство открытых стандартов в области аутентификации и обеспечения безопасности, таких как Kerberos, LDAP v3, SAML, X.509 и WS-Trust.
Демонстрация работы решения Project Lightwave:
Код проекта Project Lightwave также будет доступен как Open Source в репозитории на GitHub. Его финальный релиз ожидается через несколько месяцев.
Мы уже упоминали компанию opvizor на нашем сайте - она тогда называлась еще Icomasoft. Она время от времени делает утилитки для виртуальной инфраструктуры. Оказалось у нее есть могущая оказаться полезной многим утилита Snapwatcher Enterprise Edition.
Как знают администраторы VMware vSphere, снапшоты виртуальных машин в большой виртуальной инфраструктуре - это просто беда. Они плодятся неаккуратными пользователями и администраторами, создаются пачками в тестовых системах и почему-то иногда не удаляются средствами резервного копирования. Для решения таких проблем и предлагается использовать Snapwatcher:
Что умеет Snapwatcher:
Отслеживание имеющихся снапшотов ВМ на различных vCenter.
Отчет о количестве паразитно занятого снапшотами дискового пространства.
Нахождение некорректных снапшотов (например, после средств бэкапа).
Удаление ненужных снапшотов централизованно, из одной консоли.
Починка невалидных снапшотов (очевидно, работает не всегда - но весьма интересная функция).
Отслеживание истории снапшотов.
Как это работает:
Сам продукт Snapwatcher платный ($200 за лицензию на пользователя), но у него есть триальная версия. А так как в большинстве случаев проблема со снапшотами в виртуальной среде - разовая, то можно скачать Snapwatcher бесплатно и все пофиксить.
Этот вебинар продолжает серию технических мероприятий StarWind, в рамках которых подробно рассматриваются довольно интересные глубокие темы. На этот раз речь пойдет об использовании технологий Offloaded Data Transfer (ODX) и APIs for Array Integration (VAAI), которые позволяют передать исполнение до 30% дисковых операций на сторону SAN (дисковый массив или серверы-хранилища), не затрагивая подсистему ввода-вывода хост-серверов Microsoft Hyper-V или VMware ESXi.
Мероприятие пройдет послезавтра, 21 апреля в 21-00 по московскому времени.
Компания VMware довольно оперативно выставила на всеобщее обсуждение бета-версию своего основного руководства по обеспечению информационной безопасности виртуальной инфраструктуры vSphere 6.0 Hardening Guide.
В этой Excel-табличке на данный момент общим списком собраны основные рекомендации (подчеркнем, что список неполный, и в релизной версии рекомендаций будет больше). Часть рекомендаций была удалена из руководства или перемещена в документацию - список этих пунктов приведен вот тут.
Основное, что ушло из руководства - это операционные рекомендации, то есть что следует делать правильно во время эксплуатации VMware vSphere. Это переместилось в соответствующие разделы документации по платформе. В итоге, осталась сухая выжимка из необходимых настроек безопасности, которые нужно правильно применять в своей инфраструктуре.
Гайдлайны сгруппированы в профили риска (Risk Profiles) - их всего три штуки (1, 2, 3), и они определяют степень критичности их применения. Уровень 1 - только для высокозащищенных систем, 2 - для окружений с чувствительными данными (например, персональными), 3 - для обычных производственных систем.
Также прибавились префиксы компонентов для рекомендаций:
Было: enable-ad-auth
Стало: ESXi.enable-ad-auth
Кстати, интересное видео о том, как нужно использовать Hardening Guide:
Компания VMware с радостью примет пожелания и замечания к руководству, которые можно оставить вот тут. Релиз финальной версии VMware vSphere 6.0 Hardening Guide ожидается во втором квартале 2015 года.
Не так давно мы писали про технологию Virtual Volumes (VVols), которая полноценно была запущена в новой версии платформы виртуализации VMware vSphere 6. VVols - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее.
VVols - это один из типов хранилищ (Datastore) в vSphere:
Тома vVOLs создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы сейчас видите в папке с ВМ, создается отдельный vVOL.
Многие администраторы задаются вопросом: а почему VVols - это крутая штука, нужны ли они вообще? VMware в своем блоге отвечает на этот вопрос. Попробуем изложить их позицию здесь вкратце.
Ну, во-первых, VVols дают возможность создавать аппаратные снапшоты, клоны и снапклоны на уровне одной виртуальной машины, а не целых LUN, но это неконцептуально. Вопрос следует понимать глубже.
Все идет из концепции SDDC (Software Defined Datacenter), которая подразумевает абстракцию всех уровней аппаратных компонентов (вычислительные ресурсы, сети, хранилища) на программный уровень таким образом, чтобы администратор виртуальных ресурсов не ломал себе голову насчет физического устройства датацентра при развертывании новых систем. Иными словами, при создании виртуальной машины администратор должен определить требования к виртуальной машине в виде политики (например система Tier 1), а программно-определяемый датацентр сам решит где и как эту машину разместить (хост+хранилище) и подключить ее к сети (тут вспомним про продукт VMware NSX).
С точки зрения хранилищ (SDS - software defined storage) эта концепция реализуется через подход Storage Policy Based Management (SPBM), предполагающий развертывание новых систем на хранилищах, которые описаны политиками. Этого мы уже касались в статье "VMware vSphere Storage DRS и Profile Driven Storage - что это такое и как работает".
Если раньше дисковый массив определял возможности хранилища, на котором размещалась ВМ (через LUN для Datastore), и машина довольствовалась тем, что есть, то теперь подход изменился: с Virtual Volumes, к которым привязаны политики виртуальных машин, сама машина "рассказывает" о своих требованиях дисковому массиву, который уже ищет, где он может ее "поселить". Этот подход является более правильным с точки зрения автоматизации и человеческого фактора (ниже расскажем почему).
Представим, что у нас есть три фактора, которые определяют качество хранилища:
Тип избыточности и размещения данных (например, RAID - Stripe/Mirror)
Наличие дедупликации (да/нет)
Тип носителя (Flash/SAS/SATA)
Это нам даст 12 возможных комбинаций типов LUN, которые мы можем создать на дисковом массиве:
Соответственно, чтобы учесть все такие комбинации требований при создании виртуальных хранилищ (Datastores), мы должны были бы создать 12 LUN. Но на этом проблемы только начинаются, так как администратор всегда стремится выбрать лучшее с его точки зрения доступное хранилище, что может привести к тому, что LUN1 у нас будет заполнен под завязку системами разной критичности, а новые критичные системы придется размещать на LUN более низкого качества.
На помощь тут приходят политики хранилищ (VM Storage Policies). Например, мы создаем политики Platinum, Silver и Gold, для которых определяем необходимые поддерживаемые хранилищами функции, которые обоснованы, например, критичностью систем:
Если говорить о примере выше, то Platinum - это, например, хранилище с характеристиками LUN типов 1 и 3.
Интерфейс vSphere Web Client нам сразу показывает совместимые и несовместимые с этими политиками хранилища:
Так вот при развертывании новой ВМ администратору должно быть более-менее неважно, на каком именно массиве или LUN будет расположена машина, он должен будет просто выбрать политику, которая отражает его требования к хранилищу. Удобно же!
При создании политики администратор просто выбирает провайдера сервисов хранения (в данном случае массив NetApp с поддержкой VVols) и определяет необходимые поддерживаемые фичи для набора правил в политике:
После этого при развертывании новой виртуальной машины администратор просто выбирает нужную политику, зная обеспечиваемый ей уровень обслуживания, и хранилищем запускается процесс поиска места для новой ВМ (а точнее, ее объектов) в соответствии с определенными в политике требованиями. Если эти требования возможно обеспечить, то создаются необходимые тома VVOls (как бы отдельные LUN для объектов машины). Таким образом, с помощью политик машины автоматически "вселяются" в пространство хранения дисковых массивов в соответствии с требованиями, не позволяя субъективному человеку дисбалансировать распределение машин по хранилищам различных ярусов. Вот тут и устраняется человеческий фактор, и проявляется сервисно-ориентированный подход: не машину "селят" куда скажет дядя-админ, а система выбирает хранилище для ВМ, которое соответсвует ее требованиям.
Компания VMware на днях выпустила весьма интересный документ "VMware Horizon 6 Storage Considerations", в котором рассматриваются различные рекомендации при построении инфраструктуры хранилищ для виртуальных ПК на базе решения VMware Horizon View, а также других продуктов EUC-линейки VMware.
Документ весьма технический и будет полезен тем, кто хочет разобраться в деталях производительности хранилищ, от которых будет зависеть скорость работы виртуальных ПК на платформе VMware Horizon. Например, вот уровни абстракции хранилищ и структура задержек, возникающих при прохождении SCSI-команд к данным виртуальной машины (об этом мы подробно писали вот тут):
Помимо, собственно, самого решения VMware Horizon View, в документе рассматриваются еще и такие продукты, как App Volumes, Mirage, Workspace Portal и Virtual SAN.
Основные разделы:
VMware Horizon Architecture
Capacity and Sizing Considerations
Storage Platform Considerations
VMware App Volumes Storage Considerations
Workspace Portal Storage Considerations
Mirage Storage Considerations
Horizon 6 Storage Enhancements
Скачать "VMware Horizon 6 Storage Considerations" можно по этой ссылке.
Вскоре после выхода платформы виртуализации VMware vSphere 6.0 компания VMware выпустила апрельский патч VMware ESXi 6.0 (Build 2615704). Обновление ESXi600-201504001 описано в KB 2111975. В данном билде есть только исправления багов, его статус - Critical.
Какие ошибки были исправлены:
Выпадение в "розовый экран смерти" при промотке логов хоста через прямое подключение к консоли сервера - DCUI (по комбинации клавиш ALT+F12).
Stateless-хосты VMware ESXi (бездисковые, загруженные в память) могут упасть при применении профиля из VMware Host Profiles (с ошибкой A specified parameter was not correct: dvsName).
Производительность виртуальной машины с ОС Windows, для которой включена технология Fault Tolerance, может неожиданно сильно упасть.
Баг с непредоставлением сервером vCenter лицензии stateless-хосту.
Когда у вас много виртуальных машин с небольшой памятью (< 128 МБ), в процессе NUMA remapping может выскочить "розовый экран смерти".
Как мы видим, баги в ESXi 6.0 еще есть, и пока некуда торопиться с обновлением с версий 5.x.
Скачать апрельский патч VMware ESXi 6.0 (Build 2615704) можно с VMware Patch Portal, введя номер билда в поиск.
Как многие знают, начиная с версии VMware View 6.0, компания VMware вступила в открытую конкуренцию с Citrix и ее продуктом XenApp, заявив поддержку виртуальных ПК и приложений на хостах Microsoft RDSH.
То есть, VMware предоставляет доступ к приложениям, исполняемым на серверах RDS, осуществляя их так называемую "доставку" в бесшовных окнах:
Видимо, дела с рапространением этой фичи у VMware идут не очень хорошо, поэтому она старается популяризовать ее и , в частности, раскрывает подробности улучшений этих техник в своем блоге.
Посмотрим, что мы имеем в плане поддержки RDSH в VMware Horizon View на данный момент:
1. В VMware View 6.0 появилась поддержка Location Based Printing для RDSH.
Эта поддержка появилась в обновлении Horizon 6.0.1 / Horizon Client 3.1, которое вышло вскоре после основного релиза версии 6.0. Теперь с клиентов Windows, Linux и Mac за счет технологий ThinPrint можно печатать из доставляемых через RDSH рабочих столов и приложений на локальных и сетевых принтерах клиента.
2. Перенаправление сканера для десктопов RDSH и приложений.
В декабре прошлого года, VMware выпустила Horizon 6.0.2 и Horizon Client 3.2. В этом релизе появилось перенаправление сканеров стандартов TWAIN и WIA. Теперь можно отсканировать документ из приложения или десктопа, предоставляемого через RDSH. При этом при передаче картинки происходит компрессия, что снижает требования к каналу. На данный момент эта фича работает только для Windows-клиентов.
3. Поддержка аутентификации через смарт-карты.
В версии VMware Horizon View 6.1 и Horizon Client 3.3 появилась возможность проходить аутентификацию в приложениях и Windows-десктопах RDSH через подключенные локально ридеры смарт-карт. Пока поддерживается только Windows-системы.
4. Поддержка перенаправления USB-устройств для RDSH.
Для VMware Horizon View 6.1 и выше теперь поддерживается перенаправление локальных USB-устройств (их список ограничен) в виртуальных ПК RDSH на платформах Windows Server 2012 и 2012 R2.
Пользователь теперь имеет возможность получить прямой доступ к файлам на флешке для чтения-записи из приложения или ПК, работающего через RDSH. Также пока только для Windows-клиентов.
5. Поддержка перенаправления локальных дисков для RDSH.
Аналогично прошлому пункту - теперь можно локальные диски пробросить в ПК на RDSH или предоставить доступ к ним приложениям. Также актуально только для Windows-клиентов, но будет добавлена поддержка Mac и Linux.
В целом, VMware Horizon View 6.1 с точки зрения доставки приложений, конечно же, далеко не так хорош, как Citrix XenApp, но раз VMware занялась этой проблемой - то, возможно, скоро догонит и перегонит Citrix.
Незадолго до выпуска платформы виртуализации VMware vSphere 6 компания VMware решила обновить пути сертификации технических специалистов по продуктам линейки, привязанных к шестой версии базового продукта. Итак, теперь у нас есть Certification Roadmap for 2015, которая графически представлена следующим образом...
Какое-то время назад мы писали о том, что на сайте проекта VMware Labs доступен пакет VMware Tools для виртуальных серверов VMware ESXi, работающих как виртуальные машины. В версии VMware vSphere 6 этот пакет по умолчанию уже вшит в ESXi 6.0, и ничего ставить дополнительно не нужно:
Это можно также просто проверить с помощью консольной команды:
Как вы знаете, в обновленной версии платформы виртуализации VMware vSphere 6.0 появились не только новые возможности, но и были сделаны существенные улучшения в плане производительности (например, вот).
В компании VMware провели тест, использовав несколько виртуальных машин с базами данных SQL Server, где была OLTP-модель нагрузки (то есть большой поток небольших транзакций). Для стресс-теста БД использовалась утилита DVD Store 2.1. Архитектура тестовой конфигурации:
Сначала на хосте с 4 процессорами (10 ядер в каждом) запустили 8 виртуальных машин с 8 vCPU на борту у каждой, потом же на хосте 4 процессорами и 15 ядер в каждом запустили 8 ВМ с 16 vCPU. По количеству операций в минуту (Operations per minute, OPM) вторая конфигурация показала почти в два раза лучший результат:
Это не совсем "сравнение яблок с яблоками", но если понимать, что хосты по производительности отличаются не в два раза - то результат показателен.
Интересен также эксперимент с режимом Affinity у процессоров для "большой" виртуальной машины. В первом случае машину с 60 vCPU привязали к двум физическим процессорам хоста (15 ядер на процессор, итого 30 ядер, но использовалось 60 логических CPU - так как в каждом физическом ядре два логических).
Во втором же случае дали машине те же 60 vCPU и все оставили по дефолту (то есть позволили планировщику ESXi шедулить исполнение на всех физических ядрах сервера):
Результат, как мы видим, показателен - физические ядра лучше логических. Используйте дефолтные настройки, предоставьте планировщику ESXi самому решать, как исполнять виртуальные машины.