На прошлой неделе блогер Дункан Эппинг получил вопрос о vSAN Stretched Cluster, который заставил его задуматься. Человек, задавший этот вопрос, рассматривал несколько сценариев отказа, некоторые из которых Дункан уже рассматривал ранее. Вопрос, который ему задали, заключается в том, что должно произойти в следующем сценарии, показанном на диаграмме, когда разрывается связь между предпочтительным сайтом (Site A) и сайтом свидетеля (Witness):

Ответ, по крайней мере, он так думал, был прост: все виртуальные машины продолжат работать, или, иначе говоря, не будет никакого воздействия на работу vSAN. Во время теста, действительно, результат, который он зафиксировал, а также документированный в Stretched Clustering Guide и PoC Guide, был таким же: виртуальные машины продолжали работать. Однако, он обратил внимание, что когда эта ситуация происходит, и действительно связь между сайтом А и Witness теряется, свидетель почему-то больше не является частью кластера, что не то, что ожидалось. Причина, по которой он не ожидал этого, заключается в том, что если произойдет второй сбой, и, например, связь между сайтом А и сайтом B пропадет, это напрямую повлияет на все виртуальные машины. По крайней мере, так он думал.

Однако, когда был вызван этот второй сбой и отключена связь между сайтом А и сайтом В, Дункан увидел, что Witness снова появляется в кластере сразу же, а объекты свидетеля переходят из состояния «absent» в состояние «active», и, что более важно, все виртуальные машины продолжают работать. Причина, по которой это происходит, довольно проста: при запуске такой конфигурации у vSAN есть «leader» и «backup», и они каждый работают в отдельном домене отказа. И лидер, и резерв должны иметь возможность общаться с Witness для корректного функционирования. Если связь между сайтом А и Witness пропадает, то либо лидер, либо резерв больше не могут общаться со свидетелем, и свидетель исключается из кластера.

Так почему же свидетель возвращается к работе, когда вызывается второй сбой? Когда вызывается второй сбой, лидер перезапускается на сайте В (так как сайт А считается потерянным), а резерв уже работает на сайте В. Поскольку и лидер, и резерв снова могут общаться со свидетелем, свидетель возвращается к работе, и все компоненты кластера автоматически и мгновенно восстанавливаются. Это означает, что даже если связь между сайтом А и сайтом В прервана после того, как свидетель был исключен из кластера, все виртуальные машины остаются доступными, так как свидетель снова включается в работу кластера для обеспечения доступности рабочей нагрузки.

Решение VMware Cloud Foundation Instance Recovery предоставляет собой руководство по восстановлению экземпляра VMware Cloud Foundation (VCF) с нуля до полностью работоспособной среды. Процесс включает подробные инструкции по восстановлению всего экземпляра VCF, включая управляющий домен и домены рабочей нагрузки VI, где необходимо восстановить все компоненты.

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

Сценарии использования

Примеры сценариев, когда вам может понадобиться этот процесс:

• Полный сбой площадки
• Восстановление после атаки вредоносного ПО или вымогателей (Ransomware)
• Катастрофическая логическая порча данных

Это особенно важно для отраслей, которые должны соблюдать нормативные требования (такие как Акт о цифровой операционной устойчивости (DORA) в Европейском Союзе).

Немного о DORA

DORA — это регламент Европейского Союза (ЕС), вступивший в силу 16 января 2023 года, который создал обязательную, всеобъемлющую систему управления рисками информационных и коммуникационных технологий (ИКТ) для финансового сектора ЕС.

DORA устанавливает технические стандарты, которые финансовые учреждения и их критически важные поставщики технологий третьих сторон должны внедрить в свои ИКТ системы до 17 января 2025 года.

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

Хотя DORA является европейским регламентом, его действия распространяются на компании, работающие в ЕС, независимо от места нахождения их штаб-квартиры. Более того, DORA является примером регламента, который станет более распространенным в других юрисдикциях в ближайшие годы.

Восстановление экземпляра VCF — это не просто на бумаге

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

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

Краткое описание решения

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

• Перестройка/ребилд хостов VMware vSphere с использованием того же или нового оборудования на основе данных, извлеченных из резервной копии инвентаря VCF SDDC Manager
• Выполнение частичного развертывания VCF
• Восстановление экземпляров VMware vCenter и NSX Manager, а также SDDC Manager
• Реконструкция кластеров vSphere, включая их сетевые конфигурации и настройки
• Восстановление NSX Edges
• Восстановление рабочих нагрузок (виртуальных машин)
• Восстановление настроек рабочих нагрузок (группы DRS, теги vSphere и местоположения инвентаря)

Временная шкала восстановления VMware Cloud Foundation Instance Recovery

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

• 3 домена рабочих нагрузок VI
• Домен VI 1 и домен VI 2 находятся в том же домене единого входа vCenter SSO, что и домен управления. Они находятся в режиме расширенной связи (Enhanced Link Mode, ELM).
• Используется только версия VMware Cloud Foundation 5.x. Домен VI 3 находится в изолированном домене единого входа vCenter (SSO).
• Шаблон восстановления для домена рабочих нагрузок VI в том же домене SSO можно расширить, если к домену управления vCenter подключены дополнительные домены рабочих нагрузок VI.

Автоматизация с помощью PowerShell

Автоматизация представлена в виде модуля PowerShell под названием VMware.CloudFoundation.InstanceRecovery, являющимся комплексным набором командлетов, который упрощает рутинные процессы и уменьшает вероятность ошибок в процессе реконструкции потенциально сложного и большого программно-определяемого центра обработки данных.

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

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

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

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

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

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

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

Известный блоггер Эрика Слуф опубликовал интересное видео, посвященное обеспечению высокой доступности и восстановлению после сбоя в кластере NSX-T Management Cluster.

В этом видео Эрик демонстрирует эти концепции в действии, рассматривая различные сценарии отказов и подробно обсуждая стратегии аварийного восстановления. Вы можете получить копию оригинального файла Excalidraw и презентационные слайды в форматах PDF и PowerPoint на GitHub.

Введение

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

Обзор кластера управления NSX-T

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

Высокая доступность в кластере управления NSX-T

1. Поддержание кворума

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

2. Отказы узлов и их влияние

• Отказ одного узла: кластер продолжает работать нормально с двумя узлами.
• Отказ двух узлов: кластер теряет кворум, интерфейс NSX Manager становится недоступным. Управление через CLI и API также будет невозможно.

Стратегии восстановления

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

1. Развертывание нового управляющего узла

• Разверните новый управляющий узел как четвертый член существующего кластера.
• Используйте команду CLI detach node <node-uuid> или API-метод /api/v1/cluster/<node-uuid>?action=remove_node для удаления неисправного узла из кластера.
• Эту команду следует выполнять с одного из здоровых узлов.

2. Деактивация кластера (по желанию)

• Выполните команду deactivate cluster на активном узле для формирования кластера из одного узла.
• Добавьте новые узлы для восстановления кластера до конфигурации из трех узлов.

Лучшие практики для аварийного восстановления

1. Регулярные резервные копии

• Планируйте регулярные резервные копии конфигураций NSX Manager для быстрой восстановления.
• Храните резервные копии в безопасном месте и обеспечьте их доступность в случае аварийного восстановления.

2. Географическая избыточность

• Развертывайте NSX Manager на нескольких площадках для обеспечения географической избыточности.
• В случае отказа одной площадки другая может взять на себя операции управления с минимальными перебоями.

Проактивный мониторинг

• Используйте встроенные инструменты мониторинга NSX-T и интегрируйте их с решениями сторонних производителей для постоянного мониторинга состояния кластера управления.
• Раннее обнаружение проблем может предотвратить серьезные сбои и уменьшить время простоя.

Площадка аварийного восстановления

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

Заключение

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

Для более детального изучения технических деталей ознакомьтесь с следующими ресурсами:

• Документация VMware NSX-T Data Center
• Резервное копирование и восстановление VMware Cloud Foundation
• Кластер NSX Manager не работает или недоступен, если все узлы кластера NSX Manager вышли из строя или большинство узлов не работает
  

Дункан Эппинг опубликовал интересный пост о том, как предотвратить исполнение виртуальных машин vCLS на VMware vSphere HA Failover Host. Напомним, что vSphere Clustering Service (vCLS) - это служба, которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Она реализуется тремя агентскими виртуальными машинами в кластере, где 3 или более хостов, и двумя, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.

Для тех, кто не знает, сервер vSphere HA Failover Host — это хост, который используется, когда происходит сбой и vSphere HA должен перезапустить виртуальные машины. В некоторых случаях клиенты (обычно партнеры в облачных решениях) хотят предотвратить использование этих хостов для любых рабочих нагрузок, поскольку это может повлиять на стоимость использования платформы.

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

