Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Все самое нужное о виртуализации и облаках

Более 6150 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru | Ссылка дня: Какие есть версии и номера билдов VMware vCenter, ESXi, Tools и Connection Server?

Архитектура кластеров VMware Aria Operations (бывшие vROPs) - Standalone, High Availability (HA) и Continuous Availability (CA)


У 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 балансировщик нагрузки, чтобы направлять пользователей к активному кластеру.


Таги: VMware, Aria, Operartions, HA

Растянутый кластер VMware vSAN Stretched Cluster - где запускать сервер vCenter?


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

Таги: VMware, vSAN, HA, Stretched, vCenter, Blogs

Как предотвратить исполнение виртуальных машин vCLS на Failover-хосте VMware vSphere HA


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


Таги: VMware, vSphere, HA, vCLS, VMachines, DRS, Blogs

Интересное видео: VMware vSAN Adaptive Quorum Control в растянутом кластере


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

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


Таги: VMware, vSAN, vSphere, HA, DR, Stretched, Video

Как правильно обслуживать ISL-соединение растянутого кластера VMware vSAN


Дункан Эппинг написал интересную статью про обслуживание межсайтового соединения (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, vSAN, HA, DRS, Stretched, Storage

Гибкие сетевые топологии растянутых кластеров в решении VMware vSAN Max


Распределенная архитектура 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 HCI (ESA) в конфигурации stretched cluster Кластер vSAN Max или vSAN HCI (ESA) в конфигурации растянутого кластера Да

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

Кластер vSAN HCI (ESA), когда он находится на одном из сайтов данных, где находится кластер vSAN Max. Кластер vSAN Max или vSAN HCI (ESA) в конфигурации растянутого кластера Да Предоставляет высокую доступность для данных и запущенных виртуальных машин
Растянутый кластер vSphere между двумя сайтами с ассиметричным сетевым соединением Кластер vSAN Max или vSAN HCI (ESA) в конфигурации растянутого кластера Нет Пока не поддерживается
Растянутый кластер vSphere между двумя сайтами с симметричным сетевым соединением Кластер vSAN Max или vSAN HCI (ESA) в конфигурации растянутого кластера Да

Поддерживается, встречается редко, так как требуется аналогичные параметры bandwidth и latency между доменами отказа, как и внутри домена

Кластеры vSphere, когда они находятся на одном из сайтов данных, там же, где и кластер vSAN Max

Кластер vSAN Max или vSAN HCI (ESA) в конфигурации растянутого кластера Да Предоставляет высокую доступность для данных, но НЕ для запущенных виртуальных машин

Любой клиентский кластер архитектуры vSAN OSA

vSAN Max cluster or vSAN HCI cluster (ESA) в режиме одного сайта или в конфигурации растянутого кластера Нет Пока не поддерживается

Как отмечено выше, когда кластер 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, vSAN, Max, Stretched, vSphere, HA, DR

Улучшения интерфейса vSphere Cluster Services (vCLS) в VMware vSphere 8 Update 2 и режим Retreat Mode


Недавно компания 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:


Таги: VMware, vSphere, HA, vCLS

Нужно ли указывать два Isolation-адреса растянутого кластера VMware vSAN для механизма VMware HA?


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


Таги: VMware, vSAN, HA

Что нового в решениях VMware Ransomware Recovery и Cloud Disaster Recovery


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


Таги: VMware, Cloud, DR, Ransomware, Security, HA

Внимание: не используйте режим "Multi-writer" для виртуальных дисков VMDK на платформе vSphere в кластерах Microsoft WSFC


В 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):

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


Таги: VMware, Microsoft, WSFC, VMDK, Storage, HA, Bugs

Планы восстановления и новая функциональность решения VMware Cloud Director Availability 4.6


Недавно мы писали о репликации шаблонов виртуальных приложений 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, HA, DR

Сообщения об ошибках VMware HA при восстановлении виртуальных машин в случае сбоя межсайтового соединения распределенного кластера vSAN


