Какое лучшее решение для хранения файлов для приложения ASP.NET с балансировкой нагрузки?

Question

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

В нашей текущей настройке мы указываем на общий ресурс на первичной базе данных / файловом сервере. В течение дня мы выполняем повторное копирование содержимого общего ресурса на основном сервере для восстановления после отказа. Это scneario гарантирует, что у нас есть вторичный компьютер с достаточно текущими данными на нем, но мы хотим добраться до точки, где мы можем переключаться с основного на аварийное переключение и обратно без потери данных или ошибок во внешнем приложении. Сейчас это довольно ручной процесс.

Возможные решения включают в себя:

• Robocopy. Простой, но он не позволяет легко переключаться назад и назад без одновременного выполнения нескольких заданий (копирование данных назад и вперед)
• Храните файл в BLOB в SQL Server 2005. Я думаю, что это может быть проблемой производительности, особенно с большими файлами.
• Используйте тип FILESTREAM в SQL Server 2008 . Мы отражаем нашу базу данных, поэтому это может показаться многообещающим. У кого-нибудь есть опыт с этим?
• Распределенная файловая система Microsoft . Похоже, излишнее из того, что я прочитал, поскольку у нас есть только 2 сервера для управления.

Итак, как вы обычно решаете эту проблему и что является лучшим решением?

Answer 1

Рассмотрим облачное решение, подобное AWS S3 . Это плата за то, что вы используете, масштабируемая и имеет высокую доступность.

Answer 2

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

Если вы не воспринимаете DFS как жизнеспособный подход, возможно, вы захотите рассмотреть Отказоустойчивая кластеризация вашего уровня файлового сервера , при которой ваши файлы хранятся во внешнем общем хранилище (не дорогой SAN, которая Я считаю, что это слишком для вашего случая, так как DFS уже вне вашей досягаемости) подключен между активными и пассивными файловыми серверами. Если активный файловый сервер выходит из строя, пассивный может вступить во владение и продолжить чтение / запись в общее хранилище. Драйвер кластерного диска Windows 2008 был улучшен по сравнению с Windows 2003 для этого сценария (согласно статье), что указывает на необходимость решения для хранения, поддерживающего команды SCSI-3 (PR).

Answer 3

Вам нужен SAN с RAID. Они строят эти машины для безотказной работы.

Это действительно вопрос ИТ ...

Answer 4

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

Учитывая вышесказанное, я склонен использовать решение для хранения данных на SQL Server, так как это уменьшает сложность вашей системы, а не увеличивает ее.

Пройдите несколько тестов, чтобы выяснить, будет ли в первую очередь проблема с производительностью.

Answer 5

Полагаю, это зависит от типа загружаемого файла, который вы увидите. Я храню файлы в столбце Изображение SQL Server 2005 с большим успехом. Мы не видим большого спроса на эти файлы, поэтому производительность в нашей конкретной ситуации не так уж велика.

Одним из преимуществ хранения файлов в базе данных является то, что это делает аварийное восстановление быстрым. Также становится намного проще управлять разрешениями на файлы, поскольку мы можем управлять ими в базе данных.

В Windows Server есть служба репликации файлов, которую я бы не рекомендовал. Мы использовали это в течение некоторого времени, и это вызвало много головных болей.

Answer 6

Я согласен с Омар Аль Забир на веб-сайтах высокой доступности:

Do: использовать сеть хранения данных (SAN)

Почему: производительность, масштабируемость, надежность и расширяемость. SAN это оптимальное решение для хранения. SAN это гигантский ящик с сотнями дисков внутри него. У него много дисков контроллеры, много каналов передачи данных, много кеш памяти. У вас есть конечная гибкость конфигурации RAID, добавив столько дисков, сколько вам нравится в RAID, совместное использование дисков в нескольких RAID конфигурации и тд. SAN имеет более быстрые дисковые контроллеры, более параллельные вычислительная мощность и больше дискового кеша памяти, чем обычные контроллеры, которые вы положили внутри сервера. Итак, вы получаете лучшая пропускная способность диска при использовании SAN поверх локальных дисков. Вы можете увеличить и уменьшить объемы на лету, в то время как ваше приложение работает и использует объем. SAN может автоматически отражать диски и при сбое диска, это автоматически поднимает зеркала диски и перенастраивает RAID.

Полный текст статьи в CodeProject.

Поскольку у меня сейчас нет личного бюджета на SAN, я полагаюсь на вариант 1 (ROBOCOPY) из вашего поста. Но файлы, которые я сохраняю, не являются уникальными и могут быть воссозданы автоматически, если по какой-то причине они умирают, поэтому в моем случае необходима абсолютная отказоустойчивость.