Обслуживание изображений, где бы вы ни решили их хранить, является тривиальной проблемой; Я не буду обсуждать, как это решить.
Решение о том, где их хранить, является реальным решением, которое вам нужно принять. Вам нужно подумать о своих целях:
- Резервирование оборудования
- Много дешевого хранения
- Read-масштабирование
- Write-масштабирование
Последние два не совпадают и определенно вызовут проблемы.
Если вы уверены, что размер этой библиотеки изображений не будет превышать размер диска, который вы с удовольствием поместите на свои веб-серверы (скажем, 200 ГБ на момент написания, как самый большой высокоскоростной серверный диск, который можно получить; я предполагаю, что вы хотите использовать веб-серверы 1U, чтобы вы не могли хранить больше, чем в raid1, в зависимости от вашего поставщика), тогда вы можете получить очень хорошее масштабирование при чтении, разместив копию всех изображения на каждом веб-сервере.
Конечно, вы, возможно, захотите также хранить мастер-копию где-нибудь, и иметь демон или процесс, который время от времени синхронизирует их, и иметь мониторинг для проверки того, что они остаются в синхронизации, и этот демон работает, но это детали. Хранение копии на каждом веб-сервере сделает масштабирование чтения практически идеальным.
Но хранение копии везде повредит масштабируемости при записи, так как каждый веб-сервер должен будет записывать каждый измененный / новый файл. Поэтому общая пропускная способность записи будет ограничена самым медленным одиночным веб-сервером в кластере.
«Разделение» данных изображения между многими серверами обеспечит хорошую масштабируемость чтения / записи, но это нетривиальное упражнение. Это также может позволить вам использовать дешевое (ish) хранилище.
Наличие одного центрального сервера (или активной / пассивной пары или чего-либо) с дорогостоящим оборудованием ввода-вывода обеспечит лучшую пропускную способность записи, чем везде использование «дешевого» оборудования ввода-вывода, но тогда вы будете ограничены масштабируемостью чтения.