Дункан Эппинг в своем блоге описал ситуацию, когда один из администраторов распределенного кластера 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, HA

Таблица возникающих проблем и ожидаемого поведения растянутого кластера VMware vSAN при сбоях


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

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

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

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

 Site Disaster Tolerance Failures to Tolerate VM Location Failure vSAN behavior HA behavior
None Preferred No data redundancy Site A or B Host failure Site A Objects are inaccessible if failed host contained one or more components of objects VM cannot be restarted as object is inaccessible
None Preferred RAID-1/5/6 Site A or B Host failure Site A Objects are accessible as there's site local resiliency VM does not need to be restarted, unless VM was running on failed host
None Preferred No data redundancy / RAID-1/5/6 Site A Full failure Site A Objects are inaccessible as full site failed VM cannot be restarted in Site B, as all objects reside in Site A
None Preferred No data redundancy / RAID-1/5/6 Site B Full failure Site B Objects are accessible, as only Site A contains objects VM can be restarted in Site A, as that is where all objects reside
None Preferred No data redundancy / RAID-1/5/6 Site A Partition Site A Objects are accessible as all objects reside in Site A VM does not need to be restarted
None Preferred No data redundancy / RAID-1/5/6 Site B Partition Site B Objects are accessible in Site A, objects are not accessible in Site B as network is down VM is restarted in Site A, and killed by vSAN in Site B
None Secondary No data redundancy / RAID-1/5/6 Site B Partition Site B Objects are accessible in Site B VM resides in Site B, does not need to be restarted
None Preferred No data redundancy / RAID-1/5/6 Site A Witness Host Failure No impact, witness host is not used as data is not replicated No impact
None Secondary No data redundancy / RAID-1/5/6 Site B Witness Host Failure No impact, witness host is not used as data is not replicated No impact
Site Mirroring No data redundancy Site A or B Host failure Site A or B Components on failed hosts inaccessible, read and write IO across ISL as no redundancy locally, rebuild across ISL VM does not need to be restarted, unless VM was running on failed host
Site Mirroring RAID-1/5/6 Site A or B Host failure Site A or B Components on failed hosts inaccessible, read IO locally due to RAID, rebuild locally VM does not need to be restarted, unless VM was running on failed host
Site Mirroring No data redundancy / RAID-1/5/6 Site A Full failure Site A Objects are inaccessible in Site A as full site failed VM restarted in Site B
Site Mirroring No data redundancy / RAID-1/5/6 Site A Partition Site A Objects are inaccessible in Site A as full site is partitioned and quorum is lost VM restarted in Site B
Site Mirroring No data redundancy / RAID-1/5/6 Site A Witness Host Failure Witness object inaccessible, VM remains accessible VM does not need to be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site B Full failure Site A Objects are inaccessible in Site A as full site failed VM does not need to be restarted as it resides in Site B
Site Mirroring No data redundancy / RAID-1/5/6 Site B Partition Site A Objects are inaccessible in Site A as full site is partitioned and quorum is lost VM does not need to be restarted as it resides in Site B
Site Mirroring No data redundancy / RAID-1/5/6 Site B Witness Host Failure Witness object inaccessible, VM remains accessible VM does not need to be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site A Network failure between Site A and B (ISL down) Site A binds with witness, objects in Site B becomes inaccessible VM does not need to be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site B Network failure between Site A and B (ISL down) Site A binds with witness, objects in Site B becomes inaccessible VM restarted in Site A
Site Mirroring No data redundancy / RAID-1/5/6 Site A or Site B Network failure between Witness and Site A/B Witness object inaccessible, VM remains accessible VM does not need to be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site A Full failure Site A, and simultaneous Witness Host Failure Objects are inaccessible in Site A and Site B due to quorum being lost VM cannot be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site A Full failure Site A, followed by Witness Host Failure a few minutes later Pre vSAN 7.0 U3: Objects are inaccessible in Site A and Site B due to quorum being lost VM cannot be restarted
Site Mirroring No data redundancy / RAID-1/5/6 Site A Full failure Site A, followed by Witness Host Failure a few minutes later Post vSAN 7.0 U3: Objects are inaccessible in Site A, but accessible in Site B as votes have been recounted VM restarted in Site B
Site Mirroring No data redundancy / RAID-1/5/6 Site B Full failure Site B, followed by Witness Host Failure a few minutes later Post vSAN 7.0 U3: Objects are inaccessible in Site B, but accessible in Site A as votes have been recounted VM restarted in Site A
Site Mirroring No data redundancy Site A Full failure Site A, and simultaneous host failure in Site B Objects are inaccessible in Site A, if components reside on failed host then object is inaccessible in Site B VM cannot be restarted
Site Mirroring No data redundancy Site A Full failure Site A, and simultaneous host failure in Site B Objects are inaccessible in Site A, if components do not reside on failed host then object is accessible in Site B VM restarted in Site B
Site Mirroring RAID-1/5/6 Site A Full failure Site A, and simultaneous host failure in Site B Objects are inaccessible in Site A, accessible in Site B as there's site local resiliency VM restarted in Site B

