SDN (часть 2)
Итак. Продолжу и закончу пост про SDN.
В первой части статьи было дано определение SDN и перечислены потребности корпората.
А вот список ограничений:
1. Сложность сегодняшних сетей. Существует куча различных протоколов, каждый из которых решает свою узкоспециализированную задачу. Эти протоколы практически никак не связаны между собой. Любое изменение (например, добавление сетевого элемента или его перенос) в сети связано с необходимостью настройки кучи оборудования, правкой списков контроля доступа, механизмов качества обслуживания, VLAN, и других настроек. В отличие от сетевой инфраструктуры серверная на текущий момент является более мобильной за счёт виртуализации. Миграция гостевых систем в больших дата-центрах может происходить постоянно. Это требует соответствующего изменения в настройках сетевого оборудования. Хотя современные корпоративные сети являются конвергентными (используются для передачи данных, видео и голоса), настройки происходят в ручном режиме.
2. Непоследовательные политики (Inconsistent policies). Вытекает на самом деле из комплексности сетей. Применение политик на большой сети сопровождается огромным трудом по их настройке. Чуть где ошибёшься - брешь в безопасности или возможность деградации сервиса.
3. Проблемы с масштабируемостью. Опять виновата комплексность.
4. Зависимость от производителя. Отсутствие стандартных, открытых интерфейсов вкупе с долгим жизненным циклом продукта негативно сказывается на способности компаний оперативно разворачивать новые сервисы, а также затачивать свои сети под индивидуальные нужды.
Далее документ говорит, что расхождение между тем, что нужно компаниям, и тем, что могут предложить производители, огромно. Отсюда и растут ноги у SDN.
SDN сети на основе OpenFlow должны нести благо человечеству. Будет возможно построение мульти-вендорной сети с централизованным управлением, уменьшится комплексность через автоматизацию. Такой подход позволит увеличить скорость внедрения новых сервисов. Улучшится надёжность и безопасность сетей. Будет более лучший контроль за сетью. Улучшится user experience (никто не подскажет, как литературно это можно перевести?).
В заключении упоминаются тренды: мобильность пользователей, виртуализация, IT-as-a-Service и оперативное реагирование на бизнес-потребности. Всё это предлагается решить с помощью SDN.
Ну а пока идут дискуссии по поводу SDN и OpenFlow, некоторые из игроков рынка сетевого оборудования и программного обеспечения. Уже выпускают свои SDN-продукты. Список таких продуктов можно найти здесь. Пока, правда, железо с поддержкой OpenFlow совсем недешёвое. Это связано с тем, что позиционируется оно как раз в дата-центры. Отсюда и наличие портов 10G, и прочих необходимых атрибутов.
Перед новым годом к нам в гости приходил один вендор. Обещались дать поиграть коммутаторы с реализацией OpenFlow. Надеюсь, что удастся подержать в руках и поиграться с этим оборудованием.
В первой части статьи было дано определение SDN и перечислены потребности корпората.
А вот список ограничений:
1. Сложность сегодняшних сетей. Существует куча различных протоколов, каждый из которых решает свою узкоспециализированную задачу. Эти протоколы практически никак не связаны между собой. Любое изменение (например, добавление сетевого элемента или его перенос) в сети связано с необходимостью настройки кучи оборудования, правкой списков контроля доступа, механизмов качества обслуживания, VLAN, и других настроек. В отличие от сетевой инфраструктуры серверная на текущий момент является более мобильной за счёт виртуализации. Миграция гостевых систем в больших дата-центрах может происходить постоянно. Это требует соответствующего изменения в настройках сетевого оборудования. Хотя современные корпоративные сети являются конвергентными (используются для передачи данных, видео и голоса), настройки происходят в ручном режиме.
2. Непоследовательные политики (Inconsistent policies). Вытекает на самом деле из комплексности сетей. Применение политик на большой сети сопровождается огромным трудом по их настройке. Чуть где ошибёшься - брешь в безопасности или возможность деградации сервиса.
3. Проблемы с масштабируемостью. Опять виновата комплексность.
4. Зависимость от производителя. Отсутствие стандартных, открытых интерфейсов вкупе с долгим жизненным циклом продукта негативно сказывается на способности компаний оперативно разворачивать новые сервисы, а также затачивать свои сети под индивидуальные нужды.
Далее документ говорит, что расхождение между тем, что нужно компаниям, и тем, что могут предложить производители, огромно. Отсюда и растут ноги у SDN.
SDN сети на основе OpenFlow должны нести благо человечеству. Будет возможно построение мульти-вендорной сети с централизованным управлением, уменьшится комплексность через автоматизацию. Такой подход позволит увеличить скорость внедрения новых сервисов. Улучшится надёжность и безопасность сетей. Будет более лучший контроль за сетью. Улучшится user experience (никто не подскажет, как литературно это можно перевести?).
В заключении упоминаются тренды: мобильность пользователей, виртуализация, IT-as-a-Service и оперативное реагирование на бизнес-потребности. Всё это предлагается решить с помощью SDN.
Ну а пока идут дискуссии по поводу SDN и OpenFlow, некоторые из игроков рынка сетевого оборудования и программного обеспечения. Уже выпускают свои SDN-продукты. Список таких продуктов можно найти здесь. Пока, правда, железо с поддержкой OpenFlow совсем недешёвое. Это связано с тем, что позиционируется оно как раз в дата-центры. Отсюда и наличие портов 10G, и прочих необходимых атрибутов.
Перед новым годом к нам в гости приходил один вендор. Обещались дать поиграть коммутаторы с реализацией OpenFlow. Надеюсь, что удастся подержать в руках и поиграться с этим оборудованием.