OpenStack でのロード バランシング

大規模なクラウド システムでは、コンピューティング リソースの負荷を自動的にバランスまたは平準化する問題が特に深刻です。 Tionix (Rostelecom グループ企業の一部でクラウド サービスの開発および運用会社) もこの問題に取り組んでいます。

そして、私たちの主な開発プラットフォームは Openstack であり、私たちも他の人々と同じように怠け者であるため、プラットフォームにすでに含まれている既製のモジュールを選択することにしました。 私たちの選択は Watcher に決まり、ニーズに合わせて使用​​することにしました。

まず、用語と定義を見てみましょう。

用語と定義

目標 人間が読み取り可能、観察可能、測定可能な最終結果であり、達成する必要があります。 各目標を達成するには XNUMX つ以上の戦略があります。 戦略とは、特定の目標に対する解決策を見つけることができるアルゴリズムの実装です。

アクション OpenStack クラスターのターゲット管理対象リソースの現在の状態を変更する基本タスクです。たとえば、仮想マシンの移行 (移行)、ノードの電源状態の変更 (change_node_power_state)、nova サービスの状態の変更 (change_nova_service_state) です。 )、フレーバーの変更 (サイズ変更)、NOP メッセージの登録 (nop)、一定時間のアクションの欠如 - 一時停止 (スリープ)、ディスク転送 (volume_移行)。

行動計画 - 特定の目標を達成するために、特定の順序で実行される特定のアクションの流れ。 アクション プランには、一連のパフォーマンス指標とともに測定されたグローバル パフォーマンスも含まれています。 監査が成功すると、Watcher によってアクション プランが生成され、その結果、使用された戦略によって目標を達成するための解決策が見つかります。 アクション プランは、一連のアクションのリストで構成されます。

監査 クラスターを最適化するリクエストです。 最適化は、特定のクラスター内で XNUMX つの目標を達成するために実行されます。 監査が成功するたびに、Watcher はアクション プランを生成します。

監査範囲 監査が実行されるリソースのセットです (アベイラビリティーゾーン、ノードアグリゲーター、個々の計算ノードまたはストレージノードなど)。 監査範囲は各テンプレートで定義されます。 監査スコープが指定されていない場合は、クラスター全体が監査されます。

監査テンプレート — 監査を開始するための保存された設定セット。 テンプレートは、同じ設定で監査を複数回実行するために必要です。 テンプレートには必ず監査の目的が含まれている必要があります。戦略が指定されていない場合は、最も適切な既存の戦略が選択されます。

集まる は、コンピューティング、ストレージ、およびネットワーキング リソースを提供する物理マシンの集合であり、同じ OpenStack 管理ノードによって管理されます。

クラスター データ モデル (CDM) クラスターによって管理されるリソースの現在の状態とトポロジーを論理的に表現したものです。

効率指標 - この戦略を使用して作成されたソリューションがどのように実行されるかを示す指標。 パフォーマンス指標は特定の目標に固有であり、通常は、結果として得られるアクション プランの全体的な有効性を計算するために使用されます。

効能の仕様 は、各目標に関連付けられた一連の特定の機能であり、対応する目標を達成するための戦略がソリューションで達成する必要があるさまざまなパフォーマンス指標を定義します。 実際、戦略によって提案された各ソリューションは、全体的な有効性を計算する前に、仕様と照合してチェックされます。

スコアリングエンジン は、明確に定義された入力と明確に定義された出力を備え、純粋に数学的なタスクを実行する実行可能ファイルです。 このように、計算は実行される環境に依存せず、どこでも同じ結果が得られます。

ウォッチャープランナー - Watcher の意思決定エンジンの一部。 このモジュールは、戦略によって生成された一連のアクションを取得し、これらのさまざまなアクションを時間内にスケジュールする方法と各アクションの前提条件を指定するワークフロー プランを作成します。

ウォッチャーの目標と戦略

目標
戦略

ダミーゴール
ダミー戦略 

サンプルスコアリングエンジンを使用したダミー戦略

