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

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

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

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

Использование дисков 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

Как включить общий доступ на запись для одного VMDK с двух ВМ на разных VMware ESXi.


В среде VMware vSphere есть возможность использования одного виртуального диска VMDK на запись несколькими виртуальными машинами, размещенными на разных хостах VMware ESXi. Например, это необходимо для построения кластеров Oracle RAC, а также для работы технологии VMware Fault Tolerance.

Этот режим называется Multi-Writer VMDK, чтобы его включить, нужно (если у вас vSphere 6.0 Update 1 и выше) зайти в vSphere Web Client и выбрать пункт "Edit Settings" для витуальной машины. Далее идем в Virtual Hardware -> выбираем диск, для которого нужно включить multi-writer flag, и в поле Sharing выбираем режим Multi-Writer:

Если у вас более старая версия VMware ESXi, то чтобы включить Multi-Writer VMDK надо определить диск VMDK, например, "SCSI0:1" и в Configuration Parameters виртуальной машины (то есть в ее vmx-файл) внести поле с именем "scsi0:1.sharing" со значением "multi-writer":

Когда вы включаете кластер непрерывной доступности ВМ VMware Fault Tolerance, режим Multi-Writer VMDK включается автоматически.

У этого режима есть некоторые ограничения, связанные с одновременной работой с одним виртуальным диском нескольких машин (соответственно, такие же ограничения есть и у VMware FT, и у кластеров Oracle RAC на базе ВМ):

Действия или возможности Поддерживается Не поддерживается Комментарий
Включение, выключение и перезагрузка ВМ
 
Приостановка ВМ (Suspend)

Горячее добавление виртуальных дисков (Hot add)
Только для уже существующих адаптеров
Горячее удаление устройств (Hot remove)

Горячее расширение виртуального диска

Присоединение и отсоединение устройств

Снапшоты
Решения для резервного копирования используют снапшоты через механизм vStorage APIs, соответственно такие решения (например, Veeam Backup and Replication) также не поддерживаются для этого режима.
Снапшоты ВМ с типом диска independent-persistent
Поддерживается в vSphere 5.1 update 2 и более поздних версиях
Клонирование ВМ

Горячая миграция хранилищ Storage vMotion
Не поддерживаются и shared, и non-shared диски, так как требуется приостановка ВМ во время миграции хранилищ.
Технология Changed Block Tracking (CBT)

Техника vSphere Flash Read Cache (vFRC)
Может привести к повреждению данных.
vMotion
       

       

       
Поддерживается только для Oracle RAC и ограничена 8 хостами ESXi.
   

Таги: VMware, VMDK, FT, vSphere, ESXi

Вышла обновленная версия 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 Fault Tolerance.


Компания VMware выпустила очень интересный документ "VMware vSphere 6 Fault Tolerance Architecture and Performance", посвященный производительности технологии VMware Fault Tolerance (FT), которая позволяет обеспечивать непрерывную доступность виртуальных машин, даже в случае отказа хост-сервера VMware ESXi. Делается это за счет техники Fast Checkpointing, по своей сути похожей на комбинацию Storage vMotion и vMotion, которая копирует состояние дисков, памяти, процессорных команд и сетевого трафика на резервную машину, поддерживая ее в полностью синхронизированном с первой состоянии. На данный момент vSphere 6 FT поддерживает виртуальные машины с конфигурацией до 4 vCPU и до 64 ГБ оперативной памяти на хост ESXi.

Давайте посмотрим на интереснейшие результаты тестирования производительности, приведенные в документе.

1. Процедура компиляции ядра в гостевой ОС.

Эта процедура грузит CPU на 100%, поэтому посмотрим, каковы тут потери, связанные с аспектами производительности процессора и синхронной передачи команд. Все вполне хорошо, потери небольшие:

2. Сетевая активность.

Если говорить о производительности сетевой коммуникации, то на получение данных потерь практически нет, а вот на передачу все происходит процентов на 10 медленнее. Результат для 1 Гбит сети:

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

Результат для 10 Гбит сети. Вот тут и происходит ситуация, когда канал на прием забивается FT-трафиком, как итог - прием происходит только на полосе 2,4 Гбит:

Из-за необходимости поддержки параметров сетевой передачи и приема в синхронном режиме возникает Latency около 6 миллисекунд:

3. Тестирование подсистемы ввода-вывода.

Для тестирования работы с хранилищами (I/O) взяли стандартный инструмент IOMeter. Особых потерь не обнаружилось:

4. Тест Swingbench для Oracle 11g.

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

5. Тест DVD Store на Microsoft SQL Server 2012.

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

