На прошлой неделе блогер Дункан Эппинг получил вопрос о 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 вышли из строя или большинство узлов не работает
  

У Brock Peterson есть хорошая подборка статей о решении VMware Aria Operations (ранее этот продукт назывался vRealize Operations или vROPs). Сегодня мы посмотрим на то, как работает кластер vROPs/Aria с точки зрения основных архитектур отказоустойчивости - Standalone, High Availability (HA) и Continuous Availability (CA). Официальная документация на эту тему находится тут, а мы начнем с некоторых понятий:

• Primary Node (основной узел) - начальный и единственный обязательный узел в Aria Ops. Все остальные узлы управляются основным узлом. В установке с одним узлом основной узел выполняет все функции.
• Data Node (дата-узел) - на этих узлах установлены адаптеры, они собирают данные и выполняют анализ. В крупных развертываниях адаптеры обычно устанавливаются только на дата-узлах, чтобы основной узел и реплики могли сосредоточиться на управлении кластером.
• Replica Node (реплика) - высокая доступность (HA) и непрерывная доступность (CA) Aria Ops требует преобразования дата-узла в реплику. Это копия основного узла, которая используется в случае его отказа.
• Witness Node (свидетель) - непрерывная доступность (CA) Aria Ops требует наличие узла-свидетеля. Свидетель выступает в качестве арбитра при принятии решений о доступности Aria Ops.
• Remote Collectors (удаленные сборщики) - распределенные развертывания могут требовать удаленных сборщиков (RC), которые могут обходить брандмауэры, взаимодействовать с удаленными источниками данных, снижать нагрузку на каналы передачи данных между центрами обработки данных или уменьшать нагрузку на кластер аналитики Aria Ops. Узлы RC только собирают объекты для инвентаризации, без хранения данных или выполнения анализа. Кроме того, удаленные сборщики могут быть установлены на другой операционной системе, чем остальные узлы кластера.

Важно отметить, что основные узлы и реплики также являются дата-узлами. Кластер аналитики (Analytics Cluster) включает все основные узлы, реплики и дата-узлы. Кластер Aria Ops включает кластер аналитики и любые узлы удаленных сборщиков.

Вне кластера Aria Ops также могут быть Cloud Proxies (CP). Первоначально они назывались Remote Collectors для развертываний vROps Cloud, но потом они были доработаны для полного замещения RC. Рекомендации по их сайзингу можно найти здесь. Отдельное развертывание может выглядеть следующим образом:

Вы можете построить кластер Aria Ops несколькими способами: автономный (Standalone), с высокой доступностью (HA) или с непрерывной доступностью (CA).

Начнем с базового варианта (изображенного выше), автономные варианты выглядят следующим образом:

• Single Primary Node Cluster (кластер с одним основным узлом) - в этом развертывании ваш основной узел Aria Ops будет выполнять все функции: административный интерфейс, продуктовый интерфейс, REST API, хранение данных, сбор и аналитика. Такие развертывания часто используются для пробных версий или пилотных проектов (proof-of-concept). Сайзинг основных узлов зависит от количества объектов и метрик, которые они будут обрабатывать, подробности можно найти здесь.
• Кластеры с несколькими узлами (Multi-Node Clusters):
  • Основной узел и как минимум один дата-узел, но может включать и до 16 дата-узлов. Дата-узлы могут выполнять все функции, которые выполняет основной узел, кроме обслуживания Admin UI. Они часто используются для разгрузки основного узла. Обратите внимание, что основной узел также является дата-узлом.
  • Основной узел и как минимум один облачный прокси (CP), но может включать и до 60 CP. Ранее известные как удаленные сборщики (RC), они используются для обхода брандмауэров, получения данных из удаленного источника, уменьшения пропускной способности между центрами обработки данных и других задач. Они только собирают метрики, не хранят данные и не выполняют анализ данных. RC являются частью кластера Aria Ops, тогда как CP не являются частью кластера.

Автономные варианты визуально выглядят следующим образом.

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

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

В версии vRealize Operations 6.0 была введена функция HA, обеспечивающая некоторую защиту от потери аналитического узла (основной узел, реплика узел или дата-узел). Следует отметить, что Aria Ops HA не является стратегией аварийного восстановления (DR), но обеспечивает некоторую защиту от потери данных. Как и для кластеров без HA, мы просто добавляем узел реплики, получая следующие конфигурации:

