Пару лет назад мы писали о производительности Microsoft SQL Server в облаке VMware Cloud on AWS для инстанса AWS-i4i.metal. С тех пор много что изменилось, а компания VMware анонсировала новый тип экземпляра m7i для VMware Cloud на AWS, который использует сетевое хранилище NFS вместо vSAN. Это предоставляет клиентам гибкое и масштабируемое хранилище на основе VMware Cloud Flex Storage и Amazon FSx для NetApp ONTAP.

Для других типов экземпляров VMware Cloud на AWS включено хранилище vSAN, которое базируется на локальных дисках каждого хоста. Хранилища данных vSAN растут вместе с кластером по мере добавления новых узлов. С m7i количество хранилища не зависит от числа хостов, и вы можете настроить его в зависимости от требований к хранилищу.

Ниже рассмотрим производительность виртуальных машин SQL Server, работающих на 3-узловом кластере m7i с хранилищем NFS, по сравнению с 3-узловым кластером i4i с хранилищем vSAN. Инстансы m7i основаны на процессорах Intel, которые на одно поколение новее, чем i4i. Вот чем отличаются эти инстансы:

Методология

Для тестов использовался набор ВМ с 16 vCPU и 24 vCPU. Поскольку экземпляры m7i имели 48 ядер, как 16 vCPU, так и 24 vCPU были равномерно распределены по общему количеству ядер, что облегчало сравнение производительности и делало его понятным. Для поддержки максимального числа ВМ с 16 vCPU на кластере m7i каждой ВМ назначили 60 ГБ ОЗУ.

Для тестов использовали ВМ Windows Server 2022 с установленным Microsoft SQL Server 2022 и применили открытый инструментарий бенчмаркинга DVD Store 3.5 для запуска нагрузок OLTP-приложений на SQL Server и измерения результатов. DVD Store симулирует онлайн-магазин, где клиенты просматривают, оставляют отзывы и оценивают, регистрируются и покупают продукты. Результаты выражаются в заказах в минуту (OPM), что является мерой пропускной способности. Чем выше показатели OPM - тем лучше.

Результаты производительности ВМ SQL Server с 24 vCPU против 16 vCPU

Результаты на рисунках 1 и 2 показывают производительность ВМ с 24 vCPU и 16 vCPU. Линия обозначает общую пропускную способность в OPM по всем ВМ в каждом тесте. Количество ВМ увеличивается в каждом тесте, начиная с 1 и заканчивая максимально возможным, исходя из количества vCPU, соответствующих числу доступных потоков в кластере.

Темп прироста OPM замедляется, когда количество vCPU превышает количество физических ядер и необходимо использовать второй логический поток (hyperthread) на каждом ядре. Это начинается с 8 и 12 ВМ для тестов с 24 и 16 vCPU соответственно.

Столбцы в каждом графике представляют использование CPU трех хостов для каждого теста. По мере добавления ВМ, VMware Distributed Resource Scheduler (DRS) автоматически размещал и, возможно, динамически перемещал ВМ между хостами для управления нагрузкой. Как показывают результаты, это поддерживало использование CPU на всех хостах довольно стабильным, даже когда нагрузка увеличивалась.

Последняя точка данных в тесте с 16 vCPU (рисунок 2) показывает небольшое снижение OPM, поскольку на этом этапе теста кластер немного перегружен. Несмотря на это, можно было продолжить масштабирование производительности кластера m7i, добавляя больше инстансов. В этих тестах был использован только кластер из 3 инстансов, но можно было бы добавить больше инстансов в кластер для увеличения его емкости.

Рисунок 1 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 24 vCPU на ВМ:

Рисунок 2 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 16 vCPU на ВМ:

Рисунок 3 сравнивает производительность ВМ с 16 vCPU и 24 vCPU таким образом, что в каждом тестовом случае назначалось одинаковое общее количество vCPU. Например, для 48 vCPU 2?24 vCPU сравниваются с 3?16 vCPU (по сумме - 48 в обоих случаях).

Рисунок 3 - производительность ВМ SQL Server: 16 vCPU по сравнению с 24 vCPU:

Сравнение производительности m7i с i4i

Те же ВМ были перенесены на кластер i4i и тесты повторили. Важно отметить, что чтобы сохранить ВМ максимально идентичными, им не увеличивали объем RAM, несмотря на то, что в кластере i4i было примерно в 2,5 раза больше RAM.

Как показывает рисунок 4, результаты для i4i были схожи в плане OPM и использования CPU хоста. Основное отличие: получилось запустить до 24 ВМ на i4i против максимума 18 ВМ на m7i. Это связано с большим количеством ядер и большей памятью в экземплярах i4i.

Рисунок 4 - трехузловой кластер i4i VMware Cloud on AWS: SQL Server ВМ и использование CPU хоста на ВМ с 16 vCPU по сравнению с vSAN:

Рисунок 5 показывает различия между m7i и i4i. Поскольку отдельные ядра экземпляров m7i имеют более высокую производительность, чем ядра кластера i4i, рисунок 5 показывает преимущество в производительности на левой стороне графика. Как только экземплярам m7i необходимо полагаться на второй логический поток (hyperthread) от каждого физического ядра для поддержки рабочих нагрузок, производительность i4i становится схожей. И, наконец, когда экземпляры i4i полностью используют преимущество большего количества ядер, их производительность превышает производительность m7i.

Рисунок 5 - различие между m7i и i4i:

Тестирование производительности говорит о хорошей работе SQL Server на m7i в рамках предоставляемой экземплярами m7i ресурсной емкости. Поскольку экземпляры m7i имеют меньше ядер и меньше памяти, чем i4i, важно использовать инструмент VMC Sizer, чтобы убедиться, что платформа соответствует потребностям баз данных.

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

26 февраля 2024 года Шанкар Иер, генеральный директор EUC, объявил, что глобальная инвестиционная компания KKR заключила окончательное соглашение о покупке подразделения EUC у Broadcom.

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

• EUC будет функционировать как независимая компания с долговременным обязательством предоставлять клиентам продукты и услуги высокого класса.
• KKR поддержит EUC долгосрочными инвестициями для повышения удовлетворенности клиентов и поддержки партнеров.
• И EUC, и KKR опубликовали общедоступные заявления, которые можно найти здесь: сообщение EUC и сообщение KKR.
• Workspace ONE и Horizon будут продолжать предоставлять варианты развертывания для государственного сектора в облачных решениях FedRAMP

EUC и Broadcom полностью привержены поддержанию непрерывного клиентского опыта услуг FedRAMP. Отделение систем FedRAMP Workspace ONE и Horizon от границы авторизации FedRAMP VMware будет осуществляться тщательно спланированным образом. Этот процесс будет продолжаться после официальной даты закрытия сделки с KKR, но обязательства по этому процессу были формально зафиксированы в договорных документах, определяющих взаимные обязательства сторон для достижения желаемого конечного состояния.

В конечном итоге, Workspace ONE будет продолжать функционировать в рамках авторизации FedRAMP VMware до завершения действий по разделению, и EUC получит независимую авторизацию FedRAMP. Horizon будет продолжать предоставлять частные или суверенные облачные решения для соответствия требованиям, включая варианты, размещенные в FedRAMP. Главные приоритеты VMware на протяжении этого перехода - постоянное внимание к безопасности систем Workspace ONE и Horizon, непрерывное поддержание статуса авторизации FedRAMP и непрерывная операционная поддержка наших клиентов. Подробнее об этом рассказано тут.

Недавно компания VMware в составе Broadcom объявила о новой продуктовой линейке VMware Cloud Foundation (VCF). Это комплексное решение, разработанное для управления центрами обработки данных, определяемыми программно (Software-Defined Data Centers, SDDC). Оно бесшовно интегрирует различные компоненты для предоставления единой и эффективной инфраструктуры. Компоненты интеграции в составе VCF способствуют его универсализации, позволяя организациям рационализировать и улучшать операции своих датацентров.

С операционной точки зрения, на первый план выходят два критически важных элемента: учет ресурсов (metering) и биллинг. Эти элементы играют ключевую роль для сервис-провайдеров и партнеров, использующих VMware Cloud Foundation. Metering включает измерение и отслеживание использования ресурсов разной природы, тогда как биллинг обеспечивает точный расчет и выставление счетов за предоставленные услуги через SDDC.

Биллинг является ключевым компонентом VMware Cloud Foundation, позволяя сервис-провайдерам точно выставлять счета клиентам на основе мониторинга использования ресурсов. Эта возможность обеспечивает прозрачные и справедливые финансовые операции, а также поддерживает оптимальное управление ресурсами и их распределение в динамичной среде SDDC-датацентров.

Что такое VMware Chargeback?

VMware Chargeback — это инструмент, предоставляемый компанией VMware, который позволяет поставщикам услуг управлять и распределять стоимость, связанную с виртуализированными средами. Он помогает как поставщикам, так и арендаторам понимать потребление ресурсов и, соответственно, учитывать и распределять затраты.

Chargeback функционирует как плагин для арендаторов, предлагая интерфейс учета. Он облегчает отслеживание, измерение и выставление счетов за предоставленные услуги через сервис VMware Cloud Director.

Что нового появилось в последнее время?

У сервис-провайдеров, использующих решения VMware, есть хорошее понимание chargeback — подхода к отслеживанию и назначению затрат на основе использования ресурсов. Поставщики услуг обычно знают, как Chargeback интегрируется с VMware Cloud Director, платформой для управления облачными ресурсами и услугами.

Теперь, с выпуском VMware Aria Operations версии 8.16 произошли заметные изменения в работе Chargeback. В этом релизе Chargeback наконец полностью интегрирован в VMware Aria Operations.

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

В начале рабочего процесса сервис-провайдеры начинают со страницы VMware Aria Operations. В этом интерфейсе у них есть возможность просто интегрировать Cloud Director с Chargeback. После этого поставщики могут приступить к конфигурации Chargeback и тонкой настройке различных параметров, таких как электронная почта.

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

Однако пользователи-арендаторы могут получить доступ к возможностям Chargeback через портал VMware Cloud Director, используя плагин Operation Manager.

Возможности VMware Cloud Director (VCD) Operations и Chargeback:

• Все возможности Chargeback (ранее известного как VMware Chargeback или Tenant App) теперь доступны нативно в Aria Operations.
• Специализированный стартовый экран для инфраструктурного слоя Cloud Director для всех ключевых возможностей Chargeback и операций.
• Возможность создавать и назначать политики ценообразования Cloud Director через политики Aria Operations.
• Возможность управления представлением для арендатора.
• Поддержка возможностей управления пользователями арендаторов и электронной почтой.
• Поддержка возможностей управления отчетами, оповещениями и уведомлениями арендаторов.
• Просмотр деталей Chargeback по организациям, OVDC, vApp и ВМ.
• Поддержка генерации счетов и планирования.
• Поддержка VMware Cloud Director (VCD 10.5.1 и выше) в Aria Operations на локальных серверах (Aria Operations 8.16).
• Новый и улучшенный плагин менеджера операций в VMware Cloud Director (VCD 10.5.1 и выше).
• Новый процесс миграции для перехода от VMware Chargeback (VMware Chargeback 8.16) к Chargeback на основе VMware Aria Operations (VMware Aria Operations 8.16) и операциям VMware Cloud Director (VCD 10.5.1 и выше).

Более подробно о возможностях Chargeback в Aria Operations можно узнать из документации.

Продолжаем рассказывать о решении VMware Avi Load Balancer, которое недавно стало доступно в качестве балансировщика как услуги (Load Balancer as a Service, LBaaS) для решения Aria Automation 8.16.1.

Часто менеджеров датацентров мучает простой вопрос – как администраторы знают, что приложения находятся в "хорошем" состоянии? В VMware провели огромное количество встреч и дебатов по теме, касающейся "здоровья приложений" - приведем ниже основные моменты статьи сотрудников Avi, касающейся здоровья приложений.

В команде были люди с разным опытом, им всем задали один и тот же вопрос – "что для вас значит здоровье приложения?". Вот некоторые из ответов, которые были получены:

• "Здоровье" – это пропускная способность (throughput), которую может обеспечивать приложение. Если она составляет 10 Гбит/с, это значит, что оно в хорошем состоянии.
• Здоровье плохое, когда CPU и память загружены более чем на 100%.
• Здоровье хорошее, когда задержка (latency) ниже 100 мс.
• Здоровье хорошее, если приложение работает и отвечает на проверки (health checks).

