Performance Best Practices for VMware vSphere 7.0. Часть 8 и заключительная

В заключительной статье речь пойдет про SDRS и SIOC, HA и FT, vSAN и vVols, а так же немного про LCM, SSO и CL.

Важное примечание. Я так долго тянул, что уже вышел более свежий документ, основанный на vSphere 7.0 Update 2, поэтому заключительная часть будет основана на нем. Не смотря на то, что он подрос на 4 страницы, основные принципы остаются теми же от версии к версии и предыдущие части не утратили своей актуальности.

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

Часть 1 – Hardware for Use with VMware vSphere;

Часть 2 – ESXi General Considerations и CPU;

Часть 3 – ESXi General Considerations и оперативная память;

Часть 4 – ESXi Storage Considerations;

Часть 5 – ESXi Networ Considerations;

Часть 6 – Guest Operating Systems;

Часть 7 – vCenter, vMotion/svMotion, DRS, DPM.

Примечание:
В комментариях к предыдущей статье упомянули важный момент, который касается изменений в vMotion в Update 2 для vSphere 7.0.

VMware vSphere Storage I/O Control

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

Для управления распределением ресурсов используются:

1. IOPS Shares, которые определяют какую часть ресурсов получит виртуальная машина. Shares работают на глобальном уровне, а количество получаемых хостом ресурсов с хранилища определяется суммой значений Shares виртуальных машин, работающих с данным хранилищем на данном хосте, деленным на сумму значений shares всех виртуальных машин, работающих на данном хранилище;
2. IOPS Reservations – данный параметр позволяет определить минимальную потребность виртуальной машины в IOPS. Storage I/O Control сможет гарантировать потребность в ресурсах только при условии, что оборудование (СХД) в состоянии обеспечить данную потребность;
3. IOPS Limits – указывает верхнюю границу IOPS, которые может получить виртуальная машина.

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

VMware Storage Distributed Resource Scheduler (Storage DRS)

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

Ряд рекомендация для SDRS:

1. Формировать кластер следует из хранилищ, которые схожи по характеристикам, таким как протокол подключения (FCP, iSCSI, NFS), производительность, используемый уровень RAID.  Например, не рекомендуется формировать кластер из хранилищ на базе HDD и SSD;
2. При конфигурации кластера не стоит превышать допустимые максимумы;
3. Следует убедиться, что все хосты имеют доступ ко всем хранилищам в кластере. Таким образом SDRS будет проще формировать правила и решения по балансировке;
4. Рекомендуется наблюдать за показателями Latency в Performance Chart кластера, особенно в моменты повышенных нагрузок. Если большинство из хранилищ в кластере функционируют со значениями latency близкими к порогу реагирования (30ms по умолчанию), это может быть индикатором того, что кластер не в состоянии обеспечить требуемый уровень ввода-вывода. В таком случае следует задуматься о добавлении новых хранилищ в кластер;
5. По умолчанию правила Storage DRS размещают все диски виртуальной машины на одном хранилище (Intra-VM affinity). Однако, гибкость SDRS в плане балансировки можно повысить, отказавшись от использования Intra-VM правил. Это может дать некоторый потенциальный выигрыш в производительности. Применить настройку можно как на уровне VM, так и на уровне кластера;
6. Ограничить размещение двух и более виртуальных машин на одном и том же хранилище можно с помощью правил Inter-VM anti-affinity;
7. В случае, если datastore cluster состоит из хранилищ, размещенных на тонких дисках (thin-provisioned LUN), следует убедиться, что на системе хранения данных достаточно пространства для роста данных LUN.

VMware vSphere High Availability

Механизм VMware vSphere High Availability позволяет снизить время недоступности виртуальных машин за счет мониторинга хостов, хранилищ, виртуальных машин и выполнения перезапуска виртуальных машин на других хостах в случае наблюдаемого сбоя.

VMware High Availability in General

