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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

Некоторые вещи, которые я обычно рассмотрел бы перед переходом на смену арки:

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

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

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