хранить большое количество фотографий (150 миллионов) и сделать их доступными для Интернета [закрыто]
Для реального проекта я должен настроить сервер хранения с высокой доступностью, который может хранить и публиковать (http) 150 миллионов фотографий в 7 размерах, то есть всего 1050 миллионов файлов. Для каждой фотографии нам нужно в общей сложности 200 КБ места, чтобы хранить их всех 7 размеров в общей сложности 28 ТБ.
На самом деле у меня есть два доступных сервера (2x E5620, 12 ГБ оперативной памяти, Raid Controller 1 ГБ NV кэш, 2x160 ГБ диск для ОС), оба подключили массив хранения (DAS) с дисками SAS 12x3 ТБ.
Я не уверен, что моя запланированная установка действительно лучшее решение:
ОС: RHEL 6
Дисковый массив: Raid 6, ext4 / rsync или gfs2
HTTP-сервер: Apache Traffic Server 3 или nginx
Таким образом, сервер хранит и публикует фотографии.
Что-нибудь посоветуете? При необходимости я могу добавить больше серверов. Какая файловая система подходит? Raid 6 в порядке?
Почему бы не сохранить один большой файл и попросить сервер по запросу преобразовать его в требуемый размер, а затем сохранить в кеше? Также рассмотрите возможность запуска нескольких внешних серверов (через балансировщик нагрузки) для обслуживания запросов, а затем, возможно, использования NAS или нескольких других серверов для обслуживания статического контента. Количество необходимых интерфейсов зависит от того, какой объем трафика вы получите (емкость YouTube или просто хранение контента для случайного доступа).
РЕДАКТИРОВАТЬ: Неправильно прочитаны требования к хранилищу!
Я бы использовал как минимум 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 ТБ, если не добавить другая система хранения с необходимой избыточностью для обработки худших вариантов. Добавьте внешнюю резервную копию, чтобы справиться с тем, что произойдет, если вы забудете какой-то худший сценарий
В конце концов, это не звучит слишком сложно. Интересный вопрос: Готово ли ваше руководство тратить деньги?