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

среда хостинга для доставки файлов FLV

Какая была бы идеальная установка оборудования для увеличения пропускной способности на сайте трубки?

У нас есть постоянно расширяющееся облачное хранилище, куда пользователи загружают фильмы, затем у нас есть эти машины веб-доставки, которые кэшируют файлы FLV на своих локальных жестких дисках и доставляют их пользователям. Каждая кеш-машина может обеспечить скорость 1200 Мбит / с, если у нее есть жесткие диски SAS 8. Такая кэш-машина стоит нам 550 долларов в месяц за 8x160 ГБ, поэтому каждая машина может кэшировать только 160 ГБ в любой момент времени.

Если мы хотим кэшировать более 160 ГБ, нам нужно добавить еще одну машину ... еще 550 долларов в месяц ... и т. Д. Это очень неэкономично, поэтому мне интересно, есть ли у нас здесь эксперты, которые могут найти лучшую настройку.

Я искал "gluster FS", но я не уверен, может ли эта штука сильно увеличить пропускную способность.

Любые идеи высоко ценятся.

Спасибо!

В общем, я бы поставил под сомнение разумность использования здесь репликации. Что бы я сделал, так это ....;)

  • Выгрузите файлы в один центральный NAS / SAN (возможно, скопируйте их по мере необходимости). Вы могли бы использовать некоторые из кейсов для хранения SUperMicro - 24 x 2,5-дюймовые диски в 2 стойках. И да, арендованные / арендованные серверы не подходят, вам нужно разместить свои собственные. Особые потребности = специальное оборудование = не то, что предлагают массовые хостеры .

  • Создайте базу данных, которая динамически распределяет файлы по группам серверов потоковой передачи, чтобы эти серверы могли выполнять кэширование. Они идентичны отдельным записям сервера имен, которые указывают на все серверы в группе и просто следят за тем, чтобы не каждый сервер кэшировал каждый файл.

  • Создайте группы серверов (согласно пункту ранее), которые отвечают за потоковую передачу групп файлов.

  • Пусть кеширование файлов ОС разберется с остальным. Серьезно;) Поставить на такую ​​машину макс барана и покончить с этим.

  • И пока вы занимаетесь этим, кому пришла в голову супер-умная идея запустить диски SAS ... вы проверяли, нужны ли они? Подсказка - ставьте диски SATA, в основном ... WD Velociraptors. 300 ГБ на диск, и я уверен, что намного дешевле, чем ваши диски SAS. Почти так же быстро, работает 10.000 об / мин. Я использую их в базах данных и получаю от них очень экономичный ввод-вывод. И я думаю, что мои требования к вводу-выводу выше, чем ваши (поскольку видео, как правило, больше, чем данные, с которыми я работаю).

В основном вы попали в диапазон, в котором центральная система хранения имеет смысл, и вы пытаетесь обойти это с - извините - посредственными элементами хранения (88 дисков уже НЕ впечатляют для одного сервера). Результат - огромные затраты на оборудование;) Теперь вы можете использовать особые случаи (посмотрите на предложения супермикро, которые я сделал - у них также есть большой дисковый отсек 3,5 дюйма на 48 дисков) или специальное оборудование (которое, впрочем, будет стоить Даже больше). Хорошая установка с вашими внешними устройствами без больших дисков и центральным хранилищем с использованием подходящих высокопроизводительных RAID-контроллеров, большого количества дисков и одного или нескольких адаптеров на 10 ГБ должны быть хорошими.

Забудьте о кластеризации файловых систем - вам нужно что-то запланированное. Проблема в том, что вам нужно спланировать свою полосу пропускания в системе. У вас не может быть слишком много перекрестного трафика, если вы не хотите использовать коммутаторы 10 ГБ во всем. И даже тогда перекрестное движение может вас убить.

Интеллектуальное кеширование!

В вашем случае пропускная способность сети и ввод-вывод будут вашими текущими узкими местами.

Если вы можете запустить что-то вроде zfs, вы можете использовать большой SSD в качестве динамического кеша между физическими драйверами и памятью.

Zfs будет управлять этим кешем. Если вам нужна более высокая производительность SSD, просто соедините их вместе, чтобы повысить производительность.

Если у вас нет zfs, подумайте об определении «горячих» файлов в кластере и перенесите их на локальный SSD или выделенный RAM-диск. Таким образом, вы можете использовать медленную передачу файлов на сервер, а популярные файлы будут обслуживаться с быстрых SSD / RAM. Думайте о SSD как о расширении вашего кеша. Это не так быстро, как барана, но намного быстрее, чем диск. (меньшая энергия тоже!).

Максимально увеличьте физическую память на ваших серверах, это улучшит кэширование. Если вы идете по пути ПК, я видел материнские платы емкостью более 128 ГБ! :-).

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

Также обратите внимание на использование оптимизированного веб-сервера для потоковой передачи файлов, http://nginx.org/ приходит на ум. Вы по-прежнему можете сохранить существующие серверы приложений, но направить пользователей на выделение серверов потокового видео.

Memcache интересен, в зависимости от загруженности вашей работы это тоже может помочь.

по мере вашего роста в инфраструктуре будут появляться узкие места, поэтому убедитесь, что у вас есть хорошие журналы производительности / ошибок / безопасности. Вы сможете намного лучше планировать ресурсы, если будете знать, что ваша инфраструктура делает в условиях нагрузки пользователей. График изменения этих данных в течение определенного периода времени, и вы сможете показать руководству, почему вам нужно новое оборудование x для решения проблемы узкого места y.

Если у вас нет внутренних навыков, чтобы сделать все это, взгляните на сеть доставки контента. Их инфраструктура настроена для этого. Вы просто платите за это!

После того, как вы обновите сервер до нескольких 10Gbit Ethernet, вы обнаружите, что столкнетесь с другими узкими местами, а именно с системной шиной машины :-).

Я бы второй ZFS и кеш-диск SSD - работает хорошо. Также максимальный барабан. ZFS на основе OpenSolaris, кстати, реализация FreeBSD не так надежна.

Это не тот ответ, на который вы хотите здесь, извините. Я очень конкретный парень, специализирующийся на передаче видео по IP, я создал одни из самых больших систем VoD, и то, что вы делаете сейчас, кажется мне огромной тратой, существует так много проблем, о которых я не знаю с чего начать.

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

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