Website development
Comments 79
-12
Ой как все усложнено.
Берем и ставим прокси сервера, которым командуем хранить кешированные медийные файлы очень долго.
Прокси, squid, например, умеют использовать иерархические хранилища.
Таким образом от центрального файлы пойдут на остальные сервера и там закешируются, а если файлы пропадут на любом из центральных серверов, то их без проблем вытянуть из кеша :)

И еще.

dell.merlion.ru/catalog/storage/hddarray/dell_powervault_md1000/ — вот эту штучку набиваем дисками и подключаем, после чего на сервере будет много дискового пространства по дешевой цене.
+4
Я не очень понял, при чем тут кэширование и проксирование? Оно в данной схеме отсутствует вовсе, файловый сервер способен отдать контент самостоятельно, на скоростях (по опыту) до 600 Мбит/с, его стоимость низкая (относительно). А суммарная нагрузка распределена по отдельным серверам, имеет неограниченное масштабирование (в отличие от центрального хранилище).

А вот вероятность потери данных очень высокая в силу различных отказов как железа, так и софта. На практике отказ — 1 сервер за полгода-год, но этого вполне достаточно для больших потерь ;)
-4
Хотите сказать, что Apache будет более производительный чем Squid? :)
И кроме того, где у меня было центральное хранилище? :)
+1
Я про Apache не говорил, в статье написано про Apache для WebDAV (внутренний доступ), а для отдачи контента там упоминались nginx и lighttpd.

Центральное хранилище — это полка с дисками от Dell. Вот в нём-то смысла и нет, т.к. доступ идёт к данным постоянно, это не архив, а бэкапить это чудо всё равно надо ;) Я просто хочу сказать, что полка — это круто, но, по моему мнению, для данной задачи не подходит. Можно из полок делать «статичный» бэкап, который никогда не используется для отдачи контента.
0
Это не центральное хранилище
Это кеш одного из серверов ;)
+1
Тогда непонятна архитектура и смысл предложенного в первом комменте.
-1
А что тут непонятного? Решение бекапов и CDN в одном флаконе.
+1
Ну, наверное. Я только не понял Вашей идеи, поэтому никак отреагировать не смогу.
+1
Сам пишу статейку на подобную тему (видеохостинг), опередили :)
Кстати, можно уточнить как сработает система в случае падения storage-сервера? Как хранится информация о бекап данных?
0
Кто кого бэкапит — это статичная информация, пары серверов формируются при вводе в строй.

В случае падения сервера (информация мониторинга) нагрузка может быть сразу перенаправлена на сервер, где лежит бэкап.
0
Рекомендую хранить по несколько копий одного видео файла на разных серверах. Это поможет лучше сбалансировать нагрузку.
После восстановления упавшего сервера, ему необходимо восстановить данные на диске. Будет лучше, если в этом ему помогут несколько соседних серверов — меньше влияния на производительность всей системы.
0
Скорее всего, в нашем случае это приведет только к неоправданно большому юзанию жесткого диска. Но только в нашем случае, это не универсальный совет.
+4
Вот не пойму, почему обычную загрузку FLV с произвольного места именуют «стримингом». Ведь стриминг — это потоковая передача с регулируемой скоростью в зависимости от битрейта видео.
0
Согласен, не совсем корректно. Кто-то «первый» назвавший это так виноват.

Я бы сказал, что скорость стриминга должна еще зависеть от канала клиента.
0
Подозреваю, что это был создатель flv-плагина для lighthttpd (или где он там впервые появился?)… :-)