Если вы создадите хранилище данных, которое недоступно назначенному Failover-хосту vSphere HA, то машины vCLS не смогут работать на этом хосте, так как хост не сможет получить доступ к датастору. Это обходной путь для решения проблемы, вы можете узнать больше о механизме размещения хранилищ данных для vCLS в этом документе. Обратите внимание, что если остальная часть кластера выйдет из строя и останется только Failover-хост, виртуальные машины vCLS не будут включены. Это означает, что механизм балансировки нагрузки VMware DRS также не будет функционировать, пока эти ВМ недоступны.

Борьба с программами-вымогателями и готовность к восстановлению после катастроф продолжают оставаться в приоритете для 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.

Недавно мы писали об изменениях в лицензионной политике и новых изданиях 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 доступно уже сейчас.

Вчера мы писали о том, как правильно обслуживать ISL-соединение растянутого кластера VMware vSAN. В этой статье был упомянут механизм vSAN Adaptive Quorum Control, который позволяет сохранять работоспособность растянутого кластера vSAN даже при последовательных отказах (например, сначала отказывает основная площадка, а затем и компонент Witness).

Видео ниже объясняет механику голосования, используемую vSAN в случае отказа одного из сайтов и последующего отказа Witness. Адаптивное управление кворумом присваивает больше голосов выжившему сайту, чтобы обеспечить обработку последующего отказа сайта свидетеля. Путем присвоения 3 голосов компонентам на выжившем сайте по-прежнему соблюдается большинство голосов. Даже если дополнительный хост ESXi на предпочтительном сайте потерян, всё равно есть достаточно голосов для достижения большинства, поэтому виртуальные машины продолжат функционировать.

Дункан Эппинг написал интересную статью про обслуживание межсайтового соединения (ISL) растянутого кластера VMware vSAN. Обычно, если условия позволяют, можно потушить все рабочие нагрузки (ВМ) на обеих площадках, после чего можно выключить кластеры и проводить обслуживание сетевого линка между площадками. Эта процедура описана в KB 2142676.

Но что делать в случае, когда вам нужно, чтобы рабочие нагрузки на одной из площадок продолжили выполняться во время обслуживания ISL?

В VMware vSAN 7 Update 3 появился механизм vSAN Witness Resiliency, который мы подробно описывали в статье "Улучшения VMware vSAN 7.0 Update 3 - пересчет голосов для обеспечения кворума при последовательных отказах". Он позволяет сохранять кворум в кластере и его функционирование при последовательных отказах - сначала одного из датацентров, а потом и компонента Witness.

Этот механизм и можно использовать для обслуживания ISL-соединения. Итак, переводим все хосты кластера на сайте 1 в режим обслуживания (Maintenance Mode) или выключаем их. В этом случае в растянутом кластере голоса для компонента Witness будут пересчитаны в течение 3 минут. После этого можно выключить и сам Witness - и это не приведет к падению виртуальных машин на сайте 2.

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

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

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

Для верности можно выполнить команду vsan.vm_object_info в консоли RVC и проверить объекты/экземпляры виртуальных машин на предмет того, что они находятся в статусе "ACTIVE" вместо "ABSENT":

После завершения обслуживания ISL-линка, вы можете включить компонент Witness, после чего включаете обратно хосты сайта 1 и обязательно выполняете ресинхронизацию (resync). После этого механизм VMware DRS в автоматическом режиме сам сбалансирует нагрузки по площадкам, распределив их по ним с помощью vMotion.

Недавно компания VMware обновила решение Cloud Director Availability 4.7, которое предназначено для создания резервной инфраструктуры в одном из публичных облаков на основе VMware Cloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS). Напомним, что о прошлой версии этого продукта мы писали вот тут.

Новый механизм репликации

До настоящего момента VMware Cloud Director Availability использовал независимые (independent) диски при репликации рабочих нагрузок в облака Cloud Director. Однако это не является их изначальным назначением, что может оказать отрицательное влияние на механику репликации в определенных случаях.

Для уменьшения действия этого фактора и дальнейшего улучшения стабильности и оперативности, а также для обеспечения возможности будущих улучшений, введена система отслеживания репликации Replication Tracking VM (RT VM). Она позволяет использовать новый способ репликации виртуальных машин, совместимый с продуктом Cloud Director Availability 4.7, который зарегистрирован в Cloud Director 10.5+.

Запущенные репликации не будут затронуты этим изменением после обновления VMware Cloud Director Availability. Существует опция для их миграции с независимых дисков на RT VM через пользовательский интерфейс VMware Cloud Director Availability.

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

Выбор политики хранения

VMware Cloud Director Availability 4.7 получил две новые функции, связанные с выбором политики хранения:

• Выбор политики хранения для каждого диска
• Переназначение политики хранения во время восстановления рабочей нагрузки

Выбор политики для каждого диска

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

Эта функция доступна как для облаков Cloud Director, так и для vSphere с одним отличием - для облаков vSphere вы можете выбрать политику хранения и хранилище размещения для каждого диска.

При использовании seed VM репликация будет использовать ее настройки хранилища, и вы не сможете их указать.

Переназначение политики во время восстановления рабочей нагрузки

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

Однако скорость хранилища может негативно сказаться на производительности рабочей нагрузки при ее переключении в случае сбоя. Чтобы сэкономить клиентам сложный выбор того, где именно пойти на уступки, VMware Cloud Director Availability 4.7 позволяет использовать конкретные настройки хранилища при начальной настройке репликации, а затем выбрать другие настройки при восстановлении реплик.

Эта новая функция доступна как для облаков vSphere, так и для облаков Cloud Director.

Предварительная проверка выполнения планов восстановления

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

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

Эта информация доступна в новой вкладке "Health", которая присутствует в каждом плане восстановления при его выборе. Там вы можете увидеть, когда была проведена последняя проверка, а также доступные действия для устранения обнаруженной проблемы.

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

Улучшения для облаков VMware Cloud Director

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

• Передача меток безопасности NSX, связанных с реплицированной виртуальной машиной при инициировании миграции/восстановления между двумя облаками, работающими на VMware Cloud Director 10.3+.
• Автовыбор политики сайзинга при cloud-to-cloud - если виртуальной машине назначена политика сайзинга на исходном сайте, и на назначенном сайте существует политика с таким же именем, она будет автоматически выбрана при настройке репликации.
• Управление видимостью удаленных облачных сайтов - поставщики облачных услуг могут контролировать, какие партнерские сайты будут видны для каких организаций. Если сайт, на котором активны репликации, скрыт, они будут продолжать отображаться в пользовательском интерфейсе, но невозможно будет создавать новые репликации в/из скрытого сайта.
• Управление политиками для направлений репликации - доступные средства управления расширяются еще одной новой опцией для поддержания возможного направления операций репликации для клиента облака. С ее помощью поставщики облачных услуг могут ограничить клиентов в защите рабочих нагрузок, работающих в облаке, только в направлении их собственного датацентра.

Более подробную информацию о VMware Cloud Director Availability 4.7 можно получить по этой ссылке.

Распределенная архитектура vSAN всегда была естественным решением для множества топологий, таких как растянутые кластеры, 2-узловые кластеры и кластеры, использующие домены отказа (fault domains). Но что насчет vSAN Max? Давайте рассмотрим, как vSAN Max может помочь обеспечить централизованное общее хранилище для ваших кластеров vSphere, используя эти альтернативные топологии.

Гибкость распределенного объектного хранилища

Кластер vSAN HCI объединяет вычислительные ресурсы и хранилища на одних и тех же хостах, которые составляют кластер, что обеспечивает простой и мощный способ создания растянутого кластера. Просто разместите хосты vSAN в кластере на двух географических площадках вместе с виртуальным хостом Witness на третьем сайте и настройте кластер как растянутый (stretched). И вычислительные ресурсы, и хранилища распределены по площадкам в единой, согласованной манере, что обеспечивает доступность экземпляров виртуальных машин и их данных в случае частичного или полного сбоя сайта.

Хост Witness не показан ниже для ясности на всех иллюстрациях растянутых кластеров в этом посте.

Рисунок 1. Отказоустойчивость на уровне сайта для виртуальных машин в растянутом кластере vSAN HCI, охватывающем два центра обработки данных.

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

Растянутые топологии, использующие разделенные хранилища и вычислительные ресурсы

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

Когда вычислительные ресурсы и хранилища отделены друг от друга, они должны понимать характеристики двух сетевых путей от вычислительных ресурсов к избыточным данным. В большинстве случаев один из сетевых путей (межсайтовая связь или ISL) будет медленнее другого. Это называется асимметричной сетевой топологией, как показано на Рисунке 2. Хотя это наиболее распространенная конфигурация для растянутого кластера, она представляет интересную задачу, потому что система должна правильно выбрать оптимальный сетевой путь вместо менее быстрого для лучшей производительности.

Рисунок 2. Асимметричные сетевые топологии для растянутых сред.

