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

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

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

VM Guru | Ссылка дня: Вышел VMware vCenter 6.5c - фикс уязвимости Apache BlazeDS

Новый документ "VMware vSphere encrypted vMotion architecture, performance, and best practices".


Недавно компания VMware выпустила очередной интересный технический документ "VMware vSphere encrypted vMotion architecture, performance, and best practices", посвященный различным аспектам работы механизма шифрованной миграции виртуальных машин между хостами.

Напомним, что шифрование как данных виртуальных машин, так и трафика vMotion, появилось в обновленной версии платформы VMware vSphere 6.5. Шифрование трафика vMotion происходит на уровне VMkernel средствами широко распространенного алгоритма AES-GCM (Advanced Encryption Standard / Galois Counter Mode).

Эксперименты, описанные в открытом документе, подтвердили следующее:

  • Миграция vSphere 6.5 Encrypted vMotion работает практически с той же скоростью, что и vMotion.
  • Нагрузка на CPU для шифрования небольшая за счет оптимизации в коде реализации vMotion.
  • vSphere 6.5 Encrypted vMotion работает так же надежно, как и обычный vMotion.

Миграция в корпоративной инфраструктуры виртуальной машины с СУБД Redis:

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

Содержание документа:

  • Encrypted vMotion Architecture
    • Encryption Protocol
    • Encryption Algorithms
    • Defending Against Replays
    • Workflow
  • Encrypted vMotion Configuration
  • Performance Test Configuration and Methodology
    • Test Configuration
    • Measuring Encrypted vMotion Performance
  • Encrypted vMotion Performance in a Private Cloud Deployment
    • Performance Impact on Duration and Switch-Over Time
    • Performance Impact on Throughput and CPU Usage
  • Encrypted vMotion Performance Over Long Distance
    • Test Methodology
    • Load Generation Software
    • Results
  • Encrypted vMotion Performance Best Practices

Кстати, шифрованные виртуальные машины всегда перемещаются между хостами ESXi средствами также шифрованного vMotion.


Таги: VMware, Whitepaper, vMotion

Шифрование виртуальных машин в VMware vSphere 6.5 - как это работает?


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

Устроено это шифрование ВМ на базе алгоритма AES-NI, а управление ключами происходит по стандарту KMIP 1.1. Когда операция ввода-вывода приходит на диск виртуальной машины - она сразу же шифруется "на лету", что обеспечивает полную безопасность при попытке несанкционированного доступа к данным.

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

Шифрование объектов ВМ идет за ее пределами, таким образом гостевая ОС не имеет доступа к ключам шифрования. Шифрованные виртуальные машины всегда перемещаются между хостами ESXi средствами также шифрованного vMotion.

Чтобы начать шифровать виртуальную машину, нужно назначить ей соответствующую политику хранения (Storage Policy):

Как работает VM Encryption в VMware vSphere 6.5:

  • Пользователь назначает политику VM Encryption на уровне виртуальной машины.
  • Для машины генерируется случайный ключ и шифруется ключом из key manager (KMS Key).
  • При включении ВМ сервер vCenter получает ключ из Key Manager, посылает его в VM encryption Module на сервере ESXi, что разлочивает ключ в гипервизоре.
  • Далее все операции ввода-вывода идут через encryption module, шифруя все входящие и исходящие SCSI-команды прозрачно для гостевой ОС.

Все это совместимо со сторонними системами управления ключами (и требует одну из них), которые построены на стандарте KMIP версии 1.1 или выше:

 

Для того, чтобы расшифровать виртуальную машину и хранить далее ее в обычном формате, нужно просто поставить дефолтную политику хранения (Datastore default).

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

vCenter в системе шифрования работает только как клиент. Для управления ключами используется Key Management Server (KMS).

В механизме управления привилегиями теперь появилась роль No Cryptography Administrator. Если ее назначить, то стандартному администратору будут запрещены следующие привилегии:

  • Manage key servers
  • Manage keys
  • Manage encryption policies
  • Console access to encrypted VMs
  • Upload/download encrypted VMs

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

При использовании шифрования ВМ нужно учитывать следующие моменты:

  • Да, вам понадобится система управления ключами (внешний Key Management Server)
  • Не поддерживаются возможности SAN Backup.
  • Если для обычного метода бэкапа сделать резервную копию - она будет нешифрованной, если восстановить - то все будет в соответствии с политикой целевого хранилища (то есть, ВМ может оказаться незашифрованной после восстановления).
  • Сам сервер vCenter не может быть зашифрован - иначе его просто было бы нельзя включить.
  • Также не поддерживаются следующие возможности:
    • Suspend/resume
    • Шифрование ВМ со снапшотами и создание снапшотов для шифрованных ВМ
    • Serial/Parallel port
    • Content library
    • vSphere Replication

Для vMotion шифрование включается на уровне отдельной ВМ, а для передачи данных в момент синхронизации используются 256-битные ключи шифрования.

Есть 3 политики для шифрованного vMotion:

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

Перенос машин между хостами осуществляется путем обмена одноразовыми ключами, которые генерируются и обслуживаются сервером vCenter (не KMS).

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


Таги: VMware, VMachines, Security, vMotion, Update

Важные патчи для фикса критических багов VMware ESXi 6.0.


На днях VMware выпустила обновления, которые исправляют прямо-таки фатальные баги в гипервизоре VMware ESXi 6.0. Скорее всего, вы с ними не сталкивались, но обновиться обязательно стоит - ведь если такое случится хотя бы раз, вам придется отвечать перед пользователями и начальством.

