[Хд] logo

Хостинг на 500Тб

Хостинг и отдача большого количества медиа данных в Web — одна из самых сложных задач. Видео и аудио файлы могут достигать гигабайтов в размере. Как выглядят реальные решения на примере одного из крупнейших файловых хостингов в СНГ.

Цифры

500ТБ общий объем данных, 2 ТБ данных загружаются каждый день



100 тысяч одновременных соединений



250 Гбит/с исходящий трафик, 80 Гбит/с максимальный трафик с одного сервера



На 60% загружены сервера отдачи



Используемое ПО

  • Linux Ubuntu платформа
  • Nginx Web сервер
  • Bcachemx модуль ядра для блочного кэширования, идея bcache, переписан практически полностью
  • FTP сервер Pyftp написан на питоне на основе стандартных библиотек для работы с FTP
  • Ffmpeg, x264 для кодирования видео
  • Redis для хранения данных статистики
  • Mysql + Handlersocket как основное хранилище информации о файлах

    Система хранения файлов

    В системе присутствуют четыре типа серверов. Структура медиа хостинга

    1. Сервера хранения

    Как правило, это 4U сервера с 36 дисками по 4ТБ. Все файлы хранятся на них. Уникальным идентификатором каждого файла является md5 хеш его содержимого, каждый файл хранится на 2х разных серверах для обеспечения отказоустойчивости. Простои из-за неработоспособности какого-то сервера случаются достаточно редко, потому от трехкратного дублирования отказались.

    Жесткие диски используются отдельно (не в RAID). Кроме того, в сервере присутствует 4 SSD диска для кэширования горячих данных. Служат эти SSD для того, чтобы снимать кратковременные повышенные нагрузки на диски в следствие появления на них популярных файлов, которые еще не успели скопироваться на сервера кэширования.

    Для распределения нагрузки и кэширования используется система, которая изначально основывалась на Bcache, но в итоге была переписана полностью. Более подробное ее описание чуть ниже.

    Каждый сервер способен утилизировать 12-13Гбит, на практике 10Г порт у них один и скорость в пиках доходит до 8 Гбит.

    На текущий момент используется 10 таких серверов.

    2. Upload сервера

    Загрузка файлов

    На них работает FTP сервер, через который файлы и попадают в CDN. Этот сервер считает md5 сумму файлов в реальном времени. Те файлы, которые уже есть в системе, удаляются. Остальные попадают во временное хранилище. Там файлы находятся до завершения их копирования на сервера хранения. Сразу после этого, файл становится доступен для скачивания.

    Данные сервера используют 6 жестких дисков в RAID 1+0 не считая системных. Канал 10Г, но нагрузка редко превышает 2-3Гбита.

    3. Сервера кодирования

    Служат для преобразования видеофайлов в формат, подходящий для воспроизведения онлайн и на мобильных устройствах (mp4, h264). Это 1U сервера с двумя серьезными процессорами (E2670 и выше) и тремя жесткими дисками в RAID 0 + системный. Для кодирования файлы из очереди сначала закачиваются на сервер, кодируются и удаляются, а результат кодирования переносится на сервера хранения. Перекодированные файлы в системе представлены аналогично остальным.

    4. Сервера кэширования

    Серверы с несколькими оптическими 10Г портами и SSD дисками. Кэши хранит самые востребованные файлы системы, наполняются на основе данных системы сбора статистики. Используется 2 вида серверов: Кэширование медиа хостинга

    1. Региональные кэши

    Ставятся в точки обмена трафиком и у крупных провайдеров. 8-16 SSD дисков по 240ГБ, один топовый четырехъядерный процессор и двухпортовая оптическая карта. Способны полностью утилизировать 20Г канал (строится на базе транка из двух 10Г).

    2. Суперкэши

    Способны утилизировать 80 Г с одного сервера. Используются процессоры E5-2687W в паре, 24 SSD, подключенные к трем отдельным 8ми портовым контроллерам без экспандеров (для этого используется специальный корпус). Кроме того, содержат 4 оптические двухпортовые карты (суммарно, 8 10Г портов) и 256+ ГБ оперативной памяти.

    Для раздачи используют ту систему кэширования, что работает на серверах хранения, но в другой конфигурации. Базовым хранилищем являются SSD диски, а быстрым кэшем — оперативная память, на которую приходится больше половины генерируемого трафика. Кроме того, используется пропатченная версия Nginx для связки с этой системой кэширования.

    Изначально, из памяти был сделан RAMdisk в который фоново копировались самые популярные файлы с SSD. Это было достаточно простое решение и позволяло использовать стандартный Nginx, но больше 70 Гбит выжать с такой конфигурации не удалось. Система блочного кэширования добавила 10 Гбит и мы уперлись в максимум, который обеспечивает данная архитектура.

    При такой нагрузке, оперативная память работает на 90% своей максимальной скорости, аналогично нагружены SSD диски и процессор.

    Основную нагрузку берут на себя 3 суперкэша, которые загружены на 60% в пиках. Т.е. падение одного сервера не приводит к проседанию по скорости. 60Г приходится на региональные кэши, остальное раздается с серверов хранения.

    Балансировщики нагрузки

    Балансировка файлов

    Система, которая распределяет файлы по серверам хранения работает просто: выбирает случайный сервер и на нем случайный диск и копирует файлы туда. В фоновом режиме работает служба, которая перераспределяет файлы, если где-то случается неравномерная заполняемость.

    Система статистики

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

    Данные, которые отдает этот модуль по каждому серверу, агрегируются в специальные таблицы:

    Таблица состояния серверов и жестких дисков.
    Статистика дисков

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

    Таблица ratio файлов
    Ratio файлов

    Для каждого уникального файла (md5 хеша) рассчитывается отношение трафика, который генерировал файл за последнее время к его размеру. Это отношение и является ratio — параметр, на основе которого составляется список файлов, которые должны находиться на кэширующих серверах.

    Система распределения файлов сверяется с таблицей по каждому серверу, удаляет те файлы, которых на кэше больше быть не должно и копирует те, которых не хватает. За счет того, что обновление статистики происходит достаточно часто (1-2 раза в минуту), списки файлов меняются незначительно, потому популярные файлы уходят на кэширующие сервера достаточно оперативно.

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

    Блочное кэширование

    Блочное кэширование

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

    Однако, разбиение файла на части и разнесение частей по разным хранилищам допустимо только внутри одного сервера. Дело в том, что у нас не используется отдельных проксирующих серверов, которые могли бы собирать файл с разных серверов и отдавать его клиенту целиком. Так, как важная обязанность CDN — дать возможность клиенту скачать любой файл просто по http протоколу, то приходится смириться с необходимостью держать каждый файл целиком на любом из серверов, с которых он может отдаваться.

    Самое важное

    Эта статья описывает одну из реальных CDN структур, которая используется для отдачи большого количества медиа-данных. Полезные и интересные решения:

    • Кэширование не целых файлов, а отдельных блоков позволяет существенно повысить эффективность работы кэша
    • Постоянная фоновая перебалансировка позволяет избежать трудных операций при установке нового оборудования
    • Хранение файла сразу на двух серверах обеспечивает отказоустойчивость и дополнительную балансировку
    • Ubuntu отлично подходит для решения сложных задач
  • [Хд]

    Подписывайтесь на отборные материалы по продвинутой разработке

    Google Email

    Esc, чтобы подписаться позже