Comments 7
После прочтения статьи у меня возникли одни лишь вопросы, но с радостью прочту следующую. На сегодняшний день тема очень живая, но сомнительная. Слишком велики риски и затраты на данные платформы. Я до сих пор опасаюсь, что все эти картинки — всего лишь картинки. Большинство информации в сети о NFV выглядит как: тратата снижение капексов и опексов, тратата гибкость.
Если речь пойдет о нагрузке только в сотни или тысячи мегабит, то там большая часть описанного Control Plane и так виртуализируется без особых проблем уже далеко не первый год. Но на реализацию MPLS в виде NFV, лично я, взглянул бы с интересом, т.к. это может решить некоторый ряд встречающихся проблем эксплуатации таких сетей(особенно мультивендорных).
От перечисленных решений многие отказываются на этапе тестирования, кто то, после внедрения, не понимает зачем они им нужны. Так же эти решения не всегда блещут стабильностью работы, примеров из практики хватает.
Буду ждать продолжения, с надеждой что это не маркетинг, спасибо.
Если речь пойдет о нагрузке только в сотни или тысячи мегабит, то там большая часть описанного Control Plane и так виртуализируется без особых проблем уже далеко не первый год. Но на реализацию MPLS в виде NFV, лично я, взглянул бы с интересом, т.к. это может решить некоторый ряд встречающихся проблем эксплуатации таких сетей(особенно мультивендорных).
От перечисленных решений многие отказываются на этапе тестирования, кто то, после внедрения, не понимает зачем они им нужны. Так же эти решения не всегда блещут стабильностью работы, примеров из практики хватает.
Буду ждать продолжения, с надеждой что это не маркетинг, спасибо.
Sptsh, вопросов эта технология оставляет, действительно, очень много. Но на названные Вами — имею что сказать.
Риски и затраты мне видятся не такими уж большими — точка входа для решения на несколько десятков Gbps (а в российских условиях это несколько десятков тысяч broadband-абонентов или сотни тысяч мобильных), лежит где-то в масштабах пары десятков серверов весьма средней конфигурации и пары недорогих 10GE-коммутаторов. Внедряться NFV также может постепенно — например, дополнительная услуга (скажем, родительский контроль и антивирус от какого-нибудь новго, альтернативного поставщика) может быть развёрнута поверх NFV, притом все остальные компоненты остаются legacy.
Что касается MPLS и NFV, то эти технологии пересекаются, как я вижу, в двух плоскостях:
1. MPLS традиционно используется на магистральной сети и сети агрегации с целью изоляции сервисов и упрощения форвардинга. Если NFV-сервис должен иметь продолжение в остальных доменах операторской сети — условно говоря, VRF/PW на границе сети, соответствующий MPLS FEC на сети ядра, PW на сети агрегации, VLAN на сети доступа — что угодно — то оркестратор, которому даётся команда построить сервис, должен внести соответствующие изменения во всех доменах: в ЦОДе (NFVI) и на legacy-сети. Если сервис требует изменений на MPLS-инфраструктуре, то это делает оркестратор, и для NFV-домена всё оказывается абстрактно. NFV ничего может не знать про MPLS и вланы на сети доступа, а сети доступа и агрегации могут ничего не знать про NFV.
2. MPLS может использоваться внутри NFV домена (внутри ЦОД, между хостами) как способ маркировки, как средство сегментации для service-chaining, как альтернатива или дополнение к другим средствам туннелирования/энкапсуляции.
В остальном MPLS и NFV слишком далеки друг от друга и, условно говоря, относятся к разным уровням сетевого взаимодействия. Либо я неправильно понял что вы имели в виду. То, о чём вы пишете, косвенно напоминает тезисы об SDN. Термины SDN и MPLS, действительно, относятся к одному уровню и взаимозаменяемы, но реализуют диаметрально противоположные принципы сигнализации.
Эта статья не является маркетинговой, а вот следующая, видимо, вас расстроит — она, будет в официальном блоге Cisco. Но там, уж извините, будет, как вы и пишете, «тратата снижение капексов и опексов, тратата гибкость». Не иначе.
Риски и затраты мне видятся не такими уж большими — точка входа для решения на несколько десятков Gbps (а в российских условиях это несколько десятков тысяч broadband-абонентов или сотни тысяч мобильных), лежит где-то в масштабах пары десятков серверов весьма средней конфигурации и пары недорогих 10GE-коммутаторов. Внедряться NFV также может постепенно — например, дополнительная услуга (скажем, родительский контроль и антивирус от какого-нибудь новго, альтернативного поставщика) может быть развёрнута поверх NFV, притом все остальные компоненты остаются legacy.
Что касается MPLS и NFV, то эти технологии пересекаются, как я вижу, в двух плоскостях:
1. MPLS традиционно используется на магистральной сети и сети агрегации с целью изоляции сервисов и упрощения форвардинга. Если NFV-сервис должен иметь продолжение в остальных доменах операторской сети — условно говоря, VRF/PW на границе сети, соответствующий MPLS FEC на сети ядра, PW на сети агрегации, VLAN на сети доступа — что угодно — то оркестратор, которому даётся команда построить сервис, должен внести соответствующие изменения во всех доменах: в ЦОДе (NFVI) и на legacy-сети. Если сервис требует изменений на MPLS-инфраструктуре, то это делает оркестратор, и для NFV-домена всё оказывается абстрактно. NFV ничего может не знать про MPLS и вланы на сети доступа, а сети доступа и агрегации могут ничего не знать про NFV.
2. MPLS может использоваться внутри NFV домена (внутри ЦОД, между хостами) как способ маркировки, как средство сегментации для service-chaining, как альтернатива или дополнение к другим средствам туннелирования/энкапсуляции.
В остальном MPLS и NFV слишком далеки друг от друга и, условно говоря, относятся к разным уровням сетевого взаимодействия. Либо я неправильно понял что вы имели в виду. То, о чём вы пишете, косвенно напоминает тезисы об SDN. Термины SDN и MPLS, действительно, относятся к одному уровню и взаимозаменяемы, но реализуют диаметрально противоположные принципы сигнализации.
Эта статья не является маркетинговой, а вот следующая, видимо, вас расстроит — она, будет в официальном блоге Cisco. Но там, уж извините, будет, как вы и пишете, «тратата снижение капексов и опексов, тратата гибкость». Не иначе.
Что вы имеете ввиду под «MPLS в виде NFV»? Предоставить абоненту виртуальный CPE с поддержкой MPLS?
В статье в разделе CE был упомянут MPLS Traffic Engineering и то что он может быть легко виртуализован. Это стало мне не понятным, но заинтересовало.
Мда, нестыковочка. MPLS TE я привёл в качестве примера сложного Control Plane — это самый навороченный функционал, который можно встретить на CE-роутере. Притом скорее нетипичный для CE, а больше типичный для P/PE, такая абсурдная крайность, которая почти не встречается.
— Можно ли предоставить виртуальный CPE (=Business CE) с поддержкой MPLS? — можно, притом даже в нынешних дизайнах Virtualized Multitenant Datacenter это не проблема. Например, на платформе amazon доступен Brocade Vyatta — это лишь один из линейки.
— Возможно ли использовать преимущества MPLS в таком режиме? — Скорее нет, т.к. MPLS сервисы требуют сквозной сигнализации меток. Для MPLS L3 VPN технологически возможны подобные схемы: Inter-AS-VPN, Carrier-supporting-Carrier, которые позволяют несколько вариантов пиринга с провайдером или через провайдера для сохранения сквозной сигнализации меток — но я не слышал о том, чтобы кто-то такой вариант применял в облаке — он всё-таки сложноват для оператора и плохо масштабируем. А для MPLS TE такого сквозного механизма нет вообще. К тому же, Service Chaining NFV предполагает простейшую топологию — линейную, а Multi-Tier Virtual Datacenter облака — тоже самую простейшую иерархию Tier-ов (или зон) — так что нет даже задачи, для решения которой можно было бы применять MPLS TE.
— Если для лабораторных задач, стэйджинга, то вполне возможно пириться виртуальными роутерами и в облачке внутри одного vDC (они должны быть l2-adjacent), также можно входить в этот домен средствами туннелирования снаружи. Возможна даже связь с реальной сетью или другой лабой средствами GRE tunneling, и пиринга по всем протоколам внутри таких туннелей.
— Можно ли предоставить виртуальный CPE (=Business CE) с поддержкой MPLS? — можно, притом даже в нынешних дизайнах Virtualized Multitenant Datacenter это не проблема. Например, на платформе amazon доступен Brocade Vyatta — это лишь один из линейки.
— Возможно ли использовать преимущества MPLS в таком режиме? — Скорее нет, т.к. MPLS сервисы требуют сквозной сигнализации меток. Для MPLS L3 VPN технологически возможны подобные схемы: Inter-AS-VPN, Carrier-supporting-Carrier, которые позволяют несколько вариантов пиринга с провайдером или через провайдера для сохранения сквозной сигнализации меток — но я не слышал о том, чтобы кто-то такой вариант применял в облаке — он всё-таки сложноват для оператора и плохо масштабируем. А для MPLS TE такого сквозного механизма нет вообще. К тому же, Service Chaining NFV предполагает простейшую топологию — линейную, а Multi-Tier Virtual Datacenter облака — тоже самую простейшую иерархию Tier-ов (или зон) — так что нет даже задачи, для решения которой можно было бы применять MPLS TE.
— Если для лабораторных задач, стэйджинга, то вполне возможно пириться виртуальными роутерами и в облачке внутри одного vDC (они должны быть l2-adjacent), также можно входить в этот домен средствами туннелирования снаружи. Возможна даже связь с реальной сетью или другой лабой средствами GRE tunneling, и пиринга по всем протоколам внутри таких туннелей.
Я все смотрю на OPNFV и пытаюсь понять их видение/стратегию…
Пока получается что-то в стиле «мы возьмем сложные и многомодульные проекты: опенстек, одл, онос, опенконтрейл, клаудстек, обвяжем своими скриптами, допишем еще своих модулей, спрячем всю сложность и получим 10 простых и понятных NFV платформ» — вот только судя по текущему уровню развития технологий оно таким станет только лет через 10, тот же опенстек пилят 5 лет уже…
Пока получается что-то в стиле «мы возьмем сложные и многомодульные проекты: опенстек, одл, онос, опенконтрейл, клаудстек, обвяжем своими скриптами, допишем еще своих модулей, спрячем всю сложность и получим 10 простых и понятных NFV платформ» — вот только судя по текущему уровню развития технологий оно таким станет только лет через 10, тот же опенстек пилят 5 лет уже…
Вы затрагиваете очень интересный вопрос, и в целом верно говорите, все апстримные проекты, на которых лежат OPNFV и Openstack, постоянно развиваются. Дилемма — принять их как есть, динамичными или пересоздать в виде чего-то статического и неизменяемого — в таких проектах, заточенных под совместимость и производительность, решается именно первым способом. В качестве медиатора разных интерфейсов используется не «обвязка в виде скриптов», а более продвинутый слой Middleware. Рискну предположить, что в OPNFV всё сращивается через MOM, входящий в опенстэк — rabbitmq, либо что-то ему подобное.
Sign up to leave a comment.
Обработка трафика в облаке. Кому нужна виртуализация сетевых функций (NFV)?