本質的に非常に大容量のSFTPサーバーをセットアップする必要があります。パートナーの1人に、数百テラバイトのファイルをアップロードするサーバーへのSFTPログイン詳細を提供する必要があります。その後、私は選択的であり、これらのファイルの一部を読み取ることはほとんどありません。これが唯一の実際の要件であり、どのようなテクノロジーの選択も可能です。
最も簡単な方法として頭に浮かぶのは、アップロードされたものを直接S3に送信するか、アップロードされたときに何らかのプロセスが新しいファイルを見つけてそれらをコピーするような方法で、SFTPサーバーを実行するある種のEC2インスタンスを用意することですS3、およびそれらをディスクから削除します。
これは最善の方法ですか?基本的に「無限で魔法のように増大するディスク領域」を持つサーバーを取得する他の方法はありますか?
ご協力いただきありがとうございます!ダニエル
私は答えました スタックオーバーフローに関する同じ質問 。
s3fsは確かに妥当な解決策であり、私の場合、理論的/潜在的な問題にもかかわらず、私はそれをproftpdと組み合わせて優れた結果を得ました。
回答を書いた時点では、これはコンサルティングクライアントの1つにのみ設定していたのですが、それ以来、自分のクールエイドを飲み始め、日常業務で本番環境で使用しています。 S3にすべてを直接保存している私のsftpサーバーで、アップロードおよびダウンロードファイルとデータを1日中交換する会社。おまけとして、ExcelスプレッドシートをS3に直接書き込むレポートエクスポートシステムは、レポートをFTPサーバーのバケットに直接配置するだけで、uid、gid、および各ファイルのモード。 (s3fsは、x-amz-meta-uid、-gid、および-modeヘッダーを使用してファイルシステムのアクセス許可をエミュレートします)。クライアントがサーバーにログオンすると、レポートファイルはただそこにあります。
理想的な解決策はおそらくsftpからS3へのゲートウェイサービスだと思いますが、この解決策は非常にうまく機能するため、まだ設計に取り掛かっていません。もちろん、いくつかの注意点があります。
S3fsのすべてのデフォルト値が正常であるとは限りません。おそらくこれらのオプションを指定したいと思うでしょう:
-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
US-Standard以外のリージョンを使用することをお勧めします。これは、新しいオブジェクトで書き込み後の読み取り一貫性を提供しない唯一のリージョンであるためです。 (または、US-Standardを使用する必要がある場合は、ほとんど文書化されていないホスト名your-bucket.s3-external-1.amazonaws.com
をus-east-1リージョンから使用して、リクエストが地理的にルーティングされるのを防ぎ、一貫性を向上させることができます。)
バケットでオブジェクトのバージョニングを有効にしていますが、s3fsでは完全に認識されません。これの利点は、ファイルが「踏みにじられる」必要がある場合でも、バケットのバージョン管理にいつでも行って「上書きされた」ファイルを回復できることです。 S3のオブジェクトバージョニングは、バージョニングを認識しないS3クライアントが決して無効にされたり混乱したりしないように見事に設計されました。バージョニング対応REST呼び出しを行わない場合、S3が返す応答は互換性があるためです。バージョン管理の概念がないクライアントと。
また、データ転送料金の データの転送からS3は無料 です。リクエストごとの料金のみを支払います。 S3からEC2にリージョン内でデータを転送する場合も、データ転送料金はかかりません。転送料金を支払うのは、S3からインターネット、Cloudfront、または別のAWSリージョンに転送する場合のみです。低価格の冗長性の低いストレージを使用する場合、s3fsは-o use_rrs
でそれをサポートします。
おかしなことに、256テラバイトの空き領域(および0が使用されていることがわかります)は、S3がファイルシステムではなくオブジェクトストアであるため、実際のサイズの計算が非現実的であるため、常に温かみのあるぼやけた感じになります。 )。
$ 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
もちろん、バケットはどこにでも取り付けることができます。私はたまたまそれを/ srv/s3fsに置いています。
AWS MarketplaceのSFTPゲートウェイ を確認してください。
S3fsで信頼性の問題が発生したため、この目的専用のカスタムソリューションを開発しました。私たちは数年問題なくそれを本番環境で使用しており、最近AWSマーケットプレイスにリリースしました。
2つのオプションがあります。最近Amazonによって追加されたネイティブのマネージドSFTPサービスを使用できます(セットアップが簡単です)。または、バケットをLinuxサーバー上のファイルシステムにマウントし、サーバー上の他のファイルと同様にSFTPを使用してファイルにアクセスできます(これにより、より詳細に制御できます)。
Amazon AWSコンソールで、 AWS Transfer for SFTP に移動し、新しいサーバーを作成します。
SFTPサーバーページで、新しいSFTPユーザーを追加します。
ユーザーのアクセス許可は、IAMサービスの関連するAWSロールによって管理されます(クイックスタートでは、AmazonS3FullAccessポリシーを使用できます)。
ロールには、transfer.amazonaws.com
との信頼関係が必要です。
詳細については、マイガイド Amazon S3へのSFTPアクセスのセットアップ を参照してください。
@Michaelはすでに answered なので、s3fs
ファイルシステム(または同様のもの)を使用してバケットをLinuxサーバー(Amazon EC2)にマウントし、サーバーの組み込みSFTPサーバーを使用してバケツ。
基本的な手順は次のとおりです。
s3fs
をインストールaccess-key-id:secret-access-key
の形式で/etc/passwd-s3fs
に追加しますバケットマウントエントリをfstab
に追加します。
<bucket> /mnt/<bucket> Fuse.s3fs rw,nosuid,nodev,allow_other 0 0
詳細については、マイガイド Amazon S3へのSFTPアクセスのセットアップ を参照してください。
または、任意の無料の「FTP/SFTPクライアント」を使用します。これも「S3クライアント」、サーバー側で何もセットアップしていません。たとえば、myWinSCP または Cyberduck です。
AWSは AWS Transfer For SFTP と呼ばれるSFTP over S3サービスを提供するようになりました。 S3(耐久性が高く、利用可能な分散ストレージ)と、よく知られ確立されているSFTPプロトコルを組み合わせた利点があります。
デフォルトでは、ユーザーは秘密鍵と公開鍵のペアを使用して認証し、IAMポリシーを使用して、S3バケットでSFTPユーザーのアクセス許可を設定できます。 AWS API GatewayとAWS Lambdaに独自の機能を実装することで、認証スキームを追加できます。
SFTP To Go と呼ばれるHerokuアドオンにSFTPのAWS Transferをラップして、柔軟な認証スキームと低いTCOの両方を提供します(サービスエンドポイントはAWSで固定コストですが、共有できます)多くのユーザーによるセキュリティやパフォーマンスの妥協なし。