Многие администраторы VMware vSphere знают, что для серверов ESXi установлен лимит одновременных миграций vMotion (входящих и исходящих) на один хост = 8 штук. Многие интересуются, а почему именно восемь? Ведь если бы увеличить это число, то виртуальные машины с хоста смогут быстрее эвакуироваться во время проведения планового обслуживания и обновления хостов при их переводе в режим обслуживания (maintenance mode).

Для разъяснения этого VMware написала интересную статью, где рассматриваются результаты тестирования миграций vMotion виртуальных машин при разных значениях параметра, ограничивающего число одновременных миграций.

Лимит на vMotion установлен со стороны сервера vCenter. Он считает ограничения следующим образом. Если на хосте 2 физических сетевых карты 40GbE NIC, выделенных под vMotion, то он считает каждую из них как емкость из 8 слотов с точки зрения миграций, а совокупная емкость хоста равна 16 слотам, из которых 2 тратится на каждую операцию vMotion:

В VMware сделали тестирование производительности одновременных миграций vMotion на хостах ESXi в рамках тестового стенда (он описан в статье), где число Concurrent vMotions регулировали с помощью следующего расширенного параметра vCenter:

По умолчанию он равен 2, что означает, что из 16 слотов хоста на каждую vMotion будет тратиться пара слотов, а суммарно будет возможно сделать 8 миграций одновременно. Если поставить это значение в 4, то, соответственно, будет выполняться 4 одновременных миграции (16/4=4).

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

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

Так и четырех:

Если миграции стоят в очереди, то для них отображается статус "Resources currently in use by other operation".

Результаты получились следующими (по оси Х изменяли объем оперативной памяти машин):

То есть восемь одновременных миграций с точки зрения эвакуации всех машин с хоста проигрывают рабочему процессу с четырьмя vMotion.

Аналогично возрастало и среднее время миграции:

Если говорить об использовании памяти, то видно что при 4 одновременных миграциях было передано на 10% меньше страниц памяти, что говорит о более эффективном ее использовании:

Для второго теста выбрали утилиту DVD Store, которую использовали для 2 типов соединений - 10 GbE и 100 GbE:

И здесь тоже результаты получились в пользу 4 одновременных миграций. Та же картина была и для 100 GbE-соединения:

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

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

Не так давно мы писали о новых возможностях средства для организации отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Среди новых возможностей мы упоминали поддержку служб vSAN File Services для растянутых кластеров (Stretched Clusters).

Дункан Эппинг раскрыл эту тему несколько подробнее. Действительно, службы vSAN File Services, так удобные для ROBO-сценариев при доступе к общим файловым шарам, теперь полностью поддерживаются.

Теперь в vSAN 7 U2 при настройке File Services надо указать, какому сайту принадлежит каждый из IP-адресов серверов файловых служб. Это Affinity rule, но оно не жесткое - при отказе виртуальных машин и рестарте их на другой площадке, оно может быть нарушено.

Но это еще не все. Для каждой файловой шары вам необходимо будет указать Affinity в ее настройках:

Это позволяет точно определить, файловую шару какой площадки следует использовать при соединении с ней клиентов. Опять-таки, это не строгое правило, на что намекает наличие опции "Either".

Ну и небольшой обзор работы файловых служб в растянутом кластере vSAN 7 Update 2 от Дункана:

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

В июне прошлого года VMware объявила о продлении поддержки vSphere 6.7 в связи с пандемией, но кто ж знал, что все настолько поменяется, поэтому о продлении срока поддержки версии 6.5 сообщили только сейчас.

Теперь период general support period для vSphere 6.5 продлен на 11 месяцев до 15 октября 2022 года, что совпадает с аналогичным для vSphere 6.7. До этого момента достижение точки прекращения предоставления полной технической поддержки (EoGS, End of General Support) было намечено на 15 ноября 2021 года. Но окончание технического сопровождения (EoTG, End of Technical Guidance) не изменилось - оно наступит 15 ноября 2023 года.

У VMware нет планов продлевать период Extended Support для vSphere 6.5, поэтому тем, кому это важно, следует смигрировать хотя бы на vSphere 6.7, где расширенная поддержка будет действовать подольше.

Расширение поддержки для vSphere 6.5 будет с некоторыми ограничениями:

• Нужно будет использовать vCenter 6.7 для хостов ESXi 6.5, потому что там есть обновленный vSphere Client вместо старого Web Client.
• Для хостов на базе vCenter Server Appliance нужно будет обновиться на vCenter Server to 6.7 Update 3 (см. тут подробнее).
• vCenter Server for Windows нужно проапгрейдить до vCenter Server to 6.7 Patch 05 или более поздней версии (см. тут).
• Если вы не сможете обновить vCenter, то будет допустимо использовать vCenter 6.5, но как-то поддерживать работоспособность Flash-клиента (см. тут).

Аналогично продляются сроки оказания технической поддержки для VMware vSAN 6.5 и 6.6 до тех же дат и с теми же условиями, что и для vSphere: теперь окончание поддержки наступит 15 октября 2022 года, но EoTG также не изменится:

Ограничения расширения поддержки для vSAN остаются теми же, что и для VMware vSphere.

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

Эксперты #CloudMTS, Veeam и Huawei расскажут об особенностях построения надежной инфраструктуры и сценариях использования современных BaaS-средств в публичных, частных и защищенных IaaS ФЗ-152 облаках.

Вебинар пройдет 8 апреля в 11:00 по московскому времени.

Темы вебинара:

• Базовые принципы производительной работы с данными
• Надежное хранение различных типов информации с использованием флэш-массивов Huawei
• On-premise vs Cloud: различия в использовании лицензий Veeam
• BaaS-стратегия в разрезе проектных решений: особенности резервного копирования в модели частных и гибридных облаков
• DR в гибридных средах: обзор ключевых возможностей
• Резервное копирование и аварийное восстановление
• Обзор востребованных сценариев использования BaaS-сервиса на практике
• Обеспечение доступности данных в сегменте ФЗ-152
• Использование облака провайдера в качестве хранилища резервных копий
• Сценарии использования BaaS-сервисов на примере клиентских кейсов

Зарегистрироваться бесплатно.

Все, кто хоть раз сталкивался с инфраструктурой виртуальных ПК VMware Horizon, знает, что в этом решении есть 3 способа развертывания виртуальных ПК для нужд различных типов пользователей. Делается это с помощью одного из следующих видов клонов:

• Full Clone - полная копия родительской виртуальной машины, абсолютно никак с ней не связанная и действующая как полноценная новая ВМ.
• Linked Clone - связанный клон виртуальной машины, создаваемый со стороны View Composer, который использует общее для всех клонов хранилище реплики на чтение, но имеет собственное хранилище для операций записи (дельта-диск или redo log). Память такой ВМ полностью независима от родительской ВМ, которая называется репликой (потому что она получается путем создания дубликата мастер-образа).
• Instant Clone - это мгновенный клон работающей виртуальной машины, то есть имеющий с ней не только общее хранилище на чтение, но и общую память, для которой также используется техника copy-on-write. То есть это больше похоже на контейнерную виртуализацию.

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

Full Clone

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

Но есть и еще некоторый минус по сравнению со связанными и мгновенными клонами - это обновления. Так как полные клоны содержат свою копию ОС, то вам нужно обновлять каждую машину, а не только реплику/родительскую ВМ, как в случае с Linked и Instant Сlones.

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

Linked Clone

Связанные клоны появились довольно давно в решении VMware View (тогда Horizon еще не было). Их созданием занимался и продолжает заниматься компонент VMware View Composer, который управляет процессами, связанными с развертыванием пулов виртуальных десктопов.

Суть таких клонов заключается в создании реплики от мастер-образа виртуального ПК, который подготовлен к массовому развертыванию (настроена ОС и установлены приложения). Реплика является родителем для новых виртуальных десктопов в плане их общего хранилища на чтение. Все операции чтения, которые создают клоны, складываются в отдельные дельта-диски за счет технологии copy-on-write, позволяющей при записи операции I/O перемещать ее в отдельный файл отличий от родительского диска.

Это очень удобно - такие десктопы создаются очень быстро (нужно только создать дельта-диски), реплика не должна быть включена и активна (только ее хранилище), а хранилище очень сильно экономится, ведь общие данные (предустановленные приложения и ОС) хранятся только в одном экземпляре. Такая модель идеально подходит для временных ПК - например, для сотрудников кол-центров, которые используют какое-то приложение во время работы (например, CRM), но в остальное время десктоп оказывается не нужен.

В этом случае, в соответствии с политикой пула Linked Clone, виртуальный ПК можно уничтожить после отключения пользователя или оставить висеть до следующего логина, а уничтожать после операции Log off. Что еще тут важно - к такому десктопу можно прицепить persistent-диск, который будет сохранять данные пользователя даже при выключении десктопа.

Недостатки тоже очевидны: инфраструктура связанных клонов опирается на компонент View Composer и зависит от его надежности, а операции записи и чтения работают медленнее, так как при записи данных нужно потратить ресурсы на обработку механизма copy-on-write, а при чтении - найти откуда данные считать - из базового образа или из дельта-дисков пользователей.

Тут надо обязательно отметить, что начиная с VMware Horizon 8 (2006), связанные клоны помечены как Deprecated-функционал, то есть вскоре (а именно, в следующей мажорной версии Horizon) будет произведен переход на мгновенные клоны, о которых рассказано ниже.

Instant Clone

Функция мгновенного клонирования виртуальной машины (ранее известная как технология VMFork) позволяет очень быстро сделать работающую копию запущенной ВМ на платформе VMware vSphere. Что важно, она не зависит от централизованного сервера, а реализована прямо на уровне гипервизора VMware ESXi. Появилась эта возможность в vSphere 6.7 и до сих пор совершенствуется.

Работает мгновенное клонирование так: посредством Memory copy-on-write "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory) на чтение, что и родительская ВМ. При этом дочерняя ВМ в общую память писать не может, а для записи и чтения собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:

Такой подход больше похож на контейнерную виртуализацию, где в рамках одной общей ОС работает несколько изолированных окружений - и это действительно так, со всеми его плюсами и минусами. Плюсом является экономия дискового пространства и памяти, а также скорость создания такого клона - он не просто быстрее создается, но и сразу включен и готов к использованию. Еще очевидным преимуществом является независимость технологии мгновенных клонов от сервисов View Composer, а значит в этом смысле надежность инфраструктуры таких ПК несколько выше.

