Ho risposto a questa stessa domanda su Stack Overflow .
s3fs è davvero una soluzione ragionevole e, nel mio caso, l'ho abbinato a proftpd con risultati eccellenti, nonostante i problemi teorici / potenziali.
Al momento in cui ho scritto la risposta, l'avevo impostato solo per uno dei miei clienti di consulenza ... ma da allora ho anche iniziato a bere il mio kool-aid e lo sto usando nella produzione per il mio lavoro quotidiano. Le aziende che scambiamo dati con upload e download di file tutto il giorno sul mio server sftp, che memorizza tutto direttamente su S3. Come bonus, il mio sistema di esportazione dei report - che scrive fogli di calcolo Excel su S3 - può esportare i report "sul server FTP" semplicemente inserendoli direttamente nel bucket del server ftp, con metadati appropriati per mostrare uid, gid e modalità di ciascun file. (s3fs usa le intestazioni x-amz-meta-uid, -gid e -mode per emulare le autorizzazioni del filesystem). Quando il client accede al server, i file di report sono solo lì.
Penso che la soluzione ideale sarebbe probabilmente un servizio gateway SFTP per S3, ma non sono ancora riuscito a progettarne uno, dal momento che questa soluzione funziona davvero bene ... con alcuni avvertimenti, ovviamente:
Non tutti i valori predefiniti per s3fs sono sani. Probabilmente vorrai specificare queste opzioni:
-o enable_noobj_cache # s3fs has a huge performance hit for large directories without this enabled
-o stat_cache_expire=30 # the ideal time will vary according to your usage
-o enable_content_md5 # it's beyond me why this safety check is disabled by default
Probabilmente è meglio usare una regione diversa da quella degli Stati Uniti, perché è l'unica regione che non offre coerenza di lettura dopo scrittura su nuovi oggetti. (Oppure, se è necessario utilizzare lo standard USA, è possibile utilizzare il nome host quasi non documentato your-bucket.s3-external-1.amazonaws.comdella regione us-east-1 per impedire che le richieste vengano geo-indirizzate, il che può migliorare la coerenza.)
Ho abilitato il versioning degli oggetti sul bucket, di cui s3fs non è completamente a conoscenza. Il vantaggio di ciò è che anche se un file dovesse essere "calpestato", posso sempre passare al bucket versione per recuperare il file "sovrascritto". Il versioning degli oggetti in S3 è stato progettato in modo brillante in modo tale che i client S3 ignari del controllo delle versioni non siano in alcun modo disabilitati o confusi, perché se non si effettuano chiamate REST sensibili al controllo delle versioni, le risposte restituite da S3 sono compatibili con i client che hanno nessun concetto di versioning.
Si noti inoltre che il trasferimento di dati in S3 è privo di costi di trasferimento. Paghi solo il prezzo per richiesta. Anche il trasferimento di dati da S3 a EC2 all'interno di una regione è gratuito. È solo quando trasferisci da S3 a Internet, a Cloudfront o in un'altra regione AWS che paghi le spese di trasferimento. Se si desidera utilizzare l'archiviazione a ridondanza ridotta a basso costo, s3fs lo supporta con -o use_rrs.
A parte il divertimento, avrai sempre una calda sensazione confusa quando vedi i 256 terabyte di spazio libero (e 0 utilizzati, poiché un vero calcolo delle dimensioni è impraticabile a causa del fatto che S3 è un archivio oggetti, non un filesystem ).
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.9G 1.4G 6.2G 18% /
s3fs 256T 0 256T 0% /srv/s3fs/example-bucket
Certo, puoi montare il secchio ovunque. Mi è capitato di averlo in / srv / s3fs.