Affinity rules vmware что это

Обновлено: 03.07.2024

Must run rules (Принудительные) (а так же anti affinity)
Should run rules (Предпочительные) (а так же anti affinity)

Must run rules – принудительные правила ограничивают HA, DRS и пользователей таким образом, что виртуальная машина может не включиться или же переехать на другой ESX/ESXi хост который не принадлежит ассоциированный DRS host группе.

Should run rules – дает предпочтение DRS-у чтобы запустить виртуальную машину на хосте который указан в ассоциированной DRS host группе.

Вот один из случаев когда нам может пригодится Should run affinity rule. У нас следующая задача:

нам нужно чтобы например виртуальная машина xp-01 всегда была бы запушена на ESX/ESXi хост-е esxi-01 до тех пор пока мы не переведем данный хост в maintenance mode.

Для этого в vCenter 4.1 у нас есть DRS Host группы которые нам помогут все это сделать. Создадим DRS Host группу DHG-ESXi-01 и добавим ESX/ESXi хост-е esxi-01. Затем создадим группу виртуальных машин например xp-01-to-esxi-01 и добавим туда виртуальную машину xp-01.

Что бы сделать все это заходим на vCenter с помощью vSphere Client-а затем выбираем наш кластер, жмем правой кнопкой и выбираем Edit Settings и после этого DRS Groups Manager.

После этого нам надо создать VMs to Hosts affinity rule и использовать Should run.

После этого как мы создали данный DRS rule, наша виртуальная машина не покинет esxi-01 хост до того момента пока мы не переведем его в maintenance mode.

Как только наш ESX/ESXi хост к которому привязана виртуальная машина выйдет из maintenance mode-а то DRS вернет ее обратно.

Прошел уже почти год с момента как я опубликовал последнюю запись на тему документа по Best Practices в VMware 7.0. Изначально я не планировал разбирать его дальше раздела, посвященного виртуальным машинам, однако результаты посещаемости сайта говорят о том, что данный цикл интересен читателю и было бы неплохо его закончить.

В течение следующих частей мы посмотрим на рекомендации VMware по управлению виртуальной инфраструктурой. Сегодня на очереди vCenter Server, vMotion, DRS, DPM.

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

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

General Resource Management

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

Следует использовать Reservation, Shares и Limits только в случае необходимости;
Если ожидаются частые изменения в инфраструктуре, которые могут влиять на общее количество доступных ресурсов, стоит использовать Shares, а не Reservation для честного распределения ресурсов между виртуальными машинами;
При использовании Reservation, рекомендуется указывать минимально необходимое количество CPU или RAM, а не резервировать все ресурсы для виртуальной машины. После того, как резерв будет удовлетворен, оставшиеся ресурсы будут распределены на основании показателя Shares. Не стоит выставлять большие значения Reservations, это может помещать запуску других виртуальных машин, которым не остается свободных ресурсов в пуле;
При использовании резервов, всегда необходимо оставлять свободные ресурсы для работы гипервизора и прочих служб, например, DRS и миграции;
Чтобы полностью изолировать пул ресурсов, необходимо использовать тип Fixed, а также включить для него Reservation и Limit;
Если сервис состоит из нескольких виртуальных машин (multi-tier service), стоит группировать данные виртуальные машины в рамках одного пула ресурсов для управления потребностями на уровне сервиса целиком.

VMware vCenter

vCenter Server должен получать достаточное количество вычислительных и дисковых ресурсов для функционирования;
Количество потребляемых ресурсов и производительность напрямую зависит от размера инфраструктуры (количество хостов, виртуальных машин и т.п.), а также от количества подключенных клиентов. Превышение допустимых максимумов однозначно скажется на производительности в худшую сторону, и к тому же не поддерживается;
Для получения минимальных задержек при работе vCenter с базой данных, следует минимизировать количество сетевых узлов между ними;
Сетевые задержки между vCenter Server и хостами ESXi могут влиять на производительность операций, в которые вовлечены данные хосты.

VMware vCenter Database Considerations

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

VMware vCenter Database Network and Storage Considerations

Если vCenter Appliance использует thin или lazy-zeroed диски, процесс загрузки может быть дольше, чем в случае использования дисков в формате eager-zeroed;
В крупных инсталляциях могут генерироваться большие объемы данных и хорошей практикой будет наблюдение за утилизацией дискового пространства. Как настроить оповещения сказано в соответствующей KB.

