クラウドコンピューティング資源仮想化技術の実装原理

クラウド コンピューティングというと、「仮想化技術によって実現される」という表現をよく目にしますが、クラウド コンピューティングの概念において、仮想化は非常に基本的ではあるものの非常に重要な部分であり、仮想化が最も重要な部分であることは容易に理解できます。クラウド コンピューティングの実現. コンピューティングの分離、スケーラビリティ、セキュリティなど、多くの問題の鍵となります。

クラウド コンピューティングの基本は仮想化ですが、仮想化はクラウド コンピューティングの一部であり、クラウド コンピューティングは複数のリソース プールを仮想化した後のアプリケーションです。多くの人は、仮想化はクラウド コンピューティングの小さな後押しにすぎないと考えていますが、そうではありません。仮想化自体に関しては、IT 分野で古くから広く使用されており、リソースごとにまったく異なる仮想化技術が存在します。

現在、仮想化には、サーバー仮想化、ストレージ仮想化、メモリ仮想化、ネットワーク仮想化の 4 種類があります。

業界には、サーバー仮想化の多くのアプリケーションがあります。サーバーの仮想化を使用して、サーバーの CPU、メモリ、ディスク、およびその他のハードウェアを一元管理し、一元化された動的なオンデマンド割り当てによってリソースの使用効率を向上させることができます。

ストレージ仮想化は、ストレージ リソースの論理ビューを物理ストレージから分離することで、システムのシームレスなリソース管理を提供します。ただし、ストレージの標準化の程度が低いため、使用するストレージ仮想化テクノロジーが異なるベンダーからのものである場合、互換性を考慮する必要があります。

メモリの仮想化とは、仮想化テクノロジを使用して、コンピュータのメモリ システムによるメモリの管理を実現することです。メモリ仮想化システムは、上位層のアプリケーションがメモリを継続的に利用できるようにし、物理層で複数のフラグメントを分割して、メモリの割り当てと必要なデータ交換を実現します。

ソフトウェアを使用してネットワーク電源を物理ネットワーク要素から分離するネットワーク仮想化には、他の形式の仮想化と共通点があります。ただし、ネットワーク デバイスとサーバーが異なる場合、通常、高度な I/O タスクの実行やデータ処理用の専用ハードウェア モジュールの必要性など、技術的な課題に直面します。

現在、クラウド コンピューティングはサーバー仮想化テクノロジをより多く使用していますが、仮想化テクノロジ自体はクラウド コンピューティングに役立つだけではありません。

1. 情報資源とクラウド資源の仮想化

1. 情報資源

1. 情報資源の紹介

情報資源は、社会の生産と生活に関連するあらゆる種類の情報だけでなく、使用して利益を生み出すことができるあらゆる種類のテキスト、数字、オーディオビジュアル、チャート、および言語の総称として定義できます。これには、データベース、文書ファイル、画像、オーディオとビデオ、および html などの構造化データ、半構造化データ、制度化されていないデータが含まれ、これらはすべて人々の生産および管理プロセスに関与する文書、資料、図表、およびデータです。の用語。管理の第一人者である John Naisbitt は、制御不能で整理されていない情報はもはやリソースではなく、インフォメーション ワーカーの敵であると主張しています。

2. 情報資源の特徴

ネットワーク環境において、情報資源は従来のローカル情報とは容量、搬送波、構造、分布、伝送方式、伝送範囲が大きく異なり、以下のような特徴があります。

1) 大容量情報と急速な変化

インターネット上には無数の情報が流通しており、手作業だけでは必要な情報を網羅的かつタイムリーに入手することはできません。または、最後に表示した情報リソースを表示したいが、それがどこにあるのかわからない。ネットワークの更新速度は比較的速く、管理者は既存のアクセス エントリを自由に変更または削除できるため、情報取得の制御がより困難になります。

2) 情報が広く分散され、構造化されている

インターネット環境では、情報が異なるサーバーに格納され、異なるデータ記述方法が使用されると同時に、各サーバーのオペレーティング システム、データベース、および文字セットが異なるため、ネットワークの情報リソースが複雑かつ多様になります。州。

3) 高度に統合された情報には統一基準がない

各情報サイトの情報は、情報管理者によって収集・整理されており、業界や時空を超えた特徴を持ち、幅広い範囲をカバーしています。また、各情報管理 Web サイトには、独自の情報表現と編成方法があります。たとえば、画像をファイル トランスポート プロトコル (FTP) で直接読み取って、ハード ディスクに保存したり、特定の文字コードでデータベースに保存したりできます。

4) さまざまな保存方法と送信方法

情報記憶媒体のほとんどはディスクとテープであり、ネットワーク ストレージも使用できます。インターネットを通じて、人々は電子メール、ネットワーク ダウンロード、携帯端末、オンライン チャット、ビデオなど、さまざまな方法で情報を入手できます。ユーザーは、家を出ることなく世界中を歩き回ることができます。

5) 強力なリアルタイム情報交換

バイナリ情報はインターネット上で急速に広まり、人々はインターネットを閲覧することでリアルタイムのニュースや身の回りの最新の変化を得ることができ、電子メールは人々のコミュニケーションの時間を短縮します。

3. 情報資源の編成

情報資源の構成は、大まかに次のように説明できます。

1) ファイルモード

トピック編成のアイデアを使用して、ファイル システムを介してローカルおよびネットワーク情報を編成および管理する簡単な方法。各ファイルには名前が付けられ、さまざまな情報を識別し、ネットワークを介して情報を共有するために使用されます。

FTP はネットワーク情報をこのように整理し、FTP と HTTP に基づくファイル サーバーに画像、ビデオ、オーディオ、プログラムなどの一部の非構造化情報を格納し、情報の閲覧やダウンロードなどの操作を実現します。ネットワーク情報に対する広範な需要と情報量の増加に伴い、情報を広める媒体としてのドキュメントの使用は不十分になりました。情報構造が複雑で、より多くのロジック関数が必要な場合、ファイル管理方法の効率が低すぎるため、この方法を情報管理システムの基盤となるファイル サービスとして使用して、他の機能を支援することができます。

2) データベースモード

データベースとは、データ構造に従ってデータを整理・保管・管理する倉庫であり、大量のデータを保管・管理することができます。データの整合性を維持し、データ共有を可能にします。ユーザーは柔軟にキーワードを設定し、クエリ条件を組み合わせて、最終的に一致するネットワーク情報を返すことができます. 効果的なクエリは、ネットワークの負荷を軽減します.

データベース技術に基づいて多数の情報システムが確立され、完全な情報管理モデルが形成され、ユーザーのクエリ効率とネットワーク サービス機能が大幅に向上しています。データベース方式の欠点は、構造化されていない情報を扱うことが難しく、情報の相互関係が直感的でないことです。さらに、複雑な情報単位の処理は非効率的であり、人間と機械の互換性は貧弱です。

3) ホームページ方式

ホームページ形式の情報整理とは、関連する部門や個人の詳細な情報を有機的に整理し、特定のインターフェースに表示することで、組織や人々をより包括的に紹介するものです。組織や個人は、インターネット上に自由にホームページを作成でき、具体的な内容は自由です。

4. 情報資源クラウドに対する仮想化の意義

情報資源クラウドは、クラウドコンピューティングの概念で構築された情報資源管理プラットフォームおよびサービスモデルであり、既存のインターネット資源の分散を変更する必要はなく、仮想化および情報資源統合の関連技術を使用して、情報資源を仮想化および統合します。 . また、知識レベルの編成と構築を行い、サービスの品質を保証して、ユーザーに安全で信頼できるオンデマンドの知識サービスを提供します。

ユーザーのストレージ環境が複雑になればなるほど、仮想化のメリットが明確になると言えます。具体的には、情報資源クラウドに対する仮想化の意義は以下の通りです。

  1. 仮想化により、リソースの表示、アクセス、および管理が簡素化され、これらのリソースに標準インターフェイスが提供されるため、ユーザーはそれらに透過的かつオンデマンドでアクセスできます。
  2. 仮想化は、ユーザー向けアプリケーションを最適化し、ストレージ関連の管理負担を軽減し、データ センターの移行、バックアップ、災害復旧、および負荷分散のためのより優れたモデルを提供します。
  3. 仮想化では、複数のマシンを仮想化して分離を形成することにより、さまざまなアプリケーションを実装できます。分離は、さまざまな競合を解決し、リソースの処理効率を向上させることができます。
  4. 仮想化により、ユーザーとリソース間の結合度が低下するため、ユーザーはリソースの特定の実装に依存せず、リソースの動的なスケーラビリティも強化できます。
  5. 仮想化は、低コストの設備を多数統合した上で、クラウド上で均一に優れたサービスを提供できるため、プロバイダーの開発コストとユーザーの使用コストを大幅に節約できます。
  6. 仮想化は、ユーザーがいつでもさまざまなビジネス ニーズを満たすためにオンデマンドで使用できる、弾力的にスケーラブルなアプリケーション アーキテクチャを確立するのに役立ちます。ユーザーが要求したホスト サービスは、迅速にプロビジョニングおよび展開でき (リアルタイムのオンライン プロビジョニング)、クラウド サーバー構成のオンデマンドの拡張または縮小は、数分以内に迅速に実現できます。

5. 情報資源検索の障壁

インターネット上には多くの情報があり、入手した情報すべてが役に立つわけではありません。ネットワーク情報の構造と表現方法の多様性、およびネットワークを検索する際のネットワーク ユーザーの習熟度はすべて、ネットワーク情報リソースのクエリに多くの障害を引き起こします.主な要因は次のように分析されます.

1) 表示端末のソフトウェアおよびハードウェア構成に関する各種要件

情報リソースの特性は、ローカルおよびネットワーク情報リソースのアクセス インターフェイスの多様性を直接決定します.ローカル ファイルは、ファイル マネージャまたはユーザー端末を使用してブラウズおよび表示できます.データベース リソースは、データベース クライアントまたはサードパーティのデータベース ディスプレイを介して表示できます.閲覧と操作:ネットワーク内のファイル情報や Web ページは、FTP や HTTP プロトコルの使用を含め、ブラウザを使用して閲覧できますが、これはユーザー エクスペリエンスの低下と管理の煩わしさにつながります。

2) 情報整理が標準化されておらず、氾濫している

ほとんどの情報は Web ページの形式で表示され、情報を公開する各 Web サイトには独自のルール セットがあります。Web サイトの検索エンジンの最適化 (検索エンジンの最適化、SEO) はすべて適切に実装されているわけではないため、キーワードの検索が困難になっています。情報は無秩序で必要な制約がなく、情報は外部リンクで複製され、検索結果で多数の繰り返しが発生します。ユーザーには多くの選択肢がありますが、エッセンスとドロスを区別するのは困難です。

3) 深刻な情報汚染

インターネットはあらゆる種類の情報で満たされた自由の王国であり、私たちは情報の海に深く入り込んでいます。さらに、大量の制御不能、虚偽、時代遅れ、さらには違法な情報が含まれており、情報リソースの質を低下させているため、情報の調査、分析、クリーニング、レビューがますます重要になっています。

2. リソースの仮想化

1. 3 種類のクラウド コンピューティング リソース

クラウド コンピューティングでは、リソースを物理リソース、仮想化リソース、サービス リソースの 3 つのタイプに分けることができます。

1) 物的資源

サーバー、ストレージ、ネットワーク、ルーターなど、クラウド コンピューティング プラットフォームのインフラストラクチャを指します。物理リソースは、直感的で比較的固定された構造で管理されます。ただし、規模と構造が比較的固定されているため、変化するサービス要件に対応することは困難です。

2)仮想資源(仮想資源)

インフラストラクチャ上で仮想化テクノロジによって生成される物理リソースの論理マッピングを指し、柔軟性と変更可能性が特徴です。仮想化テクノロジーのサポートに基づいて、管理者はリソースの規模と量を調整し、物理リソースを増やすことでプラットフォーム全体の仮想化リソースの総量を拡張できます。

3) サービスリソース

特定の機能を持つアプリケーション サービス ユニットを指し、サービス インターフェイスを呼び出すことにより、ユーザーはサービスの内部実装を気にすることなく、サービスがサポートする特定の機能を取得できます。サービス インスタンスは他のサービスから呼び出すことができ、複数の同一のサービス インスタンスを結合して負荷分散されたリソース プールにすることができるため、サービス インスタンスはリソース提供の形式と見なすことができます。

実際、リソースは特定の機能を提供できるサービスによって実現され、標準化された入力と出力を実現できます。ここでのリソースは、ディスク、CPU、メモリ、サーバー、ネットワーク、特別な機器などのハードウェアです。また、メール サービスや Web サービスなどのソフトウェアの場合もあります。

2. リソースの仮想化

リソースの仮想化とは、物理ハードウェア (電力、ディスク容量、CPU コンピューティング サイクル、メモリ、ネットワークなど) によって提供されるリソースを抽象化し、それらを論理アプリケーション (Web サービス、電子メール、ビデオなど) に提供する抽象化レイヤーの作成を指します。および音声)など)これらのリソースを使用するために。

多くの場合、リソースの抽象化には複数のレベルがあります.たとえば、現在業界で提案されているリソース モデルでは、仮想マシン、クラスター、仮想データ センター、クラウドなど、いくつかのレベルのリソースの抽象化が登場しています。リソースの抽象化は、上位層のリソース管理ロジックの操作のオブジェクトと粒度を定義し、インフラストラクチャ層を構築するための基礎となります。このリソースの抽象化の利点は、より優れた冗長性、柔軟性、およびサービス分離を提供できるため、ユーザーにより信頼性が高く強力なサービスを提供できることです。さまざまなブランドやモデルの物理リソースを抽象化し、それらをグローバルに統合されたリソース プールとして管理し、顧客に提供する方法は、インフラストラクチャ レイヤーで解決する必要があるコアな問題です。

別の観点から見ると、リソースの仮想化は、実際のリソースの内部属性、構造、および機能実現メカニズムのカプセル化、および仮想空間内の特定の形式でのそれらの機能のパフォーマンスを指します。仮想空間内の仮想化されたリソースは、ユーザーまたはアプリケーションに共通の呼び出しインターフェイスを提供します. このメカニズムにより、物理リソースに厳密にバインドされていないリソースを使用できますが、リソースのステータスや機能などの情報に従ってリアルタイムで動的にバインドできます. 物理リソース.

リソース仮想化テクノロジの難しさは、多くの場合、リソース使用率とサービスの信頼性および効率性のバランスを取ることにあります.大量のサービス要求には、多数のさまざまなリソースが必要です.限られたリソースを使用して、より多くのユーザー要求に対応するには、リソース使用率を可能な限り改善する必要があります.効率. たとえば、サービス QoS とサービス レベル アグリーメント (サービス レベル アグリーメント、SLA) およびその他の要件です。また、サービス応答の遅延、サービス取得コストなどを削減しながら、効率的で安定した信頼できるサービスを提供する必要があります。

さらに、さまざまなリソース間のクロス仮想化と、同じリソース仮想化テクノロジーのクロスプラットフォームの移植性も、リソース仮想化が直面する必要がある問題です。

3. 仮想化リソースと物理リソース間のマッピング

仮想化を仮想化すること(Virtualizing Up)と仮想化すること(Virtualizing Down)に分けて、前者は複数の物理リソースを基に単一の物理リソースよりも高い性能を仮想化リソースに提供することを指し、後者は物理リソースを解体することを指します。同時に、この物理リソースよりもパフォーマンスの低いリソース。

リソースの使用状況に応じて、プラットフォーム リソースは、コンピューティング リソース、ストレージ リソース、およびネットワーク帯域幅リソースの 3 つのタイプに分けることができます。

次の表は、3 つのリソースの仮想化の可能性をさまざまな形で比較したものです。

コンピューティング リソースは、CPU やメモリ リソースなどのデータ処理機能を提供することに注意してください。データ ストレージ機能は含まれておらず、コンピューティング リソースはステートレスです。ストレージ リソースはデータを保存するために使用され、複雑な論理演算処理機能は含まれません。データベース アプリケーションは、ストレージ リソースを使用してデータを記録し、コンピューティング リソースを使用してプログラム ステートメントを分析および実行する必要があります。 

3. 仮想リソースの特徴

ネットワーク仮想化環境における仮想リソースには、次の特徴があります。

1.異質性

ネットワーク仮想化環境の仮想リソースにはさまざまな種類があり、さまざまな機能があり、アクセス構成方法、ローカル管理システムの操作、および共有ルールは大きく異なります。ノード リソースには、コンピューター、ルーター、スイッチ、基地局、モバイル ハンドヘルド デバイスが含まれます。 .

リンクリソースには、光ファイバー、光波長、マイクロ波、ツイストペア、およびタイムスロットが含まれます; ネットワークリソースの異なる形式は仮想リソースの違いにつながり、仮想リソースの異質性は必然的に仮想リソースの管理と制御につながります. その管理は、これらの物理リソースの異質性を保護し、物理リソースの共有と使用を調整します。

2.分散

仮想リソースは地理的に分散されており、複数のインフラストラクチャ プロバイダーに属しています。この分散環境における仮想リソース管理は、単に分散した異種仮想リソースを結合することではなく、さらに重要なこととして、仮想ネットワーク要求に対するリソース割り当てとスケジューリングの問題を解決し、複数の仮想ネットワークを実現することで、リソースの調整と共有を行います。

分散異種仮想リソース環境では、リソース管理は、クラウド ユーザーに QoS 保証付きのクラウド サービスを提供するために、リソースのメンテナンスやリソースの構成などの操作も実装する必要があります。

3. 自律性

仮想リソースの異種分散特性は、リソース管理にも自律性をもたらします. 仮想リソースは、最初にインフラストラクチャプロバイダーに属し、インフラストラクチャプロバイダーは、仮想リソースの所有者として、リソースに対する最高レベルの管理権限を持ちます. つまり、自律的な管理機能があるため、自律性があります。

一方では、システム内のリソースを他の仮想ネットワーク ユーザーが使用できるようにするために、仮想リソースは、特定のポリシーと合意に従って、仮想ネットワーク ユーザーの統合管理と構成を受け入れる必要があります。したがって、仮想リソース管理では、さまざまなインフラストラクチャ プロバイダー間でリソースの共有とスケジューリングを実現し、リソース自律環境における権限、セキュリティ、課金管理などの問題を解決する必要があります。

一方、仮想リソースの移植性は、インフラストラクチャ プロバイダーがリソースの使用を最適化するためのより大きな柔軟性を提供します。インフラストラクチャ プロバイダーは、仮想ノードの移行、仮想リンクの移行、仮想パスの分割、および仮想パスの集約によって、リソースの移行を透過的に実装できます.たとえば、インフラストラクチャ プロバイダーは、独自の管理領域内の異なる物理ノード間で仮想ノードを移行します.仮想ネットワークを接続し、仮想ネットワーク トポロジの接続を確認します。

セキュリティと管理の容易さの理由から、仮想リソースの移行は、他のインフラストラクチャ プロバイダーやグローバル ネットワークにイベントを通知する必要なく、インフラストラクチャ プロバイダーの管理ドメイン内で行う必要があります。

4. スケーラビリティ

将来のネットワークは大規模なグローバル ネットワークであり、インフラストラクチャはさまざまなプロバイダーによって提供されるため、ネットワーク仮想化リソース管理アーキテクチャの設計では、下位層が競合する複数のインフラストラクチャ プロバイダーで構成されるという問題を考慮する必要があります。

ネットワーク仮想化環境ではスケーラビリティが重要な要件となりますが、設備構築の必要性から、既存のインフラ事業者は新たなネットワーク機器リソースを追加してネットワーク規模を拡大します。一方、ビジネス拡大のニーズにより、仮想ネットワークは新しいインフラストラクチャ プロバイダーにまたがる可能性があり、新しいインフラストラクチャ プロバイダーを管理フレームワークに含める必要があります。リソースの拡大とビジネスの拡大は、候補リソースのセットの拡大に​​つながるため、リソース管理システムはスケーラブルである必要があります。リソース情報を適時に更新して、仮想ネットワークの拡張とメンテナンスを完了します。

5.ダイナミック

ネットワーク仮想化環境では、仮想リソースが動的にシステムに参加したり、システムから離脱したりできます. 特に無線ネットワーク環境では、リソースの場所、サービス提供能力、および負荷が時間とともに動的に変化し、機器の物理的な障害も発生する可能性があります.リソースにアクセスできなくなります。リソースが動的に変化する場合、仮想ネットワークによるリソースの継続的な使用と、仮想ネットワークのサービスが途切れないようにするための仮想ネットワークトポロジの継続的な接続関係をどのように維持するかが、仮想リソースで解決する必要がある問題です。管理。

要約すると、仮想リソースの特性は、仮想リソース管理メカニズムが持つべき機能と特性を決定します。スケーラブルで、物理ネットワーク リソースの不均一性を隠し、仮想ネットワーク ユーザーに統一されたアクセス インターフェイスを提供して、物理ネットワーク リソースの動的な性質を保護し、物理ネットワーク リソースのローカル管理メカニズムと戦略を尊重する必要があります。仮想ネットワーク ユーザーにサービスを提供します。

4. リソースパフォーマンス指標

1. 仮想化リソースのパフォーマンス指標

仮想化されたリソースはクラウド サービスとは異なり、リソースの種類によって運用プロセスが大きく異なるため、統一的な指標システムを確立することは不可能です。管理システムのパフォーマンス指標の観点から、対応する指標は、1 秒あたりの読み取りと書き込みの数、読み取りと書き込みの速度、および信頼性 (バックアップと回復のメカニズム) を含む、ストレージ リソースなどの仮想化されたリソースの実際の動作に従って選択する必要があります。など)。

1) コンピューティング リソースの仮想化

コンピューティング リソースは主に仮想マシンの形で提供されるため、コンピューティング リソースのパフォーマンス指標は物理マシンのパフォーマンス指標に似ています。管理レイヤーでの管理を簡素化するために、仮想マシンには通常、事前設定された標準構成が割り当てられます。

たとえば、EC2 の実装では、仮想マシンは極小、小、中、大などのさまざまなレベルに分割され、それらの主なパフォーマンス指標には、CPU 周波数、CPU の数、メモリ サイズ、CPU 占有率、メモリ占有率、およびデータ通信速度等

2) 仮想化されたストレージ リソース

管理システムの主な関心事は、調整可能なパフォーマンス インジケーターです. ストレージ リソースの主な制御可能な項目には、ストレージ リソースの増加によるディスク スペースの総量の増加、並列リソースの増加による I/O パフォーマンスの増加、および相互間の冗長バックアップによるデータの信頼性の向上が含まれます。したがって、仮想化ストレージ リソースのパフォーマンス指標には、合計ディスク容量、使用済みディスク容量、1 秒あたりの読み取りと書き込みの数 (1 秒あたりの入力/出力、IOPS)、I/O レート、接続の最大数、およびデータの冗長性が含まれます。 rate (回復可能なバックアップの数) など。

3) ネットワーク帯域幅リソースを仮想化する

仮想化レイヤーのネットワーク帯域幅リソースは論理的な概念であり、主に仮想化リソース間のネットワーク通信要件とネットワーク トポロジーを表し、そのパフォーマンス インジケーターには、合計ネットワーク帯域幅、ネットワーク帯域幅占有率、パケット遅延、および最大ユーザー数が含まれます。 . ネットワーク帯域幅リソースのパフォーマンス要件を計算するときは、ストレージ リソースのディスク I/O やコンピューティング リソースのデータ転送速度など、関連する仮想化リソースのパフォーマンス指標と関連付ける必要があります。ネットワーク帯域幅リソースのパフォーマンスは、少なくともこれらの指標を下回らないようにする必要があります。そうしないと、パフォーマンスのボトルネックになります。

次の表は、いくつかの重要なパフォーマンス指標を示しています。

一部の SLA インジケーターはリソースのパフォーマンスを完全には決定しないため、仮想化リソースのパフォーマンス インジケーターがクラウド サービスの SLA ドメインを完全にカバーしていないことがわかります。たとえば、コンピューティング サービスの可用性指標は、主にコンピューティング リソースの数と、HA などのフォールト トレランス対策が講じられているかどうかに関連しています。

一方、ネットワーク帯域幅リソースの特殊性は、それらがリソース間の関連付けの抽象的な概念を表すことです。実世界のリソース エンティティに直接マッピングされないため、物理ネットワーク リソースに一般的に使用される一部のメトリックは、仮想化されたネットワーク帯域幅リソースには適用されません。 

2. 物的資源のパフォーマンス指標

仮想化リソースのパフォーマンス インジケータは、物理リソースのパフォーマンス インジケータの論理的な概要と分割された組み合わせです. 論理的な概要は、ノード機能、ハードウェア構成、マシン名、およびマザーボード インターフェイス属性などの情報を含む物理リソースを参照します. 管理層は、仮想化リソース層でこれらの内容に注意を払う必要がないため、それらを論理的に要約して不要な情報を除外します (分割と結合は、仮想化リソースが物理リソース上で占めるさまざまなトポロジー関係を指します)。

管理システムに関係する物理的リソースの重要なパフォーマンス指標は次のとおりです。

  1. コンピューティング リソース: CPU パフォーマンス (Hz)、CPU の数、CPU 使用率、合計メモリ、メモリ使用率、実行時間、使用不可時間、およびネットワーク I/O レートなど。
  2. ストレージ リソース: 合計ストレージ容量、使用可能なスペース、読み取り/書き込み速度、使用可能な接続の合計数、現在の接続数、ネットワーク I/O 速度など。
  3. ネットワーク リソース: ネットワーク帯域率とキャッシュ サイズなど。

仮想化リソースの一部のパフォーマンス インジケータが複雑なロジックを持っていることを除けば、残りは物理層のパフォーマンス インジケータに簡単にマッピングできることがわかります。

次の 2 種類のパフォーマンス インジケータのマッピングには、複雑なロジックがあります。

  1. 信頼性や可用性などの指標は、分割と結合によって物理リソースのパフォーマンス指標から直接計算することはできません.仮想化リソースの信頼性を決定する2つの要因があります.1つは、物理リソースノードを介して取得できる物理リソース自体の信頼性です.環境条件(マザーボードの温度など)、サービス障害の記録、正常稼働時間に対する異常稼働時間の比率を計算し、2 つ目は仮想化レイヤーの稼働安定性です。3 つ以上の物理リソースをサポートする仮想ストレージ リソースの例では、ストレージ リソースの信頼性は、物理リソース間の論理関係にも関連しています。物理リソースが相互にバックアップする場合、仮想化されたリソースの信頼性が向上します。
  2. 仮想化されたネットワーク リソースのパフォーマンス インジケーターは、物理ネットワーク リソースだけに基づくものではなく、このインジケーターは、関連付けられているすべての物理ネットワーク リソースのパフォーマンス インジケーターを決定します。複数の仮想化ネットワーク リソースが同じ物理ネットワーク リソースを占有すると、リソースの競合が発生するため、物理リソースのサービス能力を個別に考慮する必要があります。

5. クラウド サービスと仮想化リソースの関係

仮想化レイヤーは、クラウド コンピューティング プラットフォームのアプリケーション レイヤーに、その動作パフォーマンス要件を満たす仮想化されたリソースを提供しますが、SLA 保証付きのクラウド サービスを提供するには、まだ一定の距離があります。クラウド サービスが満たすべき条件は、クラウド サービスのライフ サイクルを満たし、クラウド サービスの使用インターフェイスを提供し、サービス SLA 保証メカニズムを備え、サービスを提供しながら仮想化されたリソースを合理的に使用することです。

仮想化されたリソースを介してクラウド サービスをサポートする一般的な考え方は、仮想マシンに基づくシステムにサービス アプリケーションをインストールし、仮想マシンのネットワーク インターフェイスを介してさまざまなサービスを提供することですが、さまざまな種類のクラウドを提供することは最適なソリューションではありません。仮想マシンを介したサービス プログラム。たとえば、仮想マシンを使用してストレージ サービスを提供する場合、物理リソースに対する仮想化テクノロジの追加のオーバーヘッドが非常に高くなります。さらに、ストレージサービスの提供方法は比較的安定しており、仮想マシンを使用することで得られる柔軟性は、実際にはサービス品質を向上させるものではありません。

アマゾン ウェブ サービス (AWS) のストレージ サービスは EC2 ではなく S3 を使用しており、クラウド サービス アーキテクチャでさまざまなサービスを提供するには、その需要特性を十分に考慮する必要がある一方で、複雑な構造をうまく管理する必要があることを示しています。のクラウド サービスには、適切に設計された階層型リソース モデルが必要です。つまり、クラウド サービス自体の関連性を維持し、管理操作を完全に簡素化できます。

クラウド サービスと仮想化リソースの関係、および関連する管理要件については、既存のクラウド コンピューティング プラットフォーム システムを参照してください。

1. 各種クラウドサービスの提供

クラウドサービスの用途に応じて、コンピューティングサービス、ストレージサービス、およびその他の補助サービスに分けることができます。この基本的な分類を超えたさまざまな種類のサービスは、これら 3 種類のサービスの派生物または組み合わせと見なすことができます。

たとえば、Web アプリケーション サービスは一般に、バックグラウンド データベース ストレージ サービス、Web アプリケーション (コンピューティング サービス)、および Web ディスプレイ (コンピューティング サービス) で構成され、データベース ストレージ サービスは、データベース アプリケーション サービスとストレージ サービスで構成されます。この Web サービスの監視と認証を実現する必要がある場合は、監視サービスと認証サービスの支援が必要です。

仮想化リソースの特性により、コンピューティング サービスはコンピューティング リソースとネットワーク リソースによって提供され、ストレージ サービスはストレージ リソースとネットワーク リソースによって提供されます。したがって、コンピューティング サービスは一般に、仮想化層の仮想マシンに基づいて提供され、特定のコンピューティング サービス機能は仮想マシン テンプレートをカスタマイズすることによって提供されます。ストレージ サービスは、一般に、仮想化層のネットワーク ストレージに基づいて提供されます。プラットフォーム補助クラウド サービスは、によって指定されます。クラウド コンピューティング プラットフォーム サーバーは、システム サービス インターフェイスを直接提供します。

システム実装の観点から、仮想マシンが複数のコンピューティング サービスをサポートすると、その変更の再利用コストと開発コストが増加するため、1 つの仮想マシンは、記述されたプラットフォームで 1 つのコンピューティング サービスのみをサポートするように制限されます。

2. クラウドサービス構造と仮想化リソース構造

クラウド サービスの SLA を確保するために、クラウド コンピューティング プラットフォームの管理レイヤーは、まず関連する仮想化リソースのパフォーマンス インジケーターを確認する必要があるため、管理レイヤーがクラウド サービスと仮想化リソースの関係を理解することは非常に重要です。

プラットフォームでは、クラウド サービスは複数の基本サービスに基づく場合があります。これは、クラウド サービスが複数の仮想化されたリソースに関連付けられていることを意味します。また、クラウドサービスには、ストレージサービスなども含まれる場合があります。単一の機能を持つ Web サービスを例にとると、それに関連するクラウド サービスと仮想化されたリソースは、下の図に示すように非常に複雑になる場合があります。

この Web サービスを提供するために、プラットフォームは、サービス要件に従って仮想化されたリソースのグループを組み合わせて構成する必要があります。上の図に示されている目に見える構成には、基本的なコンピューティング サービスと基本的なストレージ サービスおよびその他の補助サービスで構成される複数の階層が含まれています。

このクラウド サービス構造は普遍的であり、ほとんどのクラウド サービスと仮想化リソース構造では、コンピューティング リソースの提供がプラットフォームのエネルギー消費を引き起こす主な負荷であるため、コンピューティング リソースの管理は仮想化レイヤーの重要な管理要件です。対照的に、ストレージ サービスやその他の補助サービス (アカウンティングや認証など) の管理は比較的単純です。

1) クラウドサービスの仕組み

クラウド サービスの構成関係は、単純なオブジェクト アクセス プロトコル (Simple Object Access Protocol、SOAP) アーキテクチャを参照でき、同様の構成サービス モデル表現を使用して、クラウド サービスのグループ間の異なる呼び出しプロセスを反映できます。クラウドサービスの階層関係には、サービスの順次呼び出し、並列呼び出し、循環呼び出しなどの関係があります。

2) 仮想化リソース構造

仮想化リソースの構造体には、次の 2 つの意味があります。

  • 仮想化されたリソースは、仮想化レイヤーで仮想ネットワーク トポロジに基づいてリソース ネットワーク構造を形成し、管理システムは、仮想ネットワークに従ってリソースを分割し、アクセス権や負荷分散などの管理操作を制御できます。
  • サポートするクラウド サービス アプリケーション間の相互呼び出し関係に基づく、仮想化されたリソースの関連付け。仮想化されたコンピューティング リソースを例にとると、アプリケーションはコンピューティング サービス サポートとして複数の仮想マシンを使用する場合があります。このアプリケーションでこれらのコンピューティング サービスを組み合わせて使用​​すると、これらの仮想マシン間に対応する論理構造が生成され、同じ論理構造内の仮想化リソース間のネットワーク通信は、サービス動作中の独立した仮想化リソースのネットワーク通信よりも大幅に高くなります。 .

2 つのレベルのリソース構造を統一することで、プラットフォームの通信パフォーマンスを最大化できるため、管理層は 2 つのレベルの構造記述を同時に取得し、効果的な調整管理を実装することが、アプリケーションのパフォーマンスを最適化するための必要条件です。プラットホーム。

アプリケーションのシナリオを想像してみてください。つまり、クラウド コンピューティング プラットフォームがクラウド サービス アプリケーション A を発行する要求を受け取り、A に関する SLA 要件の説明が要求メッセージと共に送信されます。プラットフォーム管理レイヤーは、まずサービス構造と SLA の説明に従って、A に必要な基本サービスとその最小パフォーマンス インジケーターを分析し、分析結果に従ってプラットフォーム サービス リソース プールで利用可能なアトミック サービスを検索し、使用される仮想サービスを展開します。仮想マシンやネットワーク ストレージなどのリソース。仮想化されたリソースを仮想化レイヤーで公開し、リソースの分散と構造関係を最適化し、最終的にプラットフォームはリリースされたクラウド サービス アプリケーション A のユーザー インターフェイスを返します。

下図に示すように、構造 A には、クラウド サービス A1 から A5 の 5 つの基本サービスが含まれます。 

リソースをデプロイするとき、プラットフォームは基本サービスのパフォーマンス要件に従って仮想化リソースを割り当てる必要があります.この例では、それらは仮想化リソースA〜Eであり、各仮想化リソースは1つのクラウドサービスの運用をサポートします. 同時に、プラットフォームは、基本的なクラウド サービス間の呼び出し関係に従って、仮想化されたリソース間の仮想ネットワークも構成し、データ伝送を必要とする仮想化されたリソース間の伝送コストを削減します。 

2. 仮想資源プラットフォーム

1. 仮想資源プラットフォームの機能

仮想化されたリソースのプラットフォーム管理は、リソースの実装、地理的な場所、または物理的なパッケージに基づく独自の方法ではなく、ユーザーとアプリケーションの両方が簡単に恩恵を受けることができる方法でコンピューター リソースを表すプロセスです。つまり、データ、コンピューティング能力、ストレージ リソース、およびその他のリソースの物理ビューではなく、論理ビューを提供します。

リソースは、標準インターフェースに基づいて入力を受け取り、出力を提供できる特定の機能を提供します。リソースは、サーバー、ディスク、ネットワーク、機器などのハードウェアの場合もあります。または、Web サービスなどのソフトウェア。

消費者は、仮想リソースによってサポートされる標準インターフェイスを介してリソースにアクセスします. 標準インターフェイスを使用すると、IT インフラストラクチャが変更された場合の消費者の損失を最小限に抑えることができます. クラウド コンピューティングのインフラストラクチャは、仮想化されたコンピューティング リソース、ストレージ リソース、およびネットワーク リソースを、インフラストラクチャ、つまりサービスの形で、ネットワークを介してユーザーが使用および管理できるようにします。

各クラウド事業者のインフラは提供するサービスが異なりますが、基盤となる基本的なリソースを提供するサービスとして、このレイヤーは一般的に次のような基本的な機能を備えています。

1. リソースの抽象化

インフラを構築する際にまず直面するのは、ネットワークを介して相互に接続されたサーバーやストレージなどの大規模なハードウェア リソースです。高レベルのリソース管理ロジックを実装するには、リソースを抽象化する、つまりハードウェア リソースを仮想化する必要があります。

一方では、仮想化プロセスはハードウェア製品の違いを隠す必要があり、他方では、各ハードウェア リソースに統一された管理ロジックとインターフェイスを提供する必要があります。

インフラストラクチャによって実装されるロジックに応じて、同じタイプのリソースのさまざまな仮想化方法が非常に異なる方法を持つ可能性があることに注意してください。さらに、ビジネス ロジックとインフラストラクチャ サービス インターフェイスのニーズに応じて、インフラストラクチャ リソースの抽象化が頻繁に行われます。には複数のレベルがあり、リソースの抽象化はインフラストラクチャを構築するための基礎です。

2. リソース監視

リソースの監視は、クラウド コンピューティング インフラストラクチャの高効率を確保するための重要なタスクであり、負荷管理の前提条件です。負荷管理は、リソースを効果的に監視しないと実行できません。インフラストラクチャは、さまざまな方法でさまざまな種類のリソースを監視します.CPU については、通常、その使用率が監視されます.メモリとストレージについては、使用率の監視に加えて、必要に応じて読み取りおよび書き込み操作も監視されます.ネットワークについては、その実際の入力と出力を監視する必要がある時間、およびルーティング状態。

インフラストラクチャは、まずリソースの抽象モデルに基づいてリソース監視モデルを確立し、リソース監視の内容と属性を記述する必要があります.同時に、リソース監視にはさまざまな粒度と抽象化レベルがあります.典型的なシナリオは特定のソリューションです リソース監視スキーム全体で実行されます。多くの場合、ソリューションは複数の仮想リソースで構成され、全体的な監視結果は、ソリューションの各部分の監視結果の統合です。

結果を分析することで、ユーザーはリソースの使用状況とパフォーマンスへの影響をより直感的に監視し、必要なアクションを実行してソリューションを調整できます。

3.負荷管理

クラウド コンピューティング インフラストラクチャなどの大規模なリソース クラスター環境では、すべてのノードの負荷が常に均一ではありません。ノードのリソース使用率が妥当であれば、ノードの負荷がある程度不均一であっても、深刻な問題は発生しません。

ただし、あまりにも多くのノードのリソース使用率が低すぎたり、ノード間の負荷差が大きすぎたりすると、一連の未解決の問題が発生します。リソースの浪費を引き起こします。インフラストラクチャは、負荷を統合し、リソース使用率を改善し、負荷統合後にアイドル状態のリソースをシャットダウンするために、自動化された負荷分散メカニズムを提供する必要があります。一方、リソース使用率の差が大きすぎると、一部のノードの負荷が高くなりすぎて、上位層のサービスのパフォーマンスに影響を与えます。また、他のノードの負荷が低すぎて、リソースが十分に活用されていません。現時点では、インフラストラクチャの自動ロード バランシング メカニズムが負荷を転送するために必要です。つまり、高負荷のノードから低負荷のノードに負荷を転送し、すべてのリソースが全体的な負荷と全体的な使用率の点でバランスを取るようにします。 .

4. データ管理

クラウド コンピューティング環境におけるデータの整合性、信頼性、および管理性は、インフラストラクチャ データ管理の基本要件です。インフラストラクチャは、データ センター内の大規模なサーバー クラスター、または複数の異なるデータ センター内のサーバー クラスターで構成されているため、データの整合性、信頼性、および管理性は非常に困難です。

整合性は、データの状態がいつでも決定されることを必要とし、操作によって正常および異常な状態でデータを一貫した状態に復元できることを必要とします。書き込み操作。

信頼性を確保するには、データの損傷や損失の可能性を最小限に抑える必要があり、そのためには通常、データの冗長バックアップが必要です。管理性を実現するには、管理者と上位レベルのサービス プロバイダーがデータを粗粒度で論理的に単純な方法で管理する必要があります。特定のクラウド インフラストラクチャ レイヤーについては、データ読み取りパフォーマンスやデータ処理規模の要件、クラウド コンピューティング環境に大量のデータを格納する方法など、他のデータ管理要件があります。

5. リソースの展開

リソースのデプロイとは、自動化されたデプロイ プロセスを通じてリソースを上位層のアプリケーションに配信するプロセス、つまりインフラストラクチャ サービスを利用可能にするプロセスを指します。アプリケーション環境構築の初期段階では、仮想化されたハードウェアリソース環境がすべて整った時点で、初期化プロセスでのリソース配備が必要であり、アプリケーションの実行プロセス中にリソース配備が 2 回または複数回行われることがよくあります。インフラストラクチャ内のリソースに対する上位層サービスのニーズ、つまり運用中の動的な展開に対応するため。

動的な展開には多くのアプリケーション シナリオがあります. 典型的なシナリオは、インフラストラクチャの動的なスケーラビリティを実現することです, つまり、クラウドアプリケーションは、特定のユーザーのニーズと極端な期間内のサービス条件の変化に応じて調整できます. ユーザー サービスのワークロードが高すぎる場合、ユーザーは自分のサービス インスタンスを数個から数千個に簡単に拡張し、必要なリソースを自動的に取得できます。

通常、この種のスケーリング操作は非常に短い時間で完了する必要があるだけでなく、スケールの増加に伴って操作の複雑さが増加しないようにする必要があります。別の典型的なシナリオは、障害回復とハードウェアのメンテナンスです. クラウド コンピューティングでは、何万ものサーバーからなる大規模な分散システムでは、ハードウェア障害は避けられません。また、ハードウェアのメンテナンス時にアプリケーションを一時的に削除する必要があり、障害からサービスを迅速に復旧できるように、サーバーのデータと動作環境を複製し、動的なリソース配置によって別のノードに同じ環境を確立できるインフラストラクチャが必要です。 .

6. セキュリティ管理

セキュリティ管理の目標は、インフラストラクチャ リソースが合法的にアクセスおよび使用されることを保証することです. クラウド コンピューティングは、クラウド内のデータ セキュリティを確保するための信頼できるセキュリティ保護メカニズムを提供し、クラウド データの操作が承認されていることを確認するためのセキュリティ レビュー メカニズムを提供する必要があります.追跡されています。

クラウドは、ユーザー プログラムをより簡単に実行できる、よりオープンな環境です。これは、悪意のあるコードやウイルス プログラムでさえ、クラウド内の他の通常のプログラムを破壊できることを意味します。プログラムは従来のプログラムとは実行方法やリソースの使用方法が大きく異なるため、クラウド コンピューティング環境でコードの動作をより適切に制御したり、悪意のあるコードやウイルス コードを特定したりする方法は、管理者にとって新たな課題となっています。クラウド コンピューティング環境では、データはクラウドに保存されます。クラウド コンピューティングの管理者がセキュリティ ポリシーを通じてデータを漏洩させないようにする方法も、重点的に検討する必要がある問題です。

7. 請求管理

クラウドコンピューティングも従量制課金モデルであり、上位層の使用状況を監視することで、一定期間内にアプリケーションが消費するストレージ、ネットワーク、およびメモリリソースを計算し、ユーザーに課金することができます。これらの計算結果に基づきます。特定の実装中に、クラウド コンピューティング プロバイダーは、適切な代替方法を採用して、ユーザーのビジネスを円滑に完了し、ユーザーが支払う必要のある料金を削減できます。

仮想化されたリソース プラットフォームの主な機能は、ストレージやネットワーク リソースなど、多数のさまざまな種類のコンピューター リソースを統合することです。また、負荷分散を実現するには、これらのリソースを効果的に監視する必要があります。そのためには、仮想化リソース プラットフォームが優れた異質性を持ち、さまざまなハードウェアおよびソフトウェア リソースを効果的に統合できる必要があり、さらに、仮想化リソース プラットフォームには動的リソース展開機能が必要です。つまり、アプリケーションの実行中に 2 つまたは複数のリソースのデプロイを実行できます。このようにして、リソースをオンデマンドで使用することができ、物理的な施設に対して透過的なリソース管理およびサポート ツールを提供できます。

2. 仮想資源プラットフォーム

コンピューティング リソースの仮想化、サービスとしてのソフトウェア、およびリソースの柔軟なスケジューリングの主要なテクノロジを突破するには、コンピューティング リソース、仮想マシン リソース、仮想ストレージなどのサービスをユーザーに提供する仮想リソース プラットフォーム層を構築する必要があります。 「Software as a Service、Location Transparency、および Interaction Pervasiveness」は、新しいネットワーク アプリケーション モデル用のネットワーク化されたオペレーティング システム仮想化プラットフォームです。

1. 一般的な枠組み

仮想化されたリソース プラットフォーム (インフラストラクチャ レイヤー) は、1 つ以上のクラスターからリソースを集約して管理できます。クラスターは、同じ LAN に接続されたマシンのグループです。クラスターには 1 つ以上の仮想マシン管理ノード インスタンスが存在する可能性があり、各インスタンスは仮想インスタンスの起動、終了、および再起動を管理します。クラスタの数に応じて、仮想化プラットフォーム レイヤーは、シングル クラスタとマルチ クラスタの 2 つのアーキテクチャに分けることができます。

単一クラスタ アーキテクチャを次の図に示します。

少なくとも 2 台のマシンが含まれており、1 台のマシンでクラウド プラットフォーム コントローラー (CLoud Controller、CLC)、クラスター コントローラー (Cluster Controller、CC)、ストレージ アクセス コントローラー (Walrus)、ストレージ コントローラー (Storage Controller、SC) などを実行します。エンド コンポーネント; もう 1 つはノード コントローラー (NC) を実行します。この構成は、主に実験と迅速な構成の目的に適しています。インストール プロセスは、フロントエンド コンポーネントを 1 台のマシンに組み合わせることで簡素化できますが、このマシンのパフォーマンスは非常に堅牢である必要があります。

マルチクラスタ アーキテクチャを次の図に示します。

ここでは、個々のコンポーネント (CLC、SC、Walrus、CC、および NC) を別々のマシンに配置できます。これは、プラットフォーム層を使用して重要なタスクを実行する必要がある場合に、プラットフォーム層を構成する理想的な方法です。マルチクラスタのインストールでは、実行しているコントローラのタイプに適したマシンを選択することで、パフォーマンスを大幅に向上させることもできます.たとえば、超高速 CPU を搭載したマシンを選択して CLC を実行したり、大容量のストレージ スペースを備えたマシンを選択したりできます.その結果、可用性が向上し、クラスタ全体に負荷とリソースが分散されます。クラスターの概念は、Amazon EC2 内のアベイラビリティ ゾーンの概念に似ています。ここでは、リソースを複数のアベイラビリティ ゾーンに割り当てることができるため、1 つのゾーンでの障害がアプリケーション全体に影響を与えることはありません。

2. コンポーネント

具体的には、仮想化プラットフォーム層は 5 つの主要コンポーネントで構成されています。つまり、CLC、CC、Walrus、SC、および NC は、相互に協力して必要な仮想化サービスを提供し、SOAP メッセージングを Work Station (Work Station、WS)-Security で使用して相互に安全に通信します。 

1)CLC

CLC は、仮想化リソース プラットフォームのメイン コントローラー コンポーネントであり、システム全体を管理し、すべてのユーザーと管理者が仮想化リソース プラットフォームに入るメインの入り口です。すべてのクライアントは、SOAP または REpresentational State Transfer (REST) に基づく API を介してのみ CLC と通信します。CLC は、要求を正しいコンポーネントに渡し、それらのコンポーネントからの応答をクライアントに送り返す役割を果たします。仮想リソース プラットフォーム。

すべての仮想化リソース プラットフォームのインストールには、システムの中枢神経系、ユーザーの目に見えるエントリ ポイント、およびグローバルな意思決定を行うためのコンポーネントとして機能する単一の CLC が含まれています。これは、ユーザーによって開始された要求またはシステム管理者によって発行された管理要求の処理、高レベルの仮想マシン インスタンスのスケジューリングの決定、サービス レベル アグリーメントの処理、およびユーザーに関連するシステム メタデータの維持を担当します。CLC は、ユーザー要求の処理、システムの認証と維持、ユーザー メタデータ (仮想マシン イメージ、キー ペアなど)、および仮想マシン インスタンスの操作の管理と監視を行う一連のサービスで構成されます。これらのサービスは、エンタープライズ サービス バス (ESB) によって構成および管理され、サービスの公開などの操作を実行できます。仮想化リソース プラットフォームの設計では、プラットフォームの実験と拡張を容易にするために透明性とシンプルさが強調されています。

この詳細レベルの拡張を実現するために、CLC のコンポーネントには、仮想マシン スケジューラ、SLA エンジン、ユーザー インターフェイス、および管理インターフェイスなどが含まれます。それらはモジュール化された独立したコンポーネントであり、明確に定義された外界へのインターフェイスを提供します。ESB は、それらの間の相互作用と有機的な協力を制御および管理する役割を果たします。CLC は、Web サービスと Amazon の EC2 クエリ インターフェイスを使用して EC2 のクライアント ツールと相互運用することで、Amazon の EC2 のように機能します。

2)CC

仮想化リソースプラットフォームのCCは、仮想インスタンスネットワーク全体を管理し、リクエストはSOAPまたはRESTに基づくインターフェースを介してCCに送信されます。CC は、システムで実行されている NC に関するすべての情報を維持し、これらのインスタンスのライフ サイクルを制御し、仮想インスタンスを開始する要求を利用可能なリソースを持つ NC にルーティングします。

一般的な CC は、クラスタのヘッド ノードまたはサーバーで実行され、どちらもプライベート ネットワークまたはパブリック ネットワークにアクセスできます。1 つの CC で複数のノード コントローラーを管理でき、所属するノード コントローラーからノード ステータス情報を収集します。

これらのノードのリソース ステータス情報に従って、各ノード コントローラーで実行される着信仮想マシン インスタンスの要求をスケジュールし、パブリックおよびプライベート インスタンス ネットワークの構成を管理します。NC と同様に、CC インターフェイスも Web サービス記述言語 (Web サービス記述言語、WSDL) ドキュメントによって記述され、これらの操作には runInstances、describeInstances、terminateInat​​ances、および describeResources が含まれます。インスタンスの記述と終了は、関連するノード コントローラに直接渡されます。

CC が runInstances リクエストを受け取ると、単純なスケジューリング タスクが実行されます.タスクは、describeResource を呼び出して各ノード コントローラーにクエリを実行し、インスタンス実行リクエストを実行するのに十分なアイドル リソースを持つ最初の NC を選択します。CC はまた、describeResources 操作を実装します。これは、インスタンスが占有するリソースを入力として受け取り、その NC で同時に実行できるインスタンスの数を返します。

3)NC

NC 制御ホスト オペレーティング システムおよび対応する仮想化プラットフォーム ハイパーバイザー (Xen または KVM) は、実際の仮想インスタンス (CC からの要求に応じてインスタンス化) をホストする各マシンで NC のインスタンスを実行する必要があります。

NC は、仮想マシンによってホストされる物理リソース上で実行されるコンポーネントである物理ノードの管理を担当し、仮想マシン インスタンスの起動、チェック、シャットダウン、クリアなどを担当します。一般的な仮想化プラットフォームには複数の NC がインストールされていますが、1 つの NC でノード上で実行されている複数の仮想マシン インスタンスを管理できるため、マシン上で実行する必要がある NC は 1 つだけです。

NC インターフェースは、インスタンス データ構造と NC によってサポートされるインスタンス制御操作を定義する WSDL ドキュメントによって記述されます。これらの操作には、runInstance、describeInstance、terminateInat​​ance、describeResource、および startNetwork が含まれます。インスタンスの実行、記述、および終了操作は、システムの最小構成を実行し、現在のハイパーバイザーを呼び出して、実行中のインスタンスを制御および監視します。

describeRescource オペレーションは、プロセッサ リソース、メモリ、ディスク容量などの情報を含む、現在の物理リソースの特性を呼び出し元に返します。StartNetwork オペレーションは、仮想イーサネットの設定と構成に使用されます。

4)セイウチ

このコントローラー コンポーネントは、仮想化リソース プラットフォーム内のストレージ サービスへのユーザーのアクセスを管理し、要求は SOAP または REST に基づくインターフェイスを介してストレージ アクセス コントローラーに渡されます。

5)SC

SC は Amazon の S3 インターフェイスを実装し、Walrus と組み合わせて使用​​して、仮想マシン イメージ、カーネル イメージ、RAM ディスク イメージ、およびユーザー データを保存およびアクセスします。VM イメージはパブリックまたはプライベートにすることができ、最初は圧縮および暗号化された形式で保存されますが、これらのイメージは、ノードが新しいインスタンスを開始する必要があり、イメージへのアクセスを要求する場合にのみ復号化されます。

3. 情報資源クラウドの仮想論理アーキテクチャ

クラウド環境と組み合わせて情報リソースの特定の属性を拡張した後、下図に示すように、仮想化テクノロジーをリソース仮想化の抽象レイヤーモデルに導入して、情報リソースのクラウド仮想化を実現するための論理アーキテクチャを取得します。

ユーザー活用の観点から仮想化を実現し、情報資源を動的かつ透過的に低コストで利用できます。

1. ネットワーク層

ネットワーク層は情報資源の仮想化を実現する最も基本的な層であり、物理ホストは情報資源の重要なキャリアであるだけでなく、情報資源クラウドの重要な部分でもあり、現在は主にvNetworkネットワークを通じて実現されていますVMware vSphere の要素。

このレイヤーは、指定された物理サーバー内の仮想マシン間で分散スイッチを使用して、単一の仮想スイッチとして統合します。これにより、仮想マシンは、ホスト間で移行するときにネットワーク構成の一貫性を維持できます。

スイッチの一方の端はポート グループに接続され、もう一方の端は仮想マシンが存在するサーバの物理イーサネット アダプタに接続されたアップリンクです。仮想スイッチは、そのアップリンクを複数の物理イーサネット アダプタにリンクして、NIC チーミングを有効にすることができます。NIC チーミングを使用すると、2 つ以上の物理アダプターがトラフィックの負荷を共有したり、物理アダプターのハードウェアまたはネットワークに障害が発生した場合にパッシブ フェールオーバーを提供したりできます。同じポート グループに関連付けられたすべての仮想マシンは、異なる物理サーバーに属し、仮想環境内の同じネットワーク上にあります。

仮想マシンの観点からは、ゲスト オペレーティング システムの通信プロセスは実際の物理デバイスの通信プロセスと同じです。仮想マシンの外部から見ると、vNIC (仮想ネットワーク インターフェイス カード) には独立した MAC アドレスと 1 つの MAC アドレスがあります。標準のイーサネット ネットワーク プロトコルに準拠する 1 つ以上の IP アドレス。個別のハードウェア リソースを統合して、アプリケーションの可用性、セキュリティ、およびスケーラビリティが組み込まれた共有動的プラットフォームを作成します。

ネットワーク仮想化により、データ センター内の物理ホストに展開された仮想マシンを、仮想マシンが属するネットワークに関係なく、物理環境と同じ方法で相互接続できます。したがって、異なるネットワーク間の境界が排除され、透明性の要件が満たされます。

2. リソース層

ネットワークの仮想化により、地理や属性などの制限要因に関係なくホストをオンデマンドで使用できるようになるため、ストレージやサーバーに格納されたデータを仮想化するために、ストレージやサーバーの仮想化が必要になります。

1) 仮想ストレージ リソース

仮想ストレージリソースは、従来の環境のストレージメディアをクラウド環境で必要なモードに変換できます.現在、クラウドストレージシステムは通常、仮想ストレージを次の3つのレイヤーに分割します.

  • 物理デバイス層: 主に、データ ブロック レベルでリソースを割り当てて管理し、基礎となる物理デバイスを使用して、連続した論理アドレス空間、つまりストレージ プールを作成するために使用されます。物理デバイスの属性とユーザーの要件に応じて、ストレージ プールは複数のデータ属性 (読み取りと書き込みの特性、パフォーマンスの重み、信頼性レベルなど) を持つことができます。
  • ストレージ ノード レイヤー: ストレージ ノード内の複数のストレージ プール間でリソースを割り当てて管理し、オンデマンドで割り当てられた 1 つ以上のストレージ プールをストレージ ノードの範囲内の統合仮想ストレージ プールに統合します。このレイヤーは、ストレージ ノード仮想モジュールによってストレージ ノード内に実装されます。ストレージ ノード仮想モジュールは、オンデマンドで割り当てられたストレージ デバイスを下部から管理し、上部でストレージ エリア ネットワークの仮想化レイヤーをサポートします。
  • ストレージ エリア ネットワーク レイヤー: ストレージ ノード間でリソースを割り当てて管理し、すべてのストレージ デバイス上のストレージ プールを集中管理して、統合された仮想ストレージ プールを形成します。このレイヤーは、仮想ストレージ管理サーバー上の仮想ストレージ管理モジュールによって実装され、帯域外仮想化方式で仮想ストレージ システムのリソース割り当てを管理し、仮想ディスク管理のためのアドレス マッピングやクエリなどのサービスを提供します。 .

2 層のアドレス空間マッピング メカニズムが仮想化ストレージに導入され、2 つの論理部分とマッピング コンポーネントが構築されます。グローバル拡張アドレス空間は、ローカル拡張アドレス空間にマッピングされたすべてのリモート空きメモリを管理するために使用されます。拡張アドレス空間は、ローカルの物理アドレス空間を拡張するために使用されます。

最後に、マッピング コンポーネントは、特定のルールに従ってグローバル拡張アドレス空間から論理拡張アドレス空間へのマッピングを完了し、物理サーバー リソースの境界を越えるメモリ リソースの抽象化を構築します。また、バルーンドライブ、ページスワッピング、コンテンツベースのページ共有およびページパッチ技術などを使用して、空きメモリを解放し、リモートメモリを使用して仮想マシンのメモリ割り当てサイズを動的に調整し、リモートメモリを追加ストレージとして使用します。レベル メモリ割り当てを仲介することで、メモリ リソース割り当てを最大限に最適化できます。

クラウド ストレージ内の各データには、異なるノードに保存された複数のバックアップがあり、クラウド内のノードに障害が発生すると、モニターは信号を送信して仮想マシンを迅速に移行します。ノードは動的に追加および削除できます。これは、元のストレージ方法よりもスケーラブルです。

情報資源の仮想化を実現するカギはストレージの仮想化であり、Hadoop分散ファイルシステム、vSphere高性能クラスタファイルシステム、Googleファイルシステムはいずれもクラウド環境に適用可能な分散ファイルシステムであり、耐障害性が高く、低コストでの展開が可能です。ハードウェア機器のコスト。

2) 仮想サーバー

サーバー仮想化には、ソフトウェア仮想化とハードウェア仮想化という 2 つのアプローチがあります。適切に構成された実行中のサーバーにより、複数の仮想マシン、サーバー、またはデスクトップを同じ物理サーバー上で実行できます。それぞれが独自の電源を必要とせず、独自の熱を生成せず、スペースも必要としません。しかし、これらの仮想マシンはすべて同じサービスを提供し、1 台の物理マシンで同時に実行できるため、各データ センターの使用率が大幅に向上し、多くのスペースが節約されます。

情報リソースの使用はサーバーに依存しており、サーバーの仮想化は、リソースに優先順位を付けて、いつでもどこでも最も必要とするワークロードにサーバー リソースを割り当てることで、管理を簡素化し、効率を向上させることができます。これにより、単一のワークロード ピーク用に予約されるリソースが削減され、リソースのスケジューリングで重要な役割を果たします。

3) 仮想データセンター

情報資源の仮想化の結果は、コンテンツをオンデマンドで継続的に出力できる巨大なデータセンターのようなものであり、狭義の「データの仮想化」とも言えます。

クラウドコンピューティングは、ストレージとサーバーの仮想化に基づいて、パッケージ化された一般的なサービスとリソースをユーザーに提供することに重点を置いており、異種リソースの処理はミドルウェアに依存せず、リソースごとに異なる処理を行います。プログラムに応答するとき、異種リソースの代わりに CPU、メモリ、およびソフトウェアを割り当てます。これにより、管理が容易になり、コストが削減されます。したがって、仮想データセンター内のリソースは、同形のリソースに従って同様の属性でグループ化され、物理から論理へのマッピングによって統合されます。

仮想データセンターは、さまざまなデータ ソースから抽象化されたサービス レイヤーにデータをインポートできます。これにより、物理ストレージ システムの必要性が軽減され、データを使用するすべてのアプリケーション (特にビジネス インテリジェンス システム、分析システム、およびトランザクション システム) にデータが提供されます。統一されたインターフェース。

4) 仮想資源管理層

オンデマンドで動的かつ効果的なプロビジョニングを実現するには、さまざまな仮想化方法を合理的に編成する必要があり、管理層はストレージ管理、スケジュール監視、デスクトップのインスタンス化、QoS 評価およびセキュリティなどを担当します。

サーバなどの仮想化後は規模が大きくなり、その移行性からネットワーク内の仮想サーバの物理的な位置を可視化することは困難です。管理レイヤーは、リソース ビューと仮想トポロジを導入してリソースを管理できます。仮想リソース ビューを介して、物理サーバー、仮想スイッチ、VM、およびネットワーク構成機能のリソース アフィリエーション情報を表示できます。仮想トポロジ データは、すべてのノードを物理サーバーに集約します。ノード 、および物理サーバー内の仮想世界を反映できます。

モニターは、仮想マシンの可用性とリソースの使用権を表示し、要求を受け取った後にリソース ストレージの動作状態を監視する役割を担います. ストレージ ノードに障害が発生したことが判明した場合、制御ノードはワークロードを通常のストレージに転送できます.完了するノード。

デスクトップのインスタンス化は仮想デスクトップであり、すべてのソフトウェア インスタンスの表示ウィンドウを統合して、真に仮想化されたエクスペリエンスをユーザーに提供できます。要求、認証、接続、リストの有効化、適用、および切断のプロセスを通じて、ローカル デスクトップと仮想デスクトップの融合を可能にします。エンドユーザーのデバイスは、キーボード、マウス、モニター、およびローカルに接続されたスキャナーとプリンターのみを処理する軽量コンピューターになり、真にどこでも使用できるようになります。従来の「ファット デスクトップ」と比較すると、その利点は、第一に低コスト、改善された管理性、セキュリティ、柔軟性、および再設定可能性であり、第二に、必要なアプリケーション ウィンドウのみが顧客にプッシュされ、第三に、リソースの動的割り当て、高性能およびロード バランシングです。 4 つ目は、クライアントとサーバー間の対話を制御するプロトコルを持つことです。

セキュリティ管理は、サード パーティの認証、承認、およびユーザー ID の検証のタスクを実行し、機密データを保護するためにファイル情報を通じてユーザー ロイヤルティの変化を動的に検出することもできます。

5) 仮想資源実行層

このレイヤーのコア機能は、仮想リソース タスクの実行をサポートすることです。

リソース スケジューリングは、クラウド環境でリソースの使用効率を改善するための重要なリンクです. 各サービスについて、特定の時点でのリソース要件を満たすために、負荷モデル、履歴データ分析、および外部イベントの兆候に基づいて、リアルタイムの要求量が予測されます. リソースのスケジューリングには、通常、リソースの要求、リソースの検出、リソースの選択、およびリソースの監視という 4 つのステップが含まれます。

まず、ユーザーのニーズとリソースが検出され、検出されたリソース インジケーターと事前定義されたリソース スケジューリング戦略に従ってリソースが評価されます。つまり、候補リソースのリストから最適なリソースを選択し、戦略と評価結果に従って対応するアクションを実行します。次に、仮想マシンを適切なマシンで起動して、リソース プール内のリソースを適切に使用できるようにします。スケジュール移行戦略では、アイドル状態のサーバーを合理的にシャットダウンするか、複数の仮想マシンを起動して、ユーザーのニーズに応じて比較的負荷の高いタスクを完了するときに負荷を分散できます。

仮想実行環境のリソースは仮想化レイヤーの存在を認識しませんが、従来のコンピューティング環境と同様に実行され、仮想リソースに独立した環境を提供します。ソフトウェア リソースの場合、仮想ソフトウェアは、その一部がシステムにインストールされていない限り、動的に展開できます。

3. 物理サービス層

物理サービス層は、主にリソースの統一標準化と統一コール インターフェイスの問題を解決し、リソース サービス カプセル化は仮想化の方法です。

最初のステップは、リソースを記述すること、つまり、対応するリソース記述テンプレートを選択することです。また、必要に応じて対応するリソース属性情報を入力して、リソース属性ドキュメントを XML 形式で作成します。2 つ目は、必要に応じてリソース実装クラスをパッケージ化して形成することです。3 つ目は、リソースをデプロイする、つまりリソー​​ス アダプタのインターフェースを呼び出すことです。リソース アダプタに参加します。リソース アダプタは、リソースを自動的に生成し、リソース実装クラスに関する情報を取得します。このようにして、リソースのサービス指向のカプセル化が完了し、統一された呼び出しインターフェイスが外部に提示されます。

リソースからサービスへのマッピングには 3 つのタイプがあります。1 つは 1 対 1 です。リソースが実行できる機能は比較的単純で、サービスの形で直接カプセル化されています。2 番目は多対 1 です。複数の結合されたリソースは、単一のインターフェースを提供する単一の論理表現として表されます. フォーム; 3 番目は、比較的強力なリソース用の 1 対多です。各機能は互いに独立しており、機能に応じて異なる機能を完了することができるサービスにパッケージ化できます。

4. 論理サービス層

論理サービス層は、特定のサービスからサービス機能を抽象化し、それらを論理サービスの形式で記述して、動的に変化する要件または特定のビジネス ニーズを満たす論理サービス層を形成します。

物理サービスと論理サービスの記述は、主に機能属性と非機能属性の 2 つの側面から記述されます. 機能属性記述は、サービスの内部処理ロジックであり、サービスが実行できることを記述します. 非機能属性も呼ばれます. 「サービス品質」 (Qos) 。パフォーマンス、価格、信頼性、可用性、セキュリティなど、使用中のサービスの外部パフォーマンスを表します。

物理サービスから論理層へのマッピングには 2 つのタイプがあります. 1 つは、同じ機能と異なる非機能属性値を持つ複数の物理リソースです. これらの物理サービスは、同じビジネス機能を完了することができ、同じ種類のサービスです.

それを論理サービスに仮想化し、実際の運用中に特定の非機能属性要件に従って使用する適切な物理リソースを選択します。2 つ目は、同じ機能と同じ非機能属性を持つ複数の物理リソースです。耐障害性を高めたり、負荷分散などの問題を解決したりするために、物理サービスの複数のコピーが複数のマシンに展開されます. 物理サービスを呼び出すときに、現在のサービスの運用状況に応じて動的に選択することができます.

上記のモデルは、基本的にハードウェア、ソフトウェア、およびデータの仮想化実装方法をカバーしており、上から下のレイヤーは明確に定義されておらず、独立して機能していますが、相互に補完し、相互に浸透しています。

3. リソース仮想化の設計と実装

1. リソースの仮想化を実現するクラウドコンピューティングの仕組み

サービスとしてのインフラストラクチャ (IaaS) のサービス モデルの定義によると、サービス プロバイダーは、エラスティック コンピューティング、エラスティック ストレージ、エラスティック ブロードバンド、および仮想マシンを含む、従量制の標準化されたエラスティック リソース サービスをテナントに提供する必要があります。

クラウド コンピューティングは、VDC プロバイダーの物理的なコンピューター ルーム内のすべてのハードウェア リソースを仮想化と標準化によって巨大なリソース プールに変換し、その中のすべての仮想設備はプロバイダーがサービスを提供できる製品であり、標準化された IaaS 形式でパッケージ化されています。ユーザーに貸し出します。テナントは必要なリソースをオンラインおよびオンデマンドで申請し、申請したリソースへのアクセス権と使用権を短期間で取得できます。

次の図は、リソースの仮想化を実現するためのクラウド コンピューティングの階層アーキテクチャを示しています。

管理者と一般ユーザーは、統合ポータルを通じてクラウド コンピューティング管理プラットフォームにログインし、各ユーザーが異なる認証レベルに従って使用できるクラウド コンピューティング管理プラットフォームによって提供されるサービスも異なります。VDC テナントが気にするのは、クラウド管理プラットフォームで必要なリソースをどのように申請し、リソースの使用状況、請求書、および履歴を表示するかです。

リソース レベルでは、クラウド管理プラットフォームは、仮想マシン モニター (VMM) を介して、CPU、メモリ、入出力 (I/O)、ネットワーク仮想化などのハードウェア リソースの仮想化を実装します。仮想化されたハードウェア リソースは、さまざまなハイパーバイザーによって収集され、ビジネス レイヤーの指示に従って仮想マシン (VM) にパッケージ化されます。 

2. 仮想リソースの静的および動的割り当てアルゴリズム

クラウド コンピューティング プラットフォームの仮想化された運用環境は革新的なコンピューティング モデルを採用しており、ユーザーはいつでもインターネットを介してほぼ無制限のコンピューティング パワーを得ることができ、ユーザーはコンピューティングとサービスを自由に使用し、ボリュームに応じて課金することができます。仮想化テクノロジのスケーラビリティと柔軟性は、仮想化された運用環境でリソースの使用率を向上させ、リソースとサービスの管理と保守を簡素化するのに大いに役立ちます。

数万台のサーバーの物理リソースを統合してリソースプールを構築し、最終的にサービスとしてオンデマンドでユーザーに提供します。また、Linux および Windows シリーズで一般的に使用されている主流のオペレーティング システムの仮想実行環境を提供するため、ユーザーはローカルの物理マシンを使用するのと同じように、仮想および実行環境で仮想マシンを使用できます。さまざまなトポロジとアクセス制御メカニズムに対して、仮想ネットワークの動的リソース割り当てには、永続的な仮想ネットワークの監視と、物理ノードとリンク容量の動的更新が必要です。

次の図は、動的および静的リソース割り当てアルゴリズムを示しています。

1.静的アルゴリズム

静的仮想ネットワーク マッピング アルゴリズムは、次の 2 つのカテゴリに分類できます。

1) 2 段階の仮想ネットワーク マッピング アルゴリズム

2 段階の仮想ネットワーク マッピング アルゴリズムは、ノード マッピングとリンク マッピングを分離し、それらを順次実行します. オフラインの仮想ネットワーク マッピング問題をデマルチプレクサ問題に変換できたとしても、それは依然として NP 困難な問題です. 完全なノード マッピングの場合、分離できないフローの場合の仮想リンク マッピングも NP 困難な問題です。

したがって、既存の仮想ネットワーク マッピング アルゴリズムはすべて、ヒューリスティック ベースのリンク マッピング スキームと組み合わせた貪欲なノード マッピングを使用して、仮想ネットワークをマッピングします。

2) ワンステップ ソリューションのための仮想ネットワーク マッピング アルゴリズム

ワンステップ仮想ネットワーク マッピング アルゴリズムは、最適なマッピング効果を得るために、仮想ネットワーク ノードとリンクを同時にマッピングします. いくつかの一般的なワンステップ仮想ネットワーク マッピング アルゴリズムは次のとおりです.

  • 分散協調セグメンテーション アルゴリズム

仮想ネットワーク マッピング アルゴリズムの複雑さと遅延を軽減するために、分散協調型仮想ネットワーク マッピング アルゴリズムは、仮想ネットワークをいくつかのスター トポロジ、つまりハブアンドスポーク トポロジに分割します。このアルゴリズムは、マルチエージェント ベースのスキームを使用して、スター トポロジのノードとリンクを同時にマッピングします. ノード マッピング スキームも、貪欲な方法を使用して、利用可能なリソースが最大の物理ノードをハブ ノードに割り当て、最短パスを使用します。接続するハブ ノードを選択するアルゴリズムと、スポーク ノードの物理パス。分散マッピング方式は、単一障害点がなく、仮想ネットワーク要求の並列処理という利点を得ることができますが、集中マッピング アルゴリズムと比較すると、応答時間とグローバル最適リソース割り当てに関するパフォーマンスは劣ります。

ノードとリンクを同時にマッピングすることを目的とするアルゴリズムは、ネットワークの状態が変化したときにコストを再計算する必要がある場合、複数のローカル最適化でスタックする可能性があります。

  • ビジネス上の制約に基づくマッピング アルゴリズム

検索スペースを狭めるために、VN トポロジはバックボーンのスター構造に制限されています。これらのノードの一部はバックボーン ノードであり、その他はアクセス ノードです。バックボーン ノードはスター トポロジの中心であり、アクセス ノードはバックボーン ノードに接続されます。

問題の複雑さをさらに軽減するために、バックボーン ノードは完全に相互接続された構造に限定されます。つまり、仮想ネットワーク トポロジ全体がスターとリングで構成される完全なグラフになります。仮想ネットワーク マッピング コストを最小化するという最適化目標を持つこの仮想ネットワーク マッピング アルゴリズムは、1 つの仮想ネットワーク リクエストに対してのみ解決され、アルゴリズムによって生成されるトポロジは最適ではありませんが、検索スペースは狭められます。

この方法は、仮想ネットワークのトポロジを制限することにより、バックボーン ノードのマッピングを混合整数二次計画法モデルに変換し、ノード間のフロー制約を使用して、反復法により最小のマッピング コストで仮想ネットワーク マッピング スキームを見つけます。ただし、アルゴリズムの計算は複雑であり、特定の構造に対する仮想ネットワーク トポロジ設計の一般性は低いです。

  • 埋め込まれた仮想リンクのみを考慮するアルゴリズム

仮想プライベート ネットワーク (VPN) のリソース割り当ては、最も初期の比較的単純な仮想ネットワーク マッピング問題と見なすことができます. これらの仮想プライベート ネットワーク マッピング アルゴリズムは、仮想リンクの帯域幅制約のみを考慮して、仮想ネットワーク マッピング問題を単純化します.

これにより、仮想ノードの制約が無視されるため、パス選択フェーズの処理が簡素化されます。シミュレーテッド アニーリング法を使用して仮想ノードをマッピングすることもできます。ノード マッピングに関する唯一の制限は、異なる仮想ノードが異なる物理ノードにマッピングされることを前提としていることです。このアルゴリズムは、リソース使用率が低い排他的なノード リソース割り当て方法です。 

2.動的アルゴリズム

静的アルゴリズムでは、仮想ネットワーク マッピングは時間とともに変化しませんが、動的アルゴリズムでは、仮想ネットワークの運用中にマッピングされたリソースを再割り当てして、基盤となる物理ネットワーク リソースの使用を最適化します。通常、静的アルゴリズムは物理リソースの使用率の低下につながります.この問題を解決するために、動的マッピング アルゴリズムを設計できます。それは、ネットワーク内のいくつかのボトルネック ノードまたはボトルネック リンクのリソースを解放し、ネットワークの接続を確保するために、分散したリソースを管理可能なリソース全体に編成することです。

1) 選択的仮想ネットワーク リマッピング アルゴリズム

回線交換ネットワークの再ルーティング メカニズムにより、仮想ネットワーク マップは定期的かつ選択的に再構成され、物理ネットワークの過負荷部分が最適化されます。ただし、仮想ネットワーク リソースの再分配の問題は、フローの再ルーティングの問題よりも複雑であり、仮想ネットワーク リソースの再構成により、物理ネットワークのノード/リンク マッピングが明らかに変化します。

仮想ネットワークの再マッピングのコストを定量化するために、仮想ネットワークの再マッピングのコストは、仮想ネットワーク、ノード、およびリンクの再マッピング率の加重合計として定義されます。再構成された仮想ネットワークの数は、ネットワークの安定性とコンピューティング オーバーヘッドに影響を与えるため、選択的再構成プロセスを使用して、再構成の負荷が高い仮想ネットワークを選択します。

選択的仮想リソース再構成アルゴリズムは、ボトルネックの物理ノードまたはリンクを定期的に特定するステップと、各仮想ネットワークのパフォーマンスを再構成および監視するステップの 2 つのステップに依存します。

2) トポロジを考慮した仮想ネットワークの再マッピング アルゴリズム

リソース再割り当てのマッピング アルゴリズムと定期的な再マッピング方法には 2 つの違いがあります. 1 つは再マッピングのコストを定量化することであり、もう 1 つは再マッピング メカニズムをトリガーすることです. 再マッピング コストを定量化する方法は、仮想ネットワークの再マッピングの前後のマッピング コストの差を計算することです。定期的な再マッピング メカニズムにより、すべての仮想ネットワーク リクエストを常に最適な状態に保つことができますが、より多くの仮想ノードと仮想リンクが再マッピングされることになります。

ネットワーク オーバーヘッドとコンピューティング オーバーヘッドが増加するため、アルゴリズムは、仮想ネットワーク リクエストをマッピングできない場合にのみ、仮想ネットワークの再マッピングを調整します。さらに、すべてのボトルネック ノードとボトルネック リンクが再マッピングされるわけではありませんが、ボトルネック ノードとボトルネック リンクの優先度が低い仮想ネットワーク リクエストのみが再マッピングされ、リソースの使用圧力が軽減されます。このアルゴリズムは、仮想ネットワーク マッピングの受け入れ率を向上させるノードとリンクの再マッピング メカニズムを設計します。ただし、仮想ノードを移行する際には、仮想ノードに関連付けられた仮想リンクも移行する必要があるため、全体の計算コストは​​比較的大きくなります。

3)DaVinei算法

DaVinei アルゴリズムは、カスタマイズされたインターネット用に提案された動的適応仮想ネットワーク マッピング アルゴリズムです. このアルゴリズムは、複数の仮想ネットワーク間で同じ物理リンクを共有する仮想リンク間の帯域幅を定期的に再分配します.

さらに、各仮想ネットワークは独自の分散プロトコルも実行し、独自の目的関数を最大化します。このアーキテクチャはマルチパスをサポートしており、複数の物理パスが他のノードに到達できるため、パケットの並べ替えの問題が発生します。このアーキテクチャのもう 1 つの欠点は、物理ネットワーク内のリンクがすべての仮想ネットワークのパフォーマンス目的関数を事前に知る必要があることです。これは実際には実現が困難であり、このアルゴリズムは仮想ネットワーク ノードの割り当てを考慮していません。

4) QoSMap メカニズム

QoSMap メカニズムは、仮想ネットワークを確立する際に仮想ネットワークの QoS 要件とトポロジの弾力性を厳密に考慮し、高品質で保証された物理リンクを選択することで、仮想ネットワークの QoS 要件を満たします。

さらに、このメカニズムは、中間ノードを経由するバックアップ 1 ホップ ルートも構築して、仮想ネットワーク リンク マッピングの弾力的な保証を提供します。メッセージ伝送遅延とパケット損失率を厳密に保証する必要がある仮想ネットワークにリソースを割り当てることを検討した場合、実験結果は、このアルゴリズムが QoS のみを考慮した仮想ネットワーク確立方式よりも優れたサービス品質と優れた弾力性を確保できることを示しています。ただし、アルゴリズムは仮想リンク保護のためにリンク帯域幅リソースを事前に予約するため、物理ネットワーク リソースの使用率は低くなります。

3. 仮想化環境におけるクラウド コンピューティング アーキテクチャのコア モジュール設計

1. クラウド コンピューティングの技術アーキテクチャ

ご存知のように、オンデマンド展開はクラウド コンピューティングの中核です。この問題を解決するには、仮想化、高性能ストレージ、プロセッサ、高速インターネットなどのテクノロジーに基づいて、リソースの動的再構成、監視、自動展開などを解決する必要があります。

クラウド コンピューティングを効果的にサポートするために, クラウド コンピューティングのアーキテクチャはいくつかの重要な機能をサポートする必要があります. まず, システムは自律的である必要があります.第二に、クラウド コンピューティングの構造は機敏で、需要のシグナルや変化に迅速に対応できなければならず、組み込みの仮想化テクノロジとクラスタリング テクノロジは、成長やサービス レベル要件の急速な変化に対応できなければなりません。 .

一般的なクラウド コンピューティング プラットフォームのアーキテクチャを次の図に示します。

  1. ユーザー インターフェイス: クラウド ユーザーがサービスを要求するための対話型インターフェイスを提供し、ユーザーがクラウドを使用するための入り口でもあります。ユーザーは、登録、ログイン、サービスのカスタマイズ、Web ブラウザーを介したユーザーの構成と管理を行うことができ、アプリケーション インスタンスを開くことは、デスクトップ システムをローカルで操作することと同じです。
  2. サービス カタログ: クラウド ユーザーは、対応する権限 (支払いまたはその他の制限) を取得した後、サービス リストを選択またはカスタマイズできます。また、既存のサービスのサブスクライブを解除し、クラウド ユーザー インターフェイスで対応するアイコンまたはリストを生成して、関連するサービスを表示することもできます。
  3. 管理システム: 利用可能なコンピューティング リソースとサービスを管理するために使用され、クラウド ユーザーを管理できます。つまり、ユーザーの承認、認証、ログインを管理し、利用可能なコンピューティング リソースとサービスを管理できます。同時に、ユーザーから送信された要求を受け取ります。ユーザー要求プログラムに従って、対応するアプリケーションにそれらを転送します。 
  4. 展開ツール: ユーザーの要求に応じてリソースとアプリケーションを自律的、インテリジェントかつ動的に展開し、リソースを構成および再利用します。
  5. 監視: 迅速な対応のために、クラウド システム リソースの使用状況を監視および測定します。ノード同期構成、負荷分散、およびリソース監視を完了して、リソースが適切なユーザーにスムーズに割り当てられるようにします。
  6. サーバー クラスター: 仮想サーバーまたは物理サーバーは、管理システムによって管理され、同時実行性の高いユーザー要求処理、大規模なコンピューティング処理、およびユーザー Web アプリケーション サービスを担当します。対応するデータ カット アルゴリズムをクラウド データ ストレージに採用し、大容量データを並行してアップロードおよびダウンロードします。

クラウド コンピューティング テクノロジー アーキテクチャとクラウド コンピューティング アーキテクチャは概念ではありません。後者は主にクラウドサービスがユーザーにもたらすものに焦点を当てたサービスの観点からクラウドを分割し、前者は主にソフトウェアとハ​​ードウェアが果たす役割の説明であるシステム属性と設計アイデアの観点からクラウドを説明しますクラウド コンピューティング テクノロジーのリソース。

クラウド コンピューティングには、クラウド コンピューティング インフラストラクチャを構築するための技術アーキテクチャを示す下図に示すように、複数の機能が含まれています。

このアーキテクチャは、物理リソース層、リソース仮想化層、管理ミドルウェア層、およびサービス指向アーキテクチャ (サービス指向アーキテクチャ、SOA) 構築層の 4 つの層に分けることができます。

物理リソース層では、物理設備を仮想化して柔軟なリソース プールを提供し、リソースの使用率を向上させます。管理層は、物理リソースと仮想リソース プールの管理、展開、監視、アラーム、およびセキュリティを担当します。サービス プロバイダー層は、管理層 機能は、さまざまな形態のサービスを提供します。

  1. 物理リソース: 主に、コンピュータの通常の動作をサポートできる一部のハードウェア デバイスとテクノロジを指し、安価な PC、高価なサーバー、ディスク アレイなどであり、既存のネットワーク、並列および分散テクノロジを通じて分散できます。コンピューティングやストレージなどのクラウド コンピューティング操作に優れた機能を提供できるクラスター。クラウド コンピューティングの時代では、ローカル コンピューターは、従来のコンピューターのように十分なスペースを備えたハードディスク、高性能プロセッサ、大容量メモリを必要としなくなり、ネットワーク デバイスや基本的なハードウェア デバイスなどの必要なハードウェア デバイスのみが必要になる場合があります。入力および出力デバイス。
  2. リソースの仮想化:コンピューティング リソース プールやデータ リソース プールなど、同じ種類の多数のリソースを同形またはほぼ同形のリソース プールに形成する特定の操作と特定の機能を実現できるリソース プールを指します。物理的なリソースに関するものであり、ジョブを統合して管理します。クラウド管理者は、需要をサーバーにフィードバックし、サーバー仮想化ソフトウェアを介してアイドル状態のリソースを直接確認します。これらのリソースは、数分でリソース プールとして確立され、ユーザーに提示されます。ユーザーは、クラウド サービス プロバイダーの課金基準に従って料金を支払った後に使用できます。使用中、管理者はユーザーのニーズに基づいてリソースを増減できます。これは一種の変更管理です。レンタルを開始するのに十分なリソースがない場合、管理者はアイドル状態のリソースをユーザーのリソース プールに追加できます。ユーザーのリソースが減少し、管理者はまだ多くのアイドル状態のリソースがあることを確認し、ユーザーがコストを削減したい場合は解放できます。いつでもどこでも アイドル状態のリソースの一部を IaaS サービス プロバイダーの大規模なリソース プールに解放して、他のユーザーにサービスを提供することができます。このようにして、利用者及びサービス側のコストを削減し、サービスの利便性も提供する。
  3. 管理ミドルウェア: クラウド コンピューティング テクノロジでは、ミドルウェアはサービスとサーバー クラスターの間に配置され、リソース管理、タスク管理、ユーザー管理、およびセキュリティ管理を担当します。識別、認証、認可、ディレクトリ、セキュリティなどのサービスを標準化し、統一された標準化されたプログラム インターフェイスとアプリケーション用プロトコルを提供します。また、基盤となるハードウェア、オペレーティング システム、およびネットワークの異種性を隠し、ネットワーク リソースを統一された方法で管理します。そのリソース管理は、バランスの取れた方法でクラウド リソース ノードを使用し、ノードの障害を検出してそれらを回復または保護し、リソースの使用状況を監視および統計することを担当し、タスク管理は、デプロイの完了とユーザー タスクの管理、タスクのスケジューリング、タスクの実行、およびタスクのライフサイクル管理。ユーザー管理は、ユーザー交換インターフェースの提供、ユーザー ID の管理と識別、ユーザー プログラムの実行環境の作成、ユーザーへの使用料の課金などを含む、クラウド コンピューティング ビジネス モデルの実現に不可欠な部分であり、セキュリティ管理はクラウド コンピューティング全体を保証します。身元認証、アクセス許可、包括的な保護、およびセキュリティ監査を含む施設のセキュリティ。
  4. SOAの構築:クラウドコンピューティング時代のコンピュータ使用に関する統一規則、クラウドコンピューティングサービスの各種規格など

管理者は、ログイン インターフェイスを介してログインし、仮想マシン ストレージ、ネットワーク、アカウント、イベント、システム、および構成機能をリモートで提供できます. ユーザーは、ユーザー インターフェイスを介して、使用する仮想マシンとリソース プールを表示できます. 同時に、ユーザーは、使用および管理できるデータ リソースと、リソースの可用性に直面します。ユーザーと管理者の両方がクラウド コンピューティング プラットフォーム上で追加操作を実行でき、操作の結果は権限の範囲内でユーザーに影響を与える可能性があります。

違いは、管理者はすべてのユーザーのイベントとアラームを表示できるのに対し、ユーザーは自分自身に関連するイベントのみを表示できることです。さらに、ユーザーはシステム内の完全なオペレーティング システム情報を表示でき、仮想マシンにログインして実行することもできます。関連操作。管理者は、システム リソースを維持および管理し、リソースの追加および変更を完了することもできます。管理者はクラウド環境でユーザー情報を包括的に管理でき、システム内の多くの特定のパラメーターと構成を管理者構成インターフェイスで設定できます。 

2. 仮想化から見たクラウドコンピューティングアーキテクチャ 

仮想化テクノロジは非常に包括的なテクノロジであり、コンピューター サイエンスのほとんどの作業は仮想化を行っています。ネットワークのレイヤー 7 プロトコルは物理通信の仮想化であり、従来のオペレーティング システムは単一のコンピューターの物理ハードウェアの仮想化であり、高レベルのコンピューター言語は機械語の仮想化であり、人工知能はより高度な仮想化テクノロジです。 .

次の図は、コンピューター サイエンスの仮想化階層を示しています。

ノードとネットワーク物理ハードウェアは、いわゆるクラウド コンピューティング モデルである多層仮想化の論理的簡素化プロセスを通じて、コンピューティング、ストレージ、およびネットワーク帯域幅を統合する柔軟な仮想リソース プールを形成します。

クラウド コンピューティングの概念は、基盤となる物理ハードウェアを複数の仮想化によって抽象化することによって形成されていることがわかります。これは、クラウド コンピューティングが今後数年間の技術開発の方向性である理由も説明しています。技術の発展は継続的な抽象化と単純化のプロセスであるため、技術的なロジックが高ければ高いほど、ロジックは高くなります。このロジックは多くの「巨人」の肩にかかっており、これらの「巨人」が基盤となる仮想化テクノロジーです。

1) クラウドコンピューティングのリソースプールに含まれるリソースを仮想化の観点から見る

一般的に、クラウド コンピューティングによって形成されるリソース プールには、コンピューティングとストレージのみが含まれますが、クラウド コンピューティングのリソース プールには、コンピューティングとストレージに加えて、ネットワーク帯域幅があることが図からわかります。クラウド コンピューティング システムのノードは分散しているため、クラウド センターは複数の場所に存在する可能性があります。クラウド コンピューティング システムは、帯域幅リソースの効果的な調整を実現できるため、帯域幅のリソースをリソース プールに持ち込むことができます。もちろん、オープンな汎用クラウド コンピューティング システムのリソース プールには、システム プラットフォームがアクセスするサービスも含まれます.アプリケーション アクセス プラットフォームとして、クラウド コンピューティング プラットフォームは、多数のアプリケーションのアクセスと統合を実現できます.おそらくサービス.また、リソースの仮想化テクノロジになる必要があります。

2)仮想化の観点からクラウドコンピューティングの産業チェーンを考える

最大の仮想化製品は、既存のオペレーティング システム ソフトウェアの Window と Linux であり、厳密には 90% 以上の IT 企業が仮想化を行っています。たとえば、Cisco はネットワーク層の仮想化を行っており、Intel はハードウェア層の仮想化を行っており、多数のソフトウェア企業がアプリケーション層の仮想化を行っています。

上の図の各仮想化レイヤーは、より詳細に分割することもできます。各仮想化レイヤーは、クラウド コンピューティング業界チェーンのリンクを表しています。チップ メーカー、ハードウェア メーカー、ネットワーク機器メーカー、クラウド コンピューティング プラットフォーム プロバイダー、クラウド アプリケーション プラットフォーム プロバイダー、ストレージ テクノロジー プロバイダー、オペレーティング システムおよび帯域幅プロバイダーなどは、必然的にクラウド コンピューティング産業チェーンに参入し、さまざまな仮想化ロジック レイヤーで異なる働きをします。クラウド コンピューティング アプリケーションの最上位レイヤーをサポートします。

クラウド コンピューティングの標準では、仮想化された論理プロトコル スタックを確立する必要があります。これにより、業界チェーン内のさまざまな企業が同じ論理再帰関係の下で効果的に作業できるようになります。

下の図は、クラウド コンピューティングのプロトコル スタックを簡略化して示したもので、各層には多くのサブ層も含まれています. クラウド コンピューティングの概念は、下位層の複数の論理プロトコル層から派生した上位概念です.

3) 仮想化の観点からクラウド コンピューティング プラットフォームを考える

下の図に示すように、仮想化はクラウド コンピューティングの基盤であり、典型的なクラウド コンピューティング プラットフォームです。 

このプラットフォームでは、複数の仮想マシンで構成される仮想化されたハードウェア プラットフォームが、すべてのソフトウェア レイヤーによって提供されるサービスを共同でサポートします。
このような仮想化とクラウド コンピューティングで構成される全体的なアーキテクチャでは、仮想化によってハードウェアとソフトウェアが効果的に分離され、クラウド コンピューティングによって人々はソフトウェアによって提供されるサービスにより集中できるようになります。

クラウド コンピューティングは仮想化する必要があり、仮想化はクラウド コンピューティングの強固な基盤を提供します。しかし、仮想化の有用性は、その強力な機能の一部にすぎないクラウド コンピューティングに限定されません。

これまでのところ、クラウド コンピューティング インフラストラクチャのほとんどは、データ センターを通じて提供される信頼性の高いサービスと、サーバー上に構築された仮想化テクノロジのさまざまなレイヤーで構成されています。仮想化はクラウド コンピューティングの基盤となる優れたテクノロジ プラットフォームを提供し、クラウド コンピューティングは最終的な製品です。 

3. クラウド コンピューティング プラットフォームにおける仮想化された動作環境のコア モジュール設計

クラウド コンピューティング プラットフォームの仮想化オペレーティング環境システムには、リソース管理、ノード スケジューリング、仮想マシンのライフ サイクル管理、および仮想マシンの監視という 4 つのモジュールが含まれています。

リソース管理モジュールは、異種分散された物理リソース(CPU、メモリ、ハードディスクなど)の管理と仮想化を実現し、これらの物理リソースのオンデマンド使用を実現し、ノード スケジューリング モジュールは最適なノードの選択を実現します。スケジューリング戦略に従ったコントローラ; 仮想マシン ライフサイクル管理モジュールは、仮想マシンのライフサイクルにおける仮想マシンの管理を実現します; 仮想マシン監視モジュールは、すべてのノードコントローラで仮想マシンのリアルタイム監視を実現しますクラウド コンピューティング プラットフォームで。4 つのモジュールの連携により、システムはシステム内のリソースを完全かつ合理的に使用および共有し、利用率を最大化できます。

1) 動作環境のアーキテクチャ

クラウド コンピューティング プラットフォームにおける仮想化された動作環境は、クラスター コントローラーと複数のノード コントローラーで構成され、そのアーキテクチャを下図に示します。

クラスタ コントローラは、主にノード スケジューリング、システム内の仮想マシンのステータスの監視、およびすべてのノード コントローラの CPU、メモリ、およびストレージ リソースの占有を担当します。ノード コントローラは、仮想マシン マネージャを介して物理リソースを仮想マシン リソースに仮想化します。それらを仮想マシンに割り当て、ライフサイクル中に仮想マシンを管理および監視します。各ノード コントローラーは、ハードウェア リソース (CPU、メモリ、およびハード ディスク)、仮想マシン マネージャー (KVM+Qemu、Xen または virtualBox)、および仮想マシンの 3 つのレイヤーに分割されます。

その中で、仮想マシン マネージャーは、物理リソースの仮想リソースへの仮想化を完了し、仮想マシンの I/O 要求を処理します; ノード コントローラーのアダプター モジュールは、クラスター コントローラーからの要求を受け取り、異なる仮想マシンに適応します。マネージャーと仮想マシンの管理 お待ちください。このシステムでは、ノード コントローラーは Axis2/C、つまり Apache Extensible Interaction System (AXIS) を使用してサービスを公開し、クラスター コントローラーは Axis2/C クライアントを介してノード コントローラーに要求を送信し、応答を取得します。

2) リソース管理

(1) リソースの仮想化

クラウド コンピューティング プラットフォームにおける仮想化された動作環境のリソースの仮想化は、主にノード コントローラー内の仮想マシン マネージャーによって実現されます。ノード コントローラー内の仮想マシン マネージャーは、ノード コントローラー上の CPU、メモリ、およびハード ディスク リソースを、仮想マシンが使用する仮想リソースに仮想化します。このシステムは、KVM+Qemu、Xen、VirtualBox の 3 種類の仮想マシン マネージャーをサポートしています。

KVM は完全に仮想化された仮想マシン モニター (VMM) であり、KVM ドライバーと Qemu (広く使用されているオープン ソースのコンピューター エミュレーターおよび仮想マシン、仮想マシン管理システム) の 2 つの部分で構成されます。その中で、KVM ドライバーは Linux のカーネル モジュールとしてカーネルに組み込まれており、その主な役割は、仮想マシンの作成、仮想マシン メモリの割り当て、仮想 CPU レジスタの読み取りと書き込み、および仮想 CPU の実行です。Qemu は I/ O 仮想マシンのデバイス エミュレータが周辺機器にアクセスする方法。

次の図は、KVM の基本的なアーキテクチャを示しています (Libkvm は、KVM が Qemu に提供するアプリケーション プログラム インターフェイスです)。

KVM ドライバーは、標準の Linux カーネルに追加され、Linux で標準のキャラクター デバイス (/dev/kvm) として編成されます。ユーザーモードの Qemu は、仮想マシンの作成および実行時にシステムコールを介して /dev/kvm にアクセスできます。KVM ドライバーの追加により、Linux カーネル全体が VMM になり、元の 2 つの Linux 実行モード (ユーザー モードとカーネル モード) に基づくクライアント モード (独自のカーネル モードとユーザー モード) が追加されます。

(2) リソース監視

仮想化されたオペレーティング環境は、CPU、メモリ、およびハードディスクを含むリソースの統一された抽象化と論理表現を実現します. 抽象化された仮想マシン リソースは 1 つ以上の仮想マシンで構成され、最終的なプラットフォームは仮想マシンの形でユーザーに提示されます. . したがって、リソースを効果的にリアルタイムで監視してリソースを適切に割り当てることは、仮想化された運用環境の重要な役割です。

クラスタ コントローラは 60 秒ごとにプラットフォームの最新のリソース情報を取得します. 具体的なプロセスでは、まず構成ファイルが変更されているかどうかを確認し、最新の構成ファイル情報に従って、リソース情報を記述した要求を各ノード コントローラに送信します.

ノード コントローラがリクエストを受信すると、CPU、メモリ、ハードディスクなどのリソースの占有率と残りのステータスの受信をクラスタ コントローラに提供し、クラスタ コントローラは受信したすべての応答をカウントして、ノード上のリソースを把握します。プラットフォームの占有率と残り。さらに、ユーザーが仮想マシンを申請すると、仮想化オペレーティング環境は、現在の残りのリソースに従って仮想マシンにリソースを割り当て、ユーザーが仮想マシンを閉じると、システムは時間内にリソースを回収します。 

3) ノードのスケジューリング

クラウド コンピューティング プラットフォームの仮想化された動作環境は、クラスター コントローラーと複数のノード コントローラーで構成され、各ノード コントローラーには、1 つ以上の仮想マシンを実行できる仮想マシン マネージャーがインストールされます。ユーザーが仮想マシンを申請すると、クラスタ コントローラは特定のスケジューリング戦略に従ってノード コントローラを選択し、十分なリソースを前提として、リソースの合理的な割り当てと負荷分散を保証します。

クラウド コンピューティング プラットフォームの仮想化された動作環境では、ノード コントローラーを選択するための 3 つのスケジューリング方法が提供されます。つまり、GREEDY (リソースが需要を満たすことができる最初の利用可能なノードを選択する)、ROUNDROBIN (ノードをキューに入れ、ノードに従って順序付けする) です。ポーリング方式) 使用可能なノードを選択) と POWERSAVE (ノード上で実行されている仮想マシンがない場合はスリープ状態であり、その都度、要件を満たすリソースを持つ使用可能な非スリープ ノードを選択します。要件を満たす非スリープ ノードがない場合は、使用可能なスリープ ノードをウェイクアップします)。

ノード スケジューラは、仮想マシンの申請要求を受信すると、スケジューリング戦略の 1 つに従ってノード コントローラーを選択し、同時に仮想マシンの申請要求をノード コントローラーに送信します。

さらに、ユーザーが仮想マシンのシャットダウンまたは再起動を要求し、システムが仮想マシンをリアルタイムで監視する場合、システムはノードをスケジュールして、仮想マシンが配置されているノード コントローラーを決定できる必要があります。ノードコントローラーにリクエストを送信して、後続の操作を実行します。

(1) 仮想マシン起動時のノードスケジューリング

システムが仮想マシンの起動要求を受信すると、クラスター コントローラーはノード スケジューリング戦略を呼び出して、仮想マシンのリソースでアプリケーション要件を満たすノード コントローラーを見つけ、仮想マシンを起動する要求をサーバーに送信します。それを見つけた後のノードコントローラー. プロセスは、下の図に示すとおりです。

クラスタ コントローラの各ノード コントローラには、RESASLEEP、RESDOWN、RESUP、RESWAKING の 4 つの状態があります。スリープ中のノードコントローラーは RESASLEEP 状態、覚醒中のノードコントローラーは RESWAKING 状態、覚醒したノードコントローラーは RESUP 状態、一時的にアクセスできないノードコントローラーは何らかの理由で RESDOWN 状態です。

ノードコントローラで仮想マシンが起動していない場合、ノードコントローラはスリープ状態となりますが、クラスタコントローラは仮想マシン起動の申請を受信すると、まずスリープしていないノードコントローラの中からアプリケーションの要件を満たすリソースが残っているノードコントローラを選択します。 . そうでない場合は、スリープ状態から要件を満たすノード コントローラーを選択し、ノード コントローラーをウェイクアップします。

(2) 仮想マシン停止時のノードスケジューリング

クラスタ コントローラは、仮想マシンのシャットダウン要求を受信すると、シャットダウンする仮想マシンのリストに従って、対応する仮想マシンを検索し、仮想マシンが見つかり、仮想マシンを終了できる場合は、サービスを取得します。ノード コントローラが配置されているノード コントローラのアドレスを指定し、リクエストを仮想マシンに送信します。ノード コントローラは、仮想マシンをシャットダウンするサービス リクエストを送信します。それ以外の場合は、仮想マシンをシャットダウンするサービス リクエストをすべてのノード コントローラーに送信します。

(3) 仮想マシン再起動時のノードスケジューリング

クラスタ コントローラは、仮想マシンの再起動要求を受信すると、再起動された仮想マシンのリストに従って、対応する仮想マシンを検索し、見つかった場合、仮想マシンが配置されているノード コントローラのサービス アドレスを取得して送信します。再起動仮想マシンをノード コントローラに送信します。サービス リクエスト。それ以外の場合は、この仮想マシンを再起動するサービス リクエストをすべてのノード コントローラに送信します。

仮想マシン再起動時のノードスケジューリングのフローチャートを下図に示します。

(4) 仮想マシン移行時のノードスケジューリング

クラスタ コントローラは、仮想マシンの移行要求を受信すると、移行対象の仮想マシンのリストに従って、対応する仮想マシンを検索し、見つかった場合、仮想マシンが配置されているノード コントローラのサービス アドレスを取得して、移行仮想マシン アドレスをノード コントローラに送信します。サービス リクエスト。それ以外の場合は、サービス リクエストを送信して、この仮想マシンをすべてのノード コントローラに移行します。

仮想マシンを移行する際のノード スケジューリング プロセスを次の図に示します。

4) 仮想マシンのライフサイクル管理

仮想マシンのライフサイクルとは、利用者が仮想マシンを申請してから仮想マシンをシャットダウンするまでの全期間を指し、この間に仮想化された運用環境の起動、再起動、シャットダウン、停止が行われます。ユーザーの要求に従って仮想マシンを移行します。仮想マシンのライフサイクル全体を通じて、仮想マシンは申請者が所有し、プラットフォーム管理者を含む誰も仮想マシンで操作を実行できません。

(1) 仮想マシンを起動する

ノード コントローラが仮想マシンの申請要求を受け取ると、アダプタはリソース マネージャに仮想マシンに十分なハードウェア リソースが割り当てられているかどうかを問い合わせ、十分なハードウェア リソースが割り当てられている場合は、仮想マシン用のミラーリング リソースを準備し、その仮想マシンの XML ファイルを開始します。仮想マシン。イメージ リソースとは、仮想マシンの起動に必要なイメージ ファイルを指し、ユーザーが必要とするオペレーティング システムと共通ソフトウェアがユーザーの要件に従ってインストールされています。次に、Libvirt 仮想化ライブラリの API を呼び出して仮想マシンを起動し、サービスの応答をクラスター コントローラーに送信します。仮想マシンが起動されると、DHCP またはクラスター コントローラーによって構成されたアドレス プールを介して IP アドレスが取得され、仮想マシンが正常に起動されると、ユーザーは仮想マシンにアクセスできるようになります。 

(2) 仮想マシンをシャットダウンする

ノード コントローラは、クラスタ コントローラから仮想マシンのシャットダウン要求を受け取ると、まず仮想マシン リストから該当する仮想マシンを検索し、見つかった場合は仮想マシン管理プログラムに接続されているかどうかを検出します。 、Libvirt 仮想化ライブラリ API を使用して仮想マシン ハイパーバイザーに接続します。次に、仮想マシン名から対応する仮想マシンを見つけ、Libvirt 仮想化ライブラリ API を呼び出して仮想マシンをシャットダウンし、サービス応答をクラスター コントローラーに送信します。

(3) 仮想マシンの再起動

ノードコントローラは、クラスタコントローラから送信された仮想マシンの再起動要求を受信すると、まず仮想マシン一覧から該当する仮想マシンを検索し、見つかった場合、仮想マシン監視プログラムに接続されているかどうかを検出します。接続されていない場合は、Libvirt 仮想化ライブラリ API を使用してハイパーバイザーに接続し、対応する仮想マシンを見つけます。次に、Libvirt 仮想化ライブラリ API を呼び出して仮想マシンを再起動し、サービス応答をクラスター コントローラーに返します。

(4) 仮想マシンの移行

ノードコントローラは、クラスタコントローラから送信された仮想マシン移行要求を受信すると、まず仮想マシン一覧から該当する仮想マシンを検索し、見つかった場合、仮想マシン監視プログラムに接続されているかどうかを検出します。接続されていない場合は、Libvirt 仮想化ライブラリ API を使用してハイパーバイザーに接続し、対応する仮想マシンを見つけます。次に、Libvirt 仮想化ライブラリ API を呼び出して仮想マシンを移行し、サービス応答をクラスター コントローラーに返します。

5) 仮想マシンの監視

仮想化されたオペレーティング環境は、仮想化テクノロジによって物理リソースを仮想リソースに仮想化し、最終的に各仮想マシンをユーザーに提示します。そのため、仮想マシンを監視して仮想マシンの状態をリアルタイムに把握し、正常に稼働しているかどうかを判断することは、クラウドコンピューティングプラットフォームにおける仮想化運用環境の重要な機能です。

このシステムの仮想監視は 2 つの部分に分かれており、1 つはノード コントローラーがその上で実行されている仮想マシンを監視し、その最新の状態を把握すること、もう 1 つはクラスター コントローラーがプラットフォーム上のすべての仮想マシンを監視することです。すべての仮想マシンの最新の状態情報を取得するための仮想マシン状態要求。

リソース監視と同様に、クラスタ コントローラはプラットフォームの最新の仮想マシン ステータス情報を 60 秒ごとに取得します。仮想マシン監視の主なプロセスは、すべてのノード コントローラ情報を取得し、仮想マシン ステータス要求をすべてのノード コントローラに送信することです。応答を受信した後、関連するデータ構造が更新され、仮想マシンに関する最新情報が保存されます。ノード コントローラは、ノード コントローラ上で実行されている仮想マシンのステータス情報を 5 秒ごとに更新し、クラスタ コントローラに送信される応答が仮想マシンの最新のステータス情報であることを確認します。

仮想マシンの監視プロセスを図に示します。

4. リソース仮想化の導入事例

仮想化技術は、コンピューティング、ネットワーク、およびストレージ リソースを集中化して、動的に割り当てられたリソース プール (リソース プール) を形成し、多数のコンピューティング ユニットの同時高速アクセスに対応し、システム パフォーマンスに影響を与えずに容量を動的に拡張します。信頼性が高く、回復力と回復力があります。

統一されたデータ サービス仮想化プラットフォーム モデルを構築することにより、リソースの有効利用を実現できます.安全性、信頼性、および大規模なコンピューティング ストレージに基づいて、コンピューティング、ネットワーク、およびストレージ リソースが動的リソース プールに集中し、効率的なアプリケーション ソフトウェアを形成します。開発・運用プラットフォームです。

1. システムアーキテクチャ設計

クラウド コンピューティングに基づく仮想化プラットフォームは、クラウド コンピューティングに基づくさまざまな典型的なアプリケーション タイプをサポートできます。システム アーキテクチャ全体は、下図に示すように、リソース プール管理プラットフォーム、リソース プール統合スケジューリング、ホスト リソース プール、ストレージ リソース プール、およびネットワーク リソース プールに分けられます。

  1. リソースプール管理プラットフォーム:「リソース操作管理プラットフォーム」とも呼ばれ、統合仮想化プラットフォームのコアモジュールとして、リソースプールリソース全体の統合管理とスケジューリングを担当します。プラットフォーム全体の監視、運用、保守、リソース全体の業務、運用プロセスのサポート。
  2. リソース プール統合スケジューリング モジュール: プラットフォーム内のすべてのリソース プレゼンテーションおよび管理エンティティを統合し、リソース プール運用管理プラットフォームから指示を受け取ります。
  3. ホスト リソース プール: リソース プール内のすべてのコンピューティング リソースの管理とスケジューリングを担当. リソース プールの管理には、仮想マシン リソースと物理マシン リソースが含まれます。VMware vSphere Hypervisor (ESXi) は VMware の組み込みハイパーバイザーであり、サーバー ハードウェアに直接インストールするベアメタル仮想化ハイパーバイザー アーキテクチャです。VMware vSphere 5 以降、ESXi は、vSphere の展開に使用できる唯一のハイパーバイザーです。VMware ESXi は汎用オペレーティング システムに依存せず、コード ベースが小さいため、より信頼性が高く安全に選択できます。主流の物理サーバーに組み込まれているこのプログラムは、展開を簡素化して高速化し、メニュープロンプトによる起動と自動構成機能により、VMware 仮想化を開始する最も簡単な方法になります。 
  4. ストレージ リソース プール: リソース プール内のすべてのストレージ リソース (ブロック ストレージとファイル ストレージを含む) の管理とスケジューリングを担当します。ブロック ストレージ リソースの仮想化は、さまざまなメーカーの SAN デバイスの異種性をサポートし、さまざまなデバイスのハードウェアの違いを保護します。ファイル ストレージは、業界で普及している成熟したクラウド ストレージ テクノロジーを使用して、ストレージの場所の違いを保護し、オンデマンドの割り当てを提供します。ビジネス プラットフォーム ストレージ サービスの弾力的な拡張。
  5. ネットワーク リソース プール: リソース プール内のすべてのネットワーク リソースの管理とスケジューリングを担当し、外部アクセス、デバイス アクセス、ビジネス管理、およびネットワーク分離に必要なネットワーク接続サービスをビジネス プラットフォームに提供します。

統合アプリケーションシステムは、システムの応答速度とユーザーへのサービス品質を保証する必要があるため、システムには高い信頼性が必要です。データの正確性、完全性、および一貫性を保証し、事故によるシステム障害または中断後に迅速に復旧することができます。

システム アーキテクチャ、アプリケーション設計、データベース設計、およびシステム展開を設計する際には、パフォーマンスの問題を十分に考慮する必要があります。同時に、システムが長く活力を持ち、将来のシステム開発の要件を満たすことを保証するために、システムには優れた開放性が必要です。

2. 実装技術

プラットフォームモデルはマイクロカーネル設計技術を採用しており、オペレーティングシステムのカーネルは操作の最も基本的でコアな部分のみを提供する必要があります。他のハイパーバイザーは大部分がカーネルの外側に配置されているため、オペレーティング システムの内部構造が単純明快になり、プログラム コードのメンテナンスが非常に便利になります。外部プログラムは独立して実行でき、プログラムがカーネルの支援を必要とする場合にのみ、関連するインターフェースを介してカーネルに要求呼び出しを送信するため、他の電源コンポーネントを拡張および追加するのに便利です。

ルール構成は、簡潔で明確な構文と、他の言語で記述されたさまざまなモジュールを簡単に組み合わせることができる強力なクラス ライブラリを備えた Python 言語で実装されます。次に、特別なニーズのある部分をより適切な言語で書き直します。明確で一貫したスタイルにより、製品の高いスケーラビリティとカスタマイズ性が保証されます。

プラットフォームで採用されている Open Service Gateway Initiative (OSGI) プラグイン フレームワークは、現在のほとんどの多変量カウンター (Multiple Variate Counter、MVC) ベースのレイヤード デザインとは異なり、高度に再利用可能で効率的であり、システムの動作を動的に変更できます。ホットスワップ可能なプラグイン アーキテクチャにより、サードパーティのプラグインを簡単に挿入でき、監視および管理用の特定のソフトウェア用の特定のプラグインを開発できます。

データ サービス仮想化プラットフォームは、Java Management Extensions (JMX) の監視と構成を採用しており、一連の異種オペレーティング システム プラットフォーム、システム アーキテクチャ、およびネットワーク伝送プロトコルにまたがることができます。また、シームレスに統合されたシステム、ネットワーク、およびサービス管理アプリケーションを柔軟に開発できるため、システムの管理性が向上します。

3. 開発と実装のアイデア

統合データ サービス仮想化プラットフォームは、さまざまな担当者が表示できるリソースのさまざまなビューを提供し、リソース プールを管理および使用するためのさまざまな機能を提供できます。データ サービス仮想化プラットフォームは、管理ポータルとサービス ポータルに分かれており、管理ポータルは統合プラットフォームのさまざまな管理者が使用し、サービス ポータルは主に統合プラットフォームのさまざまなユーザーが使用します。

デバイス管理は、ホスト、ストレージ、ネットワーク デバイスなど、統合プラットフォームのリソース プール内のさまざまな物理デバイスにアクセスして管理するために使用されます。管理ポータル。

リソースに対するユーザーのさまざまなニーズを満たし、リソースの共有とソフトウェアとハ​​ードウェアの分離という目的を達成するために、リソース プール内のさまざまなデバイスが仮想化され、ユーザーが使用できるようにリソース プールに取り込まれます。管理プラットフォームは、既存の主流の仮想化製品を管理し、これらの仮想化製品を通じてさまざまな仕様の仮想マシンを提供できます。

さまざまな属性に従って、リソース プール内のさまざまな物理リソースと仮想リソースがさまざまなリソース プールを形成できます。管理プラットフォームは、ユーザーのリソース使用要件を満たすために、統一された方法でリソース プールを管理、監視、およびスケジュールします。プラットフォームは、システム内のさまざまなリソースの操作と操作を監視および記録し、リソース プール トポロジーの表示、リソースの監視、アラーム管理、ログ管理、バックアップと回復などを含む、システムの日常的なメンテナンスの基礎を提供できます。

これまでのところ、統合データ サービス仮想化プラットフォーム モデルを構築してリソースの有効利用を実現し、既存のネットワーク リソースを統合することで、すべてのリソースの統合、集中化、インテリジェントなスケジューリング、および管理のための実現可能なソリューションを提供しています。同時に、システムのセキュリティ、負荷分散、データのバックアップなどの要件を考慮して、ビジネス プラットフォームのスムーズなカットオーバーと柔軟な拡張を完全にサポートし、古い機器を再利用して再生するという目的を達成します。

4. 仮想資源管理

クラウド データ センターには多数のコンピューターが含まれており、運用コストが高くなります。仮想リソースを効果的に統合して動的な仮想リソース プールを構築し、リソースの使用率を向上させ、エネルギーを節約し、運用コストを削減することは、クラウド データセンターのホット スポットです。

クラウド コンピューティング仮想リソースの自動展開、動的拡張、およびオンデマンド割り当てを実現し、ユーザーがオンデマンドおよび従量制で仮想リソースを取得できるようにすることは、仮想リソース管理の重要なタスクです。

1. 仮想資源管理の機能

仮想化リソース管理は、リソースの地理的位置、実装、またはカプセル化の観点から表現されるのではなく、データ、コンピューティング能力、ストレージ、ネットワークなどのリソースの物理的なビューではなく、論理的なビューを提供します。各管理モデルは、仮想化ストレージ サービス、仮想化サーバー サービス、仮想化ファイル システム サービス、仮想化クラスター システム サービス、仮想化ユーザー システム サービスなどのシステム レベルのリソース サービスを含む、仮想リソース管理サービスを提供します。

仮想化されたリソース管理のコンシューマーは、エンド ユーザー、アプリケーション、またはリソースにアクセスまたは対話するサービスです。仮想化されたリソース管理により、ユーザーは物理リソースの実装と配布の詳細に注意を払うことなく、リソースの使用プロセスを簡素化できます。サービス プロバイダーは、リソース仮想化管理を通じて分散リソースを効果的かつ均一に管理し、ユーザー リクエストを効率的に完了し、サービス プロセスを簡素化し、サービス効率を向上させることができます。

リソース管理では、クラウド コンピューティング ネットワーク仮想化環境でさまざまな分散異種仮想リソースを管理し、ユーザーにシンプルなリソース アクセス インターフェイスを提供する必要があります。また、仮想リソースの共有と使用を調整し、ネットワーク仮想化環境内のさまざまな仮想リソースを可能な限り効率的に使用して、仮想リソース間の広範な共有を実現する必要があります。仮想リソース管理は、仮想リソースがユーザーやアプリケーションなどの他のエンティティに利用可能な機能を提供する方法を制御する一連の操作であり、仮想ネットワーク リソースのサービス プロビジョニング機能の制御に重点を置いています。つまり、リソースの特定の機能は気にしませんが、その機能がどのように実行されるかを気にします。

仮想リソース管理の中心的な機能は、仮想リソースの維持とスケジュール、仮想リソースの発見と特定、仮想リソースの発見と割り当て、仮想リソースの提供と展開、仮想リソースと物理リソースの運用の監視、仮想リソースのライフサイクルの実現です。 . 仮想資源のライフサイクル等の管理・管理

仮想リソース管理では、仮想リソースの使用プロセスを管理するだけでなく、仮想リソースのライフサイクル全体を管理する必要があります。次の図に示すように、仮想リソースのライフサイクル全体には、仮想リソースの登録、仮想リソースの検出、仮想リソースのスケジューリング、仮想リソースの予約、仮想リソースのリサイクルなどのプロセスが含まれます。

1. 仮想リソースの登録

インフラストラクチャプロバイダーは、基本的な物理ネットワークの敷設と構築を担当し、抽象化および分離メカニズムを通じて物理ネットワークリソースを分割して、スライスされた仮想ネットワークリソースを形成し、リソースの所有者です。リソース プロバイダーとして、システムがローカル仮想リソースを管理できるように、ローカル仮想リソースを管理システムに登録する必要があります。

仮想リソースの登録情報には、ノードのオペレーティング システムの種類、仮想マシン環境、使用されているネットワーク プロトコル スタックなどの静的な情報と、仮想リソースの残りの CPU リソースなどの動的な情報などのリソース属性情報が含まれます。ノードと接続リンクの残り帯域 情報はリソース情報データベースに保存されます。

2. 仮想リソースの発見

仮想リソースの検出は、仮想ネットワーク ユーザーの要求によって送信された必要なリソース記述情報に従って、仮想リソース情報のコレクションから仮想ネットワーク ユーザーの要求を満たす使用可能なリソースを見つけるプロセスです。仮想リソースのスケジューリング処理の候補となるリソースのセットを提供する操作であり、ユーザーのアプリケーションに適した仮想リソースをタイムリーに発見し、仮想リソースと物理リソース間の関連付けを自動的に発見して適用するために使用されます。リソース情報ストレージおよびリソース照合操作の典型的な実装は、分散システムの形で存在します。 

3. 仮想リソースのスケジューリング

仮想リソースのスケジューリングとは、仮想ネットワークの要求に対して適切なリソースを割り当てるプロセス、つまり、複数の仮想ネットワーク ユーザーによる物理リソースの共有を実現するプロセスです。異なる戦略を使用して、必要なリソースを対応するユーザータスクに割り当てます. 解決すべき問題は、仮想ネットワークによって提案されたリソース需要の制約に従って、リソース発見ステップによって提供された候補リソースセットから最適な仮想リソースを見つけることです.ユーザー。

ネットワーク仮想化環境には、さまざまな種類の異種仮想リソースが存在し、仮想リソースを必要とするさまざまな仮想ネットワーク アプリケーションも存在します。仮想リソースを提供するインフラストラクチャ プロバイダーと、仮想リソースを使用する仮想ネットワーク ユーザーは、リソースを使用するための独自の戦略とインターフェイスを持っています. リソース スケジューリングは、ユーザーのニーズを満たすだけでなく、基盤となる物理ネットワーク リソースの使用率を最大化する必要があります.

4. 仮想リソース予約

リソース管理システムが仮想ネットワーク ユーザーに適したリソースを見つけたら、対応する予約操作を実行するようにインフラストラクチャ プロバイダーに通知する必要があります。インフラストラクチャ プロバイダーは、構成リソースへの特定のアクセス権を持つ仮想ネットワーク ユーザーを承認する必要があります。リソース予約戦略は、SLA と QoS に対するユーザーの要件を確実にするために、ユーザーの複雑なアプリケーション要件に対して特定の時間内に必要なリソースを提供できます。

各予約アプリケーションには 8 つの異なる状態があり、状態間の遷移プロセスを下図に示します。

  • 予約申請が送信されると、リソースクエリの検証段階に入り、ユーザーの申請が要件を満たしている場合は予約リクエストが承認され、要件を満たしていない場合は申請が拒否されます。
  • 検証プロセス中に、ユーザーが予約申請が要件を満たしていないことがわかった場合、ユーザーはリソース予約申請をキャンセルできます。ただし、クラウド管理者がキャンセルが不適切であり、残りのリソースがユーザーのニーズを満たすことができると判断した場合、アプリケーションは引き続き承認状態になり、それ以外の場合はキャンセルされます。
  • 提出されたリソース予約申請が承認された後、ユーザーがキャンセルしない場合、有効な状態になり、必要なリソースが予約されます。それ以外の場合は、キャンセルされた状態になります。
  • 提出された資源予約申請が承認または有効状態の場合、利用者が予約した時間は満了間近のため、資源予約は満了間近の状態に遷移します。
  • ユーザーは、予約済みのリソースの有効期限が近づいていることに気付いた場合、リソースを再予約するか、使用中のリソースを終了するかを選択できます。
  • リソース予約の終了時刻に達すると、期限切れ状態になり、予約されたリソースを再利用します。

5. 仮想リソースの再利用

仮想ネットワークのライフ サイクルが終了し、使用されているリソースを解放する必要がある場合、インフラストラクチャ プロバイダーはリソースを管理する権利を取り戻し、次の仮想ネットワークに仮想リソースを提供するのを待ちます。仮想ネットワークはリアルタイムで出入りし、仮想リソースは占有または解放されます。仮想リソース管理では、そのようなリソースの動的な変更に対して合理的なスケジューリング戦略を実装し、散在するリソースを統合して、基盤となる物理ネットワーク リソースの使用を最適化する必要があります。

上記の仮想ネットワーク リソース管理の基本的な操作の一部は、仮想ネットワーク リソース管理システムの監督下で完了しますが、多くの場合、仮想化されたすべてのリソース管理には、リソースの抽象化、リソースの監視、負荷管理、データ管理、およびリソースの動的展開も含まれます。

2. 仮想リソースの提供と自動デプロイ

クラウド データ センター仮想リソース管理の特徴は、仮想柔軟なプロビジョニング、自動展開、集中管理、分散使用、集中監視、動的最適化、省エネルギー、低消費であり、その中で仮想リソースのプロビジョニングと自動展開は基本であり、重要な側面です。クラウド コンピューティングのリソース管理、コンテンツ。

1. 資源提供戦略

典型的なクラウド コンピューティングのリソース プロビジョニング戦略には、リース理論と動的マルチレベル リソース プールに基づく戦略、経済原理に基づくリソース プロビジョニング戦略、一般的な最適化アルゴリズムに基づくリソース プロビジョニング戦略、ランダム整数計画法に基づく最適なリソース プロビジョニング戦略が含まれます。

  1. リース理論とマルチレベル リソース プールに基づくプロビジョニング戦略: これは、リソースを複数のスロットに仮想化する、リース理論と動的なマルチレベル リソース プールを組み合わせたリソース スケジューリング戦略です。リソースは共通の特性に従ってリソースプールに分類され、マルチレベルのリソースプールが確立されます. リソースプールの1つはサーバーとして機能し、クラウドの外部との相互作用、リソースプールの負荷の維持などのサービスを提供します.バランシング、タスクの割り当て、リソースのスケジューリングを完了するための共有、プライベート、借用と返却、および再宣言戦略と組み合わせます。リソース分割とリソース予約戦略を通じて仮想リソースの割り当てを実現し、ユーザーによる仮想リソースの使用の有効性を保証し、仮想リソースの利用を最大化するために借用/貸し出しスケジューリング戦略を利用します。
  2. 経済学に基づくクラウド コンピューティング リソースの提供戦略: 経済学の概念によれば、クラウド コンピューティング環境はクラウド市場と見なされます。つまり、リソースは商品と見なされ、複数のコンピューティング クラウドとストレージ クラウドはリソース プロバイダーとして抽象化され、クラウド コンピューティング ユーザーはリソースの消費者と見なされます。この戦略は、クラウドの消費者と供給者に経済的インセンティブに関するフィードバックを提供し、リソースの利用を改善し、クラウド コンピューティング環境で効率的な管理とリソースの最適な割り当てを実現するのに役立ちます。同時に、ユーザー サービスの品質要件を最大限に満たします。ただし、この戦略は経済的な観点に基づいており、顧客のコストを節約するための関連する戦略を提供するものではなく、リソースと価格のダイナミクスを考慮していません。
  3. Random Integer Programming に基づく最適なリソース プロビジョニング戦略: これは、確率的整数計画法を使用してリソース プロビジョニングを最適化する方法です。クラウド コンピューティングでは、クラウド プロバイダーは、サブスクリプションと従量制の 2 つの方法でユーザーにリソースを提供できます。前者はユーザーのコストを効果的に削減できますが、ユーザーのニーズとリソースの価格が不確実であるため、ユーザーの要件を満たすために完全に予約によってリソースを取得することは困難です. ヒューリスティックな方法またはK近接アルゴリズムを使用すると、必要なリソースを予測できます.ユーザー。この戦略は、顧客のニーズを満たす動的なリソース提供スキームを提供し、リソース提供の各段階のリソースコストを考慮して、ユーザーのリソースコストを最小限に抑えます。

2. 仮想リソースの自動展開

仮想リソースの自動展開とは、データセンターの重要な機能要件である自動インストールおよび展開によって、仮想リソースを元の状態から使用可能な状態に変換することを指します。クラウド コンピューティング データ センターが仮想化テクノロジを採用した後のリソース管理の重要な機能は、仮想リソース プールを構築し、仮想マシンをさまざまな物理マシンに展開して、大規模な基本リソースを効果的かつ一元的に管理することです。

ハードウェア(サーバー)、ソフトウェア(ユーザーが必要とするソフトウェアや設定)、ネットワークやストレージなど、さまざまなサービスやアプリケーションをユーザーに提供するために、仮想的なリソース プールにリソースを分割してインストールし、展開するプロセスをクラウド コンピューティングで具体化します。システムリソースの配備には複数のステップがありますが、自動配備では、さまざまなベンダーのデバイス管理ツールの自動構成と、スクリプトを呼び出すことによるアプリケーションソフトウェアの配備および構成を実現します。これらの呼び出しプロセスをデフォルトの方法で実装できるようにすることで、人間とコンピューターのやり取りを大幅に削減し、展開プロセスが手動操作に依存しなくなります。

以下の図に示すように、展開プロセス全体がワークフローに基づいて実装されます。

ワークフロー エンジンとデータ モデルは、自動化された展開管理ツールに含まれる機能モジュールです. データ モデルで特定のソフトウェア、ハードウェア、さらには論理的な概念を定義することにより、管理ツールは、ワークフロー内のこれらのリソースを識別してスケジュールし、分類管理を実装できます。 . ワークフロー エンジンは、ワークフローを呼び出してトリガーし、展開の自動化を実装するためのコア メカニズムです。さまざまな種類のスクリプト プロセスを、一元化された再利用可能なワークフロー データベースに自動的に統合します。これらのワークフローは、最初は手動で完了する必要があったサーバーを自動的に完了することができます。、オペレーティング システム、ミドルウェア、アプリケーション、ストレージ、およびネットワーク デバイスの構成タスク。

仮想マシンの展開は複雑な問題です. 一方で、クラウド環境のリソースとアプリケーションは、さまざまな変化があるだけでなく、非常に動的でもあります. ユーザーが必要とするサービスは、主にオンデマンドで展開されます.異なるクラウド データ センターと異なるレベルのクラウド コンピューティング環境でのサービスの展開モードは異なり、展開プロセスでサポートされるソフトウェア システムはさまざまな形式であり、システム構造も異なり、展開戦略も多様です。

リソースのデプロイは通常、コンピューティング リソースのデプロイから始まります.リソース デプロイヤーは、仮想化ソリューションに必要なコンピューティング リソースが保証されることを前提として、ストレージおよびネットワーク リソース プールに適切なリソースを割り当てることを検討します. 単一の物理サーバーのコンピューティング リソースがソリューション サービスの要件を満たすことができない場合、複数のサーバー リソースが必要になります。このとき、仮想マシンのロード バランシングは非常に重要な要素になります。つまり、デプロイ フェーズで割り当てられたリソースを十分に活用できるようにすることができます。もちろん、ストレージ リソースの I/O ロード バランシングと帯域幅バランシングも重要です。ネットワーク リソースも考慮する必要があります。 

3. 仮想デバイスをデプロイする

仮想デバイスの展開は、仮想デバイスがサポートするソリューションをユーザーに提供するプロセス、つまり仮想マシンのインスタンス化の段階で最も重要なリンクです。展開フェーズで行う作業は、仮想デバイスを新しい仮想化環境に適応させ、それが運ぶソリューションをユーザーに提供することです。

次の図に、仮想デバイスを展開するプロセスを示します。

1) 仮想デバイスを選択してカスタマイズする

ユーザーは、仮想デバイスをデプロイする前に、デプロイする仮想デバイスを選択し、構成パラメーターを入力する必要があります. ユーザーが構成できるパラメーター情報には、仮想マシンの仮想ハードウェア情報 (CPU やメモリなど) と、少量のソフトウェア情報。

ソフトウェア情報とは、仮想マシンの内部ソフトウェア スタック (オペレーティング システム、ミドルウェア、およびアプリケーション プログラム) に関連する構成を指し、その中でネットワークおよびアカウント関連のパラメーターは不可欠です。ネットワーク パラメータは、IP アドレス、サブネット マスク、DNS サーバー、ホスト名、ドメイン名、ポートなど、各仮想デバイスを接続して全体的なソリューションを形成するための重要な情報です。これらは、ユーザーが手動で割り当てることも、展開ツールによって自動的に割り当てることもできます。アカウント パラメータには、主に、仮想マシンのユーザー名とパスワード、特定のソフトウェアのユーザー名とパスワード、または特定のソフトウェアのユーザー名とパスワードが含まれます。情報元。セキュリティ上の理由から、これらのパラメータは通常、デフォルト値ではなくユーザーが指定する必要があります。

2) カスタマイズパラメータファイルの保存

一般的に、カスタマイズされた情報は 2 つのファイルとして保存され、1 つのファイルは仮想化プラットフォームによって呼び出されて仮想マシンを起動する仮想マシンのハードウェア構成情報を保存し、もう 1 つのファイルは仮想デバイス内のソフトウェアのカスタマイズ情報を保存します。仮想マシン構成ファイルは、仮想マシンのプラットフォームに関連しているため、製造元が指定したファイル形式の仕様に従う必要があります。仮想デバイスのソフトウェアカスタマイズ情報については、仮想化技術の初期段階で各ベンダーが独自に独自の配備ツールを開発したため、カスタマイズされたパラメーターの保存方法が異なります。たとえば、一部のベンダーはテキスト構成ファイルを使用し、他のベンダーは XML ファイルを使用します。現在、主要なメーカーは、カスタマイズされた情報を OVF 環境ファイルの形式で保存します。

OVF 環境ファイルは、仮想マシンのソフトウェアが展開プラットフォームと対話する方法を定義し、これらのソフトウェアが展開プラットフォームに関連する情報を取得できるようにします。たとえば、属性自体はOVFファイルで定義されていますが、ユーザー指定の属性値です。OVF 環境仕様は 2 つの部分に分かれています。つまり、プロトコルと送信の部分です。プロトコルの部分では、仮想マシン上のソフトウェアが取得できる XML ドキュメントの形式とセマンティクスを定義します。送信の部分では、仮想マシン ソフトウェアと展開プラットフォームの間で情報が通信される方法を定義します。 . 通常、OVF ファイルには、仮想デバイスのテンプレートの記述情報、ユーザーが設定できる属性項目情報、および属性のデフォルト値が記述されます。手順1でお客様が入力したカスタマイズ情報をOVF環境ファイルに記述し、属性名をキーワードにして2つのファイルを照合します。

3) 展開するターゲット物理マシン サーバーを選択します。

ターゲット マシンは、スムーズなネットワーク、仮想イメージ ファイルを配置するための十分なディスク容量、仮想マシンのハードウェア リソース要件を満たす物理リソース (十分な CPU とメモリ)、および仮想デバイスのフォーマットと互換性のある仮想化プラットフォーム (たとえば、Xen プラットフォームは Xen 仮想デバイスをサポートし、VMware プラットフォームは VMware 仮想デバイスをサポートします)、および現在の展開ツールは上記の条件を自動的に確認できます。

具体的には、展開ツールはネットワーク経由でターゲット サーバーに接続します。接続が成功した後、システム コマンドを実行して、サーバーの CPU、メモリ、ディスク容量、および仮想化プラットフォームをチェックし、合格後にユーザーに展開可能な情報を返します。さらに、一部の展開ツールは、より高度な機能を提供できます。事前に入力されたサーバーのリストがサーバー プールを形成します。

ユーザーが仮想デバイスのデプロイを選択すると、デプロイメント システムは、上記の条件に従って、サーバー プールから条件を満たすサーバーをデプロイメントのターゲット マシンとして自動的に選択します。また、展開ツールは、ユーザーのカスタマイズ要件を考慮して、仮想デバイスをネットワークが優れたサーバー、ハードウェア パフォーマンスが優れたサーバー、または他の仮想マシンを実行していないサーバーに展開したり、複数の仮想デバイスを検討したりすることもできます。ソリューションで仮想デバイスを作成し、それらを同じサーバーまたは複数の異なるサーバーに展開します。

4) 仮想デバイスの関連ファイルをコピーします 

ユーザーがパラメーターのカスタマイズを完了し、ターゲットの物理マシンを選択した後、展開ツールは、ユーザーが選択した仮想デバイスの OVF パッケージを仮想デバイス ライブラリから抽出し、OVF 環境ファイルおよび仮想マシン構成ファイルと一緒にコピーできます。手順 2 で生成されたターゲット物理マシン。

ミラー ストリーミングは、オンライン ビデオ再生用のストリーミング メディアに似ています。つまり、ユーザーは、ストリーミング メディア テクノロジを介してダウンロードした部分を再生しながら、オーディオ ファイルとビデオ ファイルをダウンロードできます。これの利点は、ユーザーがファイル全体がダウンロードされて再生されるのを待つ必要がないことです。これにより、時間が節約され、ユーザー エクスペリエンスが最適化されます。一般的な仮想デバイスには、オペレーティング システム、ミドルウェア、アプリケーション ソフトウェア、およびユーザーが使用する必要がある残りの領域が含まれます。ユーザーが仮想デバイスを起動すると、主にそのオペレーティング システム、ミドルウェア、およびアプリケーション ソフトウェアが起動します.これらの部分は、仮想デバイス ファイル全体のごく一部しか占めません.イメージ ストリーミング テクノロジにより、ダウンロードせずに仮想マシンをすぐに起動できます.仮想デバイス全体。

簡単に言えば、仮想デバイスが起動されると、仮想デバイスはイメージストレージサーバーから仮想化プラットフォームにストリーム送信によって送信され、仮想デバイスはその一部を受信した後に起動プロセスを開始できます。仮想デバイスの残りの部分は、必要に応じてイメージ ストレージ サーバーから取得できるため、仮想デバイスの展開時間が短縮され、合計展開時間は数十秒から数分で済みます。仮想デバイス ファイルのパッケージ化が省略され、全体的な展開時間がさらに短縮されます。

5) ターゲット マシンで展開された仮想デバイスを起動します。

展開ツールは、リモート接続を介してターゲット マシンで一連のコマンドを実行し、仮想デバイスの起動を完了します。起動プロセスの重要なポイントは、手順 2 で生成されたソフトウェア構成パラメーター ファイルを仮想デバイスに転送することです。

現在、転送には仮想ディスクの方法が使用されています。つまり、OVF 環境ファイルが ISO イメージ ファイルにパッケージ化され、仮想ディスク構成項目が仮想デバイスの構成ファイルに追加され、パッケージ化された ISO をポイントします。画像ファイル。このように、仮想デバイスの起動後、OVF 環境ファイルが格納されているディスク デバイスが仮想デバイス内に表示されます。一般的に、この手順で必要な操作は、OVF 環境ファイルを ISO ファイルにパッケージ化し、仮想デバイス構成ファイルを変更して仮想ディスク アイテムを作成し、仮想デバイス情報を仮想マシン管理プラットフォームに登録し、仮想デバイスを起動することです。端末。

6) 仮想デバイスをアクティブ化する

OVF環境ファイルの情報を仮想デバイス内に読み込み、その情報に合わせて仮想デバイス内のソフトウェアをカスタマイズすることを「仮想デバイスの活性化」と呼びます。アクティベーションの自動化の程度と機能に応じて、完全な手動アクティベーション、スクリプトベースの手動アクティベーション、単一の仮想デバイスの自動アクティベーション、およびソリューションを構成する複数の仮想デバイスの協調アクティベーションに分けることができます。

すべての仮想デバイスに完全手動アクティベーションを適用 ユーザーは、仮想デバイス内の OVF 環境ファイルの内容を読み取り、構成アイテムがどのソフトウェアに属しているかを判断し、自分の知識に従ってソフトウェアを構成します。明らかに、このシナリオでは、OVF 環境ファイルの形式を理解し、コンテンツを読むことができ、さまざまなオペレーティング システム、ミドルウェア、およびアプリケーション ソフトウェアの構成に関する知識を持っている必要があるユーザーに対する高い要件があります。ユーザーがこの知識を持っていても、設定プロセスが複雑なため、誤操作やシステムの異常終了によりアクティベーションに失敗する場合があります。

スクリプト テクノロジはアクティベーション プロセスを簡素化でき、スクリプトは仮想デバイスの作成者と公開者によってコンパイルされます。アクティブ化プロセス中、ユーザーは構成スクリプトを呼び出し、OVF 環境ファイル内の構成情報をスクリプトの入力パラメーターとして使用するだけで、アクティブ化を完了できます。ユーザーはアクティベーション スクリプトのワークフローを理解する必要はなく、さまざまなソフトウェア製品の構成に関する知識も必要ありません。ただし、この方法には、ユーザーに対する一定の要件があり、まず、ユーザーは OVF 環境ファイルの内容を理解する必要があります。次に、ユーザーは、アクティベーション スクリプトによって公開されるインターフェース形式を理解し、対応する OVF 環境ファイルの内容を渡す必要があります。第三に、複数のソフトウェアのアクティベーションはアクティベーション中に特定の順序に従う必要があるため、ユーザーは複数のスクリプトの実行プロセスを理解し、調整する必要があります。

単一の仮想デバイスを自動的にアクティベートするための一般的なツールの動作原理は、アクティベーション ツールが仮想デバイスの起動プロセス中に仮想ディスクから OVF 環境ファイルを取得することです。アクティベーションの順序に従って OVF 環境ファイル内のパラメーターを読み取り、アクティベーション スクリプトを実行して仮想デバイス内のソフトウェアを構成し、カスタマイズされた使用可能な仮想デバイスをユーザーの介入なしで取得します。

この展開方法は、従来のソフトウェアのインストールおよび展開方法を改善し、コンパイル、互換性、最適化された構成など、時間がかかり、エラーが発生しやすい展開手順を排除します。この方法は、仮想リソース プールのインテリジェントな管理をサポートすることで完全に自動化でき、仮想化環境でのソフトウェアとサービスの迅速な展開に非常に適しています。現在、多くの企業が開発した仮想デバイスには簡単なアクティベーション ツールが組み込まれており、たとえば、IBM がリリースした仮想デバイスでは、自動アクティベーション ツールとして IBM アクティベーション エンジンが広く使用されています。

複数の仮想デバイスが 1 つのソリューションに結合されます。これらの仮想デバイスは、アクティベーション プロセス中に構成パラメーターの依存関係とアクティベーション シーケンスの関係を持つ場合があります。仮想デバイス内にネットワーク通信機能を備えたアクティベーション ツールを埋め込むことにより、ソリューション全体のアクティベーション プロセスを調整し、ソリューションのアクティベーションを共同で完了することができます.もちろん、これには、定義されたパラメーターの依存関係とアクティベーション シーケンスの使用が必要です.既存の OVF ファイル内。

3. 仮想リソース スケジューリング モデル、アルゴリズム、およびプロセス

リソースのスケジューリングは、特定のリソース使用ルールに従って、さまざまなリソース ユーザー間でリソースを調整するプロセスです。異なるリソース ユーザーは異なるコンピューティング タスクに対応し、各コンピューティング タスクはオペレーティング システム内の 1 つ以上のプロセスに対応します。リソース スケジューリングの目的は、ユーザー タスクを適切なリソースに割り当てて、ユーザーのニーズを満たしながら、タスクの完了時間をできるだけ短くし、リソースの使用率をできるだけ高くすることです。

リソースのスケジューリングは、最終的には、タイム スパン、サービス品質、負荷分散、および経済原則の最適な目標を達成する必要があります。異なるベンダー アーキテクチャのクラウド インフラストラクチャは異なるため、リソース管理とスケジューリングに関する統一された国際標準は存在せず、さまざまなスケジューリング インフラストラクチャとスケジューリング モデルに基づいた多数のスケジューリング アルゴリズムが存在します。

1. リソース スケジューリング モデル

タスク スケジューリング モデルは、アプリケーション モデル、コンピューティング プラットフォーム モデル、およびパフォーマンス ターゲット モデルに分けられます. アプリケーション モデルには、アプリケーションをタスクに分割する方法と、タスクの属性と特性をどのように考慮するかが含まれます. 典型的なタスク モデルには、依存タスク モデル DAG、独立タスク モデルがあります。タスク モデル IND と分離可能なタスク モデル DLM。

コンピューティング プラットフォーム モデルは、システム内のリソースの抽象化であり、その中で最も重要なのはプロセッサ リソースとネットワーク リソースです。パフォーマンス インデックス モデルは、システム目標とユーザー ベースの目標に基づく 2 つのタイプと、システム ベースのパフォーマンス モデルに分けることができます。システム全体のスループット、リソース使用率、効率、および公平性に焦点を当て、ユーザーベースのパフォーマンス指標には、最短のアプリケーション完了時間、ターンアラウンド タイム、平均遅延、加重完了時間が含まれます。

リソース管理スケジューリング モデルは、スケジューリング エンティティ間の関係に従って、統合リソース エージェント スケジューリング モデルとマルチリソース エージェント スケジューリング モデルに分けることができ、集中型スケジューリング モデル、階層型スケジューリング モデル、非リソース スケジューリング モデルに分けることができます。リソースの組織的なスケジューリング形式に従った集中スケジューリング モデル。集中型環境では、すべてのリソースが中央スケジューラーによってスケジュールされ、使用可能なすべてのシステムに関する情報が中央コンピューターに収集されます。階層型スケジューリング モデルには、ジョブが送信される集中型スケジューラがあります。各リソースはローカル スケジューリングに独立したスケジューラを使用しますが、この構造の主な利点は、ローカル ジョブ スケジューリングとグローバル ジョブ スケジューリングに異なる戦略が使用されることです。非集中型システムでは、分散スケジューラが対話してリモート システムに送信され、障害単一のコンポーネントがクラウド コンピューティング システム全体に影響を与えることはなく、耐障害性と信頼性が高くなります。ただし、並列プログラムのすべての部分が異なるドメインのリソースに割り当てられる可能性があるため、異なるスケジューラーがジョブを同期し、それらが同時に実行されるようにする必要があり、スケジューリング システムの最適化が非常に困難になります。

リソース管理スケジューリング モデルは、さまざまなアーキテクチャに従って、階層モデル、抽象所有者モデル、および市場経済モデルに分けることができます.階層モデルは、管理システムをいくつかの機能層に分割します.これは、サイトの自律性と基礎となる異質性を備えたリソースの管理に役立ちます. ある程度のリソースの共同割り当てを実現でき、強力な適用性があります。

抽象的な所有者モデルは、リソース ブローカーをリソース所有者として使用して、ユーザーと対話および交渉し、リソース共有プロセスでファースト フード レストランと同様の注文および配達モデルに従います。計算経済モデルは、階層モデルと抽象所有者モデルのコア機能を組み合わせており、階層モデルで比較的成熟した技術を使用できるだけでなく、経済学に基づくリソース管理とスケジューリングを明確に強調しています。需要と供給の原則に基づく投資収益メカニズムは、コンピューティング サービスの品質の向上とリソースのアップグレードを促進し、経済は需要と供給の関係を調整する最も重要なメカニズムです。グリッド リソースにアクセスするユーザーに公正な価格メカニズムを提供し、すべてのリソースを取引できるようにします。システム中心ではなくユーザー中心のスケジューリング ポリシーを確立して、リソースの割り当てと管理に効果的なメカニズムを提供します。

2. リソース スケジューリング アルゴリズム

さまざまなリソース スケジューリング モデルを目指して, 多くの学者が独自のさまざまなアルゴリズムを提案しています. アルゴリズムに基づく目的関数には、通常、時間最適化アルゴリズム、コスト最適化アルゴリズム、および時間コスト最適化アルゴリズムが含まれます. 時間最適化アルゴリズムの出発点は、予算内でできるだけ早くタスクを完了し、以前に割り当てられたタスクと完了率を考慮して、各リソースのタスクの完了時間を見積もることです。そして、リソースを完了時間に従って昇順にソートし、キューからリソースを 1 つずつ取り出します。

タスクのコストがタスクの予算以下の場合、タスクはこのリソースに割り当てられます。コスト最適化アルゴリズムは、最小コストで完了期限内にタスクを完了しようとします. 基本的な考え方は、最初にリソースを価格の昇順にソートし、スコープ内のキュー内の各リソースにできるだけ多くのタスクを割り当てることです.完了期限; 時間コスト 最適アルゴリズムは、上記の 2 つのアルゴリズムの利点を組み合わせて、追加の処理コストを追加することなく処理時間を最適化します。

アルゴリズムのさまざまなスケジューリング戦略と目的関数を考慮すると、リソース スケジューリング アルゴリズムは、次のようにさまざまな基準に従って分類できます。

  1. 従来のスケジューリング アルゴリズム: ラウンド ロビン スケジューリング、最小接続スケジューリング、ターゲット アドレス ハッシュ スケジューリング、送信元アドレス ハッシュ スケジューリングなどは、アルゴリズムは単純ですが、パフォーマンスは低くなります。
  2. ヒューリスティック マッピング スケジューリング アルゴリズム: リソース スケジューリング要素は複雑であるため、通常はヒューリスティック アルゴリズムが使用されます。スケジューリング アルゴリズムの実行時間に応じて、ヒューリスティック マッピング スケジューリング アルゴリズムは、静的マッピングと動的マッピングに分けることができます。動的スケジューリング アルゴリズムは、オンライン モードとバッチ モードに分けられます. 典型的なオンライン モードのヒューリスティック アルゴリズムには、最小完了時間 (最小完了時間、MCT)、最小実行時間 (最小実行時間、MET)、スイッチング アルゴリズム (スイッチング アルゴリズム、SA)、K が含まれます。 -Percent Best Heuristic (KPB) および Opportunistic Load Balancing (OLB) など。典型的なバッチ モードのヒューリスティック アルゴリズムには、min-min アルゴリズム、max-min アルゴリズム、fast greedy アルゴリズム、greedy アルゴリズム、endurance アルゴリズム、および ageing アルゴリズムなどがあります。
  3. 経済モデルに基づくスケジューリングアルゴリズム:経済学における商品市場モデル、プライシングモデル、交渉モデル、入札・契約ネットワークモデル、オークションモデルに基づき、最適コスト、最適時間、時間コストなどの目的関数を用いて実現します。リソースのスケジューリング。
  4. インテリジェント エージェントに基づくスケジューリング アルゴリズム: 各リソース ノードはインテリジェント エージェントにカプセル化され、リソース管理システムはマルチレベルのインテリジェント エージェント システムの集合体になり、スケジューリングの問題は、インテリジェント エージェント間で計算タスクを一致させる方法として単純化されます。インテリジェントエージェントの変更を調整する必要があり、インテリジェントエージェントでサブタスクを引き続き割り当てる方法に応じて時間。
  5. タスクの性質とタスク間の相関に基づくアルゴリズム: スケジューリング アルゴリズムは、独立したタスク スケジューリング アルゴリズム、分離可能なタスク スケジューリング アルゴリズム、従属タスク スケジューリング アルゴリズム、および多次元 QoS 要件と負荷分散タスク スケジューリング アルゴリズムに分けることができます。
  6. ゲーム理論に基づく資源スケジューリングアルゴリズム: ゲーム理論は経済学における重要な理論的手法であり、資源配分と社会経済活動の類似性から、ゲーム理論は資源配分研究にも広く利用されています。
  7. その他のスケジューリング アルゴリズム: 上記で紹介したリソース スケジューリング アルゴリズムに加えて、信頼モデルに基づく信頼できるリソース スケジューリング アルゴリズム、タスク依存スケジューリング アルゴリズム、多次元 QoS 要件スケジューリング アルゴリズム、負荷など、いくつかの改善された包括的なスケジューリング アルゴリズムがあります。 - エネルギー消費などに基づくバランスのとれたスケジューリング アルゴリズムとリソース スケジューリング アルゴリズム。

クラウド リソース スケジューリング アルゴリズムは、グリッド コンピューティングと分散コンピューティングの研究結果から学習し、クラウド コンピューティング リソース スケジューリングの特性に注意を払うことができます。クラウド データ センターのリソース スケジューリングの特徴は、リソースの仮想化とユーザー指向のスケジューリング パフォーマンスの最適化です. 仮想マシンの出現により、すべてのコンピューティング タスクを仮想マシン内にカプセル化できます.

仮想マシンの分離により、仮想マシンの動的移行テクノロジーを使用してコンピューティング タスクの移行を完了し、リソースの最適化を実現できます。従来の分散コンピューティング環境では、リソースは無料であり、システムの全体的な最適なパフォーマンスがスケジューリングの最適化目標であることがよくあります。クラウド コンピューティング環境では、クラウド サービス プロバイダーがリソースとサービスを提供し、ユーザーはオンデマンドで料金を支払います。つまり、使用するリソースまたはサービスに対してのみ支払う必要があるため、クラウド環境でのスケジューリングの問題では、タスク実行のコスト制約を考慮する必要があります。

さらに、タスクの完了時間、報酬率、ユーザーの支払いなどのコスト関連の要因も、クラウド コンピューティングのスケジューリング問題で考慮する必要がある重要な制約です。従来の分散環境では、スケジューリングの最適化の目標はシステム中心であり、主にシステム スループットや CPU 使用率などのシステム パフォーマンスを対象としていましたが、ユーザーの QoS 要件はあまり考慮されていませんでした。クラウド コンピューティング環境では、リソースの使用率とシステム パフォーマンスの向上に注意を払うだけでなく、ユーザーの QoS 要件の確保にも注意を払い、リソースの供給とリソースの消費の双方にとって有利な状況を実現します。

3. リソース スケジューリングの抽象的な関係と一般的な手順

クラウド コンピューティングでは、リソース スケジューリングは非常に重要なコンポーネントです。異なるクラウドのリソースは異なり、対応するスケジューリング ポリシーも異なります。さまざまなクラウドが独自のニーズに応じて独自のポリシーと動作を定義できるように、これらのさまざまなスケジューリング用の比較的一般的なフレームワークをどのように設計するかが、クラウド コンピューティング リソース スケジューリングの難しさです。

一般的なリソース管理システムは、一般に、次の図に示すように、リソース コンシューマー インターフェイス、リソース プロバイダー インターフェイス、リソース マネージャー サポート インターフェイス、およびピア インターフェイスで構成されます。

グリッド コンピューティングやクラウド コンピューティングでは、リソース スケジューリング システムがコアであり、その基本的な機能は、リソース要求を受信し、リソース プールまたはクラウドから要件を満たすリソースを要求元に割り当てることです。リソースのスケジューリングには、通常、次の 4 つの手順が含まれます。

  1. リソース要求: リソース コンシューマは、要求されたリソース要件情報をリソース管理システムに送信します. リソース要件情報は、複数のコンポーネント要素で構成されています. 仮想化ベースのクラウド コンピューティング製品では、各コンポーネントは仮想マシンまたは物理マシンのリソースです. . 説明情報のコレクション。
  2. リソースの検出: 特定の要件に従ってリソースを検索し、検出を通じてすべての適格なリソースのリストを取得します. リソースの検出には、主に、リソース情報の格納形式、リソースの解放 (転送) 方法、およびリソースの発見方法の 3 つの側面が含まれます。
  3. リソース選択: リソース選択戦略に従って候補リソース リストから最適なリソースを選択し、リソースをリクエスタに割り当てます。リソースの選択には、リソースの候補を評価する基準となる選択最適化の目的(効用関数)を定義することと、リソースの候補から最適なリソースを選択する適切なアルゴリズムを選択することの2つの側面があります。ユーティリティ関数. リソース. 
  4. リソース監視: リソース管理の最終段階は、選択された最適なリソースをリソース要求者に提供し、リソースを監視することです。リソースが異常な場合は、リクエスタ リソースに再割り当てしてリクエスタがリソースを使用できるようにすることができます。リソースが使用された後は、仮想マシン ファイルを削除するなど、リソースを回復するためのクリーンアップ作業を実行する必要があります。

4. 仮想化リソース管理ディレクトリのシステム構成とエンジン設計

1. リソース ディレクトリ サービスの全体的な設計思想

仮想資源管理ディレクトリのシステムアーキテクチャ設計は、以下の考え方に従っています。

  1. 厳密な階層関係: システムは厳密な階層化を実装し、階層化は各層内で継続できます。
  2. トップダウンおよび漸進的な改良: システムのトップからボトムまで設計および実装します。
  3. 仮想実装: 上位層が実装されると、それが依存する下位層が実装されていると見なされますが、システムを実行し続けるために、実現されていない下位層の機能については「空の」実装のみが与えられます。 、所定のテストデータを直接返すか、動作状態フラグに直接戻るように求められます。

2. システム全体のアーキテクチャ設計

システムアーキテクチャとは、システムの内部構造、つまり、システムのアルゴリズムと基本的なデータ構造の上の実装構造を指します。アーキテクチャはユーザーに対して透過的であり、システムのパフォーマンスを決定します。

次の図は、システムの全体的なアーキテクチャ設計を示しています。

システム アーキテクチャの設計図は 6 つの部分に分かれており、最下層から上位層まで、データ層、永続層、中間層、ロジック層、プレゼンテーション層、ユーザー層に分かれています。

1) データ層

システムのデータ ストレージ層には、ローカル データとネットワーク データが含まれます。ローカル データには、システム ログ、リソース ディレクトリ、サーバー型データベース、ファイル ライブラリなどが含まれます。ネットワーク データには、すべての構造化、半構造化、および非構造化情報リソースが含まれます。 

  • サーバー型データベースには、構造化データとシステムデータテーブルが格納されます. 構造化データには、地域、産業、指標、時間に関するデータなど、さまざまな機関によって収集されたフォーマットデータが含まれます. システムデータテーブルには、ユーザーデータテーブルとユーザー個人のレコードテーブルが含まれます.
  • リソース情報管理システムではコンテンツ管理が大部分を占めるため、ファイル ライブラリの負荷圧力は比較的高く、複数のファイル ライブラリを使用してコンテンツを格納します。それは、サブライブラリ ストレージを実現し、各ファイル ライブラリの負荷圧力を軽減することです.さらに、リソース ディレクトリ ライブラリとログ ファイル ライブラリがあります.リソース ディレクトリは、eXtensible Markup Language (eXtensible Markup Language, XML)ファイル ストレージを使用して、リソース ディレクトリはプラットフォームに依存せず、プラグ アンド プレイが可能です。

2) 永続層

リソース ディレクトリ パーシスタンス マネージャー、Hibernate データ アクセス オブジェクト (Data Access Objects、DAO)、ファイルの読み書きエンジンなどを含みます。

  • Resource Directory Persistence Manager: リソース ディレクトリの保存形式として XML を使用して、リソース ディレクトリを保持し、読み取ります。XML ベースの機能は、リソース ディレクトリのホット プラグのサポートを最大化し、異種リソース ディレクトリの同期を可能にします。さらに、異種プラットフォームでのリソース ディレクトリ交換のコストが最小限に抑えられ、リソースを変更せずに別の異種プラットフォームに接続できます。
  • Hibernate DAO: リレーショナル データベースの永続化に使用され、構造化データへのアクセスをサポートします。また、優れた柔軟性、スケーラビリティ、プラットフォームの独立性、および構成可能性を備えており、プラグイン機能と一致しています。情報リソースにはリレーショナル データベース リソースが含まれ、これらのリソースの永続性とアクセスはこの DAO に依存すると同時に、システムはユーザー管理、インターフェイス プレートのカスタマイズ、フロー レビュー、ユーザー機能などの機能を提供します。これらの関数のデータはすべてリレーショナル データベースに格納され、これらのデータへの永続性とアクセスはすべてこの DAO に依存します。この DAO を操作するエンジンには、データ取得エンジン、データ処理エンジン、データ結合エンジンが含まれる場合があります。 、データ取得エンジン、データ取得エンジンセンターなど
  • ファイル読み取りおよび書き込みエンジン: 呼び出しエンジンに属するコンテンツ リソースの永続化に使用されると同時に、ファイル ライブラリの負荷を動的に評価して、各ファイル ライブラリの負荷分散を実現します。

3) 中間層

リソース ディレクトリ エンジン、Luence (オープン ソースの検索エンジン フレームワーク、元は Java バージョン、.net、C++、Pascal およびその他の言語には対応するバージョンがあります) 検索エンジン、ウイルス検出およびデータ センターなどを含みます。

  • リソース ディレクトリ エンジン: リソース ディレクトリの挿入、更新、削除、読み取り、インポート、およびエクスポートなどのサービスを提供するサーバー タイプのエンジンです。これは、このシステムの重要なモジュールであり、リソースのインデックス作成を提供し、セキュリティ、バージョン管理、パイプライン、ロックなどのサービスを提供できます。リソース ディレクトリ エンジンのコアはリソース ディレクトリ ツリーであり、ディレクトリ ツリーを操作するための一連の機能インターフェイスを提供し、情報リソース ディレクトリ プラットフォームにディレクトリ サービスを提供します。
  • Luence 検索エンジン: リソースの全文検索サービスを提供し、リソース ディレクトリ エンジンと連携します。リソース ディレクトリは Luence 検索エンジンのデータ ソースであり、エンジンはリソース ディレクトリの変更に従ってインデックス ライブラリを更新します。全文検索を実現するためには、リソースコンテンツを細分化し、キーワードを取得した後にインデックスを構築する必要があります。
  • リソース ライブラリが悪意のあるウイルスによって侵略されるのを防ぐために、保存されているリソース コンテンツに対してウイルス検出を実行する必要があります。ウイルス検出層は、呼び出し元サーバーに属する中間層でウイルス検出サービスを提供するためのミドルウェアとして表示されます。
  • データセンター:サーバー型データベースでは、各機関や集中型サーバーのデータが同期されていないため、各機関のサーバー型データベースを同期させて総合的な分析などを行う必要がある場合が多い同時に、各機関が使用するサーバー プラットフォームのために、Web サーバー、サーバー データベース、およびデータ テーブルが同形であることが保証されておらず、異種データベース テーブルの同期の問題を解決する必要があります。センターは、異種データベースの同期とデータ交換を担当します。

4) ロジック層

ユーザー管理、検索、データ取得、データ処理、データ結合、データ取得、データ ストレージ制御エンジン、Web サービス エンジン、および「情報リソース ディレクトリ プラットフォーム エンジン」と呼ばれるその他のモジュールを含みます。

  • ユーザー管理: ユーザー権限管理とシステム アクセス制御管理を含み、シングル サインオン、マルチシステム共有ログイン、ページ機能権限制御からリソース ノード レベルの権限制御までを実現します。
  • 検索:全文検索、専門検索、二次検索など 全文検索は一般的な一般的な検索ですが、専門検索は検索条件のカスタマイズを実現します。
  • データ取得: リソース ディレクトリ、リソース コンテンツ、ログ ファイルなどの読み取り、リソース データをカプセル化してアプリケーション サービスに対して透過的にすることを含みます。
  • データ処理: 主な抽象操作には、変換、クリーニング、スクリーニング、更新、同期、置換、保存、およびデータ分類 (中国図書館法、統計年鑑法、カスタム分類法などによる) が含まれます。
  • データの結合: リソース プール内のデータを戦略に従って再編成、マージ、および多次元処理し、リソース プール内に新しいデータ リソースを形成します。
  • データ収集: Web およびローカル情報リソースの収集を含む、戦略に従って外部データをシステムに収集します.Web コレクションは、特定の戦略を定義することにより、Web ページをシステムに自動的にダウンロードします.
  • データ アクセス制御エンジン: 各機能モジュールの使用ポータルの操作指示を受け取り、関連するモジュールが対応する操作を実行するようにスケジュールすると同時に、バッファ プール全体のメンテナンスと各機能のライフ サイクル管理を担当します。モジュール。リソース コンテンツは、ローカルまたはネットワークの場合があり、構造化データ、半構造化データ、非構造化データなどの場合があります。このため、エンジンは情報リソース コンテンツのパスの違いを外部に隠し、一貫した読み取りおよび書き込みインターフェイスを提供します。内部では、情報リソース コンテンツのパスに従ってリソース コンテンツを割り当ててプルします。
  • Web サービス エンジン: 情報リソース ディレクトリ プラットフォーム エンジンのオープンな Web サービス指向インターフェイスは、リモート アクセスをサポートします. 情報リソース ディレクトリ プラットフォームは、リソース アクセス制御、リソース アクセス、リソース結合、リソース処理、リソース収集などのアプリケーションを統合します。リソースクリーニングです。ユーザーのネットワーク サービスに対するニーズの高まりと多様化に対応するには、プラットフォーム エンジンに Web サービス サポートを提供する必要があります。つまり、システム間の通信をサポートするクロスプラットフォームでプログラミング言語に依存しない方法を提供するため、プラットフォーム エンジン、つまり Web サービス エンジンに Web サービス アクセス インターフェイスを提供する必要があります。

5) プレゼンテーション層

ウィンドウ スタイルの Web クライアントと Google World Wide Web Toolkit (Google Web Toolkit、GWT) リモート処理呼び出し (Remote Procedure Call、RPC) エンジンを含みます。

  • ウィンドウ化された Web クライアントは、Windows エクスプローラーに似た対話型インターフェイスを提供し、ユーザー エクスペリエンスが向上します。
  • GWT RPC エンジンは、ファット クライアントとサーバー間の通信に AJAX リモート呼び出しの豊富なインターフェイスを提供します. このシステムの Web クライアントのすべてのデータ通信は、これらのインターフェイスを介してアップリンクおよびダウンリンク データの送信を実現します.

3. エンジン設計

情報リソース ディレクトリ プラットフォームには、取得、結合、処理、収集、クリーニング、およびスクリーニング アプリケーションなど、情報リソース管理のためのさまざまなアプリケーションが含まれています。これらのアプリケーションを統合してリモート ユーザーにサービスを提供するには、これらのサービスを管理するために、疎結合でプラットフォームに依存しないフレームワークが必要です. サービス指向アーキテクチャ (SOA) システムに基づくプラットフォーム エンジンは、リモート ユーザーにコマンドとデータを提供できます。 .

1) Webサービスをベースとしたエンジンアーキテクチャ

Web サービス ベースのアプリケーション統合は、現在、エンタープライズ アプリケーション統合の最も先進的な方法です. インターネット分散サーバーまたは中央サーバーを介したアクセス方法を提供できます. 企業とユーザーは、標準インターフェイスといくつかのパブリック サービスを介して発見、記述、および使用できます. これらの共有シリーズサービスの。

Web Service は SOA の実装技術であり、インターネット環境におけるエンタープライズ アプリケーションの統合と疎結合を実現するために使用されます。Universal Description Discovery and Integration (UDDI) 標準に従って、Web サービス標準は名前とディレクトリを使用してサービスを検索し、WSDL 言語仕様を使用してサービスを記述します。これらのメッセージ オブジェクトは Simple Object Access Protocol SOAP を使用します。

システムの元のアプリケーションの場合、Web サービスに基づくアーキテクチャは、元のシステムを変更せず、元のアプリケーションに影響を与えることなく、元のシステムに基づいて SOAP インターフェースを追加するだけでよく、異なるテクノロジーによって実現されるシステムの相互接続により、相互のデータ交換が提供されます。アクセス操作など、さまざまなシステムが連携してより強力なシステムを形成できます。

情報資源仮想化管理エンジンの構成を次の図に示します。

2) プロトコル仕様

Web サービスに基づくエンジン フレームワークでは、ログイン、ログアウト、ディレクトリへのアクセス、現在の作業ディレクトリの下のサブディレクトリとリソースの一覧表示、ディレクトリの作成、ディレクトリの削除、リソースの書き込み、リソースのクエリなど、さまざまなアクセス項目をエンジン間でサポートする必要があります。 、リソースの更新、リソースの削除、およびインポート、エクスポート、ヘルプなど。

設計時には、コマンド名、オプション、および関連するパラメータを理解しやすいように設計する必要があるため、ここでは詳しく説明しません。 

5. 典型的な仮想リソース マネージャー フレームワーク

仮想リソース管理の特性と要件によると、仮想リソースの記述は、従来の物理リソースの記述よりも難しく複雑です。オントロジーとは、存在、本質、法則についての理論であり、その目的は、現場の知識を獲得し、現場の知識や概念の共通理解を達成することです。そして、現場の語彙の統一性を判断し、異なる形式化・標準化レベルの語彙間の関係を明確に定義する. そこで、オントロジーに基づくリソース仮想化手法を用いて以下のケースを分析する.

仮想資源の合理的な利用を実現するには、まず資源を管理できなければなりません。仮想リソースを効果的に管理するには、対応する仮想リソース マネージャーを確立する必要があります。次の図に示すように、確立された仮想リソース マネージャー フレームワークです。

仮想資源マネージャは、主に3つの層、すなわち仮想資源層、仮想資源プール層および仮想資源管理層を含む。

以下についてそれぞれ説明します。

1. 仮想リソース層

実際のリソースに基づいて、前述の方法を使用してリソースの仮想化とカプセル化を実現し、オントロジー分析エンジンは仮想リソースの情報とステータスを更新、認識、クエリし、リソースをリアルタイムで監視および動的に制御できます。

2. 仮想資源プール

仮想リソース抽象モデル、仮想リソース結合モデル、仮想リソース ネゴシエーション モデル、対応するモデル分析エンジン、ナレッジ ベース、リソース マッピング、リソース基準などを含む。仮想リソース プールを確立するには、物理​​リソースと仮想リソースの間のマッピング関係を定義して、一連の仮想リソース マッピング モデルを構築する必要があります。

物理リソースと仮想リソース間のマッピング関係は、3 つの基本的なタイプに分けることができます. 1 つは 1 対 1 マッピングであり、最も基本的なリソース マッピング関係に属します. たとえば、単一の機能を持つ物理デバイスのみをマッピングできます.もう 1 つは 1 対多のマッピングで、複数の機能を持つ物理リソースに適しています。単一の機能を独立した仮想リソースとしてマッピングできます。たとえば、複数の機能モジュールを持つソフトウェア ツールを複数の仮想ソフトウェア ツールとしてマッピングできます。3 つ目は多対 1 マッピングです。これは主に、複数の物理リソースの組み合わせと調整に関する特定の論理関係と制約に従って、複数の物理リソース要素を仮想リソースにマッピングします。

たとえば、複雑な製品のシミュレーション計算タスクでは、高性能コンピューティング システム リソースが必要になることが多く、ストレージ リソース、コンピューティング リソース、およびシミュレーション ソフトウェアを組み合わせて仮想マシンにマッピングすることができます。論理的な関係を持つ物理リソースの組み合わせについては、複数の製品ソフトウェア ツールの機能インターフェイスを仮想設計ソフトウェアに結合し、結合されたプロセス ロジック、制約、コラボレーション ルールを同時に定義する必要があります。

3. 仮想リソース管理層

主に、仮想リソースのカプセル化、登録/リリース管理、モデル管理、展開とバインド、QoS モデルと評価管理、インテリジェントな検索とマッチング管理、スケジューリングと監視管理、セキュリティ管理とオンライン リアルなど、仮想リソース ユーザーに対応する機能を提供します。 -時間動的最適化管理など カプセル化/登録/解放管理は、仮想リソースのカプセル化と、仮想リソース プール ディレクトリでの登録および解放管理に使用されます。

モデル管理は、物理リソースと仮想リソースの間のマッピング モデル、および仮想リソースの抽象記述テンプレートを管理するために使用されます. クラウド サービスが特定のリソースを呼び出す必要がある前に、マッピング モデルに従って仮想リソース テンプレートをインスタンス化する必要があります.そして、運用環境の展開と展開が完了している必要があります。

QoS モデルと評価管理は、仮想リソースと物理リソースのサービス品質のモデル管理と、さまざまな指標の評価に使用されます。インテリジェントな検索とマッチング管理を使用して、クラウド サービスのリソース要件に従って、仮想リソース プールから適切な仮想リソース テンプレートまたは仮想リソース インスタンスを見つけて取得します。リソースの状態取得、イベント通知、タスクのスケジューリング、リソースの監視と制御の管理には、スケジューリングと監視の管理が使用されます。セキュリティ管理は、仮想リソース プールのユーザー認証、アクセス制御、およびセキュリティ監査の管理に使用されます。オンライン リアルタイム動的最適化管理は、多目的多制約最適スケジューリング、リソース組み合わせの動的置換、負荷分散、およびフォールト トレラント マイグレーションの管理に使用されます。

次の図に示すように、仮想リソース マネージャーに基づいて、オントロジー記述に基づく仮想リソースの検索およびスケジューリング プロセスを実現できます。 

このプロセスは主に、仮想リソースの解放プロセスと仮想リソースの検索およびスケジューリング プロセスの 2 つの部分に分けられます。詳細は次のとおりです。

  1. リソース提供者は、トップレベルのオントロジー マッピング規則に従ってリソースをリソース オントロジーとして記述し、リソース登録および公開機能を使用して、リソース オントロジーを仮想リソース管理に提出します。
  2. 次に、リソースオントロジーは、トップレベルのオントロジーマッピングルールに従って、システム内のオントロジー解析エンジンによって解析されます. ここでは、サービス用のオントロジー言語 (Web Ontology Language for Services, OWL-S) 解析エンジンが使用されます. 解析後,仮想資源オントロジー・ライブラリーに入ります。
  3. 仮想リソースを正確に取得できるようにするために、分析されたオントロジーは、対応する仮想リソース情報も仮想リソース ディレクトリに追加します。これには、主に仮想リソース ID、名前、属性などの基本情報が含まれます。これまでのところ、仮想リソース オントロジー ライブラリと仮想リソース ディレクトリが形成され、仮想リソースのリリース プロセスと対応するレビュー プロセスが完了しています。
  4. 仮想リソースのユーザーは、リソースの属性、機能と非機能、およびその他の使用要件情報を、システムが解析して仮想リソース マネージャーに送信できる形式で記述します。
  5. 仮想リソース要件を受け取った後、仮想リソース マネージャーはインテリジェントな検索およびマッチング機能を呼び出してリソースを見つけます。これは、仮想リソース マネージャーのコア機能の 1 つです。基本的な属性、分類、機能、入出力の前提条件と効果 (Input Output Precondition Effect、IOPE) の一致など、オントロジーに基づく類似性によって、仮想リソース ディレクトリ内のリソースの記述情報と要件を一致させ、対応するマッチング アルゴリズムには、テキスト マッチング、ファジー関数マッチング、階層分析マッチング、構造ツリー マッチング アルゴリズムなどがあります。類似性比較の後、通常は機能要件のみを満たすことができる候補仮想リソースのリストが取得されます。ただし、QoS 要件などの非機能要件は考慮されていないため、インテリジェント検索およびマッチング機能は、前の候補仮想リソース リストに対して非機能マッチングをさらに実行します。QoS や SLA などの非機能記述を含む仮想リソース オントロジー ライブラリ内の仮想リソースを要件と比較することにより、ユーザーの機能要件と非機能要件の両方を満たす候補仮想リソースのリストが最終的に取得され、返されます。ユーザーに。
  6. システムによる自動インテリジェント検索とマッチングによって得られた候補仮想リソースのリストが複数ある場合があるため、デフォルトの仮想リソースを考慮するだけでなく、ユーザーは自分のニーズに応じて手動で選択することもできます。選択したリソースを決定した後、仮想リソース オントロジー ライブラリから対応するリソース バインド情報を取得し、要件またはタスクを特定の物理リソースにバインドして、要件を実現するか、タスクを完了します。
  7. リソースのバインドが完了すると、システムはタスクまたは需要情報を実際の物理リソースに送信し、実際のリソースはタスクを完了します。
  8. 実際のリソースは、リソースの要件またはタスクを受け取った後、合意されたサービスレベルでタスクを完了することができ、使用プロセス中に対応するリソースの監視を受け入れる必要があります。リソースの利用過程や利用後のリソースの状態や能力などの情報は変更される可能性があり、変更された情報はオントロジー情報として再記述され、仮想リソースディレクトリと仮想リソースオントロジー情報が更新されます。オントロジー記述に基づく仮想リソース検索とスケジューリングの適用事例は、提案されたリソース仮想化方法が要件を満たすことができることを検証します。

以上の作業は単一リソースの仮想化記述のみを考​​えた. 実際, クラウド製造環境では仮想リソース間に対応する組み合わせ関係がある. したがって, 本節で提案するオントロジーモデルを使用して組み合わせ後の仮想リソースを記述する方法. 、および使用方法 上記のリソースモデルは、タスクの特性に応じて仮想リソースの自動集約を実現し、仮想リソースの検索とマッチングをより効率的にするためのすべての問題であり、次のステップで解決する必要があります。

仮想資源の管理に関して、今後さらに検討が必要な主な内容は以下のとおりです。

  1. 多段階の動的リソース割り当て: ユーザーはリソースの予約や従量課金制など、複数の方法でクラウド リソースを使用できるため、データ センターのリソース プロビジョニングの実装はさまざまな段階に分けられます。また、リソースの需要は不確実であるため、ユーザー需要の動的な不確実性の下で、クラウド データ センターの収益とリソース使用率を改善する方法を検討する必要があります。
  2. QoS の制約: クラウド アプリケーションの多様性により、クラウド ユーザーの QoS に対する要件が異なります.ユーザーに異なる SLA を備えたクラウド アプリケーション サービスを提供し、ユーザーの QoS 要件が確実に満たされるように SLA の測定、監視、および罰則メカニズムを確立する必要があります.
  3. 複数のデータセンターのリソース割り当て: 複数の異なるメーカーや企業のデータセンターを組み合わせることで、より大きな動的スケーリング リソース プールを確立して、リソースの提供を拡張できます。

おすすめ

転載: blog.csdn.net/qq_35029061/article/details/128786120