VMware ESXi 6.0.0. билд 4192238, описанный в KB 2145667 фиксит следующие критические баги за счет обновлений в самом коде ESXi, VMware Tools и драйверах:

  • ESXi может вывалиться в розовый экран смерти (PSOD), когда вы переносите виртуальную машину с хоста ESXi в режиме обслуживания (maintenance mode).
  • ESXi может вывалиться в PSOD во время асинхронных операций компонентов IO Filter (то есть, при обычной работе с хранилищами).
  • Хосты ESXi 6, использующие драйвера mpt2sas или mptsas, могут вывалиться в PSOD.
  • ESXi выдает ложную ошибку "deprecated VMFS volume" при обновлении тома VMFS3на VMFS5.
  • Функция vMotion для активного SQL-узла может оказаться недоступной при использовании балансировки Round-Robin PSP.
  • Датасторы NFS v4.1 генерируют частые события APD, даже когда уже произошло их восстановление из этого состояния.

Загрузить патч можно на VMware Patch Portal.


Таги: VMware, Update, Bug, Bugs, ESXi, vMotion, VMachines

Extrasphere - бесплатный vMotion для виртуальных машин на бесплатных VMware ESXi.


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

Решение Extrasphere предоставляет бесплатный аналог технологии vMotion, которая доступна без использования vCenter. Ключевая особенность продукта — поддержка бесплатной версии VMware ESXi.

Продукт позволяет:

  • Менять местоположение дисков виртуальной машины на ESXi без простоя виртуальной машины.
  • Менять местоположение всех файлов виртуальной машины за счет suspend/resume в конце операции (небольшой простой при переключении будет).
  • Менять местоположение всех файлов виртуальной машины и/или хост-сервер с использованием общего между хостами хранилища - в конце операции выполняется suspend/resume или выключение/включение, если флаги CPU не поддерживаются принимающим хостом.
  • Менять местоположение и хост-сервер без использования общего между хостами хранилища с помощью специально виртуального модуля Extrasphere Resharer на базе Linux - в конце операции выполняется suspend/resume или выключение/включение, если флаги CPU не поддерживаются целевым хостом.

Текущие требования и ограничения:

  • Не поддерживаются виртуальные машины со снапшотами.
  • Нет поддержки Independent-дисков и дисков RDM в режиме физической совместимости.
  • Для подключения используется SSH под пользователем root.
  • Для миграции между хостами необходимо разрешить на ESXi исходящий SSH-трафик.

Скачать Extrasphere можно по этой ссылке. В целом-то тема давно изъезженная, но, мало ли, утилита вам понравится.


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

Миграция vMotion виртуальных машин между датацентрами под управлением разных vCenter в VMware vSphere 6.0.


Как многие из вас знают, в VMware vSphere 6.0 была добавлена функциональности горячей миграции vMotion виртуальной машины между датацентрами под управлением разных серверов vCenter. Виртуальные машины могут теперь перемещаться между виртуальными коммутаторами Standard vSwitch и Distributed Switch (vDS)в любой их комбинации, при этом при уходе с vDS настройки машины на его портах сохраняются и уезжают вместе с ней.

На днях VMware выпустила интересное видео, описывающее данную возможность:

Чтобы машина могла переезжать с одного vCenter на другой в горячем режиме необходимо:

  • Чтобы оба сервера vCenter были версии 6.0 или более поздней.
  • Чтобы оба сервера vCenter работали в режиме Enhanced Linked Mode и были в одном домене Single Sign-On, то есть один vCenter (исходный) мог аутентифицироваться на другом (целевом).
  • Оба сервера vCenter должны быть синхронизированы по времени, чтобы SSO мог корректно производить аутентификацию.
  • Если вы переносите только ВМ с сервера на сервер (хранилище остается тем же), оба сервера vCenter должны видеть общее хранилище (соответственно, хост-серверы и vCenter должны быть соответствующим образом отзонированы).

Больше подробностей можно узнать из видео выше и KB 2106952.


Таги: VMware, vSphere, vMotion

Что нового в VMware vSphere 6 с точки зрения серверов ESXi и виртуальных машин.


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

В этой части мы расскажем о новых возможностях платформы vSphere с точки зрения улучшений, сделанных непосредственно в плане хостов ESXi и виртуальных машин.

Итак, начнем по порядку:

1. Новые возможности хост-сервера и кластера.

Если еще с давних времен кластеры VMware HA/DRS объединяли 32 хоста, то в версии vSphere 6 кластер, наконец-то, может объединять до 64 хостов включительно. Помимо этого, на хосте может быть запущено до 1000 виртуальных машин (и до 8000 в кластере), а сам ESXi поддерживает сервер с числом процессоров до 480 CPU и памятью до 12 ТБ.

Сравним с предыдущей версией:

2. Новые возможности виртуальных машин.

Виртуальные машины, как и хосты ESXi, также стали поддерживать еще большие максимальные конфигурации - теперь можно создать машину со 128 vCPU и до 12 ТБ оперативной памяти:

Интересны также и другие возможности. Горячее добавление памяти теперь правильно работает с vNUMA, что положительно сказывается на производительности. Появилась поддержка ускорения для объектов GDI в пакете драйверов WDDM 1.1, также контроллер xHCI 1.0 теперь работает с драйвером этого контроллера под Мак, начиная с OS X 10.8.

3. vMotion теперь работает между разными vCenter и на большие расстояния.

