仮想化環境では容量管理が重要

適切なツールがなければ、IT サービスの最適化を実装するのは難しい場合があります。

汎用サーバーのサーバー仮想化は、企業組織で最も急速に採用されているテクノロジーの 1 つです。今日、従来の非効率的な「1 つの物理サーバーと 1 つのアプリケーション」モデルは、仮想サーバー間の共有リソース プールに急速に取って代わられつつあります。これにより、組織はデータセンター内の電力、冷却、床面積などのリソースを節約できるだけでなく、特定の物理サーバーの過剰プロビジョニングを回避することでコストを節約することもできます。仮想化テクノロジーはより柔軟なソリューションを提供し、企業は変化する実際のニーズに基づいてリソースを再割り当てできるようになります。

[[216735]]

サーバー仮想化の概念には確かに多くの重要な利点があります。しかし、人生の多くのことと同様に、そこには一つの側面だけがあるわけではありません。リソースの仮想化により、インフラストラクチャ スタックに新しい抽象化レイヤーが追加されます。このレイヤーにより、仮想化ソリューションはより柔軟かつ効率的になりますが、IT サービスの最適化もより複雑になります。要求が厳しく、パフォーマンスが重要なアプリケーションの場合、これは停止やサービス レベル契約違反につながる可能性があります。仮想化戦略を実装または更新するときには、この点に留意することが重要です。

この記事では、複雑な仮想環境で IT サービスを最適化する方法について読者と議論します。

サーバー仮想化が容量管理と IT サービスの最適化にもたらす課題について議論する場合、柔軟な仮想化環境を構成するメカニズムについて共通の理解を持つ必要があります。概念的には、次の 3 つのメカニズムが使用されます。

1. リソース仮想化: リソースをプールにグループ化し、ハイパーバイザーを通じて異なる仮想マシンに割り当てます。

2. 動的リソース スケジューリング: ハイパーバイザーには、現在の需要に基づいてリソースを自動的に割り当て、対応する仮想マシンにリソースを割り当てる機能があります。

3. シームレスな移行: 異なる物理サーバー間でリソースをスケジュールする機能があり、サーバー クラスターまたはサーバー ファームを大規模なリソース プールにします。

これらのメカニズムを使用することで、企業はコンピューティング環境における従来の容量管理の問題の一部を解決できます。 「物理サーバーごとに 1 つのアプリケーション」が標準であったコモディティ化されたプラットフォームの時代では、企業はピーク時のアプリケーション需要に対応しなければならないことがよくありました。通常の需要レベルがピーク時の需要レベルよりはるかに低い場合、ほとんどのリソースはほとんどの時間使用されません。さらに悪いことに、イベントの周期的な性質によっては、ピークは数週間または数か月に 1 回しか発生しない場合があります。仮想化環境では、ピーク使用時に必要な追加の動的スペースを、複数の異なる仮想マシン間および複数の物理ホスト間で共有することができ、これらはすべて仮想マシンで実行されているアプリケーションに対して完全に透過的です。ピーク時の需要を最適化することを目的とした管理アクティビティと組み合わせると、動的なリソース スケジューリングは、過剰プロビジョニングの防止に特に効果的です。

しかし、サーバーの仮想化と動的リソースによって、容量管理の必要性が完全になくなるのでしょうか?明らかにそうではありません。以下で説明します。

チャレンジ

典型的なサーバー仮想化プロジェクトは、簡単な部分から始まり、その後難しい部分へと進みます。まず、持続的なアクティビティ レベルが低いコモディティ アプリケーションを仮想環境に移行します。これらのコモディティ ワークロードは、パフォーマンスの低い古いインフラストラクチャ上で実行されることが多く、ほとんどのリソースは特にリソースを要求しない可能性があるため、パフォーマンスとサービス品質が初期段階で向上します。これにより、物理ホストの数を減らすことに重点を置いて、ワークロードを仮想サーバーに移行するという決定が確定しました。

最終的には、より簡単な作業がすべて完了すると、プロセスを続行してより複雑な作業負荷に取り組むことが自然になります。サーバー仮想化は長期的にはコストを節約できるはずですが、仮想化戦略を実装するには通常、新しいインフラストラクチャへの初期の先行投資が必要になります。多くの場合、企業の IT 部門は、合理的かつタイムリーな投資収益率を達成するために、これらの先行投資を多数のアプリケーションやサービス間で共有する必要がある状況に直面しています。これにより、電子メール、データベース、ERP システムなどのワークロードが増加します。これらはリソース消費の面で要求が厳しく、重要性の要件も高くなります。このようなアプリケーションでは、可用性とスループットが非常に重要です。ビジネスのコアプロセスをサポートしたり、顧客と直接やり取りしたりすることもあります。つまり、企業はこれらのサービスをどのように運用および管理するかについて特に注意する必要があります。現在および近い将来にわたって、ビジネスに十分な能力があることを確認します。

容量管理の重要な側面は、各ワークロードまたはアプリケーションを適切に特性評価することです。ワークロードを分析する際には、いくつかの側面が重要です。

リソースの使用率 - このワークロードはどのようなリソースをどの程度使用しますか?

オンラインまたはバッチ - ワークロードがオンライン形式で使用されるかどうか (この場合、個々のトランザクションの応答時間が重要になります)、またはバッチ形式で使用されるかどうか (この場合、全体のスループットがより重要になります)。

線形分布と指数分布 – 作業負荷は、強度が増すにつれてどのように変化するでしょうか?

ワークロードの安定性 – ワークロードは常に同じレベルのアクティビティを維持していますか、それとも時折アクティビティが急増しますか?

周期性とランダム性 — アクティビティのピークは予測可能なものでしょうか、それともランダムに発生するものでしょうか?

これらすべての情報を組み合わせたプロファイルにより、組織は特定のワークロードとリソース要件を管理する方法を適切に把握できるようになり、ワークロードの特性を理解するのに役立ちます。同じ物理リソース上で複数のワークロードを混在させ始めると、状況は少し複雑になります (これが、組織がそもそも仮想化を実装した理由の 1 つであると考えられます)。前述したように、動的リソース スケジューリングは、単一の物理ホスト内または複数のホスト間での容量要件の変化に対処するための単一のメカニズムとしてよく使用されます。しかし、リソース スケジューリングの効率性と実用性は、ワークロードの特性に大きく依存します。リソース要件が中程度のワークロード セットは、通常、異なるホスト間でバランスを調整したり移行したりするのが簡単です。しかし、より要求の厳しいワークロードと組み合わせ始めると、選択肢は突然大幅に制限されてしまいます。

かつてロンドンで開催された Gartner Data Center Summit で私が発表した例え話が注目を集めているようで、さまざまなワークロードを組み合わせようとしたときに発生する可能性のある問題を示しています。サミットでの講演では、さまざまなワークロード間の不規則性を象徴するためにテトリスのようなブロックを使用することを提案しました。リソース要求が中程度の単純なワークロードは、基本的な 2 ピースのブロックで表されます。リソース要件の増加と複雑さの増大により、ブロックチェーンはあらゆる方向に拡大することになります。

ブロックが大きくなるほど対称性が低くなり、統合が難しくなります。ブロックの組み合わせをリソース不足に変換できないワークロードは、別のホストに移行できません。突然、仮想化環境で柔軟性を実現するための 2 つの重要なメカニズムが使用できなくなりました。たとえ結合できたとしても、大きな非対称ブロックによって空白領域が断片化され、当初計算して計画したよりもリソース使用率が低くなる可能性があります。

動的なリソース スケジューリングとシームレスなワークロード移行に基づく仮想化環境のサービス最適化戦略では、完全なモビリティとワークロードの自由な混合のみが想定されています。しかし、多くの場合、これは単純すぎることがわかります。さまざまな「ワークロード担当者」がいるだけでなく、テクノロジーやビジネス環境によって課せられるその他の制約も影響する場合があります (専用または独自のハードウェア構成、契約上の義務、データ セグメンテーションに関するセキュリティ ポリシー、変更管理手順など)。

全体として、これは、企業全体の仮想化戦略を実装するには、より徹底したアプローチが必要であることを示唆しています。より要求が厳しく重要なワークロードを仮想化するには、パッシブなリソース スケジューリングとワークロード移行メカニズムだけでは不十分です。最適なサービス提供を確実に行うには、ワークロードの配置と移行戦略を展開する前に調査と分析が必要です。

オプションは何ですか?

ワークロードの容量要件と他のワークロードとの共存を予測するためのさまざまなアプローチは、大きく 3 つのカテゴリに分けられます。

評価する

この種のアプローチは、「常識」と過去の経験に大きく依存します。サーバー仮想化および統合ソリューションで選択されるアプローチは、多くの場合、事前に設定されたしきい値に達するまでワークロードを積み重ねることです。しかし、この分野で成功するためには、企業が以下の点を十分に理解する必要があります。

評価に関連する指標はどれですか?

これらのメトリックの正しいしきい値は何ですか?

企業はどのようにして世代や指標を超えてプラットフォームを標準化できるのでしょうか?

ワークロードが積み重ねられた場合の非線形パフォーマンスの変化をどのように説明すればよいでしょうか?

上記の情報のいずれかを企業が誤解すると、予測が不正確になります。

評価と品質予測は、確かな事実ではなく、意見と直感に基づいています。このカテゴリのツールは、プログラミングを容易にすることに重点を置いています。結局のところ、品質に関する予測は、上記の質問に対する答えに依存します。非線形成長などのいくつかの側面は、ほとんどの場合、対処されていません。

分析モデリング

ワークロードミックスのパフォーマンスを予測するもう 1 つの方法は、分析キュー ネットワーク ソルバーを使用することです。システムのキューイング ネットワーク モデルは、モデル ソルバーの分析を容易にし、キューイング遅延が発生する場所とキューイング遅延の程度を数学的に計算できます。モデルは、予測目的で使用される前に、サーバーが実際にどのように使用されているかについての実証的研究に基づいて調整されます。

サーバーのパフォーマンスに重要なすべてのオブジェクトは、システムを記述するモデルで表現されます。

モデルが構築されると、トランザクション密度を変えたり、モデル間でワークロードを移行したりすることで、さまざまなシナリオを評価できます。トランザクションの予測応答時間またはスループットにより、取り組みが成功したかどうかがビジネスに伝わります。キュー内で費やされる時間とシステム内で費やされる時間の相対的な差に焦点を当てることで、各トランザクション タイプに明示的なしきい値を設定する必要性を排除できます。この関係についての簡単な経験則により、企業は構成シナリオの状態について適切なアイデアを得ることができます。

このタイプの分析モデリングは、混合ワークロード環境を最適化するための予測可能で、迅速かつ繰り返し可能なプロセスを提供します。分析モデリングでは、結果の品質はそれを実行する個人にあまり依存しません。また、ワークロードが増加するとパフォーマンスが直線的に低下すると想定する一般的な間違いも回避できます。

包括的な負荷テスト

ここでの目標は、実際のシナリオにできるだけ近い合成トランザクションを作成することです。正しく実行するには、オペレーティング環境を注意深く調べてトランザクションと同時実行の適切な組み合わせを見つけ、それらのトランザクションに基づいて繰り返し可能なテスト ケースを開発し、運用環境と同じ機器で長時間のパフォーマンス テストを実行する必要があります (並列テスト環境への投資が必要になる場合があります)。さらに、組織では、各トランザクション タイプに対する応答時間に関する成功基準を定義する必要があります。

正しく実行すれば、負荷テストは高い精度を実現できます。しかし、ほとんどの場合、コストと長いテストサイクルは正当化されません。重要なサービスが稼働する前に、IT サービスの最適化作業を定期的に行うよりも、「一生に一度の」品質保証活動を実施する方が適切である可能性があります。

では、あなたの会社はどのアプローチを選択すべきでしょうか?最も重要なことは、容量管理のためのフレームワークの反応的なメカニズムに頼るのではなく、少なくとも実用的な戦略を持つことです。確立後、*** の選択は通常、さまざまなアプローチを組み合わせて行われます。重要なビジネス サービスを迅速かつ簡単に分析するリスクを負う余裕がないのと同様に、重要度の低いユーティリティ アプリケーションの分析に時間をかけすぎることは望ましくありません。さまざまな状況に合わせて適切な方法を選択できる包括的なツールボックスを用意することが重要です。

結論は

市販のサーバー仮想化ベンダーは、自社のプラットフォームに組み込まれたリアクティブ パフォーマンス管理テクノロジだけで、ビジネスで最高のパフォーマンスを実現できると信じ込ませようとしています。実際のところ、動的なリソースのスケジューリングや移行などのリアクティブ手法は役立ちますが、完全なソリューションではなく、必ずしも IT サービスの最適化が容易になるわけではありません。仮想化環境によって複雑さが増すと、システムから得られるすべてのものを確実に得ることがより困難になる可能性があります。

「十分に大きい」仮想リソース プールは簡単には実現できません。ホストするワークロードの特性に注意を払わないと、アプリケーションを過剰にプロビジョニングしたり、リソースが不足したりする可能性があります。

ワークロードが互いに効率的に実行されること（またはテトリスのような形状が互いに適合できること）を保証するには、本格的な分析が必要です。あるワークロードが別のワークロードに干渉して、不要なリソース競合やキューイングの遅延が発生するかどうかを知るには、基盤となるアプリケーションのリソース要件について十分な知識が必要です。したがって、特に重要なワークロードの場合、さまざまなワークロードをシステムに投入し、動的なリソースのスケジュール設定と移行によってすべてが迅速かつ効率的に統合されることを期待するのではなく、事前に慎重に分析を行うのが合理的です。

前述したように、事前の計画「評価」を通じて最適なワークロードの配置を実現するには、通常、事前に決められたしきい値に達するまでワークロードを積み重ねる必要があります。これは、データ センターを調査し、仮想化の可能性を特定するために利用できるほとんどのツールで使用される手法です。結果は安価ですぐに入手できますが、あくまでも概算値にすぎません。この見積もりだけでは、ビジネスが最適なパフォーマンスを達成することはできません。

分析モデリングは予測ほど速くも簡単でも安価でもありませんが、私たちの目的に非常に近いものです。 (「分析モデリング」とは、具体的には分析キューイング ネットワーク ソルバーを使用したモデリングを意味します。それほど複雑ではない分析数学モデルは、「推定」ツールと考える方が適切かもしれません。) 分析モデリングは、負荷テスト (またはシミュレーション モデリング) よりもセットアップが簡単で、推定よりも正確です。

合成負荷と基礎となるシステム構成が実稼働環境を代表するものであれば、「負荷テスト」は非常に正確になります。ただし、生産負荷とインフラストラクチャを一致させるには、より多くの時間と費用がかかります。ほとんどの場合、このテクノロジを使用して仮想化環境で IT サービスを最適化することは現実的ではありません。ただし、小規模なテストを実行し、分析モデルを使用して、より強力なシステム構成でより大きな負荷をかけた場合に何が起こるかを予測することは、有用な妥協策となる可能性があります。

要約すると、IT サービスの最適化のために、リアクティブなリソース スケジューリングとワークロード移行メカニズムに頼るだけでは不十分です。要求の厳しいアプリケーションをコモディティ サーバー仮想化環境で実行する場合、組織はさらに多くのことを行う必要があります。最も賢明な解決策は、事前に計画を立て、ワークロードが効率的に連携して実行できるように配置および移行戦略を設計することです。見積ツールは、単純なワークロードの臨時分析に最適です。負荷テストは、特に新しいアプリケーション ワークロードを展開するときに非常に役立ちますが、仮想化環境で実行される重要なアプリケーションを最適化するための最も包括的な手法は、キューイング ネットワーク リゾルバを使用した分析モデリングです。