OpenStack でのロード バランシング (パート 2)

В 前の記事 Watcher を使用する試みについて話し合い、テスト レポートを提供しました。 当社は、大企業やオペレーターのクラウドのバランス調整やその他の重要な機能を目的として、このようなテストを定期的に実施しています。

解決しようとしている問題は非常に複雑なので、プロジェクトを説明するには複数の記事が必要になる場合があります。 本日は、クラウド内の仮想マシンのバランスをとることに特化したシリーズの XNUMX 番目の記事を公開します。

ちょっとした専門用語

VmWare 社は、開発および提供した仮想化環境の負荷のバランスをとるために、DRS (Distributed Resource Scheduler) ユーティリティを導入しました。

彼が書いているように searchvmware.techtarget.com/定義/VMware-DRS
「VMware DRS (分散リソース スケジューラ) は、仮想環境で利用可能なリソースを使用してコンピューティング負荷のバランスをとるユーティリティです。 このユーティリティは、VMware Infrastructure と呼ばれる仮想化スイートの一部です。

VMware DRS を使用すると、ユーザーは仮想マシン (VM) 間で物理リソースを分散するためのルールを定義します。 このユーティリティは手動または自動制御用に構成できます。 VMware リソース プールは、簡単に追加、削除、再編成できます。 必要に応じて、リソース プールを異なるビジネス ユニット間で分離できます。 XNUMX つ以上の仮想マシンのワークロードが大幅に変化した場合、VMware DRS は仮想マシンを物理サーバー間で再分散します。 全体的なワークロードが減少した場合、一部の物理サーバーが一時的にオフラインになり、ワークロードが統合される可能性があります。」

なぜバランス調整が必要なのでしょうか?

私たちの意見では、DRS は必須のクラウド機能ですが、DRS を常にどこでも使用しなければならないという意味ではありません。 クラウドの目的とニーズに応じて、DRS と分散方法には異なる要件が存在する場合があります。 バランス調整がまったく必要ない状況もあるかもしれません。 あるいは有害ですらあります。

DRS がどこでどのクライアントに必要なのかをより深く理解するために、クライアントの目標と目的を考えてみましょう。 クラウドはパブリックとプライベートに分類できます。 これらのクラウドとお客様の目標との主な違いは次のとおりです。

プライベート クラウド / 大企業のクライアント
パブリッククラウド / 中小企業・人材

オペレーターの主な基準と目標
信頼できるサービスや商品の提供
競争市場におけるサービスコストの削減

サービス要件
すべてのレベルおよびすべてのシステム要素における信頼性

保証されたパフォーマンス

仮想マシンをいくつかのカテゴリに優先順位付けする 

情報および物理データのセキュリティ

SLA と XNUMX 時間年中無休のサポート
サービスを受けやすさを最大限に高める

比較的シンプルなサービス

データに対する責任はクライアントにあります

VMの優先順位付けは必要ありません

標準サービスレベルの情報セキュリティ、クライアントの責任

不具合がある可能性があります

SLAなし、品質は保証されない

電子メールサポート

バックアップは必要ありません

クライアント機能
非常に幅広い応用範囲。

社内で引き継がれたレガシーアプリケーション。

各クライアントの複雑なカスタム アーキテクチャ。

アフィニティ ルール。

ソフトウェアは 7x24 モードで停止することなく動作します。 

オンザフライバックアップツール。

予測可能な周期的な顧客負荷。
代表的なアプリケーション – ネットワークバランシング、Apache、WEB、VPN、SQL

アプリケーションが一時的に停止する場合があります

クラウド内での VM の任意の分散を可能にする

クライアントのバックアップ

多数のクライアントによる予測可能な統計的に平均化された負荷。

建築への影響
ジオクラスタリング

集中型または分散型ストレージ

予約済み IBS
計算ノード上のローカル データ ストレージ

目標のバランスを取る
均等な負荷分散

アプリケーションの応答性を最大限に高める 

バランスをとるための最小遅延時間

明らかに必要な場合にのみバランスをとる

予防保守のために一部の機器を持ち出す
サービスコストとオペレーターコストの削減 

低負荷時に一部のリソースを無効にする

省エネ

人件費の削減