VMware vCenter Database Configuration and Maintenance

Следует использовать statistic level в соответствии с текущими требованиями. Данное значение может варьироваться от 1 до 4, но 1 достаточно в большинстве случаев. Более высокие значения могут замедлить работу vCenter, а также увеличится потребление дискового пространства. В случае, если необходим более высокий уровень статистики, например, при отладке, по окончанию данного процесса его следует снизить;
При запуске vCenter формирует пул из 50 потоков для подключения к БД. Размер данного пула меняется динамически в зависимости от работы vCenter и не требует модификации. Однако, при необходимости, размер данного пула может быть изменен до 128 потоков, при этом следует учитывать, что это увеличит потребление ОЗУ и может снизить скорость загрузки VC;
При необходимости подключения к БД VCSA следует воспользоваться материалом из данной KB;
В случае, если наблюдается медленное выполнение запросов, производительность может быть увеличена с помощью выполнения процедуры Vacuum and Analyze на базе данных VCDB.

PostgreSQL (vPostgres) Database Recommendations

В качестве базы данных vCenter использует PostgreSQL (vPosgress). Несмотря на то, что на этапе инсталляции, оптимизация работы базы данных выполняется автоматически, есть некоторые моменты на которые стоит обратить внимание:

vCenter Server Appliance создает несколько виртуальных дисков в момент инсталляции. Для улучшения производительности в больших окружениях следует убедиться, что виртуальные диски с партициями /storage/db, /storage/dblog и /storage/seat располагаются на разных физических дисках;
На виртуальном диске /storage/dblog хранятся транзакционные логи базы данных. vCenter особенно чувствителен к производительности данной партиции, в связи с чем виртуальный диск с данным разделом рекомендуется располагать на высокопроизводительном хранилище с наименьшим временем отклика;
Несмотря на то, что у PostgreSQL имеется свой собственный кэш, данные так же кэшируются на уровне операционной системы. Таким образом, производительность может быть улучшена за счет увеличения кэша ОС. Сделать это можно увеличив объем ОЗУ, выделенный виртуальной машине с vCenter Server, после чего, часть выделенной оперативной памяти будет задействована под кэш;
При достижении размера партиции /storage/dblog примерно до 90%, происходит сброс транзакционных логов. Чем быстрее заполняется этот раздел – тем чаще происходит операция сброса, увеличивая при этом количество дисковых операций. Увеличение размеров данной партиции снижает частоту сброса логов и уменьшает общий ввод-вывод. Это может помочь в больших инфраструктурах, однако, здесь есть и минусы – в случае необходимости восстановления после сбоя, данная процедура может занять большее время;
Для мониторинга дискового пространства можно использовать параметры vpxd.vdb.space.errorPercent и vpxd.vdb.space.warningPercent в расширенных настройках vCenter Server;
Так же для мониторинга можно использовать плагин pgtop для vCenter Server Appliance.

VMware vMotion and Storage vMotion

VMware vMotion Recommendations

