PowerScale、Isilon OneFS: 「Isilon：IsilonでのHBaseパフォーマンス テスト（英語）」

概要

YCSBベンチマーキング スイートとCDH 5.10を使用して、Isilon X410クラスターで一連のパフォーマンス ベンチマーキング テストを実施しました。

CAE POCラボ環境は、OneFS 8.0.0.4以降の8.0.1.1 NFS大規模ブロック ストリーミング ベンチマークを実行している5つのIsilon x410ノードで構成されました。 これらのテストでは、理論上の集計最大値として、5~700 MB/秒の書き込み(3.5 GB/秒)と5x~1 GB/秒の読み取り(5 GB/秒)が予想されます。

(9)コンピューティング ノードは、CentOS 7.3.1611を実行しているDell PowerEdge FC630サーバーで、それぞれ2x18C/36T-Intel Xeon® CPU E5-2697 v4 @ 2.30GHz(512GB RAM)で構成されています。ローカル ストレージは、オペレーティング システムとスクラッチ スペース/スピル ファイルの両方に対してXFSとしてフォーマットされたRAID 1の2xSSDです。

また、YCSBの負荷を高めるために使用された追加のエッジ サーバーも3台ありました。

コンピューティング ノードとIsilon間のバックエンド ネットワークは10Gbpsで、NICとスイッチ ポートのジャンボ フレームセット(MTU=9162)です。

初期テスト

最初の一連のテストでは、全体的な出力に影響を与えるHBASE側の関連パラメーターを決定しました。YCSBツールを使用してHBASEの負荷を生成しました。この初期テストは、YCSBと4,000万行の「ロード」フェーズを使用して、単一のクライアント(エッジ サーバー)を使用して実行されました。このテーブルは、各実行前に削除されました。
 

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=family -threads 256 -p recordcount=40000000

hbase.regionserver.maxlogs - WAL(Write-Ahead Log)ファイルの最大数。この値にHDFSブロック サイズ(dfs.blocksize)を乗算した値は、サーバーがクラッシュしたときに再生する必要があるWALのサイズです。この値は、ディスクへのフラッシュの頻度に反比例します。

hbase.wal.regiongrouping.numgroups : WALProviderとして複数のHDFS WALを使用する場合、各 RegionServer を実行する必要がある先書きログの数を設定します。この数のHDFSパイプラインが作成されます。特定のリージョンに対する書き込みは、単一のパイプラインにのみ行き、RegionServerの総ロードを分散します。

この考え方は、可能な限り多くの書き込みを並列化することでした。そのため、CALの数を増やし、WALあたりのスレッド(パイプライン)の数を増やすことでこれを実現できます。前の2つのチャートでは、「maxlogs」128または256の特定の数値に対して、クライアント側からこの数値を実際にプッシュしていないことを示す実際の変更はないことを示しています。ファイルあたりの「パイプライン」の数が異なりますが、並列化の影響を受けやすいパラメーターを示すトレンドが表示されます。次の質問は、IsilonがディスクI/O、ネットワーク、CPU、OneFSを使用して「邪魔になる」場所です。Isilon統計レポートを見てみましょう。



ネットワークとCPUのグラフは、Isilonクラスターが十分に活用されておらず、より多くの作業を行う余地があることを示しています。CPUは > 80%で、ネットワーク帯域幅は3 GB/秒を超えます。



これらのプロットは、HDFSプロトコルの統計情報と、それらがOneFSによって変換される方法を示しています。HDFS opsはdfs.blocksizeの倍数で、256MBです。ここで興味深いのは、「Heat」グラフにOneFSファイル操作が表示され、書き込みとロックの相関関係を確認できる点です。この場合、HBaseはWALへの追加を実行しているため、OneFSは追加された書き込みごとにWALファイルをロックします。これは、クラスター化されたファイル システムでの安定した書き込みに期待されるものです。これらは、この一連のテストの制限要因に寄与しているように見えます。

HBaseのアップデート

この次のテストでは、大規模に何が起こるかを調べた後、10億行のテーブルを作成し、生成に1時間かかりました。その後、YCSBを実行し、「workloada」設定(50/50読み取り/書き込み)を使用して1,000万行を更新しました。これは単一のクライアントで実行され、生成できる最も高いスループットも求めていました。これをYCSBスレッドの数の関数として実行しました。もう1つの注意点は、Isilonのチューニングを行い、データ ノード サービスのパフォーマンスを微調整したOneFS 8.0.1.1に進んだ点です。前の一連の実行と比較して、パフォーマンスの向上を確認できます。これらの実行では、hbase.regionserver.maxlogs = 256、hbase.wal.regiongrouping.numgroups = 20を設定します。

これらの実行を見ると、最初に明らかなのは、スレッド数が多い場合のフォールオフです。これがIsilonの問題か、クライアント側の問題かは興味を持っていました。これについては、今後の段落でさらにいくつかのテストが行われる予定です。しかし、3ミリ秒のアップデート レイテンシーで20万以上の < 運用を推進することは素晴らしいと言えます。これらのアップデートの実行はそれぞれ高速で、1つずつ実行できます。次のグラフは、これらの実行に対するIsilonノード間の均等なバランスを示しています。



ヒート グラフから、ファイル操作がWALプロセスの追加の性質に対応する書き込みとロックであることを確認できます。

リージョン サーバーの拡張

次のテストでは、Isilonノード(そのうち5つ)が異なる数のリージョン サーバーとどのように比較されるかを判断しました。前のテストで実行したのと同じアップデート スクリプトがここで実行されました。10億行のテーブルと1,000万行を「workloada」を使用して更新し、1つのクライアントとYCSBスレッドを51にしました。また、maxlogsとパイプライン(それぞれ256と20)についても同じ設定を維持しました。

 
結果は有益ですが、驚くものではありません。HBaseのスケールアウトの特性とIsilonのスケールアウト特性の組み合わせにより、more===betterが実現します。これは、お客様独自のサイジング演習の一環として、お客様の環境で実行することをお勧めするテストです。収益が低下する可能性がありますが、ここには5つのIsilonノードをプッシュする9台の高いサーバーがあり、さらに多くの余地があるようです。

クライアント数の増加

最後の一連のテストは、テスト中のシステムを破壊する深い暗い場所から行われます。結局のところ、テストが中断して呼び出されるまでテストを実行し、テスト対象のパラメーターの上限が何であるかを知ることは、完全に有効な科学的方法です。この一連のテストでは、クライアントの実行に使用できるサーバーを2台追加しました。さらに、2台のYCSBクライアントをそれぞれに実行しました。これにより、それぞれ512スレッド(全体で4,096スレッド)を駆動する6台のクライアントにスケールアップできます。40億行が600の領域に分割され、4億行が90の領域に分割された2つの異なるテーブルを作成しました。  

 



 

ご覧のように、このテストではテーブルのサイズはほとんど重要ではありません。Isilonヒート チャートを見ると、ファイル操作の数に何パーセントもの違いがあり、40億行のテーブルと4億行の違いがあります。

結論

HBaseは、主にスケールアウト アーキテクチャからスケールアウト アーキテクチャに対応しているため、Isilonで実行する場合に適しています。HBaseは独自のキャッシュを多数行い、HBaseを取得する適切な数の領域にテーブルを分割してデータをスケールアウトします。言い換えれば、独自のニーズを満たすのに適しており、ファイル システムは永続性のために存在します。負荷テストを実際に壊すところまで進むことができませんでしたが、HBase設計で40億行を検討し、3ミリ秒未満のレイテンシで80万回の運用を期待している場合、このアーキテクチャはそれをサポートします。HBase自体に適用できる無数のクライアント側の微調整についてあまり触れていなかった場合は、これらの調整はすべて有効であり、このテストの範囲を超えると予想されます。