Цикл включения нового десктопа для мгновенных клонов гораздо короче:

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

Причина падения производительности ввода-вывода проста: у родительской ВМ создается дельта-диск, который используется первым мгновенным клоном, потом базовая ВМ несколько меняется за время до создания следующего - и на момент создания нового мгновенного клона будет использоваться уже следующий дельта-диск и так далее.

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

Сейчас для связанных клонов недоступны следующие возможности:

• Кастомизация машин средствами Sysprep и Quickprep
• ОС Windows 8 и 8.1
• Функции Persona Management
• Тома Virtual Volumes (VVols)
• Нативные снапшоты на хранилищах через VAAI (vStorage APIs for Array Integration)
• Указание имен компьютеров ВМ вручную (это доступно для связанных клонов в пулах dedicated- или floating-)
• Политика питания Remote machine power policy (Always Powered On, Suspend, Power Off) для пула
• Привязка постоянных (Persistent) дисков

Несмотря на то, что персистентные диски не работают из коробки для связанных клонов, эту проблему можно решить с помощью продуктов Dynamic Environment Manger DEM , Microsoft FSLogix или VMware App Volumes Writable Volumes.

Отметим, что для мгновенных клонов (Instant clones) поддерживаются возможности TRIM и UNMAP для хранилищ vSAN.

Производительность клонов

У компании VMware есть прекрасный документ "Understanding Clones in VMware vSphere 7", где описываются результаты тестирования производительности всех трех типов клонов. Очень интересный whitepaper, давайте взглянем на некоторые выводы в нем содержащиеся.

Первое - это скорость развертывания клонов и тестирование производительности под большой нагрузкой ввода-вывода:

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

А вот правая часть картинки показывает нам, насколько падает производительность подсистемы ввода-вывода при тяжелых нагрузках - для связанных клонов больше, чем в три раза, а для мгновенных - аж в четыре (Hammer DB создает нагрузку еще и на память, которую должен обслуживать механизм мгновенных клонов).

Второй не менее интересный тест - с помощью методики SPECjbb. Тут брали не машины с хранилищем 450 ГБ и тяжелой нагрузкой по вводу-выводу, как в прошлом тесте, а легковесные машины с 16 ГБ диска и нагрузку делали на CPU и память. Результат получился таким:

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

Второй полезный инсайт - с точки зрения отработки запросов к CPU и памяти (а именно это и меряет SPECjbb) все три типа клонов ведут себя одинаково в пределах статистической погрешности в 5%.

Следующая картинка - влияние на родительскую ВМ. Очевидно, что для полных клонов влияния никакого нет, а вот для связанных и, тем более, мгновенных клонов влияние большое:

И, опять-таки, для памяти и CPU связанных и мгновенных клонов такого влияния практически нет.

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

При увеличении числа виртуальных машин совокупная производительность по вводу-выводу растет вот так:

При увеличении числа клонов картина для CPU/памяти вполне ожидаемая:

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

Что касается времени развертывания разного количества для трех типов клонов, тут тоже все понятно: полные клоны растут линейно, остальные - несущественно.

Итоги

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

Летом прошлого года компания VMware купила команду True Visibility у компании Blue Medora. На днях был анонсирован продукт на базе этого решения - vRealize True Visibility Suite. Этот анонс стал еще одним в серии весенних релизов компании VMware.

Новое решение True Visibility позволяет получить информацию обо всех компонентах виртуальной инфраструктуры, включая топологию сети, ресурсы хранилищ и серверов на физическом уровне, а также объектов приложений.

В течение ограниченного времени VMware предлагает купить новый бандл, который содержит vRealize True Visibility Suite, который дополняет обычный vRealize Suite Standard (либо отдельный продукт vRealize Operations Standard или Advanced) или vCloud Suite Standard:

В первую очередь, решение True Visibility позволит быстрее находить проблему, а также проводить root cause analysis и своевременно реагировать на события, происходящие в инфраструктуре на физическом и виртуальном уровне.

После того, как вы поставите все необходимые management packs и автоматически соберете данные о взаимосвязях и взаимодействиях в вашей инфраструктуре, вы увидите, как она выглядит на одной детализированной схеме, где видны виртуальные и физические компоненты:

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

Бандл доступен с 1 апреля по 30 октября, потом он будет интегрирован в одно из изданий по большей цене. Пробная бесплатная версия vRealize True Visibility Suite доступна по этой ссылке.

На днях компания VMware анонсировала еще одно обновление в своей продуктовой линейке - vRealize Operations v8.4 (vROPs) и vRealize Operations Cloud, которое дополняет сделанные ранее весенние анонсы. Напомним, что это средство предназначено для комплексного управления и мониторинга виртуальной инфраструктуры в различных аспектах. О прошлой версии vRealize Operations 8.3 мы писали не так давно вот тут.

Давайте посмотрим, что нового появилось в vROPs 8.4:

1. Улучшенная поддержка служб AWS

Поддержка служб Amazon позволяет пользователям строить функциональную инфраструктуру гибридного облака, соединяющую собственную и облачную инфраструктуры. Теперь поддержка включает в себя 57 сервисов, с которыми работает vRealize Operations 8.4.

2. Мониторинг сервисов и процессов

С помощью агентов Telegraf решение vROPs позволяет мониторить процессы на базе имени, регулярных выражений или PID в системах Linux и Windows. Если какой-то из сервисов упадет, то администратору придет оповещение, после чего можно будет узнать детали события.

3. Планировщик операций Reclamation и Rightsizing

С помощью нового планировщика пользователи могут задавать расписание для операций Reclamation и Rightsizing, таких как удаление старых снапшотов, выключение и удаление виртуальных машин, освобождение ресурсов ВМ, либо добавление ресурсов машинам, которые испытывают проблемы с заполнением диска или производительностью.

4. Расчет затрат на VMware Cloud on AWS

Эта функция позволяет посчитать стоимость содержания виртуальных машин и кластеров VMware Cloud on AWS на базе полученных счетов. Это включает в себя также и прогнозирование затрат от освобождения ресурсов виртуальных машин. Все это можно посмотреть на одном дэшборде.

5. Улучшенные функции Cost Flow Optimization

С помощью 10 новых дэшбордов пользователи могут увидеть детальную структуру затрат на содержание виртуальной инфраструктуры, а также визуализовать их. Там же показываются такие экономические показатели, как ROI (return on investment), TCO (total cost of ownership), ежемесячная экономия затрат и многое другое.

6. VMware Cloud on AWS What-if Planning

С помощью движка планирования "что если" пользователи могут предсказать запросы будущей инфраструктуры и увидеть инсайты о предлагаемых конфигурациях для VMware Cloud on AWS. Новые возможности дают функции по отслеживанию трендов утилизации инфраструктуры, выяснению времени, которое есть до необходимого ее расширения, и влияния удаления виртуальных машин на стоимость окружения в среде VMware Cloud on AWS.

7. Поддержка Open Source Telegraf Agent

Эта возможность расширяет пути, за счет которых пользователи могут мониторить свои приложения, вытягивая метрики с любого ПО, для которого есть плагины агентов Telegraf (также можно написать и свои собственные). Кстати, мониторинг доступен не только для систем VMware, но и для физических серверов.

Релиз обновленных решений vRealize Operations v8.4 и vRealize Operations Cloud ожидается во втором квартале этого года.

Как вы знаете, при обновлении виртуальной инфраструктуры в части хостов ESXi с помощью vSphere Lifecycle Manager (vLCM), в кластере HA/DRS хост переводится в режим обслуживания (Maintenance mode), который предполагает эвакуацию виртуальных машин на другие серверы с помощью vMotion. После обновления хоста он выводится из режима обслуживания, и виртуальные машины с помощью DRS постепенно возвращаются на него. В зависимости от характера нагрузки этот процесс может занять от нескольких минут до нескольких часов, что не всегда соответствует ожиданиям администраторов.

Второй вариант - потушить виртуальные машины, обновить ESXi, а потом включить его - тоже не подходит, так как приводит к длительным простоям сервисов виртуальных машин (нужно не только время на обновление хоста, но и время на выключение и включение ВМ, либо их небыстрый Suspend на диск).

Поэтому VMware придумала технологию Suspend-to-Memory, которая появилась в VMware vSphere 7 Update 2. Суть ее в том, что при обновлении ESXi его виртуальные машины приостанавливаются, сохраняя свое состояние (Suspend) в оперативной памяти. Очевидно, что в таком состоянии перезагружать хост нельзя, поэтому данная техника используется только совместно с ESXi Quick Boot, которая подразумевает обновление гипервизора без перезагрузки сервера.

Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по поддержке этой технологии со стороны серверных систем приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:

• Quick boot on Dell EMC
• Quick Boot on HPE
• Quick Boot on Cisco
• Quick Boot on Fujitsu
• Quick Boot on Lenovo

По умолчанию настройка кластера Cluster Remediation для виртуальных машин выставлена в значение "Do not change power state" для виртуальных машин, что подразумевает их vMotion на другие серверы, поэтому чтобы использовать Suspend to Memory, надо выставить "Suspend to memory", как на картинке выше.

При использовании такого типа обновления vLCM будет пытаться сделать Suspend виртуальных машин в память, а если этого не получится (например, недостаточно памяти), то он просто не будет переходить в режим обслуживания.

Надо сказать, что Suspend-to-Memory поддерживает vSAN и работает с такими продуктами, как vSphere Tanzu и NSX-T.

Ну и вот небольшое демо того, как это работает:

На сайте проекта VMware Labs появилась очередная интересная штука - интерфейс vRealize Automation Code Stream CLI. Он представляет собой CLI-обертку для vRealize Automation Code Stream API, написанную на языке Go.

С помощью данного интерфейса вы сможете автоматизировать операции для Code Stream и выполнять миграцию контента между экземплярами и проектами.

Основные возможности утилиты vRealize Automation Code Stream CLI:

• Импорт и экспорт артефактов Code Stream, таких как Pipelines, Variables, Endpoints
• Выполнение операций CRUD для этих же артефактов
• Инициирование исполнения Pipelines

Для начала работы вам понадобится vRealize Automation Cloud или vRealize Automation 8.x, API-токен (либо аккаунт с необходимыми правами к Code Stream), ну и клиентская машина на базе MacOS, Linux или Windows.