В реальном мире, если спросить вас - "вы считаете, что у меня хорошее здоровье, если я пробежал сегодня 3 мили?", в зависимости от того, кто вы, вы, скорее всего, ответите: "это зависит от разных факторов", "конечно!", "ты пробежал только сегодня или бегаешь каждый день?" или "каков был твой пульс и жизненные показатели после бега?". У вас будет много дополнительных вопросов, чтобы углубиться в детали. С этой точки зрения, теннисист Роджер Федерер, скорее всего, выиграл бы по этому показателю у большинства людей, даже если бы бегал с гриппом. Сделало бы это его здоровым? Конечно нет!

Как вы видите, простой факт возможности пробежки на 3 мили недостаточен для врача, чтобы выдать заключение о хорошем здоровье. Аналогично, если вы думаете, что можете определить здоровье сервера, исходя из простого факта, что он может обрабатывать пропускную способность 10 Гбит/с, вы, вероятно, ошибаетесь. Автору было трудно с этим смириться, особенно учитывая, что большую часть своей карьеры до Avi он провел в компании по производству оборудования, где было нормально считать, что сетевое оборудование в отличном состоянии, когда соединение работает и передает данные с пропускной способностью 10 Гбит/с.

Аналогии со здоровьем человека

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

На секунду давайте представим команду Golden State Warriors как веб-приложение. Тогда звездный баскетболист Стефен Карри, вероятно, был бы важным микросервисом в этом приложении. Как бы мы измеряли его здоровье? Конечно, когда Карри здоров, мы ожидаем, что он будет набирать около 30 очков за игру в среднем. Мы также не ожидаем, что он устанет во время игры. В хорошем состоянии здоровья (измеряемом с помощью таких показателей, как пульс, кровяное давление и т. д.) от Карри ожидают, что он будет последовательно и ровно выступать.

Автор применил аналогичную философию к измерению здоровья приложений. Вот определение здоровья от Merriam-Webster, которое он счел релевантным:

"состояние организма в отношении выполнения его жизненно важных функций, особенно оцениваемое субъективно или непрофессионально"

Автор немного улучшил это определение для "оценки здоровья" приложений в Avi:

"Avi Health (Score) – это мера производительности приложения и его постоянства, которая отражает любые риски для приложения в контексте различных факторов, таких как ресурсы и безопасность."

Пока все хорошо. Авторы определили оценку здоровья Avi. Однако оставался "слон в комнате" — как определять термины "производительность", "риски" и т. д. Вот как дальше было конкретизировано определение оценки здоровья:

• Performance Score: оценка производительности приложения отражает способность приложения соответствовать и превосходить SLA (соглашения об уровне обслуживания). Метрики производительности должны однозначно показывать хорошее состояние против плохого и указывать на соответствие приложения SLA. В этом случае метрики, такие как максимальное количество одновременных подключений или транзакций в секунду, стали неприемлемы, поскольку эти метрики не могли быть выражены как хорошие или плохие транзакции. Поэтому в VMware построили платформу, использующую множество метрик производительности, таких как качество ответа, качество соединения и качество опыта клиентов, для представления производительности приложения.
• Resources Risk (Penalty): следующим важным набором метрик было определение, достаточно ли у приложений ресурсов (или выносливости, энергии и т.д.) для постоянного соответствия требованиям производительности. Оценка здоровья Avi комбинирует несколько метрик, таких как использование CPU, использование памяти, использование программной очереди, использование лицензий и т.д. Вместо прямой шкалы были применены человеческие принципы к ресурсам, которые накладывают штрафы только тогда, когда использование ресурсов превышает пороговое значение (скажем, 80%).
• Security Risk (Penalty): так же, как люди лучше работают, когда они находятся в безопасной умственной, физической и социальной среде, в VMware пришли к выводу, что уязвимости приложения должны приводить к снижению его здоровья. Например, использование слабых шифров для SSL приводит к снижению оценки здоровья Avi.
• Application Performance Consistency (Anomaly penalty): тут считается, что согласованность производительности является очень важной мерой здоровья приложения. Неважно, если производительность достаточна в периоды низкой нагрузки, если она снижается в периоды пиковой нагрузки.

Теперь, когда определена оценка здоровья Avi, все еще нужно проработать детали того, как комбинировать качество сети с качеством HTTP-ответа, как рассчитывать оценку, когда и память, и CPU используются более чем на 80% и т.д.

Уточнение алгоритма

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

1. Когда есть две метрики или факторы здоровья различного рода, то используется наименее здоровый фактор для представления Health Score. Например, у человека может быть очень крепкое сердце, но опухоль в головном мозге. Нет смысла вычислять "среднее здоровье" между этими органами, но важно подчеркнуть, что тело не в очень хорошем состоянии из-за опухоли в мозге. Для программного обеспечения выразили эти ситуации как здоровье = min(здоровье_A, здоровье_B), когда необходимо объединить здоровье двух факторов A и B.

2. Когда две метрики или факторы здоровья подобны, то здоровье усредняется по всем подобным факторам. Например, если виртуальная служба имеет 100 серверов, то здоровье пула определяется через среднее здоровье всех 100 серверов, учитывая, что все серверы должны быть схожей природы.

Еще одним важным моментом было, должно ли здоровье приложения основываться на мгновенных метриках или должно включать историю производительности. Большинство пользователей и сотрудников разделились на две группы: 1) команда с опытом в индустрии аппаратного обеспечения, которая отвечала, что здоровье приложения должно основываться на мгновенной информации и 2) команда с программным/операционным опытом, которая склонялась к анализу тенденций и истории. Опять же, в VMware использовали стратегии принятия решений в области здоровья человека, чтобы разрешить спор – считается, что человек еще не в хорошем здоровье, если он все еще восстанавливается после недавней болезни.

Поэтому было принято решение смотреть на метрики последних 6 часов, чтобы определить оценку здоровья приложения. На платформе Avi Vantage, когда администратор приложения видит идеальную оценку здоровья (100), он может с уверенностью сказать, что за предыдущие 6 часов здоровье приложения было идеальным и приложение соответствовало его ожиданиям по производительности.

Avi Health Score - это основа

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

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

Так что теперь вы знаете, как работает метрика Health Score в Avi, и что означают все эти пункты:

На днях, одновременно с релизом продукта Aria Operations 8.16, компания VMware объявила о доступности для загрузки решения Aria Automation 8.16.1 (ранее о версии Aria Automation 8.16 мы писали вот тут).

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

Как VMware рассказывала ранее в своем блоге, в компании рады объявить о новых возможностях балансировщика нагрузки как услуги (Load Balancer as a Service, LBaaS), реализованных на основе Aria Automation 8.16.1 с Avi Load Balancer, которые усиливают решение по автоматизации сетей VMware Cloud Foundation. Напомним, что Avi доступен как аддон к VMware Cloud Foundation (VCF).

В ответ на растущую потребность провайдеров облачных услуг новая интеграция с Avi из коробки позволяет организациям предоставлять комплексный набор возможностей LBaaS на протяжении всего жизненного цикла для частных облачных сред на базе VCF.

Как VMware Cloud Foundation и Avi реализуют модель управления облачными операциями

VCF и Avi вместе упрощают операции с частным облаком на протяжении жизненного цикла - с Day-0 по Day-2. Возможности автоматизации VCF, основанные на Aria Automation, позволяют организациям максимально использовать инвестиции в Avi и масштабировать свои возможности LBaaS.

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

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

Широкий спектр опций, предлагаемых Avi, что было недоступно ранее с NSX-T LB, и гибкая архитектура автоматизации VCF обеспечивают клиентам большую свободу и выбор для предоставления именно тех возможностей LBaaS, которые им нужны.

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

Благодаря встроенным возможностям VCF, администраторы облака смогут предложить командам разработчиков приложений доступ к самообслуживанию для услуг балансировки нагрузки с Day-4 по Day-7 уровень. Это позволит командам приложений и инфраструктуры немедленно развертывать балансировку нагрузки в момент доставки приложения, с минимальными знаниями технологии балансировки нагрузки или необходимостью создания ручных заявок.

О развертывании балансировщика Avi Load Balancer можно почитать вот тут. Release Notes по продукту VMware Aria Automation 8.16.1 доступны тут.

Недавно компания VMware объявила о выпуске решения Aria Operations 8.16, предназначенного для комплексного управления и мониторинга виртуальной среды на платформе VMware vSphere в облаке. В прошлый раз мы писали о нововведениях решения Aria Operations вот тут. Этот релиз сосредоточен на упрощении использования продукта, улучшении производительности и возможностей управления.

Как было недавно объявлено, VMware Aria Operations теперь будет доступно только как часть VMware Cloud Foundation и VMware vSphere Foundation. VMware Cloud Foundation — это комплексное решение, которое сочетает в себе масштабируемость и гибкость публичного облака с безопасностью и производительностью частного облака. Aria Operations больше не продается как отдельный продукт или как SaaS, а доступно только как аддон.

Вот некоторые из новых функции функций Aria Operations версии 8.16:

1. Интеграция функции Chargeback в Aria Operations

Chargeback, ранее известный как приложение Tenant, был отдельным продуктом, который работал в сочетании с операциями VMware Aria и vCloud Director. В этом релизе Chargeback был интегрирован в VMware Aria Operations.

Это позволит:

• Вести упрощенный учет расходов для арендаторов с гибким планированием и выставлением счетов на уровне организации или виртуального датацентра.
• Настраивать ценообразование с поддержкой моделей распределения ресурсов.
• Более глубоко понимать использование сети арендаторами.
• Получить обширные возможности самостоятельного мониторинга.
• Использовать пользовательские панели управления и отчеты для провайдеров и арендаторов.

2. Улучшенная информация мониторинга сети через LLDP

Протокол обнаружения на уровне канала (Link-Layer Discovery Protocol, LLDP) — это протокол, не зависящий от производителя, используемый вендорами сетевых устройств, не относящимися к Cisco. VMware Aria Operations предоставлял ограниченный набор информации для протокола LLDP по сравнению с CDP (Cisco Discovery Protocol). С этим релизом будут доступны следующие данные для протокола LLDP:

• Описание системы
• Размер MTU
• Описание порта
• Состояние агрегирования ссылок для конфигураций LACP

3. Уменьшение разнообразия виджетов для упрощения взаимодействия с дашбордами

vSphere и vSAN из коробки включают дашборды, использующие ограниченное количество виджетов и представлений. Для расширения возможностей при одновременном увеличении удобства использования было решено уменьшить это число до 17. Ниже приведен список виджетов и представлений:

1. List
2. Top-N List
3. Summary Table
4. Health Chart
5. Trend Chart
6. Distribution Chart
7. Scoreboard
8. Heat Map
9. Property List
10. Geo
11. Relationship (ранее называлось Object Relationship)
12. Weekly Pattern
13. Alert List
14. Top Alerts
15. Metric Chart
16. Metric Picker
17. Object List

В средах, где присутствует большое количество рабочих нагрузок, становится сложно отслеживать множество операций vMotion и ВМ, перемещаемых из-за workload placement (WLP). Новая метрика WLPVmMovedCount была добавлена на уровне объекта кластера для:

• фиксации числа миграций ВМ, происходящих при каждом действии WLP
• определения вовлеченных кластеров и времени этих миграций

4. Обновленный пакет соответствия VCF на основе руководства по аудиту VCF 4.5

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

5. Использование тегов для исключения ВМ и кластеров из участия в размещении рабочих нагрузок

В крупных средах, где работают критически важные рабочие нагрузки, возникает необходимость запускать определенные ВМ на конкретных хостах. В случаях, когда происходит обновление VCF, такие ВМ необходимо исключить из WLP. В последней версии можно использовать теги, созданные в vSphere, для формирования Business intent, чтобы исключить ВМ и кластеры из участия в размещении рабочих нагрузок.

6. Возможность изменения языка отображения VMware Aria Operations

VMware Aria Operations в настоящее время выбирает язык отображения на основе настроек браузера. С последним релизом пользователь сможет изменить язык отображения в разделе настроек пользователя.

Больше подробностей о новом релизе VMware Aria Operations 8.16 приведено в Release Notes.

Недавно компания VMware представила очередной релиз платформы виртуализации и доставки настольных ПК и приложений Horizon 8 2312, в котором появилось несколько функций, разработанных для улучшения опыта работы как администраторов, так и конечных пользователей. Horizon 2312 предлагает набор возможностей, направленных на оптимизацию операций, обеспечение безопасности сессий, повышение производительности и добавление большей персонализации к каждой сессии. Напомним, что о прошлой версии VMware Horizon 8 2306 мы рассказывали вот тут.

Horizon 2312 является последним релизом ветки Extended Service Branch (ESB) - это означает, что VMware предоставит несколько будущих обновлений, содержащих критические исправления ошибок и поддержку новых версий ОС в течение трехлетнего периода. Более подробно об этом рассказано здесь.

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

