Flashcache：初めての体験

多くの場合、ディスクサブシステムはサーバーパフォーマンスのボトルネックであり、企業は高速ディスクと特殊なソリューションに多額の投資を余儀なくされています。 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論理ボリュームを作成しました。

 # lvcreate -L 100G -n lv1 vg1 # mkfs -t ext4 /dev/vg1/lv1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このボリュームでフラッシュキャッシュをテストしました。

フラッシュキャッシュをインストールする

最近、フラッシュキャッシュのインストールが簡単になりました。現在、elrepoリポジトリにバイナリパッケージがあります。 これに先立ち、ユーティリティとカーネルモジュールをソースからコンパイルする必要がありました。

elrepoリポジトリを接続します。

 # rpm -Uvh http://elrepo.reloumirrors.net/elrepo/el6/x86_64/RPMS/elrepo-release-6-4.el6.elrepo.noarch.rpm
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Flashcacheは、カーネルモジュールと制御ユーティリティで構成されています。 インストール全体が1つのcodmandaになります。

 # yum -y install kmod-flashcache flashcache-utils
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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です。 ほとんどのユースケースに最適です。

キャッシュを作成します。

 # flashcache_create -p thru cachedev /dev/sda /dev/vg1/lv1 cachedev cachedev, ssd_devname /dev/sda, disk_devname /dev/vg1/lv1 cache mode WRITE_THROUGH block_size 8, cache_size 0 Flashcache metadata will use 335MB of your 7842MB main memory
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドは、ブロックデバイス/dev/vg1/lv1



のSSD /dev/sda



でcachedev



モードで動作するcachedev



というキャッシュデバイスを作成します。



その結果、device /dev/mapper/cachedev



が表示され、dmsetup statusコマンドにさまざまなキャッシュ操作の統計が表示されます。

 # dmsetup status vg1-lv1: 0 209715200 linear cachedev: 0 3463845888 flashcache stats: reads(142), writes(0) read hits(50), read hit percent(35) write hits(0) write hit percent(0) replacement(0), write replacement(0) write invalidates(0), read invalidates(0) pending enqueues(0), pending inval(0) no room(0) disk reads(92), disk writes(0) ssd reads(50) ssd writes(92) uncached reads(0), uncached writes(0), uncached IO requeue(0) uncached sequential reads(0), uncached sequential writes(0) pid_adds(0), pid_dels(0), pid_drops(0) pid_expiry(0)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、パーティションをマウントしてテストを開始できます。 マウントする必要があるのはパーティション自体ではなく、キャッシュデバイスであることに注意してください。

 # mount /dev/mapper/cachedev /lv1/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これですべてです/lv1/



ディレクトリのディスク操作はSSDにキャッシュされます。



別のLVMボリュームではなく、ボリュームのグループで作業する場合に役立つ可能性がある1つのニュアンスについて説明します。 キャッシュは、LVMグループを含むブロックデバイス上に作成できます。私の場合は/dev/md3



です。

 # flashcache_create -p thru cachedev /dev/sda /dev/md3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、すべてが機能するためには、ボリュームの検索を担当するLVM構成設定を変更する必要があります。 これを行うには、/ /etc/lvm/lvm.conf



ファイルでフィルターを設定します。

filter = [ "r/md3/" ]





または、LVM検索を/dev/mapper



ディレクトリのみに制限します。

scan = [ "/dev/mapper" ]







変更を保存した後、このLVMサブシステムを報告する必要があります。

 # vgchange -ay
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テスト中

私は3種類のテストを実施しました。

• さまざまなキャッシュモードでiozoneユーティリティを使用してテストします。
• 1および4ストリームでのdd
  
  
  
  による連続読み取り。
• 実際のサイトのバックアップから取得したさまざまなサイズの一連のファイルを読み取ります。

イオノテスト

このユーティリティはrpmforgeリポジトリにあります。

 # rpm -Uvh http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm # yum -y install iozone
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストは次のように開始されました。

 # cd /lv1/ # iozone -a -i0 -i1 -i2 -s8G -r64k
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この図は、順次書き込みおよび読み取り操作中にキャッシュをオンにするとパフォーマンスがわずかに低下することを示していますが、ランダム読み取り操作では、パフォーマンスが複数倍になります。 writeback



モードは、書き込み操作でも分離されます。

Ddテスト

順次読み取りテストは、次のコマンドで起動されました。

1つのスレッドで：

 # dd if=/dev/vg1/lv1 of=/dev/null bs=1M count=1024 iflag=direct
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

4つのスレッドで：

 # dd if=/dev/vg1/lv1 of=/dev/null bs=1M count=1024 iflag=direct skip=1024 & dd if=/dev/vg1/lv1 of=/dev/null bs=1M count=1024 iflag=direct skip=2048 & dd if=/dev/vg1/lv1 of=/dev/null bs=1M count=1024 iflag=direct skip=3072 & dd if=/dev/vg1/lv1 of=/dev/null bs=1M count=1024 iflag=direct skip=4096
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各起動の前に、RAMキャッシュをクリアするコマンドが実行されました。

 # echo 3 > /proc/sys/vm/drop_caches
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キャッシュされたマルチスレッド読み取りはSSDの最大速度に近い速度を示しますが、初めて実行するときは、キャッシュがない場合よりも速度が遅くなります。 これは、データストリームの戻りとともに、システムがソリッドステートドライブに情報を書き込む必要があるためです。 ただし、再起動すると、すべての情報がすでにSSDに記録され、最大速度で提供されます。

さまざまなファイルの読み取りテスト

最後に、さまざまなサイズの多数のファイルの読み取り時間の小さなテスト。 バックアップから数十の実際のサイトを取得し、それらをディレクトリ/lv1/sites/



に解凍しました。 合計ファイルサイズは約20 GBで、その数は約76万です。

 # cd /lv1/sites/ # echo 3 > /proc/sys/vm/drop_caches # time find . -type f -print0 | xargs -0 cat >/dev/null
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後のコマンドは、現在のディレクトリですべてのファイルを検索し、それらを読み取って、合計実行時間を同時に検出します。







ダイアグラムでは、「最初の読み取り」で約25％に達すると予想されるパフォーマンスの低下が見られますが、コマンドを再起動すると、キャッシュなしの操作よりも3回以上実行されました。

キャッシュを無効にする

キャッシングデバイスを削除する前に、パーティションをアンマウントする必要があります。

 # umount /lv1/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、ボリュームグループで作業した場合は、LVMを無効にします。

 # vgchange -an
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、キャッシュを削除します。

 # dmsetup remove cachedev
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

sysctlを使用して調整できる微妙なフラッシュキャッシュ設定については触れませんでした。 その中でも、FIFOまたはLRUキャッシュに書き込むためのアルゴリズムの選択、シーケンシャルアクセスのキャッシュしきい値などです。これらの設定を使用して、適切な作業条件に適合させると、パフォーマンスが少し向上します。



このテクノロジーは、主にランダム読み取り操作でその最大の利点を示しており、生産性の倍増を示しています。 しかし、サーバー上の実際の状況では、最も頻繁に使用されるのはほとんどランダムなI / O操作です。 したがって、最小限の投資で、ソリッドステートドライブの速度を従来のハードドライブの容量と組み合わせることが可能になり、リポジトリにパッケージが存在するため、インストールが簡単かつ迅速になります。



記事を準備する際に、開発者からの公式文書を使用しました 。これについては、 こちらをご覧ください 。



それだけです この情報が誰かに役立つことを願っています。 コメント、コメント、推奨事項を喜んでいます。 戦闘サーバーでフラッシュキャッシュを使用した経験、特にライトバックモードを使用した場合のニュアンスを学ぶことは特に興味深いでしょう。