В моей сети у меня есть несколько типов файлов, которые я хочу сохранить в SAN, например:
Теперь мне интересно, должен ли я создать одну цель iSCSI с большим объемом и инициировать ее с одного из серверов. (и поделитесь им, чтобы другие серверы тоже могли его использовать)
Или я должен создать отдельные цели, чтобы каждый сервер использовал свое собственное хранилище.
Для записи хранилище может быть разделено, потому что серверы не используют общие данные. Я думал об одном хранилище по одной причине - это простота резервного копирования. (но, возможно, производительность может быть проблемой?)
Какая конфигурация рекомендуется для этого типа данных?
Вам нужно будет делать отдельные цели. NTFS не является кластерной файловой системой, поэтому наличие нескольких ящиков, записывающих на один и тот же диск, приведет к уничтожению вашей файловой системы или, по крайней мере, файлов в вашей файловой системе, поскольку они не будут знать, что делают другие системы.
Причины одиночной цели
Причина одна: нет фрагментации дискового пространства.
Нет необходимости заранее планировать мощности. Как указывает @Zypher, NTFS не является кластерной файловой системой, поэтому у вас будет только один инициатор, взаимодействующий с целью.
Вы можете настроить хост-инициатор как хост CIFS, чтобы другие серверы могли совместно использовать хранилище. Поскольку многие механизмы баз данных, такие как SQL Sever 2005, отказываются работать с томами сетевого хранилища, лучшим кандидатом на роль инициатора является хост БД. Обмен и файловое хранилище могут использовать CIFS.
Причины нескольких целей
Если какой-либо отдельный сервер выйдет из строя, остальные будут работать, как будто ничего не произошло.
CIFS или NFS не могут обеспечить задержку так же хорошо, как блочное хранилище.
Многие дисковые массивы в настоящее время имеют такие опции, как тонкое обеспечение Это позволяет легко превратить несколько логических томов в одну область хранения, чтобы каждый том мог расти до тех пор, пока в области хранения не останется свободного места, без какого-либо вмешательства со стороны администратора хранилища или операционной системы хоста.
Случайные файлы, вероятно, не так критичны для бизнеса, как DB или Exchange, и их сложнее спланировать емкость. Может быть дешевле разместить их на уровнях емкости, тогда как файлы базы данных предпочтительнее располагать на уровне производительности, если только база данных не мала и не работает из памяти.
Даже без тонкого предоставления логические тома могут быть расширены в соответствии с ростом объема данных, но для этого потребуется взаимодействие от имени администратора хранилища и администраторов серверов.
Вывод
Если вы можете запланировать емкость заранее, или в системе хранения есть опция тонкого выделения ресурсов, или если важно многоуровневое хранение, рекомендуется выбрать несколько целей. Если ничего из этого не подходит, выбор единственной цели, разделяющей ее с CIFS, может быть жизнеспособным вариантом.