Мой предыдущий опыт работы с серверами, как правило, ограничивался домашними серверами обмена файлами, веб-серверами с низким трафиком и т.п. Это оставляет мне технические знания о том, как настроить систему, но мало опыта с точки зрения масштабирования этой системы.
Тем не менее, в моем текущем проекте я являюсь техническим руководителем в создании школы для онлайн-трансляции аудио и видео. Сложность, с которой я сталкиваюсь, заключается в том, что у меня нет опыта, чтобы угадать, что им понадобится, и у них нет опыта, чтобы сказать мне, поэтому я попытался задать как можно больше уместных вопросов о том, что они хотят делать со своим сервером, и вот что я узнал:
Предварительные решения, которые я уже принял:
Чего я не знаю:
Большое спасибо за любую помощь - если вам нужна дополнительная информация, дайте мне знать, и я расскажу вам все, что могу.
Изменить 1:
Я ожидаю выхода либо в формате OGG, либо в формате MP3 - возможно, в формате MP3, поскольку он более широко поддерживается (и более знаком родителям учеников начальной школы.
Контент будет состоять из пакетов видео стандартного разрешения в реальном времени / предварительно записанных (для последнего, вероятно, в Quicktime). Вещание только со звуком, скорее всего, будет состоять из файлов MP3, перекодированных до более приемлемого качества. DRM не является проблемой, как и авторское право (по крайней мере, авторское право не мой выпуск). Контент генерируется всякий раз, когда учащиеся хотят что-то транслировать, но с хранением этих медиа не должно быть проблем. Они здесь не создают сырые кадры из фильмов - они дети делают небольшие телевизионные пакеты - я добавлю 4 жестких диска Terrabyte в RAID 10 на рабочую станцию и закончу.
Большая часть остального, похоже, не подходит. Самая важная часть - это внутренние ограничения сети. Когда я попытался узнать, что это могло быть, они на самом деле понятия не имели - поскольку они никогда не подвергали это стресс-тестированию. Их подключение к Интернету используется в основном для стандартных интернет-услуг для студентов и учителей, а также для обслуживания веб-сайта, построенного, вероятно, в 90-х годах. Я сомневаюсь, что они пройдут дорогостоящее переоборудование своих NAT и внешних систем - детям просто придется жить с тем, что у них есть.
Я не думаю, что моему серверу (-ам) придется беспокоиться о массовом кешировании или больших фрагментах хранения данных - они просто получат готовый поток от внутренней рабочей станции / исходного клиента и должны будут реплицировать и распространять поток. клиентам. Я ожидаю, что столкнусь с узкими местами, связанными с пропускной способностью, прежде чем обнаружу, что требую больше памяти.
Что касается многоадресной рассылки - я думал, что Интернет в целом ее не поддерживает - и внешние клиенты составляют большую часть наших потенциальных подписчиков. Мой большой вопрос немного более элементарный - что является "приличный сервер" / серверная система для такого рода приложений? Мне сложно представить, какое количество машин мне понадобится и на что они должны быть способны. Есть предположения? Заранее спасибо.
Я создаю системы IPTV, и вам это не понравится, но перед вами стоит очень сложная задача, особенно с учетом вашего бюджета.
Давайте рассмотрим это шаг за шагом (я нацеливаю этот ответ на более широкую аудиторию, а не только на вас, если вы не против);
Первое, что должен сделать каждый, кто создает такую систему, - это определить своих клиентов с точки зрения местоположения, операционных систем, игроков и в идеале понять сетевые аспекты между клиентами и серверами - вы уже многое из этого сделали. Это важно, поскольку оно определяет код сервера, кодеки, скорость передачи данных и возможность использования многоадресной рассылки вообще.
Второе, что нужно сделать, это понять ваш контент; откуда он берется, в каком формате, как часто возникают проблемы с авторским правом, требования DRM, как быстро он должен быть доступен и как долго его нужно хранить. Я думаю, что вы кое-что из этого рассмотрели, но вы, вероятно, можете задать еще несколько вопросов в этом направлении.
Это далеко не простая задача, но, основываясь на результатах двух блоков вопросов, приведенных выше, вы можете начать проектировать свою систему, опять же с точки поглощения - насколько ТОЧНО вы собираетесь перекодировать (если требуется) ваш контент, делает ли это нужно QA'ing, где он получает печать DRM и как вы собираетесь справляться с риском временного получения незашифрованного видео, если это имеет значение. Эту систему приема / постановки нужно продумать заранее, вам вообще не нужно «крутить» этот процесс, потому что он очень быстро станет повторяющимся.
После того, как вы разобрались с этой системой, вам нужно знать, что делает вашу каталогизацию контента и как система захвата подключается к ней, а также как вы собираетесь публиковать этот каталог и как вы удаляли «устаревший» контент. Эта система публикации затем инициирует воспроизведение на клиенте и может потребовать некоторой формы системы проверки прав, что создает свои проблемы, которые мы могли бы решить в другой раз.
Теперь мы переходим к интересующей вас части - серверам потоковой передачи.
К этому моменту вы будете знать свои базовые данные пользователей (кто, что, где, когда, как и т. Д.), И это поможет вам рассчитать ваши требования к пиковой пропускной способности (обычно что-то вроде «пиковые пользователи» x «максимальная скорость передачи данных»). .
«Лучшее качество» - это что-то вроде неправильного употребления, поскольку я уверен, что вы имеете в виду не «48-битное 8k HD при 60 кадрах в секунду», а скорее качество SD или около того, в качестве ориентира я делаю SD на скорости около 1,5 Мбит / с и HD около 6 Мбит / с, но это будет зависеть от вашего кодека и требований. Так, в качестве примера 1000 пользователей, воспроизводящих 1,5 Мбит / с одноадресного трафика, очевидно, равны 1,5 Гбит / с, здесь и проявляется жесткость. Во-первых, может ли ваша сеть, фактические магистрали и коммутаторы сами последовательно доставлять данные такого рода? Вам нужно сесть и разобраться, где находятся ваши слабые места. Можете ли вы использовать QoS для этих данных, чтобы защитить их от того, чтобы кто-то сбросил большую загрузку и убил видео всего сетевого сегмента? Также существует тот факт, что если вы используете на своих сетевых адаптерах более 1 Гбит / с, вам необходимо убедиться, что вы правильно объединили их в команду, чтобы второй и последующие члены команды действительно получали свою долю трафика, или до сетевых карт 10 Гб.
Затем мы перейдем к моей специализированной области - хранилищу - к настоящему времени вы уже определили, сколько хранилища вам понадобится для контента в начале, как быстро он будет расти, его максимальный размер и его «скорость оттока» (как много появляется и выходит из магазина контента в течение какого периода). Это покажет вам, какой объем хранилища вам нужен, но если у вас есть 1000 пользователей, просматривающих большой каталог контента, происходит то, что вам нужно уделять очень пристальное внимание кэшированию и возможности случайного чтения вашего хранилища.
Если вам ОЧЕНЬ повезло и ваш сервер может кэшировать 100% вашего контента, значит, вам повезло, вам просто нужен приличный сервер, много памяти и 64-битная операционная система. Если вы ожидаете, что пользователи будут иметь доступ к большему хранилищу контента, чем вы можете кэшировать, вам необходимо убедиться, что ваша система хранения может последовательно обеспечивать ваши пиковые требования к потоковой передаче, скажем, 1,5 Гбит / с в приведенном выше примере. То, как вы это делаете, зависит от размера хранилища контента и от того, нужно ли для этого более одного потокового сервера (как если бы вы это сделали, вам нужно будет выяснить, собираетесь ли вы разделять или делиться своим видео).
Вы можете, например, посмотреть на SSD, но не смотрите на «заголовочные» числа, такие как 500 Мбит / с, вам нужны SSD или диски, которые можно объединить в RAID, чтобы обеспечить максимальную скорость доставки. Существует множество твердотельных накопителей и дисков, которые отлично подходят для рабочих станций или серверов с низким уровнем параллелизма, но когда вы сталкиваетесь с требованием не отставать, скажем, от 1000 пользователей, которые извлекают небольшие фрагменты больших файлов в разных местах файлов - ну, в основном они не успевайте, как и большинство алгоритмов кэширования - вы должны знать, что ваше хранилище может выполнять работу самостоятельно, если это необходимо.
Если это хоть как-то утешает, то прямая потоковая передача намного проще, но, вероятно, заслуживает собственной машины для обработки захвата / шифрования / потоковой передачи, а не основного сервера / серверов на основе хранилища контента. Вам повезло в том, что вы, вероятно, лучше понимаете свою сеть, поскольку она звучит как закрытая система, если вы можете, вы хотите убедиться, что можете многоадресной рассылки, иначе вы столкнетесь с теми же проблемами управления полосой пропускания, которые я описал выше, но с лучшим возможность попадания в кеш.
Надеюсь, это поможет, например, я нацелен на более широкую аудиторию, чем просто этот вопрос, и я могу вернуться и добавить / отредактировать (как только у меня будет первая чашка чая за день!).
Пропускная способность потока зависит от качества и вычислительной мощности принимающей стороны. Вы можете рассчитывать на 0,5 Мбит / с на одного клиента. Это примерно эквивалент DVD со сжатием DivX.
Вам следует попробовать найти решение, в котором серверу (-ам) не нужно выполнять кодирование или перекодирование, а поток уже имеет правильный формат. Особенно на клиентской основе.
Высококачественное оборудование стоит пропорционально дороже, и вы столкнетесь с проблемами, если оно выйдет из строя. Попробуйте создать ферму из недорогих серверов стоимостью менее 1000 долларов и при необходимости запасной. Использование одного и того же образа для системного диска для серверов - хорошая идея.
При использовании только потоковых данных - без кодирования / перекодирования - узкое место возникает из сетевых интерфейсов (и, возможно, сетевой инфраструктуры). Вы должны рассчитывать, что не должно превышать 10% названной пропускной способности интерфейсов, иначе соединения будут замедляться.
Я не уверен, что ваша сеть везде оборудована для обработки дополнительного трафика 500 Мбит / с (с пропускной способностью <10%). Если нет, вы можете попробовать сделать серверы для каждого местоположения или сократить полосу пропускания. Вы можете использовать пять серверов с гигабитным Ethernet, но их нельзя подключить к концентратору с одним гигабитным восходящим каналом.
Надеюсь это поможет.
Свяжитесь с ребятами из TightwadTech, это прямо на их улице, и, надеюсь, мы получим из этого подкаст :-)