クラウド インフラストラクチャのネットワーク部分の概要

クラウドコンピューティングは私たちの生活にますます浸透しており、クラウドサービスを一度も利用したことがない人はいないでしょう。 しかし、クラウドとは正確に何なのか、そしてそれがどのように機能するのかを、アイデアのレベルであっても知っている人はほとんどいません。 5G はすでに現実になりつつあり、通信インフラが完全なハードウェア ソリューションから仮想化された「柱」に移行したときと同じように、柱ソリューションからクラウド ソリューションに移行し始めています。

今日はクラウド インフラストラクチャの内部世界について、特にネットワーク部分の基本について説明します。

クラウドとは何ですか? 同じ仮想化 - プロファイルビュー?

論理的な質問以上のものです。 いいえ、これは仮想化ではありませんが、仮想化なしでは実現できません。 XNUMX つの定義を見てみましょう。

クラウドコンピューティング（以下、クラウド） 分散コンピューティング リソースへのユーザー フレンドリーなアクセスを提供するためのモデルです。分散コンピューティング リソースは、可能な限り待ち時間を最小限に抑え、サービス プロバイダーのコストを最小限に抑えて、オンデマンドで展開および起動する必要があります。

仮想化 - これは、3 つの物理エンティティ (サーバーなど) を複数の仮想エンティティに分割する機能で、これによりリソースの使用率が向上します (たとえば、25 台のサーバーが 30 ～ 1 パーセントで負荷されていましたが、仮想化後は 80 台のサーバーが負荷されるようになります) 90〜XNUMXパーセント）。 当然のことながら、仮想化はリソースの一部を消費します。ハイパーバイザーに供給する必要がありますが、実践が示しているように、このゲームにはろうそくの価値があります。 仮想化の理想的な例としては、仮想マシンを完全に準備する VMWare や、たとえば私が好む KVM がありますが、これは好みの問題です。

私たちは無意識に仮想化を使用しており、鉄のルーターでさえもすでに仮想化を使用しています。たとえば、最新バージョンの JunOS では、オペレーティング システムはリアルタイム Linux ディストリビューション (Wind River 9) 上の仮想マシンとしてインストールされます。 ただし、仮想化はクラウドではありません。仮想化なしではクラウドは存在できません。

仮想化は、クラウドを構築するための構成要素の XNUMX つです。

複数のハイパーバイザーを 2 つの LXNUMX ドメインに集めてクラウドを作成し、ある種の Ansible を介して VLAN を自動的に登録するための yaml プレイブックをいくつか追加し、仮想マシンを自動的に作成するためにオーケストレーション システムのようなものをそこに詰め込むだけでは、機能しません。 それはより正確になりますが、結果として得られるフランケンシュタインは、他の人にとっては究極の夢かもしれませんが、私たちが必要とする雲ではありません。 さらに、同じ Openstack を使用したとしても、本質的にはフランケンシュタインのままですが、まあ、それについては今は話さないでおこうと思います。

しかし、上記の定義からは、実際に何をクラウドと呼べるのかは完全には明らかではないことは理解しています。

したがって、NIST (国立標準技術研究所) の文書では、クラウド インフラストラクチャが持つべき 5 つの主な特性が示されています。

リクエストに応じてサービスを提供します。 ユーザーには、自分に割り当てられたコンピューター リソース (ネットワーク、仮想ディスク、メモリ、プロセッサ コアなど) への自由なアクセスが与えられなければなりません。また、これらのリソースは、サービス プロバイダーの介入なしに自動的に提供される必要があります。

幅広いサービスが利用可能。 標準の PC、シン クライアント、およびモバイル デバイスの両方を使用できるようにするには、リソースへのアクセスを標準のメカニズムによって提供する必要があります。

リソースをプールに結合します。 リソース プールは、複数のクライアントに同時にリソースを提供でき、クライアントが分離され、相互影響やリソースの競合が発生しないようにする必要があります。 ネットワークもプールに含まれており、重複したアドレス指定が使用される可能性があることがわかります。 プールはオンデマンドで拡張できる必要があります。 プールを使用すると、必要なレベルのリソース フォールト トレランスと、物理リソースと仮想リソースの抽象化を提供できます。サービスの受信者には、要求したリソースのセットが提供されるだけです (これらのリソースは物理的にどこに配置され、いくつあるのか)。サーバーとスイッチ - クライアントにとっては関係ありません)。 ただし、プロバイダーはこれらのリソースの透過的な予約を保証する必要があるという事実を考慮する必要があります。

さまざまな条件への素早い適応。 サービスは柔軟である必要があります。リソースの迅速な提供、再配布、クライアントの要求に応じたリソースの追加または削減など、クライアント側ではクラウド リソースが無限であると感じる必要があります。 たとえば、理解を容易にするために、サーバー上のハード ドライブが故障したために Apple iCloud のディスク領域の一部が消失したという警告は表示されませんが、ドライブは実際に故障します。 さらに、あなた側では、このサービスの可能性はほぼ無限です - 2 TB が必要です - 問題ありません、あなたは支払い、受け取りました。 同様の例は、Google.Drive または Yandex.Disk にも当てはまります。

提供されたサービスを測定する可能性。 クラウド システムは、消費されるリソースを自動的に制御および最適化する必要があり、これらのメカニズムはユーザーとサービス プロバイダーの両方に対して透過的である必要があります。 つまり、あなたとあなたのクライアントが消費しているリソースの数をいつでも確認できます。

これらの要件は主にパブリック クラウドの要件であるため、プライベート クラウド (つまり、企業の内部ニーズのために立ち上げられたクラウド) の場合は、これらの要件を若干調整できるという事実を考慮する価値があります。 しかし、それでも実現する必要があります。そうしないと、クラウド コンピューティングのメリットをすべて享受できなくなります。

なぜクラウドが必要なのでしょうか?

ただし、新規または既存のテクノロジ、新しいプロトコルは、何かのために作成されます (もちろん、RIP-ng は除きます)。 プロトコルのためにプロトコルを必要とする人はいません (もちろん、RIP-ng を除いて)。 クラウドがユーザー/クライアントに何らかのサービスを提供するために作成されるのは論理的です。 私たちは皆、Dropbox や Google.Docs など、少なくとも XNUMX つのクラウド サービスに精通しており、ほとんどの人がそれらをうまく活用していると思います。たとえば、この記事は Google.Docs クラウド サービスを使用して書かれています。 しかし、私たちが知っているクラウド サービスは、クラウドの機能の一部にすぎません。より正確には、それらは SaaS タイプのサービスにすぎません。 クラウドサービスはSaaS、PaaS、IaaSのXNUMXつの方法で提供できます。 どのようなサービスが必要かは、あなたの希望と能力によって異なります。

それぞれを順番に見てみましょう。

サービスとしてのソフトウェア（SaaS） Yandex.Mail や Gmail などの電子メール サービスなど、本格的なサービスをクライアントに提供するためのモデルです。 このサービス配信モデルでは、クライアントとしては、実際にはサービスを使用すること以外は何もしません。つまり、サービスの設定、そのフォールト トレランス、または冗長性について考える必要はありません。 重要なのはパスワードを危険にさらさないことです。残りの作業はこのサービスのプロバイダーが行います。 サービス プロバイダーの観点から見ると、サーバー ハードウェアやホスト オペレーティング システムからデータベースやソフトウェアの設定に至るまで、サービス全体に対して全責任を負います。

サービスとしてのプラットフォーム（PaaSの） — このモデルを使用する場合、サービスプロバイダーはクライアントにサービス用のワークピースを提供します。たとえば、Web サーバーを考えてみましょう。 サービスプロバイダーは、クライアントに仮想サーバー (実際には、RAM/CPU/ストレージ/ネットなどのリソースのセット) を提供し、このサーバーに OS と必要なソフトウェアをインストールします。これらすべてはクライアント自身によって行われ、クライアントが応答するサービスのパフォーマンスのために行われます。 前のケースと同様に、サービス プロバイダーは、物理機器、ハイパーバイザー、仮想マシン自体のパフォーマンス、ネットワークの可用性などに対して責任を負いますが、サービス自体はもはやその責任範囲ではありません。

サービスとしてのインフラストラクチャ（IaaSの） - このアプローチはすでにさらに興味深いものであり、実際、サービス プロバイダーはクライアントに完全な仮想化インフラストラクチャ、つまり CPU コア、RAM、ネットワークなどのリソースのセット (プール) を提供します。その他はすべて次第です。クライアント - クライアントが割り当てられたプール (クォータ) 内でこれらのリソースを使用して何をしたいか - サプライヤーにとっては特に重要ではありません。 クライアントが独自の vEPC を作成したい場合でも、ミニ オペレーターを作成して通信サービスを提供したい場合でも、疑いなく、それを実行してください。 このようなシナリオでは、サービス プロバイダーは、リソース、そのフォールト トレランスと可用性、およびこれらのリソースをプールし、いつでもリソースを増減できるようにクライアントが利用できるようにする OS のプロビジョニングを担当します。クライアントのリクエストに応じて。 クライアントは、セルフサービス ポータルとコンソールを通じて、ネットワーク (外部ネットワークを除く) のセットアップを含め、すべての仮想マシンとその他の見掛け倒しを自分で構成します。

オープンスタックとは何ですか?

XNUMX つのオプションすべてにおいて、サービス プロバイダーにはクラウド インフラストラクチャの作成を可能にする OS が必要です。 実際、SaaS では、複数の部門がテクノロジーのスタック全体を担当します。インフラストラクチャを担当する部門があります。つまり、別の部門に IaaS を提供し、この部門がクライアントに SaaS を提供します。 OpenStack は、多数のスイッチ、サーバー、ストレージ システムを XNUMX つのリソース プールに収集し、この共通プールをサブプール (テナント) に分割し、これらのリソースをネットワーク経由でクライアントに提供できるクラウド オペレーティング システムの XNUMX つです。

