Комментарии 5
Чем обусловлен выбор border хостов на границе сети, вместо того чтобы роутить трафик прямо на compute ноды из мира условным evpn? В связке с isolcpu для vpp это будет довольно эффективно + нет точки отказа в виде бордер хоста.
Ну, на самом деле тут получится составить большой список, но, если обобщить, то можно выделить следующие пункты:
Вопрос безопасности прежде всего. Если выносить внешние маршруты на компьюты, это кратно увеличивает поверхность потенциальной атаки, а так же сложность управления политиками. Ну и часть инфраструктуры, которая не попала в данную работу по разным причинам
Разделение функций. Вместо хостов, которые неплохо делают и то, и то, акцент был сделан на узких специализациях и соответствующих оптимизациях. Сложно сказать, был бы какой-то выигрыш, если в тч на бордерах находились широкопрофильные компьюты, но за это часть ресурсов на всех компьютах всех зон было бы "отъедено" на разного рода уникальные для бордеров детали. При быстрой прикидке как будто бы нет
Ну и если говорить про точку отказа, то тут тоже не так все однозначно. Самое минимальное - это то, что когда речь идет о бордерах, то речь не об одном единственном серваке, а отказоустойчивом кластере с несколькими зонами. Если даже с целой зоной что-то случается - вторая зона подхватывает (как минимум такая схема позволяет обновлять инфраструктуру "невидимо" для клиентов)
Слабо представляется первая тема, не могли бы конкретизировать? Трафик в любом случае доедет до compute.
VPP очень производительный и выделить условно 1 ядро (уверен что так сейчас и делаете) не составит большого расхода, с учетом что на compute нодах он все равно запущен, прогнать несколько ACL не составит большого труда.
Когда мы говорим про увеличение поверхности атаки при прямом роутинге, речь не о том, что трафик не доедет до compute вовсе, а о том, что при централизованном border мы можем применять жёсткие политики до входа в underlay. Если эти же правила размазать по сотням compute-нод, сложнее гарантировать их синхронность и полноту, а так же контролировать изменения. Ну и сам факт того, что compute нода будет обязана тратить ресурсы на обработку внешнего трафика, при централизованном же есть гарантия, что по underlay перемещается уже сколько то отфильтрованный и причесанный по полосе трафик.
По поводу одного ядра и ACL. Ядро выделить-то можно, только пограничная обработка не ограничивается ACL, и тут мы снова утыкаемся в те же грабли, что и выше. Есть ещё нюанс с изоляцией: если внешний трафик валится напрямую на compute, сложнее гарантировать, что всплеск внешней нагрузки не повлияет на производительность виртуальных машин
Как виртуальные машины общаются в облаке MWS Cloud Platform: разбираем Data Plane