ソリューション

マクニカネットワークスが取り扱う製品で、皆様の課題を解決します

Splunkの基盤として仮想化環境は使えるのか?
コンバージドインフラストラクチャ製品であるNutanixを使ってパフォーマンス検証を実施

Splunkの基盤として仮想化環境は使えるのか?<br>コンバージドインフラストラクチャ製品であるNutanixを使ってパフォーマンス検証を実施

「マクニカラボ便り」は、ちょっとやってみたい検証や、このテクノロジー、こう使ってみたらどうなる?など、マクニカネットワークスのエンジニアが気になった製品や技術について、ディープな検証や評価を行い、面白かったら皆さんにも公開しようという、ちょっと気まぐれなコーナーです。

サーバ群とストレージ階層を単一の統合されたアプライアンスに集約した所謂コンバージドインフラストラクチャ製品であるNutanix Virtual Computingプラットフォームは、パフォーマンス面で最もボトルネックになり易いSANやNASを排除した環境である為、今日の仮想化環境の多様な要求に対しても、パフォーマンスを劣化させる事なく対応できる事が可能です。
また、各サーバにはハイパーバイザーがプリインストール済の為、複雑な構成になりがちな仮想化環境を簡単にかつ素早く構築する事が可能です。

【今回のチャレンジ】

データ分析プラットフォームであるSplunkの基盤としては、パフォーマンスを考慮に入れると仮想化環境はあまり適していません。その理由は、サーバとストレージを接続するSAN環境がボトルネックになる為、パフォーマンスを出す為には、SANまわりの設計や細かいチューニングが必要になります。また、当然ディスクの回転数や構成なども考慮に入れる必要もあります。
そこで、今回は細かい設計を気にする事なく、仮想化環境を構築する事ができるNutanix上にSplunk環境を構築して、ログの取り込み時のパフォーマンスと、検索スピードについて計測を行ってみました。

また、一般的な仮想化基盤としてサーバとストレージが分離した環境と比べてパフォーマンスに差が出るか比較しました。

この検証結果により、NutanixはSplunk環境の基盤として検討できるものなのかどうかを考察してみたいと思います。

Nutanixアーキテクチャ

Nutanixは、複数のノードから構成されるスケールアウト型クラスターで、標準的なハイパーバイザーを稼動させます。各ノードには、プロセッサー、メモリ、および、ローカルストレージ(SSDおよびSATA HDDで構成)が搭載されています。各ノードは、標準的なハイパーバイザーホストと同様に動作します。さらに、全ノードのローカルストレージは、Nutanix Distributed File System(NDFS)によって、1つのストレージプールとして仮想化されます。クラスター上の仮想マシンは、あたかもNASに対してデータを書き込むかのように、NDFSに対してデータを書き込むことができます。NDFSは、仮想環境向けに特別に設計されたもので、高度なデータ管理機能を提供します。データを実システムのローカル環境に保存することで、低コストで高いパフォーマンスを実現します。Nutanixは、数ノードから大規模なノード構成に至るまで、水平拡張に優れ、インフラに対する企業の要求に合わせて拡張することが可能です。

Nutanixアーキテクチャ

Google File Systemと同様の設計原理や技術を活用したNDFSは、ストライピング、レプリケーション、自動階層化、エラー検知、フェイルオーバー、自動リカバリーなどの技術を駆使することで、クラスターを構成する全ノードのストレージを1つのプールとして提供します。このストレージプールを、共有ストレージとしてVMに提供し、vMotion、HA、DRSなどに加え、業界先端のデータ管理機能をシームレスにサポートできるようにします。この高性能なスケールアウトアーキテクチャーに対するノードの追加は、プラグ・アンド・プレイ方式で実施することが可能で、必要な時にいつでも容易に拡張することができます。

Splunkとは

仮想化、クラウド環境への移行など、ITシステムが高度化・複雑化するにつれ、ITシステムから生成されるデータも増加、複雑化しています。
Splunkは、これらの様々なITシステムから生成されるデータの収集、検索、分析を行うために開発された「ITシステムのためのデータ分析プラットフォーム」です。
ITシステムから生成されるデータ(テキストデータ)をサーバ内に取り込みインデックス化して、そのインデックス化したデータをもとに検索、レポート出力、アラート処理を実効する事が可能です。また、これらの検索処理やレポート、アラートはリアルタイムでの処理も可能である為、システム安定稼働、障害発生時の迅速な原因特定、セキュリティインシデント調査、ビジネス活用など幅広い用途に活用いただくことが可能です。さらに、1台のサーバでは処理しきれないような大量のログデータの処理を、複数サーバで分散処理を実施する事により、高いパフォーマンスを発揮できる構成を組む事が可能です。

