仮想環境のトラブル、今まで見落とされてきた本当の原因とは？：サーバーには異常がないのに、レスポンスは低下！？
サービス事業者やユーザー企業の間で、サーバー仮想化にあらためて関心が集まっている。サーバー仮想化の浸透に伴い、ネットワークやストレージ管理をサーバー仮想化の技術の中に取り込もうとするトレンドが生まれた中で、これまで気付きにくかった課題が顕在化してきたためだ。19年にわたって「仮想化」を専門領域としてきたピー・ビーシステムズに、サーバー仮想化で「いま最も注目しなければならないポイント」を聞いた。
“テクノロジの境界線”でトラブルが多発
サーバー仮想化は多くの企業にコストメリットをもたらした。ハードウェア台数の集約、柔軟・効率的なリソース活用など、その利点をITインフラに生かすことは、今となってはもはや当たり前のこととなっている。
だが一方で、「原因がはっきりしないシステムトラブル」に見舞われることが増えてはいないだろうか。例えば、「業務アプリの画面遷移が遅くなった」「ログインに時間がかかるようになった」「バッチ処理が終わらなくなった」などだ。従来、こうしたパフォーマンスのボトルネックの発生原因は、ハードウェアの故障であったり、アプリケーションに内在するバグであったりすることが多かった。だが最近では、こうした現象に遭遇しても「どこに原因があるのか分からない」というユーザー企業が増えている。
ピー・ビーシステムズの松下幸史氏「その原因を探っていくと、テクノロジの境界部分でトラブルが起きていることが多いのです。例えば、サーバーとネットワークの間、サーバーとストレージの間です。こうした境界部分に問題があると、サイロ化した管理体制では気付くことが難しい。そこを調査して問題をつぶしていくためには、サーバー、ネットワーク、ストレージに対する横断的な知識・スキルが求められます。従って、それぞれの管理者、あるいはSIer担当者などが複数名集まり、問題を絞り込んでいく必要があるのですが、その結果、問題の特定・解決に時間がかかり、ビジネスにも支障が出てしまうケースが増えているのです」
こう話すのは、ピー・ビーシステムズの松下幸史氏だ。ピー・ビーシステムズは、仮想化システムを中心として、コンサルティングからシステム構築、サポートまでを手掛ける福岡県に本拠をおく企業。サーバー、ネットワーク、ストレージなどの技術を横断的に取り扱うことを強みとし、首都圏にも多くの顧客を抱えている。松下氏は、そうした問題の発生源になりがちな「テクノロジの境界線」とは、具体的には「サーバーとネットワークをつなぐブレードサーバーのインターコネクトスイッチや、サーバーとストレージをつなぐiSCSIスイッチなどです」と指摘する。
福岡県に本拠をおくピー・ビーシステムズはシステムを構成するさまざまな技術を横断的に取り扱っている技術者集団。その高いスキルには定評があり、首都圏にも多くの顧客企業を持つ「仮想化により物理サーバーの集約率が向上したことで、ネットワークがボトルネックになることが増えてきたのです。調べてみると、数百台という多数のサーバーのトラフィックがインターコネクトスイッチの少数のアップリンクに集約され、アップリンクの輻輳の影響が全サーバーに波及しているケースが多く見られます。iSCSIなども同様で、ストレージに大量のI/Oが発生し、帯域が足りなくなってボトルネックになっているケースが散見されます」
こうした“境界線上のトラブル”の原因特定が難しく、手間も掛かる理由は、前述した「サイロ化した管理体制」だけではない。
「仮想化技術が進展して、ネットワーク／ストレージ管理も仮想化ソフトウェア側の管理機能に取り込まれるようになってきました。そのため、ストレージに特化した専門スキルを持つパートナーや、ネットワークだけに強みを持つパートナーなどは、逆に知識が足りず、仮想環境を横断的に見られなくなっているケースも増えています」
この他、ハードウェア設計に起因するケースもあるという。例えばブレードサーバーのインターコネクトスイッチなどは、そもそも増設を前提とした設計になっていないことが多い。
「ブレードを足すことでコンピューティングリソースは増やせますが、インターコネクトスイッチのキャパシティについては後から見直されることはまれです。将来を見据えてポートを開けていても、そのポートを使うためにはシステム停止を伴う根本的な設定を変更する、つまりビジネスを止める必要があり、なかなか切り替えられないという事情もあります。こうした境界線上の問題、いわば“管理対象間のエアポケット”に問題が生じると、各管理対象に専門特化した体制であるほど見落とされやすいといえます」
原因特定の鍵となる「鳥の視点」と「アリの視点」
では、こうした問題を解決するためには、どのようなアプローチが有効なのだろうか？ ピー・ビーシステムズの経験を基に、典型的な二つの問題事例と解決のアプローチを聞いた。
一つ目は、先のインターコネクトスイッチやiSCSIのように、「トラフィックが集中しがちな個所でありながら、物理ネットワークの監視ツールや、仮想化ソフトの監視ツールなどでは見つけられない個所」がボトルネックになるパターン。
「ハイパーバイザーの監視ツールから見える部分については、そもそもキャパシティプランニングがきちんと行われていたり、サーバー管理者が監視していたりしています。注意すべきは、そうした監視ツールでは状況を把握できない“目に見えない部分”です。具体的には、トップオブラックスイッチやコアスイッチなど、物理ネットワークの接合点、ラックを横断する個所がポイントになります」
「気付きにくい箇所が事前に分かるのなら、普段からそこに気を付けておけばいいのでは？」とも思える。だが前述のように、サーバー仮想化技術の中に、ネットワーク、ストレージ管理の技術が取り込まれてきたことがハードルとなる。例えば、ネットワーク管理者は物理スイッチのトラブルシュートはできても、インターコネクトスイッチや仮想化ソフトの中にある仮想スイッチになると、とたんに原因特定が難しくなってしまう、といった具合だ。
例えば、インターコネクトスイッチは、多数のサーバーのトラフィックが集中するためボトルネックになりやすい。また、データベーストランザクションなど重要で敏感な通信が遠回りとなっているケースも実在する。だが、仮想化ソフトウェアの管理機能だけではこれらの問題を検知することはできない《クリックで拡大》二つ目は、構築・運用時のキャパシティプラニングの目算が外れ、その修正も難しいというケース。例えば、iSCSIなどで1GBのNICを束ねて10GBの帯域を作っていたとする。設計時はiSCSI用に8GB、サービス用に2GBを発行していたが、実際の使用量は、iSCSIは3GBしか使っておらず、サービスは2GB全体を使い切ってしまっている。そのためにサービスに遅延が出ている、といった問題だ。
もちろんサービスで帯域リソースを使い切る前に、iSCSI用に確保した帯域を空ければいいのだが、そもそもサービスで帯域が不足していることが分からない。また、それが本当にリソースを割いて優先的にレスポンスを担保すべきサービスかどうかも判断できない。当初の目算が外れるだけでなく、リソースの最適化もままならないという問題だ。
「実際に、ある企業ではiSCSIで実装した仮想ストレージを運用していましたが、仮想マシンに負荷がかかった際に、SCSIコマンドに対して応答が遅くなるという現象に遭遇しました。同社ではネットワーク帯域を可視化するようなツールを導入していなかったため、弊社がSCSIコマンドのパケットをキャプチャして原因を特定しました」
「仮想環境のトラブルの多くは、“管理対象のエアポケット”で起こっている」と指摘する松下氏松下氏は、以上のような二つの典型的なケース――「仮想化ソフトの監視ツールでは見つけられない個所に問題が発生して、レスポンス低下の原因がつかめなくなるケース」と、「帯域リソースの実際の利用内訳が把握できず、レスポンス低下の原因がつかめなくなるケース」の解決策として、こうアドバイスする。
「こうしたトラブルシューティングには大きく二つの視点が必要です。一つはアプリケーションのパケットをキャプチャして帯域の使用状況を把握する“アリの視点”。もう一つは、システム全体を見渡しつつ、平常時や過去の帯域使用状況との違いなども把握する“鳥の視点”です。具体的には、SNMPによる監視だけではなく、フロー監視ツールを組み合わせて監視することが、レスポンスの堅持とスピーディな問題解決の大きなポイントになります」
「フロー監視ツール」は、「フローコレクター」とも呼ばれ、NetFlowやsFlowなどのフロープロトコルに対応したネットワーク機器から得られるフロー情報を蓄積し、帯域使用状況を可視化するGUIを持つツールだ。
フロー監視ツールでトラブルの早期対処を
では、なぜフロー監視ツールを組み合わせることがポイントになるのか？ それは上記のような“アリの視点”と“鳥の視点”の両立は、仮想環境が浸透した今となっては、人手で行うことが難しくなっているためだ。
「トラブルシューティングには、下から攻める方法と、上から攻める方法があります。前者は“アリの視点”で、起こった事実・状況を一つ一つ整理していき、事実から考えられる仮説を立てて、検証を繰り返して原因を絞り込んでいく方法。後者は“鳥の視点”で全体を見渡して、ある程度、原因個所を推定してから、その個所に詳しいエンジニアがフォーカスして調べる方法です。しかし物理・仮想の混在環境になったことで、後者は難しくなり、前者に頼らざるを得ない状況にあります。その結果、原因特定にかなりの時間を要してしまうのです」
というのも、以前はトラブルがあれば、アプリケーションのログなどから痕跡を読み取ることができた。だが仮想環境では、仮想サーバーには異常がないのに、レスポンスが低下するというケースもしばしば発生する。そうなると物理環境も併せて調べなければならず、結局“アリの視点”でネットワークのパケットを逐一拾うことによってアプリケーションの挙動を調べる必要に迫られてしまう。つまり、“鳥の視点”を持つことが難しくなっているのだ。
「ここにフロー監視ツールを導入すると、物理・仮想の混在環境においても、“どこからどこまで、どのような内容のパケットが流れたか”を時系列で可視化できるようになります。つまり“アリの視点”と共に“鳥の視点”を持てることで、前述した『仮想化ソフトの監視ツールでは見えない部分』も含めてトラフィックを監視できるようになるのです。こうしたツールがあれば、『帯域の実際の利用内訳』も瞬時に把握可能となり、問題発生から解決までの時間を大幅に短縮することができます」
松下氏によると、「数週間かかっていた作業時間が、一気に数時間、数日レベルにまで短縮できた例もある」という。
また、継続的にネットワークのフローデータを取得することで、自ずとシステムの最適化にもつながるという。例えば、インターコネクトスイッチのフローデータを取得・可視化することで、物理サーバーをまたいだ仮想マシン間の密な通信を容易に発見することができる。これを受けて、管理者が仮想マシンを適切に配置し直すことで、物理サーバーの通信負荷を最小化するとともに、障害が重要なサービスには波及しにくい仮想マシンの配置に改善することなども狙えるというわけだ。
松下氏は、「サーバーの通信量に対して、ネットワークがボトルネックになりやすい状況は今後も続いていきます。また、サーバー、ネットワーク、ストレージといった“各管理対象間のエアポケット”が生じやすい体制も、当面は続いていくと見るのが現実的でしょう。そうした中では、物理・仮想の混在環境のトラフィックをリアルタイムで可視化し、“通信の量と質”を把握して横断的にシステムを監視することが、仮想化によってリソースを有効活用しながら、安定運用を堅持するための最大の鍵になるといえるでしょう」とコメントする。
ではフロー監視ツールには、より具体的にはどのような機能があるのだろうか。一般に、こうしたツールはその効用があまり理解されていない他、SNMP監視ツールに比べて高価なことも手伝い、導入を見送っている企業も少なくない。だが松下氏は、「トラブル原因が見えにくくなっている昨今の現状を顧みると、問題解決の時間を短縮する――すなわちビジネスの遅滞を最小限に食い止められる非常に有効なツールです」と力説する。
松下氏自身も使用しているフロー監視ツール、ゾーホージャパンの「ManageEngine NetFlow Analyzer」（マネージエンジン ネットフローアナライザー／以下、NetFlow Analyzer）の概要とポイントをまとめている。「サーバーには異常がないのにレスポンスが低下している」「横断的な監視ができず、どこに問題原因があるのか分からない」といった問題に一度でも遭遇したことがある方は、ぜひ参考にしてみてはいかがだろうか。
ゾーホージャパン「ManageEngine NetFlow Analyzer」とは？
ピー・ビーシステムズも利用しているNetFlow Analyzerは、SNMPに基づく監視だけでは捉えきれないネットワークトラフィックの詳細な状況を、フロー技術に対応するネットワーク機器と組み合わせて可視化するフローコレクターと呼ばれるソフトウェアだ。
本文中でも紹介したように、ネットワーク利用状況の分析やトラブルシューティングを大幅に効率化する。
特徴は大きく二つ。一つは「アプリケーションごとの負荷をグラフで可視化できること」。もう一つは「ドリルダウンにより障害の原因追跡が簡単にできること」。
前者は、「どこからどこまで、どのようなパケットが流れたかを時系列で把握可能とする」機能。これにより、普段は気付きにくいネットワーク利用状況の変化も、一目瞭然で把握できる。例えばSNMPツールでアラートを上げておき、アラートの原因究明のためにNetFlow Analyzerを使うといったSNMPとフロー監視を組み合わせた運用によって、効率的に問題原因を特定できる。
後者は、インターフェース単位、アプリケーション単位、フロー単位での原因究明を実現する機能。ネットワークの利用状況データをクリックして情報をドリルダウンしていくことで、問題がどこにあるかを効率的に調査可能としている。松下氏によると「ネットワーク管理に慣れていない人でも問題なく使うことができる」という。
この他、日本語でのヘルプやサポートが充実していることもNetFlow Analyzerの大きな特長だ。松下氏も「仮想化によって管理対象がオーバーラップしつつある中で、UIが分かりやすく、サポートも充実していることは、組織として使いこなす上で大きなメリットだと考える」とコメントしている。
価格は10拠点間のNetFlowやsFlowを監視する場合(サポート付き)で、年間17.8万円から。興味のある方は、以下の関連リンクから詳細を調べてみてはいかがだろうか。
Copyright © ITmedia, Inc. All Rights Reserved.
提供：ゾーホージャパン株式会社
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2014年11月28日
ITmediaはアイティメディア株式会社の登録商標です。