ティントリのオフィス内に、テクニカルマーケティングラボという施設があります。お客様にお見せするデモの基盤、新機能の検証、トレーニングなどの重要な活動のために必要な環境を用意します。このラボは、常に最大限のパフォーマンスが出せるようにしなければなりません。また、停電や災害などの不測の事態にも、早急に対応できるような体制を整えています。

何が起きたのか?

このラボをメンテナンスしている最中に、何かしら変なことが起きていることに気づきました。

ティントリのGUIには、あるVMに大きなレイテンシーが発生していると表示されていました。そして、そのレイテンシーの約半分は、ネットワーク遅延によって引き起こされたことを示していました。ただ、これがなぜ発生しているのかについては、以下の理由によって直感的にはわかりませんでした。

  • VMstoreレベルでのネットワークのスループット合計値がとても小さかった

  • 別のストレージネットワークがあるため、ストレージ以外のノイズがネットワークの負荷に影響を及ぼすことはない

  • 本来、夜間は環境が静かであると考えられる

原因は明らかにネットワーク上のデータトラフィックによるものでしたが、私が確認したVMstoreにあるVMから発生したものではなかったようです。

さらに調べてみると……

そして、vCenterを確認してみたところ、次のことがわかりました。

あるホストから多くのパケットが送信されていたことがわかりましたが、vCenterからではVMの特定はできませんでした。結局のところ、vCenterの情報はそれほど役に立ちませんでした。

細部に気を取られていたため、全体像を見ることができるTintri Global Center(TGC)の存在を忘れかけていました。TGCは複数のノードにまたがった、すべてのVMstoreのデータを統合して見ることができるため、インフラの全体像を俯瞰することができます。案の定、TGCにログインすると、すぐに原因がわかりました。

原因をTGCで把握

上のグラフは、複数のTintri VMstoreでサポートされているインフラの中にある、全549台のVMにあるスループットの合計を示しています。グラフ上のある点(赤線)をクリックすると、その時点のスループットに影響を与えているVMのリストが、上位順に並びました。結論として、最もデータを送信しているVMは、"SHARE2012"ということがわかりました。

結局、誰かがVM"SHARE2012"で実行されているIO-Meterを用いて、テスト目的で極端な設定を施していたのです。このVMはネットワーク全体に負荷を与え、別のVMstoreやESXiホストのVMの動きまでも遅くしました。複数のノードにまたがって状況を確認することができる、TGCならではの原因究明方法といえるでしょう。6月から無償提供を開始したTGCを、ぜひうまく活用してみてください。

Author

ティントリジャパン　技術本部長
村山雅彦

パートナー各社への支援とエンドユーザーへの製品・ソリューション紹介などプリセールスSE業務を担当。

※本コラムは、ティントリジャパンに掲載されたブログ記事より転載したものです。

(マイナビニュース広告企画：提供 ティントリジャパン)

[PR]提供：ティントリ