В VMware vSphere 6 технология горячей миграции виртуальных машин vMotion была значительно улучшена. Во-первых, виртуальные машины могут теперь перемещаться между виртуальными коммутаторами Standard vSwitch и Distributed vSwitch в любой их комбинации, при этом при уходе с vDS настройки машины на его портах сохраняются и уезжают вместе с ней.

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

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

При этом для миграции не требуется ни общего хранилища, ни той же самой сети или того же vCenter - можно все это в рамках одной операции vMotion поменять:

Кроме того, если раньше vMotion "держала" задержку в канале (RTT) до 10 мс (и до 50 мс в Enterprise Plus издании), то теперь это значение увеличено до 100 мс. То есть, стратегия Follow the sun для перераспределения нагрузки - теперь реальность, так как такое RTT позволяет уже "трансконтинентальные" миграции vMotion:

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

4. Полезные мелочи.

Во-первых, появилась настройка политики сложности пароля в Host Advanced System Settings. Раньше для этого нужно было мудохаться с pam.d модулем.

Во-вторых, в логах хостов ESXi действия, произведенные через vCenter, включают в себя пользователя, которых их выполнял. Если раньше в логе было так: [user=vpxuser], то теперь вот так: [user=vpxuser:DOMAIN\User]. Весьма удобно.

В-третьих, появилась поддержка новых гостевых ОС:

  • Oracle Unbreakable Enterprise Kernel Release 3 Quarterly Update 3
  • Asianux 4 SP4
  • Solaris 11.2
  • Ubuntu 12.04.5
  • Ubuntu 14.04.1
  • Oracle Linux 7
  • FreeBSD 9.3
  • Mac OS X 10.10

5. Улучшения vSphere Network I/O Control.

Улучшенный механизм vSphere Network I/O Control версии 3 позволяет гарантировать уровень обслуживания на уровне vNIC виртуальной машины. Применять NetIOC можно также и к Distributed Port Group:

На этом вкратце все. Ну и так для общей информации - улучшения режима Linked Mode для серверов vCenter:


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

Новые возможности 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

Как запретить vMotion отдельной виртуальной машине на VMware vSphere.


Если вы хотите, чтобы никто не делал vMotion конкретной виртуальной машины с конкретного сервера VMware ESXi, то нужно просто разослать письмо администраторам vSphere с просьбой этого не делать. Но есть еще один способ, который поведал нам Frank Denneman - хотя он тоже имеет ограниченные условия применения. Ну и не забываем, что есть способ путем задания правил механизма балансировки VMware DRS (однако, не у всех по лицензии DRS есть).

В этом способе есть один существенный минус - в то время, как он не позволяет пользователю двинуть виртуальную машину через vMotion вручную, смигрировать машину можно будет через перевод хоста ESXi в Maintenance mode, так как делается это не под аккаунтом пользователя, а под системной учетной записью (System). Но режим обслуживания используется редко, и хотя бы для ручных операций это можно будет сделать. Ну и имейте в виду, что механизм VMware HA также может перезапустить машину на другом хосте в случае сбоя, наплевав на все.

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

Итак, добавляем роль No-vMotion в vSphere Web Client:

1. Заходим в vCenter как administrator.
2. Идем на домашний экран и переходим в Roles на экране Administration.
3. Выбираем действие создать роль (зеленый плюс).
4. Выбираем "All Priveleges", скроллимся до категории "Resource" и отчекиваем следующие привилегии,

  • Migrate powered off virtual machine
  • Migrate powered on virtual machine
  • Query vMotion

Далее добавляем пермиссию для виртуальной машины для нужного администратора/группы:

1. Выбираем "Host and Clusters" и находим нужную ВМ на вкладке Manage.
2. Выбираем пункт "Permissions" и кликаем на добавление пермиссии (зеленый плюс).
3. Нажимаем "Add" и выбираем пользователя или группу, которым мы хотим запретить vMotion этой виртуальной машины.
4. В правой части экрана выбираем роль "No-vMotion" и нажимаем "Ok".

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

Попробуем смигрировать эту виртуальную машину пользователем FrankD - видим, что опция "Migrate" загреена:

Но вот возможность перевода в Maintenance mode, к сожалению, по-прежнему активна:

Кто-нибудь знает более простой и надежный способ?


Таги: VMware, vSphere, vMotion, VMachines, Security, Обучение, ESXi, DRS, Blogs

Загадочное поведение VMware ESXi: падает vMotion на 13%, нет места, когда оно есть, и прочие аномалии.


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

  • Не работает vMotion - отваливается на 13% с ошибкой "A general system error occurred: Timed out waiting for vpxa to start" или зависает вовсе
  • Не работает консоль виртуальной машины (Unable to contact the MKS)
  • Не зайти на хост VMware ESXi по SSH
  • Хост ругается на отсутствие свободного места, хотя оно есть на разделах ESXi (No free space left on device)
  • и прочие неприятности

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

Чтобы проверить количество доступных inodes надо выполнить следующую команду на VMware ESXi (подробнее в KB 1007638):

[root@esx /]$ stat -f /

Вывод будет похож на этот:

File: "/"
ID: 0 Namelen: 255 Type: ext2/ext3
Blocks: Total: 1259079 Free: 898253 Available: 834295 Size: 4096
Inodes: Total: 640000 Free: 580065

Вот тут мы видим, что из 640 тысяч айнодов свободно 580 тысяч, то есть все в порядке.