Гораздо менее распространенная симметричная сетевая топология показана на рисунке 3. Это представляет собой топологию, где пропускная способность и задержка остаются одинаковыми независимо от выбранного пути данных для выполнения запроса. Такую ситуацию можно увидеть, когда два домена отказа или "сайта", как их определяют, представляют собой просто стойки серверов, расположенные рядом друг с другом и использующие одно и то же сетевое оборудование, что обеспечивает задержку менее 1 мс между клиентским кластером и серверным кластером внутри одного домена отказа или между доменами.

Рисунок 3. Симметричные сетевые топологии для растянутых сред.

Чтобы помочь vSAN Max понять правильный сетевой путь в топологии растянутого кластера, мастер настройки vSAN Max позволит вам выбрать сетевую топологию, соответствующую вашей среде.

vSAN Max, растянутый между географическими сайтами

Кластер vSAN Max может быть настроен как кластер одного сайта или в растянутой конфигурации. vSAN Max может обеспечивать устойчивость данных на уровне сайта, зеркалируя данные между сайтами, и вторичные уровни отказоустойчивости с помощью эффективного для экономии места схемы хранения RAID-6 erasure coding в пределах каждого сайта. Это обеспечивает высокий уровень отказоустойчивости эффективным способом и гарантирует, что восстановление данных будет выполнено локально в случае отдельного сбоя хоста в пределах сайта.

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

Рисунок 4. Растянутый кластер vSAN Max обеспечивает устойчивое хранение данных на двух сайтах обработки данных для кластера vSAN HCI, который также является растянутым.

Рекомендация: используйте профили ReadyNode, сертифицированные для vSAN Max, для всех развертываний vSAN Max.

Поддерживаемые клиентские кластеры при использовании vSAN Max в растянутой топологии

Следующая таблица резюмирует типы клиентских кластеров, поддерживаемых при использовании кластера vSAN Max в конфигурации растянутого кластера. Предполагается, что требование к задержке в 1 мс или меньше между клиентским кластером и кластером vSAN Max выполнено, и предполагается, что все клиентские кластеры используют vSphere 8.

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

При использовании в конфигурации растянутого кластера кластеры vSAN Max будут иметь те же требования к пропускной способности и задержке сети между сайтами, что и традиционные кластеры vSAN HCI того же размера. Смотрите руководство по размерам пропускной способности растянутых кластеров vSAN для получения дополнительной информации.

Рекомендация. Размер вашей межсайтовой связи (ISL) должен быть основан на требованиях вашей рабочей нагрузки. Учитывая, что кластер vSAN Max может предложить высокопроизводительное хранилище, убедитесь, что ISL может обеспечить необходимую пропускную способность и задержку для ваших рабочих нагрузок. Это означает, что ваша среда может потребовать более 10 Гбит/с пропускной способности, указанной как минимально необходимая для этого типа топологии.

vSAN Max с использованием функции доменов отказа vSAN

vSAN Max также может быть настроен с использованием функции Fault Domains, которая чаще всего используется для обеспечения отказоустойчивости на уровне стоек для больших кластеров. Функция доменов отказа стала гораздо более эффективной с ESA, и поскольку vSAN Max построен на этой архитектуре, он обеспечивает все улучшенные уровни производительности, эффективности и доступности данных, связанные с ESA.

Рисунок 5. vSAN Max обеспечивает устойчивость на уровне стоек с использованием функции доменов отказа.

Будучи настроенной правильно, функция доменов отказа обычно ограничивается большими кластерами. Это связано с тем, что, как показано на рисунке 5 выше, RAID-6 распределяет данные и четность по минимум шести доменам отказоустойчивости, и VMware рекомендует использовать по крайней мере 3 хоста на каждый домен отказа. Для достижения такой же устойчивости на уровне стоек с использованием относительно меньшего кластера можно просто разместить один (и не более одного) хоста в кластере vSAN Max на стойку, не включая функцию доменов отказа, как показано на рисунке 6. В этой конфигурации он обеспечит устойчивость на уровне стоек таким же образом.

Рисунок 6. vSAN Max обеспечивает устойчивость на уровне стоек без использования функции доменов отказа.

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

Хотя типичная рекомендация VMware - включать опцию "Host Rebuild Reserve" для кластеров vSAN Max, обратите внимание, что эти переключатели не могут быть включены при настройке vSAN Max в растянутой топологии или при использовании функции доменов отказа vSAN.

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

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

Готовность к восстановлению средствами VMware Cloud DR - быстрое переключение и восстановление, оптимизированная стоимость владения

До сегодняшнего дня, когда клиенты сталкивались со сценарием DR, у них была только одна возможность - включить восстановленные виртуальные машины в резервном датацентре DR SDDC с помощью функции Instant Power On, при этом их диски располагались в облачной файловой системе. Затем они переносились на основное хранилище в DR SDDC через Storage vMotion.

Хотя это по-прежнему рекомендуемый подход для интенсивных по вводу-выводу или крупных рабочих нагрузок, пользователи теперь могут получить преимущества улучшенной производительности восстановления с новой функцией: Run Recovered VMs on Cloud Filesystem (запуск восстановленных машин в облачной файловой системе). Подробнее об этом рассказано тут.

С этой опцией ВМ могут продолжать работать в DR SDDC, причем их диски располагаются в Cloud Filesystem, что позволяет избежать использования Storage vMotion, что сильно ускоряет переключение в случае сбоя. Машины, работающие в Cloud Filesystem, получают защиту средствами высокой доступности (HA), а также низкие значения RPO.

Ключевые преимущества функции "Запуск восстановленных ВМ на Cloud Filesystem" включают:

• Быстрое переключение и улучшенная производительность после восстановления: исключение использования Storage vMotion для vSAN и запуск восстановленных ВМ с дисками, по-прежнему располагающимися в Cloud Filesystem.
• Быстрое обратное восстановление: эта новая функция устраняет необходимость создания снапшотов на базе VADP в резервном SDDC при обратном восстановлении.
• Оптимизация TCO: для рабочих нагрузок, ограниченных объемом хранилища, требуется меньше ресурсов облачных хостов для непосредственного запуска ВМ на Cloud Filesystem по сравнению с традиционным переключением.
• Гибкость: вы можете выбрать, какие рабочие нагрузки запускать на Cloud Filesystem, а какие - переносить в резервный SDDC с помощью storage vMotion.

Более подробно о VMware Cloud DR можно почитать на этой странице.

VMware Ransomware Recovery: быстрое и эффективное восстановление от современных атак

VMware недавно представила функцию "Bulk VM Processing" для решения VMware Ransomware Recovery. С этой функцией пользователи получают преимущества автоматизированного восстановления до 50 виртуальных машин за раз, что ускоряет время восстановления и оптимизирует ИТ-ресурсы.

Обработка машин в больших объемах работает в рамках существующего руководящего рабочего процесса восстановления от программ-вымогателей (Ransomware), который охватывает идентификацию, проверку и восстановление точек восстановления. До 500 ВМ можно включить в один план восстановления от программ-вымогателей, при этом одновременная обработка возможна для 50 ВМ в одном пакете, что позволяет сразу нескольким ВМ пройти живой поведенческий анализ для выявления предупреждений безопасности, которые могут быть использованы для очистки штаммов программ-вымогателей из скомпрометированных снимков. Вместе эти интегрированные возможности обеспечивают более уверенное и быстрое восстановление работы в случае успешной атаки программы-вымогателя.

Для более подробной информации об этом решении рекомендуем почитать FAQ и вот эту страничку на TechZone.

Недавно мы писали о репликации шаблонов виртуальных приложений vApp средствами VMware Cloud Director Availability, которая появилась в версии 4.6. Сегодня мы расскажем о прочих улучшениях этого решения в части планов восстановления (Recovery Plans).

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

VMware Cloud Director Availability 4.6 предлагает несколько заметных улучшений:

• Планы восстановления
• Регулирование пропускной способности (Bandwidth throttling)
• Публичный API
• Усовершенствования настроек процесса восстановления

Планы восстановления

Планы восстановления были частью VMware Cloud Director Availability уже некоторое время, но были доступны только для облачных мест назначения VMware Cloud Director. Теперь они стали частью набора функций vSphere DR и миграции и обеспечивают тот же интерфейс и удобство использования. План может быть создан как для миграций, так и защиты/репликации, но их смешивание не допускается.

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

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

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

Регулирование пропускной способности

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

Лимит применяется к определенному сетевому интерфейсу виртуального модуля Tunnel и указывается в мегабитах в секунду:

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

Публичный API

Еще одной новой функцией в VMware Cloud Director Availability 4.6 является публичный API для vSphere DR и миграции, которого не было в предыдущих релизах. Этот API позволяет вам выполнять настройку, репликацию, резервное копирование и многие другие операции.

Полная ссылка на API и подробная документация доступны на developer.vmware.com.

Настройки восстановления

Также произошли некоторые изменения в настройках восстановления, которые теперь проверяются вместе с настройками репликации (для датасторов) для избежания ошибок в процессе переключения/миграции из-за неправильной конфигурации. Кроме того, раздел "Network Mappings" позволяет настраивать общие сопоставления между исходными и целевыми сетями, что очень удобно при установке настроек восстановления для нескольких репликаций одновременно. Конечно, при необходимости эти сопоставления можно дополнительно настроить для каждого сетевого адаптера каждой виртуальной машины.

Каталоги VMware Cloud Director и шаблоны vApp широко используются многими организациями для оптимизации администрирования инфраструктуры виртуальных приложений vApp.

В Cloud Director Availability версии 4.3.1 компания VMware представила миграцию шаблонов vApp внутри облака или в удаленное облако Cloud Director. Это позволяет синхронизировать только конкретные элементы, а не весь каталог. Чтобы еще больше расширить возможности использования, в VMware Cloud Director Availability 4.6 теперь можно также защитить и шаблон vApp средствами репликации.

Меню консоли клиента было переработано, там добавлена новая кнопка защиты шаблона vApp:

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

После выбора шаблона для репликации, его назначения в облаке, датацетра VDC и политики хранения, вас перенаправят на страницу настроек мастера.

Вот основные нововведения здесь:

• Отслеживание исходного шаблона на предмет изменений - если включено, VMware Cloud Director Availability каждые 5 минут проверяет, не было ли каких-либо изменений в исходном шаблоне и, если они есть, настраивает новую репликацию для последней версии шаблона.
• Задержка начала синхронизации - проверки на изменения будут выполняться каждые 5 минут только в течение указанного интервала. Если изменение обнаружено, VMware Cloud Director Availability приступит к выполнению операций. Обратите внимание, что они могут начаться только в течение определенного времени, но могут завершиться за его пределами этого окна.
• Автоматическое поведение миграции - определяет, будет ли шаблон vApp перезаписан на месте назначения или будет добавлена новая копия в каталог, сохраняя старую версию без изменений. Для включения автоматической миграции начальная миграция должна быть выполнена вручную, и защита должна быть в состоянии восстановления после сбоя (Failed-Over recovery state).

Рабочий процесс

Рабочий процесс репликации шаблона vApp выглядит следующим образом:

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

Когда обнаруживается изменение, VMware Cloud Director Availability автоматически создает новую репликацию с последней версией шаблона vApp и удаляет старую. Если успешно выполнена ручная миграция текущей репликации (не обязательно начальной), то каждая следующая также будет автоматически выполнена с указанными настройками (перезапись или новая копия).

Учет баллов/стоимости для сервис-провайдера

Репликации шаблона vApp учитываются как стандартные репликации vApp/VM с помощью VMware vCloud Usage Meter:

• Миграции шаблона vApp как обычные миграции - 0 баллов за смигрированную ВМ.
• Репликация шаблонов vApp как их защита - 10 баллов за защищенную ВМ.

Обратите внимание, что учет ведется на виртуальную машину, а не на шаблон. Это означает, что если вы защищаете шаблон vApp, состоящий из 3 ВМ, он будет потреблять 30 баллов.

Особенности процесса

• Настройки восстановления можно изменить только до начала первоначальной ручной миграции. После этого они не могут быть изменены.
• Настройки восстановления применяются только к автоматически созданным (будущим) репликациям, если сохраняются имена всех ВМ в шаблоне.
• Настройка политики репликации "Custom SLA settings" должна быть обязательно активирована для организаций, которые будут защищать шаблоны vApp.

Источник.

Недавно мы писали о новом релизе фреймворка для управления виртуальной инфраструктурой VMware PowerCLI 13.1. У данного средства есть очень много командлетов для автоматизации задач в различных продуктах VMware. Сегодня мы поговорим о том, как с помощью PowerCLI можно управлять задачами репликации в Site Recovery Manager (SRM) и vSphere Replication (VR). Данные операции осуществляются через REST API.

1. Подключение к серверу vSphere Replication через Connect-VrServer

Чтобы подключиться к серверу управления vSphere Replication, необходимо использовать команду Connect-VrServer. Репликация может быть настроена внутри одного сервера vCenter или между локальными и удаленными экземплярами сервера vCenter.

При настройке репликации внутри одного и того же сервера vCenter, вы можете подключиться только к локальному сайту репликации vSphere. В параметре Server укажите адрес сервера vSphere Replication. В параметрах User и Password укажите имя пользователя и пароль для экземпляра сервера vCenter, где развернут виртуальный модуль vSphere Replication.

$vrConnection = Connect-VrServer -Server "MyVrAddress.com" 
   -User "administrator@vsphere.local" `
   -Password "MyLocalVCenterServerPassword"

Давайте рассмотрим объект VrServerConnection, возвращаемый командой Connect-VrServer. Он содержит свойство ConnectedPairings:

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

Вы можете индексировать этот словарь по имени vCenter и получить определенный объект Pairing. Вам понадобится этот объект Pairing для вызова различных операций из API VR:

Чтобы аутентифицироваться на удаленном сервере vCenter, вы будете использовать другой набор параметров команды Connect-VrServer. Обратите внимание, что у вас должна быть настроена пара сайтов между локальным и удаленным сайтами vSphere Replication.

На этот раз для параметра LocalServer укажите уже доступный объект VrServerConnection. Для параметра RemoteServer укажите имя удаленного VC. Для параметров RemoteUser и RemotePassword укажите имя пользователя и пароль удаленного VC. Обратите внимание, что с VR мы можем настроить несколько удаленных сайтов:

$remoteVc = "myRemoteVcName"
$vrConnection = Connect-VrServer -LocalServer $vrConnection `
    -RemoteServer $remoteVc `
    -RemoteUser "administrator@vsphere.local" `
    -RemotePassword "MyRemoteVCenterServerPassword"

Теперь, если вы проверите свойство ConnectedPairings объекта VrServerConnection, вы увидите, что в словаре появилась вторая пара, позволяющая вам вызывать операции API на удаленном сайте:

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

$remoteVc = "myRemoteVcName"
$vrConnection = Connect-VrServer -Server $localVr `
   -User "administrator@vsphere.local" `
   -Password "MyLocalVCenterServerPassword" `
   -RemoteServer $remoteVc `
   -RemoteUser "administrator@vsphere.local" `
   -RemotePassword "MyRemoteVCenterServerPassword"

2. Настройка Host Based Replication

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

$remotePairing = $vrConnection.ConnectedPairings[$remoteVc].Pairing	

Получение реплицируемых ВМ

Для начала вам нужно получить ВМ, которую вы хотите реплицировать. Используйте команду Invoke-VrGetLocalVms, для которой нужно указать параметры PairingId и VcenterId. У нас есть эти идентификаторы в объекте Pairing, который мы сохранили в переменной $remotePairing:

$replicatedVm = Invoke-VrGetLocalVms -PairingId $remotePairing.PairingId `
   -VcenterId $remotePairing.LocalVcServer.Id.Guid `
   -FilterProperty 'Name' `
   -Filter "VrSrmDemo"

Вы также можете применить фильтр к этому вызову. Параметр FilterProperty указывает свойство ВМ, которое будет использоваться для поиска. В данном случае это свойство Name. Параметр Filter указывает значение свойства, которое вы ищете. Результатом этого вызова является объект VirtualMachineDrResponseList, который содержит список ВМ, соответствующих указанному фильтру. В нашем случае это будет список с одной ВМ:

Настройка HDD-дисков машин для репликации

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

Вот как получить целевое хранилище данных на удаленном vCenter, используя команду Invoke-VrGetVrCapableTargetDatastores:

$targetDatastore = Invoke-VrGetVrCapableTargetDatastores -PairingId $remotePairing.PairingId `
   -VcenterId $remotePairing.RemoteVcServer.Id.Guid `
   -FilterProperty "Name" `
   -Filter "MyRemoteDS"

Здесь для VcenterId укажите идентификатор удаленного vCenter. Укажите параметры FilterProperty и Filter, чтобы выбрать целевое хранилище данных по имени. Жесткие диски доступны в свойстве Disks нашего объекта VirtualMachine, сохраненного в переменной $replicatedVm.

Пройдитесь по списку Disks и инициализируйте объекты ConfigureReplicationVmDisk для каждого жесткого диска. Сохраните эти конфигурации в переменной массива $replicationVmDisks:

$replicationVmDisks = @()
$replicatedVm.List[0].Disks | ForEach-Object {
   $replicationVmDisks += Initialize-VrConfigureReplicationVmDisk -VmDisk $_ `
      -EnabledForReplication:$true `
      -DestinationDatastoreId $targetDatastore.List[0].Id `
      -DestinationDiskFormat 'SAMEASSOURCE'
}

Конфигурация Host Based Replication

Сначала вам нужно инициализировать объект ConfigureReplicationSpec. Помимо различных настроек репликации, мы должны указать конфигурацию репликации диска, сохраненную в переменной $replicationVmDisks, для параметра Disk. Также вам нужно указать идентификатор целевого vCenter и идентификатор реплицируемой ВМ.

$replicationSpec = Initialize-VrConfigureReplicationSpec `
   -Rpo 60 `
   -NetworkCompressionEnabled:$true `
   -MpitEnabled:$true `
   -AutoReplicateNewDisks:$true `
   -LwdEncryptionEnabled:$false `
   -MpitInstances 1 `
   -MpitDays 1 `
   -Disks $replicationVmDisks `
   -TargetVcId $remotePairing.RemoteVcServer.Id.Guid `
   -VmId $replicatedVm.List[0].Id

Затем используйте команду Invoke-VrConfigureReplication для настройки репликации. В качестве параметров укажите PairingId и объект ConfigureReplicationSpec:

$task = Invoke-VrConfigureReplication -PairingId $remotePairing.PairingId `
   -ConfigureReplicationSpec $replicationSpec

Результатом операции является объект TaskDrResponseList, который в нашем примере содержит список из одной задачи. Если хотите, вы можете указать массив объектов ConfigureReplicationSpec и реплицировать несколько ВМ одним вызовом. Чтобы дождаться завершения задачи настройки репликации, получите задачу, пока ее свойство Status не будет равно чему-то отличному от "RUNNING":

Invoke-VrGetTaskInfo -TaskId $task.List[0].Id

В следующем разделе мы будем использовать командлеты из модуля VMware.Sdk.Srm для создания группы защиты и плана восстановления для только что созданной репликации.

3. Подключение к Site Recovery Manager с помощью Connect-SrmSdkServer

Для подключения к серверу Site Recovery Manager используйте командлет Connect-SrmSdkServer. Не используйте старый командлет Connect-SrmServer, уже доступный в модуле VMware.VimAutomation.Srm, так как он не совместим с командлетами модуля VMware.Sdk.Srm.

Site Recovery Manager поддерживает только одно соединение между локальными и удаленными сайтами SRM. Вы можете подключиться либо только к локальному сайту, либо вы можете аутентифицироваться на удаленном сайте сервера vCenter в том же вызове. Поскольку далее мы будем создавать группу защиты и план восстановления, мы выберем второй вариант. Обратите внимание, что у вас должна быть настроена пара сайтов между локальными и удаленными сайтами SRM.

$srmConnection = Connect-SrmSdkServer -Server "MySrmAddress.com" `
   -User "administrator@vsphere.local" `
   -Password "MyLocalVcPassword" `
   -RemoteUser "administrator@vsphere.local" `
   -RemotePassword "MyRemoteVcPassword"

Если мы посмотрим на объект SrmServerConnection, возвращенный командлетом Connect-SrmSdkServer, мы увидим, что он содержит свойство с именем ConnectedPairing. В этом случае это один объект Pairing, который представляет пару между локальным и удаленным сайтами SRM. Вам потребуется этот объект Pairing для вызова различных операций из API SRM:

4. Создание Protection Group и Recovery Plan для Host Based Replication

В этой главе мы будем использовать репликацию на основе хоста, которую мы настроили ранее. Сначала мы инициализируем HbrProtectionGroupSpec с уже реплицированной ВМ:

$hbrSpec = Initialize-SrmHbrProtectionGroupSpec -Vms $replicatedVm.List[0].Id

В этом примере мы повторно используем идентификатор ВМ, который мы сохранили в переменной $replicatedVm, поскольку он совместим между API VR и SRM. Если вам нужно получить реплицированную ВМ с помощью модуля VMware.Sdk.Srm, используйте командлет Invoke-SrmGetReplicatedVms:

$replicatedVm = Invoke-SrmGetReplicatedVms `
   -PairingId $srmConnection.ConnectedPairing.PairingId `
   -VcenterId $srmConnection.ConnectedPairing.LocalVcServer.Id.Guid `
   -FilterProperty "Name" `
   -Filter "VrSrmDemo"

Используйте объект HbrProtectionGroupSpec для инициализации SrmProtectionGroupCreateSpec. Для параметра ReplicationType укажите HBR:

$protectionGroupSpec = Initialize-SrmProtectionGroupCreateSpec -Name "SrmDemoGroup" `
   -ReplicationType HBR `
   -ProtectedVcGuid $srmConnection.ConnectedPairing.LocalVcServer.Id.Guid `
   -HbrSpec $hbrSpec

Создайте Protection Group с помощью командлета Invoke-SrmCreateGroup:

$task = Invoke-SrmCreateGroup -PairingId $srmConnection.ConnectedPairing.PairingId `
   -ProtectionGroupCreateSpec $protectionGroupSpec

Дождитесь завершения задачи SRM:

$task = Invoke-SrmGetTaskInfo -TaskId $task.Id

Когда $task.Status равно 'SUCCESS', получите Protection Group, используя свойство $task.Result, которое содержит ID созданной группы:

$protectionGroup = Invoke-SrmGetGroup -PairingId $srmConnection.ConnectedPairing.PairingId `
   -GroupId $task.Result
	

Чтобы завершить этот пример, мы создадим Recovery Plan для Protection Group. Для этого сначала инициализируйте RecoveryPlanCreateSpec, требуемый командлетом Invoke-SrmCreatePlan:

$recPlanSpec = Initialize-SrmRecoveryPlanCreateSpec `
   -Name "SrmDemoRecoveryPlan" `
   -ProtectedVcGuid $srmConnection.ConnectedPairing.LocalVcServer.Id.Guid `
   -ProtectionGroups $protectionGroup.Id

Затем создайте план восстановления с объектом RecoveryPlanCreateSpec и дождитесь завершения задачи, используя Invoke-SrmCreatePlan:

$task = Invoke-SrmCreatePlan -PairingId $srmConnection.ConnectedPairing.PairingId `
  -RecoveryPlanCreateSpec $recPlanSpec
Invoke-SrmGetTaskInfo -TaskId $task.Id

5. Отключение соединений к SRM и VR

После того, как вы закончили взаимодействовать с сервером SRM, закройте соединение, используя командлет Disconnect-SrmSdkServer:

Disconnect-SrmSdkServer "MySrmAddress.com"

Чтобы закрыть соединение с сервером VR, используйте командлет Disconnect-VrServer:

Disconnect-VrServer "MyVrAddress.com"

Вы можете объединить модули PowerCLI VMware.Sdk.Vr и VMware.Sdk.Srm для автоматизации всего сценария создания репликации на основе хоста и использования ее с группой защиты и планом восстановления. Если вы хотите автоматизировать репликацию на основе массива, доступную с модулем VMware.Sdk.Srm, обратитесь к статье "Array Based Replication with PowerCLI 13.1". Также вы можете ознакомиться со статьей "vSphere Replication REST API with PowerShell: Configure VM replication".

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

В некоторых из приведенных ниже сценариев Дункан обсуждает сценарии разделения кластера. Под разделением подразумевается ситуация, когда и L3-соединение с компонентом Witness, и ISL-соединение с другим сайтом недоступны для одного из сайтов. Так, на примере приведенной выше диаграммы, если говорится, что сайт B изолирован - это означает, что сайт A все еще может общаться со свидетелем, но сайт B не может общаться ни со свидетелем, ни с сайтом A.

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

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

Дункан Эппинг опубликовал статью о VMware Ransomware Recovery, которая может оказаться полезной администраторам, встретившимся или готовящимся встретиться с проблемой программ-вымогателей. Об этом продукте мы также рассказывали вот тут. Приведем основные мысли этой статьи ниже.

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

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

Кроме того, с помощью NSX и программного обеспечения Next Generation Anti-Virus от VMware можно безопасно проверить точку восстановления. Создается карантинная среда, где точка восстановления проверяется на уязвимости и угрозы, а также может быть проведен анализ рабочих нагрузок для восстановления, как показано на скриншоте ниже. Это значительно упрощает процесс восстановления и проверки, поскольку устраняет необходимость ручных операций, обычно включенных в этот процесс. Конечно, в рамках процесса восстановления используются продвинутые возможности сценариев VMware Cloud Disaster Recovery, позволяющие восстановить полный дата-центр или просто выбранную группу виртуальных машин, запустив план восстановления. В этот план восстановления включен порядок, в котором нужно включить и восстановить рабочие нагрузки, но в него также можно включить настройку IP, регистрацию DNS и многое другое.

В зависимости от результатов анализа, вы можете затем определить, что делать со снапшотом. В рамках анализа вы сможете ответить на следующие вопросы:

• Данные не скомпрометированы?
• Рабочие нагрузки не заражены?
• Есть ли какие-либо известные уязвимости, которые мы должны сначала устранить?

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

Более подробно о решении VMware Ransomware Recovery можно почитать тут.

В конце ноября этого года компания NAKIVO выпустила бета-версию своей платформы для резервного копирования и репликации виртуальных машин Backup & Replication v10.8 Beta. Напомним, что о возможностях прошлой версии NAKIVO Backup & Replication v10.7 мы писали вот тут.

Давайте посмотрим, что нового предлагает бета-версия NAKIVO Backup & Replication v10.8:

1. Консоль сервис-провайдеров

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

До этого вы могли создавать окружения новых клиентов в рамках датацентра, а теперь можно добавить standalone-инстансы в общую инфраструктуру защиты данных как Managed Service Provider (MSP). Можно мониторить все эти окружения из единого дэшборда, что позволяет сервис-провайдерам предоставлять службы Backup-as-a-Service (BaaS) и Disaster Recovery-as-a-Service (DRaaS) для клиентов, у которых есть географически распределенные вычислительные ресурсы.

2. Поддержка VMware vSphere 8

Теперь NAKIVO Backup & Replication полностью поддерживает новые возможности платформы VMware vSphere 8, такие как digital processing units (DPU) для разгрузки основных CPU серверов и улучшение производительности онпремизных и облачных компонентов.

Еще в апдейте 10.7.2 была заявлена поддержка vSphere 8 initial availability (IA), а сейчас полностью поддерживается vSphere 8 general availability (GA).

3. Поддержка S3-совместимых объектных хранилищ

В прошлых релизах поддерживалось резервное копирование и репликация на хранилища Amazon S3, Wasabi Hot Cloud Storage, Azure Blob Storage и Backblaze B2 с возможностью неизменяемых бэкапов (immutability). Новая версия поддерживает гибридные окружения, которые содержат объектные хранилища S3 через API, среди которых можно выбрать из различных сервис-провайдеров, обеспечивающих их поддержку.

4. Функции прямого восстановления с ленточных носителей

Теперь с помощью решения от NAKIVO пользователи могут производить восстановление резервных копий виртуальных машин и инстансов EC2 напрямую с ленточных носителей. Такой подход обеспечивает высокую скорость восстановления и поддерживает платформы VMware vSphere, Microsoft Hyper-V, Nutanix AHV и Amazon EC2.

5. Улучшения юзабилити и средств управления

Здесь появились следующие функции:

• Улучшения политики хранения бэкапов - ранее решение NAKIVO использует отдельные рабочие процессы для планирования задач резервного копирования и для настройки политики хранения резервных копий. Это позволяло вам менять политики хранения (включая схему grandfather-father-son, GFS), не затрагивая настройки задач бэкапа. Теперь же можно открыть оба вида настроек в рамках одного шага, чтобы обеспечить тонкий тюнинг и более гранулярную настройку задачи РК.
• Приоритет задач РК - эта функция позволяет обеспечить высокий приоритет в очереди для задач резервного копирования наиболее критичных систем. Приоритет можно выставить от 5 (низший, ставится по умолчанию) до 1 (высший приоритет).

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

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

Загрузить бета-версию решения NAKIVO Backup & Replication v10.8 по этой ссылке.

На сайте проекта VMware Labs появился новый интересный продукт - Cluster Rules Manager (CRM). С помощью данной утилиты можно провести обследование виртуальной инфраструктуры на предмет правил DRS affinity и anti-affinity rules. Первые определяют обязательное сосуществование ВМ на одном хосте ESXi (например, критичный сервис с высокой интенсивностью сетевого и дискового взаимодействия), а вторые - наоборот, невозможность существования ВМ на одном хосте (например, для целей отказоустойчивости и независимости от единой точки отказа оборудования).

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

Давайте посмотрим на возможности VMware Cluster Rules Manager:

• Аудит правил anti-affinity для всех виртуальных машин в рамках сервера vCenter.

• Импорт правил DRS affinity rules из разных серверов vCenter.

• Экспорт правил DRS affinity rules в новый vCenter с сервера vCenter, гле они уже настроены.

• Отчет о правилах, содержащий различные умные метрики - пользователь может выбрать, на каком уровне он будет сгенерирован (vCenter, датацентр или кластер). Отчет можно экспортировать в HTML-формат.

• Отчет в реальном времени по ассоциациям VM-Rule. Можно выбрать виртуальную машину, и отчет будет содержать информацию обо всех правилах DRS, которые затрагивают данную ВМ. Этот отчет также можно генерировать на разных уровнях - ВМ, хост ESXi, кластер, датацентр и сервер vCenter. Его также можно экспортировать.

• Возможность соединяться с разными vCenter в интерфейсе продукта.

Скачать VMware Cluster Rules Manager (CRM) можно по этой ссылке. Такую утилиту мы давно ждали, правда пока интерфейс оставляет желать лучшего. Ждем следующих версий!

Компания VMware на днях сделала доступным для сервис-провайдеров средство Cloud Director Availability версии 4.5, которое предназначено для создания резервной инфраструктуры в одном из публичных облаков на основе VMware Cloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS).

Давайте посмотрим, что нового появилось в vCDA 4.5, в основном в плане функций Disaster Recovery и обеспечения миграции сервисов виртуального датацентра:

1. DR и миграция

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

• Новый механизм сопряжения между онпремизным датацентром и компонентами Cloud vCenter Replication / vCenter Replication Management через обратный тоннель, который теперь представляет собой одношаговый процесс, не требующий, чтобы на онпремизной площадке был создан публичный endpoint для соединения с облаком.
• Возможность указать настройки репликации заранее, до ее актуального исполнения.
• Возможность выбора политики хранилищ виртуальной машины (VM Storage Policy).
• Улучшенная масштабируемость на облачной площадке за счет добавления новых виртуальных модулей Cloud Replicator.
• Возможность репликации зашифрованных ВМ.

Также модули для облака (vCenter Replication Management) и для онпремизной площадки (On-premises to Cloud vCenter Replication) были обновлены до версии 4.5, при этом если вы используете On-premises to Cloud vCenter Replication версии 4.4, то соединения продолжат работать, но добавить новые репликации вы не сможете.

2. Возможности для сервис-провайдеров

Теперь резервное копирование и восстановление могут быть автоматизированы в рамках существующего ручного процесса. В меню Scheduled Backup Archives вы можете определить расписание, когда создаются бэкапы, а также SFTP-сервер, куда загружаются зашифрованные архивы. Минимальный интервал бэкапов - 30 минут, максимальный - 1 неделя.

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

Также в vCDA 4.5 используются VMware Cloud Director Advisories для пуш-нотификаций клиентам, которые также доступны и на портале VMware Cloud Director Availability.

3. Дополнительные новые функции и улучшения

Теперь настройки восстановления размещены в новом меню, которое устроено более интуитивно. Сохранены такие настройки, как выбор сети и конфигурация адаптера (IP и MAC), но есть и дополнительные действия по кастомизации. Все свойства, доступные через VMware Cloud Director, могут быть изменены для каждой репликации, включая возможность исполнения сценария.

Также появилась новая политика VM sizing policy в разделе настроек VDC policy. Она расширяет уже существующую политику placement policy, которая появилась в прошлых релизах.

VMware Cloud Director Availability 4.5 также получил новую роль view-only user, которую можно использовать для разных вариантов, когда нужно исключить риск любого изменения системы и настроенных репликаций.

Ну и последнее - теперь представление System health дает больше информации, например, о времени непрерывной доступности (uptime) сервисов и виртуального модуля.

Подробнее о новых возможностях продукта VMware Cloud Director Availability 4.5 можно почитать в Release Notes и документации.

На прошедшей конференции Explore 2022 компания VMware представила множество интересных продуктов и технологий, о которых мы рассказали вот тут. Сегодня мы поговорим еще об одном решении, релиз которого состоялся на этой неделе - VMware Ransomware Recovery.

Согласно исследованиям, каждые 11 секунд в мире происходят атаки типа Ransomware (программы-вымогатели). Компаниям приходится платить до 5 миллионов долларов в качестве выкупа за получение доступа к своим данным. При этом в 92% случаев жертвы Ransomware после переведения оплаты в итоге не получают полного доступа к своим данным.

Сегодня мероприятия по борьбе с Ransomware состоят из следующих этапов:

В настоящее время большие компании заинтересованы в получении услуги Ransomware Recovery as-a-Service, которая подразумевает непрерывную работу по обнаружению и ликвидации вредоносного ПО, которое постоянно проникает в крупные организации. Проблема здесь в том, что Ransomware может жить незаметно в инфраструктуре до нескольких месяцев (сейчас медианный показатель составляет 11 дней), поэтому регулярное резервное копирование, неизменяемые копии (immutable backups) и жесткие политики хранения данных тоже не являются на 100% работающим средством.

В процессе восстановления после атаки Ransomware администраторы сталкиваются со следующими проблемами:

• Идентификация точки восстановления, которая находится до момента возникновения подозрительной активности.
• Валидация точки восстановления, чтобы убедиться в том, что данные в ней не содержат вредоносного кода.
• Проведение итеративного процесса восстановления как можно быстрее.
• Минимизация потерь данных в рамках процесса восстановления и после него - машины нужно поднять в изолированном окружении (Isolated Recovery Environment, IRE) и протестировать их на отсутствие инфекции. При этом надо сделать так, чтобы внутри ВМ оказались самые последние незараженные версии файлов и папок.