私たちは自分自身で次の結論を導き出しました。

プライベートクラウドの場合DRS は大企業顧客に提供されているため、次の制限に従って使用できます。

• 情報セキュリティとバランスをとる際のアフィニティ ルールの考慮。
• 事故が発生した場合に備えて十分なリソースを確保できるかどうか。
• 仮想マシンのデータは集中型または分散型ストレージ システムに配置されます。
• 管理、バックアップ、バランス調整の手順を時間的に分離する。
• クライアントホストの集合体内でのみバランスをとる。
• 強い不均衡がある場合にのみバランスをとる、最も効果的で安全な VM 移行 (結局のところ、移行は失敗する可能性があります)。
• 比較的「静かな」仮想マシンのバランスを取る（「ノイズの多い」仮想マシンの移行には非常に長い時間がかかる場合があります）。
• 「コスト」、つまりストレージ システムとネットワークの負荷 (大規模クライアント向けにカスタマイズされたアーキテクチャ) を考慮してバランスをとる。
• 各 VM の個別の動作特性を考慮してバランスをとる。
• バランス調整は、勤務時間外 (夜間、週末、休日) に行うことが望ましいです。

パブリッククラウド向け小規模顧客にサービスを提供する場合、高度な機能を備えた DRS をより頻繁に使用できます。

• 情報セキュリティ制限とアフィニティ ルールがないこと。
• クラウド内のバランスをとる。
• 適切な時点でバランスをとる。
• 任意の VM のバランスをとる。
• 「ノイズの多い」仮想マシンのバランスを調整します (他の人の迷惑にならないように)。
• 仮想マシンのデータはローカル ディスクに配置されることがよくあります。
• ストレージ システムとネットワークの平均パフォーマンスを考慮します (クラウド アーキテクチャは統合されています)。
• 一般的なルールと利用可能なデータセンターの動作統計に従ってバランスを調整します。

問題の複雑さ

バランスをとることの難しさは、DRS が多数の不確実な要素に対処しなければならないことです。

• 各クライアントの情報システムのユーザーの行動。
• 情報システムサーバーを運用するためのアルゴリズム。
• DBMS サーバーの動作。
• コンピューティング リソース、ストレージ システム、ネットワークへの負荷。
• クラウド リソースをめぐる争いにおけるサーバー間の相互作用。

クラウド リソース上の多数の仮想アプリケーション サーバーとデータベースの負荷は時間の経過とともに発生し、その結果が顕在化し、予測できない期間にわたって予測できない影響が互いに重なり合う可能性があります。 比較的単純なプロセスを制御する場合でも (たとえば、家庭のエンジンや給湯システムを制御する場合)、自動制御システムは複雑な機能を使用する必要があります。 比例積分微分 フィードバック付きのアルゴリズム。

私たちのタスクは何桁も複雑であり、ユーザーからの外部の影響がない場合でも、システムが適切な時間内に負荷のバランスを確立された値に合わせることができないリスクがあります。

開発の歴史

この問題を解決するために、私たちはゼロから始めるのではなく、既存の経験を基に構築することを決定し、この分野で経験のある専門家との対話を開始しました。 幸いなことに、問題に対する私たちの理解は完全に一致しました。

段階1

私たちはニューラルネットワーク技術に基づくシステムを使用し、それに基づいてリソースの最適化を試みました。

この段階の関心は新しいテクノロジーをテストすることであり、その重要性は、他の条件が同じであれば、標準的なアプローチでは事実上使い果たされてしまった問題を解決するために、非標準的なアプローチを適用することにありました。

システムを立ち上げ、本格的にバランス調整を開始しました。 私たちのクラウドの規模では、開発者が述べたような楽観的な結果を得ることができませんでしたが、バランスがうまくいっているのは明らかでした。

同時に、非常に深刻な制限もありました。

• ニューラル ネットワークをトレーニングするには、仮想マシンを大幅な変更を加えずに数週間または数か月間実行する必要があります。
• このアルゴリズムは、以前の「履歴」データの分析に基づいて最適化するように設計されています。
• ニューラル ネットワークのトレーニングには、かなり大量のデータとコンピューティング リソースが必要です。
• 最適化とバランス調整は比較的まれに (数時間に XNUMX 回) 実行できますが、これでは明らかに十分ではありません。

