ソーラーウインズの小宮です。


今回はServer & Application Monitor(以下SAMで記載します)のEditionに含めている機能でApplication Stack(以下App Stackで記載します)の機能をご紹介したいと思いますが、その前に一度SolarWinds製品を一部ご紹介致します。

SolarWindsの製品は全部で30種類近くあります。その中でも比較的Web Consoleで可能なアプリケーションが数種類あります。

SolarWinds製品に関してはOrionと呼ばれるCore上にモジュール形式でアプリケーションが提供されます。ユーザはブラウザを介してOrionにアクセスすることでそれぞれのアプリケーションにアクセスすることが可能となります。

 

SolarWinds製品全般

左側のオレンジ部分についてはネットワーク関連の製品になります。真ん中から右のほうにかけて緑色になっている部分が今回App Stackの対象となるところになります。

(Firewall Securityに関しては現状Orionと完全に統合されていません)

  1. Server & Application Monitor 【SAM】(サーバハードウェアやアプリケーションのモニタリング)
  2. Web Performance Monitor 【WPM】(ウェブサーバのモニタリング)
  3. Storage Resource Monitor 【SRM】(ストレージのモニタリング)
  4. Virtualization Manager 【VMAN】(仮想化環境のモニタリング)

App Stackは主にサーバインフラ上で動作するアプリケーション環境などを全体的にモニタリングし、運用者に単一ビューで表示するものになります。詳細については後ほど説明致します。

 

統合化されたインフラ環境の管理

現状のインフラにおいて、物理・仮想問わず様々なインフラが存在し、その中にはアプリケーションも存在して無秩序な状態になっています。またインフラの管理者もサーバ・ストレージ・ネットワーク・仮想化とそれぞれ担当者がおり、その上アプリケーションの担当者もいます。このような状態の中で何か障害があった時にどのような形で切り分け作業を行っているでしょうか?おそらく各管理者が集まって、状況を確認しながら切り分け作業を行っていると思われます。そのようなことをしていると障害対応にも多くの時間が費やされ、運用業務だけで業務が終わってしまいます。

一般的なシステムの管理体系

 

たとえば、アプリケーション開発のプロジェクトを開始すると、インフラ担当者にプラットフォームを要求することがあるかと思います。アプリケーションの担当者はあまりハードウェアのことは詳しくないので、システムのスペックをだけをインフラの担当者に伝えてハードウェアを用意してもらいます。

その後開発プロジェクトが進みますが、アプリケーションのパフォーマンスが上がらない(もしくは遅い)といったクレームがあがりました。このままだとプロジェクトの遅延も予想されるためアプリケーションの開発者は自分達のパラメータに問題はないと思うのでインフラ側で何かおかしくないかインフラの管理者のほうで調べて欲しいと言われました。

インフラの担当者は数百台ものサーバやストレージを管理しているので、すぐにはその状況を調べるのは厳しいという回答しました。プロジェクトの進行もあることから管理者を集めて切り分けに関する打ち合わせをすることになりましたが、かなりの時間を費やすことになります。

 

問題発生時の対応(その1)

 

 

問題発生時の対応(その2)

 

無駄な打ち合わせを行わず障害が起きる前に、予兆を発見しその対策を事前に講じることを考えることで少しでも被害の軽減をすることができるかと思います。

App Stackは予兆の可視化を可能とします。

 

App Stackによるボトルネックの可視化

このようにインフラ側のどの担当者が運用端末すぐに切り分けができるような状況があります。その際にApp Stackを利用することで、一目でボトルネックになっている部分を可視化します。

では以下で画面イメージも含めてご説明致します。

 

■アプリケーションに関連するサーバ、ストレージなどの情報を瞬時に表示し、ボトルネックを可視化!!

App Stackは複雑化したアプリケーションのインフラで構成されている複数のレイヤを詳細に表示する。パフォーマンスや冗長性などの問題点の根源を明確にするためにインフラ全体を掘り下げて分析することによりインフラ環境を可視化したマップで表示します。

  1. どの運用担当者が見てボトルネック箇所がわかるように!
  2. 切り分けに時間をかけたくない!

