Оптимальный размер блока esxi 5.5

Обновлено 13.08.2016

Оптимальный размер блока esxi 5.5-01

Оптимальный размер блока esxi 5.5-01

Всем привет сегодня хочу затронуть тему как выбрать размер блока esxi 5.5. Выбор размера тома VMFS-5 для размещения виртуальных машин VMware ESXi стал уже не таким сложным с выходом ESXI 5.5.

При развертывании виртуальной инфраструктуры серверов VMware Virtual Infrastructure, один из основных вопросов, который встает перед администраторами и CIO – это выбор правильной системы хранения и необходимого дискового пространства. От правильного сайзинга виртуальных машин по томам VMFS зависит в будущем то, насколько производительной и гибкой будет виртуальная инфраструктура.

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

Итак, для начала несколько рекомендаций:

  • Помните, что лучшей практикой является создание одного тома VMFS для одного LUN. Добавление дополнительных LUN в качестве экстентов (extents) не рекомендуется.
  • Для уменьшения риска необходимости расширения тома VMFS при создании снапшотов и прочих непредвиденных обстоятельств виртуальные машины размещаются таким образом, что 30% тома VMFS должны оставаться свободными.
  • Да улучшения производительности на одном VMFS-томе размещаются от 5 до 15 виртуальных машин на LUN. Не рекомендуется размещать более 30 виртуальных машин.
  • Создавайте все LUN унифицированного размера, например, по 1024 ГБ или 2048 ГБ. Не храните ISO-образы на дорогих FC LUN – используйте для этого NFS-шары.
  • Уделите особое внимание выбору размера блока при создании тома VMFS.
  • Для маленьких LUN необходимо учитывать, что метаданные тома VMFS также занимают некоторое дисковое пространство. Объем метаданных, расположенных на томе VMFS вычисляется по следующей формуле:500Мб + (x – 1)*(0.016Кб), где x-объем, выделенный тому VMFS в гигабайтах.Например, для тома емкостью в 200 Гб объем метаданных будет равен:500Mб + (200 - 1) (0.016Кб) = 503.184 Мб
vsphere 5

Оптимальный размер блока esxi 5.5

  • Для доступа к одному тому VMFS используйте не более 10-15 хостов. При большем количестве хостов ESXi в вашей инфраструктуре – лучше создать два кластера DRS / HA во избежание проблем с производительностью. Если у вас виртуальные машины с большими требованиями к I/O (серверы БД), не используйте более 8 хостов ESXi на том VMFS.
  • Одним из важных параметров является размер очереди к диску (Disk Queue). Если вы мигрируете существующие ВМ в виртуальную среду – необходимо сначала изучить размеры средней очереди к диску систем и распределить их потом по LUN так, чтобы средние значения дисковой очереди на LUN были приблизительно одинаковы. Провести такое обследование (Virtualization Assessment) может авторизованный консультант (VMware Authorized Consultant, VAC), который использует ПО VMware Capacity Planner для централизованного сбора информации об Inventory и загрузках физических серверов.
  • Занимаемое пространство виртуальной машиной на томе VMFS может рассчитываться исходя из формулы disk*2+RAM. RAM понятно для чего – на случай приостановки (suspend) виртуальной машины. Дисковое пространство умножается в два раза исходя из учета возможного создания «снэпшота» виртуальной машины, файл отличий которого может увеличиться до размера базового диска. Почему так? Да потому, что NTFS работает таким образом: при записи файлов на диск сначала используются полностью свободные блоки, а только после того, как они закончились – блоки, которые помечены как свободные. То есть при записи файлов – vmdk разрастается, а при удалении – размер не уменьшается.Таким образом, файл отличий vmdk, который из гостевой ОС видится как диск размером с базовый, быстро вырастет до его размера, и у нас получится два диска исходного размера. Это происходит еще и потому, что Windows постоянно производит запись и удаление чего-то на диск – например, работает с файлом подкачки.Кроме того, очень важный момент – резервное копирование виртуальных машин средствами VMware Consolidated Backup (VCB), который пользуется технологией снапшотов. Иногда VCB забывает удалить снапшот виртуальной машины после того, как отработает, и этот снапшот продолжит расти.
  • Отдельная история, если вы планируете внедрить Virtual Desktop Infrastructure (VDI) на базе, например, продукта VMware View. При использовании технологии Linked Clones, которая предоставляется средствами VMware View Composer и позволяет создавать несколько ВМ с файлами отличий от базового образа виртуального диска, отдельное внимание нужно уделить быстродействию системы хранения. Поскольку пространство под виртуальные диски связанных клонов выделяется динамически (блоками по 16 МБ) – это вызывает дополнительные операции по резервированию LUN хостом ESXi. Таким образом, если таких клонов много – система хранения начнет испытывать проблемы с производительностью.

Особенности VMFS-5

Улучшения VMFS-5:

  • Унификация размера  файлового блока в 1МБ. Предыдущая версия VMFS использует блоки размеро 1, 2, 4 или 8МБ. Большие размеры блоков нужны для создания файлов свыше 256GB. В VMFS-5 больше нет потребности в таких больших блоках — очень большие файлы можно создавать используя 1МБ блок.
  • Большие одиночные экстенты. Размер одиночного экстента увеличен до 60ТБ.
  • Меньше размер субблоков. В VMFS-5 реализован субблок меньшего размера. Субблоки уменьшены с 64 до 8КБ. Файлы размером от 1 до 8КБ теперь занимают 8КБ места.
  • Поддержка маленьких файлов. Новая файловая система поддерживает очень маленькие файлы. Для файлов размером менее 1КБ используется участок описания файла в метаданных. При превышении размера в 1КБ начинает использоваться 8-килобайтный файловый субблок.
  • Поддержка большего количества файлов. Теперь поддерживается более 100 000 файлов.
  • Расширенная поддержка ATS. Примитив с аппаратной аккселерацией, Atomic Test & Set (ATS), теперь используется для повышения проивзодительности блокировок файлов.

Улучшена утилита vmkfstools детально покажет существующие блоки

~ # vmkfstools -Pv 10  /vmfs/volumes/newly-created-vmfs5/
VMFS-5.54 file system spanning 1  partitions.
File  system label (if any): newly-created-vmfs5
Mode: public
Capacity 3298534883328 (3145728 file  blocks * 1048576),
3297500987392 (3144742 blocks) avail
Volume Creation Time: Tue Jun 14  14:35:53 2011
Files  (max/free): 130000/129992
Ptr Blocks (max/free):  64512/64496
Sub Blocks  (max/free): 32000/32000
Secondary Ptr Blocks (max/free):  256/256
File Blocks  (overcommit/used/overcommit %): 0/986/0
Ptr Blocks   (overcommit/used/overcommit %): 0/16/0
Sub Blocks   (overcommit/used/overcommit %): 0/0/0
UUID:  4df771c9-f6419df2-81bc-0019b9f1ecf6
Partitions spanned (on  "lvm"):
 naa.60a98000572d54724a34642d71325763:1
DISKLIB-LIB   : Getting VAAI support  status for /vmfs/volumes/newly-created-vmfs5/
Is Native Snapshot Capable:  NO
~ #

Переход с VMFS-3 на VMFS-5

Операция перехода с VMFS-3 на VMFS-5 бесшовна: производится вживую, без останова, во время операции ВМ продолжают работать.

Хранилища, обновленные до VMFS-5, могут использовать: функцию поддержки 1-килобайтных файлов,  тома до 60ТБ, все улучшения в функционале VAAI ATS.

Пример вывода vmkfstools на обновленном томе:

~ # vmkfstools -Pv 10  /vmfs/volumes/upgrade-testvol
VMFS-5.54 file system spanning 1  partitions.
File  system label (if any): upgrade-testvol
Mode: public
Capacity 3298534883328 (3145728 file  blocks * 1048576),
3297916223488 (3145138 blocks) avail
Volume Creation Time: Mon Jun 13  13:03:04 2011
Files  (max/free): 30720/30713
Ptr Blocks (max/free):  64512/64496
Sub Blocks  (max/free): 3968/3968
Secondary Ptr Blocks (max/free):  256/256
File Blocks  (overcommit/used/overcommit %): 0/590/0
Ptr Blocks   (overcommit/used/overcommit %): 0/16/0
Sub Blocks   (overcommit/used/overcommit %): 0/0/0
UUID:  4df60a88-8eaa51ea-3108-0019b9f1ecf6
Partitions spanned (on  "lvm"):
 naa.60a98000572d54724a34642d71325763:1
DISKLIB-LIB   : Getting VAAI support  status for /vmfs/volumes/upgrade-testvol
Is Native Snapshot Capable:  NO
~ #

Различия между созданным с нуля и обновленным хранилищем на VMFS-5

Хранилища, обновленные до VMFS-5:

  • продолжают использовать прежний размер файлового блока, а не унифицированный 1-мегабайтный блок;
  • продолжают использовать 64-килобайтный субблоки, а не новый 8-килобайтный;
  • имеют ограничение в 30720 файлов, а созданные с нуля поддерживают свыше 100000 файлов;
  • продолжают использовать партиции с MBR (Master Boot Record), при превышении размера в 2 ТБ происходит бесшовное переключение с MBR на GPT (GUID Partition Table);
  • имеют начало разделов с сектора 128;у созданных изначально разделы начинаются с сектора 2048.

RDM — Raw Device Mappings

  • Максимальный размер для passthru RDM 60ТБ.
  • Максимальный размер для non-passthru(virtual) RDM 2ТБ — 512 байт.
  • Обновленный до VMFS-5 хранилища также поддеживают большие passthru RDM.

Хочется напомнить об оставших ограничениях:

Максимальный размер VMDK-файла равен  2ТБ — 512 байт.

Максимальное количество LUN равно 256.

Рекомендация

Рекомендуется  создавать VMFS-5 тома с нуля для получения максимального эффекта, миграцию с VMFS-3 оcуществлять посредством Storage vMotion.

Теперь несколько примеров по выбору размера тома VMFS:

Пример 1. Минималистичный и экономичный.

Сайзим виртуальные машины по тому VMFS по номинальному размеру дисков vmdk. Оставляем 30% тома свободным на случай снапшотов и Suspend’ов виртуальных машин.

Пример 2. Сбалансированный.

Суммируем все виртуальные машины, учитывая диски таким образом: (disk +RAM)*1.1. Считаем, что 10% от номинального размера vmdk будут исполь зоваться снапшотами, за ростом которых будет следить системный администратор. Прибавляем еще 30-35% к получившемуся размеру, которые всегда остаются свободными на случай отпуска системного администратора или создания внеплановых ВМ. Этот вариант учитывает, что файл *.vmss, содержащий RAM виртуальной машины, которая поставлена «на паузу» (suspend), не удаляется при ее старте (удаляется только после полной остановки). Поэтому, возможно, у каждой машине в папке будет лежать файл *.vmss, равный размеру номинальной RAM виртуальной машины.

Пример 3. Максимальный запас.

Сайзим виртуальные машины по формуле disk*2+RAM. Этот вариант учитывает, что для всех машин будет по одному снапшоту, эти снапшоты разрастутся до размера базового диска, и все машины когда-либо будут приостановлены. Самым волнующимся можно добавить сюда еще 30%.

так что советую в ESXI 5.5 оставлять размер блока 1 мб, и размер страйпа на RAID лучше оставлять тот что по умолчанию, так как работа контроллера заточена под него. Надеюсь вы немного разобрались с VMFS-5.

Автор - Сёмин Иван

One Response to Оптимальный размер блока esxi 5.5

  1. Вася:

    А можно где-то прочитать, чем обусловлено вот это?
    «Для доступа к одному тому VMFS используйте не более 10-15 хостов. При большем количестве хостов ESXi в вашей инфраструктуре – лучше создать два кластера DRS / HA во избежание проблем с производительностью. Если у вас виртуальные машины с большими требованиями к I/O (серверы БД), не используйте более 8 хостов ESXi на том VMFS.»
    Вопрос интересный, но я, например, не нашел, таких рекомендаций от Vmware

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *