👂 📧 🙋🏾 クラウドインフラストラクチャのネットワーキング部分の概要 👩🏼‍⚖️ ⌛️ 🐕

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

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

クラウドとは何ですか？同じ仮想化-縦断ビュー？

論理的な質問以上のもの。いいえ-これは仮想化ではありませんが、仮想化なしではありませんでした。 2つの定義を検討してください。

クラウドコンピューティング（以下、クラウド）は、分散コンピューティングリソースへのユーザーフレンドリーなアクセスを提供するためのモデルであり、サービスプロバイダーからの最小の遅延と最小のコストでオンデマンドで展開および起動する必要があります（NISTからの定義の翻訳）。

仮想化-これは、1つの物理エンティティ（サーバーなど）を複数の仮想エンティティに分割して、リソース使用率を向上させる機能です（たとえば、仮想化後に1つのサーバーが80〜90％読み込まれると、3つのサーバーが25〜30％読み込まれます）。当然のことながら、仮想化はリソースの一部を消費します。ハイパーバイザーにフィードする必要がありますが、実際に示されているように、ゲームはキャンドルの価値があります。仮想化の理想的な例は、仮想マシンを完全に準備するVMWare、またはたとえば私が好むKVMですが、これはすでに好みの問題です。

私たちはこれに気付かずに自分たちで仮想化を使用しており、鉄のルーターでさえすでに仮想化を使用しています。たとえば、最新バージョンのJunOSでは、オペレーティングシステムはリアルタイムLinux配布キット（Wind River 9）の上に仮想マシンとしてインストールされます。しかし、仮想化はクラウドではありませんが、クラウドは仮想化なしでは存在できません。

仮想化は、クラウドが構築される構成要素の1つです。

複数のハイパーバイザーを1つのL2ドメインに収集し、いくつかのansibleを介してvlanを自動的に登録するためのyamlプレイブックをいくつか追加し、仮想マシンを自動的に作成するためのオーケストレーションシステムのようなものを詰め込むだけでは、クラウドを作成することはできません。より正確には、それは判明しますが、結果として得られるフランケンシュタインは私たちが必要とするクラウドではありませんが、他の誰かとして、おそらく誰かにとってこれは究極の夢です。さらに、同じOpenstackを使用する場合、実際にはまだフランケンシュタインですが、まあ、それについてはまだ話さないでください。

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

したがって、NIST（National Institute of Standards and Technology）のドキュメントには、クラウドインフラストラクチャに必要な5つの主な特性が記載されています。

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

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

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

さまざまな条件への迅速な適応。サービスは柔軟である必要があります。クライアントの要求に応じて、リソースの迅速な提供、リソースの再割り当て、リソースの追加または削減を行い、クライアントはクラウドリソースが無限であると感じる必要があります。たとえば、わかりやすくするために、サーバーのハードドライブが壊れていて、ディスクが壊れているためにAppleiCloudのディスクスペースの一部が失われたという警告は表示されません。さらに、あなたの側から見ると、このサービスの可能性はほぼ無限です-あなたは2TBが必要です-問題ありません、あなたは支払いと受け取りをしました。同様に、Google.DriveまたはYandex.Diskを使用して例を示すことができます。

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

これらの要件は主にパブリッククラウドの要件であるため、プライベートクラウド（つまり、企業の内部ニーズのために起動されたクラウド）の場合、これらの要件はわずかに調整できます。ただし、それでも実行する必要があります。そうしないと、クラウドコンピューティングのすべての利点を得ることができません。

なぜクラウドが必要なのですか？

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

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

Software as a Service（SaaS）は、Yandex.MailやGmailなどのメールサービスなど、クライアントに完全なサービスを提供するためのモデルです。このようなサービス提供モデルでは、クライアントとして、実際にはサービスを使用する以外に何もしません。つまり、サービスの設定、その障害許容度、または予約について考える必要はありません。主なことはあなたのパスワードを危険にさらすことではありません、このサービスのプロバイダーはあなたのために残りをします。サービスプロバイダーの観点から、彼はサーバーハードウェアやホストオペレーティングシステムからデータベースやソフトウェアの設定まで、サービス全体に対して完全な責任を負っています。

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

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

OpenStackとは何ですか？

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

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

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

この記事の執筆時点では、OpenStackの構造は次のようになっています。openstack.org

から取得した画像

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

ダッシュボード-OpenStackサービスを管理するためのWebベースのGUI
Keystoneは、他のサービスに認証および承認機能を提供し、ユーザーの資格情報と役割を管理する一元化されたIDサービスです。
Neutron — , OpenStack ( VM )
Cinder —
Nova —
Glance —
Swift —
Ceilometer — ,
Heat —

すべてのプロジェクトとその目的の完全なリストは、ここにあります。

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

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

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

マシンを作成するためのリクエストを作成するとき、それがHorizon（Dashboard）を介したリクエストであろうと、CLIを介したリクエストであろうと、最初に発生するのはKeystoneのリクエスト承認です。マシンを作成できますか、このネットワークを使用する権利がありますか、十分ですか？ドラフトクォータなど。
Keystoneはリクエストを認証し、応答メッセージで認証トークンを生成します。これは後で使用されます。Keystoneからの応答を受信した後、要求はNova（nova api）に送信されます。
Nova-api , Keystone, auth-
Keystone auth- .
Nova-api nova-database VM nova-scheduler.
Nova-scheduler ( ), VM , . VM nova-database.
nova-scheduler nova-compute . Nova-compute nova-conductor (nova-conductor nova, nova-database nova-compute, nova-database ).
Nova-conductor nova-database nova-compute.
nova-compute glance ID . Glace Keystone .
Nova-compute neutron . glance, neutron Keystone, database ( ), nova-compute.
Nova-compute cinder volume. glance, cider Keystone, volume .
Nova-compute libvirt .

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

ネットワークなしではクラウドインフラストラクチャは存在しないことを常に覚えておく価値があります。各要素は、何らかの方法でネットワークを介して他の要素と相互作用します。さらに、クラウドには完全に非静的なネットワークがあります。当然、アンダーレイネットワークは多かれ少なかれ静的です-新しいノードとスイッチは毎日追加されませんが、オーバーレイコンポーネントは絶えず変更される可能性があり、必然的に変更されます-新しいネットワークが追加または削除され、新しい仮想マシンが表示され、古い仮想マシンは消滅します。また、記事の冒頭で説明したクラウドの定義から覚えているように、リソースはユーザーに自動的に割り当てられ、サービスプロバイダーの介入は最小限（またはそれ以上）である必要があります。つまり、ネットワークリソースの提供の種類、これは現在、http / httpsからアクセスできる個人アカウントの形式のフロントエンドの形式であり、バックエンドとしてVasilyを担当するネットワークエンジニアです。これは、Vasilyに8つのハンドがある場合でも、クラウドではありません。

ネットワークサービスであるNeutronは、クラウドインフラストラクチャのネットワーク部分を管理するためのAPIを提供します。このサービスは、Network-as-a-Service（NaaS）と呼ばれる抽象化レイヤーを提供することにより、Openstackネットワーク部分の正常性と管理を提供します。つまり、ネットワークは、たとえばCPU仮想コアやRAMと同じ仮想測定可能ユニットです。

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

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

現時点では、これは4台のサーバーの仮想化に過ぎず、これまでに行ったのは4台のサーバーを仮想化して、2台の物理サーバーに配置することだけです。そして今のところ、彼らはネットワークにさえ接続されていません。

クラウドを取得するには、いくつかのコンポーネントを追加する必要があります。まず、ネットワーク部分を仮想化します。これら4台のマシンをペアで接続する必要があり、クライアントは正確にL2接続を望んでいます。スイッチを使用してその方向にトランクを設定し、linuxブリッジを使用してすべてを管理するか、より高度なopenvswitchユーザーの場合（これに戻ります）。ただし、ネットワークは多数存在する可能性があり、スイッチを介してL2を常にプッシュすることは最善の方法ではありません。そのため、さまざまな部門、サービスデスク、アプリケーションの実行を数か月待つ、トラブルシューティングを数週間行うなど、このアプローチは現代の世界では機能しなくなりました。そして、会社がこれに気付くのが早ければ早いほど、前進しやすくなります。したがって、ハイパーバイザー間で、仮想マシンが通信するL3ネットワークを選択し、すでにこのL3ネットワークの上に、仮想の重ね合わせたL2（オーバーレイ）ネットワークを構築します。仮想マシンのトラフィックが実行される場所。 GRE、Geneve、またはVxLANをカプセル化として使用できます。特に重要ではありませんが、ここでは後者について詳しく見ていきましょう。

VTEPをどこかに配置する必要があります（VxLANの用語に誰もが精通していることを願っています）。 L3ネットワークはすぐにサーバーを離れるので、サーバー自体にVTEPを配置することを妨げるものは何もなく、OVS（OpenvSwitch）はこれを完全に行うことができます。その結果、次のようになりました

。VM間のトラフィックを分割する必要があるため、仮想マシンへのポートのvlan番号は異なります。タグ番号は、1つの仮想スイッチ内でのみ役割を果たします。VxLANにカプセル化する場合、VNIがあるため、問題なくタグ番号を削除できるためです。

これで、問題なくマシンと仮想ネットワークを作成できます。

