Abbiamo un cluster GlusterFS che utilizziamo per la nostra funzione di elaborazione. Vogliamo integrare Windows in esso, ma abbiamo qualche problema a capire come evitare il single-point-of-failure che è un server Samba che serve un volume GlusterFS.
Il nostro flusso di file funziona in questo modo:
- I file vengono letti da un nodo di elaborazione Linux.
- I file vengono elaborati.
- I risultati (possono essere piccoli, possono essere piuttosto grandi) vengono riscritti nel volume GlusterFS mentre vengono eseguiti.
- I risultati possono invece essere scritti in un database o includere diversi file di varie dimensioni.
- Il nodo di elaborazione preleva un altro lavoro dalla coda e da GOTO 1.
Gluster è eccezionale poiché offre un volume distribuito e una replica istantanea. La resilienza alle catastrofi è buona! Ci piace.
Tuttavia, poiché Windows non ha un client GlusterFS nativo, abbiamo bisogno di un modo per i nostri nodi di elaborazione basati su Windows di interagire con l'archivio file in modo simile resiliente. La documentazione di GlusterFS afferma che il modo per fornire l'accesso a Windows consiste nell'impostare un server Samba sopra un volume GlusterFS montato. Ciò porterebbe a un flusso di file come questo:
A me sembra un singolo punto di fallimento.
Un'opzione è quella di raggruppare Samba , ma questo sembra essere basato sul codice instabile in questo momento e quindi fuori dai giochi.
Quindi sto cercando un altro metodo.
Alcuni dettagli chiave sui tipi di dati che lanciamo:
- Le dimensioni dei file originali possono variare da pochi KB a decine di GB.
- Le dimensioni dei file elaborati possono variare da pochi KB a un GB o due.
- Alcuni processi, come scavare in un file di archivio come .zip o .tar, possono causare MOLTE ulteriori scritture man mano che i file contenuti vengono importati nell'archivio file.
- Il conteggio dei file può arrivare a 10 milioni.
Questo carico di lavoro non funziona con una configurazione Hadoop "dimensione unità di lavoro statica". Allo stesso modo, abbiamo valutato i negozi di oggetti in stile S3, ma li abbiamo trovati carenti.
La nostra applicazione è scritta in modo personalizzato in Ruby e disponiamo di un ambiente Cygwin sui nodi Windows. Questo può aiutarci.
Un'opzione che sto prendendo in considerazione è un semplice servizio HTTP su un cluster di server su cui è montato il volume GlusterFS. Poiché tutto ciò che stiamo facendo con Gluster sono essenzialmente le operazioni GET / PUT, che sembrano facilmente trasferibili a un metodo di trasferimento file basato su HTTP. Mettili dietro una coppia di loadbalancer e i nodi Windows possono HTTP PUT al contenuto del loro cuoricino blu.
Quello che non so è come verrebbe mantenuta la coerenza di GlusterFS . Il livello proxy HTTP introduce una latenza sufficiente tra quando il nodo di elaborazione segnala che è stato eseguito con la scrittura e quando è effettivamente visibile sul volume GlusterFS, che sono preoccupato per le successive fasi di elaborazione che tentano di raccogliere il file Trovalo. Sono abbastanza sicuro che l'uso direct-io-mode=enabledell'opzione mount aiuterà, ma non sono sicuro che sia abbastanza . Cos'altro dovrei fare per migliorare la coerenza?
O dovrei perseguire completamente un altro metodo?
Come Tom ha sottolineato di seguito, NFS è un'altra opzione. Quindi ho eseguito un test. Poiché i file sopra menzionati hanno nomi forniti dal cliente che dobbiamo conservare e possono essere disponibili in qualsiasi lingua, dobbiamo preservare i nomi dei file. Quindi ho creato una directory con questi file:
Quando lo monto da un sistema Server 2008 R2 con il client NFS installato, ottengo un elenco di directory come questo:
Chiaramente, Unicode non viene conservato. Quindi NFS non funzionerà per me.
ctdbstabile e pronto per l'uso in produzione e la prima frase nel link che hai dato rende la seconda non valida perché se non è mai stata aggiornata. Avevo intenzione di stabilirlo, ma prima di arrivare a questo ho cambiato lavoro in un ambiente quasi privo di finestre.