HCIプラットフォーム上のデータベースの拡張性と統合率を評価する方法

  • 11 May 2022
  • 0 replies
  • 116 views

Userlevel 3

本記事は2020327日にGary Little氏が投稿した記事の翻訳版です。

原文はこちら

 

データベースの統合率をどのように測定しますか?

  • より多くのDBを統合することによってデータベース性能はどのように変化しますか?
  • CVMの実行は利用可能なホストリソースにどのような影響を与えますか?
  • クラスタの性能は理論的上の最大値の90%を達成できました。
  • CVMのオーバーヘッドはこのワークロードの5%でした。

 

テスト環境設定

評価の目的は、クラスタにデータベースワークロードを徐々に追加していくことでDBのパフォーマンスがどのように影響を受けるかを確認することでした。2つ目の目的として、データベースサーバーと同じホストで仮想ストレージコントローラーを動かすことによる負荷を測定します。Postgresデータベースでpgbenchワークロードを用いて1秒当たりの合計トランザクションを測ります。

 

クラスタ構成

  • 4ノードのNutanixクラスタにて、各ホストはソケットあたり20コアで構成された2つのXeon CPUを備えています

 

データベース構成

各データベースは下記スペックやソフトウェアで構成します

  • Postgres 9.3
  • Ubuntu Linux
  • 4 vCPU
  • 8GBのメモリ
  • pgbenchベンチマークは、”Simple”のクエリセットを実行します

データベースのサイズはメモリ内に収まるように調整します。IOではなくCPU/メモリのテストです。

 

テスト手順

1台のホスト上の1つのデータベースよりテストを行います。合せて40データベースになるまでクラスター上にデータベースを追加します。40のデータベースではそれぞれ4つのvCPUCPUバウンドのワークロードで構成され、クラスター上で160個のCPUコアをすべて利用します。

データベースはホストのDRAMメモリに収まるように構成しており、ベンチマークはCPUバウンドであり、可能な限り高速に実行されます。

 

結果

下記より4ノードクラスタ上で1-40台のデータベースを実行した際の測定結果をご覧ください。

40台のデータベースでCPUコアが飽和状態になるまで、パフォーマンスは4から160 CPUまでほぼ直線的に上昇し、明らかなボトルネックはありません。

 

4ノードクラスタでデータベースを1台から40台まで拡張する

 

完全なスケーリング  実際のスケーリング

それでは、クラスタにおける拡張性について上のグラフから何がわかるでしょう結果は良い? 悪い? それともこんなもんでしょうかシステムがどの程度拡張できたかを理解するには、つまりシステムに追加された新たなデータベースで同じ性能を提供し続けるために、測定結果を「理想的なスケーリングが行えるプラットフォーム」において期待される数値と比較します。

 

下表の「理想的なスケーリング」と書かれた列は、1 台のデータベース上で測定された数値を実行中のデータベース数にかけて算出してます。そうすることで、ワークロードがシステムにおいて飽和し始めるにつれて、計測値と「理想的な」値が乖離することがわかります。これは予測されることであり、主にユニバーサルスケーラビリティ法(USL)で説明されている効果によるものです

最大負荷 (40コアすべてビジーでは、「完全な」値が2560に対して、測定値は2194です。したがって、このシステムは理論上の最大値に対して85%を超えてスケーリングしており、とてもよい性能といえます。

 

DB数 総コア数 総コアの利用段階 実測
トランザクション/秒 (K)
理想的な拡張
トランザクション/秒 (K)
1DB 4 0.025 64 64
4DB 16 0.1 256 256
8DB 32 0.2 540 512
16DB 64 0.4 1045 1024
24DB 96 0.6 1540 1536
32DB 128 0.8 1957 2048
40DB 160 1 2194 2560

 

実測されたパフォーマンス 対 理想的なスケーリング

 

ストレージCVMオーバヘッドの測定

ワークロードを拡張するにつれて、CPU負荷が理想的なスケーリングから乖離してくることがわかります。このケースでは、DBワークロードそれぞれが完全に独立していても、共有のハイパーバイザーやCPUのスケジューラのもとでワークロードが実行される点が関係することが、USLからも理解できます。

 

更に起動してサービスを続けているCVMを考慮する必要があります。

オーバーヘッドを計算するために、性能が飽和するコアの割合を80%とすることにしました。それより低いと測定値が完全なスケーリング値に等しく、リソース競合がないことを示しています。80%を超えると共有リソースのために競合や干渉を管理するために性能が低下していくことがわかります。

80%の飽和状態では、「理想的な」値と「測定」値の差はおよそ5%です。測定値 (1957) / 完全な値 (2048) = 0.95

したがって160コアの場合、CVMでは160コアの5% (クラスタ全体で8コア、ホストあたり2コア消費すると予想できますが、実際にはこの構成環境ではCVM16 vCPUで設定されています。

 

CVMは 16 vCPUのうち 12% – データベースは 4vCPUのうち 98%

 

Prism上では、CVM16 vCPUと設定してますが、その割り当てられたCPUに対して(平均で)12%(2vCPU/コアしか使われてないことが確認できます。

 

結論

  • スケーリングは合計CPU容量の80%まで (理想的に)線形に拡張しており、主に  USL で説明される効果によるものです。
  • 実際のCVM利用状況はおおよそ2 vCPUであり、この例ではほとんどがCPUバウンドのワークロードです。
  • AHVハイパーバイザーは、CVMよりデータベースワークロードを優先的に処理しています。

 


This topic has been closed for comments