Splunkとは

検証の為の環境

ベンチマークツール

今回パフォーマンスの計測には、Splunk社が提供しているAppと呼ばれる公開テンプレートの中から、ベンチマーク検証用のAppである「SplunkIT」を使用しました。「SplunkIT」は以下の値を計測する事が可能です。

  • Throughput (KBps): スループット
  • Events per second (EPS): 毎秒のログイベントをインデックス化した値
  • Time to first event (TFE): 検索処理で最初に結果が返ってきた時間
  • Time to search (TTS): 検索処理で全結果が返ってきた時間

以下の値は、Splunk環境においての一般的な各計測値の許容範囲となります。Splunk環境を設計/構築する際には、この値がひとつの指標になります。

計測値 結果
Throughput (KBps) > 10,000
Events per second (EPS) > 20,000
Time to first event (TFE) < 5
Time to search (TTS) < 30

使用機材

  • ストレージ/サーバ: Nutanix NX-3450 x1 (NX-3050シリーズを4ノード構成)

製品仕様 1ノードあたりのスペック

プラットフォーム NX-3050
(4 Nodes per Block)
NX-3000
CPU Dual Intel Sandy Bridge E5-2670 processors, 16 cores/2.6GHz
ストレージ容量 SATA SSD 400GB×2, SATA HDD 1TB×4
メモリ 128GB
ネットワークポート 10GbE×2, 1GbE×2, 10/100 BASE-T RJ45×1
  • 10Gスイッチ: Juniper EX3300-24T

Nutanix

  • Version: 3.1.2

Splunk サーバ

  • OS: CentOS release 6.3×64
  • CPU: 8 vCPU
  • Memory: 8 G
  • Disk
    • 1×20GB (OS)
    • 8×500GB (Data)
      ※8個の仮想ディスクをLVMで1つの論理ボリュームとして使用
  • Splunk Version: 5.0

SplunkIT

  • Version: 2.0
  • Index サイズ: 50GB

検証環境の概要

検証環境1

Splunkサーバと、それに接続するテストクライアントを含めて全ての仮想マシンをNutanix上に構築しました。Nutanixの各ノードはJuniper EX3300-24Tに10GbEで接続しました。

  • ※今回の検証環境には、Splunk環境の他に普段の業務で使用しているテスト用のVMが各ノードに約20台程度同時に動いている環境で実施しました。
検証環境1

検証環境2

Nutanixの各ノードに対して、NetAppストレージをデータストアとしてNFS接続して、サーバとストレージがネットワークで接続された一般的な仮想化環境を疑似的に作成しました。検証環境1と同様に、Splunkサーバと、それに接続するテストクライアントを含めて全ての仮想マシンをNutanix上に構築しました。

  • ※NetAppストレージのスペック
    モデル:FAS2240A-4
    ディスク:SATA 2TB×24本
    ネットワーク:1G NICから2本接続してアグリゲート構成
  • ※Nutanixは検証環境1の機器と同様の為、Nutanix上にはSplunk環境の他に普段の業務で使用しているテスト用のVMが各ノードに約20台程度同時に動いている環境で実施しました。
検証環境2

パフォーマンス計測結果

1.Splunkサーバとテストクライアントを各1台、Nutanixの1ノード上で動作。

パフォーマンス計測結果

検証環境1 Nutanix

Splunk Avg(KBps) Avg(EPS) Avg(TFE) Avg(TTS)
1 16860.46 59698.00 2.02 17.56

検証環境2 Nutanix+NetApp

Splunk Avg(KBps) Avg(EPS) Avg(TFE) Avg(TTS)
1 15422.42 54902.16 2.22 18.42

2.Splunkサーバとテストクライアントを各4台、Nutanixの各ノードの4ノード上で動作

パフォーマンス計測結果

検証環境1 Nutanix

Splunk Avg(KBps) Avg(EPS) Avg(TFE) Avg(TTS)
1 15320.75 54612.59 2.05 17.19
2 16983.06 60346.63 1.99 16.78
3 16627.59 58758.80 2.10 17.29
4 17099.72 60184.33 2.04 17.34
総計
合計 66031.12 233902.35 N/A N/A
平均 16507.78 58475.58 2.04 17.15

検証環境2 Nutanix+NetApp

Splunk Avg(KBps) Avg(EPS) Avg(TFE) Avg(TTS)
1 15242.24 54092.259 2.02 19.24
2 15583.60 55346.36 2.01 18.87
3 15007.98 54298.70 1.96 17.35
4 15088.65 52987.45 2.05 17.46
総計
合計 60922.47 216724.76 N/A N/A
平均 15230.61 54181.19 2.02 18.23

3.Splunkサーバとテストクライアントを各8台、Nutanixの各ノードの4ノード上に2台ずつ動作

