Назад | Перейти на главную страницу

хранить большое количество фотографий (150 миллионов) и размещать их в Интернете

Для реального проекта я должен настроить сервер хранения с высокой доступностью, который может хранить и публиковать (http) 150 миллионов фотографий 7 размеров, что означает всего 1050 миллионов файлов. Для каждой фотографии нам нужно в общей сложности 200 КБ места, чтобы хранить их всех 7 размеров в общей сложности 28 ТБ.

На самом деле у меня есть два доступных сервера (2x E5620, 12GB Ram, Raid Controller 1 GB NV Cache, 2x160 GB Disk для ОС), оба подключили массив хранения (DAS) с дисками SAS 12x3TB.

Я не уверен, что моя запланированная установка действительно лучшее решение:

ОС: RHEL 6

Дисковый массив: Raid 6, ext4 / rsync или gfs2

HTTP-сервер: Apache Traffic Server 3 или nginx

Таким образом, сервер хранит и публикует фотографии.

Какой-нибудь совет для меня? При необходимости я могу добавить больше серверов. Какая файловая система подходит? Raid 6 в порядке?

РЕДАКТИРОВАТЬ: неправильно прочитали требования к хранилищу!

Я бы использовал как минимум 2 + k + n серверов.

  • 2 сервера являются балансировщиками нагрузки с keepalived, работающий в чистом аварийном переключении (или что-то еще, что плавает на вашей лодке) - я предполагаю, что доступны 1GigE-Connections и которые могут обрабатывать чертовски много простых запросов GET, если вы используете прямой возврат для своей конфигурации IPVS
  • k Серверы являются Frontend HTTP-серверами, HTTP-сервером будет nginx с некоторым дополнительным разделом для локального кеша. k зависит от объема трафика, который вы ожидаете обслужить (см. ОТКРЫТЫЕ ВОПРОСЫ ниже)
  • n Серверы, настроенные с помощью glusterfs для хранения данных. Таким образом, вы можете начать с двух серверов GlusterFs и протестировать свою настройку. Поскольку вы храните только довольно маленькие файлы, нет необходимости разделять один файл на несколько серверов, GlusterFS подойдет. Локальный кеш на фронтах должен быть в состоянии преодолеть любые проблемы со скоростью, поскольку количество обращений к файлам обычно составляет менее 5% (но я не знаю вашего варианта использования - это просто дикие догадки). n легко вычисляется. И да, это всего лишь пример, я не пишу этого, потому что я думаю, что вы не можете этого сделать, но я часто забываю об очевидных частях ...
    • Возьмите один сервер хранения с 8 дисками по 500 ГБ. Дает вам около 6 * 500 ГБ хранилища (RAID6) по 3 ТБ на сервер,
    • 10 серверов - это 30 ТБ хранилища (2 ТБ зарезервировано для начального роста). У вас сейчас нет избыточности,
    • поэтому добавьте еще 10 серверов, и вы с GlusterFS можете настроить его на хранение 2 копий каждого файла, чтобы любой из серверов хранения мог выйти из строя в любое время, и ничего плохого не произойдет.
    • это легко расширить, просто добавив больше серверов, просто согрейтесь с GlusterFS, и все должно быть в порядке.
  • монтировать серверы хранения на внешних интерфейсах: начать с радостью обслуживать контент

ОТКРЫТЫЕ ВОПРОСЫ (и вопросы о прикрытии): (не знаю, понятны ли вам требования)

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

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

НОТА Я предполагаю, что у вас есть система резервного копирования, которая займет 28 ТБ, если не добавить другую систему хранения с необходимой избыточностью для обработки худших вариантов. Добавьте внешнюю резервную копию, чтобы справиться с тем, что произойдет, если вы забудете какой-то худший сценарий.

В конце концов, звучит не слишком сложно. Интересный вопрос: Готово ли ваше руководство тратить деньги?

Почему бы не сохранить один большой файл и не попросить сервер преобразовать его в требуемый размер по запросу, а затем сохранить в кеше? Также рассмотрите возможность запуска нескольких внешних серверов (через балансировщик нагрузки) для обслуживания запросов, а затем, возможно, использования NAS или нескольких других серверов для обслуживания статического контента. Количество необходимых интерфейсов зависит от того, сколько трафика вы получите (емкость YouTube или просто хранение контента для случайных обращений).