Хостинг и отдача большого количества медиа данных в Web – одна из самых сложных задач. Видео и аудио файлы могут достигать гигабайтов в размере. Как выглядят реальные решения на примере одного из крупнейших файловых хостингов в СНГ.
500ТБ общий объем данных, 2 ТБ данных загружаются каждый день
100 тысяч одновременных соединений
250 Гбит/с исходящий трафик, 80 Гбит/с максимальный трафик с одного сервера
На 60% загружены сервера отдачи
В системе присутствуют четыре типа серверов.
Как правило, это 4U сервера с 36 дисками по 4ТБ. Все файлы хранятся на них. Уникальным идентификатором каждого файла является md5 хеш его содержимого, каждый файл хранится на 2х разных серверах для обеспечения отказоустойчивости. Простои из-за неработоспособности какого-то сервера случаются достаточно редко, потому от трехкратного дублирования отказались.
Жесткие диски используются отдельно (не в RAID). Кроме того, в сервере присутствует 4 SSD диска для кэширования горячих данных. Служат эти SSD для того, чтобы снимать кратковременные повышенные нагрузки на диски в следствие появления на них популярных файлов, которые еще не успели скопироваться на сервера кэширования.
Для распределения нагрузки и кэширования используется система, которая изначально основывалась на Bcache, но в итоге была переписана полностью. Более подробное ее описание чуть ниже.
Каждый сервер способен утилизировать 12-13Гбит, на практике 10Г порт у них один и скорость в пиках доходит до 8 Гбит.
На текущий момент используется 10 таких серверов.
На них работает FTP сервер, через который файлы и попадают в CDN. Этот сервер считает md5 сумму файлов в реальном времени. Те файлы, которые уже есть в системе, удаляются. Остальные попадают во временное хранилище. Там файлы находятся до завершения их копирования на сервера хранения. Сразу после этого, файл становится доступен для скачивания.
Данные сервера используют 6 жестких дисков в RAID 1+0 не считая системных. Канал 10Г, но нагрузка редко превышает 2-3Гбита.
[ad]
Служат для преобразования видеофайлов в формат, подходящий для воспроизведения онлайн и на мобильных устройствах (mp4, h264). Это 1U сервера с двумя серьезными процессорами (E2670 и выше) и тремя жесткими дисками в RAID 0 + системный. Для кодирования файлы из очереди сначала закачиваются на сервер, кодируются и удаляются, а результат кодирования переносится на сервера хранения. Перекодированные файлы в системе представлены аналогично остальным.
Серверы с несколькими оптическими 10Г портами и SSD дисками. Кэши хранит самые востребованные файлы системы, наполняются на основе данных системы сбора статистики. Используется 2 вида серверов:
Ставятся в точки обмена трафиком и у крупных провайдеров. 8-16 SSD дисков по 240ГБ, один топовый четырехъядерный процессор и двухпортовая оптическая карта. Способны полностью утилизировать 20Г канал (строится на базе транка из двух 10Г).
Способны утилизировать 80 Г с одного сервера. Используются процессоры E5-2687W в паре, 24 SSD, подключенные к трем отдельным 8ми портовым контроллерам без экспандеров (для этого используется специальный корпус). Кроме того, содержат 4 оптические двухпортовые карты (суммарно, 8 10Г портов) и 256+ ГБ оперативной памяти.
Для раздачи используют ту систему кэширования, что работает на серверах хранения, но в другой конфигурации. Базовым хранилищем являются SSD диски, а быстрым кэшем – оперативная память, на которую приходится больше половины генерируемого трафика. Кроме того, используется пропатченная версия Nginx для связки с этой системой кэширования.
Изначально, из памяти был сделан RAMdisk в который фоново копировались самые популярные файлы с SSD. Это было достаточно простое решение и позволяло использовать стандартный Nginx, но больше 70 Гбит выжать с такой конфигурации не удалось. Система блочного кэширования добавила 10 Гбит и мы уперлись в максимум, который обеспечивает данная архитектура.
При такой нагрузке, оперативная память работает на 90% своей максимальной скорости, аналогично нагружены SSD диски и процессор.
Основную нагрузку берут на себя 3 суперкэша, которые загружены на 60% в пиках. Т.е. падение одного сервера не приводит к проседанию по скорости. 60Г приходится на региональные кэши, остальное раздается с серверов хранения.
Система, которая распределяет файлы по серверам хранения работает просто: выбирает случайный сервер и на нем случайный диск и копирует файлы туда. В фоновом режиме работает служба, которая перераспределяет файлы, если где-то случается неравномерная заполняемость.
[ad]
Одной из самых важных частей является система сбора статистики. Для этого был написан специальный модуль Nginx. Он выводит данные о том, какие файлы качались с момента последнего запроса к статистике (какими клиентами, с какой скоростью и т.п.). В отличие от парсера логов, этот модуль позволяет собрать информацию и о тех файлах, которые еще не докачались, что сильно улучшает эффективность работы статистики.
Данные, которые отдает этот модуль по каждому серверу, агрегируются в специальные таблицы:
На основе данных о количестве соединений, трафике, проценту загруженности по iostat и данных от системы кэширования, считается условный процент загруженности (сервера в целом и каждого диска в отдельности). Считается в процентах (0-100) по формуле, которая учитывает текущую загруженность и максимально допустимые параметры для каждой величины, выведенные опытным путем для каждого типа сервера и диска в отдельности. На основе этой таблицы, система решает с какого именно сервера и диска отдать файл в момент запроса.
Для каждого уникального файла (md5 хеша) рассчитывается отношение трафика, который генерировал файл за последнее время к его размеру. Это отношение и является ratio – параметр, на основе которого составляется список файлов, которые должны находиться на кэширующих серверах.
Система распределения файлов сверяется с таблицей по каждому серверу, удаляет те файлы, которых на кэше больше быть не должно и копирует те, которых не хватает. За счет того, что обновление статистики происходит достаточно часто (1-2 раза в минуту), списки файлов меняются незначительно, потому популярные файлы уходят на кэширующие сервера достаточно оперативно.
Для распределения файлов внутри сервера используется исключительно система блочного кэширования, которая сама считает статистику внутри сервера и решает, какие блоки нужно сохранить в кэше или продублировать на другом диске хранилища, в зависимости от настроек.
Важное отличие системы блочного кэширования от основной системы распределения файлов в том, что они оперирует не целыми файлами, а блоками (по 16 МБ в нашем случае, но размер может быть и другим). Практика показывает, что для больших файлов первые блоки являются примерно втрое более популярными, чем последние (и вдвое, чем в среднем по файлу). Потому, кэширование только наиболее востребованной части файла позволяет эффективнее использовать ограниченный объем быстрого кэша.
Однако, разбиение файла на части и разнесение частей по разным хранилищам допустимо только внутри одного сервера. Дело в том, что у нас не используется отдельных проксирующих серверов, которые могли бы собирать файл с разных серверов и отдавать его клиенту целиком. Так, как важная обязанность CDN – дать возможность клиенту скачать любой файл просто по http протоколу, то приходится смириться с необходимостью держать каждый файл целиком на любом из серверов, с которых он может отдаваться.
Эта статья описывает одну из реальных CDN структур, которая используется для отдачи большого количества медиа-данных. Полезные и интересные решения:
Сегодня мы поговорим о том, как выбрать лучшие курсы Power BI в Украине, особенно для…
В 2023 году во всех крупнейших регионах конкуренция за вакансию выросла на 5–12%. Не исключением…
Unicorn Hunter/Talent Manager Лина Калиш создала бесплатный трекер поиска работы в Notion, систематизирующий все этапы…
Edtech-стартап Mate academy принял решение отправить своих работников в десятидневный отпуск – с 25 декабря…
Служба безопасности Украины задержала в Киеве 46-летнего программиста, который за деньги устанавливал шпионские программы и…
IT-специалист Джордан Катлер создал и выложил на Github подборку разнообразных ресурсов, которые помогут достичь уровня…