| Oracle® Enterprise Manager Cloud管理ガイド 12c リリース5 (12.1.0.5) B70509-13 |
|
 前 |
 次 |
この章では、Oracle Enterprise Manager Cloud Controlによって提供される統合プランナ機能の使用方法を説明します。
この章の内容は次のとおりです。
長年にわたり、標準的なエンタープライズ・データ・センターは、ビジネスのニーズを満たすために必要とされるサーバーの追加のため、絶え間なく成長を続けています。この成長は、多くの場合、ラック・スペースを占領し、冷却のために多くの電力を消費し、セキュリティやパッチなどのシステムのメンテナンスを必要とする、多すぎるサーバーという事態を招きます。
調達サイクルまたは特定のハードウェア・ベンダーと結んだ契約のため、企業は異なるタイプのサーバー・ハードウェアおよびオペレーティング・システムを手にすることになり、ふとしたことからシステム配置の混乱を生み、管理者による管理や運用、パッチ、アップグレードを必要とすることになります。その結果、仕事を増やし、IT予算における、絶え間のないメンテナンスとサポートのコストが増加します。企業は、コスト削減の究極の目標である、種々雑多なシステムを標準化されたオペレーティング・システムおよびハードウェアに移行する手段として、統合に注目しています。
企業はまた、物理サーバーから仮想サーバーに移行する、Oracle仮想マシンのような仮想化テクノロジについての調査を進めています。これは、仮想化がもたらす独立性の利益を得る一方で、共有ハードウェア・インフラストラクチャの使用を可能にします。
統合の目的は、そのような十分に活用されていないサーバーを見つけ出し、それを統合する手段を発見し、企業がそのサービス・レベルを維持しながら、できるかぎり多くのサーバーを解放できるようにすることです。それぞれのサーバーの持つCPU容量のレベルが異なるため、統合プランナは、与えられたハードウェアのCPU使用状況を正規化するため、統合プロセスでコンピュータのベンチマーク・データを使用します。特に、統合プランナでは、ハードウェアの様々なクラスに、次のCPUベンチマークを使用します。
SPECint®_base_rate2006: データベース・ホスト、アプリケーション・ホストまたは混合ワークロード・ホスト
SPECjbb®2005: ミドルウェア・プラットフォーム
統合プランナでは、統合する管理対象ターゲット・ソースを新規または既存のターゲット宛先と一致させることができます。汎用的な物理マシンであるOracle Engineered System (Exadataデータベース・マシンまたはExalogic Elastic Cloudシステム)またはOracle Virtual Machine (VM)サーバーにソース・サーバーを統合します。
また、Oracle Cloudで構成されている物理マシンにソース・サーバーを統合できます。このタイプの統合では、Oracle Cloud Compute構成はホストを模倣します(検討するリソースとして重要なメモリーおよびCPU性能だけは除く)。
統合プランナでは、Enterprise Manager Cloud Controlによって管理対象ターゲット・サーバーから収集されたメトリックおよび構成データを利用でき、最適な統合シナリオを決定でき、それは、統合プロセスでビジネスおよび技術的な制約にも反映されます。
次の概念が、統合プランナ使用の中核となります。
ソース・サーバー
統合の対象となる既存のサーバーです。
宛先サーバー
ソース・サーバーをそれに統合する既存または購入前のサーバーです。統合のターゲットと考えることもできます。これには、個々のマシン、仮想サーバー・プール、Oracle Exadata Database MachineやExalogic Elastic Cloudシステムなどのエンジニアド・システム、またはOracle Cloud Compute構成を使用できます。
次のようなものを含み、統合作業を可能とする有効範囲を定義します。
統合のタイプ現在のリリースでは、2つのタイプの統合スキーマがサポートされています。
P2V: 物理的なソース・サーバーからOracle仮想マシン(VM)の宛先サーバー
P2P: 物理的なソース・サーバーから物理的な宛先サーバー
統合元の検討対象とするソース・サーバー候補の仮のセット
統合先の検討対象とするソース・サーバー候補の仮のセット
統合シナリオの生成に使用されるデータがソース・サーバーから収集される期間
宛先サーバーに統合できるソース・サーバーの数を決定するときの、CPU容量の測定に使用されるベンチマーク
それぞれの統合プロジェクトには、次のような入力に基づいて生成される1つ以上の統合シナリオがあります。
宛先サーバーが満たさなくてはならないソース・サーバーのリソース要件(CPU、メモリー、ディスクI/O、ネットワークI/Oおよびディスク・ストレージの1つ以上)。
考慮する必要のある、なんらかのビジネス、コンプライアンスまたは技術的制約
シナリオで考慮する宛先サーバー
事前構成された統合シナリオのセットが提供されており、保守的な統合シナリオ、中間的な統合シナリオ、積極的な統合シナリオがあります。それぞれのシナリオは、お客様の入力を基に生成されます。また、お客様の状況に最適な独自のカスタム・シナリオを作成することもできます。作成したら、どの統合計画が要求に最適かを判断するため、様々なシナリオを比較できます。
それぞれのシナリオには、統合される各ソース・サーバーと宛先サーバー間の初期のマッピングも含まれます。マッピングは、手動生成、または統合プランナによる自動生成を選択できます。すべての入力を指定したら、シナリオを実行してその結果を評価できます。その後、前に指定された条件に基づくシナリオを、使用可能な最新のデータを使用して再評価するために、シナリオを返すこともできます。前の分析の結果は上書きされます。既存のシナリオに基づいて新しいシナリオを作成し、特定の値を微調整して新しいシナリオをカスタマイズすることも可能です。
統合プランナでは、統合プロジェクトおよびシナリオの作成時に考慮すべき、様々な制約を指定できます。
この項の内容は次のとおりです。
ソース・サーバーには、互換性または排他性に基づく制約を定義できます。
互換サーバー
特定のプロパティおよび構成の値と一致する場合、サーバーは互換性があるとみなされます。
プロパティには次のものがあります。
ライフサイクル・ステータス
部門
場所
たとえば、データ・センターの場所または地理的条件のように、特定のサーバーを特定の場所に残す必要があるような場合です。
構成アイテムには次のものがあります。
ネットワーク・ドメイン
システム・ベンダー
システム構成
CPUベンダー
CPU名
オペレーティング・システム
たとえば、同じシステムとCPUベンダーを使用するアカウンティング・ポリシーがある場合です。
これらのターゲット・プロパティおよび構成アイテムの一部または全部に互換性を確立する、またはいずれにも確立しないことができます。
相互に排他的なサーバー
サーバーが特定のOracleベスト・プラクティスに反する場合、それらのサーバーを統合範囲から除外することができます。次のいずれかまたは両方の条件を設定して、一致するサーバーを除外します。
RACデータベースのノード: 同じRACデータベースのノードを単一の宛先サーバーに統合しません。
Oracle Clusterのノード: Oracle Clusterのノードを同じ障害グループに配置しません。
宛先サーバーでは、候補を新しい候補または既存の候補にスコープできますが、制約は主としてCPUおよびメモリー・リソースの使用率(宛先サーバーでリソース・タイプを最大どれだけ使用できるか)として表されます。
統合プランナのプロセスの手順は、次のとおりです。
統合プロジェクトを作成します。第44.2.1項「統合プロジェクトの作成」を参照してください。
プロジェクトに1つ以上の統合シナリオを定義します。次の2つのオプションがあります。
事前定義済の統合シナリオを使用。第44.2.1.5項「事前構成済のシナリオの選択」を参照してください。
カスタム統合シナリオを作成。第44.2.2項「カスタム統合シナリオの作成」を参照してください。
統合プランナ・コンソールで統合シナリオを評価し、ニーズに最適な統合戦略を決定します。第44.2.4項「統合シナリオの評価」を参照してください。
シナリオの設定を変更し、異なる結果を生成します。お客様の状況にとって最良のシナリオが得られるまでこの手順を続けます。
このリリースでは、計画の目的でのみ統合シナリオを作成できます。ソースから宛先へ実際にデータが移動するシナリオの実行は、サポートされていません。
複数のソースを複数の宛先に統合する場合、ソースのリソース要件は、宛先のリソース容量に対してチェックされます。識別されるすべてのソースを最小限の数の宛先に統合するために、統合プランナは、宛先の対応する使用可能なリソースにできるだけ厳密に適合する既知のリソース要件があるソースのセットを識別しようとします。
たとえば、宛先サーバーで使用可能なメモリーが2GBの場合、統合プランナは、必要なメモリーの合計が2GBにできるだけ近くて、宛先サーバー内のソース・サーバーに適合する、候補となるソース・サーバーのセットを見つけようとします。目標は、ソース・サーバーを最も少ない数の宛先サーバーへ「適合」させることです。
この項には、次の項目が含まれます。
各統合処理に対して、統合プロジェクトを作成し、個々の統合シナリオをその中に追加します。統合シナリオを比較して、どの統合方法が最も有用であるかを決定できます。
プロジェクトを定義した後で、指定したターゲットで使用可能なデータを管理リポジトリから収集するために、Cloud Controlジョブが発行されます。ジョブが終了すると、そのプロジェクトがアクティブなプロジェクトになります。プロジェクトがアクティブ状態にあるかぎり、データの収集が続きます。
|
注意: Exadata Engineered Systemにレガシー・ホストを統合するためのプロジェクトを作成する方法の視覚的デモンストレーションを表示するには、次のURLを使用して、「Oracle Enterprise Manager 12c: Consolidation Planner」というビデオを視聴してください。
|
作成プロセス全体を通してウィザードのガイダンスに従って、次の手順を実行します。
統合プロジェクトの一般的な情報を、次に示すとおりに指定します。
「エンタープライズ」メニューから、「統合プランナ」を選択します。
「プロジェクトの作成」ボタンをクリックします。
統合プロジェクト名と、オプションで説明を入力します。
物理ソース・サーバーからOracle VMサーバー(P2V)または物理ソース・サーバーから物理サーバー(P2P)のホスト統合タイプを選択します。
「次へ」をクリックして、ソースの候補を指定します。
次のようにソースの選択に進みます。
ドロップダウン・メニューから適切なベンチマークを選択します。
データベース・ホスト、アプリケーション・ホストまたは混合ワークロード・ホストには、SPECint®_base_rate2006を指定します。
ミドルウェア・プラットフォームには「SPECjbb®2005」を指定します。
「ソース・サーバーの追加」をクリックして、管理対象サーバー候補のリストから、統合するソース・サーバーを選択します。フィルタ基準を使用してターゲット検索を絞り込みます。フィルタした結果から選択し、「選択」をクリックします。
選択したターゲットが表に表示されます。選択したソース・サーバーを削除して、リストを間引くことができます。
オプションで、ディスクI/OリクエストのサーバーI/O容量とネットワークI/Oボリューム容量を設定します。「サーバーI/O容量の指定」をクリックして、統合プロジェクトに関係するすべてのソースについてこれらのI/O容量を見積もります。行をクリックし、様々な容量の値を編集することで、これらの見積もりを後で微調整できます。
「次へ」をクリックして、宛先の候補を指定します。
次のように宛先の選択に進みます。
オプションで、ソース・サーバーを統合する1つ以上の既存のサーバーを選択します。
物理サーバーからOracle Virtual Server (P2V)に統合する場合は、「既存の仮想サーバーを宛先として追加」をクリックし、ソース・サーバーの統合先となる既存のVMベースのExalogic Elastic CloudシステムとOracle Virtual Machineの宛先サーバーのリストを表示します。2つを区別するには、ターゲット・タイプ・フィルタを使用します。追加するサーバーを選択し、「選択」をクリックします。
選択したターゲットが表に表示されます。選択した宛先サーバーを削除して、リストを間引くことができます。
物理サーバーから物理サーバーに統合する場合は(P2P)、既存のOracleエンジニアド・システムを宛先として追加をクリックして、ソース・サーバーを統合するExadataデータベース・マシン・サーバーまたはExalogic Elastic Cloudサーバーを検索します。2つを区別するには、ターゲット・タイプ・フィルタを使用します。追加するサーバーを選択し、「選択」をクリックします。
選択したターゲットが表に表示されます。選択した宛先サーバーを削除して、リストを間引くことができます。
|
注意: 統合は、新しい宛先サーバーまたはソース・サーバーとして選択された既存のサーバーに対するものになります。 |
オプションで、行をクリックして値を変更することにより、見積もられたCPU容量、I/OリクエストおよびネットワークI/Oボリュームを編集します。「サーバーI/O容量の指定」をクリックしてI/O値を編集し、統合プロジェクトに関係するすべての宛先サーバーについてこれらのI/O容量を見積もることもできます。
「次へ」をクリックしてデータ収集を設定します。
統合シナリオを生成するのに使用されるデータを、「データ収集」リージョンのプロジェクトで指定したソース・サーバーに収集する期間を指定します。このデータは、宛先サーバーが満たす必要があるリソース要件を決定するのに使用されます。
データを収集する最小日数を指定します。デフォルトの最小値は21日です。実行に既存の履歴データを使用し、統合シナリオを即時に表示するには、日の最小値に0を指定します。
データを収集する最大日数を指定します。デフォルトの最大値は90日です。
データ収集プロセスの開始時を指定します。
データ収集が開始したら、「統合プランナ」コンソールの「アクション」メニューから収集の中断と再開をいつでも選択できます。
オプションで、最大日数の間データ収集を続行を選択して、新しい日付のデータが追加された場合に古い日付のデータをパージします。
「次へ」をクリックして、事前構成済のシナリオを選択します。
統合プロジェクトの作成時に、オプションで、最大3つの事前構成済の統合シナリオを生成するよう選択し、プロジェクトに追加できます。これらの即時利用可能なシナリオは、保守的、積極的および中間の統合スキームを表します。
プロジェクトの作成時に統合プロジェクトで定義されたソース・ターゲットに収集されたデータを使用して、これらのシナリオが生成されます。プロジェクトの作成時に使用可能なデータがない場合、最小量のデータを収集すると、事前構成済のシナリオが自動的に生成されます。
統合プランナには、保守的、積極的および中間の統合スキームを表す3つの即時利用可能なシナリオが付属しています。
適切なラジオ・ボタンをクリックして、事前構成済のシナリオを使用するかどうかを選択します。オプションを選択すると、使用できる即時利用可能な統合シナリオのリストが表示されます。デフォルトで、ソース・ターゲットのリソース使用量を日次で集計するのに使用される方法で、シナリオが指定されます。
積極的: 平均の日次の使用量に基づいて、時間ごとにデータを集計します。
この場合、通常、多くのソースが各宛先に適合するため、高い統合の比率(ソース:宛先)となります。しかし、多くのソースが含まれるため、1つ以上がリソースの要件を満たさない可能性が高くなります。
保守的: 最大の日次の使用量に基づいて、時間ごとにデータを集計します。
この場合、通常、ほとんどのソースが各宛先に適合しないため、低い比率(ソース:宛先)となります。
中: 80%の使用率に基づいてデータが集計されます。
この場合、通常、積極的な集計と保守的な集計の間の比率(ソース:宛先)となります。
使用する事前構成済のシナリオを選択します。いずれかまたはすべてのシナリオを選択できます。
シナリオの新規または既存の宛先を繰り込むかどうかを選択します。新規(phantom)サーバーを選択する場合は、リソース・メトリックの見積もりを指定します。
「次へ」をクリックして、統合プロジェクトを確認します。
統合プロジェクトで定義されたソース・サーバーに対して収集されたデータを使用して、プロジェクトを作成する場合、事前構成済のシナリオが生成されます。
統合プロジェクトが完了すると、独自のカスタム・シナリオを作成するよう選択することもできます。
統合プロジェクトの詳細を確認します。「戻る」ボタンを使用して、変更する手順に戻ります。問題ない場合は、「発行」をクリックします。メッセージにより、プロジェクトが作成され、ジョブが発行されたことが確認されます。
プロジェクトが作成されると、統合プランナ・コンソールに表示されます。統合シナリオをこのプロジェクトに定義できます。
事前構成済のシナリオを使用するかわりに、またはそれに追加して、カスタムの統合シナリオを作成できます。1つのプロジェクトで複数のシナリオを作成でき、ソリューションを決定する前に異なるシナリオを比較できます。既存の統合プロジェクト内に新しい統合シナリオが作成されます。
作成プロセス全体を通してウィザードのガイダンスに従って、次の手順を実行します。
シナリオの一般的なパラメータを、次に示すとおりに指定します。
「エンタープライズ」メニューから、「統合プランナ」を選択します。
シナリオの適用対象となる統合プロジェクトをクリックします。
シナリオの作成ボタンをクリックします。
シナリオ名など、シナリオの詳細を指定します。
対象となるソース・リソースを指定します。統合プランナは指定されたリソースを集計して合計の要件を決定します。
リソース・タイプ: CPU、メモリー(GB)、I/O容量など、考慮する必要のあるサーバー要件。
スケール係数: 各ソースの宛先におけるサイズ増加に備えて余裕を作ります。スケール計数は、統合の見積もりに余裕を持たせるために、リソース要件の見積に使用されます。たとえば、使用状況データに基づくと、指定されたソースの見積もり要件が、スケール係数1に相当するメモリー2GBで、1.1のスケール係数を指定している場合、そのソースの統合には2.2GBが必要です。
該当する日数: 週のうち、リソース使用量メトリックを収集する日数。
リソース割当て: 毎日のソース・サーバー・リソースの使用率の集計に使用するメソッド。値は次のとおりです。
積極的: 平均の日次の使用量に基づいて、時間ごとにデータを集計します。
この場合、通常、多くのソースが各宛先に適合するため、高い統合の比率(ソース:宛先)となります。しかし、多くのソースが含まれるため、1つ以上がリソースの要件を満たさない可能性が高くなります。
保守的: 最大の日次の使用量に基づいて、時間ごとにデータを集計します。
この場合、通常、ほとんどのソースが各宛先に適合しないため、低い比率(ソース:宛先)となります。
中: 80%の使用率に基づいてデータが集計されます。この場合、通常、積極的な集計と保守的な集計の間の比率(ソース:宛先)となります。
日付範囲には、標準的なリソース要件でよく使用される期間を定義する必要があります。
推定される合計のリソース要件を表示するには、推定要件をクリックします。
リソース要件は、集計された1時間ごとの要件に基づいて表示されます。表示される要件は、リソースに指定されたスケール係数(存在する場合)を反映しています。24時間の要件パターンは、統合ターゲットが満たす必要のある最低要件として使用されます。
「次へ」をクリックして、統合制約を定義します。
適用する必要があるビジネス、企業または技術的な制約を指定します。これらの制約は次の目的で使用されます。
ソースから宛先への自動マッピング中における割当てプロセスのガイド
ソースと宛先間の手動マッピングが使用されている場合の違反の計算
互換性のあるサーバーの基準を選択します。
サーバーは、同じターゲット・プロパティと構成が指定されている場合に互換性があると判断されます。複数のソース・サーバーを1つのターゲット・サーバーに統合する場合は、互換性のあるサーバーのみが同じターゲット・サーバーに統合されます。
相互に排他的なサーバーの基準を指定します。
特定タイプのソース・サーバーは相互に排他的であり、様々な理由で同じ宛先サーバー上に統合することができません。たとえば、Oracleクラスタのノードは、同じ障害グループに配置しないでください。
「制約の結果のプレビュー」をクリックし、定義済の制約に基づいて、互換性のないソース・サーバーのリストを表示します。
「次へ」をクリックして、宛先サーバーの候補を指定します。
要件を満たすために必要な宛先の候補を決定します。プロジェクト・タイプに従って続行します。
物理サーバーから仮想サーバーへのプロジェクト
物理サーバーから物理サーバーへのプロジェクト
物理サーバーから仮想サーバーへのプロジェクト
P2Vプロジェクトの場合:
次のいずれかのオプションを使用して、宛先サーバーの候補を選択します。
まだプロビジョニングされていないか購入されていないターゲット・サーバーを使用する場合は、「新規(ファントム)サーバーの使用」をクリックし、次のいずれかのオプションを選択します。
「Oracle Engineered Systemの使用」を選択し、検索アイコンをクリックして、Exalogic Elastic Cloudシステムの適切な構成タイプを選択します。
「汎用サーバーの使用」を選択し、可能な場合は予想されるCPU容量を指定します。それ以外の場合はCPU容量入力フィールドの横にある検索アイコンをクリックして、要件を最も満たすサーバー構成を選択します。
必要に応じて、メモリーおよびストレージの推定量を調整します。
仮想環境では、データベース・マシンでスーパーバイザ・ソフトウェアが使用できるように確保(予約)しておくリソースの量を指定することもできます。この量は、ソース・サーバーを残りのリソースに統合する前に、宛先の合計容量から差し引かれます。たとえば、予想されるメモリー要件が12GBで、2GBの予約を指定した場合、統合に使用できるのは10GBのみです。
統合プランナにより、統合結果の一部として、必要な宛先サーバー数が決定されます。
ターゲットとして使用する既存の管理対象サーバーのセットを指定するには、既存のサーバーを使用をクリックします。
これが、統合プロジェクトの範囲を定義する際に指定したサーバーです。統合プランナにより、収集された使用量のデータに基づいて、使用可能なハードウェア・リソースが決定されます。
デフォルトでは、できるだけ少ない数のターゲット・サーバーを使用して統合プロセスが実行されるよう設定されています。必要な場合は、宛先全体でソース負荷を平均化することを選択します。
「宛先サーバーで許可される最大リソース使用量」で、デフォルトを受け入れるか、割合を編集します。宛先サーバーにヘッドルームを提供するこれらの許容値を、個々のソース・サーバーにヘッドルームを提供するスケール係数と対比します。
「次へ」をクリックして、ソース・サーバーを宛先サーバーにマップします。
物理サーバーから物理サーバーへのプロジェクト
P2Pプロジェクトの場合:
次のいずれかのオプションを使用して、宛先サーバーの候補を選択します。
まだプロビジョニングされていないか購入されていない宛先サーバーを使用する場合またはOracle Cloud Computingを使用する場合は、「新規(ファントム)サーバーの使用」をクリックし、次から該当するオプションを選択します。
「Oracle Engineered Systemの使用」を選択して、Exadataデータベース・マシンまたはExalogic Elastic Cloudのいずれかを選択します。検索アイコンをクリックして、いずれかの選択に適した構成タイプを選択します。
「汎用サーバーの使用」を選択し、可能な場合は予想されるCPU容量を指定します。それ以外の場合はCPU容量入力フィールドの横にある検索アイコンをクリックして、要件を最も満たすサーバー構成を選択します。
Oracle Compute Cloudの使用を選択し、宛先として使用するクラウド計算構成(形状)を選択します。詳細は、第44.2.7項「Oracle Compute Cloud形状の検討」を参照してください。
必要に応じて、メモリーおよびストレージの推定量を調整します。
プロジェクトの宛先として使用する既存の管理対象サーバーのセットを指定するには、「既存のサーバーの使用」をクリックします。
これが、統合プロジェクトの範囲を定義する際に指定したサーバーです。統合プランナにより、収集された使用量のデータに基づいて、使用可能なハードウェア・リソースが決定されます。宛先の候補を明示的に指定しなかった場合は、すべてのソース・サーバーが統合の潜在的な宛先になります。
デフォルトでは、できるだけ少ない数の宛先サーバーを使用して統合プロセスが実行されるよう設定されています。必要な場合は、宛先全体でソース負荷を平均化することを選択します。
「宛先サーバーで許可される最大リソース使用量」で、デフォルトを受け入れるか、割合を編集します。宛先サーバーにヘッドルームを提供するこれらの許容値を、個々のソース・サーバーにヘッドルームを提供するスケール係数と対比します。
「次へ」をクリックして、ソース・サーバーを宛先サーバーにマップします。
次に、統合先の宛先にソースをマップします。目的は、ソース要件を、各宛先の使用可能なリソースにできるだけ厳密に適合させることです。
このマッピングは、統合プランナで自動的に実行することをお薦めします。そうすることで、リソース性能および指定されている様々な統合制約に基づいて、宛先のリソース使用率を最大化できます。
既存の宛先を選択した場合は、オプションで、各ソースおよび宛先を手動でマップできます。
リスト内のソースをクリックします。
懐中電灯アイコンをクリックし、ソースにマップする宛先を選択します。宛先には単一のソースまたは複数のソースをマップできますが、宛先は1つのみ指定できます。
結果の統合レポートには、手動マッピングが原因のリソースまたは制約の違反(あるいはその両方)が表示されます。
「次へ」をクリックして、統合シナリオを確認します。
新しいシナリオに設定されている様々なパラメータを確認します。オプションで、シナリオをテンプレートとして保存することもできます。変更が必要な場合は、「戻る」ボタンを使用します。それ以外の場合は、次のように続行します。
オプションで、テンプレートとしてシナリオを保存し、他のユーザーと共有できます。このことを実行する場合は、「シナリオをテンプレートとして保存」をクリックします。開かれたダイアログで、ローカル・ファイル・システムの場所を参照し、XMLファイルとしてテンプレートを保存します。
「発行」をクリックします。ジョブがシナリオのより詳細な分析のために発行されたことを確認するメッセージが表示されます。完了すると、統合プランナ・ページの下部に結果が表示されます。
既存のシナリオに基づいて統合シナリオを作成することもできます。統合プロジェクトの下で適用可能なシナリオを選択し、「アクション」メニューから「シナリオの類似作成」を選択します。必要に応じてシナリオを変更し、意味のある名前を指定して、通常どおり分析のために発行します。
テンプレートとしてシナリオを保存した場合、後でシナリオを別の環境にインポートできます。
統合プランナ・ホームページで、「アクション」メニューから「テンプレートからのシナリオの作成」を選択します。
ローカル・ファイル・システムで保存されたテンプレートXMLファイルを参照します。「開く」をクリックします。
保存されたテンプレートをレプリケートする範囲(テンプレートで表現されるリソース、制約およびターゲット計画)を示します。変更する場合は、「更新」をクリックします。
「OK」をクリックして、保存されたテンプレートをインポートします。
インポートしたシナリオは、統合プランナでシナリオを編集および保存できるウィザードで開きます。
統合プランナ・コンソールを使用して、統合シナリオの詳細を表示できます。統合シナリオの結果を評価したら、別の計画を定義することも、既存のシナリオを再実行し、使用可能な最新のデータで、前に指定された条件に基づいて再評価することもできます。前の分析の結果は上書きされます。既存のシナリオに基づいて新しいシナリオを作成し、特定の値を微調整して新しいシナリオをカスタマイズすることも可能です。この反復プロセスは、様々な要因に折り合いを付け、それぞれのトレードオフを秤にかけて生成される、最適化された統合シナリオを得るために役立ちます。
作成した統合シナリオを比較して、どの統合計画が最も要件を満たすかを決定します。
目的は次のとおりです。
ソース・リソースの要件を、その要件を最も満たす宛先と一致させます。
ソースの要件と各宛先の使用可能なリソースをできるだけ緊密に適合させ、宛先の容量を最大限に使用できるようにします。
リソース要件の係数としてヘッドルームを準備しておくことで、宛先におけるサイズ増加に備えて余裕を作ります。
オプションで、使用可能なすべての宛先全体で、ソースの作業負荷のバランスをとります。
現在のリリースでは、統合シナリオは計画目的でのみ作成できます。統合プランナを使用して統合シナリオを実行できません。
「エンタープライズ」メニューから、「統合プランナ」を選択します。
まず、表示するシナリオを含むプロジェクトを調査します。
「ステータス」列は、プロジェクトに指定された最小および最大の収集日数に基づいて、データ収集のステータスを示します。
「一般」タブは、プロジェクトをタイプ、収集の詳細、ソース数などで要約します。
「ソース」タブをクリックして、プロジェクトで定義されたソースに対して収集された様々な使用状況データを表示します。データには、プロジェクト・タイプに応じてCPU、メモリー、記憶域およびディスクとネットワークのI/Oの使用率が含まれます。
「ソース・ワークロード」タブをクリックして、収集されたソースのリソース使用量データを示すグラフを表示します。データは、月次スパンで24時間の期間ごとに表示されます。ビューは、ソース、リソース・タイプおよび月でフィルタできます。
「宛先候補」タブをクリックして、統合されるソースに基づいて、ハードウェア詳細および予測されるリソース使用率を宛先候補ごとに分類して表示できます。
プロジェクトが選択されているときに「レポート」ボタンをクリックし、要約された情報および詳細を表示します。
次に、特定のシナリオのデータを表示します。完了済の分析の場合は、詳細を表示する行で任意のメトリックをクリックします。「ソース」メトリックをクリックすると、シナリオのサマリーを表示できる「一般」タブが表示されます。その他のメトリックをクリックすると、次のように、それぞれのタブが表示されます。
宛先: ソースの統合先の宛先のリスト。宛先ごとにリソース構成および計算された使用量が表示されます。
クラウドへの統合で重要なリソースはCPU性能とメモリーです。
比率: 宛先に対するソースの比率。デフォルトでは、統合プランナはできるだけ少ない宛先にソースを適合させようとします。
マッピング: 特定のソースがマップされる宛先。分析には予想されるCPUとメモリーの要件および使用率が含まれ、考慮する推奨のCPUおよびメモリー割当ての数値で拡張されます。これらの推奨は、要件と宛先サーバーの容量の間での合理的な妥協点を表します。
信頼度: シナリオで定義したソースの使用要件を満たすソースについて収集されたデータの割合。この値は、プロジェクトで定義されたすべてのソースについて集計されます。
違反: シナリオで定義された技術的な違反またはビジネス制約の数。
排他: 宛先への修飾されたマッピングがないソースの数。これらは、使用可能な宛先の容量を超えたソースです。ソースから宛先への自動マッピングを使用している場合のみ、このメトリックは適用可能です。
制約のセットが異なると、最適なシナリオが異なることがあります。別のシナリオ結果を得るには、制約を変更します。
統合シナリオを分析するために、統合プランナは定義済のプロセスに従います。
最初に、統合プランナは、各統合ソースの時間ごとおよび全体的なリソース要件を見積もります。Enterprise Managerで収集されたメトリック・データを使用して、統合プランナは(指定した収集日数内の)時間ごとおよびすべての時間の要件を計算し、選択したリソース割当てスタイル(「積極的」、「中」または「保守的」)に応じて平均、80パーセンタイルまたは最大値を選択します。スケール係数が指定されている場合、統合プランナはこの値を調整します。ソースに対して表示されるリソース要件は、リソース割当てスタイルと調整によって決定される全体的な要件です。
統合シナリオに既存の宛先が含まれている場合、統合プランナは同様の計算を実行して、各宛先の時間ごとおよび全体的な使用状況の値を決定します。統合プランナは、これらの値をスケーリングまたは調整せず、リソース割当てスタイルに応じて、平均、80パーセンタイルまたは最大値を使用してこれらを計算します。
ソースを新規または既存の宛先に統合するために、統合プランナは、各ソースの時間当たりの要件を宛先の1時間当たりの使用可能容量と照合します。(既存の宛先は、既存の時間当たりのワークロードが移入されたこのプロセスを開始します。新しい宛先は空の状態で開始します。)宛先がすべてのリソースに対する時間当りのすべての要件に対応できる場合は、統合が正常に行われます。任意の要件を統合できない場合、統合プランナは、十分な容量が検出されるまで次の宛先を試行します。統合が既存の宛先に対するもので、十分な容量が残っていない場合、ソースは統合から除外されます。新しい宛先への統合の場合は、ソースに対応するために別の宛先が作成されます。デフォルトでは、統合プランナは可能な最少の宛先にソースを統合します。ただし、複数の既存の宛先があるシナリオでは、ワークロードをすべての宛先に分散させることを選択できます。
シナリオの「マッピング」ページには、統合の結果が表示されます。このページの内容は、統合に対して選択したプロジェクト・タイプとリソースによって異なりますが、一般には次の内容が表示されます。
予測される宛先、および各宛先に統合されたソース。
各リソースについて、宛先の容量と、既存のワークロードに統合されたソースによって消費されるリソースの割合および量(存在する場合)。統合プランナは、宛先のリソースの1時間当たりの最大のリソース使用状況を検出することで、この量を見積もります。ソース行は、そのソースによって使用される宛先のリソースの割合を示します。
統合プロジェクトおよびシナリオの詳細を、様々な書式で取得できるレポート形式で再利用し、より多くのユーザーに配布できます。
プロジェクト・レポートを表示するには、「統合プランナ」ホームページでプロジェクトを選択し、表の上にある「レポート」ボタンをクリックします。「レポート」ページでは、ホームページのプロジェクト詳細に表示されているタブ情報を表示するスタック済でスクロール可能な表としてプロジェクト詳細を再度表示します。
「レポートの公開」をクリックし、レポート・コンテンツを取得します。このアクションはBI Publisherと結合し、次のことができます。
様々な形式(Excel、PowerPoint、HTML、PDF)によるレポートの保存。
定義済のスケジュールに基づく、生成されたレポートの電子メール・リスト(Enterprise Managerへのアクセス権がないユーザーなど)への配信。
「OK」をクリックして「統合プランナ」ホームページに戻ります。
プロジェクト・シナリオ・レポートを表示するには、「統合プランナ」ホームページでプロジェクトにあるシナリオを選択し、表の上にある「レポート」ボタンをクリックします。「レポート」ページでは、ホームページのシナリオ詳細に表示されているタブ情報を表示するスタック済でスクロール可能な表としてシナリオ詳細を再度表示します。
「レポートの公開」をクリックし、レポート・コンテンツを取得します。このアクションはBI Publisherと結合し、次のことができます。
様々な形式(Excel、PowerPoint、HTML、PDF)によるレポートの保存。
定義済のスケジュールに基づく、生成されたレポートの電子メール・リスト(Enterprise Managerへのアクセス権がないユーザーなど)への配信。
「OK」をクリックして「統合プランナ」ホームページに戻ります。
形状では、1つのインスタンスに使用可能なOracle Compute Unit (OCPU)の数およびRAM容量を定義します。1 (OCPU)は、現在ハイパー・スレッドが使用可能な3.0 GHz 2012 Intel Xeonプロセッサ相当のCPU性能を提供します。各OCPUは、vCPUと呼ばれる、2つのハードウェア実行スレッドに対応します。
広範な形状は、ビジネス要件に最適な、インスタンスの処理能力とメモリーの組合せを選択する際に役立ちます。インスタンスの形状を選択する際に、インスタンスにデプロイするアプリケーションの特性、アプリケーションの使用が予想されるユーザー数、および将来予想される負荷のスケールの程度について検討します。OSで使用されるCPUおよびメモリー・リソースも忘れずに考慮してください。
リソース要件を満たす形状を決定するために、形状を試して典型的なワークロードでテストできます。
表44-1には、Oracle Compute Cloud Serviceで現在利用可能な形状のリストが示されています。OC3からOC7の形状は標準のOCPUとメモリーの組合せを表しています。OC1MからOC5Mの形状は上位のメモリー構成を表していて、メモリー割当てが標準構成の2倍です。
プロジェクトのステータスを表示して、データ収集を管理します。
統合プランナ・ホームページで、「アクション」メニューから「データ収集の表示」を選択します。
次のタスクを実行できるプロジェクト内のソース・ターゲットが、ビューにリストされます。
プロジェクトによる最新の収集ステータスを表示します。
ターゲットを選択して収集履歴を確認し、収集の潜在的な問題のトラブルシューティングを行います。
「データ収集ジョブ」の下のリンクをクリックして、表示できるジョブ・アクティビティ・ページに移動し、最新のデータ収集ジョブを管理します。
手順に従って最新のSPECintレートを更新し、最新レートでCSVファイルをダウンロードします。ファイルをダウンロードしたら、「参照」をクリックしてローカル・ファイル・システムのファイルを検索し、「ロード」をクリックして統合プランナのレートを更新します。