Виртуальные машины, создаваемые в vSphere 7.0, имеют версию vHardware 17 (а в более свежих апдейтах – 18). Поскольку виртуальные машины с vHardware версии 17 могут запускаться только на хостах ESXi 7.0 и выше, vMotion для данных VM будет функционировать только в рамках хостов, поддерживающих данную версию;
Начиная с версии 6.5 vSphere поддерживает шифрование при выполнении операций миграции vMotion. Шифрование выполняется как на источнике, так и на приемнике, поэтому в случае миграции виртуальной машины на хост, версия которого ниже, чем 6.5, шифрования траффика при операциях vMotion производиться не будет;
Производительность vMotion со включенным шифрованием будет значительно выше, в случае если хост поддерживает инструкции AES_NI (Intel’s Advanced Encryption Standard New Instruction Set). Без поддержки данных инструкций, производительность vMotion может быть неприемлемой;
Зашифрованные виртуальные машины всегда используют Encrypted vMotion при миграции. Для нешифрованных виртуальных машин, шифрование может быть отключено (Disabled), обязательно (Required) и «по возможности» (Opportunistic);
Производительность vMotion напрямую зависит от скорости сети, поэтому рекомендуется иметь сетевое подключение 10GB/s и выше для сети, которая задействована под миграцию;
Все vmknic для vMotion следует располагать на одном и том же виртуальном свитче, при этом каждая из подгрупп, к которым они подключены, должна использовать разные физические интерфейсы в качестве активного аплинка;
В случае использования сети 40GB/s, рекомендуется сконфигурировать минимум 3 vMotion vmknics. Использование нескольких vmknic позволяет создавать множество потоков vMotion, утилизируя при этом большее количество процессорных ядер и увеличивая общую производительность;
При выполнении операций vMotion, ESXi старается зарезервировать процессорные ресурсы на источнике и приемнике, с целью максимальной утилизации пропускной способности сети. Количество резервируемого CPU зависит от количества vMotion NICs и их скорости, и составляет 10% производительности процессорного ядра за каждый 1Gb/s сетевого интерфейса, или же 100% процессорного ядра за каждый 10GB/s сетевой интерфейс, c минимальным резервом в 30%. Из этого вытекает то, что всегда следует держать незарезервированные процессорные ресурсы, чтобы процессы vMotion могли полностью утилизировать доступный сетевой канал и выполнять миграции быстрее;
Производительность vMotion может быть снижена, если swap уровня хоста размещен на локальных дисках (SSD или HDD).

VMware Storage vMotion Recommendations

Производительность Storage vMotion напрямую зависит от инфраструктуры хранения данных, от скорости подключения ESXi к хранилищам, от скорости работы хранилища-источника и хранилища-приемника. В момент операции миграции происходит чтение данных виртуальной машины из источника и запись в приемник, при этом виртуальная машина продолжает функционировать;
Storage vMotion будет иметь максимальную производительность в моменты низкой активности в сети хранения и если перемещаемые виртуальные машины при этом не создают большого дискового ввода-вывода;
Одна операция миграции позволяет перемещать до 4-х дисков виртуальной машины одновременно, но при этом на один Datastore будет копироваться не более одного диска одновременно. Например, перемещение 4-х дисков VMDK с хранилища A в хранилище B будет выполняться последовательно диск за диском, в то время, как перемещение четырех дисков VMDK с хранилищ A, B, C, D в хранилища E, F, G, H будут идти параллельно;
Как вариант, можно использовать anti-affinity правила для дисков виртуальных машин, тем самым выполнять операции svMotion на разные Datastore параллельно;
При выполнении операции Storage vMotion на более быстрое хранилище, эффект будет заметен только по окончанию процедуры миграции. В то же время эффект от перемещения на более медленное хранилище будет проявляться постепенно с операцией копирования;
Storage vMotion работает значительно лучше на массивах, поддерживающих VAAI.

VMware Cross-Host Storage vMotion Recommendations

Cross-host Storage vMotion позволяет перемещать виртуальные машины одновременно между хостами и хранилищами.

Cross-host Storage vMotion оптимизирован для работы с блоками размером 1MB, который уже достаточно давно является размером блока, выбираемым по умолчанию для VMFS. Однако, при создании хранилищ VM на VMFS3 размер блока мог быть выбран другой и при апгрейде хранилища до VMFS5 он не изменялся. В таком случае, самым верным вариантом будет пересоздать хранилище;
При использовании 40GB/s интерфейсов, применяются те же правила, что и для обычного vMotion, и рекомендуется использовать 3 vMotion vmknics;
Аналогичным образом одновременно копируется 4 диска и применяются те же правила, что и при Storage vMotion;
В большинстве своем, Cross-host Storage vMotion для миграции виртуальных дисков использует сеть vMotion. Однако, если оба хоста, между которыми выполняется миграция, подключены к одному и тому же массиву, поддерживающему VAAI, и хост-источник имеет доступы к Datastore, на который будет мигрирована виртуальная машина, в таком случае будет задействован VAAI функционал массива. Если же VAAI не поддерживается, будет задействована сеть хранения данных для копирования дисков, а не сеть vMotion;

При миграции выключенных виртуальных машин, Cross-host Storage vMotion будет использовать технологию Network File Copy (NFC). Однако, как и в случае со включенными виртуальными машинами, NFC будет задействовать VAAI, если это возможно, или же сеть хранения данных (нужно помнить, что это будет возможно только в случае, если хост-источник имеет доступ к хранилищу, куда перемещается машина).

Примечание: до vSphere 6.0 NFC использовал только management сеть. Начиная с vSphere 6.0, NFC траффик все так же использует сеть управления по умолчанию, однако, теперь для нужд NFC можно выделить отдельный интерфейс (vmknic Storage Replication).

VMware Distributed Resource Scheduler (DRS)

DRS in General

Следует следить за рекомендациями DRS, особенно в случае использования ручных ограничений и правил. В некоторых случаях невыполнение текущих рекомендаций может помешать генерации новых;
В случае использования affinity rules, следует наблюдать за DRS Faults и ошибками в работе DRS, которые могут возникать из-за препятствия существующих правил балансировке. Устранение текущих ошибок может значительно помочь с балансировкой существующей нагрузки;
Начиная с vSphere 7.0 привычная метрика cluster-level balance была заменена на новую – Cluster DRS Score, которая является индикатором состояния кластера и виртуальных машин в данном кластере.

DRS Cluster Configuration Setting

DRS affinity rules позволяют обеспечивать нахождение группы виртуальных машин в рамках одного хоста (VM/VM affinity), в то время как anti-affinity rules, препятствуют этому (VM/VM anti-affinity). Правила DRS так же позволяют явно указать хосты, на которых будут запускаться виртуальные машины (VM/Host affinity), или наоборот не будут (VM/Host anti-affinity).

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

Доступны следующие правила:

Keep Virtual Machines Together – позволяет достичь повышения производительности за счет уменьшения задержек при взаимодействии между виртуальными машинами в группе;
Separate Virtual Machines – Использование данного правила для группы VM, предоставляющих один и тот же сервис, позволит повысить доступность сервиса, за счет исключения ситуации, при которой все виртуальные машины, обеспечивающие один и тот же сервис оказались на одном хосте, с которым возникли неполадки;
Virtual Machines to Hosts – Включает в себя правила Must run on, Should run on, Must not run on и Should not run on, которые могут применяться, например, в случае с лицензированием, поскольку ограничивают круг хостов, на которых могут запускаться VM.

DRS Cluster Sizing and Resource Settings

Превышение допустимых максимумов по количеству хостов, виртуальных машин, пулов ресурсов не поддерживается. Несмотря на то, что система с превышенными максимумами может оставаться работоспособной, это может повлиять на производительность vCenter Server и DRS;
С осторожностью следует подходить к установке reservations, shares и limits. Слишком большой резерв может оставить мало незарезервированных ресурсов в кластере, что повлияет на DRS. В то же время слишком низкие лимиты могут препятствовать виртуальной машине в использовании свободных ресурсов, что скажется на ее производительности;
DRS учитывает NetIOC (NIOC) при расчетах рекомендаций;
Как уже упоминалось выше, для операций vMotion следует оставлять свободные ресурсы CPU на хостах.

DRS Performance Tuning

Начиная с vSphere 7.0 реакция механизма DRS зависит от типа нагрузок и настраивается соответственно нагрузкам в кластере. Всего таких уровней 5:

Level 1 – Только необходимая миграция, например, при вводе хоста в режим Maintenance. На текущем уровне DRS не предлагает миграцию с целью улучшения производительности;

Level 2 – Используется для стабильных рабочих нагрузок. DRS рекомендует миграцию виртуальных машин, только в моменты нехватки ресурсов;

Level 3 – Уровень по умолчанию. Подходит для большинства стабильных нагрузок;

Level 4 – Для систем, которым свойственны всплески при потреблении ресурсов и требуется реакция DRS;

Level 5 – Данный уровень следует использовать для динамичных нагрузок, потребление ресурсов которых постоянно изменяется.

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

VM Distribution – DRS старается равномерно распределять виртуальные машины в кластере, тем самым косвенно повышая доступность систем;
Начиная с vSphere 7.0 в дополнении к процессорным ресурсам и оперативной памяти, DRS учитывает так же и пропускную способность сети, когда формирует рекомендации по перемещению VM.

Обще вышеуказанных опции доступны в разделе Additional Options настроек DRS.

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

Есть несколько причин, по которым DRS Score может быть занижен:

Миграции препятствуют affinity и anti-affinity правила;
Миграции препятствуют несовместимые хосты в кластере;
Затраты ресурсов на миграцию могут быть выше, чем ожидаемые преимущества после ее выполнения;
На всех хостах в кластере повышенная загрузка сетевых интерфейсов;
В кластере нет свободных ресурсов, чтобы удовлетворить потребности виртуальных машин.

VMware Distributed Power Management (DPM)

VMware Distributed Power Management позволяет экономить электроэнергию, в моменты, когда хосты в кластере не утилизированы и не находятся под нагрузкой. Данный функционал позволяет консолидировать виртуальные машины на группе хостов, после чего переводит высвободившиеся гипервизоры в Standby режим. DPM поддерживает достаточную вычислительную емкость в кластере, чтобы удовлетворить нужды всех виртуальных машин. В моменты, когда потребность в ресурсах увеличивается, DPM включает дополнительные хосты и переносит на них виртуальные машины, приводя кластер к сбалансированному состоянию.

Начиная с vSphere 7.0, DPM учитывает всю выделенную оперативную память для виртуальных машин и поскольку эти значения достаточно стабильны, в большинстве случаев работа DPM зависит от процессорной утилизации.

DPM использует DRS, а значит большинство практик, применяемых к DRS, применяются и к DPM.

Основные термины и определения собраны в глоссарии.

Организации, vDC, пулы, регионы

Не могу попасть в панель vCloud Director, хотя деньги на счету есть

Возможно, вы пытаетесь попасть в учетную запись московского vCloud Director через веб-панель петербургского vCloud Director (или наоборот). В таком случае проверьте адрес веб-панели:

Учетная запись vCloud Director блокируется на 10 минут после 5 неудачных попыток ввода пароля. Поменять пароль можно на вкладке Пользователи панели управления Selectel.

Я не вижу свои vDC в панели vCloud Director, что делать?

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

Можно связать два региона в одной веб-панели с помощью функции Multisite, подробности в документации.

Как перенести ВМ из одного пула в другой?

Сменить пул ВМ можно только для vApp целиком:

Перенесите ВМ в отдельный vApp.
Выключите этот vApp в интерфейсе vCloud Director и затем в контекстном меню выберите Move to.
В графе Virtual Datacenter выберите дата-центр с другим типом пула.
Нажмите OK.

Для ВМ с ОС Windows необходимо оставить заявку через тикет-систему.

Для ВМ с диском до 40Гб время переноса — не более 10 мин.

Мне надо перенести vDC на другой аккаунт, это возможно?

Да. Это возможно, но с условиями и ограничениями:

на новом аккаунте не должно быть ни одного vDC;
можно перенести только сразу все vDC со старого на новый аккаунт;
перенос осуществляется на уровне Организации, то есть, переносится сразу Организация и все vDC в ней;
простоя ВМ не происходит;
все пользователи Организации сохраняются и переносятся вместе с ней.

Какие лимиты на ресурсы и количество vDC?

Стандартные лимиты на ресурсы vDC:

Пул	vCPU	RAM, GB	Disk, TB
Gold	100	500	3
Silver	100	500	5
Gold DR	100	500	2

Количество vDC на один аккаунт — 5.

По заявке клиента можем увеличить лимиты на ресурсы vDC и количество vDC.

Как удалить vDC?

Удалять можно только пустые vDC. Предварительно через vCloud Director удалите все vApp, ВМ, шаблоны vApp и каталоги.

В панели управления Selectel перейдите в раздел Облако на базе VMware. Раскройте меню (⋮) в карточке виртуального дата-центра и нажмите Удалить дата-центр.

Сколько сетей можно создать в одном vDC?

До 50 сетей в одном vDC. По заявке клиента лимит может быть увеличен.

Локальная сеть до других услуг?

Сети vDC можно подключить в локальную сеть выделенных серверов, размещаемых серверов (colocation), стоек и арендованного сетевого оборудования.

Вы можете использовать любую адресацию внутри локальной сети.

QnQ не поддерживается. Если вы используете QnQ в физической локальной сети, то необходимо сделать новый локальный VLAN и подключить его в VMware. Отправьте заявку через тикет-систему. В заявке укажите, в какой vDC будет заводиться сеть, адресацию в физической сети и желаемую адресацию в сети VMware.

