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

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

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

Я предполагаю, что вы собираетесь виртуализировать серверы, а не рабочие столы, хорошо? Далее я предполагаю, что вы собираетесь использовать несколько серверов 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 или около того.

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

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

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

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

Another consideration is controller performance. I don't know your SAN specifically, but most if not all SANs required that a LUN is owned by a single controller at a time. You want to have enough LUNs on the system so that you can balance out your workload between controllers.

For example, if you had only one LUN, you'd only be using one active controller at a time. The other would sit idle as it would have nothing to do.

If you had two LUNs, but one was much busier than the other, you'd be using both controllers but not equally. As you add more LUNs the controllers share the workload more evenly.

Specific advice for you:

Your VMs are all relatively the same in terms of performance requirements. I'd create two LUNs, one per controller. Start putting VMs on the first LUN, and measure your I/O latency and queue depth over time as the VMs settle in. Don't use the second LUN yet. Continue filling up LUN 1. You will either reach a point where you start to see performance indicators that the LUN is full, or you will have migrated half of your VMs to that LUN, and still have maintained performance.

If you do see performance issues, I'd remove 30% of the VMs from LUN 1 and move them to LUN 2. Then start filling up LUN 2 in the same manner. Go to LUN 3 if necessary... does that make sense? The idea is to achieve maximum VM density on a given LUN along with a roughly 30% overhead for fudge room.

I would also make a pair of "high performance" LUNs for any heavy hitting VMs. Again, one per controller to share the workload.

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

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

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

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

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

Предлагаю вам заглянуть сюда 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-practice-and-counter-fud.html ). Это дает преимущество управления одним или несколькими хранилищами данных в vSphere, и, поскольку vSphere автоматически балансирует виртуальные машины по доступным экстентам, начиная с первого блока каждого экстента, выигрыш в производительности достигается за счет распределения операций ввода-вывода на несколько LUN.

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

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

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

Все дело в том, чтобы объединить аналогичные шаблоны ввода-вывода, чтобы использовать преимущества механического поведения базовых дисков, чтобы, например, записи журнала в одной виртуальной машине не влияли на скорость чтения из Интернета в другой виртуальной машине.

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

Все дело в том, чтобы объединить аналогичные шаблоны ввода-вывода, чтобы использовать преимущества механического поведения базовых дисков, чтобы, например, записи журнала в одной виртуальной машине не влияли на скорость чтения из Интернета в другой виртуальной машине.

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

t влияют на скорость чтения из Интернета на другой виртуальной машине.

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

t влияют на скорость чтения из Интернета на другой виртуальной машине.

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

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

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