Про офлоадинг — речь про аппаратный разбор SRH. Разгрузка обработки End.DX4/DT6. По аналогии с разгрузкой VXLAN на сетевой карте. Операция далеко не бесплатная, хоть на VPP она и делается сильно шутсрее чем в ядре, но всеж за счет ресурсов компьюта(не бесплатных) Ваш ответ понял — используете софтовую разгрузку на VPP за счет векторизации операций.
Обратите внимание, что использование AVX2/AVX512 сильно не бесплатны для CPU и тротлят ему частоту, что снижает эффективность утилизации гипервизора в целом.
Про скорость линков тоже понял. Странно что не 2х100G. С учетом трафика SDS это не очень толстая полоса. К примеру, нам в расчетных характеристиках и 2х100G было тесно для обеспечения высоких IOPS. Не говоря уж про сверхплотные гипервизоры.
Если TE вам не нужно, то как гарантируете полосу и латентность своим клиентам? Как боритесь с кейсом ассиметричной нагрузки разными клиентами? А трафик хранилки относительно клиентов? Понятно что все это делается SIDами, но только при программировании всего пути по фабрике с пристройкой QoS. Возможно вы знаете альтернативный способ?
Низколатентный трафик — трафик требующий приоритета не по ширине полосы, а по очереди в буферах rx/tx. У клиента виртуализации полно сценариев где он ожидает привычный джиттер без переподписки. (кеши, HFT, кворумные механизмы, невросетки, синхронные репликации и т.д) Не знаю как у вас, но обычно и в самой платформе виртуализации есть низколатентный трафик (например при живой миграции VM требуется синхронизировать виртуальную память и на определенных сценариях нагрузки клиентской VM латентность сети становится узким местом)
L2 связность в VPC — камон, даже в 2126 потребность в L2 останется в корпоративном сегменте. Огромное число проприоритарных решений использует L2-протоколы (HFT, репликации, дискаверинг, мультимедиа и т.д) Да даже банальные тестовые среды инфраструктурных компонент без L2 становятся болью.
Мы в далеком прошлом сбежали из одного Клауда на последнюю букву русского алфавита, потому что устали строить свой оверлей поверх из VPC чтоб запустить нормально IPv6. А подавляюще большинство т.н отечественного софта из реестра отечественного ПО для резервирования все еще использует VRRP и требует единый боардкаст домен.
Увы, все мечтают избавится от L2, но все прикручивают для него костыли. И лучше, когда они системные.
Для L2 в SRv6 тоже все есть, но придется или городить свой контролплейн или откатится к уже решенной задаче — SRv6 + EVPN.
Ну и про VMки продавать может любой школьник — это конечно очень оптимистично. VMки со SLA, быстрыми дисками и быстрой сетью (хотяб уровня VMWARE) в РФ крайне проблематично получить. А там где их получить можно встречаются все те же иностранные вендоры. «Продвинутый» провайдер облака IaaS для корпоративных клиентов — это не тот, кто предоставляет массу PaaS-услуг, а тот кто выдерживает SLA по базовым метрикам IaaS. Так, чтоб миграция корпората своей привычной инфрой с железяк с VMWare в облако проходила без боли и унижения :-) А потом уже можно апсейлить PaaS бусами…
P.S: мы когда проектировали компонент SDN для он-прем платформы, выбрали решение EVPN как контролплейн и MPLS как датаплейн. При том, что VPР занимается лейблингом. И тоже IPv6-only андерлей. Собственно я потому на TE и делаю акцент, что в нашей схеме мы не придумали эффективный TE без подпорок. А в SRv6 это сделать проще.
SRv6 вещь хорошая, но еще хуже поддерживаемая вендорами нежели VXLAN EVPN. Да и encap/decap не офлоадитсяся на серверах и кушает CPU, что на широких линках несет значимые расходы.
SRv6 без централизованного контроллера приводит к плохому TE, а централизованный контроллер — весьма сложная и ресурсоемкая вещь.
А так, идея классная — L3 фабрика от хоста. Сам был автором похожей конструкции :-)
По части телеметрии рекомендую взглянуть на IOAM. Для него даже в VPP кажется планинчик был.
Пару вопросов: — какова ширина физического канала до хоста? — чем строите TE (если ваши вагоны не крашенные, значит нет QoS на андерлее) — как решаете проблему VPP связанную с низколатентным трафиком? (архитектура VPP ориентирована на максимальную утилизацию полосы в жертву латентности) — чем обеспечивается потребность в L2 между VM? (Как с т.з датаплейна, так и контролплейна)
Отличная статья. Понимаю что получилось очень много, однако после детального рассказа про параллелизм в обучении, прям не хватало обратного пути запроса — кластеризация для инференса. Полагаю, что подходы к построению сетей в кластерах для обучения и для инференса могут отличатся?
Бушующие за малыми ядерными реакторами замкнутого цикла с длительным сроком эксплуатации на одной загрузке. IMHO
Вот сделали бы в формате морского контейнера, мегаватт на 25 и сроком эксплуатации лет 20 — тогда можно ЦОДы хоть в поле ставить и планово ротировать источники на обслуживание и перегрузку топлива.
Как-то это не по облачному. Даже засомневался что статья в блоге VK…
Схема стара как мир и много где работает для связи площадок, но у VK облака есть VPNaaS и продвинутый маршрутизатор Sprut с динамической маршрутизацией посредством BGP ECMP. (Управлять приоритетом при этом будет сторона on-premise)
Все описано в документации и настраивается очень просто.
Подход к IaaS подразумевает, что нужно использовать инфраструктуру как сервис везде, где платформа это предоставляет, а не строить поверх платформы дополнительную инфраструктуру.
Потому что при проектировании натянули ужа на ежа. Попытка скрестить OLTP и OLAP в рамках классической РСУБД всегда приводит к таким монстрам.
При переезде могли бы и учесть ошибки прошлых лет и построить архитектуру Data Lakehouse и golden layer с витринами на РСУБД. Было бы на порядки проще масштабировать в петабайты, развивать функциональность и постепенно мигрировать поставщиков данных на чистую архитектуру, без тайных знаний по кодированию данных на стороне клиента.
Стадно. Клонировать кривую архитектуру 1:1, а не реализовывать бизнес-требования к системе. Так обычно бывает, когда заказчик дает не требования, а требует решение в своей архитектуре. Но другой, заказной разработки по госконтрактам у нас для вас нет. Все ушли в продуктовую…
Тема раскрыта не полностью: есть на рынке игро и, которые готовы заключать долгосрочные контракты на дедик с последующим выкупом по остаточной и переходом на колок. Да, дедик получается чуть дороже, да привязка к конкретному оператору ЦОД, но можно получить нужную конфигурацию железа и существенную часть capex превратить в opex. И такая схема на 50% дешевле облака (а то и больше)
Облака, как основная инфраструктура нужны или очень маленьким компаниям либо коротким проектам с большим потреблением
Для того, чтобы понять все лицемерие продвиженцев копилефта, достаточно внимательно посмотреть под чьей юрисдикцией работают т.н фонды свободы ПО и как в этой юрисдикции работают экспортные ограничения.
Никакой свободой распространения там даже не пахнет. Все это было придумано для надувания щек и раздувания ЧСВ. А вирусная природа копилефта — способ недобросовестной конкуренции, убивающий инвестиции в ИТ.
Любой, более-менее крупный программный продукт — это десятки или сотни человеко-лет на разработку и тестирование. Увы, но альтруистов среди профессионалов мало. Профессиональные разработчики знают цену своего времени и «голодать за еду» не готовы. Так, что в отсутствии правовых механизмов защиты интеллектуальной собственности от создания производных произведений, созданных такими разработчиками, коммерциализировать можно только поддержку. А это уже совсем другой бизнес, в задачи которого не входит создание чего-то нового. Потому-то вся эта история с т.н «свободным ПО» не идет во благо развитию индустрии.
Основная проблема Ceph – плохая прогнозируемость эксплуатации. Строить коммерческие системы на нем можно, точно понимая что делать во время отказа и имея в запасе инженерную команду, способную эти проблемы чинить на уровне кода.
Это совсем другая модель и компаниям, которые не занимаются разработкой системного ПО такой подход не годится.
IOPS – показатель, зависящий от аппаратных возможностей оборудования. Одной из целей подсистемы хранения, является сокращение аппаратных требований по части подсистемы IO. В масштабных почтовых системах, в каждый момент времени, происходит большое количество операций над небольшими или средними объектами и это является одним из слабых мест «классических» архитектур. В Mailion мы постарались учесть такие слабые места и исправить их на уровне архитектуры решения.
Про подсистему хранения мы обязательно напишем в ближайшее время.
В состав решения Mailion входит специальный плагин для MS Outlook, который позволяет прозрачно заменить сервер MS Exchange и сохранить полную функциональность решения и добавляет дополнительные возможности.
Мне не известны решения, которые предоставляли такой прозрачный переход.
MTA в Mailion выполняет ~1% всех функций. Если очень грубо говорить, то это просто очередь доставки и транспорт SMTP (больше, в нашем случае, MTA ничем не занимается) MDA у нас собственной разработки.
Процессы прохождения стадий обработки от «SMTP HELLO» до того как пользователь прочитает письма, большая и сложная тема. Если к ней будет интерес, то обязательно расскажем.
Про офлоадинг — речь про аппаратный разбор SRH. Разгрузка обработки End.DX4/DT6. По аналогии с разгрузкой VXLAN на сетевой карте.
Операция далеко не бесплатная, хоть на VPP она и делается сильно шутсрее чем в ядре, но всеж за счет ресурсов компьюта(не бесплатных)
Ваш ответ понял — используете софтовую разгрузку на VPP за счет векторизации операций.
Обратите внимание, что использование AVX2/AVX512 сильно не бесплатны для CPU и тротлят ему частоту, что снижает эффективность утилизации гипервизора в целом.
Про скорость линков тоже понял. Странно что не 2х100G. С учетом трафика SDS это не очень толстая полоса. К примеру, нам в расчетных характеристиках и 2х100G было тесно для обеспечения высоких IOPS. Не говоря уж про сверхплотные гипервизоры.
Если TE вам не нужно, то как гарантируете полосу и латентность своим клиентам? Как боритесь с кейсом ассиметричной нагрузки разными клиентами? А трафик хранилки относительно клиентов?
Понятно что все это делается SIDами, но только при программировании всего пути по фабрике с пристройкой QoS. Возможно вы знаете альтернативный способ?
Низколатентный трафик — трафик требующий приоритета не по ширине полосы, а по очереди в буферах rx/tx. У клиента виртуализации полно сценариев где он ожидает привычный джиттер без переподписки. (кеши, HFT, кворумные механизмы, невросетки, синхронные репликации и т.д)
Не знаю как у вас, но обычно и в самой платформе виртуализации есть низколатентный трафик (например при живой миграции VM требуется синхронизировать виртуальную память и на определенных сценариях нагрузки клиентской VM латентность сети становится узким местом)
L2 связность в VPC — камон, даже в 2126 потребность в L2 останется в корпоративном сегменте. Огромное число проприоритарных решений использует L2-протоколы (HFT, репликации, дискаверинг, мультимедиа и т.д)
Да даже банальные тестовые среды инфраструктурных компонент без L2 становятся болью.
Мы в далеком прошлом сбежали из одного Клауда на последнюю букву русского алфавита, потому что устали строить свой оверлей поверх из VPC чтоб запустить нормально IPv6.
А подавляюще большинство т.н отечественного софта из реестра отечественного ПО для резервирования все еще использует VRRP и требует единый боардкаст домен.
Увы, все мечтают избавится от L2, но все прикручивают для него костыли. И лучше, когда они системные.
Для L2 в SRv6 тоже все есть, но придется или городить свой контролплейн или откатится к уже решенной задаче — SRv6 + EVPN.
Ну и про VMки продавать может любой школьник — это конечно очень оптимистично. VMки со SLA, быстрыми дисками и быстрой сетью (хотяб уровня VMWARE) в РФ крайне проблематично получить. А там где их получить можно встречаются все те же иностранные вендоры. «Продвинутый» провайдер облака IaaS для корпоративных клиентов — это не тот, кто предоставляет массу PaaS-услуг, а тот кто выдерживает SLA по базовым метрикам IaaS. Так, чтоб миграция корпората своей привычной инфрой с железяк с VMWare в облако проходила без боли и унижения :-)
А потом уже можно апсейлить PaaS бусами…
P.S: мы когда проектировали компонент SDN для он-прем платформы, выбрали решение EVPN как контролплейн и MPLS как датаплейн. При том, что VPР занимается лейблингом. И тоже IPv6-only андерлей. Собственно я потому на TE и делаю акцент, что в нашей схеме мы не придумали эффективный TE без подпорок. А в SRv6 это сделать проще.
SRv6 вещь хорошая, но еще хуже поддерживаемая вендорами нежели VXLAN EVPN.
Да и encap/decap не офлоадитсяся на серверах и кушает CPU, что на широких линках несет значимые расходы.
SRv6 без централизованного контроллера приводит к плохому TE, а централизованный контроллер — весьма сложная и ресурсоемкая вещь.
А так, идея классная — L3 фабрика от хоста. Сам был автором похожей конструкции :-)
По части телеметрии рекомендую взглянуть на IOAM. Для него даже в VPP кажется планинчик был.
Пару вопросов:
— какова ширина физического канала до хоста?
— чем строите TE (если ваши вагоны не крашенные, значит нет QoS на андерлее)
— как решаете проблему VPP связанную с низколатентным трафиком? (архитектура VPP ориентирована на максимальную утилизацию полосы в жертву латентности)
— чем обеспечивается потребность в L2 между VM? (Как с т.з датаплейна, так и контролплейна)
Вроде как NVIDIA QM97xx умеет dual-mode порты. Но я в IB не очень силен.
Есть еще вариант софтверный ib2roce, возможно его можно завести на вайтбоксе.
Ну и да, с IB основная засада — вендор лок, впрочем с AI итак много вендор лока в области GPU.
С RoCE больше напрягает отдельное лицензирование фитчи у некоторых вендоров коммутаторов.
Спасибо. Хорошо бы затронуть эту тему, потому что она действительно сильно влияет на экономику проекта в целом.
И еще вопрос: что вы думаете на тему IB в рамках стойла, а в рамках зала уже RoCE?
Кажется что строить большие фабрики IB оаерпрайс.
Отличная статья. Понимаю что получилось очень много, однако после детального рассказа про параллелизм в обучении, прям не хватало обратного пути запроса — кластеризация для инференса. Полагаю, что подходы к построению сетей в кластерах для обучения и для инференса могут отличатся?
Да все понятно. Так рассуждает каждый интегратор, который что-то интегрирует в такую ГИС. Потому и получаются монстры обмазанные тайными знаниями.
Не, ну а чо — поставленная задача решена, а остальное проблемы эксплуатанта.
Бушующие за малыми ядерными реакторами замкнутого цикла с длительным сроком эксплуатации на одной загрузке. IMHO
Вот сделали бы в формате морского контейнера, мегаватт на 25 и сроком эксплуатации лет 20 — тогда можно ЦОДы хоть в поле ставить и планово ротировать источники на обслуживание и перегрузку топлива.
Как-то это не по облачному. Даже засомневался что статья в блоге VK…
Схема стара как мир и много где работает для связи площадок, но у VK облака есть VPNaaS и продвинутый маршрутизатор Sprut с динамической маршрутизацией посредством BGP ECMP. (Управлять приоритетом при этом будет сторона on-premise)
Все описано в документации и настраивается очень просто.
Подход к IaaS подразумевает, что нужно использовать инфраструктуру как сервис везде, где платформа это предоставляет, а не строить поверх платформы дополнительную инфраструктуру.
Потому что при проектировании натянули ужа на ежа. Попытка скрестить OLTP и OLAP в рамках классической РСУБД всегда приводит к таким монстрам.
При переезде могли бы и учесть ошибки прошлых лет и построить архитектуру Data Lakehouse и golden layer с витринами на РСУБД. Было бы на порядки проще масштабировать в петабайты, развивать функциональность и постепенно мигрировать поставщиков данных на чистую архитектуру, без тайных знаний по кодированию данных на стороне клиента.
Стадно. Клонировать кривую архитектуру 1:1, а не реализовывать бизнес-требования к системе.
Так обычно бывает, когда заказчик дает не требования, а требует решение в своей архитектуре. Но другой, заказной разработки по госконтрактам у нас для вас нет. Все ушли в продуктовую…
Тема раскрыта не полностью: есть на рынке игро и, которые готовы заключать долгосрочные контракты на дедик с последующим выкупом по остаточной и переходом на колок. Да, дедик получается чуть дороже, да привязка к конкретному оператору ЦОД, но можно получить нужную конфигурацию железа и существенную часть capex превратить в opex. И такая схема на 50% дешевле облака (а то и больше)
Облака, как основная инфраструктура нужны или очень маленьким компаниям либо коротким проектам с большим потреблением
Для того, чтобы понять все лицемерие продвиженцев копилефта, достаточно внимательно посмотреть под чьей юрисдикцией работают т.н фонды свободы ПО и как в этой юрисдикции работают экспортные ограничения.
Никакой свободой распространения там даже не пахнет. Все это было придумано для надувания щек и раздувания ЧСВ. А вирусная природа копилефта — способ недобросовестной конкуренции, убивающий инвестиции в ИТ.
Любой, более-менее крупный программный продукт — это десятки или сотни человеко-лет на разработку и тестирование. Увы, но альтруистов среди профессионалов мало. Профессиональные разработчики знают цену своего времени и «голодать за еду» не готовы. Так, что в отсутствии правовых механизмов защиты интеллектуальной собственности от создания производных произведений, созданных такими разработчиками, коммерциализировать можно только поддержку. А это уже совсем другой бизнес, в задачи которого не входит создание чего-то нового. Потому-то вся эта история с т.н «свободным ПО» не идет во благо развитию индустрии.
А что не так с решениями от Huawei?
тру инженеры парсят /proc глазами :-)
Довольно неплохо разобран типовой отказ Ceph тут
Основная проблема Ceph – плохая прогнозируемость эксплуатации. Строить коммерческие системы на нем можно, точно понимая что делать во время отказа и имея в запасе инженерную команду, способную эти проблемы чинить на уровне кода.
Это совсем другая модель и компаниям, которые не занимаются разработкой системного ПО такой подход не годится.
В статье опечатка, речь идет про историю CloudMouse
Если поискать на Habr
Про подсистему хранения мы обязательно напишем в ближайшее время.
Мне не известны решения, которые предоставляли такой прозрачный переход.
Процессы прохождения стадий обработки от «SMTP HELLO» до того как пользователь прочитает письма, большая и сложная тема. Если к ней будет интерес, то обязательно расскажем.