Comments 10
ИМХО, статья была бы интереснее и полезнее, если бы ее обозвали как "Чем хороша модель thread-per-core и как круто Seastar это эксплуатирует" и если бы в ней не было условно-полезного (точнее бесполезного) сравнения Seastar с Boost.Asio, userver и ACE. Т.к. с самого начала стало понятно, что для вас киллер-фича -- это именно thread-per-core, а все обозначенные "конкуренты" Seastar на такую модель не заточены (по крайней мере Boost.Asio и ACE, то userver не знаю).
Раздел же про mutex-ы и "подкрепление" тезиса о стоимости синхронизации графиками сравнения ScyllaDB и Cacandra... Ну такое себе. Да, есть факт, что ScyllaDB шустрее, но вы же говорите о стоимости примитивов сихронизации, а демонстрируете производительность БД, в которых кроме примитивов синхронизации еще куча разного и разнообразного (включая и тот факт, что эти СУБД на разных языках написаны).
В общем, есть сильное ощущение, что выбор в ваших условиях однозначно за Seastar, а остальные фреймворки были добавлены для того, чтобы придать этому выбору некую объективность. Ну так и рассказывали бы больше о плюшках Seastar, не отвлекаясь на то, что вам не подошло. Статья бы получилась интереснее. Тем более, что Seastar заслуживает того, чтобы о нем рассказывали.
В своем же текущем формате статья оставляет впечатление изначальной предвзятости автора. И провоцирует позадавать вопросы из категории "А что, Boost.Asio в принципе нельзя использовать в модели thread-per-core?" или "Если mutex настолько дорог, то неужели так уж обязательно писать прикладной код на mutex-ах?" ;)
Вы по большому счету правы, однако было бы странно сразу перейти к нахваливанию Seastar за его killer фичи без краткого (о чем свидетельствует название статьи) сравнения с другими фреймворками, вследствие чего становится понятно, почему это именно killer фичи, а также позволяет избежать вопросов: «а что по поводу Boost.Asio», «а почему не попробовали userver» и т. п.
Более того содержимое статьи никак не противоречит вашему комментарию «Ну так и рассказывали бы больше о плюшках Seastar, не отвлекаясь на то, что вам не подошло». В статье так и есть - лишь краткое сравнение и обоснование, почему другие не подошли, а далее объемное (в рамках обзорной статьи) описание Seastar.
Спасибо за ваш комментарий, я учту его в будущих статьях :)
Вы по большому счету правы, однако было бы странно сразу перейти к нахваливанию Seastar за его killer фичи
Ничего странного, если бы рассказ был только про Seastar. Отдельным разделом статьи могло бы идти пояснение, почему вы считаете Seastar отличным выбором для работ над 5G. Хотя это было бы не обязательно, т.к. в самой статье не так уж и много говорится о специфике конкретно 5G.
В статье так и есть - лишь краткое сравнение и обоснование, почему другие не подошли
Ну вот как раз это обоснование и не выглядит убедительным :)
А не выглядит так, потому что в этом обосновании, что называется, "смешались кони, люди". Например, если вам нужен SCTP, а его нет нигде, кроме Seastar, то бессмысленно обсуждать затраты на синхронизацию в Boost.Asio или в userver.
ЗЫ. Все вышесказанное безусловное и злостное ИМХО.
Если мы говорим про ядро опорной сети, то от gNB трафик в UPF будет уходить строго с udp порта 2152, итого распределение на основе source порта точно не будет рабочим, так? И тогда останется только первый тип балансировки? Но это же udp, что в таком случае тут за “connection” и как будет обеспечиваться постоянное попадание нужного teid от нужной gNB в нужное ядро, т.к. видимо только в нем будут всякие far, qer и т.д. для этой сессии?
Перечисленные балансировки и POSIX network stack разумно будет использовать для control plane (UE registration, PDU session establishment, etc.) Для user plane в Seastar есть диспачинг пакетов с использованием RSS, т.е. можно взять Seastar native stack over DPDK и поехали.
т.е. балансировки в разделе статьи про Shared Nothing, это только про POSIX стек? Для нагрузок сигналинга и каких-то описанных сложностей не то, чтобы нужно. Там шардировать тоже по каким-то совсем другим критериям надо, если вообще шардировать.
Хорошо, тогда переходим к native stack+dpdk. Rss, он же только по связкам - src ip,sport,dst ip, dst port. В рамках одной пары gnb-upf набор для всех сессий пользователей будет один и тот же, и поэтому ляжет на одно ядро?
Я все это к тому, что либо понадобится какой-то другой балансер, или вот это вот shared nothing рано или поздно превратится в shared немало.
При росте количества активных пользователей и их сессий, наличие балансировки и шардирования позитивно скажется на скорости обработки control plane. Время выхода UE в состояние RM-REGISTERED, время получения мобилой PDU Session Establishment Accept - это важные метрики, которые надо стремиться улучшать.
В user plane домене я понимаю хуже, так что поправляйте, если что. UPF selection - это control plane процедура. Если большое количество UE заходят через один gNB - это не значит, что кора должна посадить их на один UPF. Теперь, если UE распределились по нескольким UPF, значит dst IP и dst port - разные, следовательно и RSS hash разный. Таким образом UP пойдет на разные ядра.
Спасибо, кроме всего прочего я узнал, что ACE ещё жив спустя двадцать лет. Удивительно стойкий солдатик. Упоминание CORBA в диаграмме компонент особенно умиляет.
А что касается фреймворков со своими реализациями сетевого стека: не страшно? Это же весьма нетривиальная штука, если они хоть одним глазком из публичного интернета видны то желающих уложить систему мобильному оператору найдутся сотни.
Если вопрос относительно POSIX stack, то seastar сильно много сверху не добавляет, а фактически передает управление в Linux.
Если речь про native stack, то можно посмотреть с двух сторон: 1) волков бояться — в лес не ходить :) хорошо что open-source, можно будет баг завести, либо самим починить 2) native stack можно просто не использовать, заменив чем-то другим.
Однако при выборе я бы не исходил из слишком уж больших опасений по поводу безопасности, потому что строго говоря, любая реализация может быть с багами, так что полагать, что у seastar их больше, чем у других - опрометчиво.
Уверенности придают кейсы использования этого фреймворка, а так же авторитетность людей, которые стоят у его истоков.
С одной стороны я понимаю "везде баги".
Но с другой, когда-то я выковыривал из проекта "менее известную" TLS библиотеку с более удобным API и заменял её на стандартный openssl. Потому что разбираясь с "чего это мы некоторые сайты скачать не можем", полез к ней в потроха и понял, что если мне такие багрепорты писать придётся, то что же там на более сложном уровне. Некоторые проекты попросту требуют вложенных десятков человеко-лет, иначе никак.
Но про seastar ничего не знаю, может там реально крутая команда.
Seastar как платформа для опорной сети 5G и краткое сравнение с Boost.Asio, userver и другими