Обзор архитектуры Printum: как читать схему

Зачем инженеру уметь читать архитектурную схему 
 Инженеру необходимо научиться читать архитектурную схему так, чтобы видеть потоки данных: как задание, атрибуты или событие проходят через компоненты системы. 
 Понимание потока данных,позволяет: 
 
 диагностировать проблему в проекте любой сложности, а не только в тех конфигурациях, которые инженер уже видел; 
 понимать, зачем нужен каждый компонент и что случится, если он откажет; 
 объяснять заказчику и коллегам, почему архитектура устроена именно так, а не иначе. 
 
 Схема Printum описывает не одну конфигурацию, а семейство из четырёх архитектурных блоков, которые комбинируются между собой в зависимости от масштаба и требований инфраструктуры заказчика. Разбор каждого блока — отдельная статья цикла: 
 
 Обзор архитектуры и легенда схемы (эта статья). 
 Система мониторинга. 
 ПринтМенеджер в базовой конфигурации: Сингл. 
 Отказоустойчивость и горизонтальное масштабирование. 
 Филиальная сеть. 
 
 Архитектурная схема Printum 
 Перед дальнейшим чтением откройте архитектурную схему Printum. В этой статье мы будем ссылаться на её элементы и условные обозначения. 
 ➡ Скачать архитектурную схему Printum 
 Если абстрагироваться от внутреннего устройства, Printum — комплексное решение из двух веб-приложений и набора вспомогательных программ и сервисов: 
 
 Система мониторинга принтеров и МФУ — ядро системы. Собирает и агрегирует данные из LDAP-каталогов (доменов), от сетевых принтеров и МФУ, с локальных устройств (подключенных по USB) и от ПринтМенеджеров. 
 Система управления печатью (ПринтМенеджер) — обрабатывает задания печати, копирования и сканирования, управляет правилами и авторизацией пользователей на МФУ. 
 
 Функциональные и нефункциональные требования 
 Прежде чем разбирать компоненты, полезно разделить требования к системе на два типа — это объясняет, зачем часть архитектуры существует. 
 Функциональные требования — что система должна делать: печать (прямая и отложенная, с клиентом ПринтМенеджера и без), копирование, сканирование (в почту, в сетевую папку), авторизация пользователя на устройстве, сбор данных о состоянии парка устройств, управление пользователями и правилами. 
 Нефункциональные требования — какими свойствами система должна обладать при выполнении этих функций: отказоустойчивость (продолжать работать при потере части инфраструктуры), масштабируемость (выдерживать рост числа устройств, пользователей, заданий), производительность, безопасность (не хранить данные в открытом виде, разграничивать доступ и т.п.). 
 Часть компонентов на схеме существует не ради функций, а ради нефункциональных требований — например, разделение на PostgreSQL и ClickHouse существует ради производительности, а балансировщик HAProxy и Redis Sentinel — ради отказоустойчивости и масштабируемости. Если непонятно, зачем нужен компонент, полезно задать вопрос: он выполняет функцию или обеспечивает нефункциональное требование? 
 Легенда схемы 
 Архитектурная схема Printum использует ограниченный набор условных обозначений. Разобравшись с ними один раз, любой блок схемы читается одинаково. 
 
 
 
 Обозначение 
 Значение 
 
 
 
 
 Зелёный цилиндр 
 База данных. Под каждым цилиндром подписан конкретный движок: PostgreSQL, ClickHouse, Redis. 
 
 
 Синий прямоугольник 
 Python-приложение — бэкенд одной из систем (Django, Celery, планировщик). 
 
 
 Синий прямоугольник со скруглёнными краями 
 Обратный прокси / веб-сервер (nginx) или балансировщик (HAProxy). Устанавливает соединения между компонентами, браузером и личным кабинетом. 
 
 
 Пунктирный прямоугольник — архитектурный блок 
 Какие компоненты необходимы для выполнения определённой функции. Отвечает на вопрос «из чего это состоит». 
 
 
 Пунктирный прямоугольник — логический блок 
 Где компоненты физически размещаются в инфраструктуре (на каком сервере, в каком сегменте сети). Отвечает на вопрос «где это стоит». 
 
 
 Прочие значки 
 МФУ, АРМ пользователя, внешние системы (домен, SMTP/IMAP, SIEM) — обозначаются отдельными иконками и подписываются явно. 
 
 
 
 Различие между архитектурным и логическим блоком важно: один и тот же архитектурный блок (например, «ПринтМенеджер») может быть развёрнут в нескольких логических местах — в филиале А, в филиале Б, — и в каждом из них будет одинаковый набор внутренних компонентов. 
 Четыре архитектурных блока верхнего уровня 
 Полная схема Printum состоит из четырёх архитектурных блоков. На практике в конкретном проекте одновременно присутствует блок мониторинга (всегда один) и один или несколько блоков управления печатью — в зависимости от масштаба и требований к отказоустойчивости. 
 
 Система мониторинга — единственный экземпляр в инфраструктуре независимо от количества филиалов или ПринтМенеджеров. Подробности — в статье 2. 
 ПринтМенеджер в базовой конфигурация (Сингл) — типовая установка: один сервер обрабатывает печать/сканирование/копирование для одного офиса или сегмента сети. Подробности — в статье 3. 
 ПринтМенеджер с горизонтальным масштабированием (Кластер) — несколько ПринтМенеджеров работают как единый кластер через балансировщик HAProxy. Применяется, когда одного сервера не хватает по нагрузке или когда заказчику нужна отказоустойчивость обработки заданий. Подробности — в статье 4. 
 Филиальная сеть — несколько независимых ПринтМенеджеров в разных географических точках, каждый обслуживает свой филиал и синхронизируется с общим сервером мониторинга. Применяется при значительных сетевых задержках между офисами или в тех случаях, когда простой сервиса печати при обрыве связи с центральным сервером критичен. Подробности — в статье 5. 
 
 Блоки 3 и 4 не взаимоисключающие: в одном из филиалов филиальной сети вполне может быть развёрнута схема с балансировкой, если нагрузка именно этого филиала того требует. 
 Поток данных на верхнем уровне: мысленная модель 
 Прежде чем переходить к деталям каждого компонента, полезно держать в голове базовый маршрут задания печати — вне зависимости от конкретной конфигурации он всегда проходит одну и ту же последовательность звеньев: 
 АРМ пользователя → драйвер виртуального принтера → ПринтМенеджер (обработка атрибутов и образа) → МФУ (авторизация и печать) 
 Статистика по обработанным заданиям после этого возвращается из ПринтМенеджера в систему мониторинга (по расписанию или мгновенно). Данные же о состоянии самих устройств идут отдельным маршрутом — от МФУ через сетевой агент напрямую в мониторинг, минуя ПринтМенеджер. 
 Это два разных потока: поток заданий (через ПринтМенеджер) и поток данных о состоянии устройств (через агентов мониторинга). Их не стоит путать при диагностике — если не печатает конкретное задание, проблема всегда в первом потоке; если в личном кабинете не видно актуального состояния принтера (уровень тонера, статус ошибки), проблема — во втором. 
 Как это связано с диагностикой 
 Способность назвать компонент по картинке — не цель. Цель — при жалобе «не работает печать» уметь мысленно провести задание по цепочке АРМ → драйвер → ПринтМенеджер → МФУ и определить, на каком звене данные потерялись. Подробно эта методика разобрана в отдельной статье Модель диагностики — она построена именно на знании этой цепочки, которое даёт архитектура.