Итак, выпущенный VMware продукт Ransomware Recovery представляет собой облачное решение, доступное по запросу как Ransomware Recovery as-a-Service. Оно является дополнением к продукту VMware Cloud Disaster Recovery и использует двухъярусную инфраструктуру хранения, которая была разработана, в том числе, для задач борьбы с Ransomware.

Об этом мы уже писали ранее - одной из имплементаций такой инфраструктуры является платформа VMware Cloud Flex Storage.

Это решение построено на базе файловой системы enterprise-класса, которая разрабатывается уже много лет на базе продукта Datrium DHCI, купленного VMware в июле 2020 года. Эта же файловая система используется для сервиса VMware Cloud Disaster Recovery. Она имеет двухъярусный дизайн, который позволяет просто масштабировать емкость и производительность хранилищ, используя архитектуру Log-Structured Filesystem (LFS).

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

Функциональность VMware Ransomware Recovery в консоли Cloud Disaster Recovery позволяет обеспечить рабочий процесс идентификации Ransomware, валидации резервных копий и восстановления инфраструктуры после атаки в рамках утвержденных шагов согласно руководствам blueprints от VMware.

Возможности guided restore point selection позволяют найти точку во времени (снапшот данных), которая является наиболее подходящей для восстановления, учитывая баланс теряемых данных и вероятности возвращения инфекции:

Встроенные функции Next Gen AV and Behavioral Analysis позволяют проанализировать выбранный снапшот на наличие вредоносного кода. Это, конечно же, не дает 100% гарантии, что его там нет, но очень существенно снижает риски.

Все тесты проходят в окружении Isolated Recovery Environment (IRE), где внутрь виртуальной машины вставляет специальный security sensor, который проверяет машину на подозрительные активности.

В результате анализа будет выведен отчет о подозрительных активностях ВМ:

Кроме того, VMware Ransomware Recovery предоставляет следующие функции:

• Пользователи могут использовать предконфигурированные сетевые политики в изолированном окружении, чтобы избежать реинфицирования.
• За счет возможности Live Mount виртуальные машины включаются мгновенно в среде IRE, без необходимости их восстанавливать в нативном формате. Это минимизирует общее время восстановления инфраструктуры.
• Возможности 30-minute RPO и Granular Recovery позволяют сохранять резервные копии в облако каждые полчаса и хранить их там в immutable-режиме в файловой системе Scale Out Cloud Filesystem. Это позволяет хранить глубокую историю снапшотов, а также восстанавливать отдельные файлы и папки из резервных копий в нужную точку восстановления (машину для этого даже не нужно включать).
• Встроенные отчеты об аудите дают представление о производительности и полноте операций аварийного восстановления. Они доступны напрямую из SaaS-консоли.
  

Релиз VMware Ransomware Recovery уже состоялся. Более подробно почитать об этом решнии можно по этой ссылке.

Совсем недавно компания VMware выпустила обновленную версию своего решения для обеспечения высокой доступности датацентров на базе VMware Cloud Director - Cloud Director Availability 4.4. По-сути, Cloud Director Availability предназначен для создания резервной инфраструктуры в одном из публичных облаков сервис-провайдеров на основе VMware vCloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS). Сегодня мы посмотрим на новые возможности этого продукта...

Некоторое время назад мы писали о службах VMware vSphere Cluster Services (ранее они назывались Clustering Services), которые появились в VMware vSphere 7 Update 1. Они позволяют организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Для этого VMware придумала такую штуку - сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом:

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

Иногда требуется отключить службы Cluster Services, что может оказаться необходимым в следующих случаях:

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

Режим, в котором службы Cluster Services отключены, называется Retreat Mode. Итак, заходим в vSphere Client и выбираем кластер, в котором мы хотим ввести Retreat Mode. В строке браузера нам нужна строка вида:

domain ID domain-c<number>

Скопировав эту часть строчки, идем в Advanced Setting сервера vCenter и нажимаем Edit Settings:

Далее создаем там параметр со следующим именем и значением false:

config.vcls.clusters.domain-cxxx.enabled

Где cxxx - это идентификатор домена, который вы скопировали на прошлом шаге:

После этого нажимаем кнопку Save. В консоли vSphere Client в разделе vCLS для кластера мы увидим, что этих виртуальных машин больше нет:

На вкладке Summary мы увидим предупреждение о том, что vSphere Cluster Services больше не работает, а службы DRS вследствие этого также не функционируют корректно:

Чтобы вернуть все как было, нужно просто удалить добавленный параметр из Advanced Settings сервера vCenter.

Одним из нововведений новой версии решения для обеспечения катастрофоустойчивости виртуальной инфраструктуры хранения VMware vSAN 7.0 Update 3 стал улучшенный механизм по обработке последовательных отказов. Называется он Enhanced Data Durability.

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

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

Проиллюстрируем это на примере, который привел Дункан Эппинг. Предположим, у нас есть вот такая инфраструктура:

И вот у нас отказывает полностью один из датацентров. В консоли RVC мы увидим следующее:

  VM R1-R1:

  Disk backing:

  [vsanDatastore] 0b013262-0c30-a8c4-a043-005056968de9/R1-R1.vmx

  RAID_1

  RAID_1

  Component: 0b013262-c2da-84c5-1eee-005056968de9 , host: 10.202.25.221

  votes: 1, usage: 0.1 GB, proxy component: false)

  Component: 0b013262-3acf-88c5-a7ff-005056968de9 , host: 10.202.25.201

  votes: 1, usage: 0.1 GB, proxy component: false)

  RAID_1

  Component: 0b013262-a687-8bc5-7d63-005056968de9 , host: 10.202.25.238

  votes: 1, usage: 0.1 GB, proxy component: true)

  Component: 0b013262-3cef-8dc5-9cc1-005056968de9 , host: 10.202.25.236

  votes: 1, usage: 0.1 GB, proxy component: true)

  Witness: 0b013262-4aa2-90c5-9504-005056968de9 , host: 10.202.25.231

  votes: 3, usage: 0.0 GB, proxy component: false)

  Witness: 47123362-c8ae-5aa4-dd53-005056962c93 , host: 10.202.25.214

  votes: 1, usage: 0.0 GB, proxy component: false)

  Witness: 0b013262-5616-95c5-8b52-005056968de9 , host: 10.202.25.228

  votes: 1, usage: 0.0 GB, proxy component: false)

Здесь мы видим, что у нас 1 голос на каждый из дисковых компонентов основной площадки (итого 2), 3 голоса на Witness и 2 голоса на резервной площадке.

Теперь представим, что все хосты резервной площадки отказывают полностью. У нас остается 2+3=5 голосов из 7, то есть кворум есть, все в порядке (для обеспечения кворума нужно больше 50% голосов). Но вот если у нас после этого откажет компонент Witness, имеющий 3 голоса, то у нас останется только 2 голоса из 7, кворума не будет - и это может привести к проблемам в кластере.

Для этого в vSAN 7 Update 3 сделали механизм пересчета голосов. Посмотрим на то, как выглядит картина через 5 минут после отказа резервной площадки в консоли RVC:

  VM R1-R1:

  Disk backing:

  [vsanDatastore] 0b013262-0c30-a8c4-a043-005056968de9/R1-R1.vmx

  RAID_1

  RAID_1

  Component: 0b013262-c2da-84c5-1eee-005056968de9 , host: 10.202.25.221

  votes: 3, usage: 0.1 GB, proxy component: false)

  Component: 0b013262-3acf-88c5-a7ff-005056968de9 , host: 10.202.25.201

  votes: 3, usage: 0.1 GB, proxy component: false)

  RAID_1

  Component: 0b013262-a687-8bc5-7d63-005056968de9 , host: 10.202.25.238

  votes: 1, usage: 0.1 GB, proxy component: false)

  Component: 0b013262-3cef-8dc5-9cc1-005056968de9 , host: 10.202.25.236

  votes: 1, usage: 0.1 GB, proxy component: false)

  Witness: 0b013262-4aa2-90c5-9504-005056968de9 , host: 10.202.25.231

  votes: 1, usage: 0.0 GB, proxy component: false)

  Witness: 47123362-c8ae-5aa4-dd53-005056962c93 , host: 10.202.25.214

  votes: 3, usage: 0.0 GB, proxy component: false)
 

Итак, мы видим, что каждый из дисковых компонентов получил по 3 голоса. Компонент Witness вне площадок получил 1 голос вместо 3, а компонент Witness, поднявшийся на основной площадке также получил 3 голоса.

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

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

Мы много писали о возможностях продукта для резервного копирования и восстановления виртуальной и физической инфраструктуры NAKIVO Backup and Replication. Мы подробно разбирали его возможности, средства защиты от вредоносного ПО, а также решения для бэкапа и восстановления приложений. Сегодня мы поговорим о том, как использовать продукт для аварийного восстановления инфраструктуры после больших сбоев и аварий.

