На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):
Итак, для первого тестирования использовалась следующая конфигурация:
В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.
Масштабируемость производительности под нагрузкой (OPM - это orders per minute):
Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):
Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:
Теперь обратимся ко второму исследованию. Там использовалась следующая тестовая конфигурация, выдающая 1 миллион IOPS на тестах:
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers
Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):
Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).
Второй тест - 60% операций чтения и 40% операций записи:
Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.
Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.
С приходом Нового года в продукте VMware vCenter, входящем в состав vSphere 5.1, была обнаружена ошибка, следствием которой является отображение за прошедший год статистик производительности (Performance history) только за последние 30 дней (декабрь).
Данная ошибка является следствием недоработок в хранимых процедурах БД vCenter Server, что приводит к удалению (purge) объектов базы данных, касающихся производительности. Исправления ошибки и никакого workaround'а пока нет.
С одной стороны, эти данные не являются критичными и, зачастую, не используются администраторами, однако различные продукты, которые используют исторические данные для анализа и планирования мощностей инфраструктуры виртуализации (Capacity Planning), не смогут уже выполнять свои функции адекватно.
Для получения информации об исправлении ошибки можно подписаться на KB 2042164.
Не так давно мы писали про то, как работает механизм динамического выравнивания нагрузки на виртуальные хранилища VMware Storage DRS. Напомним, что он работает на базе 2-х параметров хранилищ:
Заполненность - в этом случае SDRS выравнивает виртуальные машины для равномерного заполнения хранилищ.
Производительность - при использовании этих метрик SDRS старается динамически перенести виртуальные машины с более нагруженных по параметрам ввода-вывода хранилищ на менее загруженные.
Однако бывает так, что несколько виртуальных хранилищ (Datastores) располагаются на одних и тех же RAID-группах, а значит миграция хранилищ виртуальных машин между ними ничего не даст - суммарно бэкэнд-диски системы хранения будут испытывать ту же самую нагрузку.
Например, бесполезна (с точки зрения производительности) будет миграция с Datastore1 на Datastore2:
Раньше этот факт не учитывался механизмом SDRS в vSphere 5.0, что приводило к бесполезным миграциям в автоматическом режиме. Теперь ситуация изменилась к лучшему в версии vSphere 5.1.
Как многие знают, в VMware vSphere есть механизм Storage IO Control (SIOC), который позволяет измерять мгновенную производительность хранилищ (параметр latency - задержка команд ввода-вывода) и регулировать очередь HBA-адаптеров на хостах ESXi. Так вот, одна из техник SIOC Injection позволяет производить тестирование виртуальных хранилищ на наличие корреляции производительности между ними.
Делается это следующим образом: SIOC запускает тестовую рабочую нагрузку на случайно выбранном Datastore1, измеряет latency, а потом отдельно от него запускает нагрузку на другом Datastore2 и также смотрит на latency:
Это нужно для установления базового уровня производительности для этих виртуальных хранилищ. Потом SIOC запускает нагрузку одновременно на 2 этих хранилища и смотрит, что происходит с latency:
Если оба этих хранилища физических расположены на одних и тех же дисковых устройствах (как в нашем случае), то измеряемые latency в данном случае возрастут, что говорит о взаимной корреляции данных хранилищ в плане производительности.
Узнав про этот факт, Storage DRS не будет генерировать рекомендации по перемещению виртуальных машин между хранилищами Datastore1 и Datastore2:
Однако эти рекомендации перестанут генерироваться только на базе производительности, на базе заполненности хранилищ такие рекомендации останутся.
Достаточно давно, известный многим Duncan Epping писал о стартапе CloudPhysics, для которого он является техническим эдвайзором, и который выпускает продукт в виде виртуального модуля (Observer Virtual Appliance), систематизирующий информацию о количественных параметрах виртуальной среды VMware vSphere в виде карточек. На основе этих карточек можно составить заключение о существующих проблемах своей инфраструктуры виртуализации:
Для работы продукта потребуется установить OVA-модуль в своем окружении VMware vSphere, а дальше для просмотра параметров карточек можно использовать веб-консоль (для кого-то это может быть проблемой, так как данные посылаются на сервер CloudPhysics, однако они утверждают, что данные полностью обезличены).
Сами карточки формируются на базе опросов пользователей и всяческих голосований, которые проводятся, например, на конференциях VMworld. Вот примеры таких карточек:
Затем лучшие карточки, будучи реализованными технически, попадают в основной интерфейс продукта (при этом для появления новых карточек не обязательно обновлять виртуальный модуль в своей инсталляции).
Помимо этого есть всякие технические детали о виртуальной инфраструктуре, корелляции параметров и необычные метрики. В общем, для больших инсталляций в плане траблшутинга - штука интересная, попробуйте, это пока бесплатно.
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: 2 x Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: 5 x QLA2532
Storage: 2 x Violin Memory 6616 Flash Memory Arrays
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Config: 4K IO size w/ 16 workers
Напомним, что на прошлом VMworld 2011 также была показана производительность в 1 миллион IOPS (300 000 для одной машины), но для хост-сервера VMware ESXi (суммарно от нескольких виртуальных машин).
Также из любопытных фактов, озвученных на VMworld 2012:
60% серверов уже являются виртуальными, VMware стремится к показателю 90% и более.
Число сертифицированных специалистов VMware VCP достигло 125 тысяч.
В VMworld 2012 приняли участие 20 000 специалистов.
Основная концепция на ближайшее будущее - "Software-defined data center" (по аналогии с приобретенной недавно концепцией компании Nicira - Software-defined networking). Предполагается, что ключевые позиции в этой концепции займут продукты VMware vSphere, vCloud Director, vCloud Connector, Site Recovery Manager, vCenter Operations и vFabric Application Director.
Больше об облачных инициативах VMware - в самое ближайшее время.
Если мы запустим утилиту esxtop, то увидим следующие столбцы (интересующее нас выделено красным):
Нас интересует 5 счетчиков, касающиеся процессоров виртуальных машин, с помощью которых мы сможем сделать выводы об их производительности. Рассмотрим их подробнее:
Счетчик %RUN
Этот счетчик отображает процент времени, в течение которого виртуальная машина исполнялась в системе. Когда этот счетчик для ВМ около нуля или принимает небольшие значение - то с производительностью процессора все в порядке (при большом его значении для idle). Однако бывает так, что он небольшой, а виртуальная машина тормозит. Это значит, что она заблокирована планировщиком ESXi или ей не выделяется процессорного времени в связи с острой нехваткой процессорных ресурсов на сервере ESXi. В этом случае надо смотреть на другие счетчики (%WAIT, %RDY и %CSTP).
Если значение данного счетчика равно <Число vCPU машины> x 100%, это значит, что в гостевой ОС виртуальной машины процессы загрузили все доступные процессорные ресурсы ее vCPU. То есть необходимо зайти внутрь ВМ и исследовать проблему.
Счетчики %WAIT и %VMWAIT
Счетчик %WAIT отображает процент времени, которое виртуальная машина ждала, пока ядро ESXi (VMkernel) выполняло какие-то операции, перед тем, как она смогла продолжить выполнение операций. Если значение этого счетчика значительно больше значений %RUN, %RDY и %CSTP, это значит, что виртуальная машина дожидается окончания какой-то операции в VMkernel, например, ввода-вывода с хранилищем. В этом случае значение счетчика %SYS, показывающего загрузку системных ресурсов хоста ESXi, будет значительно выше значения %RUN.
Когда вы видите высокое значение данного счетчика, это значит, что нужно посмотреть на производительность хранилища виртуальной машины, а также на остальные периферийные устройства виртуального "железа". Зачастую, примонтированный ISO-образ, которого больше нет на хранилище, вызывает высокое значение счетчика. Это же касается примонтированных USB-флешек и других устройств ВМ.
Не надо пугаться высокого значения %WAIT, так как оно включает в себя счетчик %IDLE, который отображает простой виртуальной машины. А вот значение счетчика %VMWAIT - уже более реальная метрика, так как не включает в себя %IDLE, но включает счетчик %SWPWT (виртуальная машина ждет, пока засвопированные таблицы будут прочитаны с диска; возможная причина - memory overcommitment). Таким образом, нужно обращать внимание на счетчик %VMWAIT. К тому же, счетчик %WAIT представляет собой сумму метрик различных сущностей процесса виртуальной машины:
Счетчик %RDY
Главный счетчик производительности процессора. Означает, что виртуальная машина (гостевая ОС) готова исполнять команды на процессоре (ready to run), но ожидает в очереди, пока процессоры сервера ESXi заняты другой задачей (например, другой ВМ). Является суммой значений %RDY для всех отдельных виртуальных процессоров ВМ (vCPU). Обращать внимание на него надо, когда он превышает пороговое значение 10%.
По сути, есть две причины, по которым данный счетчик может зашкаливать приведенное пороговое значение:
сильная нагрузка на физические процессоры из-за большого количества виртуальных машин и нагрузок в них (здесь просто надо уменьшать нагрузку)
большое количество vCPU у конкретной машины. Ведь виртуальные процессоры машин на VMware ESX работают так: если у виртуальной машины 4 vCPU, а на хосте всего 2 физических pCPU, то одна распараллеленная операция (средствами ОС) будет исполняться за в два раза дольший срок. Естественно, 4 и более vCPU для виртуальной машины может привести к существенным задержкам в гостевой ОС и высокому значению CPU Ready. Кроме того, в некоторых случаях нужен co-sheduling нескольких виртуальных vCPU (см. комментарии к статье), когда должны быть свободны столько же pCPU, это, соответственно, тоже вызывает задержки (с каждым vCPU ассоциирован pCPU). В этом случае необходимо смотреть значение счетчика %CSTP
Кроме того, значение счетчика %RDY может быть высоким при установленном значении CPU Limit в настройках виртуальной машины или пула ресурсов (в этом случае посмотрите счетчик %MLMTD, который при значении больше 0, скорее всего, говорит о достижении лимита). Также посмотрите вот этот документ VMware.
Счетчик %CSTP
Этот счетчик отображает процент времени, когда виртуальная машина готова исполнять команды, одна вынуждена ждать освобождения нескольких vCPU при использовании vSMP для одновременного исполнения операций. Например, когда на хосте ESXi много виртуальных машин с четырьмя vCPU, а на самом хосте всего 4 pCPU могут возникать такие ситуации с простоем виртуальных машин для ожидания освобождения процессоров. В этом случае надо либо перенести машины на другие хосты ESXi, либо уменьшить у них число vCPU.
В итоге мы получаем следующую формулу (она верна для одного из World ID одной виртуальной машины)
%WAIT + %RDY + %CSTP + %RUN = 100%
То есть, виртуальная машина либо простаивает и ждет сервер ESXi (%WAIT), либо готова исполнять команды, но процессор занят (%RDY), либо ожидает освобождения нескольких процессоров одновременно (%CSTP), либо, собственно, исполняется (%RUN).
Таги: VMware, vSphere, esxtop, ESXi, VMachines, Performance, CPU
Как известно, виртуализация требует дополнительных ресурсов сверх тех, которые потребляет непосредственно виртуальная машина. Это называют накладными расходами на виртуализацию (так называемый virtualization overhead). Оверхэд есть как для процессора (примерно 3-5 процентов на хост-сервере), так и для оперативной памяти.
При этом для оперативной памяти накладные расходы гипервизора зависят от количества виртуальных процессоров (vCPU) и объема оперативной памяти, выделенных виртуальной машине. Мы уже писали о накладных расходах по RAM для виртуальных машин в VMware vSphere 4, где использовались следующие средние значения:
В VMware vSphere 5 есть новая возможность, которая называется VMX Swap. При включении виртуальной машины гипервизор ESXi создает для нее vmx-процесс, управляющий различными структурами данных, под которые требуется физическая оперативная память. Ее объем, как было сказано, зависит от конфигурации ВМ - количества vCPU и RAM. Для снижения потребления этой памяти в ESXi 5.0 механизм VMX Swap создает swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте.
VMX Swap создает файлы подкачки в директории с виртуальной машиной, через который и происходит загрузка и выгрузка страниц процесса vmx. Размещение этих файлов можно переопределить, добавив следующий параметр в расширенные настройки виртуальной машины:
sched.swap.vmxSwapDir
По умолчанию механизм VMX Swap включен и в критических ситуациях позволяет уменьшить overhead типичной виртуальной машины с 50 МБ до 10 МБ. Для виртуализации серверов такие порядки цифр может и не очень важны, зато для виртуализации настольных ПК (например, VMware View), где на одном сервере могут находиться десятки и даже сотни виртуальных машин, эта возможность может оказаться весьма кстати в условиях нехватки вычислительных ресурсов.
Если вы считаете, что ресурсов у вас достаточно и VMX Swap вам не нужен, можно его отключить, добавив значение FALSE в следующу расширенную настройку виртуальной машины:
sched.swap.vmxSwapEnabled
Ну а теперь посмотрим сколько оверхэда по памяти потребляет виртуальная машина уже в VMware vSphere 5 с включенным по умолчанию VMX Swap:
Эта информация уже из vSphere 5 Documentation Center. Как мы видим из таблицы, накладные расходы по памяти с учетом VMX Swap уже значительно меньше (в некоторых случаях до 8-9 раз). Как уверяют коллеги из VMware, в условиях недостатка ресурсов VMX Swap почти не влияет на производительность хост-сервера ESXi, ну а в условиях достатка - не влияет совсем.
На сайте Фрэнка Деннемана появилась отличная статья про механизмы "горячей" миграции хранилищ (Storage vMotion) и "горячей" миграции виртуальных машин (vMotion) в контексте их использования для одного хранилища (Datastore) или хоста ESXi в VMware vSphere. Мы просто не можем не перевести ее, так как она представляет большой интерес для понимания работы этих механизмов.
Начнем со Storage vMotion. Данная операция, очевидно, требует большой нагрузки как на хранилище, откуда и куда, переносятся виртуальные машины, так и на сам хост-сервер VMware ESXi. Особенно актуально это, когда хост или хранилище переходят в Maintenance Mode, и виртуальные машины массово начинают миграцию. В случае со Storage vMotion это создает колоссальную нагрузку на хранилище по вводу-выводу.
Для понимания затрат ресурсов на эти процессы Фрэнк вводит понятие "цены" (cost) начинающейся операции, которая не может превосходить количество доступных слотов на хосте или хранилище, выделенных под них. Наглядно это можно представить так:
Resource Max Cost - это максимальный объем в неких единицах (назовем их слотами), который находится в рамках пула доступных ресурсов для операции Storage vMotion. Для хоста ESXi емкость такого пула составляет 8 слотов, а цена операции Storage vMotion - 4 слота. Таким образом, на одном хосте ESXi могут одновременно выполняться не более 2-х операций Storage vMotion. Если выполняется одна операция - то занято 4 слота и 4 слота свободно (как для исходного, так и для целевого хранилища).
С хранилищем точно такая же система - но у него 128 слотов. Одна операция Storage vMotion для Datastore потребляет 16 слотов. Таким образом, на одном хранилище может выполняться 8 (128 / 16) одновременных операций Storage vMotion. Их могут инициировать, например, 4 хоста (по 2 операции максимально каждый). То есть, мы получаем следующую схему:
Все просто и понятно. Отметим здесь, что операция vMotion тоже потребляет ресурсы с Datastore - но всего 1 слот. Таким образом, на одном Datastore могут, например, выполняться 7 одновременных миграций Storage vMotion (7 * 16 = 112 слотов) и еще 16 миграций vMotion (112+16 = 128), задействующих ВМ этого Datastore.
Если вы не хотите, чтобы при переводе Datastore в Maintenance Mode на нем возникало сразу 8 одновременных миграций Storage vMotion и, как следствие, большой нагрузки, вы можете уменьшить пул слотов для хранилищ (для всех, а не для какого-то конкретно). Для этого нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:
Вбив значение 112, вы уменьшите максимальное число одновременных миграций Storage vMotion на Datastore до 7. На хосте ESXi менять размер пула слотов для Storage vMotion не рекомендуется (хотя такие секции можно добавить - это пробовали энтузиасты).
Про стоимость миграций vMotion для хостов ESX / ESXi 4.1 мы уже писали вот тут. На эту тему есть также статья KB 2001417. С тех пор в vMotion много чего изменилось, поэтому подтвердить актуальность для vSphere 5 пока не могу. Буду признателен, если вы напишете об этом в комментариях.
Не так давно мы упоминали о результатах тестирования решения для виртуализации настольных ПК предприятия VMware View 5, проведенного компанией Principled Technologies по поручению компании VMware. Продукт VMware View 5 в нем сравнивался с конкурирующим решением Citrix XenDesktop 5.5, при этом ПО от VMware выигрывало в производительности аналогу от Citrix для типовой нагрузки во многих категориях тестов.
VMware View 5 Performed better than or equal to Citrix XenDesktop 5.5 with equivalent settings on Login VSI workloads simulating common office applications
Посыл данного заголовка понятен - VMware View производительнее и круче.
Титульная страница отчета выглядит следующим образом:
В компании Citrix возмутились таким положением дел: "Как так? Они тестируют XenDesktop для одного десктопа и рабочей нагрузки в сферической локальной сети и выставляют это за результат реального тестирования. Непорядок!". Тогда в Citrix решили обратиться к парням из Principled Technologies и спросили "Что за дела, пацаны? Наше решение круче себя ведет, когда на предприятии сотни виртуальных ПК, доступ ко многим из них происходит через WAN-сети, да и вообще мы давно делаем продукт и свой протокол ICA/HDX, поэтому так быть не должно!".
Сообразительные ребята из Principled Technologies почесали репу и говорят: "А давайте мы вам сделаем тоже отчет! Там как раз про все это будет: и про WAN, и про то, что у вас есть технологии всякие оптимизации канала, и про все остальные ваши навороты". Citrix сказал: "А давайте!". И получился еще один документ, уже от апреля 2012 года, являющийся также результатом тестирования продуктов, но уже по заказу Citrix, с красивым заголовком:
Citrix XenDektop Provided a better remote user experience via WAN vs. VMware View 5
Видимо за прошлое исследование парням из Principled Technologies было немного стыдно, поэтому "vs. VMware View 5" они написали мелким шрифтом:
Посыл этого документа тоже понятен - Citrix круче VMware (причем если почитать, то даже если настроить View по Optimization Guide). Поэтому пользователям предлагается поломать голову над текстом и картинками обох исследований, которые радуют глаз своими разными подходами к оценке продуктов.
Посмотрим на графики первого исследования (по заказу VMware - справедливости ради отметим, что с Flash Redirection показан лучше XenDesktop):
Взглянем на второй документ (по заказу Citrix):
В итоге, что мы имеем: одна контора подготовила для двух конкурирующих вендоров отчеты, которые по-разному формируют отношение к их продуктам. Надо полагать, за это были заплачены деньги, ведь делаются такие вещи небесплатно. Поэтому все это напоминает один старинный анекдот. Ну а чуваки из PT свое получили.
Теперь мы ждем очередного задания для Principled Technologies, уже от VMware, в котором мы узнаем, почему же все-таки нужно использовать VMware при доступе через WAN. Непорядок же...
Как мы уже писали в одной из статей, в VMware vSphere 5 при работе виртуальных машин с хранилищами могут возникать 2 похожих по признакам ситуации:
APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. При этом хост не знает, в течение какого времени будет сохраняться такая ситуация. Типичный пример - отказ FC-коммутаторов в фабрике или выход из строя устройства хранения. В этом случае хост ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути. В этом случае демон hostd будет постоянно блокироваться, что будет негативно влиять на производительность. Этот статус считается временным, так как устройство хранения или фабрика могут снова начать работать, и работа с устройством возобновится.
В логе /var/log/vmkernel.log ситуация APD выглядит подобным образом:
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_IssueCommandToDevice:2954:I/O could not be issued to device "naa.60a98000572d54724a34642d71325763" due to Not found
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceRetryCommand:133:Device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...
Ключевые слова здесь: retry, awaiting. Когда вы перезапустите management agents, то получите такую вот ошибку:
Not all VMFS volumes were updated; the error encountered was 'No connection'.
Errors:
Rescan complete, however some dead paths were not removed because they were in use by the system. Please use the 'storage core device world list' command to see the VMkernel worlds still using these paths.
Error while scanning interfaces, unable to continue. Error was Not all VMFS volumes were updated; the error encountered was 'No connection'.
В этом случае надо искать проблему в фабрике SAN или на массиве.
PDL (Permanent Device Loss) - когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет (понятно, что в случае APD по причине свича мы такого ответа не получим). Этот статус считается постоянным, так как массив ответил, что устройства больше нет.
А вообще есть вот такая табличка для SCSI sense codes, которые вызывают PDL:
В случае статуса PDL гипервизор в ответ на запрос I/O от виртуальной машины выдает ответ VMK_PERM_DEV_LOSS и не блокирует демон hostd, что, соответственно, не влияет на производительность. Отметим, что как в случае APD, так и в случае PDL, виртуальная машина не знает, что там произошло с хранилищем, и продолжает пытаться выполнять команды ввода-вывода.
Такое разделение статусов в vSphere 5 позволило решить множество проблем, например, в случае PDL хост-серверу больше не нужно постоянно пытаться восстановить пути, а пользователь может удалить сломавшееся устройство с помощью операций detach и unmount в интерфейсе vSphere Client (в случае так называемого "Unplanned PDL"):
В логе /var/log/vmkernel.log ситуация PDL (в случае Unplanned PDL) выглядит подобным образом:
2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba3:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba4:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: vmw_psp_rr: psp_rrSelectPathToActivate:972:Could not select path for device "naa.60a98000572d54724a34642d71325763".
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: ScsiDevice: 1223: Device :naa.60a98000572d54724a34642d71325763 has been removed or is permanently inaccessible.
2011-08-09T10:43:26.857Z cpu3:2132)ScsiDeviceIO: 2288: Cmd(0x4124403c1fc0) 0x9e, CmdSN 0xec86 to dev "naa.60a98000572d54724a34642d71325763" failed H:0x8 D:0x0 P:0x0
2011-08-09T10:43:26.858Z cpu3:2132)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-08-09T10:43:26.858Z cpu2:2127)ScsiDeviceIO: 2316: Cmd(0x4124403c1fc0) 0x25, CmdSN 0xecab to dev "naa.60a98000572d54724a34642d71325763" failed H:0x1 D:0x0 P:0x0 Possible sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.858Z cpu2:854568)WARNING: ScsiDeviceIO: 7330: READ CAPACITY on device "naa.60a98000572d54724a34642d71325763" from Plugin "NMP" failed. I/O error
2011-08-09T10:43:26.858Z cpu2:854568)ScsiDevice: 1238: Permanently inaccessible device :naa.60a98000572d54724a34642d71325763 has no more open connections. It is now safe to unmount datastores (if any) and delete the device.
2011-08-09T10:43:26.859Z cpu3:854577)WARNING: NMP: nmpDeviceAttemptFailover:562:Retry world restore device "naa.60a98000572d54724a34642d71325763" - no more commands to retry
Ключевое слово здесь - permanently.
Становится понятно, что в случае, когда устройство хранения (LUN) реально сломалось или удалено сознательно, лучше всего избежать ситуации APD и попасть в статус PDL. Сделать это удается хост-серверу ESXi не всегда - по прежнему в vSphere 5.0 Update 1 это обрабатывается в ограниченном количестве случаев, но в vSphere 5.1 обещают существенно доработать этот механизм.
Также есть Advanced Settings на хосте ESXi, которые позволяют управлять дальнейшей судьбой машины, которая оказалась жертвой ситуации PDL. В частности есть 2 следующие расширенные настройки (начиная с vSphere 5.0 Update 1) - первая в категории "Disk", а вторая в расширенных настройках кластера HA:
disk.terminateVMonPDLDefault - если эта настройка включена (True), то в ситуации PDL для устройства, где находится ВМ, эта машина будет выключена. Настройка задается на уровне хоста ESXi и требует его перезагрузки для ее применения.
das.maskCleanShutdownEnabled - это настройка, будучи включенной (True), позволяет механизму VMware HA приступить к восстановлению виртуальной машины. Соответственно, если она выключена, то HA проигнорирует выключение виртуальной машины в случае ее "убийства" при включенной первой настройке.
Рекомендуется, чтобы обе эти настройки были включены.
Все описанные выше механизмы могут очень пригодиться при построении и обработке сбоев в "растянутых кластерах" VMware HA, построенных между географически разнесенными датацентрами. Об этом всем детально написано в документе "VMware vSphere Metro Storage Cluster Case Study".
Таги: VMware, vSphere, Storage, Performance, Troubleshooting, HA, ESXi
Мы уже писали о новых возможностях VMware View 5.1 и, в частности, о технологии Storage Accelerator, которая использует кэш CBRC на чтение на стороне хоста VMware ESXi, чтобы быстрее отдавать блоки виртуальной машине напрямую из памяти, не обращаясь к хранилищу.
Как понятно из названия (Content Based Read Cache), технология Storage Accelerator позволяет оптимизировать ввод-вывод именно тогда, когда в среде виртуальных ПК у нас много операций чтения, которые происходят для множества связанных клонов, развертываемых из реплики View Compser. Таких показательных ситуаций две: Boot Storm (когда пользователи приходят на работу и одновременно включают свои ПК для доступа к своим виртуальным машинам) и Antivirus Storm (когда антивирус начинает шерстить файлы в гостевой ОС).
Интересные картинки по тестированию данной технологии обнаружились в одном из тестов Login VSI, которая проверила, как это работает на хосте со 143-мя связанными клонами виртуальных ПК для размера кэша CBRC размером в 2 ГБ. Работает это замечательно:
Как мы видим, к сотой минуте нагрузка улеглась и операции чтения стали уже не такими однородными. Для постоянных (persistent) дисков (т.е. тех, которые не развертываются из единого базового образа) технология CBRC тоже дает свои плоды:
Ну и здорово помогает нам View Storage Accelerator при антивирусном шторме, когда антивирусники большого количества виртуальных машин одновременно набрасываются на файлы гостевых ОС:
Ну и под конец напомним, что в качестве антивирусных решений в VDI-средах для оптимизации нагрузки нужно использовать решения с поддержкой VMsafe.
Мы уже недавно писали о метриках производительности хранилищ в среде VMware vSphere, которые можно получить с помощью команды esxtop. Сегодня мы продолжим развивать эту тему и поговорим об общей производительности дисковых устройств и сайзинге нагрузок виртуальных машин по хранилищам в виртуальной среде.
Как говорит нам вторая статья блога VMware о хранилищах, есть несколько причин, по которым может падать производительность подсистемы ввода-вывода виртуальных машин:
Неправильный сайзинг хранилищ для задач ВМ, вследствие чего хранилища не выдерживают такого количества операций, и все начинает тормозить. Это самый частый случай.
Перегрузка очереди ввода-вывода со стороны хост-сервера.
Достижение предела полосы пропускания между хостом и хранилищем.
Высокая загрузка CPU хост-сервера.
Проблемы с драйверами хранилищ на уровне гостевой ОС.
Некорректно настроенные приложения.
Из всего этого набора причин самой актуальной оказывается, как правило, первая. Это происходит вследствие того, что администраторы очень часто делают сайзинг хранилищ для задач в ВМ, учитывая их требования только к занимаемому пространству, но не учитывая реальных требований систем к вводу выводу. Это верно в Enterprise-среде, когда у вас есть хранилища вроде HDS VSP с практически "несъедаемой" производительностью, но неверно для Low и Midrange массивов в небольших организациях.
Поэтому профилирование нагрузки по хранилищам - одна из основных задач администраторов VMware vSphere. Здесь VMware предлагает описывать модель нагрузки прикладной системы следующими параметрами:
Размер запроса ввода-вывода (I/O Size)
Процент обращений на чтение (Read)
Процент случайных обращений (Random)
Таким образом профиль приложения для "типичной" нагрузки может выглядеть наподобие:
8KB I/O size, 80% Random, 80% Read
Само собой, для каждого приложения типа Exchange или СУБД может быть свой профиль нагрузки, отличающийся от типичного. Размер запроса ввода-вывода (I/O Size) также зависит от специфики приложения, и о том, как регулировать его максимальное значение на уровне гипервизора ESXi, рассказано в KB 1008205. Нужно просто в Advanced Settings выставить значение Disk.DiskMaxIOSize (значение в килобайтах). Некоторые массивы испытывают проблемы с производительностью, когда размер запроса ввода-вывода очень велик, поэтому здесь нужно обратиться к документации производителя массива. Если с помощью указанной настройки ограничить размер запроса ввода-вывода, то они будут разбиваться на маленькие подзапросы, что может привести к увеличению производительности подсистемы ввода-вывода на некоторых системах хранения. По умолчанию установлено максимальное значение в 32 МБ, что является достаточно большим (некоторые массивы начинают испытывать проблемы при запросах более 128 KB, 256 KB или 512KB, в зависимости от модели и конфигурации).
Однако вернемся к профилированию нагрузок по хранилищам в VMware vSphere. В одной из презентаций VMware есть замечательная картинка, отражающая численные характеристики производительности дисковых устройств в пересчете на шпиндель в зависимости от типа их организации в RAID-массивы:
Параметры в верхней части приведены для операций 100%-й последовательной записи для дисков на 15К оборотов. А в нижней части приведены параметры производительности для описанной выше "типичной" нагрузки, включая среднюю скорость чтения-записи, число операций ввода-вывода в секунду (IOPS) и среднюю задержку. Хорошая напоминалка, между прочим.
Теперь как анализировать нагрузку по вводу выводу. Для этого у VMware на сайте проекта VMware Labs есть специальная утилита I/O Analyzer, про которую мы уже писали вот тут. Она может многое из того, что потребуется для профилирования нагрузок по хранилищам.
Ну а дальше стандартные процедуры - балансировка нагрузки по путям, сторадж-процессорам (SP) и дисковым устройствам. Сигналом к изысканиям должен послужить счетчик Device Latency (DAVG) в esxtop, если его значение превышает 20-30 мс для виртуальной машины.
Мы уже писали об основных приемах по решению проблем на хостах VMware ESX / ESXi с помощью утилиты esxtop, позволяющей отслеживать все аспекты производительности серверов и виртуальных машин. Через интерфейс RCLI можно удаленно получать эти же данные с помощью команды resxtop.
Сегодня мы приведем простое объяснение иерархии счетчиков esxtop, касающихся хранилищ серверов VMware vSphere. Для того, чтобы взглянуть на основные счетчики esxtop для хранилищ, нужно запустить утилиту и нажать кнопку <d> для перехода в режим отслеживания показателей конкретных виртуальных машин (кликабельно). Данные значения будут представлены в миллисекундах (ms):
Если мы посмотрим на колонки, которые выделены красным прямоугольником, то в виде иерархии их структуру можно представить следующим образом:
Распишем их назначение:
GAVG (Guest Average Latency) - общая задержка при выполнении SCSI-команд от гостевой ОС до хранилища сквозь все уровни работы машины с блоками данных. Это, само собой, самое большое значение, равное KAVG+DAVG.
KAVG (Kernel Average Latency) - это задержка, возникающая в стеке vSphere для работы с хранилищами (гипервизор, модули для работы SCSI). Это обычно небольшое значение, т.к. ESXi имеет множество оптимизаций в этих компонентах для скорейшего прохождения команд ввода-вывода сквозь них.
QAVG (Queue Average latency) - время, проведенное SCSI-командой в очереди на уровне стека работы с хранилищами, до передачи этой команды HBA-адаптеру.
DAVG (Device Average Latency) - задержка прохождения команд от HBA адаптера до физических блоков данных на дисковых устройствах.
В блоге VMware, где разобраны эти показатели, приведены параметры для типичной нагрузки по вводу-выводу (8k I/O size, 80% Random, 80% Read). Для такой нагрузки показатель Latency (GAVG) 20-30 миллисекунд и более может свидетельствовать о наличии проблем с производительностью подсистемы хранения на каком-то из подуровней.
Как мы уже отметили, показатель KAVG, в идеале, должен быть равен 0 или исчисляться сотыми долями миллисекунды. Если он стабильно находится в пределах 2-3 мс или больше - тут уже можно подозревать проблемы. В этом случае нужно проверить значение столбца QUED для ВМ - если оно достигло 1 (очередь использована), то, возможно, выставлена слишком маленькая величина очереди на HBA-адаптере, и необходимо ее увеличить.
Для просмотра очереди на HBA-адаптере нужно переключиться в представление HBA кнопкой <u>:
Ну и если у вас наблюдается большое значение DAVG, то дело, скорее всего, не в хосте ESX, а в SAN-фабрике или дисковом массиве, на уровне которых возникают большие задержки.
Мы уже писали о новых возможностях VMware View 5.1 и новых клиентах, а сегодня поговорим о производительности этого решения для виртуализации настольных ПК предприятия. Прежде всего, напомним 2 основных документа, откуда можно узнать о том, какие техники использует VMware View и в каких моментах превосходит Citrix XenDesktop:
Теперь VMware View 5.1 идет еще дальше по сравнению с версией 5.0:
1. Появилась функция VMware View Storage Accelerator
Этот механизм позволяет использовать оперативную память сервера для кэширования наиболее часто используемых блоков данных виртуальных ПК, запрашиваемых с конечного устройства. Делается это средствами технологии Content Based Read Cache (CBRC), поддержка которой уже имеется в VMware vSphere 5.0. Эта штука, само собой, положительно влияет на скорость обмена данными с конечными устройствами и производительность операций ввода-вывода для виртуальных ПК, поскольку блоки запрашиваются напрямую из памяти хост-сервера:
Этот тест проводился для 50 виртуальных ПК с гостевой ОС Windows 7 и были достигнуты следующие результаты (по сравнению с ситуацией, когда CBRC отключен):
Увеличение до 80% пиковых IOPS
Увеличение на 45% средних IOPS
Увеличение пиковой скорости обмена с ПК до 65%
Увеличение средней скорости обмена с ПК на 25%
2. Оптимизация клиентов VMware View 5.1
Со стороны клиентов, компания VMware внесла множество улучшений, большинство которых сделано для увеличения производительности воспроизведения видео. По сравнению с версией View 5.0, клиенты View 5.1 дают следующий прирост в плане видео:
При этом отметим, что улучшения были сделаны как для x86, так и для ARM-клиентов.
3. Улучшения коммуникации клиент-сервер в View 5.1.
В механизмах коммуникации клиента VMware View 5.1 с виртуальной машиной на сервере было сделано множество умных и полезных улучшений, сводящихся к тому, что клиент чаще и быстрее взаимодействует с виртуальным ПК, что приводит к приросту производительности операций перетаскивания объектов (и гладкости их прорисовки), а также скроллинга. Вот, например, как отличается прорисовка кривых по протоколам PCoIP (View 5.1) и RDP:
В общем, если и раньше были объективные причины предлагать клиентам Citrix XenDesktop по причине высокой производительности протокола Citrix HDX, то теперь их практически не осталось. С каждой новой версией видно, что VMware инвестирует в PCoIP, а XenDesktop просто стоит дороже.
Похоже, что кто-то (после 5 лет разработки) наконец додумался до того, что нужно применять виртуализацию GPU со стороны сервера, чтобы реализовывать требовательные к графике нагрузки в инфраструктуре виртуальных ПК предприятия (VDI). 15 мая компания NVIDIA анонсировала скорую доступность платформы VGX, которая представляет собой модуль с четырьмя GPU и 16 ГБ памяти, который будет устанавливаться в сервер через стандартный разъем PCI Express (2 слота).
Платформа NVIDIA VGX основана на трех сущностях:
Плата NVIDIA VGX. Она имеет четыре GPU (каждый имеет 192 ядра NVIDIA CUDA) и 16 ГБ памяти и подключается к серверам через стандартный интерфейс PCI Express. Рассчитана на количество пользователей на сервер - до 100 штук.
NVIDIA VGX GPU Hypervisor. Этот программный компонент, который интегрируется в коммерческие гипервизоры (пока говоритя почему-то о Citrix XenServer), обеспечивая поддержку виртуализации GPU со стороны хост-сервера.
NVIDIA User Selectable Machines (USM). Эта опция позволяет компаниям предоставлять графические возможности индивидуальным пользователям в соответствии с их запросами. Эти возможности варьируются от реальных возможностей ПК, доступных со стандартной NVIDIA USM, до профессиональных функций 3D дизайна и проектирования с помощью GPU NVIDIA Quadro или NVIDIA NVS.
Характеристики платы VGX:
Теперь нам обещают новый уровнеь производительности в ПО для 3D-моделирования:
Воспроизведении видео:
И Windows Aero в виртуальном ПК:
Платформа NVIDIA VGX, включая новые платы NVIDIA VGX, а также компоненты NVIDIA GPU Hypervisor и NVIDIA USM, будет доступна через OEM и VDI партнеров NVIDIA уже в этом году. Ну что - посмотрим, штука интересная, и спрос на нее определенно есть.
Интересная штука обнаружилась среди средств управления и мониторинга инфраструктуры VMware vSphere - Cloud Resource Meter от компании 6fusion, которая специализируется на утилитах для облачных сред. Это такая штука, которая реализована в виде виртуального модуля (Virtual Appliance), позволяющая оценить облачную инфраструктуру vSphere "в попугаях", то есть в специальных единицах Workload Allocation Cube (WAC), потребляемых за час. Убеждают, что алгоритм этого WAC - не хухры-мухры, а patent pending.
Этот WAC - это шестимерная сущность, представляющая собой эталонную совокупность ресурсов, потребляемых виртуальной машиной в облаке, а именно:
Вот в количестве таких шестигранных кубиков вы и увидите каждую из виртуальных машин своего (или провайдерского) датацентра в реальном времени. Предполагается, что такая модель позволит наиболее адекватно обсчитать вычислительные мощности своего ЦОД (chargeback), вести учет и планировать вычислительные мощности. Облачные провайдеры и менеджеры корпоративных датацентров могут устанавливать параметры и цену такого "вака", что позволит понимать, сколько ресурсов есть в наличии и сколько будет стоить разместить то или иное приложение в облаке.
Для каждой машины ведется исторический учет потребляемых "вакочасов":
Авторы этой программулины утверждают, что алгоритм этих "ваков" был разработан еще в 2004 году для профилирования приложений под ESX 1.0, так что может стоит и посмотреть, что они с тех пор сделали, тем более, что есть бесплатная версия продукта Cloud Resource Meter. На данный момент он, правда, находится в бете, но поддерживает vSphere 4.1 и 5.0.
В преддверии выхода новой версии платформы для виртуализации настольных ПК VMware View 5.1, о котором будет объявлено 3 мая, продолжаем рассказывать о новых возможностях этого продукта. Сегодня продолжим разговор о функции Content Based Read Cache (CBRC), которая позволяет увеличить производительность операций чтения для наиболее часто читаемых блоков виртуальных ПК.
Как мы уже писали ранее, Content Based Read Cache - это функция кэширования в оперативной памяти хоста VMware ESXi, которая уже реализована в VMware vSphere 5. Убедиться в этом вы можете сами, открыв Advanced Settings на хосте:
Как мы видим из картинки, есть планка для CBRC размером в 2 ГБ, которую нельзя менять и есть текущее значение памяти, зарезервированной для кэша. Кроме того, есть настройка таймаута при загрузке хоста для дайджест-журнала SCSI, который хранит в себе хэш-таблицу блоков, которые учитывает кэш CBRC при их запросе от виртуальной машины.
Этот дайджест хранится в папке с виртуальной машиной в виде отдельного VMDK-файла:
То есть, при чтении виртуальной машиной блока с хранилища, он сначала ищется в кэше, и, если он там отсутствует, то он туда помещается и отдается виртуальной машине. Ну а если он в кэше есть - то сразу ей отдается. Соответственно, кэш CBRC увеличивает производительность при операциях чтения виртуальных машин хоста с одними и теми же блоками, что часто бывает в инфраструктуре VDI. Особенно это актуально при одновременной загрузке десятков виртуальных ПК, которая может вызвать так называемый Boot Storm. Посмотрите, как увеличивается интенсивность операций чтения при загрузке Windows ВМ, с которую может существенно "погасить" CBRC:
Надо отметить, что CBRC - это чисто хостовая фишка VMware vSphere, которую может поддерживать любое надстроенное VDI-решение (например, Citrix XenDesktop). А вот в VMware View поддержка CBRC будет идти под эгидой функции VMware View Storage Accelerator:
Как понятно из описанного выше, для такой поддержки практически ничего уже и делать не нужно - все есть в ESXi 5.0.
Во второй части заметки рассмотрим возможность VMware View Client Side Caching, которая представляет собой использование кэша в оперативной памяти устройств доступа к виртуальным ПК (тонкие и толстые клиенты с View Client) для картинки рабочего стола (а точнее, ее регионов). Эта возможность появилась уже в VMware View 5.0 и включена по умолчанию: 250 МБ памяти используется на клиенте, за исключением всяких Android и iOS-устройств.
Представьте, что вы просматриваете в виртуальном ПК PDF-документ. Рамка и контролы в ридере остаются на месте, а его содержимое скроллится в ограниченной области экрана. Вот для этого и нужен Client Side Caching - он позволяет закэшировать этот неизменяющийся фрагмент картинки экрана и не обращаться за ним к хосту и хранилищу. Это увеличивает производительность виртуального ПК до 30%.
Настраивается это просто - через шаблон групповой политики pcoip.adm, про работу с которым написано, например, вот тут. Настройка GPO называется "Configure PCoIP client image cache size policy":
Диапазон допустимых значений - от 50 до 300 МБ. Работает эта штука и для Linux-устройств. С ней есть тоже одна засада - если на тонком клиенте мало оперативной памяти (меньше 1 ГБ), клиентский кэш луше немного уменьшить, если наблюдаются проблемы с производительностью.
Известна также их утилита Virtual Session Indexer (VSI) для тестирования VDI-решений, о которой, собственно, и пойдет речь ниже. На днях коллеги из Login Consultants прислали мне скриншоты и пресс релиз с новой версией VSI 3.6 (см. про 3.5 тут), которая научилась делать Client Side Performance Testing, т.е. тестирование производительности со стороны клиентских устройств для VMware View, Citrix XenDesktop и других решений для виртуализации настольных ПК.
Модуль Client Side Performance Testing теперь может выполнять следующие тесты:
Character response – сколько времени проходит между нажатием кнопки на клавиатуре и прорисовкой на экране с использованием соответствующего протокола передачи (PCoIP, HDX и др.)
Large text response – то же самое, но для больших объемов текста
Mouse click feedback – то же самое, но для щелчка мыши
Image quality and loading times – необходимое время для прорисовки сложной картинки посредством тестируемого.
Картинка непростая - она, ко всему прочему, позволяет заценить еще и качество отображения:
Утилита Login VSI 3.6 позволяет проводить тесты VDI-нагрузок для следующих сценариев:
Что будет, если увеличить число пользователей на сервер, как изменится поведение рабочего стола на клиенте?
Если переключиться с Server Side на Client Side rendering, какое влияние будет на потребление канала и отклик для пользователя?
Какой эффект оказывает WAN-акселератор (если он есть) на производительность сессии с виртуальным ПК?
В первой части статьи "Сравнение производительности StarWind iSCSI Enterprise и Microsoft iSCSI" мы приводили выводы Джейка Ратски о том, что iSCSI-таргет от компании StarWind показывает большую производительность по сравнению с его аналогом от Microsoft для рассмотренной нагрузки при установке одной ВМ. Теперь Джейк провел тестирование обоих продуктов при использовании трех виртуальных машин (на той же самой конфигурации оборудования), с которым можно ознакомиться в следующих статьях:
Для тех, кто использует хранилища iSCSI под виртуальные машины - очень полезно ознакомиться. Приведем основные выводы.
1. Использование полосы пропускания адаптера iSCSI.
Microsoft iSCSI:
StarWind iSCSI:
Как видно из картинок, StarWind iSCSI потихоньку разгоняется и показывает лучшие результаты, чем Microsoft iSCSI Target. Происходит это за счет активного использования кэша на сервере хранилища iSCSI, как и в предыдущем тесте:
2. Эффективность процесса дедупликации.
Как мы уже писали, StarWind iSCSI использует inline-дедупликацию данных на хранилище с размером блока 4 КБ, что подразумевает запись на диск только оригинальных копий данных, без повторяющихся блоков. В тесте для 3-х ВМ размером 9 ГБ каждая на хранилище было реально занято 8,69 ГБ данных, что довольно эффективно для трех практически одинаковых машин.
Коэффициент дедупликации - 3.15 к 1.
3. Производительность хранилища.
В тесте опять использовалась нагрузка, генерируемая IOMeter, на одной машине при двух простаивающих, а также на всех трех одновременно. Результат MS iSCSI (нагружена только одна ВМ):
Результат StarWind iSCSI:
И тут снова StarWind выигрывает.
Теперь метрики IOMeter для трех одновременно нагруженных ВМ для Microsoft iSCSI (минута с момента начала генерации нагрузки):
Продолжаем вас знакомить с решением номер 1 для создания отказоустойчивых хранилищ виртуальных машин для серверов VMware vSphere 5 - StarWind iSCSI Enterprise. Блоггер Jake Rutski провел интересное тестирование, в котором он сравнил производительность продуктов StarWind iSCSI Enterprise и Microsoft iSCSI при работе виртуальных машин с хранилищами. Итак, характеристика тестового окружения...
На сайте известного многим из вас проекта VMware Labs появилось очередное приложение. Бесплатное средство VMware vBenchmark, поставляемое в виде готового виртуального модуля (Virtual Appliance на базе SLES 11), позволяет измерять ключевые метрики производительности инфраструктуры VMware vSphere, анализировать времена типичных операций в виртуальной среде, а также определять показатели качества обслуживания для виртуальных сервисов (например, простой хост-серверов или сколько времени простоя помогают избежать функции высокой доступности).
То есть основная мысль vBenchmark - предоставить пользователю количественные показатели преимуществ, получаемых средствами инфраструктуры виртуализации VMware vSphere.
Основные возможности VMware vBenchmark:
Получение метрик с одного или нескольких серверов vCenter
Возможность включения или исключения хостов на уровне кластера из анализа
Возможность сохранять запросы к инфраструктуре и сравнивать их между собой в разные точки времени
Воможность сравнить ваше облако с аналогами по региону, отрасли и размеру организации, чтобы определить, насколько хорошо оно устроено
Последняя возможность предполагает загрузку результатов анализа в общий репозиторий, который представляет собой глобальную базу данных организаций.
Статистика инфраструктуры:
Метрики эффективности виртуальной среды:
Показатели типовых операций:
Все это и остальные вкладки утилиты вы можете увидеть в ролике, записанном Владаном Сегетом:
Скачать виртуальный модуль VMware vBenchmark можно по этой ссылке. Отметим, что он поставляется как в форматах OVF/OVA (vCenter+vCloud Director), так и в обычном VMX, что позволит развернуть продукт на VMware Workstation, Fusion и Player.
Как мы уже не раз писали, в VMware View 5 появилась новая возможность отключать функцию Build to Loseless (BTL) для доступа к виртуальным ПК. Ее отключение несколько ухудшает качество передаваемой картинки, зато существенно увеличивает быстродействие (снижение требований к каналу до 30%) и отклик элементов отображаемого рабочего стола пользователя. При этом можно регулировать различные параметры, определяющие качество картинки, FPS и другое средствами групповых политик.
Конфигурируются эти настройки через шаблон групповой политики (GPO) pcoip.adm, расположенный на сервере VMware View Connection Server в папке (там же лежат и другие шаблоны):
Самый актуальный для пользователей VMware View 5 вопрос - это как сделать так, чтобы при доступе из локальной сети предприятия (LAN) пользователь входил на десктоп с включенным BTL (в условиях, когда канал широкий), а при доступе из интернета (WAN, узкий канал) можно было бы BTL отключить для повышения производительности.
Средствами View Manager, к сожалению, этого сделать нельзя, поэтому Dwayne Lessner придумал вот такой способ.
Нам понадобится следующее:
Шаблон политики vdm_agent.adm – используем его для запуска VB-скрипта или сценария PowerShell при соединении пользователя (Connect или Reconnect)
Шаблон
pcoip.adm – используем его для установки параметров Frame Rate, Image quality и других.
Прежде всего, для проверки используемых настроек (включен BTL или выключен) можно использовать лог, находящийся в папке виртуального ПК по адресу :\ProgramData\VMware\VDM\logs (для Windows 7). Называется он pcoip_server*timestampOfConnection*.log.
Там будут подобные строчки:
02/02/2012, 22:04:16.737> LVL:0 RC: 0 MGMT_ENV :cTERA_MGMT_CFG::load_server_config_from_stores[1]: Did not process over-rideable pcoip defaults from registry.
Если пользователь соединился из внешней сети (WAN), то в этом ключе будет записано имя Security Server. Для сторонних брокеров соединений (например, F5) можно читать ключик:
Теперь Dwayne нам предлагает вот такой скрипт (вы можете написать его самостоятельно, например, на PowerShell, где он будет выглядеть элегантнее):
'Declare Environment Variables
Dim ViewBroker, BTL
'Set Environment Variables
Set WSHShell = CreateObject("WScript.Shell")
'Lookup values in registry and assign to variables
ViewBroker = WSHShell.RegRead("HKEY_CURRENT_USER\Volatile Environment\ViewClient_Broker_URL")
BTL = WSHShell.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Teradici\PCoIP
\pcoip_admin_defaults\pcoip.enable_build_to_lossless")
'Check Build to Lossess and if they are connecting to a security server
If ((ViewBroker = "External-Broker-Name") And (BTL = 1)) Then
WSHShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Teradici\PCoIP\
pcoip_admin_defaults\pcoip.enable_build_to_lossless","0","REG_DWORD"
'Test Message Box inform the user
MsgBox "Your Connected from a Remote Location, to get better performance please disconnect and connect to get optimal user experince. A new setting must be applied"
End If
'Check to see if they connected from home and turned BTL off but are now back on the LAN
If ((ViewBroker = "Internal") And (BTL = 0)) Then
WSHShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Teradici\PCoIP\
pcoip_admin_defaults\pcoip.enable_build_to_lossless","1","REG_DWORD"
'Test Message Box inform the user
MsgBox "Your Performance is optimized for a slow link. To have the best user experience disconnect your session and log back in. A new setting must be applied"
End If
Ну а дальше конфигурируете групповую политику, где прописываете VB или PowerShell скрипт в CommandsToRunOnConnect и Reconnect:
После этого, конечно, пользователю будет нужно делать Reconnect при смене сети LAN/WAN, но зато процесс будет частично автоматизирован. Остается вопрос - почему такую важную вещь VMware не сделала в GUI своего View? Ведь при работе через инет по медленным соединениям виртуальные ПК откровенно тормозят и без отключения BTL просто не обойтись.
Тем из вас, кто следит за новостями в сфере виртуализации настольных ПК, должна быть известная организация Login Consultants, которая постоянно проводит различные сравнения продуктов для серверной и десктопной виртуализации. В частности, известен их фреймворк Login VSI для обмеров производительности виртуальных ПК.
На этот раз коллеги провели тесты производительности качества работы с виртуальными ПК в VMware View 5 (протокол PCoIP) и Citrix XenDesktop 5.5 (технология HDX):
В тесте был использован тот же Login VSI, с помощью которого генерировалась нагрузка на ПК. В итоге - XenDesktop показал лучшие результаты (FPS для десктопа) при меньших требованиях десктопа к каналу (bandwidth). В отличие от других сравнительных тестов, в этом примечательно то, что модель нагрузки, конфигурация сети, а также набор оборудования были взяты из документа "Desktop Virtualization with VMware View 5.0 Compared to View 4.6", о котором мы уже писали вот тут (также от Login Consultants). Это документ, утвержденный компанией VMware. Так что, объективности ради, стоит признать, что VMware View пока проигрывает Citrix XenDesktop в плане производительности пользовательских сессий.
Как вы знаете, Teradici при помощи VMware занимается разработкой протокола PCoIP, который реализуется аппаратными (Teradici) и программными (VMware) модулями. В частности VMware View 5 поддерживает программную реализацию протокола PCoIP, об улучшениях которого вы можете прочитать вот тут.
Но что делать с виртуальными машинами, которые требуют мощностей графических карт, которые отсутствую в хост-серверах виртуализации? Это могут быть программы графического моделирования, медицинские приложения, медиа-сервисы и т.п. VMware и Teradici предлагают такое решение: в датацентре ставятся мощные рабочие станции с сильными GPU, в них устанавливаются аппаратные карточки PCoIP, которые позволяют на высокой скорости передавать картинку уже на обычный ПК или тонкий клиент с VMware View Client:
При этом такая рабочая станция находится под управлением VMware View Connecion Server через VMware View Agent, устанавливаемый на ней. Преимущество такого подхода только одно - безопасность. Машина и ее данные находятся в датацентре компании и обслуживаются его персоналом.
У VMware появилась полезная презентация на русском языке по решению наиболее часто встречающихся проблем в работе решения VMware View и виртуальных ПК.
Освещаются такие компоненты решения, как VMware Security Server, PCoIP, Composer и другие.
Презентация из серии материалов по решению проблем, которые готовит служба технической поддержки VMware.
Многие из тех, кто следит за новостями в сфере виртуализации, помнит, что достаточно давно компания VMware выпустила продукт VMware vCenter AppSpeed, предназначенный для мониторинга и решения проблем производительности на уровне приложений, работающих в виртуальных машинах.
Продукт продвигался весьма форсированно и выглядел весьма красиво. Но, как говорится, не пошел. Я думаю, что не пошел он, во-первых, из-за сильной конкуренции со стороны аналогов, а, во-вторых, из-за того, что это была "непонятная и бесполезная хрень", хотя идея мне нравилась. Ну и надо отметить абсолютно беспомощную маркетинговую компанию по его продвижению.
vCenter AppSpeed давно не обновлялся, и последняя версия vSphere, с которой он совместим - это vSphere 4.0 Update 2:
Официальное сообщение об End of Life продукта vCenter AppSpeed доступно тут. 3 января 2012 года заканчивается поставка лицензий на данное ПО, а поддержка заканчивается 15 сентября 2012 года.
На сайте steelbytes.com недавно обновилась бесплатная утилита HD_Speed, которая позволит вам протестировать производительность дисков в виртуальных машинах VMware vSphere или на других платформах.
Утилита выводит статистику скорости обмена в реальном времени не только для виртуальных дисков, но и любых других устройств - hard disks, cd/dvd-roms, flash cards/sticks, floppys и т.д. Поддерживаемые режимы - чтение, запись, чтение-запись, чтение-запись-проверка (можно задавать размер блока). С режимом записи осторожнее - можно уничтожить данные на диске. Также возможно тестирование пиковой пропускной способности устройства.
Результаты можно писать в лог-файл. Что приятно - присутствует интерфейс на русском языке.
Для пользователей решения по виртуализации настольных ПК предприятия VMware View появилась красивая бесплатная утилита PCoIP Log Viewer 2.0 для визуализации статистики, собираемой через WMI для PCoIP-сессий в виртуальных ПК.
Возможности PCoIP Log Viewer 2.0:
Парсинг и графическое отображение метрик производительности PCoIP из лог-файлов (для View 4.x, 5.0)
Отображение в реальном времени счетчиков WMI для PCoIP (View 5.0)
Возможность сохранять сессии WMI для дальнейшего просмотра и анализа
Возможность WMI-Rewind для перемещения во временном интервале для статистики сессии
Вкладки для различных сессий WMI и лог-файлов
Возможность Drag-and-Drop лог-файлов в окно просмотрщика
Экспорт сохраненных WMI-сессий в формат XLSX для дальнейшего анализа и возможности построения своих графиков
Классная штука. Скачать PCoIP Log Viewer 2.0 можно по этой ссылке.
На сайте проекта VMware Labs, где в последнее время часто появляются полезные утилиты от сотрудников VMware, опубликована новая штучка - VMware I/O Analyzer, виртуальный модуль (Virtual Appliance) для анализа статистики по вводу-выводу.
Данное ПО включает в себя стандартные средства для измерения производительности систем хранения VMware vSphere, которые позволят выявить проблемы и узкие места в инфраструктуре хранилищ.
Ключевые возможности VMware I/O Analyzer:
Интегрированный фрейворк для тестирования хранилищ
Готовый к развертыванию виртуальный модуль
Прост в настройке и возможность исполнения тестов на нескольких хостах ESX/ESXi
Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС
Возможность экспорта данных для последующего анализа
Скачать VMware I/O Analyzer можно по этой ссылке. Инструкция по развертыванию доступна тут.
RSS