Откуда может взяться так много файлов? Оказывается это случается, когда включен демон SNMPD на VMware ESXi 5.1. Каталог /var/spool/snmp начинает быстро засираться файлами SNMP-трапов. Если у вас включен SNMP и в этом каталоге более 2000 файлов - вероятность возникновения описанного выше поведения высока.

Выход - почистить папку и сделать так, как написано в статье KB 2040707.

P.S. Кстати, интересная идея для злодеев.


Таги: VMware, ESXi, Bug, SNMP, vSphere, Bugs, vMotion, Blogs

VMware Storage vMotion уже почти научился переименовывать VMDK-диски виртуальных машин.


Интересные новости приходят от Дункана: в VMware vSphere 5.0 Update 2 при переименовании виртуальной машины во время миграции Storage vMotion ее VMDK-диски также переименовываются (раньше это не работало - менялось только имя машины). Но это, почему-то, не включено по умолчанию.

Чтобы это заработало нужно добавить расширенную настройку VMware vCenter. Для этого идем в "Administration" -> "vCenter Server Settings" -> "Advanced Settings" и добавляем параметр:

provisioning.relocate.enableRename со значением true

Итак, титаническая работа была проделана - и диски теперь переименовываются. Однако, почему эта настройка не активирована по умолчанию? Непонятно - бажит наверное...

Для VMware vSphere 5.1 эта штука пока не актуальна (только vSphere 5.0 Update 2), но обещают, что скоро она заработает с очередным апдейтом. Кстати, а почему тут только интерфейс добавления расширенных настроек и нет удаления?


Таги: VMware, vSphere, SVMotion, Storage vMotion, vCenter, Blogs, VMDK

Максимальное количество миграций VMware vMotion и Storage vMotion - хосты, сети и хранилища.


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

Теперь, на основе статьи Франка, мы обобщим и актуализуем информацию по миграциям vMotion и Storage vMotion в разных контекстах - на уровне хранилищ, сети и хост-серверов VMware ESX.

Как и в прошлой статье, здесь будем пользоваться понятием стоимости миграции в единицах (cost) и максимального значения костов в тех же единицах (max cost), которое отображает предельно допустимое значение. Сумма костов операций vMotion и SVMotion не должна превышать max cost для соответствующего объекта (datastore, NIC и хост ESXi).

Теперь взглянем на таблички (в них есть не только vMotion, но и SVMotion):

Хост ESXi

Operation Config Key Cost
vMotion Cost costPerVmotionESX41 1
Storage vMotion Cost costPerSVmotionESX41 4
Maximum Cost maxCostPerEsx41Host 8

Сеть

Operation Config Key Cost
vMotion Cost networkCostPerVmotion 1
Storage vMotion Cost networkCostPerSVmotion 0
Maximum Cost maxCostPerNic 2
maxCostPer1GNic 4
maxCostPer10GNic 8

Хранилище (Datastore)

Operation Config Key Cost
vMotion Cost CostPerEsx41Vmotion 1
Storage vMotion Cost CostPerEsx41SVmotion 16
Maximum Cost maxCostPerEsx41Ds 128

Читать эти таблички просто - например, для хоста ESXi стоимость миграции vMotion равна 1, а поскольку max cost равно 8, то всего на хост может быть 8 одновременных миграций в конфигурации по умолчанию. Либо допустимы одновременно: 1 миграция SVMotion (4 очка) и 4 штуки vMotion (по одному очку каждая), т.е. суммировать надо по костам: 4+1+1+1+1=8.

Для хранилища (Datastore) также есть ограничения vMotion, поскольку передаются страницы файла подкачки (если он не шаренный между хостами), а также производится передача владения VMX-файлом и другими файлами ВМ на хранилище. Но поскольку влияние это мало, то стоимость vMotion для хранилища всего 1 при максимальной емкости одновременных операций 128 (а вот SVMotion, требующая значительных ресурсов хранилища, "кушает" 16 единиц). Таким образом 1 операция vMotion съест 1 единицу коста, поэтому в этот момент для хранилища будет доступно только 7 миграций SVMotion, т.е. (128-1) div 16 = 7.

Соответственно, редактирование параметра Config Key для соответствующей операции позволяет изменять количество одновременных операций vMotion/SVMotion. Для редактирования параметра Config Key нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:

%ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\

Там нужно вписать новое значение в соответствующую секцию. Например, для параметра maxCostPerEsx41Ds:

< config >
< vpxd >
< ResourceManager >
< MaxCostPerEsx41DS > new value < /MaxCostPerEsx41DS >
< /ResourceManager >
< /vpxd >
< /config >

Если соответствующей секции нет, то ее можно просто добавить. Уменьшать максимальные косты точно можно, а увеличение работает не всегда. То есть гарантированно вы сможете только уменьшить число одновременных миграций vMotion или SVMotion, а вот увеличить - не факт. Ограничение можно делать двумя способами - повышением обычных костов или понижением максимальных костов.

Теперь самое интересное - это динамический параметр max cost для сетевых адаптеров. Как видно из таблицы, его действующее значение зависит от типа сетевого адаптера на хосте - 1G или 10G. Но, на самом деле, и не только от типа. Точнее - от скорости соединения для трафика vMotion между хостами ESXi, которую обнаруживает VMkernel. Таким образом:

  • Если VMkernel обнаруживает соединение на скорости 1Gbit/s - Maximum Cost выставляется в значение 4 (это верно и для случая соединения 1G<->10G).
  • Если VMkernel обнаруживает соединение на скорости 10Gbit/s - Maximum Cost выставляется в значение 8.
  • Если VMkernel обнаруживает соединение на скорости ниже 1Gbit/s - Maximum Cost выставляется в значение 2.

