Как некоторые из вас знают, в августе компания VMware объявит об окончании поддержки версий платформ VMware vSphere 5.0 и 5.1 согласно своему расписанию жизненного цикла продуктов. Поэтому самое время задуматься об обновлении инфраструктуры на VMware vSphere 6.0. Но как проверить, поддерживаются ли ваши серверы, на которых исполняются старые версии платформ, новый релиз ESXi 6.0? Можно, конечно, смотреть в VMware HCL для каждого сервера, но это очень долго и муторно.
Как раз для нуждающихся в ускорении этой процедуры пользователей на сайте virten.net появился скрипт PowerCLI Check-HCL function, который позволяет вывести все версии VMware vSphere, которые поддерживает каждый из ваших хост-серверов. Результат работы скрипта выглядит следующим образом:
Скрипт соединяется с вашим сервером VMware vCenter, получает оттуда хосты ESXi и для каждого проверяет, с какими релизами vSphere хост данном модели совместим (обратите внимание, что для каждого из хостов указывается модель сервера).
Скрипт основан на предыдущих наработках автора - JSON based HCL и Check-HCL. Снипет для использования этих функций весьма прост:
По заявлению автора скрипты очень хорошо работают для оборудования HP и Dell, а также дают приемлемые результаты для серверов IBM и Cisco. Для остальных - надо качать, запускать и тестировать самостоятельно.
Давно что-то мы не писали про обновления тонкого клиента для управления виртуальной инфраструктурой VMware vSphere HTML5 Web Client (в прошлый раз мы писали про версии 1.12 и 1.13), а за прошедшие пару недель вышло сразу 3 обновления - версии Web Client 1.14, 1.15 и 1.16.
Напомним, что VMware vSphere HTML5 Web Client заменит снимаемый с производства vSphere C# Client в следующем релизе серверной платформы виртуализации vSphere.
Новые возможности последних версий веб-клиента:
Работает мониторинг состояния аппаратных компонентов (состояния сенсоров).
Возможность создания нового объекта Datacenter.
Добавление новых адаптеров VMkernel.
Можно редактировать расширенные настройки HA advanced settings.
Можно менять действие HA response для условий APD и PDL.
Возможность создания снапшота запущенной виртуальной машины с ее памятью.
Назначение и удаление тэгов объектов, которые видны для всех объектов.
Новый список "Connectivity and Multipathing" для VMFS-хранилищ ([Datastore] -> Configure -> Connectivity and Multipathing).
Графики производительности (performance charts) теперь имеют возможность обновляться в реальном времени.
Возможность ввода адреса IPv4 при кастомизации ОС в процессе клонирования виртуальной машины.
Хосты ESXi можно перевести в режим standby и снова включить их обратно.
Можно редактировать HA datastores for heartbeat.
Можно менять политики старта сервисов при загрузке ESXi и состояние сервисов.
Возможность изменения кастомных атрибутов (имена и значения).
Создание виртуальной машины в папке.
Новый Datastore wizard, который позволяет выбрать хост ESXi.
Скачать VMware vSphere HTML5 Web Client версии 1.16 можно по этой ссылке.
Этот документ посвящен тому, как необходимо анализировать, планировать и строить архитектуру инфраструктуры VDI (Virtual Desktop Infrastructure), которая будет стандартизирована по составу, унифицированно управляться, легко масштабироваться и быстро реагировать на изменения, которые рождают требования бизнеса. Звучит булшитово, но зато фундаментально.
Вот как авторы документа представляют себе основные фазы внедрения инфраструктуры виртуальных десктопов на предприятии:
1. Определение основных драйверов бизнеса компании и вариантов использования VDI.
2. Определение сервисов, которые будут доставляться пользователям.
3. Выработка архитектурных принципов и общей концепции построения решения.
4. Подготовка компонентной архитектуры VMware Horizon 7 Enterprise.
5. Планирование развертывания платформы VMware vSphere 6.
6. Планирование физической инфраструктуры и определение состава оборудования.
7. Планирование интеграции сервисов между собой.
8. Планирование взаимодействия пользователей с сервисами через интерфейсы VDI.
В документ включены так называемые Service Blueprints, которые позволяют понять эталонную архитектуру необходимых сервисов в среде виртуальных ПК:
Из документа многим будет полезно узнать и о средстве VMware Identity Manager, которое предоставляет точку входа пользователям компании и реализует рабочее пространство назначенных пользователю десктопов и приложений:
То есть, по-сути, документ представляет собой референсную архитектуру и методологию построения VDI-инфраструктуры, которую можно адаптировать для большинства сценариев корпоративной инфраструктуры. Скачать документ можно по этой ссылке.
Совсем недавно мы писали о том, что на сайте проекта VMware Labs стала доступна новая версия утилиты Horizon Migration Tool, а на днях там появилась еще одна новинка - App Volumes Toolbox. Эта штука соединяется с хостами App Volumes 2.x, 3.x и Horizon Air Hybrid-Mode (он же Enzo) и высасывает данные через нативные REST APIs, чтобы представить их в одной консоли и позволить администраторам производить недоступные через консоль App Volumes операции.
Такие опции конфигурации, как удаление томов AppStacks и управление томами Writable Volumes, доступны в консоли App Volumes Toolbox, что нельзя на данный момент сделать в интерфейсе App Volumes 3.x. Утилита использует нативные вызовы REST API для всех действий.
Вот как использовать App Volumes Toolbox, и что он умеет:
Для пользователей VMware vSphere нам в почту пришло письмо от небольшой группы разработчиков, которая представляет новый продукт Extrasphere. Не так часто встретишь утилиты от русских разработчиков, поэтому мы решили бесплатно пропиарить ребят.
Решение Extrasphere предоставляет бесплатный аналог технологии vMotion, которая доступна без использования vCenter. Ключевая особенность продукта — поддержка бесплатной версии VMware ESXi.
Продукт позволяет:
Менять местоположение дисков виртуальной машины на ESXi без простоя виртуальной машины.
Менять местоположение всех файлов виртуальной машины за счет suspend/resume в конце операции (небольшой простой при переключении будет).
Менять местоположение всех файлов виртуальной машины и/или хост-сервер с использованием общего между хостами хранилища - в конце операции выполняется suspend/resume или выключение/включение, если флаги CPU не поддерживаются принимающим хостом.
Менять местоположение и хост-сервер без использования общего между хостами хранилища с помощью специально виртуального модуля Extrasphere Resharer на базе Linux - в конце операции выполняется suspend/resume или выключение/включение, если флаги CPU не поддерживаются целевым хостом.
Текущие требования и ограничения:
Не поддерживаются виртуальные машины со снапшотами.
Нет поддержки Independent-дисков и дисков RDM в режиме физической совместимости.
Для подключения используется SSH под пользователем root.
Для миграции между хостами необходимо разрешить на ESXi исходящий SSH-трафик.
Скачать Extrasphere можно по этой ссылке. В целом-то тема давно изъезженная, но, мало ли, утилита вам понравится.
На сайте проекта VMware Labs появилась очередная полезная штука - утилита Horizon Migration Tool версии 1.2, предназначенная для миграции виртуализованных приложений и десктопов с платформы Citrix XenApp на платформу VMware Horizon View (теперь поддерживается седьмая версия View). В процессе миграции одна ферма Citrix XenApp переносится в одну или несколько ферм VMware View.
Возможности Horizon Migration Tool:
Валидация агентов View Agent на хостах RDP (как от View Connection Server, так и от XenApp Server).
Создание новых ферм серверов.
Валидация доступности приложений на RDP-хостах.
Миграция приложений и виртуальных ПК на одну или несколько ферм (как новых, так и существующих).
Миграция прав доступа в новые или существующие виртуальные ПК или приложения. Поддерживаются также различные комбинации прав доступа к приложениям.
Проверка окружения на возможность миграции.
Идентификация несовместимых возможностей и конфигураций, которые образуются после миграции.
Утилита работает с Horizon версий 6.2.2 или 7, а также XenApp версий 6.5, 6.0 или 5.0. Скачать Horizon Migration Tool можно по этой ссылке.
Как вы знаете, в последней версии платформы VMware vSphere 6.0 технология кластеров непрерывной доступности VMware Fault Tolerance была существенно улучшена (напомним, что добавили поддержку до 4 vCPU и до 64 ГБ памяти). Также в этом году мы писали о тестах производительности технологии FT, которые показали небольшие издержки на поддержание работы таких кластеров (их проводила сама VMware).
Однако есть и другие результаты тестов Fault Tolerance, которые показывают уже не такие бодрые значения. Кстати, напомним, что для FT желательно иметь 10 GbE соединение, иначе на гигабитном линке вы будете получать вот такое предупреждение (хотя все продолжит работать):
Так вот, посмотрим на результаты тестов, которые были сделаны с помощью бенчмарк-утилиты DVDstore. В качестве приложения для тестов использовался MS SQL Server (8GB памяти, адаптер VMXNET3 NIC и контроллер VMware paravirtual SCSI) а также машина с клиентом DVDstore. Между хостами ESXi, на которых были FT-машины, был организован 10-гигабитный линк.
В качестве команды для тестирования нагрузки на MS SQL Server была использована следующая:
Основной показатель теста OPM (Orders per Minute) - это оранжевые столбцы. Как видим, добавление новых vCPU не сильно повышает производительность системы, а вот включение Fault Tolerance прямо-таки обрушивает параметр OPM практически в 2 раза (на 47%, если быть точным). Результаты в таблице:
FT disabled
FT enabled
Difference
OPM test 1 vCPU
12291
6418
-48%
OPM test 2 vCPU
13164
7023
-47%
OPM test 4 vCPU
14139
7458
-47%
Ну и зеленые столбики показывают, как линейно росло использование полосы пропускания с ростом количества виртуальных процессоров (vCPU) для FT. При этом самое большое CPU Latency наблюдалось для одного vCPU.
В итоге, мы видим, что производительность при включении VMware Fault Tolerance вполне себе существенно падает, по крайней мере, при некоторых видах рабочих нагрузок. Поэтому тут главный совет - тестировать технологию в своей инфраструктуре перед тем, как планировать использовать ее в производственной среде.
Еще на VMworld 2014 компания VMware анонсировала технологию VMware Project Fargo (которая также называлась VM Fork), позволяющую очень быстро сделать работающую копию работающей виртуальной машины на платформе VMware vSphere.
Суть технологии VMFork такова, что "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory), что и родительская ВМ. При этом дочерняя ВМ в общую память писать не может, а для записи собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:
В процессе работы VMFork происходит кратковременное "подвешивание" родительской ВМ (quiescence) с помощью технологии "fast suspend resume" (FSR), после чего дочерняя ВМ "отцепляется" от родительской - происходит реконфигурация машины, включающая в себя назначение нового MAC-адреса, получение нового UUID и другое. При этом ВМ шарят общие ресурсы на чтение и имеют свои уникальные области на запись - это очень удешевляет стоимость ресурсов в перерасчете на одну ВМ на хосте.
После выхода новой версии платформы виртуализации настольных ПК VMware Horizon 7 технология VMFork была переименована в Instant Clone и стала доступна для использования в производственной среде. Помимо удешевления стоимости ресурсов для размещения виртуальных машин, Instant Clone имеет еще несколько преимуществ - это делает развертывание виртуальных машин более гибким и быстрым. Ниже мы рассмотрим особенности этих процессов.
В сочетании с технологией доставки приложений через подключаемые виртуальные диски VMware App Volumes 3.0 и средством управления окружениями User Environment Manager, эти возможности позволяют пользователям получить мгновенный доступ к своим данным, при этом рабочая машина пользователя не "загрязняется" ненужными устанавливаемыми программами и распухающими ветками реестра. Это все позволяет собрать десктоп пользователя на лету из полностью кастомизируемых и доставляемых по требованию "кирпичиков".
Давайте посмотрим, насколько Instant Clone упрощает цикл развертывания новых настольных ПК. Вот так выглядит развертывание связанных клонов (Linked Clones) в инфраструктуре VMware View Composer:
Клонирование виртуального ПК из реплики мастер-образа
Реконфигурация нового ПК
Включение ВМ
Кастомизация машины
Создание контрольной точки нового ПК (checkpoint)
Включение ВМ
Логин пользователя
С использованием Instant Clone процесс заметно упрощается:
Создание копии ВМ в памяти средствами VMFork
Кастомизация машины
Включение ВМ
Логин пользователя
Для администратора виртуальных ПК в пулах Instant Clone удобны тем, что таким десктопам не требуются операции Refresh, Recompose и Rebalance. Ведь после выхода пользователя из ПК его десктоп уничтожается, а перестраивать связанные клоны не требуется. Изменения базового образа проходят "на лету" в течение рабочего дня, а при следующем логине пользователь получает уже обновленные приложения. Также есть возможность принудительного перелогина пользователя для обновления компонентов виртуального ПК (например, фикс в подсистеме безопасности).
Также отпадает необходимость в использовании технологии Content-Based Read Cache (CBRC), ведь виртуальные ПК Instant Clone живут недолго, постоянно выгружаются из памяти при выходе пользователя, и нет нужды прогревать кэш их блоками в памяти, а вот для мастер-ВМ и реплик CBRC вполне себе используется.
Кроме того, теперь не нужны операции wipe и shrink для виртуальных дисков SEsparse, которые позволяют возвращать место на растущем диске для связанных клонов. Виртуальные машины Instant Clone живут недолго, а при их уничтожении дисковое пространство их дельта-дисков возвращается в общий пул пространства хранения.
Ну и в отличие от View Composer, технология Instant Clone не требует наличия и поддержки базы данных для операций с виртуальными ПК, что существенно упрощает обслуживание инфраструктуры виртуальных десктопов.
Многие думают, что пулы Instant Clone трудно создавать, настраивать и поддерживать. Это не так, все делается в несколько простых шагов:
Создаем родительскую виртуальную машину, устанавливаем в ней Windows, оптимизируем ее и активируем лицензионным ключом.
Устанавливаем VMware Tools.
Устанавливаем Horizon Agent и отмечаем фичу Instant Clone для установки.
При добавлении нового пула виртуальных ПК типа Automated/Floating отмечаем Instant Linked Clones.
Помимо того, что с Instant Clone процесс проходит меньшее количество шагов, уменьшается и нагрузка на различные компоненты виртуальной инфраструктуры - меньше операций ввода-вывода, быстрее происходит процесс создания мгновенной копии (скорее освобождаются системные ресурсы), меньше объем взаимодействий с сервером vCenter, а дисковое пространство высвобождается сразу после окончания использования виртуального ПК.
Давайте посмотрим, насколько быстрее это работает на тестах. Развертывание связанных клонов View Composer типовой конфигурации (2 vCPU, 2 GB memory, Windows 7, Office 2010, Adobe 11, 7-Zip, Java) на 15 хост-серверах с использованием HDD-дисков занимает где-то 150-200 минут. А то же самое развертывание 1000 виртуальных машин на базе Instant Clone занимает лишь 25-30 минут. То есть скорость получения новой инфраструктуры десктопов по запросу возрастает в 5-7 раз.
При этом не особо-то и растет нагрузка на сервер VMware vCenter. Поначалу, конечно же, возникает пиковая нагрузка на vCenter при операциях в оперативной памяти с мгновенными копиями ВМ, но в итоге средняя загрузка практически такая же, как и при использовании View Composer - ведь не нужно проходить цикл включения (2 раза) и реконфигурации виртуальной машины (3-4 раза), как это происходит у Composer.
В итоге, можно сказать, что в определенных случаях Instant Clone - это лучшее решение с точки зрения быстродействия и производительности. Когда виртуальную машину нужно получить как можно быстрее, а пользователю после окончания работы она не нужна в том виде, в котором он ее оставил - мгновенные копии позволят ускорить процесс в несколько раз. Примером такого варианта использования может служить колл-центр, где оператор использует виртуальный десктоп для решения определенной задачи технической поддержки, после чего от разлогинивается, уничтожая ненужную в данный момент сущность - свой виртуальный десктоп.
Многие из вас знают, как узнать номер билда того или иного продукта VMware (например у ESXi нужно набрать в консоли vmware -v), но как узнать, какой официальной версии этот номер соответствует? На самом деле, вся эта информация доступна и поддерживается актуальной в базе знаний VMware.
Для поиска нужного соответствия версии и номера билда соответствующего продукта удобно использовать вот такую табличку, содержащую ссылки на страницы KB, которые поддерживаются в состоянии up-to-date со стороны VMware.
В блоге компании VMware появился очень и очень полезный постер vCenter Server Appliance 6.0 Reference Poster, посвященный основным аспекам работы виртуального модуля vCSA для управления инфраструктурой VMware vSphere (vCenter в готовой Linux-машине).
Основные разделы постера:
Requirements and Maximums - здесь указаны требования к виртуальному модулю vCSA и его хранилищам, а также для справки приведены максимумы конфигураций vCenter Server.
Firewall Requirements - требования к портам и соединениям при взаимодействии:
PSC с PSC (Platform Services Controller)
PSC с vCenter Server
vCenter Server с vCenter Server
Migration from Deprecated to Recommended Topology - в этой секции перечислены основные высокоуровневые моменты, касающиеся миграции с устаревших топологий. Эти топологии еще поддерживаются в vSphere 6, но уже не будут работать для следующих версий платформы.
Command Line Interface - здесь приведены команды как для самого виртуального модуля (Appliance Shell), так и для шелла (Bash Shell), которые позволят выполнять основные операции с vCSA.
Knowledge Base (KB) Articles - здесь приведены заголовки 20 основных статей базы знаний (в PDF-документе они являются кликабельными), которые помогут в решении повседневных задач администрирования vCenter Server Appliance.
Скачать VMware vCenter Server Appliance 6.0 Reference Poster можно по этой ссылке. Напомним также, что большинство постеров VMware вы можете найти вот тут.
Ну и вот еще парочка полезных ссылок от VMware на тему топологий vCenter:
У компании Netwrix, выпускающей средства аудита программных решений в виртуальных и физических инфраструктурах, оказывается есть полезное решение, которое может помочь администраторам VMware vSphere в отслеживании изменений, происходящих в компонентах платформы.
Бесплатная утилита Netwrix Change Notifier for VMware позволяет осуществлять мониторинг событий в виртуальной инфраструктуре и оповещать администраторов об изменениях на регулярной основе. Это средство отслеживает изменившиеся конфигурации виртуальных датацентров, хостов VMware ESXi, пулов ресурсов, кластеров, папок, самих виртуальных машин и других объектов.
В результате аудита администратору каждые 24 часа предоставляется отчет по электронной почте в следующем виде (кликабельно):
Очень полезно, что мы видим не только изменения настроек в соответствующих компонентах, но и добавление или удаление объектов. Естественно, под эгидой бесплатной утилиты Netwrix продает и платное решение Netwrix Auditor, которое скажет, кто и когда делал изменения, предоставит расширенный поиск по событиям и репортинг нескольким пользователям, но для маленькой инфраструктуры Change Notifier окажется вполне достаточным.
Feature
Change Notifier
Netwrix Auditor
Automatic daily email reports showing all changes made during the last day
Details on what changed in VMware
Who, when and where details for every change
Before and after values for all modifications
Predefined reports based on SQL Server Reporting Services, with filtering, sorting and exporting options
Google-like search of audit data with custom search queries and custom reports
Out-of-the-box compliance reports mapped to specific regulatory standards (PCI DSS, HIPAA, SOX, FISMA/NIST800-53 and ISO/IEC 27001)
Long-term storage of audit data in a two-tiered (file-based + SQL database) storage system
Email subscriptions to scheduled reports with the ability to choose multiple recipients (or specific folders), delivery frequency and delivery format
Reports on virtual machine sprawl statistics over a selected period of time
Single installation that handles multiple VMware vSphere instances, each with its own unique settings
Advanced cross-system auditing and reporting
Скачать Netwrix Change Notifier for VMware можно по этой ссылке.
VMware продолжает обновлять свой тонкий клиент для управления виртуальной инфраструктурой - VMware vSphere HTML5 Web Client, который заменит снимаемый с производства vSphere C# Client. Еще пару недель назад мы писали про версии 1.10 и 1.11, но на днях уже вышли версии 1.12 и 1.13.
Посмотрим, что нового появилось в новых версиях веб-клиента vSphere:
На хост-серверах можно запустить процедуру "Reconfigure for HA".
Базовые возможности по настройке параметров HA-кластера.
Живое обновление дерева снапшотов (после процедур revert, delete, delete all).
Автоматический апгрейд VMware Tools в виртуальных машинах.
Выбор между 12 или 24-часовым форматом для представлений времени.
Отображение кастомных атрибутов и тэгов в разделе Summary для виртуальных машин.
Редактирование IP-настроек для интерфейса VMkernel.
Можно кликать по алармам на панели, чтобы перейти к просмотру их деталей.
Множество багофиксов.
Скачать VMware vSphere HTML5 Web Client 1.13 можно по этой ссылке.
Если у вас много виртуальных машин в Inventory сервера VMware vCenter, то при превышении порога в 100 виртуальных машин они будут автоматически сгруппированы таким образом, что их список вы будете видеть только в группах:
Это поведение удобно далеко не всем администраторам VMware vSphere, но это легко можно изменить в настройках веб-клиента. Для этого откройте файл на сервере vCenter для Windows:
Почти 2 года назад мы писали о полезном для многих администраторов платформы vSphere плагине PowerActions for vSphere Web Client, который позволяет хранить и исполнять сценарии PowerCLI прямо из vSphere Web Client, что очень удобно, когда администратор выполняет повседневные задачи по управлению виртуальной инфраструктурой, где некоторые операции автоматизированы средствами PowerShell.
То есть вы просто нажимаете в веб-клиенте правой кнопкой по объекту виртуального датацентра и из контекстного меню выбираете нужный PowerCLI-скрипт для исполнения:
Многие администраторы VMware vSphere часто используют снапшоты для отката виртуальных машин в базовую точку после внесения в них экспериментальных изменений. Но вы же знаете, что снапшоты - это плохо, поэтому в некоторых ситуациях можно заменить этот процесс на более эффективный, так как снапшот можно забыть удалить, их удаление грузит дисковую подсистему и т.п.
Итак, иногда независимые (independent) диски могут оказаться вам полезными. Если вы зайдете в настройку дисков виртуальной машины, то увидите там такие опции:
Независимость таких дисков заключается в том, что они работают независимо от снапшотов, то есть при снятии снапшота и откате к ним, независимые диски остаются в том же состоянии. И тут есть 2 подвида таких дисков:
Persistent (постоянный) - этот диск является обычным диском для записи данных, но его не касаются снапшоты.
Nonpersistent (непостоянный) - этот диск является Redo-диском, то есть если вы выключаете виртуальную машину или откатываете ее к снапшоту - изменения, сделанные в этом диске, сбрасываются.
Как раз Nonpersistent-диски - это то, что можно иногда использовать вместо снапшотов. Сделали базовую машину, поэкспериментировали в ней, выключили - и она откатилась к базовому состоянию.
А вот еще кейс, который может научить вас использованию дисков сразу всех трех типов (обычных, независимых-постоянных и независимых-непостоянных). Например, вы сделали веб-сайт, который меняться не будет еще очень долго. Делаете виртуальную машину с тремя дисками:
Обычный - для файлов веб-сервера
Nonpersistent - для контента веб-сайта
Persistent - для логов веб-сайта
Теперь, если этот сайт кто-то поменяет или заразит, какой-то фигней, можно будет просто перезагрузить виртуальную машину - и это откатит ее в начальное состояние контента (непостоянный диск), но сохранит логи для анализа действий злоумышленника (постоянный диск).
В общем, независимые диски как-то не очень используются, но ведь иногда они вполне подойдут для решения некоторых админских задач.
Многие администраторы VMware vSphere часто сталкиваются с необходимостью получить какие-то файлы конфигурации с VMware ESXi или заглянуть в логи хост-сервера. Для этих целей они используют SSH-клиенты, такие как WinSCP / Veeam FastSCP, либо копируют файлы еще каким-нибудь экзотическим образом.
Но есть простой способ - забрать файл конфигурации esx.conf либо другой конфиг-файл или лог через веб-браузер. Просто зайдите по ссылке:
https://<имя хоста ESXi>/host
После ввода логина и пароля вы получите список файлов, которые можно скачать по прямым ссылкам (всего 46 конфигурационных файлов):
Таким вот образом можно получить любой файл для целей траблшутинга - например, мы тут видим не только основной файл конфигурации хоста esx.conf, но и логи VMware HA (fdm.log) или агента vCenter (vpxa.log), а также основной лог службы хост-сервера ESXi (hostd.log).
Ну а известный многим William Lam написал на основе vSphere API (он как раз и используется для доступа к объектам хоста) сценарий PowerCLI, который позволяет быстро вывести основную конфигурацию ESXi, содержащуюся в esx.conf.
На сайте vcommunique.blogspot.ru появилась интересная табличка в которой приведены максимальные конфигурации хостов, серверов vCenter, виртуальных машин и других компонентов виртуального датацентра в сравнительной таблице, где представлена информация для различных версий платформы VMware vSphere и средства катастрофоустойчивости Site Recovery Manager (SRM).
Вот так прогрессировали vSphere и SRM от версии к версии:
Максимально поддерживаемая конфигурация / Версия платформы
6
5.5
5.1
5
4.1
4
Число Virtual CPU на виртуальную машину (Virtual SMP)
128
64
64
32
8
8
Объем оперативной памяти (RAM) на ВМ
4 TB
1TB
1TB
1TB
255GB
255GB
Размер виртуального диска
62 TB
62TB
2TB
2TB
2TB
2TB
Число виртуальных дисков
На хост - 2048
На Datastore Cluster - 9000
60
60
60
60
60
Логических CPU на хост
480
320
160
160
160
20
Виртуальных машин на хост
1024
512
512
512
320
320
Виртуальных CPU на хост
4096
4096
2048
2048
512
512
Виртуальных CPU на ядро
32
32
25
25
25
20
Оперативной памяти (RAM) на хост
6 TB
4TB
2TB
2TB
1TB
1TB
Размер LUN
64 TB
64TB
64TB
64TB
2TB
2TB
Raw Device Mapping size (virtual compatibility)
62TB
62TB
2TB
2TB
2TB
2TB
Размер диска Raw Device Mapping в режиме физической совместимости (Physical RDM)
64TB
64TB
64TB
64TB
2TB
2TB
Виртуальных машин в кластере
8000
4000
4000
3000
3000
1280
Пулов ресурсов в кластере
1600
1600
1600
1600
512
512
Хостов на один vCenter Server
1000
1000
1000
1000
1000
200
Число хостов в виртуальном датацентре
500
500
500
500
400
100
Включенных виртуальных машин на один vCenter Server
10000
10000
10000
10000
10000
2000
Зарегистрированных виртуальных машин на один vCenter Server
15000
15000
15000
15000
15000
3000
Число распределенных коммутаторов (Distributed switches, VDS) на один vCenter
128
128
128
32
32
16
Single Sign On (SSO)
Требуется
Требуется
Требуется
Не доступен
Не доступен
Не доступен
Параметры VMware Site Recovery Manager (SRM)
Число защищенных виртуальных машин всего
5000
1000
1000
1000
1000
1000
Число защищенных ВМ в одной protection group
500
500
500
500
500
500
Число Protection groups на один recovery plan
250
250
150
150
150
150
Число Datastore groups
255
255
150
150
150
150
Число одновременно запущенных планов восстановления (recovery plans)
Как мы уже писали, начиная с VMware Tools 10.0, компания VMware сделала тулзы загружаемыми отдельно от дистрибутивов VMware ESXi. Доступны они по этой ссылке. Чтобы посмотреть актуальную версию VMware Tools, которая установлена в вашей ВМ, можно просто взглянуть на свойства ВМ в vSphere Client:
Ну а как узнать, какая версия VMware Tools является сейчас самой последней, а также какие версии тулзов с какой версией ESXi поставляются? Очень просто - для этого есть вот такая ссылка: https://packages.vmware.com/tools/versions.
Здесь мы видим версии ESXi и соответствующие им версии VMware Tools. Но там есть и такие версии хостов: "esx/0.0". Это прсто плейсхолдер для пакетов VMware Tools, которые как раз вышли отдельно от релиза VMware ESXi (последние 2 версии так и выходили).
Кстати, все новые версии VMware Tools обратно совместимы со всеми версиями VMware ESXi, которые моложе как минимум на одно поколение. В этом можно убедиться, посмотрев VMware Interoperability Matrix:
Компания VMware в последние несколько месяцев постоянно работает над тонкими клиентами для управления виртуальной инфраструктурой VMware vSphere: ESXi Embedded Host Client для управления отдельными хостами vSphere и HTML5 Web Client для управления виртуальным датацентром через vCenter. Напомним, что совсем недавно мы писали про HTML5 Web Client версий 1.8 и 1.9, а на днях вышли обновления HTML5 Web Client 1.10 и 1.11.
Новые возможности веб-клиентов версий 1.10 и 1.11:
Мастер добавления виртуального хранилища VMFS.
Просмотр информации о сетевом экране и сервисах хоста ESXi.
Возможность апгрейда VMware Tools (только в интерактивном режиме).
Просмотр деталей адаптеров VMkernel.
Возможность выбрать политику хранилищ (storage policy) при редактировании размещения виртуального диска.
Возможность выбрать любое расположение виртуального диска при создании виртуальной машины.
Редактируемые настройки DRS.
При создании ВМ можно выбрать SDRS-рекомендации, даже если SDRS пока отключен.
Возможность управления алармами на вкладке Alarms внизу.
Упрощенная процедура апгрейда Web Client.
Видно, что работа кипит, но видно также, что и осталось работы достаточно много - а до релиза новой версии vSphere нужно успеть выпустить финальную версию веб-клиента, так как толстого C#-клиента уже не будет.
Скачать VMware HTML5 Web Client 1.11 можно по этой ссылке.
На сайте проекта VMware Labs, где очень часто появляются полезные штуковины для продуктов VMware, была выпущена очередная интересная утилита - DRS Doctor. Это средство позволяет проводить диагностику поведения DRS-кластера в рамках сервера VMware vCenter. DRS Doctor собирает такую информацию, как состояние кластера, распределение рабочей нагрузки, миграции DRS и многое другое. Все это объединяется в удобном и человекочитаемом формате логов.
В общем-то довольно давно системные администраторы VMware vSphere хотели получить средство, позволяющее узнать больше информации о деятельности кластера балансировки нагрузки, поэтому многим утилита придется как раз кстати. Ну и DRS Doctor подойдет инженерам техподдержки, которые решают различные проблемы, возникающие в среде vSphere.
DRS Doctor соединяется с vCenter и отслеживает действия, которые происходят в кластере DRS, в реальном времени. Самое интересное, что утилита выводит причину для каждой миграции DRS, что раньше было доступно только в файлах дампов. Так можно узнать, чем руководствуется DRS при выборе хоста для vMotion виртуальных машин между ними.
В конце каждого файла логов, генерируемого DRS Doctor, вкратце записывается загрузка системных ресурсов и небольшая сводная информация по аудиту кластера, чтобы помочь в решении проблем.
Утилита поставляется в качестве средства командной строки для Linux. Для работы вам понадобится установленный Python. Инструкции по установке на CentOS доступны здесь, а скачать DRS Doctor можно по этой ссылке.
Не так давно компания VMware выпустила интересный и полезный документ, который пригодится очень многим Enterprise-администраторам виртуальной инфраструктуры - "Oracle Databases on VMware Best Practices Guide".
Как и остальные документы серии Best Practices Guide, данный документ предоставляет вполне конкретные рекомендации и лучшие практики по эксплуатации СУБД Oracle на платформе VMware vSphere.
Основные разделы документа:
VMware Support for Oracle Databases on vSphere - рассказывает о политиках поддержки СУБД Oracle на платформе vSphere.
Server Guidelines - рекомендации по выбору и конфигурации серверов.
Virtual CPU Guidelines - как правильно сайзить виртуальные процессоры ВМ.
Memory Guidelines - лучшие практики по использованию оперативной памяти (что очень важно для баз данных).
Storage Guidelines - как правильно выбирать тип хрананилища, настраивать его и правильно эксплуатировать (в том числе Virtual SAN).
Networking Guidelines - лучшие практики по конфигурации сетевого взаимодействия (виртуальные коммутаторы, сетевые адаптеры и т.п.).
Guest Operating System Guidelines - как правильно настроить гостевую ОС, чтобы база данных работала быстро.
Database Guidelines - общие принципы правильной архитектуры решений Oracle на платформе vSphere.
ESXTOP/rESXTOP - средства мониторинга производительности серверов.
Backup and Recovery - резервное копирование и восстановление, а также защита данных.
High Availability - обеспечение высокой доступности и средства отказоустойчивости.
Disaster Recovery - восстановление после масштабных сбоев с помощью решений vSphere Replication, SRM и прочих.
VMware Engineered Systems - использование готовых референсных архитектур (например, EVO:RAIL) для организации больших инфраструктур.
Скачать "Oracle Databases on VMware Best Practices Guide" можно по этой ссылке.
На днях мы писали о том, что компания VMware выпустила релизную версию своей минимальной операционной системы Photon OS 1.0, которая предназначена для исполнения виртуальных контейнеров Docker. Многие сразу задумались о том, как дело обстоит с работой контейнеров с хранилищами своих данных.
Как раз в этой связи компания VMware выпустила технологическое превью драйвера vSphere Docker Volume Driver, позволяющего напрямую работать с виртуальными хранилищами прямо из контейнеров Docker (версии 1.9 или выше).
Архитектура решения выглядит так:
Как видно из картинки, нам потребуется установить Volume Driver на серверы VMware ESXi, а также плагины vSphere Docker Volume Plugin на виртуальные машины Docker Host, где будут исполняться наши контейнеры. Также мы видим, что в качестве хранилищ поддерживаются практически все, что поддерживает платформа vSphere: тома VMFS (локальные и общие), NFS-хранилища, а также тома Virtual SAN (и соответственно их политики по обеспечению избыточности данных в целях отказоустойчивости).
Рассмотрим развертывание решения vSphere Docker Volume Driver по шагам.
1. На серверы VMware ESXi 6.0 или выше устанавливается компонент vSphere Data Volume Driver в виде обычного VIB-пакета.
4. Устанавливаем VMDK Plugin (Docker Volume Plugin) на хост ESXi.
Проверяем версию Docker:
root@photon-machine [ ~ ]# docker version
Client:
Version: 1.11.0
API version: 1.23
Go version: go1.5.4
Git commit: 4dc5990
Built: Wed Apr 13 19:36:04 2016
OS/Arch: linux/amd64
Server:
Version: 1.11.0
API version: 1.23
Go version: go1.5.4
Git commit: 4dc5990
Built: Wed Apr 13 19:36:04 2016
OS/Arch: linux/amd64
root@photon-machine [ ~ ]#
Install the RPM (I’ve used “-U” out of habit, but “-i” can also be used):
Устанавливаем RPM-пакет с плагином в гостевую ОС:
root@photon-machine [ ~ ]# ls
docker-volume-vsphere-0.1.0.tp-1.x86_64.rpm
root@photon-machine [ ~ ]# rpm -Uvh docker-volume-vsphere-0.1.0.tp-1.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:docker-volume-vsphere-0:0.1.0.tp-################################# [100%]
File: '/proc/1/exe' -> '/usr/lib/systemd/systemd'
Created symlink from /etc/systemd/system/multi-user.target.wants/\
docker-volume-vsphere.service to /usr/lib/systemd/system/docker-volume-vsphere.service.
5. Проверяем статус плагина:
root@photon-machine [ ~ ]# systemctl status docker-volume-vsphere
* docker-volume-vsphere.service - "Docker Volume Driver for vSphere"
Loaded: loaded (/usr/lib/systemd/system/docker-volume-vsphere.service;\
enabled; vendor preset: enabled)
Active: active (running) since Mon 2016-05-30 09:04:21 UTC; 28s ago
Main PID: 256 (docker-volume-v)
CGroup: /system.slice/docker-volume-vsphere.service
`-256 /usr/local/bin/docker-volume-vsphere
May 30 09:04:21 photon-machine systemd[1]: Started "Docker Volume Driver\
for....
Hint: Some lines were ellipsized, use -l to show in full.
root@photon-machine [ ~ ]#
Регулярные проблемы с нарушением конфиденциальности корпоративных данных, атаки на инфраструктуру и приложения, запущенные в виртуальной среде, прямые многомиллионные потери денег банками – это результат использования средств защиты информации (СЗИ) не соответствующих современной архитектуре виртуализированных ЦОД.
Мы как-то писали о технологии vSphere Integrated Containers (VIC), которая подразумевает запуск виртуализованных контейнеров Docker (и прочих) в маленьких виртуальных машинах с легковесной ОС на базе дистрибутива Linux.
Этой ОС и является VMware Photon OS 1.0, которая окончательно вышла на днях. Это первая релизная версия этой операционной системы от VMware.
При использовании Photon OS каждый контейнер исполняется в своей виртуальной машине, но не в обычной, а в созданной "на лету" с помощью технологии Instant Clone.
VMware Photon OS обеспечивает следующие возможности для контейнеров приложений (в частности, Docker):
Средства быстрого обновления (tdnf), которые позволяют сканировать и своевременно обновлять устаревшие пакеты приложений.
Большой набор библиотек в репозиториях, которые требуются для работы различных приложений на платформе Photon OS.
Построенная на ядре 4.2 система Photon OS поддерживает файловую систему btrfs со всеми ее возможностями в дополнение к overlayfs.
До 26% улучшения производительности по сравнению с бета-версиями (на базе микробенчмарков). Теперь время загрузки ядра составляет примерно 200 миллисекунд. Сама ОС занимает в оперативной памяти 384 МБ, а на диске 396 МБ.
Очень много было сделано в плане безопасности - проведено тщательное ревью всего исходного кода Photon OS, код был проверен различными тулзами, а также привлекались сторонние компании для поиска потенциальных уязвимостей.
Чуть больше недели назад компания VMware выпустила очередное обновление своего тонкого клиента для управления отдельными хост-серверами VMware ESXi Embedded Host Client 1.5 (на самом деле, это версия v9). Напомним, что о прошлой версии Embedded Host Client v8 мы писали вот тут (а здесь - о том, что данный клиент уже входит в стандартную поставку ESXi).
Новые возможности Host Client 1.5:
Основное:
Просмотрщик логов теперь имеет возможности поиска и подсветки найденного.
Настройки теперь хранятся как переменные в расширенной конфигурации хоста, а не в локальном хранилище браузера. Это означает, что конфигурация клиента сохраняется между браузерами и машинами пользователя, с которых он работает с консолью.
Колонка видимости во всех таблицах теперь запоминается.
Хост-сервер:
Добавление, редактирование и удаление пользователей.
Добавление, редактирование и удаление ролей.
Добавление пермиссий для хост-серверов и виртуальных машин.
Появился GUI для настройки параметров автостарта ВМ.
Виртуальные машины:
Пофикшена проблема с нераскрывающимися комбобоксами при редактировании или создании виртуальных машин (в Safari).
Пофикшена проблема с добавлением устройств PCI passthrough.
Пофикшена проблема с добавлением сетевых адаптеров SR-IOV.
Исправлена проблема с отключением горячего добавления CPU и памяти.
Добавлен пункт меню "reset to native resolution" в браузерной консоли ВМ.
Добавлен пункт меню для работы консоли ВМ во вкладке или полном окне.
Исправлена проблема с экспортом виртуальных машин, которая могла приводить к нечаянному скачиванию дисковых образов. Добавили подтверждающий диалог.
Хранилища:
Добавлена возможность поиска в таблице с iSCSI target.
Добавлено поле ввода при создании хранилища VMFS для возможности указания точного размера раздела при кастомном разбиении диска на разделы.
Сетевое взаимодействие:
Исправлено много ошибок, которые проявлялись при редактировании правил фаервола.
Добавлена поддержка средств балансировки NIC teaming и управления полосой канала (traffic shaping) для виртуальных коммутаторов vSwitch и их портгрупп.
Скачать последнюю версию VMware ESXi Embedded Host Client 1.5 можно по этой ссылке.
Некто Kim Bottu в своем блоге опубликовал интересный калькулятор, предназначенный для определения того, сколько хостов, хранилища, физических/виртуальных процессоров, памяти и кэша вам потребуется, чтобы поддерживать кластеры VMware Virtual SAN для вашей инфраструктуры виртуальных хранилищ.
VMware VSAN 6.2 Online resource calculator представляет собой Excel-таблицу, размещенную в облаке Microsoft OneDrive, в которой показаны только редактируемые поля для ввода данных, влияющие на результат (а параметры, которые используются в качестве исходных данных, можно посмотреть в таблице, начиная с ячейки EO:1660).
В верхней части таблицы черным шрифтом обозначаются ресурсы, которые рассчитываются только для того, чтобы можно было исполнять виртуальные машины в кластере Virtual SAN, а красным шрифтом выделен тот объем ресурсов, который вам потребуется, чтобы обеспечить требуемый уровень избыточности и отказоустойчивости.
В синей (верхней) области таблицы данные параметры рассчитываются для All-Flash архитектуры кластера Virtual SAN, а зеленая часть предназначена для расчетов гибридной архитектуры (обычные HDD-диски для данных, а SSD-носители - для кэша).
Также жирным шрифтом выделены реальные ресурсы (процессоры хостов, память, хранилища), которые вам нужно приобрести для своей инфраструктуры, а обычным шрифтом - вспомогательные параметры (как именно эти ресурсы распределяются).
Калькулятор весьма интересный, доступ к нему можно получить по этой ссылке. Кроме того, напомним, что мы писали еще об одном калькуляторе для VMware Virtual SAN от компании VMware, который также помогает вам проводить сайзинг инфраструктуры VSAN и считать совокупную стоимость владения такой инфраструктурой (TCO - total cost of ownership). В принципе, ничто вам не мешает воспользоваться обоими калькуляторами и сравнить результаты, которые должны, по идее, более-менее сходиться.
Интересный пост о технологии VVols появился на блогах VMware. Дескать, их часто спрашивают - почему средства балансировки нагрузки на хранилища Storage DRS не поддерживаются для томов VVols?
Для ответа на этот вопрос надо рассмотреть, как работает традиционная архитектура хранилищ, которая была до VVols и кластеров Virtual SAN. Обычный дисковый массив или хост можно представить набором носителей двух типов (HDD и Flash), которые дают суммарно некоторую емкость.
Например, у нас 160 ТБ на СХД, которые мы разбиваем на LUN по 8 ТБ, итого получая 20 томов VMFS. Допустим, половина емкости у нас HDD, а половина - SSD. Тогда мы создадим 2 датастор-кластера (datastore cluster), в каждом из которых будет по 10 томов VMFS:
Кластер на SSD-носителях будет хранилищем яруса Gold, а HDD - Silver. Технология Storage DRS предназначена, чтобы балансировать виртуальные машины в рамках яруса между LUN для обеспечения их равномерной загрузки, как по емкости, так и по вводу-выводу. А в случае необходимости машину можно также и перенести между ярусами (Silver->Gold) с помощью технологии Storage vMotion.
Все это вызвано сложной структурой хранилищ, которая "прячет" виртуальную машину от дискового массива, представляя ее в конечном счете как набор дисковых блоков, ничем не отличающихся таковых при подключении физических серверов.
В случае же с VVols дело обстоит совсем иначе: на все хранилище создается один Storage Container, который объединяет собой все 160 ТБ доступной емкости - и Flash, и HDD. И этот контейнер представляет собой единственный объект для хранения виртуальных машин с томами VVols:
То есть все операции по балансировке данных виртуальных машин (на уровне дисковых объектов VVols) передаются на сторону СХД, которая лучше знает, как правильно распределять данные и обеспечивать необходимый уровень обслуживания на базе политик (Storage Policies), привязанных к ярусам. Это, конечно же, требует некоторой работы со стороны производителей систем хранения, зато избавляет от забот саму VMware, которая универсализовала технологию VVols и средства работы с ней.
То есть, VVols не требует наличия Storage DRS - технологии, которая уйдет со временем на уровне отдельных аппаратных хранилищ, но будет полезной для балансировки в среде, где есть несколько СХД или кластеров хранилищ от одного или нескольких вендоров.
Компания VMware стремительными темпами развивает свое средство для управления виртуальной инфраструктурой vSphere через браузер на базе технологии HTML5 - VMware HTML5 Web Client. Напомним, что недавно было окончательно объявлено, что следующая версия VMware vSphere не будет иметь "толстого" клиента vSphere Client, сделанного на C#, а старый и тормозной Web Client заменят новым и, возможно, быстро работающем (хотя многие очень сомневаются в этом).
Давайте посмотрим, что нового VMware добавила в последних версиях своего тонкого клиента к vCenter:
Открытие консоли ВМ из контекстного меню действий.
Миграция виртуальной машины в объект "виртуальный сервис" (vApp).
Добавление отдельного хоста ESXi в датацентр или папку Hosts.
Менеджер снапшотов теперь имеет древовидное представление с подробной информацией о каждом снапшоте. Пока еще менеджер снапшотов работает в режиме Read Only. При этом можно откатиться на любой выбранный снапшот.
Выбор спецификации для кастомизации в мастере клонирования ВМ, а также возможность фильтра по гостевым ОС.
Просмотр сообщений об ошибках для случаев, когда ВМ не может включиться в DRS-кластере.
Для кластера VMware HA можно просматривать информацию об ответных действиях в случае сбоя.
Возможность просмотра порт-групп для виртуальных коммутаторов.
Было исправлено несколько серьезных ошибок.
Подробнее о новых обновлениях VMware HTML5 Web Client 1.6 и 1.7, а также загрузить последнюю актуальную версию клиента vSphere можно по этой ссылке.