Улучшения клиента и агента Horizon

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

1. Автоматическое обновление агента Horizon для упрощения обслуживания

Вы можете оптимизировать ваши Day-2 операции с помощью активной технологии виртуального рабочего стола (VDI), используя функцию auto-upgrade для агента Horizon, которая автоматизирует обновления по всем вашим VDI или RDSH десктопам, убирая необходимость в ручных обновлениях. Эта функция доступна эксклюзивно для клиентов с лицензией Horizon Plus или Horizon Universal и применима для рабочих столов Full Clone и серверов RDSH. Для обновления агента Horizon в пулах мгновенных клонов или фермах удаленных рабочих столов (RDS) просто обновите агент Horizon в золотом образе и запланируйте окно технического обслуживания для развертывания нового образа.

2. Оптимизированная производительность CPU

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

3. Улучшенные изображения с бинарным lossless-режимом для кодека Blast

Horizon 2312 вводит бинарный lossless-режим для кодека Blast. Он делает так, что при сжатии изображений не теряется ни одна деталь — обеспечивая пиксель-к-пикселю воссоздание оригинального изображения. Эта функция обеспечивает максимальную четкость изображения, гарантируя, что конечные пользователи получают лучший опыт использования. С бинарным lossless-режимом Blast пользователи в критически важных областях, таких как здравоохранение, могут быть уверены, что их изображения, включая рентгеновские снимки и другие детализированные сканы, передаются без потери информации.

4. Увеличение персонализации с помощью настраиваемых фонов Microsoft Teams

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

5. Размытие фона для клиента Linux

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

6. Модуль FIPS для MacOS

Для клиентов, требующих модуль обработки федеральных стандартов информации (FIPS) для macOS, клиент Horizon MacOS использует шифры, соответствующие FIPS.

7. Упрощенное развертывание Horizon Linux с помощью инструмента легкой настройки

Horizon 2312 получил легкую настройку для агента Horizon Linux. Этот новый инструмент предназначен для упрощения процесса установки с помощью CLI-инсталлятора и руководства администратора. Он предлагает пошаговый подход к развертыванию агента Horizon Linux, облегчая более гладкую и эффективную настройку. С помощью инструмента легкой настройки администраторы ИТ теперь могут без труда устанавливать агент, упрощая и обеспечивая успешное развертывание в операционной системе Linux.

8. Улучшения режима эмуляции, совместимого с ARM, для клиента Windows

На основе релиза Horizon 2309, который добавил поддержку режима эмуляции, совместимого с устройствами на базе ARM, решение Horizon 2312 предоставляет дополнительную функциональность с поддержкой «Login as Current User» (LACU). Эта функция, эксклюзивная для Windows, упрощает рабочие процессы для устройств, входящих в домен, используя функциональность LACU, чтобы позволить пользователям запускать Horizon без необходимости повторной аутентификации. Поддержка Horizon для ARM предоставляет клиентам больше выбора оборудования для их конечных пользователей, предлагая больше вариантов аппаратного обеспечения и обеспечивая операционную эффективность.

9. Возможность блокировки SendKey для защиты ВМ от вредоносных скриптов

Horizon 2312 вводит возможность блокировать скрипты PowerShell и другие скрипты SendKey от передачи с устройства пользователя в виртуальную машину. Блокируя скрипты от отправки вредоносных нажатий клавиш, эта функция предотвращает манипуляции злоумышленников с сессией конечного пользователя. Доступная для Horizon Client for Windows, эта защитная мера помогает предотвратить потенциальные атаки типа "отказ в обслуживании" (DoS) и внедрение вредоносного программного обеспечения, обеспечивая безопасность виртуальных сессий.

10. Интеграция DEEM улучшает возможности телеметрии Horizon

Horizon интегрировал возможности управления цифровым опытом сотрудников (DEEM) для улучшения аналитики по опыту сотрудников. Horizon будет предоставлять информацию, связанную с сессией, агенту DEEM, оптимизируя сбор и передачу телеметрии ВМ внутри гостевой системы напрямую в Workspace ONE Intelligence. С этим обновлением агент Horizon делится телеметрией гостевой ОС — такой как ID сессии Horizon, ID пула и имя пула — с агентом DEEM, предоставляя набор данных, доступных для анализа. Собранная информация о производительности ВМ и опыте пользователя позволяет администраторам превентивно решать проблемы, оптимизировать ресурсы и улучшать общий опыт пользователя. Эта интеграция DEEM и агента Horizon в настоящее время находится в бета-тестировании до конца марта 2024 года. Если вы заинтересованы в участии в бета-программе, то можно зарегистрироваться тут.

Новые возможности платформы Horizon 2312

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

1. Права доступа Horizon Cloud

Horizon 2312 позволяет конечным пользователям получать права доступа как из Horizon 8, так и из Horizon Cloud Service (HCS). Пользователи могут входить в локальный сервер подключения Horizon с использованием своих учетных данных без необходимости повторного входа для доступа к тем же правам на рабочие столы и приложения в облаке. Эта интеграция устраняет необходимость в использовании множества URL, выходов и дополнительных входов в систему при переключении между локальными и облачными рабочими столами, синхронизируя права доступа в обеих средах. Конечные пользователи могут аутентифицироваться через клиент Horizon для Windows или HTML Access, получить свои права Horizon 8 и затем получить доступ к своим правам Azure в Horizon Cloud Next-Gen с использованием токена JWT. Для получения дополнительной информации обращайтесь сюда.

2. Интуитивно понятный графический интерфейс для функции форензики

На основе функции форензики, представленной в релизе Horizon 2206, которая позволяет сохранять непостоянные ВМ для последующего просмотра, Horizon 8 теперь добавил графический пользовательский интерфейс (GUI). Специально разработанный для рабочих столов Instant Clone, этот интуитивно понятный графический интерфейс предоставляет информацию, связанную с пользователем, и детали форензических действий внутри ВМ. Новый графический интерфейс служит мостом, добавляя видимость и простоту к процессам расследований в виртуальных средах.

Функции форензики могут быть применены к пользователям или группам:

Отдельные машины пользователя или группы можно выбрать для более детального изучения:

3. Оптимизированная база данных ADAM для улучшения производительности репликации

В связи с ростом баз данных Active Directory Application Mode (ADAM), Horizon 2312 предлагает решение, направленное на уменьшение размера базы данных за счет сокращения периода "tombstone-lifetime" для уменьшения времени репликации. Ранее удаленные объекты сохранялись в течение 180 дней, что приводило к увеличению базы данных и удлинению времени репликации. В версии 2312 этот период сокращается до 60 дней, что приведет к уменьшению размера базы данных, ускорению репликации и повышению надежности работы системы. Кроме того, это помогает сократить время, необходимое для полной репликации базы данных ADAM, например, при добавлении Connection Server в существующую среду.

4. Настройка маршрутизации RDSH для опубликованных приложений и рабочих столов

Для предоставления администраторам более точного контроля во время тестирования и устранения неполадок, Horizon 2312 позволяет использовать опубликованные приложения и рабочие столы для направления пользователей на конкретные RDSH в рамках фермы. Эта функциональность сделана в ответ на потребности заказчиков — будь то для проверки и мониторинга всего процесса end-to-end или для проведения теста на каждом RDSH внутри фермы. Эта функция активируется в настройках опубликованного приложения или рабочего стола и требует использования параметра командной строки клиента Horizon для Windows. Функция также доступна для выбора конкретной виртуальной машины из пула non-persistent рабочих столов.

5. Автоматизированное обслуживание мгновенных клонов с автоматическим отключением хостов RDS

В обновлении Horizon 2313 автоматически отключаются отдельные хосты RDS в фермах мгновенных клонов RDS при выполнении обслуживания и использовании опции "Wait for users to logoff". Ранее администраторам приходилось вручную вмешиваться, чтобы отключить хосты для обслуживания. Теперь система автоматизирует этот процесс, оставляя достаточное количество хостов RDS включенными для поддержания доступа пользователей, позволяя другим хостам RDS освобождаться и обновляться.

6. Политика приостановки питания для мгновенных клонов с vGPU

Применение политик управления питанием полезно для экономии ресурсов, когда ВМ не используются. В Horizon 2312 администраторы могут использовать политику приостановки удаленной машины для пулов мгновенных клонов с поддержкой NVIDIA vGPU. Эта функция активируется ESXi, который поддерживает политики приостановки/возобновления питания для ВМ с vGPU. Отметим, что только версии ESXi 6.7 или выше поддерживают эту функцию.

7. Настройка текста запроса на сброс пароля в консоли администратора

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

Настроенное сообщение будет показано при неудачной попытке изменения пароля:

8. Завершена модернизация API с полным переходом на REST

Horizon 2312 завершает переход с API, основанных на SOAP, на REST API с полным сохранением функциональности предыдущих SOAP API. Все новые RESTful API можно загрузить с сайта API сервера Horizon.

9. Архитектура vSAN Express Storage

Horizon 8 2309 начал поддерживать vSAN 8 Express Storage Architecture (ESA) как для полных, так и для мгновенных клонов. Сейчас эта поддержка была улучшена. vSAN ESA — это новая, опциональная архитектура хранения, введенная в vSAN 8. Кроме того, с этой новой поддерживаемой архитектурой, Horizon может поддерживать до 500 ВМ на хост ESXi в зависимости от рабочей нагрузки и конфигурации оборудования. vSAN 8 предоставляет клиентам свободу выбора, какую из двух архитектур (vSAN OSA или vSAN ESA) использовать, чтобы лучше всего удовлетворить их потребности. vSAN ESA обеспечивает новые уровни производительности, масштабируемости, надежности и простоты использования на базе высокопроизводительных устройств хранения. Чтобы узнать больше почитайте вот эту статью блога VMware.

На этом обзор основных моментов релиза Horizon 2312 закончен. Для полного ознакомления со всеми улучшениями обратитесь к Horizon 8 2312 Release Notes.

Ransomware стало настоящей напастью последних лет - выплаты компаний злоумышленникам, зашифровавшим данные и держащим их в заложниках, перевалили за миллиард долларов в прошлом году (и это только то, что известно). Серверы VMware ESXi и vCenter, являющиеся основными компонентами инфраструктуры vSphere, представляют главную мишень для атак Ransomware.

В рамках конференции VMware Explore Europe 2023 прошла интересная сессия, где рассматривались примеры из реального мира по борьбе с программами-вымогателями, а также обсуждались проактивные методики, которые позволят избежать атаки или минимизировать последствия:

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

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

2. Важно провести различие между защитой рабочих нагрузок (виртуальные машины, серверы, клиенты, AD) и защитой инфраструктурной платформы (vSphere, хранилище и т.д.), поскольку каждое требует различных мер безопасности. Эти аспекты должны быть отделены друг от друга.

3. Понимание путей атаки, ведущих к появлению программы-вымогателя в инфраструктуре vSphere, является ключевым. Эти пути включают начальный доступ, использование Active Directory и различные способы добраться и атаковать vCenter Server и ESXi.

4. Восстановление среды vSphere после атаки не должно включать в себя выплату выкупа. Платеж атакующим увеличивает риск будущих атак и не гарантирует полного решения проблемы.

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

6. Очистка и восстановление скомпрометированных компонентов, таких как виртуальные машины, vCenter Server и хосты ESXi после атаки, требует тщательного рассмотрения и технического анализа (форензика).

7. Для защиты vSphere от атак должны быть предприняты несколько мер, включая сегментацию vSphere от рабочих нагрузок и клиентов, использование EDR/XDR/SIEM для конечных точек и vSphere, установку обновлений безопасности и следование рекомендациям по защите платформы vSphere.

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

9. UEFI Secure Boot может использоваться для проверки целостности файлов загрузки и ядра ESXi, что защищает от угроз с использованием неподписанных VIB.

10. Деактивация доступа к Shell для не-root пользователей ESXi может предотвратить боковое движение от vCenter к ESXi, что является важной мерой для остановки или замедления атакующего.

VMware Cloud Foundation (VCF) — это решение для частного облака от Broadcom, основанное на виртуализации вычислений, сетевых функций и хранилищ, предоставляющее клиентам возможность реализации модели облачной операционной системы на онпремизных площадках клиентов (более подробно об этом тут, тут и тут). Оно предлагает такие преимущества, как простота развертывания и управление жизненным циклом с использованием предварительно проверенного списка ПО (Bill of Materials, BOM), который тщательно тестируется на совместимость.

Хранение данных (критически важная часть частного облака) поддерживается в двух категориях: Основное (Principal) и Дополнительное (Supplemental).

