衝突と衝突: OpenStack の仮想マシンとベアメタル

[[319074]]

仮想化か非仮想化か?

パフォーマンスを追求する場合、議論の余地はありません。ベアメタルは依然として VM よりも優れています。特に I/O 集約型アプリケーションに適しています。ただし、それを十分に活用できることが保証されない限り、代償が伴います。この記事では、Nova を使用してハイパーバイザーとベアメタルコンピューティングノードへのアクセスを統一的に提供する方法について説明しました。

スケジュール

Nova が Ironic を通じてベアメタルコンピューティングをサポートするために初めて導入されたとき、従来のハイパーバイザーベースのワークロードと簡単に共存することはできませんでした。当時の解決策では、通常、ホスト集約とフレーバー機能の使用が必要でした。

ベアメタルのスケジューリングについては、特注のベアメタルブログ投稿で詳しく説明しています (「概要: Nova でのスケジューリング」を参照)。

配置サービスの導入以来、ベアメタルのスケジュールは大幅に変更されました。各 Ironic ノードについて、標準の vCPU、メモリ、およびディスクリソースを、カスタムリソースクラスの個別のユニットに置き換えます。これには 2 つの重要な副作用があります。

ベアメタルノードは完全に割り当てられるか、まったく割り当てられないかのいずれかです。
仮想マシンとベアメタルで使用されるリソースクラスは分離されているため、最終的にはベアメタルノードにVMフレーバーをスケジュールすることはできません。

「小さな」VM フレーバーは次のようになります。

 openstack フレーバー show vm-tiny -f json -c名前-c vcpus -c ram -c ディスク -c プロパティ
{
 「名前」 : 「vm-tiny」 、
 "vcpus" : 1,
 「ラム」 : 1024,
 「ディスク」 : 1,
 「プロパティ」 : 「」  
 }

「ゴールド」ノードのベアメタルフレーバーは次のようになります。

 openstack フレーバー show bare-metal-gold -f json -c name -c vcpus -c ram -c disk -c properties
 {
 「名前」 : 「ベアメタルゴールド」 、
 "vcpus" : 64,
 「ラム」 : 131072,
 「ディスク」 : 371,
 "プロパティ" : "リソース:CUSTOM_GOLD= '1' 、
                リソース:DISK_GB= '0' 、
                リソース:MEMORY_MB= '0' 、
                リソース:VCPU= '0' "
 }

vCPU/RAM/ディスクリソースは参照専用であり、スケジュール設定の目的でプロパティによってゼロに設定されることに注意してください。これについては後ほどさらに詳しく説明します。

インターネットはどうですか?

ハイブリッド環境では、VM とベアメタルインスタンスが相互に通信できるようにしたり、相互に分離したりする必要がある場合があります。どちらのモデルも可能であり、典型的な Neutron ネットワークと同じように機能します。Neutron ネットワークは、Neutron ルーターを介して接続されるまで互いに分離されています。

ベアメタルコンピューティングノードは通常、VLAN またはフラットネットワークを使用します。もちろん、ネットワークハードウェアと Neutron プラグインを適切に組み合わせれば、他のモデルも可能です。 VLAN ネットワークの場合、ハイパーバイザーがベアメタルコンピューティングノードと同じ物理ネットワークに接続されていると仮定すると、VM をベアメタルコンピューティングインスタンスと同じ VLAN に接続すると、それらの間の L2 接続が提供されます。あるいは、Neutron ルーターを使用して、VLAN 上のベアメタルインスタンスを別のネットワーク (VXLAN など) 上の VM に接続し、それらの間で L3 接続を提供することも可能になります。

これは実際にはどのように見えるのでしょうか? VM とベアメタルネットワークの両方をサポートする Neutron プラグイン/ドライバーの組み合わせが必要です。ベアメタルサーバーをテナントネットワークに接続するには、Neutron で物理ネットワークデバイスを構成する必要があります。通常は networking-generic-switch ML2 メカニズムドライバーを使用しますが、networking-ansible ドライバーがベンダー中立の代替として登場しています。これらのドライバーは、ベアメタルポート、つまり、VNIC_TYPE が baremetal の Neutron ポートをサポートします。ベンダー固有のドライバーも利用可能であり、VM とベアメタルの両方をサポートする場合があります。

何か質問はありますか？

より成熟したクラウドが遭遇する可能性がある問題の 1 つは、標準リソースクラス (vCPU、RAM、ディスク) に基づくスケジュール設定からカスタムリソースクラスに基づくスケジュール設定への移行です。 Rocky リリース以前で作成された古いベアメタルインスタンスがある場合、カスタムリソースクラスに加えて、Placement に標準のリソースクラスマニフェストが存在する可能性があります。たとえば、Placement に報告されるノードのリストは次のとおりです。

 $ openstack リソースプロバイダーインベントリリスト <ノード UUID>
 + ---------------+---------------------+----------+----------+-----------+----------+--------+  
 |リソースクラス |割り当て比率 |最大単位 |予約済み |ステップサイズ |最小単位 |合計 |
 + ---------------+---------------------+----------+----------+-----------+----------+--------+  
 |仮想CPU 1.0 | 64 | 0 | 1 | 1 | 64 |
 |メモリ1.0 | 131072 | 0 | 1 | 1 | 131072 |
 |ディスク容量1.0 | 371 | 0 | 1 | 1 | 371 |
 |カスタムゴールド | 1.0 | 1 | 0 | 1 | 1 | 1 |
 + ---------------+---------------------+----------+----------+-----------+----------+--------+

このノードが標準リソースクラスのインスタンスを要求する (または明示的にクリアされない) フレーバーに割り当てられている場合、使用法は次のようになります。

 $ openstack リソースプロバイダー使用状況表示 <ノード UUID>
 + ----------------+--------+  
 |リソースクラス |使用法 |
 + ----------------+--------+  
 |仮想CPU 64 |
 |メモリ131072 |
 |ディスク容量371 |
 |カスタムゴールド | 1 |
 + ----------------+--------+

このインスタンスを削除すると、標準のリソースクラスインベントリが使用可能になり、VM のスケジューラによって選択できるようになります。これは決して良い結果にはならないだろう。私たちがしなければならないのは、これらのリソースが Placement に報告されないようにすることです。これは、Nova の Stein バージョンではデフォルトで実行され、Rocky でも nova.conf で次のように設定することで同じことを実行するように構成できます。

 [回避策]
 report_ironic_standard_resource_class_inventory = False

ただし、これを行うと、Nova はインスタンスがすでに消費している在庫を Placement リソースプロバイダーから削除しようとし、HTTP 409 競合が発生します。これにより、すぐにログが役に立たない警告でいっぱいになります。

フレーバー移行

ありがたいことに、解決策はあります。既存のインスタンスで使用されているフレーバーを変更して、標準のリソースクラスマニフェストを削除することができます。これにより、それらのリソースの割り当てが Placement から削除されます。これにより、Nova はリソースプロバイダーからインベントリを削除できるようになります。 Matt Riedemann は、標準のリソースクラスマニフェストを削除する Nova Patch を開始しました。このパッチは生産ラインにプッシュする必要がありますが、生産 Rocky ビルドで使用するには十分に機能します。

移行はオフラインでもオンラインでも実行できます。このパッチの展開を避けるために、オフラインで実行することを選択しました。移行するノードごとに:

 nova-manage db ironic_flavor_migration --resource_class <ノード リソース クラス> --host <ホスト> --node <ノード UUID>

または、すべてのノードが同じリソースクラスを持つ場合:

 nova-manage db ironic_flavor_migration --resource_class <ノードリソースクラス> --all

データベースをチェックすることで、インスタンスに含まれるフレーバーが正しく更新されたかどうかを確認できます。

 sql> novaを使用する
sql> instance_extraからフレーバーを選択します。

現在 (Rocky のみ)、標準のリソースクラスのインベントリレポートを無効にすることができます。 nova コンピューティングサービスがしばらく実行されると、配置が更新されます。

 $ openstack リソースプロバイダーインベントリリスト <ノード UUID>
 + ----------+---------------------+----------+----------+-----------+----------+----------+  
 |リソースクラス|割り当て比率 |最大単位 |予約済み |ステップサイズ |最小単位 |合計 |
 + ----------+---------------------+----------+----------+-----------+----------+----------+  
 |カスタムゴールド | 1.0 | 1 | 0 | 1 | 1 | 1 |
 + ----------+---------------------+----------+----------+-----------+----------+----------+   
 
 $ openstack リソースプロバイダー使用状況表示 <ノード UUID>
 + ----------------+--------+  
 |リソースクラス |使用法 |
 + ----------------+--------+  
 |カスタムゴールド | 1 |
 + ----------------+--------+