OpenStackは は、標準の認証メカニズムを使用する API を通じてプロビジョニングおよび管理される、コンピューティング リソース、データ ストレージ、およびネットワーク リソースの大規模なプールを制御できるクラウド オペレーティング システムです。

言い換えれば、これはクラウド サービス (パブリックとプライベートの両方) を作成するように設計された一連のフリー ソフトウェア プロジェクトです。つまり、サーバーとスイッチング機器を単一のリソース プールに結合し、管理を可能にするツールのセットです。これらのリソースにより、必要なレベルのフォールト トレランスが提供されます。

この資料の執筆時点では、OpenStack の構造は次のようになります。

からの写真 openstack.org

OpenStack に含まれる各コンポーネントは、特定の機能を実行します。 この分散アーキテクチャにより、必要な機能コンポーネントのセットをソリューションに含めることができます。 ただし、一部のコンポーネントはルート コンポーネントであり、それらを削除すると、ソリューション全体が完全または部分的に動作不能になります。 これらのコンポーネントは通常、次のように分類されます。

• ダッシュボード — OpenStack サービスを管理するための Web ベースの GUI
• キーストーン は、他のサービスの認証および認可機能を提供し、ユーザーの資格情報とその役割を管理する集中型の ID サービスです。
• 中性子 - さまざまな OpenStack サービスのインターフェイス間の接続を提供するネットワーク サービス (VM 間の接続および外部世界へのアクセスを含む)
• シンダー — 仮想マシンのブロック ストレージへのアクセスを提供します
• ノヴァ — 仮想マシンのライフサイクル管理
• ひと目 — 仮想マシンのイメージとスナップショットのリポジトリ
• スウィフト — ストレージ オブジェクトへのアクセスを提供します
• シーロメーター — テレメトリを収集し、利用可能なリソースと消費されたリソースを測定する機能を提供するサービス
• ヒート — リソースの自動作成とプロビジョニングのためのテンプレートに基づくオーケストレーション

すべてのプロジェクトとその目的の完全なリストを表示できます。 ここで.

OpenStack の各コンポーネントは、特定の機能を実行し、その機能を管理し、他のクラウド オペレーティング システム サービスと対話して統合インフラストラクチャを作成するための API を提供するサービスです。 たとえば、Nova はコンピューティング リソース管理とこれらのリソースの構成にアクセスするための API を提供し、Glance はイメージ管理とそれらを管理するための API を提供し、Cinder はブロック ストレージとそれを管理するための API を提供します。 すべての機能は非常に密接に相互接続されています。

しかし、よく見てみると、OpenStack で実行されているすべてのサービスは、最終的にはネットワークに接続されたある種の仮想マシン (またはコンテナ) です。 なぜこれほど多くの要素が必要なのかという疑問が生じます。

仮想マシンを作成し、それを Openstack のネットワークと永続ストレージに接続するためのアルゴリズムを見てみましょう。

1. マシンを作成するリクエストを作成するとき、それが Horizo​​n (ダッシュボード) を介したリクエストであっても、CLI を介したリクエストであっても、最初に行われるのは Keystone でのリクエストの承認です。マシンを作成できますか?このネットワークを使用する権利、ドラフトクォータなど。
2. Keystone はリクエストを認証し、応答メッセージ内に認証トークンを生成します。このトークンはさらに使用されます。 Keystone から応答を受信すると、リクエストは Nova (nova API) に送信されます。
3. Nova-api は、以前に生成された認証トークンを使用して Keystone に接続し、リクエストの有効性をチェックします。
4. Keystone は認証を実行し、この認証トークンに基づいて権限と制限に関する情報を提供します。
5. nova-api は、nova-database に新しい VM のエントリを作成し、マシンを作成するリクエストを nova-scheduler に渡します。
6. Nova スケジューラは、指定されたパラメータ、重み、ゾーンに基づいて VM が展開されるホスト (コンピュータ ノード) を選択します。 この記録と VM ID が nova-database に書き込まれます。
7. 次に、nova-scheduler は nova-compute に接続して、インスタンスのデプロイを要求します。 Nova-compute は、nova-conductor に接続してマシンパラメーターに関する情報を取得します (nova-conductor は、nova-database と nova-compute の間のプロキシサーバーとして機能する nova 要素であり、データベースの問題を回避するために nova-database へのリクエストの数を制限します)一貫性負荷の軽減)。
8. Nova-conductor は、nova-database から要求された情報を受け取り、それを nova-compute に渡します。
9. 次に、nova-compute は、glance を呼び出してイメージ ID を取得します。 Glace は Keystone でリクエストを検証し、リクエストされた情報を返します。
10. Nova-compute は neutron に接続して、ネットワーク パラメーターに関する情報を取得します。 グランスと同様に、neutron は Keystone でリクエストを検証し、その後データベースにエントリ (ポート識別子など) を作成し、ポートを作成するリクエストを作成し、リクエストされた情報を nova-compute に返します。
11. Nova-compute は cinder に接続して、仮想マシンにボリュームを割り当てるリクエストを送信します。 グランスと同様に、cider は Keystone でリクエストを検証し、ボリューム作成リクエストを作成し、リクエストされた情報を返します。
12. Nova-compute は、指定されたパラメーターを使用して仮想マシンをデプロイするリクエストを libvirt に送信します。

実際、単純な仮想マシンを作成するという一見単純な操作が、クラウド プラットフォームの要素間での API 呼び出しの渦に変わります。 さらに、ご覧のとおり、以前に指定されたサービスも、相互作用が発生する小さなコンポーネントで構成されています。 マシンの作成は、クラウド プラットフォームで実行できることのほんの一部にすぎません。トラフィックのバランスを担当するサービス、ブロック ストレージを担当するサービス、DNS を担当するサービス、ベア メタル サーバーのプロビジョニングを担当するサービスなどがあります。クラウドを使用すると、仮想マシンを (仮想化ではなく) 羊の群れのように扱うことができます。 仮想環境でマシンに問題が発生した場合 - バックアップなどから復元しますが、クラウド アプリケーションは仮想マシンがそれほど重要な役割を果たさないように構築されています - 仮想マシンが「死亡」しました - 問題ありません- 新しい車両が作成されるだけで、車両はテンプレートに基づいており、彼らが言うように、分隊は戦闘機の損失に気づきませんでした。 当然のことながら、これによりオーケストレーション メカニズムが提供されます。Heat テンプレートを使用すると、数十のネットワークと仮想マシンで構成される複雑な機能を簡単にデプロイできます。

ネットワークのないクラウド インフラストラクチャは存在しないことを常に念頭に置く価値があります。各要素はネットワークを通じて何らかの方法で他の要素と対話します。 さらに、クラウドには完全に非静的なネットワークがあります。 当然のことながら、アンダーレイ ネットワークは多かれ少なかれ静的です。新しいノードやスイッチは毎日追加されるわけではありませんが、オーバーレイ コンポーネントは常に変化する可能性があり、必然的に変化します。新しいネットワークが追加または削除され、新しい仮想マシンが現れたり、古い仮想マシンが現れたりします。死ぬ。 そして、この記事の最初に示したクラウドの定義から覚えているように、リソースは自動的に、サービス プロバイダーの介入を最小限に (またはできれば、介入なしで) ユーザーに割り当てられる必要があります。 つまり、http/https 経由でアクセスできる個人アカウントの形でフロントエンドの形で存在し、バックエンドとして勤務中のネットワーク エンジニアである Vasily が提供するネットワーク リソースの提供のタイプは、クラウドではありません。ヴァシリーがXNUMX本の手を持っていたら。

Neutron は、ネットワーク サービスとして、クラウド インフラストラクチャのネットワーク部分を管理するための API を提供します。 このサービスは、Network-as-a-Service (NaaS) と呼ばれる抽象化レイヤーを提供することで、Openstack のネットワーク部分を強化および管理します。 つまり、ネットワークは、仮想 CPU コアや RAM の量などと同じ仮想的な測定可能な単位です。

ただし、OpenStack のネットワーク部分のアーキテクチャに進む前に、このネットワークが OpenStack でどのように機能するのか、またネットワークがクラ​​ウドの重要かつ不可欠な部分である理由を考えてみましょう。

したがって、XNUMX つの RED クライアント VM と XNUMX つの GREEN クライアント VM があります。 これらのマシンが次のように XNUMX つのハイパーバイザー上に配置されていると仮定します。

現時点では、これは 4 台のサーバーを仮想化するだけであり、それ以上のことはありません。これまでに行ったのは 4 台のサーバーを仮想化し、XNUMX 台の物理サーバーに配置することだけです。 そして今のところ、ネットワークにも接続されていません。

クラウドを作成するには、いくつかのコンポーネントを追加する必要があります。 まず、ネットワーク部分を仮想化します。これら 4 台のマシンをペアで接続する必要があり、クライアントは L2 接続を必要とします。 スイッチを使用してその方向にトランクを構成し、Linux ブリッジを使用してすべてを解決するか、より上級ユーザーの場合は openvswitch (これについては後で説明します) を使用してすべてを解決できます。 しかし、ネットワークは多数存在する可能性があり、常にスイッチを介して L2 をプッシュすることは最良のアイデアではありません。さまざまな部門があり、サービス デスクがあり、アプリケーションが完了するまで数か月待ち、トラブルシューティングに数週間かかります。現代の世界では、これはアプローチはもう機能しません。 そして、企業がこれを理解するのが早ければ早いほど、前進することが容易になります。 したがって、ハイパーバイザー間で、仮想マシンが通信する L3​​ ネットワークを選択し、この L3 ネットワーク上に、仮想マシンのトラフィックが実行される仮想 L2 オーバーレイ ネットワークを構築します。 カプセル化として GRE、Geneve、または VxLAN を使用できます。 特に重要ではありませんが、今は後者に焦点を当てましょう。