Таги: VMware, vSAN, Troubleshooting, HA, DR, Blogs

Возможность High Availability for Application Monitoring в решении VMware Aria Operations


Вчера мы писали о новых возможностях январского релиза облачного решения 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, Aria, Operations, HA, Monitoring

Первоначальная настройка StarWind SAN & NAS storage appliance


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


Таги: StarWind, SAN, NAS, Storage, HA, Virtual Appliance

Права доступа инициаторов к таргетам StarWind Virtual SAN - как это работает


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


Таги: StarWind, iSCSI, Virtual SAN, VSAN, Security, Storage, HA

Как отключить VMware vSphere Cluster Services при обслуживании кластера vSAN


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

Узлы кластера Witness node в инфраструктуре StarWind Virtual SAN - защита от ситуации split-brain


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


Таги: StarWind, HA, Storage

Улучшения VMware vSAN 7.0 Update 3 - пересчет голосов для обеспечения кворума при последовательных отказах


Одним из нововведений новой версии решения для обеспечения катастрофоустойчивости виртуальной инфраструктуры хранения 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, vSAN, Update, HA, DR, VMachines, Storage

Улучшения интерфейса в VMware vCenter 7.0 Update 3


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


Таги: VMware, HA, vCenter, Update, vSphere, Client

Настройка Challenge-Handshake Authentication Protocol (CHAP) в решении StarWind Virtual SAN


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


Таги: StarWind, iSCSI, Storage, Security, ESXi, VMware, Microsoft, Hyper-V, HA

Использование дисков VMDK на платформе VMware vSphere в режиме Multi-writer для кластерных решений


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


Таги: VMware, Clustering, Backup, HA, FT, VMachines, Storage, VMDK, VMFS

VMware Cloud Director Availability 4.2.1 - что там нового?


В августе компания 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), там есть простой мастер из нескольких шагов:

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

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

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


Таги: VMware, NSX, Cloud, Director, HA, DR, Enterprise, IaaS

Новый продукт StarWind SAN & NAS - хранилища iSCSI на базе Linux


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


Таги: StarWind, Virtual SAN, NAS, Storage, Linux, Virtual Appliance, HA, VMware, ESXi, vSphere, vCenter, Microsoft, Hyper-V

Как кластер VMware HA обрабатывает отказы Primary и Secondary хостов ESXi?


Как вы знаете, в кластере отказоустойчивости 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, vSphere, ESXi

Как сделать хост VMware vSphere Primary (он же Master) в кластере HA


Дункан Эппинг написал интересный пост о том, что в кластере 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:


Таги: VMware, HA, vSphere, ESXi, Blogs, FDM, vCenter

Обновленная версия StarWind Virtual SAN v8 for Hyper-V (build 14120) - что нового появилось в этом году


На днях компания 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 доступны тут (список улучшений там практически такой же, за исключением некоторых моментов в мартовской версии).


Таги: StarWind, Virtual SAN, Update, Storage, HA