Таким образом, для адаптера возможны либо 2, либо 4, либо 8 одновременных миграций vMotion, в зависимости от действующей скорости соединения. Операция Storage vMotion, как видно из таблицы, костов сети не кушает.

Если ограничение для сети жестче (например, 4 миграции vMotion), чем ограничение для хоста (8 миграций vMotion) - то для машин этого хоста действует ограничение сети.


Таги: VMware, vSphere, vMotion, ESXi, Storage vMotion, SVMotion, VMachines, Storage, vNetwork

Учет производительности виртуальных хранилищ механизмом Storage DRS в VMware vSphere 5.1.


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

  • Заполненность - в этом случае SDRS выравнивает виртуальные машины для равномерного заполнения хранилищ.
  • Производительность - при использовании этих метрик SDRS старается динамически перенести виртуальные машины с более нагруженных по параметрам ввода-вывода хранилищ на менее загруженные.

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

Например, бесполезна (с точки зрения производительности) будет миграция с Datastore1 на Datastore2:

Раньше этот факт не учитывался механизмом SDRS в vSphere 5.0, что приводило к бесполезным миграциям в автоматическом режиме. Теперь ситуация изменилась к лучшему в версии vSphere 5.1.

Как многие знают, в VMware vSphere есть механизм Storage IO Control (SIOC), который позволяет измерять мгновенную производительность хранилищ (параметр latency - задержка команд ввода-вывода) и регулировать очередь HBA-адаптеров на хостах ESXi. Так вот, одна из техник SIOC Injection позволяет производить тестирование виртуальных хранилищ на наличие корреляции производительности между ними.

Делается это следующим образом: SIOC запускает тестовую рабочую нагрузку на случайно выбранном Datastore1, измеряет latency, а потом отдельно от него запускает нагрузку на другом Datastore2 и также смотрит на latency:

Это нужно для установления базового уровня производительности для этих виртуальных хранилищ. Потом SIOC запускает нагрузку одновременно на 2 этих хранилища и смотрит, что происходит с latency:

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

Узнав про этот факт, Storage DRS не будет генерировать рекомендации по перемещению виртуальных машин между хранилищами Datastore1 и Datastore2:

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


Таги: VMware, vSphere, SDRS, Performance, Storage vMotion, SVMotion, ESXi, Storage

Как работает "Shared-Nothing" vMotion (Enhanced vMotion) в VMware vSphere 5.1.


Как знают многие пользователи, среди новых возможностей VMware vSphere 5.1 есть так называемая Enhanced vMotion или "Shared-Nothing" vMotion - функция, позволяющая переместить работающую виртуальную машину на локальном хранилище ESXi на другой хост и хранилище с помощью комбинации техник vMoton и Storage vMotion в одной операции. Это означает, что для такого типа горячей миграции не требуется общее хранилище (Shared Storage), а значит и затрат на его приобретение. Напомним также, что функция Enhanced vMotion включена во все коммерческие издания VMware vSphere, кроме vSphere Essentials.

Давайте посмотрим поближе, как это все работет:

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

  • Хосты ESXi должны находиться под управлением одного сервера vCenter.
  • Хосты должны находиться в одном контейнере Datacenter.
  • Хосты должны быть в одной Layer 2 подсети (и, если используется распределенный коммутатор, на одном VDS).
  • Enhanced vMotion - это исключительно ручной процесс, то есть функции DRS и Storage DRS не будут использовать миграцию машин без общего хранилища. Это же касается и режима обслуживания хоста (Maintenance Mode).
  • Для одного хоста ESXi может быть проведено не более 2-х Enhanced vMotion единовременно. Таким образом, на хост ESXi может одновременно приходиться максимум 2 штуки Enhanced vMotion и 6 обычных vMotion (всего 8 миграций на хост) + 2 операции Storage vMotion, либо 2 Enhanced vMotion (так как это также задействует Storage vMotion). Подробнее об этом тут.
  • Enhanced vMotion может проводить горячую миграцию одновременно по нескольким сетевым адаптерам хоста ESXi, если они имеются и настроены корректно.

Миграция Enhanced vMotion может быть проведена только через тонкий клиент vSphere Web Client (в обычном клиенте эта функция недоступна - см. комментарии):

Миграция Enhanced vMotion идет по обычной сети vMotion (а не по Storage Network), по ней передаются и диск ВМ, и ее память с регистрами процессора для обеспечения непрерывной работоспособности виртуальной машины во время миграции:

Теперь как это все работает последовательно. Сначала механизм Enhanced vMotion вызывает подсистему Storage vMotion, которая производит копирование данных по сети vMotion. Здесь важны 2 ключевых компонента - bulk copy и mirror mode driver.

Сначала механизм bulk copy начинает копирование блоков данных с максимально возможной скоростью. Во время этого часть блоков на исходном хранилище хоста может измениться - тут и вступает в дело mirror mode driver, который начинает поддерживать данные блоки на исходном и целевом хранилище в синхронном состоянии.

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