Основное хранилище (Principal Storage)

Основное хранилище настраивается при создании нового домена рабочей нагрузки (Workload Domain) или кластера в консоли SDDC Manager. После создания тип основного хранилища для кластера изменить нельзя. Однако Workload Domain может включать несколько кластеров с собственными типами основного хранилища.

Основные варианты хранения данных (principal storage) включают:

• vSAN
• vVols
• NFSv3
• VMFS на FC-хранилищах

Следует отметить, что vSAN является единственно поддерживаемым типом основного хранилища для всех кластеров в управляющем домене (Management Domain). vSAN требуется для управляющего домена, поскольку он предсказуем с точки зрения производительности. vSAN предоставляет высокопроизводительное решение для хранения данных Enterprise-уровня для SDDC. Использование vSAN исключает внешние зависимости и облегчает использование средств автоматизации для инициализации управляющего домена VCF. Во время первоначальной установки VCF Cloud Builder инициализирует все основные компоненты центра обработки данных, определяемые программно - такие как vSphere, NSX и vSAN, на минимально необходимом количестве хостов. Этот процесс первоначального запуска в среднем занимает около двух часов.

Дополнительное хранилище (Supplemental storage)

Supplemental storage предоставляет дополнительную емкость кластеру и рекомендуется для данных Tier-2 или Tier-3, таких как библиотеки контента vSphere, шаблоны виртуальных машин, резервные копии, образы ISO и т. д. Дополнительное хранилище требует ручной настройки, не интегрировано и не отображается в SDDC Manager.

Доступные варианты таких хранилищ включают vSAN, vVols, VMFS на FC или iSCSI, NFSv3 или v4.1, а также NVMe-FC или NVMe-TCP.

Роль vSAN ESA

Начиная с версии 5.1, vSAN поддерживает как OSA (оригинальная архитектура хранения), так и ESA (экспресс архитектура хранения). vSAN ESA оптимизирован для использования с высокопроизводительными устройствами хранения нового поколения на базе NVMe, чтобы обеспечить еще более высокие уровни производительности для требовательных рабочих нагрузок, таких как OLTP и генеративный AI. Broadcom рекомендует использовать vSAN ESA в качестве основного хранилища для всех доменов рабочих нагрузок, чтобы получить все преимущества управления и обслуживания полностью программно-определенного стека.

vSAN также обновляется и патчится через LCM (Lifecycle Manager) в SDDC Manager. Обновление и патчинг хранилищ, отличных от vSAN, является ручной задачей и не входит в процедуры управления жизненным циклом, реализованные в SDDC Manager. Для обеспечения поддержки, само хранилище и его HBA необходимо проверять на соответствие VMware Compatibility Guide, когда vSAN не используется.

vSAN использует движок Storage Policy-Based Management (SPBM), который позволяет управлять политиками хранения на уровне виртуальных машин, а не на уровне всего хранилища (datastore). С помощью этого механизма вы можете управлять всеми хранилищами инфраструктуры VCF. Если у вас большая инфраструктура, то необходимо использовать программные средства автоматизации, так как вручную управлять LUN и виртуальными томами и их возможностями очень проблематично в большом масштабе.

Также на эту тему есть интересная статья: "Why vSAN and vVols are Best for VMware Cloud Foundation".

Выводы

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

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

• VMware Cloud Foundation Resource Center
• vSAN ReadyNode Sizer
• Why vSAN and vVols are Best for VMware Cloud Foundation

Недавно в компании VMware решили несколько переработать состав доступных онлайн лабораторных работ Hands-On Labs (HoL), включив туда новый контент в соответствии с последними изменениями в продуктовой линейке, а также убрав уже не актуальные лабы. Напомним, что полный список доступных онлайн лабораторных работ доступен по этой ссылке. А о прошлом пакете новых работ HoL мы писали вот тут.

Сейчас в списке находятся 103 лабы:

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

Также некоторые лабы были заменены более актуальными аналогами, вот также их список:

Ну и некоторые лабораторные были отправлены в архив, поскольку полностью потеряли актуальность:

Конструктор лаборатории VMware Cloud Foundation Lab Constructor (VLC) Holodeck Toolkit предназначен для обеспечения масштабируемого, повторяемого способа развертывания вложенных сред VMware Cloud Foundation (VCF) непосредственно на хостах VMware ESXi. Эти среды идеально подходят для практических занятий нескольких команд, изучающих возможности VCF и реализации управляемого заказчиком облака VMware.

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

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

• Снижение требований к оборудованию - при работе в физической среде VCF требует четыре узла vSAN Ready Nodes для домена управления и дополнительные хосты для создания кластеров и доменов рабочих нагрузок. Во вложенной среде те же четыре-восемь хостов легко виртуализируются для работы на одном хосте ESXi.
• Самодостаточные сервисы - конфигурация Holodeck Toolkit предоставляет общие инфраструктурные сервисы, такие как NTP, DNS, AD, сервисы сертификатов и DHCP внутри среды, исключая необходимость полагаться на сервисы центра обработки данных во время тестирования. Каждой среде требуется один внешний IP.
• Изолированная сеть - конфигурация Holodeck Toolkit устраняет необходимость в соединениях VLAN и BGP в сети клиента на ранних этапах тестирования.
• Изоляция между средами - каждая развертываемая среда Holodeck полностью самодостаточна. Это избегает конфликтов с существующими сетевыми конфигурациями и позволяет развертывать множество вложенных сред без опасений насчет перекрытия.
• Множественные развертывания VCF на одном хосте VMware ESXi с достаточной мощностью - типичное развертывание стандартной архитектуры VCF с четырехузловым доменом управления и четырехузловым доменом рабочих нагрузок VI, а также дополнениями, такими как VMware vRealize Automation, требует примерно 20 ядер процессора, 512 ГБ памяти и 2.5 ТБ диска.
• Автоматизация и повторяемость - развертывание вложенных сред VCF почти полностью автоматизировано и легко повторяемо с использованием файлов конфигурации. Типичное развертывание занимает менее 3 часов, с менее чем 15 минутами активного времени использования клавиатуры.

Среда Holodeck Toolkit 2.0

Пакет Holodeck Toolkit 2.0 состоит из нескольких основных компонентов:

• Пакет VCF Lab Constructor (VLC) 5.0 для полной автоматизации развертывания повторяемых вложенных лабораторий Cloud Foundation на одном хосте ESXi. Этот релиз поддерживает VCF 4.5, 4.5.1 и 5.0.
• Пользовательские файлы конфигурации VLC-Holo-Site-1 и VLC-Holo-Site-2 для VLC, поддерживающие развертывания VMware Cloud Foundation с несколькими сайтами.
• Пользовательский Holo-Router на базе VMware Photon OS для поддержки коммуникаций внутри вложенной среды VCF и из этой среды во внешнюю сеть.
• Пользовательская Holo-Console на базе Microsoft Windows Server 2019.
• Полностью автоматизированный механизм создания ISO-образа Holo-Console.
• Полные руководства по развертыванию и эксплуатации одного или нескольких серверов Holodeck.
• Набор лабораторий Holodeck "Always succeed" для демонстрации модели облачной эксплуатации нескольким командам внутри центра обработки данных.
• Программно-определенные сети и безопасность с VMware NSX Data Center.
• Автоматизация частного облака на базе VMware Cloud Foundation.
• Масштабирование развертывания и мониторинга приложений с VMware vRealize Automation.
• Миграция рабочих нагрузок с VMware HCX.
• Модернизация приложений с VMware Tanzu.

Обзор VCF Lab Constructor (VLC)

VLC - это утилита PowerShell/PowerCLI, разработанная для автоматизации развертывания VMware Cloud Foundation во вложенной среде. VLC, используемый с конфигурацией Holodeck, автоматизирует предоставление стандартизированной среды Holodeck "Pod".

Каждый Pod Holodeck содержит:

• Четырехузловой домен управления VCF на вложенных узлах, готовых к использованию с vSAN.
• Опционально три дополнительных вложенных хоста в домене рабочих нагрузок - или второй кластер vSphere в домене управления, или просто дополнительные элементы первого.
• NSX полностью настроен.
• Развернутый AVN/NSX Edge (рекомендуется).
• Развернутый Tanzu (опционально).
  
• VM Cloud Foundation Cloud Builder, настроенный для предоставления DHCP, NTP, DNS, BGP peering и L3 маршрутизации внутри пода.

VLC также может автоматизировать развертывание второго экземпляра VCF на под для предоставления многосайтовой конфигурации VCF для продвинутых лабораторных занятий, таких как NSX Federation, VMware Site Recovery Manager и VCF с vSAN Stretched Cluster.

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

Примечание: VCF Lab Constructor не поддерживается VMware как официальный продукт, это что-то похожее на VMware Flings. Вы также можете присоединиться к каналу поддержки VLC в Slack.

Обзор вложенной среды

Конфигурация "VLC Holodeck Standard" является вложенной конфигурацией VMware Cloud Foundation, используемой в качестве базовой для нескольких лабораторных упражнений по эксплуатации частного облака, созданных командой технического маркетинга Cloud Foundation. Стандартный "VLC-Holo-Site-1" является основной развертываемой конфигурацией. Дополнительный VLC-Holo-Site-2 может быть развернут в любое время позже в рамках нового Pod. Конфигурация VLC-Holo-Site-1 соответствует лабораторной конфигурации в VCF Hands-On Lab HOL-2246 и вложенной конфигурации в программе VCF Experience, запущенной на платформе лабораторий VMware.

Каждый Pod в развертывании Holodeck работает с идентичной вложенной конфигурацией. Pod может быть развернут с автономной конфигурацией VLC-Holo-Site-1 или же с одновременно активными конфигурациями VLC-Holo-Site-1 и VLC-Holo-Site-2. Разделение подов, а также между сайтами внутри пода, обрабатывается на уровне виртуального коммутатора vSphere Standard Switch (VSS). Каждый Pod Holodeck настроен с уникальным VSS для сайта. Группа портов VMware vSphere настроена на каждом VSS и сконфигурирована как транк VLAN.

• Компоненты в группе портов используют тегирование VLAN для изоляции коммуникаций между вложенными VLAN. Это устраняет необходимость в физических VLAN, подключенных к хосту ESXi для поддержки вложенных лабораторий.
• Когда развертывается конфигурация Holo-Site-2, она использует второй VSS и группу портов для изоляции от Holo-Site-1.
• Конфигурация VLC Holodeck настраивает виртуальную машину VCF Cloud Builder для предоставления нескольких сервисов поддержки внутри пода, чтобы не требовать дополнительных сервисов со стороны клиента. VM Cloud Builder развертывается на сайт для предоставления следующих услуг внутри пода:
  • DNS (локально для Site1 и Site2 внутри пода, действует как промежуточный узел).
  • NTP (локально для Site1 и Site2 внутри пода).
  • DHCP (локально для Site1 и Site2 внутри пода).
  • L3 TOR для сетей vMotion, vSAN, управления, Host TEP и Edge TEP в каждом сайте.
  • BGP-пир с VLC Tier 0 NSX Application Virtual Network (AVN) Edge (обеспечивает подключение к оверлей-сетям NSX из лабораторной консоли).

На рисунке ниже показан логический вид конфигурации VLC-Holo-Site-1 внутри Pod Holodeck. Конфигурация Site-1 использует домен DNS vcf.sddc.lab и VLAN 10-15.

Пакет Holodeck также предоставляет предварительно настроенную виртуальную машину Photon OS, называемую "Holo-Router", которая функционирует как виртуализированный маршрутизатор для базовой среды. Эта ВМ позволяет соединять вложенную среду с внешним миром. Holo-Router настроен на перенаправление любого трафика Microsoft Remote Desktop (RDP) к вложенному jump-хосту, известному как Holo-Console, который развертывается внутри пода.

Интерфейс пользователя для вложенной среды VCF предоставляется через виртуальную машину Windows Server 2019 "Holo-Console". Holo-Console предоставляет место для управления внутренней вложенной средой, подобно рабочему столу системного администратора в центре обработки данных. Holo-Console используется для запуска пакета VLC для развертывания вложенного экземпляра VCF внутри пода. Виртуальные машины Holo-Console развертываются из специально созданного ISO, который настраивает следующее:

1. Microsoft Windows Server 2019 Desktop Experience, имеющий на борту:

• Домен Active directory "vcf.holo.lab"
• DNS-форвардер к Cloud Builder
• Сервер сертификатов, Web Enrollment и шаблон сертификата VMware
• Включенный RDP
• Настроенный IP, подсеть, шлюз, DNS и VLAN для развертывания как Holo-Console
• Отключенный брандмауэр и улучшенная безопасность IE
• Настроенное рабочее окружение SDDC Commander