6. Бенчмарк на базе TPC-E.

Здесь были симулированы операции сервера брокерской компании, который производит обработку OLTP-транзакций в реальном времени. Тест очень стрессовый, и потери здесь весьма существенны:

7. Операции VMware vCenter Server.

Ну а здесь уже сам сервер vCenter защитили технологией Fault Tolerance и измерили производительность операций для двух типов нагрузки - легкой и тяжелой. При тяжелой нагрузке все происходит медленнее больше чем в 2 раза:

vSphere Web Client работает, в общем-то, неплохо, но хотелось бы лучше:

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


Таги: VMware, FT, Performance, vSphere, ESXi, Whitepaper

Обеспечение отказоустойчивости компонента 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 6 - новости с VMworld 2014.


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

Итак, что нового мы увидим в первой половине 2015 года (а именно тогда выйдет VMware vSphere 6):

1. Поддержка технологией Fault Tolerance до четырех виртуальных процессоров машины (4 vCPU).

Теперь технология непрерывной доступности VMware Fault Tolerance будет поддерживать виртуальные машины с 4 vCPU и объемом памяти до 64 ГБ.

Ранее для работы FT использовался механизм "Record-Replay" средствами технологии vLockstep, который воспроизводил инструкции основной машины на резервной. Теперь же используется техника Fast Checkpointing, которая позволяет организовать исполнение потока инструкций одновременно на обеих машинах. Если по какой-либо причине сетевое соединение между машинами замедляется, основная машина тоже начинает работать медленнее.

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

  • На хост ESXi можно иметь до 4 машин, защищенных технологией FT, при этом всего суммарно может быть защищено до 8 vCPU. Обратите внимание, что эти максимумы применяются суммарно к Primary и Secondary виртуальным машинам, расположенным на этом хосте.
  • Обязательно потребуется адаптер 10 Gb. Можно будет его разделять между различными типами трафика средствами NetIOC.
  • Нельзя использовать горячее добавление CPU или памяти для таких машин (Hot Add).
  • Если несколько vCPU затронуто технологией FT, то для таких машин не поддерживается Storage vMotion.
  • Кроме того, технику SMP-FT не поддерживают такие вещи, как vCloud Director, vSphere Replication, VSAN/vVols и vFlash.

При этом для таких машин полностью поддерживается VMware vMotion, а также они (как и раньше) защищаются кластером VMware HA - если с одной из машин что-то случается, то на другом хосте перезапускается реплика, которая уже становится Secondary VM.

Помимо этого, надо понимать, что SMP-FT вызовет падение производительности гостевой ОС, по оценкам VMware - это около 10-30% в зависимости от нагрузки.

Приятная новость - многопроцессорная FT будет поддерживать снапшоты виртуальных машин, а значит вы сможете делать их резервные копии средствами Veeam Backup and Replication или любым другим средством, поддерживающим vStorage APIs for Data Protection.

2. Улучшения горячей миграции виртуальных машин на большие расстояния (long distance vMotion).

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

Теперь работающую виртуальную машину можно перемещать на расстояния, где RTT (Round Trip Time) в канале достигает 100 мс (неофициально поддерживается значение 150 мс). Это в 10 раз больше, чем было раньше.

И это - расстояние до 3000 километров (!). Теперь менеджерам датацентров открываются очень интересные стратегии по таким вариантам использования, как Follow the sun (машины работают там, где работают люди) и Follow the moon (машины работают ночью, когда электричество дешевле).

Кроме того, появились следующие улучшения технологии vMotion.

  • vMotion между разными серверами vCenter (нужна сеть на скорости 250 Mbps). Это происходит средствами протокола VMware Network File Copy (NFC).
  • Маршрутизируемый трафик vMotion (наконец-то).
  • vMotion между виртуальными коммутаторами vSwitch, а также Virtual Distributed Switch (VDS), поддерживаются режимы VSS to VSS, VSS to VDS, VDS to VDS (а вот VDS to VSS - нельзя).
  • средствами VMware NSX сетевые настройки машин могут быть перемещены в горячем режиме даже, если используется long distance vMotion.

3. Улучшенная производительность и новые возможности vSphere Web Client.

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

4. Технология Virtual Volumes.

О ней мы уже писали вот тут и тут.

Все это приходит в рамках концепции создания конвергентной инфраструктуры и развития парадигмы Software-Defined-Datacenter.