Когда диски на исходном и целевом хранилище и их изменяющиеся блоки приходят в синхронное состояние, начинается передача данных оперативной памяти и регистров процессора (операция vMotion). Это делается после Storage vMotion, так как страницы памяти меняются с более высокой интенсивностью. После проведения vMotion идет операция мгновенного переключения на целевой хост и хранилище (Switch over). Это делается традиционным способом - когда различия в памяти и регистрах процессора весьма малы, виртуальная машина на мгновение подмораживается, различия допередаются на целевой хост (плюс переброс сетевых соединений), машина размораживается на целевом хосте и продолжает исполнять операции и использовать хранилище с виртуальным диском уже целевого хоста.

Ну а если вы перемещаете виртуальную машину не между локальными дисками хост-серверов, а между общими хранилищами, к которым имеют доступ оба хоста, то миграция дисков ВМ идет уже по Storage Network, как и в случае с обычным Storage vMotion, чтобы ускорить процесс и не создавать нагрузку на процессоры хостов и сеть vMotion. В этом случае (если возможно) будет использоваться и механизм VAAI для передачи нагрузки по копированию блоков на сторону дискового массива.

Картинки и описание процесса взяты у Фрэнка.


Таги: VMware, vMotion, vSphere, Storage vMotion, Storage, ESXi, VMachines, SMB

Максимальное количество операций vMotion и Storage vMotion на одном хранилище VMware vSphere.


На сайте Фрэнка Деннемана появилась отличная статья про механизмы "горячей" миграции хранилищ (Storage vMotion) и "горячей" миграции виртуальных машин (vMotion) в контексте их использования для одного хранилища (Datastore) или хоста ESXi в VMware vSphere. Мы просто не можем не перевести ее, так как она представляет большой интерес для понимания работы этих механизмов.

Начнем со Storage vMotion. Данная операция, очевидно, требует большой нагрузки как на хранилище, откуда и куда, переносятся виртуальные машины, так и на сам хост-сервер VMware ESXi. Особенно актуально это, когда хост или хранилище переходят в Maintenance Mode, и виртуальные машины массово начинают миграцию. В случае со Storage vMotion это создает колоссальную нагрузку на хранилище по вводу-выводу.

Для понимания затрат ресурсов на эти процессы Фрэнк вводит понятие "цены" (cost) начинающейся операции, которая не может превосходить количество доступных слотов на хосте или хранилище, выделенных под них. Наглядно это можно представить так:

Resource Max Cost - это максимальный объем в неких единицах (назовем их слотами), который находится в рамках пула доступных ресурсов для операции Storage vMotion. Для хоста ESXi емкость такого пула составляет 8 слотов, а цена операции Storage vMotion - 4 слота. Таким образом, на одном хосте ESXi могут одновременно выполняться не более 2-х операций Storage vMotion. Если выполняется одна операция - то занято 4 слота и 4 слота свободно (как для исходного, так и для целевого хранилища).

С хранилищем точно такая же система - но у него 128 слотов. Одна операция Storage vMotion для Datastore потребляет 16 слотов. Таким образом, на одном хранилище может выполняться 8 (128 / 16) одновременных операций Storage vMotion. Их могут инициировать, например, 4 хоста (по 2 операции максимально каждый). То есть, мы получаем следующую схему:

Все просто и понятно. Отметим здесь, что операция vMotion тоже потребляет ресурсы с Datastore - но всего 1 слот. Таким образом, на одном Datastore могут, например, выполняться 7 одновременных миграций Storage vMotion (7 * 16 = 112 слотов) и еще 16 миграций vMotion (112+16 = 128), задействующих ВМ этого Datastore.

Если вы не хотите, чтобы при переводе Datastore в Maintenance Mode на нем возникало сразу 8 одновременных миграций Storage vMotion и, как следствие, большой нагрузки, вы можете уменьшить пул слотов для хранилищ (для всех, а не для какого-то конкретно). Для этого нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:

%ALLUSERPROFILE%\Application Data\VMware\VMware VirtualCenter\

Там нужно вписать новое значение в следующую секцию, где "new value":

< config >
< vpxd >
< ResourceManager >
< MaxCostPerEsx41DS > new value < /MaxCostPerEsx41DS >
< /ResourceManager >
< /vpxd >
< /config >

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

Про стоимость миграций vMotion для хостов ESX / ESXi 4.1 мы уже писали вот тут. На эту тему есть также статья KB 2001417. С тех пор в vMotion много чего изменилось, поэтому подтвердить актуальность для vSphere 5 пока не могу. Буду признателен, если вы напишете об этом в комментариях.


Таги: VMware, Storage vMotion, SVMotion, vMotion, Storage, ESXi, vCenter, Performance, Blogs

DRS Host Affinity Rules - неочевидное поведение.


Вот эта заметка на блоге VMware напомнила об одной интересной особенности поведения правил совместного и несовместного размещения виртуальных машин на хосте ESX/ESXi (DRS Host Affinity Rules).

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

То есть, мы задаем группы виртуальных машин и хостов:

И указываем, что виртуальные машины DRS-группы могут работать только на данной DRS-группе хостов:

Правила эти бывают мягкими (preferential), когда DRS+HA будут стараться следовать им при штатном функционировании кластера, и жесткими (mandatory, "Must run") - в этом случае ни при каких условиях виртуальные машины не переедут на хосты не из группы. Этого не произойдет ни средствами vMotion/DRS/Maintenance Mode, ни средствами перезапуска HA в аварийных ситуациях.

