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

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

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

VM Guru | Ссылка дня: VMware vSphere 6.7 Update 3 доступен для загрузки

Как быстро и просто провести тест хранилищ с использованием утилиты IOBlazer.


Недавно на сайте проекта VMware Labs обновилась одна из самых полезных утилит для администраторов хранилищ VMware vSphere – IOBlazer. Она позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и Mac OS, при этом администратор может задавать паттерн нагрузки с высокой степенью кастомизации, что очень важно для реального тестирования подсистемы хранения для виртуальных машин.


Таги: VMware, IOBlazer, Storage, Performance, vSphere, VMachines

Что нового появилось в VMware User Environment Manager 9.8?


Недавно мы писали о выходе серьезного обновления платформы виртуализации и доставки ПК и приложений в инфраструктуре предприятия VMware Horizon 7.9. Одновременно с этим вышли и обновления клиентов - VMware Horizon Clients 5.1. Также мы упоминали, что вышли новые версии User Environment Manager 9.8 и App Volumes 2.17. В App Volumes практически не появилось ничего нового, а вот в UEM 9.8 есть много всего интересного. Напомним, что о User Environment Manager 9.6 мы писали вот тут.

Давайте, посмотрим на список новведений и улучшений:

1. Дополнительные умные политики (Smart Policies).

Теперь можно включить или выключить воспроизведение аудио, которое применяется для протоколов Blast и PCoIP. Также через умные политики можно оптимизировать протокол Blast Extreme. Кроме того, можно настраивать механизм Drag and Drop. Для работы всех этих функций вам потребуется Horizon agent версии 7.9 или более поздней.

2. Поддержка условий для регулярных выражений.

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

Пользователи продуктов AppSense и RES уже знакомы с этим механизмом регулярных выражений, теперь они появились и в UEM.

3. Новая опция Chrome Client при задании условия для Endpoint Platform.

Теперь для устройств Chrome появилось 2 новых опции - настройка Chrome ARC++ для Android-приложений, исполняемых на устройстве, а также Chrome Native для нативного клиента.

Для этой опции вам понадобится Horizon Client 5.1 или более поздней версии. Доступна эта возможность для устройств с протоколами Chrome Horizon Blast и PCoIP (Citrix ICA пока не поддерживается).

4. Поддержка Amazon FSx.

В этой версии UEM появилась полная поддержка файловой системы Amazon FSx for Windows File Server, которая представляет собой нативную облачную ФС для машин на базе Windows Server. Это упрощает развертывание инсталляций User Environment Manager для гибридных облаков, построенных на базе технологий VMware и Amazon (см. VMC on AWS).

Скачать VMware User Environment Manager 9.8 можно уже по этой ссылке, Release Notes доступны тут.


Таги: VMware, UEM, Update, Horizon, VMachines, Management

Новое на VMware Labs - мобильный клиент vSphere Mobile Client 1.1 для iOS и Android.


Еще очень давно, 8 лет назад, компания VMware развивала мобильный клиент (см. также тут) для управления инфраструктурой VMware vSphere, но забросила это дело на некоторое время.

И вот совсем недавно на сайте проекта VMware Labs появилось средство vSphere Mobile Client 1.1. Это очередной подход VMware к управлению виртуальной средой через мобильные приложения для iOS и Android.

Само собой, vSphere Mobile Client предоставляет лишь малую часть функций полноценного клиента (но для мобильных устройств это и не нужно), вот основные из них:

  • Просмотр информации и виртуальных машинах - просмотр статуса ВМ (включено/выключено), использования ресурсов и конфигурации машин.
  • Управление ВМ - операции с питанием (в том числе, перезагрузка). Возможность найти виртуальную машину с помощью поиска. Если вы свайпните влево карточку с виртуальной машиной, то получите скриншот ее консоли, который можно сохранить.
  • Мониторинг задач - можно "подписаться" на любую запущенную задачу и получать нотификации на телефон о том, когда она завершится. При этом неважно, что ваш девайс находится в неактивном режиме или в данный момент вы работаете с другим приложением.
  • Графики производительности - можно отслеживать использование ресурсов виртуальными машинами в реальном времени, либо в разрезе дня, недели, месяца или года назад. Счетчики включают в себя метрики CPU, памяти, хранилищ и сети. Также на дэшборде можно посмотреть общее использование ресурсов vCenter.

Ссылки на загрузку vSphere Mobile Client:

Чтобы получать пуш-уведомления на ваши устройства, нужно будет поднять vSphere Mobile Client Notification Service в виде контейнера Docker. О том, как это сделать написано тут, а скачать сам контейнер можно на странице vSphere Mobile Client.


Таги: VMware, Labs, Mobile, vSphere, VMachines, Monitoring

Storage I/O Control (SIOC) версии 2 в VMware vSphere - что там интересного?


Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.

Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.

SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):

На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:

Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.

Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.

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

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

SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:

На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:

Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:

Так для Normal:

А так для High:

Если выберите вариант Custom, то дефолтно там будут такие значения:

Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.

Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:

После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:


Таги: VMware, vSphere, SIOC, Update, SPBM, Storage, Performance, VMachines

Изменение дефолтной конфигурации виртуального модуля VMware vCenter Server Appliance 6.5/6.7.


Многим администраторам знакома такая вещь: сначала для теста устанавливается виртуальная машина VMware vCenter Server Appliance в конфигурации tiny (минимальные аппаратные настройки), а потом она приживается, и хочется сделать из нее полноценную производственную среду управления (конфигурацию large). Только вот не хочется ее переустанавливать.

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

Установщик vCSA использует фреймворк Electron, настраивая конфигурацию через JSON, и механизм JSON-Schema для установки и валидации параметров. Поэтому в ISO-образе вы сможете найти конфигурацию сервера vCenter по следующему пути:

\vcsa-ui-installer\win32\resources\app\resources\layout.json

Там как раз и находятся данные о типовых конфигурациях vCSA. Например, так выглядит размер xlarge:

"xlarge": {
        "cpu": 24,
        "memory": 49152,
        "host-count": 2000,
        "vm-count": 35000,
        "disk-swap": "50GB",
        "disk-core": "100GB",
        "disk-log": "25GB",
        "disk-db": "50GB",
        "disk-dblog": "25GB",
        "disk-seat": "500GB",
        "disk-netdump": "10GB",
        "disk-autodeploy": "25GB",
        "disk-imagebuilder": "25GB",
        "disk-updatemgr": "100GB",
        "disk-archive": "200GB",
        "required-disk-space": "1180GB",
        "label": "X-Large vCenter Server with Embedded PSC",
        "description": "This will deploy a X-Large VM configured with 24 vCPUs and 48 GB of memory and requires 1180 GB of disk space will be updated for xlarge later. This option contains vCenter Server with an embedded Platform Services Controller for managing up to 2000 hosts and 35,000 VMs."
    }

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

Теперь переходим, собственно, к изменению самой конфигурации:

1. Увеличение CPU и памяти (RAM).

  • Остановите машину.
  • Хорошая идея - вывести ее ESXi-хост из кластера DRS.
  • Зайдите на ESXi через Host Client, после чего в настройках ВМ измените конфигурацию CPU и памяти, чтобы выставить ее в соответствии с нужной конфигурацией.

2. Увеличение диска ВМ с сервером vCSA.

  • Об увеличении дискового пространства сервера vCSA 6.5 мы писали вот в этой статье. С тех пор ничего особо не изменилось. Некоторую дополнительную информацию вы также можете получить в KB 2145603 на случай если что изменится в процедуре vCSA 6.x.
  • Диски нужно настраивать не только по размеру, но и по корректной позиции в виртуальном слоте SCSI.

Примерно так это выглядит для vCenter 6.7 Update 2:

Назначение Позиция в фале JSON Номер VMDK Слот SCSI
root / boot n/a 1 0:0
tmp n/a 2 0:1
swap 1 3 0:2
core 2 4 0:3
log 3 5 0:4
db 4 6 0:5
dblog 5 7 0:6
seat 6 8 0:8
netdump 7 9 0:9
autodeploy 8 10 0:10
imagebuilder 9 11 0:11
updatemgr 10 12 0:12
archive 11 13 0:13

Помните, что иногда имя VMDK может не соответствовать его позиции в слоте SCSI. Например, встречаются случаи, когда VMDK0 смонтирован в слот SCSI(0:4), а VMDK2 - в слот SCSI(0:0). В этом случае реальным загрузочным диском будет VMDK2, а не VMDK0, несмотря на их названия.

Также обратите внимание, что SCSI слот 0:7 не используется - не ошибитесь.

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


Таги: VMware, vCenter, vCSA, Upgrade, Virtual Appliance, Blogs, VMachines

Почему vGPU не уступают по производительности «железным» решениям


Это гостевой пост компании ИТ-ГРАД, предоставляющей виртуальные машины из облака в аренду. VMware обновили свой гипервизор ESXi. Теперь скорость работы виртуальных графических процессоров под его управлением сопоставима с возможностями их bare metal реализаций — разница составляет всего 3%. Рассказываем, как компании удалось этого добиться...


Таги: IT-Grad, Cloud, vGPU, Hardware, VMachines

Влияет ли vSAN IO Limit на производительность операций ресинхронизации кластера и Storage vMotion (SVMotion)?


