Если вы администратор VMware vSphere со стажем, то наверняка попадали в такую ситуацию: по какой-то причине отключается сервер VMware vCenter (он может работать, но не отвечать на подключения), а с ним вместе недоступна и его база (на том же хосте или на отдельном) - и вам нужно искать хост ESXi с этими ВМ, чтобы поднять всю виртуальную инфраструктуру. А хостов ESXi в кластере у вас может быть несколько десятков.
Можно, конечно, сделать правило DRS для vCenter, чтобы он не перемещался по хостам, но в случае срабатывания аварийного восстановления VMware HA, сервер vCenter вполне может поменять хост, так как HA забивает на правила DRS.
В этом случае может оказаться полезным интерфейс PowerCLI, который позволит найти нужную ВМ по ее имени. Но сначала вам нужно разрешить множественные соединения к нескольким хостам. Делается это следующей командой:
Это, конечно, покатит только если у вас на всех хостах ESXi везде одинаковый пароль root. Но если они там разные, то нужно будет для каждого сервера исполнить соответствующую команду.
Далее просто ищем нужную виртуальную машину по ее имени:
(get-vm vCenter01).vmhost
(get-vm SQL01).vmhost
В выводе этих команд будут хосты ESXi, на которых они зарегистрированы. Остается только открыть к ним консоль через vSphere Client и включить эти машины.
Документ состоит из двух частей: в первой части рассказывается о том, как правильно спроектировать кластер vMSC и настроить платформу VMware vSphere соответствующим образом:
Во второй части подробно описаны различные сценарии сбоев и их обработка кластером vMSC в вашей распределенной виртуальной инфраструктуре:
В документе описаны следующие виды сбоев:
Отказ одного хоста в основном датацентре
Изоляция одного хоста в основном датацентре
Разделение пула виртуальных хранилищ
Разделение датацентра на сегменты (сети хостов и сети хранилищ)
Отказ дисковой полки в основном ЦОД
Полный отказ всех хранилищ в основном датацентре
Потеря устройств (полный выход из строя, выведение из эксплуатации) - Permanent Device Loss (PDL)
Понятное дело, что документ обязателен к прочтению, если вы планируете строить распределенную инфраструктуру для ваших виртуальных машин на платформе VMware vSphere 6.0.
Интересная история произошла тут между компаниями VMware и Nutanix. Инженеры и сейлы из VMware решили провести сравнение производительности программных отказоустойчивых кластеров на базе локальных хранилищ серверов VMware Virtual SAN и Nutanix. Создав тестовую конфигурацию и выбрав профиль нагрузки, компания VMware сделала тест в средах Virtual SAN и Nutanix.
Кстати, вот конфигурация тестового кластера хранилищ:
4 x Dell XC630-10 для Nutanix,
4 x Dell R630 для vSphere с кластером VSAN
2 x Intel E5-2690 v3 на сервер
12 ядер на процессор 2.6GHz, 256 ГБ памяти на сервер
Двухпортовый 10Gb Ethernet
1 x PERC H730 Mini на сервер
2 x 400GB Intel S3700 на сервер
6 дисков x 1TB 7200 RPM NL-SAS (Seagate) на сервер
Но тут спецы из VMware решили заглянуть в EULA Nutanix, а там написано (п. 2.1, подпункт e):
You must not disclose the results of testing, benchmarking or other performance or evaluation information related to the Software or the product to any third party without the prior written consent of Nutanix
То есть, публиковать результаты тестирования нельзя. Вот такой облом. А ведь VMware много раз ругали за то, что она сама запрещает публиковать результаты тестирования производительности с конкурирующими продуктами. Это также зафиксировано в EULA:
You may use the Software to conduct internal performance testing and benchmarking studies. You may only publish or otherwise distribute the results of such studies to third parties as follows: (a) if with respect to VMware’s Workstation or Fusion products, only if You provide a copy of Your study to benchmark@vmware.com prior to distribution; (b) if with respect to any other Software, only if VMware has reviewed and approved of the methodology, assumptions and other parameters of the study (please contact VMware at benchmark@vmware.com to request such review and approval) prior to such publication and distribution.
VMware, конечно, утверждает, что у нее условия мягче, но по-сути у них написано одно и то же. Публиковать результаты тестов без разрешения нельзя. А разрешение, конечно, никто не даст, так как опубликовать конкуренты захотят только, если у них все работает лучше и быстрее.
Поэтому VMware ничего не оставалось, как опубликовать результаты только своих тестов и разбить их по профилям нагрузки, отметив, что желающие сравнить пользователи сами могут убедиться, что Nutanix работает медленнее, проведя тесты самостоятельно.
Надо также отметить, что VMware отправила запрос на публикацию в Nutanix, на что получила ожидаемый ответ - публиковать нельзя.
Ну и, собственно, результаты тестирования для кластера Virtual SAN:
Если вкратце, то компоненты vCenter предлагается защищать с помощью следующих решений:
1. Кластер высокой доступности VMware HA и сервис слежения за vCenter - Watchdog.
Сервис HA автоматически перезапускает виртуальную машину с vCenter отказавшего сервера на другом хосте кластера, а сервис Watchdog (он есть как на обычном vCenter, так и на vCenter Server Appliance) следит за тем, чтобы основная служба vCenter работала и отвечала, и запускает/перезапускает ее в случае сбоя.
2. Защита средствами VMware Fault Tolerance.
Теперь технология VMware FT в VMware vSphere 6.0 позволяет защищать ВМ с несколькими vCPU, поэтому данный способ теперь подходит для обеспечения непрерывной доступности сервисов vCenter и мгновенного восстановления в случае сбоя оборудования основного хоста ESXi.
Компания VMware предоставляет специализированный API, который могут использовать партнеры для создания решений, защищающих приложения в гостевой ОС, в частности, сервис vCenter. Одно из таких приложений - Symantec ApplicationHA. Оно полностью поддерживает vCenter, имеет специализированного агента и перезапускает нужные службы в случае сбоя или зависания сервиса.
4. Средства кластеризации на уровне гостевой ОС (с кворумным диском).
Это один из древнейших подходов к защите сервисов vCenter. О нем мы писали еще вот тут.
Для организации данного типа защиты потребуется основная и резервная ВМ, которые лучше разместить на разных хостах vCenter. С помощью кластера Windows Server Failover Clustering (WSFC) организуется кворумный диск, общий для виртуальных машин, на котором размещены данные vCenter. В случае сбоя происходит переключение на резервную ВМ, которая продолжает работу с общим диском. Этот метод полностью поддерживается с vCenter 6.0:
Кстати, в документе есть пошаговое руководство по настройке кластера WSFC для кластеризации vCenter 6.0 (не забудьте потом, где его искать).
Ну и в заключение, сводная таблица по функциям и преимуществам приведенных методов:
Далее идет описание средств высокой доступности в Enterprise-инфраструктуре с несколькими серверами vCenter, где компоненты PSC (Platform Services Controller) и vCenter разнесены по разным серверам. Схема с использованием балансировщика:
Обратите внимание, что для PSC отказоустойчивость уже встроена - они реплицируют данные между собой.
Та же схема, но с кластеризованными серверами vCenter средствами технологии WSFC:
Использование географически распределенных датацентров и сервисов vCenter в них в едином домене доступа SSO (Single Sign-On) за счет технологии Enhanced Linked Mode (каждый сайт независим):
То же самое, но со схемой отказоустойчивости на уровне каждой из площадок:
Ну и напоследок 2 дополнительных совета:
1. Используйте Network Teaming для адаптеров vCenter (физических или виртуальных) в режиме отказоустойчивости, подключенные к дублирующим друг друга сетям.
2. Используйте Anti-affinity rules кластера HA/DRS, чтобы основная и резервная машина с vCenter не оказались на одном хосте VMware ESXi.
Да, и не забывайте о резервном копировании и репликации виртуальной машины с vCenter. Сделать это можно либо средствами Veeam Backup and Replication 8, либо с помощью VMware vSphere Replication/VMware vSphere Data Protection.
Некоторое время назад мы писали про обработку гипервизором VMware vSphere таких состояний хранилища ВМ, как APD (All Paths Down) и PDL (Permanent Device Loss). Вкратце: APD - это когда хост-сервер ESXi не может получить доступ к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды, а PDL - это когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось.
Так вот, в новой версии VMware vSphere 6.0 появился механизм VM Component Protection (VMCP), который позволяет обрабатывать эти ситуации со стороны кластера высокой доступности VMware HA в том случае, если в нем остались другие хосты, имеющие доступ к виртуальной машине, оставшейся без "хост-хозяина".
Для того чтобы это начало работать, нужно на уровне кластера включить настройку "Protect against Storage Connectivity Loss":
Далее посмотрим на настройки механизма Virtual Machine Monitoring, куда входят и настройки VM Component Protection (VMCP):
С ситуацией PDL все понятно - хост больше не имеет доступа к виртуальной машине, и массив знает об этом, то есть вернул серверу ESXi соответствующий статус - в этом случае разумно выключить процесс машины на данном хосте и запустить ВМ на других серверах. Тут выполняется действие, указанное в поле Response for a Datastore with Permanent Device Loss (PDL).
Со статусом же APD все происходит несколько иначе. Поскольку в этом состоянии мы не знаем пропал ли доступ к хранилищу ВМ ненадолго или же навсегда, происходит все следующим образом:
возникает пауза до 140 секунд, во время которой хост пытается восстановить соединение с хранилищем
если связь не восстановлена, хост помечает датастор как недоступный по причине APD Timout
далее VMware HA включает счетчик времени, который длится ровно столько, сколько указано в поле Delay for VM failover for APD (по умолчанию - 3 минуты)
по истечении этого времени начинается выполнение действия Response for a Datastore with All Paths Down (APD), а само хранилище помечается как утраченное (NO_Connect)
У такого механизма работы есть следующие особенности:
VMCP не поддерживает датасторы Virtual SAN - они будут просто игнорироваться.
VMCP не поддерживает Fault Tolerance. Машины, защищенные этой технологией, будут получать перекрывающую настройку не использовать VMCP.
Мы уже весьма немало писали про возможности обновленной версии платформы виртуализации 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]. Весьма удобно.
Улучшенный механизм vSphere Network I/O Control версии 3 позволяет гарантировать уровень обслуживания на уровне vNIC виртуальной машины. Применять NetIOC можно также и к Distributed Port Group:
На этом вкратце все. Ну и так для общей информации - улучшения режима Linked Mode для серверов vCenter:
Новые лабораторные работы по VMware vSphere 6 - попробуйте новую версию платформы без установки.
Как почти все из вас знают, компания VMware совсем недавно анонсировала новую версию платформы виртуализации VMware vSphere 6 и другие продукты серверной линейки (наша последняя статья об этом тут). Пока сам продукт недоступен для загрузки в релизной версии, но компания VMware на днях предоставила возможность попробовать его вживую в виде лабораторных работ - VMware Hands-On Labs (HoL).
В рамках лабы вам развертывают виртуальную машину, с которой вы работаете прямо в браузере:
На данный момент доступно 4 новых лабораторных работы:
Эта лаба вводит начинающих в суть темы отказоустойчивых кластеров Virtual SAN и позволяет понять основные преимущества технологии на практике, никакого булшита. Модули лабы:
Virtual SAN Setup and Enable
Virtual SAN with vMotion, Storage vMotion and HA Interoperability
В этой небольшой лабораторной работе вам расскажут про технологию EVO:RAIL, которая представляет собой стандартизованный строительный блок виртуальной инфраструктуры для небольших компаний. С технической точки зрения EVO:RAIL - это двухюнитовый блок, представляющий собой 4-узловую структуру на базе архитектуры "microserver", которая сочетает в себе 4 полноценных микросервера в 2-юнитовой корзине.
Эта лабораторная работа, посвященная возможным вариантам применения VMware Horizon 6, была доступна и ранее. Но теперь в нее добавили модуль о технологии AppVolumes, про которую мы писали вот тут (ранее это называлось CloudVolumes).
Модули лабораторной работы:
Build and Operate the Mobile Secure Workplace
Build and Operate the Call Center Desktop
Build and Operate the Branch Office Desktop
Take a Guided Tour of vCOPS for View
Understanding use cases for Application Remoting
Understanding use cases for Cloud Pod Architecture
Mirage-Controlled View Static Desktops
Guided Tour of AppVolumes
Время на прохождение: 5-8 часов (то есть на всю лабу лучше выделить целый день).
В течение пары недель компания VMware обещает выложить еще несколько лабораторных работ, посвященных VMware vSphere 6 и другим продуктам и технологиям обновленной серверной линейки, о которых мы вам обязательно расскажем. Можно также следить за обновлениями в твиттер-аккаунте VMware HoL.
Как вы знаете, вчера компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, но нас больше всего заинтересовала технология непрерывной доступности VMware Fault Tolerance.
Ранее никто не воспринимал технологию Fault Tolerance всерьез, поскольку она была доступна только для виртуальных машин с одним vCPU, а такие машины, как правило, не делаются для бизнес-критичных приложений, для которых, собственно, технология Fault Tolerance и создавалась.
Теперь VMware Fault Tolerance в VMware vSphere 6.0 полноценно доступна для виртуальных машин с четырьмя vCPU и 64 ГБ оперативной памяти. И все это поддерживается в производственной среде.
Какие преимущества дает VMware FT в vSphere 6.0:
Непрерывная доступность и полное сохранение данных ВМ в случае отказа хоста ESXi.
При отказе не разрывается TCP-соединение.
Срабатывание Fault Tolerance полностью прозрачно для гостевой системы.
При сбое хоста происходит переключение на новую первичную ВМ, при этом на другом хосте автоматически поднимается новая резервная ВМ.
Что нового в Fault Tolerance 6.0:
Теперь технология непрерывной доступности VMware Fault Tolerance поддерживает виртуальные машины с 4 vCPU и объемом памяти до 64 ГБ.
Fast Check-Pointing - новая технология, предназначенная для поддержания исходного и резервного узла в синхронном состоянии, пришедшая на смену технологии "Record-Replay".
Поддержка технологии горячей миграции как для Primary, так и для Secondary-узла.
Возможность резервного копирования виртуальных машин, защищенных с помощью FT, технологией vStorage APIs for Data Protection. То есть, для таких ВМ теперь работет Veeam Backup and Replication.
FT в vSphere 6.0 поддерживает новые типы дисков, такие как EZT, Thick или Thin Provisioned. Для vSphere 5.5 и более ранних поддерживаются только диски типа Eager Zeroed Thick.
Возможность создания снапшотов виртуальных машин, защищенных FT.
Новая версия FT поддерживает отдельные копии файлов ВМ (.vmx и .vmdk) для каждой машины, чтобы защитить машину не только от сбоев хоста, но и от сбоев хранилища, которые могут произойти одновременно со сбоем хоста. Файлы Primary и Secondary VM могут быть на разных виртуальных хранилищах.
Но по-прежнему, для 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 HA полностью поддерживается:
Для наглядности есть вот такая табличка, описывающая отличия от предыдущей версии FT:
Надо понимать, что SMP-FT вызовет падение производительности гостевой ОС, по оценкам VMware - это около 10-30% в зависимости от нагрузки.
Ну и помните, что VMware Fault Tolerance на защитит от сбоя на уровне приложения - если он произойдет в основной ВМ, то будет и в резервной ВМ, поскольку машины синхронизированы на уровне исполнения инструкций в процессорах.
Многие из вас знают про решение VMware Virtual SAN, представляющее собой средство для создания отказоустойчивых кластеров хранилищ на базе локальных дисков серверов VMware ESXi. Но это всего лишь средство для хранения и обеспечения отказоустойчивости виртуальных машин, а можно ли все пространство хранения в небольшой компании организовать полностью на базе локальных дисков серверов и управлять ими из одной точки?
Компания Nexenta считает, что можно, предлагая пользователям VMware vSphere и VMware Virtual SAN продукт NexentaConnect, позволяющий создавать NFS и SMB ресурсы для размещения данных виртуальной среды и пользователей на локальных дисках хост-серверов.
NexentaConnect это надстройка над Virtual SAN, которая предоставляет следующие возможности централизованно управляемого хранилища:
Экспорт файловых шар по протоколам NFSv3, NFSv4 и SMB 2.1.
Оптимизированный кэш на чтение, размещенный на стороне хост-серверов.
Техники сжатия данных и дедупликации.
Быстрая настройка прямо из vSphere Web Client.
Совместимость с VMware HA и DRS.
Интеграция с доменом AD (поддержка AAA и Kerberos).
Использование преимуществ Virtual SAN.
NexentaConnect состоит из следующих компонентов:
Плагин для vSphere (как для Web Client, так и для vSphere Client).
NexentaConnect Manager – виртуальный модуль (Virtual Appliance) на базе Ubuntu Linux (64 Bit), предоставляющий сервисы управления решением, такие как мониторинг, планировщик событий, база данных, обслуживание операций и т.п.
NexentaConnect Filers – это компоненты, реализующие, собственно, экспорт сетевых шар. Развертываются автоматически по одному на кластер Virtual SAN в момент создания первой общей папки.
Особенности файлеров:
Отдельная файловая система, составленная из виртуальных дисков VMDK по 2 ТБ (для каждой из политик хранения). 2 ТБ - это для того, чтобы обеспечить поддержку со стороны VMware VSAN. Всего можно объединить до 30 VMDK на файлер.
Размер блока 128 КБ.
Развертывание при первом обращении - масштабирование пространства хранения по требованию.
Развертывание как Thin provisioned, так и в режиме заранее аллоцированного пространства.
Параметры файлеров:
ОС Ubuntu Linux (64 Bit)
4 vCPU
16 GB RAM
Минимум 2 виртуальных диска (до 30)
Объем диска до 2 TB
2 сетевых адаптера
Достоинства продукта:
Сжатие данных алгоритмом LZ4 в реальном времени с небольшой нагрузкой на CPU.
До 500 MB/s на компрессию (на ядро).
До 1.5 GB/s на декомпрессию (на ядро).
Дедупликация нулевых блоков.
Дедупликация данных в режиме Tech Preview (полноценная будет во второй версии).
Требования для развертывания NexentaConnect:
VMware vSphere 5.5 или выше
VMware vCenter Server 5.5 U1 или выше (Windows и Linux)
ESXi 5.5 U1 или выше
Кластер VMware vSphere с установленным Virtual SAN
VMware vSphere Web Client
VMware HA (опционально)
Службы каталога (Directory Services - опционально)
Microsoft Windows Active Directory 2008 R2 или выше
VMware vCenter Server 5.5 U1 или выше
DNS
DHCP
NexentaConnect - это еще один способ построить Scale-Out файловый сервер (то есть масштабирующиеся по требованию службы хранения). Например, это востребованной в инфраструктуре виртуальных ПК предприятия, где требуется хранить не только виртуальные машины, но и данные их пользователей.
Об одном из подобных решений - StarWind Virtual SAN - мы регулярно пишем (сейчас это лучшее решение на рынке). Вот тут, например, мы писали про документ о построении инфраструктуры файловых сервисов на базе StarWind.
Добавим, что решение NexentaConnect доступно не только для инфраструктуры VMware vSphere, но и для Citrix XenServer (пока в бете). Больше подробностей о продукте можно узнать вот на этой странице.
В блоге joshodgers.com появилось пять интересных статей о том, как правильно виртуализовать почтовый сервер Microsoft Exchange на платформе VMware vSphere.
Тут обсуждается необходмый объем памяти. Не рекомендуется использовать Memory Overcommitment (то есть, часть ресурсов надо всегда держать свободными), а вот Memory Reservations предлагается устанавливать в 100% - таковы рекомендации для бизнес-критичного сервиса.
К выделенной памяти виртуальным машинам рекомендуется прибавлять как минимум 25% требуемой емкости памяти хоста ESXi. То есть, если у вас машина с 96 ГБ RAM, то хост должен иметь как минимум 128 ГБ физической памяти. Также рекомендуется сайзить машину с Exchange в пределах одного NUMA-узла.
Тут основная рекомендация - держать машины с ролями MBX / MSRна одном хосте в целях быстродействия (средствами хост-групп), а также настроить их восстановление в случае сбоя также на один хост. Также уровень автоматизаци миграций ВМ в кластере рекомендуют выставить как "Fully Automated" (а Migration Threshold как 3).
В этой части цикла описываются рекомендуемые настройки механизма VMware HA.
В этой статье, пожалуй, больше всего дается практических советов и рекомендаций по настройке VMware HA в кластере высокой доступности для виртуальных машин с Exchange на борту.
Как вы знаете, у компании VMware был такой продукт как vCenter Server Heartbeat, который защищал управляющий сервер vCenter от сбоя различных его компонентов и на различных уровнях. Некоторое время этот продукт был снят с производства, и теперь защиту vCenter от сбоев рекомендуется обеспечивать стандартными средствами платформы VMware vSphere.
Надо сказать, что обеспечение надежности сервера vCenter, работающего в виртуальной машине (а сейчас уже мало кто ставит его в физической), начинается с обеспечения доступности и дублирования компонентов, которые находятся "под ним", а именно: хост-сервер ESXi, источники питания, хранилища, сетевые подключения и т.п.
Ну а, собственно, для правильной конфигурации самой платформы vSphere и сервера vCenter, компания VMware выпустила полезный документ "VMware vCenter Server 5.5 Availability Guide".
Итак, начнем с того, что VMware предлагает разделить сервисы vCenter на две большие части:
Compute Node - это сам vCenter и все сервисы к нему относящиеся (SSO, Web Client, Inventory service)
Data Node - это узел, где хранятся данные vCenter, попросту говоря, это СУБД и сама база данных.
Понятно, что оба этих компонента могут быть как на одном сервере (для небольшой инфраструктуры), так и в разных машинах, когда требуется производительная база данных (например, в Enterprise-окружениях).
Если у вас большая виртуальная инфраструктура, где есть множество управляющих компонентов, то вы можете выделить отдельный кластер из трех и более хостов чисто под эти нужды.
Но чаще всего у вас есть просто одна или максимум две виртуальные машины - одна под vCenter, вторая - под его базу данных.
Доступность Compute Node
Это раздел включает в себя доступность следующих комопнентов:
vCenter Single Sign-On services
vCenter Inventory Service
vCenter Server
vCenter Server management Web service
vSphere Web Client
Здесь рекомендуется настроить защиту средствами технологии VMware HA и придерживаться следующих рекомендаций:
Создавайте (по-возможности) отдельный кластер для управляющих сервисов - в случае отказа любого из компонентов сервисы будут перезапущены с помощью HA автоматически.
Включите не только VMware HA, но и технологию virtual machine monitoring, которая отключена по умолчанию. Это позволит перезапустить сервер с vCenter при зависании гостевой ОС.
Включите и настройте admission control в кластере HA/DRS, где работает vCenter. Это позволит гарантированно перезапустить vCenter на одном из хостов в случае сбоя.
Установите restart priority в настройках HA для машины с vCenter Server в значение "High". Он будет первым запускаться.
Если ваш vCenter находится в Windows-машине, то можно настроить автоматический рестарт машины при невозможности после многократных попыток запустить службу vCenter Service.
Выглядеть это может примерно вот так (только помните, что в случае такй настройки, виртуальная машина может впасть в цикл бесконечных перезагрузок).
Если у вас компоненты vCenter на разных машинах, не забудьте установить правило affinity rule, чтобы машины оказались на одном хосте при миграции и восстановлении, в целях сохранения максимальной производительности управляющего сервиса.
Также для гарантии можно выделить управляющим компонентам гарантированную физическую память (Memory Reservation) в настройках виртуальной машины.
Доступность Data Node
Тут VMware приводит следующие рекомендации:
Также, как и в случае с Compute Node, рекомендуется использовать для управляющих сервисов и базы данных отдельный кластер.
Если вы используете решение для кластеризации vCenter, необходимо убедиться, что настройка ForceAffinePoweron в параметрах vSphere DRS установлена в значение 1, чтобы включать сервер БД, несмотря на правила DRS.
Так же, как и в случае с Compute Node, используйте технику virtual machine monitoring для перезапуска зависшей гостевой ОС.
То же самое и про admission control - используйте его для гарантированного восстановления ВМ с сервером БД.
Аналогично Compute Node, установите restart priority в настройках HA для машины с базой данных в значение "High". Он будет первым запускаться.
Для защиты vCenter Server SQL Server database можно использовать Microsoft Failover Clustering, который официально поддерживается со стороны VMware. Табличка совместимости СУБД и версий vCenter приведена ниже.
Компания VMware выпустила финальные версии обновленных настольных платформ виртуализации VMware Workstation 11 и VMware Player 7 Pro. Напомним, что ранее мы писали об анонсе этих продуктов тут.
Важно - продукты теперь полностью 64-битные, то есть вам потребуется 64-битный процессор и 64-битная ОС (однако гостевые ОС могут быть любые - и 32- и 64-битные).
Итак, новые возможности VMware Workstation 11:
New OS Support - Теперь появилась поддержка не только Windows 8 / 8.1, но и Windows 8.1 Update 1 в качестве хостовой и гостевой ОС (также поддерживается и Windows Server 2012 R2). Кроме того, поддерживаются также последние версии десктопных платформ Ubuntu 14.10, Fedora 20, RHEL 7, CentOS 7, Debian 7.6, OpenSUSE 13.2 и других Linux-дистрибутивов.
Ready for Windows 10 Technical Preview - возможность запуска превью-версии операционной системы Windows 10 без дополнительного шаманства и модификаций.
Поддержка последних процессоров микроархитектуры Haswell. Новые процессоры архитектуры Intel 64-bit x86 теперь поддерживаются намного лучше и дают до 45% прироста производительности (мультимедиа, расшифровка/зашифровка) по сравнению с их использованием в продукте Workstation 10.
Новые максимальные значение параметров хоста и виртуальных машин - до 16 vCPU для машины, виртуальные диски по 8 ТБ, 64 ГБ памяти хоста, 64 ГБ оперативной памяти на машину (а также 2 ГБ видеопамяти, что очень важно для требовательных к графике приложений).
VMware Hardware Version 11 - очередное обновление поколения виртуального программного обеспечения. Теперь возможностей у устройств виртуальной машины станет значительно больше. Например, можно создавать виртуальные машины с числом виртуальных процессоров (vCPU) до 16, кроме того улучшилась поддержка устройств USB 3.0, и появилась возможность выделять графическую память на уровне отдельной гостевой ОС.
Connection to VMware vCloud Air - теперь можно присоединиться к сервису VMware vCloud Air, чтобы использовать виртуальные машины из публичного облака компании. Разработчики могут просто шарить свою машину с удаленными коллегами, и они сами, прощелкивая процесс по шагам, смогут таким образом воспроизводить проблемные ситуации.
CPU enablement - кроме поддержки 16 vCPU, появилась полная поддержка новых поколений процессоров микроархитектур Intel Haswell и AMD Jaguar. Также поддерживаются на уровне совместимости процессоры Intel Broadwell и AMD Steamroller.
Virtual xHCI controller - виртуальный контроллер xHCI появился еще в версии virtual hardware 8, но в этой версии он соответствует спецификации Intel xHCI 1.0. Также тут ожидается лучшая производительность устройств USB 3.0.
Dedicated graphics memory for guest operating system - теперь полностью доступно управление выделением графической памяти под гостевые ОС. Это дает пользователю больший контроль и гибкость в конфигурации виртуальной машины. Настройка эта регулируется в Virtual Machine Settings -> Hardware -> Display. Не рекомендуют выделять гостевой ОС слишком много (будут глюки) и слишком мало видеопамяти (будут тормоза).
Windows 8 Unity mode improvements - был существенно улучшен процесс работы с механизмом Unity, особенно для ВМ под управлением Windows 8 / 8.1. Кроме того улучшилась работа с экраном "Пуск" - когда происходит переключение между гостевой и хостовой ОС.
Boot virtual machine with EFI - эта версия Workstation позволяет создавать и запускать виртуальную машину на базе EFI как альтернативе BIOS. Для этого нужно выставить следующую настройку - Virtual Machine Settings -> Options -> Advanced, далее отметить "Boot with EFI instead of BIOS".
Experimental performance tuning for VM suspend and resume - в этом релизе платформы можно улучшить производительность операций по приостановке и возобновлению работы виртуальной машины (suspend/resume). Для этого машина должна иметь версию виртуального аппаратного обеспечения (Hardware Version) 11. Для этого необходимо в vmx-файл конфигурации ВМ добавить следующие строчки:
mainMem.save.vmem="FALSE"
checkpoint.compressDumper="TRUE"
Этот твиг действует как для шифрованной, так и обычной виртуальной машины. Он ускоряет suspend до 20% и resume до 60%.
Новые возможности VMware Player 7 Pro:
Enhanced Operating System Compatibility – VMware Player 7 Pro запускается и работает на всех продакшен-релизах Windows, включая Windows 8.1. Кроме того, поддерживаются устаревшие ОС, такие как Windows XP and Windows 7.
Greater Hardware Compatibility – VMware Player 7 Pro оптимизирован для экранов новых ноутбуков, а также планшетов, работающих с высоким разрешением.
Updated VMware Compatibility – VMware Player 7 Pro будет запускать защищенные ВМ, созданные с помощью VMware Workstation 11 или VMware Fusion 7 Pro. Решение имеет средства обратной совместимости для устаревших ОС, которые помогают защищать виртуальные машины средствами шифрования, паролем на текущую сессию, запретом доступа к USB и изоляцией меду хостом и гостевой ОС.
VMware Workstation 11 и VMware Player 7 доступны для приобретения по ценам $249.99 и $149.99, соответственно (это американские цены). Для тех, кто купил продукты Workstation 11 и Player 6 Pro в октябре и ноябре - апргрейд будет бесплатным, остальным пользователям придется заплатить $149,99 и $79,99, соответственно.
Скачать VMware Workstation 11 можно по этой ссылке, а VMware Player 7 по этой.
Перечислим основные возможности VMware Workstation 11:
New OS Support - Теперь появилась поддержка не только Windows 8 / 8.1, но и Windows 8.1 Update 1 в качестве хостовой и гостевой ОС. Также в Workstation 11 заявлена поддержка анонсированной недавно Windows 10 Tech Preview. Кроме того, поддерживаются также последние версии десктопных платформ Ubuntu 14.10, Fedora 20, RHEL 7, CentOS 7, Debian 7.6, OpenSUSE и других Linux-дистрибутивов.
Поддержка последних процессоров микроархитектуры Haswell. Новые процессоры архитектуры Intel 64-bit x86 теперь поддерживаются намного лучше и дают до 45% прироста производительности (мультимедиа, расшифровка/зашифровка) по сравнению с их использованием в продукте Workstation 10.
Новые максимальные значение параметров хоста и виртуальных машин - до 16 vCPU для машины, виртуальные диски по 8 ТБ, 64 ГБ памяти хоста, 64 ГБ оперативной памяти на машину (а также 2 ГБ видеопамяти).
VMware Hardware Version 11 - очередное обновление поколения виртуального программного обеспечения. Теперь возможностей у устройств виртуальной машины станет значительно больше. Например, можно создавать виртуальные машины с числом виртуальных процессоров (vCPU) до 16, кроме того улучшилась поддержка устройств USB 3.0, и появилась возможность выделять графическую память на уровне отдельной гостевой ОС.
Connection to VMware vCloud Air - теперь можно присоединиться к сервису VMware vCloud Air, чтобы использовать виртуальные машины из публичного облака компании. Разработчики могут просто шарить свою машину с удаленными коллегами, и они сами, прощелкивая процесс по шагам, смогут таким образом воспроизводить проблемные ситуации.
CPU enablement - кроме поддержки 16 vCPU, появилась полная поддержка новых поколений процессоров микроархитектур Intel Haswell и AMD Jaguar. Также поддерживаются на уровне совместимости процессоры Intel Broadwell и AMD Steamroller.
Virtual xHCI controller - виртуальный контроллер xHCI появился еще в версии virtual hardware 8, но в этой версии он соответствует спецификации Intel xHCI 1.0. Также тут ожидается лучшая производительность устройств USB 3.0.
Dedicated graphics memory for guest operating system - теперь полностью доступно управление выделением графической памяти под гостевые ОС. Это дает пользователю больший контроль и гибкость в конфигурации виртуальной машины. Настройка эта регулируется в Virtual Machine Settings -> Hardware -> Display. Не рекомендуют выделять гостевой ОС слишком много (будут глюки) и слишком мало видеопамяти (будут тормоза).
Windows 8 Unity mode improvements - был существенно улучшен процесс работы с механизмом Unity, особенно для ВМ под управлением Windows 8 / 8.1. Кроме того улучшилась работа с экраном "Пуск" - когда происходит переключение между гостевой и хостовой ОС.
Boot virtual machine with EFI - эта версия Workstation позволяет создавать и запускать виртуальную машину на базе EFI как альтернативе BIOS. Для этого нужно выставить следующую настройку - Virtual Machine Settings -> Options -> Advanced, далее отметить "Boot with EFI instead of BIOS".
Experimental performance tuning for VM suspend and resume - в этом релизе платформы можно улучшить производительность операций по приостановке и возобновлению работы виртуальной машины (suspend/resume). Для этого машина должна иметь версию виртуального аппаратного обеспечения (Hardware Version) 11. Для этого необходимо в vmx-файл конфигурации ВМ добавить следующие строчки:
mainMem.save.vmem="FALSE"
checkpoint.compressDumper="TRUE"
Этот твиг действует как для шифрованной, так и обычной виртуальной машины. Он ускоряет suspend до 20% и resume до 60%.
Также VMware обновила свой "плеер" виртуальных машин - VMware Player 7 Pro. Напомним, что он в простой форме позволяет запускать уже созданные виртуальные машины, среди которых могут быть защищенные ВМ (restricted virtual machines).
Новые возможности VMware Player 7 Pro:
Enhanced Operating System Compatibility – VMware Player 7 Pro запускается и работает на всех продакшен-релизах Windows, включая Windows 8. Кроме того, поддерживаются устаревшие ОС, такие как Windows XP and Windows 7.
Greater Hardware Compatibility – VMware Player 7 Pro оптимизирован для экранов новых ноутбуков, а также планшетов, работающих с высоким разрешением.
Updated VMware Compatibility – VMware Player 7 Pro будет запускать защищенные ВМ, созданные с помощью VMware Workstation 11 или VMware Fusion 7 Pro. Решение имеет средства обратной совместимости для устаревших ОС, которые помогают защищать виртуальные машины средствами шифрования, паролем на текущую сессию, запретом доступа к USB и изоляцией меду хостом и гостевой ОС.
Для обоих продуктов есть небольшое изменение по системным требованиям. Теперь хост и его ОС должны быть 64-битными (но запускать 32-битные виртуальные машины можно без проблем).
VMware Workstation 11 и VMware Player 7 Pro будут доступны в декабре этого года по ценам $249.99 и $149.99 соответственно (это штатовские цены, у нас традиционно будет дороже). Апгрейды с VMware Workstation 9.x и 10.x на Workstation 11 будут продаваться по цене $149.99, а апгрейды с VMware Player 6 Plus на VMware Player 7 Pro будут стоить $79.99. Все это будет доступно к заказу на момент выхода продуктов.
Для тех, кто покупает Workstation 10, начиная с этого момента, апгрейд будет бесплатным.
Новая архитектура сервисов управления VMware vCenter в VMware vSphere 6.
Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 6, о которых было подробно рассказано на прошедшей конференции VMworld 2014. Одним из нововведений новой версии станет новая архитектура сервисов управления VMware vCenter.
Надо начать с того, что "толстый" десктопный клиент vSphere Client в vSphere 6 по-прежнему останется доступен для управления виртуальными машинами через vCenter. Причины просты - компании VMware так и не удается довести до ума Web Client - он все еще притормаживает и не настолько быстро обновляет статус объектов, как это делает обычный vSphere Client. Однако все новые возможности будут появляться только в vSphere Web Client.
С точки зрения самого vCenter появляется новый сервис Platform Services Controller (PSC), который заменяет существующие сервисы Single Sign-On (напомним, что они уже были переписаны в версии SSO 5.5). Если ранее SSO был частью vSphere и обновлялся только вместе с платформой, то теперь PSC может быть обновлен отдельно (например, если появились новые источники аутентификации или были исправлены ошибки), что очень удобно.
На картинке ниже Infrastructure Controller (это так сейчас в бете называется Platform Services Controller) может быть выделен для каждого сервиса vCenter, но также и несколько сервисов vCenter могут использовать один PSC.
В обоих случаях сохраняются функции синхронизации данных между контроллерами и механика их отказоустойчивости.
Помимо стандартных функций аутентификации SSO, компонент PSC возьмет на себя управление лицензиями, а также хранение сертификатов.
Когда у вас до 8 серверов vCenter в рамках одной географической площадки, то можно использовать один PSC (который устанавливается на том же хосте, где и один из серверов vCenter). Ну а если у вас несколько датацентров, то для каждого разумнее использовать свой PSC, к которому подключаются не только сервисы vCenter, но и другие компоненты виртуальной инфраструктуры, например, продукт для управления облачной инфраструктурой VMware vCAC или средства автоматизации vRealize Orchestrator (бывший vCenter Orchestrator):
Шестую версию vCenter уже настоятельно рекомендуют устанавливать в виртуальной машине, так как только тогда можно будет воспользоваться преимуществами технологий отказоустойчивости и непрерывной доступности VMware HA и VMware Fault Tolerance. Ранее был продукт и для физических серверов - vCenter Heartbeat, но его сняли с производства.
Настало время объединить все сервисы управления виртуальной средой (vCenter, серверы vCAC, vCenter Log Insight, vCenter Orchestrator, vCenter Operations Manager и т.п.) в виде блоков в виртуальных машинах:
Также весьма существенно будет доработан виртуальный модуль vCenter Server Appliance (vCSA). Теперь он будет поддерживать до 1 000 серверов ESXi под своим управлением, 10 000 включенных виртуальных машин, 64 хоста ESXi на кластер HA/DRS, 6 000 ВМ в кластере, а также 10 серверов vCenter в режиме Linked Mode.
Как многие из вас знают, ранее режим Linked Mode не поддерживался со стороны vCSA, так как для этого режима использовалась модель Active Directory Application Mode (ADAM), не поддерживаемая в Linux. Теперь для Linked Mode используется собственная аутентификация, поэтому объединение нескольких машин vCSA в единую мета-сущность теперь вполне возможно.
Как Windows-версия, так и vCSA будут использовать встроенную БД vPostgres, а в качестве внешних БД стандартно будут поддерживаться Microsoft SQL Server и Oracle.
Ну и, помимо всего прочего, сейчас ходят слухи о выпуске вместе с VMware vSphere 6 утилиты для миграции с Windows-версии vCenter на vCSA. Эта штука для многих пользователей будет очень кстати.
Вчера компания VMware выпустила обновление для платформы виртуализации VMware vSphere 5.5 Update 2, которое включает в себя апдейты составляющих компонентов - ESXi 5.5 Update 2 и vCenter Server 5.5 Update 2.
Основные новые возможности обновления:
Поддержка хостов ESXi с объемом памяти до 6 ТБ.
Агентское ПО VMware vShield Endpoint Thin Agent для поддержки взаимодействия с решениями vShield, которое устанавливается в гостевых ОС вместе с VMware Tools, теперь называется VMware Tools Guest Introspection plugin.
vCenter Server 5.5 U2 теперь поддерживает следующие внешние СУБД: Oracle 12c, Microsoft SQL Server 2012 Service Pack 1 и Microsoft SQL Server 2014.
Поддержка vCloud Hybrid Service (vCHS, переименован в vCloud Air) - теперь в vSphere Web Client на стартовой странице появился новый контейнер Hybrid Cloud Service, который содержит установщики vCHS и vCloud Connector.
Появились технические средства программы Customer Experience Improvement Program - теперь данные о конфигурации вашей виртуальной инфраструктуры на еженедельной основе могут передаваться на сторону VMware, чтобы она могла шпионить анализировать их и улучшать продукт.
Множественные исправления ошибок, о которых можно почитать в Release Notes.
При этом у данного релиза есть следующие особенности:
Начиная с vSphere 5.5 Update 2, операционные системы Windows XP и Windows Vista не поддерживаются для vSphere Web Client. Полный список поддерживаемых систем находится в VMware Compatibility Guide.
Так как Linux-платформы больше не поддерживаются механизмом Adobe Flash, то Web Client не поддерживается в ОС Linux. Но не поддерживается - не значит, что это прекратило работать.
VMware vCenter Server Appliance в vSphere 5.5 поддерживает гайдлайны по обеспечению ИБ DISA Security Technical Information Guidelines (STIG), поэтому перед использованием этого решения надо бы почитать VMware Hardened Virtual Appliance Operations Guide для того, чтобы узнать о новых стандартах безопасности и о том, как нужно работать, чтобы security-примочки не мешали.
В VMware vSphere 5.5 U2 больше не поддерживается СУБД IBM DB2 как база данных для vCenter.
Вся информация касательно установки VMware Tools в гостевых ОС теперь представлена в общей документации по VMware vSphere (начиная с версии 5.5).
vSphere Data Protection 5.1 не совместима с vSphere 5.5 по причине изменения рабочих процессов в vSphere Web Client. То есть, вместе с vSphere надо обновлять и VDP.
При обновлении компонентов виртуальной инфраструктуры посмотрите также Interoperability Matrix.
Скачать VMware vSphere 5.5 Update 2 можно по этой ссылке. Документация доступна тут.
Не так давно мы писали о публичной бета-версии 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 для них. Также существенно будет улучшена производительность и уменьшен отклик при различных операциях.
Все это приходит в рамках концепции создания конвергентной инфраструктуры и развития парадигмы 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 можно прочитать вот тут.
Если вы хотите, чтобы никто не делал 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 Workstation и VMware Fusion, а на днях компания VMware обновила функциональность этих продуктов, выпустив VMware Workstation 11 и VMware Fusion 7 Technology Preview July 2014. Больше всего новых возможностей в этом выпуске получила платформа Fusion 7.
Июльский VMware Workstation 11 TP обладает следующими новыми возможностями:
New OS Support - Теперь появилась поддержка не только Windows 8 / 8.1, но и Windows 8.1 Update 1 в качестве хостовой и гостевой ОС. Кроме того, поддерживаются также последние версии десктопных платформ Ubuntu, Fedora, RHEL, OpenSUSE и других Linux-дистрибутивов. К моменту релиза список будет уточнен.
VMware Hardware Version 11 - очередное обновление поколения виртуального программного обеспечения. Теперь возможностей у устройств виртуальной машины станет значительно больше. Например, можно создавать виртуальные машины с числом виртуальных процессоров (vCPU) до 16, кроме того улучшилась поддержка устройств USB 3.0, и появилась возможность выделять графическую память на уровне отдельной гостевой ОС.
CPU enablement - кроме поддержки 16 vCPU, появилась полная поддержка новых поколений процессоров микроархитектур Intel Haswell и AMD Jaguar. Также поддерживаются на уровне совместимости процессоры Intel Broadwell и AMD Steamroller.
Virtual xHCI controller - виртуальный контроллер xHCI появился еще в версии virtual hardware 8, но в этой версии он соответствует спецификации Intel xHCI 1.0. Также тут ожидается лучшая производительность устройств USB 3.0.
Dedicated graphics memory for guest operating system - теперь полностью доступно управление выделением графической памяти под гостевые ОС. Это дает пользователю больший контроль и гибкость в конфигурации виртуальной машины. Настройка эта регулируется в Virtual Machine Settings -> Hardware -> Display. Не рекомендуют выделять гостевой ОС слишком много (будут глюки) и слишком мало видеопамяти (будут тормоза).
Windows 8 Unity mode improvements - был существенно улучшен процесс работы с механизмом Unity, особенно для ВМ под управлением Windows 8 / 8.1. Кроме того улучшилась работа с экраном "Пуск" - когда происходит переключение между гостевой и хостовой ОС.
Boot virtual machine with EFI - эта версия Workstation позволяет создавать и запускать виртуальную машину на базе EFI как альтернативе BIOS. Для этого нужно выставить следующую настройку - Virtual Machine Settings -> Options -> Advanced, далее отметить "Boot with EFI instead of BIOS".
[новое] Experimental performance tuning for VM suspend and resume - в этом релизе платформы можно улучшить производительность операций по приостановке и возобновлению работы виртуальной машины (suspend/resume). Для этого машина должна иметь версию виртуального аппаратного обеспечения (Hardware Version) 11. Для этого необходимо в vmx-файл конфигурации ВМ добавить следующие строчки: mainMem.save.vmem="FALSE"
checkpoint.compressDumper="TRUE"
Этот твиг действует как для шифрованной, так и обычной виртуальной машины. Он ускоряет suspend до 20% и resume до 60%.
Больше подробностей о возможностях VMware Workstation 11 рассказано на этой странице. Скачать превью решения можно по этой ссылке.
Июльский VMware Fusion 7 TP получил вот такие новые возможности:
Новое поколение виртуального программного обеспечения - Hardware Version 11. (VM > Settings > Compatibility). Описание см. выше.
Новые иконки в библиотеке, которые показывают состояние виртуальной машины в представлении списком.
Поддержка настройки видеопамяти для гостевой ОС (VM > Settings > Display). Описание см. выше.
Настройка использования встроенной видеокарты для Mac Book Pro с более, чем одним графическим модулем (GPU).
Обновленная поддержка конфигураций с несколькими мониторами, один из которых Retina.
Возможность настраивать горячие клавиши отдельно для каждой ВМ (VM > Settings > Keyboard & Mouse).
Улучшенная поддержка предрелизных версий Microsoft Windows.
Новый упрощенный способ установки VMware Tools под Windows 8 с использованием виртуального устройства USB CD virtual device.
[новое] Поддержка просмотра хостов VMware Workstation, VMware ESXi, VMware vSphere в библиотеке (в меню нужно выбрать File > Connect to Server).
[новое] Возможность удаленного управления виртуальными машинами на платформах VMware Workstation, VMware ESXi и VMware vSphere.
[новое] Улучшенная поддержка для еще не вышедших версий Mac OS X.
[новое] Возможность расшарить камеру iSight между хостовой и гостевой ОС.
Больше подробностей о возможностях VMware Fusion 7 рассказано на этой странице. Скачать превью решения можно по этой ссылке.
Некоторое время назад мы писали о том, что в самом ближайшем будущем ожидается выпуск обновленной версии решения для управления виртуальными и физическими ПК предприятия VMware Horizon 6. В преддверии выпуска этого продукта компания VMware запустила виртуальную лабораторную работу HOL-MBL-1451 - Horizon 6 with View Introduction, посвященную работе с решением для виртуализации ПК VMware Horizon View:
Лабораторные работы VMware Hands-On Labs (HOL) - это один из лучших форматов знакомства с продуктами VMware, так как в процессе их выполнения вы видите их интерфейс с пояснениями о назначении различных возможностей, а также указания, касающиеся дальнейших действий администратора. То есть самостоятельно нужно тыкать на клавиши и делать различные настройки, что гораздо лучше презентаций и мануалов.
За 4 часа, выделенных на лабораторную работу, администратор VMware View пройдет через процесс установки и настройки VDI-инфраструктуры и узнает обо всех новых возможностях продукта, включая такие функции как Application Remoting и архитектура Cloud Pod.
Если вы не хотите проходить лабу, а просто хотите ознакомиться с ее описанием в текстовом формате с картинками, то вот, пожалуйста:
На днях компания VMware сделала неожиданное для некоторых своих клиентов заявление - продукт для защиты серверов VMware vCenter (на уровне различных его компонентов) VMware vCenter Server Heartbeat снят с производства со 2-го июня 2014 года и не будет больше доступен. То есть, для него уже наступил End of Availability (EoA).
На самом деле, этот продукт всегда был каким-то непонятным. Продавали его в довесок к VMware vSphere, а заказчик потом и не знал, что с ним делать - интерфейс корявый, установка сложная, полезность сомнительная. Достаточно просто посмотреть на окно версии vCenter Server Heartbeat 5.5:
По-видимому, не меня одного раздражал этот иконочный привет из девяностых, а развивать продукт было сложно - надо ведь поддерживать как обычный vCenter, так и его линуксового собрата в виде готовой виртуальной машины - VMware vCenter Server Appliance (а его поддержки в Heartbeat не было).
Таким образом, теперь остаются следующие способы защитить сервер управления vCenter от сбоев:
Использовать виртуальную машину с vCenter Server и защищать ее средствами VMware HA (полностью поддерживается).
Использовать последние версии vCenter Server Heartbeat (End of Live).
Использовать сторонние решения по кластеризации (не поддерживается).
Использовать технологию VMware Fault Tolerance (в целом работает, но не поддерживается).
Так что способ защиты vCenter остался, по-сути, только один. Но и ничего страшного - не такая это суперкритичная часть инфраструктуры. Разворачивайте его в виртуальной машине, бэкапьте, включайте в кластер HA, да и все.
Поддержка VMware vCenter Server Heartbeat продлится до сентября 2018 года, поэтому пока можно не волноваться. Об остальном можно прочитать в FAQ на странице продукта.
Таги: VMware, vCenter, Heartbeat, EoL, Support, HA
Как многие знают, с выходом средства для создания отказоустойчивых кластеров хранилищ VMware Virtual SAN, строящихся на базе локальных дисков серверов ESXi, стало известно, что этот механизм интегрирован со средством серверной отказоустойчивости VMware HA.
"Интегрирован" - означает, что любая нештатная ситуация, случившаяся с хостами ESXi должна быть обработана на стороне обоих механизмов, а также решение этой проблемы находится в компетенции поддержки VMware. И правда - ведь отказавший хост ESXi нарушает целостность обоих кластеров, поскольку предоставляет и ресурсы хранилищ, и вычислительные ресурсы.
При этом, например, в случае каких-нибудь сбоев в сети может произойти "разделение" кластеров на сегменты, что может повлечь неоднозначность в их поведении, поскольку они используют разные сети для поддержания кластера (хождения хартбитов).
Например, на картинке представлено разделение кластеров VMware HA и Virtual SAN на два частично пересекающихся сегмента:
Это, конечно же, плохо. Поэтому в VMware vSphere 5.5 были сделаны изменения, которые автоматически переносят сеть хартбитов кластера VMware HA в подсеть VMware Virtual SAN. Это позволяет в случае разделения сети иметь два непересекающихся в плане обоих технологий сегмента:
Как адрес в случае изоляции хоста (isolation address) нужно использовать, чтобы надежно отличать изоляцию хоста от разделения сети на сегменты (network partitioning)?
Какие действия в случае изоляции хостов ESXi от остальной сети (isolation responses) нужно использовать?
Ну а в статье на блогах VMware даются вот такие ответы:
1. В качестве хранилищ, использующих datastore heartbeat в данной конфигурации, предлагается использовать датасторы, прицепленные к хостам ESXi, не входящим в кластер Virtual SAN. Объясняется это тем, что в случае разделения сети VSAN, механизм VMware HA сможет координировать восстановление виртуальных машин на хостах через эти хранилища.
2. По поводу isolation address есть следующие рекомендации:
При совместном использовании Virtual SAN и vSphere HA настройте такой isolation address, который позволит определить рабочее состояние хоста в случае отключения его от сети (сетей) VSAN. Например, можно использовать шлюз VSAN и несколько дополнительных адресов, которые задаются через расширенную настройку das.isolationAddressX (подробнее об этом - тут).
Настройте HA так, чтобы не использовать дефолтный шлюз management network (если эта не та же сеть, что и Virtual SAN network). Делается это через настройку das.useDefaultIsolationAddress=false.
Ну и общая рекомендация - если вы понимаете, как может быть разделен кластер с точки зрения сети, то найдите такие адреса, которые будут доступны с любого хоста при этом сценарии.
3. Ну и самое главное - действие isolation response, которое необходимо выполнить в случае, когда хост посчитал себя изолированным от других. На эту тему уже много чего писалось, но VMware объединила это вот в такие таблички:
Тип виртуальной машины
Хост имеет доступ к сети VSAN?
Виртуальные машины имеют доступ к своей сети VM Network?
Рекомендация для Isolation Responce
Причина
Не-VSAN машина (не хранится на хранилищах Virtual SAN)
Да
Да
Leave Powered On
ВМ работает нормально - зачем что-то делать?
Не-VSAN машина
Да
Нет
Leave Powered On
Подходит для большинства сценариев. Если же доступ машины к сети очень критичен и не критично состояние ее памяти - надо ставить Power Off, чтобы она рестартовала на других хостах (координация восстановления будет через сеть VSAN). Дефолтно же лучше оставить Leave Powered On.
VSAN и не-VSAN машина
Нет
Да
Leave Powered On
или
Power Off
См. таблицу ниже
VSAN и не-VSAN машина
Нет
Нет
Leave Powered On
или
Power Off
См. таблицу ниже
А теперь, собственно, таблица ниже, которая объясняет от чего зависят последние 2 пункта:
Наиболее вероятна ситуация, когда в случае изоляции хоста, все остальные также изолированы?
Будут ли хосты иметь доступ к heartbeat datastores,
если будут изолированы?
Важно ли сохранить память виртуальной машины при сбое?
Рекомендованная isolation policy (responce)
Причина
Нет
Да
Да
Leave Powered On
Важно состояние памяти ВМ. Так как есть доступ к хартбит-хранилищам, то ВМ не стартует на других хостах
Нет
Да
Нет
Power Off
Надо выключить ВМ, так как есть вероятность того, что ее вторая копия стартанет в другом сегменте разделенной сети.
Да
Нет
Да
Leave Powered On
Нет смысла выключать ВМ, так как хост-мастер операций не сможет инициировать ее восстановление, так как все хосты друг от друга изолированы.
Логика тут в принципе понятна, но в каждой конкретной ситуации может быть масса тонкостей касательно различных сценариев разделения и сбоев в сети, так что эти таблички лишь определяют направление мысли, а не дают готового рецепта.
Майское превью - первое в череде версий 2014 года, финальные же версии данных платформ виртуализации ожидаются через несколько месяцев.
На данный момент VMware Workstation 11 TP имеет следующие новые возможности:
New OS Support - Теперь появилась поддержка не только Windows 8 / 8.1, но и Windows 8.1 Update 1 в качестве хостовой и гостевой ОС. Кроме того, поддерживаются также последние версии десктопных платформ Ubuntu, Fedora, RHEL, OpenSUSE и других Linux-дистрибутивов. К моменту релиза список будет уточнен.
VMware Hardware Version 11 - очередное обновление поколения виртуального программного обеспечения. Теперь возможностей у устройств виртуальной машины станет значительно больше. Например, можно создавать виртуальные машины с числом виртуальных процессоров (vCPU) до 16, кроме того улучшилась поддержка устройств USB 3.0, и появилась возможность выделять графическую память на уровне отдельной гостевой ОС.
CPU enablement - кроме поддержки 16 vCPU, появилась полная поддержка новых поколений процессоров микроархитектур Intel Haswell и AMD Jaguar. Также поддерживаются на уровне совместимости процессоры Intel Broadwell и AMD Steamroller.
Virtual xHCI controller - виртуальный контроллер xHCI появился еще в версии virtual hardware 8, но в этой версии он соответствует спецификации Intel xHCI 1.0. Также тут ожидается лучшая производительность устройств USB 3.0.
Dedicated graphics memory for guest operating system - теперь полностью доступно управление выделением графической памяти под гостевые ОС. Это дает пользователю больший контроль и гибкость в конфигурации виртуальной машины. Настройка эта регулируется в Virtual Machine Settings -> Hardware -> Display. Не рекомендуют выделять гостевой ОС слишком много (будут глюки) и слишком мало видеопамяти (будут тормоза).
Windows 8 Unity mode improvements - был существенно улучшен процесс работы с механизмом Unity, особенно для ВМ под управлением Windows 8 / 8.1. Кроме того улучшилась работа с экраном "Пуск" - когда происходит переключение между гостевой и хостовой ОС.
Boot virtual machine with EFI - эта версия Workstation позволяет создавать и запускать виртуальную машину на базе EFI как альтернативе BIOS. Для этого нужно выставить следующую настройку - Virtual Machine Settings -> Options -> Advanced, далее отметить "Boot with EFI instead of BIOS".
В платформе VMware Fusion 7 TP появились следующие нововведения и улучшения:
Новое поколение виртуального программного обеспечения - Hardware Version 11. (VM > Settings > Compatibility). Описание см. выше.
Новые иконки в библиотеке, которые показывают состояние виртуальной машины в представлении списком.
Поддержка настройки видеопамяти для гостевой ОС (VM > Settings > Display). Описание см. выше.
Настройка использования встроенной видеокарты для Mac Book Pro с более, чем одним графическим модулем (GPU).
Обновленная поддержка конфигураций с несколькими мониторами, один из которых Retina.
Возможность настраивать горячие клавиши отдельно для каждой ВМ (VM > Settings > Keyboard & Mouse).
Улучшенная поддержка предрелизных версий Microsoft Windows.
Новый упрощенный способ установки VMware Tools под Windows 8 с использованием виртуального устройства USB CD virtual device.
Скачать VMware Workstation 11 можно по этой ссылке (документация - тут), а VMware Fusion 7 - по этой (документация - тут).
Интересная новость пришла с конференции EMC World 2014, которая проходила с 5 по 8 мая в Лас-Вегасе. Теперь при построении распределенного ("растянутого") кластера VMware HA/DRS (он называется vSphere Metro Storage Cluster, vMSC) поддерживается задержка RTT (Round Trip Time) в канале до 10 миллисекунд. Для такого варианта использования сертифицировано решение VPLEX Geosynchrony 5.2, начиная с версии VMware vSphere 5.5.
Надо сказать, что технология EMC VPLEX Metro ранее поддерживалась на расстояниях между ЦОД в диапазоне до 100-150 км (иногда несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало. Теперь же это расстояние увеличилось до 300 километров.
Ранее технология vMotion поддерживалась и для latency до 10 мс, а вот механизм отказоустойчивости VMware HA гарантированно работал только для задержек до 5 мс.
При этом сейчас кластер vMSC сертифицирован как для нативного плагина доступа к хранилищам NMP (Native Multi-pathing), так и для плагина PowerPath/VE. Здесь надо обязательно отметить, что данная конфигурация поддерживается только издания VMware vSphere Enterprise Plus.
Более подробная информация о кластерах vMSC приведена в KB 2007545.
Таги: VMware, vMSC, Update, EMC, Storage, HA, DR, Replication
Интересную особенность тут обнаружил один из читателей Дукана Эппинга: оказывается в VMware vSphere 5.5 Update 1 при перезапуске/выключении хоста VMware ESXi через консоль DCUI рестарта его виртуальных машин посредством механизма VMware HA не происходит.
Ну то есть, если выключение ESXi делать по клавише <F12> в консоли сервера:
Действительно, в этом случае в логе FDM можно увидеть вот такую запись:
2014-04-04T11:41:54.882Z [688C2B70 info 'Invt' opID=SWI-24c018b] [VmStateChange::SavePowerChange] vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx curPwrState=unknown curPowerOnCount=0 newPwrState=powered off clnPwrOff=true hostReporting=host-113
Это означает, что VMware vSphere считает, что виртуальные машины были выключены корректно (администратором/хостом), а значит их перезапуск механизмом VMware HA не требуется (параметр clnPwrOff=true).
Совсем другая картина, если мы делаем ребут или выключение VMware ESXi из VMware vSphere Client или vSphere Web Client:
В этом случае в логе FDM мы обнаружим что-то вроде такого:
2014-04-04T12:12:06.515Z [68040B70 info 'Invt' opID=SWI-1aad525b] [VmStateChange::SavePowerChange] vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx curPwrState=unknown curPowerOnCount=0 newPwrState=powered on clnPwrOff=false hostReporting=host-113
Здесь уже мы видим, что clnPwrOff=false, а значит vSphere полагает, что что-то пошло не так и VMware HA перезапустит виртуальные машины "отказавшего" хоста.
Это поведение актуально для VMware vSphere 5.5 Update 1, но пользователи в комментариях к статье Дункана отмечают, что подобное поведение наблюдается и для vSphere 5.0. Поэтому будет не лишним знать об этом всем тем, кто после настройки отказоустойчивого кластера VMware HA тестирует его работоспособность путем перезагрузки хостов ESXi.
Таги: VMware, vSphere, HA, VMachines, ESXi, DCUI, Troubleshooting
Раньше пользователи думали о том, как нужно развертывать VMware vCenter - в виртуальной машине или на физическом сервере. Теперь время этих размышлений прошло - большинство ставит его в виртуальной машине. Однако с появлением готового модуля vCenter Server Appliance (vCSA) встал немного другой вопрос - использовать ли готовый vCSA или устанавливать vCenter в Windows. Попробуем разобраться.
Как многие знают, в VMware vSphere 5.5 появились возможности Virtual SAN, которые позволяют создать кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бета этого решения, кроме того мы не так давно писали о производительности VSAN тут и тут.
Сегодня же мы поговорим о том, как нужно сайзить хранилища Virtual SAN в VMware vSphere, а также немного затронем тему отказоустойчивости. Более детальную информацию можно найти в VMware Virtual SAN Design & Sizing Guide, а ниже мы расскажем о подходе к планированию хранилищ VSAN вкратце.
Объекты и компоненты Virtual SAN
Начнем с простого ограничения по объектам (objects) и компонентам (components), которое есть в VSAN. Виртуальные машины, развернутые на vsanDatastore, могут иметь 4 типа объектов:
Домашняя директория виртуальной машины Virtual Machine ("namespace directory").
Объект файла подкачки - swap object (для включенной ВМ).
Виртуальный диск VMDK.
Дельта-диски для снапшотов. Каждый дельта-диск - это отдельный объект.
Каждый объект, в зависимости от типа RAID, рождает некоторое количество компонентов. Например, один VMDK, размещенный на двух томах страйпа (RAID 0) рождает два объекта. Более подробно об этом написано вот тут.
Так вот, ограничения тут следующие:
Максимальное число компонентов на 1 хост ESXi: 3000.
Максимальное число компонентов для одного объекта: 64 (это включает в себя тома страйпов и также реплики VMDK с других хостов).
На практике эти ограничения вряд ли актуальны, однако о них следует знать.
Сколько дисков потребуется для Virtual SAN
Во второй бета-версии VSAN (и, скорее всего, так будет в релизной версии) поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп. Таким образом, на хосте поддерживается до 5 SSD-дисков и до 35 HDD-дисков. Надо убедиться, что контроллеры хоста поддерживают необходимое количество дисков, а кроме того нужно проверить список совместимости VSAN HCL, который постоянно пополняется.
Также надо учитывать, что кластер хранилищ Virtual SAN поддерживает расширение как путем добавления новых дисков, так и посредством добавления новых хостов в кластер. На данный момент VMware поддерживает кластер хранилищ максимум из 8 узлов, что суммарно дает емкость в дисках в количестве 40 SSD (1*5*8) и 280 HDD (7*5*8).
Сколько дисковой емкости нужно для Virtual SAN (HDD-диски)
Необходимая емкость под размещение VMDK зависит от используемого параметра FailuresToTolerate (по умолчанию 1), который означает, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1, то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:
Тут можно сказать о том, как работает отказоустойчивость кластера Virtual SAN. Если отказывает хост, на котором нет виртуальной машины, а есть только VMDK или реплика, то виртуальная машина продолжает работу с основной или резервной копией хранилища. В этом случае начнется процесс реконструкции реплики, но не сразу - а через 60 минут, чтобы дать время на перезагрузки хоста (то есть если произошел не отказ, а плановая или внеплановая перезагрузка), а также на короткие окна обслуживания.
А вот если ломается хост, где исполняется ВМ - начинается процедура восстановления машины средствами VMware HA, который перезапускает ее на другом хосте, взаимодействуя при этом с Virtual SAN.
Более подробно этот процесс рассмотрен вот в этой статье и вот в этом видео:
Однако вернемся к требующейся нам емкости хранилищ. Итак, если мы поняли, что значит политика FailuresToTolerate (FTT), то требуемый объем хранилища для кластера Virtual SAN равняется:
Capacity = VMDK Size * (FTT + 1)
Что, в принципе, и так было очевидно.
Сколько дисковой емкости нужно для Virtual SAN (SSD-диски)
Теперь перейдем к SSD-дискам в кластере VSAN, которые, как известно, используются для вспомогательных целей и не хранят в себе данных виртуальных машин. А именно, вот для чего они нужны (более подробно об этом тут):
Read Cache - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
Write Buffering - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.
Так каковы же рекомендации VMware? Очень просты - под SSD кэш и буфер неплохо бы выделять 10% от емкости HDD-дисков хоста. Ну и не забываем про значение FailuresToTolerate (FTT), которое в соответствующее число раз увеличивает требования к емкости SSD.
Таким образом, необходимая емкость SSD-хранилищ равна:
Capacity = (VMDK Size * 0.1) * (FTT + 1)
Ну и напоследок рекомендуем отличнейший список статей на тему VMware Virtual SAN:
Сегодня мы хотим обратить внимание на два интересных документа, которые раскрывают подробности использования этой технологии.
Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение. Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.
В этом документе описано, как работает инфраструктура vFlash в рамках виртуальной инфраструктуры vSphere, для каких целей можно использовать данную технологию, требования, а также шаги по установке и настройке этого механизма.
Второй документ - это официальный FAQ VMware по технологии Flash Read Cache - "VMware vSphere Flash Read Cache 1.0 FAQ". Так как она появилась впервые, и не все технические особенности ясны администраторам, в документе даны ответы аж на 67 вопросов.
Интересные факты из этого FAQ:
В качестве интерфейсов накопителей поддерживаются SATA, SAS и PCI Express.
До 8 устройств vFlash на один хост ESXi и до 4 ТБ емкости на устройство (до 400 ГБ на один VMDK). На один контейнер VFFS (то есть на хост) поддерживается до 32 ТБ.
В качестве хранилищ ВМ механизмом поддерживаются тома VMFS/NFS/vRDM (pRDM не поддерживается).
Настраивается только через Web Client.
При изменении настроек vFlash все кэши для дисков сбрасываются.
Thin provisioning не поддерживается технологией vFlash.
При миграции виртуальной машины средствами vMotion можно использовать 2 политики: Always migrate the cache contents (copy) - кэш копируется вместе с ВМ и Do not migrate the cache contents (drop) - кэш очищается. Техники VMware HA / SVMotion также полностью поддерживается.
Механизм VMware DRS при миграции не затрагивает машины с включенным Virtual Flash Read Cache.
Операции, которые очищают кэш ВМ: suspend, изменение конфигурации, удаление,
перезапуск машины или хоста, восстановление из снапшота. Операции, которые не очищают кэш: снятие снапшота, клонирование, миграция vMotion, fast suspend/resume.
В vCenter есть 3 специальных метрики для мониторинга vFlash (IOPS, Latency и объем кэша).
Кэшем vFlash можно управлять через ESX CLI: get –m <module> -c <cache file name>
Файлы кэша vFlash находятся в следующей директории на хосте: /vmfs/volumes/vffs/vflash
Мы уже не раз писали (тут и тут) про расширенные настройки (Advanced Settings) кластеров VMware HA в VMware vSphere (до версии 5.0 включительно). Эти настройки позволяют гибко настраивать различные параметры кластеров, их поведение, определять сетевые настройки и т.п. В этой статье мы приведем все эти настройки в единую таблицу и актуализуем для версии VMware vSphere 5.5.
Таги: VMware, vSphere, HA, vCenter, FDM, ESXi, VMachines
Очень часто при чтении документации VMware приходиться сталкиваться с различного рода сокращениями, большинство из которых, конечно же, понятно опытным администраторам VMware vSphere, но не всегда понятно для новичков.
Andrea Mauro составил неплохой список акронимов VMware, который мы и публикуем здесь (ссылки добавил я - на релевантные статьи):
AAM
Automated Availability Manager (aka VMware HA since v 4.1)
Некоторое время назад мы писали о втором технологическом превью (о первом - вот тут) лидирующей настольной платформы виртуализации VMware Workstation 2013. На прошлой неделе, по окончании VMworld 2013, компания VMware наконец-то объявила о выпуске юбилейной версии этой платформы - VMware Workstation 10.
Основные нововведения этого релиза - улучшения работы Unity с новым интерфейсом и поддержка Microsoft Windows 8.1. Как и VMware vSphere 5.5, Workstation 10 поддерживает hardware version 10, что позволяет существенно увеличить максимумы параметров для виртуальных процессоров, памяти и виртуальных дисков.
VMware Workstation 10 получит следующие функции (некоторые из этих функций мы уже рассматривали в предыдущих статьях, новые же возможности отмечены звездочкой):
New OS Support - появилась экспериментальная поддержка Windows 8.1, а также гостевых и хостовых ОС Ubuntu 13.04, Fedora 18 и прочих.
VMware Hardware Version 10 - обновилось поколение виртуального аппаратного обеспечения виртуальных машин. Это дает новую функциональность создаваемых ВМ, в первую очередь, поддержку 16-ти виртуальных процессоров (vCPU) для одной машины. Для этого на вашем ПК должно быть не менее 16-ти логических процессоров (или 8 ядер с включенным HT), чем может похвастаться далеко не каждый компьютер. Также существенно была увеличена производительность, работа с подсистемой питания и улучшена поддержка новых возможностей десктопных процессоров. Кроме того, появилась поддержка виртуальных дисков объемом 8 ТБ. Появились виртуальные SATA-диски, была улучшена поддержка USB 3.0.
* Convert Windows 8.1 PC to a VM - возможность сразу же конвертировать физический ПК или ноутбук в виртуальную машину.
* 20 virtual networks - теперь поддерживается существенно больше (в 2 раза!) виртуальных сетей (VMnet) для машин на хосте.
SSD Passthrough - ОС Windows 8 способна определить, что она работает с диска solid state drive (SSD), что позволяет ей оптимизировать работу с подсистемой ввода-вывода. В этом Technology Preview, Workstation может обнаружить, что диск ВМ размещен на SSD-носителе, и передать гостевой ОС эту информацию, чтобы та смогла включить оптимизацию.
Expiring Virtual Machines - VMware улучшила возможности Restricted Virtual Machines, которые появились в прошлых версиях. Теперь виртуальная машина может устареть в заданную дату по времени UTC. Такие машины соединяются с ресурсом VMware.com для валидации времени и предотвращения попыток пользователя снять лок с машины.
Virtual Tablet Sensors - теперь в виртуальной машине можно получить виртуальные устройства планшетов: GPS, акселерометр, инклинометр, компас, гирометр и симуляцию окружающего света (Ambient Light). Все это пригодится при разработке программного обеспечения, например, под планшеты и телефоны на базе Windows 8.
New Converter - в этой версии VMware Converter получил несколько новых улучшений:
- Поддержка гостевых ОС Microsoft Windows 8 и Microsoft Windows Server 2012
- Поддержка гостевой ОС Red Hat Enterprise Linux 6
- Поддержка виртуальных и физических машин с дисками GUID Partition Table (GPT)
- Поддержка виртуальных и физических машин с интерфейсом Unified Extensible Firmware Interface (UEFI)
- Поддержка файловой системы EXT4
- Поддержка ВМ vSphere 5.1 (hardware version 9)
Pre-Released OVFTool - утилита командной строки VMware OVF Tool позволяет импортировать и экспортировать OVF-пакеты. Теперь она имеет улучшенные механизмы импорта шаблонов Oracle.
VMware-KVM - очень полезный режим для тех, кто хочет скрыть от пользователя, что он работает в виртуальной машине (например, в школьных классах). В этом случае машину можно запустить командой "vmware-kvm.exe vmx-file.vmx" и она будет развернута на весь экран, комбинация клавиш Ctrl-Alt позволит выйти из машины, а кнопкой Pause/Break можно будет переключаться между консолями нескольких ВМ в полноэкранном режиме.
Windows 8 Unity Mode Support - поддержка режима бесшовной интеграции Unity теперь еще лучше интегрирована с интерфейсом Windows Metro.
Multiple Monitor Navigation - улучшенные механизмы работы с 2, 3, 4, 5 и даже 6-ю мониторами в полноэкранном режиме при переключении между экранами.
* Run a Cloud on Your PC– Workstation 10 позволяет развернуть в виртуальных машинах облачные приложения от Pivotal, Puppet Labs и Vagrant.
Power Off Suspended Virtual Machines - возможность выключить ВМ, поставленную "на паузу", что отменяет необходимость включать такие машины для внесения изменений в их конфигурацию.
Remote Hardware Upgrade - при удаленной работе с виртуальными машинами на платформе vSphere или другом ПК с VMware Workstation, теперь можно удаленно обновлять Hardware version.
30-day evaluation - теперь для активации пробной версии Workstation на 30 дней достаточно ввести email в окне установки.
* Improved application and Windows VM startup times - традиционно уменьшилось время запуска Windows и приложений.
Улучшенные возможности Restricted Virtual Machines, определяемые на базе политик:
Планшетные устройства в виртуальной машине для разработчиков:
Улучшенный тулбар с функциями работы с несколькими мониторами и интерфейсом подключения к нескольким виртуальным машинам (KVM):
По вопросам лицензирования VMware Workstation 10 можно обратиться к FAQ, приведенному в KB 2032851.
Скачать и купить VMware Workstation 10 можно уже сейчас по этой ссылке.
Также была обновлена платформа VMware Fusion 6, предназначенная для запуска Windows на Mac в одновременном режиме. Напомним, что не так давно был выпущен конкурент этой платформы - Parallels Desktop 9.
Новые возможности VMware Fusion 6:
Powerful VMs - улучшение максимумов виртуальных машин до
16 vCPU / 64 GB of RAM /
8TB disks /
поддержка Haswell.
Улучшенная поддержка 3D-графики для движков OpenGL 2.1 и DirectX 9.0c shader model 3.
Улучшенный
Virtual Network Editor.
Поддержка связанных клонов ВМ (Linked Clones).
Улучшенный мастер создания новой виртуальной машины.
RSS
