AmazonEC2の冗長NFS

Question

AmazonEC2でフェイルオーバーを備えた2つのフォールトトレラント/冗長NFSサーバーを構築することに興味があります。私はDRBD、ハートビートなどのツール/テクノロジーに精通しています。Amazonは、プラットフォームを通じてこれを実現するための特定の方法を提供していますか？

適切な例としては、ファイルが別の冗長EBSに保持されている場合があります。障害が発生した場合、事前に構築されたAMIから新しいインスタンスが自動的に起動され、EBSボリュームがマウントされ、IPアドレスがシームレスに移行されます。

これは可能ですか？アマゾンよりも優れたプラットフォームはありますか？これを実現するために私たちが話している基盤となるアーキテクチャの概要を教えてください。

cyberx86 · Accepted Answer

AWSでは、Elastic Load BalancerでGlusterFSを使用し、EC2インスタンスを自動スケーリングすることで目的を達成できるはずです。他のIaaSについてコメントすることはできません。

Amazonは、目的を達成するために必要なもののいくつかを提供し、残りを実装することを可能にします。

AmazonのEC2サーバーは基本的にVPSであり、Heartbeat/Corosync/Pacemakerなどをセットアップできます（前回チェックしたときは、ネットワークでブロードキャストを使用できませんが、ユニキャストを使用できます-udpu）。

あなたは、Amazonが（ある程度）別々に取り組む2つのアイデア、フォールトトレランスと冗長性について言及しています。

EC2には冗長性のための組み込みメカニズムはありませんが、探しているものに応じて、それを実現するいくつかの方法があります。

理論的には、S3は複数の冗長性レイヤーで設計されており、「特定の年にオブジェクトの 99.999999999％の耐久性を提供するように設計されています」。彼らのSLAは 99.9％の可用性年間です。静的ファイルのためにそのルートに行きたい場合は、ローカルファイルシステムとしてs3Fuseを使用してS3バケットをマウントできます。ただし、これはかなり遅いので、ほとんどの目的（コード、データベース、サーバーソフトウェアなど）にはあまりお勧めできません。
EBSスナップショットは、EBSボリュームの圧縮された差分ポイントインタイムイメージを提供します。これらはバックアップとして最適であり、スナップショットから新しいインスタンスを起動できますが、真の冗長性ではありません。
実際の冗長性を解決するには、自分で設定する必要があります。この問題のために設計された1つのアプローチはGlusterFSです。ブリックを分散、複製、またはその両方としてセットアップでき、データはシステム全体に分散されます。個々のノードの削除に対して復元力があり、複数のインスタンスを起動してビルドできるAMIがビルド済みです。集まる。

一方、フォールトトレランスは、Amazonプラットフォームによってより適切に提供されます。

EC2ネットワークは、複数のリージョンとアベイラビリティーゾーンを提供します。これらは（理論的には）単一障害点を回避するために、分離されたデータセンターや地理的に分離されたデータセンターを提供します。
Amazonは、さまざまなインスタンスメトリクス（CPU、ネットワーク、ディスクI/Oなど）のモニタリング（Cloudwatch）と、カスタムメトリクスを提供しています。これらは、「自動スケーリング」と呼ばれるプロセスである、事前に構築されたAMIから新しいインスタンスを起動するためのトリガーとして使用できます。
EC2にはElasticIPアドレスがあります。これらはパブリックIPアドレスであり、予約してオンデマンドで別のインスタンスにすばやく再マッピングできるため、インスタンスがダウンしたときのDNS伝播の遅延を回避できます。
最後に、AmazonにはElastic Load Balancerがあります。これらは、単一障害点を回避し、着信トラフィックに合わせて拡張できるように設計されているはずです（ロードバランサーとしてセットアップされた単一インスタンスと同じ帯域幅制限の影響を受けません）。に）。 ELBは、バックエンドインスタンスの「正常性」を監視し、自動スケーリングと連携して適切な数のインスタンスを維持できます。

上記に加えて、新しく起動したインスタンスにカスタムパラメータを渡したり、現在実行中のインスタンスに関する情報をかなり簡単に取得したりできます。これにより、セットアップの一部をスクリプト化できる場合があります（もちろん、AWSには次のAPIがあります。エラスティックIPアドレスの再マッピング、新しいインスタンスの起動、EBSボリュームのデタッチ/アタッチなど、提供されるすべてのアクションをスクリプト化できます。

「ファイルは別の冗長なEBSに保存されます... [その後]マウントされます」と説明しました。まず、EC2では、EBSボリュームは一度に1つのインスタンスにのみアタッチできます（したがって、データをインスタンスにコピーするには、EBSボリュームをアタッチする必要があります）。冗長性を維持するのはあなた次第です（EBSデバイスのRAIDアレイをセットアップするか、他のほとんどすべてを行うことができます）。ただし、問題は、インスタンスが実際にクラッシュしたときにEBSボリュームがデタッチされない場合があることです。ただし、EBSボリュームを強制的にデタッチでき（成功率は高くなりますが、完全ではありません）、使用中であってもEBSボリュームのスナップショットを作成できます（次に、から新しいEBSボリュームを作成し、を使用してAMIを起動できます。ただし、同じインスタンス上の複数のEBSボリューム間ではなく、複数のインスタンス間でデータのレプリカを維持することをお勧めします（リカバリ時間の短縮、柔軟性の向上など）。