Комментарии 79
Ой как все усложнено.
Берем и ставим прокси сервера, которым командуем хранить кешированные медийные файлы очень долго.
Прокси, squid, например, умеют использовать иерархические хранилища.
Таким образом от центрального файлы пойдут на остальные сервера и там закешируются, а если файлы пропадут на любом из центральных серверов, то их без проблем вытянуть из кеша :)
И еще.
dell.merlion.ru/catalog/storage/hddarray/dell_powervault_md1000/ — вот эту штучку набиваем дисками и подключаем, после чего на сервере будет много дискового пространства по дешевой цене.
Берем и ставим прокси сервера, которым командуем хранить кешированные медийные файлы очень долго.
Прокси, squid, например, умеют использовать иерархические хранилища.
Таким образом от центрального файлы пойдут на остальные сервера и там закешируются, а если файлы пропадут на любом из центральных серверов, то их без проблем вытянуть из кеша :)
И еще.
dell.merlion.ru/catalog/storage/hddarray/dell_powervault_md1000/ — вот эту штучку набиваем дисками и подключаем, после чего на сервере будет много дискового пространства по дешевой цене.
Я не очень понял, при чем тут кэширование и проксирование? Оно в данной схеме отсутствует вовсе, файловый сервер способен отдать контент самостоятельно, на скоростях (по опыту) до 600 Мбит/с, его стоимость низкая (относительно). А суммарная нагрузка распределена по отдельным серверам, имеет неограниченное масштабирование (в отличие от центрального хранилище).
А вот вероятность потери данных очень высокая в силу различных отказов как железа, так и софта. На практике отказ — 1 сервер за полгода-год, но этого вполне достаточно для больших потерь ;)
А вот вероятность потери данных очень высокая в силу различных отказов как железа, так и софта. На практике отказ — 1 сервер за полгода-год, но этого вполне достаточно для больших потерь ;)
Хотите сказать, что Apache будет более производительный чем Squid? :)
И кроме того, где у меня было центральное хранилище? :)
И кроме того, где у меня было центральное хранилище? :)
Я про Apache не говорил, в статье написано про Apache для WebDAV (внутренний доступ), а для отдачи контента там упоминались nginx и lighttpd.
Центральное хранилище — это полка с дисками от Dell. Вот в нём-то смысла и нет, т.к. доступ идёт к данным постоянно, это не архив, а бэкапить это чудо всё равно надо ;) Я просто хочу сказать, что полка — это круто, но, по моему мнению, для данной задачи не подходит. Можно из полок делать «статичный» бэкап, который никогда не используется для отдачи контента.
Центральное хранилище — это полка с дисками от Dell. Вот в нём-то смысла и нет, т.к. доступ идёт к данным постоянно, это не архив, а бэкапить это чудо всё равно надо ;) Я просто хочу сказать, что полка — это круто, но, по моему мнению, для данной задачи не подходит. Можно из полок делать «статичный» бэкап, который никогда не используется для отдачи контента.
Сам пишу статейку на подобную тему (видеохостинг), опередили :)
Кстати, можно уточнить как сработает система в случае падения storage-сервера? Как хранится информация о бекап данных?
Кстати, можно уточнить как сработает система в случае падения storage-сервера? Как хранится информация о бекап данных?
Кто кого бэкапит — это статичная информация, пары серверов формируются при вводе в строй.
В случае падения сервера (информация мониторинга) нагрузка может быть сразу перенаправлена на сервер, где лежит бэкап.
В случае падения сервера (информация мониторинга) нагрузка может быть сразу перенаправлена на сервер, где лежит бэкап.
Рекомендую хранить по несколько копий одного видео файла на разных серверах. Это поможет лучше сбалансировать нагрузку.
После восстановления упавшего сервера, ему необходимо восстановить данные на диске. Будет лучше, если в этом ему помогут несколько соседних серверов — меньше влияния на производительность всей системы.
После восстановления упавшего сервера, ему необходимо восстановить данные на диске. Будет лучше, если в этом ему помогут несколько соседних серверов — меньше влияния на производительность всей системы.
Вот не пойму, почему обычную загрузку FLV с произвольного места именуют «стримингом». Ведь стриминг — это потоковая передача с регулируемой скоростью в зависимости от битрейта видео.
Хорошая статья! Хотел только уточнить один момент, html-контент раздает один сервер, а всю медийную часть — эти «морды»?
«Морды» отдают html, а медийную часть файловые сервера.
А тогда кто и как решает, какая морда должна отдать ту же индексную страницу?
так кто тогда кодирует-то?
А как лучше реализовать авторизованный доступ к видео-файлам?
В зависимости от точной задачи. Можно просто генерировать «умирающие» (ограниченные по времени ссылки) ссылки на файлы. Например: redmine.lighttpd.net/wiki/lighttpd/Docs:ModSecDownload
можно поподробнее!
очень интересует тема…
но даже не знаю в какую сторону капать
возможно есть готовые решения?
авторизованный доступ к большим файлам
генерировать «умирающие» (ограниченные по времени ссылки) ссылки на файлы.
с возможности докачки
обязательно(лучше) строить решение на ngnix или lighthttpd?
очень интересует тема…
но даже не знаю в какую сторону капать
возможно есть готовые решения?
авторизованный доступ к большим файлам
генерировать «умирающие» (ограниченные по времени ссылки) ссылки на файлы.
с возможности докачки
обязательно(лучше) строить решение на ngnix или lighthttpd?
Да есть куча способов в том или ином виде, я привел ссылку на модуль lighttpd, который позволяет сделать «умирающую» со временем ссылку. При этом тот, кто генерирует ссылку, никак не связан с тем, кто проверяет её валидность, достаточно самой ссылки.
Вся информация об этом модуле, его работе, примеры можно найти. Это совсем просто и может подойти ;)
Вся информация об этом модуле, его работе, примеры можно найти. Это совсем просто и может подойти ;)
это все неработает для paid services. поэтому и придумали drm.
не работает — потому что клиент все равно получает файл, который (при желании) может копировать?
эта маленькая проблема и решается не drm, а стримингом (поток windows media точно невозможно сохранить). а ключевые проблемы лежат в плоскости доступа к vod/live пользователя который заплатил и пользователей которые не платили, но получили от того, который платил секретный линк/пароль/etc
Немного через «спину», но потоковый звук вполне себе можно записать.
А важна ли эта проблема [для правообладателей, в частности] — если в один момент времени аккаунтом может пользоваться только один человек?
А важна ли эта проблема [для правообладателей, в частности] — если в один момент времени аккаунтом может пользоваться только один человек?
Можно сделать с помощью nginx и X-Accel-Redirect. Подробнее тут — www.opennet.ru/base/net/nginx_x_accel_redirect.txt.html.
если не секрет что такое RTMP сервер?
Сервер вещаний, клиентом является любой Flash Player. ru.wikipedia.org/wiki/RTMP
а какое коннективити между серверами хранения и серверами трансляции/ретрансляции?
Ещё за memcached хотел в карму клюнуть — да забыл. А тут такое напоминание :)
В очередной раз — спасибо за статью.
В очередной раз — спасибо за статью.
Вы отметили что NFS ведет себя ненадежно при падении соединения с сервером, а WebDav не ведет себя также ненадежно в этой ситуации? :)
Откуда у вас крос-маунты когда много клиентов просто монтируют одну директорию на storage сервере, он ведь (storage сервер) ничего не монтирует.
А как решить проблему failover, т.е. в момент записи файла у вас упадет storage сервер? С NFS можно настроить автоматическую подмену основного сервера на бекапный за счет установки больших таймаутов у клиентов.
Откуда у вас крос-маунты когда много клиентов просто монтируют одну директорию на storage сервере, он ведь (storage сервер) ничего не монтирует.
А как решить проблему failover, т.е. в момент записи файла у вас упадет storage сервер? С NFS можно настроить автоматическую подмену основного сервера на бекапный за счет установки больших таймаутов у клиентов.
В случае падения соединения с NFS-сервером на уровне ядра ОС идёт блокировка процесса, при WebDAV ничего не происходит, кроме таймаута HTTP-запроса, что легко обрабатывается. На практике же если подмонтированный по NFS раздел «пропадает», через некоторое время сервер, который являлся клиентом NFS, целиком падает в deadlock.
Кросс-маунты от того, что если есть 30 морд и 30 файловых серверов, то каждая морда должна подмонтировать каждый файловый сервер, это 900 маунтов.
Если в момент записи упадет — можно операцию повторить еще раз, выбрав другой файловый сервер.
Я не говорю, что NFS — это однозначно «плохо», просто для данной ситуации этого плохо. Для бездисковой рабочей станции NFS — это супер!
Кросс-маунты от того, что если есть 30 морд и 30 файловых серверов, то каждая морда должна подмонтировать каждый файловый сервер, это 900 маунтов.
Если в момент записи упадет — можно операцию повторить еще раз, выбрав другой файловый сервер.
Я не говорю, что NFS — это однозначно «плохо», просто для данной ситуации этого плохо. Для бездисковой рабочей станции NFS — это супер!
HTTP таймаут это тоже блокировка на уровне ядра, и от того как она реализована (а в ПХП она практически не работает), к томуже NFS4 также работает по TCP, поэтому принципиальной разницы тут нет.
Мне всегда казалось что кросс-маунты это когда ты монтируешь файловую систему в которой также есть примонтированные из других мест части.
Мне всегда казалось что кросс-маунты это когда ты монтируешь файловую систему в которой также есть примонтированные из других мест части.
Согласен, с кросс-маунтами я не прав, слово у меня идёт от того, что в реальности нам нужна была более сложная схема маунтов, которую можно назвать «кросс».
Насчет блокировки Вы не правы совершенно, процесс при обращении по TCP не блокируется таким образом, как и при NFS. И дело не в TCP. А в том, что, скажем read() из файла по NFS должен поддерживать семантику POSIX, а она не всегда позволяет после таймаута сказать «извини, файл недоступен». И конечные программы обычные (sh, например), не будут готовы обработать такие ошибки, т.к. на файловой системе с дисками такое невозможно. Это вопрос скорее практики, чем теории.
Насчет блокировки Вы не правы совершенно, процесс при обращении по TCP не блокируется таким образом, как и при NFS. И дело не в TCP. А в том, что, скажем read() из файла по NFS должен поддерживать семантику POSIX, а она не всегда позволяет после таймаута сказать «извини, файл недоступен». И конечные программы обычные (sh, например), не будут готовы обработать такие ошибки, т.к. на файловой системе с дисками такое невозможно. Это вопрос скорее практики, чем теории.
Ну конечно же исключения не решаются с только за счет самой NFS. Например можно реализовать из основного и бекапных серверов «soft-raid» c помощью DRBD, таким образом, записывая файл в примонтированную директорию, он будет записыватся на все сервера сразу, получится некоторый такой multi-master сервер. Затем представим что сгорел блок питания на основном сервере, таймаут у нас пусть 30 сек, за это время мы успеем узнать что сервер сдох и надо переключиться на бекапный, берем его IP адрес и перебрасываем его на другой NFS сервер, соединения (запись/чтение) которые не успели отпасть просто продолжат свою работу, но уже с бекапным сервером.
Я не о том, что это невозможно, я о том, что наша практика подсказывает, что машина с 30-ю маунтами по NFS работает нестабильно, особенно когда в сети возникает проблема (например, теряются пакеты). И это приводит к «подвисаниям» сервера. NFS — классно, удобно, но наша практика заставила от него избавиться.
Если Вы знаете на собственном опыте, как в такой ситуации всё-таки использовать NFS — я, и, думаю, многие хабралюди, были бы рады прочитать об этом в подробной статье :)
Если Вы знаете на собственном опыте, как в такой ситуации всё-таки использовать NFS — я, и, думаю, многие хабралюди, были бы рады прочитать об этом в подробной статье :)
Стриминг у вас как не работал год назад так и не работает сейчас… с чем это связано не понятно
Чтобы я мог дать ответ или как-то исправить, надо понять, что именно Вы имеете в виду.
Это не вопрос, это утверждение! На него не нужно отвечать, вы лучше качество трансляций бы повысили, чтоб без глюков все работало, какие там 1000 подключений, 10 подключений и уже полный абзац, вы хоть сами свою систему тестировали?)))Похоже что нет!
Вообще тестировали, и, более того, оно работает, и когда 1000, и когда 2000.
Просто на качество влияет большое количество внешних факторов: качество канала, загруженность сервера, качество канала вещающего (именно так). Качество картинки и звука (между прочим) выбирает автор трансляции прямо в плеере вещаний.
Мы будем рады конструктивной критике и любым замечаниям.
Просто на качество влияет большое количество внешних факторов: качество канала, загруженность сервера, качество канала вещающего (именно так). Качество картинки и звука (между прочим) выбирает автор трансляции прямо в плеере вещаний.
Мы будем рады конструктивной критике и любым замечаниям.
Спасибо большое за статью! Очень интересно когда рассказывает человек прошедший через реальные сложности, а не про «сферический сервис в вакууме». Сразу возникает два типа вопросов:
1. На какие то промежутки времен (день, неделя) некотрые файлы становятся популярными и нагрузка на сервер где они хранятся резко возрастает. Как решается эта проблема? Трафик делиться на два и равномерно раскидывается на основной storage сервер и на storage сервер с бэкапом?
А если двух серверов не хватает? Какой компонент у вас занимается репликацией популярных файлов по серверам?
2. Всегда опускается железная часть серверов. А это же тоже не маловажно. :) Можно чуть подробней про storage сервера? Насколько они требовательный к CPU и памяти? Думаю очень мало, но все же… Какая дисковая подсистема? Что лучше в таком случае — несколько SAX винтов или в два раза больше SATA?
1. На какие то промежутки времен (день, неделя) некотрые файлы становятся популярными и нагрузка на сервер где они хранятся резко возрастает. Как решается эта проблема? Трафик делиться на два и равномерно раскидывается на основной storage сервер и на storage сервер с бэкапом?
А если двух серверов не хватает? Какой компонент у вас занимается репликацией популярных файлов по серверам?
2. Всегда опускается железная часть серверов. А это же тоже не маловажно. :) Можно чуть подробней про storage сервера? Насколько они требовательный к CPU и памяти? Думаю очень мало, но все же… Какая дисковая подсистема? Что лучше в таком случае — несколько SAX винтов или в два раза больше SATA?
1. Популярность — это характеристика файла примерно на неделю. Как было описано, в каждый момент времени «активными» (то есть не забитыми до предела) являются несколько серверов, новые файлы разбрасываются по ним равномерно, какая-то часть из них станет популярной, но эта часть окажется распределенной по нескольким серверам, поэтому на практике у нас не было даже необходимость отдавать с backup-части, всегда справлялся один сервер.
2. Я не спец по железу, но, в нашей ситуации это были SATA-диски, достаточно обычные сервера, RAID-5. Этот вариант оказался достаточно разумным по эффективности/стоимости.
2. Я не спец по железу, но, в нашей ситуации это были SATA-диски, достаточно обычные сервера, RAID-5. Этот вариант оказался достаточно разумным по эффективности/стоимости.
Спасибо за пояснение.
Хотел еще спросить про файловую систему — какую именно используйте. На больших объемах файлов, я так понимаю, фрагментация контента становиться проблемой. Но судя по всему — вы файлы только добавляете, не удаляя старых. Что решает проблему фрагментации. Но все же узнать FS было бы интересно.
Хотел еще спросить про файловую систему — какую именно используйте. На больших объемах файлов, я так понимаю, фрагментация контента становиться проблемой. Но судя по всему — вы файлы только добавляете, не удаляя старых. Что решает проблему фрагментации. Но все же узнать FS было бы интересно.
Какое у вас ПО отвечает за перекодирование видеофайлов различного формата в FLV?
mencoder или ffmpeg
запускается из коммандной строки в линуксах
ffmpeg видел под win2k скомпилированным, можно скачать поиграться
запускается из коммандной строки в линуксах
ffmpeg видел под win2k скомпилированным, можно скачать поиграться
спасибо, подписался на ваш блог
А вы не пробовали все сделать через MogileFS?
Во первых на порядок надежнее, удобнее и быстрее.
Во вторых реально протестированно на миллионах пользователях lj.
В третих хорошо держит нагрузки и в связке с perlball отлично отдает контент.
Слабым место конечно остаеться БД, но вы ее хоть так хоть так юзаете.
Во первых на порядок надежнее, удобнее и быстрее.
Во вторых реально протестированно на миллионах пользователях lj.
В третих хорошо держит нагрузки и в связке с perlball отлично отдает контент.
Слабым место конечно остаеться БД, но вы ее хоть так хоть так юзаете.
Не пробовали, думаю эти решения примерно равны по сложности/возможностям/эффективности в данной ситуации. У нас не было человека в команде, который бы уже был готов ко всем подводным камням MogileFS, а такая архитектура выглядела более прямолинейной. Ни в коей мере не против MogileFS ;)
Подтверждаю эффективность применения могилы в данном случае. У нас туб реализован на ней и она показала себя с наилучшей стороны. Полностью берет на себя вопросы репликации, резервных копий мувиков, переадресации на наименее загруженный сервер и много чего еще. «Одним кликом» можно перевести сторадж в ред-онли или вообще вывести из отдачи. Удобно блин.
Кстати, а почему БД слабое место? Вроде как можно разнести мастеры и слейвы тогда все будет вообще кучеряво.
Кстати, а почему БД слабое место? Вроде как можно разнести мастеры и слейвы тогда все будет вообще кучеряво.
А почему для обслуживания WebDAV-запросов был выбран Apache, а не nginx?
НЛО прилетело и опубликовало эту надпись здесь
Сталкивались ли вы с live broadcast и необходимостью организации multicast? Насколько я знаю smotri.com предоставляет только статичный контент. Если да, было бы интересно услышать, как все организовано в плане архитектуры и оборудования.
«Live broadcast» на smotri.com есть, вы можете посмотреть, оно работает. Multicast на практике не работает в пределах «большого» Интернета, только в контролируемых локальных сетях.
Насчет того, как это устроено — я собираюсь написать статью (или серию статей на эту тему). Это в двух словах не расскажешь ;)
Насчет того, как это устроено — я собираюсь написать статью (или серию статей на эту тему). Это в двух словах не расскажешь ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Доставка видеоконтента пользователям