ただし、クライアントに別のマシンがあり、別のネットワーク上にある場合はどうなりますか？ネットワーク間のルート化が必要です。集中ルートを使用する場合の簡単なオプションを分析します。つまり、トラフィックは特別な専用ネットワークノードを介してルーティングされます（通常、これらは制御ノードと組み合わされるため、同じことができます）。

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

つまり、次のスキームが得られます。

L2トンネルは、すべての計算ノードから制御ノードに収束します。これらのネットワークのL3インターフェイスが配置されているノードで、それぞれが分離専用の名前空間にあります。

しかし、私たちは最も重要なことを忘れてしまいました。仮想マシンは、クライアントにサービスを提供する必要があります。つまり、仮想マシンには、アクセスできる外部インターフェイスが少なくとも1つ必要です。つまり、私たちは外の世界に出かける必要があります。ここにはさまざまなオプションがあります。最も簡単なオプションを作成しましょう。 1つのネットワークにクライアントを追加しましょう。これは、プロバイダーのネットワークで有効であり、他のネットワークと重複しません。ネットワークは重複していて、プロバイダーネットワーク側のさまざまなVRFを調べることもできます。これらのネットワークは、各クライアントの名前名にも存在します。ただし、それらは1つの物理的（またはより論理的な結合）インターフェイスを介して外界に入ります。クライアントトラフィックを分離するために、外部に向かうトラフィックは、クライアントに割り当てられたVLANタグでタグ付けされます。

その結果、次のスキームが得られました。

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

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

どういうわけかマシンを保護する必要があります。つまり、クライアントに向けてスイッチインターフェイスにフィルターを掛ける必要があります。
仮想マシンが自動的にIPアドレスを取得できるようにすることで、毎回コンソールから入力してアドレスを登録する必要がなくなります。

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

つまり、トポロジがもう少し複雑になりました

。さらに進んでみましょう。DHCPサーバーを追加する必要があります。各クライアントのDHCPサーバーの場所として最も理想的な場所は、名前名が配置されている、前述の制御ノードです。

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

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

そして、ここでNATが助けになります。NAT変換を使用して、デフォルトの名前名を介してクライアントが外の世界に出かけることを可能にします。さて、ここに少し問題があります。クライアントサーバーがサーバーとしてではなくクライアントとして機能する場合、つまり、接続を受け入れるのではなく開始する場合に適しています。しかし、私たちと一緒にそれは逆になります。この場合、宛先NATを実行して、トラフィックを受信するときに、このトラフィックがクライアントAの仮想マシンAを対象としていることを制御ノードが理解できるようにする必要があります。つまり、外部アドレス（100.1.1.1など）から内部アドレス10.0.0.1にNAT変換を行う必要があります。この場合、すべてのクライアントが同じネットワークを使用しますが、内部の分離は完全に保持されます。つまり、制御ノードでdNATとsNATを作成する必要があります。クラウドにドラッグする必要があるため、フローティングアドレスまたは外部ネットワーク、あるいはその両方を同時に割り当てた単一のネットワークを使用します。フローティングアドレスは図に追加しませんが、外部ネットワークは以前に追加したままにしておきます。各クライアントには独自の外部ネットワークがあります（図では、外部インターフェイスでvlan 100および200として指定されています）。

その結果、ある程度の柔軟性を備えた、興味深いと同時によく考えられたソリューションが得られましたが、これまでのところ、障害耐性メカニズムはありません。

まず、制御ノードが1つしかないため、その障害によりすべてのシステムが崩壊します。この問題を修正するには、少なくとも3ノードのクォーラムを作成する必要があります。これを図に追加しましょう。

当然、すべてのノードが同期され、アクティブノードが終了すると、別のノードがその責任を引き継ぎます。

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

セファロは、冗長性のためのオプションの束とビルドvyskodostupnoeストレージソリューションにあなたを可能にするディスクのロケーションサーバ、およびサーバキャビネット内などに基づいて、複数のディスクにデータの完全な複製で終わる符号パリティ（アナログRAID 5または6）以来。

のためにCephアセンブリにはさらに3つのノードが必要です。ストレージとの対話も、ブロック、オブジェクト、およびファイルストレージサービスを使用してネットワーク経由で実行されます。スキーマにストレージを追加します。

: compute — — storage+compute — ceph storage. — SDS . — — storage ( ) — CPU SDS ( , , ). compute storage.

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

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

中性子アーキテクチャ

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

高レベルのネットワークサービス（基本部分）は次のように説明できます。

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

このVM（または複数のポート）のポートを作成し、DHCPサービスに通知します。
新しい仮想ネットワークデバイスが（libvirtを介して）作成されます。
VMは、手順1で作成した1つ（複数のポート）に接続します。

