ASP.NET, достижение пределов DFSR и сегментирование хранилища файлов

Мы запускаем популярное веб-приложение, и наше внутреннее файловое хранилище существует на файловом сервере, реплицированном на другой файловый сервер для переключения при отказе с помощью DFSR. Мы приближаемся к теоретическим пределам DFSR и, следовательно, должны начать рассматривать сегментирование нашего хранилища.

Как лучше всего использовать шардинг? Я знаю, что мы можем абстрагироваться от нашего файлового хранилища на уровне приложения, но, среди прочего, мне непонятно, как сторонние элементы управления, взаимодействующие с файловой системой, смогут подключиться к этой абстракции. Какие лучшие техники вы видели или могли придумать? Предположим, что у нас есть структура каталогов, такая как / Customers / bikesystems, / Customers / 10degrees и т. Д. Один большой каталог данных о клиентах, где у каждого клиента есть собственная папка в этом каталоге / Customers.

Вначале я решил разбить этот более крупный каталог клиентов на более иерархическую структуру, например, в / Customers / b / bikesystems, / Customers / 1 / 10degrees (беря первую букву или номер каждого идентификатора клиента), что дает мне возможность для создания пространств имен DFS для каждого первого символа, составляющего идентификатор клиента (который для вас, ребята, является [a-z0-9]). Итак, потенциальных 36 пространств имен DFS. Затем я могу перетасовать эти пространства имен по разным серверам по мере увеличения емкости любого из них. И это дало бы мне гораздо больше передышки, прежде чем я достигну теоретических пределов DFSR.

Это лучший подход?

Я знаю, что мы могли бы рассмотреть Linux или другие системы хранения корпоративного уровня (Isilon и т. Д.). Однако для этого обсуждения я хотел бы пока ограничить обсуждение Windows. Если, конечно, у вас нет горячего желания вообще превозносить преимущества другого решения, и вы хотели бы помочь мне увидеть свет!