1. В кластере HA принимают участие активные хосты, не находящиеся в режиме Maintenance. Все хосты участвуют в выборе главного (Primary), который ответственен за мониторинг состояния остальных хостов в кластере, защищает виртуальные машины, инициируя их перезапуск, а также передает в vCenter информацию о состоянии кластера. Роль Primary либо оказывает крайне незначительное влияние на производительность хоста, либо не оказывает вовсе;
2. Когда Primary хост в кластере не может установить связь с другим хостом через сеть управления, он использует общие хранилища (datastore hearbeating) для того чтобы установить его состояние. По умолчанию HA использует два хранилища, что позволяет обеспечить минимум ложных срабатываний операций failover. Еще больше уменьшить вероятность ложных срабатываний можно за счет изменения параметра das.heartbeatDsPerHost, который позволяет изменить количество используемых heartbeat datastore до 5. Предпочтительно выбирать хранилища, на доступность которых не влияет недоступность сети, используемой механизмом High Availability;
3. Включение HA резервирует на хосте некоторое количество ресурсов для работы агентов, что незначительное уменьшает доступное количество ресурсов для запуска VM;
4. После включения HA, vCenter Server резервирует достаточное количество ресурсов в кластере чтобы соответствовать заданным admission policy и иметь возможность запустить виртуальные машины со сбойного хоста на других узлах. В свою это уменьшает общее количество ресурсов, доступных для виртуальных машин;
5. В случае сбоя, механизм HA запрашивает DRS, с целью определения наилучших хостов для запуска виртуальных машин. В случае, если механизм DRS не доступен, HA будет придерживаться базового алгоритма.

Virtual Machine Component Protection (VMCP)

VMCP – функционал, который позволяет механизму HA определять, когда хост теряет связь с хранилищем, подключенным по FC, iSCSI или NFS и производить автоматическое восстановление работоспособности виртуальных машин на других хостах, с которых хранилище доступно. Данный функционал отключен изначально, при включении начинает потреблять некоторое количество процессорных ресурсов.

VMware Fault Tolerance

VMware Fault Tolerance или же FT позволяет обеспечить непрерывную доступность виртуальной машины даже в случае выхода из строя гипервизора.

Поскольку FT использует механизм HA, большинство практик, применяемых для HA, актуальны и для Fault Tolerance.

После включения функционала FT для виртуальной машины, она получает статус Primary. Для каждой Primary машины создается ее зеркальная копия, называемся Secondary. Виртуальная машина с ролью Secondary может стать основной, например, после сбоя и выполнения операции failover.

FT требует дополнительные ресурсы и перед включением необходимо убедиться в наличии необходимых ресурсов:

1. Парная виртуальная машина требует дисковые ресурсы, аналогичные основной, поскольку является ее полной копией. Все изменения в VMDK основной машины дублируются на диски резервной машины;
2. Для основной и резервной виртуальной машины включается полный резерв оперативной памяти, что позволяет удостовериться в том, что memory ballooning и swapping данных машин не коснется. Следует помнить, что накладные расходы оперативной памяти составляют 1-2 гигабайта для основной и резервной машины;
3. Следует убедиться, что сеть, используемая под Fault Tolerance, функционирует на скорости 10Gb/s и выше;
4. Потребности в процессорных ресурсах для резервной виртуальной машины будут выше, чем потребности основной, в связи с необходимостью в выполнении операций синхронизации с Primary VM.

Прежде чем виртуальная машина будет защищена, между Primary и Secondary VM должна пройти синхронизация дисков VMDK, а также оперативной памяти (initial synchronization).  Синхронизация дисков может занять длительное время, поэтому не стоит ожидать, что виртуальная машина будет защищена сразу же после включения FT.

Initial synchronization происходит в следующих случаях:

1. Когда для виртуальной машины включается Fault Tolerance;
2. Когда защищенная FT машина переходит из состояния powered-off в powered-on, т.е. просто включается;
3. В случае запуска FT после его приостановки (Suspend Fault Tolerance);
4. При восстановлении защиты FT после аварийных ситуаций, либо при выполнении операций Test Failover или Test Restart Secondary.

Некоторые рекомендации:

1. Не следует использовать сеть виртуальных машин для задач FT и прочих операций, например, vMotion. Каждый из данных типов трафика может негативно влиять на всех остальных;
2. Большая часть сетевого трафика передается от Primary VM к Secondary. В случае с большим количеством защищаемых с помощью FT виртуальных машин, снизить нагрузку на сеть можно за счет разнесения Primary виртуальных машин на разные хосты. Например, в случае с двумя хостами ESXi и двумя FT машинами, размещение Primary VM на каждом из хостов будет правильным решением;
3. Следует быть осторожным при размещении на одном хосте больше 4, защищенных FT виртуальных машин, либо при суммарном количестве vCPU защищенных машин, более чем 8. Подобная конфигурация может привести к повышенной утилизации сети, используемой для нужд Fault Tolerance и увеличить количество миграций виртуальных машин;
4. В случае если резервной виртуальной машине не будет хватать ресурсов, например, сети или процессорных циклов, это может сказаться на производительности основной VM, работа которой может быть принудительно замедленна гипервизором ESXi с целью поддержания резервной виртуальной машины в актуальном состоянии;

Например, хост, на котором работает несколько Secondary VM, может оказаться в ситуации, при которой ему не хватит пропускной способности сети, в то время как хост с основной VM полон свободных ресурсов. В этой ситуации основная машина будет замедленна, в связи с нехваткой ресурсов ее копии. Для исключения подобных ситуаций следует придерживаться рекомендаций:

1. Убедитесь, что утилизация хостов на которых располагаются виртуальные машины схожая. Это касается процессорных ресурсов, сети, а также производительности хранилища. Узкие места могут сказаться на производительности VM;
2. Следует убедиться, что параметры Power Management одинаковы для BIOS обоих хостов;
3. Чтобы гарантировать достаточное количество процессорных ресурсов виртуальным машинам, можно использовать CPU Reservations для Primary. Данный параметр будет продублирован и для резервной.

Для наилучшей производительности FT рекомендуется использовать процессоры Intel поколения Haswell и выше, а также AMD поколения Piledriver и выше.

VMware vSphere Lifecycle Manager

Lifecycle Manager – это система управления патчами и обновлениями для VMware vSphere. LCM включает в себя весь функционал vSphere Update Manager (который использовался в предыдущих версиях), а так же включает новые возможности. Lifecycle Manager может быть использован как для установки обновлений и патчей для хостов ESXi, так и для обновления прошивок (firmware) серверного оборудования, VMware Tools для виртуальных машин и т.п.

Lifecycle Manager General Recommendations

1. Следует убедиться, что базе данных vCenter хватает дискового пространства как для хранения всего окружения, так и для данных, необходимых Lifecycle Manager. Инициализация LCM требует около 150 мегабайт, с дальнейшим потреблением около 100MB в месяц;
2. Количество оперативной памяти, которую потребляет LCM напрямую зависит от размеров инфраструктуры, особенно от количества виртуальных машин.  Наряду с остальными службами vCenter следует наблюдать и за потреблением ресурсов LCM;
3. Операции обновления VMware Tools значительно быстрее, если виртуальная машина уже включена. Выключенные виртуальные машины нужно будет предварительно включить, что увеличивает общее время выполнения операции обновления;
4. При этом обновление vHardware производится быстрее, если виртуальная машина уже выключена. В противном случае, Lifecycle Manager должен предварительно выключить VM, что так же увеличивает время выполнения операции;
5. VMware Tools должны быть обновлены до обновления vHardware.

Lifecycle Manager Quick Boot Option

LCM поддерживает функционал под названием Quick Boot на совместимом серверном оборудовании. Использование Quick Boot позволяет выполнить перезагрузку ESXi без последующей необходимости в инициализации микрокода и устройств, что значительно экономит время при обновлении хостов.

Чтобы убедиться, что оборудование поддерживает функционал Quick Boot, можно выполнить данную команду из консоли ESXi:
/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py

Lifecycle Manager Cluster Remediation

Начиная с vSphere 7.0 Lifecycle Manager позволяет формировать образы ESXi (базовая версия, набор патчей, вендорский аддон), которые будут использоваться для всех гипервизоров, включенных в кластер. Использование Cluster Image позволяет убедиться, что все хосты в кластере используют один и тот же заранее сформированный образ ESXi.

LCM также поддерживает и привычные baselines, которые использовались в предыдущих версиях vSphere.

Обновлять кластер можно либо с помощью подготовленного заранее образа, либо с помощью baseline, но оба варианта использовать для одного и того же кластера одновременно невозможно.

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

VMware vSAN

VMware vSAN позволяет использовать локальные дисковые ресурсы серверного оборудования, на котором работает гипервизор ESXi, позволяя сформировать общее распределенное хранилище между хостами, входящими в кластер.

Hybrid versus All-Flash vSAN

vSAN может функционировать как в гибридном, так и в all-flash вариантах.