サイズ変更を伴うダミー戦略

省エネルギー
省エネ戦略

サーバーの統合
基本的なオフラインサーバー統合

VM ワークロード統合戦略

ワークロードバランシング
ワークロード バランスの移行戦略

ストレージ容量バランス戦略

ワークロードの安定化

うるさい隣人
うるさい隣人

熱の最適化
出口温度に基づく戦略

エアフローの最適化
均一な気流移行戦略

ハードウェアのメンテナンス
ゾーンの移行

分類されていません
作動装置

ダミーゴール — テスト目的で使用される予約済みの目標。

関連戦略: ダミー戦略、サンプル スコアリング エンジンを使用したダミー戦略、およびサイズ変更を伴うダミー戦略。 ダミー戦略は、Tempest による統合テストに使用されるダミー戦略です。 この戦略は有用な最適化を提供しません。その唯一の目的は、Tempest テストを使用することです。

サンプルのスコアリング エンジンを使用したダミー戦略 - この戦略は前の戦略と似ていますが、唯一の違いは、機械学習手法を使用して計算を実行するサンプルの「スコアリング エンジン」を使用することです。

サイズ変更を伴うダミー戦略 - この戦略は前の戦略と似ていますが、唯一の違いはフレーバーの変更 (移行とサイズ変更) を使用することです。

実稼働環境では使用されません。

省エネルギー — エネルギー消費を最小限に抑えます。 この目標の省エネルギー戦略は、VM ワークロード統合戦略 (サーバー統合) と組み合わせることで、リソース使用率が低い期間でもワークロードを動的に統合することでエネルギーを節約する動的電源管理 (DPM) 機能を利用できます。仮想マシンはより少ないノードに移動されます。 、不要なノードは無効になります。 統合後、この戦略は、指定されたパラメータに従ってノードのオン/オフを決定します。「min_free_hosts_num」 - ロードを待機している空き有効なノードの数、および「free_used_percent」 - ロードを待機している空き有効なノードの割合マシンが占有しているノードの数。 戦略が機能するには、次のことが必要です ノードの電源の入れ直しを処理するように Ironic を有効にして構成しました。

戦略パラメータ

パラメーター
тип
デフォルトで
説明

free_used_percent
数
10.0
仮想マシンを備えたコンピューティング ノードの数に対する空きコンピューティング ノードの数の比率

min_free_hosts_num
int型
1
空きコンピューティング ノードの最小数

クラウドには少なくとも XNUMX つのノードが必要です。 使用される方法は、ノードの電力状態を変更することです (change_node_power_state)。 この戦略ではメトリクスを収集する必要はありません。

サーバーの統合 - コンピューティング ノードの数を最小限に抑えます (統合)。 これには、基本的なオフライン サーバー統合と VM ワークロード統合戦略の XNUMX つの戦略があります。

基本的なオフライン サーバー統合戦略により、使用されるサーバーの総数が最小限に抑えられ、移行の数も最小限に抑えられます。

基本戦略には次の指標が必要です。

メトリクス
奉仕
プラグイン
コメント

compute.node.cpu.percent
シーロメーター
なし
 

cpu_util
シーロメーター
なし
 

戦略パラメーター: migration_attempts - シャットダウンの潜在的な候補を検索する組み合わせの数 (デフォルト、0、制限なし)、period - メトリック データ ソースから静的集計を取得するための秒単位の時間間隔 (デフォルト、700)。

使用される方法: 移行、nova サービス状態の変更 (change_nova_service_state)。

VM ワークロード統合戦略は、測定された CPU 負荷に焦点を当てた初回適合ヒューリスティックに基づいており、リソース容量の制約を考慮して負荷が多すぎる、または少なすぎるノードを最小限に抑えようとします。 この戦略は、次の XNUMX つの手順を使用して、クラスター リソースをより効率的に使用するソリューションを提供します。

1. アンロードフェーズ - 過剰に使用されたリソースの処理。
2. 統合フェーズ - 十分に活用されていないリソースの処理。
3. ソリューションの最適化 - 移行の数を削減します。
4. 未使用の計算ノードを無効にします。

