Amazon EBSを複数のインスタンスにアタッチできますか？
現在、1つのmysqlサーバーとファイルサーバーにアクセスする複数のWebサーバーを使用しています。クラウドへの移行を見ると、この同じセットアップを使用してEBSを複数のマシンインスタンスにアタッチできますか、それとも別のソリューションは何ですか？
UPDATE（2015年4月）：このユースケースでは、新しい Amazon Elastic File System（EFS） =、必要な方法で正確に多重接続されるように設計されています。 EFSとEBSの主な違いは、異なる抽象化を提供することです。EFSはNFSv4プロトコルを公開しますが、EBSはrawブロックIOアクセスを提供します。
以下に、複数のマシンにrawブロックデバイスを安全にマウントできない理由についての最初の説明を示します。
オリジナルPOST（2011）：
EBSボリュームを複数のインスタンスに接続できた場合でも、_REALLY_BAD_IDEA_になります。ケコアを引用すると、「これは、2台のコンピューターで同時にハードドライブを使用するようなものです」
これが悪い考えなのはなぜですか？...ボリュームを複数のインスタンスにアタッチできない理由は、EBSが「ブロックストレージ顧客がext2/ext3/etcのようなファイルシステムを実行する抽象化。これらのファイルシステム（ext2/3、FAT、NTFSなど）のほとんどは、ブロックデバイスへの排他的アクセス権があると想定して記述されています。同じファイルシステムにアクセスする2つのインスタンスは、ほぼ確実に涙とデータ破損で終わります。
つまり、EBSボリュームのダブルマウントは、複数のマシン間でブロックデバイスを共有するように設計されたクラスターファイルシステムを実行している場合にのみ機能します。さらに、これでも十分ではありません。このシナリオでは、EBSをテストし、他の共有ブロックデバイスソリューションと同じ一貫性の保証を提供することを確認する必要があります。つまり、Dom0カーネル、Xenレイヤーなどの中間非共有レベルでブロックがキャッシュされない、およびDomUカーネル。さらに、複数のクライアント間でブロックを同期する際のパフォーマンスの考慮事項があります。クラスター化されたファイルシステムのほとんどは、ベストエフォート型のコモディティイーサネットではなく、高速専用SANで動作するように設計されています。それはとても単純に聞こえますが、あなたが求めているのは非常に重要なことです。
または、データ共有シナリオがNFS、SMB/CIFS、SimpleDB、またはS3であるかどうかを確認します。これらのソリューションはすべて、共有ブロックデバイスサブシステムを持たずにファイルを共有するための上位層プロトコルを使用します。多くの場合、このようなソリューションは実際にはより効率的です。
あなたの場合、あなたはまだ複数のウェブフロントエンドによってアクセスされる単一のMySqlインスタンス/ファイルサーバーを持つことができます。そのファイルサーバーは、そのデータをEBSボリュームに保存し、夜間のスナップショットバックアップを取ることができます。ファイルサーバーを実行しているインスタンスが失われた場合、EBSボリュームをデタッチし、新しいファイルサーバーインスタンスに再接続して、数分でバックアップして実行できます。
"ファイルシステムとしてS3のようなものはありますか？"-はい、いいえ。はい、 s3fs のようなサードパーティ製のソリューションがありますが、それは「正常」に動作しますが、内部では、読み取り/書き込みごとに比較的高価なWebサービス呼び出しを行う必要があります。共有ツールディレクトリの場合は、うまく機能します。クラスタ化されたFSの使用法は、HPCの世界で見られるものであり、偶然ではありません。より良くするには、NFSなどのバイナリ接続指向プロトコルを提供する新しいサービスが必要です。合理的なパフォーマンスと動作を備えたこのようなマルチマウントファイルシステムを提供することは、EC2のすばらしい機能アドオンになります。私はAmazonがそのようなものを構築することを長年支持してきました。
いいえ、これは2台のコンピューターでハードドライブを使用するようなものです。
共有データが必要な場合は、すべてのインスタンスがアクセスできるサーバーをセットアップできます。すべてのインスタンスにシンプルなストレージエリアが必要な場合は、AmazonのS3ストレージサービスを使用して、分散されたスケーラブルなデータを保存できます。
クラウドに移行すると、まったく同じセットアップを使用できますが、ファイルサーバーをS3に置き換えるか、すべてのインスタンスをファイルサーバーに接続することもできます。
多くのオプションがありますが、インスタンス間でハードドライブを共有することはおそらく最良のオプションではありません。
いいえ、EBSのドキュメントによると、「ボリュームは一度に1つのインスタンスにしか接続できません」。
現在、共有ストレージをどのように使用していますか？ファイルサーバーからファイルを提供するだけの場合、ウェブサーバーにそれらのファイルを提供させるのではなく、ファイルサーバー上のプロセスへの特定のリクエストをプロキシできるようにシステムをセットアップすることを検討しましたか？
できないと確信していますが、EBSのクローンを作成して別のインスタンスにアタッチできます。
これは、固定データセット、または「実際の」データのテストに役立ちますが、1つのブロックストアで複数のインスタンスを操作することはできません
MySQLサーバーとファイルサーバーにアクセスする複数のWebサーバーは、AWSでは正常です。上記のアーキテクチャについて従うべきベストプラクティスのいくつかは次のとおりです。
ポイント1）EC2上のMySQLは、AWSの非同期/半同期モードでマスター/スレーブとして設定できます。 RAID 0のEBS-OPT + PIOPSは、高性能DBに推奨されます
ポイント2）または、Amazon RDS +マルチAZモードを使用できます。読み取りスケーリングの場合、複数のRDSリードレプリカをMySQL RDSに接続できます。
ポイント3）EBSボリュームを複数のEC2に同時に接続することはできません。 EBSを使用して、Amazon EC2でGlusterFSに基づくファイルサーバーを作成できます。複数のWebサーバーが、AWSインフラ上で単一のGlusterFSと同時に通信できます。
ポイント4）アプリケーションをファイルストアとしてS3に統合できる場合、アーキテクチャに安定性をもたらすため、この方法が推奨されます。アプリケーションからS3Fuseなどのツールを使用してS3にアクセスすることもできます。
ボリュームとsshfsを持つ1つのインスタンスを他のインスタンスのそのボリュームに作成しないのはなぜですか？
ITの世界には、クラスター化ファイルシステム、Redhat GFS、Oracle OCFS2、Veritas CFSとして知られているものがあります...
簡潔な答えは、カテゴリー「いいえ」です。他の人はそれを上で言った。
「はい」と言った人は質問に答えなかったが、別の質問に答えた。 EFSが単なるNFSサービスである場合、最初に述べたように、それは質問に対する答えではありません。また、EFSが「すべてのゾーンで展開される」かどうかは関係ありません。これは、独自のNFSインスタンスを作成でき、複数のサーバーでNFSをマウントできるためです。それは新しいものではありません。1992年に既に行っています。 SMBおよびsshfs、これらはすべて、ドライブをリモートファイルシステムとしてマウントする方法にすぎません。
「なぜあなたはそれをしたいのか」または「それはすべて涙で終わる」と言った人は間違っています。何十年もの間、複数のディスクを複数のサーバーにマウントしてきました。 SAN（ストレージエリアネットワーク））を使用したことがある場合、通常FibreChannel SANを使用して同じデバイスを複数のノードに接続する機能は完全に正常です。 10年前に仮想化/クラウドサーバーがユビキタスになる前にサーバーを実行していた人は、それをある程度経験しています。
すぐに、2つのシステムがまったく同じボリュームを読み書きできるクラスター化されたファイルシステムがありました。これはVAXとAlpha VMSの歴史の中ですでに始まったと思います。クラスター化されたファイルシステムは、分散相互排除方式を使用して、ブロックを直接操作できます。
同じディスクを複数のノードにマウントする利点は、速度と単一障害点の削減です。
現在、クラスター化されたファイルシステムは、 "コンシューマ"ホスティングビジネスではあまり人気がありません。それは事実です。そして、それらは複雑であり、いくつかの落とし穴があります。ただし、複数の計算ノードに接続されたディスクを使用するためにクラスター化されたファイルシステムさえ必要ありません。読み取り専用ドライブが必要な場合はどうしますか？クラスター化されたファイルシステムさえ必要ありません！読み取り専用（ro）と同じ物理デバイスを/ etc/fstabに配置するだけです。次に、2台または10台のEC2サーバーにマウントすると、すべてのサーバーがそのデバイスから直接読み取ることができます！
急速にスケーリングするファームを構築するとき、クラウドサーバーの世界でこれを使用する明らかな使用例があります。メインシステムディスクをすべて準備して、各サーバーに非常に小さなブートおよび構成ディスクだけを使用できます。それらすべてを同じブートディスクからブートすることもでき、読み取り/書き込みモードで/を再マウントする直前に、3層のUnion-FSを挿入できます。
- メインの読み取り専用システムディスク、ブート、カーネル、およびユーザーランドのインストール
- 個々のサーバーに固有の少数のファイル（ほとんどは/ etcにある）のみを備えた構成ファイルシステム。このディスクは、新しいインスタンスの起動を準備するために別のサーバーによって書き出すことができます。ここでのファイル例は/ etc/hostnameであり、ノードごとに異なる必要がある設定ファイルはごくわずかです。
- まったく必要ないかもしれない書き込み可能なディスクは、メモリファイルシステムとしての/ tmpだけです。
したがって、はい、質問は非常に理にかなっており、残念ながら答えは「まだ」「いいえ」です。また、NFSは、システムディスクからのすべての読み取りアクティビティにペナルティを課すため、そのユースケースの優れた代替品ではありません。ただし、NFSシステムディスクからのネットワークブートは、上記のユースケースを実装するための唯一の選択肢です。残念ながら、ネットワークブートエージェントとNFSのセットアップは、同じ物理ブロックデバイスにアクセスするよりもはるかに複雑です。
PS：これの短いバージョンをコメントとして提出したかったのですが、愚かな51クレジットポイントのしきい値のためにできませんでした。当然の答えを受け取っていない関連する質問。
PPS：StackExchangeでiSCSIについて言及している人を見つけました。 iSCSIはNFSに多少似ていますが、論理的にはFibreChannel SANに似ています。物理ブロックデバイスにアクセス（および共有）できます。ブートディスクの共有が簡単になるため、bootdネットワークブートを設定する必要がなくなります。ただし、AWSでは、利用可能なネットワークブートもありません。