衝突と衝突: 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 |
 + ----------------+--------+  

これは、OpenStack が、このような厄介なシナリオであっても VM とベアメタルが平和的に共存できる段階に到達したことを示すものであると期待しています。 Ironic を一流のプロジェクトにするために一生懸命働いてくれた Nova チームに感謝します。