Дункан написал полезный пост о том, влияет ли установка лимитов по вводу-выводу в кластере VMware vSAN (I/O Limit) на производительность операций ресинхронизации кластера и перемещение машин между хранилищами Storage vMotion (SVMotion).

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

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

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


Таги: VMware, vSAN, Storage, Performance, VMKDK, VMachines, Limits

Проверки кластера VMware vSphere Update Manager перед обновлениями хостов (Remediation).


У средства обновления хостов VMware vSphere Update Manager (VUM) есть полезный механизм проверок Pre-Check Remediation Report, который выполняет предварительную проверку условий для обновления хостов ESXi, чтобы этот процесс не прервался уже после его начала. Эти условия очень просты, но иногда позволяют сэкономить массу времени, особенно в большой инфраструктуре VMware vSphere.

Чтобы запустить эти проверки, надо выбрать нужный вам кластер и нажать кнопку Pre-Check Remediation:

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

Отчет Pre-Check Remediation Report для кластера может содержать следующие пункты:

Номер Текущий статус Рекомендуемое действие Описание
1 Отключен ли DPM? Отключите DPM в кластере

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

2 Включен ли DRS? Включите DRS в кластере

Именно DRS позволяет серверу vCenter смигрировать ВМ на другие хосты ESXi, чтобы обновить целевой хост-сервер.

3 Отключен ли HA admission control? Отключите HA admission control

HA admission control предотвращает миграцию ВМ средствами vMotion, в результате которой не выполняются правила доступности слотов. Перед обновлением этот механизм лучше отключить.

4 Включен ли EVC в кластере? Включите EVC в кластере

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

5 Успешны ли проверки vSAN health check? Проверьте страницу vSAN Health Check на наличие проблем

Проверки vSAN Health Check представляют собой набор тестов для хостов ESXi, составляющих кластер vSAN (например, тесты доступности хранилищ во время обновления). Они должны завершиться успешно перед началом процедуры обновления хостов.

Отчет Pre-Check Remediation Report для виртуальных машин может содержать следующее:

Номер Текущий статус Рекомендуемое действие Описание
1 К ВМ привязан привод CD/DVD Отключите привод CD/DVD

 

Это редкая, но случающаяся проблема, когда такие приводы используются, например, для монтирования ISO-образов.
2 К ВМ привязан floppy-драйв Отключите привод floppy

 

Очень редко, но бывает.
3 Для ВМ включена технология FT Отключите Fault Tolerance для ВМ

 

Технология Fault Tolerance не позволяет VUM обновлять ВМ.
4 На ВМ установлен VMware vCenter Server, при этом DRS в кластере отключена Включите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion

vCenter управляет компонентом VUM, поэтому нужно, чтобы он мог переехать на другой хост в процессе обновления ESXi.

 

5 На ВМ установлен VMware vSphere Update Manager, при этом DRS в кластере отключенаВключите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion vCenter управляет процессом обновления, поэтому нужно, чтобы он мог переехать на другой хост в процессе обновления ESXi.


Таги: VMware, vSphere, Update Manager, VUM, Update, Обучение, ESXi, VMachines

Обновление безопасности VMSA-2019-0009 для VMware Tools. Как вам можно обновиться.


Компания VMware опубликовала уведомление VMSA-2019-0009 для пакета VMware Tools, который содержит уязвимость, позволяющую непривилегированному пользователю читать данные из гостевой ВМ, а также негативно влиять на ее гостевую ОС. Уязвимости подвержены версии VMware Tools ниже 10.3.10.

В качестве примера использования такой уязвимости можно привести Windows-машины, где включены службы Microsoft Remote Desktop Services. Также риску подвержены службы Microsoft SQL Server или IIS, использующие сервисные аккаунты.

Сначала надо вывести все ВМ, имеющие VMware Tools версии ниже 10.3.10 с помощью следующей команды PowerCLI:

Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’} | Sort-Object Name | Format-Table

Вот такая команда выдаст все Windows-машины с VMware Tools ниже, чем 10.3.10:

Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’ -and $_.Guest.GuestFamily -eq ‘windowsGuest’} | Sort-Object Name | Format-Table

Проверить версию VMware Tools можно и самостоятельно в VMware vSphere Client:

Помните, что VMware 6.7 Update 2a идет с версией VMware Tools 10.3.5. Надо отметить, что гостевые ОС Linux не подвержены уязвимости, поэтому не пугайтесь, что open-vm-tools имеют только версию 10.3.5.

Последнюю же версию пакета тулзов можно скачать по этой ссылке: https://www.vmware.com/go/tools.

Если вы хотите обновить VMware Tools через офлайн-бандл, то скачайте "VMware Tools Offline VIB Bundle", после чего можно использовать vSphere Update Manager (VUM) для развертывания установщиков пакета на хостах ESXi без простоя. После этого машины должны в течение 5 минут схватить новую версию тулзов (таков период обновления информации об актуальной версии пакета). Установленная версия VMware Tools также проверяется и при vMotion, а, кроме того, и при операциях с питанием ВМ (включение/выключение).

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

Обновление VMware Tools можно инициировать через PowerCLI с помощью следующего командлета:

Get-VM | Where-Object {$_.ExtensionData.Guest.ToolsVersionStatus -eq "guestToolsNeedUpgrade" -and $_.PowerState -eq "PoweredOn"} | Get-VMGuest | Where-Object {$_.GuestFamily -eq "windowsGuest" } | Update-Tools -NoReboot -RunAsync

Помните, что при апгрейде VMware Tools вам может потребоваться перезагрузка виртуальных машин и их гостевых ОС. Также вы можете использовать приведенный выше сценарий для нескольких ВМ в одной папке:

Get-VM “TEST-VM-02” | Where-Object…
Get-Folder “Test VMs - Snapshotted" | Get-VM | Where-Object…

Через vSphere Client тулзы также прекрасно обновляются:

Если вы используете опцию "Automatic Upgrade", то машина будет обновлена автоматически (без взаимодействия с гостевой ОС) и, при необходимости, перезагрузится. Также вы можете использовать обновление тулзов без немедленной перезагрузки, применив инструкции, описанные в KB1018377. Надо помнить, что в этом случае до перезагрузки будет работать старая версия VMware Tools, а значит, что до перезагрузки машины уязвимость будет актуальна.

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

 

 

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

В этом случае они получат нотификацию о новой версии VMware Tools из трея, либо могут проверить наличие обновлений самостоятельно с помощью команд:

  • VMwareToolboxCmd.exe –v - проверка установленной версии.
  • VMwareToolboxCmd.exe upgrade status - возможность обновления для доступных апгрейдов.
  • VMwareToolboxCmd.exe upgrade start - запуск процедуры апгрейда.

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


Таги: VMware, Tools, Update, vSphere, ESXi, VMachines

Кластер VMware vSAN и Site Locality - убедитесь, что все диски нерастянутых машин находятся на одной площадке.


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

При создании растянутого кластера вам предоставляют опции по выбору уровня защиты данных RAID-1 или RAID-5/6 средствами политики FTT (Failures to tolerate), а также позволяют определить, как машина будет защищена с точки зрения репликации ее хранилищ между датацентрами.

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

В старом интерфейсе vSphere Web Client это настраивается вот тут:

Смысл настройки этих политик для виртуальной машины в том, чтобы вы могли однозначно определить размещение ее дисковых объектов, так как если у нее несколько виртуальных дисков VMDK, то если вы не зададите их локацию явно - может возникнуть такая ситуация, когда диски одной машины размещаются в разных датацентрах! Потому что при развертывании ВМ решение о размещении принимается на уровне дисковых объектов (то есть на уровне виртуальных дисков), которые по каким-то причинам могут разъехаться в разные сайты, если вы выберите первый пункт на первом скриншоте.

Это, конечно же, со всех сторон плохо, особенно с точки зрения производительности.

Если такая машина работает не в растянутом кластере vSAN, то в случае, если произойдет разрыв между площадками - часть дисков в гостевой системе станет недоступна, что неприемлемо для приложений и ОС.

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


Таги: VMware, vSAN, DR, VMachines, Storage, VMDK

Как предоставить доступ виртуальной машине в облаке VMware vCloud on AWS из сети Compute Network в сеть SDDC Management Network?


Для многих пользователей публичного облака VMware vCloud on AWS одним из первых возникает вопрос - как предоставить доступ из виртуальной машины в сети Compute Network в сеть SDDC Management Network, например, для целей управления сервисами vCenter или другими службами виртуального датацентра?

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

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

Процедура для NSX-V

В среде NSX-V вам нужно настроить IPsec VPN между компонентами Management Gateway (MGW) и Compute Gateway (CGW) перед тем, как заработает коммуникация между сетями.

Для настройки VPN для компонента Management Gateway нажимаем Add VPN в консоли VMC и вводим требующуюся информацию сетевой идентификации (публичный IP удаленного шлюза, параметры удаленной сети и ключи), что должно отражать конфигурацию Compute Gateway (остальные настройки можно оставить по умолчанию).

Далее надо настроить VPN для Compute Gateway путем выполнения тех же шагов, что и в предыдущем абзаце, только указав конфигурацию шлюза Management Gateway. После того, как настройки обеих VPN будут сохранены, начнет отображаться статус "Partially Connected". Потом нажимаем ссылку Actions в правом верхнем углу, выбираем Edit и сохраняем настройки еще раз, чтобы на обоих шлюзах показался статус "Connected":

Теперь надо настроить сетевой экран Compute Gateway Firewall, чтобы разрешить исходящие соединения в SDDC Management Network по порту 443 для требуемых ВМ (этот порт используется для vSphere Client, а также для доступа через средства OVFTool и PowerCLI).

В приведенном ниже примере машина имеет адрес 192.168.1.4, и мы хотим позволить ей общаться с сетью 10.2.0.0/16 через порт 443:

Теперь нужно добавить в фаервол Management Gateway Firewall правила для разрешения входящих соединений для vCenter Server и хостов ESXi по порту 443 от наших определенных ВМ. Здесь все точно так же - указываем IP машины 192.168.1.4, и нам нужно добавить 2 правила для входящего трафика для разрешения коммуникации со средствами управления виртуальной инфраструктурой:

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

Процедура для NSX-T

В среде NSX-T вам не нужно создавать VPN для получения функциональности маршрутизации, которая изначально заложена в маршрутизаторе T0, ведь обе сети Management и Compute Network присоединены к T0. Между тем, правила сетевого экрана добавлять, конечно же, нужно.

В решении NSX-T используются сущности Inventory Groups, чтобы сгруппировать набор виртуальных машин и/или IP-адреса/сети, которые можно использовать при создании правил сетевого экрана.

Создаем две Inventory Groups для нашей Compute Group - одну для нашей виртуальной машины и одну для того, чтобы представлять сеть Management Network. Идем в Groups и в левой части выбираем пункт "Workload Groups", где создаем 2 группы:

  • Windows10 с Member Type вида Virtual Machine и указываем ВМ из инвентаря.
  • VMC Management Network с Member Type вида IP Address и указываем сетевой диапазон 10.2.0.0/16.

Теперь нужно создать еще одну Inventory Group для нашей Management Group, которая будет отражать ВМ, для которой мы хотим сделать доступ. Чтобы это сделать, идем в Groups, выбираем "Management Groups" и создаем следующую группу:

  • Windows10 Private IP с Member Type вида IP Address и указываем частный IP-адрес ВМ (в данном случае это 192.168.1.2).

Не забывайте нажать кнопку Publish, чтобы сохранить и применить правило сетевого экрана.

Теперь нужно создать правило сетевого экрана, чтобы разрешить Compute Gateway исходящие соединения к SDDC Management Network по порту 443 для нужных ВМ. Идем в Gateway Firewall и выбираем "Compute Gateway", где создаем новое правило, которое отражает группу Windows 10 как источник и группу VMC Management Network как назначение, а в качестве сервиса выбираем HTTPS (помним также про кнопку Publish).

Теперь надо создать правила на уровне Management Gateway, чтобы разрешить входящие соединения к хостам vCenter Server и ESXi по порту 443 из нужных нам ВМ. Идем в Gateway Firewall, слева выбираем "Management Gateway", затем создаем правило, которое отражает группу Windows 10 как источник, а в качестве группы назначения указываем vCenter и ESXi (сервис ставим также HTTPS):

После выполнения этой процедуры вы сможете залогиниться в ВМ Windows и использовать утилиту OVFTool для импорта/экспорта ВМ в ваш виртуальный датацентр (см. также данную процедуру здесь).

Если все было сделано правильно, вы должны иметь возможность доступа к интерфейсу vSphere Client из нужной вам ВМ, а также возможность выполнять сценарии PowerCLI и использовать утилиту OVFTool, как показано на скриншоте ниже:


Таги: VMware, vCloud, VMConAWS, Cloud, Amazon, vNetwork, Networking, vSphere, ESXi, VMachines, Blogs

Ограничения Persistent Memory для виртуальных машин на платформе VMware vSphere.


В августе прошлого года мы сделали статью о новом виде памяти Persistent memory (PMEM) в VMware vSphere, которая находится на уровне между DRAM и Flash SSD с точки зрения производительности:

Надо сказать, что устройства с Persistent Memory (они же, например, девайсы с Intel Optane Memory) уже начинают рассматривать некоторые пользователи для внедрения в своей виртуальной инфраструктуре, поэтому надо помнить об их ограничениях, которые раскрыл Дункан Эппинг.

С точки зрения предоставления памяти PMEM виртуальной машине, на платформе vSphere есть 3 способа:

  • vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
  • vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
  • vPMEM-aware - это то же самое, что и vPMEM, но только с дополнительными возможностями приложения понимать, что машина использует такое устройство, и пользоваться его преимуществами.

Если виртуальная машина использует такие устройства, то она имеет очень существенные ограничения, которые на данный момент препятствуют их использованию в производственной среде. Они приведены в документе "vSphere Resource Management Guide" на странице 47 внизу. А именно:

  • vSphere HA - полностью не поддерживается для машин с включенными vPMEM устройствами, вне зависимости от режима использования.
  • vSphere DRS - полностью не поддерживается для машин с включенными vPMEM устройствами (машины не включаются в рекомендации и не мигрируют через vMotion), вне зависимости от режима использования.
  • Миграция vMotion для машин с устройствами vPMEM / vPMEM-aware доступна только на хосты с устройствами PMEM.
  • Миграция vMotion машин с устройством vPMEMDISK возможна на хост без устройства PMEM.

Будем надеяться, что эта ситуация в будущем изменится.


Таги: VMware, vSphere, Memory, PMEM, Intel, VMachines, HA, DRS

Улучшения планировщика side-channel aware scheduler (SCA) в VMware vSphere 6.7 Update 2.


Некоторое время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere Platinum 6.7 Update 2. Cреди новых возможностей гипервизора там есть фича "Новые возможности планировщика CPU помогают бороться с уязвимостями типа L1TF".

Оказывается, это довольно серьезное улучшение. Надо сказать, что планировщик гипервизора side-channel aware scheduler (SCA) появился еще в прошлой версии платформы. Он закрывал уязвимость L1TF (L1 Terminal Fault) в процессорах Intel за счет того, что процессы виртуальных машин запускались только в одном треде одного физического ядра. Это позволяло нивелировать вектор атаки данного типа, но приводило к существенному снижению производительности.

Особенно это чувствовалось, когда сервер ESXi был загружен по CPU полностью, и SCA первой версии в этом случае давал до 30% хуже результат, чем без него. Если же сервер был загружен, например, на 75%, то в производительность оставалась примерно той же, но без SCA нагрузка на CPU была существенно ниже.

Обо всем этом подробно описано в документе "Performance of vSphere 6.7 Scheduling Options":

Давайте вкратце посмотрим, о чем там говорится.

Итак, начиная с VMware vSphere 6.7 Update 2, появился обновленный планировщик SCAv2, который был существенно доработан по сравнению со своей предыдущей версией. Он позволяет исполнять контексты vCPU одной машины в разных гипертредах одного физического ядра процессора хоста. В этом случае атаке L1TF не подвержены взаимодействия типа VM/VM и VM/ESXi (чувствительная информация между ними не шарится в общем кэше).

В документе описано 2 типа тестов, которые проводились для планировщиков SCAv1 и SCAv2: работа хоста под максимальной нагрузкой по процессорам и под нагрузкой на уровне 75% от максимальной мощности всех CPU хоста ESXi (reduced load). В качестве базового уровня использовался планировщик без SCA (он же на картинке ниже обозначен как Default):

Если верить графикам, отражающим результаты тестирования различными бенчмарками, то планировщик SCAv2 работает существенно лучше во всех случаях, кроме очень большой (по выделенным ресурсам) виртуальной машины - Monster VM с базой Oracle и 192 vCPU, но такой кейс в реальной жизни случается весьма редко. Так что, в целом, улучшения были проведены весьма существенные (как минимум, на 11% планировщик стал более производительным по результатам тестов).

Помимо документа выше, информация об улучшениях планировщика приведена еще в KB 55806.


Таги: VMware, ESXi, Performance, Security, vSphere, vCPU, VMachines

Подробно о дисковых группах VMware vSAN - что это такое и как работает.


Мы много пишем о решении для организации отказоустойчивых хранилищ на базе хостов ESXi - платформе VMware vSAN. Сегодня мы расскажем о дисковых группах на основе вот этого поста на блогах VMware.

Архитектура vSAN включает в себя два яруса - кэш (cache tier) и пространство постоянного хранения (capacity tier). Такая структура дает возможность достичь максимальной производительности по вводу-выводу, которая абсолютно необходима в кластере хранилищ на базе хостов.

Чтобы управлять отношениями устройств кэша и дисков хранения, решение vSAN использует дисковые группы:

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

  • Каждый хост, который дает емкость кластеру vSAN, должен содержать как минимум одну дисковую группу.
  • Дисковая группа содержит как минимум одно устройство для кэша и от 1 до 7 устройств хранения.
  • Каждый хост ESXi в кластере vSAN может иметь до 5 групп, а каждая группа - до 7 устройств хранения. То есть на хосте может быть до 35 устройств хранения, чего вполне достаточно для подавляющего большинства вариантов использования.
  • Неважно, используете ли вы гибридную конфигурацию (SSD и HDD диски) или All-Flash, устройство кэширования должно быть Flash-устройством.
  • В гибридной конфигурации устройства кэша на 70% используются как кэш на чтение (read cache) и на 30% как кэш на запись (write buffer).
  • В конфигурации All-Flash 100% устройства кэша выделено под write buffer.

Write buffer и capacity tier

В принципе, всем понятно, что гибридная конфигурация хостов ESXi в кластере vSAN более дешевая (HDD стоит меньше SSD), но менее производительная, чем All-Flash. Но когда-то наступит время, и все будет All-Flash (в них, кстати, еще и нет нужды организовывать кэш на чтение, так как все читается с SSD с той же скоростью). Поэтому и выделяется 100% под write buffer.

При этом если операция чтения в All-Flash хосте находит блок в кэше - то он читается именно оттуда, чтобы не искать его в capacity tier. Максимальный размер write buffer на одной дисковой группе хоста ESXi - 600 ГБ. При этом если сам диск более 600 ГБ, то его емкость будет использоваться с пользой (см. комментарий к этой статье).

Для гибридных конфигураций 70% емкости кэша выделяется под кэш на чтение, чтобы быстро получать данные с производительных SSD-устройств, при этом vSAN старается поддерживать коэффициент попадания в кэш на чтение (cache hit rate) на уровне 90%.

Write buffer (он же write-back buffer) подтверждает запись на устройство хранения еще до актуальной записи блоков на сapacity tier. Такой подход дает время и возможность организовать операции записи наиболее эффективно и записать их на сapacity tier уже пачкой и более эффективно. Это дает существенный выигрыш в производительности.

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

Вот сравнительная таблица этих классов (колонка TBW - это terabytes written, то есть перезапись скольких ТБ они переживут):

Помните, что нужно всегда сверяться с VMware Compatibility Guide, когда выбираете устройства PCIe flash, SSD или NVMe.

vSAN содержит в себе несколько алгоритмов, которые учитывают, как часто write buffer сбрасывает данные на сapacity tier. Они учитывают такие параметры, как емкость устройств, их близость к кэшу по времени записи, число входящих операций ввода-вывода, очереди, использование дискового устройства и прочее.

Организация дисковых групп

При планировании хостов ESXi в кластере vSAN можно делать на нем одну или более дисковых групп. Несколько дисковых групп использовать предпочтительнее. Давайте рассмотрим пример:

  • Одна дисковая группа с одним кэшем и 6 устройств хранения в ней.
  • Две дисковых группы с двумя устройствами кэша, в каждой по 3 устройства хранения.

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

Надо понимать, что этот кейс не имеет прямого отношения к доступности данных виртуальных машин, которая определяется политикой FTT (Failures to tolerate) - о ней мы подробно рассказывали тут, а также политиками хранилищ SPBM. Между тем, размер домена отказа (failure domain) во втором случае меньше, а значит и создает меньше рисков для функционирования кластера. Также восстановление и ребилд данных на три диска займет в два раза меньше времени, чем на шесть.

Кстати, некоторые думают, что в случае отказа дисковой группы, кластер vSAN будет ждать 60 минут (настройка Object Repair Timer) до начала восстановления данных на другие диски согласно политике FTT (ребилд), но это неверно. Если вы посмотрите наш пост тут, то поймете, что 60 минут vSAN ждет в случае APD (All Paths Down - например, временное выпадение из сети), а вот в случае PDL (Physical Device Loss) восстановление данных на другие дисковые группы начнется немедленно.

С точки зрения производительности, иметь 2 дисковые группы также выгоднее, чем одну, особенно если разнести их по разным контроллерам хранилищ (storage controllers). Ну и это более гибко в обслуживании и размещении данных на физических устройствах (например, замена диска во втором примере пройдет быстрее).

Работа операций ввода-вывода (I/O)

Как уже было сказано, в гибридной конфигурации есть кэши на чтение и на запись, а в All-Flash - только на запись:

При этом хост ESXi работает так, чтобы операции чтения с дисков попадали в кэш на чтение в 90% случаев. Остальные 10% операций чтения затрагивают HDD-диски и вытаскивают блоки с них. Но и тут применяются оптимизации - например, одновременно с вытаскиванием запрошенного блока, vSAN подтягивает в кэш еще 1 МБ данных вокруг него, чтобы последовательное чтение проходило быстрее.

Для All-Flash конфигурации кэш на чтение не нужен - все данные вытаскиваются с примерно одинаковой скоростью, зато все 100% кэша используются под write buffer, что дает преимущество в скорости обработки большого входящего потока операций ввода-вывода.

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


Таги: VMware, vSAN, Storage, VMachines, Performance

Как обновить информацию от VMware Tools о сетевых настройках гостевой ОС (пригодится для Instant Clone).


Вильям Лам написал интересную заметку про обновление информации о сетевой идентификации гостевой ОС, которую выдает VMware Tools. Она показывается на вкладке Summary клиента vSphere Client или VMware Workstation:

По умолчанию эта информация обновляется каждые 30 секунд на базе данных, предоставляемых пакетом VMware Tools из гостевой ОС. Однако если вы используете технологию создания мгновенных клонов (Instant Clone) и массово создаете виртуальные машины, то вам может потребоваться увидеть эту информацию пораньше.

Здесь есть 2 пути:

1. Принудительно обновить настройки из гостевой ОС следующими командами:

  • Windows - C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe info update network
  • Linux - /usr/bin/vmware-toolbox-cmd info update network
  • Mac OS - /Library/Application\ Support/VMware\ Tools/vmware-tools-cli info update network

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

Для этого в vmx-файл виртуальной машины нужно добавить следующую строчку (но не факт, что это работает сейчас):

vnet.pollInterval = XX


Таги: VMware, Tools, VMachines, vSphere, ESXi

Для чего нужна настройка Dedicated failover hosts в кластере VMware HA?


Некоторые администраторы VMware vSphere задаются вопросом, а для чего же нужна опция Dedicated failover hosts при настройке механизма Admission Control в кластере VMware HA:

Очень просто - это так называемые Spare Hosts, то есть запасные и всегда свободные хосты ESXi, которые берут на себя нагрузку по размещению виртуальных машин только в случае сбоев других серверов, обрабатываемых механизмом VMware HA.

Эти хосты в обычной жизни будут простаивать, и, если на них не удастся запустить виртуальные машины в случае сбоя, VMware HA все равно перезапустит эти ВМ на других хостах ESXi. Также эти хосты не будут браться в расчет механизмом VMware DRS, то есть он не будет мигрировать туда виртуальные машины, даже на период обслуживания других хостов (Maintenance mode).

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

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

Оба этих варианта очень маловероятны, поэтому, как правило, настройку Dedicated failover hosts использовать вообще не нужно.


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

На каком чипсете материнской платы работают виртуальные машины VMware vSphere?


Интересный пост Дэвида Пасека про чипсет материнской платы виртуального аппаратного обеспечения виртуальных машин на платформе VMware vSphere. Оказывается, все ВМ, независимо от версии виртуального "железа" (включая Virtual Hardware Version 14 в vSphere 6.7 Update 1), используют одну и ту же виртуальную материнскую плату на базе Intel 440BX, которая в свойствах системы называется "440BX Desktop Reference Platform" (скриншот из гостевой ОС Windows 10):

Примечательно, что этот чипсет был выпущен в апреле 1998 года - в том же году, когда была основана VMware, а через год был выпущен первый продукт компании VMware Workstation. И вот с тех пор чипсет виртуальной материнской платы не менялся! Видимо, незачем вносить туда серьезные изменения, от него ничего особо в работе виртуальной машины не зависит.

Кстати, изнутри гостевой ОС виртуальной машины можно поймать модель материнской платы следующей командой:

Get-WMIObject win32_baseboard | Select-Object Product

Это же позволит вам определить, что, например, ваш сценарий или программа работает в ВМ.

В Linux, возможно, сработает эта команда:

# dmidecode | grep -C 3 'Base Board'


Таги: VMware, VMachines, Hardware, vSphere

В какой enclosure и слоте находится диск VMware vSAN, какого он типа и емкости?


Часто администраторы виртуальной инфраструктуры VMware vSphere и отказоустойчивых кластеров VMware vSAN задаются вопросом, а как найти тот или иной диск vSAN в физическом сервере?

Иногда такую информацию можно получить с помощью следующей команды:

esxcli storage core device physical get -d <device id>

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

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

Также эту информацию можно посмотреть в разделе Cluster > Configure > vSAN > Disk Management, выбрав режим показа дисков "By Disk Vendors":

Но это тоже неудобно, хотелось бы такую информацию получать через PowerCLI. Информацию о дисковых устройствах можно получить с помощью командлета Get-ScsiLun, который выдает адаптер, к которому подключен диск, а также является ли он SSD-устройством, подходит ли для vSAN и другое. Но, к сожалению, он не дает данных об enclosure для этого диска, поэтому дополнительно нужно воспользоваться командлетом Get-EsxCli, который добавит эту информацию.

Таким образом, VMware предлагает использовать вот такой сценарий PowerCLI, который выведет информацию о физических устройствах, их нахождении в enclosure и слоте, а также типе дисков и их емкости:

Сам сценарий доступен по этой ссылке: https://code.vmware.com/samples/5539 (кстати, обратите внимание, что на портале VMware Code можно найти еще много чего интересного).


Таги: VMware, vSAN, PowerCLI, vSphere, VMachines, Hardware

Анонсирована платформа VMware vSphere 6.7 Update 2 - много новых возможностей.


На днях компания VMware анонсировала доступность новой версии своей флагманской платформы виртуализации VMware vSphere 6.7 Update 2. Напомним, что предыдущее обновление VMware vSphere 6.7 Update 1 вышло в августе прошлого года.

Давайте посмотрим, что с тех появилось нового:

1. Новое издание VMware vSphere ROBO Enterprise.

Теперь в издании для ROBO-сценариев (Remote or Branch Offices) появились следующие возможности уровня Enterprise:

DRS в режиме обслуживания (Maintenance Mode):

  • Доступно только для vSphere ROBO Enterprise.
  • Может быть использовано для автоматического перемещения ВМ между хостами (и обратно по окончании процесса). Для этого автоматически создаются правила VM-Host affinity (отслеживается, куда машины уехали перед миграцией, потом запомненные правила применяются - и машины приезжают обратно, где и были изначально).
  • Применяются обычные требования vMotion.
  • Никакого визуального механизма настройки DRS нет.

Шифрование машин (VM Encryption):

  • Шифрование домашней директории и файлов VMDK.
  • Требуется инфраструктура KMS.
  • Полностью безразлично к гостевой ОС.
  • Управляется через GUI или PowerCLI.

2. Обновление архитектуры vCenter Server.

Утилита PSC Converge tool теперь доступна в графическом интерфейсе. Об этом средстве мы писали вот тут, оно позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC.

Она дает следующие возможности:

  • Конвертация топологии external PSC в Embedded через GUI.
  • Можно выполнить шаги по выводу внешнего PSC из эксплуатации (Decomission).

  • Все это доступно в разделе System Configuration тонкого клиента vSphere Client (на базе HTML5).
  • Можно посмотреть текущую топологию PSC и vCenter в графическом или табличном виде.
  • В следующих релизах будет невозможно развернуть внешний PSC, поэтому с него надо уходить.

3. Улучшения резервного копирования и восстановления vCenter Server.

Здесь появилось 2 главных улучшения:

  • Новые протоколы, посредством которых вы можете сделать бэкап vCSA - NFS v3 и SMB.
  • Нотификации и алармы на успешное и неуспешное завершение задач РК. Эти алармы можно настроить подобно обычным алармам vSphere (послать email, SNMP trap или выполнить сценарий в случае успеха или неудачи).

4. Новые алармы и категории для vSphere Health.

  • Опция acknowledgement (заглушить) для алармов vSphere health (как и для обычных алармов).
  • Новые категории теперь включают в себя:
    • Online Availability
    • Compute
    • Network
    • Storage
  • Эти новые категории позволяют более органично охватывать проблемы сервера vCenter и упрощать управление им.

5. Улучшения Content Library.

  • Функции синхронизации шаблонов VM Template (VMTX).
  • Шаблоны виртуальных машин теперь можно синхронизировать в автоматическом режиме, как между приватными облаками с серверами vCenter, так и с публичным облаком VMware Cloud on AWS.

6. Улучшения vSphere Client.

  • В vSphere Client появилась возможность "code capture" (о ней мы писали вот тут). Теперь она позволяет вести запись пользовательских действий, которые были сделаны в рамках текущей сессии через vCenter API, и генерация соответствующего скрипта. Далее его можно использовать для автоматизации задач в инфраструктуре vSphere.
  • Функции API Explorer (доступны в разделе "Developer Center") - простая утилита по поиску в API, которая позволяет найти основные API-вызовы, включая примеры и возможность их тестирования.
7. Улучшения vSphere Update Manager.
  • Улучшения пользовательского интерфейса, включая функции attach, compliance check и remediation (все можно делать на одном экране).
  • Теперь можно привязать и сделать remediate для нескольких бейслайнов в рамках одной операции.
  • Во время remediation можно отключать removable-девайсы от виртуальных машин, включать Quickboot и пропускать проверки vSAN HealthCheck.

8. Улучшения VMware Tools.

  • Для Windows Server 2016 тулзы теперь обновляются через Windows update, а значит, что их обновления включены в общий цикл апдейта системы.
  • Версия VMware tools for Linux (в формате .TAR) больше не развивается, начиная с VMware Tools 10.3.10, так как OpenVM Tools доступны через любой package update manager.

9. Фикс Host Profiles.

Теперь при применении профиля хоста к ESXi не удаляется интерфейс VMK0, как это было раньше.

10. Улучшения безопасности.

  • Windows Server 2019 и RHEL 8 теперь полностью поддерживаются в vSphere 6.7 Update 2.
  • Можно применять лимиты для Password History и Reuse.
  • Теперь логируются дополнительные события SSO.
  • Улучшения ESXi certification API.
  • Генерация запроса vCenter Server CSR доступна через GUI клиента.
  • vSphere 6.7 Update 2 лучше обрабатывает уязвимости CPU за счет нового планировщика.
  • Доступна сертификация NIAP.

11. Улучшения производительности.

  • Поддержка 40 & 100Gb Ethernet и RDMA
  • Новая версия Virtual Hardware 15 (VM Compatibility):
    • До 256 vCPU на виртуальную машину
    • До 6 ТБ RAM на ВМ
    • Поддержка SAP HANA

На момент написания статьи обновление VMware vSphere 6.7 Update 2 было еще недоступно. Мы обновим пост, когда обновление можно будет скачать.


Таги: VMware, vSphere, Update, ESXi, vCenter, Tools, Security, VMachines

Лимитирование по IOPS виртуальных машин в кластере VMware vSAN - как это влияет на машину и ее соседей.


Политика ограничения виртуальных машин по операциям ввода-вывода (IOPS limits storage policy rule) позволяет ограничить виртуальную машину в кластере VMware vSAN в плане потребления ресурсов хранилища. Она применяется для VMDK дисков машин и, как правило, используется в ситуациях, когда нужно изолировать "прожорливого соседа" - то есть виртуальную машину, которая может начать потреблять несоразмерно много ресурсов хранилища по вводу-выводу на хосте ESXi, вызывая большие задержки (latency) у других машин этого хоста. При этом такая машина на данном хосте может быть далеко не самой важной.

Ограничение машины по IOPS имеет некоторые особенности. Размер операции ввода-вывода может варьироваться в диапазоне от 4 КБ до 1 МБ. Это означает, что самая большая операция может быть в 256 больше по объему самой маленькой. Поэтому при применении ограничения по IOPS решение vSAN использует так называемые "взвешенные IOPS", определяемые квантами по 32 КБ (об этом мы писали вот тут). При размере операции до 32 КБ планировщик vSAN считает ее как одну операцию, 32-64 КБ - как две, и так далее.

Это позволяет при визуализации метрик производительности нормализовать поток данных к хранилищу и управлять им при импорте настроек из механизма SIOC, который применяется к виртуальным машинам не в кластере vSAN. Надо отметить, что vSAN имеет собственную механику регуляции I/O и собственный планировщик, поэтому механизм SIOC не применяется к таким хранилищам.

Соответственно, давайте взглянем на графики операций ввода-вывода на вкладке Monitor->vSAN->Performance:

На нижнем графике (Virtual SCSI IOPS) мы видим число реальных операций ввода-вывода, независимо от их размера, а на верхнем - уже нормализованные IOPS и лимиты, применяемые к ВМ.

IOPS limit применяется только ко всему потоку ввода-вывода гостевой ОС машины (то есть ярус хранения, ярус кэширования), но не затрагивает операции с самим диском VMDK и его swap-файлами, например, репликация машины, SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.

Если машина достигает лимита по IOPS, планировщик vSAN для нее начинает откладывать операции ввода-вывода до завершения транзакции таким образом, чтобы они не превышали заданного лимита по нормализованному числу операций в секунду. Это все приводит к тому, что задержки исполнения данных операций (latency) существенно возрастают, что видно на графике Virtual SCSI Latency:

Здесь мы видим, что при достижении лимита 200 IOPS latency возросла до 580 мс, а при достижении 400 мс - где-то до 230-290 мс. Эти задержки, возникающие на уровне виртуальной машины, проявляют себя также и на уровне всего хоста, кластера и даже приложений, таких как vRealize Operations.

Этот важный фактор надо учитывать, когда вы ищете причину высокой latency, потому что механизм vSAN Performance Service не делает различий, возникли ли задержки из-за проблем с производительностью, или они являются результатом применения IOPS limits.

Интересно также, что применение IOPS limits storage policy rule к одной виртуальной машине может повлиять и на другую ВМ, к которой не применяется этого правила. Например, вы копируете файлы одной ВМ на вторую (и обратно), у которой есть IOPS limit. При достижении этого лимита, очевидно, происходит уменьшение числа IOPS не только у целевой ВМ, но и у источника, так как происходит уменьшение совокупного числа операций ввода-вывода на передачу файлов.

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