Примеры использования CLI-команд приведены вот тут. Скачать vRealize Automation Code Stream CLI можно по этой ссылке.

Недавно мы писали о новых возможностях решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Среди новых функций мы упоминали возможность Enhanced Data Durability, позволяющую еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.

Как знают администраторы vSAN, этот продукт обеспечивает высокую степень защиты данных от сбоев, в том числе встроенным механизмом избыточности, регулируемым политикой FTT (Failures to tolerate).

Однако при отказе одного или нескольких хостов ESXi в кластере vSAN может произойти ситуация, когда дисковый объект есть на одном из хостов, но только в одном экземпляре. Такая ситуация опасна тем, что если произойдет второй сбой, затрагивающий этот объект - данные могут быть безвозвратно утеряны.

Кстати, при переводе хоста в плановый режим обслуживания такая ситуация тоже может возникнуть - но в vSAN этот момент учитывался и раньше, и на время обслуживания все операции записи сохранялись до момента возвращения хоста в строй, после чего происходило накатывание операций, случившихся за это время:

Теперь же такой механизм появился и для внештатных ситуаций:

При сбое и недоступности хранилищ хост ESXi, который понял, что произошла авария, начинает записывать дельта-данные дискового объекта с этого момента не только на хранилище, где хранится активная реплика, но и в дополнительное хранилище (durability component), чтобы обеспечить надежность данных, записываемых во время сбоя.

По умолчанию в случае сбоя кластер vSAN ждет 60 минут до начала восстановления дискового объекта на другом хранилище хоста ESXi для обеспечения политики FTT. Это связано с тем, что кластер не начинает емкие по ресурсам операции для сбоев, которые могут оказаться временными. Регулируется это настройкой Object Repair Timer (она же настройка vsan.clomrepairdelay в Advanced Settings, подробнее об этом тут):

Если в этот момент случится еще одна авария, которая затронет единственно выжившую копию данных, то виртуальная машина остановится, но возможность восстановить данные будет - как только хост с последней копией данных восстановится, на них накатятся сохраненные инкрементальные операции записи. Это позволит получить состояние виртуальной машины без потери всех последних операций записи.

Надо сказать, что операции по созданию durability component имеют приоритет над стандартными операциями vSAN, такими как синхронизация дисковых объектов, поэтому это происходит очень быстро, чтобы сразу начать записывать дельта-writes. Операции записи в durability component будут продолжаться (он будет в состоянии active), пока синхронизация дискового объекта с его репликой не завершится удачно (либо на восстановившемся хосте, либо на новом, после операции rebuild). После этого durability component для дискового объекта будет удален.

Еще стоит отметить, что если хост с durability component откажет, то новый хост возьмет на себя его функции и создаст свой durability component (число таких операций не ограничено). Также полезно то, что защита данных с помощью durability component работает и для дисковых объектов с FTT=2 или выше - главное, чтобы у вас было для всех этих операций свободное дисковое пространство в кластере.

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

Вот анонс вебинаров от сотрудника VMware Михаила Михеева:

Портфель компании давно выходит за рамки виртуализации и включает решения в области:

• модернизации, мониторинга и запуска приложений;
• миграции в облако;
• сетей и безопасности.

Каждый вторник и четверг с 16 марта по 1 июня на вебинарах VMware будет рассказывать:

• Как поменялась архитектура сетевых функций после прихода программной определяемости
• Какие непривычные возможности получают привычные инструменты ИБ, когда они работают на уровне платформы
• Какие новые технологии в области виртуализации и информационной безопасности нас ждут
• Какие инструменты есть у VMware для управления частными и гибридными облаками
• Почему важно следить за использованием ресурсов и при чем здесь инструменты Инфраструктуры-как-код

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

Зарегистрироваться на бесплатные вебинары VMware можно по этой ссылке: https://via.vmw.com/ERG1.

На днях VMware сделала много больших анонсов о скором выпуске решений семейства vRealize. Вчера мы рассказали о новых возможностях решений для поиска и анализа данных в виртуальной инфраструктуре VMware vRealize Log Insight 8.4 и Log Insight Cloud, а сегодня немного посмотрим на новые функции VMware vRealize Network Insight 6.2 (vRNI) и vRNI Cloud - решений, предназначенных для для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре.

Напомним, что о прошлой версии vRNI 6.1 мы писали вот тут. Давайте посмотрим, что нового появилось в vRNI 6.2:

1. Улучшения техник машинного обучения для обнаружения приложений и анализа

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

После того, как все приложения обнаружены, vRealize Network Insight может быть использован для миграции в публичное облако, VMware Cloud или для переноса больших объемов данных в другие датацентры с помощью VMware HCX.

С помощью алгоритмов машинного обучения vRNI 6.2 предоставляет функции Flow Based Application Discovery для всех онпремизных инсталляций (ранее это было доступно только как SaaS-сервис). Это даст возможность быстрее и качественнее планировать миграции.

2. Assurance and Verification

В этом релизе были сделаны улучшения юзабилити и масштабируемости для функций business intent validation.

3. Поддержка VMware NSX-T

В обновлении улучшены метрики, трешхолды, а также возможности фильтрации поисковых запросов для BGP и Equal-cost multi-path (ECMP).

4. Улучшения VMware SD-WAN

Здесь была улучшена детализация для application heat maps, которая поможет быстрее решать проблемы.

5. Поддержка VMware Cloud

Теперь появилась возможность видеть детали сетей Google Cloud VMware Engine и Azure VMware Solution, чтобы пользователи могли соотносить производительность приложений в окружениях, где используется несколько облачных инфраструктур.

6. Улучшения VMware Cloud on AWS

Возможность анализа vRNI для AWS включает в себя группы SDDC Groups и потоки трафика AWS Transit Connect, что поможет считать затраты и анализировать их, а также лучше измерять и оптимизировать производительность.

• Метрики производительности сети

Здесь поддерживаются потоки intra-SDDC Group flows, что позволяет найти виртуальные машины и приложения внутри них. Новые детализированные метрики доступны для AWS edge router и VMware HCX Network Extension (L2C) для измерения пропускной способности и числа пакетов в секунду.

• Функции Transit Connect

Дэшборды теперь включают в себя информацию о VMware Cloud on AWS Transit Connect - метрики, потоки и события для более детального анализа и решения проблем. Также есть поддержка анализа сетевых потоков L3 MPLS VPN и VRF Route Leaking для VMware Cloud on AWS Direct Connect Colo Routers.

• Алерты и трешхолды

Для VMware Cloud on AWS, когда метрики и пороговые значения превышают пороговые значения для реальных конфигураций, vRNI выставит алерты на различные максимальные трешхолды для метрик в плане конфигураций сети и конфигураций безопасности.

Доступность новых версий VMware vRealize Network Insight 6.2 (vRNI) и vRNI Cloud ожидается в ближайшие пару месяцев.

Продолжается весенняя серия релизов продуктов VMware (напомним, что главные из них - vSphere 7 Update 2 и vSAN 7 Update 2). На этот раз мы расскажем об анонсированном обновлении решений VMware vRealize Log Insight 8.4 и Log Insight Cloud, предназначенных для поиска любых данных в виртуальной инфраструктуре, анализа лог-файлов и визуализации аналитики. Напомним, что о прошлой версии Log Insight 8.3 мы писали в начале года вот тут.

Давайте теперь посмотрим, что нового появилось в VMware vRealize Log Insight 8.4 и Log Insight Cloud:

1. Функция Log Partitions

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

2. Функция Log Exploration 

Это возможность задать один или несколько разделов для операций таргетированного поиска.

3. Функция Re-Hydrate Logs

Она позволяет вернуть логи из архива для выполнения функций Log Exploration, описанных выше. Нужно выбрать соответствующий раздел и временной интервал, после чего архивные данные будут переиндексированы.

4. Захват логов Live Tail

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

5. Knowledge Base (KB) Correlation

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

6. Enhanced Multi-Cloud observability 

Эта возможность позволяет смотреть логи в публичных инфраструктурах, таких как AWS, Microsoft Azure и Google Cloud Platform (в дополнение к имеющейся информации по 50+ AWS-сервисам).

7. Geo-expansion 

Log Insight Cloud стал доступен в датацентрах в Канаде (central), US West (Oregon), Asia Pacific (Sydney) и Europe (Frankfurt).

Пока VMware vRealize Log Insight 8.4 и обновленный Log Insight Cloud недоступны для загрузки и использования, но уже в самом ближайшем будущем VMware планирует выпустить эти решения.

На днях мы писали о новых возможностях решения для создания отказоустойчивых хранилищ VMware vSAN 7.0 Update 2. Дункан Эппинг обратил внимание на один из вспомогательных сервисов - VMware Skyline Health, в котором появилось очень полезное нововведение - Health History.

Теперь в сервисе Skyline Health (ранее он назывался Health Check) появилась опция по визуализации пройденных / не пройденных проверок для различных объектов в исторической ретроспективе, которая позволит вам соотнести непройденные проверки с происходившими странностями, ошибками или отказами компонентов инфраструктуры:

Вы можете вернуться до 30 дней назад во времени, указав промежуток, в котором вы хотите посмотреть детали непройденных или успешных проверок. Опцию сохранения этих данных можно отключить на вкладке Configuration.

При клике на красный квадрат, вы можете увидеть какие именно проверки не были пройдены, а также для скольки объектов они прошли успешно, а для скольки нет:

Ну и посмотрите небольшое видео от Дункана, где он показывает, как это работает в его тестовой лаборатории:

На прошлой неделе компания VMware выпустила обновления своих главных продуктов - vSphere 7 Update 2 и vSAN 7 Update 2. Одной из важных составляющих инфраструктуры vSphere является технология репликации, которая служит основой для защиты активного датацентра и позволяет создать горячие копии виртуальных машин на резервной площадке в рамках решения VMware Site Recovery Manager. Напомним, что о возможностях репликации и SRM 8.3 мы писали около года назад вот тут.

Давайте посмотрим на новые возможности недавнего обновления VMware SRM 8.4 и vSphere Replication 8.4:

1. Оптимизация процедуры Re-Protect

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

Вот так это выглядит с точки зрения экономии времени на восстановление изначальной конфигурации площадок:

2. Улучшения масштабируемости и производительности

