Изображения в среде с балансировкой нагрузки

Question

У меня есть среда с балансировкой нагрузки, в которой более 10 веб-серверов работают под управлением IIS.Все веб-сайты имеют доступ к единому файловому хранилищу, в котором хранятся все изображения.На данный момент у нас есть 200 ГБ изображений — мы храним их в каталогах по 1000 изображений в каждом каталоге.Сейчас все изображения находятся на одном устройстве хранения (RAID 10), подключенном к одному серверу, который служит файловым сервером.Все веб-серверы подключены к файловому серверу в одной локальной сети.Я хочу улучшить архитектуру, чтобы у нас не было единой точки отказа.Я рассматриваю два варианта:

1. Реплицируйте хранилище файлов на все веб-серверы, чтобы все они имели доступ к данным локально.
2. реплицировать файловое хранилище в другое хранилище, чтобы, если что-то случится с текущим хранилищем, мы могли переключиться на него.

Очевидно, что основные операции, выполняемые с файловым хранилищем, — это чтение, но есть также множество операций записи.Как вы думаете, какой метод предпочтительнее?Есть еще идеи?

В настоящее время я исключаю использование CDN, поскольку это потребует изменения архитектуры приложения, которое мы не можем сделать прямо сейчас.

Answer 1

Прежде чем приступить к смене арки, я обычно рассматриваю некоторые вещи:

1. каковы проблемы текущей арки
2. что я делаю не так с текущей аркой. (если это работало какое-то время, небольшие настройки обычно решают множество проблем)
3. позволит ли это мне легко расти (здесь всегда будет верхний предел).Основываясь на прошлом росте данных, вы можете эффективно его планировать.
4. надежность
5. простота обслуживания/мониторинга/устранения неполадок
6. расходы

200 ГБ — это не так уж много данных, и вы можете использовать какое-нибудь домашнее решение или использовать что-то вроде NAS, что позволит вам расширить его в дальнейшем.И иметь его копию с возможностью горячей замены.

Репликация в хранилище всех веб-серверов — это очень дорогая установка, и, как вы сказали, существует много операций записи, при репликации на все серверы будут большие накладные расходы (которые будут только увеличиваться с увеличением количества серверов и роста данных). ).Также существует проблема устаревших данных, обслуживаемых одним из других узлов.Помимо этого, устранение проблем с репликацией будет затруднительно с 10 и растущими узлами.Если поиск/чтение/запись файлов не очень критичны по времени, репликация на все веб-серверы не является хорошей идеей.Пользователи (в Интернете) вряд ли заметят разницу во времени загрузки в 100–200 мс.

Answer 2

Есть некоторые предприятие решения для такого рода вещей.Но я не сомневаюсь, что они дорогие.NAS плохо масштабируется.И у вас есть одна точка отказа, что нехорошо.

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

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

Answer 3

Поскольку в вашем хранилище так мало данных, имеет смысл купить несколько больших HD-дисков или использовать свободное место на веб-серверах для хранения копий.Это снизит нагрузку на вашу серверную систему хранения, и в случае ее сбоя вы все равно сможете доставлять контент своим пользователям.Более того, если вам нужно масштабироваться (больше загрузок), вы можете просто добавить новый сервер, и нагрузка на ваш бэкэнд не сильно изменится.

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

Время от времени запускайте rsync (например, после любой загрузки или однажды ночью;вы будете лучше знать, какие размеры подходят вам лучше всего).

Более универсальным решением было бы использование протокола P2P, такого как Bittorreent.Таким образом, вы можете публиковать все изменения в серверной части хранилища на веб-серверах, и они автоматически оптимизируют обновления.