段階2

この現状に満足できなかったので、システムを修正することにしました。 主な質問 – 誰のために作っているのでしょうか？

まず、法人顧客向けです。 これは、実装を簡素化するだけの企業制限を備えた、迅速に機能するシステムが必要であることを意味します。

二番目の質問 ――「速やかに」とはどういう意味ですか？ 短い議論の結果、短期間のサージによってシステムが共振状態にならないように、応答時間は 5 ～ 10 分で開始できると判断しました。

三番目の質問 – サーバーのバランスのとれた数はどれくらいのサイズを選択すればよいでしょうか?
この問題は自動的に解決されました。 通常、クライアントはサーバー集約をそれほど大きくしません。これは、集約を 30 ～ 40 台のサーバーに制限するという記事の推奨事項と一致しています。

さらに、サーバー プールをセグメント化することで、バランシング アルゴリズムのタスクを簡素化します。

XNUMX番目の質問 – 学習プロセスが長く、バランシングがまれなニューラル ネットワークは、私たちにとってどの程度適していますか? 数秒で結果を得るために、私たちはそれを放棄し、よりシンプルな操作アルゴリズムを採用することにしました。

このようなアルゴリズムを使用するシステムとその欠点についての説明は、次のとおりです。 ここで

このシステムを実装して立ち上げたところ、心強い結果が得られました。現在では定期的にクラウドの負荷が分析され、仮想マシンの移動に関する推奨事項が作成されますが、これはほぼ正しいものです。 現在でも、既存の仮想マシンの作業品質を向上させながら、新しい仮想マシンのリソースの 10 ～ 15% の解放を達成できることは明らかです。

RAM または CPU の不均衡が検出されると、システムは Tionix スケジューラにコマンドを発行して、必要な仮想マシンのライブ マイグレーションを実行します。 監視システムからわかるように、仮想マシンはある (上位) ホストから別の (下位) ホストに移動し、上位ホスト (黄色の丸で強調表示) 上のメモリを解放し、それを下位ホスト (白色で強調表示) で占有します。丸）。

現在、私たちは現在のアルゴリズムの有効性をより正確に評価し、アルゴリズム内で考えられるエラーを見つけようとしています。

段階3

これについては落ち着いて、有効性が証明されるのを待ってトピックを閉じることができるようです。
しかし、次の明らかな最適化の機会により、私たちは新たな段階に進むよう促されています。

1. 統計など、 ここで и ここで XNUMX プロセッサと XNUMX プロセッサのシステムは、シングル プロセッサ システムに比べてパフォーマンスが大幅に低いことがわかります。 これは、シングルプロセッサ システムと比較して、マルチプロセッサ システムで購入した CPU、RAM、SSD、LAN、FC からすべてのユーザーが受け取る出力が大幅に少ないことを意味します。
2. リソース スケジューラ自体に重大なエラーが発生する可能性があります。 ここに記事の XNUMX つがあります このトピックについて
3. Intel と AMD が提供する RAM とキャッシュの監視テクノロジーを使用すると、仮想マシンの動作を調査し、「騒々しい」近隣マシンが「静かな」仮想マシンに干渉しないように仮想マシンを配置することができます。
4. 一連のパラメーター (ネットワーク、ストレージ システム、仮想マシンの優先順位、移行コスト、移行の準備状況) の拡張。

合計で

バランシング アルゴリズムを改善するための取り組みの結果、最新のアルゴリズムを使用すると、データ センター リソースの大幅な最適化 (25 ～ 30%) を達成し、同時に顧客サービスの品質を向上させることが可能であるという明確な結論が得られました。

ニューラル ネットワークに基づくアルゴリズムは確かに興味深いソリューションですが、さらなる開発が必要であり、既存の制限のため、プライベート クラウドに典型的なボリュームでこの種の問題を解決するのには適していません。 同時に、このアルゴリズムは、かなりの規模のパブリック クラウドでも良好な結果を示しました。

プロセッサー、スケジューラー、および高レベルのバランシングの機能については、次の記事で詳しく説明します。

出所： habr.com