Un roundrobin per i file in arrivo

Una serie di nuovi file con nomi di file univoci "appare" regolarmente ¹ su un server. (Come centinaia di GB di nuovi dati ogni giorno, la soluzione dovrebbe essere scalabile in terabyte. Ogni file ha dimensioni di diversi megabyte, fino a diverse decine di megabyte.)

Esistono diverse macchine che elaborano tali file. (Dieci, la soluzione dovrebbe essere scalabile a centinaia.) Dovrebbe essere possibile aggiungere e rimuovere facilmente nuove macchine.

Esistono server di archiviazione dei file di backup su cui ogni file in arrivo deve essere copiato per l'archiviazione. I dati non devono essere persi, tutti i file in arrivo devono essere consegnati sul server di archiviazione di backup.

Ogni file in arrivo può essere consegnato a un singolo computer per l'elaborazione e deve essere copiato sul server di archiviazione di backup.

Non è necessario che il server ricevente memorizzi i file dopo averli inviati sulla loro strada.

Si prega di consigliare una soluzione affidabile per distribuire i file nel modo sopra descritto. La soluzione non deve essere basata su Java. Sono preferibili soluzioni Unix-way.

I server sono basati su Ubuntu, si trovano nello stesso centro dati. Tutte le altre cose possono essere adattate ai requisiti della soluzione.

¹ Nota che sto omettendo intenzionalmente informazioni sul modo in cui i file vengono trasportati nel filesystem. Il motivo è che al giorno d'oggi i file vengono inviati da terze parti con diversi mezzi legacy (abbastanza stranamente, via SCP e ØMQ). Sembra più facile tagliare l'interfaccia tra cluster a livello di filesystem, ma se una o un'altra soluzione richiederà effettivamente un trasporto specifico, i trasporti legacy possono essere aggiornati a quello.

Ecco una soluzione a ciò che stai cercando. Nessun java è coinvolto nella realizzazione di questo sistema, solo bit Open Source prontamente disponibili. Il modello qui presentato può funzionare con tecnologie diverse da quelle che sto usando come esempio.

1. I file sono POST HTTP inviati a un indirizzo DNS Round-Robin specifico.
2. Il sistema POSTing i file rilascia un lavoro in un sistema AMQP (qui Rabbit MQ), tramite un'altra coppia di bilanciatori del carico, per avviare il flusso di lavoro di elaborazione.
3. I Load Balancer che ricevono il POST HTTP sono ciascuno di fronte a un gruppo di server di archivio oggetti OpenStack Swift.
   • I sistemi di bilanciamento del carico dispongono ciascuno di due o più server di archivio oggetti OpenStack Swift.
   • 'Round Robin non è HA' può essere se gli obiettivi sono HA stessi. YMMV.
   • Per una maggiore durata, gli IP in RRDNS potrebbero essere singoli cluster LB hot-standby.
4. Il server Object Store che ottiene effettivamente il POST consegna il file a un file system basato su Gluster.
   • Il sistema Gluster dovrebbe essere sia distribuito (aka sharded) che replicato. Ciò gli consente di ridimensionare a densità sciocche.
5. Il sistema AMQP invia il primo lavoro, effettua il backup, su un nodo di elaborazione disponibile.
6. Il nodo di elaborazione copia il file dalla memoria principale alla memoria di backup e segnala l'esito positivo / negativo secondo necessità.
   • L'elaborazione della modalità errore non è schematizzata qui. In sostanza, continua a provare fino a quando non funziona. E se non funziona mai, esegui un processo di eccezioni.
7. Una volta completato il backup, AMQP invia il processo di elaborazione a un nodo di elaborazione disponibile.
8. Il nodo di elaborazione estrae il file nel suo file system locale o lo elabora direttamente da Gluster.
9. Il nodo di elaborazione deposita il prodotto di elaborazione ovunque vada e segnala il successo ad AMQP.

Questa configurazione dovrebbe essere in grado di ingerire i file a velocità estreme di velocità dato un numero sufficiente di server. Ottenere 10 GbE di velocità di ingestione aggregata dovrebbe essere fattibile se lo si ingrandisce abbastanza. Naturalmente, l' elaborazione di così tanti dati così velocemente richiederà ancora più server nella tua classe di macchine di elaborazione. Questa configurazione dovrebbe scalare fino a un migliaio di nodi, e probabilmente oltre (anche se quanto lontano dipende da cosa, esattamente, stai facendo con tutto questo).

Le profonde sfide ingegneristiche saranno nel processo di gestione del flusso di lavoro nascosto all'interno del processo AMQP. Questo è tutto software e probabilmente costruito su misura per le esigenze del tuo sistema. Ma dovrebbe essere ben alimentato con i dati!

Dato che hai chiarito che i file arriveranno tramite scp, non vedo alcun motivo per l'esistenza del server front-end, poiché il meccanismo di trasporto è qualcosa che può essere reindirizzato al livello 3.

Metterei un regista LVS (coppia) in primo piano, con un pool di server di elaborazione dietro e una politica di reindirizzamento round-robin. Ciò semplifica l'aggiunta e la sottrazione di server da / verso il pool, aumenta l'affidabilità perché non esiste un server front-end su cui cadere e significa che non dobbiamo affrontare la domanda pull / push su come ottenere i file da il front-end ai server di elaborazione perché non esiste un front-end.

Ogni server di pool dovrebbe quindi fare due cose quando riceve un file: in primo luogo, copiarlo nella memoria di archiviazione, quindi elaborare il file e inviarlo sulla sua strada.