Перед тем как начать

• все, о чем здесь идет речь, в большей мере относится к дата-центрам и офисным сетям
• речь пойдет о проекте https://github.com/nihole/PSEFABRIC
• см. так же статью в которой изложены базовые принципы PSEFABRIC.

Идеальная система управления сетью

Осмелюсь утверждать, что с точки зрения управления и автоматизации PSEFABRIC сейчас ближе всех других решений находится к тому, что можно было бы назвать «идеальным менеджером сети».

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

Можно ли этот подход перенести на сети и если да, то какая система управления была бы идеальной для сети?

Чтобы ответить на эти вопросы давайте сначала ответим на вопрос, а кто водитель?

Сети, не являясь “сферическим конем в вакууме”, существуют не ради себя, они существуют для одной единственной цели – передача данных. И пользователями этого сервиса являются приложения. Все, что нужно приложению — это сетки и связность между ними. Точка конфигурирования в идеале должна быть единой для всей сети (а не сотня разных сетевых устройств) и интерфейс должен быть простым и унифицированным.

И… конечно же, это невыполнимая задача, потому что с точки зрения сети все сложно: сотни протоколов, типов оборудования, вендоров, дизайнов, — это океан всевозможных вариантов. Как же создать продукт с простым унифицированными интерфейсом, который учел бы все это разнообразие? Понятно, что задача в таком виде не может быть решена.

И все же, сейчас уже можно сказать, что решение есть и PSEFABRIC показывает это. Задачу, конечно, нужно немного видоизменить, но, к счастью, это изменение не является существенным.

Постановка задачи

Есть две хорошие новости.

Первая заключается в том, что после того, как вы закончили построение вашей сети и ввели ее в эксплуатацию, с этого момента спектр задач, которые вы делаете на сети сильно сужается.
Обычно операционные задачи сводятся к следующему:

• создание/удаление конфигурации, связанной с настройкой L2/L3 протоколов для подключения устройств (сети, виланы, сабинтерфейсы,…).
  Я буду называть это созданием/удалением сетей.
• открытие/закрытие доступов
• создание/удаление виртуальный серверов для балансировки трафика

Это дает нам возможность изменить исходное требование. Мы не собираемся управлять всеми операциями в сети. Мы выделяем несколько взаимосвязанных операций, а именно

• создание доступов
• создание сетей (в смысле, описанном выше)
• создание виртуальных серверов для балансировки
• …

Вторая хорошая новость касается интерфейса.

Продукт Cisco ConfD дает нам все необходимое. С помощью языка YANG мы можем описать (и таким образом создать) фактически любую необходимую логику нашего интерфейса. Также мы будем иметь все, что мы так любим. Вот кое-что из этого:

• сохранение конфигурации
• candidate & running версии конфигурации (возможность commit)
• проверка синтаксиса и логики изменений
• rollbacks
• ААА
• возможность конфигурирования через cli, http, rest, netconf, snmp

PSEFABRIC v.010

Новая версия v.010 PSEFABRIC

• позволяет легко переключаться между контекстами разных проектов
• является легко настраиваемой под большое разнообразие дизайнов, оборудования и требований. Это обеспечивается следующими свойствами PSEFABRIC:
  • проект p000, являющийся темплейтом для других проектов. Рекомендованным подходом при создании нового проекта является копирование файлов данного проекта с последующим их изменением
  • набор инструментов для настройки PSEFABRIC. При этом не требуется изменение кода
  • методология, описывающая последовательность шагов, которые нужно предпринять в процессе внедрения этого решения

Когда год назад была написана эта статья, по большому счету, это был ответ на вопрос «возможно ли это в принципе?».

Приведенный тогда пример (теперь он называется проект p001), являясь интересным с точки зрения набора оборудования (Cisco Routers, L3 Switches, Switches, Cisco ASA, Juniper SRX), является все же несколько искусственным.

Большим плюсом этого проекта (p001) является наличие лаборатории (UNL), где можно “поиграться” с настройками PSEFABRIC и всего вышеперечисленного оборудования, понять принципы работы, основные моменты конфигурации, ознакомиться с инструментами диагностики…

Текущая версия PSEFABRIC (v.010) – это уже полноценный продукт. Вы можете брать и применять его в своей сети или в сети вашего клиента. Для демонстрации гибкости и силы этого решения был создан еще один проект (p002).

Это уже “боевой” дизайн, который вы можете применить у себя или у клиента. Это востребованный и современный подход к построению дата-центра в основе которого лежат давние идеи:

• Вложенная логическая сегментация
  
  • логические устройства (ACI Tenants, Palo-Alto VSYS, N7k VDCs, …)
  • сегметнация с точки зрения маршрутизации (VRFs)