Для жестких правил есть один интересный аспект: они сохраняются и продолжают действовать даже тогда, когда вы отключили кластер VMware DRS. То есть вы не сможете сделать ручной vMotion или Power On машин на хостах не из группы, а HA не будет их там перезапускать. При этом в настройках кластера с отключенным DRS уже не будет возможности редактирования этих правил (категория VMware DRS пропадет). Это сделано для того, чтобы во время временных сбоев (например, vCenter) лицензионные правила существования ВМ для приложений на хостах не нарушались в любом случае.

Поэтому, если нужно удалить правила, нужно снова включить DRS, удалить их и снова отключить DRS.


Таги: VMware, DRS, Обучение, vSphere, ESX, ESXi, vMotion, HA

Особенности работы миграции ВМ по нескольким сетевым адаптерам - VMware vSphere 5 Multi NIC vMotion.


Как знают многие пользователи VMware, в новой версии платформы VMware vSphere 5 появилась возможность производить "горячую" миграцию виртуальных машин между хостами ESXi сразу по нескольким физическим сетевым адаптерам (Multi NIC vMotion). Опишем кратко особенности использования данной технологии.

При миграции ВМ в vSphere 5 есть следующие особенности:

  • Поддержка до четырех одновременных миграций на адаптерах 1Gbps и до 8 одновременных миграций по 10Gbps сетевым адаптерам.
  • Поддержка на хосте ESXi до 4 адаптеров 10Gbps и до 16 адаптеров 1Gbps.
  • Миграция одной виртуальной машины vMotion может идти сразу по нескольким сетевым адаптерам (между ними просиходит балансировка нагрузки)
  • В целом, vMotion стала работать быстрее (в подавляющем большинстве случаев, время переключения - не более 1 секунды)
  • Логи ошибок vMotion стали богаче и информативнее

Миграция vMotion по нескольким сетевым адаптерам - это комплексный процесс, поскольку vSphere приходится обрабатывать различные комбинации из 1 GbE и 10 GbE адаптеров на хостах.

Перед началом vMotion сервер vCenter анализирует сетевые адаптеры на хостах VMware ESX / ESXi и определяет суммарную пропускную способность, которая доступна для миграции. Например, если у хоста 2 адаптера 1GbE и 1 адаптер 10GbE, тогда пул хоста считается равным 12 GbE. Емкость пула определяется как на исходном, так и на целевом хосте.

Далее есть несколько аспектов работы vMotion:

  • Если исходный и целевой хосты имеют адаптеры 1GbE NIC, то между ними настраивается одно соединение для vMotion.
  • Если исходный хост имеет 3 адаптера 1GbE NIC, а целевой хост имеет 1 адаптер 10GbE, то с исходного хоста к целевому, в его адаптер, открывается 3 параллельно работающих соединения (сокета vMotion).
  • Если исходный хост имеет 15 адаптеров 1GbE, а целевой - 1 адаптер 10GbE и 5 адаптеров 1GbE, то первые 10 адаптеров исходного хоста соединяются с одним 10GbE-адаптером целевого, а дальше 5 адаптеров 1GbE соединяются на исходном и целевом хостах между собой. Таким образом, для миграций (одной или нескольких) открыто суммарно 15 соединений.
  • Ну и, само собой, если на исходном хосте 2 адаптера 1GbE, а на целевом только один такой адаптер, то будет открыто только одно соединение 1GbE.

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

И еще одно видео с комментариями EMC:


Таги: VMware, vSphere, vMotion, Video, ESXi, vNetwork, vMachines, Blogs

Насколько VMware vSphere 5 работает быстрее vSphere 4?


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

Сейчас компания VMware решила сделать несколько иначе: на одном и том же сервере Dell Power Edge R310 поставить vSphere 4, посчитать производительность, а потом сделать то же самое с vSphere 5 на этом же сервере. При тестировании было 4 типа нагрузки с нарастанием до насыщения утилизации сервера по CPU и получились вот такие результаты:

В результате ESXi 5.0 обогнал ESXi 4.1 на 3-4% очкам в зависимости от нагрузки (линии же CPU - практически одинаковы). Но самое интересное, что при росте нагрузки машин на сервер ESXi 5 позволил поддерживать виртуальных машин на 33% больше, чем ESXi 4.1 при условии соблюдения требований к качеству обслуживания для виртуальных машин - правый столбик (как это оценивалось не очень понятно). При этом ESXi 5.0 позволял выполнять в два раза больше операций с инфраструктурой в кластере, чем его предшественник (см. ниже).

Также VMware померила время отклика различных приложений и вычислила их задержки (latency), а также latency для операций инфраструктуры (vMotion, Storage vMotion и VM Deploy). Вышло так (показано в нормализованном виде):

Обратите внимание, что vMotion и Storage vMotion - стали работать значительно быстрее (о том, как это было сделано - тут). Вот как раз за счет низкого latency ESXi 5 и смог обеспечить поддержку на 33% больше виртуальных машин при условии соблюдения QoS.

Подробнее о тестировании написано тут.


Таги: VMware, vSphere, Performance, Hardware, ESXi, vCenter, vMotion, SVMotion

VMware vSphere 5 Stretched Clusters: Metro HA и vMotion на EMC VPLEX.


Скоро нам придется участвовать в интереснейшем проекте - построение "растянутого" кластера VMware vSphere 5 на базе технологии и оборудования EMC VPLEX Metro с поддержкой возможностей VMware HA и vMotion для отказоустойчивости и распределения нагрузки между географически распределенными ЦОД.