Мы много писали о решении VMware Cloud Disaster Recovery, которое позволяет обеспечивать катастрофоустойчивость виртуальных инфраструктур за счет резервирования онпремизных ресурсов в облаке. Службы VMware Cloud Disaster Recovery позволяют производить восстановление после сбоев по запросу (On-Demand Disaster Recovery) напрямую в облаке VMware Cloud on AWS.

VMware Cloud Disaster Recovery обеспечивает оркестрацию процесса создания реплик на хранилищах S3 Cloud, а также реализацию процесса восстановления инфраструктуры на стороне VMware Cloud on AWS с сохранением показателя RPO равного 30 минутам.

У многих пользователей такой схемы возникает вопрос - а за что они отвечают в этом процессе, за что отвечает VMware, а за что - Amazon?

Ответ можно найти вот тут, мы расскажем об этом вкратце. Итак, VMware Cloud Disaster Recovery состоит из трех компонентов:

• Файловая система Scale-out Cloud File System (SCFS)
• Оркестратор (Orchestrator)
• Коннекторы DRaaS Connectors

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

С точки зрения безопасности и операций, ответственность распределяется по трем основным уровням - пользователь, VMware и Amazon AWS:

Пользователь отвечает за:

"Security in the Cloud":

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

VMware отвечает за:

"Security of the Cloud" - то есть за безопасность самого облака, что означает защиту систем и программного обеспечения, составляющего основу облака для служб VMware Cloud Disaster Recovery. Очевидно, что это включает в себя не только DRaaS-cервисы, но и платформенные составляющие, такие как VMware vSphere и vSAN.

Amazon отвечает за:

"Security of the Infrastructure" - физические серверы, доступ к ним в датацентрах, функционирование аппаратного обеспечения, исправность физических линий связи и соединений в рамках ЦОД.

Если говорить о разделении зон ответственности в плане конкретных операций и функциональности, то таблица в разрезе указанных трех сущностей выглядит так:

Более детальная информация обо всем этом приведена в документе "VMware Cloud Disaster Recovery Service Description".

На сайте проекта VMware Labs обновилась полезная для администраторов VMware vSphere утилита VMware DRS Sump Insight до версии 2.1. Напомним, что это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS. О прошлых версиях этой утилиты мы писали тут и тут.

В новой верси не так много нововведений:

• Добавлена поддержка дампов VMware vSphere 7.0 Update 2 и Update 3
• Минорные улучшение интерфейса и бэкенда
• Исправления ошибок

Напомним также о специальном плагине на базе HTML5 к vSphere Client для данного сервиса. Он добавляет функции утилиты DRS Dump Insight в интерфейс vSphere Client, работающего с сервером vCenter Server Appliance (vCSA).

Скачать VMware DRS Sump Insight 2.1 можно по этой ссылке.

Итак, началось главное событие года в сфере виртуализации - онлайн-конференция VMworld 2021 (на которую вы, кстати, еще можете зарегистрироваться бесплатно). В рамках конференции было сделано множество анонсов, о которых мы постепенно расскажем, а начнем с нововведений в инфраструктуре катастрофоустойчивости как услуги - DR-as-a-Service (DRaaS)...

Давно мы не писали о продуктах компании NAKIVO - одного из лидеров в сфере резервного копирования и защиты данных виртуальной инфраструктуры. Недавно компания выпустила обновление NAKIVO Backup & Replication v10.4. Напомним, что мы писали о версии NAKIVO B&R 10 чуть больше года назад. С тех пор функциональность продукта существенно улучшилась - это полноценное Enterprise-решение, которое получило функции защиты от программ-вымогателей и...

Весной этого года мы рассказывали о новых возможностях продукта VMware Cloud Disaster Recovery, который позволяет производить кросс-облачное восстановление виртуальных сред. Одним из самых страшных DR-сценариев для администраторов является поражение инфраструктуры программой-вымогателем (ransomware), которая зачастую блокирует компьютеры, а данные их дисков зашифровывает.

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

Вот какие моменты важны при борьбе с массовой атакой посредством ransomware:

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

В ответ на эти требования компания VMware разработала облачную файловую систему Scale-out Cloud Filesystem (SCFS), которая позволяет хранить готовые к восстановлению резервные копии ВМ, избегая больших затрат.

Делается это за счет комбинации в одном хранилище двухъярусной архитектуры - для хранения резервных копий и для исполнения нагрузок. Облако EC2 с локальными NVMe-хранилищами используется для обеспечения работы высокопроизводительных нагрузок (cache-tier), а S3-хранилища используются для больших объемов данных (capacity tier).

Это позволяет независимо масштабировать ресурсы для увеличения производительности и емкости. Часть cache-яруса используется для обработки входящих данных по резервному копированию, чтобы обеспечить баланс потока резервного копирования (backup-mode) и исполнения нагрузок. Когда нужно приступить к восстановлению (recovery-mode) ярус кэша может быть расширен, чтобы виртуальные машины запускались напрямую с этой файловой системы. То есть, такой дизайн файловой системы позволяет быстро переключаться между режимами backup-mode и recovery-mode.

Этот подход основан на Log-Structured Filesystem (LFS), файловой системы, которая была предложена еще в 1992 году одним из основателей VMware Менделем Розенблюмом. Она основывается на идее, что устройства хранения (HDD, SSD, S3) не так производительны в случайных операциях, как в последовательных, а sequential writes как раз удобно использовать для такой структуры хранения бэкапов. Идея LFS в том, чтобы сохранять данные изменений файловой системы в виде лога, а позже проводить его очистку.

Эти же техники использует VMware Cloud Disaster Recovery в облаке S3. Как видно из картинки, все входящие данные бэкапов разбиваются на большие сегменты в 10 МБ, которые последовательно записываются на хранилище как объекты S3 на высокой скорости. Данные хранятся в виде лога, то есть не перезаписывают прошлые данные. Это позволяет избежать ситуации, когда резервные копии виртуальных машин перезаписываются уже инфицированными бэкапами.

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

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

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

Начать изучение платформы VMware Cloud Disaster Recovery можно с этой странички.

В августе компания VMware выпустила новую версию продукта Cloud Director Availability 4.2.1, который предназначен для создания резервной инфраструктуры в одном из публичных облаков сервис-провайдеров на основе VMware Cloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS). Напомним, что о предыдущей версии этого продукта 4.1 мы писали в декабре прошлого года вот тут.

Основная новая возможность продукта - это автоматическое расширение сети Layer 2 в облако.

Теперь Cloud Director Availability 4.2.1 позволяет расширить Layer 2 network в облако, как для инсталляций VMware Cloud Director на базе VMware NSX-T Data Center (это появилось еще в версии 4.2), так и на базе NSX Data Center for vSphere.

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

Для использования этих возможностей виртуальные модули VMware Cloud Director Availability нужно обновить на версию 4.2.1. Что касается версий VCD и NSX, то нужно использовать VMware Cloud Director 10.x и NSX Data Center for vSphere 6.4.10 или более поздние.

При этом тут есть следующие ограничения:

• Только ести Routed Org VDC с типом интерфейса Subinterface могут мыть использованы как Server networks, которые присоединяются к Trunk-интерфейсу NSX Data Center for vSphere Edge.
• Сеть Guest VLAN должна быть деактивирована. Если ранее она была хоть раз активирована, то нужно ее пересоздать и снова деактивировать при создании.
• После создания сессии L2 VPN Server выбранные сети Server Networks уже нельзя менять (если нужно поменять - их нужно пересоздать).
• Для больших инсталляций (50 серверов vCenter и более) есть проблемы с NSX Data Center for vSphere, когда Edge VM падают с kernel panic.
• Для инсталляций Edge Gateway нельзя менять настройки после первоначальной установки. Если вы меняете, например, тип с Compact на Large, то нужно удалить конфигурацию IPSec и пересоздать сессию L2 Server Session.

Итак, чтобы включить растянутую конфигурацию, вам нужно на стороне облака:

1. Зарегистрировать NSX Data Center for vSphere Manager в интерфейсе VMware Cloud Director Availability и принять сертификат для создания траста:

2. Создать сессию L2 VPN Server, указав IP-адреса и сети, используемые для растягивания. Эту операцию может провести как облачный провайдер, так и Org Admin со стороны клиента:

Как и в случае NSX-T Data Center, для растягивания сети в NSX Data Center for vSphere нужно использовать VMware NSX Edge (он же NSX Autonomous Edge), там есть простой мастер из нескольких шагов:

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

Руководства по апгрейду на новую версию для клиентов и сервис-провайдеров приведены здесь:

• VMware Cloud Director Availability Upgrade Guide for Providers
• VMware Cloud Director Availability Upgrade Guide for Tenants

Скачать Cloud Director Availability 4.2.1 можно по этой ссылке.