2. Дополнительные программные пакеты, развернутые и настроенные:

• Google Chrome с закладками Holodeck
• VMware Tools
• VMware PowerCLI
• VMware PowerVCF
• VMware Power Validated Solutions
• Клиент PuTTY SSH
• VMware OVFtool

3. Дополнительные программные пакеты, скопированные в Holo-Console для последующего использования:

• VMware Cloud Foundation Cloud Builder OVA в C:\CloudBuilder.

4. VCF Lab Constructor 5.0 с двойной конфигурацией Holodeck:

• C:\VLC\VLC-Holo-Site-1
• C:\VLC\VLC-Holo-Site-2

5. VMware vRealize Automation 8.10 Easy Installer

На рисунке ниже показаны виртуальные машины, работающие на физическом хосте ESXi для предоставления пода Holodeck под названием "Holo-A". Обратите внимание на экземпляры Holo-Console, Holo-Router, Cloud Builder и четыре вложенных хоста ESXi. Они все общаются через группу портов VLC-A-PG.

Добавление второго сайта включает дополнительный экземпляр Cloud Builder и дополнительные вложенные хосты ESXi. VLC-Holo-Site-2 подключается ко второй внутренней линии Holo-Router на VLAN 20. Доступ в сеть из Holo-Console к VLC-Holo-Site-2 осуществляется через Holo-Router.

На рисунке ниже показан логический вид конфигурации VLC-Holo-Site-2 внутри пода Holodeck. Конфигурация Site-2 использует домен DNS vcf2.sddc.lab и VLAN 20-25.

Доступ к среде Holodeck

Доступ пользователей к поду Holodeck осуществляется через Holo-Console. Доступ к Holo-Console возможен двумя способами:

1. Подключение через Microsoft Remote Desktop Protocol (RDP) к внешнему IP Holo-Router. Holo-Router настроен на перенаправление всего RDP-трафика к экземпляру Holo-Console внутри пода:

• Клиент Microsoft Remote Desktop для Mac
• Клиент Remote Desktop для Windows (доступен в Microsoft Store)

2. Доступ к Holo-Console через хост ESXi:

• Консоль браузера (встроенная в клиент vSphere)
• VMware Remote Console (требуется вход в VMware Customer Connect)

Предварительные требования для развертывания VLC Holodeck

Размер хоста ESXi:

• Good (один под): Один хост ESXi с 16 ядрами, 384 ГБ памяти и 2 ТБ SSD/NVME
• Better (два пода): Один хост ESXi с 32 ядрами, 1024 ГБ памяти и 4 ТБ SSD/NVME
• Best (четыре или более подов): Один хост ESXi с 64+ ядрами, 2.0 ТБ памяти и 10 ТБ SSD/NVME

Конфигурация хоста ESXi:

• vSphere 7.0U3 или 8.0
• Виртуальный коммутатор и группа портов, настроенные с подключениями к сети клиента/интернету
• Поддерживается автономный хост, не управляемый сервером vCenter, и одноузловой кластер, управляемый экземпляром сервера vCenter
• Кластеры с несколькими хостами НЕ поддерживаются в этом выпуске из-за требования физической поддержки VLAN

Хост Holo-Build:

• Хост Windows 2019 или VM с локальным доступом к хостам ESXI, используемым для Holodeck + доступом в интернет для загрузки программного обеспечения. (Этот пакет был протестирован только на Microsoft Windows Server 2019)
• 200 ГБ свободного дискового пространства
• Действительный вход в CustomerConnect
• Лицензия на VCF 4.5 или 5.0 Enterprise для минимум 8 хостов (16 хостов, если планируется тестирование Cloud Foundation Multi region с NSX Federation)

Ключи лицензий для следующих компонентов VCF 4.5 или 5.0 (на данный момент Toolkit Holodeck не поддерживает подписочные лицензии):

• VMware Cloud Foundation
• VMware NSX-T Data Center Enterprise
• VMware vSAN Enterprise
• VMware vSphere Enterprise Plus
• VMware vCenter Server (одна лицензия)
• VMware vRealize Suite Advanced или Enterprise (теперь это VMware Aria Suite)

Требуемые внешние/клиентские сети:

• IP-адрес управления хоста ESXi (один на хост)
• Адрес Holo-Router на под

Требуемое программное обеспечение (ссылки и инструкции есть в модуле создания пользовательского ISO Holodeck):

• Microsoft Server 2019 Desktop Experience (Eval копия с истечением срока действия через 6 месяцев)
• Свежий пакет VMware VMTools
• Отдельная установка Google Chrome
• Последний архив VMware PowerCLI
• Свежий архив VMware PowerVCF
• Свежий модуль VMware Power Validated Solutions Module
• Свежий MSI клиента PuTTY SSH
• Свежий VMware OVFtool (требуется вход в CustomerConnect)
• VMware Cloud Foundation 4.5 или 5.0 Cloud Builder OVA (требуется вход в CustomerConnect)
• Архив VLC holodeck-standard-main zip - включает VCF Lab Constructor, Holo-Router.ova, скрипты автоматизации поддержки Holodeck и руководства по развертыванию в файле holodeck-standard-main.zip
• Notepad ++ 8.4.7
• VMware vRealize Automation 8.11.2 Easy Installer (требуется вход в CustomerConnect) - эта лаборатория разработана для работы только с VMware vRealize Automation 8.11.2.

Полезные ссылки

• Holodeck 2.0 Setup
• SDDC Manager Operations
• Software-Defined Networking
• Cloud Operations
• Tanzu Operations
• Exploring Holodeck

VMware Cloud Foundation 5.1 и vSAN 8 Update 2 вносят новые улучшения в архитектуру хранения данных vSAN Express Storage Architecture (ESA), которые помогают лучше понять потребление емкости в кластерах.

Часто задаваемые вопросы администраторов

Когда речь идет о хранении данных, основные вопросы, которые задают себе архитекторы центров обработки данных - это "сколько емкости хранения я купил?", "сколько я использую?" и "сколько у меня осталось?". Хотя ответы кажутся очевидными, системы хранения данных часто полагаются на множество способов обеспечения надежности данных и часто используют возможности повышения эффективности использования пространства, что иногда может затруднить ответы на эти вопросы.

Стек хранения данных ESA обрабатывает и хранит данные иначе, чем Original Storage Architecture (OSA). В результате, его накладные расходы на хранение метаданных, файловых систем и необходимая емкость для обеспечения надежности хранения основных данных на случай сбоя также отличаются. Недавние улучшения в vSAN 8 U2 и VMware Cloud Foundation 5.1 включают изменения в пользовательском интерфейсе, которые позволяют лучше учитывать эти накладные расходы. Эти улучшения упрощают понимание потребления емкости. Давайте посмотрим, что изменилось и рассмотрим пример использования емкости хранения для ESA.

Пример потребления храненилищ в ESA