Вообще говоря, решение EMC VPLEX весьма новое и анонсировано было только в прошлом году, но сейчас для нашего заказчика уже едут модули VPLEX Metro и мы будем строить active-active конфигурацию ЦОД (расстояние небольшое - где-то 3-5 км) для виртуальных машин.

Для начала EMC VPLEX - это решение для виртуализации сети хранения данных SAN, которое позволяет объединить ресурсы различных дисковых массивов различных производителей в единый логический пул на уровне датацентра. Это позволяет гибко подходить к распределению дискового пространства и осуществлять централизованный мониторинг и контроль дисковых ресурсов. Эта технология называется EMC VPLEX Local:

С физической точки зрения EMC VPLEX Local представляет собой набор VPLEX-директоров (кластер), работающих в режиме отказоустойчивости и балансировки нагрузки, которые представляют собой промежуточный слой между SAN предприятия и дисковыми массивами в рамках одного ЦОД:

В этом подходе есть очень много преимуществ (например, mirroring томов двух массивов на случай отказа одного из них), но мы на них останавливаться не будем, поскольку нам гораздо более интересна технология EMC VPLEX Metro, которая позволяет объединить дисковые ресурсы двух географически разделенных площадок в единый пул хранения (обоим площадкам виден один логический том), который обладает свойством катастрофоустойчивости (и внутри него на уровне HA - отказоустойчивости), поскольку данные физически хранятся и синхронизируются на обоих площадках. В плане VMware vSphere это выглядит так:

То есть для хост-серверов VMware ESXi, расположенных на двух площадках есть одно виртуальное хранилище (Datastore), т.е. тот самый Virtualized LUN, на котором они видят виртуальные машины, исполняющиеся на разных площадках (т.е. режим active-active - разные сервисы на разных площадках но на одном хранилище). Хосты ESXi видят VPLEX-директоры как таргеты, а сами VPLEX-директоры являются инициаторами по отношению к дисковым массивам.

Все это обеспечивается технологией EMC AccessAnywhere, которая позволяет работать хостам в режиме read/write на массивы обоих узлов, тома которых входят в общий пул виртуальных LUN.

Надо сказать, что технология EMC VPLEX Metro поддерживается на расстояниях между ЦОД в диапазоне до 100-150 км (и несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало.

До появления VMware vSphere 5 существовали некоторые варианты конфигураций для инфраструктуры виртуализации с использованием общих томов обоих площадок (с поддержкой vMotion), но растянутые HA-кластеры не поддерживались.

С выходом vSphere 5 появилась технология vSphere Metro Storage Cluster (vMSC), поддерживаемая на сегодняшний день только для решения EMC VPLEX, но поддерживаемая полностью согласно HCL в плане технологий HA и vMotion:

Обратите внимание на компонент посередине - это виртуальная машина VPLEX Witness, которая представляет собой "свидетеля", наблюдающего за обоими площадками (сам он расположен на третьей площадке - то есть ни на одном из двух ЦОД, чтобы его не затронула авария ни на одном из ЦОД), который может отличить падения линка по сети SAN и LAN между ЦОД (экскаватор разрезал провода) от падения одного из ЦОД (например, попадание ракеты) за счет мониторинга площадок по IP-соединению. В зависимости от этих обстоятельств персонал организации может предпринять те или иные действия, либо они могут быть выполнены автоматически по определенным правилам.

Теперь если у нас выходит из строя основной сайт A, то механизм VMware HA перезагружает его ВМ на сайте B, обслуживая их ввод-вывод уже с этой площадки, где находится выжившая копия виртуального хранилища. То же самое у нас происходит и при массовом отказе хост-серверов ESXi на основной площадке (например, дематериализация блейд-корзины) - виртуальные машины перезапускаются на хостах растянутого кластера сайта B.

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

Если откажет только сеть управления для хостов ESXi на одной площадке - то умный VMware HA оставит её виртуальные машины запущенными, поскольку есть механизм для обмена хартбитами через Datastore (см. тут).

Что касается VMware vMotion, DRS и Storage vMotion - они также поддерживаются при использовании решения EMC VPLEX Metro. Это позволяет переносить нагрузки виртуальных машин (как вычислительную, так и хранилище - vmdk-диски) между ЦОД без простоя сервисов. Это открывает возможности не только для катастрофоустойчивости, но и для таких стратегий, как follow the sun и follow the moon (но 100 км для них мало, специально для них сделана технология EMC VPLEX Geo - там уже 2000 км и 50 мс latency).

Самое интересное, что скоро приедет этот самый VPLEX на обе площадки (где уже есть DWDM-канал и единый SAN) - поэтому мы все будем реально настраивать, что, безусловно, круто. Так что ждите чего-нибудь про это дело интересного.


Таги: VMware, HA, Metro, EMC, Storage, vMotion, DRS, VPLEX

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


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

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


Таги: VMware, vSphere, Update, Release, ESXi, Enterprise, Storage DRS, Storage VMotion, vMotion, Network, vMachines, DRS, Auto Deploy, VMFS, Storage, HA, Licensing, Price

 
Реклама

Advertisement

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

Быстрый переход:
VMware IT-Grad StarWind Microsoft 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 vSAN SSO DRS Horizon LSFS Workspace Client Host Client VMDK App Volumes vROPs VTL vCloud Update iSCSI Labs IaaS SDDC vCSA NSX Virtual Appliance Backup VSA Whitepaper PowerShell Fusion Appliance 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 Event Free Datacenter SQL VSAN 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 vMA 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, Александр Самойленко. Правила перепечатки материалов.