Система за управление на конфигурацията на мрежовата филтрация Qrator

TL;DR: Описание на клиент-серверната архитектура на нашата вътрешна система за управление на конфигурацията на мрежата, QControl. В основата й лежи двустепенен транспортен протокол, работещ с опаковани в gzip съобщения без декомпресия между крайни точки. Разпределените рутери и крайни точки получават актуализации на конфигурацията, а самият протокол позволява инсталирането на локализирани междинни релейки. Системата е изградена по принципа диференциално архивиране ('recent-stable', обяснено по-долу) и използва езика на запитвания JMESpath заедно с шаблонизатора Jinja за рендериране на конфигурационни файлове.

Qrator Labs управлява глобално разпределена мрежа за неутрализиране на атаки. Нашата мрежа работи по принципа на anycast, а подсетите се анонсират посредством BGP. Като BGP anycast мрежа, физически разположена в няколко региона по Земята, можем да обработваме и филтрираме нелегитимен трафик по-близо до ядрото на интернет — Tier-1 операторите.

От друга страна, да бъдеш географски разпределена мрежа не е лесна работа. Комуникацията между сетевите точки на присъствие е критично важна за доставчика на услуги за сигурност, за да има последователна конфигурация на всички възли на мрежата, обновявайки ги навременно. Затова, с цел да предоставим максимално възможно ниво на основната услуга за потребителя, трябваше да намерим начин да синхронизираме надеждно конфигурационните данни между континентите.

В началото беше Словото. То бързо стана комуникационен протокол, нуждаещ се от актуализация.

Крайъгълният камък на съществуването на QControl и основната причина за значителните инвестиции в време и ресурси за изграждането на такъв протокол е необходимостта от единен авторитетен източник на конфигурация, с който в крайна сметка да синхронизираме нашите точки на присъствие. Самото хранилище беше само едно от многото изисквания по време на разработката на QControl. Освен това, нуждаехме се от интеграции с налични и планирани услуги на точките на присъствие (ТП), интелигентни (и настраиваеми) методи за валидация на данни, и ограничаване на достъпа. Искахме също така да управляваме тази система чрез команди, а не чрез модификация на файлове. Преди QControl, данните се изпращаха към точките на присъствие почти ръчно. Ако една от точките на присъствие беше недостъпна и забравехме да я актуализираме по-късно, конфигурацията ставаше несинхронизирана — налагаше се да отделим време за възстановяване на нейната работа.

В резултат на това измислихме следната схема:

Конфигурационният сървър е отговорен за валидация на данни и хранилище, рутерът има няколко ендпойнта, които получават и предават конфигурационни обновления от клиентите и екипа за поддръжка на сървера, а от сървера към точките на присъствие.

Качеството на интернет свързаността все още значително варира в различни части на света — за илюстрация на тази теза, нека погледнем на прост MTR от Прага, Чешка Република до Сингапур и Хонконг.

MTR от Прага до Сингапур

Същото до Хонконг

Високите закъснения означават по-ниска скорост. Освен това, има загуба на пакети. Широчината на каналите не компенсира този проблем, който винаги трябва да бъде взет под внимание при изграждането на децентрализирани системи.

Пълната конфигурация на точката на присъствие е значителен обем данни, който трябва да бъде предаден на много получатели по ненадеждни връзки. За щастие, въпреки че конфигурацията непрекъснато се променя, това става на малки партиди.

Дизайн recent-stable

Може да се каже, че изграждането на разпределена мрежа на принципа на инкрементални обновления е достатъчно очевидно решение. Но дифовете са свързани с многобройни проблеми. Необходимо е да запазим всички дифове между опорните точки и да можем да ги изпращаме отново в случай, че някой пропусне част от данните. Всяка точка на получаване трябва да прилага дифовете в строго зададена последователност. Обикновено, когато има няколко точки на получаване, подобна операция може да отнеме дълго време. Получателят също трябва да има възможност да поиска пропуснатите части и, разбира се, централната част трябва да отговори на подобно запитване коректно, изпращайки само пропуснатите данни.

В крайна сметка стигнахме до доста интересно решение — имаме само един опорен слой, фиксиран, нека го наречем stable, и само един диф за него — recent. Всеки recent е основан на последния създаден stable и е достатъчен за реконструиране на конфигурационните данни. След като новият recent достигне до местоназначението, старият вече не е нужен.

Остава само от време на време да изпращаме свежа stable конфигурация, например, защото recent е станал твърде голям. Също така е важно да отбележим, че разпространяваме всички тези обновления в режим на бродкаст/мултикаст, без да се тревожим за отделните получатели и тяхната способност да съберат парчетата данни. След като се уверим, че всички притежават коректен stable — изпращаме само новите recent. Струва ли си да уточняваме, че това работи? Работи. Stable се кешира на конфигурационния сървър и у получателите, recent се създава при необходимост.

