Tech Sketch Bucket of Technical Chips by TIS Inc.

DRBD9の性能を検証してみた

Pocket

前回の記事 DRBD9の環境構築と新機能を試すではDRBD9の環境を構築して、一部の機能を試してみました。

今回は、DRBD9で実現した分散ストレージはどの位の読み書き性能であるのか、実際に検証した結果をご紹介します。 その後、機能面について前回の記事では紹介できなかった部分、DRBD9のマスターブランチにコミットされているDRBD9.1に向けた新機能についてご紹介したいと思います。

今回、使用しているDRBD9はStableではなく、開発中のブランチを用いていることに注意してください。

DRBD9の読み書き性能の検証結果

DRBD9で作成した分散ストレージボリュームに対して、ファイルのI/O、PostgreSQL(version 9.4.5)の実行トランザクション数について検証を行いました。

検証は、下記に示す3パターンの検証環境構成で行いました。

  • データのI/Oがストレージクラスタ外(DRBD client)から行われる時
  • データのI/Oがストレージクラスタ内から行われる時
  • ローカルストレージへ直接書き込む時(DRBDを使用しない)

今回行った検証は環境に応じたチューニングは一切行わずに、すべてデフォルトの設定で行いました。

DRBD9_性能検証構成

検証環境

  • OS = CentOS Linux release 7.1.1503 (Core)
  • Linux_kernel_version = 3.10.0-229.20.1.el7.x86_64
  • drbdmanage_version = 0.5.0
    • GIT-hash: c5f39e2511d40329ae66783e6476a6c41c273440
  • drbd_kernel_version = 9.0.0
    • GIT-hash: ece72f515db06d78f1603c452d38d1f943648eb4
  • drbd_utils_version = 8.9.4
    • GIT-hash: 13f1450d0aa5af7466977f4c8be77794817b578e
  • ベアメタルサーバ最大4台使用
    • CPU: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz
    • Memory Size: 48GB
    • SSD: 250GB
    • ストレージはRAID0を上記SSD2枚で構成している。

ファイルI/O

fio(version-2.2.8)を用いてファイルサイズ10GBの単一ファイルをを計測しました。指定したパラメータは以下の通りです。

  • sequential-write
  • sequential-read
  • random-write
  • random-read

fioの計測結果をグラフ化したものが以下の図です。 このグラフを見ると、クラスタ内からのI/Oは、DRBDを使用していないローカルストレージへのI/Oと比較して、性能低下が約1割程度にとどまっていることがわかります。特にsequential-readではローカルストレージとほぼ同じ読み込み性能が計測されています。 クラスタ外からのI/Oは、性能低下がクラスタ内の時よりも大きいです。それでも、3割程度の性能低下にとどまっていることがわかります。

file_IO

実行トランザクション数

PostgreSQLを分散ストレージ上で動かして、3分間の総実行トランザクション数を計測しました。 計測には、PostgreSQLに同梱されているベンチマークツールであるpgbenchを用いて、DBへの同時接続数を変えて調べました。

pgbenchの計測結果をグラフ化したものが以下の図です。

先ほどのファイルI/Oの結果と同様に、性能低下は大きくても3割程度にとどまっています。

トランザクション数

分散ストレージを使用していると、ストレージへの読み書きの性能がネットワーク帯域等によるボトルネックにより低下してしまうことが懸念材料に挙げられると思います。しかし、DRBD9はデフォルトの設定でも最大で3割程度の性能低下にとどまっているため、迅速に高いI/O性能を持つ分散ストレージを利用したい事例に向いていると思います。

機能紹介

前回の記事では紹介していなかった機能について紹介したいと思います。

ここからは、先ほどの環境とは別の以下の環境で検証を行いました。

検証環境

  • OS = CentOS Linux release 7.2.1511 (Core)
  • Linux_kernel_version = 3.10.0-327.4.4.el7.x86_64
  • drbdmanage_version = 0.91
  • drbd_kernel_version = 9.0.0
  • drbd_utils_version = 8.9.5
  • 仮想マシン2台を使用

