Servaya

AT A GLANCE

This was an internal software product, designed for large multi-location enterprise customers.

Such organisations needed a secure, easy to manage on-premise email, file service, and Internet security system running at multiple locations and administered from a single console.

Challenges

At the time when Servaya was designed, there were very few enterprise-class products to offer the set of integrated services which every multi-location organisation needed.

The key requirements were

  • single-console administration of any number of servers spread across any number of data centres, offering various services
  • a unified user directory, where a user account is created in the enterprise-wide database, not at a given location or on a specific server. Password resets should be possible for any user using the central management console.
  • All reports should cover all services and resources across all locations, allowing administrators to take an enterprise-wide view or a location-based view.
  • The system needed to work reliably in the presence of unreliable inter-site links. All server-to-server communication, including log aggregation and system reconfiguration commands, needed to be moved using store-and-forward messaging protocols, so that communication would succeed whenever a failed link was restored.
  • Users would not use any proprietary client software. All services must operate using industry standard protocols, so that off-the-shelf client applications for email access, Internet browsing, etc, could work seamlessly with a Servaya-based infrastructure.

Solutions

Servaya was built as a server-side product running on Linux servers and using best-of-breed open source components, e.g. Sendmail for email message transmission, Cyrus IMAP for mailbox services, Squid for controlled Internet access, etc. All management interfaces were browser based.

There was no distributed database system in common existence when Servaya was designed, and certainly nothing in the open source universe — the only well-known distributed database product was Lotus Notes. The core of Servaya was the ability to keep servers in sync using asynchronous communication operating over unreliable WAN links. This batched communication layer was built as a foundation on top of which the user-facing services were built.

One server in a Servaya network offered the “master” service, which means it acted as a master and controlled the other servers. The “master” service includes the user database, server database, and all configuration and log information. Administrators connect to the master to manage the system, view logs, etc. A sub-set of the master functionality was available for location-specific administrators, and full features were available to global administrators.

The entire product operated on Linux servers.

Installable CD images were created, with an installer program, which allowed rapid installation of Servaya on servers. When a server was installed, it was told whether it was the master or a slave. The master server was given full configuration information about the entire network. Slave servers were simply pointed to the master, and pulled their own slave configurations from it automatically.

Servaya administrators got the user management features needed for a large enterprise. One administrator could create hundreds of accounts in bulk by uploading a file, and could move a user’s mailbox from one location to another by one click on one field. In large organisations, where employees are transferred from one city to another, this kind of integrated user management was very necessary.

NOW THAT’S VALUE

In an era when the only two enterprise-wide multi-server email systems were Microsoft Exchange and Lotus Notes, Servaya offered a third alternative, and worked with excellent reliability and scalability on a fully open source stack.Many mid-sized and large organisations which had grown over the years identified at some point that their information and collaboration backbone had not kept pace. They used Servaya and transformed the communication and collaboration scenario within their teams.

The case study above is published purely as a factual example of work done by Remiges Technologies (“Remiges”) for a client, and may contain some views of Remiges. Remiges asserts that the work described above is factually correct. Remiges has no association or relationship with the client other than as vendor and client for the duration of the contract. Nothing here indicates or implies any endorsement, promotion, or support for Remiges by the client or of the work done, nor does it represent the views of the client. Remiges does not represent the client in any capacity.