Rambler's Top100
Статьи
Нарек Татевосян  02 августа 2018

Практический взгляд на автоматизацию сетей и SDN

Перевод сети современных ЦОДов, ориентированных на предоставление облачных услуг, на принципы Software-Defined Network позволит автоматизировать и ускорить процесс внесения сложных изменений на большой парк оборудования разных производителей.

Центры обработки данных повсеместно переходят к предоставлению услуг по облачной модели. Не важно, используются ли публичные облака, частные или гибридный подход, главная особенность облака – это высокая скорость внесения изменений в услуги, причем автоматически, по «нажатию кнопки» на портале самообслуживания. Такая автоматизация требует кардинального изменения метода управления сетями передачи данных. Если раньше как корпоративные, так и коммерческие ЦОДы могли себе позволить полностью ручное управление сетями и работу по запросу (многие так делают до сих пор), то теперь это с каждым днем становится все менее и менее допустимым.

Основные требования к сетям для облаков

Скорость внесения изменений. Сегодня это одна из наиболее важных метрик для компаний. Современные ИТ-проекты, с одной стороны, очень сложны, а с другой – имеют жесткие временные рамки. Проектные команды просто не в состоянии заранее предусмотреть все требования к инфраструктуре и вынуждены их менять. Если собственная ИТ-служба медленно реагирует на запросы бизнес-пользователей, то последним приходится обращаться к внешним сервис-провайдерам, «теневым» ИТ или прибегать к разным IaaS- и PaaS-сервисам, которые позволяют им самим быстро и легко работать с сетевыми сервисами.

Качество внесения изменений. Ключевые показатели качества – это высокий уровень доступности (внесение изменений без простоя сервисов), конфиденциальности (сохранение необходимого контроля доступа) и управляемости (изменения состоят из понятных «кубиков», которые легче эксплуатировать). Для обеспечения доступности сервисов мало построить сеть правильно (сейчас это требование обычно соблюдается, поскольку строительством сетей занимаются высококвалифицированные специалисты), нужно грамотно ее эксплуатировать. А вот это часто бывает проблемой из-за более низкой квалификации работающего с сетью персонала, а также из-за необходимости быстро вносить изменения на множество устройств. Скорость изменений всегда имеет приоритет перед качеством, так как скорость — это понятная для бизнеса метрика, проблемы же с качеством вскроются только при массовом сбое или внешнем аудите. А сбой на сети – это, как правило, приостановка большого количества сервисов.

Сложность и массовость изменений. Сегодня даже ранее тривиальная операция может потребовать изменений в большом числе единиц оборудования и ПО разных поставщиков. Например, чтобы добавить новый внешний VLAN-канал в обычной сети облака (скажем, для подключения клиентов друг к другу или к MPLS-сети), потребуется настроить его в CE-устройствах, edge-коммутаторах, гипервизорах серверов, облачной платформе. Риск ошибки повышается, каждая ошибка может обернуться сбоем сервиса, поэтому важно грамотно протестировать влияние изменений на работу сервисов.

Мультитенантность. Под мультитенантностью подразумевается возможность разделения системы на разные среды, не мешающие друг другу. Публичным сервис-провайдерам такая возможность нужна для предоставления услуг разным клиентам, службам ИТ – для разных проектов, сред (разработки, тестирования, бизнес-систем), сегментов сети или разных подразделений в компании. Разделять все на физическом уровне слишком затратно с финансовой точки зрения, а производительность и уровень развития сетей уже давно позволяют решать эту задачу на базе стандартных технологий (VLAN, MPLS, EVPN).