Раньше технология vSphere Replication поддерживала репликацию до 2000 виртуальных машин на один сервер vCenter, теперь же это число было увеличено до 3000. На один модуль Replication Appliance теперь может приходиться до 300 ВМ вместо 200 ранее. Кроме того, инженеры VMware также поработали и над улучшением производительности процесса репликации.

3. Отчетность

Ранее отчеты можно было выгружать в файл XML, теперь же была добавлена еще и возможность копировать их в любой Datagrid через UI. Также появилась опция "Export Global Report" в формат CSV, которая позволяет экспортировать все настройки и конфигурации инфраструктуры катастрофоустойчивости для отчетности и анализа. Там будут все Recovery Plans и Protection groups с их подробными конфигурациями.

4. Улучшения интерфейса

Тут появилось множество всего нового, например, раздел Missing network mappings, очень полезный для администраторов SRM.

На скриншоте видно, что при настройке репликации недостающие маппинги показываются в интерфейсе, где есть возможность их добавить в Protection groups на этапе одного из шагов мастера.

После создания плана аварийного восстановления вам покажут список задач с ошибками, обнаруженными для полученных конфигураций. Это доступно на Summary Page, без необходимости открывать recovery plan report.

В истории задач видны все ошибки, сгруппированные по задачам:

На любом экране с деревом инфраструктуры теперь есть информация о состоянии каждого из объектов (Disconnected, Maintenance Mode и т.п.):

Для маппинга папок теперь есть подсказка об их иерархии:

После фейловера или плановой миграции на другую площадку наступает необходимость восстановить функционирование основного сайта и вернуться к изначальной конфигурации. О процедуре Reprotect теперь напоминает специальный попап:

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

Ну и появилась возможность read-only просмотра мастера recovery settings для ВМ, когда планы восстановления находятся в нередактируемом состоянии.

5. Улучшения vSphere Replication Appliance Management

Интерфейс модуля VRMS был приведен к тем же стандартам, что и консоли Site Recovery Manager и vCenter. Теперь нужные задачи и настройки находить легче:

6. Улучшения простоты использования

Теперь Site Recovery Manager автоматически выбирает placeholder datastores на обеих площадках с учетом характеристик этих датасторов. Эту механику можно отключить в настройках:

Также теперь при настройке репликации автоматически определяются редко используемые ISO, подключенные как CD/DVD и исключаются из репликации:

7. Улучшенная поддержка соединения площадок

Теперь конфигурация SRM поддерживает разницу в версиях (N+1), что очень удобно в целях апгрейда версии ПО на обеих площадках:

Тут есть 3 основных момента:

• Пара будет функционировать на условиях младшей версии
• SRM и vSphere Replication должны быть одной версии в рамках одной площадки
• Эта функциональность идет отдельно от совместимости разных версий vCenter

8. Улучшения автоматизации

Через SRM API теперь доступны следующие возможности:

• Просмотр числа и типов лицензий
• Создание пустых protection groups
• Создание/редактирование папок и перемещение recovery plans и protection groups
• Настройка array managers
• Управление реплицируемыми парами дисковых массивов
• Ручной маппинг/защита ВМ
• Функции Add/Remove/Get для Placeholder Datastores
• Добавление зависимостей ВМ

Для плагина vRealize Orchestrator plug-in for SRM было добавлено:

• Добавление Inventory Mappings на уровне ВМ
• Настройка Placeholder Datastore
• Новый рабочий процесс создания папок Protection Group и Recovery Plan, а также их перемещение из одной папки в другую

9. Улучшения vRealize Operations Management Packs

Management Pack теперь поддерживает vRealize Operations Manager 8.3. В отчетах теперь можно найти новую информацию о:

• Лицензиях
• Объектах Array Manager
• Ошибках, алертах и алармах
• Recovery History
• MPIT visibility для vSphere Replication

Более подробная информация о релизах VMware Site Recovery Manager 8.4 и vSphere Replication 8.4 приведена тут и тут, соответственно. Скачать SRM 8.4 можно по этой ссылке.

Это гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду по модели IaaS. 2020 год прошел под флагом цифровизации. Компании массово переходили в онлайн, в максимально сжатые сроки трансформируя устоявшиеся бизнес-процессы. Чтобы с минимальными потерями пережить локдаун, огромные корпорации и небольшие предприятия вводили удаленный формат работы и коренным образом меняли привычные способы коммуникации сотрудников с клиентами, партнерами и между собой. Читать статью далее->>

Недавно мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а также новой версии средства создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Сегодня мы немного подробнее расскажем о новых возможностях инфраструктуры работы с хранилищами (core storage) в новом обновлении vSphere.

Давайте посмотрим, что именно там нового:

1. Увеличение iSCSI Path Limit

Раньше для одного LUN максимально доступны были только 8 путей, но многим пользователям требовалось существенно больше. Используя несколько портов VMKernel или точек назначения, пользователям иногда было нужно 16 или даже 24 пути. Теперь максимум составляет 32 пути на LUN, что должно хватить всем.

2. Поддержка RDM для RHEL HA

Теперь для для работы Red Hat Enterprise HA можно использовать тома RDM на платформе vSphere. В корневых механизмах работы с хранилищами для этого были сделаны некоторые изменения.

3. Улучшения снапшотов VMFS SESparse

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

4. Поддержка нескольких адаптеров Paravirtual RDMA (PVRDMA)

В vSphere 6.7 была анонсирована поддержка RDMA. Одним из ограничений было то, что для одной виртуальной машины можно было использовать только один адаптер PVRDMA. Теперь этой проблемы больше нет.

5. Улучшения производительности для томов VMFS

Здесь были сделаны улучшения первых операций чтения для тонких дисков. Они особенно проявляются при резервном копировании и восстановлении, операциях копирования данных и Storage vMotion.

6. Улучшения работы с NFS-хранилищами

Теперь не обязательно создавать клон ВМ для использования offload'а операций по созданию снапшотов уровня дискового массива. Теперь можно использовать любые виртуальные машины на базе снапшотов без необходимости создавать redo logs.

7. Поддержка High Performance Plugin FastPath для Fabric Devices

Плагин HPP теперь используется по умолчанию для устройств NVMe. В плагине есть 2 опции - SlowPath для legacy-поведения и новый FastPath для большей производительности, но с некоторыми ограничениями. Подробнее рассказано вот в этой статье.

8. HPP - дефолтный плагин для vSAN

Начиная с vSphere 7 Update 2, HPP теперь дефолтный MPP для всех устройств - SAS/SATA/NVMe (и Fabric Devices, как было сказано выше).

9. Улучшения VOMA

Средство vSphere On-disk Metadata Analyzer (VOMA) используется для нахождения и исправления повреждений метаданных томов, которые влияют на файловую систему и логические тома. Теперь это доступно и для spanned VMFS-томов. Более подробно об этом можно узнать тут.

10. Поддержка бОльших значений Queue Depth для vVols Protocol Endpoints

В некоторых случаях параметр Disk.SchedNumReqOutstanding (DSNRO) не соответствует глубине очереди на vVols Protocol Endpoint (PE) (он же VVolPESNRO). Теперь глубина очереди для PE равна 256 или берется максимальная глубина видимого LUN. Поэтому минимум PE QD выставлен в 256.

11. Создание Config vVol больше, чем на 4 ГБ

Теперь это позволяет партнерам VMware хранить образы для автоматических билдов на томах VVols.

12. Улучшения правил SPBM Multiple Snapshot

Движок Storage Policy Based Management позволяет администратору управлять фичами хранилищ VVols на уровне отдельных виртуальных машин. Теперь в рамках одной политики SPBM можно использовать несколько правил для снапшотов (например, интервалы их создания). Эта фича должна поддерживаться на уровне VASA у соответствующего производителя массива.

13. Поддержка снапшотов для Cloud Native Storage (CNS) на базе First Class Disks

Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. Для них теперь есть поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.

14. Маппинг CNS PV на vVol

В некоторых случаях пользователи хотят видеть, какие тома VVols ассоциированы с томами CNS Persistent Volume (PV). Теперь этот маппинг можно увидеть в интерфейсе CNS.

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

Нововведения сосредоточены в следующих областях:

Давайте посмотрим, что именно нового в vSAN 7 U2:

Улучшения масштабируемости

• HCI Mesh Compute Clusters

Теперь в дополнение к анонсированной в vSphere 7 Update 1 топологии HCI Mesh для удаленного доступа к хранилищам vSAN появилась технология HCI Mesh Compute Clusters, которая позволяет иметь вычислительный кластер vSphere/vSAN без собственных хранилищ, использующий хранилища удаленных кластеров.

Самое интересное, что эти кластеры не нуждаются в лицензиях vSAN, вы можете использовать обычные лицензии vSphere.

Также такие кластеры vSAN могут использовать политики хранилищ, в рамках которых можно получить такие сервисы, как дедупликацию / компрессию или шифрование Data-at-rest:

Также было увеличено число хостов ESXi, которые могут соединяться с удаленным датастором, до 128.

Небольшое видео о том, как создать HCI Mesh Compute Cluster:

• Улучшение файловых служб

Службы vSAN file services теперь поддерживают растянутые (stretched) кластеры и двухузловые конфигурации, что позволяет использовать их для ROBO-сценариев.

• Улучшения растянутых кластеров

Растянутые кластеры vSAN теперь обрабатывают не только различные сценарии сбоев, но и условия восстановления, которые были определены механизмом DRS до наступления события отказа. DRS будет сохранять ВМ на той же площадке до того, как данные через inter-site link (ISL) будут полностью синхронизированы после восстановления кластера, после чего начнет перемещать виртуальные машины в соответствии со своими правилами. Это повышает надежность и позволяет не загружать ISL-соединение, пока оно полностью не восстановилось.

• Технология vSAN over RDMA

В vSAN 7 Update 2 появилась поддержка технологии RDMA over Converged Ethernet version 2 (RCoEv2). Кластеры автоматически обнаруживают поддержку RDMA, при этом оборудование должно находиться в списке совместимости VMware Hardware Compatibility Guide.

• Улучшения производительности

В vSAN 7 U2 была оптимизирована работа с RAID 5/6 в плане использования CPU. Также была улучшена производительность яруса буффера. Это позволяет снизить CPU cost per I/O.

