AmazonAutoScalingとGlusterFS
ロードバランサーに登録された5つのEC2インスタンスを使用してElasticロードバランシングをセットアップしました。当社のウェブサイトユーザーがデータ（画像）をアップロードするために、これらの画像をネットワーク接続ストレージ（NAS）に保存します。 NASがすべてのインスタンスにマウントされています。
Amazon AutoScalingを導入し、ネットワーク接続ストレージからも移行することを計画しています。
GlusterFSは、自動スケーリンググループのすべてのインスタンス間でデータを共有するための優れたソリューションですか？
Glusterはデータの損失がないことを保証しますか？
自動スケーリングのすべてのインスタンスが終了するとどうなりますか？ユーザーデータは失われますか？
ユーザーが画像をアップロードし、リクエストを処理しているサーバーがダウンした場合はどうなりますか？
クライアントがダウンした場合、IOに影響はありますか？（ Glusterは正確に何をしますか？ ）
GlusterFSは、自動スケーリンググループのすべてのインスタンス間でデータを共有するための優れたソリューションですか？
おそらく..あなたが決定的な答えを得る唯一の方法は、しかし、あなた自身のテストを使うことです。以前は、Linodeインスタンスに4ノードのWebサーバークラスターをセットアップし、GlusterFSを使用してイメージのアセットディレクトリなどを配布/共有していました。
このアプローチには2つの主な問題があります。
- GlusterFSはかなりIO集中的であり、競合しないIOを備えたハードウェアで非常にうまく機能します
- 時折、LinodeサーバーはバックエンドSANへのアクセスが最適ではなく、IO-Wait時間が劇的に増加することがありました。これが発生すると、Glusterは残りのノード間でより多くのデータをコピーするため、これらのノードでIOパフォーマンスが低下しました。その結果、マイナーIO最適ではないSAN構成、またはタイムシェアリングによって引き起こされるブリップは、Webサーバークラスター全体が機能しなくなり、共有ファイルシステム全体が使用できなくなる可能性があることを意味します。
純粋に事例証拠ですが、SAN /共有ストレージを備えた仮想マシンでGlusterFSを実行することは二度とありません。
Glusterはデータの損失がないことを保証しますか？
それが可能です... Gluster 3.0では、クラスター全体に存在するデータのコピー数を定義できる「レプリケーションプール」の認識が向上しています。レプリケーションレベルを2に設定すると、クラスター全体に2つのコピーが存在することになります。これにより、ストレージ容量が実質的に半分になりますが、ノード障害に対する回復力が向上します。
重要なことは、レプリケーションレベルの倍数（この場合はノードのペア）としてノードを追加する必要があることも意味します。
自動スケーリングのすべてのインスタンスが終了するとどうなりますか？ユーザーデータは失われますか？
インスタンスがエフェメラルインスタンスストレージのみを使用している場合は、はい。 EBSベースの場合、またはマウントされたEBSインスタンスを使用している場合は、いいえ。
ユーザーが画像をアップロードし、リクエストを処理しているサーバーがダウンした場合はどうなりますか？
これは、アプリケーションの設計方法に大きく依存します。私は、ユーザーがデータを失うことになるのではないかと強く疑っています（素朴に設計されたソリューションではほぼ確実です）。
クライアントがダウンした場合、IOに影響はありますか？
上記を参照してください。バックエンドストレージの問題が原因でクライアントがダウンした場合、クラスターのパフォーマンスが完全に破壊される可能性があります。
GlusterFSは、自動スケーリングが必要なインスタンスで使用するのに適したシステムにするために、新しいインスタンスをオンラインにするときに少し多すぎる構成を必要とするようです。私はそれができると確信していますが、Webインスタンスがglusterfsインスタンスとは異なるようにアーキテクチャを変更する方が簡単です。 Webインスタンスは、クライアントとしてglusterfsレイヤーに接続するだけで済みます。次に、Webインスタンスを自動スケーリングするように設定できます。
クラウドシステムを扱う際の適切なルールは、サービスとインスタンスを1：1でマッピングすることです。インスタンスにやりすぎをさせようとしないでください。アーキテクチャ上、これは物事をスケーリングしようとするときに役立ちます。
Glusterの質問に対するいくつかの良い答えはすでにありますが、役立つかもしれない何かについて言及したいと思います。
ユースケースによっては、次の管理が簡単でエラーが発生しにくい場合があります。
- EC2はすべて同一であり、コードをリポジトリから取得して最新の状態に保ちます（これは、デプロイプロセスを通じてさまざまな方法で管理できます）。
- ユーザーのアップロードは、アプリに統合されたs3fsまたはAPI呼び出し（python/phpなど）を介してS3に直接送信されます。
S3の利点は素晴らしいです：
- 使用した分だけ支払います（EC2の未使用のリソース全体、ランニングコスト、複数のマシンを介したレプリケーションなどに支払う必要はなく、管理も不要です）
- 冗長性はS3に組み込まれているため、ファイルはs3に移行した瞬間に安全になります（安全とは、世界中の複数の場所にあるマネージドサービスにあることを意味します。AWSは、s3でファイルを失ったことはないと報告しています）
さらに一歩進んだ場合は、すべてのログを「ロギングサーバー」に送信するように（Linux）サーバーを構成できます（これにより、すべてのEC2が同じように維持され、可能な限りダムダウンされます）。
この種のセットアップは、私が管理しているWebサーバーに対して過去に非常にうまく機能していることがわかりました。