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

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

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

Насколько мне известно, у Amazon S3/CloudFront такого ограничения нет, однако для сайтов с высоким трафиком эти сервисы обходятся намного дороже, чем наша собственная серверная стойка. Есть ли наилучшая практика для разделения загрузок на нескольких дисках в нашей собственной среде?

решение1

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

Есть и другие технологии, о которых вам действительно нужно знать и использовать. Вы не указали свою ОС, но, надеюсь, это вариант Linux. В таком случае вам следует обратить внимание на LVM, который управляет дисками и, помимо прочего, имеет возможность объединять несколько дисков в один виртуальный диск — ниже уровня ОС.

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

решение2

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

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

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

  • Вы можете сэкономить на покупке материнских плат, шасси, ЦП, оперативной памяти и т. д., приобретя «сервер хранения», который представляет собой сервер корпоративного класса средней мощности, подключенный ко многим жестким дискам — либо напрямую установленным в шасси, либо подключенным через оптоволоконный канал или SAS к внешней стойке хранения, иногда содержащей жесткие диски, количество которых может быть от 60 и даже больше. В этих конфигурациях жесткие диски обычно объединяются в одно логическое устройство с помощью аппаратного RAID-контроллера или объединительной платы. Конечно, этот метод в конечном итоге достигнет максимальной емкости, если у вас есть все диски, которые вы можете поместить в одну стойку при максимальной плотности дисков, в этом случае вы можете масштабироваться, имея кластер на уровне файловой системы или системного уровня этих серверов хранения.

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

В крайнем случае, когда вам нужны тысячи терабайт избыточного хранилища, в масштабе того, что Amazon S3 предоставляет своим нижестоящим клиентам, вам, по сути, придется иметь некую кластерную систему, обычно с централизованной инфраструктурой для управления ею. В этих случаях очень быстрое межузловое сетевое взаимодействие имеет решающее значение для поддержания хорошей производительности. Определенно рассмотрите 10G ethernet как минимум.

Судя по тому, что вы сказали, вы сейчас работаете наодин жесткий дискОднако наиболее экономичным способом масштабирования отсюда, не раздувая масштаб слишком сильно, будет покупка сервера 2U или 3U, который может вместить от 4 до 8 жестких дисков, и включение в него нескольких дисков в RAID. RAID10, RAID5 и RAID6 — довольно распространенные конфигурации для такого количества дисков, но если вы выбираете RAID5/RAID6, убедитесь, что вы используете аппаратный RAID-контроллер, чтобы избежать чрезмерной нагрузки на процессор.

Вероятно, вы можете масштабировать примерно до 16 ТБ полезного хранилища (с избыточностью), используя этот метод и доступные в настоящее время диски, но имейте в виду, что диски большей емкости также, как правило, медленнее, с меньшей пропускной способностью и большим временем отклика, поэтому сайты с очень высоким трафиком, как правило, используют диски меньшей емкости... что, конечно, означает, что вам понадобится большеизчтобы достичь той же полезной емкости. :/

Связанный контент