Забегая вперед, никакого рокет сайнса тут не будет, скорее просто для истории, как мы пришли к текущему решению.

Исторически, было дано: проприетарный сторадж Huawei OceanStor 5500f, общим полезным объемом несколько сотен терабайт. На нем лежат видео в формате mp4 (эфирные - пережатые из mxf), а также их мультибитрейтный вариант вместе c fmp4-HLS плейлистами и DASH манифестами.

Предыдущая команда, видимо, любила энтерпрайз, поэтому приобрела очень специфическое сетевое железо, а именно два Brocade ServerIron ADX 4000, суть которых сводилась к поддержке BGP для анонса своих реальных подсетей и очень сомнительного функционала балансировщика, похожим на ipvs. SSL при этом они не терминировали. Long story short, 1.5 года мучений, 8000+ страниц документации, включая, блин, скриптовый внутренний язык, осознание, что компания-производитель закрылась больше 8 лет назад, что прошивка у тебя еще старше, а новых прошивок нигде нет, но зато есть список изменений в этих прошивках, и примерно половина из них очень похожа на те проблемы, которые происходят. Например, можно было обычным ab создать 100% cpu usage.

За балансировщиком стояли несколько серверов медиа-раздачи, представляющие собой NGINX на bare metal, у которых в качестве try_files был указан примонтированный к ним по NFS сторадж. Никакого кеша, как видите, в этой схеме нет, а нагрузка интерфейсов стораджа регулируется разве что тем, какой из них примонтирован к конкретному серверу.

Сейчас у нас кубер, где несколько нод, являющиеся по совместительству ингресс-контроллерами, по BGP анонсят на наш новый центральный маршрутизатор адреса своих сервисов, таким образом, создавая ECMP aka BGP Anycast, это позволяет равномерно утилизировать два плеча интернет-канала и перераспределять нагрузку в случае падения.

Кеш теперь есть и он распределенный, что позволяет и увеличить его размер (каждая машина не обязана хранить полную копию) и обеспечить балансировку в пределах группы машин, отвечающих за этот диапазон ключа кеша. Реализовано посредством директив upstream-hash-by-subset*, с оговоркой, что ключем у нас являются уже конкретные byte-range запросы (slice). Также создали количество апстримов соответствующее количеству интерфейсов стораджа, чтобы и их утилизировать равномерно. А еще, тупо переставили диски между полкой и башкой так, чтобы их оказалось равное количество.

Итог - конечно, весь трафик пользователей мы не обрабатываем, но хотя бы справляемся с оригинацией популярного контента в сторону CDN и обслуживанием длинного хвоста видео, накопленных за почти 20 лет. IOPS-ы на сторадже существенно подросли, при этом мы не упираемся в потолок. Я бы написал stay tuned, но, честно говоря, на наших объемах дальнейшие улучшения не выглядят целесообразными. Разве что, безусловно, предпримем попытку переехать с проприетарного стораджа в цеф.