多くの場合、ディスクサブシステムはサーバーパフォーマンスのボトルネックであり、企業は高速ディスクと特殊なソリューションに多額の投資を余儀なくされています。 SSDは今日ますます人気を集めていますが、従来のハードドライブと比較すると依然として高すぎます。 ただし、SSD速度とHDD容量を組み合わせるように設計された技術があります。 これらは、SSDのディスクキャッシュがギガバイトの場合のキャッシュテクノロジーであり、HDDキャッシュまたはコントローラーのメガバイトではありません。
そのような技術の1つは、独自のデータベースで使用するためにFacebookによって開発されたフラッシュキャッシュであり、現在はオープンソースです。 私は長い間彼女に注目してきました。 最後に、SSDドライブをシステムドライブとして自宅のコンピューターに入れることに決めたときに、テストする機会を得ました。
そして、SSDをホームコンピューターに入れる前に、サーバーに接続しましたが、サーバーはテスト用に無料であることが判明しました。 次に、CentOS 6.3にフラッシュキャッシュをインストールするプロセスを説明し、いくつかのテストの結果を示します。
4台のWestern Digital Caviar Black WD1002FAEX SATAディスクがソフトウェアRAID10、2つのXeon E5-2620プロセッサ、および8 GBのRAMに統合されたサーバーがあります。 ソリッドステートドライブの選択は、容量が90 GBのOCZ Vertex-3で決まりました。 SSDは6ギガビットSATAポート、ハードドライブ-3ギガビットポートに接続されます。 SSDドライブは
/dev/sdaとして識別されました。
実験のために、
/dev/md3 RAIDデバイスに未割り当ての大きなディスク領域を
vg1 、
vg1という名前のLVMボリュームのグループと
vg1という名前の
lv1 LVM論理ボリュームを作成しました。
このボリュームでフラッシュキャッシュをテストしました。
フラッシュキャッシュをインストールする
最近、フラッシュキャッシュのインストールが簡単になりました。現在、elrepoリポジトリにバイナリパッケージがあります。 これに先立ち、ユーティリティとカーネルモジュールをソースからコンパイルする必要がありました。
elrepoリポジトリを接続します。
Flashcacheは、カーネルモジュールと制御ユーティリティで構成されています。 インストール全体が1つのcodmandaになります。
Flashcacheは、次の3つのモードのいずれかで動作できます。
- ライト
writethrough -読み取りおよび書き込み操作はキャッシュに保存され、ディスクへの書き込みはすぐに行われます。 このモードでは、データの整合性が保証されます。 writearound前のものと似ていますが、読み取り操作のみがキャッシュに保存されます。writebackは最速のモードです。読み書き操作はキャッシュに保存されますが、しばらくするとデータはバックグラウンドでディスクにフラッシュされます。 このモードは、サーバーの突然の障害や停電の場合にデータがディスクに書き込まれないリスクがあるため、データの整合性を維持するという観点からはそれほど安全ではありません。
管理のために、パッケージに3つのユーティリティ
flashcache_create 、
flashcache_load 、
flashcache_destroyが含まれています。 1つ目はキャッシングデバイスの作成に使用し、他の2つはライトバックモードでのみ動作して既存のキャッシングデバイスをロードおよび削除するためにそれぞれ必要です。
flashcache_create主なパラメーターは次のとおりです。
-pキャッシュモード。 必須です。 thru 、 around 、 backの値を取り、それぞれライトthru 、ライトアラウンド、ライトバックモードを有効にします。-sはキャッシュのサイズです。 このパラメーターが指定されていない場合、SSD全体がキャッシュに使用されます。-bはブロックサイズです。 デフォルトは4KBです。 ほとんどのユースケースに最適です。
キャッシュを作成します。
このコマンドは、ブロックデバイス
/dev/vg1/lv1のSSD
/dev/sdaで
cachedevモードで動作する
cachedevというキャッシュデバイスを作成します。
その結果、device
/dev/mapper/cachedevが表示され、dmsetup statusコマンドにさまざまなキャッシュ操作の統計が表示されます。
これで、パーティションをマウントしてテストを開始できます。 マウントする必要があるのはパーティション自体ではなく、キャッシュデバイスであることに注意してください。
これですべてです
/lv1/ディレクトリのディスク操作はSSDにキャッシュされます。
別のLVMボリュームではなく、ボリュームのグループで作業する場合に役立つ可能性がある1つのニュアンスについて説明します。 キャッシュは、LVMグループを含むブロックデバイス上に作成できます。私の場合は
/dev/md3です。
ただし、すべてが機能するためには、ボリュームの検索を担当するLVM構成設定を変更する必要があります。 これを行うには、/
/etc/lvm/lvm.confファイルでフィルターを設定します。
filter = [ "r/md3/" ]または、LVM検索を
/dev/mapperディレクトリのみに制限します。
scan = [ "/dev/mapper" ]変更を保存した後、このLVMサブシステムを報告する必要があります。
テスト中
私は3種類のテストを実施しました。
- さまざまなキャッシュモードでiozoneユーティリティを使用してテストします。
- 1および4ストリームでの
ddによる連続読み取り。 - 実際のサイトのバックアップから取得したさまざまなサイズの一連のファイルを読み取ります。
イオノテスト
このユーティリティはrpmforgeリポジトリにあります。
テストは次のように開始されました。
この図は、順次書き込みおよび読み取り操作中にキャッシュをオンにするとパフォーマンスがわずかに低下することを示していますが、ランダム読み取り操作では、パフォーマンスが複数倍になります。
writebackモードは、書き込み操作でも分離されます。
Ddテスト
順次読み取りテストは、次のコマンドで起動されました。
1つのスレッドで：
4つのスレッドで：
各起動の前に、RAMキャッシュをクリアするコマンドが実行されました。
キャッシュされたマルチスレッド読み取りはSSDの最大速度に近い速度を示しますが、初めて実行するときは、キャッシュがない場合よりも速度が遅くなります。 これは、データストリームの戻りとともに、システムがソリッドステートドライブに情報を書き込む必要があるためです。 ただし、再起動すると、すべての情報がすでにSSDに記録され、最大速度で提供されます。
さまざまなファイルの読み取りテスト
最後に、さまざまなサイズの多数のファイルの読み取り時間の小さなテスト。 バックアップから数十の実際のサイトを取得し、それらをディレクトリ
/lv1/sites/に解凍しました。 合計ファイルサイズは約20 GBで、その数は約76万です。
最後のコマンドは、現在のディレクトリですべてのファイルを検索し、それらを読み取って、合計実行時間を同時に検出します。
ダイアグラムでは、「最初の読み取り」で約25％に達すると予想されるパフォーマンスの低下が見られますが、コマンドを再起動すると、キャッシュなしの操作よりも3回以上実行されました。
キャッシュを無効にする
キャッシングデバイスを削除する前に、パーティションをアンマウントする必要があります。
または、ボリュームグループで作業した場合は、LVMを無効にします。
次に、キャッシュを削除します。
おわりに
sysctlを使用して調整できる微妙なフラッシュキャッシュ設定については触れませんでした。 その中でも、FIFOまたはLRUキャッシュに書き込むためのアルゴリズムの選択、シーケンシャルアクセスのキャッシュしきい値などです。これらの設定を使用して、適切な作業条件に適合させると、パフォーマンスが少し向上します。
このテクノロジーは、主にランダム読み取り操作でその最大の利点を示しており、生産性の倍増を示しています。 しかし、サーバー上の実際の状況では、最も頻繁に使用されるのはほとんどランダムなI / O操作です。 したがって、最小限の投資で、ソリッドステートドライブの速度を従来のハードドライブの容量と組み合わせることが可能になり、リポジトリにパッケージが存在するため、インストールが簡単かつ迅速になります。
記事を準備する際に、開発者からの公式文書を使用しまし
た 。これについては、
こちらをご覧ください 。
それだけです この情報が誰かに役立つことを願っています。 コメント、コメント、推奨事項を喜んでいます。 戦闘サーバーでフラッシュキャッシュを使用した経験、特にライトバックモードを使用した場合のニュアンスを学ぶことは特に興味深いでしょう。