Перед тем как начать
- все, о чем здесь идет речь, в большей мере относится к дата-центрам и офисным сетям
- речь пойдет о проекте 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