Кластер в примере ниже состоит из 8 хостов ESXi, работающих на платформе vSAN 8 U2. Каждый хост оснащен четырьмя устройствами хранения емкостью 1.6 ТБ, обеспечивая чуть менее 6 ТБ на хост или примерно 47 ТБ для кластера. В этом кластере ESA работает около 100 виртуальных машин, каждой из которых назначена специфичная для кластера политика хранения данных по умолчанию с RAID-6 под управлением функции автоматического управления политиками vSAN ESA. Также там включена функция возврата пространства хранилищ TRIM/UNMAP vSAN. Для ясности, в этом кластере не включены механизмы управления емкостью операционного резерва и резерва восстановления хоста (Operation's Reserve и Host Rebuild Reserve). Хотя этот пример использует кластер в варианте развертывания vSAN HCI, результаты будут такими же, как и в кластере, работающем на vSAN Max.

vSAN представляет емкость кластера на странице Summary, которая делится на два раздела. Раздел "Capacity Overview" показывает, сколько доступной емкости используется, а "Usage breakdown" подробно описывает тип данных, в настоящее время хранящихся в кластере.

Представление Capacity Overview

В этом примере пользовательский интерфейс показывает, что кластер предоставляет 46.57 ТБ отформатированной сырой емкости. Маленькая вертикальная линия на графике обзора емкости представляет "порог операций" (operations threshold), который отражает рекомендуемый лимит потребления емкости (в данном случае - 38.27 ТБ), который обеспечивает операционную деятельность vSAN.

Хотя на кластере хранится почти 31 ТБ данных гостевых виртуальных машин, метаданных объектов и снимков, фактически используемая емкость составляет 17.69 ТБ после учета сжатия данных, что экономит 13.70 ТБ. Сжатие данных в ESA гораздо лучше, чем в OSA, но, конечно, коэффициенты сжатия, которых вы достигнете, будут полностью зависеть от типа данных, хранящихся в вашей среде.

Представление Usage breakdown

В разделе "Usage breakdown" подробно описывается распределение данных после сжатия, исключая свободную емкость. Нововведением в vSAN 8 U2 и VMware Cloud Foundation является значение "ESA object overhead" в категории "System usage". Она отображает метаданные, создаваемые в отношении объекта и реплицированных данных. В этом примере оно составляет около 11.96% от хранимых данных. Указанные накладные расходы объекта ESA рассчитываются после сжатия данных, так что чем лучше сжатие, тем меньше необходимо накладных расходов.

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

Результат

Этот конкретный пример демонстрирует, что ESA, даже после учета различных накладных расходов, может защищать данные с высоким уровнем устойчивости (FTT=2) таким образом, что практически все накладные расходы на отказоустойчивость и метаданные компенсируются. В этом примере на кластере, который предоставляет около 46 ТБ сырой емкости, было примерно 15 ТБ данных гостевых виртуальных машин, которые после учета накладных расходов и сжатия потребовали около 17,7 ТБ сырого хранилища. Предполагая тот же уровень сжатия для новых данных, можно было бы хранить еще 15 ТБ дополнительных данных в высокоустойчивом виде и оставаться в пределах базового порога операций для кластера в 38.27 ТБ.

По сравнению с OSA, ESA обеспечивает более высокую устойчивость (поскольку большинство клиентов используют менее устойчивый FTT=1 вместо FTT=2 на OSA), гораздо более высокую производительность и улучшенную эффективность использования пространства для снижения затрат. Intel недавно опубликовала материал, который подтверждает это мнение: "Beyond Savings:  How Server Consolidation with VMware vSAN 8 Boosts Performance by more than 7.4x!". И в отличие от традиционного модульного массива хранения, вы получаете полностью распределенную систему хранения, которую можно масштабировать постепенно и экономично, используя ваши любимые серверы.

Оценка требований к хранению данных

Как вы можете применить эти знания при планировании собственной среды? Утилита vSAN ReadyNode Sizer делает все расчеты необходимой емкости за вас. На рисунке ниже показано, что когда введены спецификации серверов и коэффициенты сжатия, чтобы они соответствовали этому кластеру, оценки емкости оказываются очень похожими.

Недавно компания VMware выпустила новую версию решения VMware Aria Operations for Networks 6.12. Напомним, что этот продукт сменил средство vRealize Network Insight (vRNI) в рамках большого ребрендинга и перепаковки линейки vRealize. vRNI - это платформа для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре. О прошлой версии Aria Operations for Networks 6.11 мы писали вот тут.

В последнем релизе Aria Operations for Networks 6.12 представлено много новых возможностей для обеспечения видимости сети, чтобы помочь пользователям решения VMware Cloud Foundation улучшить производительность сети приложений и устранять проблемы с сетью.

1. Функция Network Map Scope - область видимости сети

Корпоративные сети обширны и сложны, поэтому важно сузить круг устройств, которые могут быть отображены в топологии, когда пользователи устраняют конкретные проблемы с сетевым взаимодействием приложений. Видимость масштаба сети позволяет пользователям создавать визуальную карту области сети для конкретных типов устройств, чтобы лучше понять, где могут возникать проблемы. К типам устройств, которые могут быть включены в область, относятся как физические, так и виртуальные объекты, такие как узлы NSX Host Transport Nodes и NSX Edge Transport Nodes, хосты vCenter, коммутаторы, маршрутизаторы, брандмауэры, балансировщики нагрузки, блейд-серверы и расширители фабрик.

2. Тэги для устройств

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

3. API и Databus

Для качественного устранения неполадок и анализа их причин в средах NSX были представлены несколько API NSX и vCenter для databus, которые будут извлекать метрики через NSX Edge, хост vCenter и кластер хостов vCenter. Примерами улучшенной видимости сети являются метрики хоста vCenter, такие как usage, transmission и drop rate.

4. Сохранение изменений в таблицах и виджетах

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

5. Уведомления по почте о закрытии алертов

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

Более подробно о VMware Aria Operations for Networks 6.12 можно прочитать в Release Notes, а также на странице продукта.

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

VMware предлагает предприятиям готовые возможности, чтобы удовлетворить потребности современного бизнеса за счет новых функций в решениях VMware Cloud Disaster Recovery и VMware Ransomware Recovery. VMware Ransomware Recovery for VMware Cloud Disaster Recovery предлагает уверенное восстановление от критических угроз, быстрое восстановление с помощью управляемой автоматизации и упрощенные операции восстановления. Это полностью управляемое решение Ransomware Recovery as-a-Service, которое позволяет безопасно восстанавливаться от современных программ-вымогателей через поведенческий анализ включенных рабочих нагрузок в изолированной среде восстановления (IRE) в облаке.

На днях компания VMware выпустила обновленную версию Cloud Disaster Recovery с функциями Ransomware Recovery. Давайте посмотрим, что нового стало доступно пользователям в этом феврале:

1. 15-минутное RPO с частыми снимками

Потеря доступа организации к некоторым (или всем) данным может обойтись в миллионы упущенной выручки, повреждении репутации бренда и штрафах за несоблюдение нормативных требований - и это лишь некоторые из возможных последствий. По этой причине минимизация потерь данных при восстановлении давно является ключевой задачей, особенно в крупных организациях или в сильно регулируемых отраслях. Чтобы решить эту важную проблему, VMware Cloud DR и VMware Ransomware Recovery теперь поддерживают 15-минутное RPO (требование к контрольной точке восстановления), которое предоставляет клиентам большую гибкость и выбор. Эта техника позволяет делать до 96 снимков в день и поддерживает приостановку работы приложений для обеспечения их согласованности. В сочетании с глубокой историей неизменяемых точек восстановления, сохраненных в Cloud Filesystem, это предоставляет клиентам больший выбор в частоте и политиках хранения снимков. Такая гибкость важна для достижения баланса между готовностью к восстановлению и общей стоимостью владения инфраструктурой.

2. Запуск рабочих нагрузок в облаке

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

3. Transit Connect для репликации, переключения на резерв и возврата к исходному сайту

Расширенная поддержка Transit Connect обеспечивает улучшенную безопасность сети для клиентов, которые не могут передавать данные по общедоступным сетям из-за требований комплаенса или просто желают минимизировать риски передачи. С этим улучшением передача данных для репликации, переключения на резерв (failover) и возврата (failback) осуществляется через защищенную частную сеть, полностью изолированную от общедоступного интернета. Трафик автоматически шифруется в состоянии покоя и в процессе передачи, а правила брандмауэра на облачном шлюзе в сочетании со списками доступа на стороне VMware Cloud DR добавляют слой безопасности.

4. Улучшенное сетевое подключение

VMware Cloud DR и VMware Ransomware Recovery теперь позволяют клиентам изолировать DR-сеть от той, что используется для тестирования и восстановления. Наличие DR-сети, полностью отделенной от сети изолированной среды восстановления (Isolated Recovery Environment, IRE), предотвращает перемещение киберугроз в SDDC-датацентр восстановления, которые могли бы заразить рабочие нагрузки, если они работают в одной и той же среде. Сегментация сети, создаваемая на уровне NSX в резервном SDDC, теперь является опцией конфигурации плана DR. VMware Cloud DR и VMware Ransomware Recovery будут использовать NSX Compute Gateway для указания отдельных сетей, что позволяет операциям DR и восстановления проводиться одновременно и безопасно в одном и том же SDDC. Это также позволяет клиентам консолидировать инфраструктуру сайта восстановления без риска заражения рабочих нагрузок.

Более подробно о новых возможностях VMware Cloud Disaster Recovery можно прочитать в Release Notes.

Почти два года назад мы писали о решении Cloud Flex Storage, которое представляет собой распределенное хранилище и средства управления данными, полностью управляемые со стороны VMware. Это комбинация cloud-native абстракций, реализующих службы хранения для клиентов, которая предоставляет высокопроизводительные сервисы для современных нагрузок.

С помощью VMware Cloud Services Console пользователи могут масштабировать облачные хранилища без необходимости добавления дополнительных хостов и регулировать доступные емкости как вверх, так и вниз, для каждого из работающих приложений. Также здесь работает модель оплаты по мере потребления ресурсов (pay-as-you-go).

Когда VMware впервые представила Cloud Flex Storage на мероприятии VMware Explore 2022, основной целью было предоставить решение для управления данными и облачным хранилищем уровня предприятия. С тех пор компании разных размеров уже внедрили Cloud Flex Storage для легкого масштабирования хранилищ без добавления хостов, что для многих из них привело к значительной экономии средств. Теперь, с улучшениями, которые были представлены недавно, существенно расширен спектр поддерживаемых рабочих нагрузок, включая критически важные задачи. Основные направления развития продукта - это увеличение масштабируемости сервиса и укрепление его устойчивости.

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

1. Увеличенная масштабируемость: расширение объема облачного хранилища с эластичным ростом

В этом обновлении VMware Cloud Flex Storage теперь предоставляется дизагрегированное хранилище уровня петабайтов на платформе VMware Cloud on AWS. VMware удвоила доступную емкость на одном хранилище с 400 ТБ до 800 ТБ. Кроме того, теперь поддерживаются до 4 хранилищ на одном SDDC, что позволяет клиентам использовать до 3.2 петабайт хранилища в одном SDDC.

2. Повышение устойчивости: обеспечение производительности для критических приложений

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

За подробностями о нововведениях технологии VMware Cloud Flex Storage вы можете обратиться к этой странице.

В блоге VirtualPad появилась интересная статья о технологии VMware vSAN Encryption. Шифрование vSAN поддерживает и гибридные, и All-Flash кластеры vSAN. Это относится к архитектуре OSA, поскольку ESA поддерживает только All-Flash для всего пула хранения.

Сейчас поддерживаются следующие методы шифрования vSAN: шифрование данных в состоянии покоя (Data-at-Rest Encryption) и шифрование данных в процессе передачи (Data-in-Transit Encryption). Оба конфигурируются независимо друг от друга и на уровне кластера. vSAN OSA выполняет шифрование на уровне всего кластера. Архитектура HCI Mesh не поддерживает шифрование данных в состоянии покоя.

Шифрование данных в процессе передачи (Data-in-Transit)

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

Процесс шифрования трафика между узлами в кластере vSAN можно свести к трем основным шагам:

• Создается TLS-соединение между узлами vSAN для обмена трафиком
• Узлы vSAN создают общий пароль (secret) и прикрепляют его к текущей сессии
• Общий секрет используется для установления сессии шифрования с аутентификацией между узлами

Шифрование данных в состоянии покоя (Data-at-Rest)

Шифрование данных в состоянии покоя vSAN надежно шифрует данные vSAN с использованием AES-256, когда они записываются на кэш и устройства емкости. При использовании этого метода мы получаем следующее:

• Шифруются данные, находящиеся на устройствах кэша и дисковой емкости
• Поддерживаются конфигурации All-Flash и Hybrid
• Исключается необходимость в самошифрующихся дисках
• Проверено на соответствие FIPS 140-2

Разумеется, выбор шифрования данных в состоянии покоя требует либо сервис управления ключами (Key Manager Service, KMS), либо собственного провайдера ключей vSphere (Native Key Provider, NKP) и конфигурируется на уровне кластера.

Шифрование данных vSAN в состоянии покоя (D@RE) помогает защищаться от ситуаций потери или кражи устройства. Шифрование D@RE в vSAN работает отдельно от шифрования виртуальных машин vSphere (VM Encryption).

Шифрование D@RE в vSAN является процессом реального времени, который шифрует данные до того, как они попадают на диск. Данные никогда не хранятся на диске в незашифрованном состоянии. Если в среде используется дедупликация и сжатие или только сжатие, шифрование происходит после операций дедупликации и сжатия или только сжатия, что позволяет клиенту использовать преимущества экономии места перед шифрованием. Когда данные читаются, они расшифровываются в процессе передачи и возвращаются в гостевую операционную систему. Ну а данные на диске остаются в зашифрованном состоянии.

С выходом обновленной версии VMware vSAN 8 в этом решении появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

Дункан Эппинг в ответ на запрос пользователей решения vSAN ESA сделал интересный пост на тему минимально необходимого числа хостов, которое требуется для поддержания определенного уровня избыточности - RAID-0/1/5/6.

В VMware vSAN 8 Update 1 появился адаптивный алгоритм записи, который существенно уменьшает избыточность записи на RAID-конфигурации. Когда мы рассматриваем, куда записываются данные по умолчанию используя путь записи ESA для объекта, использующего erasure codes для RAID-6, это уменьшает избыточность записи данных с 4,5x (3x для тройного зеркала + 1,5x для полосы RAID-6 4+2 с двойной паритетной проверкой) до всего лишь 1,5x. Это не только сокращает объем вычислений в процессорах, но и уменьшает сетевой трафик. Этот новый адаптивный путь записи приводит к большему объему передачи данных для всех рабочих нагрузок, которые склонны генерировать большие размеры I/O или большое количество ожидающих операций, создавая ситуации, обычно называемые большим количеством необработанных операций ввода-вывода (high outstanding I/O).

Теперь для vSAN ESA на базе RAID-5, в зависимости от размера кластера, могут быть использованы конфигурации 2+1 или 4+1, а конфигурация 3+1 больше не поддерживается. При этом для RAID-1 и RAID-6 в конфигурациях ничего не изменилось.

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

Когда мы рассказывали о нововведениях в продуктовой линейке VMware на 2024 год, мы упоминали, что компания в составе Broadcom решила полностью перейти на модель подписки на свои продукты (VMware Cloud Foundation и VMware vSphere Foundation), исключив "вечные" (perpetual) лицензии и поддержку. Также к этим продуктам можно докупать аддоны, которые лицензируются отдельно, в зависимости от типа аддона.

На днях VMware объявила об этом официально. Подробную информацию о данном переходе можно найти в KB 96168.

Кроме того, VMware от Broadcom также планирует предложить возможность использовать уже имеющиеся купленные лицензии в рамках программы Bring Your Own License, которая позволит клиентам получать новые подписки на VMware Cloud Foundation от Broadcom и гибко использовать эти подписки в проверенных гибридных облачных средах VMware, а также в собственных локальных датацентрах.

Еще одним результатом этого перехода является то, что продукты, перечисленные в таблице ниже, теперь находятся на стадии снятия с производства (End of Availability, EOA) в качестве отдельных продуктов. Некоторые предложения все еще могут быть доступны для использования в рамках решений VMware Cloud Foundation (VCF) или VMware vSphere Foundation (VVF), что отмечено отдельно.

VMware также объявляет об окончании доступности (EOA) услуг Aria SaaS, но продолжит поддерживать клиентов, в настоящее время использующих эти услуги, до конца срока их подписки. По истечении срока подписки клиентам нужно будет перейти на использование либо VCF, либо VVF. Также обратите внимание, что услуги Aria SaaS находятся в режиме maintenance mode, что означает, что новые функции не будут доступны, хотя обновления безопасности и критические обновления будут предоставляться в течение активного периода подписки.

Это объявление охватывает все варианты лицензирования, включая Perpetual, поддержку и подписку (Support & Subscription, SnS), SaaS/хостинг и другие типы подписок. Оно также касается каждого издания, пакета и модели ценообразования для каждого продукта. Любое исключение из этого правила будет указано отдельно.

Эта таблица позволит вам понять сущность перехода от старых продуктов на новые:

Обратите внимание, что бесплатного решения VMware ESXi (vSphere Hypervisor) больше нет! За все надо платить)

Если вы являетесь существующим клиентом и приобрели продукты, которые сейчас находятся на стадии окончания доступности (End of Availability), но ваша подписка пока не подлежит обновлению, в настоящее время никаких немедленных действий не требуется. VMware будет продолжать предоставлять активную поддержку на протяжении всего срока вашего договора поддержки. В будущем, в момент обновления подписки, вы можете работать со своим представителем или партнером VMware, чтобы согласовать ваши дальнейшие требования с обновленным портфелем предложений VMware.

В продукт VMware Skyline Advisor Pro, предназначенный для генерации умных проактивных рекомендаций (Findings), новые фичи добавляются каждый месяц (правда, в последний раз мы писали несколько месяцев назад об этом тут). Результаты приоритезируются на основе актуальных проблем при обращениях в техническую поддержку VMware, особенностей, выявленных в процессе обзора работы с тикетами, уязвимостей безопасности, проблем, выявленных инжиниринговой командой VMware, а также улучшений предлагаемых клиентами.