• Основной узел и реплика
• Основной узел, реплика и до 16 дата-узлов
• Основной узел, реплика и до 60 облачных прокси (CP)
• Основной узел, реплика, до 16 дата-узлов и до 60 CP

Как описано здесь, Aria Ops HA создает копию основного узла, называемую репликой, и защищает кластер аналитики от потери дата-узла. Aria Ops использует базу данных PostgreSQL, распределенную между всеми дата-узлами (включая основной узел и реплики) для хранения всех данных, поэтому если мы потеряем основной узел, узел реплики будет повышен до основного, и мы продолжим работу без потери данных. Если мы потеряем дата-узел, эти данные также доступны на основных/реплика узлах (эта схема похожа на RAID5), поэтому потери данных не будет. Если мы потеряем более одного дата-узла, произойдет потеря данных.

Лучшие практики для развертывания кластера Aria Ops HA можно найти здесь. В итоге, ваш кластер Aria Ops HA будет выглядеть примерно так:

Вы можете разместить перед вашим кластером Aria Ops HA балансировщик нагрузки, как и раньше, указывающий на ваш основной узел, реплику и дата-узлы.

В версии Aria Ops 8.0 были введены функции непрерывной доступности (CA) и концепция доменов отказа. Можно сказать, что Aria Ops CA - это Aria Ops HA с репликой в другом физическом расположении, а также с парными дата-узлами и узлом Witness, чтобы отслеживать все процессы.

Aria Ops CA защищает нас от потери целого домена отказа, например, всего датацентра. Как описано здесь, с CA данные, хранящиеся в основном узле и дата-узлах в домене отказа 1, постоянно синхронизируются с узлом реплики и дата-узлами в домене отказа 2. Aria Ops CA требует как минимум один дата-узел в дополнение к основному узлу, и они должны быть парными, то есть дата-узел в домене отказа 1 требует дата-узел в домене отказа 2.

Существует третий узел, называемый свидетелем (Witness), который ни собирает, ни хранит данные. Он определяет, в каком домене отказа должен работать кластер Aria Ops. Его можно представить как диспетчер трафика, маршрутизирующий трафик на основе состояния основного узла Aria Ops.

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

Интересный пост от John Nicholson о размещении сервера VMware vCenter в растянутом кластере vSAN Stretched Cluster. В идеальном мире у вас есть управляющий кластер, который содержит ваш сервер vCenter, а вы управляете каждым кластером из него. Но, к сожалению, в реальном мире всё сложнее:

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

Можно ли запустить сервер vCenter на управляемом им кластере?

Надо сказать, что всегда полностью поддерживался запуск сервера vCenter на управляемом им кластере. Высокая доступность (HA) в этом случае всё равно будет работать. Если вам нужно более подробно изучить этот вопрос, этот короткий видеоролик ответит на ваш вопрос.

Итак, какой лучший совет при размещении vCenter?

Используйте ephemeral port groups для всех управляющих сетей. Это предотвратит проблемы chicken-egg с виртуальными распределенными коммутаторами (vDS), которые раздражают, но с которыми можно справиться.

Автор предпочитает использовать правила DRS типа "SHOULD", чтобы vCenter "как правило" находился на узле с наименьшим номером или IP-адресом в кластере. Это полезно в ситуации, когда vCenter работает с ошибками и службы управления не запускаются, так как это упрощает поиск узла, на котором он работает. Обязательно избегайте использования правил "MUST" для этого, так как это не позволит vCenter запуститься в другом месте в случае сбоя данного узла.

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

Вот такое делать не рекомендуется. Всегда предпочтительнее запускать сервер vCenter там, где он будет защищен с помощью высокой доступности (HA), и ему не потребуется выключение для обновления хоста. Растянутые кластеры vSAN всегда поддерживают операции active/active, и многие клиенты часто настраивают их так, чтобы большинство рабочих нагрузок выполнялись в предпочтительном датацентре (preferred site). Если вы используете эту конфигурацию, рекомендуется запускать сервер vCenter во вторичном (secondary) местоположении по нескольким причинам:

• В случае сбоя основного сайта, вы не останетесь «операционно слепым», поскольку HA со стороны vCenter будет активирована и восстановит рабочие нагрузки. Это снизит любые операционные простои, которые могли бы произойти в течение нескольких минут, пока сервер vCenter запустится на резервном узле основного сайта.
• Он будет действовать как указатель на состояние здоровья вторичного датацентра. В целом полезно иметь какую-то рабочую нагрузку на вторичном сайте, чтобы понимать, как будут работать эти хосты, даже если это будет относительно легкая нагрузка.

Дункан Эппинг опубликовал интересный пост о том, как предотвратить исполнение виртуальных машин 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 также не будет функционировать, пока эти ВМ недоступны.

Вчера мы писали о том, как правильно обслуживать 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.

Распределенная архитектура 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.

Недавно компания VMware выпустила обновленную версию платформы виртуализации vSphere 8 Update 2, где было сделано много интересных изменений. В частности, несколько поменялся интерфейс механизма vSphere Cluster Services (vCLS).

Напомним, что VMware High Availability (HA) и DRS при активации создают системные виртуальные машины vCLS в vSphere. Это обязательно, так как эти ВМ развертываются на каждом кластере vSphere после обновления vCenter Server до версии v7.0 Update 2 или более поздней. Теперь интерфейс vSphere Cluster Services изменился с выпуском vSphere 8.0 U2, про который Дункан Эппинг рассказывает в своем видео:

Начиная с vSphere 7.0 Update 2, автоматически создается и применяется новое правило anti-affinity. Это правило гарантирует, что каждые 3 минуты проводится проверка, не расположены ли несколько ВМ vCLS на одном и том же хранилище данных. Если это так, правило инициирует операцию storage vMotion и перераспределяет эти ВМ по разным хранилищам.

Когда хранилище данных, на котором расположены ВМ vCLS, переводится в режим обслуживания, вам нужно вручную применить Storage vMotion к машинам vCLS, чтобы переместить их в новое место, или перевести кластер в режим Retreat Mode.

Режим Retreat Mode позволяет отключить службу vSphere Clustering Service для автоматического удаления виртуальных машин-агентов. Это полезно, когда вам нужно выполнить задачи по техническому обслуживанию инфраструктуры, в частности хранилищ, чтобы эти вспомогательные ВМ вам не мешали.

Ранее Retreat Mode был доступен только через расширенную конфигурацию, а теперь его можно включать через пользовательский интерфейс, начиная с vSphere 8.0 U2. Для этого откройте vSphere Client, выберите ваш кластер > Configure > General (в разделе vSphere Cluster Service), далее нажмите Edit vCLS mode:

Дункан Эппинг поднял вопрос о том, необходимо ли указывать 2 параметра Isolation Address в растянутом кластере VMware vSAN (stretched cluster), которые используются механизмом VMware HA.

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

Некоторые пользователи спрашивали, могут ли они использовать один Gateway Address от Cisco ACI, который будет доступен в обоих местах, даже если произойдет разделение, например, из-за сбоя ISL. Если это действительно так, и IP-адрес действительно доступен в обоих местах во время таких сбоев, то достаточно использовать один IP-адрес в качестве адреса изоляции.

Тем не менее, вам нужно удостовериться, что IP-адрес пингуется через сеть vSAN при использовании vSAN в качестве платформы для расширенного хранения данных. Ведь когда vSAN активирован, vSphere HA использует именно сеть vSAN для управляющих сигналов. Если адрес пингуется, вы можете просто задать адрес изоляции, установив расширенную настройку "das.isolationaddress0". Также рекомендуется отключить использование стандартного шлюза управляющей сети, установив "das.usedefaultisolationaddress" в значение false для сред, использующих 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.

В 2021 году мы писали об использовании дисков VMDK на платформе VMware vSphere в режиме Multi-writer для кластерных решений. Этот режим предназначен для поддержки технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) и для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance, когда требуется использование общего диска в кластерной конфигурации.

В этом случае необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли производить запись в файл VMDK одновременно с нескольких хостов ESXi (можно также организовать и запись от нескольких ВМ на одном хосте). Этот режим со стороны VMware поддерживается только для некоторых кластерных решений, таких как Oracle RAC, и для технологии Fault Tolerance, у которой техника vLockstep требует одновременного доступа к диску с обоих хостов ESXi.