奇妙なことに、Neutronの仕事の中心には、Linuxに飛び込んだことのある人なら誰でも知っている標準的なメカニズムがあります。これらは、名前名、iptables、linuxブリッジ、openvswitch、conntrackなどです。

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

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

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

Neutron-serverは、実際にはpythonで記述されたアプリケーションであり、次の2つの部分で構成されています。

RESTサービス
Neutronプラグイン（コア/サービス）

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

プラグインは、API要求で呼び出されるプラグインソフトウェアコンポーネント/モジュールです。つまり、サービスの割り当てはそれらを介して行われます。プラグインは、サービスとルートの2つのタイプに分けられます。原則として、horseプラグインは主にVM間のアドレススペースとL2接続の管理を担当し、サービスプラグインはすでにVPNやFWなどの追加機能を提供しています。

今日利用可能なプラグインのリストは、たとえばここで表示できます。

サービスプラグインは複数ある場合がありますが、ホースプラグインは1つしかありません。

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プラグインの前身はモノリシック構造であり、たとえば、1つのインストールで複数のテクノロジーを組み合わせて使用することはできませんでした。たとえば、openvswitchとlinuxbridgeの両方を同時に使用することはできません（最初または2番目のいずれか）。このため、そのアーキテクチャを備えたML2プラグインが作成されました。

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

タイプドライバは、VxLAN、VLAN、GREなど、ネットワーク接続を整理するために使用されるテクノロジを定義します。同時に、ドライバーを使用すると、さまざまなテクノロジーを使用できます。標準テクノロジは、オーバーレイネットワークおよびvlan外部ネットワーク用のVxLANカプセル化です。

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

フラット-タグ付けされていない

VLANのネットワーク-タグ付けされたネットワーク

ローカル-オールインワンインストール用の特別なタイプのネットワーク（このようなインストールは開発者またはトレーニングのいずれかに必要です）

GRE -

GREVxLANトンネルを使用したオーバーレイネットワーク-VxLANトンネルを使用したオーバーレイネットワーク

メカニズムドライバーは、タイプドライバーで指定されたテクノロジーの編成を提供する手段を定義します-たとえば、openvswitch、sr-iov、opendaylight、OVNなど。

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

例ML2をOVSと一緒に使用する場合は、各計算ノードには、OVSを管理するL2エージェントが設定されています。ただし、たとえばOVNやOpenDayLightを使用する場合、OVSコントロールがその管轄下にあります。Neutronはルートプラグインを介してコントローラーにコマンドを提供し、彼はすでに言われたことを実行します。

OpenvSwitchの更新

現在、OpenStackの主要コンポーネントの1つはOpenvSwitchです。

JuniperContrailやNokiaNuageなどの追加ベンダーSDNを使用せずにOpenStackをインストールする場合、OVSはクラウドネットワークのメインネットワークコンポーネントであり、iptables、conntrack、namespacesとともに、マルチテナンシーを備えた本格的なオーバーレイネットワークを編成できます。当然、このコンポーネントは、たとえば、サードパーティ独自の（ベンダー）SDNソリューションを使用する場合に置き換えることができます。

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

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

注：当初、OVSは、高負荷のテレコム機能のソフトスイッチとしては考えられておらず、WEBサーバーやメールサーバーなど、帯域幅をあまり使用しないIT機能向けに設計されていました。ただし、OVSは最終決定中であり、現在のOVS実装ではパフォーマンスと機能が大幅に向上しているため、高負荷機能を備えた通信事業者が使用できます。たとえば、DPDKアクセラレーションをサポートするOVS実装があります。

知っておくべき3つの重要なOVSコンポーネントがあります。

カーネルモジュール-コントロールから受信したルールに基づいてトラフィックを処理する、カーネルスペースにあるコンポーネント。
vSwitch daemon (ovs-vswitchd) — , user space, kernel —
Database server — , , OVS, . OVSDB SDN .

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

現在、Openstackは、EPC、SBC、HLRなどのネットワーク機能を移行するために通信事業者によって広く使用されています。一部の機能は、OVSの形式で問題なく動作できますが、たとえば、EPCはサブスクライバートラフィックを処理します。つまり、EPCはそれ自体を介して大量のトラフィックを通過させます（現在、トラフィック量は毎秒数百ギガビットに達します）。当然、カーネルスペースを介してそのようなトラフィックを駆動することは（フォワーダーはデフォルトでそこにあるため）、良い考えではありません。したがって、OVSは、多くの場合、DPDKアクセラレーションテクノロジーを使用してユーザースペースに完全にデプロイされ、NICからカーネルをバイパスしてユーザースペースにトラフィックを転送します。

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

実際のレイアウトではどのように機能しますか？

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

簡単なOpenstackインストールを展開することから始めましょう。実験用のサーバーのセットが手元にないため、仮想マシンから1つの物理サーバーにレイアウトをアセンブルします。はい、もちろん、そのようなソリューションは商用目的には適していませんが、Openstackでネットワークがどのように機能するかの例を見ると、そのようなインストールで十分です。さらに、トレーニング目的のこのようなインストールは、トラフィックなどをキャッチできるため、さらに興味深いものです。

基本的な部分だけを見る必要があるため、複数のネットワークを使用することはできませんが、2つのネットワークのみを使用してすべてをレイズします。このレイアウトの2番目のネットワークは、アンダークラウドとdnsサーバーへのアクセス専用に使用されます。今のところ、外部ネットワークについては触れません。これは、別の大きな記事のトピックです。

それでは、順番に始めましょう。まず、少し理論。 TripleO（Openstack上のOpenstack）を使用してOpenstackをインストールします。 TripleOの本質は、アンダークラウドと呼ばれるOpenstackオールインワン（つまり、1つのノード）をインストールし、展開されたOpenstackの機能を使用して、オーバークラウドと呼ばれる悪用を目的としたOpenstackをインストールすることです。 Undercloudは、コンピューティング、制御、ストレージノードとして機能するハイパーバイザーをプロビジョニングするために、物理サーバー（ベアメタル）を管理する固有の機能（皮肉なプロジェクト）を使用します。つまり、Openstackのデプロイにサードパーティのツールを使用していません。OpenstackをOpenstackとともにデプロイします。インストールが進むにつれて、それははるかに明確になるので、そこで止まって先に進むことはしません。

: Openstack, . — , , . . ceph ( ) (Storage management Storage) , , QoS , . .

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

ネストされた仮想化が有効になっているかどうかは、次のように確認できます。
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 
文字Nが表示されている場合は、ネットワーク上にあるガイド（たとえば、このガイド）に従って、ネストされた仮想化のサポートを有効にします。

仮想マシンから次のスキームを組み立てる必要があります。

私の場合、将来のインストールの一部である仮想マシンの接続性のために（7つありますが、リソースがあまりない場合は4つで済ませることができます）、OpenvSwitchを使用しました。1つのovsブリッジを作成し、ポートグループを介して仮想マシンをそれに接続しました。これを行うために、次の形式の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>

ここでは、グループの3つのポート（2つのアクセスと1つのトランク）が宣言されています（後者はDNSサーバーに必要でしたが、それなしで実行することも、ホストマシンで起動することもできます-それはあなたにとってより便利な方法です）。次に、このテンプレートを使用して、virshnet-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サーバーなど、必要なすべてのパラメーターを設定すると、すぐにポートを構成できますが、インストール後は、コンソールからマシンにアクセスして必要なファイルを修正する方が簡単です。既製のイメージが既にある場合は、それを使用するか、私と同じように実行できます。Centos7の最小イメージをダウンロードし、それを使用して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

Undercloudのインストール

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


useradd stack
passwd stack

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

ここで、hostsファイルでフルネームundercloudを指定します。


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関連のコマンドを入力する必要はありません。クイーンズリリースを使用しましたが、好きなものを使用できます。

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


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

だから、設定を経る：

undercloud_hostname -完全undercloudサーバー名は、DNSサーバのエントリと一致しなければなりません

local_ipをprovizheningネットワークへのローカルアドレスundercloud -

network_gateway -同じローカルアドレス、インストール時に外の世界にアクセスするためのゲートウェイとして機能しますovercloudノードは、また、ローカルIPと一致する

undercloud_public_hostプロビジョニングネットワークから任意のフリーアドレス割り当て、外部APIの住所-

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

undercloud_nameserversをDNSサーバ-

generate_service_certificate-この行は現在の例では非常に重要です

。falseに設定されていない場合、インストール中にエラーが発生するため、問題はネットワークプロビジョニングのRedHatバグトラッカーlocal_interfaceインターフェイスに記述されています。このインターフェイスはアンダークラウドの展開中に再構成されるため、アンダー

クラウドに2つのインターフェイスが必要です。1つはアクセス用、もう1つはlocal_mtuのプロビジョニング用です。MTU。私たちは1500ポートOVS Svichaを持ってテストラボとMTU私を持っているので、1450年の値に置くことが必要である、VXLANパッケージにカプセル化されていたであろうその

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

マスカレード-外部ネットワークにアクセスするためのNATの使用

masquerade_network -ネットワークという意志をNAT -sya

dhcp_start-展開オーバー

クラウド中にノードにアドレスが割り当てられるアドレスプールの開始アドレスdhcp_end-展開オーバークラウド中にノードにアドレスが割り当てられるアドレスプールの最終アドレス