複数ノードからの読み込みが特定条件で可能

複数ノードからのデータ読み込みが、特定の条件で可能であることがわかりました。 特定条件とは、クラスタ内にPrimaryがいない状態かつ、すべてのノードがRead-only でマウントしている時です。

上の条件以外では、どのような結果になるかを見ながら実際に試した結果をご紹介します。

クラスタ内にPrimaryがいる時

クラスタ内にPrimaryがいる状態では、別のノードから同じボリュームをマウントできません。 ここではtest1がPrimaryの時に、test2が通常のマウントを行うことができないことを示しています。

上のメッセージを見ると、read-onlyならマウントできそうですが、やはりマウントできません。 下の操作はmountする時に、-rオプションをつけることでread-onlyマウントを実行しようとしています。

クラスタ内にPrimaryがいない時

クラスタ内にPrimaryがいない状態で、read-onlyマウントを行います。すると、read-onlyマウントではPrimaryへの自動昇格行われていないことがわかります。

続けて、test2でもread-onlyマウントができるか確かめました。結果、test1,test2の2台からread-onlyマウントができることが確認できました。この状態から、test1,test2のどちらからでもデータの読み込みができることも確認できました。

ちなみに、test1がread-onlyマウントしている時に、test2が通常マウントを行うと、test2のマウントは強制的にread-onlyマウントになります。

このように、Primaryがクラスタ内にいなければ、read-onlymountで複数ノードからの読み込みができることがわかりました。 複数ノードからの読み込みのみができるということは、共有ライブラリ用のストレージなどに利用ができるかもしれません。

DRBD 9.1に向けて開発中の機能

satellite node

マスターブランチに追加されている9.1に向けた新機能として、satellite nodeがあります。 現在、DRBD9のクラスタは最大32ノードまでという台数制限があります。この制限は、control volume(実際に使われているボリューム名は.drbdctrl)でクラスタの情報を管理しているため設けられているそうです。

この台数制限を緩和するために、control volumeを持たない代わりに、control volumeを持つノードからクラスタの情報を受け取るsatellite nodeが実装されました。control volumeを持つノードは複数のsatellite nodeを好きなだけ持つことができ、32台という台数制限以上のノードを持つことが可能になりました。 また、satellite nodeの実装で、以下のようにノードが分類されました。

Control node
  • Control VolumeがローカルのLV(Logical Volume)にあるノード
  • データ格納領域があるノードは Normal Control node という。
  • データ格納領域がないノードは pure Controller という。
Satellite node
  • Control VolumeがローカルのLVに存在しないノード
  • Control nodeとTCP/IPで通信を行うことで、Control Volume内のクラスタ情報を受け取る。
  • データ格納領域があるノードは Normal Satellite node という。
  • データ格納領域がないノードは pure client という。
External nodes
  • Control Volumeは持たず、データ格納領域もなく、Control nodeと通信も行わないノード
  • クラスタの情報はscpなどで取得する。

以下の図のように、Control nodeは複数台のSatellite nodeを持つことができるため、DRBD9は必要な台数に応じたクラスタの拡張が可能になりました。

satellite_node

まとめ

DRBD9のI/O性能の検証を行いました。結果、チューニングを行わないデフォルトの設定でもローカルストレージへのI/Oと比べても、あまり変わらないI/O性能であることがわかりました。 使っていて新たに分かったこととして、Primaryがいない時ならば、複数ノードからread-onlyマウントができることがわかりました。ここから、適用できる事例が少し増えた気がします。 また、マスターブランチで実装中の機能としてsatellite nodeがありました。この新機能を使用することで組めるクラスタの台数が爆発的に増えました。これで、リソースが許す限り巨大なクラスタが組めるようになったと思います。

I/O性能が良いメリットを生かして、どのような事例に適用できるのか考えながら、DRBD9の今後の動向に注目していきたいと思います。

エンジニア採用中!私たちと一緒に働いてみませんか?