Новости Статьи VMware Veeam StarWind vGate! Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4110 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Veeam Agent для Linux и Windows - бесплатны для всех клиентов Veeam

О нововведениях VMware High Availability в vSphere 6.5.


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

На днях появилось интересное видео, подробно объясняющее, в чем именно они заключаются:

Во-первых, приоритет рестарта виртуальных машин был расширен - вместо трех уровней (Low, Medium и High) появилось пять (добавились Lowest и Highest). Это позволит увеличить гранулярность приоритета запуска виртуальных машин при сбое, которой, видимо, хватало не всем:

Во-вторых, появились возможности восстановления виртуальных машин с учетом связи сервисов в ВМ между собой. Теперь VMware HA позволяет учитывать взаимосвязи сервисов в виртуальных машинах при их рестарте в случае сбоя на основе заданных правил зависимостей VM-to-VM по приоритетам восстановления.

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

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

А вот если выйдет из строя третий хост ESXi - то VM5 и VM7 могут запуститься одновременно, согласно правилу во второй строчке (VM5<-VM6<-VM7<-VM8), так как для VM5 нет предварительного условия старта, а для VM7 условие старта выполнено - машина VM6 работает. Поэтому в данном случае добавляется еще одно правило VM5<-VM7. Имейте это в виду при планировании виртуальной инфраструктуры и кластеров HA.

Настраиваются такие правила довольно просто. Сначала в интерфейсе настройки VMware HA мы создаем несколько групп VM/Host Group, в каждую из которых добавляем только по одной виртуальной машине:

А далее устанавливаем правила (VM/Host Rules) типа "Virtual Machines to Virtual Machines" для данных групп, где определяем, какую ВМ нужно запускать сначала, а какую вслед за ней.

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


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

Высокая доступность VMware vCenter Server Appliance High Availability - как это работает.


Как мы писали ранее, в новой версии платформы VMware vSphere 6.5 появились встроенные возможности обеспечения высокой доступности сервера vCenter, правда только если он развернут на базе виртуального модуля vCenter Server Appliance (vCSA). Для стандартного vCenter Server for Windows высокая доступность обеспечивается средствами MSCS/WFCS.

Функция vCenter Server High Availability позволяет обеспечить доступность для сервисов vCSA, развернув 2 экземпляра виртуального модуля и компонент Witness, обеспечивающий защиту от ситуации Split Brain:

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

Между активным и пассивным узлами кластера серверов vCenter производится репликация на базе технологии Linux RSYNC, которая работает на уровне файлов, реплицируя конфигурацию всего сервера управления. Для репликации основной базы данных VCDB и базы данных Update Manager (VUMDB) используются средства Native vPostgres DB replication.

Если текущий узел vCSA испытывает проблемы с доступностью, происходит переключение на резервный узел (FQDN-имя сервера сохраняется без изменений):

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

Есть 2 типа развертывания vCenter HA - это Basic и Advanced. В режиме Basic все происходит почти в автоматическом режиме - администратору потребуется только настроить IP-адреса, размещение машин на хостах и хранилищах, и все - дальше мастер настройки сделает все сам.