VTEP をどこかに見つける必要があります (皆さんが VxLAN の用語に精通していることを願っています)。 サーバーから直接 L3 ネットワークが接続されているため、サーバー自体に VTEP を配置することを妨げるものは何もありません。OVS (OpenvSwitch) はこれを行うのに優れています。 その結果、次のようなデザインが得られました。

VM 間のトラフィックは分割する必要があるため、仮想マシンへのポートには異なる VLAN 番号が割り当てられます。 タグ番号は XNUMX つの仮想スイッチ内でのみ役割を果たします。これは、VxLAN にカプセル化されている場合、VNI があるため簡単に削除できるためです。

これで、問題なくマシンとその仮想ネットワークを作成できるようになりました。

しかし、クライアントに別のマシンがあり、別のネットワーク上にある場合はどうなるでしょうか? ネットワーク間で root 化が必要です。 集中ルーティングが使用される場合の単純なオプションを見ていきます。つまり、トラフィックは特別な専用ネットワーク ノードを介してルーティングされます (通常、それらは制御ノードと結合されるため、同じことになります)。

複雑なことは何もないようです。制御ノード上にブリッジ インターフェイスを作成し、そこにトラフィックを送り、そこから必要な場所にルーティングします。 しかし、問題は、RED クライアントが 10.0.0.0/24 ネットワークの使用を希望し、GREEN クライアントが 10.0.0.0/24 ネットワークの使用を希望していることです。 つまり、アドレス空間が交差し始めます。 さらに、クライアントは他のクライアントが内部ネットワークにルーティングできることを望んでいませんが、これは当然のことです。 ネットワークとクライアント データ トラフィックを分離するために、それぞれに個別の名前空間を割り当てます。 名前空間は、実際には、Linux ネットワーク スタックのコピーです。つまり、名前空間 RED のクライアントは、名前空間 GREEN のクライアントから完全に分離されています (これらのクライアント ネットワーク間のルーティングは、デフォルトの名前空間または上流のトランスポート機器を介して許可されます)。

つまり、次の図が得られます。

L2 トンネルは、すべてのコンピューティング ノードから制御ノードに集中します。 これらのネットワークの L3 インターフェイスが配置されるノード。それぞれが分離のための専用の名前空間にあります。

しかし、私たちは最も重要なことを忘れていました。 仮想マシンはクライアントにサービスを提供する必要があります。つまり、仮想マシンにアクセスできる外部インターフェイスが少なくとも XNUMX つ必要です。 つまり、外の世界へ出ていく必要があるのです。 ここにはさまざまなオプションがあります。 最も単純なオプションを実行しましょう。 各クライアントに XNUMX つのネットワークを追加します。このネットワークはプロバイダーのネットワーク内で有効であり、他のネットワークと重複しません。 ネットワークは交差して、プロバイダー ネットワーク側の異なる VRF を確認することもできます。 ネットワーク データも各クライアントの名前空間に存在します。 ただし、それらは依然として XNUMX つの物理 (または結合、より論理的な) インターフェイスを介して外の世界に出ます。 クライアント トラフィックを分離するために、外部に送信されるトラフィックには、クライアントに割り当てられた VLAN タグが付けられます。

その結果、次の図が得られました。

当然の疑問は、なぜ計算ノード自体にゲートウェイを作成しないのかということです。 これは大きな問題ではありません。さらに、分散ルーター (DVR) をオンにすると、これが機能します。 このシナリオでは、Openstack でデフォルトで使用される集中型ゲートウェイを使用した最も単純なオプションを検討します。 高負荷機能の場合、分散ルーターと SR-IOV やパススルーなどの高速化テクノロジーの両方を使用しますが、彼らが言うように、それはまったく別の話です。 まず基本的な部分について説明し、次に詳細を説明します。

実際、私たちのスキームはすでに実行可能ですが、いくつかのニュアンスがあります。

• 何らかの方法でマシンを保護する必要があります。つまり、クライアントへのスイッチ インターフェイスにフィルターを設定する必要があります。
• 仮想マシンが自動的に IP アドレスを取得できるようにすると、毎回コンソールからログインしてアドレスを登録する必要がなくなります。

まずはマシンを保護することから始めましょう。 このためには、平凡な iptables を使用できます。

つまり、トポロジはもう少し複雑になっています。

次へ移りましょう。 DHCP サーバーを追加する必要があります。 各クライアントの DHCP サーバーを配置する最も理想的な場所は、ネームスペースが配置されている前述の制御ノードです。

ただし、小さな問題があります。 すべてが再起動され、DHCP 上のアドレスのレンタルに関する情報がすべて消えてしまったらどうなるでしょうか。 マシンに新しいアドレスが与えられるのは当然ですが、これはあまり便利ではありません。 ここには 8 つの方法があります - ドメイン名を使用するか、クライアントごとに DNS サーバーを追加します。そうすれば、アドレスは私たちにとって特に重要ではなくなります (kXNUMXs のネットワーク部分と同様) - しかし、外部ネットワークには問題があります。アドレスは DHCP 経由で発行することもできます。クラウド プラットフォーム内の DNS サーバーおよび外部 DNS サーバーとの同期が必要です。私の意見では、これはあまり柔軟性がありませんが、十分に可能です。 または、XNUMX 番目のオプションは、メタデータを使用することです。つまり、マシンに発行されたアドレスに関する情報を保存して、マシンがすでにアドレスを受信して​​いる場合に、DHCP サーバーがそのマシンにどのアドレスを発行するかを認識できるようにします。 XNUMX 番目のオプションは、車に関する追加情報を保存できるため、よりシンプルで柔軟です。 次に、エージェントのメタデータを図に追加しましょう。

議論する価値のあるもう XNUMX つの問題は、すべてのクライアントが XNUMX つの外部ネットワークを使用できることです。外部ネットワークがネットワーク全体で有効である必要がある場合、外部ネットワークは困難になるため、これらのネットワークの割り当てを常に割り当てて制御する必要があります。 すべてのクライアントに対して単一の事前構成済み外部ネットワークを使用できる機能は、パブリック クラウドを作成するときに非常に役立ちます。 これにより、アドレス データベースを参照して各クライアントの外部ネットワークに固有のアドレス空間を選択する必要がなくなるため、マシンの展開が容易になります。 さらに、外部ネットワークを事前に登録でき、展開時に外部アドレスをクライアント マシンに関連付けるだけで済みます。

ここで NAT が役に立ちます。NAT 変換を使用して、クライアントがデフォルトの名前空間を通じて外部の世界にアクセスできるようにするだけです。 さて、ここで小さな問題があります。 これは、クライアント サーバーがサーバーとしてではなくクライアントとして機能する場合、つまり接続を受け入れるのではなく開始する場合に適しています。 しかし、私たちにとっては逆になります。 この場合、トラフィックを受信するときに、このトラフィックがクライアント A の仮想マシン A 宛てであることを制御ノードが理解できるように、宛先 NAT を実行する必要があります。つまり、外部アドレス (100.1.1.1 など) から NAT 変換を行う必要があります。 .10.0.0.1、内部アドレス 100 へ。 この場合、すべてのクライアントが同じネットワークを使用しますが、内部の分離は完全に維持されます。 つまり、制御ノードで dNAT と sNAT を実行する必要があります。 フローティング アドレスを持つ単一のネットワークを使用するか、外部ネットワークを使用するか、あるいはその両方を同時に使用するかは、クラウドに何を取り込みたいかによって異なります。 この図にはフローティング アドレスを追加しませんが、すでに追加されている外部ネットワークはそのままにしておきます。各クライアントには独自の外部ネットワークがあります (図では、外部インターフェイス上で vlan 200 および XNUMX として示されています)。

その結果、一定の柔軟性はあるものの、フォールト トレランス メカニズムがまだ備わっていない、興味深いと同時によく考え抜かれたソリューションを受け取りました。

まず、制御ノードは 3 つだけです。その障害はすべてのシステムの崩壊につながります。 この問題を解決するには、少なくとも XNUMX つのノードのクォーラムを作成する必要があります。 これを図に追加してみましょう。

当然のことながら、すべてのノードは同期されており、アクティブなノードが離れると、別のノードがその責任を引き継ぎます。

次の問題は仮想マシンのディスクです。 現時点では、それらはハイパーバイザー自体に保存されており、ハイパーバイザーに問題が発生した場合、すべてのデータが失われます。ディスクではなくサーバー全体が失われると、RAID の存在は役に立ちません。 これを行うには、ある種のストレージのフロントエンドとして機能するサービスを作成する必要があります。 どのような種類のストレージになるかは私たちにとって特に重要ではありませんが、ディスクとノードの両方、場合によってはキャビネット全体の障害からデータを保護する必要があります。 ここにはいくつかのオプションがあります - もちろん、ファイバー チャネルを備えた SAN ネットワークもありますが、正直に言います - FC はすでに過去の遺物です - トランスポートにおける E1 の類似物です - はい、同意します、まだ使用されていますが、それなしでは絶対に不可能な場合にのみ。 したがって、他にもっと興味深い代替手段があることを知っているので、私は 2020 年に自発的に FC ネットワークを展開するつもりはありません。 人それぞれですが、限界がある FC だけで十分だと信じる人もいるかもしれません。私は異論はありません。人それぞれの意見があります。 ただし、私の意見では、最も興味深い解決策は、Ceph などの SDS を使用することです。

