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