Есть ли резервирование сетевого оборудования?

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

Можно ли назначить публичный IP прямо на ВМ без NAT?

Да. Мы выделим Direct Connected подсеть /29 или /28. Вы можете заказать подсеть размером до /24 по запросу через тикет-систему. Вы можете использовать любой доступный адрес в рамках выделенной подсети. Стоимость одного блока адресов указана на странице услуги.

Адрес назначается автоматически при деплое машины, если соблюдены условия:

внутри ВМ установлена утилита vmware-tools (Windows)/open-vm-tools (*nix);
сетевой интерфейс машины подключен к необходимой сети.

Нет доступа с ВМ на её же внешний IP через NAT, что делать?

Надо сделать NAT reflection, он же NAT hairpinning, он же NAT loopback, пример:

Act	Interface	Source	Port	Destination	Port	Proto
DNAT	WAN	85.119.148.123	80	10.60.0.6	80	TCP
DNAT	LAN	85.119.148.123	80	10.60.0.6	80	TCP
SNAT	LAN	10.60.0.6	any	85.119.148.123	any	any

Не работает NAT или Firewall, что не так?

Если firewall отключен, правила NAT не будут функционировать.

Убедитесь в том, что firewall включен и на нем есть правила, разрешающие нужный трафик. В ином случае включите firewall и добавьте нужные правила вручную.

Какой межсетевой экран (МСЭ) используется?

Мы предлагаем использовать встроенный в NSX.

Диски

Скорость виртуальных дисков

В таблице ниже указана производительность одного виртуального диска суммарно по всем операциям (чтение+запись) блоками по 32 килобайта:

Gold пул	Silver пул
Fast vSSD — 25000 IOPS	Fast vHDD — 2500 IOPS
vSSD — 5000 IOPS	vHDD — 300 IOPS

Можно ли подключить виртуальные диски из разных пулов к одной ВМ?

Нет. При создании виртуальной машины можно использовать разные типы дисков, но только внутри того пула, в котором она создана. Например, одновременно vSSD и Fast vSSD, или vHDD и Fast vHDD. Можно создать ВМ в разных пулах и видеть их вместе в своей организации в vCloud Director, а также соединять их в одной сети.

Снапшоты ВМ. Как использовать и управлять?

Вы можете создавать, удалять и восстанавливать снапшоты через панель vCloud Director.

На одну ВМ — один снапшот. При создании снапшота ВМ создаются снапшоты всех дисков, подключенных к ВМ. Ограничений на снапшоты дисков нет.

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

Не рекомендуется хранить снапшот больше 72-х часов. Хранение снапшотов дольше этого времени может привести к деградации производительности дисков ВМ. Для долгосрочных резервных копий используйте сервис резервного копирования.

В каких форматах могут быть импортированы шаблоны?

vCloud Director поддерживает шаблоны в форматах: ova и ovf. Шаблон в формате ovf должен загружаться вместе с сопутствующими файлами: vmx, mf, vmdk.

Не могу выбрать политику хранения при создании ВМ из шаблона в html5-консоли

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

Настроить политику хранения можно после того, как ВМ будет создана:

Нажмите Details на карточке созданной ВМ.
В графе Storage Policy выберите политику хранения и нажмите Save.

Примечание: вы можете выбрать политику хранения, которая соответствует пулу виртуального дата-центра (vHDD и Fast vHDD для Silver, vSSD и Fast vSSD для Gold).

Резервное копирование

Как реализовано резервное копирование?

Резервное копирование реализовано на базе Veeam Backup and Replication (VBR). Для управления бэкапами используется консоль Veeam Enterprise Manager.

Как управлять резервным копированием?

Резервное копирование Veeam Backup and Replication (VBR) подключается отдельно для организаций в Москве и Санкт-Петербурге.

Для доступа в консоль Veeam Enterprise Manager используйте соответствующую ссылку:

, где <org-name> — название организации.

Для входа введите данные учетной записи соответствующего региона.

Прочее

Как посмотреть загрузку ВМ?

Зайдите в веб-панель vCloud Director. В карточке виртуальной машины нажмите Details. В открывшемся интерфейсе найдите последнюю вкладку Monitoring Charts. Здесь выводятся графики загрузки ВМ — суммарные показатели по всем дискам ВМ.

Глубина хранения метрик — 90 дней. Шаг — 1 минута. Пользовательский интерфейс vCloud Director выводит данные за последнюю неделю, день, час и полчаса. Более старые метрики доступны через API: текущие значения, исторические значения.

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

В UI vCloud Director присутствуют метрики disk.read.average и disk.write.average. Эти метрики используются для классических систем хранения данных. Для дисков виртуальных машин, размещенных в хранилище vSAN, используются метрики virtualDisk.read.average и virtualDisk.write.average.

Поддерживает ли облако VMware nested virtualisation?

Да, поддерживает, но работоспособность на уровне эксплуатации не гарантируется. Подробности в документации VMware.

Максимальный размер CPU, RAM, объем диска виртуальной машины

Для ВМ, работоспособность которой мы гарантируем, максимальные показатели следующие:

vCPU — 72 (Platinum кластер);
vRAM — 256 GB;
виртуальный диск — 10 TB.

Доступно ли ПО Microsoft в облаке на базе VMware?

Да. Вы можете создавать ВМ из стандартных шаблонов серверных редакций Windows:

Windows Server 2019 Standard;
Windows Server 2016 Standard;
Windows Server 2012R2 Standard.

Вы можете использовать серверную редакцию с установленным пакетом Desktop Experience. Условия биллинга лицензий:

Если вы мигрировали или создали ВМ с Windows Server из своего образа, вам необходимо уведомить нас об этом. Мы включим лицензирование для такой ВМ вручную.

Имеют ли сотрудники Селектел доступ к vDC и данным клиента?

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

Согласно регламенту данные заказчика не могут быть скопированы, модифицированы или удалены без явного разрешения заказчика.

Как происходит изоляция между клиентскими облаками? Если один клиент будет грузить хост, начнут ли страдать соседи?

В vSphere есть механизм под названием DRS (Distributed Resource Scheduler), который автоматически и незаметно для пользователей переместит соседей на менее загруженные хосты.

Как мигрировать свои ВМ в инфраструктуру Selectel?

Вы можете использовать клиент vCloud Availability Appliance для переноса виртуальных машин. Читайте инструкцию по настройке клиента в статье: “Как установить on-prem vCloud Availability”.

Альтернативно, вы можете экспортировать/импортировать свои ВМ через шаблон OVA:

Чтобы экспортировать машины, перенесите их в отдельный vApp. Раскройте меню в карточке vApp и нажмите Download. Скачается файл шаблона в формате OVA.
Далее импортируйте скачанный шаблон в vCloud Director на базе инфраструктуры Selectel. Воспользуйтесь инструкцией Импорт виртуальных машин.

Есть ли поддержка Terraform?

Какие API предусмотрены?

У нас используется vCloud Director 10.2, который поддерживает версии API 30.0-35.0.

Для создания виртуальных дата-центров (vDC) мы предоставим отдельный API Selectel. Сейчас API и его документация в разработке.

Как сделать так, чтобы ВМ всегда были на разных хостах кластера?

В vCloud Director можно создавать Affinity правила, которые позволяют задавать правила размещения ВМ для механизма VMware DRS.

Правила бывают двух видов:

Affinity — указывают механизму DRS размещать ВМ на одном хосте виртуализации;
Anti Affinity — позволяют размещать ВМ на разных хостах кластера, что повышает доступность сервиса при сбое одного или нескольких хостов.

Эти правила различаются по типу:

hard (required) правила, которые не позволят игонрировать правило при отсутствии необходимого количества доступных хостов. Например, в правиле указано 10 машин, но в кластере доступно всего 8 хостов — в таком случае машины не запустятся;
soft (preferred) правила, которые позволяют игнорировать требования правила в случае отсутствия ресурсов, удовлетворяющих правилу.

Для настройки Anti Affinity правила:

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

После скачивания виртуальной машины из облака vCloud не удается ее загрузить ни на одну платформу VMware

После скачивания виртуальной машины проявляются следующие симптомы:

ее невозможно загрузить ни в vCloud, ни в vSphere, ни в Workstation;
при попытке распаковывания ВМ архиватором 7zip получаем ошибку: “Есть данные после конца блока полезных данных”;
в распакованной папке файл диска виртуальной машины отображается с нулевым размером;
виртуальную машину невозможно преобразовать через OVFTool, появляются ошибки.

Данная проблема возникает для виртуальных машин рамером больше 8Gb. Обусловлено это использованием расшинеия pax ustar при создании OVA файла на платформе vCloud Director.

Решения данной проблемы: файл OVA необходимо распаковать архиватором, отличнм от 7zip, например WinRAR для Windows или tar для Linux/Unix. После извлечения всех файлов их можно будет загрузить на любую поддерживаемую платформу.

Не удается смонтировать собственный образ ISO из библиотеки

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

Проблема возникает из-за того, что образ ISO размещен в библиотеке с политикой хранения пула, отличного от пула размещения ВМ, к которой монтируется образ.

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

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

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

Топ-6 проблем с производительностью CPU

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

Параметр Co-stoptime показывает, что виртуальных процессоров vCPU больше, чем необходимо. Как это ни парадоксально, порой большое число vCPU снижает, а не увеличивает производительность виртуальной машины.

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

Параметр, который отслеживает загрузку процессора хоста. Когда средняя загрузка будет более 75% или пиковая достигнет 90%, узел vSphere решит, что ресурсов CPU не хватает, как результат — остановка виртуальных машин или проблемы с запуском.

Показывает перегрузку виртуального процессора. Если запущенное на виртуальной машине приложение «ест» больше 90% ресурсов процессора, производительность будет деградировать. Решение: добавить еще vCPU или разобраться с приложением — может, оно работает нестабильно или просто зависло.

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

Имитируем загрузку CPU и изучаем особенности

Чтобы проверить корректность работы виртуального сервера, необходимо в тестовой среде запустить скрипт загрузки CPU и проанализировать поведение машины. Для этого в VMware vSphere Power CLI запускаем скрипт Start CPU Test.

Скрипт запускает две виртуальные машины и показывает их удаленные рабочие столы. На машинах PERF-WORKER-01A и PERF-WORKER-01B имитируется сильная нагрузка на vCPU и отображается производительность в режиме реального времени. В нашем случае она составляет около 15 000.

Теперь необходимо в окне vSphere зайти на вкладку мониторинга производительности виртуальной машины PERF-WORKER-01A и для отображения расширенных параметров включить опцию Advanced –> Chart Options.

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

Мы рекомендуем обратить внимание на следующие счетчики:

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

Выявление проблем путем анализа показателей счетчиков

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

На скриншоте мы видим, что значение счетчика Demand (потребление) сильно больше, чем значение счетчика Use (использование). А показатель Ready Time равен 9977 ms. Чтобы перевести значение из миллисекунд в проценты для режима реального времени (real-time), необходимо показатель Ready Time разделить на 200 — в случае одного используемого vCPU. Или воспользоваться калькулятором. Для нашего теста получилось значение 49,89%, что в значительной мере превышает рекомендуемые 10%, а значит, наблюдается серьезная проблема с производительностью.

Также рекомендуем посмотреть статистику CPU на уровне хоста. Для этого выбрать нужный узел на вкладке Monitor-Performance и включить опцию Advanced — теперь станут видны счетчики производительности хоста.

Отследим статистику нагрузки CPU на уровне физического хоста.

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

Чтобы решить эту проблему, проверим правильность конфигураций тестовых виртуальных машин.

Проверка параметров виртуальных машин

Для проверки параметров виртуальной машины VMPERF-WORKER-01A выбираем в меню Actions команду Edit Settings.

Теперь проверим параметр CPU affinity, который может быть причиной возникновения такой аномалии.

В нашем случае его значение равно единице — это означает, что данной виртуальной машине назначен только один физический процессор и другие она использовать не может, даже в случае 100% нагрузки. Для правильной балансировки нагрузки между физическими процессорами хоста необходимо очистить это значение (оставить параметр пустым) и нажать «ОК». Те же манипуляции необходимо проделать и с настройками виртуальной машины PERF-WORKER-01B.

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

Заключение

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

Мы рассмотрели проблемы, связанные с производительностью CPU, и рассказали, как с помощью тестов и счетчиков обнаружить слабые места виртуальной инфраструктуры. На виртуальную инфраструктуру надейся, но и сам за всем следи!

Читайте также: