Hoe bouw je een 'Failover' systeem voor als je primaire VPS uitvalt?

Alex de Vries

Quantitatief Analist & Algo-Trading Expert

Een crash van je VPS tijdens een live trade voelt als een messteek in je rug. Je ziet je bot stoppen, de markt bewegen en je risicomanagement uitgeschakeld.

Een failover systeem is je parachute: het neemt de controle over zodra je primaire server het begeeft. Je bouwt dit niet voor de leuk, je bouwt het voor je slaap en je gemoedsrust.

Wat je nodig hebt voor een stabiele failover

Voor je begint, verzamel je de juiste spullen. Je hebt twee VPS servers nodig, bijvoorbeeld bij DigitalOcean of Vultr, met elk minimaal 2 CPU cores en 4 GB RAM.

Je primaire server draait je Python bot, de failover server staat in de standby modus.

Gebruik een broker met een stabiele REST API, zoals Interactive Brokers, Alpaca of Bitvavo, en zorg dat je API keys voor beide servers klaarliggen. Je hebt verder een simpele database nodig, bijvoorbeeld PostgreSQL of Redis, om je positie en state te synchroniseren. Gebruik een message queue zoals Redis Pub/Sub of RabbitMQ voor snelle status updates.

Je backtesting setup is je testground; zorg dat je bot al is getest met historical data van minimaal 1 jaar. Reken op een initiële kostenplaatje van €20-€40 per maand per VPS, plus een paar euro voor de database. Zorg dat je basiskennis van Linux en Python hebt. Je gebruikt cron jobs, systemd services en simpele shell scripts.

Je hebt geen complexe Kubernetes cluster nodig; een lichtgewicht oplossing werkt beter voor trading bots.

Houd je risicomanagement parameter bij de hand: je maximum drawdown, je position size en je stop-loss levels.

Stap 1: Richt beide VPS servers in

1. Kies je cloud provider en maak twee VPS aan. Bij DigitalOcean kies je een Droplet van 2 GB RAM en 1 CPU voor €12/maand. Bij Vultr is een vergelijkbare instance €10/maand. Zet de primaire server in een datacenter dicht bij je broker (bijvoorbeeld Amsterdam voor Bitvavo, New York voor Alpaca).
2. Installeer Ubuntu 22.04 LTS op beide servers. Gebruik SSH om in te loggen. Voer sudo apt update && sudo apt upgrade -y uit. Dit duurt 5-10 minuten. Veelgemaakte fout: vergeten om de firewall te configureren. Zet direct ufw aan: sudo ufw allow OpenSSH en sudo ufw enable.
3. Maak een dedicated user voor je bot. Bijvoorbeeld trader. Voeg toe: sudo adduser trader en geef sudo rechten voor beheer. Log in als deze user en zet je Python omgeving op: sudo apt install python3-venv python3-pip -y. Dit duurt 2-3 minuten.
4. Clone je bot repository op beide servers. Gebruik Git of scp. Zet je bot in /home/trader/bot. Maak een virtual environment: python3 -m venv venv en activeer het met source venv/bin/activate. Installeer dependencies met pip install -r requirements.txt. Test met een simpele hello-world script.
5. Configureer je API keys veilig. Gebruik environment variables of een .env file. Zet de keys voor je broker API op beide servers. Test de connectie met een simpele request, bijvoorbeeld een account balance call. Controleer of je API limieten kent; voor Bitvavo is dat 1000 calls per minuut.
6. Open de benodigde poorten. Voor Redis poort 6379, voor PostgreSQL 5432, voor RabbitMQ 5672. Gebruik ufw: sudo ufw allow 6379. Test de verbinding vanaf de failover server naar de primaire server met nc -zv ip 6379. Dit duurt 5 minuten.

Veelgemaakte fout: keys per ongeluk committen in Git. Gebruik .gitignore en bewaar keys in een password manager. Test je inlogprocedure op beide servers.

Stap 2: Zet state synchronisatie op

Je bot moet weten wat er gebeurt, ook als de primaire server uitvalt.

Gebruik Redis als snelle state store. Installeer Redis op de primaire server: sudo apt install redis-server -y. Zet een wachtwoord via requirepass in redis.conf. Dit duurt 5 minuten.

Op je Python bot sla je elke trade, positie en timestamp op in Redis. Gebruik een key zoals bot:state:positions.

De failover server leest deze key continu uit. Gebruik een simpele polling loop of Redis Pub/Sub.

Test met een scriptje dat elke 5 seconden de state ophaalt. Controleer dat je positie correct wordt weergegeven. Gebruik een aparte database voor historische data en risicomanagement.

PostgreSQL is stabiel en werkt goed met Python via psycopg2. Maak een tabel voor trades met kolommen: timestamp, symbol, quantity, price, side.

Zet een index op timestamp voor snelle queries. Dit duurt 10-15 minuten. Veelgemaakte fout: te lange polling interval.

Kies 2-5 seconden voor live trading. Test onder load: voer 100 trades uit en kijk of je state up-to-date blijft.

Gebruik een simpel dashboard, bijvoorbeeld Streamlit, om je posities te monitoren.

Stap 3: Detecteer uitval en activeer failover

Je failover server moet weten wanneer de primaire server down is. Gebruik een heartbeat systeem.

Op de primaire server schrijf je elke 10 seconden een timestamp naar Redis: bot:heartbeat:primary. De failover server leest deze key en kijkt of de timestamp minder dan 30 seconden geleden is. Maak een simpel Python script op de failover server dat dit checkt.

Gebruik een loop met een sleep van 5 seconden. Als de heartbeat ontbreekt, activeer je de bot op de failover server.

Zorg dat je bot niet beide servers tegelijk laat traden; gebruik een lock in Redis: bot:lock:active.

Zet de lock bij start van de primaire bot, en check deze op de failover. Test deze stap grondig. Zet de primaire VPS handmatig uit via je cloud dashboard en kijk of de failover binnen 30-60 seconden activeert. Meet de tijd met een simpele print in je script.

Veelgemaakte fout: te gevoelige detectie, waardoor je failover te snel start. Pas de threshold aan op basis van je broker latency.

Zorg voor een fallback voor de Redis verbinding. Als de primaire server down is, is Redis ook down. Gebruik een tweede Redis instance op de failover server voor lokale state, en sync periodiek.

Of gebruik een managed Redis service zoals Redis Labs voor €10-€20/maand. Dit voorkomt single point of failure.

Stap 4: Risicomanagement en order routing

Als de failover activeert, moet je risicomanagement intact blijven. Zet je stop-loss en position size parameters in een JSON config file die beide servers lezen.

Bijvoorbeeld: maximum 2% drawdown per trade, maximum 10 open posities. Test deze limieten met je backtesting data. Gebruik de broker API om orders te plaatsen. Voor Alpaca: requests.post('https://paper-api.alpaca.markets/v2/orders').

Voor Bitvavo: POST /v1/orders. Zorg dat je failover server dezelfde API credentials heeft, maar met een aparte API key voor veiligheid.

Test een paper trade op beide servers om order placement te verifiëren.

Implementeer een eenvoudig risico script dat elke nieuwe trade checkt. Bereken de exposure per symbool en de totale portefeuille risico. Als de failover activeert, voer je een extra check uit: heb je open posities van de primaire server? Haal die op uit Redis en sluit ze of houd ze aan, afhankelijk van je strategie.

Veelgemaakte fout: vergeten om paper trading te gebruiken bij testen. Gebruik altijd paper accounts eerst.

Meet de order execution tijd; voor de meeste brokers is dit 200-500 ms. Zorg dat je failover niet te veel extra latency toevoegt.

Stap 5: Monitoring, logging en alerts

Zet logging op met Python logging module. Schrijf elke actie naar een file op beide servers: /home/trader/bot/logs/bot.log.

Gebruik log levels: INFO voor normale messages, ERROR voor failures. Rotatie van logs na 7 dagen voorkomt volle schijven. Monitor je servers met een simpel dashboard. Gebruik Grafana met Prometheus voor CPU, memory en disk usage.

Installeer Prometheus op een derde kleine VPS of op de failover server. Zodra je merkt dat een VPS niet meer voldoet voor je trading bots, duurt dit 15-20 minuten en kost het €5-€10/maand extra.

Krijg alerts via email of Telegram als CPU > 80% of memory > 90%.

Stel een alert in voor failover activatie. Gebruik een simpel script dat een Telegram message stuurt: bot:failover activated at [timestamp]. Test dit door je primaire server uit te zetten.

Veelgemaakte fout: alerts niet testen, waardoor je ze mist. Check je email of Telegram dagelijks.

Voeg een health check endpoint toe aan je bot, bijvoorbeeld met Flask op poort 8080. De failover server pollt deze endpoint elke 10 seconden. Als het antwoord 200 OK is, blijft alles lopen; anders activeert failover. Dit duurt 10 minuten om te bouwen.

Stap 6: Testen, rollen en onderhoud

Test je failover systeem elke week. Zet de primaire betrouwbare VPS voor trading uit, activeer de failover en controleer of trades correct doorlopen.

Gebruik je backtesting data om scenarios te simuleren: een flash crash, een broker outage.

Meet de recovery time; mik op minder dan 1 minuut. Roll je updates uit op de failover server eerst. Als je een nieuwe bot versie hebt, test die op de failover met paper trading.

Dan pas op de primaire server. Dit voorkomt dat een bug je hele setup neerhaalt.

Onderhoud je VPS servers voor algoritmische trading. Update security patches elke maand. Check je disk ruimte; mik op 20% vrije ruimte. Monitor je data kosten; een PostgreSQL database met 1 GB data kost ongeveer €5/maand.

Veelgemaakte fout: vergeten om backups te maken. Zet een dagelijkse backup van je database en bot code.

Plan een maandelijkse failover drill. Zet de primaire server uit en kijk of je live trading doorgaat zonder verlies. Dit bouwt vertrouwen en spot gaten in je setup.

Verificatie-checklist

• Beide VPS servers draaien Ubuntu 22.04 en zijn up-to-date.
• Python omgeving en dependencies geïnstalleerd op beide servers.
• API keys veilig opgeslagen en getest met paper trading.
• Redis draait op primaire server, heartbeat elke 10 seconden.
• Failover server checkt heartbeat elke 5 seconden, activeert binnen 30-60 seconden.
• PostgreSQL database synchroniseert trades en posities.
• Risk management parameters in JSON config, getest met backtesting.
• Logging en monitoring actief, alerts getest via Telegram.
• Health check endpoint draait op poort 8080, failover pollt dit.
• Maandelijkse test uitgevoerd en backup procedure vastgelegd.

Als je deze checklist afvinkt, heb je een robuust failover systeem dat je trading bot beschermt. Je slaapt beter, je risico daalt en je focus blijft op je strategie, niet op server issues.