В статье, на которую мы сослались выше, хоть и неявно, но было указано, что режим "Multi-writer" используется и для кластеров Microsoft Windows Server Failover Clustering (WSFC, ранее они назывались Microsoft Cluster Service, MSCS), однако это была неверная информация - он никогда не поддерживался для кластеров Microsoft.

Мало того, использовать режим "Multi-writer" для WSFC не только не рекомендуется, но и опасно - это может привести к потере данных. Кроме того, возможности поддержки VMware в этом случае будут очень ограничены.

Информация о поддержке "Multi-writer" и общих дисков VMDK

Использование файлов VMDK в качестве общих дисков для виртуальных машин Windows в среде vSphere возможно, но только когда файлы VMDK хранятся в кластеризованном хранилище данных с включенной поддержкой Clustered VMDK, как описано в статье Clustered VMDK support for WSFC, или ниже в этой статье.

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

Итак, какие варианты предлагает VMware, если вы уже используете кластеры WSFC в режиме multi-writer:

• Переконфигурирование общих дисков на основе файлов VMDK для кластеризованных виртуальных машин Windows, которые были настроены с использованием опции флага multi-writer.
• Перемещение файлов VMDK в одно или несколько официально поддерживаемых хранилищ данных с поддержкой Clustered VMDK.
• Представление файлов VMDK обратно виртуальным машинам таким образом, чтобы минимизировать или избежать необходимости перенастройки внутри гостевой операционной системы или на уровне приложений.

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

Как минимум, клиенты должны выполнить (или отметить) следующее перед началом этих процедур:

• Текущие конфигурации виртуальных машин, особенно:
  • Диски – какие файлы VMDK соответствуют каким томам в гостевой операционной системе.
  • Имена и расположение файлов для КАЖДОГО диска VMDK.
  • Номер SCSI и SCSI ID, к которому подключен КАЖДЫЙ диск. Мы должны присоединить диск к ТОМУ ЖЕ SCSI ID при повторном подключении.
  • В Windows - текущий владелец ресурсов диска (проверить это можно в конфигурации WSFC).
• Если владение ресурсами WSFC разделено между узлами, ПЕРЕКЛЮЧИТЕ ВСЕ РЕСУРСЫ на один узел. Это упрощает процесс реконфигурации и очень полезно, чтобы избежать путаницы. Выключите все пассивные узлы ПЕРЕД выключением активного узла. После завершения настройки необходимо включить сначала активный узел, а затем остальные узлы.

Переконфигурация кластера WSFC с Multi-Writer на режим Clustered VMDK

Давайте начнем с рассмотрения нашей текущей конфигурации, посмотрим на узлы (кликабельно):

И на диски:

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

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

Вот узел WSFC Node-1 и его расшаренные диски (флаг Multi-Writer установлен в Enabled):

Читайте статью далее->

Недавно мы писали о репликации шаблонов виртуальных приложений 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" позволяет настраивать общие сопоставления между исходными и целевыми сетями, что очень удобно при установке настроек восстановления для нескольких репликаций одновременно. Конечно, при необходимости эти сопоставления можно дополнительно настроить для каждого сетевого адаптера каждой виртуальной машины.

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

Бывает это в следующей типовой конфигурации кластера vSAN:

Предположим, что Datacenter A - это "preferred site", а Datacenter B - это "secondary site". Если между датацентром A и датацентром B происходит сбой ISL, компонент Witness, находящийся на третьей площадке, автоматически привяжет себя к датацентру A. Это означает, что ВМ в датацентре B потеряют доступ к хранилищу данных vSAN.

С точки зрения кластера HA, у датацентра A всегда будет Primary-узел (ранее он назывался Master), он же есть и у датацентра B. Первичный узел обнаружит, что есть некоторые ВМ, которые больше не работают, и он попытается перезапустить их. Он попытается сделать это на обеих площадках, и конечно, сайт, где доступ к хранилищу данных vSAN потерян, увидит, что перезапуск не удался.