В Windows Media, если правильно закодить, оно как раз зависит от канала клиента.
-1
Хорошая статья! Хотел только уточнить один момент, html-контент раздает один сервер, а всю медийную часть — эти «морды»?
0
«Морды» отдают html, а медийную часть файловые сервера.
0
А тогда кто и как решает, какая морда должна отдать ту же индексную страницу?
0
Имею в виду страницу, которую сервер отдает на запрос корня сайта, _http://domain/
0
Ммм… К статье вроде бы отношения не имеет, но это делает балансировщик HTTP-нагрузки. Вообще это может сделать любая морда.
0
Спасибо, теперь понятно. Не укладывалось просто все в одну картину, упомянули хотя бы про это :).
0
тогда на схеме непонятно — есть морда, которая как написано занимается перекодированием. но вы выше пишете, что морда отдает только html, а файловые сервера отдают видео.
0
На схеме они совмещены в одном «цилиндре», чтобы не захламлять схему. Физически морда и сервер перекодирования могут быть и одним сервером, реально же морд много и серверов перекодирования много, а с точки зрения того, что они взаимодействуют с файловым сервером по WebDAV — они похожи.
0
А как лучше реализовать авторизованный доступ к видео-файлам?
0
В зависимости от точной задачи. Можно просто генерировать «умирающие» (ограниченные по времени ссылки) ссылки на файлы. Например: redmine.lighttpd.net/wiki/lighttpd/Docs:ModSecDownload
0
можно поподробнее!
очень интересует тема…
но даже не знаю в какую сторону капать
возможно есть готовые решения?
авторизованный доступ к большим файлам
генерировать «умирающие» (ограниченные по времени ссылки) ссылки на файлы.
с возможности докачки
обязательно(лучше) строить решение на ngnix или lighthttpd?

0
Да есть куча способов в том или ином виде, я привел ссылку на модуль lighttpd, который позволяет сделать «умирающую» со временем ссылку. При этом тот, кто генерирует ссылку, никак не связан с тем, кто проверяет её валидность, достаточно самой ссылки.

Вся информация об этом модуле, его работе, примеры можно найти. Это совсем просто и может подойти ;)
0
это все неработает для paid services. поэтому и придумали drm.
0
не работает — потому что клиент все равно получает файл, который (при желании) может копировать?
0
эта маленькая проблема и решается не drm, а стримингом (поток windows media точно невозможно сохранить). а ключевые проблемы лежат в плоскости доступа к vod/live пользователя который заплатил и пользователей которые не платили, но получили от того, который платил секретный линк/пароль/etc
0
Немного через «спину», но потоковый звук вполне себе можно записать.
А важна ли эта проблема [для правообладателей, в частности] — если в один момент времени аккаунтом может пользоваться только один человек?
0
с экрана монитора можно и видео на камеру записать

вы приводите пример, когда 1000 человек скидывается по центу и покупают за $10 двд и смотрят его по очереди. что думает по этому поводу правообладатель, как вы думаете?
0
Звук будет сносного качества.
Про двд пример неподходящий.
0
почему неподходящий? например, мы говорим про фильмы/сериалы on-demand. эккаунт стоит допустим $29.95/month. 30 человек сбросились — он им стоит таким образом $1/month и смотрят, распределив между собой часы просмотра через один account.
0
Да, только с точки зрения нагрузки чуть хуже, кому-то надо обрабатывать эти редирект-запросы. Но позволяет реализовать почти сколько угодно сложную логику.
0
Если есть Flash Player, то подходит. Мобильные устройства разные бывает.
0
На всякие случай — в подавляющем большинстве терминалов плеер не может быть заэмбежен «в страничку».
0
а какое коннективити между серверами хранения и серверами трансляции/ретрансляции?
0
Никакого, кроме того, что они часть видеохостинга ;)
0
тогда я не понял, как разношерстный по формату контент на файловых серверах превращается в однородный формат отдаваемый клиентам
0
А я тогда не понял сути вопроса.

Вещание — отдельный сервис, просмотр видео — отдельный. Технически они никак не связаны. Вещается «живой» поток.
+1
Ещё за memcached хотел в карму клюнуть — да забыл. А тут такое напоминание :)
В очередной раз — спасибо за статью.
0
Вы отметили что NFS ведет себя ненадежно при падении соединения с сервером, а WebDav не ведет себя также ненадежно в этой ситуации? :)
Откуда у вас крос-маунты когда много клиентов просто монтируют одну директорию на storage сервере, он ведь (storage сервер) ничего не монтирует.
А как решить проблему failover, т.е. в момент записи файла у вас упадет storage сервер? С NFS можно настроить автоматическую подмену основного сервера на бекапный за счет установки больших таймаутов у клиентов.
0
В случае падения соединения с NFS-сервером на уровне ядра ОС идёт блокировка процесса, при WebDAV ничего не происходит, кроме таймаута HTTP-запроса, что легко обрабатывается. На практике же если подмонтированный по NFS раздел «пропадает», через некоторое время сервер, который являлся клиентом NFS, целиком падает в deadlock.

Кросс-маунты от того, что если есть 30 морд и 30 файловых серверов, то каждая морда должна подмонтировать каждый файловый сервер, это 900 маунтов.

Если в момент записи упадет — можно операцию повторить еще раз, выбрав другой файловый сервер.

Я не говорю, что NFS — это однозначно «плохо», просто для данной ситуации этого плохо. Для бездисковой рабочей станции NFS — это супер!
0
HTTP таймаут это тоже блокировка на уровне ядра, и от того как она реализована (а в ПХП она практически не работает), к томуже NFS4 также работает по TCP, поэтому принципиальной разницы тут нет.
Мне всегда казалось что кросс-маунты это когда ты монтируешь файловую систему в которой также есть примонтированные из других мест части.
0
Согласен, с кросс-маунтами я не прав, слово у меня идёт от того, что в реальности нам нужна была более сложная схема маунтов, которую можно назвать «кросс».

Насчет блокировки Вы не правы совершенно, процесс при обращении по TCP не блокируется таким образом, как и при NFS. И дело не в TCP. А в том, что, скажем read() из файла по NFS должен поддерживать семантику POSIX, а она не всегда позволяет после таймаута сказать «извини, файл недоступен». И конечные программы обычные (sh, например), не будут готовы обработать такие ошибки, т.к. на файловой системе с дисками такое невозможно. Это вопрос скорее практики, чем теории.
0
Ну конечно же исключения не решаются с только за счет самой NFS. Например можно реализовать из основного и бекапных серверов «soft-raid» c помощью DRBD, таким образом, записывая файл в примонтированную директорию, он будет записыватся на все сервера сразу, получится некоторый такой multi-master сервер. Затем представим что сгорел блок питания на основном сервере, таймаут у нас пусть 30 сек, за это время мы успеем узнать что сервер сдох и надо переключиться на бекапный, берем его IP адрес и перебрасываем его на другой NFS сервер, соединения (запись/чтение) которые не успели отпасть просто продолжат свою работу, но уже с бекапным сервером.
0
Я не о том, что это невозможно, я о том, что наша практика подсказывает, что машина с 30-ю маунтами по NFS работает нестабильно, особенно когда в сети возникает проблема (например, теряются пакеты). И это приводит к «подвисаниям» сервера. NFS — классно, удобно, но наша практика заставила от него избавиться.

Если Вы знаете на собственном опыте, как в такой ситуации всё-таки использовать NFS — я, и, думаю, многие хабралюди, были бы рады прочитать об этом в подробной статье :)

-1
Стриминг у вас как не работал год назад так и не работает сейчас… с чем это связано не понятно
+1
Чтобы я мог дать ответ или как-то исправить, надо понять, что именно Вы имеете в виду.
-1
Это не вопрос, это утверждение! На него не нужно отвечать, вы лучше качество трансляций бы повысили, чтоб без глюков все работало, какие там 1000 подключений, 10 подключений и уже полный абзац, вы хоть сами свою систему тестировали?)))Похоже что нет!
+1
Вообще тестировали, и, более того, оно работает, и когда 1000, и когда 2000.

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

Мы будем рады конструктивной критике и любым замечаниям.
0
Спасибо большое за статью! Очень интересно когда рассказывает человек прошедший через реальные сложности, а не про «сферический сервис в вакууме». Сразу возникает два типа вопросов:

1. На какие то промежутки времен (день, неделя) некотрые файлы становятся популярными и нагрузка на сервер где они хранятся резко возрастает. Как решается эта проблема? Трафик делиться на два и равномерно раскидывается на основной storage сервер и на storage сервер с бэкапом?
А если двух серверов не хватает? Какой компонент у вас занимается репликацией популярных файлов по серверам?

2. Всегда опускается железная часть серверов. А это же тоже не маловажно. :) Можно чуть подробней про storage сервера? Насколько они требовательный к CPU и памяти? Думаю очень мало, но все же… Какая дисковая подсистема? Что лучше в таком случае — несколько SAX винтов или в два раза больше SATA?
0
1. Популярность — это характеристика файла примерно на неделю. Как было описано, в каждый момент времени «активными» (то есть не забитыми до предела) являются несколько серверов, новые файлы разбрасываются по ним равномерно, какая-то часть из них станет популярной, но эта часть окажется распределенной по нескольким серверам, поэтому на практике у нас не было даже необходимость отдавать с backup-части, всегда справлялся один сервер.

2. Я не спец по железу, но, в нашей ситуации это были SATA-диски, достаточно обычные сервера, RAID-5. Этот вариант оказался достаточно разумным по эффективности/стоимости.
0
Спасибо за пояснение.
Хотел еще спросить про файловую систему — какую именно используйте. На больших объемах файлов, я так понимаю, фрагментация контента становиться проблемой. Но судя по всему — вы файлы только добавляете, не удаляя старых. Что решает проблему фрагментации. Но все же узнать FS было бы интересно.
0
Фрагментации большой не будет, т.к. файлы большие и их (относительно) мало. Вообще FreeBSD/FFS2.
0
Какое у вас ПО отвечает за перекодирование видеофайлов различного формата в FLV?
0
mencoder или ffmpeg
запускается из коммандной строки в линуксах
ffmpeg видел под win2k скомпилированным, можно скачать поиграться
+1
А вы не пробовали все сделать через MogileFS?
Во первых на порядок надежнее, удобнее и быстрее.
Во вторых реально протестированно на миллионах пользователях lj.
В третих хорошо держит нагрузки и в связке с perlball отлично отдает контент.
Слабым место конечно остаеться БД, но вы ее хоть так хоть так юзаете.
0
Не пробовали, думаю эти решения примерно равны по сложности/возможностям/эффективности в данной ситуации. У нас не было человека в команде, который бы уже был готов ко всем подводным камням MogileFS, а такая архитектура выглядела более прямолинейной. Ни в коей мере не против MogileFS ;)
+1
Подтверждаю эффективность применения могилы в данном случае. У нас туб реализован на ней и она показала себя с наилучшей стороны. Полностью берет на себя вопросы репликации, резервных копий мувиков, переадресации на наименее загруженный сервер и много чего еще. «Одним кликом» можно перевести сторадж в ред-онли или вообще вывести из отдачи. Удобно блин.
Кстати, а почему БД слабое место? Вроде как можно разнести мастеры и слейвы тогда все будет вообще кучеряво.
0
Я просто приводил примеры технологий… Это мог бы быть и nginx, и кто-то еще. А можно и Apache, нагрузки особой нет на WebDAV, это не так принципиально.
UFO landed and left these words here
0
Сталкивались ли вы с live broadcast и необходимостью организации multicast? Насколько я знаю smotri.com предоставляет только статичный контент. Если да, было бы интересно услышать, как все организовано в плане архитектуры и оборудования.
0
«Live broadcast» на smotri.com есть, вы можете посмотреть, оно работает. Multicast на практике не работает в пределах «большого» Интернета, только в контролируемых локальных сетях.

Насчет того, как это устроено — я собираюсь написать статью (или серию статей на эту тему). Это в двух словах не расскажешь ;)
Only those users with full accounts are able to leave comments., please.