この戦略には次の指標が必要です。

メトリクス
奉仕
プラグイン
コメント

メモリ
シーロメーター
なし
 

ディスクルートサイズ
シーロメーター
なし
 

次の指標はオプションですが、利用可能な場合は戦略の精度が向上します。

メトリクス
奉仕
プラグイン
コメント

記憶の住人
シーロメーター
なし
 

cpu_util
シーロメーター
なし
 

戦略パラメーター: period — メトリック データ ソースから静的集計を取得する時間間隔 (秒単位) (デフォルトは 3600)。

前の戦略と同じ方法を使用します。 さらに詳しく ここで.

ワークロードバランシング — コンピューティング ノード間のワークロードのバランスをとります。 この目標には、ワークロード バランス移行戦略、ワークロードの安定化、ストレージ容量バランス戦略の XNUMX つの戦略があります。

ワークロード バランス移行戦略は、ホスト仮想マシンのワークロードに基づいて仮想マシンの移行を実行します。 ノードの CPU または RAM 使用率 (%) が指定されたしきい値を超えるたびに、移行の決定が行われます。 この場合、仮想マシンを移動すると、ノードがすべてのノードの平均ワークロードに近づくはずです。

必要条件

• 物理プロセッサの使用。
• 少なくとも XNUMX つの物理コンピューティング ノード。
• 各計算ノード上で実行される Ceilometer コンポーネント (ceilometer-agent-compute) と Ceilometer API をインストールして構成し、次のメトリクスを収集します。

メトリクス
奉仕
プラグイン
コメント

cpu_util
シーロメーター
なし
 

記憶の住人
シーロメーター
なし
 

戦略パラメータ:

パラメーター
тип
デフォルトで
説明

メトリクス
文字列
「cpu_util」
基礎となるメトリクスは「cpu_util」、「memory.resident」です。

しきい値
数
25.0
移行のワークロードしきい値。

期間
数
300
累積期間 Ceilometer。

使用される方法は移行です。

ワークロードの安定化は、ライブ マイグレーションを使用してワークロードを安定化することを目的とした戦略です。 この戦略は標準偏差アルゴリズムに基づいており、クラスター内に輻輳があるかどうかを判断し、クラスターを安定させるためにマシンの移行をトリガーすることでそれに応答します。

必要条件

• 物理プロセッサの使用。
• 少なくとも XNUMX つの物理コンピューティング ノード。
• 各計算ノード上で実行される Ceilometer コンポーネント (ceilometer-agent-compute) と Ceilometer API をインストールして構成し、次のメトリクスを収集します。

メトリクス
奉仕
プラグイン
コメント

cpu_util
シーロメーター
なし
 

記憶の住人
シーロメーター
なし
 

ストレージ容量バランス戦略 (Queens から実装された戦略) - この戦略は、Cinder プールの負荷に応じてディスクを転送します。 プール使用率が指定されたしきい値を超えるたびに、転送の決定が行われます。 ディスクを移動すると、プールがすべての Cinder プールの平均負荷に近づくはずです。

要件と制限事項

• 少なくとも XNUMX つの Cinder プール。
• ディスク移行の可能性。
• クラスター データ モデル - Cinder クラスター データ モデル コレクター。

戦略パラメータ:

パラメーター
тип
デフォルトで
説明

volume_threshold
数
80.0
ボリュームのバランスをとるためのディスクのしきい値。

使用される方法はディスク移行 (volume_merge) です。