Архитектура на двуслойния транспорт

Защо изградихме нашия транспорт на два слоя? Отговорът е достатъчно прост — искахме да отделим маршрутизацията от високо ниво логика, черпейки вдъхновение от модела OSI с неговия транспортен слой и слой на приложенията. За транспортен протокол избрахме Thrift, а за високо ниво формат на управляващите съобщения — формата на сериализация msgpack. Поради това рутерът (извършващ multicast/broadcast/relay) не разглежда съдържанието на msgpack, не разпакова и не опакова съдържанието обратно и само осъществява преноса на данни.

Thrift (от англ. «бережливость», произносится как [θrift]) — язык описания интерфейсов, использующийся для определения и создания служб для различных языков программирования. Он является фреймворком для удаленного вызова процедур (RPC). Сочетает программный конвейер с движком генерации кода для разработки служб, которые эффективно и просто работают между языками.

Нами был выбран фреймворк Thrift из-за его поддержки RPC и множества языков. Как и ожидалось, наименьшими частями стали клиент и сервер. Однако роутер стал настоящим испытанием, отчасти из-за отсутствия готовых решений в процессе разработки.

Существуют и другие альтернативы, такие как protobuf/gRPC, но в начале нашего проекта gRPC был еще достаточно молодым, и мы не решились его использовать.

Конечно, мы могли (и, на самом деле, так и следовало бы) создать что-то свое. Создать протокол, отвечающий нашим требованиям, было бы проще, так как клиент-серверная архитектура относительно проста в реализации, чем постройка роутера на Thrift. Тем не менее, к самописным протоколам и реализациям популярных библиотек (небезосновательно) существует предвзятое отношение, а также всегда возникает вопрос: «Как мы это будем портировать на другие языки?». Поэтому идеи о создании собственного решения были сразу отвергнуты.

Msgpack — это аналог JSON, но более быстрый и компактный. Это двоичный формат сериализации данных, который позволяет обмениваться данными между множеством языков.

На первом уровне у нас находится Thrift с минимально необходимой информации для роутера, чтобы пересылать сообщения. На втором уровне — упакованные структуры msgpack.

Мы выбрали msgpack, потому что он быстрее и компактнее JSON. Но что еще важнее, он поддерживает пользовательские типы данных, что позволяет нам использовать интересные функции, такие как передача сырых бинарных данных или особых объектов, обозначающих отсутствие данных, что было критически важным для нашей схемы «recent-stable».

JMESPath
JMESPath — это язык запросов к JSON.
Така изглежда описанието, което получаваме от официалната документация на JMESPath, но на практика то предлага много повече. JMESPath позволява търсене и филтриране на поддървета в произволна дървовидна структура, както и прилагане на промени в данните в реално време. Освен това, той позволява добавяне на специални филтри и процедури за трансформация на данни. Въпреки това, определено изисква усилие за разбиране.

Jinja
За някои потребители е необходимо да превърнем конфигурацията в файл — затова използваме шаблонен двигател и Jinja е очевиден избор. С нея генерираме конфигурационен файл от шаблона и данните, получени на точката на назначение.

За да генерираме конфигурационния файл, ни е нужен JMESPath заявка, шаблон за местоположението на файла в файловата система и шаблон за самата конфигурация. Освен това, на този етап е добре да уточним правата за достъп до файла. Всичко това успяхме успешно да комбинираме в един файл — преди началото на конфигурационния шаблон поставяме заглавие в YAML формат, описващо останалото.

Например:

---
селектор: "[@][?@.fft._meta.version == `42`] | items([0].fft_config || `{}`)"
целеви_файл: "fft/{{ match[0] }}.json"
режим_на_файл: 0644
презареди_демони: [fft]
...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}


За да направим конфигурационен файл за нова услуга, добавяме само нов файл шаблон. Не са необходими промени в изходния код или софтуера на точките на присъствие.

Какви промени настъпиха след внедряването на QControl в оперативната дейност? Първото и най-важно — последователна и надеждна доставка на конфигурационни актуализации до всички възли в мрежата. Второто — получаване на мощен инструмент за проверка на конфигурацията и извършване на промени от нашия екип за поддръжка, както и от потребителите на услугата.

Успяхме да постигнем всичко това, използвайки схемата за актуализации recent-stable за опростяване на комуникацията между конфигурационния сървър и получателите на конфигурацията. Използвайки двустепенен протокол за поддържане на независим от съдържанието начин на маршрутизиране на данните. Успешно интегрирайки базирания на Jinja двигател за генериране на конфигурация в разпределената мрежа за филтриране. Тази система поддържа широк набор от методи за конфигуриране за нашата разпределена и разнообразна периферия.

Благодарим ви за помощта при написването на материала VolanDamrod, serenheit, NoN.

Английската версия поста.

Източник: habr.com