Ceph を使用すると、パリティ チェック (RAID 5 または 6 に類似) を備えたコードから始まり、ディスクの場所を考慮した別のディスクへの完全なデータ レプリケーションで終わる、多数のバックアップ オプションを備えた可用性の高いデータ ストレージ ソリューションを構築できます。サーバー、キャビネット内のサーバーなど。

Ceph を構築するには、さらに 3 つのノードが必要です。 ストレージとの対話も、ブロック、オブジェクト、およびファイル ストレージ サービスを使用してネットワーク経由で実行されます。 図にストレージを追加してみましょう。

注: ハイパーコンバージド コンピューティング ノードを作成することもできます。これは、ceph ストレージ専用の特別なノードを使用せずに、XNUMX つのノード上で複数の機能 (たとえば、ストレージ + コンピューティング) を組み合わせるという概念です。 SDS は指定した予約レベルでデータを予約するため、同じフォールト トレラント スキームが得られます。 ただし、ハイパーコンバージド ノードには常に妥協が伴います。ストレージ ノードは一見したように空気を加熱するだけではなく (仮想マシンが存在しないため)、SDS のサービスに CPU リソースを費やします (実際には、ストレージ ノードはすべてを実行します)。ノードやディスクなどの障害後のレプリケーションとリカバリ)。 つまり、コンピューティング ノードをストレージと組み合わせると、その能力の一部が失われます。

これらすべてを何らかの方法で管理する必要があります。マシン、ネットワーク、仮想ルーターなどを作成できるものが必要です。これを行うには、ダッシュボードとして機能するサービスを制御ノードに追加します。クライアントは http/https 経由でこのポータルに接続し、必要なすべてのことを (ほぼ) 行うことができます。

その結果、現在ではフォールトトレラントなシステムが完成しました。 このインフラストラクチャのすべての要素は、何らかの方法で管理する必要があります。 Openstack は一連のプロジェクトであり、それぞれが特定の機能を提供することは前述しました。 ご覧のとおり、構成および制御する必要がある要素は十分すぎるほどあります。 今日はネットワーク部分についてお話します。

中性子アーキテクチャ

OpenStack では、仮想マシンのポートを共通の L2 ネットワークに接続し、異なる L2 ネットワークにある VM 間のトラフィック ルーティングと外部ルーティングを確保し、NAT、フローティング IP、DHCP などのサービスを提供するのは Neutron です。

ネットワーク サービスの動作 (基本部分) は、大まかに次のように説明できます。

VM を起動すると、ネットワーク サービスは次のようになります。

1. 指定された VM (または複数のポート) のポートを作成し、それについて DHCP サービスに通知します。
2. 新しい仮想ネットワークデバイスが (libvirt 経由で) 作成されます。
3. VM は手順 1 で作成したポートに接続します。

奇妙なことに、Neutron の作業は、Linux に興味を持ったことがある人なら誰でもよく知っている標準メカニズム (名前空間、iptables、linux ブリッジ、openvswitch、conntrack など) に基づいています。

Neutron が SDN コントローラーではないことを直ちに明確にする必要があります。

Neutron は、相互接続されたいくつかのコンポーネントで構成されています。

Openstack-neutron-サーバー API を介してユーザーのリクエストを処理するデーモンです。 このデーモンはネットワーク接続の登録には関与しませんが、これに必要な情報をプラグインに提供し、プラグインが目的のネットワーク要素を構成します。 OpenStack ノード上の Neutron エージェントは、Neutron サーバーに登録します。

Neutron-server は実際には Python で書かれたアプリケーションで、次の XNUMX つの部分で構成されます。

• RESTサービス
• Neutron プラグイン (コア/サービス)

REST サービスは、他のコンポーネントから API 呼び出し (たとえば、何らかの情報を提供するリクエストなど) を受信するように設計されています。

プラグインは、API リクエスト中に呼び出されるプラグイン ソフトウェア コンポーネント/モジュールです。つまり、サービスの帰属はプラグインを通じて行われます。 プラグインは、サービスとルートの 2 つのタイプに分類されます。 通常、horse プラグインは主に VM 間のアドレス空間と LXNUMX 接続の管理を担当し、サービス プラグインはすでに VPN や FW などの追加機能を提供しています。

現在利用可能なプラグインのリストは次のように表示できます。 ここで

サービス プラグインは複数存在できますが、馬プラグインは XNUMX つだけです。

openstack-neutron-ml2 標準の OpenStack ルート プラグインです。 このプラグインは (以前のプラグインとは異なり) モジュラー アーキテクチャを備えており、接続されているドライバーを通じてネットワーク サービスを構成します。 プラグイン自体については、後で少し見ていきます。実際、このプラグインは、ネットワーク部分で OpenStack が持つ柔軟性を提供するからです。 ルート プラグインは置き換えることができます (たとえば、Contrail Networking はそのような置き換えを行います)。

RPC サービス (rabbitmq-server) — キュー管理と他の OpenStack サービスとの対話、およびネットワーク サービス エージェント間の対話を提供するサービス。

ネットワークエージェント — 各ノードに配置され、ネットワーク サービスが設定されるエージェント。

エージェントにはいくつかの種類があります。

主なエージェントは、 L2エージェント。 これらのエージェントは、制御ノードを含む各ハイパーバイザー上 (より正確には、テナントにサービスを提供するすべてのノード上) で実行され、その主な機能は、仮想マシンを共通の L2 ネットワークに接続し、イベントが発生したときにアラートを生成することです (たとえば、ポートを無効/有効にします)。

次の、同様に重要なエージェントは、 L3エージェント。 デフォルトでは、このエージェントはネットワーク ノード (多くの場合、ネットワーク ノードは制御ノードと組み合わされます) 上で排他的に実行され、テナント ネットワーク間 (そのネットワークと他のテナントのネットワーク間の両方) のルーティングを提供し、外部からアクセス可能です。 NAT、および DHCP サービス)。 ただし、DVR (分散ルーター) を使用する場合、コンピューティング ノードにも L3 プラグインが必要になります。

L3 エージェントは、Linux 名前空間を使用して、各テナントに独自の分離ネットワークのセットと、トラフィックをルーティングし、レイヤー 2 ネットワークにゲートウェイ サービスを提供する仮想ルーターの機能を提供します。

データベース — ネットワーク、サブネット、ポート、プールなどの識別子のデータベース。

実際、Neutron は、任意のネットワーク エンティティの作成からの API リクエストを受け入れ、リクエストを認証し、RPC (プラグインまたはエージェントにアクセスする場合) または REST API (SDN で通信する場合) を介して (プラグイン経由で) エージェントに送信します。要求されたサービスを編成するために必要な指示。

次に、テスト インストール (どのように展開されるか、何が含まれるかについては、実践編で後ほど説明します) に移り、各コンポーネントがどこにあるかを確認してみましょう。

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

実際、それが Neutron の全体構造です。 ここで、ML2 プラグインに時間を費やす価値があります。

モジュラーレイヤー2

前述したように、このプラグインは標準の OpenStack ルート プラグインであり、モジュラー アーキテクチャを備えています。

ML2 プラグインの前のバージョンはモノリシック構造を持っていたため、たとえば、2 つのインストールで複数のテクノロジーを組み合わせて使用​​することはできませんでした。 たとえば、openvswitch と linuxbridge の両方 (XNUMX 番目または XNUMX 番目のどちらか) を同時に使用することはできません。 このため、そのアーキテクチャを備えた MLXNUMX プラグインが作成されました。

ML2 には XNUMX つのコンポーネント、つまりタイプ ドライバーとメカニズム ドライバーの XNUMX 種類のドライバーがあります。

タイプドライバー ネットワーク接続を構成するために使用されるテクノロジー (VxLAN、VLAN、GRE など) を決定します。 同時に、ドライバーによりさまざまなテクノロジーの使用が可能になります。 標準テクノロジーは、オーバーレイ ネットワークおよび VLAN 外部ネットワーク用の VxLAN カプセル化です。

タイプ ドライバーには次のネットワーク タイプが含まれます。

フラット型の刃は完全に平行な状態ではありませんが、コニカル型の刃よりも明らかに平らになっており、幅もコニカル刃に比べて広いことが多いです。 - タグなしのネットワーク
VLAN - タグ付きネットワーク
ローカル — オールインワン インストール用の特殊なタイプのネットワーク (このようなインストールは開発者またはトレーニングのいずれかに必要です)
GRE — GREトンネルを使用したオーバーレイネットワーク
VxLAN — VxLAN トンネルを使用したオーバーレイ ネットワーク

メカニズムドライバー タイプ ドライバーで指定されたテクノロジー (openvswitch、sr-iov、opendaylight、OVN など) を確実に構成するツールを定義します。

このドライバーの実装に応じて、Neutron によって制御されるエージェントが使用されるか、外部 SDN コントローラーへの接続が使用され、L2 ネットワークの編成やルーティングなどに関連するすべての問題が処理されます。

例: ML2 を OVS とともに使用する場合、OVS を管理する各コンピューティング ノードに L2 エージェントがインストールされます。 ただし、たとえば OVN や OpenDayLight を使用する場合、OVS の制御はその管轄下にあります。Neutron はルート プラグインを通じてコン​​トローラーにコマンドを与え、指示されたことをすでに実行します。

Open vSwitch をブラッシュアップしましょう

現時点では、OpenStack の主要コンポーネントの XNUMX つは Open vSwitch です。
Juniper Contrail や Nokia Nuage などの追加のベンダー SDN を使用せずに OpenStack をインストールする場合、OVS はクラウド ネットワークの主要なネットワーク コンポーネントであり、iptables、conntrack、名前空間と組み合わせて、本格的なマルチテナント オーバーレイ ネットワークを編成できます。 当然のことながら、このコンポーネントは、たとえばサードパーティ独自の (ベンダー) SDN ソリューションを使用する場合に置き換えることができます。

