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