5

Webアプリケーションは、スタンドアロンサーバーからロードバランサーの背後にあるサーバーのペアに移行中です。このアプリケーションには、急速に成長しているユーザー作成データの50GBディレクトリが含まれています。ラックスペースでは、ディスクスペースを動的に追加する唯一の方法は、RAMと月額コストを2倍にすることですが、これは必要ありません。したがって、クラウドファイルにとってはそうです(誰かが別の解決策を考えている場合を除きますか?)。JungleDiskを使用すると、ファイルをクラウドファイルコンテナに移動し、両方のサーバーにクラウドコンテナをマウントして、コンテンツがあったディレクトリからマウントされたドライブへのシンボリックリンクを作成できます。これにはコードの変更は必要ありません。または、PHP APIを使用してクラウドファイルと直接インターフェースすることもできますが、これには大規模なコード変更が必要になります(すべてのパス?本当に?)。この場合、簡単な方法をとることに固有の問題はありますか?モデルを設定してみたらうまくいくようですが、普段は何かが足りないようです。

ありがとう、ブランドン

4

1 に答える 1

0

ドライブをマウントすることはあなたのシナリオにとって非常に理にかなっていると思いますが、正直なところ、私は負荷をかけずにそれを試していません。良いニュースは、いつでも簡単なアプローチを試して、負荷がかかっても機能しない場合はリファクタリングできることです。Rackspaceがこの正確なシナリオを説明し、テストしたことを願っています。それは私には理にかなっているようです。

いくつかの無関係な情報については、ここで同じ質問に直面し、クラウドサイトとクラウドファイルの使用のコスト比較を行いました。サイト/サーバーとクラウドファイル間の通信には依然として帯域幅料金が発生するため、帯域幅とストレージの量の両方をコストに含める必要がありました。つまり、たくさんのファイルがありますか、それとも頻繁にアクセスされるファイルがいくつかありますか。

クラウドサイトとクラウドファイルのパフォーマンスとスケーラビリティの違いについて、RackSpaceのサポートと話し合うことに多くの時間を費やしています。電話をかけることをお勧めします。最終的には、ニーズのためにサイトのみを使用することを選択しました。規模が拡大しても、コストの差はほとんどありませんでした。また、Cloud Files APIには必要なきめ細かいセキュリティがなかったため、とにかくゲートウェイサービスを作成する必要がありました。

于 2010-08-04T17:24:21.207 に答える