Мультивендорность. Большинство серверов в настоящее время построено на базе стандартной архитектуры x86 от Intel или AMD с использованием одних и тех же компонентов. Разница между ними только в цене, качестве сборки и поддержки. Та же ситуация с коммутаторами и маршрутизаторами: по сути, они строятся на одних тех же чипсетах, производимых компаниями Broadcom или Mellanox, а различие в качестве ПО постепенно сходит на нет, поскольку от устройств требуется поддержка стандартных протоколов. Однако решения класса IPS (Intrusion Prevention System), NGFW (Next-Generation Firewall) и WAF (Web Application Firewall) сильно отличаются друг от друга функциональностью, производительностью и защищенностью. С экономической точки зрения сейчас невыгодно «зацикливаться» на одном производителе или альянсе компаний. В одних случаях важнее ценовой фактор (когда функциональность практически идентична), в других требуется выбрать наиболее производительное решение при той же цене или функциональности и т.д. Желательно предварительно протестировать решения, а не слепо доверяться их поставщикам. И службы ИТ должны быть к этому готовы.

Разделение задач между персоналом разной квалификации. С одной стороны, сеть – это критически важная инфраструктура, работа с которой подразумевает наличие персонала высокой квалификации, выделенных временных окон для внесений изменений и тестирование их корректности. С другой стороны, жизнь и бизнес требуют высокой скорости внесения изменений при известных ограничениях рынка труда. Выходом из такой ситуации зачастую становится перекладывание части обязанностей на сотрудников более низкой квалификации с сужением круга выполняемых ими действий для минимизации возможного вреда.

Соответственно, для современных сетей необходимо решение, которое обеспечит персоналу разной квалификации возможность быстро и качественно вносить изменения в мультивендорную сеть, учитывая специфику бизнеса компании. При этом необходимо проверять, что изменения не затрагивают сервисы компании, а если затрагивают, то должна быть предусмотрена процедура отката. Конечно, если позволяют финансы, ничто не мешает задействовать для этих целей большой штат высококвалифицированных сотрудников: есть примеры, когда компании держат целые команды просто для внесения записей в списки контроля доступа. Но, во-первых, высококвалифицированных кадров в России и СНГ для подобных работ недостаточно и, во-вторых, таких специалистов задачи эксплуатации зачастую не привлекают: эксперты, как правило, хотят развития и новых интересных задач. Для сервис-провайдеров эффективность персонала -- это важное конкурентное преимущество, так как от нее зависит себестоимость услуг. Поэтому все больше компаний осознают необходимость автоматизировать управление сетью.

Раньше для такой задачи создавались различные системы управления сетью (Network Management System), но почти все такие проекты провалились, потому что в основном они были «заточены» под одного поставщика, закрыты для расширения (или расширение было очень сложным для сетевиков), часто позволяли только управлять конфигурациями отдельных устройств через единый интерфейс и не содержали в себе какого-либо слоя абстракции для управления сервисами. Ситуация изменилась с появлением концепции Software-Defined Network. Сначала был разработан протокол OpenFlow, но он не получил широкого распространения из-за архитектурных особенностей, которые не вполне соответствовали сложившимся алгоритмам работы сети (см. ниже). Однако базовые принципы концепции дали развитие большому числу решений для программно определяемых сетей, которые решают задачи автоматизации.

Принципы SDN

Базовый принцип SDN – это декомпозиция сети на три плоскости (plane):
  • Management Plane – плоскость управления конфигурацией сети. В случае одного устройства это непосредственно его конфигурирование, в случае SDN – конфигурирование всех составляющих сети (underlay, overlay, сервисы).
  • Control Plane – плоскость оперативной информации о состоянии сети. Для одного устройства это, например, таблица маршрутизации, в сети SDN – таблицы маршрутизации всех устройств на разных уровнях (underlay, overlay, сервисы).
  • Data Plane – плоскость, в которой осуществляется непосредственная передача пакетов с одного порта устройства на другой порт.
При реализации этого принципа на практике важен вопрос выбора архитектуры: централизованная или распределенная. С Management Plane и Data Plane все понятно: управление должно быть централизованным (в этом отчасти смысл SDN), а коммутация пакетов на каждом отдельном устройстве – распределенная функция. В случае Control Plane индустрия пошла разными путям: одни производители выбрали централизованную архитектуру (VMWare, Nuage, Google), а другие пошли по пути реализации распределенной или частично распределенной архитектуры (Cisco, Juniper, Facebook).

