Мне нужно сохранить 25 млн фотографий в 4 размерах = всего 100 млн файлов, размер файла будет варьироваться от 3 КБ до 200 КБ на файл, а используемый объем хранилища в начале составит около 14–15 ТБ.
Наша цель — сделать данные доступными на 2–4 серверах и обслуживать их с помощью локального быстрого веб-сервера (nginx или lighthttpd), нам необходимо обработать как можно больше запросов в секунду.
Мой план - использовать 2U Servercase от Intel с 12x2 ТБ (WD RE4) с Raid 6 (или FS с избыточностью??) для данных и 2x60 ГБ SSD для ОС, это хороший способ? Итак: я нашел Adaptec 5805ZQ, который может использовать SSD SLC Drives для кэширования наиболее часто используемых файлов, есть какие-нибудь предложения по нему?
Какой размер кэша чтения мне следует выбрать?
Какой будет наилучший способ обеспечения избыточности и балансировки нагрузки, если я планирую иметь 2–4 таких сервера?
Каковы преимущества и недостатки кластера и распределенной файловой системы относительно нашей цели?
решение1
Если это строительство с нуля, тоЯ бы обязательно использовал облако для этого.Файлы объемом 100 МБ — это очень много данных; было бы большим улучшением перенести избыточное хранилище на Amazon S3.
Учитывая, что мы говорим о файлах размером 100 М, я считаю, что можно с уверенностью сказать, что некоторые части набора данных будут «горячими» (часто запрашиваемыми), а большинство частей будут «холодными». Поэтому нам действительно нужно кэширование.
Обзор того, как это можно сделать на Amazon Web Services:
- Первый слой:Elastic Load Balancing под управлением Amazon и мониторинг Amazon CloudWatch для пары небольших экземпляров EC2 с nginx или Apache. Эти серверы — просто тупые балансировщики нагрузки со статическими файлами конфигурации, поэтому Cloudwatch может следить за ними для нас и автоматически создавать новые экземпляры, если один из них выходит из строя.
- Из первого слоя:Последовательное ускорение на основе URL-адреса запроса (имени файла)на уровень серверов кэширования. Вам нужно хеширование на основе имени файла, чтобы гарантировать, что каждый файл не кэшируется много раз (что снижает частоту попаданий в кэш), а вместо этого с N серверами кэширования каждый сервер обрабатывает 1/N адресного пространства.
- Второй слой:Кэш-сервер(ы). Ваши кэш-серверы — это экземпляры EC2 с большим объемом памяти, а также Squid или Varnish илиСервер трафика Apacheкэш установлен.
- На втором уровне: обычный HTTP-сервер для хранения файлов Amazon S3.
Поскольку эта установка слабосвязана,масштабировать его по горизонтали легко(по мере возникновения проблем масштабирования).
Насколько быстро это будет, во многом зависит от соотношения между горячими и холодными данными. Если ваша рабочая нагрузка в основном горячая, то я не удивлюсь, если увижу намного больше 10.000 req/s всего от 2 небольших балансировщиков нагрузки EC2 и 2 экземпляров EC2 с кэшем большой памяти.
решение2
SSD для самой ОС — это излишество, если только вы не хотите загружать 30-е быстрее. Просто купите пару небольших дисков SAS, и этого будет более чем достаточно.
Что касается кэша, полезность кэша зависит от рабочего набора. То есть, ожидается ли, что запросы на изображения будут равномерно распределены по всем изображениям, или вы ожидаете, что большинство запросов будут для небольшого подмножества? В последнем случае кэш может быть полезен, в первом — не очень. Обратите внимание, что кэш на контроллере диска полезен в основном для кэширования записей (если кэш не энергозависимый), что полезно для приложений с интенсивным использованием fsync(), таких как базы данных. Я подозреваю, что для обслуживания изображений выгода будет не такой уж большой.
Проблема кластерных и распределенных FS заключается в том, что их сложнее настроить, и особенно распределенные FS менее зрелы, чем «обычные» одноузловые FS. Кластерная FS обычно подразумевает общее хранилище, что означает относительно дорогую SAN, если вы хотите избежать единых точек отказа.
Альтернативой может стать настройка кластера, работающего на основе чего-то вроде Amazon S3, который обеспечивает доступное по HTTP распределенное и реплицированное хранилище ключей и значений. Например:хранилище OpenStack.
решение3
Многое зависит от того, как часто будут использоваться эти элементы. Если вы можете ожидать, что небольшой процент из них будет очень активен в одно и то же время, то вы можете рассмотреть Varnish для обработки вашего front-end, балансируя нагрузку с ваших back-end nginx/lightpd. Поскольку часто используемые изображения будут кэшироваться, скорость диска немного менее важна.
Однако, если изображения не запрашиваются повторно и кэширование не даст большого прироста, nginx/lightpd на одном или двух серверах справится с этим. Вам также нужно учесть объем пропускной способности, которую вы собираетесь предоставить. 800 МБ/с небольшого подмножества вашего набора данных легко кэшируются ОС. 800 МБ/с огромного подмножества вашего набора данных, скорее всего, приведут к узкому месту ввода-вывода, поскольку вы не сможете достаточно быстро получить данные с диска для обслуживания, в этом случае вам нужно будет разделить вашу систему на достаточное количество частей, чтобы иметь пропускную способность ввода-вывода.
Даже если вы используете RAID-6, это все равно не заменит резервное копирование, поэтому выделите в бюджет аналогичную машину для резервного копирования или, возможно, для использования в качестве сервера хранения данных при отказе.
решение4
Я бы выбрал пользовательский кластер вместо распределенной FS, потому что его проще понять и устранить неполадки, и он все еще работает. То есть, компромиссы надежности вашего собственного кластера очевидны, в то время как это само по себе задача — выяснить, как распределенная FS реагирует на мертвый сервер или неисправный коммутатор.
Возможным решением вашей проблемы является разбиение всего фотоархива на части (например, на 2 части) и указание идентификатора части в URL (например, сделать его поддоменом или GET-параметром, который легко извлекается с помощью регулярных выражений). Тогда у вас будет 4 сервера хранения фотографий (по 2 сервера на каждую часть). Пятый сервер использовать как обратный прокси-сервер, который распределяет и балансирует нагрузку. На всех пяти серверах может работать lighttpd. То есть, я предлагаю очень глупое, но работающее (для компании, в которой я работал - с общей нагрузкой ~5000 запросов в секунду, файлами размером 3-10 КБ, 8 ТБ уникальных файлов в общей сложности, сервером из 24 бэкендов, которые, однако, запускают собственный HTTP-демон вместо lighttpd) решение.
Что касается дисков и оперативной памяти: мы использовали программный RAID-0 из четырех быстрых, но дешевых дисков SATA на каждом сервере (если диск выходит из строя, все данные можно скопировать с реплики на другом сервере), а также специальное решение для перевода всего сервера в автономный режим после одной ошибки чтения. RAID-5 и RAID-6 очень плохи с точки зрения скорости, даже если один диск выходит из строя, пожалуйста, не используйте их. На контент-серверах необходим большой объем оперативной памяти (в качестве кэша диска), ищите 24 ГБ или больше. Даже в этом случае будьте готовы к 30-минутному времени прогрева. На обратном прокси, если вы используете lighttpd, пожалуйста, учтите, что он буферизует весь ответ восходящего потока в оперативной памяти как можно быстрее и может потратить много времени на отправку кэшированной фотографии кому-то по коммутируемому соединению или GPRS (и в это время нуждается в этом буфере в оперативной памяти). Мы также взяли 24 ГБ, просто чтобы иметь идентичные конфигурации, но я не уверен, что это излишество. HTTP-кеширование в памяти на обратном прокси-сервере не является обязательным (даже если есть горячие изображения!), поскольку дисковый кэш, предоставляемый ОС на бэкэндах, работает так же хорошо.
Чтобы убедиться, что все бэкенды, обслуживающие одну и ту же часть вашего архива, имеют одинаковые данные: это просто. При публикации фотографий просто скопируйте их на все серверы. Затем используйте rsync на старых частях архива, чтобы исправить любые несоответствия, таким образом сделав одну копию главной.