Кроме того, были сделаны оптимизации для процессоров AMD EPYC (см. тут).

Улучшения для задач AI and Developer Ready

Здесь появилось 2 основных улучшения:

• S3-совместимое объектное хранилище для задач AI/ML и приложений Cloud Native Apps.

На платформе vSAN Data Persistence platform теперь поддерживаются компоненты Cloudian HyperStore и MinIO Object Storage. Пользователи могут потреблять S3-ресурсы для своих AI/ML нагрузок без необходимости долгой настройки интеграций.

• Улучшения Cloud Native Storage в vSphere и vSAN
  

Теперь Cloud Native Storage лучше поддерживает stateful apps на платформе Kubernetes. Также vSAN предоставляет простые средства для миграции с устаревшего vSphere Cloud Provider (vCP) на Container Storage Interface (CSI). Это позволит иметь персистентные тома Kubernetes на платформе vSphere и расширять их по мере необходимости без прерывания обслуживания.

Улучшения безопасности

• Службы vSphere Native Key Provider Services

Это механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки. Также для двухузловых конфигураций и Edge-топологий можно использовать встроенный KMS-сервис, который работает с поддержкой ESXi Key Persistence.

• Средства для изолированных окружений

VMware предоставляет Skyline Health Diagnostics tool, который позволяет самостоятельно определить состояние своего окружения в условиях изоляции от интернета. Он сканирует критические компоненты на проблемы и выдает рекомендации по их устранению со ссылками на статьи базы знаний VMware KB.

• Улучшения Data In Transit (DIT) Encryption

Здесь появилась валидация FIPS 140-2 криптографического модуля для DIT-шифрования.

Упрощение операций

• Улучшения vLCM

Для vSphere Lifecycle Manager появились следующие улучшения:

• vLCM поддерживает системы Hitachi Vantara UCP-HC и Hitachi Advanced Servers, а также серверы Dell 14G, HPE10G и Lenovo ThinkAgile.
• vLCM теперь поддерживает кластеры, которые используют vSphere with Tanzu с технологией NSX-T networking.
• При создании кластера можно указать образ существующего хоста ESXi.

• Улучшения защиты данных

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

• Поддержка Proactive HA

vSAN 7 Update 2 теперь поддерживает технологию Proactive HA, которая позволяет проактивно смигрировать данные машин на другой хост ESXi.

• Улучшения мониторинга

Здесь появились новые метрики и хэлсчеки, которые дают больше видимости в инфраструктуре коммутаторов, к которой подключены хосты vSAN. На физическом уровне появились дополнительные метрики, такие как CRC, carrier errors, transmit и receive errors, pauses. Также для новых метрик были добавлены health alarms, которые предупредят администратора о приближении к пороговым значениям.

• Улучшения vSphere Quick Boot

Здесь появилась техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.

Скачать VMware vSAN 7 Update 2 в составе vSphere 7 Update 2 можно по этой ссылке. Release Notes доступны тут.

Бонус-видео обзора новых фичей от Дункана Эппинга:

Компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Напомним, что прошлый релиз vSphere 7 Update 1 был выпущен в начале сентября прошлого года, так что времени прошло уже немало.

Нововведения второго пакета обновлений сконцентрированы в трех основных областях:

Давайте посмотрим на новые возможности vSphere 7 Update 2 более детально:

1. Инфраструктура AI и Developer Ready

На основе технологий, анонсированных в 2020 году, компании VMware и NVIDIA сделали совместный анонс платформы AI-Ready Enterprise Platform.

NVIDIA объединилась с VMware для виртуализации рабочих AI-нагрузок в VMware vSphere с помощью NVIDIA AI Enterprise. Это позволяет предприятиям разрабатывать широкий спектр решений для работы с искусственным интеллектом, таких, как расширенная диагностика в здравоохранении, умные предприятия для производства и обнаружение мошенничества в финансовых услугах.

NVIDIA предоставляет пользователям уникальный набор утилит и фреймворков для решения AI-задач на платформе VMware vSphere.

Решение AI Enterprise:

• Поддерживает последние поколения GPU от NVIDIA в целях достижения максимальной производительности (до 20 раз лучше, чем в прошлом поколении).
• Поддерживает NVIDIA GPUDirect RDMA for vGPUs.
• Поддерживает разделение NVIDIA multi-instance GPU (MIG), что позволяет обеспечивать горячую миграцию виртуальных машин c vGPU на борту c помощью vMotion.
• Посредством Distributed Resource Scheduler (DRS) обеспечивает автоматическую балансировку машин AI-инфраструктуры по хост-серверам.

Также появились и новые возможности в плане поддержки инфраструктуры контейнеров vSphere with Tanzu:

• Интегрированная балансировка нагрузки на приложения посредством VMware NSX Advanced Load Balancer Essentials edition с поддержкой HA с использованием автоматизаций Kubernetes-native (подробнее об этом тут).
• Сервисный кластер Tanzu Kubernetes Grid и Supervisor-кластер можно обновить до Kubernetes 1.19.
• Улучшенная поддержка сторонних репозиториев, что повышает гибкость и безопасность.

2. Инфраструктурные улучшения и безопасность данных

В этой категории появились следующие новые возможности:

• Новый vSphere Native Key Provider - механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки.

• Поддержка Confidential Containers для vSphere Pods, которые используют память AMD SEV-ES и CPU data encryption на платформах AMD EPYC.
• Механизм ESXi Configuration Encryption, который использует оборудование Trusted Platform Module (TPM) для защиты ключей ESXi на хостах.
• Техника ESXi Key Persistence, которая дает возможности для защиты данных data-at-rest на изолированных хостах.
• Обновленный документ vSphere Security Configuration Guide.
• Обновленные рекомендации vSphere Product Audit Guides, а также FIPS validation для сервисов vCenter Server.

3. Упрощение операций

• Техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.
• Оптимизации процессоров AMD EPYC CPU, что приводит к улучшению производительности.
• Поддержка рабочих нагрузок Persistent Memory (PMEM) со стороны  vSphere HA. Это позволяет техникам DRS initial placement и High Availability полноценно работать в кластере.
• Новый функционал решения vSphere Lifecycle Manager with Desired Image Seeding, который позволяет автоматизировать обновление микрокода к желаемому состоянию:
  • Все фичи vSphere Lifecycle Manager теперь доступны для окружений vSphere with Tanzu.
  • Функция Desired image seeding позволяет реплицировать информацию о желаемой конфигурации с референсного хоста, экономя время администратора на настройку.
• Функция vMotion Auto Scaling, которая позволяет автоматически подстраивать производительность в сетях 25, 40 и 100 Гбит.
• Уменьшенное I/O latency и jitter для проброшенных напрямую (passthrough) сетевых адаптеров.
• Улучшенная поддержка Virtual Trusted Platform Module (vTPM) для гостевых ОС Windows и популярных дистрибутивов Linux.
• Улучшения VMware Tools, включая Guest Store - метод для распространения конфигураций и файлов между виртуальными машинами, а также драйверы Precision Clock drivers для службы Windows Time Service.
• Улучшенные vCenter Server REST API, что расширяет возможности по автоматизации операций vCenter.

Ссылки, которые могут оказаться полезными:

• Youtube-канал с новыми фичами vSphere 7 Update 2
• Технические статьи о некоторых новых возможностях
• Документация по vSphere
• Основной сайт VMware vSphere
• Release notes для ESXi 7 Update 2, а также для vCenter 7 Update 2

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

Недавно компания Veeam Software, производитель лучших решений для обеспечения доступности виртуального датацентра, выпустила обновление платформы Veeam Cloud Data Management Platform, в состав которой входит самое известное решение для защиты виртуальных сред - Veeam Backup and Replication v11. Мы уже писали об RTM-релизе этого продукта, где вкратце рассказывали его новых возможностях, а сегодня разберем их подробнее.

Итак, собственно основные новые возможности Veeam Backup and Replication v11 (наш топ-15):

1. CDP : Continuous Data Protection

Эта технология позволяет настроить непрерывную защиту виртуальных машин средствами репликации таким образом, чтобы соблюдать заданные политики RPO (Recovery Point Objectives). Достигается это за счет использования технологии VMware VAIO (vSphere API for I/O filtering).

Для этого на хосты ESXi ставится специальный VIB-пакет (фильтр VAIO), который в режиме драйвера привязывается к нужным ВМ.

При создании CDP-политики вы задаете время в секундах, за которое вы можете себе позволить потерять данные в случае сбоя (RPO):

Short-term реплики будут crash-консистентными, а long-term можно уже настроить как Application-aware, чтобы быть уверенным в работоспособности приложений виртуальной машины в конкретной точке в прошлом.

2. Функции асинхронного процессинга

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

3. Возможность Backup Copy Retention

Политика хранения задач Backup copy job теперь имеет такую же логику, как и primary backup job - то есть GFS (Grandfather-Father-Son).

4. Улучшенная работа с тэгами vSphere

Теперь вы можете использовать оператор AND для добавления условия по комбинациям тегов при поиске и создании задач.

Теперь представление с избранными фильтрами есть в управляющем дереве наравне с самими фильтрами.

6. Защищенный Linux-репозиторий

Возможность создания на Linux-репозиториях бэкапов, которые нельзя удалить (immutability), в целях защиты от вредоносных действий, который может предпринять злоумышленник, заметая следы (также это очень полезно в борьбе с Ransomware, когда может возникнуть ситуация, что вас нет рабочих систем, а бэкапы удалены). Кроме того, это может защитить от намеренной порчи данных изнутри организации.

Подробнее об этой штуке мы писали вот тут.

7. Функция Instant MSSQL Recovery

Очень подробно об этой возможности на русском языке рассказано тут. Эта технология, по аналогии с Instant VM Recovery, позволяет быстро восстановить поврежденную или удаленную базу данных MS SQL из резервной копии. Для этого надо зайти в Restoring Application Items -> Microsoft SQL Server. Далее в Veeam Explorer для нужной базы нужно выбрать опцию Instant Recovery.

Работает сама технология по такой схеме:

Теперь вам не нужно развертывать эти виртуальные модули, чтобы иметь возможность быстро восстанавливать файлы на Linux. Бэкап можно примонтировать к любой Linux-машине напрямую. Теперь восстановление будет работать быстрее, так как не нужно тратить время на развертывание helper appliance.