Но режим Basic доступен только когда серверы vCenter будут находиться у вас в одном домене SSO, а сами машины vCSA будут под управлением одного vCenter (то есть, в одном инвентори).

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

  1. Добавить второй NIC на машину с VCSA, который нужно присоединить к VCHA Network Portgroup.
  2. Через интерфейс VAMI (https://IP_FQDN:5480) настроить статический IP-адрес для внутренней сети VCHA.
  3. В мастере VCHA Configuration Wizard выбрать опцию Advanced.
  4. Задать IP-адреса узлов и компонентов Witness.
  5. Склонировать виртуальную машину VCSA дважды, убедившись, что в спецификации Guest Customization указаны IP-адреса вторых адаптеров (NIC), которые вы создали для каждого клона.
  6. Включить каждый узел и завершить на нем мастер конфигурации.

Выглядит режим Advanced следующим образом:

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


Таги: VMware, vCenter, HA, vCSA

Новые документы VMware: производительность vCenter HA, Update Manager и другое.


На днях компания VMware выпустила несколько интересных технических документов, которые могут оказаться полезными в свете выхода новой версии платформы виртуализации VMware vSphere 6.5. Но для начала - интересный ролик о создании кластеров VMware Virtual SAN в маршрутизируемых сетях:

Видео будет полезно всем тем, кто хочет создавать распределенные кластеры Virtual SAN, разнося узлы по разным подсетям. На эту тему есть также несколько полезных ресурсов:

Кроме того, компания VMware выпустила открытый документ "vCenter Server 6.5 High Availability Performance and Best Practices", где описываются сервисы высокой доступности, которые появились в виртуальном модуле VMware vCenter Server Appliance 6.5.

В рамках стрессового тестирования, описанного в документе, были проверены следующие аспекты работы VCHA (vCenter High Availability):

  • Скорость восстановления VCHA и выполнение политики recovery time objective (RTO)
  • Производительность сервера при включенном VCHA
  • Накладные расходы VCHA
  • Влияние на статистики vCenter Server
  • Влияние на сеть
  • Сравнение External Platform Services Controller (PSC) со встроенным Embedded PSC

Второй документ - это "vSphere 6.5 Update Manager Performance and Best Practices". Там описаны лучшие практики по эксплуатации VMware Update Manager и рассказано о производительности VUM. Весьма интересна следующая картинка из документа:

Выходит, что VUM on Linux (который интегрирован с vCSA) работает существенно быстрее, чем его коллега под Windows (в 2 раза для некоторых операций).

Третий документ - "vSphere Virtual Machine Encryption Performance". Не так давно мы писали о том, как работает механизм шифрования в VMware vSphere 6.5, а из этого документа вы узнаете, насколько быстро он работает.

В документе множество графиков, показывающих, что latency при шифровании особенно не меняется (незначительно увеличивается), а вот нагрузка на CPU увеличивается где-то на 20%, что, впрочем, тоже не так уж и много.


Таги: VMware, Whitepaper, VUM, HA, vCenter, Performance

Вышла обновленная версия Extrasphere 2.0 - новые возможности.


Некоторое время назад мы писали об утилите Extrasphere от русских разработчиков, которая позволяет делать бесплатный vMotion для бесплатных серверов VMware ESXi.

Коллеги продолжают работать над этим средством и на днях выпустили версию Extrasphere 2.0, где присутствует весьма интересная функциональность HotMirror. На этот раз она не бесплатна, а доступна на базе подписки за деньги.

Она предназначена для получения холодного резерва функционирующей виртуальной машины (что дает нулевое RPO) на том же самом или резервном сервере виртуализации ESXi 5.5 и старше. Допускается использование гипервизоров с бесплатными лицензиями (ESXi Free, он же vSphere Hypervisor).

Сама утилитка написана на Unity (я думал, что на нем только игры делают):

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

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

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

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

Существует две стадии зеркалирования:

  1. Режим синхронизации.
  2. Синхронный режим.

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

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

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

  1. Откат к снимку состояния исходной виртуальной машины или зеркала.
  2. Перезагрузка сервера виртуализации

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

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

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

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

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

При использовании утилиты Extrasphere с режимом HotMirror есть несколько важных моментов:

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

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

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

Скачать Extrasphere 2.0 можно по этой ссылке.


Таги: VMware, vSphere, HA, FT, Бесплатно, ESXi

Как VMware HA и Virtual SAN обрабатывают изоляцию площадки для виртуальных машин.


Интересный пост написал Duncan Epping о растянутом кластере (Stretched Cluster) Virtual SAN и обработке события изоляции площадки механизмами HA и VSAN. Изложим тут его вкратце.

Как вы знаете, растянутый кластер Virtual SAN состоит из трех компонентов - две площадки с хранилищами VSAN и виртуальными машинами и одна площадка, выступающая как "свидетель" (Witness) и необходимая для принятия решения о том, какая площадка выпала из внешнего мира (то есть с ней нет связи), а какая способна продолжать поддерживать работу виртуальных машин (как в плане хранения, так и в плане исполнения на вычислительных ресурсах хостов).

Таким образом, обычно схема растянутого кластера выглядит так:

Теперь, допустим, на основной площадке (Site 1) произошла авария - и хосты ESXi с виртуальными машинами стали частично или полностью недоступны. При этом теряется ее связь как со второй площадкой (Site 2), так и с компонентом Witness на третьей площадке.

В этом случае происходит следующее:

  • Хосты площадки Site 1 имеют связь между собой, события внутренней изоляции не происходит, поэтому HA не реагирует на ситуацию.
  • Однако кластер Virtual SAN понимает, что площадка Site 1 изолирована от Site 2 и Witness (нет кворума), а значит и от внешнего мира, поэтому принимает решение выключить виртуальные машины. Это поведение можно изменить, установив расширенную настройку VSAN.AutoTerminateGhostVm в значение 0 (но делать это не рекомендуется).
  • На второй площадке (Site 2) происходят выборы нового Master-узла в кластере VMware HA. Этот узел сверяется со списком protectedlist (в нем пока нет машин из Site 1), добавляет новые ВМ туда и берет на себя владение машинами с первого узла, так как теперь есть кворум у второй площадки. Что такое кворум? Это 2 компонента из трех (большинство) в растянутом кластере - сама эта площадка и компонент Witness (они видят связь друг с другом). Таким образом, VMware HA на второй площадке начинает восстановление виртуальных машин первого сайта.
  • Как VMware HA убеждается, что на первой площадке эти машины выключены? Да никак - просто по дизайну заложено, что кластер Virtual SAN в случае изоляции площадки Site 1 потушит все ее виртуальные машины, поэтому владение этими машинами перейдет ко второй площадке.

Ну и, конечно же, тут нельзя не порекомендовать интереснейший документ VMware vSphere 6.x HA Deepdive, в котором есть все ответы на подобные вопросы.


Таги: VMware, HA, Stretched, Virtual SAN, VSAN, Blogs, vSphere, ESXi

Новый документ от StarWind: "High Availability Features in SQL Server 2016 Standard Edition".


Компания StarWind Software, производитель лучшего решения для создания отказоустойчивых хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, выпустила новый документ "High Availability Features in SQL Server 2016 Standard Edition", посвященным возможностям высокой доступности, интегрированным в новую версию СУБД SQL Server 2016 Standard Edition:

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


Таги: StarWind, SQL, Server, HA

Бесплатная книга по механизму VMware HA в vSphere.


Многие из вас знают блоггера Дункана Эппинга, который уже многие годы пишет о технических аспектах платформы виртуализации VMware vSphere, особенно фокусируясь на вопросах доступности виртуальных машин (механизм VMware HA) и кластеризации хранилищ Virtual SAN. В целом-то, на сегодняшний день это главный эксперт по VMware HA. Так вот, Дункан решил сделать полностью бесплатным свое техническое руководство по VMware HA "vSphere 6.x HA Deepdive", которое доступно онлайн на GitBook.

Также книжку можно скачать в следующих форматах:

Особенно большой интерес представляют пункты про работу механизма VMware HA Admission Control (мы писали об этом тут), а также описание расширенных настроек (HA Advanced Settings).


Таги: VMware, vSphere, HA, Book, Бесплатно, Virtual SAN

Сценарии, когда нужно отключить Site / Data Locality для растянутого кластера VMware Virtual SAN.


Какое-то время назад мы писали о функции Data Locality, которая есть в решении для создания отказоустойчивых кластеров VMware Virtual SAN. Каждый раз, когда виртуальная машина читает данные с хранилища, они сохраняются в кэше (Read Cache) на SSD-накопителе, и эти данные могут быть востребованы очень быстро. Но в рамках растянутого кластера (vSphere Stretched Cluster) с высокой скоростью доступа к данным по сети передачи данных, возможно, фича Site / Data Locality вам не понадобится. Вот по какой причине.

Если ваши виртуальные машины часто переезжают с хоста на хост ESXi, при этом сами хосты географически разнесены в рамках VSAN Fault Domains, например, по одному зданию географически, то срабатывает функция Site Locality, которая требует, чтобы кэш на чтение располагался на том же узле/сайте, что и сами дисковые объекты машины. Это отнимает время на прогрев кэша хоста ESXi на новом месте для машины, а вот в скорости в итоге особой прибавки не дает, особенно, если у вас высокоскоростное соединение для всех серверов в рамках здания.

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

[root@esxi-01:~] esxcfg-advcfg -g /VSAN/DOMOwnerForceWarmCache

Value of DOMOwnerForceWarmCache is 0

Устанавливаем значение в 1, если хотим отключить принудительный прогрев кэша при смене площадки размещения машины:

[root@esxi-01:~] esxcfg-advcfg -s 1 /VSAN/DOMOwnerForceWarmCache

Value of DOMOwnerForceWarmCache is 1

Таги: VMware, Virtual SAN, DR, Stretched, HA, Performance

Доступность кластера VMware Virtual SAN - шесть девяток (99,9999%). Доказательство!


Компания VMware в своем блоге, посвященном продуктам линейки VMware vSphere, представила интереснейшее доказательство, что кластер VMware Virtual SAN дает надежность "шесть девяток", то есть доступность данных 99,9999% времени в году. А это меньше, чем 32 секунды простоя в год.

Бесспорно, приведенное ниже "доказательство" основано на множестве допущений, поэтому заявление о шести девятках является несколько популистским. С моей точки зрения, гораздо более вероятно, что админ с бодуна не туда нажмет, или, например, в команде vmkfstools укажет не тот LUN и снесет все виртуальные машины на томе VMFS (привет, Антон!), чем откажет оборудование с дублированием компонентов. Но все же, рассмотрим это доказательство ниже.

Прежде всего, введем 2 понятия:

  • AFR – Annualized Failure Rate, то есть вероятность отказа в год (носителя данных или другого компонента), выраженная в процентах.
  • MTBF – Mean Time Between Failures (среднее время между отказами). Это время в часах.

Эти 2 величины взаимосвязаны и выражаются одна через другую в соответствии с формулой:

AFR = 1/(MTBF/8760) * 100%

Обычно, как HDD, так и SSD накопители, имеют AFR от 0.87% до 0.44%, что дает от 1 000 000 до 2 000 000 часов MTBF. Далее для примера берут диск 10K HDD от Seagate (популярная модель ST1200MM0088), для которой AFR равен 0.44% (см. вторую страницу даташита) или 2 миллиона часов в понятии MTBF. Ну и взяли популярный SSD Intel 3710 для целей кэширования, который также имеет MTBF на 2 миллиона часов.

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

2 000 000/ (2 000 000 + 24) = 0,99998

То есть, 4 девятки. Но диск - это еще не весь сервис. Есть еще надежность дискового контроллера, самого хост-сервера и стойки в целом (по питанию). VMware запросила данные у производителей и получила следующие параметры доступности:

  • Rack: 0,99998
  • Host: 0,9998
  • Controller: 0,9996

Итого, мы имеем доступность:

0,99998 (Rack) * 0,9998 (Host) * 0,9996 (Controller) * 0,99998 (SSD Cache) * 0,99998 (SSD/HDD Capacity) = 0,9993

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

0,9999 (Rack) * 0,999 (Host) * 0,999 (Controller) * 0,9999 (SSD Cache) * 0,9999 (SSD/HDD Capacity) = 0,997

Получается 2 девятки, а это 3,65 дня простоя в год, что уже довольно критично для многих бизнесов.

Ну а теперь применим технологию VMware Virtual SAN, которая дублирует данные на уровне виртуальных машин и отдельных виртуальных дисков. Если мы используем параметр FTT (Numbers of failures to tolerate) равный 1, что подразумевает хранение одной реплики данных, то вероятность недоступности хранилища Virtual SAN данных будет равна вероятности отказа 2-х хранилищ одновременно, то есть:

(1-0.997)^2 = 0.00000528

Ну а доступность в данном случае равна:

1-0.00000528 = 0.999994

То есть, уже 5 девяток. Но это доступность для одного объекта VSAN, а отдельная виртуальная машина обычно имеет несколько объектов, допустим, 10. Тогда ее доступность будет равна:

0.999994^10 = 0.99994

В итоге, 4 девятки. Это 52,56 минуты простоя в год. В зависимости от того, сколько объектов у вас будет на одну ВМ, вы будете иметь доступность от 4 до 5 девяток.

А теперь возьмем FTT=2, то есть конфигурацию, когда имеется 2 дополнительных копии данных для каждого объекта в кластере Virtual SAN. В этом случае вероятность полного отказа всех трех копий данных:

(1-0.997)^3 = 0.00000001214

А доступность для ВМ с десятью объектами:

0.999999988^10 = 0.999999879

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


Таги: VMware, Virtual SAN, HA, VSAN, Enterprise, Blog, Availability, Storage

Обеспечение отказоустойчивости компонента VASA Vendor Provider (VP) для томов VVols в VMware vSphere.


Интересная статья от Дункана Эппинга была опубликована в его блоге пару недель назад. Если вы хотите использовать виртуальные тома VVols, которые обладают некоторыми преимуществами по сравнению с традиционной файловой системой VMware VMFS, то для некоторых систем, поддерживающих механизм VASA (vSphere API for Storage Awareness), потребуется использовать внешний виртуальный модуль VASA Vendor Provider (VP). То есть, некоторые аппаратные хранилища уже содержат в себе готовые модули и прошитые в них модули VP, а вот для некоторых нужно запускать и поддерживать специальную виртуальную машину, выполняющую сервисные функции при работе виртуальных машин с хранилищами VVols.

Прежде всего VP используется для выполнения операции Bind (привязка машины к VVol), которая инициируется при запуске виртуальной машины. В этом случае VP создает точку доступа ввода-вывода (IO access point) для виртуального тома VVol на выбранном Protocol Endpoint (PE). Без этой операции машина не запустится, из чего следует, что критически важно поддерживать виртуальную машину с VP непрерывно доступной. У разных вендоров используются разные уровни доступности:

  • Кто-то выпускает модуль с возможностью active/standby или active/active-конфигурации виртуальных машин на разных хостах.
  • Ну а кто-то надеется на встроенные механизмы обеспечения отказоустойчивости VMware HA и VMware Fault Tolerance (FT).

Очевидно, что если вы выбираете хранилище с внешним VP, то очень желательно, чтобы там был реализован первый вариант обеспечения доступности. Ну и нельзя помещать виртуальную машину с VASA VP на том VVol, чтобы не оказаться в ловушке невозможности запуска этой виртуальной машины.

Со временем VMware планирует включить операции bind/unbind в стандарт T10 SCSI, и сервисная виртуальная машина будет не нужна, но эти вещи, как вы понимаете, делаются не быстро, поэтому пока обеспечивайте отказоустойчивость виртуальных модулей VP, по крайней мере, с помощью технологий VMware HA и VMware Fault Tolerance.

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


Таги: VMware, VVOls, HA, FT, Storage, vSphere, Hardware

Что произойдет с инфраструктурой VMware vSphere, если vCenter окажется недоступен?


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

Если вы знаете, где находится vCenter, то нужно зайти на хост ESXi через веб-консоль Embedded Host Client (который у вас должен быть развернут) и запустить/перезапустить ВМ с управляющим сервером. Если же вы не знаете, где именно ваш vCenter был в последний раз, то вам поможет вот эта статья.

Ну а как же повлияет недоступность vCenter на функционирование вашей виртуальной инфраструктуры? Давайте взглянем на картинку:

Зеленым отмечено то, что продолжает работать - собственно, виртуальные машины на хостах ESXi. Оранжевое - это то, что работает, но с некоторыми ограничениями, а красное - то, что совсем не работает.

Начнем с полностью нерабочих компонентов в случае недоступности vCenter:

  • Централизованное управление инфраструктурой (Management) - тут все очевидно, без vCenter ничего работать не будет.
  • DRS/Storage DRS - эти сервисы полностью зависят от vCenter, который определяет хосты ESXi и хранилища для миграций, ну и зависят от технологий vMotion/Storage vMotion, которые без vCenter не работают.
  • vMotion/SVMotion - они не работают, когда vCenter недоступен, так как нужно одновременно видеть все серверы кластера, проверять кучу различных условий на совместимость, доступность и т.п., что может делать только vCenter.

Теперь перейдем к ограниченно доступным функциям:

  • Fault Tolerance - да, даже без vCenter ваши виртуальные машины будут защищены кластером непрерывной доступности. Но вот если один из узлов ESXi откажет, то новый Secondary-узел уже не будет выбран для виртуальной машины, взявшей на себя нагрузку, так как этот функционал опирается на vCenter.
  • High Availability (HA) - тут все будет работать, так как настроенный кластер HA функционирует независимо от vCenter, но вот если вы запустите новые ВМ - они уже не будут защищены кластером HA. Кроме того, кластер HA не может быть переконфигурирован без vCenter.
  • VMware Distributed Switch (vDS) - распределенный виртуальный коммутатор как объект управления на сервере vCenter работать перестанет, однако сетевая коммуникация между виртуальными машинами будет доступна. Но вот если вам потребуется изменить сетевые настройки виртуальной машины, то уже придется прицеплять ее к обычному Standard Switch, так как вся конфигурация vDS доступна для редактирования только с работающим vCenter.
  • Other products - это сторонние продукты VMware, такие как vRealize Operations и прочие. Тут все зависит от самих продуктов - какие-то опираются на сервисы vCenter, какие-то нет. Но, как правило, без vCenter все довольно плохо с управлением сторонними продуктами, поэтому его нужно как можно скорее поднимать.

Для обеспечения доступности vCenter вы можете сделать следующее:

  • Защитить ВМ с vCenter технологией HA для рестарта машины на другом хосте ESXi в случае сбоя.
  • Использовать кластер непрерывной доступности VMware Fault Tolerance (FT) для сервера vCenter.
  • Применять технику кластеризации машин с vCenter, как описано в документе "Setup for Failover Clustering and Microsoft Cluster Service". Это полностью поддерживается, начиная с vCenter 5.5 Update 2.

Таги: VMware, vCenter, HA, ESXi

Какая полоса пропускания необходима для "растянутого кластера" (VMware Virtual SAN Stretched Cluster)?


Мы уже писали о том, что "растянутый" кластер VMware HA Stretched Cluster прекрасно работает и поддерживается вместе с отказоустойчивыми хранилищами Virtual SAN. Также мы писали о документе с лучшими практиками по построению таких кластеров, для которых требуется обеспечивать максимальную производительность.

Однако многие задаются вопросом - а как планировать ширину канала между площадками таких растянутых кластеров, чтобы обеспечить необходимую пропускную способность для синхронизации узлов кластера VMware Virtual SAN? В помощь таким пользователям компания VMware выпустила интересный документ "VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance", в котором даются конкретные параметры и формулы для расчета необходимой пропускной способности между площадками.

Архитектура растянутого кластера в общем случае выглядит так:

Таким образом, имеет место быть 2 связи - между двумя площадками как узлами кластера, а также между каждой из площадок и компонентом Witness, следящим за состоянием каждой из площадок и предотвращающим сценарии Split Brain.

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

Как известно, реальный трафик состоит из отношения операций чтения и записи, которое зависит от характера нагрузки. Например, в VDI-среде это отношение составляет примерно 30/70, то есть 30% - это операции чтения (read), а 70% - операции записи (write).

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

B = Wb * md * mr

где:

  • Wb - полоса записи данных.
  • md - множитель данных, он зависит от потока метаданных кластера VSAN и сервисных операций. VMware рекомендует использовать значение 1,4 для этого параметра.
  • mr - множитель ресинхронизации. Для целей ресинхронизации VMware рекомендует заложить в канал еще 25%, то есть использовать значение этого параметра 1,25.

Например, рабочая нагрузка у вас составляет 10 000 IOPS на запись (10 тысяч операций в секунду). Возьмем типичный размер операции записи в 4 КБ и получим параметр Wb:

Wb = 10 000 * 4KB = 40 MB/s = 320 Mbps

Мегабайты в секунду переводятся в мегабиты умножением на 8. Ну и заметим, что требование канала по записи нужно умножать на 1,4*1,25 = 1,75. То есть канал нужно закладывать почти в 2 раза больше от требований по записи данных.

Теперь считаем требуемую пропускную способность канала между площадками:

B = Wb * md * mr = 320 Mbps * 1,4 * 1,25 = 560 Mbps

Ну а в самом документе вы найдете еще больше интересных расчетов и примеров.


Таги: VMware, Virtual SAN, Stretched Cluster, HA, Performance, vNetwork

2 или 3 узла использовать для кластера хранилищ StarWind Virtual SAN? Приходите на вебинар, чтобы узнать!


Мы часто пишем о решении для создания отказоустойчивых хранилищ StarWind Virtual SAN, которое помогает существенно сэкономить при построении инфраструктуры хранения виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Вот в этой статье мы писали о том, что 3 узла для кластера - это лучше, надежнее и экономнее (в пересчете на единицу емкости), чем 2. Это обеспечивает аптайм хранилищ до 99.9999%. Но иногда и 2 узла вполне достаточно с точки зрения экономии на программном и аппаратном обеспечении.

Приходите на бесплатный вебинар "VMware and Fault-Tolerance. Which is Better for Your Backup: 2 or 3 Nodes Hyperconverged?", чтобы узнать, сколько узлов для кластера нужно использовать и в каких ситуациях.

Бесплатный вебинар пройдет 10 ноября в 22-00 по московскому времени. Регистрируйтесь!


Таги: StarWind, Webinar, HA

vCenter Server Watchdog - сервисы контроля и восстановления доступности vCenter.


На блоге vSphere появилась отличная статья о сервисах семейства vCenter Server Watchdog, которые обеспечивают мониторинг состояния различных компонентов vCenter, а также их восстановление в случае сбоев. Более подробно о них также можно прочитать в VMware vCenter Server 6.0 Availability Guide.

Итак, сервисы Watchdog бывают двух типов:

  • PID Watchdog - мониторит процессы, запущенные на vCenter Server.
  • API Watchdog - использует vSphere API для мониторинга функциональности vCenter Server.

Сервисы Watchdog пытаются рестартовать службы vCenter в случае их сбоя, а если это не помогает, то механизм VMware перезагружает виртуальную машину с сервером vCenter на другом хосте ESXi.

PID Watchdog

Эти службы инициализируются во время инициализации самого vCenter. Они мониторят только службы, которые активно работают, и если вы вручную остановили службу vCenter, поднимать он ее не будет. Службы PID Watchdog, контролируют только лишь наличие запущенных процессов, но не гарантируют, что они будут обслуживать запросы (например, vSphere Web Client будет обрабатывать подключения) - этим занимается API Watchdog.

Вот какие сервисы PID Watchdog бывают:

  • vmware-watchdog - этот watchdog обнаруживает сбои и перезапускает все не-Java службы на сервере vCenter Server Appliance (VCSA).
  • Java Service Wrapper - этот watchdog обрабатывает сбои всех Java-служб на VCSA и в ОС Windows.
  • Likewise Service Manager - данный watchdog отвечает за обработку отказов всех не-Java служб сервисов platform services.
  • Windows Service Control Manager - отвечает за обработку отказов всех не-Java служб на Windows.

vmware-watchdog

Это шелл-скрипт (/usr/bin/watchdog), который располагается на виртуальном модуле VCSA. Давайте посмотрим на его запущенные процессы:

mgmt01vc01.sddc.local:~ # ps -ef | grep vmware-watchdog
root 5767 1 0 16:20 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -s rhttpproxy -u 30 -q 5 /usr/sbin/rhttpproxy -r /etc/vmware-rhttpproxy/config.xml -d /etc/vmware-rhttpproxy/endpoints.conf.d -f /etc/vmware-rhttpproxy/endpo root 7930 1 0 16:21 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vws -u 30 -q 5 /usr/lib/vmware-vws/bin/vws.sh root 8109 1 0 16:21 ? 00:00:11 /bin/sh /usr/bin/vmware-watchdog -s syslog -u 30 -q 5 -b /var/run/rsyslogd.pid /sbin/rsyslogd -c 5 -f /etc/vmware-rsyslog.conf root 8266 1 0 16:21 ? 00:00:11 /bin/sh /usr/bin/vmware-watchdog -b /storage/db/vpostgres/postmaster.pid -u 300 -q 2 -s vmware-vpostgres su -s /bin/bash vpostgres -c 'LD_LIBRARY_PATH=/opt/vmware/vpostgres/curre root 9422 1 0 16:21 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -a -s vpxd -u 3600 -q 2 /usr/sbin/vpxd root 13113 1 0 16:22 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vsan-health -u 600 -q 10 su vsan-health -c '/opt/vmware/bin/vmware-vsan-health /usr/lib/vmware-vpx/vsan-health/VsanHealthServer.py -p 8006' root 28775 19850 0 20:42 pts/0 00:00:00 grep vmware-watchdog

В понятном виде это можно представить так:

Служба Имя процесса Перезапускать ВМ? Минимальный аптайм Число перезагрузок
Reverse Proxy rhttpproxy Нет 30 секунд 5
vCenter Management Web Service vws Нет 30 секунд 5
Syslog Collector Syslog Нет 30 секунд 5
vPostgres Database vmware-vpostgres Нет 5 минут 2
vCenter Server vpxd Да 1 час 2
VSAN Health Check vsan-health Нет 10 минут 10

Давайте разберем эти параметры на примере наиболее важной службы VPXD:

-a
-s vpxd
-u 3600
-q 2

Это означает, что:

vpxd (-s vpxd) запущен (started), для него работает мониторинг, и он будет перезапущен максимум дважды в случае сбоя (-q 2). Если это не удастся в третий раз при минимальном аптайме 1 час (-u 3600 - число секунд), виртуальная машина будет перезагружена (-a).

Полный список параметров представлен ниже:

-d = DAEMONIZE
-n = QUIET
-b = BG_PROC-s = START
-k = STOP
-r = QUERY
-a = REBOOT_FLAG
-u = MIN_UPTIME
-q = MAX_QUICK_FAILURES
-t = MAX_TOTAL_FAILURES
-i = IMMORTAL
-c = CLEANUP_CMD
-f = EXIT_CLEANUP_CMD

Java Service Wrapper

Он основан на Tanuki Java Service Wrapper и нужен, чтобы обнаруживать сбои в Java-службах vCenter (как обычного, так и виртуального модуля vCSA). Вот какие службы мониторятся:

mgmt01vc01.sddc.local:~ # ps -ef | grep tanuki
cm 6331 6324 0 16:20 ? 00:00:37 /usr/java/jre-vmware/bin/vmware-cm -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -Dlog4j.configuration=cm-log4j.properties -Dxml.config=ht root 6876 6869 0 16:20 ? 00:00:50 /usr/java/jre-vmware/bin/vmware-cis-license -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=TRUE -XX:+ForceTimeHighRe root 7267 7258 1 16:21 ? 00:03:45 /usr/java/jre-vmware/bin/vmware-sca -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/lo root 7634 7627 0 16:21 ? 00:00:29 /usr/java/jre-vmware/bin/vmware-syslog-health -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -DlogDir=/var/log/vmware/syslog -Dlog4j.config 1002 7843 7836 0 16:21 ? 00:01:08 /usr/java/jre-vmware/bin/vmware-vapi-endpoint -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -Dlog4j.configuration=file:/etc/vmware-vapi//e root 8453 8433 1 16:21 ? 00:02:55 /usr/java/jre-vmware/bin/vmware-invsvc -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dvim.logdir=/var/log/vmware/invsvc -XX:+ForceTimeHighResolution -XX:+ParallelRefP root 10410 10388 0 16:22 ? 00:00:54 /usr/java/jre-vmware/bin/vmware-sps -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dxml.config=../conf/sps-spring-config.xml -Dpbm.config=../conf/pbm-spring-config.xml 1007 11099 11088 0 16:22 ? 00:01:27 /usr/java/jre-vmware/bin/vmware-vpx-workflow -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -ea -Dlog4j.configuration=conf/workflow.log4j.p root 23423 19850 0 20:41 pts/0 00:00:00 grep tanuki

Если Java-приложение или JVM (Java Virtual Machine) падает, то перезапускается JVM и приложение.

Likewise Service Manager

Это сторонние средства Likewise Open stack от компании BeyondTrust, которые мониторят доступность следующих служб, относящихся к Platform Services среды vCenter:

  • VMware Directory Service (vmdir)
  • VMware Authentication Framework (vmafd, который содержит хранилище сертификатов VMware Endpoint Certificate Store, VECS)
  • VMware Certificate Authority (vmca)

Likewise Service Manager следит за этими сервисами и перезапускает их в случае сбоя или если они вываливаются.

mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm list | grep vm
vmafd running (standalone: 5505)
vmca running (standalone: 5560)
vmdir running (standalone: 5600)

Вместо параметра list можно также использовать start и stop, которые помогут в случае, если одна из этих служб начнет подглючивать. Вот полный список параметров Likewise Service Manager:

list          List all known services and their status
autostart Start all services configured for autostart
start-only <service> Start a service
start <service> Start a service and all dependencies
stop-only <service> Stop a service
stop <service> Stop a service and all running dependents
restart <service> Restart a service and all running dependents
refresh <service> Refresh service's configuration
proxy <service> Act as a proxy process for a service
info <service> Get information about a service
status <service> Get the status of a service
gdb <service> Attach gdb to the specified running service

А вот таким образом можно узнать детальную информацию об одном из сервисов:

mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm info vmdir
Service: vmdir
Description: VMware Directory Service
Type: executable
Autostart: yes
Path: /usr/lib/vmware-vmdir/sbin/vmdird
Arguments: '/usr/lib/vmware-vmdir/sbin/vmdird' '-s' '-l' '0' '-f' '/usr/lib/vmware-vmdir/share/config/vmdirschema.ldif'
Environment:
Dependencies: lsass dcerpc vmafd

Помните также, что Likewise Service Manager отслеживает связи служб и гасит/поднимает связанные службы в случае необходимости.

API Watchdog

Этот сервис следит через vSphere API за доступностью самого важного сервиса vCenter - VPXD. В случае сбоя, этот сервис постарается 2 раза перезапустить VPXD, и если это не получится - он вызовет процедуру перезапуска виртуальной машины механизмом VMware HA.

Эти службы инициализируются только после первой загрузки после развертывания или обновления сервисов vCenter. Затем каждые 5 минут через vSphere API происходит аутентификация и опрос свойства rootFolder для корневой папки в окружении vCenter.

Далее работает следующий алгоритм обработки отказов:

  • Первый отказ = Restart Service
  • Второй отказ = Restart Service
  • Третий отказ = Reboot Virtual Machine
  • Сброс счетчика отказов происходит через 1 час (3600 секунд)

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

  • storage/core/*.tgz - на виртуальном модуле VCSA
  • C:\ProgramData\VMware\vCenterServer\data\core\*.tgz - не сервере vCenter

Конфигурация сервиса API Watchdog (который также называется IIAD - Interservice Interrogation and Activation Daemon) хранится в JSON-формате в файле "iiad.json", который можно найти по адресу /etc/vmware/ на VCSA или C:\ProgramData\VMware\vCenterServer\cfg\iiad.json на Windows-сервер vCenter:

mgmt01vc01.sddc.local:/ # cat /etc/vmware/iiad.json
{
"requestTimeout": 20,
"hysteresisCount": 4,
"remediatedHysteresisCount": 6,
"rebootShellCmd": null,
"restartShellCmd": null,
"maxTotalFailures": 50,
"needShellOnWin": true,
"watchdogDisabled": false,
"vpxd.watchdogDisabled": false,
"createSupportBundle": true,
"automaticServiceRestart": true,
"automaticSystemReboot": false,
"maxSingleRestarts": 3,
"maxSingleFailures": 2
}

Вот что это значит:

  • requestTimeout – дефолтный таймаут для запросов по умолчанию.
  • hysteresisCount – позволяет отказам постепенно "устаревать" - каждое такое значение счетчика при отказе, число отсчитываемых отказов будет уменьшено на один.
  • rebootShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском ВМ.
  • restartShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском сервиса.
  • maxTotalFailures – необходимое число отказов по всем службам, которое должно случиться, чтобы произошел перезапуск виртуальной машины.
  • needShellOnWin – определяет, нужно ли запускать сервис с параметром shell=True на Windows.
  • watchdogDisabled – позволяет отключить API Watchdog.
  • vpxd.watchdogDisabled – позволяет отключить API Watchdog для VPXD.
  • createSupportBundle – нужно ли создавать support-бандл перед перезапуском сервиса или рестартом ВМ.
  • automaticServiceRestart – нужно ли перезапускать сервис при обнаружении сбоя или просто записать это в лог.
  • automaticSystemReboot – нужно ли перезапускать ВМ при обнаружении сбоя или просто записать в лог эту рекомендацию.
  • maxSingleRestarts – верхний лимит попыток перезапуска упавшего сервиса.
  • maxSingleFailures – число отказов, требуемой для срабатывания действия по перезапуску сервиса.

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

  • /var/log/vmware/iiad/* - на виртуальном модуле VCSA
  • %VMWARE_LOG_DIR%/iiad/* - в ОС Windows

Вот такой небольшой deep dive в службы доступности сервисов vCenter:)


Таги: VMware, vCenter, HA, Troubleshooting, vSphere

Бесплатный вебинар StarWind: VMware and Fault-Tolerance: Why Are 3 Nodes Better Than 2 for Hyper-Converged Architecture?


20 октября компания StarWind, производитель решения номер 1 - StarWind Virtual SAN, предназначенного для создания отказоустойчивой инфраструктуры хранилищ под виртуальные машины VMware vSphere и Microsoft Hyper-V, проводит интересный вебинар "VMware and Fault-Tolerance: Why Are 3 Nodes Better Than 2 for Hyper-Converged Architecture?".

Мероприятие пройдет 20 октября в 22-00 по московскому времени.

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

Зарегистрируйтесь!


Таги: StarWind, Webinar, HA, iSCSI, Storage

Конфигурация "растянутого" кластера VMware HA Stretched Cluster вместе с отказоустойчивыми хранилищами Virtual SAN.


Недавно Cormac Hogan написал интересный пост о том, как нужно настраивать "растянутый" между двумя площадками HA-кластер на платформе VMware vSphere, которая использует отказоустойчивую архитектуру Virtual SAN.

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

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

Откроем настройки кластера HA. Во-первых, он должен быть включен (Turn on vSphere HA), и средства обнаружения сетевых отказов кластера (Host Monitoring) также должны быть включены:

Host Monitoring позволяет хостам кластера обмениваться сигналами доступности (heartbeats) и в случае отказа предпринимать определенные действия с виртуальными машинами отказавшего хоста.

Для того, чтобы виртуальная машина всегда находилась на своей площадке в случае отказа хоста (и использовала локальные копии данных на виртуальных дисках VMDK), нужно создать Affinity Rules, которые определяют правила перезапуска ВМ на определенных группах хостов в рамках соответствующей площадки. При этом эти правила должны быть "Soft" (так называемые should rules), то есть они будут соблюдаться при возможности, но при отказе всей площадки они будут нарушены, чтобы запустить машины на резервном сайте.

Далее переходим к настройке "Host Hardware Monitoring - VM Component Protection":

На данный момент кластер VSAN не поддерживает VMCP (VM Component Protection), поэтому данную настройку надо оставить выключенной. Напомним, что VMCP - это новая функция VMware vSphere 6.0, которая позволяет восстанавливать виртуальные машины на хранилищах, которые попали в состояние All Paths Down (APD) или Permanent Device Loss (PDL). Соответственно, все что касается APD и PDL будет выставлено в Disabled:

Теперь посмотрим на картинку выше - следующей опцией идет Virtual Machine Monitoring - механизм, перезапускающий виртуальную машину в случае отсутствия сигналов от VMware Tools. Ее можно использовать или нет по вашему усмотрению - оба варианта полностью поддерживаются.

На этой же кариинке мы видим настройки Host Isolation и Responce for Host Isolation - это действие, которое будет предпринято в случае, если хост обнаруживает себя изолированным от основной сети управления. Тут VMware однозначно рекомендует выставить действие "Power off and restart VMs", чтобы в случае отделения хоста от основной сети он самостоятельно погасил виртуальные машины, а мастер-хост кластера HA дал команду на ее восстановление на одном из полноценных хостов.

Далее идут настройки Admission Control:

Здесь VMware настоятельно рекомендует использовать Admission Control по простой причине - для растянутых кластеров характерно требование самого высокого уровня доступности (для этого он, как правило, и создается), поэтому логично гарантировать ресурсы для запуска виртуальных машин в случае отказа всей площадки. То есть правильно было бы зарезервировать 50% ресурсов по памяти и процессору. Но можно и не гарантировать прям все 100% ресурсов в случае сбоя, поэтому можно здесь поставить 30-50%, в зависимости от требований и условий работы ваших рабочих нагрузок в виртуальных машинах.

Далее идет настройка Datastore for Heartbeating:

Тут все просто - кластер Virtual SAN не поддерживает использование Datastore for Heartbeating, но такого варианта тут нет :) Поэтому надо выставить вариант "Use datastores only from the secified list" и ничего из списка не выбирать (убедиться, что ничего не выбрано). В этом случае вы получите сообщение "number of vSphere HA heartbeat datastore for this host is 0, which is less than required:2".

Убрать его можно по инструкции в KB 2004739, установив расширенную настройку кластера das.ignoreInsufficientHbDatastore = true.

Далее нужно обязательно установить кое-какие Advanced Options. Так как кластер у нас растянутый, то для обнаружения наступления события изоляции нужно использовать как минимум 2 адреса - по одному на каждой площадке, поэтому расширенная настройка das.usedefaultisolationaddress должна быть установлена в значение false. Ну и нужно добавить IP-адреса хостов, которые будут пинговаться на наступление изоляции хост-серверов VMware ESXi - это настройки das.isolationaddress0 и das.isolationaddress1.

Таким образом мы получаем следующие рекомендуемые настройки растянутого кластера HA совместно с кластером Virtual SAN:

vSphere HA Turn on
Host Monitoring Enabled
Host Hardware Monitoring – VM Component Protection: “Protect against Storage Connectivity Loss” Disabled (по умолчанию)
Virtual Machine Monitoring Опционально, по умолчанию "Disabled"
Admission Control 30-50% для CPU и Memory.
Host Isolation Response Power off and restart VMs
Datastore Heartbeats Выбрать "Use datastores only from the specified list", но не выбирать ни одного хранилища из списка

Ну и должны быть добавлены следующие Advanced Settings:

das.usedefaultisolationaddress False
das.isolationaddress0 IP-адрес VSAN-сети на площадке 1
das.isolationaddress1 IP-адрес VSAN-сети на площадке 2

Более подробно об этом всем написано в документе "Virtual SAN 6.1 Stretched Cluster Guide".


Таги: VMware, HA, Virtual SAN, VSAN, Stretched, DR

Подробная информация о StarWind Hyper-Converged Platform (H-CP).


Не так давно мы писали о гиперконвергентной платформе StarWind Hyper-Converged Platform (H-CP), которая позволяет построить полноценную ИТ-инфраструктуру небольшого предприятия на базе продуктов компаний StarWind, Veeam, VMware и Microsoft. H-CP поставляется в виде уже готовых к использованию серверов с предустановленными компонентами от соответствующих вендоров.

Теперь у StarWind появилась специальная страница, посвященная Hyper-Converged Platform. Ну и, кроме этого, об H-CP можно узнать из вот этого видео:

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

Подробно об аппаратных характеристиках платформы H-CP от StarWind можно узнать из этого документа.


Таги: StarWind, Hardware, H-CP, HA

Анонсирован VMware Virtual SAN 6.1 - новые возможности.


На проходящей сейчас конференции VMworld 2015 было сделано множество интересных анонсов (впрочем, как и всегда). Конечно же, мы расскажем о всех тех, что достойны внимания. Одна из самых интересных новостей - это анонс новой версии решения для создания кластеров хранилищ VMware Virtual SAN 6.1.

Давайте взглянем на новые возможности этого решения:

1. Virtual SAN Stretched Cluster.

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

2. Virtual SAN for Remote Office / Branch Office (ROBO)

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

3. Virtual SAN Replication with vSphere Replication

Virtual SAN 6.1 теперь может использовать технологию vSphere Replication для асинхронной репликации данных на любые расстояния в комбинации с VMware Site Recovery Manager (SRM), чтобы получилось полностью законченное решения для восстановления инфраструктуры после сбоев.

Например, можно создать синхронно реплицируемый растянутый кластер хранилищ на расстояниях с latency менее 5 мс, а средствами vSphere Replication откидывать данные в географически удаленный датацентр:

4. Поддержка Multi-Processor Fault Tolerance (SMP-FT).

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

5. Поддержка Windows Server Failover Clustering (WSFC) and Oracle Real Application Cluster (RAC).

В новой версии VSAN теперь поддерживаются технологии кластеризации от Oracle и Microsoft. Для Oracle RAC можно запускать несколько экземпляров Oracle RDBMS на одном хранилище. Точно так же можно использовать и кластеры Microsoft WSFC поверх хранилищ Virtual SAN:

6. Максимальная производительность и высокая скорость отклика.

Здесь было сделано 2 серьезных улучшения:

  • Поддержка ULLtraDIMM SSD хранилищ, которые втыкаются в канал оперативной памяти (слоты DIMM), работающие с очень быстрым откликом на запись (менее 5 микросекунд). Это позволяет сделать хост All Flash с емкостью на 12 ТБ в форм-факторе блейд-сервера с троекратно большей производительностью, чем у внешних массивов.
  • NVMe – интерфейс Non-Volatile Memory Express (NVMe), который был специально разработан для SSD, чтобы максимально распараллеливать операции на программном и аппаратном уровне. В тестах VMware, использующих эту технологию, было получено 3,2 миллиона IOPS на 32-узловом кластере при примерно 100 тысячах операций в секунду на одном хост-сервере ESXi.

7. Virtual SAN Health Check Plug-in.

Теперь плагин, который был ранее доступен только на VMware Labs, стал частью решения VMware Virtual SAN 6.1. Теперь вся необходимая информация о жизнедеятельности кластера хранилищ видна в VMware vSphere Web Client:

8. Virtual SAN Management Pack for vRealize Operations.

Теперь для решения vRealize Operations есть отдельный Virtual SAN Management Pack, который позволяет осуществлять мониторинг кластера хранилищ и своевременно решать возникающие проблемы:

Более подробно о решении VMware Virtual SAN 6.1 можно узнать на этой странице. О доступности решения для загрузки будет объявлено несколько позже.

В ближайшее время мы расскажем еще о нескольких интересных анонсах с VMworld 2015 - stay tuned.


Таги: Virtual SAN, Update, VMworld, Storage, ESXi, vSphere, VMachines, HA, VMware

Документ про устройство файловой системы в StarWind Virtual SAN: LSFS container technical description.


Компания StarWind, известная своим продуктом StarWind Virtual SAN для создания программных отказоустойчивых хранилищ, выпустила интересный документ о своей журналируемой файловой системе - "LSFS container technical description".

Напомним, что файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.

Помимо этого, LSFS имеет следующие полезные функции:

  • встроенная поддержка снапшотов и точек восстановления хранилищ (автоматически они делаются каждые 5 минут)
  • поддержка непрерывной дефрагментации (она идет в фоне)
  • дедупликация данных "на лету" (то есть, перед записью на диск)
  • улучшения производительности за счет комбинирования операций записи
  • поддержка overprovisioning
  • использование технологии снапшотов и техник отслеживания изменений при синхронизации HA-узлов

Обо всем этом и многом другом вы можете почитать в документе "LSFS container technical description".


Таги: StarWind, HA, LSFS, Whitepaper, Storage

Как развернуть виртуальный модуль с хранилищем StarWind: Virtual SAN OVF Deployment Guide.


Многие из вас знают о решении StarWind Virtual SAN, предназначенном для создания отказоустойчивых хранилищ. Но не все в курсе, что у StarWind есть виртуальный модуль Virtual SAN OVF (ссылка на его загрузку высылается по почте), который представляет собой шаблон виртуальной машины в формате OVF готовый к развертыванию на платформе VMware vSphere.

Недавно компания StarWind выпустила документ Virtual SAN OVF Deployment Guide, в котором описана процедура развертывания данного виртуального модуля.

Поскольку Microsoft на уровне лицензии запрещает распространение таких виртуальных модулей с гостевой ОС Windows в формате виртуальных дисков VMDK, придется сделать несколько дополнительных операций по развертыванию, а именно:

1. Запустить StarWind V2V Converter.
2. Преобразовать VHDX-диски в формат VMDK.
3. Поместить VMDK и OVF в одну папку.
4. Развернуть OVF на сервере VMware ESXi.
5. Заполнить поля IP-адреса для включения машины в виртуальную сеть.
6. Подождать окончания процесса создания и конфигурации виртуальной машины.

Больше подробностей о виртуальном модуле StarWind Virtual SAN OVF вы найдете в документе.


Таги: StarWind, Whitepaper, Virtual Appliance, OVF, Storage, HA

Как начать работу с бесплатным продуктом для организации программных хранилищ под виртуальные машины - документ "StarWind Virtual SAN Free Getting Started".


Совсем недавно компания StarWind Software, производитель средства номер 1 для создания отказоустойчивых программных хранилищ под виртуальные машины VMware и Microsoft - Virtual SAN, выпустила интересный документ по его бесплатному изданию - "StarWind Virtual SAN Free Getting Started".

Напомним, что полностью бесплатный продукт StarWind Virtual SAN Free позволяет превратить два новых или имеющихся у вас сервера в отказоустойчивый кластер хранения (с полностью дублированными зеркалированными узлами), который может служить для:

  • размещения виртуальных машин Microsoft Hyper-V (NFS/SMB3)
  • размещения виртуальных машин VMware vSphere (NFS)
  • размещения баз данных MS SQL Server (SMB3)
  • создания отказоустойчивого файлового сервера (SMB3/NFS)

Кстати, StarWind Virtual SAN Free - единственное решение, которое позволяет создавать HA-кластер из двух узлов неограниченной емкости абсолютно бесплатно. Более подробно об отличиях бесплатной и коммерческой версий продукта можно почитать вот в этом документе.


Таги: StarWind, Virtual SAN, Whitepaper, Storage, HA, Бесплатно, VMachines

Обновленный документ VMware по технологии vSphere Metro Storage Cluster (vMSC).


На днях компания VMware выпустила интересный документ "VMware vSphere Metro Storage Cluster Recommended Practices" о построении архитектуры распределенного кластера VMware HA/DRS. Теперь в документе учтены все самые последние изменения, которые произошли в этом плане после выхода VMware vSphere 6.

Документ состоит из двух частей: в первой части рассказывается о том, как правильно спроектировать кластер vMSC и настроить платформу VMware vSphere соответствующим образом:

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

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

  • Отказ одного хоста в основном датацентре
  • Изоляция одного хоста в основном датацентре
  • Разделение пула виртуальных хранилищ
  • Разделение датацентра на сегменты (сети хостов и сети хранилищ)
  • Отказ дисковой полки в основном ЦОД
  • Полный отказ всех хранилищ в основном датацентре
  • Потеря устройств (полный выход из строя, выведение из эксплуатации) - Permanent Device Loss (PDL)

Понятное дело, что документ обязателен к прочтению, если вы планируете строить распределенную инфраструктуру для ваших виртуальных машин на платформе VMware vSphere 6.0.


Таги: VMware, vSphere, vMSC, HA, DRS, DR

Референсная архитектура: Horizon View 6.0.2 и VMware Virtual SAN 6.0.


Совсем недавно компания VMware выпустила полезный документ "VMware Horizon View 6.0.2 and VMware Virtual SAN 6.0 Hybrid", описывающий эталонную архитектуру инфраструктуры виртуальных ПК Horizon View 6, которые хранятся в кластере отказоустойчивости VMware Virtual SAN 6.0, построенном на базе хостов VMware ESXi.

В документе рассмотрено тестирование производительности 12-узлового кластера Virtual SAN на базе серверов Supermicro в рамках следующей логической архитектуры:

Подробная конфигурация хостов:

В целом инфраструктура тестирования выглядела так:

Для тестов использовалось средство Login VSI (о нем мы уже много писали), которое поставляется вместе с методологией тестирования:

Сводные результаты тестов:

Для получения более подробной информации о результатах по каждому тесту, используемых сценариях и конфигурациях обращайтесь к документу. Все 38 страниц полны картинок, графиков и табличек с цифрами - док составлен очень по делу. Для тех, кто планирует VDI на базе Virtual SAN очень полезный референс, как в плане архитектуры, так и в плане производительности.


Таги: VMware, View, Virtual SAN, VSAN, Storage, HA, VDI, Performance

Организация доступности сервисов управления vSphere 6 - документ "vCenter Server 6.0 Availability Guide".


Какое-то время назад мы писали о том, что компания VMware выпустила документ об обеспечении непрерывной работы сервера управления VMware vSphere - vCenter Server 5.5 Availability Guide. Совсем недавно VMware выпустила обновление этого документа - vCenter Server 6.0 Availability Guide.

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

1. Кластер высокой доступности VMware HA и сервис слежения за vCenter - Watchdog.

Сервис HA автоматически перезапускает виртуальную машину с vCenter отказавшего сервера на другом хосте кластера, а сервис Watchdog (он есть как на обычном vCenter, так и на vCenter Server Appliance) следит за тем, чтобы основная служба vCenter работала и отвечала, и запускает/перезапускает ее в случае сбоя.

2. Защита средствами VMware Fault Tolerance.

Теперь технология VMware FT в VMware vSphere 6.0 позволяет защищать ВМ с несколькими vCPU, поэтому данный способ теперь подходит для обеспечения непрерывной доступности сервисов vCenter и мгновенного восстановления в случае сбоя оборудования основного хоста ESXi.

3. Сторонние утилиты, использующие VMware Application Monitoring API.

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

4. Средства кластеризации на уровне гостевой ОС (с кворумным диском).

Это один из древнейших подходов к защите сервисов vCenter. О нем мы писали еще вот тут.

Для организации данного типа защиты потребуется основная и резервная ВМ, которые лучше разместить на разных хостах vCenter. С помощью кластера Windows Server Failover Clustering (WSFC) организуется кворумный диск, общий для виртуальных машин, на котором размещены данные vCenter. В случае сбоя происходит переключение на резервную ВМ, которая продолжает работу с общим диском. Этот метод полностью поддерживается с vCenter 6.0:

Кстати, в документе есть пошаговое руководство по настройке кластера WSFC для кластеризации vCenter 6.0 (не забудьте потом, где его искать).

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

Далее идет описание средств высокой доступности в Enterprise-инфраструктуре с несколькими серверами vCenter, где компоненты PSC (Platform Services Controller) и vCenter разнесены по разным серверам. Схема с использованием балансировщика:

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

Та же схема, но с кластеризованными серверами vCenter средствами технологии WSFC:

Использование географически распределенных датацентров и сервисов vCenter в них в едином домене доступа SSO (Single Sign-On) за счет технологии Enhanced Linked Mode (каждый сайт независим):

 

То же самое, но со схемой отказоустойчивости на уровне каждой из площадок:

 

Ну и напоследок 2 дополнительных совета:

1. Используйте Network Teaming для адаптеров vCenter (физических или виртуальных) в режиме отказоустойчивости, подключенные к дублирующим друг друга сетям.

2. Используйте Anti-affinity rules кластера HA/DRS, чтобы основная и резервная машина с vCenter не оказались на одном хосте VMware ESXi.

Да, и не забывайте о резервном копировании и репликации виртуальной машины с vCenter. Сделать это можно либо средствами Veeam Backup and Replication 8, либо с помощью VMware vSphere Replication/VMware vSphere Data Protection.


Таги: VMware, vCenter, HA, vSphere, Whitepaper

VM Component Protection (VMCP) в VMware vSphere 6.


Некоторое время назад мы писали про обработку гипервизором VMware vSphere таких состояний хранилища ВМ, как APD (All Paths Down) и PDL (Permanent Device Loss). Вкратце: APD - это когда хост-сервер ESXi не может получить доступ к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды, а PDL - это когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось.

Так вот, в новой версии VMware vSphere 6.0 появился механизм VM Component Protection (VMCP), который позволяет обрабатывать эти ситуации со стороны кластера высокой доступности VMware HA в том случае, если в нем остались другие хосты, имеющие доступ к виртуальной машине, оставшейся без "хост-хозяина".

Для того чтобы это начало работать, нужно на уровне кластера включить настройку "Protect against Storage Connectivity Loss":

Далее посмотрим на настройки механизма Virtual Machine Monitoring, куда входят и настройки VM Component Protection (VMCP):

С ситуацией PDL все понятно - хост больше не имеет доступа к виртуальной машине, и массив знает об этом, то есть вернул серверу ESXi соответствующий статус - в этом случае разумно выключить процесс машины на данном хосте и запустить ВМ на других серверах. Тут выполняется действие, указанное в поле Response for a Datastore with Permanent Device Loss (PDL).

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

  • возникает пауза до 140 секунд, во время которой хост пытается восстановить соединение с хранилищем
  • если связь не восстановлена, хост помечает датастор как недоступный по причине APD Timout
  • далее VMware HA включает счетчик времени, который длится ровно столько, сколько указано в поле Delay for VM failover for APD (по умолчанию - 3 минуты)
  • по истечении этого времени начинается выполнение действия Response for a Datastore with All Paths Down (APD), а само хранилище помечается как утраченное (NO_Connect)

У такого механизма работы есть следующие особенности:

  • VMCP не поддерживает датасторы Virtual SAN - они будут просто игнорироваться.
  • VMCP не поддерживает Fault Tolerance. Машины, защищенные этой технологией, будут получать перекрывающую настройку не использовать VMCP.
  • VMCP не поддерживает хранилища Virtual Volumes.
  • VMCP не работает с томами Raw Device Mapping (RDM).

Ну и надо помнить, что VM Component Protection (VMCP), как и многие прочие новые возможности vSphere 6, настраивается только через vSphere Web Client.


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

Новый документ: VMware AlwaysOn Desktop.


На днях компания VMware выпустила документ "VMware AlwaysOn Desktop", который будет интересен всем тем, кто использует или планирует инфраструктуру виртуальных ПК на базе решения VMware Horizon View. Особенно, если вы хотите добиться непрерывной доступности ваших десктопов и приложений.

В данном документе из 30 страниц рассматривается VDI-архитектура, обеспечивающая постоянную доступность виртуальных ПК за счет Active/Active-конфигурации датацентров (View Pods). В каждом из сайтов есть два кластера - для управления (Active Directory, View Connection Manager, Security Server и т.п.) и для размещения, собственно, виртуальных ПК. Кроме того, есть третий сайт (Site C), который содержит legacy-приложения, к которым происходит доступ с машин как первого, так и второго сайтов.

В синхронизированном состоянии (за счет ПО для репликации) находятся как мастер-образы виртуальных ПК (base image), так и пользовательские данные, чтобы пользователи VDI-инфраструктуры могли получить к ним доступ со стороны любого сайта. Интересно, что репликацию предлагается организовать средствами продукта Veeam Backup and Replication.

В документе рассматривается не только реализация этой архитектуры, но и такие вещи как мониторинг состояния инфраструктуры средствами VMware vCenter Operations Manager for View, а также обеспечение безопасности средствами продуктов vShield.

Использованное аппаратное обеспечение:

Разделы документа:

  • About, introduction and audience
  • Business Case
  • What is the AlwaysOn Desktop
  • User Profiles
  • AlwaysOn Desktop Lab Validation
  • AlwaysOn Desktop Logical Architecture Overview
  • Key Components of the Architecture
  • Overview of Architecture
  • Validation Results
  • Conclusion

Таги: VMware, Horizon, Whitepaper, View, HA

Полезная утилита для анализа сценариев "что если" при отказах - VM Resource and Availability Service.


На сайте проекта VMware Labs, про который мы регулярно пишем, появилась очень полезная утилита VM Resource and Availability Service (vRAS). Она позволяет провести анализ "что если" (what-if analysis) в плане последствий для инфраструктуры при различных отказах.

Вы можете симулировать отказ одного или нескольких хостов VMware ESXi в кластере, чтобы узнать:

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

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

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

Кстати, VM Resource and Availability Service - это не отдельная утилита, а сервис на стороне VMware. Чтобы начать его использовать, нужно:

1. Перейти по адресу hasimulator.vmware.com.

2. Нажать "Simulate Now", чтобы принять EULA и загрузить дамп DRM, после чего начать процесс симуляции.

3. Нажмите иконку помощи в правом верхнем углу для детальной информации об использовании сервиса.

Где взать DRM-дамп:

  • vCenter server appliance: /var/log/vmware/vpx/drmdump/clusterX/
  • vCenter server Windows 2003: %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
  • vCenter server Windows 2008: %ALLUSERSPROFILE%\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\

Для больших инфраструктур vRAS - штука полезная и незаменимая.


Таги: VMware, Labs, HA, SaaS

Что нового в VMware Virtual SAN 6.0 из состава vSphere 6.0.


Как вы знаете, недавно компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот туттут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, и мы уже писали о технологии непрерывной доступности VMware Fault Tolerance 6.0.

Сегодня мы хотим рассказать об отказоустойчивых кластерах VMware Virtual SAN 6.0, для которых версия программного обеспечения продвинулась с 1.0 сразу до 6.0 (поэтому пользователи, все же, не должны заблуждаться насчет зрелости продукта - это его вторая версия).

Итак, что нового появилось в VMware Virtual SAN 6.0:

1. Поддержка архитектуры All Flash для создания кластера хранилищ.

Теперь доступны два варианта развертывания VSAN:

  • Hybrid – Virtual SAN, как и раньше, использует SSD-диски для кэширования, а для хранения ВМ используются обычные HDD-диски. Максимально возможные конфигурации этой архитектуры стали выше (например, стало 64 хоста в кластере).
  • All Flash – Virtual SAN использует имеющиеся Flash-накопители как для кэширования, так для хранения ВМ.

Отличия между данными архитектурами:

В конфигурации All Flash девайсы, ответственные за кэширование, будут производить только кэширование записи и не будут делать кэширование на чтение (это очевидно почему). В гибридной конфигурации, как и раньше, 30% емкости SSD-кэшей используется для Write Buffer, а 70% - для кэша на чтение.

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

2. Возможность High Density Direct Attached Storage (HDDAS).

Теперь кластеры Virtual SAN удобно использовать в окружениях с блейд-системами. Для них поддерживаются как SDD, так и HDD-устройства, включая flash-хранилища блейд-серверов.

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

3. Новая файловая система и формат On-Disk.

Virtual SAN в VMware vSphere 5.5 использовал модифицированный формат файловой системы VMFS с измененным механизмом блокировок, которая называлась VMFS-L. Теперь же в VSAN 6.0 используется файловая система VSAN FS, специально предназначенная для кластеров хранилищ.

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

4. Функции Proactive Rebalance.

В Virtual SAN 6.0 появилась возможность ребаланса объектов по виртуальным дискам в случае, если подключается новый узел vSphere или если диски заполнены на 80% и более. Делается это через Ruby Console.

5. VSAN Fault Domains (группы отказа).

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

 

Теперь реплики объектов происходят не на уровне хостов, а на уровне Fault Domains (в данном случае инфраструктура хранения переживет отказ одной стойки):

6. Новые функции для дисков (Serviceability Functions).

  • Light LED on failures – включение LED-индикатора при отказе.
  • Turn on disk LED manually - включение LED-индикатора вручную для диска, чтобы его можно было найти на массиве.
  • Marking a disk as local – если диск не обнаружился как локальный, его можно пометить вручную из GUI.
  • Marking a disk as SSD - теперь эта опция есть в GUI, нужна если диск автоматически не распознается как SSD.

7. Улучшения сетевого взаимодействия.

Теперь Virtual SAN 6 поддерживает конфигурации на уровне Layer 3. Кроме того, теперь доступна конфигурация с Jumbo Frames. Ну и добавлена поддержка возможностей vDS и Network IO Control (NetIOC).

8. Новый тип виртуального диска VMDK - vsanSparse.

Ранее использовались стандартные Redo-диски, но они не были приспособлены под кэширование и другие функции VSAN FS, поэтому сделали новый тип диска vsanSparse.

9. Улучшенные функции Disk/Disk Group Evacuation.

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

10. Новое представление Resynchronization Dashboard.

Это представление показывает статус объектов, которые по тем или иным причинам находятся в состоянии ресинхронизации. Также показывается примерное время окончании синхронизации:

11. Новые службы 3rd Party File Services.

Сторонние вендоры теперь могут надстраивать свои решения над VMware Virtual SAN. Например, мы писали о таком решении совсем недавно - это NexentaConnect.

12. Полноценная поддержка командлетов PowerCLI.

Ранее интерфейс PowerCLI поддерживался неофициально, теперь же командлеты задокументированы и поддерживаются:

13. Службы мониторинга жизнедеятельности (VSAN Health Services).

Теперь для компонентов Virtual SAN доступна информация об их состоянии:

14. Storage Consumption Models.

Возможность визуализовать использование ресурсов хранения Virtual SAN 6.0 при создании или изменении VM Storage Policy.

О доступности VMware Virtual SAN 6.0 будет объявлено отдельно.


Таги: VMware, Virtual SAN, Update, VSAN, vSphere, Storage, SSD, HA

Как сократить затраты на развертывание кластера Microsoft SQL Server в три раза? Бесплатный вебинар компании StarWind.


Компания StarWind, поставщик ПО номер 1 для создания отказоустойчивых кластеров хранилищ в инфраструктурах VMware vSphere и Microsoft Hyper-V (о возможностях продукта - тут), приглашает на бесплатный вебинар "Microsoft SQL Server deployment price reduced by 3 times with StarWind Virtual SAN". На мероприятии пойдет речь о том, каким образом с помощью продукта Virtual SAN можно сократить затраты на внедрение SQL Server аж в три раза!

Дата и время вебинара: 3 февраля в 19-00 по московскому времени.

Группы доступности SQL AlwaysOn стали отличным решением для тех, кто годами искал средства кластеризации баз данных SQL Server. Теперь хранилища на базе локальных дисков серверов позволяют построить кластер высокой доступности SQL Server с использованием стандартной лицензии и узлов AlwaysOn Failover Cluster.

У такой конфигурации появляются следующие преимущества:

  • Не нужно лицензии SQL Server Enterprise
  • Упрощенная настройка
  • Нет необходимости в дорогостоящем физическом SAN или NAS-хранилище

Теперь можно с помощью обычных серверов и ПО StarWind Virtual SAN построить инфраструктуру кластера SQL Server AlwaysOn с функциями высокой доступности, не приобретая лишнего оборудования и ПО, сэкономив в три раза без потери производительности. Как именно это сделать? Приходите на вебинар StarWind и узнайте!


Таги: StarWind, Storage, SQL, Microsoft, Server, HA, Webinar

Обеспечение защиты сервера управления VMware vCenter Server 5.5.


Как вы знаете, у компании VMware был такой продукт как vCenter Server Heartbeat, который защищал управляющий сервер vCenter от сбоя различных его компонентов и на различных уровнях. Некоторое время этот продукт был снят с производства, и теперь защиту vCenter от сбоев рекомендуется обеспечивать стандартными средствами платформы VMware vSphere.

Надо сказать, что обеспечение надежности сервера vCenter, работающего в виртуальной машине (а сейчас уже мало кто ставит его в физической), начинается с обеспечения доступности и дублирования компонентов, которые находятся "под ним", а именно: хост-сервер ESXi, источники питания, хранилища, сетевые подключения и т.п.

Ну а, собственно, для правильной конфигурации самой платформы vSphere и сервера vCenter, компания VMware выпустила полезный документ "VMware vCenter Server 5.5 Availability Guide".

Итак, начнем с того, что VMware предлагает разделить сервисы vCenter на две большие части:

  • Compute Node - это сам vCenter и все сервисы к нему относящиеся (SSO, Web Client, Inventory service)
  • Data Node - это узел, где хранятся данные vCenter, попросту говоря, это СУБД и сама база данных.

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

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

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

Доступность Compute Node

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

  • vCenter Single Sign-On services
  • vCenter Inventory Service
  • vCenter Server
  • vCenter Server management Web service
  • vSphere Web Client

Здесь рекомендуется настроить защиту средствами технологии VMware HA и придерживаться следующих рекомендаций:

  • Создавайте (по-возможности) отдельный кластер для управляющих сервисов - в случае отказа любого из компонентов сервисы будут перезапущены с помощью HA автоматически.
  • Включите не только VMware HA, но и технологию virtual machine monitoring, которая отключена по умолчанию. Это позволит перезапустить сервер с vCenter при зависании гостевой ОС.

  • Включите и настройте admission control в кластере HA/DRS, где работает vCenter. Это позволит гарантированно перезапустить vCenter на одном из хостов в случае сбоя.
  • Установите restart priority в настройках HA для машины с vCenter Server в значение "High". Он будет первым запускаться.
  • Если ваш vCenter находится в Windows-машине, то можно настроить автоматический рестарт машины при невозможности после многократных попыток запустить службу vCenter Service.

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

  • Если у вас компоненты vCenter на разных машинах, не забудьте установить правило affinity rule, чтобы машины оказались на одном хосте при миграции и восстановлении, в целях сохранения максимальной производительности управляющего сервиса.
  • Также для гарантии можно выделить управляющим компонентам гарантированную физическую память (Memory Reservation) в настройках виртуальной машины.

Доступность Data Node

Тут VMware приводит следующие рекомендации:

  • Также, как и в случае с Compute Node, рекомендуется использовать для управляющих сервисов и базы данных отдельный кластер.
  • Если вы используете решение для кластеризации vCenter, необходимо убедиться, что настройка ForceAffinePoweron в параметрах vSphere DRS установлена в значение 1, чтобы включать сервер БД, несмотря на правила DRS.
  • Так же, как и в случае с Compute Node, используйте технику virtual machine monitoring для перезапуска зависшей гостевой ОС.
  • То же самое и про admission control - используйте его для гарантированного восстановления ВМ с сервером БД.
  • Аналогично Compute Node, установите restart priority в настройках HA для машины с базой данных в значение "High". Он будет первым запускаться.
  • Для защиты vCenter Server SQL Server database можно использовать Microsoft Failover Clustering, который официально поддерживается со стороны VMware. Табличка совместимости СУБД и версий vCenter приведена ниже.

О том, как восстанавливать серверы vCenter, и многом другом можно почитать в документе "VMware vCenter Server 5.5 Availability Guide".


Таги: VMware, vCenter, HA, DRS, VMachines

1 | 2 | 3 | 4 | 5 | 6    >   >>
Реклама

Advertisement

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

Быстрый переход:
VMware Microsoft IT-Grad StarWind VMFS RVTools Citrix PowerCLI Veeam 5nine VM Guru Oracle Red Hat Parallels Azure KVM vGate VeeamOn Security Code 1cloud Cloud Docker Storage Offtopic NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Enterprise Teradici Amazon NetApp VDI Linux Hyper-V IBM Cisco Google VSI HP Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Horizon Host Client VMDK App Volumes vROPs VTL vCloud Update iSCSI Labs IaaS Client SDDC vCSA NSX Virtual Appliance Backup VSA Whitepaper PowerShell Fusion Appliance DRS VUM Manager VVols V2V Tools Workstation Cache VMworld SRM Support Обучение XenDesktop Web Client Mobile OpenStack Automation Replication Desktop Log Insight Fault Tolerance DR Photon Vanguard SaaS Connector HA SSO Event Free Datacenter SQL VSAN Workspace Lifecycle Sponsorship Finance FT Cloud Computing Converter XenApp esxtop Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification SSD VDP Partners PCoIP RHEV Performance Award Network AWS USB Licensing Logs Server Demo Visio Intel vCHS Calculator Бесплатно Nested vExpert Beta SAN Exchange MAP ONE DaaS Networking vNetwork Monitoring VPLEX UCS SDK Poster VSPP SDRS Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Plugin Troubleshooting DPM Director Book Memory Upgrade API SIOC Flex Mac Bug Open Source SSH Air VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS CLI Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

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

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

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

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

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

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

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

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

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

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

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

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

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

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

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

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

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

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

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

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


Купить:

VMware vSphere 6


Veeam Backup 8


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


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


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