データベースのサイズ設定とパフォーマンス
データベースのサイズ設定は、System Center - Orchestrator のパフォーマンスを理解するための鍵です。 Runbook サーバー、Management サーバー、および Web コンポーネントはすべて、その操作が Orchestrator データベースに依存します。 Orchestrator のデプロイに関する問題は、データベース内のデータの種類とその管理方法を不完全に理解している場合に発生する可能性があります。
Runbook Designer は (Management サーバーを通じて) Orchestrator データベースと通信するため、データベースのパフォーマンスが劣っていると通信の妨げになります。
Orchestrator オペレーター エクスペリエンスは、 Orchestration Console と Web サービスの 2 つのコンポーネントに基づいています。 Orchestration Console は、Silverlight ベースのアプリケーションで、Orchestrator データベースへの接続は Web サービスに依存します。 Web サービスは、データベースに接続する IIS アプリケーションです。 そのため、Web サービスと Orchestration Console はどちらも Orchestrator データベースのパフォーマンスに依存します。
さらに、 Orchestration Console は Web サービスに依存しながらも、ユーザー インターフェイスとしての機能とその独自のパフォーマンス特性に固有なロジックも持ちます。
構成データとログ データ
大まかに言えば、Orchestrator データベースには次の 2 種類のデータが含まれています。
構成データ
Orchestrator インフラストラクチャには、構成データが含まれています。 このデータは、この種類のデータのストレージ要件が小さいため、データベースの拡張のコンテキストでは問題になりません。
ログ データ
オーケストレーターはさまざまな種類のログ データを作成します。これらはすべて、 Runbook Designer で表示および管理できます。 このデータのストレージ要件はサイズが異なり、大きくなる可能性があります。
次の表は、Orchestrator データベースに保存することができるログ データの種類の一覧です。 オーケストレーターは、監査証跡とトレースのために(データベースの外部にある) 別のログ ファイルにデータを格納します。 各種類のログ データの詳細については、「 Orchestrator Logs」を参照してください。
| ログ データの種類 | Runbook Designer 内の場所 | ログの消去による管理の可否 |
|---|---|---|
| Runbook ログ | [ログ ] タブと [ ログ History ] タブ | はい |
| 活動 (プラットフォーム) イベント | [イベント ] タブ | いいえ |
| 監査履歴 | [監査履歴 ] タブ | いいえ |
プラットフォーム コードとドメイン コード
Orchestrator Runbook アクティビティには、次の 2 種類のコードが含まれています。
プラットフォーム コード
これは、ほとんどのアクティビティで共有される一般的なコードであり、Orchestrator アクティビティによって実行される一般的なタスクを実行するために使用されます。 プラットフォーム コードは、共通の公開データを生成します。
ドメイン コード
各アクティビティのアクションに固有のさまざまなタスクを実行します。通常、Orchestrator プラットフォーム自体には関連付けられていません。 場合によっては、プラットフォーム コードとドメイン コードの間に大きなバリエーションが生じる可能性があります。
特定の活動を対象に生成されるログ データには、単一値または複数値のデータ要素が含まれます。 各活動は、単一値データの単一レコードを生成します。 ドメイン コードは、複数値のレコードを複数生成できるため、活動が以前の活動から受信した共通の公開データを使って行う内容の決定に関与します。
基本的に、Orchestrator Runbook はドメイン コードの個別要素間でデータを渡すように設計されています。 さらに、ドメイン コードは必要に応じて、活動固有の公開データを生成できます。
すべての Runbook の主要な類似点は、ドメイン コードとプラットフォーム コードで構成される活動を実行すること、ワークフローをループすること、そして分岐することです。 分岐するのは、Runbook が特定のタスクを行うために他の Runbook を呼び出す場合です。 Runbook が最初に呼び出されると、1 つのスレッドで構成されます。 このスレッドで分岐を必要とするリンクを持つ Runbook 活動が発生すると、分岐ごとに追加スレッドが 1 つずつ作成されます。 各スレッドは、分岐を作成した活動からの共通の公開データを入力に利用します。 このデータは、Runbook の以前の活動にさかのぼって関連付けられ、その以前の活動がサブスクライブする共通の公開データを更新します。
ドメイン コードは、分岐によって生成されるマルチスレッドよりも、データベースのパフォーマンスに影響を与える可能性があります。 これは、ドメイン コードが活動固有の公開データを大量に生成する可能性があるためです。
ログ オプション
Runbook の [ プロパティ ] の [ ログの記録 ] タブで、必要に応じて、ログ エントリを保存できます。 "既定のログ" とは、2 つの公開データ オプションがいずれも選択されていない状態を意味し、その場合、各活動に生成されるログの容量が合計 524 バイトになります。 共通の公開データ用に 2 つのカテゴリのログ オプションがあります。
一般的な公開データ
すべての活動に共通するデータ項目のセットです。 一覧については、「 実行ログ オプションを参照してください。
このログ オプションは、各活動に 6082 バイトを生成します。
アクティビティ固有の発行済みデータ
ドメイン コードが必要に応じて作成する活動固有のデータ セットです。
このログ オプションは、特定の活動によってログに出力されたバイト数に加えて、6082 バイトを生成します。
ヒント
このオプションは、主にデバッグ目的で選択されます。 ログ サイズの増大を制限する場合は、このオプションはオフのままにします。
ログ オプションの設定によっては、パフォーマンスに著しく影響を与え、データベースを増大させる可能性があります。 同じ Runbook 活動を 2 回実行するシナリオを考えます。1 回目は(公開データのオプションを選択せずに) 既定のレベルでログを出力し、2 回目は共通の公開データを選択してログを出力します。 ドメイン コードの完了には同じ時間がかかるはずです。 しかし、共通の公開データが有効になっていると、プラットフォーム コードは既定のログ レベルで実行した場合よりも 12 倍多いデータ ログをサポートする必要があるため、プラットフォーム コードの実行時間が長くなります。
ログの消去
Runbook Designer の Log Purge 機能に指定された既定のオプションは、すぐに使用できる Orchestrator の展開に最適なユーザー エクスペリエンスを提供するように構成されています。 これらの値を変更すると、環境のパフォーマンス特性が変わる可能性があり、変更の影響を評価できるように、段階的に高基準値を実装する必要があります。
ログの自動削除と手動消去の詳細については、 Runbook ログの取得を参照してください。
パフォーマンス ベンチマークの作成
ログ記録の増加をテストする単純な Runbook を作成するには、標準アクティビティ Compare Values を使用して Orchestrator 環境のベンチマークを作成できます。
次の手順では、 Compare Values アクティビティを 10,000 回実行する Runbook を作成します。 値の比較 は、ドメイン コードが最小限の単純なアクティビティです。 この Runbook は、さまざまな状況で呼び出して、特定の Orchestrator ランタイム環境の全体的なパフォーマンスを特徴付けることができます。
Orchestrator 環境のベンチマークに使用する Runbook を作成するには
新しい Runbook を作成します。
Standard Activity パレットから、[ Compare Values ] 活動を追加します。 構成する活動をダブルクリックします。
General タブを選択し、文字列 (既定値) を比較するようにこのアクティビティを構成します。
Details タブを選択し、Test ボックスに値 STRING を入力し、 空を選択します。
[ Finish を選択して、アクティビティの更新を保存します。
活動を右クリックして、[ ループ] を選択します。
[有効] チェック ボックスをオンにし、試行間のの数を入力 (ゼロ)します。
Exit タブを選択します。
既定の終了条件を変更します。 Compare Valuesを選択し、Show Common Published Data チェックボックスをオンにして、Loop: Number of attempts を選択します。 [ OK を選択して、この変更を保存します。
更新された終了条件から value を選択し、 10000 (10,000) の数値を入力します。 [ OK を選択して、この変更を保存します。
[ Finish を選択して、これらの更新プログラムを保存します。
[チェックインを選択して、Orchestrator データベースへの変更を保存します。
この Runbook は Orchestrator のさまざまな構成で試すことができます。 たとえば、異なるデータ センターに展開された 4 台の Runbook Server のパフォーマンスを判定するベンチマーク Runbook を作成できます。
| Data Center | ログ記録の構成 | プラットフォーム コードの実行時間 (ミリ秒) | ミリ秒/活動 | スケール係数 |
|---|---|---|---|---|
| 場所 1 | 既定のログ | 819 | 82 | 1.0 (基準) |
| 場所 1 | 共通の公開データのログ | 2012 | 201 | 2.5 |
| 場所 2 | 既定のログ | 1229 | 123 | 1.5 |
| 場所 2 | 共通の公開データのログ | 3686 | 369 | 4.5 |
| 場所 3 | 既定のログ | 2457 | 426 | 3.0 |
| 場所 3 | 共通の公開データのログ | 4422 | 442 | 5.4 |
| 場所 4 | 既定のログ | 1474 | 147 | 1.8 |
| 場所 4 | 共通の公開データのログ | 2654 | 265 | 3.2 |
共通の公開データのログを出力すると、プラットフォームのパフォーマンスが著しく低下することに注目してください。 最悪のシナリオでは、共通の公開データのログが場所 2 に表示されます。 一見すると、明確で関連のある結果のように見えます。
ただし、これらの数値はドメイン コードではなくプラットフォーム コードのオーバーヘッドを示すことに注意してください。 ドメイン コード ランタイムは長くなる可能性があります。 たとえば、Virtual Machine Manager 統合パックの [ VM をテンプレートから作成する ] 活動は、VM が作成されるため、実行に数分かかる可能性があります。 前の例では、場所に関係なく、実行に 1 分 (1 分 = 60,000 ミリ秒) かかる Runbook アクティビティのプラットフォーム コード コストについて考えてみましょう。
| Data Center | ログ記録の構成 | プラットフォーム コードの実行時間 (ミリ秒) | ドメイン コードの割合 | プラットフォーム コードの割合 |
|---|---|---|---|---|
| 場所 1 | 既定のログ | 819 | 98.6% | 1.4% |
| 場所 1 | 共通の公開データのログ | 2012 | 96.7% | 3.3% |
| 場所 2 | 既定のログ | 1229 | 98.0% | 2.0% |
| 場所 2 | 共通の公開データのログ | 3686 | 93.9% | 6.1% |
| 場所 3 | 既定のログ | 2457 | 95.9% | 4.1% |
| 場所 3 | 共通の公開データのログ | 4422 | 92.6% | 7.4% |
| 場所 4 | 既定のログ | 1474 | 97.5% | 2.5% |
| 場所 4 | 共通の公開データのログ | 2654 | 95.6% | 4.4% |
このデータにより、はっきりとしてきたことがあります。 場所 2 で共通の公開データのログを出力するシナリオは、この例でも引き続き、最悪のパフォーマンスとなります。 ただし、プラットフォーム コードとそのログは、全体の実行時間の 6% しか占めません。 とはいえ、これは大きな数値です。最良のシナリオ ケースでは、1.4% です。 基本的に、この例でドメイン コードにかかった時間は、プラットフォーム コードの実行にかかった時間をはるかに上回ります。 これを観点から見ると、プラットフォーム コードのコストを完全に排除できた場合は、Runbook のパフォーマンスが 1.4% から 7.4% の範囲でのみ向上します。
ほとんどの実際のシナリオは異なります。 活動の動作は、ドメイン コードの指示によって変わる可能性があります。 たとえば、テンプレートからの Clone VM アクティビティでは、サーバー テンプレート A から VM を複製するのに 1 分かかる場合がありますが、サーバー テンプレート B から VM を複製するには 5 分かかります。また、Runbook サーバーは、パフォーマンス特性が異なる異なるネットワーク上に存在する可能性があり、ドメイン コードのパフォーマンスと Orchestrator データ ログのパフォーマンスの両方に影響する可能性があります。
データベースの拡張の決定
Orchestrator データベースのデータベース管理者は、次のガイドラインを使用して、データベース ファイルの拡張方法を決定できます。
一般に、Runbook を呼び出すたびにデータベース ファイルのサイズが増えることはありません。 ファイルは、それに含まれるデータが、データベース管理者によって構成された特定の高い基準に達したときに増加します。この時点で、通常ファイルが拡張されます。
Runbook アクティビティを実行するたびに個別にカウントする必要があります。これは、ループ機能によって 1 つのアクティビティが複数回実行される可能性がある場合に考慮する必要があります。
Runbook の呼び出しごとに必要なストレージを決定するには、選択したログ 記録レベルに従って、Runbook 内のアクティビティの数にデータベースに追加されたバイト数を乗算します。 これらの値は次のとおりです。
524 バイト
既定のログ構成
6082 バイト
共通の公開データのログ レベル
6082 バイト + 活動によって出力されたログ データ
活動特有の公開データのログ レベル
既定では、Orchestrator は、毎夜午前 2 時 00 分に各 Runbook のログを最新の 500 個を除いてすべて消去します。 Runbook の呼び出しごとに必要となる記憶域を決定するには、Runbook の呼び出しに必要な記憶域に 500 を掛けます。 必要に応じてログの消去設定を変更する場合は、各呼び出しに毎日、毎週、あるいは毎月の呼び出し数を掛けます。
次の表は、ログ レベルの構成に応じて見積もられた拡張とパフォーマンスを示したものです。
| ログ レベル | DB 拡張係数 | パフォーマンス係数 | 運用での推奨可否 |
|---|---|---|---|
| 既定値 | 1 | 1 | はい |
| 共通の公開データ | 11.6 倍 | 2.5x | 計画の上で限定使用 |
| 活動固有の公開データ | 11.6 倍超 | 2.5 倍超 | いいえ |
例
例 1
次の表では、Orchestrator のデプロイに関するデータベースのサイズ設定に関する考慮事項について説明します。
| Runbook 名 | 活動数 | ログ レベル | 1 日あたりの呼び出し数 |
|---|---|---|---|
| Runbook 1 | 50 | 既定値 | 100 |
| Runbook 2 | 25 | 既定値 | 50 |
| Runbook 3 | 12 | 共通の公開データ | 24 |
| Runbook 4 | 8 | 共通の公開データ | 500 |
上述されたデータベースのサイジングを使用して、Runbook の記憶域要件を見積もることができます。
| Runbook 名 | バイト/呼び出し | 記憶域 (MB) 既定のログの消去 (500 の呼び出し) |
1 か月あたりの呼び出し数 | 記憶域 (MB) 1 か月 (既定以外のログの消去) |
30 日後の DB 記憶域 (%) |
|---|---|---|---|---|---|
| Runbook 1 | 26,200 | 12.5 | 3,000 | 74.5 | %9 |
| Runbook 2 | 13,100 | 6.2 | 1,500 | 18.7 | 2% |
| Runbook 3 | 72,984 | 34.8 | 720 | 50.1 | %6 |
| Runbook 4 | 48,656 | 23.2 | 15,000 | 696.0 | 83% |
| 合計:76.7 MB | 合計: 839.3 MB |
この例では、データ ログに関して適切な決定を行う重要性が明確に示されています。 Runbook 4 には 8 つのアクティビティのみが含まれますが、Common Published Data Logging レベルで構成すると、呼び出しの頻度が高いため、データベース内のほとんどのストレージが使用されます。 これらの結果に基づいて、Runbook 4 のログ 記録レベルを既定のログ構成に減らすことをお好みかもしれません。
例 2
次の表では、Orchestrator の別のデプロイに関するデータベースのサイズ設定に関する考慮事項について説明します。
| Runbook 名 | 活動数 | ログ レベル | 1 日あたりの呼び出し数 |
|---|---|---|---|
| Runbook 1 | 50 | 既定値 | 100 |
| Runbook 2 | 25 | 既定値 | 50 |
| Runbook 3 | 12 | 共通の公開データ | 24 |
| Runbook 4 | 8 | 既定値 | 500 |
構成を更新して記憶域の数値を再計算したところ、結果は大きく変わりました。
| Runbook 名 | バイト/呼び出し | 記憶域 (MB) 既定のログの消去 (500 の呼び出し) |
1 か月あたりの呼び出し数 | 記憶域 (MB) 1 か月 (既定以外のログの消去) |
30 日後の DB 記憶域 (%) |
|---|---|---|---|---|---|
| Runbook 1 | 26,200 | 12.5 | 3,000 | 74.5 | 37% |
| Runbook 2 | 13,100 | 6.2 | 1,500 | 18.7 | %9 |
| Runbook 3 | 72,984 | 34.8 | 720 | 50.1 | 25% |
| Runbook 4 | 4,192 | 2.0 | 15,000 | 60.0 | 29% |
| 合計:55.5 MB | 合計: 203.3 MB |
既定のログ構成 (Runbook あたり 500 個のログ エントリ) にはほとんど変更はありませんが、30 日間のストレージ要件は大幅に変更されています。 この変更により、30 日間のデータのデータベース ストレージ要件が 76% 削減されるため、Runbook 4 に共通公開データ ログを使用する場合のストレージ コストは慎重に検討する必要があります。
まとめ
次のガイドラインに従って、データベースのサイジングとパフォーマンスを管理してください。
必要な場合のみ、共通の公開データのログを有効にしてください。
活動の実行回数が、ログに出力されるデータの容量を決定することを念頭に置いてください。 少数のアクティビティが複数回実行される小規模な Runbook では、大規模な Runbook の実行回数よりも多くのデータ ログが発生する可能性があります。
運用環境ではアクティビティ固有の発行済みデータのログ記録を有効にしないでください。デバッグ目的でのみ使用してください。
Runbook が実行に費やすドメイン コードがプラットフォーム コードの実行の何倍かかるか理解を深めてください。
このドキュメントで説明されたテクニックを使用して、プラットフォーム コードのコストを見積もってください。 Runbook のパフォーマンスの改善点を検討する際に、リファレンスとして使用します。
同じ基準で比較測定して、改善の余地を確認します。