inspection_iprange-イントロスペクションに必要なアドレスのプール（上記のプールと交差してはなりません））

scheduler_max_attempts-オーバークラウドのインストールの最大試行回数（ノードの数以上である必要があります）

ファイルが記述された後、アンダークラウドをデプロイするコマンドを与えることができます。


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

オーバークラウドの展開は、このインターフェイスを介して実行されます。

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

(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@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を調査するためにインストールする場合は、少なくとも2つのディスクで少なくとも3つのノードを作成し、テンプレートで仮想ディスク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があります。これは、/ tmp /フォルダー内の各マシンの説明を含むxmlファイルを作成します。追加しないと、仮想マシンを定義できません。

次に、これらすべてのマシンを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 ~]#

コマンドの構文は明確で説明がないと思います。ただし、現時点では、すべてのセッションがDOWNステータスになっています。それらを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

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

現在、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 ~]$

もう1つのタッチ-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-typeqemuが必要です。そうしないと、仮想マシンが実行されません。

これで、約1時間、またはそれ以上（ハードウェアの機能によって異なります）があり、この時間の後に次の碑文が表示されることを期待できます。


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 ~]$

これで、オープンスタックのほぼ本格的なバージョンができました。このバージョンで、学習したり、実験を行ったりすることができます

。すべてが正常に機能することを確認しましょう。ユーザーのホームディレクトリスタックには、2つのファイルがあります。1つはstackrc（アンダークラウドを管理するため）で、もう1つは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 ~]$

私のインストールでは、もう1つ小さなタッチが必要です。使用しているマシンは別のネットワーク上にあるため、コントローラーにルートを追加します。これを行うには、heat-adminアカウントでcontrol-1に移動し、ルートを記述します


