Failover per l'applicazione che esegue richieste in uscita

1

Abbiamo creato un'applicazione che ha un elenco di URL intranet fissi e li scorre periodicamente, trasforma i dati, li memorizza in un database.

Abbiamo il requisito che l'applicazione abbia un qualche tipo di meccanismo di failover automatico. Quindi abbiamo ordinato due server in due diversi data center. Ora: non possiamo permettere che le due applicazioni su ciascun host funzionino contemporaneamente, il che raddoppierà il carico sugli URL spidered. Quindi, quando il primario si abbassa, il secondario dovrebbe salire e continuare a spidering. "Scende" significa che non riceviamo più punti dati per un periodo di tempo nel database.

La mia prima idea:

  • Abbiamo a disposizione un cluster etcd, quindi possiamo inserire una chiave che contenga informazioni che siano attive / passive.
  • Le due istanze ascoltano la chiave e sulla modifica della chiave avvia / interrompe l'invio dei dati.
  • Abbiamo messo un semplice script su e. g. un server di compilazione che è onesto presumere che sia disponibile e lo script attiva il failover se non si ricevono i datapoint per X time attivando la chiave.

In teoria ciò risolverebbe il problema, ma in realtà è un grande sforzo da implementare. Al momento l'applicazione è molto stupida e fa solo una cosa: spidering URL. Ora ho bisogno di migliorarlo ascoltando un tasto etcd, fermando / avviando i thread in base a se l'host corrente dovrebbe essere attivo, ...

La mia precedente esperienza lavorativa mi ha permesso di lavorare principalmente con sistemi che gestiscono le richieste in arrivo e si basano su un sistema di bilanciamento del carico di fronte a loro e strutture simili. Non ho mai dovuto creare un meccanismo di failover per un'applicazione che richiede richieste in uscita .

Esiste un semplice meccanismo di failover (più semplice delle cose chiave che ho descritto prima) che sto trascurando, che ha un intervento manuale minimo o nullo? Disponiamo anche di un cluster di bilanciamento del carico, ma non riesco a vedere come ciò possa essere d'aiuto quando le richieste escono invece di venire.

    
posta Max 04.08.2018 - 14:14
fonte

1 risposta

0

Questo è un po 'ovvio .... ma nel mondo dei server di telemetria, questo tipo di primario / backup viene spesso eseguito facendo scambiare i messaggi "heartbeat" ai server.

In questo modo, entrambi i server conoscono lo stato dell'altro in ogni momento e possono intraprendere le azioni appropriate ... come il failover se manca il primario o gli avvisi se il secondario è andato AWAL o l'app si è fermata.

Spesso un server viene designato come primo principale e, quando si ripristina, può forzare un failback a ristabilirsi come primo. Tuttavia, questo potrebbe non essere un problema nella tua applicazione, ma ci possono essere motivi come il backup è una macchina meno ben configurata per risparmiare sui costi.

Nota gli heartbeat possono trovarsi a vari livelli, ad esempio semplicemente ping per vedere se l'altro è vivo e sulla rete o messaggi app-app per garantire che le app o parti specifiche di esse siano in esecuzione.

Ovviamente il routing a livello di ping può essere fatto con script, ma app-to-app potrebbe richiedere qualche riga di codice in più nelle app.

Inoltre, l'app suona come apolidi, si limita a trascinare e memorizzare e a rimescolare lo stesso sito dopo che il failover non ha importanza. Se la tua app ha un sacco di stato, il failover può essere più complicato, poiché dovresti tenerne conto nel failover.

Infine, quanto sopra è adatto (e ben collaudato) in situazioni di standby caldo, che ancora assomiglia a quello che stai cercando.

    
risposta data 06.08.2018 - 04:46
fonte