Мне нужно хранить 25 миллионов фотографий в 4 размерах = всего 100 миллионов файлов, размер файла будет варьироваться от 3 до 200 КБ на файл, а используемое хранилище в начале составляет около 14-15 ТБ.
Наша цель - иметь данные на 2-4 серверах и обслуживать их с помощью локального быстрого веб-сервера (nginx или lighthttpd), нам нужно серверное количество запросов в секунду.
Я планирую использовать Servercase 2U от Intel с 12x2TB (WD RE4) с Raid 6 (или FS с избыточностью ??) для данных и 2x60GB SSD для ОС, это хороший способ? Теперь: я нашел Adaptec 5805ZQ, который может использовать SSD-диски SLC для кеширования наиболее часто используемых файлов, какие-либо предложения по этому поводу?
Какой размер кэша чтения мне нужно выбрать?
Каким будет лучший способ резервирования и балансировки нагрузки, если я планирую иметь 2-4 таких Сервера?
Какие плюсы / минусы кластера и распределенной ФС относительно нашей цели?
Если это разработка с нуля, то Я бы обязательно использовал для этого облако. 100 M файлов - это много данных; Значительным улучшением было бы переложить избыточное хранилище на fx Amazon S3.
Учитывая, что мы говорим о 100 M файлах, я считаю, что мы можем с уверенностью сказать, что некоторые части набора данных будут «горячими» (часто запрашиваемыми), а большая часть - холодными. Следовательно, нам действительно нужно кеширование.
Обзор того, как это можно сделать в Amazon Web Services:
Поскольку эта установка слабо связана, масштабировать по горизонтали легко (по мере возникновения проблем с масштабированием).
Насколько быстро это будет, во многом будет зависеть от соотношения между горячими и холодными данными. Если ваша рабочая нагрузка в основном горячая, то я не удивлюсь, если у вас будет намного больше 10.000 запросов / с всего от двух небольших балансировщиков нагрузки EC2 и двух экземпляров EC2 с высоким кешем памяти.
SSD для самой ОС - это излишне, если вы действительно не заинтересованы в загрузке на 30 секунд быстрее. Просто возьмите пару небольших дисков SAS, и этого будет более чем достаточно.
Wrt. кеш, полезность кеша зависит от рабочего набора. Т.е. ожидается ли, что запросы на изображения будут равномерно распределены по всем изображениям, или вы ожидаете, что большинство запросов будет для небольшого подмножества? В последнем случае кеш может быть полезен, в первом - не очень. Обратите внимание, что кеш на контроллере диска полезен в основном для кэширования записей (если кеш энергонезависимый), что полезно для приложений, интенсивно использующих fsync (), таких как базы данных. Что касается обслуживания изображений, я подозреваю, что польза будет не такой уж большой.
Проблема с кластерными и распределенными FS состоит в том, что их сложнее настроить, и особенно распределенные FS менее зрелы, чем "обычные" одноузловые FS. Кластерная ФС обычно означает общее хранилище, что означает относительно дорогое SAN, если вы хотите избежать единых точек отказа.
Альтернативой может быть создание кластера, в котором работает какой-то аналог Amazon S3, который предоставляет доступное по протоколу HTTP распределенное и реплицированное хранилище ключей и значений. Например. хранилище openstack.
Я бы выбрал настраиваемый кластер вместо распределенной 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 для старых частей архива, чтобы исправить любые несоответствия, сделав одну копию главной.
Многое зависит от того, как часто эти предметы будут использоваться. Если вы можете ожидать, что небольшой процент из них будет очень активен одновременно, тогда вы можете рассмотреть возможность использования Varnish для обработки внешнего интерфейса, балансировки нагрузки с ваших серверных модулей nginx / lighttpd. Поскольку часто используемые изображения будут кэшироваться, скорость диска немного менее важна.
Однако, если изображения не запрашиваются повторно и кеширование не даст значительного прироста, nginx / lighttpd на одном или двух серверах сделает это. Вам также необходимо учитывать объем пропускной способности, которую вы собираетесь предоставить. 800 МБ / с небольшого подмножества вашего набора данных легко кэшируется ОС. 800 МБ / с огромного подмножества вашего набора данных, вероятно, столкнутся с узким местом ввода-вывода, поскольку вы не можете получить данные с диска достаточно быстро, чтобы их можно было обслуживать, и в этом случае вам нужно разделить свою систему на достаточное количество частей, чтобы иметь ввод-вывод. пропускная способность.
Даже несмотря на то, что вы используете raid-6, он по-прежнему не заменяет резервное копирование, поэтому выделите аналогичную машину для резервного копирования или, возможно, для работы в качестве резервного сервера хранения.