К сожалению, описанные эффекты влияния на производительность ВМ не всегда просто идентифицировать, поэтому нужно всегда осторожно выставлять IOPS limit и всегда четко его документировать в описании конфигурации виртуальной инфраструктуры.


Таги: VMware, vSAN, Performance, Storage, VMachines

Проверки виртуальной инфраструктуры VMware vCenter Health Сhecks в vSphere 6.7 Update 1.


В конце прошлого года мы писали о новых возможностях VMware vCenter в составе обновленной платформы виртуализации VMware vSphere 6.7 Update 1. Среди прочих интересных фичей, vCenter 6.7 U1 получил функцию Health Сhecks, которая позволяет обрабатывать данные телеметрии виртуальной инфраструктуры и на основе экспертных алгоритмов вырабатывать рекомендации по ее улучшению. Например, если у вас одна сеть Management network, вам могут порекомендовать ее задублировать.

Вчера мы писали об общем устройстве механизма vSphere Health. Давайте теперь детально посмотрим, как именно это работает. Сделано это чем-то похоже на службы vSAN Health Services, но здесь больше проактивной составляющей (то есть рекомендации генерируются постепенно и еще до возникновения реальных проблем).

Для просмотра основных хэлсчеков сервера vCenter, нужно в vSphere Client пойти на вкладку Monitor и выбрать там раздел Health:

Чтобы эти фичи функционировали корректно, нужно чтобы у вас была включена настройка Customer experience improvement program (CEIP). Если вы не включили ее во время установки vCenter, то вы всегда можете сделать это в разделе Administration клиента vSphere Client:

Надо отметить, что vCenter Health Сhecks не только оповещает о проблемах виртуальной инфраструктуры, но и в некоторых случаях предоставляет ссылки на статьи базы знаний VMware KB, которые могут помочь найти решения.

Если вы нажмете на какой-нибудь из ворнингов, например, "Disk space check for VMware vCenter Server Appliance", то увидите две группы параметров на вкладках "Details" и "Info":

На вкладке Details отображены численные значения и/или объекты виртуальной инфраструктуры, имеющие отношение к предупреждению, а вот вкладка Info разъясняет его суть и дает рекомендации по его устранению. Если же в правом верхнем углу появился значок "Ask VMware", значит для данного предупреждения есть ссылка на статью базы знаний VMware KB, которая может помочь:

Например, здесь на двух из трех хостов ESXi установлена не последняя версия драйвера bnx2x (адаптер Broadcom NetXtreme II 10Gb):

На вкладке Info объясняется, что хосты с такой версией драйвера этого устройства могут вывалиться в "розовый экран":

Если нажмем "Ask VMware", то в новой вкладке откроется статья KB, описывающая проблемы данной версии драйвера и пути их решения:

Если вы сделали изменения конфигурации согласно рекомендациям, вы можете нажать кнопку RETEST в правом верхнем углу, чтобы увидеть только актуальные предупреждения:


Таги: VMware, vCenter, Troubleshooting, vSphere, ESXi, VMachines, Blogs

Настройка указателя на единый репозиторий VMware Tools для хостов ESXi в VMware vSphere 6.7 Update 1 через Managed Object Browser.


После апгрейда виртуальной инфраструктуры на версию VMware vSphere 6.7 Update 1, а также при ее регулярном обновлении и эксплуатации, нужно поддерживать актуальные версии VMware Tools в виртуальных машинах.

Для начала напомним, что самую последнюю версию VMware Tools для ваших виртуальных машин всегда можно скачать по этой ссылке:

https://www.vmware.com/go/tools

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

/vmfs/volumes/vsanDatastore/vmtools

Далее нужно скачать последнюю версию VMware Tools по ссылке выше и положить ее в созданную папку (включая папки "vmtools" и "floppies").

Теперь на каждом хосте ESXi нужно обновить указатель ProductLocker через интерфейс MOB (Managed Object Browser). Для этого надо зайти по ссылке:

https://VCSA_FQDN/mob

И там перейти в:

Content > rootFolder > childEntity > hostFolder > host 

Далее нужно выбрать хост ESXi, для которого вы хотите обновить этот указатель. Здесь есть два API вызова, которые вам понадобятся:

Вызов QueryProductLockerLocation покажет вам текущий указатель на папку с VMware Tools на хосте (ProductLocker):

Метод UpdateProductLockerLocation_Task позволит вам обновить размещение для пакетов VMware Tools для этого хоста, добавив путь к нужной папке в параметр path:

Теперь снова вызовите QueryProductLockerLocation, чтобы увидеть, что путь к папке обновился:

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


Таги: VMware, Tools, Update, ESXi, VMachines, vSphere

Veeam Availability Suite 9.5 Update 4 и Veeam Backup and Replication 9.5 Update 4 доступны для скачивания.


Вчера на мероприятии по запуску новых продуктов и решений компания Veeam представила сразу 3 важных обновления:

Обязательно посмотрите большой анонс этих продуктов, в котором принял участие основатель компании Ратмир Тимашев:

В этой статье мы остановимся только на лидирующем в отрасли продукте Veeam Backup and Replication 9.5 Update 4, который уже сейчас доступен для скачивания:

Давайте посмотрим, какие интересные новые возможности появились в Veeam B&R 9.5 Update 4:

0. Поддержка vSphere 6.7 Update1.

Долгожданная поддержка последней версии платформы vSphere 6.7 Update 1, а также решений vCloud Director 9.5 и платформы Windows Server 2019 (включая Hyper-V 2019, Active Directory 2019, Exchange 2019 и SharePoint 2019).

1. Veeam Cloud Tier.

В новом релизе появилась нативная интеграция с облачными объектными хранилищами, которые можно использовать для долговременного хранения бэкапов в рамках концепции Scale-out Backup Repository. При этом оперативные резервные копии можно оставить на ярусе Performance Tier:

Теперь бэкапы можно передавать в облачное хранилище Amazon S3, Azure Blob Storage, IBM Cloud Object Storage, любое S3-совместимое хранилище или в другой датацентр для целей архивного хранения и/или катастрофоустойчивости.

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

2. Veeam Cloud Mobility.

Эти возможности позволяют восстановить резервные копии виртуальных машин, хранящиеся в репозиториях Veeam (в том числе, от Veeam Agent для Windows и Linux), на любую из облачных платформ в производственную среду. На данный момент поддерживаются платформы AWS, Azure и Azure Stack, а также любые онпремизные бэкапы:

Для облака AWS EC2 происходит автоматическая конверсия UEFI на BIOS для виртуальных машин.

3. Veeam DataLabs.

Данные функции Veeam B&R позволяют тестировать различные рабочие нагрузки, валидировать апдейты и патчи, проверять на наличие уязвимостей и соответствие политикам предприятия, а также убеждаться в общей восстановимости резервных копий.

Здесь Veeam B&R 9.5 Update 4 предоставляет следующие функции:

  • On-Demand Sandbox - виртуальная песочница для тестирования восстановленных резервных копий.
  • SureBackup и SureReplica - возможность удостовериться в работоспособности восстановления бэкапов и реплик.
  • Staged Restore (об этой возможности мы писали вот тут) - позволяет уменьшить время на просмотр и отсеивание чувствительных данных и убрать персональную информацию при восстановлении резервной копии (в частности, об уволенных сотрудниках). Это позволяет соблюсти требования GDPR и не попасть на штраф.
  • Secure Restore (об этой возможности мы писали вот тут) - возможность сканирования восстановленных резервных копий с помощью антивирусного программного обеспечения, чтобы устранить угрозы перед вводом восстановленных бэкапов в производственную среду.

4. Veeam Intelligent Diagnostics.

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

Сигнатуры с описанием известных проблем загружаются из базы знаний Veeam.

5. Прочие улучшения.

Полный список улучшений нового Veeam B&R приведен в документе What's New, а мы особенно отметим следующие:

  • Портал самообслуживания для ролевой модели доступа vSphere RBAC на базе Enterprise Manager.
  • Внешний репозиторий для N2WS.
  • Улучшения бэкапа на ленточные носители.
  • Плагин к Oracle RMAN.
  • Плагин к SAP Hana Plugin.
  • Улучшение продукта Veeam Explorer.

Скачать Veeam Backup and Replication 9.5 Update 4 можно по этой ссылке, Release Notes доступны тут.


Таги: Veeam, Backup, Update, vSphere, VMachines, Replication, Cloud, AWS, Azure

Как устроена цепочка сетевого стека VMware ESXi на уровне виртуального коммутатора - Network IOChain.


Недавно мы писали про то, как работает механизм регулирования полосы канала Network I/O Control (NIOC) в VMware vSphere, который позволяет приоритизировать различные типы трафика на одном сетевом адаптере, а сегодня взглянем на сам механизм прохождения трафика по уровням абстракции виртуального коммутатора изнутри.

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

IOChain обеспечивает связность виртуального коммутатора vSphere Standard Switch (VSS) или vSphere Distributed Switch (VDS) от групп портов на них к портам физических сетевым адаптеров (uplikns) в процессе передачи и обработки пакетов между этими сущностями. Для каждого из виртуальных коммутаторов есть 2 интерфейса IOChain (для входящего и исходящего трафика). Это дает большую гибкость по настройке политик каналов трафика Ingress и Egress.

Примерами таких политик служат поддержка сетей VLAN, механизма группировки NIC teaming и шейпинг трафика (traffic shaping). Работают эти политики на трех уровнях абстракции (в порядке следования от виртуальной машины):

  • Группа портов виртуального коммутатора (port group).

На этом уровне работает фильтрация VLAN, а также политики безопасности, такие как Promiscuous mode, MAC address changes и Forged transmits. Пользователи также могут настроить политики шейпинга исходящего трафика (для VSS) или в обоих направлениях (только для VDS).

  • Обычный или распределенный виртуальный коммутатор (VSS или VDS).

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

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

  • Порт (uplink).

Этот уровень отвечает за передачу трафика к драйверу сетевого адаптера. На этом уровне работают функции hardware offloading, облегчающие работу с обработкой пакетов за счет ресурсов сетевой карты. Доступные возможности hardware offloading зависят от конкретной модели карты и ее драйвера. Примерами таких возможностей являются TCP Segment Offload (TSO), Large Receive Offload (LRO) и Checksum Offload (CSO). Также здесь обеспечивается поддержка оверлейных протоколов VXLAN и Geneve, которые используются в решениях NSX-v и NSX-T соответственно (эта поддержка есть во многих современных сетевых картах).

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

Для обычного виртуального коммутатора (VSS) схема прохождения трафика через уровни абстракции IOChain выглядит так:

Если же у вас распределенный виртуальный коммутатор VDS, то вы можете использовать механизм Network I/O Control (NIOC) для резервирования и приоритизации трафика внутри канала аплинков. Также VDS предоставляет множество дополнительных возможностей, таких как LBT (Load Balanced Teaming) и LACP (Link Aggregation Control Protocol).

В случае с VDS схема с IOChain выглядит следующим образом:

 

Обратите внимание, что на этой диаграмме есть дополнительный модуль DVfilter. Это API-фреймворк, который есть в VDS и требуется для работы решения NSX. Когда компоненты NSX устанавливаются в ядро ESXi, они взаимодействуют с трафиком именно через этот модуль.

С помощью команды summarize-dvfilter можно вывести все загруженные агенты DVfilter и фильтры. Вот так это выглядит без установленного решения NSX:

Если вы посмотрите информацию по компонентам NSX, когда он установлен, то увидите модули nxst-switch-security, nsxt-vsip и nsxt-vdrb.

Вообще, весь стек IOChain является модульным, что позволяет добавлять новую функциональность его компонентов на различных уровнях абстракции. Например, компоненты DVfilter разделяются на Fastpaths, Slowpaths и Filters:

  • Fastpaths – фильтры трафика на уровне ядра ESXi.
  • Slowpaths – интеграция со сторонними продуктами для сетевой инфраструктуры.
  • Filters – размещение фильтров в слоты для каждого из подходящих по модели сетевых адаптеров vNIC.

В VMware vSphere 6.7 в стеке IOChain появилось несколько улучшений, таких как поддержка MAC learning и функции IGMP snooping через интерфейс VNI (Virtual Network Interface), которые могут быть использованы в будущем.

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


Таги: VMware, Networking, ESXi, VDS, VSS, VMachines

Почему корпоративные заказчики используют виртуальные машины, а не контейнеры.


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

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

Виды виртуализации

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

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

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

Виртуальные машины

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

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

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

Контейнеры

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


Таги: IT-Grad, VMachines, Containers, Сравнение

Сценарии отказов компонентов дисковой подсистемы кластера VMware vSAN - APD и PDL.


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

Как известно, дублирование дисковых компонентов и объектов в кластере vSAN зависит от политики Failures to tolerate (FTT) и уровня RAID, заданного для политики, которой подчиняется виртуальная машина:

Если для машин хоста задана политика с FTT=1 и RAID-1, то в общем случае, при отказе хоста ESXi, через 60 минут начинается ресинхронизация его дисковых объектов на других хостах, чтобы обеспечить выполнение политики FTT.

В случае сбоя какого-либо из компонентов дисковой подсистемы хранения кластера (от диска до хоста) механизм vSAN делит характер сбоя на 2 состояния: APD (All Paths Down) и PDL (Physical Device Loss). Об этих состояниях мы подробно писали вот тут.

  • APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. Это состояние считается временным и также называется "absent". Иными словами, мы не знаем, что случилось с устройством, может быть оно будет доступно в будущем. В этом случае vSAN не начинает сразу восстановление дисковых компонентов и объектов, а ждет 60 минут, чтобы не тратить напрасно ресурсы в случае, если устройство снова станет доступно. Время до начала восстановления можно регулировать настройкой Object Repair Timer, о которой мы детально писали вот тут
  • PDL (Physical Device Loss) - состояние, когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет. Этот статус считается постоянным и также называется "degraded". В этом случае кластер vSAN сразу начинает восстановление дисковых объектов, несмотря на значение Object Repair Timer. Примером таких состояний является выход из строя дискового массива или его части, поломка HBA/RAID-контроллера и т.п.

Давайте посмотрим, как именно реагирует кластер vSAN на различные варианты отказов и поломок дисковой подсистемы в кластере:

Сценарий отказа  Поведение vSAN  Воздействие на ВМ и поведение HA
Отказ диска в группе кэширования Дисковая группа помечается как "failed", и все ее компоненты перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ диска с данными (функции Dedupe и Compression включены) Дисковая группа помечается как "failed", и все ее компоненты перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ диска с данными (функции Dedupe и Compression отключены

Диск помечается как "failed", и все его компоненты перестраиваются на другом диске группы (rebuild).

ВМ продолжат работать
Отказ дисковой группы Все компоненты группы перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ контроллера RAID/HBA-карточки

Все дисковые группы под контролем карточки HBA/RAID будут помечены как absent и будут перестроены на других дисковых группах (rebuild).

ВМ продолжат работать
Отказ хоста или изоляция хоста

Компоненты на хосте будут помечены как absent и через 60 минут, если хост не вернется в онлайн, будут признаны устаревшими с последующим удалением (stale) после начал процесса перестроения дисковых объектов этого хоста (rebuild).

ВМ других хостов продолжат работать, ВМ этого хоста будут перезапущены HA на других хостах.

А вот графическая иллюстрация того, что происходит через 60 минут в кластере при отказе хоста ESXi. Обратите внимание, что если хост появится снова онлайн после сбоя и начала ресинхронизации (>60 минут) - его дисковые компоненты будут признаны "stale" и удалены механизмом vSAN, чтобы использовать его дисковое пространство в полном объеме.


Таги: VMware, vSAN, HA, Storage, VMachines

Политики хранилищ SPBM (Storage Policy Based Management) на базе тэгов в кластере VMware vSAN.


Мы уже упоминали о политиках хранилищ SPBM, (Storage Policy Based Management) в кластере VMware vSAN, которые представляют собой очень гибкий механизм для выделения виртуальным машинам хранилищ с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Политики SPBM разделяются на 3 основных области:

  • Storage Capabilities and Services - это политики, которые работают, когда хранилище vSAN или VVols представлено через интерфейс VASA производителем дисковой подсистемы (storage provider). Через VASA это устройство сообщает, какие сервисы оно предоставляет.
  • Data Services - это политики, настраиваемые на уровне хоста ESXi, они также реализуются на стороне дискового устройства (storage provider). Эти политики не определяют размещение виртуальных машин, но влияют на их возможности, например, использование шифрования или механизма SIOC.
  • Tags - это политики, которые используются хранилищами, которые не предоставляют каких-либо специфических функций, как правило - это обычные тома VMFS и NFS традиционных дисковых массивов без поддержки VASA.

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

Поддержка правил на базе тэгов определяется при создании политики:

С помощью тэгов можно задать ярусы размещения ВМ, конфигурации дисков и их расположение, тип ОС, департамент, к которому принадлежит ВМ, тип дисков SAS/SATA/SSD и многое другое. Вот какие аспекты размещения внутри объектов виртуальной инфраструктуры можно контролировать через категории и тэги:

Например, вы хотите сделать так, чтобы виртуальные машины с гостевой ОС Linux попадали на определенные хранилища. В этом случае надо создать категорию "OS" для объектов Datastore и Datastore Cluster и тэг "Linux", который надо назначить заданным хранилищам. После этого машины с таким тэгом при выборе соответствующей политики SPBM будут попадать на заданные стораджи.

Так, например, может выглядеть конфигурация тэгов и категорий в вашей инфраструктуре:

В рамках одной политики можно использовать до 128 тэгов - это излишне, но если у вас есть фантазия, то вы можете использовать их все) Например, вы можете использовать категорию Department для отдела, а внутри создать тэги для всех отделов: Financial, HR, Engineering и т.п.

Категории и тэги можно использовать для разных аспектов конфигураций хранилищ. Например, тип ОС или тип дисков, на которых размещены ВМ (Category: Disk Type, Tag: SAS).

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

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

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

Политики SPBM можно использовать не только отдельно для томов VMFS и NFS, но и для инфраструктуры vSAN и VVols, которые регулируются политиками на уровне хостов (host-based services). Например, можно создать политику, которая позволяет виртуальной машине использовать тома VVols, но только в определенном физическом размещении. Таким образом, с помощью провайдера VASA вы выбираете storage capability как VVols, а с помощью тэгов - физическое размещение ВМ.