1. В гибридном варианте, диски SSD используется в качестве уровня кэширования (caching tier), позволяя обеспечить кэш для операций чтения и записи, в то время как HDD диски, которые, обычно больше в объемах и дешевле, но медленней, используются для уровня хранения (capacity tier);
2. В all-flash варианте, SSD используется как для уровня кэширования (только операции записи), так и для уровня хранения данных.

Несмотря на то, что Hybrid решения достаточны быстры, all-flash решения все равно быстрее. Так же all-flash vSAN поддерживает функционал RAID-5, RAID-6, дедупликацию и компрессию, что позволяет значительно экономить на необходимом дисковом пространстве. Использование данного функционала позволяет снизить разницу в стоимости между гибридными и all-flash решениями.

vSAN Hardware Selection and Layout

Hardware Selection and Layout for Hybrid vSAN

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

Соотношение объемов SSD к HDD оказывает значительное влияние на производительность vSAN. Больший объем SSD позволяет обеспечить большую производительность, но в то же время имеет более высокую стоимость.

Hardware Selection and Layout for All-Flash vSAN

В all-flash варианте кластера, запись выполняется на диски SSD из уровня кэширования, поcле чего данные переносятся на SSD из уровня хранения (capacity tier). Чтение же выполняется напрямую с уровня хранения (исключение составляют только данные, которые еще не были перенесены с уровня кэширования в уровень хранения).

Производительность уровня кэширования имеет большое влияние на производительность всего кластера. Использование высокопроизводительных SSD дисков, например, таких как NVMe, для уровня кэширования, значительно увеличивает производительность кластера, особенно в случае использования систем, которые генерируют большой объем дисковых операций.

Hardware Selection and Layout for vSAN in General

1. vSAN функционирует наиболее стабильно в случае равномерного распределения дисковых ресурсов в кластере между хостами ESXi (идентичные хосты);
2. Все диски в кластере vSAN организуются в группы (disk groups). Каждая группа дисков состоит из одного кэширующего диска и одного или нескольких дисков уровня хранения. Увеличение количества дисковых групп увеличивает производительность vSAN.

vSAN Network Considerations

1. Несмотря на то, что небольшие гибридные инсталляции могут нормально функционировать при сетевом подключении 1Gb/s. Использование 10Gb/s либо более пропускной сети позволяет обеспечить большую производительность. Для all-flash инсталляций, 10Gb/s – минимальное требование, а не рекомендация;
2. Производительность и качество сети напрямую влияют на производительность vSAN. Сетевые проблемы могут значительно влиять на работоспособность кластера;
3. Поскольку jumbo frames позволяют помещать блоки размером в 4K и 8K в один сетевой пакет, при нагрузках, оперирующих данными размерами блоков, использование jumbo frames может быть преимуществом;
4. При больших размерах блоков, использование jumbo frames не вносит значительной прибавки в производительности, при этом, в случае правильной конфигурации сети, негативного влияния на производительность так же не оказывает.

 vSAN Configuration and Use

1. Некоторые политики vSAN их конфигурация (VM Storage Policies) могут влиять на производительность кластера:
   1. Number of disk stripes per object;
   2. Flash Read Cache reservation (в случае с гибридными кластерами);
   3. Number of failures to tolerate;
   4. Object space reservation.

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

2. Активированный по умолчанию функционал End-to-end software checksum может быть деактивирован на уровне виртуальной машины, либо объекта. Отключение проверки контрольных сумм может быть актуально, только если данный функционал уже присутствует на уровне приложения. В целом же, влияние функционала на производительность незначительное, а накладные расходы – низкие;
3. По аналогии со сбалансированным распределением дисковых ресурсов между хостами в кластере, следует так же пропорционально распределять виртуальные машины между хостами. Помочь в этом может DRS;
4. Функциональность RAID-5 и RAID-6 доступна только в all-flash вариации vSAN кластера и может обеспечить защиту данных с некоторым снижением производительности, которое нивелируется all-flash инфраструктурой. Репликация (RAID-1) позволяет обеспечить наилучшие показатели производительности ценой большего объема занятого пространства;
5. Некоторые приложения имеют встроенный функционал репликации данных, при использовании подобных систем стоит подумать насчет использования параметра Failures to Tolerate = 0 (FTT), или другими словами – не использовать репликацию и защиту данных на уровне vSAN.

vSAN Encryption

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

1. Шифрование в vSAN использует процессорные ресурсы. При достаточном количестве ресурсов ЦП, влияние на производительность не должно быть значительным;
2. Использование AES-NI может значительно снизить утилизацию процессора при использовании шифрования. Практически все современные процессоры поддерживают AES-NI, однако может потребоваться включить данный функционал в BIOS. В некоторых случаях также может потребоваться обновление BIOS;
3. После перезагрузки хоста, зашифрованные дисковые группы vSAN не монтируются до тех пор, пока не будет получен ключ от сервера KMS.

VMware vSphere Virtual Volumes (vVols)

VMware vSphere Virtual Volumes (vVols) функционируют за счет взаимодействия между программным обеспечением VMware и системами хранения данных SAN или NAS, позволяя получить более гибкий контроль над политиками размещения виртуальных машин на хранилищах.

vVols Hardware Considerations

1. vVols работают только с системами хранения данных, которые поддерживают vSphere APIs for Storage Awareness (VASA) версии 2.0 и выше;
2. Производительность vVols может отличаться на разных хранилищах. Перед выбором системы хранения следует убедиться, что оно позволяет обеспечить ожидаемую производительность при использовании vVols;
3. При выборе СХД, всегда следует помнить про ограничения, которые могут возникнуть в процессе эксплуатации. VM, использующие vVols, требуют выделение нескольких виртуальных томов (config, swap, data, snapshots и т.п.), поэтому следует знать лимиты СХД, чтобы неожиданно не столкнуться с ограничениями;
4. Для работы функционала vVols необходим VASA provider (иногда называемого storage provider или VP). Это программный уровень, который предоставляет хостам ESXi интерфейс для управления системой хранения. В случае с некоторыми СХД, VASA провайдер запускается непосредственно на системе хранения, в то время как другие требуют для этого установку отдельной виртуальной машины или выделенного сервера;
5. В случае использования виртуального VASA provider, следует убедиться, что он не находится на том же массиве и в том, что он не может на него мигрировать. Виртуальную машину необходимо защитить механизмом HA, чтобы повысить ее доступность, а также осуществлять резервное копирование;
6. Не храните vCenter Server на хранилище, задействованном под vVols, чтобы избежать цикличных зависимостей;
7. Если vVols подключаются по iSCSI, следует соблюдать наилучшие практики по работе vSphere с iSCSI:
   1. Использовать port binding, когда это возможно;
   2. Избегать конфигураций, при которой трафик iSCSI будет маршрутизироваться от хоста до хранилища;
   3. Выделить отдельный VLAN и подсеть для общения хостов, и хранилища;
   4. Использовать избыточное количество сетевых интерфейсов;
   5. Если нет возможности вынести iSCSI трафик на отдельные сетевые интерфейсы, следует убедиться, что пропускной способности сети будет достаточно как для работы iSCSI, так и для других сервисов и виртуальных машин.
8. Производительность vVols сильно зависит от пропускной способности между хостом ESXi, VASA провайдером и системой хранения данных. Для наилучшей производительности следует разделить трафик ввода\вывода и траффик управления, при этом пропускная способность канала связи не должна быть ниже 10Gb/s.

vVols Workload Performance

vVols Management Operation Performance

Скорость выполнения некоторых операций при использовании vVols отличается от скорости выполнения этих же операций при использовании «классических» NFS или VMFS.

Например, операции клонирования выполняются быстрее, в то время как операции удаления – медленней.

Скорость миграции между двумя хранилищами vVols быстрее, чем между двумя не-vVols хранилищами.

Производительность vVols при работе со снимками (snapshots) может быть медленней при операции создания, в то время, как удаление снимков перекладывается непосредственно на СХД и происходит быстрее.

vVols I/O Operation Performance

1. Поскольку путь прохождения операций ввода-вывода при использовании vVols практически идентичен классической реализации, показатели пропускной способности и задержки будут так же идентичными;
2. Операции ввода-вывода в vVols осуществляются через так называемые Protocol Endpoints (PEs). Поставщики СХД могут предоставлять рекомендации по конфигурированию PE и определению их количества в зависимости от используемого массива;
3. Поскольку функционал Snapshots перекладывается на систему хранения данных, снапшоты в vVols обычно сопоставимы со снапшотами на уровне LUN в системе хранения. В связи с этим производительность виртуальных машин в vVols со снапшотами, обычно, сильно не деградирует, а удаление снимков происходит значительно быстрее.

vVols Configuration Recommendations

1. Поскольку при использовании vVols каждый диск виртуальной машины хранится как отдельный виртуальный том с данными, становится возможным использовать Storage Policy Based Management (SPBM) для каждого виртуального диска в отдельности, что позволяет оптимизировать производительность каждого из них. Например, можно активировать дедупликацию только для системного диска и не использовать ее на диске, где хранятся изображения;
2. vVols storage containers – это не физические объекты на системе хранения. Это скорее выделенная квота на определённые типы хранения с определенными свойствами;
3. Одно из преимуществ vVols – это использование всеми хостами одного или двух Protocol Endpoints. Это означает то, что в отличии от добавления новых LUNs, что потребует SCSI rescan, при добавлении новых виртуальных томов, повторное сканирование не требуется, поскольку PE будет уже доступен. Так же это позволяет увеличить скорость загрузки хостов, за счет снижения количества LUNs, которые необходимо инициализировать на этапе загрузки.

VMware vCenter Single Sign-On Server

Начиная с vSphere 7.0, VMware изменила рекомендованные механизмы аутентификации. Active Directory Federation Services (ADFS) является предпочтительным методом, за ним следует AD over LDAP. Integrated Windows Authentication (IWA) поддерживается, но является устаревшим методом.

При использовании ADFS следует убедиться, что сеть до OpenID Connect (OIDC) стабильна.

При использовании AD over LDAP или IWA следует придерживаться следующих рекомендаций:

1. Производительность SSO напрямую зависит от производительности от Identity Source;
2. С целью уменьшения времени поиска, следует ограничить число Identity Sources в SSO. В идеале указать только основной и резервный для каждого домена;
3. При подключении Identity Sources в Single Sign-On Server, указание параметра Base DN for Users и Base DN for Groups, может значительно улучшить производительность при операции поиска, особенно в больших инфраструктурах.

Стоит минимизировать количество автоматических, либо заскриптованных входов в систему. Это снимет нагрузку на vCenter Server и ускоряет работу скриптов.

1. Когда возможно, следует использовать существующие сессии и токены;
2. Необходимо проводить аудит подключений к vCenter и определить, все ли подключения необходимы или актуальны на текущий момент. Следует обращать внимание на количество подобных подключений. Возможно их больше, чем требуется. Быть моет это скрипт, который уже давно не нужен, но все еще работает. А может быть систем пытается подключиться с учетной записью, которая уже давно неактивна;
3. Программное обеспечение для резервного копирования должно подключаться только при необходимости.

VMware vSphere Content Library

Content Library позволяет администраторам vSphere управлять образами виртуальных машин, vApp, ISO, а так же скриптами.

При работе с Content Library следует придерживаться дальнейших рекомендаций:

1. Для наилучшей производительности при синхронизации файлов и образов, а также для снижения нагрузки на сервера vCenter, следует подумать об использовании Enhanced Linked Mode (ELM). При использовании ELM, файлы, хранящиеся на хранилищах ESXi передаются непосредственно между хостами, не используя при этом vCenter;
2. Размещать Content Library стоит на хранилище, которое поддерживает vSphere APIs for Array Integration (VAAI). Это позволяет задействовать функционал VAAI, например, при развертывании виртуальных машин из шаблонов, что в свою очередь перекладывает часть операций по клонированию на СХД;
3. Mirror Server может помочь с кэшированием, в случае если удаленные сервера vCenter часто синхронизируют контент через WAN;
4. Параметр Maximum Bandwidth Consumption позволяет ограничить пропускную способность для всех операций в Content Library;
5. Так же имеется два параметра, позволяющих управлять максимальным количеством сессий. Library Maximum Concurrent Sync Items – максимальное количество потоков, которые можно использовать для синхронизации всех Subscribed Content Library. Maximum Number of Concurrent Transfers – максимальное количество одновременно передаваемых файлов в Content Library. Включает в себя синхронизацию, загрузку и выгрузку, копирование, развертывание VM из шаблонов OVF и т.п. В случае, если сетевая производительность CL ниже, чем ожидается, изменение этих параметров в большую сторону может помочь.