Пока я видел статья о производительности и масштабируемости основное внимание уделяется тому, сколько времени потребуется для добавления новых ссылок. Но есть ли информация об ограничениях на количество файлов, количество папок, общий размер и т. Д.?
Прямо сейчас у меня есть один файловый сервер с миллионами файлов JPG (примерно 45 ТБ), которые используются в сети через несколько стандартных общих файловых ресурсов. Я планирую создать пространство имен DFS и реплицировать все эти образы на другой сервер для обеспечения высокой доступности. Могу ли я столкнуться с дополнительными проблемами с DFS, которых я не испытывал бы при использовании обычных файловых ресурсов? Есть ли более рекомендуемый способ воспроизвести эти миллионы файлов и сделать их доступными в сети?
РЕДАКТИРОВАТЬ 2:
Все файлы обычно записываются на диск один раз и никогда не изменяются после этого. Единственный раз, когда они изменяются, - это когда они в конечном итоге удаляются, возможно, спустя годы. Так что все довольно статично.
РЕДАКТИРОВАТЬ:
Я бы поэкспериментировал сам и напишу об этом в блоге, но у меня пока нет оборудования для второго сервера. Я хочу собрать информацию перед покупкой 45 ТБ места на жестком диске ...
Имея 45 ТБ данных, вы превышаете проверенные ограничения DFS-R на Server 2008, согласно:
Размер всех реплицируемых файлов на сервере: 10 терабайт.
Количество реплицируемых файлов на томе: 8 миллионов.
Максимальный размер файла: 64 гигабайта.
Редактировать:
Если ваши файлы, скорее всего, никогда не изменятся, вы можете использовать часть пространства имен DFS для создания виртуализированного пути для вашего общего ресурса. Затем вы можете запустить robocopy в запланированной задаче для синхронизации серверов. Вам нужно будет использовать что-то вроде robocopy для начальной синхронизации, даже если вы собираетесь использовать DFS-R.
В настоящее время мы используем 2008 R2 DFSR с 57 ТБ реплицированных файлов (1,6 миллиона), а общий размер тома превышает 90 ТБ без каких-либо проблем.
Таким образом, проверенные MS ограничения в этом отношении немного наивны, и имхо, им следует купить больше дискового пространства и провести еще несколько тестов. Если вы не критичны по времени при начальной синхронизации, DFSR тоже может это сделать. Что ему особенно не нравится, так это то, что один и тот же файл изменяется на нескольких хостах, поскольку он должен выполнять арбитраж, чтобы сохранить.
«Есть ли более рекомендуемый способ реплицировать эти миллионы файлов и сделать их доступными в сети?» Да - либо устройство SAN или NAS для их централизации, либо распределенное хранилище, такое как Isilon, Gluster и т. Д. DFS - это хорошо, но это означает, что на каждом сервере есть полная копия всего, поэтому это не очень хорошая архитектура, если вам нужно масштабировать намного больше.
Кроме того, ваша архитектура в любом случае может испытывать трудности с масштабированием. Я видел несколько больших систем изображений, которые не хранятся в виде файлов - у них есть база данных, в которой хранятся метаданные и байтовые смещения изображений, и они сворачиваются в большие двоичные файлы, которые распределяются таким образом, чтобы диск и файловая система. Требуется изображение, и он найдет файл большого двоичного объекта и вытащит из него изображение с начальным и конечным байтами.