Case studies/Email centralisation

Public sector · Consolidation & business continuity · Romania

Email Centralisation

Two hundred ageing servers across the country, 23,000 mail clients and more than a hundred business applications — consolidated onto two mirrored data centres without re-engineering a single application.

ClientPublic sector, Romania

RoleSupply, installation & configuration

PlatformVMware vSphere + NSX Federation

SubstrateDell PowerEdge + PowerMax

FootprintTwo mirrored data centres

StatusDelivered

Two mirrored data centres consolidating a distributed public-sector messaging estate

01The challenge

A decade-old estate that could not simply be replaced

The institution’s electronic messaging platform had grown into roughly two hundred servers spread across central and regional sites, running on hardware at least ten years old. Maintenance contracts had lapsed, failures were frequent, and some of those failures were losing data.

Replacing the platform outright was never the cheaper option: more than a hundred business applications sat on the same technology, several of them critical to how the institution runs. The mandate was to consolidate the estate onto new, reliable infrastructure — and to leave the applications untouched.

P1 Ageing hardware, real data loss The servers carrying the estate were at least ten years old, out of maintenance, and failing often enough that incidents were costing data.

P2 Two hundred servers, a handful of admins Around 90% of the estate sat in regional offices. Propagating a single change across that many servers took days.

P3 A hundred applications, not just mail Business applications — document management, declaration transfer, petitions, case files — ran on the same platform and had to keep running throughout.

P4 Nothing could be rebuilt Retiring the platform would have meant re-engineering more than a hundred applications, many of them critical. Consolidation had to preserve them exactly.

The estate before and after consolidation — roughly two hundred regional servers reduced to two mirrored data centres

The estate before and after consolidation, with the scale it had to keep carrying.

02Scale

What sat on the old estate,
and had to keep working.

23,000

Mail clients in scope

11,000

Business application users

~200 → central

Servers consolidated

30M

Documents archived monthly

Beyond mail, the platform carried the institution’s document-management system, declaration transfer to other national bodies, contact and petition handling, appeals, decisions, helpdesk and asset declarations — used by around 11,000 internal staff and, indirectly, by every citizen and business filing through the public portal. Roughly nine servers in ten were regional, and those were the ones being retired.

03What was delivered

One solution, installed twice

Compute, storage, network, virtualisation, software-defined networking and replication were delivered as a single stack — and installed identically in both data centres, so neither site is the poor relation.

Compute Four-node cluster per site

Two identical clusters of current-generation two-socket rack servers, one in each data centre, replacing regional hardware that was a decade past its service life. Redundant boot volumes, out-of-band management on every node, and 25 Gbps interfaces throughout.

Storage Enterprise array, fibre-channel attached

A high-end enterprise storage array at each site, dual-fabric attached over fibre channel with independent front-end port groups, so no single fabric, port or director interrupts access. Capacity is presented to the clusters as two 50 TB datastores per site.

Network Redundant switch pair per site

A pair of data-centre switches at each site forms the interconnection layer between the core network and the servers, configured as a virtual port-channel pair so either switch can fail without dropping a link, with aggregated uplinks from every host.

Virtualisation vSphere 8, high availability and DRS

Both clusters run current-generation vSphere with high availability and dynamic resource scheduling enabled, so virtual machines are distributed evenly across nodes and restarted automatically if a node is lost. Management, live-migration and overlay traffic are separated onto dedicated interfaces.

Software-defined network NSX Federation across both sites

Distributed routing, distributed layer-2 and a distributed firewall are delivered by a federated SDN: a local manager cluster in each data centre, and a single global manager — active at the primary site, standby at the secondary — so all global routing and security policy is configured once and pushed to both sites.

Load balancing & containers Advanced load balancer, container platform

An advanced load-balancer control cluster in each data centre drives service engines inside the software-defined estate, integrated with the local network manager. A container platform runs at the primary site for modernised workloads.

04Architecture

A federated estate across two sites

The diagram shows the reference architecture model — not the actual internal implementation. A single global control plane governs both data centres; each site runs its own local managers, edge cluster, virtualisation cluster, storage and switch pair, and the two are joined by a stretched overlay and by workload replication.

Email-centralisation reference architecture — one global manager with a local manager per site, stretched edge and overlay across two mirrored data centres, with VM replication between sites

Open full-size architecture diagram →

Control planeOne global manager governs both sites; a local manager cluster in each data centre applies the policy and survives the loss of any single node.

EdgeA two-node edge cluster per site connects the software-defined estate to the physical core, running gateway routing and gateway firewalling.

RoutingA stretched gateway spans both sites in active/standby, with the primary site carrying traffic and the secondary taking over if it is lost — chosen deliberately over active/active to keep routing symmetric.

PeeringDynamic routing sessions to the core network at each site, with outbound filtering so the default route is never injected back into the physical network.

WorkloadsA single overlay segment carries the consolidated production estate, presented to both clusters as an ordinary port group.

05Federation

Why federate the network

Two data centres configured independently drift apart. Federating the software-defined network makes one policy plane authoritative for both.

Configure once, apply twiceGlobal routing and security policy is authored on the global manager and distributed to both local managers, removing the drift that comes from configuring two estates by hand.

Local survivabilityEach local manager cluster keeps operating read/write while it holds a quorum, and upgrades run node by node, so management never goes dark during maintenance.

Predictable failoverThe stretched gateway is instantiated at both sites but active at one, and inside each site the edge instances are active/standby — traffic follows one predictable path instead of an asymmetric one.

Segmentation as policyDistributed firewalling is enforced at the virtual-machine level rather than at a perimeter appliance, so east-west traffic is governed by the same policy set as north-south.

06Continuity

Continuity, at three different scales

A disk, a host, a whole site — each failure is absorbed by a different mechanism, and none of them requires the applications to know.

Replication between sitesA replication appliance cluster at each data centre, integrated with the virtualisation management layer, replicates protected virtual machines from the primary site to the secondary and groups them so they recover consistently.

Recovery from the same consoleProtection and recovery operations are driven directly from the virtualisation console through an integrated plugin, so the team works in one place rather than in a separate product.

Node loss is a non-eventCluster high availability restarts affected workloads automatically; dynamic scheduling rebalances the rest.

A mirrored second siteEvery component of the solution was installed identically in both data centres, so the secondary is a working peer rather than a partial copy.

07Outcome

What consolidation actually buys

Availability

Redundancy at every layer — power, fabric, switch, host, array and site — with automatic restart inside a site and replication between sites.

Data protection

Enterprise storage with redundant paths, plus consistent, grouped replication of protected workloads to the second data centre.

Lower running cost

Retiring the regional server estate removes the maintenance contracts, the spare parts and the electricity that went with roughly nine servers in ten.

Less administrative effort

One consolidated estate, one federated policy plane and one set of managed clusters, instead of a change repeated across hundreds of machines.

08Confidentiality note

We do not disclose the client, specific locations, addressing, host naming or the actual internal technology architecture of the project.

The diagram and figures on this page describe the reference architecture model and the publicly communicable scale of the engagement.

09Next step

Consolidating a legacy estate?

We supplied, installed and configured the infrastructure that took a distributed, decade-old platform down to two mirrored data centres — without re-engineering the applications running on it. If you are carrying an estate you cannot simply switch off, we can help.

Connect with us →