Отдельные файлы можно восстанавливать также и в системах IBM AIX, MAC и Oracle Solaris.

9. Улучшенные режимы Linux Backup Proxy

Теперь можно использовать не только методику hot-add, как было в 10-й версии, но и другие режимы (Network Mode, Direct SAN с NFS, iSCSI и FC, а также бэкап из снапшотов хранилищ).

• Технология CDP Low second RPO replication, которая позволяет улучшить показатели репликации за счет использования интерфейса vSphere APIs for IO (VAIO).
• VCD to VCD Replication – функция для провайдеров VCSP, которая позволяет реплицировать данные между организациями VMware Cloud Director для одного или разных инстансов VCD.
• VCD Native HTML5 Plugin - vCloud Director Self Service Portal интегрирован напрямую в VCD.
• Улучшенная поддержка объектных хранилищ, в частности появилась поддержка Google Storage.

Новая версия консоли Veeam Service Provider Console v5 даст сервис-провайдерам следующие возможности: 

• Готовая к производственной эксплуатации третья версия API
• Новые возможности контроля над агентами для Windows, Linux и Mac
• Возможность управлять бэкапами на AWS и Azure через обновленные нативные плагины
• Улучшенные функции безопасности и новые интеграции

12. Модуль PowerShell для Veeam Backup and Replication

Теперь есть интегрированный модуль PowerShell 6.0, который устанавливается по умолчанию. Он позволяет управлять инфраструктурой резервного копирования на базе решений Veeam с помощью сценариев. Также в одиннадцатой версии Veeam B&R появилось 184 новых командлета.

13. Новый Rest API для Veeam Backup and Replication

Теперь Rest API есть не только в Veeam Backup Enterprise Manager, но и непосредственно на бэкап-серверах, что существенно увеличивает гибкость выполнения задач и построения новых интеграций через API.

14. Поддержка Amazon S3 Glacier и Microsoft Azure Archive Storage

Теперь администраторы могут использовать сервисы хранилища Amazon S3 Glacier (включая Glacier Deep Archive) и Microsoft Azure Archive Storage для обеспечения полного цикла облачного хранения резервных копий.

15. Расширение поддержки объектных хранилищ

Теперь можно использовать Google Cloud Storage (GCS) как объектное хранилище за счет нативной интеграции GCS через собственный API Veeam.

Backup & Replication v11 содержит новые версии Veeam ONE v11 (11.0.0.1379), а также апдейт Agent for Windows (5.0.0.4300) и Linux (5.0.0.4318), плюс совершенно новые Mac Agent (1.0.0.713) и Veeam Service Provider Console (5.0.0.6726). Про агенты можно подробно прочитать на русском языке вот тут.

Полный список новых возможностей приведен в документе Veeam v11 What's New (всего их более 200), в котором они занимают аж 21 страницу. Скачать новую версию этого продукта можно по этой ссылке.

У компании VMware есть полезная бесплатная электронная книга PowerCLI Cookbook for VMware vSAN, посвященная управлению инфраструктурой отказоустойчивых хранилищ с помощью сценариев, которая будет полезна всем администраторам хранилищ виртуальных сред vSphere / vSAN.

В книге на 127 страницах подробно рассказывается о командлетах для управления всеми аспектами хранилищ с помощью PowerCLI. В документе 3 основных блока:

• Configuration Recipes - разбор примеров использования сценариев для настройки самого окружения vSAN, а именно:
  • Настройка vSAN в новом или существующем кластере
  • Добавление хостов
  • Настройка сетевого окружения
  • Выделение дисков под хранилища
  • Настройка HA и DRS
  • Настройка дедупликации и компрессии
  • Настройка шифрования
  • Конфигурация vSAN Performance Service
• Operational Recipes - это практические примеры сценариев для ежедневного использования и подробный разбор их параметров, а также описание процедур, которые нужно регулярно выполнять в кластере.
• Reporting Recipes - это набор рецептов для вывода информации о конфигурациях, метриках и состояниях, а также представления данных в удобном виде.

Скачивайте PowerCLI Cookbook for VMware vSAN - штука полезная.

Осенью прошлого года мы писали о выходе бета-версии операционной системы VMware Photon OS 4.0 Beta, использующейся в виртуальных модулях VMware (Virtual Appliances), которые реализуют различные вспомогательные сервисы. 

На днях вышла финальная версия Photon OS 4.0, давайте посмотрим, что там появилось нового:

Главные улучшения

• Ядро реального времени для приложений телекома и vRAN (Virtual Radio Network)

  Наступает эра 5G, и VMware сделала в Photon OS 4.0 возможности поддержки телеком-приложений реального времени на уровне ядра (Photon Real Time kernel). Это позволит технологиям vRAN (Virtual Radio Network) использовать возможности ОС Photon при развитии инфраструктуры 5G-операторов. Для этого появился специальный kernel flavor, который называется "linux-rt". Вместе с остальными компонентами (userspace-пакетами) этот режим называется Photon Real Time (RT).

• Безопасность
  
  Photon 4.0 получила поддержку таких технологий по обеспечению безопасности, как SELinux, Security Encrypted Virtualization – Encrypted Status и Intel Software Guard Extensions. Обязательная система контроля доступа, прошитая на уровне ядра, позволяет SELinux дать администраторам гранулярный и гибкий доступ к ресурсам. Также Photon OS позволяет из коробки, на уровне политик, обеспечить нужды приложений в изоляции. Также поддерживается SELinux для контейнеров, что было протестировано для docker, containerd и runc.
  
  Поддержка драйверов Intel SGX drivers позволяет приложениям использовать ресурсы CPU для создания "анклавов" - полностью защищенных модулей исполнения, недоступных на аппаратном уровне другим процессам.
  

• Обновленный механизм сетевой конфигурации
  
  Теперь Photon 4.0 имеет полностью переработанную библиотеку network configuration management library вместо netmgr, которая предоставляет API для большинства задач конфигурации (IP-адреса, маршруты, DNS и прочее). То есть вместо файлов конфигурации можно использовать API.

• Оптимизации производительности для решения vSphere with Tanzu
  
  Исторически Photon ОС имела специальный контекст ядра linux-esx, который был специальным образом оптимизирован для работе на платформе VMware ESXi точки зрения производительности и предоставляемых возможностей. В Photon 4.0 то же самое появилось и для контейнерной среды исполнения vSphere with Tanzu, например, уменьшение времени запуска для контейнеров и приложений.

• Прочие улучшения
  
  - Поддержка Raspberry Pi 4
  - Для ARM-архитектуры доступны образы в формате OVA и AMI
  - В tdnf добавлена поддержка расширенной конфигурации сервисов безопасности
  - Ядро обновлено до версии 5.10 (декабрь 2020)

Установщик и обновления

• Поддержка распределенных билдов с использованием Kubernetes
• Доступность установщика Photon OS в виде RPM-пакета
• Поддержка нескольких дисков в image builder
• Поддержка самоподписанных SSL-сертификатов в kickstart-установке из ISO-образа
• Для RPM используется механизм zstd по умолчанию

Состав пакета

• Готовые образы для облачного развертывания в Microsoft Azure (новое), Google Compute Engine (GCE), Amazon Elastic Compute Cloud (EC2) и продуктах VMware (vSphere, Fusion и Workstation)
• Критические обновления следующих пакетов:
• Linux kernel 5.10 LTS
• Glibc 2.32
• systemd 247
• Python3 3.9
• Openjdk : 1.8.0.265, 11.0.9
• Openssl : 1.1.1
• Cloud-init: 20.4.1
• GCC: 10.2.0
• Обновленные версии основных пакетов, доступные в репозиториях

Скачать VMware Photon OS 4.0 в виде OVA-пакета или ISO-образа можно по этой ссылке.

Продолжаем рассказывать о лучшем в отрасли решении для создания программных хранилищ под виртуальные машины на базе хост-серверов ESXi - StarWind Virtual SAN for vSphere. Как многие знают, с какого-то момента StarWind стала поставлять свое решение для платформ VMware в виде виртуального модуля (Virtual Appliance) на базе Linux, который реализует основные сервисы хранения, дедупликации и компрессии, а также отказоустойчивости и обеспечения надежности данных в виртуальных машинах.

Для виртуального модуля StarWind работа механизма дедупликации и компрессии обеспечивается средствами Linux-движка Virtual Data Optimizer (VDO), который появился относительно недавно. Это удобный и надежный способ экономии дискового пространства за счет использования дополнительных емкостей оперативной памяти на хосте.

Для начала вам нужно определиться с оборудованием хостов ESXi, где вы будете развертывать виртуальные модули StarWind. Как вы понимаете, в целях обеспечения отказоустойчивости таких узлов должно быть как минимум два.

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

Что касается дополнительной оперативной памяти на хосте ESXi, то нужно выбирать ее объем, исходя из следующих критериев:

• 370 МБ плюс дополнительные 268 МБ на каждый 1 ТБ физического хранилища
• Дополнительно 250 МБ на 1 ТБ физического хранилища, если включена дедупликация (UDS index)

То есть для 4 ТБ физического хранилища с дедупликацией вам понадобится:

370 MB + 4 * 268 MB +4 * 250 MB = 2 442 MB RAM

Итого 2,4 ГБ оперативной памяти дополнительно к памяти под ОС виртуального модуля. Вообще, StarWind рекомендует 8 ГБ памяти для виртуального модуля - 4 ГБ на машину и 4 ГБ на движок VDO для работы с хранилищем.

Один VDO-том может работать с хранилищем до 256 ТБ, что покрывает максимум потребностей в рамках хранилищ на базе серверов. Также StarWind очень рекомендует использовать дисковые массивы All-flash или NVMe-оборудование.

Общее правило развертывания таких хранилищ таково:

• Под VDO: аппаратный или программный RAID (LVM или mdraid)
• Над VDO: "толстые" (thick) диски StarWind Virtual SAN в режиме stand-alone или HA

Надо понимать, что сам том VDO - это тонкий диск, растущий по мере наполнения, поэтому устройство под ним должно иметь расширяемую природу (MD RAID, LVM).

Примерная схема отказоустойчивого решения StarWind Virtual SAN for vSphere на базе 2 узлов выглядит так:

После того, как вы установите StarWind Virtual SAN, настроите виртуальную машину и StarWind Management Console, нужно будет настроить аппаратный или программный RAID для хранилища.