Как работает VMware vSAN Enhanced Durability, если у вас всего 3 хоста на каждой площадке?


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

Дункан Эппинг рассказал о том, что происходит, если в нем всего три хоста. Например, если у вас есть 2 площадки, по три хоста ESXi на каждой, но в случае сконфигурированной политикии SFTT=1 (это Stretched FTT) у вас получается RAID-1 для дисковых объектов виртуальной машины на каждой из площадок:

При этом два хоста хранят в себе Data Component виртуальной машины, а третий хост работает для нее как Witness на случай изоляции одного из хостов кластера. Теперь возникает вопрос - а что произойдет с механизмом Enhanced Durability, если один из хостов перевести в Maintenance Mode? Где будет создаваться Durability Component (он хранит все поступающие операции записи Write IO), который защищает машину от сбоя на уровне площадки при переведенном в режим обслуживания хосте?

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

Ну и небольшое демо процесса тестирования механизма Enhanced Durability в этих условиях от Дункана:


Таги: VMware, vSAN, HA, Storage, DR, Stretched Cluster

Поддержка vSAN File Services для растянутых кластеров в обновлении VMware vSAN 7 Update 2


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

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

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

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

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

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


Таги: VMware, vSAN, File Services, SMB, Storage, HA, Stretched

Что такое и как работает техника Suspend-to-Memory при обновлении хостов VMware ESXi


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

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

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

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

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

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

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

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


Таги: VMware, vSphere, Upgrade, Update, ESXi, VMachines, HA, DRS, Memory

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8    >   >>
Интересное:





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

26/08/2024:  VMware Explore 2024 Лас-Вегас
04/11/2024:  VMware Explore 2024 Барселона

Быстрый переход:
VMware VMachines Offtopic NAKIVO vStack Gartner Veeam Vinchin StarWind Nakivo IT-Grad Cloud Teradici VeeamON VMworld PowerCLI Citrix VSAN GDPR 5nine Hardware Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud DevOps Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs IDC Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Update Avi Aria Broadcom Workstation Private AI EUC Community vSAN VCF Skyline NSX HCX AI Host Client Explore Chargeback Horizon Labs SASE Tanzu Workspace ONE Networking Backup Ransomware Tools Performance Lifecycle VCP Network AWS Intel API USB SDDC Fusion Whitepaper SD-WAN Mobile VMUG SRM ARM HCI Converter Photon OS Operations VEBA App Volumes Certification VMConAWS Workspace Imager SplinterDB DRS SAN vMotion Open Source iSCSI Partners HA Monterey Kubernetes V2V vForum Learning vRNI UAG Support Log Insight AMD vCSA NSX-T Graphics NVMe HCIBench SureBackup vCloud Обучение Web Client vExpert OpenStack UEM CPU PKS vROPs Stencils Bug VTL Forum Video Update Manager VVols DR Cache Storage DRS Visio Manager Virtual Appliance PowerShell LSFS Client Datacenter Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Encryption Nested XenDesktop VSA vNetwork SSO VMDK Appliance VUM HoL Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP iOS SC VMM VDP PCoIP RHEV vMA Award Licensing Logs Server Demo vCHS Calculator Бесплатно Beta Exchange MAP ONE DaaS Hybrid Monitoring VPLEX UCS GPU SDK Poster VSPP Receiver VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V KB VirtualCenter NFS ThinPrint ESA Troubleshooting Director Android Python Upgrade Stretched ML Hub Guardrails CLI VCPP Memory Driver Foundation HPC Orchestrator Optimization Bugs SVMotion Diagram Ports SIOC Plugin Helpdesk VIC VDS Migration Air DPM Flex Mac SSH VAAI Heartbeat MSCS Composer
Полезные постеры:

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Сравнение Oracle VirtualBox и VMware Workstation.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Работа с дисками виртуальных машин VMware.

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Полезные ресурсы:

Последние 100 утилит VMware Labs

Новые возможности VMware vSphere 8.0 Update 1

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



Copyright VM Guru 2006 - 2024, Александр Самойленко. Правила перепечатки материалов.
vExpert Badge