Project Home Downloads Wiki Issues Source
Hardware  
MogileFSのハードウェアのお薦め
Updated Jan 9, 2012 by dorma...@rydia.net

MogileFS ハードウェアの使い方

目的

MogileFSが従っている設計は、柔軟性、日常品、廉価なハードウェア要求です。(廉価/くだらないもの という意味ではありません)。ベンダーのロックインを避け、アプリケーションにとって最も良いものを組み合わせ、調和し、選択することができます。ストレージノード上に組み込みRAIDボリュームを必要としないように設計され、実際そうしないことをとても勧めています。Individual/smaller drives can be cheaper, and will scale writes better. リプリケーションは通常別個のホスト間で行われ、一つのホストでの複数のコピーは冗長です。RAIDまたはそれ以外

共有ホスト

MogileFS コンポーネントは、容量に問題がなければ、共有ホストで実行することができます。トラッカーはいくらかのCPUとメモリを使うでしょうが、ストレージノードはCPU(web/etc)ノードに少しのハードドライブを追加するとその上で動作するでしょう。データベースは大きなデータベースと共有することができます。インストールを身につけると、専用ハードウェアに移動することは難しくありません。

専用ホスト

MogileFSコンポーネントの専用のハードウェアを持つことの注意とお薦め

トラッカー

トラッカーはお手軽です。workerプロセスを実行する分だけのメモリを利用するでしょう。perlのバージョン、ホストOS、MogileFSのバージョンによって変わるでしょう。メモリ(code/etc)のほとんどもプロセス間で共有されるでしょう。トラッカーはデータベースに激しくアクセスし、memcachedをもっていればそれに、リプリケーションのために大量のネットワークの通信量を使うかも知れません。ファイルはソースノードから宛先ノードにトラッカーをプロキシとしてコピーします。そのためトラフィックは増加するでしょう。

トラッカーはディスクを使いません(syslogをディスクに送信している場合のローカルsyslogを除きます)。そのため、根性の無い/冗長性の無い ディスクが良いでしょう。クライアントは、一つへのアクセスが失敗した場合には複数のトラッカーの試行をサポートしなければならないため、トラッカーは巨大な冗長のハードウェアの必要はありません。

ジョブの大量のセットにおいて大量のfsck/replicate workerが実行されることで、CPUの利用は大きなものになりえます。実行するworkerの数を制限し大きなバッチのジョブの処理に時間を掛けることで、これは簡単に蓋をかぶせることができます。

データベース

トラッカーは通常データベースに対しては軽いです。バージョン2.30以降は残っていたDBの重いプロセスが最適化されています。ファイルと/またはパスをmogilefsの外部に適切にキャッシュすれば、リクエストは軽くなりDBの動きは小さくなるでしょう。大量のリプリケート/fsck/など が同時に実行されるか、巨大なアップロード時にはスパイクが発生します。

master/master データベースを使うことを非常にお勧めします。mySQLはもっとも利用されていますが、PostgreSQLもサポートされています。どうやってデータベースをリプリケートするかに関係なく、mogilefsトラッカーを単一のデータベースとして示す必要があることだけ注意してください。master/master clusterの異なった片方を示してしまうと、リプリケーションが壊れてファイルのアップロードに失敗するでしょう。DB のスケールアウトは必要ではありません(適切に設定された場合には、DB容量の前にディスク領域が問題になります)が、近い将来には必要になるかも知れません。現在のところ、mogileは同じデータベースの全てのトラッカーを示す必要があります。MySQLを使っていれば、信頼性とスピードのためにInnoDBが必要です。MyISAMは上手にスケールしないでしょうし、データを失いかねません。

DBのハードウェアのお勧めは様々でしょう。小さくはじめるには、R1 ディスクの小さなマシーンでもありえるでしょう。巨大なデータベースの場合は、最新のお薦めのために、DBAまたはパフォーマンスサイトに相談する必要があります。この文章の著者は通常、fastSASドライブ、バッテリーwriteキャッシュ付きのRAIDカード(crucial!)、および大量のRAMに行きます。Flashドライブは経済的になるのが遅く、指定されたMogileFSの要求には必要ないかも知れません。

ストレージ

ストレージノードは、もっとも決定のトレードオフが発生する箇所です。Generically: 少ないドライブで多くのノードを必要とするか、あるいは多くの大きなドライブで少ないノードを必要とするか。あるいは、大きなドライブで少ないノードか。ホットスワップのドライブを使っているか、スワップできない安いドライブを使っているか?

ストレージノードは一般的に多くのCPUを使わないでしょう。MogstoredはCPUを監視のためと(デフォルトでは)ファイルのアップロードのために使います。大規模構成には、読み込みロックを管理するために通常apacheまたはnginxを使います。All of the above will likely not tax your CPU before running you out of IO capacity.

覚えておく必要があるトレードオフは:

  • ノードを多くすると(もっと安価に)高速なRAM/disk レシオにすることができます。バックエンドにもっとRAMがあると、OSファイルキャッシュにファイルが存在し、パフォーマンスがよくなります。
  • ノードが完全に失敗した場合は、そのデバイス全てをdeadと印をつける(か、同じIP/デバイス名/など で新しいシャーシに移動する)必要があります。MogileFSが死亡したホストにあったファイルを再リプリケートするには時間が掛かるでしょう。
  • バージョン2.30+ ではノードの回復時間がきわめて短くなりましたが、大きなディスクの多くのノードの場合には消失からの回復に時間が掛かるでしょう。
  • アプリケーション/フロントエンドの要求を満たすために、十分なIOキャパシティを保障する必要があります。大きなドライブはたくさんのファイルを保存できますが、IOキャパシティにハードウェア的な制限があります。多くの小さなドライブは、もっと多くのIOを意味します。2TB+ドライバなんてもものを買わないでください。それらは遅いどころじゃありません。
  • システム外(Varnish, Squid, CDN)にファイルをキャッシュすることは、IOとトラッカーの容量がどれくらい使われるかに影響を与えるでしょう。
  • ストレージノードがホットスワップ機能付きの高価なRAIDカードを使うかどうかは、要求というよりは好みの問題です。MogileFSは追加したRAIDしているデバイスを必要と しない設計です。なので実際のところ、高価なカードは全く必要ではないでしょう。

大きなシステムでは、一台のマシーンあたり4から48かそこらのデバイスを持つことができます。MogileFSにストレージノードを追加することは、とても安価でトラッカーに著しい負荷を与えません。ノード間では(必要なリプリケーションと個々のファイルのリクエストを除いて)通信が無く、したがってハードウェアの追加はネットワークが許す限り容量の追加のみになります。

ホットスワップかどうかは好み/風情の問題です。下の"死亡したハードウェア"のセクションを見てください。

フロントエンド/プロキシ

フロントエンドは一般的にperlbalか、アプリケーション/nginx/etc の混成です。トラッカーからのパスの照合は、memcahcedかそのようなものでアプリケーションでキャッシュすることを非常にお勧めします。パスは数分または数時間キャッシュすることができます。キャッシュに多くのパスを提供すると、perlbal/nginxは操作不可能なかもしれないものをスキップするでしょう。

頻繁にアクセスされるファイルをキャッシュするために、vanishあるいはCDNを前に立てることで、バックエンドノードとトラッカーの疲労を大幅に少なくすることができます。繰り返しになりますが、これは好みの問題です。でっぷり肥えたストレージノードを持ち毎回バックエンドに再プロキシすることを好む人も居るでしょう。一方でもっと制御された方法で共通のファイルを提供するために重厚なキャッシュノードを持つのを好む人も居るでしょう。

死亡したハードウェアに何をするか

ドライブが壊れた場合には何をしなければいけないか?Should you spring extra for dedicated RAID controllers with hot swap backplanes, or can you go cheaper and use fast SATA/SAS cards and directly attach drives?

If you're OCD about having every drive bay active, go ahead and go the hot swap route. The cases are more expensive, backplanes, cards, etc. しかしながら、簡単に死亡したドライブを横にすべらし置き換えることができます。そうする場合は、単純に古い死亡したデバイスに印をつけ、新しいドライブを挿入し、それに 新しい device idを与えます。古いものを使いまわしてはいけません!

The other end of the spectrum is to use cold swappable hardware, with drives plugged directly into cheaper (but still fast!) SATA cards. ハードウェアを発注する場合は、来年のために実際に必要なドライブよりもちょっと多いドライブを買います。5%-10%くらい多く言いましょう。ドライブがデバイスの中で壊れた場合は、単純に'dead'として印をつけ、次に移ります。The failure rate for drives may well be low enough that it'll be necessary to replace the entire host before more than a few drives have failed in each. Or, if you're expanding rapidly, you're adding new hosts anyway.

The few extra drives ordered should work out to save costs over getting $700 RAID cards and extra expensive cases. データセンター内でドライブの取替えをしないことで、マンパワーのこすとも減らすことができます。

たくさんのホストがあれば、単純に死亡したハードウェアの電源を落として週/月/四半年の終わりまで無視することもできます。

結局は、それは好みの問題です。


Sign in to add a comment
Powered by Google Project Hosting
TOP
inserted by FC2 system