А вот и важный момент, в зависимости от того, где/как сервер vCenter подключен к этим площадкам. Он может получать, а может и нет информацию об успешных и неудачных перезапусках. Иногда бывают ситуации (в зависимости от архитектуры и характера сбоя), когда сервер vCenter может общаться только с primary-узлом в датацентре B, и это приводит к сообщениям о неудачных попытках перезапуска, хотя на самом деле все ВМ были успешно перезапущены в датацентре A.

В этом случае интерфейс может дать разъяснение - он даст вам информацию о том, какой узел является первичным, и также сообщит вам о либо об "изоляции сети" (network isolation) или о "разделении сети" (network partition) в соответствующих разделах разделах панели Hosts. При сбое ISL - это, конечно же, разделение сети.

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

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

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

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

Вчера мы писали о новых возможностях январского релиза облачного решения VMware Aria Operations. Одной из них стала высокая доступность средств мониторинга приложений High Availability for Application Monitoring, которую можно рассмотреть несколько подробнее.

Многие пользователи уже применяют решение Telegraf в VMware Aria Operations, выполняющее функции мониторинга доступности приложений и зависящее от компонентов Cloud Proxies, через которые происходит сбор данных от эндпоинтов. Сам мониторинг происходит через ARC-адаптеры приложений, которые ранее не поддерживали группы коллекторов, а Cloud Proxy был единой точкой отказа для функций application monitoring. Поэтому при выходе из строя Cloud Proxy данные от эндпоинтов не могли попадать в VMware Aria Operations.

Теперь же мониторинг приложений работает с помощью механизма Collector Groups, в которые объединены Cloud Proxy, поэтому при падении одного из них метрики будут передаваться в другие инстансы.

Первый шаг в интерфейсе - это создание Collector Group. Здесь были сделаны улучшения по добавлению новых групп и включению/выключению механизма высокой доступности из UI:

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

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

Также есть механизм по проверке конфигураций, если были внесены изменения в составе Collector Group. После того, как прокси были добавлены или удалены, становится активной опция "Retry Cloud Proxy Configuration", а также возможность активации/деактивации data persistence:

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

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

Больше подробностей об облачном решении VMware Aria Operations можно узнать на этой странице.

Сейчас многие администраторы виртуальных инфраструктур VMware vSphere и Microsoft Hyper-V используют лидирующее на рынке решение StarWind Virtual SAN для создания отказо- и катастрофоустойчивых хранилищ под виртуальные машины. В прошлой статье мы рассматривали развертывание модуля StarWind SAN & NAS storage appliance а сегодня мы поговорим о его первоначальной настройке, которая может быть проведена через графическую консоль (Web Console) или текстовый интерфейс (Text Console)...

Продолжаем рассказывать о главном продукте для создания отказоустойчивых хранилищ StarWind Virtual SAN, который позволяет обеспечивать бесперебойное функционирование кластеров виртуальных машин на базе серверов виртуализации VMware ESXi или Microsoft Hyper-V. Сегодня мы рассмотрим механизм назначения прав доступа инициаторов в консоли StarWind Management Console, с помощью которой администраторы управляют всеми аспектами виртуальных хранилищ.

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

Многие из вас используют или интересуются решением StarWind Virtual SAN, которое является сейчас одним из основных продуктов на рынке для организации отказоустойчивых кластеров хранилищ (а еще и самым технологически продвинутым). Сегодня мы поговорим об узле Witness node в кластерах и о том, как он помогает защитить его от массовых сбоев в виртуальной среде.

Одним из нововведений новой версии решения для обеспечения катастрофоустойчивости виртуальной инфраструктуры хранения 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 минут. Зато в этом случае кластер будет более устойчив к отказам, которые в реальной жизни могут происходить один за другим.

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

Давайте посмотрим на интерфейс рекомендаций VMware DRS в VMware vSphere 7 Update 2 и ниже, который находится вот тут: Cluster UI > Monitor > DRS Recommendations:

Видно, что интерфейс был так себе, поэтому в Update 3 его переделали:

Теперь в гриде мы видим список действий для данной рекомендации, появились элементы Select All и Clear Selection, ну и в целом все стало выглядеть намного приятнее.

Также это хорошо смотрится и в темной теме vSphere Client:

Кроме того, было улучшено и окно настройки механизма Proactive HA. Раньше оно выглядело вот так:

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

А когда он включен, соответствующими переключателями можно настраивать условия отказов:

При этом доступны и операции над всеми переключателями - Block All и Unblock All.

На самом деле, подобные улучшения происходят часто и в минорных релизах VMware vSphere - команда UI в VMware постоянно старается сделать жизнь администраторов проще и приятнее.

Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Сегодня мы поговорим о том, как настраивать аутентификацию доступа к хранилищам через протокол CHAP в решении StarWind Virtual SAN...

Многие администраторы VMware vSphere в крупных компаниях рано или поздно сталкиваются с необходимостью создания кластеров из виртуальных машин, например, для использования технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) или для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance. При использовании кластерных решений необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли...

В августе компания 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 можно по этой ссылке.

Компания StarWind Software, известная многим из вас как ведущий производитель программно-аппаратных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, запустила новый продукт StarWind SAN & NAS, который предназначен для создания хранилищ на основе севреров с установленным там гипервизором. В качестве платформы StarWind SAN & NAS использует Linux...

Как вы знаете, в кластере отказоустойчивости VMware HA есть Primary и Secondary хосты серверов ESXi. Первые отвечают за управление кластером и восстановление виртуальных машин, а вторые – только за исполнение операций и рестарт ВМ. Недавно мы, кстати, писали о том, как сделать хост VMware vSphere Primary (он же Master) в кластере HA, а сегодня расскажем о том, какие события происходят на этих хостах в случае отказа хоста (именно полного отказа, а не при недоступности, например, его в сети).

Как пишет Дункан Эппинг, если отказывает хост Secondary, то происходят следующие вещи, начиная с времени T0:

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+3 секунды – хост Primary начинает отслеживать хартбиты на хранилище в течение 15 секунд
• T+10 секунд – хост помечается как unreachable и Primary хост начинает пинговать его Management Network (постоянно в течение 5 секунд)
• T+15 секунд – если на датасторе на настроены хартбиты, то хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин
• Либо если настроены хартбиты, но их нет, то через T+18 секунд хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин

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

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+10 секунд – начинаются выборы нового Primary хоста в кластере
• T+25 секунд - выбор хоста Primary сделан и он читает список виртуальных машин, а также ждет, пока Secondary хосты сообщат о своих виртуальных машинах
• T+35 секунд – старый хост Primary помечается как unreachable
• T+50 секунд – хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин согласно списку нового Primary

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

Дункан Эппинг написал интересный пост о том, что в кластере VMware HA есть возможность сделать хостам ESXi такую настройку, чтобы они выбирались как Primary при конфигурации/реконфигурации кластера. Это может оказаться полезным, например, в растянутом (Stretched) кластере, когда вам важно, чтобы Primary-хосты находились на основной площадке с целью ускорения процесса восстановления после сбоя (речь идет о 2-3 секундах в большинстве случаев, но для некоторых инфраструктур это может быть критично).

Пост этот актуален еще и потому, что настройки несколько изменились, начиная с VMware vSphere 7 Update 1, поэтому информация об этом может быть полезна для администраторов.

Прежде всего, в статье VMware KB 80594 рассказывается о том, какие настройки были изменены в механизме VMware FDM (он же HA). Самое главное, что до vCenter 7 Update 1 настройки хранились в файле /etc/opt/vmwware/fdm/fdm.cfg, теперь же они переехали в ConfigStore, работать с которым нужно путем импорта и экспорта json-файлов конфигурации.

Вот, кстати, интересующая нас табличка с изменениями параметров Advanced Settings в FDM:

Нас здесь интересует настройка node_goodness, большое численное значение которой и определяет, будет ли данный узел выбран как Primary (ранее в HA он также назывался Master).

Итак, Дункан показывает, как можно экспортировать расширенные настройки из ConfigStore:

configstorecli config current get -g cluster -c ha -k fdm
{
   "mem_reservation_MB": 200,
   "memory_checker_time_in_secs": 0
}

Все это можно также экспортировать в json-файл командой:

configstorecli config current get -g cluster -c ha -k fdm > test.json

Далее добавляем в этот json параметр node_goodness с большим значением, например, 10000000:

{
    "mem_reservation_MB": 200,
    "memory_checker_time_in_secs": 0,
    "node_goodness": 10000000
}

И импортируем его обратно в ConfigStore:

configstorecli config current set -g cluster -c ha -k fdm -infile test.json