OVS は、仮想化環境で仮想トラフィック フォワーダーとして使用するために設計されたオープン ソース ソフトウェア スイッチです。

現時点では、OVS には、QoS、LACP、VLAN、VxLAN、GENEVE、OpenFlow、DPDK などのテクノロジーを含む、非常に優れた機能があります。

注: OVS は当初、高負荷の電気通信機能用のソフト スイッチとして考えられたものではなく、WEB サーバーやメール サーバーなどの帯域幅要求の少ない IT 機能向けに設計されました。 ただし、OVS はさらに開発が進められており、現在の OVS 実装ではパフォーマンスと機能が大幅に向上しているため、通信事業者が高負荷の機能を使用できるようになりました。たとえば、DPDK アクセラレーションをサポートする OVS 実装があります。

OVS には、次の XNUMX つの重要なコンポーネントがあることに注意してください。

• カーネルモジュール — カーネル空間に配置され、制御要素から受信したルールに基づいてトラフィックを処理するコンポーネント。
• vスイッチ デーモン (ovs-vswitchd) は、カーネル モジュールのプログラミングを担当するユーザー空間で起動されるプロセスです。つまり、スイッチの動作ロジックを直接表します。
• データベースサーバー - OVS を実行している各ホストに配置され、構成が保存されるローカル データベース。 SDN コントローラーは、OVSDB プロトコルを使用してこのモジュールを通じて通信できます。

これらすべてには、ovs-vsctl、ovs-appctl、ovs-ofctl などの一連の診断および管理ユーティリティが付属しています。

現在、Openstack は、EPC、SBC、HLR などのネットワーク機能を Openstack に移行するために通信事業者によって広く使用されています。一部の機能はそのまま OVS で問題なく動作しますが、たとえば、EPC は加入者のトラフィックを処理し、その後通過します。膨大な量のトラフィック (現在、トラフィック量は毎秒数百ギガビットに達しています)。 当然のことながら、このようなトラフィックをカーネル空間経由で転送することは (フォワーダーがデフォルトでカーネル空間に配置されているため) 最善のアイデアではありません。 したがって、OVS は多くの場合、カーネルをバイパスして NIC からユーザー空間にトラフィックを転送する DPDK アクセラレーション テクノロジを使用して、完全にユーザー空間に展開されます。

注: 通信機能用に展開されたクラウドの場合、OVS をバイパスしてコンピューティング ノードからスイッチング機器にトラフィックを直接出力することが可能です。 この目的には、SR-IOV およびパススルー メカニズムが使用されます。

これは実際のレイアウトではどのように機能するのでしょうか?

それでは、実践的な部分に移り、実際にすべてがどのように機能するかを見てみましょう。

まず、単純な Openstack インストールをデプロイしましょう。 実験用のサーバーセットが手元にないため、仮想マシンから XNUMX 台の物理サーバー上にプロトタイプを組み立てます。 はい、当然のことながら、このようなソリューションは商業目的には適していませんが、OpenStack でネットワークがどのように機能するかを示す例を見るには、このようなインストールで十分です。 さらに、このようなインスタレーションは、交通状況などを把握できるため、トレーニング目的ではさらに興味深いものになります。

基本的な部分だけを見ればよいので、複数のネットワークを使用することはできず、XNUMX つのネットワークだけですべてを立ち上げ、このレイアウトの XNUMX 番目のネットワークはアンダークラウドと DNS サーバーへのアクセス専用に使用されます。 今のところ、外部ネットワークについては触れません。これは別の大きな記事のトピックです。

それでは、順番に始めましょう。 まず、ちょっとした理論です。 TripleO (Openstack on Openstack) を使用して Openstack をインストールします。 TripleO の本質は、アンダークラウドと呼ばれる Openstack オールインワン (つまり XNUMX つのノード上) をインストールし、デプロイされた Openstack の機能を使用して、オーバークラウドと呼ばれる運用用の Openstack をインストールすることです。 アンダークラウドは、物理サーバー (ベアメタル) を管理する固有の機能 (Ironic プロジェクト) を使用して、コンピューティング、制御、ストレージ ノードの役割を実行するハイパーバイザーをプロビジョニングします。 つまり、Openstack のデプロイにサードパーティ ツールは使用しません。Openstack を使用して Openstack をデプロイします。 インストールが進むにつれてさらに明確になるため、そこで停止せずに先に進みます。

注: この記事では、わかりやすくするために内部 Openstack ネットワークにネットワーク分離を使用しませんでしたが、すべてが XNUMX つのネットワークのみを使用してデプロイされます。 ただし、ネットワーク分離の有無はソリューションの基本機能には影響しません。すべてが分離を使用する場合とまったく同じように機能しますが、トラフィックは同じネットワーク上を流れます。 商用インストールの場合は、当然のことながら、異なる VLAN とインターフェイスを使用して分離を使用する必要があります。 たとえば、ceph ストレージ管理トラフィックとデータ トラフィック自体 (ディスクへのマシン アクセスなど) は、分離されている場合は異なるサブネット (ストレージ管理とストレージ) を使用するため、このトラフィックを分割することでソリューションの耐障害性を高めることができます。 、異なるポート間で、または異なるトラフィックに対して異なる QoS プロファイルを使用して、データ トラフィックがシグナリング トラフィックを圧迫しないようにします。 私たちの場合、それらは同じネットワーク上にありますが、実際、これは私たちを何ら制限しません。

注: 仮想マシンに基づく仮想環境で仮想マシンを実行するので、最初にネストされた仮想化を有効にする必要があります。

次のように、ネストされた仮想化が有効かどうかを確認できます。

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

文字 N が表示されている場合は、ネットワーク上にあるガイドに従って、ネストされた仮想化のサポートが有効になっています。たとえば、 そのような .

仮想マシンから次の回路を組み立てる必要があります。

私の場合、将来のインストールの一部となる仮想マシン (7 台ありましたが、リソースがあまりない場合は 4 台でも問題ありません) を接続するために、OpenvSwitch を使用しました。 ovs ブリッジを XNUMX つ作成し、ポートグループ経由で仮想マシンをそれに接続しました。 これを行うために、次のような XML ファイルを作成しました。

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

ここでは XNUMX つのポート グループ、つまり XNUMX つのアクセスと XNUMX つのトランクが宣言されています (後者は DNS サーバーに必要でしたが、DNS サーバーなしで行うことも、ホスト マシンにインストールすることもできます。どちらでも都合の良い方です)。 次に、このテンプレートを使用して、virsh net-define 経由でテンプレートを宣言します。

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

次に、ハイパーバイザーのポート構成を編集します。

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

注: このシナリオでは、ポート ovs-br1 のアドレスには vlan タグがないため、アクセスできません。 これを修正するには、コマンド sudo ovs-vsctl set port ovs-br1 tag=100 を発行する必要があります。 ただし、再起動すると、このタグは消えてしまいます（タグをそのまま残す方法を知っている人がいたら、とても感謝します）。 ただし、このアドレスはインストール時にのみ必要であり、Openstack が完全にデプロイされるときには必要ないため、これはそれほど重要ではありません。

次に、アンダークラウド マシンを作成します。

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

インストール中に、マシン名、パスワード、ユーザー、NTP サーバーなどの必要なパラメータをすべて設定し、すぐにポートを設定できますが、個人的には、インストール後、次の方法でマシンにログインする方が簡単です。コンソールにアクセスし、必要なファイルを修正します。 すでに既製のイメージがある場合は、それを使用することも、私がやったことと同じように、最小限の Centos 7 イメージをダウンロードして、それを使用して VM をインストールすることもできます。

インストールが成功すると、アンダークラウドをインストールできる仮想マシンが作成されます。

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

まず、インストール プロセスに必要なツールをインストールします。

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

アンダークラウドのインストール

スタック ユーザーを作成し、パスワードを設定して sudoer に追加すると、パスワードを入力せずに sudo を介して root コマンドを実行できるようになります。

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

ここで、hosts ファイルに完全なアンダークラウド名を指定します。

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

次に、リポジトリを追加し、必要なソフトウェアをインストールします。

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

注: ceph をインストールする予定がない場合は、ceph 関連のコマンドを入力する必要はありません。 私は Queens リリースを使用しましたが、お好みの他のリリースを使用しても構いません。

次に、アンダークラウド設定ファイルをユーザーのホームディレクトリスタックにコピーします。

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

次に、このファイルを修正して、インストールに合わせて調整する必要があります。

ファイルの先頭に次の行を追加する必要があります。

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

それでは、設定を見てみましょう。

アンダークラウドのホスト名 — アンダークラウドサーバーのフルネームは、DNS サーバー上のエントリと一致する必要があります

local_ip — ネットワークプロビジョニング用のローカルアンダークラウドアドレス

ネットワークゲートウェイ — オーバークラウドノードのインストール中に外部へのアクセスのためのゲートウェイとして機能する同じローカルアドレスは、ローカル IP とも一致します。

undercloud_public_host — 外部 API アドレス。プロビジョニング ネットワークからの任意のフリー アドレスが割り当てられます。

undercloud_admin_host 内部 API アドレス。プロビジョニング ネットワークからの任意のフリー アドレスが割り当てられます。

undercloud_nameservers — DNSサーバー

生成_サービス_証明書 - この行は現在の例では非常に重要です。これを false に設定しないとインストール中にエラーが発生します。この問題は Red Hat バグ トラッカーで説明されています。