Конечно, можно спорить о том, какой путь лучше, но в целом различие подходов обусловлено особенностями бизнеса компаний. Cisco, Juniper и другим сетевым вендорам нет смысла заниматься новой реализацией Control Plane, потому что у них накоплена большая экспертиза по работе с протоколами маршрутизации, MPLS и т.д. Новые игроки на рынке сетевых технологий, такие как VMware, свои решения, которые являются исключительно программными и работают в тесной интеграции с гипервизорами, создавали с нуля, поэтому они пошли по пути развития централизованной архитектуры Control Plane. А Google, реализуя свою концепцию Site Reliability Engineering, выбрала централизацию для более гранулярного управления путями маршрутизации и полосой пропускания, что важно для сетей масштаба этой компании. В итоге получается, что правильный путь -- тот, который больше соответствует накопленной экспертизе компании.

Эволюция сетей в центрах обработки данных при внедрении принципов SDN во многом определялась возможностью растягивания L2-домена на весь ЦОД и предоставления разных сервисов. Это привело к следующей архитектуре сети:
  • Underlay – сеть, обеспечивающая связность между компонентами, на основе которых строится сетевая инфраструктура SDN. Это обычный IP-транспорт. По сути, чтобы реализовать этот уровень, достаточно протокола маршрутизации OSPF (Open Shortest Path First) и поддержки балансировки по маршрутам ECMP (Equal-Cost Multi-Path).
  • Overlay – виртуализированная сеть, которая позволяет предоставлять распределенные сервисы L2. Для реализации этого уровня используются разные механизмы: например, архитектура EVPN (BGP + VXLAN) для аппаратных коммутаторов или технология VMware NSX.
  • Сервисы. Реализация сервисов сильно зависит от выбранного решения для Underlay и Overlay. В облачной сети можно выделить следующие сервисы: маршрутизация для виртуальных машин облака, выход во внешний мир (интернет, MPLS), обеспечение сетевой безопасности (межсетевой экран, WAF, IPS и пр.).

Резюмируем принципы, которых следует придерживаться при построении сети SDN:
  1. SDN – это централизованное управление конфигурацией сети (Management Plane) и распределенная передача пакетов данных (Data Plane).
  2. Архитектура Control Plane должна опираться на специфику бизнеса. С учетом того, что сети строились по принципу распределенной системы, в большинстве случаев подойдет распределенный вариант.
  3. Специфика бизнеса и стек уже используемых в компании технологий также влияют на целесообразность развертывания собственного SDN-решения на каждом уровне эталонной архитектуры. Например, если уже закуплен парк оборудования Arista или Juniper и используется архитектура BGP EVPN, то есть смысл автоматизировать сети Underlay и Overlay. А если сервис-провайдер работает полностью по программе VMware vCAN, то целесообразно задуматься об автоматизации сети Underlay и сервисов, задействовав в сети Overlay технологию NSX и сделав упор на интеграцию своего решения с NSX.
  4. Стек технологий, на котором будет разрабатываться решение автоматизации, должен быть написан на языке программирования, доступном широкому кругу лиц. Сегодня можно смело говорить, что наиболее приемлемым языком для автоматизации сетей является Python ввиду быстроты освоения, наличия большого числа библиотек и решений и отсутствия требований к высокой производительности для системы автоматизации.

От теории -- к практике

Примером применения подхода SDN для автоматизации сети может служить проект, осуществленный нашей компанией для одного из сервис-провайдеров СНГ. Провайдер намеревался на базе решения VMWare предоставлять услуги IaaS, а также сервисы безопасности, такие как NGFW, WAF и Anti-DDoS. В проекте было задействовано 80 единиц коммутаторов и маршрутизаторов. Важно было обеспечить быстроту выхода на рынок и высокое качество реализации, поскольку первые и одновременно ключевые заказчики провайдера внедряли систему SAP HANA. Команда инженеров, выполняющих проект, состояла всего из трех человек.