В итоге хост ESXi 1507 был Primary:

А затем им стал узел 1505, для которого мы изменили данную расширенную настройку:

Ну и Дункан записал небольшое видео, раскрывающее весь процесс изменения данных настроек в VMware FDM / HA:

На днях компания StarWind, ведущий производитель средств для создания программно-аппаратных хранилищ под виртуализацию, выпустила новую версию своего флагманского продукта - StarWind Virtual SAN v8 for Hyper-V (build 14120). Надо отметить, что в конце марта этого года StarWind уже выпускала обновление Virtual SAN (build 14033), поэтому ниже мы расскажем о новых возможностях обеих версий.

Итак, что нового появилось в StarWind Virtual SAN v8 for Hyper-V в этом году:

1. Компоненты VTL и Cloud Replication

• Поддержка Microsoft Azure - добавлена опция по загрузке файлов в Archive tier напрямую, без необходимости сначала добавлять их в Hot/Cool tier и дальнейшего перемещения в архив.
• Возможность Write Protect для виртуальных кассет.
• Минимальный размер кассеты установлен в 50 МБ.
• Режим VTL file operation mode изменен на принудительное закрытие неиспользуемых файлов. Если в работе слишком много частей виртуальных кассет, то много открытых файлов могло привести к исчерпанию ресурсов. Изменить это поведение теперь можно в параметре closedatafiles в конфиге StarWind.cfg.
• Исправлена ошибка при восстановлении кассет, разделенных на части, из облака (некоторые части могли не загружаться).
• Пофикшена ошибка в cloud replication, которая могла возникать, если установлена опция "Create new empty tapes automatically when existing tape removed from VTL for replication". Если она была включена, это могло привести к падению сервиса при создании новой виртуальной кассеты.

2. Улучшения синхронной репликации

• Исправлена ошибка с отклонением синхронизации HA-узла при перезапуске сервиса на одном из узлов (иногда процедура не стартовала автоматически).
• Исправлена ошибка, приводившая к падению сервиса в случае, если соединение с хранилищем или сетевое соединение испытывало падение производительности.
• Исправлена реализация алгоритма Node Majority failover strategy. Ранее она работала некорректно в случае, если соединение между узлами было нарушено, но только в одну сторону.
• Пофикшена процедура автоматического восстановления для трехсторонней репликации. Ранее она использовала информацию от двух из трех узлов, что некорректно для процедура auto-restore. Теперь учитывается статус от всех трех узлов.
• Поправлено некорректное поведение при операции расширения размера хранилища на узле. Это приводило к разрыву соединения для некоторых случаев, когда операции по работе с хранилищем занимали продолжительное время.
• Исправлена ошибка, которая вела к полной синхронизации вместо быстрой в некоторых случаях.
• Исправлена ошибка с обработкой IO-запросов на одном из хранилищ, приводившая к тому, что в случае зависания запроса на конфигурации с three-way репликацией происходила некорректная работа на всех трех узлах.

3. Основные улучшения

• Улучшения производительности для версии VSA (Virtual Storage Appliance).
• Исправлена проблема с закрытием сессии в случаях, когда обнаруживался критический недостаток ресурсов.
• Исправлена проблема с обработкой операции control connection close - в некоторых случаях это приводило к генерации большого числа нотификаций, а Management Console переставала отвечать.
• Исправлена процедура session close при остановке службы - теперь она не зависает в некоторых редких случаях.
• Исправлена проблема с зависанием Management Console при накатывании бесплатной лицензии на сервер без интернет-соединения.
• Было обновлено лицензионное соглашение.

4. StarWindX PowerShell Module

• Физические устройства теперь есть в общем списке устройств. Их можно использовать для экспорта с физических ленточных устройств.
• Добавлено свойство MaintenanceMode для объекта HA Device.

Загрузить пробную версию StarWind Virtual SAN v8 for Hyper-V можно по этой ссылке. Документация доступна здесь, а Release Notes - вот тут.

Отметим также, что обновился и продукт в формате виртуального модуля для платформы VMware - StarWind VSAN for vSphere (OVF Version 20210520, Version 8 build 14120). Release notes доступны тут (список улучшений там практически такой же, за исключением некоторых моментов в мартовской версии).