Мой вопрос относится конкретно к ZFS / COMSTAR, но я предполагаю, что он обычно применим к любой системе iSCSI.
Следует ли создавать цель для каждого LUN, который вы хотите открыть? Или это хорошая практика - иметь одну цель с несколькими LUN?
Влияет ли любой подход на производительность? И есть ли какая-то точка пересечения, где другой подход имеет смысл?
Вариант использования - для дисков виртуальной машины, где каждый диск (zvol) является LUN. До сих пор мы создали отдельную цель для каждой виртуальной машины; но одна цель, которая содержит все LUN, вероятно, значительно упростит управление ... но нам могут потребоваться сотни LUN на одну цель. (И затем, возможно, десятки подключений инициатора к этой цели)
Лучше всего, чтобы несколько LUN зависали от одной цели. Общее количество целей различается, а также сколько из этих целей фактически используют одни и те же LUN. Я обычно рекомендую одну цель для каждого пути MPIO, который будут настраивать ваши клиенты, поэтому, если я настраиваю систему, будет как минимум 2 цели (но они просто являются частью одной целевой группы и группы целевого портала и предлагает те же представления - это полностью для iSCSI MPIO).
Единственная причина для выхода за пределы двух целей - это, как правило, логическое разделение, вызванное давлением бизнеса, сети или других конкретных вариантов использования. 4, 8 и даже до 16 целей - это не так уж и сложно, в зависимости от размера и сложности среды. Если вам больше 16, особенно много, возрастает вероятность того, что у вас есть ошибка в архитектуре, и вам следует привлечь эксперта для проверки. Если вы используете iSCSI MPIO (и вы должен, потому что, если вы не используете iSCSI MPIO, вероятно, единственная крупная победа zvols и iSCSI над файловыми системами и NFS потеряна, и теперь у перехода на iSCSI через NFS очень мало преимуществ, а также множество недостатков), вам также следует обычно имеют четное количество целей (2, 4, 6, 8 и т. д.), при этом каждая пара предлагает одинаковые представления (LUN).
Также имейте в виду, что «КОМСТАР» достаточно умен в том, как он обрабатывает представления, и до тех пор, пока вы действительно создаете и назначаете целевые группы и группы хостов надлежащим образом, у вас может быть одна цель, предлагающая потенциально десятки или даже сотни LUN, где фактический идентификатор LUN доступный для входящего инициатора (клиента) НЕ 578 или что-то еще, но вместо этого может быть всего 0 для каждого из них. Это важно при работе с некоторыми клиентскими ОС, такими как Linux (особенно в старых версиях), которые имеют неприятную привычку автоматически обнаруживать и назначать устройства для каждого найденного LUN, И имеют максимальное количество LUN, с которыми они могут справиться. И иметь максимальный «номер LUN» (фактический номер LUN, а не количество видимых LUN).
Я никогда не тратил время на его количественную оценку, но моя инстинктивная реакция будет такова, что вы почувствуете либо такое же влияние на производительность со 128 целями, каждая с 1 LUN, как с 1 целью со 128 LUN, либо немного хуже производительность со 128 мишенями. Определенно ожидание от «КОМСТАР» заключается в том, что вы настраиваете цели с несколькими LUN, а не по одному LUN на цель, как это было раньше до «КОМСТАР».
К комментарию о вашем окружении в целом:
Следует создавать отдельный LUN для каждой виртуальной машины только в ситуациях, когда общее количество виртуальных машин невелико (менее 100, предпочтительно менее 50) ИЛИ когда у вас нет в уме высокой доступности, которая потребовала бы экспорта / импорта пула в ситуациях, когда службы отключены, пока пул экспортирует / импортирует.
Это связано с тем, сколько времени потребуется для экспорта / импорта и полной инициализации группы LUN через COMSTAR через ZFS. Каждый дополнительный zvol добавляет X миллисекунд ко времени импорта. Ничего страшного с парой дюжин, но быстро вызывает заметную проблему при масштабировании до 1000. Раньше я управлял Sun 7410 с более чем 3000 зволей, которые занимали большую часть 15 минут чтобы выполнить аварийное переключение с использованием своих функций кластеризации (которые, по сути, экспортируют пул с одного узла и импортируют его на другом при выполнении аварийного переключения вручную, как это было в случае 15-минутного чудовища). Во многом это было связано с количеством наборов данных, и, более того, они были zvols. Тот же самый сценарий, повторенный с 3000 файловыми системами (не zvols), занял всего 5 минут (все еще долго, но уже в 3 раза короче, и это было много лет назад. В то время как общее время выполнения этих задач в ZFS с годами увеличилось, относительное время разница между zvols и файловыми системами и время до полного импорта и выхода в онлайн остаются, последний раз я проверял.
Теперь, если у вас нет 2 или более узлов в вашей настройке и вы ожидаете быстрого экспорта и импорта между ними, самая большая причина не иметь большого количества zvols исчезла. Это все еще не делает тысячи из них особенно хорошей идеей по множеству других причин, не имеющих прямого отношения к вашему вопросу. Блага, которые вы получаете, имея их отдельно, в некоторой степени компенсируются административными проблемами и проблемами, связанными с производительностью, вызванными наличием тонны зволов. За свои деньги я настоятельно рекомендую использовать NFS, даже если (черт возьми, особенно если) вам нужен один набор данных для каждой виртуальной машины.
Несколько целей увеличивают вашу потенциальную поверхность. На самом деле это зависит от количества ссылок, которые ваши коммутаторы имеют к хранилищу, и, возможно, от количества ссылок между выделенными коммутаторами iSCSI, которые вы должны использовать.
Это связано с хешированием и балансировкой нагрузки, а также с количеством путей, которые вы хотите видеть. В идеале, если у вас есть четыре ссылки от вашего целевого устройства к сети, у вас должно быть четыре IP-адреса и, возможно, пятый используется для «обнаружения» целей.
Так что единственный реальный ответ: это зависит от обстоятельств.