このような悩みをお持ちの方はSAMおよびApp Stackなどが悩みを解決致します。まずはSAMの画面イメージをご覧ください。(画面は日本語表記しておりますが、製品は英語表記になります)

SAM(Server & Application Monitor)画面イメージ

Orion上部のアプリケーションタブをクリックするとSAMの画面が表示されます。Applicationサマリの中で“Troubleshooting with App Stack”という項目があり、下部に「GO TO APPSTACK」をクリックするとApp Stackの画面に遷移します。

App Stack画面イメージ

こちらがApp Stackの画面になりますが、まず左部分に環境の絞り込みを行うことができます。ステータス、表示名、アプリケーション名でフィルターをかけることができます。

右部分についてはSAMで監視できているそれぞれの項目が表示されています。それぞれの説明は以下の通りです。

  1. アプリケーション(SAMが監視できる範囲で情報が収集可能がアプリケーションを表示)
  2. トランザクション(個別のロケーションにアサインされたウェブブラウザのトランザクションを表示)
  3. ステップ(具体的なURLにナビゲートするために必要なアクションのコレクション)
  4. サーバ(SAMが監視できておるサーバハードウェア)
  5. ホスト(仮想化環境が動作しているハイパーバイザが載っているサーバ)
  6. バーチャルクラスタ(分散された複数のサーバにインストールされた仮想マシンで構築されている仮想クラスタ)
  7. バーチャルデータセンター(仮想化環境を統合的に管理しているデータセンター)
  8. バーチャルセンター(VMware環境下のvCenterに相当します)
  9. データストア(仮想マシンのデータが保存されているレポジトリ)
  10. ボリューム(論理的なドライブ WindowsなどではCドライブやDドライブに相当するところです)
  11. LUN(Logical Unit Number ストレージ内で管理されているデバイスのアドレスになります)
  12. NASボリューム(Network Attached Storageのストレージデバイス)
  13. Pools(ストレージプール)
  14. VServer(仮想ストレージサーバ 【仮想マシンではありません】)
  15. ストレージアレイ(ストレージ各社のアレイ)

右部分のそれぞれをオブジェクトに対して、初めに紹介した4つのモジュールがバックグランドで連携することにより、オブジェクトをクリックすることで選択したオブジェクトに関連するものだとがフォーカスされて見やすく表示されます。

まずはクリティカルのアプリケーションの一つにマウスを当ててみることにします。

マウスオーバーされたアプリケーション

マウスオーバーされたアプリケーションの詳細を確認すると、アプリケーションは問題あるもののサーバハードウェアは動作していることが確認できます。下部をみると平均Readのレイテンシ(遅延)が悪いような内容が見てわかると思います。

しかしながら、このサーバやストレージがどのハードなのかはここからではわかりません。そのため、このオブジェクトをクリックしてみることにします。

 

問題があるアプリケーションをクリック

左下にクリックしたアプリケーションの情報を取得しに行くプロセスが表示されます。このプロセスが終了したらこのアプリケーションに関連する情報だけフォーカスされます。

フォーカスされたオブジェクト

これらのオブジェクトを見ると、LUNのところでクリティカルの情報が表示されています。ここでLUNのクリティカルのオブジェクトをマウスオーバーします。

 

LUNをマウスオーバーした時の詳細情報

ここからわかることは対象ストレージのTotal Latencyが遅くなっていることです。この情報を見てオペレータはストレージの管理者に対してストレージのサイジングやRAID構成・iSCSI構成の見直しをお願いでき、予兆を確認することによりシステム全体の障害を防ぐことができます。(Arrayをマスクさせて頂きました)

App Stackを提供することにより、どのオペレータが管理画面を見てもボトルネックがわかることができます。それぞれのハードウェアで管理者を頼ることなくボトルネックを可視化することで障害の切り分けを迅速化し、障害における対応時間を短くすることが可能となります。

App Stackを導入して予兆を事前に発見しシステムの健全性を向上していきませんか?