Поскольку VMFS5 больше не имеет ограничения в 2 ТБ для тома VMFS, я рассматриваю, какой сценарий был бы более выгодным в целом: -
В моем случае у меня есть новый массив хранения на 24 диска с дисками 600 ГБ. Я буду использовать RAID10, то есть примерно 7,2 ТБ, и попытаюсь решить, использовать ли 1 большое хранилище данных 7 ТБ или несколько хранилищ по 1 ТБ каждое.
Каковы плюсы и минусы каждого подхода?
Обновить: Конечно, я не учел горячие резервы в своих расчетах, так что это будет чуть меньше 7,2 ТБ, но общая идея та же. :-)
Обновление 2: Есть 60 виртуальных машин и 3 хоста. Ни одна из наших виртуальных машин не требует особо интенсивного ввода-вывода. Большинство из них - это веб-серверы / серверы приложений, а также такие вещи, как мониторинг (munin / nagios), 2 контроллера домена Windows с минимальной нагрузкой и т. Д. Серверы БД виртуализируются редко, если у них ОЧЕНЬ низкие требования к вводу-выводу. Прямо сейчас я думаю, что единственный виртуальный сервер БД, который у нас есть, - это ящик MSSQL, а размер БД в этом поле <1 ГБ.
Обновление 3: Дополнительная информация о массиве и подключении FC. Массив представляет собой IBM DS3524, 2 контроллера с кэш-памятью 2 ГБ каждый. 4 порта FC 8 Гбит на контроллер. Каждый хост ESXi имеет 2 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 автоматически балансирует виртуальные машины по доступным экстентам, начиная с первого блока каждого экстента, выигрыш в производительности достигается за счет распределения операций ввода-вывода между несколькими LUN.
Есть еще кое-что, что нужно учитывать ... Вы говорите, что ни одна из виртуальных машин не требует особенно интенсивного ввода-вывода. Учитывая это, вы можете рассмотреть комбинацию RAID5 и RAID10, чтобы получить лучшее из обоих миров (пространство и скорость).
Кроме того, если у вас есть виртуальные машины, настроенные с несколькими VMDK, с шаблонами ввода-вывода ОС и приложений, распределенными по этим виртуальным дискам (например, ОС, Интернет, БД, журналы и т. Д., Каждый на отдельном VMDK), вы можете затем найти каждый VMDK на другое хранилище данных, чтобы соответствовать возможностям ввода-вывода этого физического LUN (например, ОС на RAID5, журналы на RAID10). Все дело в том, чтобы объединить аналогичные шаблоны ввода-вывода, чтобы использовать преимущества механического поведения базовых дисков, чтобы, например, записи журнала в одной виртуальной машине не влияли на скорость чтения из Интернета в другой виртуальной машине.
FYI ... вы жестяная банка успешно виртуализировать серверы БД, вам просто нужно проанализировать шаблоны ввода-вывода и скорость ввода-вывода и нацелить этот ввод-вывод на подходящий LUN; все время осознавая шаблоны ввода-вывода и операции ввода-вывода в секунду, которые этот LUN уже выполняет. Вот почему многие администраторы винят виртуализацию в низкой производительности БД ... Oни не тщательно рассчитывал IO / IOPS, которые несколько серверов будут генерировать, когда Oни поместите их на общий 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 для каждого хранилища данных. При такой настройке хост с HBA-адаптерами 8 Гбайт отлично подойдет для ваших систем ввода-вывода более высокого уровня.
Вы можете сделать 1 хранилище данных / сервер, и в некоторых случаях я делаю это сам, но я делаю это только с репликацией SAN на специальных серверах. Управление 87 различными хранилищами данных на 9 серверах для vMotion становится запутанным, когда вы его настраиваете! Большинство моих виртуальных машин находятся в общих хранилищах данных с 5-10 серверами на них, в зависимости от того, сколько места им нужно.
И последнее замечание. Если у вас есть какие-либо серверы в паре / кластере аварийного переключения или с балансировкой нагрузки, вы захотите, чтобы они находились в разных хранилищах данных. Вы же не хотите, чтобы хранилище данных вышло из строя и осталось без серверов. По общему признанию, если вы потеряете массив, вы потеряете все, но именно поэтому мы делаем резервную копию, верно?