SSDドライブを搭載したシステムにイカ(またはワニス)キャッシュを設定することを検討しています。
明らかな利点は、これらのシステムの読み取り速度が優れていることであり、ヒット率がかなり高いと予想しています。
7つのSSDをRAID構成に入れることができると仮定しましょう。 (私がはるかに多くを詰めることができるいくつかのケースがあります)
実装に関する質問:
RAID0を使用する必要がありますか? (ドライブは最終的に故障すると予想されるため、これは危険なようです。)
RAID10を使用する必要がありますか? (これにより、ディスクのフットプリントが半分になり、コストがかかります。)
RAID5を使用する必要がありますか? (SSDには「悪い」書き込みパフォーマンスと書き込み制限があることが知られており、余分なパリティ書き込みはすべてこれを大幅に遅くする可能性があります。)
各ディスクを独自のsquidデータストアとして扱う必要がありますか? (squidは複数のデータストアをどの程度うまく処理しますか?また、1つが失敗した場合はどうなりますか?)
データストアを無視して、SSDを大きなSWAPパーティションに入れ、LinuxにVMそれをやらせるべきですか?(ずさんなようです)
実稼働環境でSSDを使用している人々からのアドバイスをいただければ幸いです。 (特に、HTTPキャッシュに使用している場合)
過去9か月間ssdドライブにワニスを使用してきましたが、非常にうまく機能しています。以前は、鯉の層を備えたイカのメモリのみのキャッシュを使用していました。それは機能しましたが、メモリの断片化は頻繁な再起動を必要とする実際の問題でした。 Squid 2.xも1つのコアのみを使用するため、現在のハードウェアではかなり非効率的です。
キャッシュに非常に優しい私たちのサイトでは、100Mbit/sのトラフィックを処理する8コアマシンで約10%のCPU使用率が見られます。私たちのテストでは、2つの1GbポートでCPU制限に達する前に、帯域幅が不足しています。
Ssdキャッシュを使用してワニスを実行するためのアドバイスがあります。
ランダムな書き込みパフォーマンスは本当に重要です。 Intel x-25mに落ち着く前に、ssdドライブ用にいくつかのベンダーを試しました。 4kランダム書き込みでわずか0.1MB /秒の投稿を見てきましたが、x-25mで24MB /秒の4kランダム書き込みが得られます。
Raid0。 2.0のキャッシュは永続的ではないため、冗長性について心配する必要はありません。これは再起動を傷つけますが、それらはまれです。再起動せずに、新しい構成をロードしたり、オブジェクトをパージしたりすることができます。
mmapモード。ワニスキャッシュは、ファイルにmmapするか、スワップスペースを使用できます。スワップの使用は私たちにとってうまく機能していません。同じ量のトラフィックを処理するためにより多くのI/O帯域幅を使用する傾向があります。 Linuxのswapinコードには4セクターの先読みがあります。これを削除するパッチを作成しましたが、本番環境では試していません。
期限スケジューラ。 2.6.28+では、これはssdに対応しており、良好に機能します。 noopを試しましたが、I/O帯域幅が制限されるため、期限がより公平であることがわかりました。
先読みを無効にします。回転遅延がないため、必要になる可能性があるという理由だけで追加データを読み取る意味はありません。 I/O帯域幅は、これらの点で貴重です。
2.6.28+を実行します。 Linuxの多くのスペースのmmapは、メモリマネージャーに良いトレーニングを提供しますが、分割lruパッチは大いに役立ちます。 kswapd cpuの使用量は、更新時に大幅に減少しました。
Vclファイルと、ニスで使用するいくつかのツールを リンクテキスト に投稿しました。 vclには、maxmindデータベースに基づく非常に高速なgeoiplookupサーバーを実装する巧妙なハックも含まれています。
SSDをHTTPキャッシュとして使用していませんが、次のことを確認できます。
すべてのSSDが同じというわけではないので、適切なSSDの選択には十分注意する必要があります。 FusionIOは、PCIeでバックアップされたSSDを作成します。これは、実際にはハイエンドのパフォーマンス(比較的容量が少ない)ですが、コストがかかります。 IntelのX25-ESLC SSDは非常に優れたパフォーマンスを発揮し、より手頃な価格ですが、それでも容量は少なくなります。あなたの研究をしてください! X25-E SLCバリアントは本番システムで使用しているので、間違いなくお勧めできます。
優れた連続読み取り/書き込み速度を提供するSSDは他にもありますが、キャッシュなどの重要な点はランダムIOであり、多くのSSDは回転ディスクとほぼ同じランダムパフォーマンスを提供します。 SSDでの書き込み増幅効果により、回転するディスクのパフォーマンスが向上することがよくあります。多くのSSDには低品質のコントローラー(古いJMicronコントローラーなど)があり、状況によってはパフォーマンスが大幅に低下する可能性があります。 Anandtechや他のサイトは、iometerなどのツールとよく比較しています。そこで確認してください。
そしてもちろん、SSDは小さいです。 Intel X25-Eは、私が見た中で最高のSATA SSDであり、32GBと64GBのバリエーションしかありません。
RAIDレベルの場合、標準のRAIDパフォーマンスノートが引き続き適用されます。 RAID 5への書き込みには、基本的に、変更するデータブロックの読み取り、パリティブロックの読み取り、パリティの更新、データブロックの書き込み、およびパリティの書き込みが含まれるため、他のRAIDよりもパフォーマンスが低下します。 SSDでもレベル。ただし、X25-EのようなドライブのランダムIOパフォーマンスが非常に高い場合、回転するディスクではランダムIOよりもパフォーマンスが優れているため、これはおそらくそれほど重要ではありません。同様のサイズのアレイの場合。
私が見たところ、少なくともシーケンシャルパフォーマンスに関する限り、RAIDコントローラーの帯域幅は7ディスクRAIDセットを最大限に活用するには早すぎます。 SATAコントローラーの現在のモデル(3ware、arecaなど)から約800MB /秒を超える値を取得することはできません。複数のコントローラー(たとえば、単一のRAID10ではなく複数のRAID1)にまたがる、より小さなアレイを使用すると、これが改善されますが、各アレイの個々のパフォーマンスは低下します。
HTTPキャッシュに関しては、まともな回転ディスクの配列と大量のRAMを使用したほうがよいと思います。頻繁にアクセスされるオブジェクトは、メモリキャッシュ(squidの内部キャッシュまたはOSのfsキャッシュ)に残ります。マシンにRAMを追加するだけで、これによりディスク負荷を大幅に減らすことができます。大容量のsquidキャッシュを実行している場合は、おそらく多くのディスクスペースが必要になりますが、高性能SSDの容量は比較的少ないです。
私はSSDドライブにあまり詳しくありませんが、私が使用したアーキテクチャの種類について話すことができます。これは、問題のいくつかを解決するのに役立つ可能性があります。
兄弟
私の場合、16GBのRAM)で4台のサーバーを構築しました。Squidが使用するメモリ内キャッシュとして9GBを設定しました。それらを兄弟のセットとして構成したため、1台のサーバーにクエリを実行します。データを探す前に他のサーバーにクエリを実行します。合計で36GBのメモリキャッシュがありました。4人の兄弟間の通信が途絶え始めたため、4人を超えることはありませんでした。
VIP
クライアントが通信する4台のサーバーにVIP)を構成しました。これにより、1台のサーバーがダウンしたときに何が起こるかが解決されました。
子供達
127.0.0.1で実行されているローカルSquidサーバーにクエリを実行するようにWebアプリケーションを設定しました。次に、このSquidインスタンスの親をVIPとして構成しました。これにより、VIP全体がダウンした場合に、非常に迅速なフェイルオーバーが可能になります。親が応答しない場合、子はサービスに直接クエリを実行します。単一のサーバーを使用している場合にも便利です。 Squidサーバーであり、VIPはありません。もちろん、Webサーバー上のローカルSquidインスタンスがダウンすると、すべてが停止します。
イカ自体
私は実際には3.0を見ていませんが、2.xはまだシングルスレッドです。ある時点で、CPUまたはTCPバッファが不足することになります。可能であれば、キャッシュを2〜3個少ないボックスに分散します。また、パーティションを作成する計画を立てることもできます。システムが成長しているのを見れば、将来的にはイカ養殖場になります。
いずれにせよ、SSDビルドで頑張ってください。将来はおそらくそのルートに行くので、どうなるか知りたいです。
RAID 10または5を検討しているのはなぜですか?ここでパフォーマンスが必要です。ドライブはキャッシュのみであるため、ドライブがダウンしただけでもかまいません。
RAID 0を使用するか、別々に保管してください。ドライブに障害が発生してもキャッシュ全体が停止するわけではないので、個別の方が良いと思います。