¿Cuándo comenzó en su empresa el trabajo de desarrollo del servidor de correo?
El trabajo en el servidor se lleva a cabo desde hace unos 4 años. No llegamos inmediatamente a su escritura. El caso es que antes nuestra empresa se dedicaba a la integración de sistemas basada en soluciones Linux. Naturalmente, en nuestro trabajo nos basábamos principalmente en soluciones de código abierto (Open Source). Llevamos más de 20 años dedicándonos a la integración y, por supuesto, conocemos perfectamente todas las ventajas y desventajas de las soluciones existentes. Algo nos gustaba sin duda, con algo teníamos que luchar.
Por lo tanto, lo primero que hicimos fue un plugin para el servidor de correo Exim. Sin embargo, la comunidad se negó a aceptar nuestro código en el upstream porque no encajaba en la hoja de ruta. Entonces surgió la idea de escribir el servidor nosotros mismos. Al empezar a trabajar, teníamos un objetivo claro ante nosotros, pero no estábamos seguros de poder realizarlo. Por lo tanto, la primera edición del servidor se escribió en Python. De hecho, de ahí viene el nombre del servidor: Python - Pitón, Tegu - lagarto. En general, parientes. Después de trabajar todas las ideas principales en Python, volvimos a escribir todo el servidor en el lenguaje compilable GoLang. Pero ya nos habíamos acostumbrado al nombre de trabajo y lo dejamos como TEGU. Las primeras pruebas de carga y las primeras implementaciones demostraron que las ideas eran correctas. Nos gusta lo que ha salido.
¿Cuánto tiempo se necesitó para tal desarrollo?
El trabajo desde el prototipo hasta hoy ha llevado 4 años. Probablemente se podría haber alargado, pero la pasión estimula, por lo que a menudo trabajábamos por las noches y durante 20 horas al día porque "no te deja ir" :)
¿Qué equipo es adecuado para su servidor y cuál será el más eficaz?
Compilamos el código para dos arquitecturas X86-64 y AArch64 (ARM64) (aquí también entran los procesadores nacionales Baikal). Tenemos el deseo de compilar para Elbrús, todavía no tenemos nuestro propio servidor en Elbrús, pero en el futuro lo tendremos.
¿Su servidor funciona bajo el sistema operativo Linux. ¿Todas las versiones rusas de Linux son compatibles con este servidor y cuál de los Linux rusos es el más óptimo para su servidor?
Una de las características del servidor es que no depende de la base de paquetes del sistema operativo. El servidor es monolítico y no utiliza nada más que la biblioteca del sistema GLIBC. De ahí el único requisito de compatibilidad: la versión de GLIBC no debe ser inferior a 2.28. Por lo tanto, somos compatibles con todos los Linux, incluyendo, por supuesto, todos los nacionales.
¿Cuándo se registró su servidor en el "Registro Unificado de programas rusos para ordenadores electrónicos y bases de datos"?
No teníamos prisa con el registro, entendiendo la responsabilidad de trabajar con clientes gubernamentales. Las primeras implementaciones se llevaron a cabo entre empresas comerciales. Por lo tanto, la primera edición apareció en el registro en marzo de 2021.
¿Para cuántos usuarios está diseñada la versión gratuita (FreeWare) de su producto?
La versión gratuita de TEGU Free no tiene ninguna restricción en ningún parámetro. Más precisamente, no restringimos estos parámetros de ninguna manera, pero está construida según la arquitectura "clásica". Es decir, el código de cálculo y los datos se almacenan en un mismo nodo de cálculo. Al mismo tiempo, los datos se almacenan en el formato Maildir estándar para los servidores de correo. Es precisamente el sistema de archivos de almacenamiento el que impone la restricción. Con un gran número de flujos (y solicitudes al sistema de almacenamiento) surgen conflictos al acceder a los archivos. Si en el momento del acceso el archivo está bloqueado, el resultado del acceso es desconocido. Dado que la transaccionalidad a nivel de archivos no se puede garantizar, con altas cargas esta arquitectura pierde fácilmente la consistencia (se destruye). Este umbral calculado empíricamente se produce aproximadamente con 1000-2000 usuarios. No recomendamos el uso de Maildir con tales cargas. De hecho, es por eso que en TEGU Enterprise hemos abandonado por completo el almacenamiento de archivos en favor de la base de datos Postgres.
¿Su servidor de alta carga ha sido probado para el número máximo de usuarios?
Todas las versiones del servidor se someten a pruebas en un banco de pruebas de carga. Esto es fundamental en el desarrollo de una aplicación de alta carga (ВНС). Debemos estar seguros de que los cambios que hemos realizado no conducen a una pérdida de rendimiento. Por lo tanto, el banco de pruebas de carga siempre está funcionando. Por lo general, en el banco de pruebas emulamos una carga de 400 mil usuarios. Las cifras que obtenemos indican que la carga se puede aumentar aún más, pero para ello se necesita más equipo. En las implementaciones comerciales reales, todo es un poco más modesto. Actualmente, el sistema más grande en TEGU incluye 26 mil usuarios.
Por favor, unas palabras sobre el enfoque CloudNative que utilizan…
CloudNative no es una panacea. Es necesario entender bien qué objetivos queremos lograr. Lo explicaré con un ejemplo. Los servidores clásicos se dividen en MTA (agente de transporte) y MDA (agente de entrega). A menudo, diferentes agentes son escritos por diferentes proveedores. Ejemplo: Postfix y Dovecot (clonados sin piedad por nuestros desarrolladores). ¿Para qué? Nadie sabe la respuesta ahora.
La razón es que el formato de correo que hoy nos resulta familiar no lo era hasta hace muy poco. Había sistemas incompatibles con SMTP de Lotus, Novell, etc. Por eso entonces era necesario instalar varios agentes de transporte y un agente de entrega (almacenamiento). Ahora esto es decididamente un atavismo que estorba. Pero para hacerlo de una nueva manera hay que reescribirlo todo.
Pero dividir el sistema por la línea de código ejecutable y el sistema de almacenamiento, separar el código del propio servidor del cliente web, es una decisión positiva que permite implementar de forma competente la transaccionalidad, la tolerancia a fallos y la redundancia, equilibrar las cargas.
¿Cómo se garantiza la recuperación de datos en caso de fallos?
Es necesario decir que el nodo de cálculo de TEGU no almacena localmente ninguna información. La configuración, las colas temporales, la base de mensajes y demás, todo esto se almacena en la base de datos. Un fallo en el lado del nodo de cálculo no es crítico. No hemos escrito el sistema de almacenamiento en absoluto, como se ha dicho anteriormente, utilizamos una de las mejores bases de datos - Postgres. Por lo tanto, la clusterización, la redundancia, la copia de seguridad y la recuperación se realizan por medio de la base de datos. Por esto, muchas gracias a nuestros colegas. Y en particular a nuestros colegas nacionales de Postgres Pro.
¿Cómo evalúa la seguridad de la información de su servidor de correo?
Que suene inmodesto, pero alta. La práctica ya lo ha demostrado. Pero no hay ningún truco aquí, la razón está en la arquitectura.
- El uso de código monolítico excluye la posibilidad de sustituir el código.
- La no utilización de una arquitectura multinivel reduce en órdenes de magnitud la superficie de ataque.
- La aplicación de un modelo asíncrono de procesamiento de solicitudes no permite influir mediante DDOS.
- Otro factor es el cumplimiento pedante de RFC. Aquellos que empiezan a utilizar TEGU siempre prestan atención a esto. De hecho, es precisamente el requisito más estricto de RFC lo que permite al servidor luchar contra los ataques a nivel de aplicación.
¿Cómo su socio Positive Technology le ayuda a garantizar la protección de Tegu?
Aquí más bien el mérito es del sistema DLP. Nosotros para esto sólo aseguramos la unión, la compatibilidad.
¿Qué le da a su servidor el hecho de que no se utilice una arquitectura multicapa en él?
El hecho de que hayamos escrito todo lo necesario nosotros mismos. Sí, el servidor se gestiona mediante una GUI de interfaz web. Pero no hay que buscar en él componentes de Apache o Nginx. No los hay, lo hemos escrito nosotros mismos. Y así en todo.
Tienen confirmada la compatibilidad de Tegu con «1С:Gestión Documental 8». ¿Tienen previsto seguir trabajando con la empresa «1С» y confirmar la compatibilidad con otros productos de esta empresa?
Sí, se está trabajando en ello. Y nos ayudan los socios del canal de Distribución 1С. Comprueban, implementan, graban vídeos.
Su servidor de correo es compatible con el paquete ofimático R7-OFICINA. ¿Tienen previsto mejorar la compatibilidad con otros paquetes ofimáticos rusos?
Intentamos ser amigos de todos, porque todos se benefician de ello, pero sobre todo nuestros usuarios.
¿Qué hay que hacer para migrar de un servidor de correo antiguo a Tegu?
Aquí hay que distinguir las situaciones. Hay dos opciones:
- Servidor de correo antiguo en el propio equipo y bajo la propia gestión del cliente (bueno, digamos MS Exchange);
- Migración desde un servidor en la nube (MS Office 365, Yandex, etc.).
Pero en el caso de utilizar TEGU, todo es sencillo. Basta con seguir la metodología que proponemos y rellenar sólo cuatro campos en el diálogo de migración. Se realizará sin problemas y sin problemas.
¿Cómo han conseguido ofrecer la posibilidad de atender de forma aislada a usuarios de diferentes organizaciones dentro de una misma instancia del servidor? La explicación es de nuevo la arquitectura elegida. Utilizando un DBMS, dividir los datos a lo largo de cualquier eje es bastante sencillo. Pero compare esto con el almacenamiento de archivos: ahí es realmente complejo y potencialmente inseguro.
Tienen soporte para equipos de servidor de producción nacional. ¿En qué servidores rusos han instalado ya Tegu?