Affidabilità per server FTP

1

Abbiamo implementato un server Ftp. Il manager vuole aggiungere affidabilità ad esso. Vuole che scriva flussi in entrata in un sistema veloce e affidabile (come hbase o redis) prima di scriverli sull'hard disk del server. Il suo punto è se il server si è arrestato in modo anomalo (ad esempio, mancanza di alimentazione) prima di archiviare il file, ne abbiamo una copia in un sistema affidabile.

Ma credo che questo metodo sia ridondante e inutile perché se vogliamo mantenere il file client, possiamo semplicemente scriverlo su disco al primo posto. Rende anche lento il server ftp (perché ha bisogno di scrivere i dati in due posti diversi).

Quindi ho sbagliato o è così? E se sbaglio, qual è la soluzione migliore da utilizzare come back-end di affidabilità?

    
posta vakarami 03.05.2017 - 11:21
fonte

1 risposta

5

È ridondante e inutile.

Se il server si arresta in modo anomalo durante il trasferimento di un file, nella migliore delle ipotesi si dispone di metà file, che nella maggior parte dei casi non sarà affatto migliore di nessun file. L'unica situazione in cui questa configurazione potrebbe aiutare, è quella in cui si verifica un arresto anomalo tra la ricezione dell'ultimo byte e la sua scrittura su disco. Supponendo che tu stia eseguendo il flusso dei file sul disco durante la loro ricezione (invece di archiviarli in un buffer e scriverli dopo il trasferimento è completato, ma sarebbe stupido, perché comporterebbe facilmente esaurimento della memoria quando vengono caricati più file di grandi dimensioni su allo stesso tempo), stiamo parlando di millisecondi qui (microsecondi con SSD).

È possibile ridurre ulteriormente la finestra temporale facendo archiviare i file server FTP su un disco SAN o NAS tramite rete. La maggior parte di questi sistemi memorizzerà nella cache i filestream in memoria prima di scriverli su disco, il che significa che si comportano in modo simile ai database proposti in memoria.

Questo piano infatti ridurrà l'affidabilità , perché con hbase / redis hai un altro componente nel sistema che può potenzialmente fallire o causare errori.

Ma quello che potresti proporre come compromesso è:

  • La possibilità di archiviare i file ricevuti in più percorsi contemporaneamente per la ridondanza. Gli amministratori possono configurare tutte le sedi che desiderano.
  • Schede per il trattamento di redis / hbase come percorsi di file

In questo modo il tuo gestore potrebbe configurare una configurazione che scrive file sia per redis / hbase che per il filesystem (come inutile dal punto di vista dell'affidabilità), mentre le persone sane potrebbero ottenere due utili altre caratteristiche:

  • Fai replicare automaticamente il tuo server FTP alle ubicazioni esterne, ad esempio una posizione di backup offsite o una rete di distribuzione del contenuto globale
  • Usa il tuo server FTP come middleware per scaricare i file direttamente nel loro database NoSQL preferito senza la deviazione tramite un filesystem "normale". Questo potrebbe essere utile per l'integrazione di un sistema che parla solo FTP con un database NoSQL.
risposta data 03.05.2017 - 12:08
fonte

Leggi altre domande sui tag