m-ashraf
← All work

F01Graduation project · Helwan University · 2025–2026

NetShield-E

Automatic failover for small networks. When the web server dies, a controller confirms the failure, starts a standby and moves the traffic, with nobody touching a keyboard. Measured at 14.0 s on real hardware.

Open the live demo ↗ Ask me about it
NetShield-E touchscreen dashboard: the VM1 web and mail server and the Raspberry Pi 4 backup, probed every 5 seconds

The controller's 7-inch touchscreen dashboard (Phase 2), shown with demo data.

My role
Technical lead: architecture, integration, deployment and validation
Team
5 students · industrial partner Ghaymah Systems · supervised by Prof. Hisham Zarif
Built on
Phase 1: Ubuntu VMs · Phase 2: Raspberry Pi 5 controller, Pi 4 backup
Stack
Python, Paramiko, Flask, Nginx, dnsmasq, systemd, SQLite, Appwrite

  • Failover on real hardware

    14.0 s

    Phase 2 · target under 30 s

  • Availability in testing

    99.97%

    Phase 1 · target 99.9%

  • Fault detection

    6–8 s

    Health checks every 5 s

  • Automatic failback

    ~30 s

    After 15 s of stable health

How it works

  1. DetectThe controller checks every server every 5 seconds: ping, TCP ports and an HTTP health endpoint, plus CPU, memory and latency from a small agent on each node.
  2. ConfirmOne failed check is never enough. A server only counts as failed after a 6-second confirmation window, so a slow reply can't trigger a false failover.
  3. Switch and recoverIt backs up the configuration, starts the standby over SSH and points DNS at it. When the primary has been healthy for 15 seconds, traffic moves back on its own.
NetShield-E on real hardware Clients reach the primary web server, VM1, through dnsmasq DNS. A Raspberry Pi 5 controller probes VM1 and the Raspberry Pi 4 backup. When VM1 fails it starts Nginx on the backup over SSH, and clients are sent there. Every event is logged to SQLite and synced to Appwrite. Clients browsers, via dnsmasq DNS traffic after failover VM1 · primary Nginx web server Pi 4 · backup Nginx, hot standby probes probes ssh: start nginx Pi 5 · controller probe · confirm · act 7-inch touchscreen events Event log SQLite, synced to Appwrite
Phase 2 on real hardware. Dashed lines are health checks; the highlighted line is the failover.

Where the 14 seconds go

Measured end to end on the hardware, from stopping Nginx on VM1 to the Raspberry Pi 4 serving the page. The 6-second window is deliberate: it's the price of never failing over on a hiccup.

VM1 down to Pi 4 serving14.0 s
  • Detect the failure
  • Confirmation window
  • Start the backup over SSH
Show as a table
StepSecondsShare
Detect the failure~6.748%
Confirmation window6.043%
Start the backup over SSH~1.39%
Total, measured14.0100%
The total, the window and the SSH step were measured; detection is what remains.

Engineering highlights

  • A silent crash in the SSH path

    On the Raspberry Pi 5, PyNaCl 1.6 crashed Paramiko with an illegal-instruction error, so failover died without a word. I traced it and pinned PyNaCl 1.5.0 and cryptography 43.0.3.

  • From 31 seconds to 14

    The first hardware runs took about 31 s. Tuning the health-check timeouts cut that in half without shortening the confirmation window.

  • No flapping

    A primary that comes back for a moment can't grab traffic back: failback waits for 15 seconds of stable health.

  • What I'd build next

    A floating virtual IP with VRRP (keepalived) instead of DNS and SSH, and a redundant controller pair so the controller isn't a single point of failure.

Built with AI-assisted tooling; I owned the architecture, integration, deployment and validation, and wrote the technical documentation. Teammates built the other SIPaCS modules: traffic-flood detection and environmental sensing.

Live demo

Break the primary yourself

The same failover logic runs on my server. Stop VM1 and watch the controller recover the site, timed live.

Open the live demo ↗