Система за управление на конфигурацията на мрежовата филтрация 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