Когда началась в вашей компании работа над разработкой почтового сервера?
Работа над сервером ведется около 4-х лет. Мы не сразу пришли к его написанию. Дело в том, что до этого наша компания занималась системной интеграцией на базе решений Linux. Естественно, что в своей работе мы в первую очередь полагались на решения СПО (Open Source). Интеграцией мы занимались более 20-ти лет и разумеется прекрасно себе представляли все плюсы и минусы существующих решений. Что-то безусловно нравилось, с чем-то приходилось бороться.
Поэтому первое, что мы сделали, это плагин для почтового сервера Exim. Однако сообщество отказалось принимать наш код в апстрим т.к. он не укладывался в дорожную карту. Тогда и пришла мысль написать сервер самостоятельно. Начиная работу, мы ясно видели перед собою цель, но не были уверены в том, что сможем ее реализовать. Поэтому первая редакция сервера писалась на Python. Собственно, оттуда и название сервера: Python - Питон, Tegu - ящерица. В общем, родственники. Отработав все основные идеи на Python, мы заново переписали весь сервер уже на компилируемом языке GoLang. Но к рабочему названию уже привыкли и так и оставили TEGU. Первые нагрузочные испытания и первые внедрения показали, что идеи были верны. Нам нравится то, что получилось.
Сколько времени потребовалось на такую разработку?
Cама работа от прототипа до сегодняшнего дня заняла 4 года. Наверно, можно было и растянуть, но увлеченность подстегивает, поэтому часто работали и ночами, и по 20 часов в сутки т.к. "не отпускает" :)
Какое оборудование подойдет для вашего сервера, а какое будет наиболее эффективным?
Мы компилируем код под две архитектуры X86-64 и AArch64 (ARM64) (сюда же попадают отечественные процессоры Байкал). Есть желание скомпилировать под Эльбрус, собственного сервера на Эльбрус у нас пока нет, но в перспективе будет.
Ваш сервер работает под управлением ОС Linux. Все ли российские разработки Linux этот сервер поддерживает и какой из российских Linux-ов наиболее оптимален для вашего сервера?
Одна из особенностей сервера заключается в том, что он не зависит от пакетной базы операционной системы. Сервер монолитный и не использует ничего кроме системной библиотеки GLIBC. Отсюда и единственное требование совместимости - версия GLIBC не ниже 2.28. Таким образом, мы совместимы со всеми Линуксами в том числе, безусловно со всеми отечественными.
Когда ваш сервер был зарегистрирован в “Едином реестре российских программ для электронных вычислительных машин и баз данных”?
Мы не торопились с реестром, понимая ответственность работы с государственными заказчиками. Первые внедрения осуществлялись среди коммерческих компаний. Поэтому первая редакция появилась в реестре в марте 2021 года.
На сколько пользователей рассчитана свободная (FreeWare) версия вашего продукта?
У свободной версии TEGU Free нет никаких ограничений ни по каким параметрам. Точнее, мы никак не ограничиваем эти параметры, но она построена по "классической" архитектуре. Т.е. вычислительный код и данные хранятся на одной вычислительной ноде. При этом данные хранятся в стандартном для почтовых серверов формате Maildir. Именно файловая система хранения и накладывает ограничение. При большом количестве потоков (и запросов к системе хранения) возникают конфликты при обращении к файлам. Если в момент обращения файл заблокирован, то результат обращения неизвестен. Т.к. транзакционность на уровне файлов обеспечить нельзя, то при высоких нагрузках такая архитектура легко теряет консистентность (разрушается). Этот эмпирически вычисленный порог наступает примерно при 1000-2000 пользователей. Мы не рекомендуем использование Maildir при таких нагрузках. Собственно, именно поэтому в TEGU Enterprise мы полностью отказались от файлового хранения в пользу СУБД Postgres.
Ваш высоконагруженный сервер проходил тестирование на максимальное число пользователей? Проверку на нагрузочном стенде проходят все версии сервера. Это принципиально при разработке высоконагруженного приложения (ВНС). Мы должны быть уверены в том, что сделанные нами изменения не приводят к потере производительности. Поэтому нагрузочный стенд работает всегда. Как правило на стенде мы эмулируем нагрузку 400 тысяч пользователей. Цифры, которые мы получаем, свидетельствуют, что нагрузку можно наращивать и далее, но просто для этого нужно больше оборудования. В реальных коммерческих внедрениях, все несколько скромнее. На данный момент самая крупная система на TEGU включает 26 тыс. пользователей.
Пожалуйста, несколько слов об используемом вами подходе CloudNative…
CloudNative же не панацея. Нужно хорошо понимать каких целей мы хотим добиться. Поясню на примере. Классические серверы разрезаются на MTA (транспортный агент) и MDA (агент доставки). Нередко различные агенты пишутся различными вендорами. Пример: Postfix и Dovecot (нещадно клонируемые нашими разработчиками). Зачем? Никто сейчас не знает ответа.
А причина в том, что привычный для нас сегодня формат почты не был таковым еще совсем недавно. Были несовместимые с SMTP системы от Lotus, Novell и т.п. Вот потому тогда и требовалось устанавливать несколько транспортных агентов и один агент доставки (хранения). Сейчас это решительно атавизм, который мешает. Но чтобы сделать по-новому надо переписать все.
А вот разделить систему по линии исполняемого кода и системы хранения, отделить код самого сервера от веб-клиента - это положительное решение, которое позволяет грамотно реализовать транзакционность, отказоустойчивость и резервируемость, сбалансировать нагрузки.
За счет чего обеспечивается восстановление данных в случаях сбоев?
Необходимо сказать, что вычислительная нода TEGU не хранит локально никакую информацию. Конфигурация, временные очереди, база сообщений и прочее, все это хранится в СУБД. Сбой на стороне вычислительной ноды не критичен. Систему хранения мы не писали вовсе, как сказано выше, мы используем одну из лучшей СУБД - Postgres. Поэтому кластерность, резервируемость, резервные копирование и восстановление осуществляются средствами СУБД. За это огромное спасибо нашим коллегами. И в частности наших отечественным коллегами из Postgres Pro.
Как вы оцениваете информационную безопасность вашего почтового сервера?
Пусть прозвучит нескромно, но высоко. Практика это уже доказала. Но фокуса здесь нет, причина в архитектуре.
- Использование монолитного кода исключает возможность замены кода.
- Неиспользование многоуровневой архитектуры на порядки снижает поверхность атаки.
- Применение асинхронной модели обработки запросов не позволяет воздействовать с помощью DDOS.
- Еще один фактор - педантичное следование RFC. Те, кто начинают использовать TEGU всегда обращают внимание на это. Собственно, именно жесточайшее требование RFC позволяет серверу бороться с атаками уровня приложения.
Как ваш партнер Positive Technology помогает вам обеспечивать защиту Tegu?
Тут скорее заслуга DLP-системы. Мы для этого только обеспечиваем стык, совместимость.
Что дает вашему серверу то, что в нем не используется многослойная архитектура?
То, что мы написали все необходимое сами. Да, сервер управляется с помощью GUI веб-интерфейса. Но не надо искать в нем компоненты Apache или Nginx-а. Их там нет, мы написали это сами. И так во всем.
У Вас подтверждена совместимость Tegu с «1С:Документооборот 8». Планируете ли вы продолжить работу с компанией «1С» и подтвердить совместимость с другими продуктами этой компании?
Да, такая работа ведется. А помогают нам партнеры из канала 1С Дистрибуции. Проверяют, внедряют, снимают видеоролики.
Ваш почтовый сервер совместим с офисным пакетом Р7-OФИС. Есть ли в ваших планах доработать совместимость и с другими российскими офисными пакетами?
Мы стараемся дружить со всеми, ведь от этого выиграют все, но в первую очередь наши пользователи.
Что нужно сделать, чтобы мигрировать со старого почтового сервера на Tegu?
Тут следует различать ситуации. Существует два варианта:
- Старый почтовый сервер на собственном оборудовании и под собственным управлением клиента (ну, допустим MS Exchange);
- Миграция с облачного сервера (MS Office 365, Yandex etc).
Но в случае использования TEGU все просто. Необходимо следовать предложенной нами методике и заполнить всего четыре поля в диалоге миграции. Она выполнится плавно и без проблем.
Как вам удалось обеспечить возможность изолированно обслуживать пользователей из разных организаций в рамках одного экземпляра сервера? Тому объяснением опять таки выбранная архитектура. Используя СУБД разрезать данные по любым осям весьма несложно. Но сравните это с файловым хранением - вот там действительно сложно и потенциально небезопасно.
У вас обеспечивается поддержка серверного оборудования отечественного производства. На какие российские серверы вы уже ставили Tegu?
Что такое отечественный сервер - вопрос юридический :) Требования постоянно меняются, поэтому отвечу так - как я уже писал выше, поддерживаются архитектуры x86_64 и AArch64 (ARM64). Нами поддерживаются все процессоры Байкал. Портирование под Эльбрус пока в перспективе.
