vSphere 5.0 и миллион IOps

vSphere 5.0 и миллион IOps

VMware показала весьма интересный документ: Achieving a Million I/O Operations per Second from a Single VMware vSphere 5.0 Host. В данном документе приводятся результаты различных тестов, из которых видно, что один хост с vSphere 5.0 может генерировать свыше одного миллиона IOps. Документ построен таким образом, что сначала нам приводятся результаты Multi-VM теста (тест, когда на одном хосте ESXi 5.0 запущены 6 виртуальных машин, и они все одновременно генерируют к хранилищу IOps), а затем результаты Single-VM теста (когда только одна виртуальная машина на хосте ESXi 5.0 генерирует IOps к хранилищу). Чуть ниже я привел основные моменты, касающиеся данных тестов.


Результаты тестов

Чтобы вы долго не искали конечные результаты ниже приведенных тестов, приведу их здесь:


  • Один хост vSphere 5.0 способен обработать более одного миллиона операций ввода/вывода в секунду.
  • 300,000 I/O операций может быть достигнуто для одной виртуальной машины.
  • Полоса пропускания масштабируется почти линейно с увеличением размера запроса в операции ввода/вывода.
  • В vSphere 5 контроллер PVSCSI использует меньше ресурсов процессора и показывает лучшую производительность по сравнению с LSI Logic SAS контроллером.


Multi-VM Tests

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


Server
  • 4 Intel Xeon Processors E7-4870, 2.40GHz, 10 cores
  • 256GB memory
  • 6 dual-port Emulex LPe12002 HBAs (8Gbps)

Storage Area Network
  • VMAX with 8 engines
  • 4 quad-core processors and 128GB of memory per engine
  • 64 front-end 8Gbps Fibre Channel (FC) ports
  • 64 back-end 4Gbps FC ports
  • 960 * 15K RPM, 450GB FC drives
  • 1 FC switch

Virtual Platform
  • vSphere 5.0


Virtual Machines
  • Windows Server 2008 R2 EE x64
  • 4 vCPUs
  • 8GB memory
  • 3 virtual SCSI controllers


Для эксперимента был задействован один физический сервер под управлением VMware vSphere 5. На данном хосте было создано шесть идентичных виртуальных машин. Также на этом хосте было установлено 6 двухпортовых 8Gbps FC HBA. Все 12 FC портов этих адаптеров были подключены к FC свичу. VMAX был подключен к одному FC свичу через 60 8Gbps FC линков, при этом каждый линк подключен к отдельному FC порту на массиве.


В общей сложности в массиве было создано 480 RIAD-1 групп с использованием 960 FC дисков. В каждой RAID группе был создан один LUN. Затем был создан 250 GB metaLUN из 8 обычных LUN. В общей сложности получилось 60 metaLUN, которые тут же были презентованы хосту vSphere 5. На каждом metaLUN создано VMFS хранилище. Для достижения максимальной производительности, для каждого VMFS хранилища был настроен фиксированный путь (fixed path) через выделенный FC порт на массиве.


На каждом VMFS-датасторе был создан толстый диск. Виртуальные диски были распределены по виртуальным машинам следующим образом:


  • Каждой ВМ назначено, в общей сложности, 10 виртуальных дисков.
  • Все 10 дисков в виртуальной машине были распределены по трем виртуальным SCSI контроллерам.
  • Тип виртуального SCSI контроллера менялся от LSI Logic SAS до PVSCSI для сравнительных тестов.
  • В общей сложности, 384 GB (6.4GB на каждом виртуальном диске) дискового пространства было использовано IOmeter для генерации I/O нагрузки на всех ВМ.

multi-vm.jpg


Переходя к тесту, на шести виртуальных машинах был запущен IOmeter (размер блока 8Kb) для генерирования нагрузки. И вот, что получилось:

test1.jpg

Как видно из диаграммы выше, когда все шесть машин одновременно генерируют I/O нагрузку, то общее количество операций I/O в секунду, направленное от хоста VMware vSphere 5.0 к массиву, составляет чуть более миллиона. Причем значение "Latency" на протяжении всего теста меняется совсем незначительно (не более 10%). Далее тест повторяется, только на этот раз с различным размером блока, установленным в IOmeter, и для различных SCSI контроллеров:

test2.jpg

Как видно, PVSCSI выигрывает по всем параметрам. Причем PVSCSI контроллер создает меньшую нагрузку на CPU:

test3.jpg

PVSCSI контроллер обеспечивает на 8% лучшую пропускную способность, при этом используя на 10% меньше процессорного ресурса. Эти результаты явно показывают, что использование PVSCSI контроллера дает лучшую производительность по сравнению с LSI Logic SAS контроллером.


Single-VM Performance

Теперь настало время протестировать, какое количество IOps сможет сгенерировать только одна виртуальная машина, расположенная на хосте VMware vSphere 5.0. Для этого немного меняем наш экспериментальный стенд.


Server

  • 4 Intel Xeon Processors E7-4870, 2.40GHz, 10 cores
  • 256GB memory
  • 4 dual-port Emulex LPe12002 HBAs (8Gbps)


Storage Area Network

  • VMAX with 5 engines
  • 4 quad-core processors and 128GB of memory per engine
  • 40 front-end 8Gbps FC ports
  • 40 back-end 4Gbps FC ports
  • 960 * 15K RPM, 450GB FC drives
  • 1 FC switch


Virtual Platform

  • vSphere 5.0


Virtual Machines

  • Windows Server 2008 R2 EE x64
  • 16 vCPUs
  • 16GB memory
  • 1 to 4 virtual SCSI controllers 


На сервере vSphere 5.0 была создана одна виртуальная машина с 4 vCPU и 16GB памяти. IOmeter был настроен для использования, в общей сложности, 40 виртуальных дисков. Все 40 виртуальных дисков были назначены на одну тестовую ВМ. vSphere 5 поддерживает до 4 PVSCSI контроллеров на одну ВМ. Поэтому на каждый PVSCSI контроллер пришлось по 10 дисков. На хосте vSphere 5.0 для соединения с массивом было установлено 4 двухпортовых HBA.

single-vm.jpg

Как и в предыдущих тестах, для генерирования нагрузки использовался IOmeter:

test4.jpg

Из диаграммы, приведенной выше, видно, что количество IOps линейно возрастает с увеличением количества виртуальных SCSI контроллеров. При этом "I/O Latency", после увеличения количества контроллеров с одного до двух, практически не меняется. Основываясь на результате этого теста, можно сделать вывод, что одна виртуальная машина с четырьмя (4) PVSCSI контроллерами может генерировать до 300,000 тысяч IOps.

Tags (2)
Version history
Revision #:
1 of 1
Last update:
‎09-01-2011 02:44 AM
Updated by: