Согласен, с кросс-маунтами я не прав, слово у меня идёт от того, что в реальности нам нужна была более сложная схема маунтов, которую можно назвать «кросс».
Насчет блокировки Вы не правы совершенно, процесс при обращении по TCP не блокируется таким образом, как и при NFS. И дело не в TCP. А в том, что, скажем read() из файла по NFS должен поддерживать семантику POSIX, а она не всегда позволяет после таймаута сказать «извини, файл недоступен». И конечные программы обычные (sh, например), не будут готовы обработать такие ошибки, т.к. на файловой системе с дисками такое невозможно. Это вопрос скорее практики, чем теории.
Вообще тестировали, и, более того, оно работает, и когда 1000, и когда 2000.
Просто на качество влияет большое количество внешних факторов: качество канала, загруженность сервера, качество канала вещающего (именно так). Качество картинки и звука (между прочим) выбирает автор трансляции прямо в плеере вещаний.
Мы будем рады конструктивной критике и любым замечаниям.
1. Популярность — это характеристика файла примерно на неделю. Как было описано, в каждый момент времени «активными» (то есть не забитыми до предела) являются несколько серверов, новые файлы разбрасываются по ним равномерно, какая-то часть из них станет популярной, но эта часть окажется распределенной по нескольким серверам, поэтому на практике у нас не было даже необходимость отдавать с backup-части, всегда справлялся один сервер.
2. Я не спец по железу, но, в нашей ситуации это были SATA-диски, достаточно обычные сервера, RAID-5. Этот вариант оказался достаточно разумным по эффективности/стоимости.
В случае падения соединения с NFS-сервером на уровне ядра ОС идёт блокировка процесса, при WebDAV ничего не происходит, кроме таймаута HTTP-запроса, что легко обрабатывается. На практике же если подмонтированный по NFS раздел «пропадает», через некоторое время сервер, который являлся клиентом NFS, целиком падает в deadlock.
Кросс-маунты от того, что если есть 30 морд и 30 файловых серверов, то каждая морда должна подмонтировать каждый файловый сервер, это 900 маунтов.
Если в момент записи упадет — можно операцию повторить еще раз, выбрав другой файловый сервер.
Я не говорю, что NFS — это однозначно «плохо», просто для данной ситуации этого плохо. Для бездисковой рабочей станции NFS — это супер!
На схеме они совмещены в одном «цилиндре», чтобы не захламлять схему. Физически морда и сервер перекодирования могут быть и одним сервером, реально же морд много и серверов перекодирования много, а с точки зрения того, что они взаимодействуют с файловым сервером по WebDAV — они похожи.
Да, только с точки зрения нагрузки чуть хуже, кому-то надо обрабатывать эти редирект-запросы. Но позволяет реализовать почти сколько угодно сложную логику.
Да есть куча способов в том или ином виде, я привел ссылку на модуль lighttpd, который позволяет сделать «умирающую» со временем ссылку. При этом тот, кто генерирует ссылку, никак не связан с тем, кто проверяет её валидность, достаточно самой ссылки.
Вся информация об этом модуле, его работе, примеры можно найти. Это совсем просто и может подойти ;)
В зависимости от точной задачи. Можно просто генерировать «умирающие» (ограниченные по времени ссылки) ссылки на файлы. Например: redmine.lighttpd.net/wiki/lighttpd/Docs:ModSecDownload
Насчет блокировки Вы не правы совершенно, процесс при обращении по TCP не блокируется таким образом, как и при NFS. И дело не в TCP. А в том, что, скажем read() из файла по NFS должен поддерживать семантику POSIX, а она не всегда позволяет после таймаута сказать «извини, файл недоступен». И конечные программы обычные (sh, например), не будут готовы обработать такие ошибки, т.к. на файловой системе с дисками такое невозможно. Это вопрос скорее практики, чем теории.
Просто на качество влияет большое количество внешних факторов: качество канала, загруженность сервера, качество канала вещающего (именно так). Качество картинки и звука (между прочим) выбирает автор трансляции прямо в плеере вещаний.
Мы будем рады конструктивной критике и любым замечаниям.
2. Я не спец по железу, но, в нашей ситуации это были SATA-диски, достаточно обычные сервера, RAID-5. Этот вариант оказался достаточно разумным по эффективности/стоимости.
Кросс-маунты от того, что если есть 30 морд и 30 файловых серверов, то каждая морда должна подмонтировать каждый файловый сервер, это 900 маунтов.
Если в момент записи упадет — можно операцию повторить еще раз, выбрав другой файловый сервер.
Я не говорю, что NFS — это однозначно «плохо», просто для данной ситуации этого плохо. Для бездисковой рабочей станции NFS — это супер!
Вещание — отдельный сервис, просмотр видео — отдельный. Технически они никак не связаны. Вещается «живой» поток.
Вся информация об этом модуле, его работе, примеры можно найти. Это совсем просто и может подойти ;)