Если вы используете аппаратный RAID, то просто создайте виртуальный диск для ВМ StarWind Virtual SAN на его хранилище, но обязательно типа "Thick Provisioned Eager Zeroed" (также вы можете использовать RDM-диск):

Если же вы будете использовать программный RAID, то нужно будет использовать HBA или RAID-контроллер в режиме DirectPath I/O passthrough, чтобы получить прямой доступ к дискам и собрать на их базе RAID-массив.

Для этого вам нужно будте выбрать правильный HBA/RAID-контроллер как PCI-устройство:

И пробросить его напрямую в виртуальную машину StarWind:

После этого в StarWind Management Console можно будет собрать RAID нужного вам уровня:

Рекомендации тут такие:

После этого в виртуальном модуле StarWind на полученном хранилище нужно будет создать VDO-устройство с нужными вам параметрами:

vdo create –activate=enabled –deduplication=enabled –compression=disabled –emulate512=enabled –indexMem=%size% –vdoLogicalSize=%size% –device=%yourdevice% -n=%name%

Здесь мы видим, что создается устройство с включенной дедупликацией, выключенной компрессией, нужным размером индексной памяти и заданного объема.

После создания это устройство надо отформатировать в XFS со следующими параметрами:

Далее вы можете создавать хранилище StarWind на этом устройстве и (опционально) сделать его реплику на партнерском узле в режиме HA. Также рекомендуется выставить настройку Disk.DiskMaxIOSize на хосте ESXi

В значение 512:

Ну и про оптимизацию производительности I/O-планировщика прочитайте вот эту статью базы знаний StarWind. Если вам интересен процесс создания хранилищ с дедупликацией и компрессией на базе StarWind Virtual SAN в стиле "от и до", то рекомендуем прочитать вот эту статью.

На днях в различных источниках появились сообщения об уязвимости CVE-2021-21972, которая есть в сервисах vCenter, что может привести к удаленному исполнению кода злоумышленником. Уязвимость по степени критичности оценивается на 9.8 из 10 (по шкале Common Vulnerability Scoring System Version 3.0) и имеет полное описание на сайте VMware как VMSA-2021-0002.

Интересно, что примеры реализации эксплоитов для Windows и Linux на базе этой уязвимости появились как минимум в шести разных местах, включая репозитории на GitHub (например, тут, тут и тут).

VMware сразу же выпустила патч к этой уязвимости, который вы можете загрузить по этой ссылке.

После публикации уязвимости начались массовые сканирования серверов vCenter (кстати, не удивительно, что уязвимость нашел русский инженер, вот ее описание):

Движок BinaryEdge нашел 15 000 серверов vCenter, торчащих в интернет с этой уязвимостью, а Shodan - около 6 700.

Уязвимость использует дырку в плагине vRealize Operations, который установлен по умолчанию, для неавторизованной загрузки файлов по порту 443, после чего становится доступным удаленное исполнение кода в операционной системе vCenter со всеми вытекающими.

В общем, всем нужно поскорее накатывать патч, так как любой с доступом к порту 443 сервера vCenter может потенциально получить к нему полный доступ.

Уязвимость CVE-2021-21972 затрагивает версии vCenter Server 6.5, 6.7 и 7.01. Соответственно, вам нужно накатить 6.5 Update 3n, 6.7 Update 3l или 7.0 Update 1c как можно скорее. Если накатить сейчас не можете, то временный workaround описан в KB 82374.

Недавно компания VMware обновила свое решение Hybrid Cloud Extension (HCX), предназначенное для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud. Версия HCX 4.0 предоставляет возможности большего контроля над процессами миграции, минимизации времени простоя, а также упрощении реконфигурации политик безопасности VMware NSX после миграции.

Давайте посмотрим на новые возможности VMware HCX 4.0:

1. Новая система нумерации релизов и обновленные политики жизненного цикла

Теперь систему версий можно просто представить вот так:

Кроме того, изменились политики жизненного цикла VMware N-2 Lifecycle Policy, которые теперь учитывают новую систему версионирования. Каждый минорный и мажорный релиз HCX будет поддерживаться минимум 12 месяцев со дня выхода.

2. Оценка времени миграции

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

Для первичного развертывания механизм Migration Estimation будет поддерживать только метод миграции Bulk Migration, а в будущем появится поддержка методов vMotion и Replication-Assisted.

3. Информация о событиях миграции

Для всех типов миграции (Bulk, vMotion, Replication-Assisted vMotion и OS-Assisted) предоставляется детальная информация об этих событиях. Там показаны данные всех событий, потоков рабочих процессов, также статусы текущих миграций и многое другое:

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

4. Инфоормация о виртуальных модулях Network Extension

HCX 4.0 предоставляет детальную информацию обо всех расширяемых сетях, реализуемых виртуальными модулями Network Extension (NE). Для них можно увидеть такие параметры, как bit rate, bytes transmitted и received, packet rate, packets transferred и received, с интервалом обновления в 1 минуту. Находится это на вкладке Network Extension Details в разделе Connection Statistics.

5. Перевод виртуальных модулей Network Extension в режим In-Service во время обновления

Виртуальные модули NE могут использоваться не только в процессе миграции, но и после него. Для таких ситуаций теперь есть специальный режим In-Service (как режим обслуживания в vSphere), который позволяет апгрейдить виртуальные модули, сокращая потенциальный простой инфраструктуры и минимизировать прерывания процессов.

6. Миграция тэгов NSX Security Tags 

Пользователи VMware NSX Distributed Firewall на источнике миграции могут смигрировать тэги NSX Security Tags в инфраструктуру публичного облака. Это работает для методов миграции Bulk Migration, HCX vMotion, HCX Replication-Assisted vMotion (RAV) и cloud-to-cloud mobility migration. Существующие тэги могут быть на базе решений NSX for vSphere и NSX-T.

Демо процесса миграции тэгов можно посмотреть вот тут.

Ну и в завершение - полезные ссылки, включая ссылку на скачивание VMware HCX 4.0:

• HCX 4.0.0 Software Download | Release Notes  
• HCX Technical Documentation 
• What’s New in VMware HCX 4.0 lightboard video 
• HCX Product Page | Hands-on Lab 
• HCX Blogs 
• HCX Majors Podcast 
• VMC on AWS Unplugged Podcast 

Команда PowerCLI компании VMware на днях выпустила обновление средства vSphere Desired State Configuration (DSC) версии 2.2. Механизм DSC есть в экосистеме Windows, начиная еще с Windows Server 2012 R2. С помощью него можно мониторить и управлять конфигурациями систем посредством специальных конфигурационных файлов на базе PowerShell, которые имплементируются через движок Local Configuration Manager (LCM), который должен быть на каждом хосте.

У VMware этот механизм работает несколько иначе, в качестве LCM используется прокси-хост, поскольку LCM не запустить ни на vCenter Server Appliance, ни на ESXi:

Так работал механизм до текущего момента, когда пользователям приходилось разворачивать отдельную Windows-машину под LCM. Но теперь появился модуль VMware.PSDesiredStateConfiguration, который предоставляет пользователям набор командлетов, чтобы скомпилировать и исполнить конфигурацию DCS без использования DSC Local Configuration Manager. Это позволяет использовать как Windows, так и Linux-машину в качестве прокси.

При этом пользователям по-прежнему предоставляется возможность использовать как vSphereDSC с движком PowerShell LCM, так и модуль VMware.PSDesiredStateConfiguration.

Давайте посмотрим, что нового появилось в DCS версии 2.2:

1. Новые ресурсы PowerCLI модуля

Вот они:

1. DatastoreCluster - создание, изменение, апдейт или удаление Datastore cluster
2. DatastoreClusterAddDatastore - добавление датастора к Datastore cluster
3. DRSRule - создание, изменение, апдейт или удаление правил DRS
4. VMHostVdsNic - изменение, апдейт или удаление "VMKernel nic" на vSphere Distributed switch
5. VMHostStorage - включение или отключение программного iSCSI-адаптера 
6. VMHostIScsiHbaVMKernelNic - используется для bind/unbind адаптеров VMKernel Network Adapters к указанному iSCSI Host Bus Adapter

2. Исправления ошибок

Поправлены ошибки в следующих командлетах:

• VMHostVDSwitchMigration 
• VMHostVssTeaming
• NfsDatastore

3. Операция Install/Update для модуля VMware vSphereDSC

Установка модуля теперь делается так:

Install-Module -Name VMware.vSphereDSC

Обновление вот так:

Update-Module -Name VMware.vSphereDSC

4. Новый модуль VMware.PSDesiredStateConfiguration

Как было сказано выше, теперь вы можете использовать Windows или Linux-машину без LCM для использования механизма DCS. Установить модуль можно следующей командой:

Install-Module -Name VMware.PSDesiredStateConfiguration

Новый командлет New-VmwDscConfiguration создает объект VmwDscConfiguration, который содержит информацию о конфигурации. Эту конфигурацию можно задать в ps1-файле и передать ее данному командлету. Например:

$config = New-VmwDscConfiguration -Path ./Site-A.ps1

Командлет Start-VmwDscConfiguration запускает исполнение конфигурации:

Start-VmwDscConfiguration -Configuration $config

Есть командлет Test-VmwDscConfiguration для проверки соответствия текущей конфигурации описанной:

Test-VmwDscConfiguration -Configuration $config

Можно также использовать параметр -Detailed для вывода полной информации по соответствию:

Test-VmwDscConfiguration -Configuration $config -Detailed

5. Новая динамическая конструкция vSphere Node

С помощью vSphere Node можно указать объект VINode (сервер vCenter или хост ESXi) и применить соответствующую конфигурацию к нужному узлу vSphere. Это дает следующие возможности:

• Персистентные сессии

Раньше для каждого подключения каждый ресурс требовал параметров учетной записи для установки сессии VISession. Теперь же если вы используете Vmware.PSDesiredStateConfiguration то можно создать персистентную VISession, которую можно использовать для всех ресурсов DCS.

• Не нужны файлы MOF

Поскольку LCM теперь не используется, то и для командлета New-VmwDSCconfiguration они не требуются. Конфигурация может храниться в переменной, либо в ps1-файле.

Скачать VMware vSphere DSC 2.2 можно по этой ссылке.

За последние дни на сайте проекта VMware Labs обновились некоторые полезные утилиты, а также были выпущены две новые - Workspace ONE Access Migration Tool и VCF Powernova.

Workspace ONE Access Migration Tool - это средство, которое позволяет упростить миграцию приложений от одного облачного клиента (tenant) к другому. Это может быть как в онпремизной, так и в SaaS-среде. Также это может быть полезно в целях отзеркаливания приложений одного тенанта к другому.

Возможности данной утилиты по миграции приложений:

• Копирование категорий приложений (App Categories)
• Миграция веблинков (сторонних IDO)
• Создание ссылок на федерированные (federated) приложения и копирование иконок (чтобы для пользователя ничего не менялось после миграции)
• Копирование App Assignment в раздел Category mapping

Скачать Workspace ONE Access Migration Tool можно по этой ссылке.

Вторая утилита - это средство VMware Cloud Foundation Powernova, которое позволяет проводить массовые операции по включению/выключению виртуальных машин по всему инвентарю виртуального датацентра VMware Cloud Foundation.

Утилита очень будет полезна в случае обслуживания инфраструктуры, а также при миграции VCF-окружений или необходимости отключить/подключить на время отдельные домены VCF.

Пока данное средство не работает для следующих окружений:

• Хосты vXRail
• Домены рабочей нагрузки WCP/Tanzu
• Вложенные (Nested) хосты ESXi

Скачать VMware Cloud Foundation Powernova можно по этой ссылке.

В понедельник мы писали новой версии решения для автоматизации рабочих процессов VMware vRealize Orchestrator 8.3, а сегодня расскажем еще об одном обновленном продукте семейства vRealize - VMware vRealize Operations 8.3 (vROPs). Напомним, что о прошлой версии vROPs 8.2 мы подробно писали вот тут.

Давайте посмотрим, что нового появилось в апдейте vROPs 8.3, тем более, что там как и всегда - масса новых функций:

1. Cloud Management Assessment (COA)

Эта функция является логическим продолжением vSphere Optimization Assessment (VOA) в vRealize Operations. Теперь COA позволяет расширить эти возможности за пределы vSphere для следующих задач:

• Подготовка к миграции на VMware Cloud on AWS
• Управление решением VMware Cloud on AWS
• Подготовка к миграции на VMware Cloud Foundation
• Управление решением VMware Cloud on Foundation
• Использование vRealize Cloud Universal
• Управление публичным облаком (AWS, Azure и т.п.)
• Управление решением Horizon

Для запуска этой утилиты надо нажать "+View More" на странице QuickStart и выбрать VMware vRealize Cloud Management Assessment:

Далее просто выберите нужную подкатегорию:

Дэшборды представляют облачную инфраструктуру в разных разрезах и дают массу полезной информации с объяснениями:

2. Функция Pathfinder

Pathfinder - это коллекция обучающих материалов VMware, которые представлены в виде удобных 10-15 минутных блоков (их более 100 штук).

Также движок Pathfinder напрямую интегрирован в CMA:

3. Поддержка FIPS 140-2

Operations 8.3 содержит криптографические модули, которые прошли тестирование по программе NIST FIPS 140-2 Cryptographic Module Validation Program (CMVP). Этот режим (FIPS-mode) можно выбрать только при новой установке, в процессе эксплуатации поменять его на обычный будет нельзя.

4. Метрики с циклом опроса в 20 секунд

По умолчанию метрики vROPs собираются раз в 5 минут, что обусловлено балансом между массивом хранимых и анализируемых данных и гранулярностью получения информации администратором.

Теперь же данные собираются раз в 20 секунд, а в истории хранятся средние данные раз в 5 минут, но полученные из усреднения этих 20-секундных значений. Подробнее об этом написано в KB 67792.

Иногда бывает так, что и усреднение не дает результата, так как оно сглаживает пиковые всплески, которые неплохо бы увидеть в реальном времени. Для этой цели есть механизм near real-time metric collection, который позволяют хранить точные данные за последние три дня:

Также есть и механизм 20-second peak metrics, который покажет пиковые значения для нужных метрик в 20-секундных интервалах:

5. Функции VMware Cloud on AWS

Теперь появились новые деревья для инвенторя инстансов SDDC, который реализован в объекте VMC World. Эти объекты унифицируют vCenter, vSAN и NSX-T в контексте сущностей VMC Organizations и SDDC.

Новый дэшборд VMC Configuration Maximums позволяет следить за приближением к хард и софт лимитам инфраструктуры. Для этого есть цветовое кодирование и алерты:

Новых алертов на эту тему аж 23 штуки:

Также можно создать VMC Configuration Maximum Report:

Текущие лимиты получаются через VMC API, но не все. Также можно подстроить их в разделе Administration / Configuration / Configuration Files / SolutionConfig / vmc_config_limits (подробнее в KB 81810).

6. Функции vRealize Operations Cloud

С момента последнего релиза стал доступен датацентр во Франкфурте:

vRealize Operations Cloud теперь сертифицирован по стандартам SOC 2, SOC 3 и ISO 27001/17/18.

Также появился новый дэшборд vRealize Operations Billing Usage, где показываются объекты, для которых собираются метрики в вашей инфраструктуре:

Более полный список новых возможностей вы можете найти в Release Notes. Скачать vROPs 8.3 можно по этой ссылке.

Недавно компания VMware выпустила обновленную версию продукта vRealize Orchestrator 8.3 (vRO), который входит в семейство решений vRealize и взаимодействует с такими продуктами, как vRealize Automation и vRealize Suite. Orchestrator предназначен для автоматизации большинства рутинных операций и рабочих процессов в облаке на базе VMware vSphere. О версии Orchestrator 8.1 мы, кстати, писали вот тут.

Давайте посмотрим, что нового VMware добавила в Orchestrator 8.3:

1. Роль Viewer

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

Роль показана в интерфейсе настройки ролей как Orchestrator Viewer:

Для такого пользователя будет доступно только действие Open с объектами:

Также режим просмотра будет и в Scripting Editor:

Эта роль может быть полезна для групп мониторинга и аудита.

2. Места использования и зависимости

Теперь в интерфейса можно узнать, где используется часть рабочего процесса и найти связи с другими элементами:

3. Улучшения юзабилити

Теперь табличные представления можно фильтровать по имени, типу и описанию в дата гридах:

После применения фильтра, можно отсортировать результаты по имени:

И после этого применить еще один фильтр, например, нам нужны только булевые переменные:

Параметр фильтра вписывается во всплывающем окошке прямо в гриде по клику на иконку:

4. Поддержка стандарта Federal Information Processing Standards (FIPS)

Orchestrator 8.3 содержит криптографические модули, которые прошли тестирование по программе NIST FIPS 140-2 Cryptographic Module Validation Program (CMVP). Этот режим (FIPS-mode) можно выбрать только при новой установке, в процессе эксплуатации поменять его на обычный будет нельзя.

Более подробно о новых возможностях VMware vRealize Orchestrator 8.3 рассказано тут и тут. Release notes находятся здесь. Скачать vRO 8.3 можно по этой ссылке.

Казалось бы, совсем недавно мы писали о выходе Veeam Availability Suite v10, в состав которого входил Veeam Backup & Replication 10, а компания Veeam выпускает уже одиннадцатую версию. Но нет, прошло уже больше года! Поэтому вполне вовремя видеть Veeam Backup & Replication 11, который вступил в стадию RTM-релиза (то есть продукт стал уже доступен для партнеров Veeam).

Пока в блогах Veeam вы можете почитать, что там появилось нового в целом, а после выхода мы расскажем подробности о главных возможностях продукта:

• Функции NAS Recovery - Malware Detection и Machine Learning
• Функция Instant MSSQL Recovery для мгновенного восстановления баз данных (описание на русском языке)
• Улучшения Continuous Data Protection (CDP) в Veeam v11 + вот тут
• Улучшения нативного плагина для vCloud Director
• Новые функции для расширений (extensions)
• Новые возможности Veeam v11 для Linux
• Некоторые фичи Veeam Backup & Replication v11
• Улучшения агентов Veeam Backup & Replication v11 - улучшенная эффективность и поддержка снапшотов хранилищ (описание на русском языке)
• Опция Google Cloud object storage для Veeam v11 

Обратная совместимость и поддержка платформы Veeam

• Veeam Backup & Replication, начиная с версии 9.5 Update 4 (build 9.5.4.2866), может сохранять бэкапы через Cloud Connect в облачный репозиторий, включая таковой для версии v11.
• Для репликации Cloud Connect Replication, реплики на основе Pre vCloud Director Hardware Plan могут отбрасываться на облачный хост v11.
• Новую версию обязательно надо накатить на Veeam Backup for Office 365 v5, чтобы она была совместима с v11.
• Backup & Replication v11 содержит новые версии Veeam ONE v11 (11.0.0.1379), а также апдейт Agent for Windows (5.0.0.4300) и Linux (5.0.0.4318), плюс совершенно новые Mac Agent (1.0.0.713) и Veeam Service Provider Console (5.0.0.6726).

Улучшения Veeam Cloud Service Provider

• Технология CDP Low second RPO replication, которая позволяет улучшить показатели репликации за счет использования интерфейса vSphere APIs for IO (VAIO).
• VCD to VCD Replication – функция для провайдеров VCSP, которая позволяет реплицировать данные между организациями VMware Cloud Director для одного или разных инстансов VCD.
• VCD Native HTML5 Plugin - vCloud Director Self Service Portal интегрирован напрямую в VCD.
• Улучшенная поддержка объектных хранилищ, в частности появилась поддержка Google Storage.

Текущие лицензии на Veeam Backup & Replication v10 будут действовать и на одиннадцатую версию - получать новые лицензии вам не потребуется.

Улучшения Veeam Service Provider Console v5 

Новая версия консоли Veeam Service Provider Console v5 даст сервис-провайдерам следующие возможности: 

• Готовая к производственной эксплуатации третья версия API
• Новые возможности контроля над агентами для Windows, Linux и Mac
• Возможность управлять бэкапами на AWS и Azure через обновленные нативные плагины
• Улучшенные функции безопасности и новые интеграции

Более подробно о новом релизе Veeam Backup & Replication 11 рассказано на специальной странице вот тут, а в блоге Veeam вы можете найти статьи об отдельных функциях продукта. Официальный запуск новой версии платформы для резервного копирования и репликации состоится через 5 дней.