Игорь Олемской — практические заметки по системному администрированию Linux CentOS

Cистема хостинга медиа (перепечатка)

Комментариев нет

flash_logo

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

Что такое подсистема хостинга медиа вообще? Это часть системы, которая отвечает за загрузку, сохранение, преобразование (транскодирование) и отдачу медиа файлов. Зачастую эта система является наиболее ресурсоемкой ввиду больших объемов данных и процессорных затрат.

Самое главное

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

Оборудование

Как всегда перед Вами выбор — покупать дорогой комплекс (файловый супер сервер) либо строить систему из дешевых серверов. Как всегда выбор падает на второй вариант, так как:

  • Решение обладает бесконечной масштабируемостью
  • Отсутствует единая точка сбоя (SPOF), делая это решение очень устойчивым к сбоям
  • Динамику наращивания железа легко контролировать
  • Дешевое оборудование — дешевое все остальное (коммутаторы, поддержка, замена и т.п.)

По сравнению с дорогостоящим комплексом, такое решение обладает единственным недостатком: реализацию самой подсистемы распределения файлов придется разрабатывать самим. При грамотном подходе это вовсе не большой кусок работы. На connect.ua переход на такое решение занял около недели (на тот момент у нас было 2.5 Тб данных).

Система репликации позволяет избежать установки дорогостоящих RAID контроллеров и уменьшает вероятность сбоя системы практически до нуля.

Архитектура

Перед нами стоят следующие задачи:

  • Загрузка файлов
  • Траскодирование файлов
  • Распредение файлов по серверам
  • Выдача файлов

В общем плане схема работы подсистемы такова:

media-hosting

Теперь детальнее. У нас есть ряд серверов-хранилищ, каждый из которых ничего не знает о всех остальных. Все они доступны извне под определенным адресом (например, m1.connect.ua, m2.connect.ua и т.п.). После получения файла (загрузка пользователя) на бекенд, мы выбираем из набора серверов тот, на который мы сохраним файл. Выбор делается на основе предпочитаемого критерия (случано; учитывая свободное место; учитывая загрузку процессора и т.п.).

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

Репликация

Для обеспечения стабильной работы применяется репликация на уровне приложения.
В этом случае все файлы сохраняются не на один, а на несколько серверов. При выходе одного сервера из строя, файл все равно будет доступен с другого. Имеет смысл копировать все файлы на два сервера, т.к. возможность выхода из строя сразу двух серверов очень мала. Выбирать более чем два сервера для копирования не обосновано в терминах затрат на объем хранилища.

Распределенные файловые системы

Обычно медиа-подсистемы характеризуются огромными объемами отдачи данных. Минус использования распределенных файловых систем в нашем случае в том, что Вы получаете огромный внутрисетевой трафик, и это выливается в малую эффективность при отдаче файлов. После ухода от GlusterFS на connect.ua наш исходящий медиа трафик вырос со 150 до 800 Мб/с.

Изоляция крупных и мелких файлов

Обязательно разносите мелкие и крупные файлы на разные физические хранилища (например, нужно разнести видео ролики и скриншоты к видео). Если они будут обслуживаться на одном сервере, то Ваша система будет медленнее черепахи. Это происходит потому, что чтение больших файлов не дает эффективно использовать дисковый кеш для мелких, и поэтому у Вас будет огромное количество рандомных чтений с диска. А это выльется в очень медленную отдачу файлов.

Cloud hosting

Сегодня большую популярность набирают cloud хостинги. Это решение имеет смысл, когда Вы планируете разработать и вывести прототипное решение.

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

Какие технологии Вы используете для обмена файлами между серверами? Используете ли распределенные файловые системы?

Google Bookmarks Digg I.ua Ru-marks Ruspace Zakladok.net Reddit delicious Technorati Yahoo My Web News2.ru БобрДобр.ru Memori.ru rucity.com
Related posts:
  1. Отдача и ресайзинг фотографий

Похожие записи:

  1. Connect.ua — история роста
  2. Оптимизация баннерной рекламы
  3. Используем Nginx, как кеширующий сервер
  4. RPM MC (Midnight Commander) 4.7.5 for CentOS 5
  5. Смертные грехи программистов

Комментировать