В январе было выпущено 60 новых рекомендаций. Из них 37 основаны на текущих проблемах, 9 - на обзорах после работы с тикетами, 1 - на основе рекомендаций безопасности VMSA и 12 - на основе предложений пользователей. В VMware выбрали несколько из этих результатов, которые наиболее ценны в этом релизе - приведем их ниже.

Уязвимости безопасности

В критическом патче VMSA-2024-0001 обновления VMware Aria Automation (ранее известного как vRealize Automation) решают проблему отсутствия контроля доступа (CVE-2023-34063). Аутентифицированный злоумышленник может использовать уязвимость так, что это приведет к несанкционированному доступу к удаленным организациям и рабочим процессам. Эта проблема была устранена в Aria Automation 8.16. Также доступны постпатчи для Aria Automation 8.11.2, 8.12.2, 8.13.1 и 8.14.1, которые будут добавлены в VMware Skyline Advisor Pro в будущем.

Обзор после эскалации тикетов

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

В KB 95965 для vSphere 8.0 Update 2 файлы Changed Block Tracking (CBT) могут стать несогласованными, что может привести к неправильной записи резервных копий. Эта проблема проявляется только при создании резервных копий после расширения диска ВМ в горячем режиме. Простое изменение размера диска выключенной машины не вызовет этой проблемы. Ситуация может возникнуть с дисками всех типов хранилищ (VVOL, VMFS, NFS, vSAN). Инженеры знают о данной проблеме и активно работают над ее решением. Подпишитесь на статью в базе знаний, чтобы получить уведомление о выходе исправления.

Также в KB 96065 для vCenter Server 8.0 Update 2 при попытке выполнения операций с виртуальными машинами операция висит и завершается после долгого времени или не завершается вовсе. Из-за нечувствительности к регистру символов в полном имени хоста vCenter Server в URL-адресе назначения умных прокси (Envoy sidecar proxy), при использовании верхнего регистра символов в именах хостов vCenter Server получаются висячие вызовы к службе VSM. Инженеры знают о данной проблеме и активно работают над ее решением. Подпишитесь на статью в базе знаний, чтобы получить уведомление о выходе исправления.

Ну и в KB 96049 для vCenter Server 8.0U2 описана проблема, проявляющася при попытке выполнения операций с виртуальными машинами - операция висит и завершается, либо не завершается вовсе. Корневой причиной является отсутствие файлов jar в пакете службы VSM. Инженеры знают о данной проблеме и активно работают над ее решением. Подпишитесь на статью в базе знаний, чтобы получить уведомление, когда будет доступно исправление.

Ну а полный список новых рекомендаций для релиза Skyline Advisor Pro Proactive Findings – January 2024 Edition вы можете посмотреть тут.

На днях компания VMware выпустила обновление продукта Aria Automation 8.16, предназначенного для автоматизации операций виртуальной инфраструктуры VMware vSphere. Напомним, что о возможностях последней облачной версии Aria Automation мы писали вот тут.

В прошлом году завершилось приобретение VMware компанией Broadcom - это объединило две команды, основной упор в работе которых - инженерия и стремление к инновациям. Давайте посмотрим, что нового появилось в первом совместном релизе Aria Automation 8.16:

• Доступ к Публичному API для списка событий IaaS

Теперь доступ к списку событий IaaS доступен для клиентов через API swagger, что облегчает пользователям доступ к этим интерфейсам.

• Применение действий Day-2 на этапе развертывания

Вслед за введением перестройки (rebuild) виртуальных машин как действия Day-2 на уровне ВМ, Aria Automation теперь также поддерживает перестройку виртуальных машин и на этапе развертывания. Пользователи могут инициировать действие Day-2 для перестройки существующего развертывания, выбрать, какие машины перестроить, и сделать это в пакетном режиме. Это усовершенствование экономит время и усилия администраторов.

• Обеспечение возможности ограничения паролей по организациям и проектам

Теперь администраторы облаков могут назначать пароли (secrets) на уровне организации (Org) или ограничивать их несколькими проектами (Projects). Это улучшение добавляет больше гибкости для клиентов при управлении доступом не только на уровне проекта, но и на организационном уровне.

Для получения дополнительной информации о релизе VMware Aria Automation 8.16.0, вы можете ознакомиться с Release Notes.

В сентябре 2023 года VMware объявила о запуске Tanzu Mission Control Self-managed (TMC - SM) - централизованного хаба, специально разработанного для управления несколькими кластерами Kubernetes множества клиентов публичного облака с продвинутыми средствами безопасности для партнеров облачных служб, ориентированных на отрасли, такие как банки, финансы, страхование, здравоохранение и государственный сектор, которые чувствительны к требованиям безопасности данных и регуляторным нормам.

На днях VMware объявила о запуске расширения VMware Cloud Director Extension for Tanzu Mission Control. Сервис-провайдеры могут централизованно управлять и предоставлять целостные, масштабируемые и безопасные службы Kubernetes как платформу для своих арендаторов в регулируемых отраслях, помогая им в их процессах модернизации приложений.

Это новое расширение VMware Cloud Director предназначено для партнеров Sovereign Cloud  Partners и, в первую очередь, интегрируется с VMware Tanzu Mission Control для VMware Cloud Director.

Поставщики суверенных облачных сервисов, предоставляющие большие кластеры Kubernetes (K8s) в рамках инфраструктуры как сервис для выполнения рабочих нагрузок в контейнерах на расширении службы контейнеров VMware Cloud Director, могут теперь централизованно управлять всеми своими кластерами K8s, работающими в изолированной среде, и без проблем применять определенные политики к этим кластерам K8s с использованием расширения VMware Cloud Director для VMware Tanzu Mission Control.

Это дает возможность поставщикам услуг обслуживать сегмент, который сложно обслуживать гигантам в области облачных услуг (например, AWS). Они могут предоставлять полностью управляемые совместимые службы Kubernetes или предоставлять средства самообслуживания опытным пользователям Kubernetes.

Как начать использовать расширение VMware Cloud Director для Tanzu Mission Control? Для начала использования этого продукта партнеру VMware необходимо иметь следующее:

• TMC SM v1.1
• VMware Cloud Director 10.4.3, 10.5.1
• Расширение контейнерных служб VMware Cloud Director 4.2
• Плагин пользовательского интерфейса Kubernetes Container Clusters - 4.2
• Версии TKG: 2.1.1, 2.2, 2.3.1, 2.4

Пользователи могут найти подробное руководство в интерфейсе CSE 4.2 касательно установки TMC Self-Managed и подключения арендаторов к TMC Self-Managed с использованием пользовательского интерфейса VCD.

Для получения дополнительной информации о продукте ознакомьтесь со страницей документации и Release Notes. Вы можете скачать расширение VMware Cloud Director для Tanzu Mission Control по этой ссылке.

В начале 2022 года мы рассказывали о ситуации вокруг продукта VMware vCenter Converter, предназначенного для миграции физических и виртуальных серверов в онпремизную и облачную среду VMware vSphere. На тот момент Converter был убран из списка доступных загрузок из соображений обеспечения совместимости, стабильности и безопасности, так как продукт многие годы не развивался - последний релиз VMware vCenter Converter был от мая 2018 года (там была и его версия VMware Converter Standalone), хотя, по-сути, не обновлялся он несколько лет и до этого.

В октябре 2022 года был впервые выпущен релиз vCenter Converter Standalone 6.3, где было много новых возможностей, необходимость в которых копилась 4 года. В апреле прошлого года VMware выпустила бета-версию vCenter Converter Standalone 6.4, а в мае финальная версия этого продукта стала доступна для загрузки.

На днях VMware выпустила обновленную бета-версию VMware vCenter Converter Standalone 6.6.0 BETA, которая уже доступна для загрузки после регистрации в программе бета-тестирования.

После успеха двух предыдущих версий, которые в сумме набрали более 200 тысяч загрузок, VMware предоставила новую версию этого инструмента. Бета-версия и документация доступны для скачивания на специализированном веб-сайте. Если вы еще не зарегистрировались в программе бета-тестирования vCenter Converter, вы можете сделать это, отправив эту форму.

vCenter Converter 6.6 закрывает важные пробелы с функциональной точки зрения, наконец предоставляя возможность конвертировать нагрузки на основе KVM, включая форматы AHV и RHV. Также поддерживаются RHEL 8 и 9 в качестве исходных ОС, а также последние версии Ubuntu - 22.04 и 20.04.

Новый бета-релиз поставляется с немного обновленным внешним видом в рамках процесса модернизации пользовательского интерфейса продуктов VMware.

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

Запланированная к выпуску версия vCenter Converter 6.6 поддерживает конвертацию нагрузок, основанных на MS Hyper-V, AWS EC2, Nutanix AHV, Red Hat RHV и нативном KVM. Также вы можете проводить конвертацию между виртуальными форматами VMware (Workstation, Fusion) и переконфигурировать виртуальные машины VMware под разные платформы. vCenter Converter поддерживает виртуальные нагрузки, работающие на Windows, Linux Ubuntu, CentOS и Red Hat Enterprise Linux.

В прошлом году мы писали о доступности решения Cloud Director Container Service Extension 4.1 (CSE), которое дает функции по управлению жизненным циклом всех типов кластеров Kubernetes через Cloud Director Cluster API, CLI и Container Service Extension-CLI, а также плагин в графическом интерфейсе. На днях VMware объявила о доступности для загрузки Cloud Director Container Service Extension версии 4.2.

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

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

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

• Добавлена поддержка версий Tanzu Kubernetes Grid (TKG) 2.3.1 и 2.4.0, поддерживающих версии Kubernetes с 1.25.13 до 1.27.5.
• Расширение VMware Cloud Director Container Service теперь совместимо с версиями VMware Cloud Director (VCD) 10.4.3 и 10.5.1.
• Пользователи теперь могут обновить свои существующие кластеры до рекомендуемых версий Kubernetes с помощью обновленного скрипта. См. "Как обновить компоненты Kubernetes в кластерах VMware Cloud Director Container Service Extension".

Еще одно обновление заключается в том, что было представлено расширение VMware Cloud Director для self-managed решения VMware Tanzu Mission Control – эксклюзивный плагин для пользователей VCD, соответствующих требованиям Sovereign compliant, для управления кластерами TKG, развернутыми через CSE.

Эта версия CSE имеет полностью интегрированный пользовательский интерфейс VMware Container Service Extension для облачных провайдеров с подробной инструкцией по установке TMC self-managed и также предоставляет руководство по подключению клиентов облака к TMC self-managed с использованием пользовательского интерфейса VCD.

Для получения дополнительной информации о выпуске обязательно посетите страницу документации продукта и Release Notes. Вы можете скачать последнюю версию расширения VMware Cloud Director Container Service по этой ссылке.

Недавно мы писали об изменениях в лицензионной политике и новых изданиях VMware vSphere, а также в картинках рассказывали о том, какие компоненты являются частью решений, а какие можно приобрести в качестве аддонов. Кроме аддонов, VMware предоставляет сертифицированные решения VMware Validated Solutions (VVS) для инфраструктур VMware Cloud Foundation (VCF).

VMware Validated Solutions - это хорошо спроектированная и проверенная реализация, созданная и протестированная VMware для повышения бизнес-ценности клиентов VMware Cloud Foundation. Это решение для улучшения перехода от только установленного продукта к готовому к использованию. Все VMware Validated Solutions включают структурированный подход к быстрому и эффективному запуску, который включает планирование и подготовку, цели и решения проектирования, реализацию, операционное руководство и руководство по взаимодействию решений. Кроме того, многие из решений предлагают возможность развертывания большей части продуктов средствами автоматизации.

Что такое Cloud-Based Ransomware Recovery for VMware Cloud Foundation?

VMware Ransomware Recovery for VMware Cloud Disaster Recovery предлагает уверенное восстановление от критических угроз, быстрое восстановление с помощью управляемой автоматизации и упрощенные операции восстановления. Это полностью управляемое решение Ransomware Recovery as-a-Service, которое позволяет безопасно восстанавливаться от современных программ-вымогателей через поведенческий анализ включенных рабочих нагрузок в изолированной среде восстановления (IRE) в облаке. Управляемая автоматизация рабочего процесса позволяет клиентам быстро идентифицировать потенциальные точки восстановления, проверять точки восстановления с помощью живого поведенческого анализа и предотвращать повторное заражение благодаря возможностям сетевой изоляции.

Основные проблемы, с которыми сталкиваются организации при восстановлении после атак программ-вымогателей:

1. Определение нужной точки восстановления
2. Проверка найденных точек восстановления
3. Предотвращение повторного заражения
4. Минимизация потери данных
5. Минимизация простоя

Cloud-Based Ransomware Recovery for VMware Cloud Foundation - это хорошо спроектированное проверенное решение, которое направлено на решение этих проблем путем предоставления подробных рекомендаций по проектированию, реализации, конфигурации и эксплуатации защиты рабочих нагрузок бизнеса, работающих в экземпляре VMware Cloud Foundation, от атак программ-вымогателей, за счет подключения экземпляра к VMware Cloud на AWS с использованием сервиса VMware Cloud Disaster Recovery.

Обзор решения

Cloud-Based Ransomware Recovery для VMware Cloud Foundation подробно описывает архитектурные решения - как и где развертывать DRaaS Connectors, учитывая различные компоненты в сервисе VMware Cloud Disaster Recovery и их интеграцию в компоненты среды VMware Cloud Foundation. Это обеспечивает повторяемый процесс, который может быть использован в любой среде VMware Cloud Foundation.

На логической схеме ниже мы используем сервис VMware Cloud Disaster Recovery и активируем регион восстановления, который настраивает оркестратор и облачную файловую систему на VMware Cloud for AWS. Регион восстановления - это место, где мы разворачиваем решение SDDC для восстановления.

Из сервиса VMware Cloud Disaster Recovery мы загружаем и устанавливаем VMware DRaaS Connectors экземпляра VMware Cloud Foundation. Это позволяет сайту VMware Cloud Foundation реплицировать снимки виртуальных машин в облачную файловую систему. Количество необходимых VMware DRaaS Connectors зависит от количества виртуальных машин, которые вы хотите защитить в вашем окружении VMware Cloud Foundation.

В процессе восстановления SDDC для восстановления обеспечивает изолированную среду восстановления (IRE) в VMware Cloud for AWS, которая позволяет вам осматривать, анализировать и восстанавливать зараженные виртуальные машины перед их возвращением в производственную среду.

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

Решение Cloud-Based Ransomware Recovery for VMware Cloud Foundation доступно уже сейчас.

Не секрет, что решение ChatGPT прочно вошло в ежедневный набор инструментов ИТ-специалистов, особенно разработчиков ПО. Администраторы VMware vSphere - не исключение, ведь им часто приходится разрабатывать сценарии на базе различных фреймворков и SDK, что часто включает в себя шаблонные задачи, которые вполне можно автоматизировать средствами ChatGPT.

Эрик Слуф недавно занялся этим вопросом. Начал он со следующего промта:

Could you develop a Python script for VMware vCenter to retrieve the virtual machines and allow the user to control their power states? The server details are: host name 'vc.ntpro.local', username 'administrator@ntpro.local', password 'VMware1!' Please ignore certificate errors and use tls.

Ответ ChatGPT оказался продуктивным, с рекомендацией использовать библиотеку pyvmomi для взаимодействия с VMware vCenter. Он дал совет установить библиотеку pyvmomi через pip, если это еще не сделано. Полный код на Python можно найти по этой ссылке.

Для управления проектами на Python можно использовать PyCharm Community Edition. Модуль pyvmomi важен для подобных задач и может быть удобно установлен через терминал с помощью команды pip install pyvmomi. PyCharm также предлагает графический интерфейс для работы с пакетами Python.

После создания нового файла Python вставьте скрипт, предоставленный ChatGPT, в редактор PyCharm. Для выполнения могут потребоваться некоторые корректировки, такие как обновление версий TLS. Если возникнут ошибки, ChatGPT можно использовать для устранения неполадок и поиска новых решений. Как только усовершенствованный скрипт будет реализован, он сможет успешно извлекать и управлять состояниями питания виртуальных машин из vCenter.

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

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

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

Итак, самое младшее решение для малого бизнеса - VMware vSphere Essentials Plus Kit (VVEP):

Решение для малого и среднего бизнеса - VMware vSphere Standard (VVS):

Флагманская онпремизная платформа - VMware vSphere Foundation (VVF):

Флагманская облачная платформа с максимальным числом дополнительных продуктов - VMware Cloud Foundation (VCF):

Ну и сертифицированные решения VMware Validated Solutions (VVS) для инфраструктур VMware Cloud Foundation (VCF):

Спасибо Сергею за ссылку на статью Вильяма.

Компания VMware выпустила очень интересную лабораторную работу для самостоятельного изучения расширенных тем, касающихся решения для создания отказоустойчивых кластеров VMware vSAN. В рамках практических заданий лабы VMware vSAN - Advanced Topics (HOL-2409-32-HCI) вы узнаете, как настроить vSAN для предоставления файловых сервисов, как vSAN может делить свою емкость с другими кластерами, и исследуете повышенную доступность, которую предлагает растянутый кластер.

Основные темы:

• Услуги по работе с файлами (30 минут) - настройте vSAN для активации общих ресурсов NFS/SMB для предоставления услуг по работе с файлами конечным пользователям и приложениям.
• Модель гиперконвергентной инфраструктуры HCI (также 30 минут) - позвольте vSAN делить свою емкость с другими кластерами vSphere/vSAN.
• Архитектура растянутого кластера vSAN Stretched Cluster (время определяется самостоятельно) - повысьте доступность за счет распределения кластера vSAN между географически разнесенными порщадками.

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

Основная ссылка для начала работы - HOL-2409-32-HCI. Если вы только начинаете знакомство с VMware vSAN, то вам подойдет лабораторная работа VMware vSAN - Getting Started (HOL-2409-31-HCI).

Android 14, выпущенный в октябре прошлого года, получил ряд улучшений в области работы функций Android Enterprise. В этой версии ОС появились новые возможности для лучшей защиты устройств в корпоративной среде и улучшения пользовательского интерфейса рабочего профиля. Также в Android 14 была добавлена поддержка управления финансируемыми устройствами (financed devices). Сегодня мы поговорим о том, какие нововведения появились в работе клиентов VMware Workspace ONE на Android 14 (также посмотрите нашу статью об управлении такими устройствами через интерфейс AMAPI).

Функции безопасности

Android 14 представляет несколько новых возможностей, которые организации могут использовать для лучшей защиты своих устройств и обеспечения соответствия их корпоративным политикам. Первая из них - возможность блокировать использование устройствами сотовых сетей 2G. Сети 2G имеют ряд известных уязвимостей и используют слабое шифрование по современным меркам. Android 14 также позволяет организациям отключать сверхширокополосные (UWB) сети, которые становятся популярными для определения местоположения удаленных устройств и для разблокировки умных автомобилей и домов.

Со стороны приложений Android 14 позволяет администраторам устанавливать список разрешенных программ в личном профиле, которые могут получать доступ к рабочим контактам. Администраторы также могут предотвратить незащищенное использование корпоративных учетных данных, указав, каким приложениям для управления учетными данными разрешается использование API Android Credential Manager.

Улучшения пользовательского интерфейса рабочего профиля

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

Android 14 также лучше определяет, какое приложение должно открывать ссылку. В предыдущих версиях Android, если пользователь открывал ссылку на нативное приложение, например Google Maps, и это приложение было установлено только в личном профиле, ссылка вместо этого автоматически открывалась в браузере рабочего профиля. Теперь с Android 14 пользователи сначала будут спрашивать, хотят ли они открыть ссылку в нативном приложении в личном профиле, а не автоматически предлагать худший опыт, открывая в браузере. Однако пользователи все равно будут иметь возможность открыть ссылку в рабочем браузере.

Поддержка финансируемых устройств

Исторически некоторые финансируемые устройства Android не поддерживали решения для управления устройствами, такие как Workspace ONE Unified Endpoint Management (UEM). Это происходит, когда финансирующая сторона устанавливает на устройство приложение, например, Google Device Lock Controller. Эти приложения, также называемые агентами финансовых киосков, используют те же API управления устройствами, что и решения типа Workspace ONE UEM. Это позволяет финансирующим сторонам блокировать устройства и легче их выводить из эксплуатации. Именно из-за использования агентами финансовых киосков API управления устройствами решения типа Workspace ONE UEM не могли перенимать управление устройством.

В Android 14 это изменилось - теперь можно нескольким приложениям выступать в роли агентов управления на одном устройстве. Когда решение UEM и другое приложение применяют противоречивые политики, Android 14 применяет наиболее строгий вариант. Таким образом, агент финансового киоска не сможет убрать ограничения, примененные Workspace ONE UEM.

Для лучшей видимости политик, применяемых организациями, Android 14 позволит решениям UEM:

• Обнаруживать, является ли устройство финансируемым
• Видеть, какие политики применили другие агенты управления устройствами
• Быть уведомленными об изменениях этих политик.

Еще несколько функций и изменений в поведении приложений, введенных с Android 14

• Во время настройки устройства, принадлежащего компании, экран устройства теперь будет оставаться включенным. Это была необязательная конфигурация, введенная в Android 13, и теперь это поведение по умолчанию.
• Появилось несколько улучшений специальных возможностей, включая улучшенное увеличение, нелинейное масштабирование размера шрифта, флэш-уведомления и улучшения для слуховых аппаратов.
• Настройки рабочих приложений обнаруживаются при поиске в разделе Settings.

Workspace ONE UEM имеет поддержку управления устройствами Android 14 в решении Intelligent Hub 23.07. Для получения дополнительной информации о специфических изменениях для предприятий в Android 14, вы можете прочитать статью "Getting Ready for Android 14".

На днях компания VMware выпутсила большое обновление утилиты vSphere Diagnostic Tool версии 2.0.1, которая теперь называется VCF Diagnostic Tool for vSphere (VDT). Напомним, что это python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance, где скрипт и нужно запускать), а также в перспективе это будет работать и в среде VMware ESXi. О предыдущем обновлении vSphere Diagnostic Tool (VDT) мы писали вот тут.

VDT 2 был переписан с нуля с целью эволюции от простой коллекции скриптов на Python к фреймворку для отчётности о состоянии инфраструктуры на основе Python. Новая версия предоставляет библиотеки, которые стандартизируют вывод и формат каждой проверки. Это означает, что скоро будет доступна совместимость с дополнительными продуктами от VMware.

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

• Вывод базовой информации о vCenter
• Проверки SSO (Lookup Service и Machine ID)
• Интеграция с Active Directory
• Сертификаты vCenter
• Функциональность VMdir
  
• Core-файлы
• Использование базы данных vPostgres
• Использование дискового пространства
• Функционирование DNS
• Синхронизация времени и функционирование NTP
• Валидность аккаунта Root
• Службы vCenter
• Проверка механизма VCHA
  
• Функционирование Syslog
• Проверки IWA/AD
• Проверка Local Identity Source

Для начала работы вы можете воспользоваться следующими статьями базы знаний VMware

• Using the VCF Diagnostic Tool for vSphere (VDT) (83896)
• Using the VCF Diagnostic Tool on SDDC Manager (94141)

Скачать VCF Diagnostic Tool for vSphere можно из KB 83896 в правой колонке:

Утилита VDT запускается простой командой из консоли:

При работе скрипта будет запрошен пароль для учетной записи administrator@sso.domain, но и без него многие проверки будут выполнены успешно.

Mateusz Romaniuk написал отличный пост о том, что делать, когда вы провели апгрейд решения для создания отказоуйстойчивых хранилищ с версии VMware vSAN 8 Update 1 на Update 2.

VMware vSphere 8.0 U2 вносит множество улучшений, исправляет несколько проблем и повышает стабильность. После обновления с vSphere 8.0 U1 на U2 происходят также некоторые изменения в vSAN. Если кластер vSAN работает в производственной инфраструктуре, вам необходимо проапгрейдить версию диска, когда вы используете самую новую версию vSphere.

В итоге у вас должна быть версия 19 для формата дисков кластера vSAN (Disk format version):

Итак, сам процесс обновления:

1. В клиенте vSphere выберите ваш кластер vSAN. Перейдите на вкладку Configure и в разделе vSAN выберите Disk Management. Если вы проверите один из хостов ESXi, работающих на vSAN, вы увидите, что текущая версия диска - 18.0.

2. Запустите процедуру предварительной проверки Pre-Check Upgrade, чтобы убедиться, что формат дисков может быть обновлен:

3. Если все в порядке, то нажимайте кнопку Upgrade:

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

5. После апгрейда вы получите уведомление об успешном завершении, а в разделе Disk Management вы можете выбрать хост ESXi и нажать View Disks:

6. Там в разделе Disk group вы и увидите нужную вам информацию - Disk format version: 19

Ну а вот и сами диски дисковой группы: