Размеры VMware VMFS5 и LUN - несколько небольших хранилищ данных или 1 большое хранилище данных?

Поскольку у VMFS5 больше нет ограничения в 2 ТБ для тома VMFS, я рассматриваю, какой сценарий будет более выгодным в целом:

• Меньше LUNs большего размера, или
• Больше LUNs меньшего размера.

В моем случае у меня есть новый 24-дисковый массив с 600 ГБ дисками. Я буду использовать RAID10, примерно 7,2 ТБ, и попытаюсь решить, использовать ли 1 большое хранилище данных по 7 ТБ или несколько хранилищ по 1 ТБ каждый.

Каковы плюсы и минусы каждого подхода?

Обновление : конечно, я не учел включать в свои расчеты горячие резервы, так что это будет чуть меньше 7,2 ТБ, но общая идея та же. :-)

Обновление 2 : 60 виртуальных машин и 3 хоста. Ни одна из наших виртуальных машин не требует особенно интенсивного ввода-вывода. Большинство из них являются веб-серверами / серверами приложений, а также такими вещами, как мониторинг (munin / nagios), 2 Windows DC с минимальной нагрузкой и так далее. Серверы БД редко виртуализируются, если у них ОЧЕНЬ низкие требования к вводу / выводу. Сейчас я думаю, что единственный виртуальный сервер БД, который у нас есть, - это блок MSSQL, а размер БД на этом блоке составляет <1 ГБ.

Обновление 3 : немного больше информации о массиве и подключении FC. Массив представляет собой IBM DS3524, 2 контроллера с кешем 2 ГБ каждый. 4 порта FC 8 Гбит / с на контроллер. Каждый хост ESXi имеет 2x 4 Гбит FC HBA.

Вы не указали, сколько у вас виртуальных машин или что они будут делать. Даже без этой информации я бы избежал создания одного большого LUN из-за размера блока / производительности, конкуренции и гибкости.

Я предполагаю, что вы собираетесь виртуализировать серверы, а не рабочие столы, хорошо? Далее я предполагаю, что вы собираетесь использовать несколько серверов ESX / ESXi для доступа к хранилищу и управления ими с помощью vCenter Server.

Принимая решение о размере LUN ​​и количестве VMFS, вы балансируете несколько факторов: производительность, гибкость конфигурации и использование ресурсов, в то же время ограничиваясь поддерживаемой максимальной конфигурацией вашей инфраструктуры.

Вы можете добиться максимальной производительности при отображении 1 ВМ на 1 LUN / VMFS. Нет конкуренции между машинами на одной и той же VMFS, нет конкуренции за блокировку, каждая нагрузка разделена и все исправно. Проблема в том, что вы собираетесь управлять неоправданно большим количеством LUN, можете достичь поддерживаемых максимальных пределов, столкнуться с головными болями при изменении размера и миграции VMFS, использовать недоиспользуемые ресурсы (складывается свободное пространство на один процентный пункт в VMFS) и вообще создать нечто, что не приятно управлять.

Другая крайность - одна большая VMFS, предназначенная для размещения всего. Таким образом, вы получите наилучшее использование ресурсов, не будет проблем с выбором места развертывания и проблем с VMFS X в качестве горячей точки, в то время как VMFS Y находится в режиме ожидания. Стоимость будет агрегированной производительностью. Почему? Из-за блокировки. Когда один ESX выполняет запись в данную VMFS, другие блокируются на время, необходимое для завершения ввода-вывода, и приходится повторять попытку. Это стоит производительности. Вне игровой площадки / среды тестирования и разработки это неправильный подход к конфигурации хранилища.

Общепринятой практикой является создание хранилищ данных, достаточно больших для размещения нескольких виртуальных машин, и разделение доступного пространства хранения на порции соответствующего размера. Количество виртуальных машин зависит от виртуальных машин. Вам может потребоваться одна или несколько критических баз производственных данных в VMFS, но вы можете разместить три или четыре десятка машин для тестирования и разработки в одном хранилище данных. Количество виртуальных машин на хранилище данных также зависит от вашего оборудования (размер диска, число оборотов в минуту, кэш контроллеров и т. Д.) И схем доступа (для любого данного уровня производительности вы можете разместить на одной и той же VMFS гораздо больше веб-серверов, чем почтовых серверов).

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

Еще одна вещь: при создании этих хранилищ данных стандартизировать на один размер блока. Позже это упрощает многие вещи, когда вы хотите что-то делать в разных хранилищах данных и видеть уродливые «несовместимые» ошибки.

Обновление : DS3k будет иметь активные / пассивные контроллеры (т. Е. Любой данный LUN может обслуживаться контроллером A или B, доступ к LUN через контроллер, не являющийся владельцем, влечет за собой снижение производительности), поэтому он окупится, если будет иметь четное количество LUN , равномерно распределенный между контроллерами.

Я мог бы представить, начиная с 15 ВМ / LUN с пространством для увеличения до 20 или около того.

Краткий ответ на ваш вопрос: все зависит от того, каковы ваши шаблоны ввода-вывода, и это будет уникальным для вашей среды.

Я предлагаю вам посмотреть здесь http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/, так как это может помочь вам определить ожидаемые IOPS и количество подходящих LUNS. Тем не менее, если бы вы допустили ошибку из-за осторожности, некоторые люди посоветовали бы иметь много LUNS (если моя поправка к предыдущему ответу будет одобрена, см. Мои комментарии относительно очередей LUN IO на стороне массива). Я склонен согласиться, но пойду дальше, чтобы затем объединить их в один / несколько томов VMFS (не верьте FUD об экстентах и ​​других ограничениях VMFS http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html). Это даст преимущество управления одним / несколькими хранилищами данных в vSphere, и, поскольку vSphere автоматически балансирует виртуальные машины по доступным экстентам, начиная с первого блока каждого экстента, выигрыш в производительности распределяет ваш IO по нескольким LUN.

Что-то еще, чтобы рассмотреть ... Вы говорите, что ни одна из виртуальных машин не является особенно интенсивной IO. Учитывая это, вы можете рассмотреть комбинацию RAID5 и RAID10, чтобы получить лучшее из обоих миров (пространство и скорость).

Кроме того, если у вас есть виртуальные машины, сконфигурированные с несколькими VMDK, с шаблонами ввода-вывода ОС и приложений, распределенными по этим виртуальным дискам (т. Е. ОС, Интернет, БД, журналы и т. Д., Каждый на отдельном VMDK), вы можете затем найти каждый VMDK в другое хранилище данных, соответствующее возможностям ввода-вывода этого физического LUN (например, ОС на RAID5, вход в систему на RAID10). Все дело в том, чтобы сохранить сходные шаблоны ввода-вывода вместе, чтобы воспользоваться механическим поведением базовых дисков, чтобы, например, запись журнала в одной виртуальной машине не влияла на скорость чтения веб-страниц в другой виртуальной машине.

К вашему сведению ... вы можете успешно виртуализировать серверы БД, вам просто нужно проанализировать шаблоны ввода-вывода и скорости IOPS и настроить этот ввод-вывод на подходящий LUN; все время осознавая шаблоны ввода-вывода и IOPS, которые этот LUN уже делает. Вот почему многие администраторы обвиняют виртуализацию в плохой производительности БД ... потому что они не рассчитывали тщательно IO / IOPS, которые сгенерировали бы несколько серверов, когда они помещали их в общий LUN (т. Е. Это ошибка администратора, а не ошибка виртуализации). ).

Каждый том (LUN) имеет свою собственную глубину очереди, поэтому, чтобы избежать конфликта ввода-вывода, многие реализации используют более маленькие LUN. Тем не менее, вы можете легко создать LUN хранилища данных. Недостаток больших (и меньших) хранилищ данных VMWare, насколько я знаю, состоит в том, что вы можете столкнуться с некоторыми ограничениями числа виртуальных машин, которые могут быть включены одновременно.

Еще одним фактором является производительность контроллера. Я не знаю вашу SAN, но большинство, если не все SAN, требуют, чтобы LUN принадлежал одному контроллеру за раз. Вы хотите, чтобы в системе было достаточно LUN, чтобы можно было сбалансировать рабочую нагрузку между контроллерами.

Например, если бы у вас был только один LUN, вы бы одновременно использовали только один активный контроллер. Другой сидел бы без дела, так как не имел ничего общего.

Если бы у вас было два LUN, но одно было гораздо более загруженным, чем другое, вы бы использовали оба контроллера, но не одинаково. По мере добавления большего количества LUN контроллеры распределяют рабочую нагрузку более равномерно.

Конкретный совет для вас:

Все ваши виртуальные машины относительно одинаковы с точки зрения требований к производительности. Я бы создал два LUN, по одному на контроллер. Начните размещать виртуальные машины на первом LUN и измеряйте задержку ввода-вывода и глубину очереди с течением времени по мере установки виртуальных машин. Пока не используйте второй LUN. Продолжайте заполнять LUN 1. Вы либо достигнете точки, когда вы начнете видеть индикаторы производительности, что LUN заполнен, либо вы переместили половину своих виртуальных машин на этот LUN, и все еще сохраняли производительность.

Если вы заметили проблемы с производительностью, я бы удалил 30% виртуальных машин из LUN 1 и переместил их в LUN 2. Затем начал бы заполнять LUN 2 таким же образом. При необходимости перейдите к LUN 3 ... это имеет смысл? Идея состоит в том, чтобы достичь максимальной плотности виртуальных машин на данном LUN вместе с примерно 30% накладных расходов для комнаты выдумки.

Я также сделал бы пару «высокопроизводительных» LUN для любых мощных ВМ. Опять же, по одному на контроллер, чтобы разделить рабочую нагрузку.

Исходя из ваших объяснений выше, вы должны быть в порядке с 1 хранилищем данных. 60 виртуальных машин более 3 хостов не так уж плохо (20: 1). Однако я рекомендую вам обновить HBA до 8 Гбит, если это возможно с финансовой точки зрения, по крайней мере на одном хосте, если ваш оптоволоконный коммутатор является как минимум 8 Гбитным коммутатором.

При этом я бы сделал как минимум 2, если не 3 хранилища данных в массиве. 1 хранилище данных на хост, причем все серверы обращаются к другим для vMotion. Я не знаю много о массиве IBM; с помощью EMC я бы создал одну группу RAID10 с 3 LUN для каждого хранилища данных. При такой настройке хост с 8-гигабайтными адаптерами HBA подойдет для ваших систем с более высоким вводом / выводом.

Вы можете сделать 1 хранилище данных / сервер, и есть некоторые случаи, когда я делаю это сам, но я делаю это только с репликацией SAN на специальных серверах. Управление 87 различными хранилищами данных на 9 серверах для vMotion приводит к путанице при настройке! Большинство моих виртуальных машин находятся в общих хранилищах данных с 5-10 серверами на них, в зависимости от того, сколько места им нужно.

Последнее замечание Если у вас есть какие-либо серверы в отказоустойчивой паре / кластере или с балансировкой нагрузки, вам понадобятся их в разных хранилищах данных. Вы не хотите, чтобы хранилище данных выходило из строя, а затем оставалось без серверов. По общему признанию, если вы потеряете массив, вы потеряли все, но именно поэтому мы резервируем, верно?