Вильям Лам выложил интересный сценарий PowerCLI, который поможет вам получить информацию об использовании хранилищ и накладных расходах vSAN с использованием API.
В интерфейсе vSphere Client вы можете увидеть подробный анализ использования хранилища vSAN, включая различные системные накладные расходы, выбрав конкретный кластер vSAN, а затем перейдя в раздел Monitor->vSAN->Capacity, как показано на скриншоте ниже:
Различные конфигурации vSAN, такие как использование традиционной архитектуры хранения vSAN OSA или новой архитектуры vSAN Express Storage Architecture (ESA), а также активация функций, таких как дедупликация и сжатие vSAN, приводят к различным метрикам использования дискового пространства, которые отображаются в разделе информации.
Недавно у Вильяма спросили - а как получить информацию о накладных расходах, связанных с дедупликацией и сжатием vSAN, с использованием PowerCLI?
Хотя командлет PowerCLI vSAN Get-VsanSpaceUsage предоставляет множество метрик использования, отображаемых в интерфейсе vSphere, он не раскрывает все свойства.
Тем не менее, мы можем использовать PowerCLI для получения этой информации, используя базовый метод vSAN API, который предоставляет эти данные, в частности querySpaceUsage(). Как видно из документации по API, этот метод возвращает массив объектов типов использования vSAN, которые соответствуют данным, отображаемым в интерфейсе vSphere, с расшифровкой свойства ObjType.
Чтобы продемонстрировать использование этого API, Вильям создал пример PowerCLI-скрипта под названием vsanUsageAndOverheadInfo.ps1, в котором вам нужно просто обновить переменную $vsanCluster, указав имя нужного кластера vSAN.
После подключения к серверу vCenter вы можете просто выполнить этот скрипт, как показано ниже:
VMware vSphere предоставляет разнообразный выбор SDK для автоматизации рабочих процессов. Пользователи часто задаются вопросом выбора SDK для автоматизации конкретных задач. Вот некоторые рекомендации по использованию различных SDK для задач автоматизации.
Выбор SDK
Основные API vSphere разделены на три категории на основе используемого протокола. Библиотеки наборов инструментов для разработки программного обеспечения vSphere также классифицируются на основе них.
vSphere Web Services (VIM) API - это популярные API, охватывающие большую часть инфраструктуры vSphere с использованием протокола SOAP. pyvmomi, govmomi и vSphere Management Java SDK широко используют эти API. Все устаревшие функции, предшествующие vSphere 6.5, доступны только в этих SDK.
vSphere Automation API - API автоматизации vSphere следует архитектуре REST на основе ресурсов, которая была введена в vSphere 6.5. VMware vSphere Automation SDK оптимизированы для разработки приложений с использованием этих API. Эти SDK доступны только на языках Java и Python и используют протокол-последователь JSON RPC. Некоторые популярные функции, такие как библиотека контента, тегирование, vSphere с Kubernetes и т.д., доступны только на этой платформе SDK. Несколько важных замечаний здесь:
Функции, такие как управление виртуальными машинами, управление хостами и кластерами, и другие функции, представленные до vSphere 6.5, также частично доступны в vSphere Automation API.
Хотя название этого SDK гласит "SDK автоматизации vSphere", оно не ограничивается только vSphere. У них есть клиентские байндинги для VMware Cloud и NSX on VMware Cloud. Это может быть использовано для автоматизации архитектуры Software Defined Datacenter (SDDC).
Virtual Infrastructure JSON API (VI JSON API) - для разработчиков, которым не нравятся тонкости SOAP, эти API предоставляют интерфейсы REST для всех указанных выше API веб-служб vSphere (VIM). В настоящее время с этими API не связано никаких SDK.
Давайте сосредоточимся только на SDK, основанных на vSphere Web Services (VIM) API и vSphere Automation API. Нам нужно убедиться, что клиентские байндинги функций vSphere доступны с правильными SDK. Руководство по API и документация по языку программирования SDK могут быть хорошей отправной точкой. Для более быстрого понимания вы можете обратиться к таблице ниже, чтобы определить подходящие SDK и руководства по программированию.
Основные функции vSphere в пакетах разработки SDK:
Если вы заинтересованы в создании байндингов к языку программирования на других языках с использованием сторонних инструментов, вы можете использовать WSDL, поставляемые в vSphere Management SDK, или использовать спецификации VI JSON.
При выборе SDK учитывайте ваши навыки в языке программирования, конкретные требования вашего проекта и наличие ресурсов и примеров для выбранного SDK. Кроме того, имейте в виду, что VMware может выпускать обновления и новые SDK, выводить SDK из эксплуатации, поэтому рекомендуется проверять официальную документацию для получения самой последней информации.
В этом году компания VMware серьезно взялась за доработку своих фреймворков по автоматизации операций в виртуальной инфраструктуре. Это было обусловлено тем, что исторически у VMware накопилось большое количество средств автоматизации, которые когда-то были привязаны к специфическим продуктам и интерфейсам, потом эти продукты эволюционировали, объединялись в различные линейки, а старые интерфейсы продолжали тянуться за разными решениями, управлять которыми до сих пор можно несколькими разными способами, а с учетом различных платформ и вспомогательных сервисов таких способов становится слишком много.
Не так давно мы писали о протоколе VI/JSON от VMware для управления инфраструктурой vSphere. В то же время, у VMware в последнее время появилось много чего еще нового в сфере средств для автоматизации управления виртуальной инфраструктурой, о будущем которых мы сегодня и поговорим, обратив внимание на такие интерфейсы, как API, JSON, OpenAPI.
1. VMware vSphere API
VMware vSphere за последние годы стала значительно более сложным продуктом и теперь предлагает несколько разных типов API-технологий. Наиболее значимыми сегодня являются:
Наличие нескольких API добавляет сложности в управление и эксплуатацию сложных сред. Эта сложность проявляется в разных аспектах, начиная с необходимости в нескольких инструментах, знаниях и навыках, в зависимости от API. Кроме того, разные API "висят" на разных эндпоинтах и требуют разные механизмы аутентификации по историческим причинам и для обеспечения обратной совместимости.
Обе категории API документированы отдельно, каждая со своими справочными руководствами и примерами кода. Это может вызвать путаницу для администраторов, поскольку они часто предполагают, что должны выбирать между REST API или SOAP API, но на самом деле им нужно использовать оба. REST не является заменой для SOAP API, но дополняет его.
В плане API компания VMware работает в трех основных направлениях:
Упрощение использования API
Упрощение документации
Улучшение опыта разработчиков и унификация протоколов и наборов инструментов
Основные ресурсы, с которых надо начать знакомство с этими API, это:
Во-первых, начиная с vSphere 8 Update 1, был введен новый протокол JSON для всех Web Services API в VMware vSphere. Это помогает унифицировать опыт разработки, позволяя разработчикам использовать общие инструменты, и преобразует SOAP API для применения более REST-подобного подхода. Этот JSON API в vSphere 8 Update 1 и новее предоставляет полный набор функциональных возможностей, предлагаемых традиционным vim25 SOAP API.
Во-вторых, были сохранены та же структура, управляемые объекты и имена методов, чтобы клиенты могли перенести существующие решения для автоматизации на новый протокол JSON с минимальными изменениями.
Наконец, VMware предлагает спецификации OpenAPI 3.0 в дополнение к документации по JSON API виртуальной инфраструктуры. VMware также ведет работу по объединению документацию по JSON API с документацией по Automation API, где задокументированы все REST-сервисы. Это приближает момент создания единого места для поиска документации клиентами.
3. Формат OpenAPI 3.0
В будущем VMware перенесет оставшиеся публичные интерфейсы SOAP-сервисов (SPBM, SMS, EAM, VLSM) на эти же форматы, предоставляя спецификации OpenAPI 3.0 для каждого из них и интеграцию с документацией REST API.
После этого следующим улучшением будет предоставление единого механизма аутентификации для REST API и нового протокола JSON для SOAP API. Это упростит создание решений для автоматизации и обеспечит общую сессию для всех сервисов vSphere.
Окончательным шагом на этом пути улучшения будет предоставление всех сервисов через единый эндпоинт, с которым администраторы смогут вызывать все API vSphere. Это значительно упростит использование API в vSphere и обеспечит более качественное документирование, тем самым улучшая опыт разработки.
Одной из сильных сторон VMware vSphere является обширное количество API, которые позволяют управлять платформой. Более тысячи API, варьирующиеся от основных операций с виртуальными машинами до виртуализации хранилищ и сетей, от кластеризации до управления ресурсами, позволяют организациям любого размера настраивать vSphere под свои конкретные потребности и автоматизировать различные рабочие процессы для экономии времени и средств.
С момента их появления более 15 лет назад, API управления виртуальной инфраструктурой (VI) обрели широкое применение. Множество продуктов и бесчисленное количество скриптов разработаны с учетом этих API, и многие разработчики знакомы с их моделью разработки. В то же время, VI API основаны на протоколе SOAP, который в свою очередь разработан на основе XML. Несмотря на свою мощь, за годы XML доказал свою сложность как формат данных, имеющий свою долю проблем с безопасностью. Учитывая эти проблемы, разработчики и системные дизайнеры прибегают к JSON в качестве замены XML в области API.
Чтобы удовлетворить спрос и облегчить интеграцию в окружения, работающие только с JSON, начиная от веб-браузеров и до современных языков программирования, таких как Go, VMware представила новый протокол, основанный на JSON и похожий на REST, под названием VI/JSON.
Новый протокол является современной альтернативой устаревшему SOAP и предоставляет те же VI API на тех же эндпоинтах, с той же моделью безопасности. Одной из главных целей нового протокола VI/JSON является максимальное облегчение перехода от SOAP для новых пользователей VI API. Кроме того, для приложений, основанных на SDK, миграция на VI/JSON может быть выполнена полностью на платформе с минимальными изменениями в приложении.
В дополнение к полной обратной совместимости API, новый протокол предоставляет прямой доступ к так "managed properties" - почти 300 типов записей, представляющих состояние различных виртуализованных элементов, управляемых vSphere, начиная от виртуальных машин до сетей, хостов, кластеров и т.д. Ранее управляемые свойства были доступны только косвенно через многофункциональный инструмент Property Collector. Сегодня простой HTTP GET-запрос может получить доступ ко всем управляемым свойствам.
Для VI/JSON, похожесть на REST означает, что управляемые ресурсы и операции кодируются в URL-адресе запроса, а не в теле сообщения, как требуется в SOAP. Это изменение предоставляет множество преимуществ: упрощает интеграцию в сетевых экранах на уровне API, облегчает анализ трафика и упрощает написание скриптов. Аналогично, кодировка данных на основе JSON облегчит разработку для многих пользователей VI API.
И наконец, улучшены также и аспекты безопасности. Вместо использования HTTP-кук для идентификации сессии, новый протокол использует специальный HTTP-заголовок, предотвращающий классическую атаку, известную как межсайтовая подделка запроса (Cross-Site Request Forgery), когда третья сторона может украсть идентификационные данные пользователя.
Чтобы дать представление о новом протоколе, вот такой запрос может быть использован для включения виртуальной машины (заголовки протокола HTTP опущены для краткости):
POST /sdk/vim25/8.0.1.0/VirtualMachine/vm-42/PowerOnVM_Task
Эквивалентный запрос SOAP выглядит следующим образом. Обратите также внимание на обязательное тело, которое не требуется для простых запросов VI/JSON.
Осенью прошлого года VMware анонсировала первую версию фреймворка
PowervRLICloud, предназначенного для управления окружением VMware vRealize LogInsight Cloud (этот продукт сейчас называется Aria Operations for Logs). Это PowerShell модуль, который реализует абстракции VMware vRealize LogInsight Cloud API для простого доступа к возможностям функций управления этим решением посредством сценариев.
Недавно мы писали о выходе новой версии фреймворка для автоматизации операций в виртуальной инфраструктуре средствами сценариев VMware PowerCLI 13. Одной из его частей является модуль Horizon PowerCLI module, с помощью которого можно управлять различными аспектами VDI-инфраструктуры. Сегодня мы посмотрим, как это делается.
Модуль PowerCLI для Horizon служит прослойкой для управления конфигурациями виртуальной инфраструктуры десктопов посредством View API, который можно также использовать и путем прямого доступа. Помимо этого, в рамках инструментария по управлению VDI-cредой есть и набор дополнительных функций, доступных в репозитории на GitHub.
В дополнение к View API, инфраструктура Horizon также предоставляет и RESTful API, который называется VMware Horizon Server API. Он предназначен для взаимодействия с Connection Server (подробнее об этом можно прочитать тут).
Итого, мы имеем три основных набора инструментов:
Для начала работы с Horizon через PowerCLI вам нужно выполнить следующие действия:
Устанавливаем VMware PowerCLI
Загружаем и устанавливаем advanced functions
Обращаемся к документации
1. Установка VMware PowerCLI
Основные инструкции по установке находятся здесь. Для начала установки просто открываем Windows PowerShell Admin console и выбиваем команду:
Install-Module VMware.PowerCLI
Далее разрешаем локальное исполнение сценариев командой:
Set-ExecutionPolicy RemoteSigned
2. Установка Advanced Functions
Идем по этой ссылке в репозиторий на GitHub и загружаем пакет по кнопке Download ZIP:
Распаковываем zip-файл и копируем подпапку Hv.Helper в папке modules в одну из директорий модулей на вашем компьютере. Чтобы узнать нужный путь, нужно проверить переменную окружения $env:PSModulePath. Она может быть одной из следующих:
User specific: %UserProfile%\Documents\WindowsPowerShell\Modules
System wide: C:\Program Files\WindowsPowerShell\Modules
Разблокируем расширенные функции, чтобы их можно было исполнять. В командной строке PowerShell под администратором выполняем следующий набор команд:
dir ‘C:\Program
Files\WindowsPowerShell\Modules\VMware.HvHelper\’ |
Unblock-File
После этого будет создана глобальная переменная DefaultHVServers, которая содержит информацию о подключениях к серверам Horizon Connection Servers. Обратиться к ней можно через $Global:DefaultHVServers.
Самое интересное содержится в свойстве ExtensionData. Давайте назначим его переменной $Services и рассмотрим поближе:
Если вы посмотрите документацию к View API, то сможете понять назначение этих записей. Свойство ExtensionData содержит информацию о доступе к любым функциям View API.
Давайте рассмотрим несколько примеров. Сначала используем простую команду для получения всех серверов Horizon Connection Servers в рамках пода (pod). Команда View API ниже использует сервис ConnectionServer и метод ConnectionServer_List для назначения результатов переменной $hvServers1.
Теперь используем одну из расширенных функций для вывода списка всех виртуальных десктопов, в зависимости от состояния агента Horizon Agent в них. Это полезно, чтобы понять, в нормальном ли состоянии там находятся агенты, или они пришли в некорректное состояние ошибки.
Итак, выводим список десктопов, где юзер залогинен, но в текущей сессии он не присоединен:
Затем вы можете написать свой сценарий, который выводит десктопы, где Horizon Agent находится в одном из перечисленных некорректных состояний. Далее можно предпринять шаги по исправлению ситуации - например, перезагрузить машины, чтобы в некоторых из них ошибка исправилась (к примеру, для статуса AGENT_ERR_NEED_REBOOT).
Сценарий ниже позволяет как раз это и сделать. Вам нужно поменять параметры, специфические для вашей среды, такие как имя Connection Server, пользователь, пароль и другое. Если вы не хотите использовать пароль в открытом виде, то можете убрать его из команд Connect-HVServer и Connect-VIServer - тогда он будет запрошен в интерактивном режиме.
Также обратите внимание на параметр -WhatIf в команде Restart-VMGuest - он позволяет вам получить возможный результат исполнения команды без необходимости ее фактического исполнения.
####################################################################
# Get List of Desktops that have Horizon Agent in problem states.
# Reboot the OS of each of these.
####################################################################
#region variables
###################################################################
# Variables
###################################################################
$cs = 's1-hcs1.mydomain.com' #Horizon Connection Server
$csUser = 'administrator' #Connection Server user
$csPassword = 'mypassword' #Connection Server user password
$csDomain = 'mydomain' #Connection Server domain
$vc = 'vcenter1.mydomain.com' #vCenter Server
$vcUser = 'administrator@vsphere.local' #vCenter Server user
$vcPassword = 'mypassword' #vCenter Server password
$baseStates = @('PROVISIONING_ERROR',
'ERROR',
'AGENT_UNREACHABLE',
'AGENT_ERR_STARTUP_IN_PROGRESS',
'AGENT_ERR_DISABLED',
'AGENT_ERR_INVALID_IP',
'AGENT_ERR_NEED_REBOOT',
'AGENT_ERR_PROTOCOL_FAILURE',
'AGENT_ERR_DOMAIN_FAILURE',
'AGENT_CONFIG_ERROR',
'UNKNOWN')
#endregion variables
#region initialize
###################################################################
# Initialize
###################################################################
# --- Import the PowerCLI Modules required ---
Import-Module VMware.VimAutomation.HorizonView
Import-Module VMware.VimAutomation.Core
Set-PowerCLIConfiguration -InvalidCertificateAction Prompt
# --- Connect to Horizon Connection Server API Service ---
$hvServer = Connect-HVServer -Server $cs -User $csUser -Password $csPassword -Domain $csDomain
# --- Get Services for interacting with the View API Service ---
$services= $hvServer.ExtensionData
# --- Connect to the vCenter Server ---
Connect-VIServer -Server $vc -User $vcUser -Password $vcPassword
#endregion initialize
#region main
###################################################################
# Main
###################################################################
Write-Output ""
if ($services) {
foreach ($baseState in $baseStates) {
# --- Get a list of VMs in this state ---
Write-Host ("Get VMs with baseState: " + $baseState) -ForegroundColor Yellow
$ProblemVMs = Get-HVMachineSummary -State $baseState
foreach ($ProblemVM in $ProblemVMs) {
$VM = Get-VM -Name $ProblemVM.Base.Name
# --- Reboot each of the Problem VMs ---
Restart-VMGuest -VM $VM
# Add -WhatIf to see what would happen without actually carrying out the action.
}
}
Write-Output "", "Disconnect from Connection Server."
Disconnect-HVServer -Server $cs
} else {
Write-Output "", "Failed to login into Connection Server."
pause
}
# --- Disconnect from the vCenter Server ---
Write-Output "", "Disconnect from vCenter Server."
Disconnect-VIServer -Server $vc
#endregion main
Эта платформа от VMware будет реализовывать API и аналитические инструменты для выявления подозрительных активностей, которые будут обнаруживаться в трафике, которым обмениваются современные приложения. С помощью Project Trinidad можно будет использовать API для East-West трафика между приложениями на базе микросервисной архитектуры, чтобы обнаруживать паттерны нормального взаимодействия и выявлять подозрительные коммуникации, обнаруживать которые человек не способен. В качестве примера можно привести уязвимость Heartbleed, трафик которой для администраторов выглядел вполне нормальным.
Ключевые особенности Project Trinidad:
Обнаружение Zero-day атак в современных приложениях
Моделирование нормального поведения приложений, обнаружение и предсказывание аномального поведения
Помещение на карантин подозрительных коммуникаций
Не требуется развертывание дополнительных специальных средств
Сейчас атаки на корпоративные инфраструктуры стали более комплексными, в том числе ввиду усложнения самих онпремизных и облачных сред. Администраторы используют сотни решений, многие из которых построены на базе стандартных компонентов, используемых в программном обеспечении по всему миру. Уязвимость Log4j показала, что зачастую стандартные системы защиты просто не работают при анализе и обнаружении вторжений.
Project Trinidad сочетает в себе как средства обеспечения безопасности, так и средства для observability - то есть наблюдения за трафиком за пределами мониторинга человеком. Инсайты по безопасности, выявленные Project Trinidad, можно быстро использовать, чтобы незамедлительно закрыть дыры в инфраструктуре.
Продукт будет работать как SaaS-сервис и не требовать вмешательства со стороны администратора для поддержки решения. Также будет доступна и онпремизная инсталляция, чтобы дать клиентам максимальную гибкость. Решение будет съедать менее 5% ресурсов, но зато даст администраторам любых компаний средства обеспечения безопасности самого высокого уровня.
Средства federated machine learning (FML) позволяет использовать алгоритмы машинного обучения, наученные на большом количестве данных об уязвимостях, что позволяет начать использовать продукт сразу, без необходимости собственного обучения на своей инфраструктуре.
На данный момент платформа Project Trinidad находится в стадии внутренней разработки и технологического превью, о дате ее доступности пока не сообщается. Более подробно о технологии federated machine learning также можно почитать вот тут.
Компания VMware выпустила обновление главного фреймворка для управления виртуальной инфраструктурой с помощью командных сценариев - PowerCLI 12.4. Напомним, что в прошлый раз об обновлении этой платформы мы писали вот тут. В обновленной версии PowerCLI появилось несколько новых возможностей:
1. Новый API интерфейс - RestAPI
Раньше PowerCLI имел 2 основных пути коммуникации с vSphere API:
Get-View (SOAP API bindings)
Get-CISService (JSON-RPC)
Теперь новые PowerCLI API байндинги позволяют работать vSphere REST API и предоставляют практически нативный интерфейс PowerShell.
Модуль, реализующий эти функции, называется vSphere Automation API SDK. Чтобы начать использовать новые возможности через автоматизацию REST API, нужно скачать новую версию PowerCLI - пакет будет называться "VMware.Sdk.vSphere". Он содержит в себе субмодули для взаимодействия со всеми REST API, которые есть в VMware vSphere.
В REST API есть методы для исполнения API и работы со структурами данных, которые используются как входные параметры для API. Новые API байндинги предоставляют низкоуровневые PowerShell функции для работы со всеми этими методами и структурами.
Функция Invoke используется для исполнения методов REST, таких как GET/PUT/POST и DELETE:
Функция Initialize используется для создания структуры данных, которая будет передана к REST API. Например, так выглядит создание структуры "локальный аккаунт":
Раздел документации vSphere API Documentation был существенно обновлен - туда были добавлены примеры, показывающие вызов REST API через PowerCLI. Например, вот раздел Create Local Accounts.
2. Новый vSphere Management Module
Для управления платформой vSphere теперь появился новый модуль. Это модуль на базе PowerShell, для построения которого используется архитектура модулей vSphere Automation API SDK, о которой рассказано выше. На данный момент в модуле 6 командлетов, позволяющих управлять сертификатами (по ссылкам вы можете почитать о них):
На прошедшей недавно конференции для разработчиков SpringOne компания VMware объявила о запуске публичной бета-версии Tanzu Application Platform. На базе этой платформы, разработчики и операторы команд DevOps кластеров Kubernetes смогут разрабатывать различные решения для Azure Kubernetes Service, Amazon Elastic Kubernetes Service, Google Kubernetes Engine, а также непосредственно для инфраструктуры на базе Tanzu Kubernetes Grid.
На этапе первого бета-релиза платформа включает в себя следующие возможности:
Шаблоны приложений с уже готовыми лучшими практиками и правилами использования
Автоматическая сборка образов контейнеров
Среда исполнения для обслуживания контейнеров и обработки событий
Средства обнаружения и маршрутизации API
Аналитика по запущенным приложениям, что упрощает траблшутинг
Основная идея Tanzu Application Platform - дать разработчикам средства для интеграции существующих и новых приложений в бэкенд инфраструктуру контейнеров с соблюдений требований комплаенса и безопасности. При этом сама платформа модульная - то есть разработчики могут выбирать утилиты, которые они используют.
С помощью данной платформы разработчики могут создать декларативный манифест приложения с URL-адресом, который можно расшарить между членами разных команд. Этот манифест превращается в своего рода контракт, над которым работают разработчики и операционные команды, чтобы обеспечить перевод приложения в производственную среду и его обслуживание там.
Вот пример такого манифеста (чтобы его обслуживать, не нужно знать языки программирования):
Платформа поддерживает как долгоживущие веб-приложения, так и различные сценарные программы, работающие на основе событий. Для них предоставляются уже готовые шаблоны и гайдлайны по интеграции приложений в продакшен, поэтому разработчикам не нужно перелопачивать тонны документации.
В то же время, предоставляемые платформой уровни абстракции для приложений не являются черной коробкой - разработчик может получить доступ ко всем оберткам от VMware, вплоть до изначального kubectl.
Если какие-то из определений для внешних компонентов отсутствуют на платформе, их всегда можно подключить с помощью специальных адаптеров, которые можно сделать для любого компонента из тысяч инструментов в экосистеме Kubernetes.
Важное преимущество платформы - возможность разделить обслуживание приложений на 2 контура: внутренний, где разработчики заняты только тем, чтобы приложение работало, и внешний - где DevOps и безопасники выводят его в производственную среду и обслуживают его. Например, при появлении уязвимости команды DevOps и безопасности могут сами обеспечить обновление приложения через VMware Tanzu Build Service. То есть, разработчика в этом случае не будут отвлекать от его самой важной задачи - кодинга.
Через Tanzu Application Platform API portal разработчики могут получить простой доступ ко внутренним и внешним API-интерфейсам. Там же можно в графическом интерфейсе протестировать endpoints напрямую.
С помощью Spring Cloud Gateway for Kubernetes можно наладить взаимодействие внутренних и внешних сервисов с микросервисами. Вместо рабочих процессов на базе тикетов, разработчики теперь получают доступ к API, который позволяет настроить маршруты в JSON во время привязки сервисов Tanzu Application Platform. То есть, разработчику не нужно покидать свою IDE для настройки взаимодействия между сервисами.
Ну и благодаря Cloud Native Runtimes for VMware Tanzu, разработчики могут просто обслуживать события от других приложений и компонентов инфраструктуры. С использованием платформы TriggerMesh можно получать внешние события от cloud native applications и обрабатывать их:
Также, чтобы узнать больше интересного о платформе Tanzu Application Platform вы можете посмотреть следующие технические сессии:
Недавно мы писали о новой версии решения для виртуализации и доставки настольных ПК и приложений VMware Horizon версии 2106. Помимо новых фич, в обновленной платформе появилось много приятных небольших нововведений, одно из них - это возможность вывести список всех событий VMware Horizon прямо в интерфейсе клиента:
Такого рода вещи стали возможны благодаря интерфейсам Audit Events API. Теперь для получения событий пользователям не нужно идти в базу данных с помощью SQL-запросов, а можно просто получать события через API.
Вильям Лам с помощью PowerCLI-сценария обработал файл с определениями событий C:\Program Files\VMware\VMware View\Server\LDAP\ldif\VDIEventStrings_en.ldf на сервере Connection Server и выяснил, что всего в Horizon есть на данный момент 858 типов событий. Эти события он вынес в отдельную табличку:
Также хотим напомнить вам об утилите VMware Horizon Event Notifier, которая соединяется с одной или несколькими базами данных Horizon View Event Database, вытаскивает оттуда выбранные администратором события (ошибки, предупреждения, инфо) и шлет письма на указанный email-адрес. При этом поддерживается возможность работы с несколькими БД, что позволяет собирать алерты с разных инсталляций VMware View (они же View Pods).
На сайте проекта VMware Labs появилась очередная полезная штуковина - OpenAPI interface for vSphere. Это новый протокол, который является альтернативой SOAP/XML, позволяющий получать доступ к интерфейсам управления VMware vSphere через обмен в JSON-формате. Работа с этим API происходит на базе открытой спецификации OpenAPI.
С помощью OpenAPI interface for vSphere можно получить следующие преимущества:
Приложения, которые используют REST API и традиционные vSphere Client API могут перейти на один протокол обмена, а значит не нужно поддерживать 2 интерфейса
Партнеры могут разрабатывать различные дополнения и утилиты для VMware vSphere на базе открытых спецификаций
Существующие API можно расширять, добавляя новые возможности как в стандартную модель SOAP/XML, так и в новый протокол
Новый протокол не зависит от существующих API, поэтому не требует доработки сервисов на бэкенде, что ускоряет его внедрение
Новый OpenAPI interface доступен как для написания комплексных независимых сценариев (например, с помощью curl или Postman) в целях автоматизации рутинных задач, так и разработки различных дополнений и компонентов с помощью специального SDK, который будет доступен партнерам VMware.
Разработчикам сценариев также доступны примеры работы простых функций в виде шаблонов, которые можно кастомизировать через CLI-интерфейс. Для работы с OpenAPI вам понадобится:
vSphere 7.0 или свежее
Окружение Docker или Kubernetes
JDK 8 или свежее
8 GB RAM
Загрузить компоненты
OpenAPI interface for vSphere можно по этой ссылке.
Мы уже много писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1. Сегодня мы посмотрим подробнее, что нового появилось в плане механики резервного копирования виртуальных машин (Data Protection), реализуемой через VMware vStorage API for Data Protection.
1. Функции Network QoS для трафика резервного копирования
Теперь возможности приоритезации трафика Network QoS доступны и для трафика резервного копирования виртуальных машин. Настроить это можно в vSphere Client в разделе System Traffic > Configure > Edit:
Основное назначение данной настройки - дать возможность урезать полосу канала резервного копирования таким образом, чтобы это не влияло существенным образом на трафик производственной среды.
2. Улучшенная обработка задач резервного копирования
Теперь при входе хоста ESXi в режим обслуживания во время резервного копирования есть флаг Entering Maintenance Mode (EMM), что означает, что операции бэкапа должны переключиться на другой хост ESXi, где сессия NFC (network file copy) может быть продолжена. Это автоматическое переключение происходит прозрачно для задачи резервного копирования, но требует от ПО для бэкапа поддержки данного флага, чтобы обнаружить момент переключения.
3.Улучшенное масштабирование для одновременно запущенных задач РК
Для окружений, где параллельно запущено множество задач резервного копирования, ограничения сервера vCenter могут стать проблемой. Использование сервиса VPXA не позволяет кастомизировать буфер памяти для задач, обрабатываемых через vCenter. В апдейте vCenter Server 7.0 U1 теперь можно настраивать буфер памяти, чтобы обрабатывать множество потоков резервного копирования. Например, для 50 одновременных бэкапов нужно использовать 96 MБ памяти.
4. Улучшения vSphere APIs for I/O Filtering (VAIO)
Фреймворк VAIO - это основной интерфейс для партнерских решений, которые могут перехватывать запросы ввода-вывода операционной системы к виртуальному диску. В этом случае команда ввода-вывода (I/O) не будет применена к диску без прохождения через IO Filter, созданный сторонним ПО.
Теперь здесь появились следующие улучшения:
CIM provider теперь стал 64-битным
Сами VAIO-фильтры теперь будут распространяться как компоненты, а не VIB-пакеты
Напомним, что в vSphere 7 появилась концепция компонентов вместо отдельных VIB-пакетов. В vSphere 7 компоненты - это набор VIB-пакетов, которые может использовать Lifecycle Manager, чтобы накатывать патчи. Теперь компоненты можно накатывать через esxcli с использованием команды component apply.
На сайте проекта VMware Labs появилось очередное бесплатное средство для администраторов VMware vSphere - SQL30. Эта штука представляет собой ORM-обертку для легковесной БД SQLITE под ESXi.
Python нативно поддерживает взаимодействие с SQLITE за счет модуля "sqlite" (или sqlite3 в python3). Ну а решение SQLAlchemy - это популярная ORM, используемая для взаимодействия с базами данных sqlite из Python. Однако это решение не работает на ESXi, так как многие его пакеты имеют зависимости от других пакетов, которые не могут быть установлены на ESXi.
Решение SQL30 как замена SQLAlchemy - весьма легковесно и написано только с использованием нативных конструкций Python, а также не имеет никаких внешних зависимостей, поэтому работает на ESXi 6.5 и более поздних версиях.
SQL30 вам пригодится для:
Возможности использования разработчиками интерфейсов Python на платформах с ограниченным применением, таких как ESXi
Предоставления разработчикам приложений доступа к базе данных без необходимости знания SQL
На VMware ESXi 6.5 будет использоваться версия Python 3.5, что ниже актуальной версии 3.6, но все равно лучше чем ничего.
Скачать SQL30 можно тут. Инструкции по установки приведены вот здесь.
Некоторые из вас знают, что есть такое решение VMware vRealize Network Insight (vRNI), которое предназначено для мониторинга и защиты сетевой инфраструктуры виртуальной среды VMware vSphere.
Администраторам виртуальной инфраструктуры часто приходится делать копии различных ее управляющих компонентов, в том числе vRNI. Сейчас VMware рекомендует делать резервную копию конфигурации vRNI на уровне всей виртуальной машины (см. KB 55829). Рекомендуется выключить ВМ с vRNI, скопировать ее целиком, а потом включить снова - это единственный поддерживаемый способ на данный момент.
Martijn Smit опубликовал интересный пост о том, что на самом деле у vRNI есть способ резервного копирования и восстановления конфигурации через API, для которого есть специальный API endpoint по пути /settings/backup:
Если посмотреть внутрь, то там можно увидеть вполне работоспособный механизм бэкапа конфигурации vRNI:
Используя API endpoint /api/ni/settings/backup,вы можете создать резервную копию конфигурации vRNI и перенаправить ее по SSH или FTP на бэкап-сервер в виде tar-файла со следующим содержимым:
Большинство этих файлов человекочитаемы, если вы откроете их в текстовом редакторе. Там находятся копии настроек приложений, объектов pinboards, data sources, сохраненный поиск, системные настройки (Syslog, SMTP и т.п.), пользовательские конфигурации и многое другое.
Для работы с конфигурациями vRNI через API Martijn сделал модуль PowervRNI. Вот пример использования сценария резервного копирования:
На сайте проекта VMware Labs за последние дни появилась пара интересных обновлений полезных утилит. Первое - это апдейт средства vSAN Performance Monitor 1.2, предназначенного для мониторинга и визуализации (в Grafana) метрик в среде отказоустойчивых кластеров VMware vSAN.
С помощью этих данных администраторы смогут диагностировать проблемы, а также распознавать текущие и намечающиеся узкие места в инфраструктуре, которые могут оказаться причиной низкой производительности.
В версии vSAN Performance Monitor 1.2 появились следующие улучшения:
Исправлена проблема с настройкой CA-сертификатов
Некоторые доработки агента, собирающиего данные
Убран анонимный сбор статистики от influxdb
Скачать vSAN Performance Monitor 1.2 можно по этой ссылке.
Второе существенное обновление в Labs - это апдейт утилиты vRealize Operations REST Notifications Helper 1.3. О прошлой версии 1.2 этого средства мы писали вот тут. Напомним, что эта штука позволяет администратору vROPs изменять свойства алерта перед его отправкой на сторону.
В данном обновлении появились следующие новые функции:
Еще в настольной платформе виртуализации VMware Fusion 10 для Mac OS, вышедшей осенью прошлого года, появился программный интерфейс REST API, который позволяет управлять как самой платформой, так и виртуальными машинами, исполняемыми на ней. Совсем недавно, когда вышла версия VMware Workstation 2018 Tech Preview, в которой также появился новый REST API полностью идентичный таковому в VMware Fusion. Однако для Workstation он пока работает только для хостовой ОС Windows.
REST API позволяет управлять различными функциями виртуальных машин, например их inventory, питанием, клонированием, сетевым взаимодействием, получением IP и MAC-адресов, а также другими аспектами их функционирования. Все это позволяет проводить автоматизированные тесты в виртуальных машинах, когда их требуется клонировать и настраивать, а затем уничтожать по окончании теста. Эти функции пока доступны только для Windows.
Давайте посмотрим, как это работает. Сначала сконфигурируем доступ к REST API, задав логин и пароль для авторизации:
Чтобы настроить Credentials к REST API на машине с Workstation, нужно перейти в папку C:\Program Files (x86)\VMware\VMware Workstation и запустить там: vmrest.exe --config
На VMware Fusion нужно пойти в /Applications/VMware Fusion.app/Contents/Public и запустить там: ./vmrest -C
На Workstation вас попросят задать пользователя и пароль:
C:\Program Files (x86)\VMware\VMware Workstation>vmrest --config
VMware Workstation REST API
Copyright (C) 2018 VMware Inc.
All Rights Reserved
vmrest 1.1.0 build-8888902
Username:alex
New password:
Retype new password:
Processing...
Credential updated successfully
На Fusion это будет выглядеть вот так:
MacBook-Pro-alex:Public alex$ ./vmrest -C
VMware Fusion REST API
Copyright (C) 2015-2017 VMware Inc.
All Rights Reserved
vmrest 1.0.0 build 6754183
Username:alex
New password:
Retype new password:
Processing...
Credential updated successfully
После этого можно запускать REST API:
На Fusion это делается командой ./vmrest
На Workstation надо просто запустить vmrest.exe
После этого у вас на рабочей станции запустится веб-сервер, через который вы сможете получить доступ к REST API как через браузер, так и через сторонние REST-клиенты или системы, которые вы хотите интегрировать с Workstation или Fusion. На Workstation для доступа к веб-серверу на дефолтном порту используйте адрес:
http:\\127.0.0.1:8697
На Fusion ссылка аналогичная (можно писать 127.0.0.1 вместо localhost):
http:\\localhost:8697
Далее для обеих платформ процедура выглядит абсолютно одинаково, поэтому дальше мы не будем уточнять, где это исполняется.
Первое что вы увидите - это REST API Explorer, запущенный в интерфейсе Swagger, в котором показаны доступные для использования функции по работе с хостом и виртуальными машинами:
Тут вам не понадобится использовать Curl, PowerShell, Postman или другие инструменты, чтобы протестировать основные функции API.
Здесь все просто:
Host Networks Management - здесь можно посмотреть все виртуальные сети на хосте, а добавить, изменить или удалить форвардинг портов.
Maintenance - можно задать режим работы демона (можно его выключить для перехода в режим обслуживания).
VM Management - управление виртуальными машинами (получение их списка и информации о ВМ, задание их настроек, клонирование ВМ и удаление).
VM Network Adapters Management - управление сетевыми адаптерами ВМ (получение списка сетевых адаптеров и IP-адресов ВМ, а также создание, обновление или удаление сетевых адаптеров ВМ).
VM Power Management - получение состояния ВМ и управление ее питанием.
VM Shared Folders Management - монтирование, размонтирование или изменение конфигурации общих папок на хосте.
После запуска веб-интерфейса, нужно сначала авторизоваться, нажав Authorize в правом верхнем углу и введя логин и пароль, которые мы задали в самом начале:
Далее можно нажать на Show/Hide для некоторых пунктов и посмотреть доступные операции:
Обратите внимание на цветовое кодирование, оно поможет вам понимать, чем вы занимаетесь при тестировании API:
Методы GET будут подсвечены синим цветом - это абсолютно безопасно, так как они только читают данные.
Желтым цветом будут подсвечены методы PUT - это изменение каких-либо настроек.
Зеленые методы POST - это создание новых сущностей (например, сетевых адаптеров) или выполнение операций (например, клонирование ВМ).
Красные методы DELETE - удаление сущностей.
Каждую операцию можно раскрыть подробнее, нажав на соответствующую строчку. Например, раскроем GET /vms для VM Management:
Здесь объясняется модель данных JSON-массива, в которой ожидается прием параметров.
Если посмотреть ниже, то мы найдем кнопку TRY IT OUT!, по нажатию на которую мы получим ответ в блоке Responce Body, где будет ID виртуальных машин и путь к ним в хостовой системе:
В данном случае код ответа (Responce Code) был 200, но бывают и другие коды ответа, обратите на них внимание:
Давайте попробуем уже метод не чтения, а метод PUT (обновление настроек). Например, для PUT /vms/{id}. Здесь мы видим, что можно поменять число процессоров ВМ и объем выделенной памяти:
Если вы кликните справа на Example Value, то значение примера подставится в окошко parameters и вам останется лишь поменять числовые значения. После того, как вы измените параметры и нажмете try it out, в поле Responce body должна отобразиться новая конфигурация ВМ.
Также можно, например, создать сетевой адаптер для виртуальной машины с помощью метода POST:
Ну и затем удалить его с помощью метода DELETE (обратите внимание, что Responce code в этом случае будет 204, а не 200):
Кстати, имейте в виду, что удаление ВМ в данном случае произойдет без подтверждения, так что будьте осторожны.
Ну а дальше вы можете получить доступ к REST API Workstation или Fusion через любой REST-клиент, например, через PowerShell или Postman, но самый простой метод - это использовать curl. Как это сделать, вы можете прочитать вот в этой статье Вильяма Лама.
Таги: VMware, WOrkstation, Fusion, API, REST API, Обучение
Ну а сегодня расскажем о новых возможностях программных интерфейсов API в vSphere 6.7. В первую очередь надо сказать, что появилось несколько наборов RESTful API, которые были полностью переписаны, чтобы соответствовать современному состоянию виртуальной инфраструктуры vSphere.
1. API виртуальных модулей (Appliance API).
Здесь основные улучшения произошли в сфере резервного копирования и восстановления модулей, а также их обновления. Помимо этого, был улучшен процесс мониторинга процесса бэкапа, и, что главное, появилась возможность запланированного запуска резервного копирования через API:
Кроме этого, теперь есть возможность управления жизненным циклом модуля и его обновлением через API. Здесь доступен полный набор интерфейсов - от предпроверок для проведения обновления, до стэйджинга и накатывания самого апдейта с последующей валидацией.
Многие API виртуальных модулей, которые ранее были доступны как превью, теперь выпущены официально. Среди них: управление службами модуля, изменение сетевой конфигурации и настроек NTP. Также появилась давно ожидаемая фича - питанием виртуального модуля теперь можно управлять через API.
2. Обновления vCenter API.
В интерфейсе vCenter RESTful API появилось более 40 новых методов. Они касаются взаимодействия с гостевыми ОС виртуальных машин, просмотра политик хранилищ Storage Policy Based Management (SPBM), а также управления службами vCenter.
Кроме того, через API теперь доступны операции по управлению жизненным циклом vCenter - развертывание, реконфигурация развернутой топологии, отчет о текущем состоянии Platform Services Controller (PSC) и т.п.
Также появилась возможность и обновлять vCenter через API:
3. Прочие улучшения API.
Помимо перечисленного, были сделаны улучшения в vSphere Web Services (SOAP) API. Появились методы по очистке всех сработавших алармов, функциональность управления виртуальным Trusted Platform Module (TPM), а также механизмом Enhanced vMotion Compatibility (EVC).
Также, как мы писали вот тут, появился новый метод по созданию мгновенного клона ВМ (Instant Clone):
Ну и, наконец, появилась возможность узнать дату и время создания виртуальной машины. Для этого нужно обратиться к свойству createDate объекта VirtualMachineConfigInfo.
Недавно компания VMware выпустила интересный документ VMware vSphere APIs for I/O Filtering (VAIO), в котором описываются основные принципы работы данной технологии. Ниже мы расскажем о них вкратце, а также затронем тему того, каким образом можно использовать VAIO в производственной среде.
VAIO - это технология и API, которые позволяют получать прямой доступ к потоку ввода-вывода (I/O Stream) гостевой ОС виртуальной машины. Механизм VAIO уже сейчас способствует созданию партнерских продуктов для решения самых разнообразных задач (например, кэширование write-back и write-through). VAIO основан на механике Storage Policy Based Management (SPBM), которая предназначена для управления правилами хранения виртуальных машин и их работой с хранилищами.
Техническая реализация данного механизма подразумевает использование драйвера VAIO (filter driver), который устанавливается на хосте VMware ESXi как пакет VIB и не требует установки никакого специального ПО в гостевой ОС виртуальной машины.
Посмотрим на эту картинку, на которой изображен путь данных от виртуальной машины к физическому устройству хранения. На ней представлены 2 компонента, относящиеся к VAIO. Первый - это VAIO фреймворк, работающий на уровне ядра VMkernel и определяющий действующую политику фильтра. Второй - это IO Filter, представляющий собой программное обеспечение, работающее на уровне пользовательской среды исполнения (User World) сервера ESXi. Этот драйвер фильтра исполняет свою функцию (например, кэширование данных или их репликация), после чего передает их на физическое устройство хранения для записи.
Такая архитектура позволяет драйверу IO-фильтра получать доступ к потоку ввода-вывода, не сильно не влияя на производительность исполнения SCSI-команд. Еще одна особенность IO-фильтра - это возможность иметь доступ к потоку ввода-вывода как в сторону записи (от ОС к хранилищу), так и в обратную сторону (квитанции о прохождении команд). Это полезно, например, при использовании IO-фильтра для технологии репликации, где очень важно получать квитанции о записи данных на диск.
Кстати, SCSI-команды попадают к IO-фильтру сразу после того, как они проходят слой эмуляции SCSI (он же vSCSI), что позволяет использовать VAIO для любых типов хранилищ - VMFS, NFS, SCSI и vSAN. Ну а перехват команд IO-фильтром перед их отсылкой в сетевой стек к хранилищу позволяет обеспечить целостность данных и безопасность.
Еще, если внимательно посмотреть на архитектуру прохождения потока ввода-вывода, можно заметить, что драйвер IO-фильтра работает на уровне User World, а значит в целом не влияет на стабильность работы сервера ESXi. Даже если он вдруг прекратит свою работу, основной стек прохождения SCSI-команд, расположенный в ядре, продолжит работать в нормальном режиме.
Работает IO Filter на уровне отдельных VMDK-дисков конкретных ВМ, что открывает широкие возможности для механизма политик Storage Policy Based Management (SPBM) и применения их к отдельным виртуальным машинам и сервисам.
Все вышеперечисленное позволяет применять VMware VAIO при решении следующих типов задач:
Encryption – стороннее ПО за счет использования механизма VAIO может на лету шифровать и расшифровывать поток данных от виртуальной машины. Таким образом на хранилище будут помещаться уже шифрованные данные. Гранулярность работы VAIO позволяет обслуживать данные, идущие даже не от всей виртуальной машины, а только от одного приложения.
De-duplication - этот механизм уже использует решение VMware Virtual SAN. В реальном времени можно дедуплицировать данные, проходящие через драйвер и в таком виде уже класть на хранилище в целях экономии дискового пространства. Эта техника доступна и партнерам VMware.
Tiering - данные различной степени важности, критичности или классифицированные по другим критериям теперь можно класть на хранилища с разными характеристиками производительности и доступности (ярусы). Механизм VAIO тут поможет проанализировать характер данных и определить конечное их место назначения.
Analytics - теперь можно анализировать непосредственно поток данных от конкретной виртуальной машины и на основе этого строить множество различных решений, включая решения по кэшированию (например, такой продукт как PrimaryIO, который можно напрямую подключить к гипервизору). Затем можно, например, искать в трафике данные определенных приложений, либо, использовать механизм write-back кэширования.
Технология VAIO работает, начиная с VMware vSphere 6.0 Update 1, поддерживает горячую миграцию vMotion (VAIO должна быть доступна на целевом хосте) и кластеры VMware DRS (должна быть доступна на всех хостах).
Давайте теперь посмотрим, как VAIO работает на практике на одном из примеров. Чтобы начать работать с VAIO, вам нужно установить IO Filter в виде VIB-пакета, который реализует функциональную составляющую партнерского продукта для VMware vSphere.
Как правило, вместе с фильтром идет и политика SPBM (аналогичная тем, которые есть для vSAN или VVols, например), которую можно назначать виртуальным машинам на уровне виртуальных дисков VMDK.
Эту политику можно назначить при создании виртуальной машины в разделе Select Storage (в данном случае это политика кэширования на SSD):
Пример политики, идущей вместе с фильтром, как правило включает в себя Common Rule - правила, которые реализуют Data Services (то есть основной функционал фильтра) и определяются через компоненты Storage Policy Components (путем добавления компонентов в разделе Common Rules).
Например, в данном случае это тип кэширования Write Through или Write Back, который мы задаем в разделе Common Rules при создании новой политики хранения:
По умолчанию эти компоненты устанавливаются вместе со встроенными фильтрами vSphere и другими продуктами, которые пополняют набор IO-фильтров, а соответственно и компонентов по мере их установки. За счет использования Storage Policy Components возможности IO-фильтров могут быть включены в любую из уже настроенных политик VM Storage Policies.
Это очень удобно, поскольку на данный момент виртуальная машина или VMDK-диск могут иметь только одну примененную к ним политику хранения, но к ним можно добавить компоненты от разных фильтров.
Как видно из картинки, на данный момент не так много партнеров используют технологию VAIO для своих продуктов, а категорий решений всего две - репликация и кэширование. Но VMware активно работает в этом направлении, и в скором времени, возможно, мы увидим еще несколько продуктов, реализующих функционал IO-фильтров для решения новых задач.
Как знают некоторые администраторы VMware vSphere, среди интерфейсов vSphere API есть механизм взаимодействия с виртуальными машинами через VMware Tools, который называется VMware vSphere Guest API.
Утилита VMware Tools Client, написанная Pierre Laine, позволяет подключиться к виртуальной машине через этот интерфейс, загружать/скачивать с нее файлы и скрипты и исполнять их. Это может оказаться полезным, когда вы потеряли сетевой доступ к виртуальной машине (например, внутри гостевой ОС что-то отвалилось).
VMware Tools Client соединяется с сервером vCenter, получает его иерархию через vCenter Inventory Service, после чего можно работать с виртуальными машинами для следующих целей:
Выполнение в гостевой ОС отдельных команд (например, пинг из ВМ) или скриптов
Загрузка, сохранение и удаление скриптов на ВМ (а также любых других файлов)
Загрузка скрипта из файла
Утилита кроссплатформенная с интерфейсом на JavaFX, поэтому может быть запущена на Linux/Windows системах. Также она не требует установки. На данный момент она находится в бете версии 0.2. В составе идет база данных SQLLite, в которой хранятся логины/пароли от vCenter и виртуальных машин. Скачать VMware Tools Client можно по этой ссылке.
Как вы знаете, VMware планирует постепенно сделать виртуальный модуль vCenter Server Appliance (vCSA) на основе Linux основным средством управления виртуальной инфраструктурой vSphere. Мы уже писали про несколько полезных штук для vCSA (например, тут, тут и тут), а сегодня расскажем об интерфейсе исполнения API-команд в оболочке модуля.
Эти API-команды позволяют выполнять различные административные задачи с сервисами виртуального модуля vCSA, чтобы поддерживать его работоспособность.
Например, с помощью API-вызовов можно изменять настройки синхронизации времени, осуществлять мониторинг процессов vCSA или настраивать параметры отсылки уведомлений SNMP.
Вот основные наборы команд, которые можно использовать:
appliance.health - все, что касается текущего состояния виртуального модуля.
appliance.monitoring - наблюдение за объектами vCSA.
appliance.recovery - управление задачами резервного копирования и восстановления компонентов самого модуля.
appliance.system - информация о системе.
appliance.version1 - управление консолями и интерфейсами доступа (DCUI, SSH и т.п.), а также правами доступа. Кроме того, через это пространство имен происходит управление SNMP, сетевыми настройками, фаерволом и многим другим.
На видео выше вы можете увидеть пример вызовов этих API-функций, а в этом разделе документации приведен полный их перечень и описание.
Совсем недавно мы писали о том, что на сайте проекта 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 часто сталкиваются с необходимостью получить какие-то файлы конфигурации с 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.
Не так давно мы писали о новых возможностях лидирующей на рынке платформы виртуализации VMware vSphere 6, которая на данный момент доступна в публичной бета-версии.
Одной из новых возможностей был заявлен механизм vSphere APIs for IO Filtering (VAIO - как ноутбуки от Sony), который позволяет получать прямой доступ к потоку ввода-вывода (I/O Stream) гостевой ОС виртуальной машины. Несмотря на то, что об этой штуке писали достаточно мало, механизм VAIO в будущем будет способствовать созданию множества партнерских продуктов для решения самых разнообразных задач. VAIO основан на механике Storage Policy Based Management (SPBM), которая предназначения для управления хранением виртуальных машин.
Техническая реализация данного механизмв подразумевает использование драйвера VAIO (filter driver), который устанавливается на хосте VMware ESXi как пакет VIB и не требует установки никакого специального ПО в гостевой ОС виртуальной машины. Работает он на уровне VMDK-диска отдельной ВМ и позволяет не только получать данные из потока ввода-вывода, но и изменять его при течении данных в ту или другую сторону.
Это открывает возможности для применения VMware VAIO при решении следующих типов задач:
Encryption – стороннее ПО за счет использования механизма VAIO может на лету шифровать и расшифровывать поток данных от виртуальной машины. Таким образом на хранилище будут помещаться уже шифрованные данные. Гранулярность работы VAIO позволяет обслуживать данные идущие даже не от всей виртуальной машины, а только от одного приложения.
De-duplication - этот механизм уже использует решение VMware Virtual SAN. В реальном времени можно дедуплицировать данные, проходящие через драйвер и в таком виде уже класть на хранилище в целях экономии дискового пространства. Теперь это станет доступно и партнерам VMware.
Tiering - данные различной степени важности, критичности или классифицированные по другим критериям теперь можно класть на хранилища с разными характеристиками производительности и доступности (ярусы). Механизм VAIO тут поможет проанализировать характер данных и определить конечное их место назначения.
Analytics - теперь можно анализировать непосредственно поток данных от конкретной виртуальной машины и на основе этого строить множество различных решений, включая решения по кэшированию (например, такой продукт как CahceBox можно будет напрямую подключить к гипервизору). Затем можно, например, искать в трафике данные определенных приложений, либо, например, использовать механизм write-back кэширования.
На первом этапе запуска технологии VAIO компания VMware решила остановиться на двух путях ее имплементации:
1. Возможности кэширования данных на SSD-накопителях (write-back кэширование для операций записи). Дизайн-документ для API тут делала компания SanDisk, которая первой будет использовать VAIO в своих продуктах. Вот их презентация:
А вот технология write-back кэширования на стороне сервера с использованием механизма VAIO:
2. Возможности высокопроизводительной репликации. Реализация данного аспекта VAIO позволит получать прямой доступ к потоку ввода-вывода и сразу же передавать его на другой хост, не прибегая к дополнительным механизмам, которые сегодня используются для реализации техник репликации. На данный момент заявлено, что такой тип репликации будет поддерживать ПО EMC RecoverPoint, команда которого принимала участие в разработке техники VAIO.
Однако несмотря на все плюсы технологии vSphere APIs for IO Filtering, в ней есть и негативные стороны:
Во-первых, это вопрос надежности. Так как между виртуальной машиной и хранилищем есть дополнительное звено, которое может рухнуть, понижается и совокупная надежность платформы виртуализации.
Во-вторых, это вопрос производительности. Прослушка трафика посредством VAIO неизбежно создает нагрузку на аппаратные ресурсы хоста ESXi.
В-третьих, это вопрос безопасности. Представим, что я написал софт, который прозрачно шифрует и расшифровывает трафик отдельной виртуальной машины на хосте ESXi, после чего внедрил его в инфраструктуру предприятия, где все это произошло незаметно для пользователей и администраторов. Затем я просто убираю это ПО из гипервизора (например, при увольнении), после чего данные на хранилищах превращаются в тыкву, а компания сталкивается с серьезной проблемой.
В целом же, подход VMware в данном вопросе очень радует - она открывает партнерам возможности разработки собственных продуктов для решения задач пользователей, а значит предоставляет и неплохую возможность заработать.
Первые реализации механизма vSphere APIs for IO Filtering мы должны увидеть уже в первой половине 2015 года, когда выйдет обновленная версия платформы VMware vSphere 6.
Компания Citrix недавно объявила о выпуске платформы CloudStack 3, предназначенной для построения публичных и частных облаков, предлагающих услуги Infrastructure as a Service (IaaS), то есть предоставление виртуальных машин по требованию в аренду (из публичного облака - сервис-провайдеры), либо внутри предприятия (частное облако), а также в гибридном облаке (то есть, когда при недостатке внутренних ресурсов используются вычислительные мощности на стороне сервис-провайдера). Таким образом, сервис-провайдеры могут делать облака наподобие Amazon EC2 (решение так и позиционируется "Amazon style").
Для тех, кто не в курсе: CloudStack - это open source платформа "облачного движка", распространяемая под лицензией GPL, которая позиционируется как решение IaaS, способное управлять виртуальной инфраструктурой на базе сразу нескольких гипервизоров - Citrix XenServer, Xen Cloud Platform, KVM, Oracle VM (VirtualBox) и VMware vSphere.
Демо платформы CloudStack:
Основные новые возможности CloudStack 3:
Теперь CloudStack 3 включает в себя специализированный вариант платформы виртуализации Citrix XenServer 6.
Возможность предоставления сетевой инфраструктуры в аренду (Networking-as-a-Service, NaaS) как в Amazon Virtual Private Cloud (VPC) средствами сторонних решений, например Citrix NetScaler SDX и VPX. Это позволяет строить высокопроизводительные виртуальные изолированные сети между разными датацентрами и централизованно обслуживать их.
Система каталогов сервисов, позволяющая сервис-провайдерам более эффективно продавать виртуальные машины и сетевые службы.
Простой интерфейс для клиентов, в который встроены функции самообслуживания в виртуальной среде (так называемая "оркестровка" рабочих процессов).
Интеграция с OpenStack Swift (OpenStack Object Storage) - решением для создания распределенной среды хранения на базе многоузловых кластеров хранилищ с горизонтальным масштабированием (то есть наращивание емкости производится добавлением узлов в кластер).
Возможности CloudStack как облачной платформы:
Совместимость по API с облачными платформами различных производителей Amazon Web Services API, Citrix Cloud Center (C3) API и VMware vCloud API.
Возможности развертывания виртуальных машин по требованию, поддержка резервирования и ограничения ресурсов.
Возможность централизованного мониторинга и отчетности об облачной инфраструктуре.
AJAX based пользовательский интерфейс управления, который может быть просто интегрирован в корпоративный портал или веб-сайт сервис-провайдера.
Возможности Dynamic Workload Management, позволяющие автоматизировать распределение вычислительных и дисковых ресурсов в рамках инфраструктуры на базе политик организации.
Поддержка шаблонов виртуальных машин как типовых сервисов для развертывания в облаке с широкими возможностями по управлению на базе ролевой модели.
Широкие возможности по управлению виртуальными сетями: сегментация VLAN, MPLS, Direct Attached IP, поддержка интеграции с устройствами Virtual Routers, Firewalls, Load Balancers и другое.
Средства для организации сдачи виртуальных машин в аренду - интеграция с системами сопровождения аккаунтов (биллинг и т.п.).
Возможность определять классы обслуживания для клиентов (SLA) в соответствии с классами пользователей и задачами в виртуальных машинах на базе "resource footprints".
Поддержка средств отказоустойчивости в платформах виртуализации.
Возможность управления облачной инфраструктурой, включающей в себя несколько датацентров (одна или несколько организаций).
Несмотря на то, что CloudStack продолжает позиционироваться как независимое от гипервизоров решение, сама компания Citrix все-таки двигает под него свою платформу XenServer 6, с которой, как утверждают в компании, облачная инфраструктура будет работать эффективнее. Кроме того, поддержка таких решений как Citrix NetScaler и Citrix CloudBridge как бы намекает нам на то, что гипервизор и смежные продукты нужно взять у Citrix.
На данный момент CloudStack третьей версии доступен как бета, окончательный релиз ожидается в конце марта. Скачать CloudStack 3 можно совершенно бесплатно по этой ссылке (версии для RHEL/CentOS и Ubuntu).
Многие пользователи виртуальной инфраструктуры VMware vSphere 4 и серверов ESX не раз сталкивались с публикациями о том, как можно управлять серверами виртуализации и виртуальными машинами с помощью интерфейса PowerShell. Для VMware vSphere это реализуется средствами пакета PowerCLI, который представляет собой надстройку к PowerShell для управления виртуальной инфраструктурой с помощью сценариев командной строки.
RSS
