Skip navigation
2011

Будете читать блог kendrickcoleman.com - не проходите мимо этой статьи:



В данной статье автор наглядно показывает то, как бы он спроектировал сеть для vSphere 5, если бы в его распоряжении имелось 6 или 10 сетевых карт на хостах ESXi 5.0. Для ознакомления будет очень полезно. Единственный момент (и автор это признает), что уже сейчас активно развивается 10GbE стандарт. И, поэтому, данные схемы могут в скором времени устареть, но сама логика (то, на какие группы разбивать, что с чем можно объединить и т.д.) сильно не устареет.

Источник: Storage I/O Control Enhancements in vSphere 5.0 и Whitepaper


Как мы можем видеть, с выходом VMware vSphere 5.0 SIOC был улучшен совсем незначительно (как мне кажется). Из существенного, что лично я могу отметить, так это добавление поддержки NAS устройств (напомню, что SIOC в четвёртой vSphere поддерживал только FC, iSCSI, FCoE устройства хранения), что, несомненно, полезно. Тем более, что сейчас протокол NFS достаточно активно продвигается на рынке. В частности, NFS продвигается таким крупным игроком на рынке СХД, как компания NetApp, которая проводит и, затем, опубликовывает различные сравнительные тесты производительности протоколов, из которых видно, что протокол NFS ничуть не уступает своим старшим, если можно так сказать, собратьям:



Поэтому поддержка NFS в SIOC появилась, как никогда кстати. Что еще радует, так это то, как включается SIOC для NFS. Ребята из VMware постарались сделать так, чтобы мы - администраторы - не перетрудились ))). Поэтому все включается за пару кликов мыши:

SIOC-NFS.png

В принципе, это все значимые улучшения, которые были сделаны в SIOC в VMware vSphere 5. По крайней мере, я других не заметил.

Замечательный постер по интерфейсу командной строки (CLI). Скачать можно здесь.

cli-poster.jpg

Распечатываем и на стену ))

В Storage DRS, равно как и в DRS, присутствуют Affinity и Anti-Affinity правила. Эти правила в SDRS и DRS очень похожи, но есть некоторые отличия, о которых я хочу кратко рассказать.


Начнем с того, что в SDRS существует Affinity и Anti-Affinity правила как для виртуальных машин, так и для виртуальных дисков (VMDK). Affinity и Anti-Affinity правила для виртуальных машин позволяют нам сделать так, чтобы ВМ находились либо на одном, либо на разных датасторах. Вы можете спросить: "а что нам это даст?". А даст нам это следующее: допустим, у вас есть два виртуальных контроллера домена (или, например, два DNS сервера - основной и резервный) и если у вас НЕ настроено Anti-Affinity правило для этих ВМ, то, вполне возможно, что эти виртуальные машины окажутся на одном датасторе. А теперь представьте, что этот датастор, на котором фактически находятся контроллеры домена, вышел из строя. Досадно, правда? Теперь у вас нет сразу двух контролеров домена. А вот, если бы было настроено Anti-Affinity правило для двух этих ВМ, то они бы никогда не оказались на одном датасторе и, в этом случае, хоть один контроллер домена был бы жив.


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


Из всего написанного выше можно сделать один единственный правильный вывод: если у вас есть соответствующая лицензия, и вы внедряете SDRS, то не стоит пренебрегать Affinity и Anti-Affinity правилами. Это поможет вам в будущем избежать возможных проблем.


На мысль меня натолкнула статья: Storage DRS Affinity & Anti-Affinity Rules

vSphere 5 documentation notes


Очень и очень полезный документ. Огромная работа проделана автором этого документа. За это ему большое человеческое СПАСИБО. Кстати говоря, в блоге vmgu.ru уже опубликована заметка касательно этого документа. Обязательно к ознакомлению.

notes5screenshot.png

Источник: How to Query VM Disk Format in vSphere 5


Помните, как в 4-ой vSphere довольно-таки сложно было определить тип "толстого" (Thick) диска? У меня даже есть пост на эту тему. В VMware vSphere 5.0 с этим стало намного лучше. Теперь, без особого труда, можно понять, какого типа диск (vmdk) у виртуальной машины. Собственно говоря, об этом и написал в приведенном выше посте автор блога www.virtuallyghetto.com William Lam. Этот пост, наверное, не заинтересовал бы меня, если бы William не привел в нем, как мне кажется, достаточно полезный скрипт: getVMDiskFormat.pl, который может помочь администраторам при проведении очередной инвентаризации. Данный скрипт в удобочитаемом виде может выводить информацию как непосредственно на консоль, так и в ".CSV" файл. На практике это выглядит вот так:


  • Консоль:

vmdisk-format1.png

  • CSV файл:

vmdisk-format2_2.png

В Ворде это выглядит очень даже неплохо:

vmdisk-format3.png

Deshifrator Hot Shot

vSphere 5 FAQ: VMFS-5

Posted by Deshifrator Sep 25, 2011

Источник: vSphere 5 FAQ: VMFS-5


Данная статья содержит информацию о новой файловой системе: "VMFS-5", которая появилась в VMware vSphere 5.0. Также в этой статье вы найдете подробности по устранения неполадок при обновлении файловой системы с VMFS-3 до VMFS-5.


VMFS-5 Overview

Почему стоит перейти на VMFS-5?

  • VMFS-5 имеет улучшенную масштабируемость и производительность.
  • VMFS-5 не использует SCSI-2 блокировки, теперь используются ATS VAAI примитивы.
  • VMFS-5 использует GPT (GUID Partition Table) вместо MBR, что позволяет пробрасывать RDM диски в режиме физической совместимости размером более 2 TB.
  • Вновь созданные VMFS-5 датасторы используют единый размер блока - 1Mb.
  • VMFS-5 поддерживает очень маленькие файлы (<1KB), сохраняя их в метаданных.
  • VMFS-5 использует суб-блоки размером 8K вместо 64K, что уменьшает пространство, которое используется маленькими файлами.
  • VMFS-5 использует SCSI_READ16 и SCSI_WRITE16 для команд ввода/вывода (файловая система VMFS-3 использует SCSI_READ10 и SCSI_WRITE10 для команд I/O).


Какие ограничения присутствуют в VMFS-5?

  • VMFS-5 по-прежнему ограничивает максимальное число экстентов, которое не должно быть больше 32-х, а общий размер хранилища должен быть не более 64TB. При этом отдельные экстенты могут быть размером более 2TB. То есть хранилище в 64TB может состоять как из одного луна, размер которого 64TB, так и из 32-х экстентов, размер которых не ограничен 2-мя терабайтами.
  • Только RDM-диски в режиме физической совместимости могут быть созданы размером более 2TB. Для RDM дисков в режиме виртуальной совместимости и для файлов виртуальных дисков ВМ, по-прежнему действует ограничение: 2 TB - 512B.
  • RDM диски в режиме физической совместимости могут быть размером до 60TB.
  • Том, обновленный до VMFS-5, поддерживает большие (больше 2TB) RDM-диски в режиме физической совместимости.


VMFS-5 Partitioning

Как мне получить информацию о VMFS-5 разделе?

Для файлов, чей размер более 2 терабайт, тип таблицы разделов должен быть изменен с MBR на GPT. Для просмотра информации о GPT разделе можно воспользоваться командой partedUtil. Для получения более подробной информации об этой команде обратитесь к следующему документу: Using the partedUtil command line utility on ESX and ESXi (1036609).


После обновления до VMFS-5 таблица разделов осталась прежней. Почему?

Если размер вашего хранилища больше 2 терабайт, то тип раздела будет автоматически изменен с MBR на GPT. Если объём вашего хранилища меньше 2TB, то таблица разделов не будет изменена и останется прежней - MBR.


Upgrading from VMFS-3 to VMFS-5

Могу ли я сделать обновление в то время, когда мои ВМ работают?

Да. Обновление с VMFS-3 до VMFS-5 может быть сделано на лету (виртуальные машины не нужно выключать или мигрировать).


Должен ли я использовать командную строку для обновления до VMFS-5?

Обновление с VMFS-3 до VMFS-5 можно сделать, используя как командную строку ESXi 5.0, так и vSphere Client. Примечание: Убедитесь, что все хосты VMware ESX, имеющие доступ к этому LUN, находятся под управлением ESXi 5.0.


  • Для обновления хранилища до VMFS-5 с использованием vSphere клиента нужно перейти Configuration -> Storage, далее выбрать нужное VMFS-3 хранилище и нажать Upgrade to VMFS-5...
  • Для обновления до VMFS-5 с использованием командной строки выполняем следующую команду:
# vmkfstools -T /vmfs/volumes/<VMFS3datastore>

Мой обновленный VMFS-5 том имеет  размер блока не равный 1MB. Почему?

Разделы, обновленные до VMFS-5, сохраняют характеристики раздела оригинального VMFS-3 датастора, в том числе размер блока, размер суб-блока, равный 64K и т.д. Чтобы в полной мере воспользоваться преимуществами VMFS-5, вам нужно удалить и заново создать хранилища с новой файловой системой.


Troubleshooting VMFS-5 Upgrade Issues

Обновление до VMFS-5 завершается вот такой ошибкой:

  • There are hosts accessing this datastore which don't support VMFS-5
  • An error occurred during host configuration. Operation failed, diagnostics report: Unable to Upgrade Filesystem: File system on device /vmfs/devices/disks/<device> cannot be online upgraded now because it is being used by some legacy host.


Чтобы решить эти проблемы проверьте, что к этому хранилищу имеют доступ только хосты под управлением ESXi 5.0.

Источник: Multiple-NIC vMotion in vSphere 5…


В VMware vSphere 5.0 появилась возможность задействовать несколько сетевых интерфейсов (NIC) для операции vMotion. Но, прежде чем данная функция станет доступной, нам нужно произвести небольшую донастройку:


  • Создаем VMkernel интерфейс и даем ему имя "vMotion-01".
  • Переходим в настройки данного Portgroup и настраиваем так, чтобы в активных адаптерах был только один интерфейс, а все остальные помещаем в Standby Adapters (см. скриншот ниже для примера).
  • Создаем второй интерфейс VMkernel и даем ему имя "vMotion-02".
  • Переходим в настройки данного Portgroup и настраиваем уже другой сетевой интерфейс в качестве активного, а все остальные помещаем в Standby Adapters.
  • и так далее...


Теперь, когда вы будете инициировать "vMotion", можно будет задействовать несколько сетевых интерфейсов. Имейте в виду, что несколько интерфейсов (multiple-NIC) будут задействованы даже тогда, когда вы делаете "vMotion" только для одной виртуалной машины. Кроме того, если вы не отвели сетевые интерфейсы только для трафика "vMotion", то есть возможность воспользоваться Network I/O Control, чтобы для различного типа трафика назначить нужные "shares". Это, в свою очередь, позволит не допустить ситуации, при которой "vMotion" заполнит весь канал, что может крайне негативно повлиять на работу других, более важных служб системы.

vmotion.jpg

Изначально меня посетила мысль сделать и опубликовать перевод вот этой англоязычной статьи: "VMware: Creating iSCSI network in vSphere ESXi 5.0", но, более внимательно прочитав её, я решил не переводить её, а просто выделить основные различия в настройке iSCSI в новой vSphere 5.0. А их, как оказалось, не так уж и мало.


  • В vSphere 5.0 теперь существуют два программных Storage адаптера: Software iSCSI Adapter и Software FCoE Adapter. Но не один из них по умолчанию не присутствует в списке Storage Adapters на вкладке "Configuration". Чтобы добавить подходящий программный адаптер, вам необходимо перейти: Configuration > Storage Adapter > Add Storage Adapter. Далее появится следующее окно, в котором следует выбрать тип адаптера и, затем, нажать на кнопку "OK" (после этого программный iSCSI или FCoE адаптер появится в списке Storage Adapters):

add-iscsi.png

  • Теперь нет такой необходимости использовать командную строку хоста ESXi, чтобы настроить multipathing для iSCSI (см. Multipathing для LUN в ESX/ESXi 4). Я имею в виду тот момент, когда нужно было привязать к hba соответствующие vmk интерфейсы:
# esxcli swiscsi nic add -n vmk1 -d vmhba33

В VMware vSphere ESXi 5.0 всё стало намного проще. В настройках iSCSI адаптера появилась новая вкладка - Network Configuration, в которой можно достаточно легко добавлять нужные vmk интерфейсы.

Обратите внимание на колонку Port Group Policy. После того, как вы выбрали vmk адаптеры для использования с программным iSCSI адаптером, колонка Port Group Policy подскажет вам, совместимы или нет эти адаптеры для bind'а. Например, если у вас есть vmk интерфейс, у которого два активных адаптера, то такой интерфейс не будет помечен как "Совместимый" (Compliant). Иными словами, одному vmk интерфейсу должен соответствовать только один активный vmnic адаптер, остальные vmnic адаптеры должны быть помещены в Unused секцию.

image43.png

Вот, как это выглядит на практике:

mpath1.png

Источник: No more Windows Patching via VMware Update Manager 5


Как мы помним, предыдущие версии VMware Update Manager'а (VUM) поддерживали возможность патчить гостевые ОС (Windows или Linux). В основном, админы этой возможностью пользовались в тестовых лабораториях для того, чтобы не разворачивать WSUS или какой-либо другой сервер обновлений. Но с выходом vSphere 5.0 и VUM 5.0 такая возможность больше не доступна (об этом нас уведомляет установщик VUM 5):

vum.png

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

Читаем и запоминаем: VMware vSphere 5.0 Configuration Maximums

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.