ノイジー ネイバー - 「ノイジー ネイバー」、つまりラスト レベル キャッシュを過剰に使用することにより、IPC の観点から優先度の高い仮想マシンのパフォーマンスに悪影響を与える優先度の低い仮想マシンを特定して移行します。 独自の戦略: Noisy Neighbor (使用される戦略パラメーターは、cache_threshold (デフォルト値は 35) です。パフォーマンスが指定された値まで低下すると、移行が開始されます。戦略が機能するには、有効にします。 LLC (最終レベルキャッシュ) メトリクス、 CMT をサポートする最新の Intel サーバーだけでなく、次のメトリクスも収集します。

メトリクス
奉仕
プラグイン
コメント

cpu_l3_cache
シーロメーター
なし
インテルが必要 CMT.

クラスター データ モデル (デフォルト): Nova クラスター データ モデル コレクター。 使用される方法は移行です。

ダッシュボードを使用してこの目標に取り組むことは、Queens では完全には実装されていません。

熱の最適化 — 温度レジームを最適化します。 出口 (排気) 温度は、サーバーの熱/ワークロードのステータスを測定するための重要な熱テレメトリ システムの XNUMX つです。 ターゲットには、出口温度ベースの戦略という XNUMX つの戦略があり、ソース ホストの出口温度が構成可能なしきい値に達したときに、熱的に有利なホスト (出口温度が最も低い) にワークロードを移行することを決定します。

この戦略が機能するには、Intel Power Node Manager がインストールされ構成されたサーバーが必要です。 3.0以降だけでなく、次のメトリクスも収集します。

メトリクス
奉仕
プラグイン
コメント

hardware.ipmi.node.outlet_temporal
シーロメーター
IPMI
 

戦略パラメータ:

パラメーター
тип
デフォルトで
説明

しきい値
数
35.0
移行の温度しきい値。

期間
数
30
メトリック データ ソースから統計集計を取得する時間間隔 (秒単位)。

使用される方法は移行です。

エアフローの最適化 — 換気モードを最適化します。 独自の戦略 - ライブ マイグレーションを使用した均一なエアフロー。 この戦略では、サーバー ファンからのエアフローが指定されたしきい値を超えるたびに、仮想マシンの移行がトリガーされます。

戦略が機能するには、次のものが必要です。

• ハードウェア: 計算ノード < NodeManager 3.0 をサポート。
• 少なくとも XNUMX つのコンピューティング ノード。
• ceilometer-agent-compute および Ceilometer API コンポーネントは各コンピューティング ノードにインストールおよび構成されており、エアフロー、システム電力、吸気温度などのメトリクスを正常にレポートできます。

メトリクス
奉仕
プラグイン
コメント

ハードウェア.ipmi.node.airflow
シーロメーター
IPMI
 

ハードウェア.ipmi.ノード.温度
シーロメーター
IPMI
 

ハードウェア.ipmi.node.power
シーロメーター
IPMI
 

この戦略が機能するには、Intel Power Node Manager 3.0 以降がインストールされ、構成されているサーバーが必要です。

制限事項: この概念は運用を目的としたものではありません。

反復ごとに XNUMX 台の仮想マシンのみを移行する予定であるため、継続的な監査でこのアルゴリズムを使用することをお勧めします。

ライブマイグレーションが可能です。

戦略パラメータ:

パラメーター
тип
デフォルトで
説明

しきい値_気流
数
400.0
移行のエアフローしきい値 単位は 0.1CFM

しきい値_インレット_t
数
28.0
移行判定のための入口温度閾値

しきい値_電力
数
350.0
移行決定のためのシステム電力しきい値

期間
数
30
メトリック データ ソースから統計集計を取得する時間間隔 (秒単位)。

使用される方法は移行です。

ハードウェア保守 — ハードウェアのメンテナンス。 この目標に関連する戦略はゾーン移行です。 この戦略は、ハードウェアのメンテナンスが必要な場合に、仮想マシンとディスクを効果的に自動かつ最小限に移行するためのツールです。 戦略は、重み付けに従って行動計画を構築します。より重み付けされた一連のアクションが、他のアクションよりも先に計画されます。 action_weights と並列化という XNUMX つの構成オプションがあります。

制限事項: アクションの重みと並列化を構成する必要があります。

戦略パラメータ:

パラメーター
тип
デフォルトで
説明

計算ノード
配列
なし
移行用のコンピューティング ノード。

ストレージプール
配列
なし
移行用のストレージ ノード。

並列合計
整数
6
並行して実行する必要があるアクティビティの総数。

ノードごとの並列
整数
2
各計算ノードで並行して実行されるアクションの数。

プールごとの並列
整数
2
各ストレージ プールに対して並行して実行されるアクションの数。

優先順位
オブジェクト
なし
仮想マシンとディスクの優先順位リスト。

添付ボリューム付き
ブール値
×
False - すべてのディスクが移行された後に仮想マシンが移行されます。 True - 接続されているすべてのディスクが移行された後に仮想マシンが移行されます。

コンピューティング ノードの配列の要素:

パラメーター
тип
デフォルトで
説明

src_node
文字列
なし
仮想マシンの移行元のコンピューティング ノード (必須)。

dst_node
文字列
なし
仮想マシンの移行先のノードを計算します。

ストレージ ノードの配列要素:

パラメーター
тип
デフォルトで
説明

src_pool
文字列
なし
ディスクの移行元のストレージ プール (必須)。

dst_pool
文字列
なし
ディスクの移行先のストレージ プール。

src_type
文字列
なし
元のディスクのタイプ (必須)。

dst_type
文字列
なし
結果のディスクの種類 (必須)。

オブジェクトの優先順位要素:

パラメーター
тип
デフォルトで
説明

プロジェクト
配列
なし
プロジェクト名。

計算ノード
配列
なし
ノード名を計算します。

ストレージプール
配列
なし
ストレージプール名。

計算
列挙型
なし
仮想マシンのパラメータ [“vcpu_num”、“mem_size”、“disk_size”、“created_at”]。

ストレージ利用料
列挙型
なし
ディスクパラメータ [“size”、“created_at”]。

使用される方法は、仮想マシンの移行、ディスクの移行です。

分類されていません - 戦略開発プロセスを促進するために使用される補助的な目標。 仕様は含まれていないため、戦略が既存の目標にまだ関連付けられていない場合はいつでも使用できます。 この目標は移行点としても使用できます。 この目標に関連する戦略がアクチュエーターです。   

新しい目標の作成

ウォッチャー意思決定エンジン には、戦略を使用して達成できる外部目標を統合できる「外部目標」プラグイン インターフェイスがあります。

新しい目標を作成する前に、ニーズを満たす既存の目標がないことを確認する必要があります。

新しいプラグインの作成

新しいターゲットを作成するには、ターゲット クラスを拡張し、クラス メソッドを実装する必要があります。 get_name() 作成する新しいターゲットの一意の ID を返します。 この一意の識別子は、後で宣言するエントリ ポイント名と一致する必要があります。

次にクラスメソッドを実装する必要があります get_display_name() 作成するターゲットの翻訳された表示名を返します (翻訳ツールによって自動的に収集されるように、翻訳された文字列を返すのに変数を使用しないでください)。

クラスメソッドを実装する get_translatable_display_name()新しいターゲットの翻訳キー (実際には英語の表示名) を返します。 戻り値は、get_display_name() に変換された文字列と一致する必要があります。

彼のメソッドを実装する get_effficacy_specation()ターゲットの効率仕様を返します。 get_effficacy_specation() メソッドは、Watcher によって提供される Unclassified() インスタンスを返します。 このパフォーマンス仕様は空の仕様に対応するため、目標を作成するプロセスに役立ちます。

→ もっとここで読みます

ウォッチャーのアーキテクチャ (詳細) ここで).

コンポーネント

ウォッチャーAPI - Watcher が提供する REST API を実装するコンポーネント。 対話メカニズム: CLI、Horizo​​n プラグイン、Python SDK。

ウォッチャー DB — ウォッチャー データベース。

ウォッチャー アプライア — Watcher Decision Engine コンポーネントによって作成されたアクション プランの実行を実装するコンポーネント。

ウォッチャー意思決定エンジン - 監査目標を達成するための一連の潜在的な最適化アクションを計算するコンポーネント。 戦略が指定されていない場合、コンポーネントは最適な戦略を独立して選択します。

ウォッチャー メトリクス パブリッシャー - いくつかのメトリクスまたはイベントを収集および計算し、CEP エンドポイントに公開するコンポーネント。 コンポーネントの機能は、Ceilometer 発行者によって提供されることもあります。

複合イベント処理 (CEP) エンジン — 複雑なイベント処理用のエンジン。 パフォーマンス上の理由から、複数の CEP エンジン インスタンスが同時に実行され、それぞれが特定の種類のメトリック/イベントを処理する場合があります。 Watcher システムでは、CEP は次の XNUMX 種類のアクションをトリガーします。 - 対応するイベント/メトリクスを時系列データベースに記録します。 - Openstack クラスターは静的システムではないため、このイベントが現在の最適化戦略の結果に影響を与える可能性がある場合、適切なイベントを Watcher Decision Engine に送信します。

コンポーネントは AMQP プロトコルを使用して対話します。

→ ウォッチャーの構成

Watcherとの対話スキーム

ウォッチャーテストの結果

1. [最適化 - アクション プラン 500] ページ (純粋な Queens と Tionix モジュールを備えたスタンドの両方) では、監査が開始されてアクション プランが生成された後にのみ表示され、空のページは通常どおり開きます。
2. [アクションの詳細] タブにエラーがあり、監査目標と戦略を取得できません (純粋な Queen と Tionix モジュールを備えたスタンドの両方)。
3. ダミー (テスト) を目的とした監査が通常どおり作成および開始され、アクション プランが生成されます。
4. 未分類の目標は機能せず、新しい戦略を作成するときの中間構成を目的としているため、監査は作成されません。
5. ワークロード バランシング (ストレージ容量バランス戦略) を目的とした監査は正常に作成されますが、アクション プランは生成されません。 ストレージプールの最適化は必要ありません。
6. ワークロード バランシングの目標 (ワークロード バランス移行戦略) の監査は正常に作成されますが、アクション プランは生成されません。
7. ワークロード バランシング (ワークロード安定化戦略) の監査が失敗します。
8. Noisy Neighbor ターゲットの監査は正常に作成されますが、アクション プランは生成されません。
9. ハードウェア メンテナンスを目的とした監査は正常に作成されますが、アクション プランは完全には生成されません (パフォーマンス インジケーターは生成されますが、アクションのリスト自体は生成されません)。
10. コンピューティング ノードおよび制御ノード上の nova.conf 構成 (デフォルト セクション compute_monitors = cpu.virt_driver) を編集しても、エラーは修正されません。
11. サーバー統合 (基本戦略) を対象とした監査も失敗します。
12. サーバー統合 (VM ワークロード統合戦略) を目的とした監査がエラーで失敗します。 ログには、ソース データの取得中にエラーが記録されています。 特にエラーに関する議論 ここで.
    構成ファイルで Watcher を指定しようとしました (役に立ちませんでした。すべての最適化ページでエラーが発生したため、構成ファイルの元の内容に戻っても状況は修正されません)。
    [watcher_strategies.basic] データソース = ceilometer、ニョッキ
13. 省エネの監査が失敗します。 ログから判断すると、問題は依然として Ironic が存在しないことであり、ベアメタル サービスがなければ機能しません。
14. 熱最適化の監査が失敗します。 トレースバックはサーバー統合 (VM ワークロード統合戦略) と同じです (ソース データ エラー)
15. エアフローの最適化を目的とした監査はエラーで失敗します。

次の監査完了エラーも発生します。 Decision-engine.log ログのトレースバック (クラスター状態は定義されていません)。

→ エラーについての議論 ここで

まとめ

私たちの XNUMX か月にわたる調査の結果は、本格的に機能する負荷分散システムを取得するには、この部分で Openstack プラットフォーム用のツールを改良することに緊密に取り組む必要があるという明白な結論でした。

Watcher は、非常に大きな可能性を秘めた、急速に発展している本格的な製品であることが証明されており、それを完全に使用するには、多くの真剣な作業が必要です。

ただし、これについては、このシリーズの次の記事で詳しく説明します。

出所： habr.com