ローカルインターフェース ネットワークプロビジョニングのインターフェイス。 このインターフェースはアンダークラウドのデプロイ中に再構成されるため、アンダークラウド上に XNUMX つのインターフェースが必要です。XNUMX つはアクセス用、もう XNUMX つはプロビジョニング用です。

local_mtu -MTU。 テスト ラボがあり、OVS スイッチ ポートの MTU が 1500 であるため、VxLAN でカプセル化されたパケットが通過できるように、MTU を 1450 に設定する必要があります。

network_cidr — プロビジョニングネットワーク

なりすまし — NAT を使用して外部ネットワークにアクセスする

マスカレードネットワーク - NAT化されるネットワーク

dhcp_start — オーバークラウドのデプロイメント中にアドレスがノードに割り当てられるアドレスプールの開始アドレス

dhcp_end — オーバークラウドのデプロイメント中にアドレスがノードに割り当てられるアドレスプールの最終アドレス

検査_iprange — イントロスペクションに必要なアドレスのプール (上記のプールと重複しないようにする必要があります)

スケジューラ_最大試行数 — オーバークラウドのインストール試行の最大回数 (ノード数以上である必要があります)

ファイルを記述した後、アンダークラウドをデプロイするコマンドを実行できます。

openstack undercloud install

アイロンの種類にもよりますが、この手順には 10 ～ 30 分かかります。 最終的には次のような出力が表示されるはずです。

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

この出力は、アンダークラウドが正常にインストールされたことを示しており、アンダークラウドのステータスを確認してオーバークラウドのインストールに進むことができます。

ifconfig の出力を見ると、新しいブリッジ インターフェイスが表示されていることがわかります。

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

オーバークラウドのデプロイメントは、このインターフェースを通じて実行されるようになります。

以下の出力から、すべてのサービスが XNUMX つのノード上にあることがわかります。

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

以下はアンダークラウドネットワーク部分の構成です。

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

オーバークラウドのインストール

現時点ではアンダークラウドのみがあり、オーバークラウドを組み立てる十分なノードがありません。 したがって、まず必要な仮想マシンをデプロイしましょう。 デプロイメント中に、アンダークラウド自体が OS と必要なソフトウェアをオーバークラウドマシンにインストールします。つまり、マシンを完全にデプロイする必要はなく、そのマシン用のディスクを作成し、そのパラメータを決定するだけです。実際、OS がインストールされていない裸のサーバーを入手します。

仮想マシンのディスクが含まれるフォルダーに移動し、必要なサイズのディスクを作成しましょう。

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

root として操作しているため、権利の問題が発生しないように、これらのディスクの所有者を変更する必要があります。

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

注: ceph を研究するためにインストールする予定がない場合、コマンドは少なくとも 3 つのディスクを持つ少なくとも XNUMX つのノードを作成しませんが、テンプレートでは仮想ディスク vda、vdb などが使用されることが示されます。

わかりました。次に、これらすべてのマシンを定義する必要があります。

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

最後に、コマンド -print-xml > /tmp/storage-1.xml があり、各マシンの説明を含む xml ファイルを /tmp/ フォルダーに作成します。これを追加しないと、仮想マシンを識別できるようになります。

次に、これらすべてのマシンを virsh で定義する必要があります。

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

ここで少しニュアンスがありますが、tripleO はインストールとイントロスペクション中に IPMI を使用してサーバーを管理します。

イントロスペクションは、ノードのさらなるプロビジョニングに必要なパラメータを取得するためにハードウェアを検査するプロセスです。 イントロスペクションは、ベア メタル サーバーで動作するように設計されたサービスである Ironic を使用して実行されます。

しかし、ここに問題があります。ハードウェア IPMI サーバーには別のポート (または共有ポート、ただしこれは重要ではありません) がありますが、仮想マシンにはそのようなポートがありません。 ここで、vbmc という助けになります。これは、IPMI ポートをエミュレートできるユーティリティです。 このニュアンスは、特に ESXI ハイパーバイザー上にそのようなラボをセットアップしたい人にとっては注意を払う価値があります。正直に言うと、それに vbmc の類似物があるかどうかはわかりません。そのため、すべてを展開する前にこの問題について疑問に思う価値があります。 。

vbmc をインストールします。

yum install yum install python2-virtualbmc

OS がパッケージを見つけられない場合は、リポジトリを追加します。

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

次に、ユーティリティを設定します。 ここにあるものはすべて、恥ずべきほど平凡だ。 これで、vbmc リストにサーバーが存在しないことは論理的になります。

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

それらを表示するには、次のように手動で宣言する必要があります。

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

コマンド構文は説明しなくても明らかだと思います。 ただし、現時点ではすべてのセッションが停止状態です。 UP ステータスに移行するには、以下を有効にする必要があります。

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

そして最後の仕上げとして、ファイアウォール ルールを修正する (または完全に無効にする) 必要があります。

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

次に、アンダークラウドに移動して、すべてが機能していることを確認してみましょう。 ホストマシンのアドレスは 192.168.255.200 です。アンダークラウドでは、デプロイメントの準備中に必要な ipmitool パッケージを追加しました。

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

ご覧のとおり、vbmc 経由で制御ノードが正常に起動されました。 では、それをオフにして次に進みましょう。

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

次のステップは、オーバークラウドがインストールされるノードのイントロスペクションです。 これを行うには、ノードの説明を含む json ファイルを準備する必要があります。 ベアサーバーへのインストールとは異なり、ファイルは各マシンで vbmc が実行されているポートを示すことに注意してください。

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

注: 制御ノードには XNUMX つのインターフェースがありますが、この場合、これは重要ではありません。このインストールでは XNUMX つで十分です。

次に、json ファイルを準備します。 プロビジョニングが実行されるポートのポッピー アドレス、ノードのパラメータを指定し、それらに名前を付け、ipmi にアクセスする方法を示す必要があります。

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

次に、皮肉用の画像を準備する必要があります。 これを行うには、wget 経由でダウンロードしてインストールします。

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

アンダークラウドへの画像のアップロード:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

すべての画像が読み込まれたことを確認する

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

もう XNUMX つ - DNS サーバーを追加する必要があります。

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

これで、イントロスペクションのコマンドを実行できるようになりました。

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

出力からわかるように、すべてがエラーなしで完了しました。 すべてのノードが利用可能な状態であることを確認してみましょう。

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

ノードが異なる状態 (通常は管理可能) にある場合は、何か問題が発生したことになるため、ログを調べて、なぜこれが起こったのかを理解する必要があります。 このシナリオでは仮想化を使用しているため、仮想マシンまたは vbmc の使用に関連するバグが発生する可能性があることに注意してください。

次に、どのノードがどの機能を実行するかを指定する必要があります。つまり、ノードがデプロイするプロファイルを指定する必要があります。

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

各ノードのプロファイルを指定します。

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

すべてが正しく行われたことを確認してみましょう。

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

すべてが正しい場合は、オーバークラウドをデプロイするコマンドを実行します。

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

実際のインストールでは、カスタマイズされたテンプレートが当然使用されますが、この場合、テンプレート内の各編集を説明する必要があるため、プロセスが非常に複雑になります。 前に書いたように、簡単なインストールでも、それがどのように機能するかを確認するには十分です。

注: この場合、ネストされた仮想化を使用するため、 --libvirt-type qemu 変数が必要です。 そうしないと、仮想マシンを実行できなくなります。

ここで、約 XNUMX 時間、あるいはそれ以上 (ハードウェアの機能に応じて) 時間がかかります。この時間が経過したら、次のメッセージが表示されることを祈るだけです。

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

これで、openstack のほぼ完全なバージョンが完成し、学習や実験などができるようになりました。

すべてが正しく動作していることを確認してみましょう。 ユーザーのホームディレクトリスタックには XNUMX つのファイルがあります。XNUMX つは stackrc (アンダークラウドの管理用)、もう XNUMX つは overcloudrc (オーバークラウドの管理用) です。 これらのファイルには認証に必要な情報が含まれているため、ソースとして指定する必要があります。

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

私のインストールでは、作業しているマシンが別のネットワーク上にあるため、コントローラーにルートを追加するという小さな操作がまだ必要です。 これを行うには、heat-admin アカウントの下の control-1 に移動し、ルートを登録します。

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

さて、これで地平線まで行けるようになりました。 すべての情報 (アドレス、ログイン、パスワード) はファイル /home/stack/overcloudrc にあります。 最終的な図は次のようになります。

ちなみに、私たちのインストールでは、マシン アドレスは DHCP 経由で発行されており、ご覧のとおり、「ランダム」に発行されます。 必要に応じて、展開中にどのアドレスをどのマシンに付加するかをテンプレートで厳密に定義できます。

仮想マシン間のトラフィックはどのように流れるのでしょうか?

この記事では、トラフィックを通過させるための XNUMX つのオプションについて説明します。

• 2 つの LXNUMX ネットワーク上の XNUMX つのハイパーバイザー上の XNUMX 台のマシン
• 同じ L2 ネットワーク上の異なるハイパーバイザー上の XNUMX 台のマシン
• 異なるネットワーク上の XNUMX 台のマシン (クロスネットワークルート化)

フローティング アドレスや分散ルーティングを使用して、外部ネットワークを介して外部にアクセスするケースについては、次回検討します。今回は内部トラフィックに焦点を当てます。

確認するために、次の図をまとめてみましょう。

4 つの仮想マシンを作成しました。3 つの L2 ネットワーク net-1 上に 1 つ、net-2 ネットワーク上にさらに XNUMX つです。

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

作成されたマシンがどのハイパーバイザーに配置されているかを見てみましょう。

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(オーバークラウド) [stack@undercloud ~]$
マシン vm-1 と vm-3 は compute-0 に配置され、マシン vm-2 と vm-4 はノード compute-1 に配置されます。

