データセンターの仮想化および統合による ROI の最大化
ホワイトペーパー
|ホワイトペーパー|

データセンターの仮想化
およびエンドユーザー・
パフォーマンス管理を
通じた統合による
ROI の最大化

データセンターの仮想化およびエンドユーザー・パフォーマンス管理を通じた統合による ROI の最大化

データ・センターの統合に関する適用事例は、ネットワーク、アプリケーション、およびサービスがさらに複雑になり、ユーザーがさらにモバイル化し、企業がパフォーマンスを損なうことなくコストを削減する必要に迫られている状況において説得力があります。ただし、これらの恩恵を得るには、組織がパフォーマンス・メトリクスを綿密にチェックしながら、統合されたアーキテクチャを管理する必要があります。従来のパフォーマンス管理ツールには複数のプラットフォームが必要で、統合された環境の管理に必要な範囲、視点、およびタイミングが欠けています。アプリケーションが仮想化されるとさらに複雑さが増し、エンドユーザーの視点からパフォーマンスを測定することが難しくなります。

統合型データ・センターを効果的かつ継続的に管理することは、プロジェクトの投資収益率を向上する決め手となります。組織は、統合プロジェクトで必要な ROI を確実に実現するためには、全ての利害関係者 – 部門、IT およびエンドユーザーの視点からパフォーマンスを管理できるソリューションが必要です。

データセンターの統合を促進するもの

データセンターはますます、従来の分散型インフラストラクチャから統一されたサービス指向構造へと変遷しつつあります。適用事例には説得力があります。ネットワーク・インフラストラクチャ、アプリケーションおよびサービスが複雑になっている一方、移動の多いユーザーからの要求は厳しくなっており、滞在場所に関係なくあらゆるタスクの生産性を高めるネットワーク・パフォーマンスが期待されています。

同時に、困難な経済情勢により、組織は品質を犠牲にせずに資本と運営費を削減するよう強いられています。エンジニアは、全てのスイッチ、ルーター、サーバー、およびハイパーバイザーを最大限に利用する必要があります。データセンターの統合によって組織は、より高度なプロトコルと管理戦略を実装し、帯域幅使用量、ネットワークとアプリケーション両方のパフォーマンスを最大化できるようになります。これによってアプリケーション仮想化の機会も生じます – アプリケーションを物理サーバーから切り離し、さらなるメリットがもたらされます。

データセンターの統合がもたらすその他の利点
  • 管理する必要のあるサイトとアセットの数を減らすことでセキュリティを強化し、より高度なリスク軽減戦略の基盤を築く
  • 自動化を通してコンプライアンスを強化し、包括的な監査機能の実装を促進
  • ハードウェアとソフトウェアの要件、電力消費、設備と輸送の要件を減らし、資本と運営費を削減し、組織の二酸化炭素排出量を軽減
これらの目標を達成するために、サーバーが仮想化され、40 ギガビットのリンクをインストールして帯域幅が十分でないアプリケーションの統合をサポートします。これにより、ネットワーク・インターフェースのコストが吊り上がり、ケーブリング・インフラストラクチャの要求が高まります。

利益が最大になるように統合を計画

データセンター統合には潜在的利益がありますが、見込まれる投資利益率 (ROI) を達成するには、組織は適切な計画と評価を行う必要があります。変更は、生産ビジネス・アプリケーションのダウンタイムを最小限に抑えてシームレスに行う必要があり、その結果統合されたデータセンターは、より優れたパフォーマンスを提供し、プロジェクトの実装に必要となった時間と資本を正当化する必要があります。

ダウンタイムのコスト
データセンターのダウンタイム 1 分あたりの平均コスト 5,600 ドル
平均ダウンタイム時間 90 分
インシデントの平均コスト 505,000 ドル
データセンター全体障害(平均復旧時間 134 分)のコスト 約680,000 ドル
部分的なデータセンター停止の場合、平均 59 分、コストは約 258,000 ドル

出典:Ponemon Institute 20111

統合の利益を十分に享受し、出費につながるダウンタイムを避けるには、組織は明確なプロセスに従う必要があります。

  • 既存のネットワーク、アプリケーションおよびサーバーを徹底的に理解し、パフォーマンスのベンチマークテストを行う
  • 統合されたデータセンターに求められるパフォーマンス・メトリクスを設定する
  • 移行計画を立てる
  • 最小のダウンタイムで新しい動作環境への移行を実施する
  • 新しくなったアーキテクチャの監視と管理を行い、必要なメトリクスを達成していることを確認する

Forrester Research のアナリストによる調査によると、一般的に、統合プロジェクトは完了までに 18 ~ 24 か月かかります2。この期間、組織では、既存の動作環境を評価するのに必要なハードウェアとソフトウェアをスタッフに提供し、移行計画を立て、新しいアーキテクチャをネットワークに接続し、パフォーマンスを管理する必要があります。

明瞭なベンチマークテストは不可欠です。統合前と統合後のパフォーマンスのメトリクスなしに、組織は ROI を評価できません。事業部門所有者、IT および運用スタッフ、企業管理、エンドユーザーなど、全ての利害関係者への影響を調べる必要があります。アプリケーションを仮想化した場合、エンドユーザーの視点からのパフォーマンス測定はより難しくなります。

ベンチマークテストの実施における重要な領域は何でしょうか?Forrester が147データセンターの統合プロジェクトを完了した、または積極的に実施していた米国企業に、成功の測定に使用した上位 5 つのメトリクスを尋ねた結果、52% は運用コスト、それに続いてわずかな差で総所有コスト (44%)、節約した予算の割合 (38%)、アプリケーション・パフォーマンス対インフラストラクチャ費用 (35%)、および CPU コア当たりのパフォーマンス (34%) となりました。

統合プロジェクトの ROI を達成し、達成を実証するには、組織は次の 3 つの領域に対処する必要があります。レポート作成、パフォーマンス管理、人材本書の残りの部分では、 密接に連結しているレポート作成とパフォーマンス管理に焦点を当てます。

実装の課題

1. レポート
データセンターの統合により、以前は企業全体に分散していたリソースが共通のプールに集められます。その結果、独自のネットワーク、アプリケーション、サービスを管理、維持していた事業部門は、制御を中央チームに渡さなければなりません。

事業部門は実質的に、統合されたデータセンターの社内顧客になります。サポートを継続するには、各事業部門は、重要なアプリケーションが、自分たちが管理していた時以上あるいはそれと同様のレベルのパフォーマンスを発揮することを確信できる必要があります。これは、データセンターと事業部門間での内部的なサービス内容合意を確立することを意味します。アプリケーションの可用性や、デスクトップとデータセンター間のトランザクションに対するエンドユーザーのレスポンス・タイムなどのメトリクスは、定期的に収集、追跡、レポートして、事業部門所有者を確保しておくのに必要な証拠を提供します。

事業部門がネットワーク・パフォーマンスを気に掛ける理由

  • POS システムのパフォーマンスは顧客の維持/損失に影響しますか?顧客の 40% は、あるウェブサイトで 1、2 回嫌な経験があると、そのウェブサイトにアクセスしなくなります。
  • ニューヨーク、ロンドンまたは香港のディーリングルームでは、ネットワークの遅延による 1ms の待機時間が、各取引で 100 万ドルの違いを生み出すことがあります。
サービスレベルのメトリクスは使用率と請求にも必要です。事業部門所有者は、実際に使用したリソースに対してのみ支払うことを当然希望し、データセンターのコストを均等に分割して支払うことで、他の事業部門を支援することは望んでいません。したがって、レポート作成には、各事業部門が使用するすべてのネットワーク、アプリケーション、サービスの使用率評価とそれに対応するチャージバックを含むようにしなければなりません。

2.パフォーマンス管理
データセンター統合、および多くの場合それに伴うアプリケーション仮想化によって企業のアーキテクチャを合理化できますが、管理については複雑になります。より多くのサービスが仮想化されるにつれ、データセンターからデスクトップまでのアプリケーション使用率を単一画面で確認することがますます困難になります。これは、単一の物理サーバーが複数のマシンをサポートする場合があるためです。データベース・サーバー、アプリケーション・サーバー、電子メール・サーバー、プリント・サーバーおよびファイル・サーバーはすべて同じハードウェアを共有している可能性があり、ネットワーク、アプリケーション、サービスのパフォーマンスの追跡がますます難しくなります。

適切な管理ツールを見つけることは、もう 1 つの難題です。従来のパフォーマンス管理ツールの多くは、特定のアプリケーション、サービス、またはネットワークの地理的あるいは論理的な一部分のみに重点を置くため、サイロ型(縦割り型)のオペレーションで最も機能を発揮します。包括的な情報や複雑なパケット・キャプチャ・ツールがないと NMS 間に問題が隠れることがありますが、このアプローチは分散型アーキテクチャに好ましい場合があります。ただし、従来のパフォーマンス管理ツールとまだ統合していないアプリケーション仮想化管理ツールを追加することでサイロの数が大きくなった場合、このアプローチは統合されたデータセンターで問題を引き起こします。

この状況では、ネットワーク・エンジニアは、それぞれが独自の機能とユーザー・インターフェイスを持つ一連の異種のツールを使用しなければなりません。エンジニアは全体的な経験と専門知識を使って問題を特定、解決するために、情報の相互関連づけを手動で行う必要があります。

最良の場合のシナリオでは、パフォーマンス管理は分散型環境と同様に実施され、コロケーションの情報や人員の利用を避けられます。最悪の場合には、運営と IT チーム間の責任追及に終わり、異常解決の効率性が低下し、エンドユーザーと経営者間の問題が生じます。

これらの問題に対処し、統合の最大の可能性を引き出すには、組織はパフォーマンスとレポート作成の優れた管理方法を見つける必要があります。

パフォーマンス管理の統合

統合されたパフォーマンス管理ソリューションは、ネットワークのすべての側面に関する情報を、すべての関係者に提供します。これは、責任追及のない効果的な問題解決に役立つほか、SLA パフォーマンス、使用率および請求などのレポート作成と管理のメトリクスを計算するためのデータを提供します。

ただし、パフォーマンス管理は統合プロセスにおける最も難しいステップです。従来のパフォーマンス管理ツールは分散型環境向けに設計されており、統合されたアーキテクチャや仮想化アーキテクチャの複雑性に対応できません。アプリケーションのフロー・モニタリング、トランザクション・ビュー、パケット分析、SNMP ポーリングおよび Stream to Disc (S2D) アーカイブなどのツールは複数のプラットフォームを必要とするため、統合の長所が減少する可能性があります。

企業が必要としているのは、事業部門、IT、および最も重要なことにはエンドユーザーの観点から、ネットワーク、アプリケーション、サービスのパフォーマンスを正確に反映する情報を取得、統合、提示、保持できる、スケーラビリティ、広範さ、詳細さを兼ね備えたエンド・ツー・エンドのソリューションです。効果的に物事を実施するには、範囲、観点、タイミングの3 つの性質を備えていなければなりません。

範囲
従来のパフォーマンス管理ツールは 2 つのカテゴリに分けられます。一部のツールは高水準のアプローチをとり、データ収集と評価では表面的な部分に目を通します。こうしたツールは上級管理者と共有できるダッシュボードを生成し、全体的なパフォーマンスを追跡できますが、詳細な領域への可視性を提供せず、問題解決を支援しません。その他のツールは、より限定された深いアプローチをとり、ネットワークの特定のセグメントに焦点を当て、パケットをキャプチャし、個々のトランザクションを調べ、詳細なリアルタイムの分析を提供します。

理想的には、IT チームにはこれら 2 つのアプローチの組み合わせが必要です。フロー、トランザクション、SNMP データは全体的な体験を調べるのに役立ち、パケット分析と S2D 機能はトラブルシューティングやコンプライアンスを支援します。IT チームには幅広く深い分析が必要であり、長時間の手作業は避けなければなりません。

視点
従来のパフォーマンス管理ツールは、ツールが提供する情報と、ツールがその情報を提示する方法に限りがあります。

ネットワークやアプリケーションからの視点により問題の根本原因を特定して解決することができますが、特に事業部門所有者がサービス・レベルのメトリクスを必要とする統合型データセンターでは、これは必ずしも十分ではありません。

たとえば、内部または外部の顧客から許容できないレベルのアプリケーション・レスポンス・タイムの遅延が報告された場合、ネットワーク・エンジニアにとってその状況を確認するための最善の方法は、ユーザーの視点からネットワークを見ることです。これが可能になるのは、パフォーマンス管理ソリューションに上記の分析の幅と深さがある場合のみです。

タイミング
パフォーマンスの問題が発生した場合に、根本原因が素早く特定され、状況が迅速に解決されるのが理想的です。ただし、パフォーマンスが時間と共にゆっくりと低下したり、問題が断続的に発生する場合は特に、統合型データセンターの複雑性によってこれはより難しくなります。

ネットワーク・エンジニアは、時間をかけてネットワーク全体のすべてのデータソースから詳細なパフォーマンス情報を収集し、エンドユーザーの視点からその情報を提示する必要があります。これによってオペレーションと IT のスタッフはリアルタイム分析を実施し、離散点に遡って、断続的なエラー・レポートに関連する環境を評価し、相互に関連づけることができます。これは短期、中期、長期のパフォーマンス・ベースラインの開発もサポートし、偏差を特定して早期に対処することができます。

エンド・ツー・エンドのパフォーマンス管理ソリューションは、これらの 3 つの問題すべてに対処する必要があります。これは、最高 1 ミリ秒までの精度で、他のデバイスから収集されたフロー、SNMP データおよび情報を含む、すべてのデータの収集、統合、相互関係付け、調整を行う必要があります。このデータは、1 人のユーザーが構成可能なダッシュボードを通して表示する必要があります。これによって、パフォーマンスを測定し、問題を特定し、素早く解決することができ、また、ネットワーク最適化のサポートに必要な可視性が得られます。データセンターの統合前に適切なパフォーマンス管理ソリューションを実装することで、IT チームはパフォーマンスを最低でも維持し、理想的には統合プロジェクト後に改善することができます。

仮想化によりパフォーマンス管理に複雑性が加わります

アプリケーションの仮想化に特有の追加の抽象化レイヤーにより、パフォーマンス管理がより難しくなります。これは、サーバーとアプリケーションが密に結びついている従来の環境と比べて、利用できる物的証拠が通常少ないためです。

仮想ネットワーク・インフラストラクチャへ移行するには、ネットワーク・エンジニアは、サポートする物理スイッチやルーター数の少ない新しい構成方法や監視方法を採用する必要があります。仮想化によってシステムのセキュリティ・レベルが上がるのか下がるのかに関する議論も続いています。仮想環境内で 1 つのシステムが被害を受けた場合、他のすべてのシステムへのアクセスも許されることになるのでしょうか?さらに、物理トラフィックが 1 つのハードウェア・プラットフォームに集中すると、ケーブル配線インフラストラクチャにも大きな負担がかかります。このインフラストラクチャは、仮想化サービスを展開する前に、十分にテストし、認証する必要があります。

仮想環境内の可視性とセキュリティは、大きな懸念事項となっています。移行前、移行中、移行後に、SNMP、NetFlow、仮想タップを使用して、仮想化されたばかりのこれらのシステムの正常性、接続性、使用状況をモニターすることが不可欠です。プラットフォームによっては、ハードウェア・リソースをより効率的に活用するように、サーバーを自動的に移動および移行できるものもあります。これらの理由から、サーバーのインベントリーと場所をしっかりとモニタリングする必要があります。

仮想タップまたはトラフィック・ミラーリング・ポートを使用して、アプリケーションのトラフィックを監視、分析し、サーバーのレスポンス・タイムや不規則な動作を確認する必要があります。IT 組織内でも他のシステムと比べて比較的新しいため、仮想化は、問題が発生したときに最初に原因を疑われる傾向があります。このため、1 日 24 時間週 7 日のモニタリング・ツールを配置してすばやく問題を特定し、問題が物理ネットワークまたは仮想環境にあるのかを判断する必要があります。

仮想化 Citrix 環境にあるアプリケーションにアクセスする際は、ユーザー・エクスペリエンス管理に関する特定の課題があります。この環境はますます複雑さを増しているため、ユーザーから多層のアプリケーション構造まで、トランザクション全体を監視し、ベースラインを作成し、管理する必要があります。これを理解するには、Citrix がどのようにアプリケーションのアーキテクチャを変更するのかを理解する必要があります。

VDI (仮想デスクトップ・インフラストラクチャ) セッションに入ると、ユーザーは、管理者によって定義、構成された特定サービスへのアクセスを構成された仮想セッションをホストする Citrix XenDesktop/XenApp サーバーと連動します。これらの権利は、多くの場合 Active Directory との外部やり取りに依存します。これは、Citrix アクセス・ゲートウェイ (高度なアクセス制御ウェブサーバー) が別のリクエストのクライアントになる個別のトランザクションです。ユーザーはここから、Citrix ソリューションとのセッションへのアクセスを得ます。このセッションは主として「スクリーン・スクレイプ」、つまりトラフィックのエミュレーション層です。

ペイロード内には、エンドユーザーが仮想デスクトップとやり取りする方法に関する補足的な洞察があります。これらのやり取りによって Citrix サーバーの後続のアプリケーション層にトランザクションがさらに生成されることになり、確立されたサービス・アーキテクチャ内の標準的な n 層アプリケーションの相互作用に対するクライアントとして機能します。

ユーザー・トランザクションの受け渡しが行われると、アプリケーション・アーキテクチャのプロキシされた性質によって、トランザクションのエンド・ツー・エンドの関連付けが難しくなる場合があります。Citrix XenApp サーバーへの ICA トラフィックには、ユーザーおよびユーザー操作を示す情報が含まれていますが、これはペイロード内にネストされています。Citrix でバックエンド・アプリケーション・インフラストラクチャへのセッションが発生すると、関連付けを行うための現実的で唯一の方法は、時間をかけて、アクセスしたアプリケーションを利用することです。

つまり、ユーザーがヘルプデスクに電話をかけ、ネットワークがダウンしていると伝えた場合、実際には Citrix を通してホストされているアプリケーションの遅延が発生している場合があります。エンジニアが実際に発生していることを発見するには、最長で 1 時間かかることがあります。エンドユーザー・エクスペリエンスに影響を及ぼしている可能性があることを知るための唯一の方法は、ネットワークの観点からこれらのアプリケーションのパフォーマンス監視を実施することです。統合型環境では、これはエンドユーザーとデータセンター間のバックエンドでのトランスポートです。

VMware のソリューションなどは、仮想化環境とサーバーを監視するためのツールを提供しますが、エンドユーザー・エクスペリエンスとネットワークは監視しません。一方、NETSCOUT は、エンドユーザーからデータセンターまでを評価するソリューションを開発しました。これによってユーザーは、ユーザーの視点からネットワークで発生していることを理解できるため、問題をより迅速に特定し、解決できます。

これらのソリューションにはフロント層のパフォーマンスを視覚化する機能があります。これはサイトごとに集計されており、ユーザーごとの比較、ユーザーによるセッション内でのやり取りの表示、公開されたアプリケーションごとのパフォーマンス・メトリクスが含まれています。その後これは、標準的な n 層アプリケーション・アーキテクチャに対して Citrix 環境が生成したトランザクションと関連付けられます。これにより問題のトラブルシューティングの時間を節約できるだけでなく、ネットワーク・エンジニアは、このアプリケーション配信シナリオのパフォーマンス管理をより積極的に行うことができます。

参考文献;
1データセンターのダウンタイムのコストを理解する - Emerson Network Power&Ponemon Institute

2コスト分析と測定により、統合の成功を保証 - Forrester Research、January 2009。

 
 
Powered By OneLink