0919ELSEADM Big pictures

The Official X-Itools ELSE 0.9.19 Administrator's HOWTO

Edited by Nicolas HAHN < hahnn@x-itools.com > / < hahnn@erios.org >

---

Top: Documentation for Administrators | Previous: Requirements | Next: Administrator's tasks

---

• The big picture
  • The one and only one
  • We are legion

The big picture

To start, it's important to understand the way the ELSE is running, how all components are integrated together.

In this section, we discuss about two big pictures: one considering a standalone, unique Linux server where everything is installed (suitable for very small or home installations), and the other considering a distributed ELSE environment, over several servers having dedicated roles.

The one and only one

Here, we consider that all components making an ELSE system, are installed on a unique Linux server (meaning Windows for Exchange server is installed on a VM running on the Linux host). For example, this shows the way the ELSE Virtual Machine, made for demonstration purpose, is designed.

Big picture: all in one ELSE integrated environment

It seems complicated? Not really...

Here are explanations with simple steps:

1. Whatever it's a Microsoft Exchange Server or a Postfix Server, the logs they produce are sent to Rsyslog. Via the Rsyslog Windows Agent for Exchange, and to the local Rsyslog daemon for Postfix.
2. If you have Exchange servers, Rsyslog Windows Agent send the logs to the Rsyslog daemon using RELP protocol
3. In addition, it's possible to deploy the GreyLSE Postfix Policy Server: Postfix can make requests on it for operations like SPF checks, whitelisting, greylisting, blacklisting, ...
4. Rsyslog filter the logs and send them in real time to the PostgreSQL database, using parallel connections to handle extremely huge loads
5. The PostgreSQL database performs its processing job on every received log line
6. Then, ELSE users or administrators use the ELSE WUI (Web user Interface) for all operations (log search, control of the GreyLSE Postfix Policy Server daemon, ...)

So, in its simplest expression, the ELSE environment can be described like this if you don't have Exchange servers nor using a Postfix Policy Server like the GreyLSE:

Big picture: the most basic ELSE environment

We are legion

Here, we suppose the ELSE environment is an ISP one. We have several servers, each of them providing a specific functionality or service.

Big picture: a distributed ELSE integrated environment

In this architecture, we can have a lot of Postfix and/or Exchange servers, as Virtual machines for example. There is a dedicated anti-virus/anti-spam server (or several of them). The ELSE system is installed on three servers: the ELSE backend, the ELSE frontend and a dedicated GreyLSE instance. The GreyLSE instance can also be installed in the ELSE backend to maximize database throughput performances.

All logs generated by messaging servers are sent to the ELSE backend via RSyslog RELP. Then the Rsyslog installed on the backend send the logs to the PostgreSQL database using several database connections to maximize throughput.

In this kind of configuration the ELSE backend, that is the heart of the system, is a huge physical server (in term of RAM, CPU cores and I/O), able to process several millions of e-mails every day.

It's highly scalable in the way additional Postfix servers, anti-virus/anti-spam servers (Amavis for instance), GreyLSE servers and Front-end Servers can be added to absorb the load.

Database scalability is accomplished by adding more CPU cores to the backend server, and by insuring there is no issue from the point of view of the I/Os.

---

Top: Documentation for Administrators | Previous: Requirements | Next: Administrator's tasks