На днях пришла пара важных новостей о продуктах компании StarWind Software, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ для виртуальной инфраструктуры.
StarWind HCA All-Flash
Первая важная новость - это выпуск программно-аппаратного комплекса StarWind HyperConverged Appliance (HCA) All-Flash, полностью построенного на SSD-накопителях. Обновленные аппаратные конфигурации StarWind HCA, выполненные в форм-факторе 1 или 2 юнита, позволяют добиться максимальной производительности хранилищ в рамках разумной ценовой политики. Да, All-Flash постепенно становится доступен, скоро это смогут себе позволить не только большие и богатые компании.
Решение StarWind HCA - это множество возможностей по созданию высокопроизводительной и отказоустойчивой инфраструктуры хранилищ "все-в-одном" под системы виртуализации VMware vSphere и Microsoft Hyper-V. Вот основные высокоуровневые возможности платформы:
- Поддержка гибридного облака: кластеризация хранилищ и active-active репликация между вашим датацентром и любым публичным облаком, таким как AWS или Azure
- Функции непрерывной (Fault Tolerance) и высокой доступности (High Availability)
- Безопасное резервное копирование виртуальных машин
- Катастрофоустойчивость на уровне площадок
- Максимизация производительности за счет RDMA
- Распределенное кэширование
- Проактивная поддержка вашей инфраструктуры специалистами StarWind
- И многое, многое другое
Сейчас спецификация на программно-аппаратные модули StarWind HCA All-Flash выглядит так:
После развертывания гиперконвергентной платформы StarWind HCA она управляется с помощью единой консоли StarWind Command Center.
Ну и самое главное - программно-аппаратные комплексы StarWind HCA All-Flash полностью на SSD-дисках продаются сегодня, по-сути, по цене гибридных хранилищ (HDD+SSD). Если хотите узнать больше - обращайтесь в StarWind за деталями на специальной странице. Посмотрите также и даташит HCA.
Новый StarWind Virtual SAN V8 для Hyper-V
Второй важный релиз - это обновленная версия продукта StarWind Virtual SAN V8 for Hyper-V (билд 13481 от 25 февраля 2020 года).
Давайте посмотрим, что нового появилось в StarWind Virtual SAN V8 for Hyper-V:
Ядро продукта
- Добавлен мастер для настройки StarWind Log Collector. Теперь можно использовать для этого соответствующее контекстное меню сервера в Management Console. Там можно подготовить архив с логами и скачать их на машину, где запущена Management Console.
- Исправлена ошибка с заголовочным файлом, который брал настройки из конфига, но не существовал на диске, что приводило с падению сервиса.
- Улучшен вывод событий в файлы журнала, когда в системе происходят изменения.
- Улучшена обработка ответов на команды UNMAP/TRIM от аппаратного хранилища.
- Добавлена реализация процессинга заголовка и блога данных дайждестов iSCSI на процессорах с набором команд SSE4.2.
- Максимальное число лог-файлов в ротации увеличено с 5 до 20.
Механизм синхронной репликации
- Процедура полной синхронизации была переработана, чтобы избежать перемещения данных, которые уже есть на хранилище назначения. Делается это путем поблочного сравнения CRC и копирования только отличающихся блоков.
- Исправлена ошибка падения сервиса в случае выхода в офлайн партнерского узла при большой нагрузке на HA-устройство.
- Значение по умолчанию пинга партнерского узла (iScsiPingCmdSendCmdTimeoutInSec) увеличено с 1 до 3 секунд.
- Исправлена ошибка с утечкой памяти для состояния, когда один из узлов был настроен с RDMA и пытался использовать iSER для соединения с партнером, который не принимал соединений iSER.
Нотификации по электронной почте
- Реализована поддержка SMTP-соединений через SSL/STARTTLS.
- Добавлена возможность аутентификации на SMTP.
- Добавлена возможность проверки настроек SMTP путем отправки тестового сообщения.
Компоненты VTL и Cloud Replication
- Список регионов для всех репликаций помещен во внешний файл JSON, который можно просто обновлять в случае изменений на стороне провайдера.
- Исправлена обработка баркодов с длиной, отличающейся от дефолтной (8 символов).
- Исправлена ошибка падения сервиса при загрузке tape split из большого числа частей (тысячи).
- Исправлены ошибки в настройках CloudReplicator Settings.
Модуль StarWindX PowerShell
- Обновился скрипт AddVirtualTape.ps1, был добавлен учет параметров, чувствительных к регистру.
- Для команды Remove-Device были добавлены опциональные параметры принудительного отсоединения, сохранения сервисных данных и удаления хранимых данных на устройстве.
- Добавлен метод IDevice::EnableCache для включения и отключения кэша (смотрите примеры FlashCache.ps1 и FlushCacheAll.ps1).
- VTLReplicationSettings.ps1 — для назначения репликации используется число, кодирующее его тип.
- Свойство "Valid" добавлено к HA channel.
- Сценарий MaintenanceMode.ps1 — улучшенная обработка булевых параметров при исполнении сценария из командной строки.
- Тип устройства LSFS — удален параметр AutoDefrag (он теперь всегда true).
Средство управления Management Console
- Небольшие улучшения и исправления ошибок.
Скачать полнофункциональную пробную версию StarWind Virtual SAN for Hyper-V можно по этой прямой ссылке. Release Notes доступны тут.
Читать далее... - читать дальше и комментировать
|
Как некоторые из вас помнят, компания VMware в 2018 году анонсировала специальное издание vSphere Platinum, которое вышло одновременно с обновлением vSphere 6.7 Update 1. Решение vSphere Platinum стало комбинацией из двух продуктов: платформы VMware vSphere Enterprise Plus и решения VMware AppDefense. Помимо этого, в рамках издания Platinum был достпен специальный плагин для vSphere Client, который реализовывал интеграцию vSphere и AppDefense (называется он vCenter Server plugin for vSphere Platinum).
В целом, решение vSphere Platinum особо нигде не обсуждалось, и, как стало теперь понятно, никем особенно не покупалось. Поэтому VMware решила снять его с производства (End of Availability), начиная со 2 апреля 2020 года. Одновременно с vSphere Platinum в прошлое с этой даты уходят и решения VMware Cloud Foundation Platinum и VMware vCloud Suite Platinum. Компоненты решений продолжат поддерживаться в соответствии с VMware Lifecycle Product Matrix.
Существующие пользователи vSphere Platinum после объявленной даты получат лицензии vSphere Enterprise Plus, SaaS-продукт VMware AppDefense и плагин VMware AppDefense Plugin for vSphere (о том, где скачать этот плагин написано вот тут). Для пользователей vCloud Suite Platinum и Cloud Foundation Platinum ничего не меняется, за исключением эволюции самой vSphere, входящей в состав пакетов. Читать далее... - читать дальше и комментировать
|
На сайте VMware Labs очередное обновление - обновился пакет vRealize Build Tools до версии 2.4.18. С помощью данного средства разработчики и администраторы, работая совместно, могут реализовать новые сценарии и рабочие процессы vRealize Automation и vRealize Orchestrator, используя стандартные практики DevOps. Напомним, что о прошлой версии этого решения мы писали вот тут.
Пакет сфокусирован на качестве кода, его повторном использовании, модульном тестировании, управлении взаимосвязями и параллельных релизах проектов под платформу vRealize. vRealize Build Tools представляют собой расширения (extensions), упакованные в формат репозитория Maven, которые поддерживают использование IDE (через Maven), а также интерфейса CLI для разработки, тестирования и развертывания решений для платформ vRA/vRO.
Давайте посмотрим что нового появилось во второй версии:
- Поддержка решения vRA 8, его блупринтов (blueprints), кастомных форм, подписок и механик flavor-mapping
- Поддержка существующего контента и импорт его для vRO 8
- Поддержка функций vRO 8 по экспорту рабочих процессов в структуру папок, созданную на базе их тэгов
- Запуск рабочих процессов на vRO с использованием команды maven
- Возможность сохранения JS Actions IDs на источнике в целях предотвращения конфликтов в среде vRO
- Улучшения экспериментальной поддержки проектов TypeScript
- Исправления ошибок и обновление документации
Для начала работы с vRealize Build Tools вам понадобятся следующие инструменты:
Скачать vRealize Build Tools можно по этой ссылке.
Читать далее... - читать дальше и комментировать
|
В конце января мы писали о средстве Power vRA Cloud, которое позволяет отобразить сложное множество программных интерфейсов VMware vRealize Automation Cloud API в простой набор функций PowerShell. На днях вышло обновление этого PowerShell-модуля - Power vRA Cloud 1.1.
Помимо множества исправлений ошибок, в утилите появилось несколько новых командлетов:
- Add-vRA-Project-Administrator
- Add-vRA-Project-Member
- Get-vRA-DeploymentFilters
- Get-vRA-DeploymentFilterTypes
- Get-vRA-FabricNetworksFilter
- Get-vRA-FabricImagesFilter
- Remove-vRA-Project-Administrator
- Remove-vRA-Project-Member
- Update-vRA-Project-ZoneConfig
Напомним, что этот модуль не поддерживается со стороны VMware (как и все утилиты на VMware Labs, находящиеся в статусе Tech Preview), поэтому используйте его осторожно.
Скачать Power vRA Cloud можно по этой ссылке. Документация по использованию данного средства скачивается вместе с самим модулем.
Читать далее... - читать дальше и комментировать
|
В последнее время VMware уделяет очень много внимания средствам для работы с кластерами Kubernetes (например, посмотрите нашу статью про решения Tanzu Mission Control и Project Pacific). Как оказалось, у VMware постоянно обновляется специальная утилита Weathervane 2.0, которая позволяет производить тестирование производительности кластеров Kubernetes под нагрузкой. Напомним, что о первой версии этой утилиты мы писали два с половиной года назад.
Это средство может оказаться вам полезным в следующих случаях:
- Когда нужно сравнить два кластера по производительности (например, на разном оборудовании)
- Когда нужно понять влияние изменений конфигурации кластера на производительность
- Когда нужно проверить корректность настройки нового кластера перед запуском его в производственную среду
Для запуска Weathervane вам нужно создать образы контейнеров, подготовить конфигурационный файл и запустить бенчмарк. Далее утилита сама развернет контейнеры в кластере, запустит приложения и соберет результаты тестирования.
Weathervane деплоит бенчмарк-приложение на узлах и подает туда нагрузку, которая генерируется через компонент Workload driver. Этот драйвер может располагаться как вместе с бенчмарк-приложением, так и во внешней среде, в отдельном кластере.
Weathervane можно установить на постоянную нагрузку для фиксированного числа симулируемых пользователей, а можно настроить на поиск максимального числа пользователей таким образом, чтобы выполнялись требования quality-of-service (QoS). В последнем случае результатом теста будет максимальное число WvUsers, которое способен выдержать кластер. Собственно, этот параметр и нужно использовать для сравнения кластеров по производительности.
Вот как выглядят компоненты решения Weathervane (компонент Run harness отвечает за исполнение тестовых прогонов и получение результатов тестирования):
Weathervane использует многоярусное веб-приложение, которое включает в себя stateless и stateful сервисы. Вы можете выбрать один из этих типов развертывания приложений. Несколько экземпляров приложений можно запускать в рамках одного прогона, что позволяет масштабировать тестирование в больших кластерах.
Приложение Weathervane состоит из нескольких ярусов. Логика приложения реализована через Java-сервисы, запущенные на сервере Tomcat, которые коммуницируют через REST API и сообщения RabbitMQ, а Zookeeper используют для координации. Бэкенд-хранилища реализованы средствами PostgreSQL и Cassandra. Фронтенд веб-серверы и прокси-кэш серверы реализованы на Nginx.
Недавно VMware провела тестирование кластеров с помощью Weathervane 2 для двух сценариев. В первом случае коллеги сравнили производительность двух поколений серверов:
Результат для различного числа микроинстансов приложений получился таким:
Как видно из картинки, если судить по числу WvUsers, то новое железо выиграло у старого в два раза (там и ядер в процессорах больше в 2 раза, но работают они на меньшей частоте). А на эквивалентном числе пользователей производительность кластера на новом оборудовании была на 15-29% выше.
Второй тест делался на разных сетевых конфигурациях кластеров Kubernetes, которые масштабировались до 16 экземпляров приложений. В первом случае использовалась механика Flannel/VXLAN, а во втором - Flannel/host-gw, которая и выиграла у первой примерно на 10%:
Скачать утилиту VMware Weathervane 2.0 можно из репозитория на GitHub по этой ссылке.
Читать далее... - читать дальше и комментировать
|
Cody Hosterman, известный своими заметками про PowerCLI, написал интересную статью о том, как запоминать дефолтные параметры на примере свойств соединения с дисковым массивом. Это может вам оказаться полезным, например, в случае если вы работаете с дисковым массивом в интерактивном режиме, при этом не хотите каждый раз указывать параметры соединения.
К примеру, при использовании модуля PureStorage.FlashArray.VMware есть возможность передавать параметры соединения, сохраненные в глобальной переменной $Global:DefaultFlashArray. Неудобство этого метода в том, что каждый раз вы должны указывать параметр -Array:
Поэтому в PowerCLI заложен отличный механизм дефолтных параметров для нужных вам командлетов. Например, можно создать переменную с параметрами соединения с массивом:
$flasharray = new-pfaarray -endpoint 10.21.202.60 -credentials (get-credential) -ignoreCertificateError
Далее можно записать эту переменную в дефолтные параметры:
$PSDefaultParameterValues = @{
"*-pfa*:Array"=$flashArray;
}
Это позволит для параметра, называющегося Array применять параметры соединения из переменной $flashArray. При этом эти параметры будут применяться только для командлетов, содержащих "-pfa" в своем названии (они есть только в модуле PureStoragePowerShellSDK).
Для всего модуля и всех командлетов нет простого способа задать дефолтные параметры, но можно получить в сценарии список всех доступных командлетов и для всех них прописать правило использования параметра -Array:
$psCMDs = (get-command -Module PureStoragePowerShellSDK).Name
$defaultParamHash = @{}
foreach ($psCMD in $psCMDs)
{
$defaultParamHash.Add("$($psCMD):Array",$flashArray)
}
$PSDefaultParameterValues = $defaultParamHash
После этого вы сможете просто использовать командлеты без параметров, например, Get-PfaVolumes, чтобы получить все тома с заданного в дефолтном соединении массива:
Аналогично способ будет работать и для всех остальных параметров командлетов и любых других модулей.
Читать далее... - читать дальше и комментировать
|
Как вы знаете, каждый год VMware раздает награды VMware vExpert тем, кто вносит вклад в развитие сообщества, собранного вокруг технологий виртуализации. Звание это присуждается уже довольно давно, его носителей стало так много, что появилась даже уже более узкая подкатегория vExpert Pro.
В России тоже набралось уже 10 человек носителей vExpert, не так много, но и не мало (на уровне Швеции и Норвегии). Понятное дело, что большинство vExpert из тех стран, где все хорошо с английским, так как аудитория блогов на английском языке шире, что мотивирует авторов писать посты (а в целом vExpert дают за ведение блога).
Вот так выглядит первая десятка:
А вот те специалисты из России, кто получил vExpert в этом году:
Полный список получателей vExpert опубликован тут.
Читать далее... - читать дальше и комментировать
|
Многие пользователи платформы VMware vSphere знают, что есть такой вариант развертывания и эксплуатации распределенной виртуальной инфраструктуры как ROBO (Remote or Brunch Offices). Она подразумевает наличие одного или нескольких главных датацентров, откуда производится управление небольшими удаленными офисами, где размещено несколько серверов VMware ESXi под управлением собственного vCenter или без него.
В конце прошлого года компания VMware выпустила интересный документ "Performance of VMware vCenter Server 6.7 in Remote Offices and Branch Offices" (мы уже немного рассказывали о нем тут), где рассматривается главный аспект применения такого сценария - производительность. Ведь удаленные офисы могут располагаться в других городах, странах и даже континентах, доступ к которым осуществляется по разным типам соединений (например, 4G или спутник), поэтому очень важно, сколько трафика потребляют различные операции, и как быстро они отрабатывают с точки зрения администратора.
Параметры различных типов сетевых соединений в VMware свели в табличку (в правой колонке, что получалось в результате использования тестовой конфигурации, а в левой - как бывает в сценариях с реальными датацентрами):
Для тестирования использовалась удаленная конфигурация из 128 хостов ESXi, где было зарегистрировано 3840 виртуальных машин (960 ВМ на кластер, 30 на хост), из которых включалось до 3000 машин одновременно.
Сначала посмотрим на фоновый трафик для синхронизации хостов ESXi и vCenter, в зависимости от числа виртуальных машин на хосте (трафик в сторону vCenter):
Теперь посмотрим на трафик в обратную сторону (там просто передаются команды к хостам, ВМ не сильно затрагиваются, поэтому отличия небольшие):
Теперь посмотрим на то, как отличается объем передаваемого трафика от ESXi к vCenrer в зависимости от уровня собираемой статистики на сервере VMware vCenter:
Теперь давайте посмотрим, как отличается трафик к vCenter в зависимости от числа включенных виртуальных машин на хосте:
Посмотрим на трафик в обратную сторону (от vCenter к хостам ESXi) в зависимости от уровня статистики:
Теперь интересно посмотреть, сколько операций в минуту может выполнять vCenter с удаленными серверами ESXi в зависимости от типа соединения, а также задержки в секундах при выполнении операций:
Теперь посмотрим на задержки при выполнении отдельных операций, в зависимости от типа соединения:
Авторы документа отмечают, что больше всего на производительность операций vCenter влияет не полоса пропускания, а latency между сервером vCenter (который может быть в головном офисе) и хостами ESXi (которые могут быть на удаленной площадке).
Теперь посмотрим на сетевой трафик от хоста ESXi к серверу vCenter, который включает в себя фоновый трафик, а также собираемую статистику Level-1:
Посмотрим на такой трафик в обратную сторону - от ESXi к vCenter:
Ну а теперь посмотрим задержки на выполнение операций уже с хостами ESXi, а не с виртуальными машинами:
И в заключение, посмотрим на трафик от хостов ESXi к серверу vCenter при выполнении операций с хостами:
В общем, очень интересный документ - будет не лишним прочитать его полностью.
Читать далее... - читать дальше и комментировать
|
Как знают многие администраторы, во время установки vCenter Server Appliance (vCSA) для управления виртуальной инфраструктурой изменить MAC-адрес управляющего сервера нельзя - он генерируется при развертывании виртуального модуля установщиком и прописывается внутрь конфигурации. Между тем, если вам это все-таки по каким-то причинам требуется, Вильям Лам привел способ, как это сделать.
Ниже приведена процедура развертывания vCSA с сервера VMware ESXi.
Во-первых, надо преобразовать OVA-модуль в формат OVF, где можно будет потом изменить настройки. Делается это с помощью утилиты ovftool следующим образом:
ovftool --allowExtraConfig VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ova VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ovf
Сначала нам нужно добавить следующую конфигурацию в раздел Network конфигурации виртуального модуля OVF, содержащую нужный нам MAC-адрес:
<Item>
<rasd:Address>00:50:56:ab:cd:ef</rasd:Address>
<rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
<rasd:Connection>Network 1</rasd:Connection>
<rasd:ElementName xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">Ethernet adapter on "Network 1"</rasd:ElementName>
<rasd:InstanceID xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">3</rasd:InstanceID>
<rasd:ResourceSubType>vmxnet3</rasd:ResourceSubType>
<rasd:ResourceType>10</rasd:ResourceType>
</Item>
Далее изменяем скрипт VCSAStaticMACAddress.sh на сервере ESXi, чтобы добавить туда нужные параметры вашего vCSA и начать его развертывание в вашей виртуальной среде. Для этого его нужно выполнить с параметром --injectOvfEnv, про который написано вот тут. Он позволяет внедрить свойства OVF в виртуальный модуль vCSA при его включении.
Если вы все сделали правильно, то сможете наблюдать за прогрессом развертывания вашего виртуального модуля из браузера по ссылке:
https://[адрес VCSA]:5480
В итоге вы должны увидеть, что в настройках модуля vCSA вы получили нужный вам MAC-адрес:
Если вы хотите пропустить стадию конфигурации сетевых настроек (IP-адрес и прочее) при исполнении скрипта, нужно выставить переменную VCSA_STAGE1ANDSTAGE2 в значение false. Тогда после развертывания модуля vCSA нужно будет закончить его конфигурацию по ссылке:
https://[адрес VCSA]:5480
После развертывания эта возможность будет доступна на открывшейся странице:
Читать далее... - читать дальше и комментировать
|
На сайте проекта VMware Labs обновилось средство App Volumes Entitlement Sync до версии 2.3. Это решение позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать.
Напомним, что о версии App Volumes Entitlement Sync 2.2 мы писали вот тут, давайте посмотрим, что нового появилось в версии 2.3:
- Исправлена периодически возникающая ошибка "
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel"
- Если AppStacks на источнике и назначении не совпадают, показывается соответствующее сообщение
- В списке назначений показывается префикс монтирования
- Версия App Volumes 4.0 пока не поддерживается, ее поддержка будет добавлена в следующей версии
Скачать VMware App Volumes Entitlement Sync 2.3 можно по этой ссылке. Читать далее... - читать дальше и комментировать
|
Другие посты
Архив новостей
|  |
RSS
