AWSの外部にあるサーバーがあります。EFSボリュームをマウントできるようにしたいのですが、それが可能かどうかはわかりません。
おそらく、VPCを作成し、VPNを介してトンネルを作成するとしますか?
これが可能かどうか誰にもわかりますか?
AWSの外部にあるサーバーがあります。EFSボリュームをマウントできるようにしたいのですが、それが可能かどうかはわかりません。
おそらく、VPCを作成し、VPNを介してトンネルを作成するとしますか?
これが可能かどうか誰にもわかりますか?
回答:
重要な更新:
2018年10月、AWSはEFSを支えるネットワークテクノロジーの機能を拡張し、以下に詳述するプロキシの回避策に頼ることなく、管理されたVPN接続とクロスリージョンVPCピアリングでネイティブに動作するようになりました。
EFSは、2016年後半にAWS Direct Connect回線を介した接続のサポートを追加しました。
https://aws.amazon.com/blogs/aws/amazon-efs-update-on-mise-access-via-direct-connect-vpc/
質問を最初に読んだときに、EFSに精通していると思っていたので、コメントにはいくつかの興味深い問題がありました。
したがって、最初に、少し背景を説明します。
Elastic File Systemの「弾性」とは、外部アクセスの柔軟性ではなく、主にストレージスペースとスループットの自動スケーリングを指します。
EFSには、保存できるデータの量に意味のある制限はないようです。EFSボリューム上の単一ファイルの文書化された最大サイズは52,673,613,135,872バイト(52 TiB)です。他の制限のほとんどは同様に寛大です。
EFSは、請求方法が特に「柔軟」です。EBSボリューム上のファイルシステムとは異なり、スペースはEFSに事前に割り当てられておらず、1時間平均で保存したものに対してのみ支払います。蓄積した量に応じて、料金は増減します(「弾力性のある」)。ファイルを削除すると、1時間以内にそれらが占有したスペースに対する支払いを停止します。1 GBを750時間(≅1か月)保管してから削除した場合、または375 GBを2時間保管してから削除した場合、毎月の請求額は$ 0.30になります。もちろん、これはEBSとはまったく異なります。EBS 0x00
は、月の残りの時間に375 GBを保存するために37.50ドルを請求します。
S3のストレージ価格モデルはEFSとほぼ同じです。オブジェクトを削除するとすぐにストレージへの請求が停止し、コストはEFSのコストの約1/10ですが、私や他の人が何度も述べているように、S3はファイルシステム。s3fs-fuseのようなユーティリティは「インピーダンスブリッジ」を提供しようとしますが、実際にはファイルシステムではないものをあたかもそれと同じように扱うことには本質的な困難があります。したがって、実際の「ファイルシステム」が必要なものであり、アクセスを共有する必要があるアプリケーション、または必要なストレージのスペースを決定するのが難しい、またはオンデマンドで拡張したい場合は、EFSが便利です。
また、8.0 EiBの空き領域がある場合はクールに見えます。
$ df -h | egrep '^Filesystem|efs'
Filesystem Size Used Avail Use% Mounted on
us-west-2a.fs-5ca1ab1e.efs.us-west-2.amazonaws.com:/ 8.0E 121G 8.0E 1% /srv/efs/fs-5ca1ab1e
us-west-2a.fs-acce55ed.efs.us-west-2.amazonaws.com:/ 8.0E 7.2G 8.0E 1% /srv/efs/fs-acce55ed
しかし、もちろん、アプリケーションに最適なストレージサービスを使用することが重要です。各オプションには有効なユースケースがあります。EFSはおそらく、AWSが提供するストレージソリューションの中で最も専門的なものであり、EBSやS3よりも使用ケースのセットが狭くなっています。
しかし、VPCの外部から使用できますか?
公式の答えは「いいえ」です。
VPN接続、VPCピアリング、AWS Direct ConnectなどのVPCプライベート接続メカニズムを介したファイルシステムのマウントはサポートされていません。
— http://docs.aws.amazon.com/efs/latest/ug/limits.html
EFSは現在、EC2 Linuxアクセスのみに制限されています。それもVPC内です。より多くの機能がすぐに追加されます。リリースされた新機能に関するAWSのアナウンスメントを監視できます。
— https://forums.aws.amazon.com/thread.jspa?messageID=732749
ただし、これは公式にサポートされている構成ではありませんが、実用的な答えはYesです。動作させるには、いくつかの特別な手順が必要です。
各EFSファイルシステムには、エラスティックネットワークインターフェイス(ENI)を使用してVPC内のエンドポイントIPアドレスが割り当てられます。これは通常、アベイラビリティゾーンごとに1つであり、パフォーマンス上の理由だけでなく、インスタンスに一致するアベイラビリティゾーンに確実にマウントする必要がありますが、また、アベイラビリティーゾーンの境界を越えてデータを転送するときに帯域幅料金が適用されるためです。
これらのENIの興味深い点は、それらが接続されているサブネットのルートテーブルを使用していないように見えることです。セキュリティグループの設定に関係なく、VPC内のインスタンスにのみ応答できるようです(各EFSファイルシステムには、アクセスを制御する独自のセキュリティグループがあります)。
外部ルートにアクセスできないため、ハードウェアVPNを介してEFSエンドポイントに直接アクセスすることはできません...そこで、実際に(@Timが予測したように)この作業を行うために必要な古い友人HAProxyを使用しました。EFSはTCPポート2049のみを使用するため、簡単な構成です。
t2.nanoでHAProxyを使用しています(HAProxyは非常に効率的です)。次のような構成になっています。
listen fs-8d06f00d-us-east-1
bind :2049
mode tcp
option tcplog
timeout tunnel 300000
server fs-8d06f00d-us-east-1b us-east-1b.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000
server fs-8d06f00d-us-east-1c us-east-1c.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000 backup
server fs-8d06f00d-us-east-1d us-east-1d.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000 backup
このサーバーはus-east-1bにあるため、us-east-1bエンドポイントをプライマリとして使用し、他の2つを1bのエンドポイントがヘルスチェックに失敗した場合のバックアップとして使用します。
あなたのVPCにVPNを使用している場合は、その後、ターゲットとして、このプロキシインスタンスのIPアドレスを使用してボリュームをマウントする(代わりにEFSを使用しての直接エンドポイント)、および出来上がりますVPC外からEFSファイルシステムをマウントしています。
外部のUbuntuマシンとSolaris¹サーバー(EFSは、サービスを移行しやすくすることにより、EFSの廃止を早めるのに非常に便利であることが証明されています)に正常にマウントしました。
AWSにデータを移動したり、移行中に特定のデータでレガシーシステムとクラウドシステムを並行して実行したりといった特定の状況では、EFSが勝者のようです。
もちろん、往復時間が長いレガシーシステムはEC2インスタンスと同じように機能しませんが、それは当然のことです。物理法則の例外はありません。それにもかかわらず、EFSとHAProxyゲートウェイは、外部で動作させるための安定したソリューションのようです。
VPNがない場合、1台のAWSとデータセンターの1台のHAProxyマシンのペアは、TLSを介してEFSをトンネリングし、個々のEFSを転送するためにTLSでラップされたペイロードとの個別のTCP接続を確立することもできますインターネットを介した接続。技術的にはVPNではなく、接続の暗号化されたトンネリング。これも非常にうまく機能しているようです。
¹Solaris10は(驚くことではありませんが)デフォルトでは多少壊れています-最初は、rootは特別な特権を持っているようには見えませんでした-rootによって作成されたEFSボリューム上のファイルはrootが所有しchown
ますが、Operation not permitted
すべてがUbuntuクライアントから期待どおりに機能する場合でも、Solarisマシン()。この場合の解決策は、を使用してSolarisマシン上のNFS IDマッピングデーモンを無効にすることsvcadm disable svc:/network/nfs/mapid:default
です。このサービスを停止すると、すべてが期待どおりに機能します。さらに、/usr/sbin/quota
各ログインでの呼び出しはで無効にする必要があります/etc/profile
。より良いまたはより正しい解決策があるかもしれませんが、それはSolarisですので、調査するのに十分興味がありません。
2016年12月20日、Amazonは、オンプレミスサーバーにEFSファイルシステムをマウントするために使用できるAWS Direct Connectを発表しました。そのため、基本的に、VPCの外部でAWS EFSを使用できるネイティブ機能があります。
前提条件として、AWS Direct Connect接続を有効にして確立し、EC2インスタンス内でEFSをマウントするときに使用する必要があるnfs-utilsを使用する必要があります。
詳細については、次のURLを参照してください。VPCの外部にEFS接続のネイティブソリューションがあることを他の人が認識できるように、この将来も探していたので、これを投稿しました。