Здесь используются три основных элемента:

  • Vendor Provider (VP) – это плагин от производителя системы хранения данных, поддерживающий VVols через VASA API версии 2.0.
  • Storage Containers (SC) – это контейнеры на дисковом массиве, в которые упаковываются VMDK-диски каждой из машин. Это операбельная единица со стороны и системы хранения, и платформы VMware vSphere.
  • Protocol Endpoints (PE) – это средства управления томами на базе политик, предоставляемые администраторам. В них уже не будет понятий LUN и точек монтирования. Будет просто VVol, который можно привязывать и отвязывать от серверов ESXi/vCenter.

Все хранилища будут управляться на базе политик (сейчас это реализовано в VSAN):

5. Технология Virtual Datacenters.

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

 

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

6. Новые максимумы для хостов ESXi.

Нам обещают следующие параметры:

  • 320+ pCPU
  • 4+ TB Mem
  • 4096+ vCPUs
  • 32+ Nodes/Cluster
  • 62TB+ VMDKs

Также с большой долей вероятности в VMware vSphere 6.0 мы увидим следующие возможности, о которых говорили на VMworld 2014:

  • Полная поддержка NVIDIA GRID vGPU - больше информации доступно тут.
  • Технология vSphere APIs for IO Filtering (VAIO) - о ней рассказано здесь.

  • Технология VMFork - метод по мгновенному клонированию запущенных виртуальных машин.

Больше подробностей о VMware vSphere 6 можно прочитать вот тут.


Таги: VMware, vSphere, Update, ESXi, vCenter, FT, vMotion

Вышло средство создания кластеров непрерывной доступности Stratus ftServer systems with vSphere 5.1.


Многим интересующимся технологиями виртуализации известна компания Stratus Technologies, занимающаяся вопросами непрерывной доступности виртуальных машин (Fault Tolerance). Ранее продукты этой компании были доступны на платформе Citrix XenServer, где позволяли обеспечивать непрерывную доступность программными методами (продукт everRun от купленной компании Marathon):

Теперь у компании появился программно-аппаратный комплекс Stratus ftServer systems with vSphere 5.1, интегрированный с последней версией платформы виртуализации от VMware. Возможности решения из пресс-релиза:

  • Обещают аптайм на уровне 99.999%, что соответствует 5.26 минут простоя в год
  • Один или два 8-ядерных процессора Intel с поддержкой hyper-threading и архитектуры QuickPath
  • Полная поддержка SMP для построения архитектуры непрерывной доступности (vSMP?)
  • Встроенные интерфейсы 10Gb Ethernet
  • Проактивная система мониторинга, предупреждающая о возможных сбоях
  • Система обнаружения проблем в самом сервере и операционной системе, работающая без прерывания обслуживания виртуальных машин
  • Минимальный overhead (<5%) на систему виртуализации
  • Интеграция с VMware HA

Очевидно, что Stratus суетится накануне выхода программного vSMP Fault Tolerance от самой VMware.

Кстати в пресс-релизе по ftServer говорится о полугодовой гарантии на нулевой даунтайм в $50 000, покрывающей не только серверную часть, но и гипервизор (!). Так что торопитесь - возможно, парочка серверов от Stratus достанется вам совершенно бесплатно (учитывая тот набор багов, который мы видим в vSphere 5.1).


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

VMware vSphere Storage Appliance (VSA) и виртуальные машины, защищенные Fault Tolerance.


Мы уже писали о продукте VMware vSphere Storage Appliance, который позволяет организовать отказоустойчивую инфраструктуру хранилищ на базе локальных дисков хост-серверов VMware ESXi, которые реализуют общее хранилище за счет зеркалирования томов и экспорта хранилищ хостам по протоколу NFS. Узлы ESXi с использованием VSA могут образовывать двух- или трехузловой кластер:

В случае, например, использования двухузлового кластера VSA совместно с технологией VMware Fault Tolerance, может возникнуть такая ситуация - когда Primary VM находится на хосте ESXi и использует основную копию тома с его локальных дисков. В случае сбоя этого хоста возникает двойной отказ - и виртуальной машины, которая на нем исполняется, и ее хранилища, так как оно находилось на дисках хоста. В этом случае возникает неизбежный простой ВМ до того момента, как подхватится хранилище с другого хоста и Secondary VM сможет его использовать.

В такой ситуации VMware рекомендует поступать так:

А именно: размещать хранилище защищенной FT виртуальной машины (ее виртуальные диски и файлы) на хосте, отличном от того, на котором она исполняется, т.е. на том хосте ESXi, где исполняется Secondary VM. В этом случае при любом отказе двойного сбоя не будет - всегда выживет или исполняющаяся ВМ или ее хранилище, которое подхватится Secondary VM.

В случае трехузловой конфигурации VSA можно пойти дальше: разместить Primary VM на одном узле, Secondary VM на другом, а файлы этой ВМ на третьем узле кластера VSA.


Таги: VMware, VSA, Fault Tolerance, FT, HA, Storage

VMware Fault Tolerance и Isolation Responce для VMware HA.


Как вы знаете, в механизме высокой доступности VMware High Availability (HA) есть такая настройка как Isolation Responce, которая определяет, какое событие следует выполнить хосту VMware ESX / ESXi в случае наступления события изоляции для него в кластере (когда он не получает сигналов доступности - Heartbeats - от других хост-серверов).

  • Leave powered on
  • Power off
  • Shutdown

Сделано это для того, чтобы вы могли выбрать наиболее вероятное событие в вашей инфраструктуре:

  • Если наиболее вероятно что хост ESX отвалится от общей сети, но сохранит коммуникацию с системой хранения, то лучше выставить Power off или Shutdown, чтобы он мог погасить виртуальную машину, а остальные хосты перезапустили бы его машину с общего хранилища после очистки локов на томе VMFS или NFS (вот кстати, что происходит при отваливании хранища).
  • Если вы думаете, что наиболее вероятно, что выйдет из строя сеть сигналов доступности (например, в ней нет избыточности), а сеть виртуальных машин будет функционировать правильно (там несколько адаптеров) - ставьте Leave powered on.

Но есть еще один момент. Как вам известно, VMware HA тесно интегрирована с технологией VMware Fault Tolerance (непрерывная доступность ВМ, даже в случае выхода физического сервера из строя). Суть интеграции такова - если хост с основной виртуальной машиной выходит из строя, то резервный хост выводит работающую резервную ВМ на себе "из тени" (она становится основной), а VMware HA презапускает копию этой машины на одном из оставшихся хостов, которая становится резервной.

Так вот настройка Isolation Responce не применяется к машинам, защищенным с помощью Fault Tolearance. То есть, если хост VMware ESX с такой машиной становится изолированным, при настройке Power off или Shutdown он такую машину не гасит, а всегда оставляет включенной.

Рекомендация - иметь network redundancy для сети heartbeats. Не должен хост себя чувствовать изолированным, если он весь не сломался.


Таги: VMware, HA, Fault Tolerance, FT, Network, VMachines, Blogs, ESX, ESXi

Резервное копирование виртуальных машин VMware vSphere с включенной Fault Tolerance.


Часто задаваемый вопрос: можно ли осуществлять резервное копирование виртуальных машин на ESX, работающих в кластере постоянной доступности VMware Fault Tolerance. Ответ прост - согласно ограничениям технологии FT, бэкап таких работающих виртуальных машин делать нельзя, поскольку для них нельзя сделать мгновенный снимок (снапшот).

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

Очевидных пути выхода из положения два:

1. Делать резервное копирование данных виртуальной машины средствами гостевой ОС (копирование на уровне файлов) либо средствами SAN (снапшоты).

2. На период бэкапа (например, средствами Veeam Backup) выключать защиту Fault Tolerance для виртуальной машины вручную или с помощью скрипта по расписанию. Этот способ подходит не всем, поскольку на время резервного копирования машина оказывается незащищенной.

О первом способе вы и так знаете, поэтому поговорим о втором:

Для автоматизации этого процесса с помощью интерфейса vSphere CLI добрые люди написали соответствующий скрипт, который можно использовать, например, на сервере резервного копирования Veeam Backup and Replication 5. Сначала нужно скачать и установить VMware vSphere CLI:

Затем минут за 10-15 до запуска задачи резервного копирования отключаем Fault Tolerance для машины командой (ее можно добавить в bat-файл и запускать планировщиком):

ftCLI2.pl --server vcenter.domain.local --passthroughauth --operation stop --vmname MyTestFTvm

Затем запускаем задачу резервного копирования Veeam Backup, в настройках которой есть замечательный параметр для выполнения скрипта после завершения задачи:

А вот в этом батнике мы уже снова включаем Fault Tolerance командой вроде этой:

ftCLI2.pl --server vcenter.domain.local --passthroughauth --operation create --vmname MyTestFTvm

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


Таги: VMware, FT, Backup, Fault Tolerance, vSphere, ESX, Blogs, HA

Требования и ограничения VMware Fault Tolerance.