さらに、指定されたネットワーク間のルーティングを可能にする仮想ルーターが作成されました。

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

ルーターには XNUMX つの仮想ポートがあり、ネットワークのゲートウェイとして機能します。

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

ただし、トラフィックがどのように流れるかを確認する前に、制御ノード (ネットワーク ノードでもあります) と計算ノードに現在何が存在するかを見てみましょう。 コンピューティング ノードから始めましょう。

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

現時点では、ノードには br-int、br-tun、br-ex の XNUMX つの ovs ブリッジがあります。 ご覧のとおり、それらの間には一連のインターフェイスがあります。 理解を容易にするために、これらすべてのインターフェイスを図上にプロットして、何が起こるかを見てみましょう。

VxLAN トンネルが発生するアドレスを見ると、1 つのトンネルが compute-192.168.255.26 (1) に発生し、192.168.255.15 番目のトンネルが control-XNUMX (XNUMX) に向けられていることがわかります。 しかし、最も興味深いのは、br-ex には物理インターフェイスがなく、どのようなフローが設定されているかを見ると、このブリッジは現時点ではトラフィックのみをドロップできることがわかります。

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

出力からわかるように、アドレスは仮想ブリッジ インターフェイスではなく、物理ポートに直接固定されています。

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

最初のルールによれば、phy-br-ex ポートから来たものはすべて破棄されなければなりません。
実際には、現時点では、このインターフェイス (br-int とのインターフェイス) 以外にトラフィックがこのブリッジに流入する場所はありません。ドロップから判断すると、BUM トラフィックはすでにブリッジに流入しています。

つまり、トラフィックは VxLAN トンネル経由でのみこのノードから出ることができ、他には何も通過できません。 ただし、DVR をオンにすると状況は変わりますが、それについては別の機会に説明します。 VLAN などのネットワーク分離を使用する場合、VLAN 3 には 0 つの LXNUMX インターフェイスではなく、複数のインターフェイスが存在します。 ただし、VxLAN トラフィックは同じようにノードから出ますが、ある種の専用 VLAN にカプセル化されます。

コンピューティング ノードを整理しました。制御ノードに移りましょう。

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

実際、すべてが同じであると言えますが、IP アドレスは物理インターフェイスではなく仮想ブリッジ上にあります。 これが行われるのは、このポートがトラフィックが外部に出力されるポートであるためです。

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

このポートは br-ex ブリッジに関連付けられており、その上に vlan タグがないため、このポートはすべての vlan が許可されるトランク ポートとなり、トラフィックはタグなしで外部に送信されます。これは、上記の出力。

現時点では、他のすべては計算ノードと同様です。同じブリッジ、同じトンネルが XNUMX つの計算ノードに接続されています。

この記事ではストレージ ノードについては考慮しませんが、理解するには、これらのノードのネットワーク部分は恥ずべきほど平凡であると言う必要があります。 この例では、IP アドレスが割り当てられた物理ポート (eth0) が XNUMX つだけあります。 VxLAN トンネルやトンネル ブリッジなどはありません。ov には意味がないので、ov もまったくありません。 ネットワーク分離を使用する場合、このノードには XNUMX つのインターフェイス (物理ポート、bodny、または XNUMX つの VLAN だけ - それは問題ではありません - 必要なものによって異なります) があり、XNUMX つは管理用、XNUMX つ目はトラフィック用 (VM ディスクへの書き込み) 、ディスクからの読み取りなど）

サービスが存在しない場合にノード上に何があるかを把握しました。 次に、4 つの仮想マシンを起動して、上記のスキームがどのように変化するかを見てみましょう。ポート、仮想ルーターなどが存在するはずです。

これまでのところ、ネットワークは次のようになります。

各コンピューター ノードには 0 つの仮想マシンがあります。 compute-XNUMX を例として使用して、すべてがどのように含まれるかを見てみましょう。

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

マシンには仮想インターフェイスが 95 つだけあります (tap96d75a0-aXNUMX)。

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

このインターフェイスは Linux ブリッジ内を調べます。

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

出力からわかるように、ブリッジには 95 つのインターフェイス (tap96d75a0-a95 と qvb96d75a0-aXNUMX) のみがあります。

ここで、OpenStack の仮想ネットワーク デバイスの種類について少し詳しく説明します。
vtap - インスタンス (VM) に接続された仮想インターフェイス
qbr - Linux ブリッジ
qvb と qvo - Linux ブリッジと Open vSwitch ブリッジに接続された vEth ペア
br-int、br-tun、br-vlan — オープン vSwitch ブリッジ
patch-、int-br-、phy-br- - ブリッジを接続する Open vSwitch パッチ インターフェイス
qg、qr、ha、fg、sg - OVS に接続するために仮想デバイスが使用する vSwitch ポートを開きます。

ご存知のとおり、ブリッジに vEth ペアである qvb95d96a75-a0 ポートがある場合、どこかに対応するポートがあり、論理的には qvo95d96a75-a0 と呼ばれるはずです。 OVS にどのようなポートがあるかを見てみましょう。

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

見てわかるように、ポートは br-int にあります。 Br-int は、仮想マシンのポートを終了するスイッチとして機能します。 qvo95d96a75-a0 に加えて、ポート qvo5bd37136-47 が出力に表示されます。 これは XNUMX 番目の仮想マシンへのポートです。 その結果、図は次のようになります。

注意深い読者ならすぐに興味を持つはずの質問 - 仮想マシン ポートと OVS ポート間の Linux ブリッジとは何ですか? 実際には、マシンを保護するためにセキュリティ グループが使用されますが、これは iptables に他なりません。 OVS は iptables では動作しないため、この「松葉杖」が発明されました。 ただし、これは廃止されつつあり、新しいリリースでは conntrack に置き換えられています。

つまり、最終的にスキームは次のようになります。

2 つの LXNUMX ネットワーク上の XNUMX つのハイパーバイザー上の XNUMX 台のマシン

これら 2 つの VM は同じ LXNUMX ネットワークおよび同じハイパーバイザー上に配置されており、両方のマシンが同じ VLAN 上にあるため、それらの間のトラフィックは論理的に br-int を介してローカルに流れます。

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

同じ L2 ネットワーク上の異なるハイパーバイザー上の XNUMX 台のマシン

次に、同じ L2 ネットワーク上にある、異なるハイパーバイザー上にある XNUMX つのマシン間でトラフィックがどのように流れるかを見てみましょう。 正直に言うと、ハイパーバイザー間のトラフィックが vxlan トンネルを通過するだけで、大きな変化はありません。 例を見てみましょう。

トラフィックを監視する仮想マシンのアドレス:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

compute-0 上の br-int の転送テーブルを確認します。

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

トラフィックはポート 2 に送信される必要があります。ポートの種類を見てみましょう。

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

これは patch-tun、つまり br-tun のインターフェイスです。 br-tun 上のパッケージに何が起こるかを見てみましょう。

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

パケットは VxLAN にパッケージ化され、ポート 2 に送信されます。ポート 2 がどこに向かうかを見てみましょう。

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

これは、compute-1 上の vxlan トンネルです。

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

compute-1 に移動して、パッケージで次に何が起こるかを見てみましょう。

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

Mac は compute-1 の br-int 転送テーブルにあり、上記の出力からわかるように、br-tun へのポートであるポート 2 を介して認識されます。

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

さて、compute-1 の br-int に宛先ポピーがあることがわかります。

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

つまり、受信したパケットはポート 3 に送信され、その後ろにはすでに仮想マシン インスタンス-00000003 が存在します。

仮想インフラストラクチャ上で学習するために Openstack をデプロイする利点は、ハイパーバイザー間のトラフィックを簡単にキャプチャして、そこで何が起こっているかを確認できることです。 これがこれから行うことです。compute-0 に向けて vnet ポートで tcpdump を実行します。

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

最初の行は、アドレス 10.0.1.85 の Patek がアドレス 10.0.1.88 (ICMP トラフィック) に送信され、vni 22 の VxLAN パケットにラップされ、パケットがホスト 192.168.255.19 (compute-0) からホスト 192.168.255.26 に送信されることを示しています。 .1 (計算-XNUMX)。 VNI が ovs で指定されたものと一致することを確認できます。

この行、actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2 に戻りましょう。 0x16 は 16 進数体系の vni です。 この数値を 10 進法に変換してみましょう。

16 = 6*16^0+1*16^1 = 6+16 = 22

つまり、vni は現実に対応します。

XNUMX 行目はリターン トラフィックを示しています。まあ、説明する必要はありません。ここですべてが明らかです。

異なるネットワーク上の XNUMX 台のマシン (ネットワーク間ルーティング)

今日の最後のケースは、仮想ルーターを使用した XNUMX つのプロジェクト内のネットワーク間のルーティングです。 DVR のないケースを検討しています (これについては別の記事で説明します)。そのため、ルーティングはネットワーク ノードで発生します。 この場合、ネットワーク ノードは別個のエンティティに配置されず、制御ノード上に配置されます。

まず、ルーティングが機能することを確認してみましょう。

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

この場合、パケットはゲートウェイに送信され、そこでルーティングされる必要があるため、ゲートウェイのポピー アドレスを見つける必要があり、インスタンス内の ARP テーブルを調べます。

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

次に、宛先 (10.0.1.254) fa:16:3e:c4:64:70 のトラフィックがどこに送信されるかを見てみましょう。

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

ポート 2 がどこにつながっているかを見てみましょう。

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

すべてが論理的で、トラフィックは br-tun に送られます。 どの vxlan トンネルにラップされるかを見てみましょう。

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

