October 29th, 2018

404

system @ HDD

В продолжение топика о том, что мы забыли, что такое "системный магнитный диск". У меня мои плейбуки лабораторные фейлятся на двухминутных таймаутах операций вида "apt-get update && apt-get install influx". Две минуты!

Ещё два-три фейла и экономически целесообразнее будет поставить SSD под почти пустую ОС.
404

secure DPI

Gateway, обнаружив входящий сетевой пакет, по openflow отсылает его на openflow контроллер. Контроллер (не заглядывая в пакет) отправляет его в jenkins в джобу на инспекцию. jeknins динамически создаёт контейнер на одном из слейвов (если надо, слейв динамически создаётся в cloud'е или в автоматическом baremetall провизе), внутри контейнера находится настроенная копия DPI, проводящая анализ пакета. Если этот пакет относится к существующей цепочке, это определяется по конфигурации в etcd. После того, как инспекция проведена, приложение создаёт артефакт с ответом, который архивируется на слейве, обрабатывается второй джобой. Ответ может быть сложным (например, поднять дополнительный datapath), так что джоба может триггерить несколько других джоб по конфигурации сетевого оборудования. После того, как конфиги разлиты, джоба возвращает ответ контроллеру в понятном gateway виде (для упрощения gateway ответ выглядит как список пакетов, которые нужно отправить по заданным портам, так, например, маршрутизация пересчитывает TTL и чексумму и для route задача будет "отправить пакет (с пересчитанным ttl/crc) в порт такой-то"). Благодаря хранению payload'а внутри тела запроса (оно несущественно на фоне обвязки XML/SOAP) gateway получается стейтлес и может отмаршрутизировать пакет другого gateway (например, из-за фейловера), что позволяет обеспечить нулевую потерю пакетов в интервале инспекции пакетов.

В настоящий момент наша команда работает над MVP-прототипом. В версии 2 по пожеланию заказчиков записано снижение latency для обработки пакета. В настоящий момент worst case включает в себя автоматический провиз бареметалл-сервера для слейва с запуском менеджера контейнеров, и составляет примерно 40 минут, плюс около 20 секунд на обработку пакета внутри контейнера, плюс около 20 секунд оверхед jenkins'а на обработку артефактов, плюс 300мс latency openflow контроллера, плюс 20µs на gateway. Клиент требует не более 5 мс, и у меня есть ощущение, что для версии два нам потребуется небольшой рефакторинг пайплайнов дженкинса. Запуск контейнера занимает примерно 500мс, так что возможно, стоит рассмотреть другие методы запуска контейнеризированных процессов для инспекции.