Какой практический смысл от виртуального сетевого оборудования известных вендоров в облаках?

Question

[muhazzz]

Вижу, что практически все производители сетевого оборудования (Cisco, Check Point, F5, Juniper...) повыпускали свои образы для маркетплейсов AWS, Google Cloud и т.д. Даже у того же Mikrotik есть возможность купить лицензию на виртуальный Mikrotik Cloud Hosted Router. Мне всегда казалось, что сам Амазон/Гугл уже весь необходимый функционал своими собственными решениями покрыли (фаерволы, подсети, NAT, роутинг, vpn и т.д.). Какой тогда в этих виртуалках практический смысл? Для решения каких реальных задач в облаках их нужно покупать/применять?

Comments

[muhazzz]

Может в гибридных окружениях какие-то задачи есть? Ну должно же быть хоть что-то :)

[Wexter]

А если мне неудобно их решение и я хочу CHR?

[muhazzz]

А в чём конкретно "неудобно"? Можно пару реальных примеров?

[ky0]

muhazzz, если у вас сетевик хорошо знает, например, цисочный синтаксис и функциональность - незачем набирать второго, сертифицированного по AWS/GC/etc.

[muhazzz]

ky0, ну так в облаках этот "цисочный сетевик" под капотом облаков же спрятан, и не один :) Мне казалось, что облака и созданы для того, чтобы не будучи "цисочным сетевиком" всё, образно говоря, мышкой накликать и полетели?

[ky0]

muhazzz, в тривиальных случаях можно и веб-интерфейсе накликать. Но при более-менее комплексной сетевой архитектуре у "кликальщика" без вменяемых знаний по сетям и конкретно особенностям облачных начнут возникать проблемы.

[muhazzz]

ky0, никто не спорит, что знания по сетям полезны. Это безусловно. Я не могу понять в чём польза именно виртуального сетевого оборудования. Понимаю, например, как в реальные порты сетевых железяк реальный кабель воткнуть, но абсолютно не могу понять как (и зачем) эта штука в облаке должна жить... что я должен в её виртуальный порт виртуально воткнуть в AWS? :)

Answer 1

[Валентин]

Конечно же решения есть у каждого cloud-провайдера, но:
1) использование сетевого решения от провайдера это vendor-lock, что делать, если он цену вломит неподъемную?
2) Cisco/juniper/Mikrotik имеют богатую историю, практически весь функционал из IEEE/RFC, этого нет и не будет в роутере от непрофильных компаний
3) Cisco/juniper предоставляют платную техническую поддержку такого уровня в части сетевого окружения, до которой остальным пилить и пилить.
4) Алгоритмы лицензирования схожи с железными решениями, что позволяет мигрировать в облака с понятным ценообразованием
5) У Cisco/juniper/Mikrotik есть проприететарные фичи, которые люди используют также на железных маршрутизаторах (та же оркестрация)
6) У профильных производителей сетевых решений уровень документации и поддержки ее в актуальном состоянии на порядок лучше, чем у облачных провайдеров
7) На Цисту/Джун вы сами вольны в выборе версии прошивки, например, вам не нужна самая свежая, лучше стабильная. Или не важна заплатка на баг для неиспользуемого функционала.

Comments

[muhazzz]

Можете подсказать прямо какой-то конкретный пример про "этого нет и не будет в роутере от непрофильных компаний"? Для решения какой задачи мне нужно купить в маркетплейсе, скажем Juniper vSRX или что-то от Cisco?

[Валентин]

muhazzz, mpls, bgp add-path, multipath, evpn, vxvlan...

[muhazzz]

Валентин, прошу прощения, я не сетевик. Для меня этот набор аббревиатур - это всё то, что скрыто от меня под капотом сети самого AWS-а и этим занимаются их инженеры. Можете пояснить, именно выпуклый военно-морской конкретный жизненный пример, для чего мне это может понадобиться? Для какого конкретного улучшения моего, например, высоконагруженного веб-проекта?

[Валентин]

muhazzz,

Для какого конкретного улучшения моего, например, высоконагруженного веб-проекта

Для этих целей не понадобится.

Answer 2

[rionnagel]