(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15         
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

さて、今、あなたは地平線に行くことができます。すべての情報（アドレス、ユーザー名、パスワード）は、ファイル/ホーム/スタック/ overcloudrcにあります。最終的なスキームは次のようになります。

ちなみに、私たちのインストールでは、マシンのアドレスはDHCPを介して発行され、ご覧のとおり、「ランダムに」発行されます。必要に応じて、展開中にどのアドレスをどのマシンにアタッチするかをテンプレートにハードコーディングできます。

仮想マシン間でトラフィックはどのように流れますか？

この記事では、トラフィックを渡すための3つのオプションについて検討します。

1つのL2ネットワークの1つのハイパーバイザーに2つのマシン
1つのL2ネットワーク内の異なるハイパーバイザー上の2台のマシン
異なるネットワーク上の2台のマシン（ネットワーク間でルート化）

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

テストするために、次のスキームをまとめましょう

。4つの仮想マシンを作成しました-1つのL2ネットワークに3つ-net-1、net-2ネットワークにもう1つ

(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                                        |

（overcloud）[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 ~]$

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

(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 ~]$

現在、ノードには3つのovsブリッジ（br-int、br-tun、br-ex）があります。それらの間に、ご覧のとおり、一連のインターフェイスがあります。わかりやすくするために、これらすべてのインターフェイスを図に配置して、何が起こるかを確認します。

VxLANトンネルが発生したアドレスから、1つのトンネルがcompute-1（192.168.255.26）に発生し、2番目のトンネルがcontrol-1（192.168.255.15）を確認していることがわかります。しかし、最も興味深いのは、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を使用してネットワーク分離を使用する場合、0番目のvlanに1つのL3インターフェイスではなく、複数のインターフェイスがあります。ただし、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が許可されるトランクポートです。上記の出力のvlan-id 0で示されているように、トラフィックはタグなしで外部に送信されます。

現時点で他のすべては計算ノードに似ています-同じブリッジ、同じトンネルが2つの計算ノードに行きます。

この記事ではストレージノードについては考慮しませんが、理解するために、これらのノードのネットワーク部分は恥ずべき点まで平凡であると言わなければなりません。この場合、IPアドレスがハングしている物理ポート（eth0）は1つだけで、それだけです。 VxLANトンネル、トンネルブリッジなどはありません。ポイントがないため、ovはまったくありません。ネットワーク分離を使用する場合、このノードには2つのインターフェイス（物理ポート、ボー、または2つのvlanのみがあります-関係ありません-必要なものによって異なります）-1つは管理用、もう1つはトラフィック用（VMディスクへの書き込み、からの読み取り）ディスクなど）。

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

これまでのところ、ネットワークは次のよう

になっています。各コンピューターに2つの仮想マシンがあります。すべてがcompute-0にどのように含まれているかを見てみましょう。


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

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

マシンには、仮想インターフェイスが1つだけあります-tap95d96a75-a0：

[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 ~]$

出力からわかるように、旅団には2つのインターフェイス（tap95d96a75-a0とqvb95d96a75-a0）しかありません。

OpenStackの仮想ネットワークデバイスの種類について少し

詳しく説明する価値があります

。vtap-インスタンス（VM）に接続された仮想インターフェイスqbr-Linuxブリッジ

qvbとqvo-LinuxブリッジとOpen vSwitchブリッジに接続されたvEthペア

br-int、br-tun、 br-vlan-vSwitchブリッジを開く

patch-、int-br-、phy-br--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が表示されます。これは、2番目の仮想マシンへのポートです。その結果、私たちのスキームは次のようになります。

注意深い読者がすぐに興味を持つはずの質問-仮想マシンポートとOVSポートの間にLinuxブリッジがあるのはなぜですか？事実、セキュリティグループはマシンを保護するために使用されます。これはiptablesにすぎません。OVSはiptablesでは機能しないため、この「クラッチ」が発明されました。ただし、それ自体は長生きしています。新しいリリースではconntrackに置き換えられています。

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

1つのL2ネットワークの1つのハイパーバイザーに2つのマシン

これらの2つのVMは同じL2ネットワーク内にあり、同じハイパーバイザー上にあるため、両方のマシンが同じ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ネットワーク内の異なるハイパーバイザー上の2台のマシン次に、同じL2ネットワーク内の異なるハイパーバイザー上にある

2台のマシン間でトラフィックがどのように移動するかを見てみましょう。正直なところ、何も変わることはなく、ハイパーバイザー間のトラフィックだけが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転送テーブルにあり、上記の出力からわかるように、ポート2、つまりbr-tunへのポートから見ることができます。

[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に宛先macがあることがわかります。

[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に送信され、その背後にinstance-00000003仮想マシンが既に配置されています。

仮想インフラストラクチャで学習するためにOpenstackを展開することの利点は、ハイパーバイザー間のトラフィックを簡単にキャッチして、それがどうなるかを確認できることです。これを実行し、vnetポートでcompute-0に向けて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のパッチがアドレス10.0.1.88（ICMPトラフィック）に送信され、vni 22のVxLANパケットにラップされ、パケットがホスト192.168.255.19（compute-0）からホスト192.168.255.26（計算-1）。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は現実に対応します。

2行目はリターントラフィックを示していますが、そこで説明するのは意味がなく、すべてが明確です。

異なるネットワーク上の2台のマシン（ネットワーク間のルーティング）

今日の最後のケースは、仮想ルーターを使用した1つのプロジェクト内のネットワーク間のルーティングです。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

この場合、パケットはゲートウェイに送られ、そこにルーティングされる必要があるため、ゲートウェイのMACアドレスを見つける必要があります。このため、インスタンスの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 ~]$

3番目のポートは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 ~]$

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

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

したがって、ゲートウェイのポピーアドレスが制御ノードの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 ~]$

3部まで。しかし、名前から判断すると、それぞれの目的を推測することができます。後でIDが0と1のインスタンスに戻ります。ここで、名前名qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abeに関心があります。


[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 ~]$

この名前名には、前に作成した2つの内部名前があります。両方の仮想ポートがbr-intに追加されます。ポートqr-0c52b15f-8fのマスアドレスを確認しましょう。宛先のポピーアドレスから判断すると、トラフィックは正確にこのインターフェイスに送信されたためです。

[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を対象としているため、2番目のインターフェイスqr-92fa49b5-54を経由して、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 ~]$

すべてが論理的であり、驚くことではありません。br-intのホスト10.0.2.8のポピーアドレスが表示されている場所を確認します。

[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へのトンネルには次のアクションがあります=ロード：0-> NXM_OF_VLAN_TCI []、ロード：0x16-> NXM_NX_TUN_ID []、出力：3。0x16を10進表記に変換する：


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

計算するトンネル-1には次のVNIがあります：actions = load：0-> NXM_OF_VLAN_TCI []、load：0x63-> NXM_NX_TUN_ID []、output：2。10進表記で0x63を変換する：


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*******************

最初のパケットは、ホスト192.168.255.19（compute-0）からホスト192.168.255.15（control-1）へのvni 22のvxlanパケットであり、その内部でICMPパケットがホスト10.0.1.85からホスト10.0.2.8にパックされます。上で計算したように、vniは出力で見たものに対応します。

2番目のパケットは、ホスト192.168.255.15（control-1）からホスト192.168.255.26（compute-1）へのvni 99のvxlanパケットであり、その中にICMPパケットがホスト10.0.1.85からホスト10.0.2.8にパックされます。上で計算したように、vniは出力で見たものに対応します。

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

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

。 2つの名前名を忘れました：

[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サーバーからアドレスを自動的に受信するのは素晴らしいことです。これらは、2つのネットワーク10.0.1.0/24および10.0.2.0/24用の2つのDHCPサーバーです。

これがそうであることを確認しましょう。この名前名には、DHCPサーバー自体のアドレスである10.0.1.1という1つのアドレスしかなく、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つの内部ネットワーク、1つの仮想ルーターです。現在、外部ネットワークはありません。さまざまなプロジェクトが山ほどあり、それぞれに独自のネットワークがあります（重複しています）。）、分散ルーターをオフにしましたが、最終的にテストベンチには制御ノードが1つしかありませんでした（障害耐性のために、3つのノードのクォーラムが必要です）。商取引ではすべてが「少し」複雑になるのは論理的ですが、この単純な例では、これがどのように機能するかを理解しています。もちろん、3つまたは300の名前名がある場合は重要ですが、構造全体の操作の観点からは、何も変わりません...しかし今のところある種のベンダーSDNを固執しないでください。しかし、それはまったく別の話です。

面白かったと思います。コメント/追加がうまくある場合、または私が公然と嘘をついた場所（私は人間であり、私の意見は常に主観的です）-修正/追加する必要があるものを書いてください-私たちはすべてを修正/追加します。

結論として、Openstack（バニラとベンダーの両方）をVMWareのクラウドソリューションと比較することについて少しお話ししたいと思います-ここ数年この質問を頻繁に受けており、正直なところ、私はそれにうんざりしていますが、それでもまだです。私の意見では、これら2つの解決策を比較することは非常に困難ですが、両方の解決策には不利な点があることは明白です。一方の解決策を選択するときは、長所と短所を比較検討する必要があります。

OpenStackがコミュニティ主導のソリューションである場合、VMWareは、クライアントからお金を稼ぐことに慣れている営利企業であるため、必要なことだけを実行する権利があります（読み取り、利益があります）。これは論理的です。しかし、大きくて太いものが1つあります。たとえば、NokiaからOpenStackを降りて、Juniper（Contrail Cloud）などのソリューションに切り替えることはできますが、VMWareを降りることはほとんどできません。私にとって、これら2つのソリューションは次のようになります。Openstack（ベンダー）は、あなたが置かれる単純なケージですが、鍵を持っていて、いつでも終了できます。 VMWareは黄金の檻であり、所有者は檻の鍵を持っており、それはあなたにかなりの費用がかかります。

私は最初の製品も2番目の製品もキャンペーンしていません-あなたはあなたが必要なものを選択します。しかし、そのような選択肢があれば、テレコムクラウドには両方のソリューション（ITクラウド用のVMWare（低負荷、便利な管理）、一部のベンダーのOpenStack（NokiaとJuniperが非常に優れたターンキーソリューションを提供））を選択します。私は純粋なITにOpenstackを使用しません-それは大砲でスズメを撃つようなものですが、冗長性を除いて、それを使用することへの禁忌は見られません。ただし、テレコムでVMWareを使用する（フォードラプターで瓦礫を運ぶ方法）ことは、外から見ると美しいですが、ドライバーは1回ではなく10回のトリップを行う必要があります。

私の意見では、VMWareの最大の欠点は、その完全な閉鎖性です-会社は、vSANやハイパーバイザーコアにあるものなど、それがどのように機能するかについての情報を提供しません-それは単にそれにとって有益ではありません-つまり、VMWareの専門家になることは決してありません-ベンダーのサポートがなければ、あなたは運命にあります（平凡な質問に困惑しているVMWareの専門家に会うことがよくあります）。私にとって、VMWareはフードがロックされた車を購入しています-はい、おそらくタイミングベルトを変更できるスペシャリストがいますが、このソリューションを販売した人だけがフードを開けることができます。個人的には、自分に合わない解決策は好きではありません。あなたはあなたがボンネットの下に行く必要はないかもしれないと言うでしょう。はい、これは可能ですが、20〜30台の仮想マシン、40〜50台のネットワークからクラウドで大規模な機能を組み立てる必要がある場合に、私はあなたを見ていきます。半分は外に出たいと思っており、残りの半分はSR-IOVアクセラレーションを要求しています。そうしないと、これらのマシンがさらに数十台必要になります。そうしないと、パフォーマンスが十分になりません。

他の観点もあるので、何を選択するかはあなた次第です。そして最も重要なことは、後であなたが選択する責任があるということです。これは私の意見です。少なくとも4つの製品（Nokia、Juniper、Red Hat、VMWare）を見て、触れたことがある人です。つまり、私は比較するものがあります。

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

クラウドとは何ですか？同じ仮想化-縦断ビュー？ (adsbygoogle = window.adsbygoogle || []).push({});