パフォーマンス計測結果

検証環境1 Nutanix

Splunk Avg(KBps) Avg(EPS) Avg(TFE) Avg(TTS)
1 11295.48 45148.01 2.08 16.15
2 12733.32 45801.13 1.95 16.35
3 12536.50 45066.54 1.99 16.63
4 12851.87 46869.26 1.92 16.47
5 12390.27 45146.55 2.10 17.457
6 12203.80 45269.69 2.00 17.24
7 11283.26 41524.01 2.12 16.81
8 12087.60 45577.99 1.92 17.19
総計
合計 97382.10 360403.18 N/A N/A
平均 12172.76 45050.39 2.01 16.78

検証環境2 Nutanix+NetApp

Splunk Avg(KBps) Avg(EPS) Avg(TFE) Avg(TTS)
1 9390.10 33488.00 2.14 16.40
2 7769.61 27552.16 2.08 16.45
3 7875.02 28033.57 2.10 16.44
4 7795.61 27676.68 2.08 16.58
5 7794.24 27617.57 2.08 16.50
6 7870.51 27962.60 2.11 17.41
7 9669.96 34542.66 2.15 16.44
8 7939.32 28127.12 2.09 16.52
総計
合計 66104.37 235000.36 N/A N/A
平均 8263.04 29375.04 2.10 16.59

考察/まとめ

今回の検証により、Nutanix環境にSplunk環境を構築する事で、仮想化環境であってもKBps/EPS/TFE/TTSの各値の基準値を上回る結果を出せる事が分かりました。また、Nutanix環境では、NutanixとSplunkの特徴の一つでもある分散アーキテクチャを利用して、インデックスサーバを増やしていく事により、ログ取り込みにおける処理を高いパフォーマンスを維持しながらスケールさせる事が出来そうです。

以下の表はNutanix単体(検証環境1)とNutanixにNetAppをデータストアとしてアタッチした環境(検証環境2)での、Splunkインデックスサーバの数を増やした際の結果のグラフです。1ノード上で2つのSplunkインデックスサーバを動かした場合には、検証結果1と検証結果2共に値は落ちています。

▼Avg(KBps)スループット

Avg(KBps)スループット

▼Avg(EPS) インデックスサーバへの1秒間あたりの取り込みイベント数

Avg(EPS) インデックスサーバへの1秒間あたりの取り込みイベント数

検証環境2のNutanix+NetApp環境では、スループットが一気に約半分程度の値に落ちています。これより、サーバとストレージ間のネットワークがボトルネックとなり、EPSの値も落ち込む結果となっている事が考えられます。このような環境で、Splunkインデックスサーバを増やしてログ取り込みのパフォーマンスを良くしようとして、1ノードに新たにVMを作成するか、あるいは新しくノードを追加してその上で新たにVMを作成しても、結果的にはサーバとストレージ間がボトルネックとなり、スループットがますます悪化してしまい、処理速度は落ちていく一方である事が予想されます。

考察/まとめ

検証結果1のNutaix単体の環境では、スループット値の落ち込みは検証環境2程ではない事から、EPSの値は単純に1ノード上で実行しているSplunkインデックスサーバのCPUリソース等のサーバパフォーマンスに影響を受けているようです。この環境でログ取り込みパフォーマンスを良くするには、ノードを新たに追加していき、さらにそのノード上でSplunkインデックスサーバを追加で動かす事により、ボトルネックとなっていたサーバとストレージ間のネットワークの影響を受ける事なくスケールさせる事が可能である事が言えるかと思います。

考察/まとめ

検証環境2のような一般的な仮想化環境においても、サーバとストレージ間のネットワーク環境の設計やチューニングを実施する事により、恐らくある程度はボトルネックも解消されるかと思いますが、その作業には非常に多くの時間がかかる事が予想されます。

しかしながら、Nutanixは4ノードの仮想化環境をわずか30分から1時間程度で構築する事が可能であり、かつノードを追加していく事でパフォーマンスを簡単にスケールさせる事が可能である事から、Splunk環境の構築はもとより仮想化環境の構築時間を劇的に短縮する事ができ、また高いパフォーマンスを維持しながら運用を継続していく事を可能とします。

以上の検証により、Splunk環境を仮想化基盤に構築する場合のプラットフォームとして、Nutanixが選択肢の一つとして検討できる製品である事が分かりました。

  • ※今回は検証のタイミングにより、Nutanixのソフトウェアバージョンは若干古いものを使用しています。今後最新版であるバージョン「NOS-3.5.2」以上での検証を実施して、結果については弊社ホームページのNutanixページ等で公開していきたいと考えています。

いつか見た景色 from Staff's Albums