XNUMX 番目のポートは vxlan トンネルです。

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

これは制御ノードを調べます。

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

トラフィックは制御ノードに到達したので、そこに行き、ルーティングがどのように行われるかを確認する必要があります。

覚えているとおり、内部の制御ノードは計算ノードとまったく同じに見えました。同じ XNUMX つのブリッジで、ノードが外部にトラフィックを送信できる物理ポートを持っていたのは br-ex だけでした。 インスタンスの作成により、コンピューティング ノードの構成が変更され、Linux ブリッジ、iptables、およびインターフェイスがノードに追加されました。 ネットワークと仮想ルーターの作成も、制御ノードの構成に影響を与えました。

したがって、ゲートウェイ MAC アドレスが制御ノード上の br-int 転送テーブルに存在する必要があることは明らかです。 それが存在し、どこを探しているかを確認してみましょう。

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

Mac はポート qr-0c52b15f-8f から表示されます。 Openstack の仮想ポートのリストに戻ると、このタイプのポートはさまざまな仮想デバイスを OVS に接続するために使用されます。 より正確には、qr は仮想ルーターへのポートであり、名前空間として表されます。

サーバー上にどのような名前空間があるかを見てみましょう。

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

0部まで。 しかし、名前から判断すると、それぞれの目的が推測できます。 後で ID 1 と 0 のインスタンスに戻りますが、ここでは名前空間 qrouter-4a2420d4-9b46c-1bd-aec86-1a299efXNUMXabe に興味があります。

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

この名前空間には、以前に作成した 0 つの内部名前空間が含まれています。 両方の仮想ポートが br-int に追加されました。 宛先 MAC アドレスから判断すると、トラフィックはこのインターフェイスに送信されたため、ポート qr-52c15b8f-XNUMXf の MAC アドレスを確認してみましょう。

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

つまり、この場合、すべてが標準ルーティングの法則に従って機能します。 トラフィックはホスト 10.0.2.8 宛てであるため、92 番目のインターフェイス qr-49fa5b54-XNUMX を通って出て、vxlan トンネルを通ってコンピューティング ノードに到達する必要があります。

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

すべては論理的であり、驚くべきことではありません。 ホスト 10.0.2.8 のポピー アドレスが br-int のどこに表示されるかを見てみましょう。

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

予想どおり、トラフィックは br-tun に送信されます。トラフィックが次にどのトンネルに送信されるかを見てみましょう。

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

トラフィックはトンネルに入り、compute-1 に到達します。 さて、compute-1 ではすべてが単純です。パッケージは br-tun から br-int に進み、そこから仮想マシン インターフェイスに進みます。

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

これが本当に正しいインターフェースであることを確認してみましょう。

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

実際、私たちはパッケージを隅々まで調べました。 トラフィックが異なる vxlan トンネルを通過し、異なる VNI で終了したことに気づいたと思います。 これらがどのような VNI であるかを見てみましょう。その後、ノードの制御ポートでダンプを収集し、トラフィックが上で説明したとおりに正確に流れることを確認します。
したがって、compute-0 へのトンネルには、actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3 があります。 0x16 を XNUMX 進数に変換してみましょう。

0x16 = 6*16^0+1*16^1 = 6+16 = 22

compute-1 へのトンネルには、次の VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2 があります。 0x63 を XNUMX 進数に変換してみましょう。

0x63 = 3*16^0+6*16^1 = 3+96 = 99

さて、ダンプを見てみましょう:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

最初のパケットは、vni 192.168.255.19 を使用したホスト 0 (compute-192.168.255.15) からホスト 1 (control-22) への vxlan パケットで、その中にはホスト 10.0.1.85 からホスト 10.0.2.8 への ICMP パケットがパッケージ化されています。 上記で計算したように、vni は出力に表示されたものと一致します。

192.168.255.15 番目のパケットは、vni 1 を使用したホスト 192.168.255.26 (control-1) からホスト 99 (compute-10.0.1.85) への vxlan パケットで、その中にはホスト 10.0.2.8 からホスト XNUMX への ICMP パケットがパッケージ化されています。 上記で計算したように、vni は出力に表示されたものと一致します。

次の 10.0.2.8 つのパケットは、10.0.1.85 ではなく XNUMX からのリターン トラフィックです。

つまり、最終的に次の制御ノード スキームが得られました。

それだけのようですか？ XNUMX つの名前空間を忘れていました。

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

クラウド プラットフォームのアーキテクチャについて説明したように、マシンが DHCP サーバーからアドレスを自動的に受信できれば良いでしょう。 これらは、10.0.1.0 つのネットワーク 24/10.0.2.0 および 24/XNUMX 用の XNUMX つの DHCP サーバーです。

これが本当かどうかを確認してみましょう。 この名前空間にはアドレス 10.0.1.1 が XNUMX つだけあります。これは DHCP サーバー自体のアドレスであり、br-int にも含まれています。

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

名前に qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 を含むプロセスが制御ノード上にあるかどうかを確認してみましょう。

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

このようなプロセスがあり、上記の出力に表示される情報に基づいて、たとえば現在レンタルしているものを確認できます。

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

その結果、制御ノード上に次のサービスのセットが得られます。

覚えておいてください - これは 4 台のマシン、2 つの内部ネットワーク、および 3 つの仮想ルーターだけです... 現在、ここには外部ネットワークはありません。それぞれが独自のネットワーク (重複) を持つさまざまなプロジェクトが多数あります。分散ルーターがオフになり、結局、テストベンチには制御ノードが 300 つだけになりました (フォールト トレランスを実現するには、XNUMX つのノードのクォーラムが必要です)。 コマースではすべてが「もう少し」複雑になるのは当然ですが、この単純な例では、それがどのように機能するかを理解しています。ネームスペースが XNUMX つであるか XNUMX であるかはもちろん重要ですが、全体の構造は、何も大きく変わりません...ただし、ベンダーの SDN をプラグインすることはありません。 しかし、それは全く別の話です。

面白かったら幸いです。 コメント/追加がある場合、または私が完全に嘘をついた場合(私は人間であり、私の意見は常に主観的です)、修正/追加が必要なものを書いてください。すべて修正/追加します。

結論として、Openstack (バニラとベンダーの両方) と VMWare のクラウド ソリューションの比較について、いくつかの言葉を述べたいと思います。私は過去 XNUMX 年間、この質問を頻繁に聞かれてきましたが、率直に言って、私は次のように思っています。もう飽きたけど、それでも。 私の意見では、これら XNUMX つのソリューションを比較するのは非常に困難ですが、どちらのソリューションにも欠点があることは間違いなく言えるため、どちらかのソリューションを選択する場合は、長所と短所を比較検討する必要があります。

OpenStack がコミュニティ主導のソリューションである場合、VMWare は自分が望むこと (つまり、何が利益になるか) だけを実行する権利を持ちます。これは論理的です。なぜなら、VMWare はクライアントからお金を稼ぐことに慣れている営利企業だからです。 しかし、大きくて重要な点が XNUMX つあります。たとえば、Nokia から OpenStack を離れて、わずかな費用で、たとえば Juniper (Contrail Cloud) のソリューションに切り替えることはできますが、VMWare から抜け出すことはできそうにありません。 。 私にとって、これら XNUMX つのソリューションは次のようになります。Openstack (ベンダー) は、ユーザーが入れられる単純な檻ですが、キーを持っているので、いつでもそこから出ることができます。 VMWare は黄金の檻のようなもので、檻の鍵は所有者が持っており、その鍵には多額の費用がかかります。

私は最初の製品と 10 番目の製品のどちらかを宣伝しているわけではありません。必要なものを選択してください。 しかし、もしそのような選択肢があるとしたら、私は両方のソリューションを選択します。IT クラウドには VMWare (負荷が低く、管理が容易)、テレコム クラウドには一部のベンダーの OpenStack (Nokia と Juniper が非常に優れたターンキー ソリューションを提供します) です。 私は純粋な IT には Openstack を使用しません。大砲でスズメを撃つようなものですが、冗長性以外に Openstack を使用することに禁忌はありません。 ただし、通信分野で VMWare を使用することは、フォード ラプターで砕石を運ぶようなものです。外から見ると美しいですが、ドライバーは XNUMX 回ではなく XNUMX 回往復する必要があります。

私の意見では、VMWare の最大の欠点はその完全な閉鎖性です。VMWare は、vSAN やハイパーバイザー カーネルの内容など、VMWare がどのように機能するかに関する情報を一切提供しません。単に VMWare にとって利益がありません。 VMWare の専門家になることは決してありません。ベンダーのサポートがなければ、終わりです (つまらない質問に困惑する VMWare の専門家によく会います)。 私にとって、VMWare はボンネットがロックされた車を購入するようなものです。はい、タイミング ベルトを交換できる専門家がいるかもしれませんが、ボンネットを開けることができるのは、このソリューションを販売した人だけです。 個人的に、私は自分が適合できない解決策は好きではありません。 あなたは、ボンネットの下に入る必要はないかもしれないと言うでしょう。 はい、可能ですが、20 ～ 30 の仮想マシン、40 ～ 50 のネットワークからクラウド内で大規模な機能を組み立てる必要があり、そのうちの半分は外部に出す必要があり、後半はSR-IOV の高速化が必要です。そうでない場合は、さらに数十台のこれらの車両が必要になります。そうでないと、パフォーマンスが十分ではありません。

他の視点もあるので、何を選択するかを決めるのはあなただけであり、最も重要なことに、その選択にはあなたが責任を負います。 これは単なる私の意見です。Nokia、Juniper、Red Hat、VMWare という少なくとも 4 つの製品を見たり触ったりしたことがある者です。 つまり、比較するものがあるのです。

出所： habr.com