Мы пошли по следующему пути. Сеть Overlay и базовые сетевые сервисы IaaS были реализованы полностью на стеке VMware NSX с использованием vCloud Director. Помочь обосновать такое решение нам помогло то, что заказчик подпадал под операторскую программу vCAN, условия которой были экономически привлекательны. Если бы заказчик создавал себе частное облако или внедрял исключительно услугу NFV, то, скорее всего, следовало бы выбрать другое решение.

Для провайдера была реализована единая платформа управления Underlay-сетью облака, сетью управления облака и сетью предоставления внешних услуг (edge-сеть), построенной на базе оборудования Juniper (рис. 1). В первую очередь мы решили добиться единого управления конфигурацией сети, которое позволило бы нам быстро и качественно внедрить систему, и уже на этой базе наладить эксплуатацию сети, развернув управление сервисами заказчика. Первыми пользователями сети стали сетевые инженеры, которые благодаря проекту смогли повысить свою эффективность в деле управления сетью. Этап передачи централизованного управления сетью инженерам поддержки мы решили отложить до следующего проекта, когда конфигурация сети полностью стабилизируется.

Рис. 1. Архитектура сети, реализованной для одного из сервис-провайдеров СНГ

Слой Underlay был создан в кратчайшие сроки. При проектировании сети leaf-spine были сделаны некоторые допущения о возможностях leaf-коммутаторов, которые оказались ошибочными, из-за чего пришлось на ходу перепроектировать и внедрять новую конфигурацию. Но благодаря выбранному решению для этого было достаточно внести незначительные изменения в базу шаблонов.

Автоматизация сети позволила обеспечить выполнение основных задач администратора сети -- настройку системных сервисов (аутентификацию, авторизацию, мониторинг, системное время, логирование), портов и протоколов маршрутизации -- в соответствии с едиными шаблонами, построенными на базе лучших практик. 

Рис. 2. Процесс обновления конфигурации

Процесс обновления конфигурации (рис. 2) стал масштабируемым и безопасным. Упрощенно этот процесс можно представить следующим образом:
  1. Создание конфигурации. На базе описания сети и комбинации шаблонов собирается полная конфигурация устройства.
  2. Тестирование конфигурации. Созданная конфигурация сравнивается с текущей. Это позволяет «выловить» ошибки синтаксиса конфигурации и увидеть различия между текущей конфигурацией и созданной. Анализ различий также дает возможность выявить и исправить ошибки.
  3. Применение конфигурации. Текущая конфигурация сохраняется, новая конфигурация устанавливается на устройства.
  4. Откат конфигурации. В случае неуспеха (появились проблемы в сети, не удалось достичь желаемого результата) делается откат и ищется причина.
Реализованное решение позволило с легкостью управлять конфигурационными файлами большого числа устройств, а исправления в конфигурации, скажем, из-за ошибок ПО коммутаторов, вносились очень быстро. Например, мы обнаружили серьезную проблему, которая не позволила нам сформировать кластер leaf-коммутаторов, и для объединения коммутаторов нам пришлось задействовать стандартную технологию MC-LAG (Multi-Chassis Link Aggregation Group). Потребовалось изменить шаблоны конфигурации.

В результате осуществления проекта заказчик начал предоставлять своим клиентам полностью самоуправляемую услугу IaaS, в которую входит возможность управлять сетевыми сервисами балансировщика нагрузки, выхода в интернет, IPsec, межсетевого экрана L4.

Получить представление о системе можно, обратившись к репозиторию https://github.com/nar3k/vagrant-net-lab , который мы использовали, проверяя правильность первоначальной концепции, а затем расширили для работы с реальным проектом.

Нарек Татевосян, руководитель отдела тестирования и анализа средств защиты, BI.ZONE
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!