一致で保存：フィルターを使用してOpenStackの局所性を高める方法

著者：アレクセイ・オヴチンニコフ



クラウド上に仮想マシンを作成するとき、多くの場合、それを何らかのストレージデバイスに関連付けたいという要望があります。 クラウド上に仮想マシンを作成するとき、可能な限り迅速に動作させたいと思うことがよくあります。 一部のデータストレージデバイスが仮想マシン（VM）に接続されている場合、それとの情報交換はバンドルのパフォーマンスを大幅に低下させる可能性があります。 したがって、ストレージデバイスがVMが展開されている物理ノードと同じ物理ノードにある場合、遅延は最小限に抑えられることは明らかです。 OpenStackプラットフォームを使用してこのような便利な配置を実現する方法は明らかではありません。



残念ながら、OpenStackはデフォルトでこのような微調整を行う手段をまだ提供していませんが、オープンで拡張が容易なプラットフォームであるため、OpenStackは同様の機能でそれ自体を補完できます。 この投稿では、開発と使用中に発生する可能性のあるこのようなアドオンと落とし穴の実装の機能について説明します。



簡単な質問、つまりVMを特定のノードに配置する方法について説明します。



誰もが（おそらく）十分に認識しているため、スケジューラー（nova-schedulerコンポーネント）はVMをノードに配置する責任があります。したがって、元の目標を達成するには、何らかの方法でその動作を変更して、ストレージデバイスの分布の特性を考慮する必要があります。 これに対する標準的なアプローチは、スケジューラフィルターを使用することです。 フィルターは、スケジューラーによるノードの選択に影響を与える可能性がありますが、フィルターはコマンドラインから制御でき、スケジューラーによって選択されたノードが対応すべき特性をフィルターに渡します。 かなり幅広いクラスの計画タスクを解決できるいくつかの標準フィルターがあり、それらはOpenStack Docsプロジェクトのドキュメントで説明されています。 それほど重要ではないタスクの場合、独自のフィルターを開発する機会が常にあります。 これが私たちが今やることです。

フィルターについて一言

フィルタリングを使用した計画の一般的な考え方は非常に単純です。ユーザーはノードが応答する特性を指定し、その後、スケジューラーはそれらに対応するノードのセットを選択します。 次に、前の段階で選択したノードの1つでVMを起動できます。 負荷と、フィルタリング段階で重要ではない他の多くの特性によって、どちらが決まるか。 フィルタリング手順をより詳細に検討してください。



多くの場合、システムには複数のフィルターが同時に存在します。 スケジューラーは、最初に使用可能なすべてのノードのリストを作成し、次に各フィルターをこのリストに適用して、各反復で不適切なノードを破棄します。 このようなモデルでは、フィルタータスクは非常に単純です。入力時に送信されたノードを考慮し、フィルター基準を満たすかどうかを決定します。 各フィルターは、少なくとも1つのメソッドhost_passes()



を持つフィルタークラスの1つのオブジェクトです。 このメソッドは、ノードおよびフィルタリング基準を入力として受け入れ、ノードが指定された基準を満たすかどうかに応じてTrue



またはFalse



を返す必要があります。 すべてのフィルタークラスは、 nova.scheduler.filters



で定義されているベースクラスBaseHostFilter()



継承する必要があります。 起動時に、スケジューラーは使用可能なフィルターのリストで指定されたすべてのモジュールをインポートします。 次に、ユーザーがVMを起動する要求を送信すると、スケジューラーは各フィルタークラスのオブジェクトを作成し、それらを使用して不適切なノードをフィルターで除外します。 これらのオブジェクトは、1つの計画セッション中に存在することに注意することが重要です。



たとえば、十分なメモリを備えたノードを選択するRAMフィルターを検討します。 これはかなり単純な構造の標準フィルターであるため、より複雑なフィルターをそれに基づいて開発できます。



クラスRamFilter（filters.BaseHostFilter）：

"" "オーバーサブスクリプションフラグ付きのラムフィルタ" ""



def host_passes（self、host_state、filter_properties）：

"" "十分なRAMがあるホストのみを返します。" ""

instance_type = filter_properties.get（ 'instance_type'）

requested_ram = instance_type ['memory_mb']

free_ram_mb = host_state.free_ram_mb

total_usable_ram_mb = host_state.total_usable_ram_mb



memory_mb_limit = total_usable_ram_mb * FLAGS.ram_allocation_ratio

used_ram_mb = total_usable_ram_mb-free_ram_mb

available_ram = memory_mb_limit-used_ram_mb

使用可能でない場合> = requested_ram：

LOG.debug（_（ "％（host_state）sは％（requested_ram）s MBを持っていません。"

「使用可能なRAM。使用可能なRAMは％（usable_ram）s MBのみです。」）、

地元の人（））

偽を返す



＃計算ノードのオーバーサブスクリプションの制限を保存して、以下をテストします：

host_state.limits ['memory_mb'] = memory_mb_limit

真を返す



特定のノードが将来のVMに適しているかどうかを判断するには、そのノードで現在どのくらいのRAMが空いているか、およびVMに必要なメモリ量をフィルターが知る必要があります。 ノードの空きメモリがVMに必要な量より少ないことが判明した場合、 host_passes()



はFalse



返し、ノードは利用可能なノードのリストから削除されます。 ノードの状態に関するすべての情報はhost_state



引数に含まれ、決定を下すのに必要な情報はfilter_properties



引数に入れられます。 ram_allocation_ratio



などのいくつかの一般的な計画戦略を反映する定数は、構成ファイルまたはフィルターコード内の別の場所で定義できますが、計画に必要なすべてのものを使用してフィルターに転送できるため、これはram_allocation_ratio



重要ではありませんいわゆるプランナーのヒント。

スケジューラーのヒント

スケジューラーのヒントは、 nova boot



コマンドによって生成されるすべての要求に含まれるキーと値のペアの辞書にすぎません。 何もしなければ、この辞書は空のままになり、興味深いことは何も起こりません。 ユーザーがヒントを渡して、辞書にヒントをnova boot … --hint your_hint_name=desired_value



することを決定した場合、これは、たとえば次のコマンドのようにキー- hint



を使用して簡単に実行できます： nova boot … --hint your_hint_name=desired_value



。 これで、ヒント付きの辞書は空ではなく、送信されたペアが含まれています。 スケジューラの拡張機能がこのヒントの使用方法を知っている場合、彼は作業時に考慮する必要のある情報を受け取りました。 そのような拡張子がなければ、何も起こりません。 2番目のケースは最初のケースほどおもしろくないので、最初のケースに注目しましょう。 拡張機能がヒントをどのように活用できるかを見てみましょう。



ヒントを使用するには、明らかにリクエストから抽出する必要があります。 この手順も非常に簡単です。すべてのヒントは、 scheduler_hints



キーによってfilter_properties



辞書に格納されます。 次のコードスニペットは、ヒントを取得する方法を完全に説明しています。



scheduler_hints = filter_properties ['scheduler_hints']

important_hint = scheduler_hints.get（ 'important_hint'、False）



nova scheduler_hints



では、scheduler_hints nova scheduler_hints



常にリクエストに存在するため、拡張機能を開発する際に不愉快な驚きを期待することはできませんが、ヒントの値を読むときは注意が必要です。



これで、任意のプロンプトを受け取ることができます。 この目標を達成するために、それらをどのように使用するかを議論することが残っています

ストレージデバイスの接続性を改善します！

スケジューラの機能を拡張する方法の知識があれば、ユーザーが関心のあるストレージデバイスが物理的に配置されているノードと同じノードでVMを実行できるフィルターを簡単に設計できます。 明らかに、使用するストレージデバイスを何らかの方法で区別する必要があります。 ここでは、各デバイスに固有のvolume_id行が役立ちます。 volume_idから、それが属するノードの名前を何らかの方法で取得し、フィルタリング段階でこのノードを選択する必要があります。 最後のタスクは両方ともフィルターで解決する必要があり、すべてが機能するには、適切なヒントを使用してフィルターにノードの名前を通知する必要があります。



まず、ヒントメカニズムを使用して、volume_idをフィルターに渡します。 このため、名前same_host_volume_id



を使用することに同意します。 これは簡単なタスクであり、すぐに次の問題に遭遇しますが、それほど明確ではありません。ホスト名を取得する方法、ストレージデバイスの識別子を知る方法などです。 残念ながら、どうやらこの問題を解決する簡単な方法はないので、データストレージの責任者であるcinderコンポーネントの助けを求めます。



cinderサービスを使用するには多くの方法があります。たとえば、API呼び出しの組み合わせを使用して、指定されたvolume_idに関連付けられたメタデータを取得し、それらからノード名を抽出します。 ただし、今回はより簡単な方法を使用します。 cinderclientモジュールの機能を利用して必要なクエリを生成し、それが返すものを処理します。



ボリューム= cinder.cinderclient（コンテキスト）.volumes.get（volume_id）

vol_host = getattr（ボリューム、「os-vol-host-attr：ホスト」、なし）



ここで注意する必要があるのは、このアプローチはGrizzly以降のリリースでのみ機能することです。なぜなら、興味のある情報を取得できるcinderの拡張機能はGrizzlyでのみ利用可能だからです。



さらなる実装は簡単ですvol_host



と入ってくる名前を比較し、一致する場合にのみTrue



を返す必要があります。 実装の詳細は、GrizzlyのパッケージまたはHavanaの実装のいずれかで確認できます。 結果のフィルターにある程度の反射があると、必然的に問題が発生します。

それはあなたができる最善ですか？

いいえ、考慮された方法は最適でも、唯一可能な方法でもありません。 そのため、単純な実装では、cinderへの複数の呼び出しに関連する問題があり、これは非常に高価であり、フィルターを遅くする他の多くの問題があります。 これらの問題は、小規模なクラスターでは重要ではありませんが、多数のノードを操作する場合、大幅な遅延につながる可能性があります。 状況を改善するために、フィルターを変更できます。たとえば、ホスト名のキャッシュを入力することにより、VMをロードするためのcinderへの1回の呼び出しに制限するか、目的のノードが検出されるとすぐにフィルターを実際にオフにするフラグを追加します



要約すると、VolumeAffinityFilterは、ローカリティを使用してクラウドのパフォーマンスを向上させる作業の始まりに過ぎず、この方向に開発の余地があることに注意してください。

あとがきの代わりに

私が調べた例は、novaスケジューラ用のフィルターを開発する方法を示しています。novaスケジューラーは、他のフィルターと区別する機能を備えています。 このフィルターは、OpenStackプラットフォームの別のコンポーネントのAPIを使用して、その目的を果たします。 柔軟性の向上に加えて、このアプローチは、サービスが互いにかなりの距離に配置される可能性があるため、全体的なパフォーマンスに悪影響を与える可能性があります。 このような微調整の問題の可能な解決策は、すべてのサービスのスケジューラーをクラウドのすべての特性にアクセスできるものに結合することですが、現時点ではこの問題を解決する簡単で効果的な方法はありません。



英語のオリジナル記事