Вот как это работает при создании политики:

С помощью PowerCLI вы можете получить информацию о виртуальных машинах или хранилищах, тэгированных определенным тэгом. Вот пример команды для ВМ:

Get-VM -Tag Windows
Name PowerState Num CPUs MemoryGB
---- ------- -------- --------
Windows-VMFS-VM PoweredOff 1 4.000
Win10-3 PoweredOn 2 4.000
jm-ws2016 PoweredOn 2 4.000
Win10-2 PoweredOn 2 4.000

И для хранилища:

Get-Datastore -Tag California
Name FreeSpaceGB CapacityGB
---- --------- ----------
N-VVol-Cali 2,048.000 2,048.000

При использовании механизмов размещения SPBM можно задавать уровень возможности их нарушения (Enforcement). Об этом вы можете прочитать в KB 2142765.

Несколько полезных ресурсов про политики SPBM:


Таги: VMware, SPBM, Storage, VMFS, NFS, VVols, vSAN, VMachines, Blogs

Режим обслуживания хостов кластера VMware vSAN Maintenance Mode - как это работает?


Как знают многие пользователи решения для создания отказоустойчивых кластеров VMware vSAN, в данном продукте есть возможность перевода хоста в режим обслуживания (Enter Maintenance Mode, EMM), который позволяет вывести его на время из эксплуатации с сохранением работоспособности кластера в целом. При этом происходит взаимодействие vSAN и механизма балансировки нагрузки VMware vSphere Distributed Resource Scheduler (DRS), который эвакуирует виртуальные машины с хоста ESXi.

Давайте посмотрим, как работает EMM для кластера vSAN, и какие есть опции для данной процедуры. Чтобы перевести хост ESXi в режим обслуживания, надо нажать на него правой кнопкой в vSphere Client и выбрать пункт Maintenance Mode > Enter Maintenance Mode.

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

  • Full Data Migration – это миграция всех компонентов дисковых объектов на другие хосты кластера.
  • Ensure Accessibility – это миграция только тех компонентов, которые есть в кластере в единственном экземпляре. При этом, для некоторых объектов в этом случае не будет соблюдена политика Failures to tolerate (FTT).
  • No Data Migration – в этом случае никакие компоненты не будут перемещены с хоста, поэтому некоторые ВМ могут оказаться недоступными (если на этом хосте их дисковые компоненты находятся в единственном экземпляре, а уровень RAID недостаточен для предоставления доступа к объекту).

С первым пунктом (Full Data Migration) все ясно - он вызывает долговременную процедуру миграции всех дисковых объектов и не всегда оправдан, когда хост ESXi нужно погасить лишь ненадолго. Но если вы выводите хост ESXi из эксплуатации производственного кластера (либо останавливаете, например, на несколько дней), то нужно выбирать именно Full Data Migration.

Давайте подробнее рассмотрим вариант Ensure Accessibility, который как раз подходит для кратковременного обслуживания хоста и последующего его повторного ввода в эксплуатацию. Если у вас достаточно запаса дисковых ресурсов, и виртуальные диски машин работают в RAID-1, то копии дисковых объектов переводимого в режим обслуживания хоста должны быть на других серверах. На картинке ниже реплика объекта C1 есть на другом хосте, поэтому в режиме Ensure Accessibility никаких миграций данных производиться не будет, кластер продолжит работать в режиме полной производительности:

Если же у вас, например, задана политика кластера FTT=1 на четырех хостах, и компоненты дисковых объектов хранятся в соответствии с политикой RAID-5, то картина будет следующей:

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

Между тем, если vSAN object manager будет наблюдать ситуацию несоответствия политики надежности более чем 60 минут (см. параметр Object repair timer в конце статьи), то он, все-таки, запустит синхронизацию дисковых объектов, чтобы их конфигурация в итоге соответствовала действующим политикам.

Кстати, обратите внимание, что такое поведение кластера vSAN - это одна из причин, почему VMware Update Manager не делает обновление хостов ESXi кластера vSAN в параллельном режиме, а проводит это последовательно. Ведь если бы это происходило параллельно, не факт, что можно было бы выполнить требования опции Ensure Accessibility, а также происходило бы много миграций дисковых компонентов.

Кроме того, перед переходом в режим обслуживания хоста, EMM делает полную симуляцию перемещений данных, которые будут проведены в процессе выключения хоста. Например, у нас есть 3 виртуальные машины: vm01 с политикой RAID-0 (без избыточных копий данных), а также машины vm02 и vm03 в режиме RAID-1 (зеркало).

Обратите внимание на картинку ниже:

Здесь показано, что в соответствии с вариантом No data migration 3 дисковых объекта виртуальной машины vm01 окажутся недоступными, а 30, относящихся к vm02 и vm03, не будут соответствовать действующей политике по обеспечению надежности.

Если мы нажмем на ссылку See detailed report, то увидим подробную картину симуляции EMM:

То есть, vm01 окажется недоступной, а vm02 и vm03 будут Non-compliant, пока хост находится в режиме обслуживания.

Если же вы выберете вариант Ensure Accessibility, то прогноз будет следующим:

440 МБ дисковых объектов, относящихся к vm01 будут перемещены, а 30 объектов не будут соответствовать политике, при этом все ВМ останутся доступными. Также в VMware vSAN 6.7 Update 1 появились новые предупреждения о том, что в кластере есть активные процессы синхронизации, а также переходящие или уже перешедшие в режим обслуживания хосты ESXi.

Ну и напомним о настройке Object Repair Timer, которую мы детально рассматривали вот тут. Она то, как раз, и позволяет вам расширить окно обслуживания хоста ESXi в Maintenance Mode, если вам это требуется для проведения какой-то долгой операции. По умолчанию синхронизация не соответствующих политике дисковых объектов начнется через 60 минут:

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


Таги: VMware, vSAN, HA, ESXi, VMachines, Storage

Кто залогинен в мои ВМ?


Знаете ли вы, кто залогинен в ваши виртуальные машины? Сколько из этих учётных записей локальные и сколько доменные? Уверены ли вы, что знаете где именно в вашей виртуальной инфраструктуре определённый пользователь залогинен в данный момент? И наконец последний вопрос, хотите ли знать ответы на эти вопросы? Если ваш ответ «Да», эта статья вам будет очень полезна...


Таги: VMware, PowerCLI, VMachines

Полезные расширенные настройки (Advanced Options) кластера VMware vSAN 6.7 Update 1.


Как почти все знают, компания VMware в рамках конференции VMworld 2018 анонсировала доступность новой версии решения для создания отказоустойчивых хранилищ VMware vSAN 6.7 Update 1. В обновленном vSAN появилась масса новых возможностей, но сегодня мы расскажем о трех новых расширенных настройках (Advanced Options), про которые написал Cormac Hogan, и которые стали доступны для редактирования в графическом интерфейсе.

Ранее Кормак рассказывал про следующие расширенные настройки кластера vSAN:

  • VSAN.ClomRepairDelay - задержка перед началом ребилда отсутствующих компонентов.
  • VSAN.DomOwnerForceWarmCache - определяет, должны ли операции чтения производится со всех реплик дисковых объектов, либо с определенных сайтов растянутого (stretched) кластера vSAN.
  • VSAN.SwapThickProvisionDisabled - возможность сделать swap-файлы виртуальных машин тонкими, то есть растущими по мере наполнения данными.

Теперь эти три настройки в новой инкарнации можно найти в разделе:

Cluster > Configure > vSAN > Services > Advanced Options

При нажатии на ссылку EDIT можно открыть интерфейс их изменения:

1. Настройка Object Repair Timer.

Как было сказано выше, она определяет задержку, после которой начинается ребилд отсутствующих дисковых объектов в кластере после произошедшего сбоя. По умолчанию она установлена в 60 минут (время, которое нужно VMware Update Manager для обновления хоста ESXi). Также тут нужно достаточное время, чтобы не происходило ненужных срабатываний при временных проблемах в сети. Если вы просто тестируете продукт vSAN, то можете поставить ее, например, в 15 минут, чтобы посмотреть, как начнется процесс ребилда.

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

2. Настройка Site Read Locality.

Эта настройка определяет, будут ли данные растянутого (stretched) кластера читаться из реплик дисковых объектов на уровне одного сайта (домена отказа), либо будут читаться из всех реплик дисковых объектов ВМ. Второй вариант подходит, когда между площадками у вас налажено высокоскоростное соединение (inter-site link), не отличающееся по скорости от внутреннего. Если же это совсем не так, то Read Locality можно отключить.

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

3. Настройка Thin Swap.

Она определяет, будут ли файлы подкачки виртуальных машин "тонкими", то есть растущими по мере наполнения данными. Тонкие swap-файлы экономят дисковое пространство, но создают совсем маленькую нагрузку по IO при аллоцировании блоков. По умолчанию тонкий своп включен.

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


Таги: VMware, vSAN, Update, Storage, VMachines, DR

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17    >   >>
Реклама





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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


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


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

Видео про Citrix Xen

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

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

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

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

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

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


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