• контроль трафика между логическими сегментами на фаерволах
• MPLS облако для подключение дата-центров

Оборудование: Palo-Alto, Cisco ACI.

В этом получасовом видео мы подробно разбираем example 0. В этом примере, используя PSEFABRIC мы настраиваем доступы между различными сегментами сети проекта p002, cоответственно настраивая ACI и PA оборудование.

Немного о чудесах

Чтобы понять насколько PSEFABRIC меняет представление об управлении сетью приведу несколько примеров.

Давайте начнем с концептуальных вещей.

• Flexability. После ответа на все вопросы в опроснике настройка PSEFABRIC под новый проект занимает от нескольких дней до нескольких недель. Многое зависит от того, насколько быстро вы сможете создать все необходимые темплейты. Но в любом случае, 3 месяца выглядят вполне реалистичным сроком для внедрения (вместе с тестированием) этой системы. Например, настройка PSEFABRIC под проект p002 заняла 1 неделю. Имея опыт создания системы управления доступами для ACI могу сказать, что даже если мы для сложного проекта увеличим это время до 6 месяцев, это все же остается очень и очень хорошим показателем.
• Disaster Recovery. У вас есть фактически «операционная» конфигурация «всей сети» в едином файле. Вы легко можете применить ее к новому оборудованию. Но что интересно, вы даже можете заменить тип оборудования (например, был Juniper SRX, а стал Palo-Alto FW), изменить настройки PSEFABRIC (или создать новый проект с новыми настройками) и применить эту же конфигурацию, но к новому виду оборудования. И это уже действительно похоже на чудо, да?
• Протоколирование доступов. Обычная проблема. Если вы не протоколируете, то очень скоро вы уже не понимаете где и что и какие доступы еще нужны, а какие уже устарели, и вообще вы теряете контроль над вашей сетью. Если же вы протоколируете, то это требует много времени, и вы никогда не уверены, что те доступы, которые запротоколированы действительно соответствуют реальной конфигурации и в конце концов вы перестаете это делать. Здесь же у вас и конфигурация и протоколирование в одном флаконе.
• DevOps. Теперь настройка вашей сети это простой, легко читаемый текстовый файл. Соответственно, вы можете применять best practice разработки к изменениям вашей сети.
• NaaS. Вы задумывались над тем как внедрить решение «Сеть как сервис»? Теперь у вас есть это решение с cli, netconf, REST, HTTP, SNMP интерфейсами.

И несколько технических примеров:

• Пытались ли вы отвечать на вопросы типа “куда/откуда открыты доступы из/в сети такой-то”? Если у вас несколько дата-центров и доступы контролируются на десятке различных устройств, то ответ на этот вопрос может быть довольно непростым. В случае PSEFABRIC это элементарно.
• Некоторые вендоры предлагают удобные с точки зрения администрирования доступов решения, такие как tag в Palo-Alto или TrustSec в Cisco. Суть заключается в том, чтобы, используя tags автоматически предоставлять доступы для сетей. В PSEFABRIC вы можете реализовать это для всей вашей сети, независимо от вендора. Похоже на чудо? По-моему, да.
• Вы хотите открыть доступ с нескольких сетей, в которых расположены административные ресурсы (система мониторинга, системы бэкапа, …) до всех сетевых устройств и линукс серверов. Обычно, это приводит к тому, что вам приходится открывать множество доступов на множестве устройств. Выполнимая, но не очень приятная процедура и конечно же таких примеров может быть много. В случае PSEFABRIC это может быть одна policy и далее PSEFABRIC сама определит где и какие конфигурационные команды должны быть применены.

Часто задаваемый вопрос

А чем же это отличается от обычной оркестрации, например, с помощью Cisco UCSD?
Что нового в этом подходе?

Новое то, что оркестрация обычно не знает о конфигурации сети и если требуется информация, то оркестрация должна делать запросы к реальному оборудованию.
Например, если вы удаляете Contract на ACI, то системе оркестрации приходится просмотреть все EPGs на ACI чтобы найти все providers and consumers для этого контракта. А это могут быть десятки тысяч EPG. И дело не только в производительности (хотя и это тоже), но в том, что это сильно усложняет логику.

Ну и просто посмотрите предыдущую главу и ответьте на вопрос, а имеете ли вы все эти преимущества в случае оркестрации?

Интересно?

PSEFABRIC — это open source с лицензией Apache License, Version 2.0.

https://github.com/nihole/PSEFABRIC
https://github.com/nihole/PSEFABRIC/wiki
https://github.com/nihole/PSEFABRIC/wiki/Installation