О чём эта статья?
Это open source проект: PSEFABRIC
PSEFABRIC является сокращением от pseudo fabric и отражает тот факт, что с точки зрения администрирования это во многом выглядит как сетевая фабрика с возможностью управления всей сетью (или ее частью) как единым устройством, но с точки зрения control plane/data plane это все та же обычная сеть, с той архитектурой, которая была до внедрения PSEFABRIC, с сетевыми решениями, которые вы выбрали и которые на ваш взгляд вам нужны. То есть, в общем случае, это не сеть, построенная на высокоскоростных коммутаторах (хотя ваша сеть может и содержать их), что является отличительной особенностью сетевых фабрик, и именно поэтому это PSEUDO fabric.
PSEFABRIC является логической надстройкой над вашей сетевой архитектурой и не требует покупки нового оборудования или программного обеспечения.
Хочется отметить, что еще несколько лет назад реализация этого проекта на качественном уровне была бы гораздо более сложной и трудоемкой задачей. Но создание такого замечательного продукта как ConfD решило важную проблему интерфейса, сведя ее (проблему интерфейса) ко вполне решаемой и несложной задаче YANG программирования.
Общее введение в проблему
Несмотря на всю сложность и многообразие современных компьютерных сетей, с точки зрения приложения основным является только одно – способность передавать данные. И для IP сетей это, грубо говоря, сводится к двум вещам:
- Создание подсетей и возможности подключения к ним
- Обеспечение связности между ними (по нужным портам)
Но с точки зрения настройки сети все выглядит совсем не просто, и собственно все сетевые протоколы, технологии и подходы направлены на решение этих двух задач.
Мы имеем противоречие между простотой формулировки задачи с точки зрения приложения и огромным количеством вариантов и сложностью ее реализации. Это говорит о том, что в общем случае это противоречие скорее всего эффективно разрешить не удастся.
Но хорошей новостью является то, что когда вы уже создали сеть, то, обычно, если ваше архитектурное решение было правильным, то вы имеете вполне ясную и алгоритмируемую последовательность действий для решения обеих задач.
Конечно, для каждой сети эти действия будут разными.
Это наводит на мысль, что для создания продукта, разрешающего это противоречие нужен подход, который:
- Предоставлял бы простой, интуитивно понятный интерфейс для управления всей вашей сетью (или частью ее) как единым целым, позволяющий оперировать сущностями важными для приложения (например, подсетями и доступами между ними) и не заботиться о частных деталях, характерных для конкретно вашего сетевого решения;
- Был бы настолько гибким, что легко подстраивался бы под разные архитектуры, вендоры, виды оборудования.
PSEFABRIC и является этим решением.
Описание PSEFABRIC
По большому счету, нам нужно решить 4 задачи.
- Cоздать и предоставить удобный и простой интерфейс, достаточный для решения нашей задачи.
- В этом интерфейсе должна быть заложена возможность предоставлять информацию о структуре нашей сети, на основании которой мы могли бы принимать решение, на каком оборудовании и какую конфигурацию мы должны создать.
- Нам нужно предусмотреть возможность как-то описывать наш дизайн, логику, которой мы должны следовать при конфигурировании.
- Мы должны уметь в соответствии с информацией, описанной в пп. 2 и 3, создавать правильные конфигурации на правильных устройствах.
1-ая задача с появлением продукта ConfD решается довольно легко и гибко. Для этого используется YANG.
Ключевыми задачами являются задачи со 2-ой по 4-ю, и они являются общими. Не зависимо от реализации, эти задачи, так или иначе, нужно решать. Поэтому в основе PSEFABRIC лежит 3 концепции:
- Структура (Structure)
- Глобальная логика (Global Logic)
- PSEFABRIC Management Data Flow Model (PMDFM)
Интерфейс
Логика заимствована из интерфейса juniper SRX. Она мне показалась самой удобной.
Чтобы отрыть доступ между подсетями мы должны:
- Создать addresses
- Объединить эти addresses в address-sets. В отличие от SRX в данной реализации интерфейса это является обязательным условием. Мы не открываем доступы между списками addresses – только между списками address-sets
- Создать applications
- Создать application-sets. Так же, как и в случае с addresses, мы всегда должны использовать application-sets
- Создать policy
Здесь пример, как могут выглядеть эти команды:
- Создать addresses (пока не обращаем внимание на структуру)
addresses dc1-vlan111 ipv4-prefix 10.101.1.0/24 structure dc DC1 zone none device dc1_sw1 interface e0/0 vlan 111 vrf VRF1
addresses dc1-vlan112 ipv4-prefix 10.101.2.0/24 structure dc DC1 zone none device dc1_sw1 interface e0/0 vlan 112 vrf VRF1
addresses dc2-vlan221 ipv4-prefix 10.202.1.0/24 structure dc DC2 zone none device dc2_sw1 interface e0/1 vlan 221 vrf TRUST- Создать address-sets
address-sets dc1-vlan111-set addresses dc1-vlan111
address-sets dc1-vlan112-set addresses dc1-vlan112
address-sets dc2-vlan221-set addresses dc2-vlan221- Создать applications
applications http-app prot 6 ports destination-port-range lower-port 80 upper-port 80
applications https-app prot 6 ports destination-port-range lower-port 443 upper-port 443
applications icmp-app prot 1- Создать application-sets
application-sets web-app-set applications [ http-app https-app ]
application-sets icmp-app-set applications [ icmp-app ]- Создать доступ
policies test match source-address-sets [ dc1-vlan111-set dc1-vlan112-set ] destination-address-sets dc2-vlan221-set application-sets [ icmp-app-set web-app-set ]ConfD дает нам полное ощущение того, что мы работаем с отдельным сетевым устройством. Например, у нас есть возможность делать «commit» и «rollback».
PSEFABRIC никак не завязана на функциях ConfD и нигде не использует код ConfD. Единственный элемент, который мы настраиваем, — это набор YANG скриптов для создания необходимого нам интерфейса. При выполнении «commit» PSEFABRIC считывает по NETCONF последнюю конфигурацию c ConfD и, сравнивая ее с предыдущей, создает конфигурационные файлы для сетевого оборудования.
Структура
Здесь мы начинаем говорить о том, что делает подход PSEFABRIC таким гибким. Речь пойдет о том, как учесть архитектуру специфичной сети.
Ясно, что мы должны иметь какой-то набор переменных, значения которых точно бы указывали что и на каком оборудовании мы должны конфигурировать. Эти переменные потом будут использоваться совместно с глобальной логикой на Demultiplexer Layer модели PMDFM.
Этот набор переменных задается в YANG файле. В данной реализации мы имеем следующий список:
- data-centers
- equipment
- vrf
- zone
- interface
- vlans
Для конкретной сети, для которой мы используем PSEFABRIC необходимо задать те значения, которые эти параметры могут принимать, например, в нашей тестовой среде это задается командами:
conf t
structure data-centers [ none DC1 DC2 DC3 ]
structure equipment [ none dc1_sw1 dc1_fw1 dc3_r1 dc3_sw1 dc2_fw1 dc2_sw1 ]
structure vrf [ none DMZ TRUST VRF1 VRF2 VRF3 ]
structure zone [ none ]
structure interface [ none e0/0 e0/1 e0/2 e0/3 ]
structure vlans none vlan-number 0
structure vlans Vlan111 vlan-number 111
structure vlans Vlan112 vlan-number 112
structure vlans Vlan121 vlan-number 121
structure vlans Vlan122 vlan-number 122…
Нет никаких вложений или иерархий, хотя, если это покажется полезным, их можно предусмотреть. Теперь каждый раз, создавая подсеть, вы должны привязать структуру к подсети.
Этого и определенной вами глобальной логики должно быть достаточно, чтобы точно знать, что делать с этими сетками, где их прописывать, где открывать доступы между ними, как пробрасывать виланы и т.д. Если этого недостаточно, введите дополнительные параметры в вашу структуру.
Глобальная логика
Структурой мы задали все необходимые параметры, которые позволяют нам однозначно определить, что и как конфигурировать. Но теперь нам нужно описать логику нашей сети.
В данной реализации PSEFABRIC для описания глобальной логики мы используем python dictionary.
Этой логикой мы должны описать все возможные действия. В нашем случае это
- Создание/удаление addressses
- Создание/удаление address-sets
- Создание/удаление applications
- Создание/удаление application-sets
- Создание/удаление policies
Глобальная логика выдает последовательность команд, в зависимости от набора элементов структуры. Эти команды описываются темплейтами.
PSEFABRIC Management Data Flow Model
Это ключевой элемент PSEFABRIC и он является, пожалуй, основным результатом исследования.
Мы можем выделить 7 уровней этой модели
- Configuration Management Engine
- Configuration Analyser
- Demultiplexer
- Configurator
- Configuration Encapsulator
- MOs Configuration Loader
- Control/Data Plans of MOs
Основные принципы PMDFM:
- Существует 2 типа потока данных управления: конфигурационные данные и диагностические. Они идут в противоположных направлениях. Диагностический поток данных в данном примере PSEFABRIC на данный момент не реализован.
- Конфигурационные данные всегда движутся в направлении сверху вниз (от уровня 1 к уровню 7).
- Обмен конфигурационными данным всегда происходит или между соседними уровнями, или внутри одного уровня
Описание уровней и схему можно найти на wiki проекта.
Конфигурирование оборудования
5,6 уровни модели PMDFM являются уровнями автоматизации. Вы можете применять любую автоматизацию, которая вам удобна. Если у вас уже внедрена какая-либо автоматизация, то это хороший задел, и вы можете интегрировать ее в PSEFABRIC.
Уровень 6 это уровень самих скриптов и др. инструментов (ansible, pappet, …).
Уровень 5 предназначен для приведения конфигурационных файлов (которые он получает с уровня 4) к нужному для инструмента, которым вы пользуетесь на уровне 6, формату.
В данном примере PSEFABRIC я использовал python и perl скрипты.
Рекомендуется следующая последовательность действий:
- После выполнения «commit» анализируем созданные конфигурационные файлы для сетевого оборудования
- Если не видим ошибок, то «заливаем» их на QA и проводим необходимые тесты
- Если все хорошо, то «заливаем» их на «боевое» оборудование
- Если процедура отлажена, и мы неоднократно убедились в корректности результатов для определенных действий, то для них можно исключить пп. 1,2 и по «commit» сразу «заливать» конфигурации на оборудование
В конце концов это должно привести к тому, что большая или хотя бы существенная часть операционных процессов может идти без промежуточных проверок.
Пример
Для тестирования подхода был создан лабораторный стенд. Его описание и сам файл с эмуляцией сети можно найти wiki проекта.
Я не старался облегчить задачу, поэтому схема максимально приближена к возможному «боевому» сценарию. Мы имеем несколько датацентров, различные вендоры (Cisco, Juniper), различные виды фаерволов (ASA, SRX, ZBF), различные виды коммутаторов (L2, L3). Так же я постарался создать нетривиальную топологию с различными зонами и VRF.
Как все это работает можно посмотреть в видео, ссылки на которые можно найти на wiki проекта.
Конечно, это должно работать не только при создании сущностей, но также и при удалении и изменении, что было не такой тривиальной задачей, но все же решаемой.
Что вы получите от внедрения PSEFABRIC?
- Это ничего не стоит, кроме времени и усилий.
- Если вы хотите внедрить NaaS, IaaS, PaaS, то внедрение PSEFABRIC существенно поможет в этом.
- PSEFABRIC дает вам простой, единый интерфейс администрирования, как и в случае сетевых фабрик или sdn решений, но при этом сохраняет все сильные стороны традиционных сетей (например, полноценные фаерволы, балансировщики нагрузки).
- Дает преимущества обычной автоматизации (perl/python/etc. scripting, ansible, puppet), но автоматизация при этом является только одним из составных элементов подхода.
- Дает возможность легко внедрить DevOps подход к конфигурированию сети, встроить процедуру изменений для сети в общие процедуры.
- Дает существенные преимущества для recovery процедур, т.к. хранит информацию о сети в универсальном виде. Это должно позволять легко менять оборудование, вендоров и даже архитектуру.
- И это, конечно же, не полный список.
Автор: nihole