Для создания дополнительного периметра это раз. Целей и реализаций может быть масса, не думаю, что тут обязательно приводить кейс.
Для "моногамности" оборудования это два. Предположим у вас колокейнш стоек в разных датацентрах и несколько виртуальных инфраструктур. Вам надо поднять bgp между этим всем и построить звездой связь gre туннелями через ipsec. Ни один вменяемый специалист не сможет гарантировать работоспособность в среде зоопарка, когда можно внезапно ловить ад по mtu, по размерам tcp окна, частыми флапами туннелей и прочего, что может появиться после обновления прошивки того или иного устройства разных вендоров.

Comments

[muhazzz]

Для создания дополнительного периметра это раз.

Что конкретно под периметром подразумеваете? Фаерволы облаков прекрасно работают, что с ними не так?

Насколько знаю, для BGP в том же Google Cloud есть свой Cloud Router. GRE так же самим линуксом "ip tunnel add netname mode gre remote ... local ... ttl ...". ipsec - опенсорсным strongswan?

По поводу зоопарка звучит логично. Но так а сам интернет - разве не зоопарк? Там нет никакой моногамности и живёт же, падлюка :) Если у меня пока нет вообще никакого физического сетевого оборудования и вендорлока, есть ещё хоть какая-то причина или задача, где лучше использовать их виртуалки в облаке?

[rionnagel]

muhazzz, Поверьте, если вам в gcp надо будет ставить виртуальные джуниперы - вы об этом узнаете), либо сами придёте к подобному умозаключению.

Ну есть свой, ну есть strongswan, ну есть бгп, ну и что?) У нас между циской и чек поинтом, дорогими вендорными решениями ад творился в туннелях - приходилось перебирать старые версии, чтобы найте те, которые хотя бы кое-как друг с другом работают. Если у вас везде роутеры на линуксах, strongswan etc. - то используйте это, в чем проблема?.

Периметр это периметр). У вас может быть изолированная инфраструктура (которая отдельно защищается каким-нибудь чек поинтом с включенным инспектором протокола) внутри другой инфраструктуры, которая параллельно с третей инфраструктурой и они все находятся в одном и том же месте пересекаясь частями.

Зоопарк зоопарком. Но нюансов, которых можно было бы избежать - тьма.

Answer 3

[Vitaly Karasik]

Во-первых, если лет 10-20 использовать какой-то appliance, то к нему привыкаешь и хочется его же в облаке. Во-вторых, бывают гибридные окружения. И, наконец, тот же F5 намного сильнее даже AWS ALB, не говоря уже о том что несколько лет назад был только ELB с функциональностью близкой к нулю.

Comments

[muhazzz]

тот же F5 намного сильнее даже AWS ALB

Можно примеры "силы", какие конкретно задачи лучше с его помощью решаются?

[Vitaly Karasik]

muhazzz, честно говоря, не могу - я с ним работал лет пять назад. Но такое у меня осталось впечатление.

[muhazzz]

Во-вторых, бывают гибридные окружения.

А для гибридных окружений какие примеры реальных задач можно придумать?

[Vitaly Karasik]

muhazzz, например, disaster recovery

Answer 4

[Alexey Dmitriev]

Смысла два:
1. Функционал
2. Унификация парка.

Если у вас в On-Premise инфраструктуре стоят например Riverbed девайсы, которые жмут трафик и у вас есть инфраструктура в Azure, то для сжатия трафика между on-prem и Azure нужен будет Riverbed virtual appliance в Azure.

По поводу унификации - уменьшается стоимость обслуживания при наличии однотипного оборудования, пусть даже и виртуального.

Answer 5

[DDwrt100]

Облака это общее название. Они бывают различные SAAS PAAS и тд. Одна из разновидностей облаков , это облако как инфраструктура. Грубо говоря вы покупаете не Microsoft office, а такой виртуальный конструктор, в таком типе облаков вы сами создаете сервера, сами их связываете. Вот когда поднимаете такой сервис, то вам требуется специализрованное оборудование типа фаерволов, балансировщиков. Поэтому вендоры предлагают свою решения в виде виртуализированных образов. Плюс каждый вендор имеет свою идеологию как должно все строиться, свою логику управления. И если вы 20 лет проработали с Cisco , то наверное вам будет эффективнее такое решение использовать в облачном решении.