Технология VMware Fault Tolerance позволяет защитить виртуальные машины с помощью кластеров непрерывной доступности, позволяющих в случае отказа хоста с основной виртуальной машиной мгновенно переключиться на ее "теневую" работющую копию на другом сервере ESX. Однако эта технология имеет существенные ограничения, приведенные ниже.
Таги: VMware, Fault Tolerance, FT, vSphere, ESX, DRS, DPM, HA, Enterprise

Интеграция VMware Fault Tolerance и DRS в VMware vSphere.


Как вы знаете, в VMware vSphere 4.1 механизм VMware DRS, осуществляющий балансировку нагрузки на хост-серверы ESX, теперь интегрирован с технологией непрерывной доступности VMware Faut Tolerance.

То есть DRS автоматически распределяет по хост-серверам и FT-машины, однако тут есть небольшой нюанс. В соответствии с рекомендациями Fault Tolerance, число таких машин на хосте должно быть не больше 4-х в целях оптимального быстродействия. Если вы попробуете смигрировать пятую виртуальную машину с включенной технологией FT на хост, вы получите вот такое сообщение:

Host already has the recommended number of 4 Fault Tolerance VMs running on it

То есть DRS не смигрирует и не сделает Initial Placement для FT-машин на хосты VMware ESX, где уже работают 4 таких ВМ. Однако, есть возможность увеличить это количество. Для этого необходимо в расширенных настройках (Advanced Settings) кластера VMware HA/DRS добавить параметр:

das.maxftvmsperhost

со значением, например, 6. Если вы поставите значение 0, то VMware DRS будет полностью игнорировать данное требование к числу FT-машин на хост.


Таги: VMware, DRS, Fault Tolerance, FT, ESX, Blogs, VMachines, vSphere

Как работает VMware Fault Tolerance в VMware vSphere 4.1.


Компания VMware выпустила отличный документ "The Design and Evaluation of a Practical System for Fault-Tolerant Virtual Machines", где описаны ключевые аспекты работы технологии непрерывной доступности виртуальных машин Fault Tolerance (FT).

В частности интересна формула, отражающая требования к пропускной способности FT-канала между серверами VMware ESX:

FT logging bandwidth = 1 Mbit/s + 1.2 * (average disk read throughput [Mbits/s] + average network receives [Mbits/s])

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


Таги: VMware, Fault Tolerance, vSphere, FT, Whitepaper, ESX, VMachines

Возможности и функции Xen 4.0 - основа Xen Cloud Platform и XenServer.


Совсем недавно сообщество xen.org, поддерживаемое компанией Cirtix и другими проивзодителями программного и аппаратного обеспечения, объявило о выпуске гипервизора Xen 4.0.

Теперь в списке возможностей, поддерживаемых Xen 4.0 есть следующее:

  • Fault Tolerance - синхронизация между основной и "теневой" копией виртуальной машины, что позволяет мгновенно переключиться на резерв в случае отказа виртуальной системы на основном сервере
  • Memory Overcommit - возможности более эффективного использования физической памяти хост-сервера за счет передачи неиспользуемой памяти виртуальных машин нуждающимся в ней системам (Transcendent Memory)
  • Support for live snapshots and clones - возможность создания мгновенных снимков систем с использованием новой реализации формата VHD под названием Blktap2
  • Support for new Smart NICs with multi-queue and SR-IOV functionality - поддержка новых возможностей для сетевых адаптеров Netchannel2 для оптимизации производительности
  • Support for Para-virtualized USB and VGA pass-through - поддержка паравиртуализованных драйверов USB и VGA (проброс устройств хоста в виртуальную машину)
  • Support for Paravirt-ops in the Dom0 - поддержка паравиртуализованных ОС, оптимизированных по производительности (Linux kernel 2.6.31)
  • Support for up to 64 vCPUs per virtual machine - до 64 виртуальных процессоров внутри виртуальной машины
  • Support for up to 1TB RAM per host - до 1 ТБ памяти хост-сервера Xen
  • Support for Intel Xeon 5600 Series CPUs - поддержка новых процессоров Intel под кодовым названием Westmere

Как известно, все новшества виртуализации сначала появляются в открытом Xen, после чего их встраивают в свои продукты различные производители, например, компания Citrix в бесплатный XenServer. Кроме того, на гипервизоре Xen построена облачная архитектура Xen Cloud Platform (XCP) и, возможно, какие-то функции от нового релиза появятся в клиентском гипервизоре Xen Hypervisor for Client Devices (XCI).

Странная вещь - но в списке функций нет ничего о поддержке распределенного виртуального коммутатора Citrix Open vSwitch.

 


Таги: Xen, XCP, XenServer, Xen Cloud Platform, Cloud Computing, Cloud, FT

 
Интересное:





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

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