雲端運算正在越來越深入地滲透到我們的生活中，可能沒有人至少沒有使用過任何雲端服務。 然而，雲到底是什麼以及它是如何運作的，很少人知道，即使只是在想法層面上也是如此。 5G已經成為現實，電信基礎設施開始從支柱解決方案轉向雲端解決方案，就像從完全硬體解決方案轉向虛擬化「支柱」一樣。
今天我們將討論雲端基礎設施的內部世界，特別是網路部分的基礎知識。
什麼是雲？ 相同的虛擬化 - 設定檔視圖？
不只是一個邏輯問題。 不——這不是虛擬化，儘管沒有虛擬化就無法實現。 我們來看兩個定義：
雲端運算（以下簡稱雲端） 是一種模型，用於提供對分散式運算資源的使用者友好訪問，這些資源必須以盡可能低的延遲和服務提供者的最低成本按需部署和啟動。
Виртуализация - 這是將一個實體實體（例如，一台伺服器）劃分為多個虛擬實體的能力，從而提高資源利用率（例如，您有3 台伺服器的負載率為25-30%，虛擬化後您將負載1 台伺服器） 80-90%）。 當然，虛擬化會消耗一些資源——您需要為虛擬機器管理程式提供資源，但是，正如實踐所表明的那樣，這是得不償失的。 虛擬化的一個理想例子是VMWare，它完美地準備了虛擬機，或者例如KVM，我更喜歡它，但這只是個人喜好的問題。
我們在不知不覺中使用虛擬化，甚至鐵路由器也已經使用虛擬化 - 例如，在最新版本的 JunOS 中，作業系統作為虛擬機安裝在即時 Linux 發行版（Wind River 9）之上。 但虛擬化不是雲，但雲不能沒有虛擬化而存在。
虛擬化是建構雲端的建構模組之一。
透過簡單地將多個虛擬機器管理程式收集到一個L2 網域中、添加幾個yaml 劇本來透過某種ansible 自動註冊VLAN 並將諸如編排系統之類的東西塞到上面來自動建立虛擬機器來建立雲，這是行不通的。 它會更準確，但由此產生的弗蘭肯斯坦並不是我們需要的雲，儘管它可能是其他人的終極夢想。 此外，如果你採用相同的 Openstack，它本質上仍然是弗蘭肯斯坦，但哦，好吧，我們現在不討論這個。
但我理解，從上面給出的定義來看，並不完全清楚什麼實際上可以被稱為雲。
因此，NIST（美國國家標準技術研究院）的一份文件提供了雲端基礎設施應具備的 5 個主要特徵：
根據要求提供服務。 使用者必須能夠自由存取分配給他的電腦資源（例如網路、虛擬磁碟、記憶體、處理器核心等），而這些資源必須自動提供——即無需服務提供者的干預。
服務範圍廣泛。 必須透過標準機制提供對資源的訪問，以允許使用標準 PC、瘦客戶端和行動裝置。
將資源合併到池中。 資源池必須能夠同時提供多個客戶端資源，確保客戶端之間相互隔離、不影響、不競爭資源。 網路也包含在池中，這表明可以使用重疊尋址。 池必須能夠按需擴充。 池的使用使得提供必要級別的資源容錯以及物理和虛擬資源的抽象成為可能——服務的接收者只需提供他請求的一組資源（這些資源的物理位置、數量）伺服器和交換機- 這對客戶端來說並不重要）。 然而，我們必須考慮到這樣一個事實：提供者必須確保這些資源的預留透明。
快速適應不同的條件。 服務必須是靈活的－快速提供資源，重新分配資源，根據客戶的要求添加或減少資源，並且在客戶方面應該有一種雲資源取之不盡用之不竭的感覺。 例如，為了便於理解，您不會看到由於伺服器上的硬碟損壞而導致 Apple iCloud 中的部分磁碟空間消失的警告，而磁碟機確實損壞了。 此外，就您而言，這項服務的可能性幾乎是無限的 - 您需要 2 TB - 沒問題，您已付款並收到它。 Google.Drive 或 Yandex.Disk 可以提供類似的範例。
衡量所提供服務的可能性。 雲端系統必須自動控制和最佳化消耗的資源，而這些機制必須對使用者和服務提供者都是透明的。 也就是說，您始終可以檢查您和您的客戶消耗了多少資源。
值得考慮的是，這些要求大多是針對公有雲的要求，因此對於私有雲（即針對公司內部需求而推出的雲），這些要求可以稍作調整。 然而，它們仍然必須完成，否則我們將無法獲得雲端運算的所有好處。
為什麼我們需要雲端？
然而，任何新技術或現有技術、任何新協議都是為某些東西而創建的（當然，RIP-ng 除外）。 沒有人為了協議而需要協議（當然，RIP-ng 除外）。 創建雲端是為了向用戶/客戶端提供某種服務，這是合乎邏輯的。 我們都至少熟悉幾種雲端服務，例如 Dropbox 或 Google.Docs，我相信大多數人都能成功使用它們 - 例如，本文就是使用 Google.Docs 雲端服務編寫的。 但我們所知道的雲端服務只是雲端的部分能力——更準確地說，它們只是SaaS類型的服務。 我們可以透過三種方式提供雲端服務：SaaS、PaaS 或 IaaS 的形式。 您需要什麼服務取決於您的願望和能力。
讓我們按順序逐一查看：
軟件即服務（SaaS） 是一種向用戶端提供成熟服務的模型，例如 Yandex.Mail 或 Gmail 等電子郵件服務。 在這種服務交付模型中，作為客戶，您實際上除了使用服務之外什麼都不做，也就是說，您不需要考慮設定服務、其容錯或冗餘。 最重要的是不要洩露您的密碼；該服務的提供者將為您完成剩下的工作。 從服務提供者的角度來看，他全面負責整個服務——從伺服器硬體和主機作業系統到資料庫和軟體設定。
平台即服務（PaaS） ——使用此模型時，服務提供者為客戶端提供服務的工件，例如，我們以 Web 伺服器為例。 服務供應商為客戶提供了一台虛擬伺服器（實際上是一組資源，如RAM/CPU/儲存/網路等），甚至在這台伺服器上安裝了作業系統和必要的軟體，但是，配置所有這些工作都是由客戶自己完成的，並且是為了客戶所提供的服務的性能。 服務提供者與先前的情況一樣，負責實體設備、虛擬機器管理程式、虛擬機器本身的效能、其網路可用性等，但服務本身不再屬於其職責範圍。
基礎設施即服務（IaaS） - 這種方法已經比較有趣了，事實上，服務提供者為客戶端提供了完整的虛擬化基礎設施 - 即一些資源集（池），例如 CPU 核心、RAM、網路等。其他一切取決於客戶-客戶想要在分配的池（配額）內使用這些資源做什麼- 對於供應商來說並不是特別重要。 無論客戶想要創建自己的 vEPC 還是創建一個迷你運營商並提供通訊服務 - 毫無疑問 - 就去做吧。 在這種情況下，服務提供者負責配置資源、其容錯性和可用性，以及允許他們匯集這些資源並使它們可供客戶端使用的作業系統，並且能夠隨時增加或減少資源應客戶要求。 用戶端透過自助服務入口網站和控制台自行配置所有虛擬機器和其他金屬絲，包括設定網路（外部網路除外）。
什麼是 OpenStack？
在所有這三個選項中，服務提供者都需要一個能夠創建雲端基礎架構的作業系統。 事實上，對於SaaS來說，不只一個部門負責整個技術堆疊——有一個部門負責基礎設施——也就是說，它向另一個部門提供IaaS，這個部門向客戶端提供SaaS。 OpenStack 是雲端作業系統之一，它允許您將一堆交換器、伺服器和儲存系統收集到資源池中，將該公用池拆分為子池（租戶），並透過網路將這些資源提供給客戶端。
OpenStack的 是一個雲端作業系統，可讓您控制大量運算資源、資料儲存和網路資源，並使用標準身份驗證機制透過 API 進行設定和管理。
換句話說，這是一組免費軟體項目，旨在創建雲端服務（公有和私有） - 即一組工具，允許您將伺服器和交換設備組合到單一資源池中，管理這些資源提供了必要的容錯級別。
在撰寫本資料時，OpenStack 結構如下所示：
圖片取自
OpenStack 中包含的每個元件都執行特定的功能。 這種分散式架構可讓您在解決方案中包含所需的功能組件集。 但是，某些組件是根組件，刪除它們將導致整個解決方案完全或部分無法操作。 這些組件通常分為：
- 我的帳戶 — 用於管理 OpenStack 服務的基於 Web 的 GUI
- 拱心石 是一種集中式身分識別服務，為其他服務提供身分驗證和授權功能，以及管理使用者憑證及其角色。
- 中子 - 網路服務，提供各種 OpenStack 服務的介面之間的連接（包括 VM 之間的連接及其對外部世界的存取）
- 煤渣 — 提供對虛擬機器區塊儲存的訪問
- 新 — 虛擬機器的生命週期管理
- 掃視 — 虛擬機器鏡像和快照的儲存庫
- 迅速 — 提供對儲存物件的存取
- 雲高儀 — 提供收集遙測資料並測量可用和已消耗資源能力的服務
- 熱 — 基於範本的編排，用於自動建立和配置資源
可以查看所有項目及其目的的完整列表 .
每個 OpenStack 元件都是執行特定功能的服務，並提供 API 來管理該功能並與其他雲端作業系統服務互動以建立統一的基礎架構。 例如，Nova提供運算資源管理和用於存取配置這些資源的API，Glance提供映像管理和用於管理它們的API，Cinder提供區塊儲存和用於管理它的API等。 所有功能都以非常緊密的方式相互關聯。
然而，如果你仔細觀察，OpenStack 中運行的所有服務最終都是連接到網路的某種虛擬機器（或容器）。 問題出現了——為什麼我們需要這麼多元素？
讓我們了解一下建立虛擬機器並將其連接到 Openstack 中的網路和持久儲存的演算法。
- 當您建立建立機器的請求時，無論是透過 Horizon（Dashboard）的請求還是透過 CLI 的請求，首先發生的事情是您的請求在 Keystone 上的授權 - 您可以建立機器嗎？它是否具有使用這個網路的權利，你的草案配額等等。
- Keystone 會對您的要求進行身份驗證，並在回應訊息中產生一個身份驗證令牌，該令牌將在以後使用。 收到 Keystone 的回應後，請求將發送至 Nova (nova api)。
- Nova-api 透過使用先前產生的身份驗證令牌聯繫 Keystone 來檢查您的請求的有效性
- Keystone 執行身份驗證並根據此身份驗證令牌提供有關權限和限制的資訊。
- Nova-api 在 nova-database 中為新虛擬機器建立一個項目，並將建立機器的請求傳遞給 nova-scheduler。
- Nova-scheduler根據指定的參數、權重和區域選擇要部署VM的主機（電腦節點）。 此記錄和 VM ID 被寫入 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中驗證請求，之後在資料庫中建立條目（連接埠識別碼等），建立建立連接埠的請求，並將請求的資訊傳回給nova-compute。
- Nova-compute 聯絡 cinder，要求為虛擬機器指派磁碟區。 與glance類似，cider在Keystone中驗證請求，建立磁碟區建立請求，並傳回請求的資訊。
- Nova-compute 聯絡 libvirt，要求部署具有指定參數的虛擬機器。
事實上，創建一個簡單虛擬機器的看似簡單的操作，卻變成了雲端平台各元素之間 API 呼叫的漩渦。 此外，如您所看到的，即使是先前指定的服務也由較小的元件組成，這些元件之間發生互動。 創建機器只是雲端平台允許您做的事情的一小部分 - 有一個負責平衡流量的服務，一個負責塊存儲的服務，一個負責DNS的服務，一個負責配置裸機伺服器的服務等雲允許您像對待一群羊一樣對待您的虛擬機器（而不是虛擬化）。 如果虛擬環境中的電腦發生問題 - 您從備份等中恢復它，但雲端應用程式的構建方式使得虛擬機無法發揮如此重要的作用 - 虛擬機「死亡」 - 沒問題- 簡單地創建了一輛新車輛，該車輛是基於模板的，正如他們所說，小隊沒有註意到戰鬥機的損失。 當然，這提供了編排機制的存在 - 使用 Heat 模板，您可以輕鬆部署由數十個網路和虛擬機器組成的複雜功能。
始終值得記住的是，沒有網路就沒有雲端基礎設施 - 每個元素都以一種或另一種方式透過網路與其他元素互動。 此外，雲端具有絕對非靜態的網路。 當然，底層網路或多或少是靜態的——新的節點和交換器不會每天添加，但覆蓋組件可以而且將不可避免地不斷變化——新的網路將被添加或刪除，新的虛擬機將出現，舊的虛擬機器將出現死亡。 正如您從本文開頭給出的雲端定義中所記得的那樣，資源應該自動分配給用戶，並且服務提供者的干預最少（或者更好的是，沒有）。 也就是說，現在以透過 http/https 存取的個人帳戶形式存在的網路資源提供類型以及作為後端的值班網路工程師 Vasily 不是雲，甚至不是雲。如果瓦西里有八隻手。
Neutron 作為網路服務，提供用於管理雲端基礎架構的網路部分的 API。 該服務透過提供稱為網路即服務 (NaaS) 的抽象層來支援和管理 Openstack 的網路部分。 也就是說，網路是與虛擬 CPU 核心或 RAM 量相同的虛擬可測量單位。
但在討論 OpenStack 網路部分的架構之前，我們先考慮一下該網路在 OpenStack 中如何運作，以及為什麼網路是雲端的重要組成部分。
因此，我們有兩台紅色客戶端虛擬機器和兩個綠色客戶端虛擬機器。 我們假設這些機器以這種方式位於兩個虛擬機器管理程式上：
目前，這只是 4 台伺服器的虛擬化，僅此而已，因為到目前為止我們所做的只是虛擬化 4 台伺服器，將它們放置在兩台實體伺服器上。 到目前為止，它們甚至還沒有連接到網路。
為了製作雲，我們需要添加幾個元件。 首先，我們虛擬化網路部分——我們需要將這 4 台機器成對連接，並且客戶端需要 L2 連接。 您可以使用交換器並在其方向上配置中繼，並使用 linux 橋接器解決所有問題，或者對於更高級的用戶，可以使用 openvswitch（我們稍後會返回）。 但可能有很多網絡，並且不斷地通過交換機推送 L2 並不是最好的主意 - 有不同的部門、服務台、數月的等待應用程序完成、數週的故障排除 - 在現代世界中，這方法不再有效。 公司越早理解這一點，就越容易向前發展。 因此，在虛擬機管理程式之間，我們將選擇一個L3 網絡，我們的虛擬機將透過該網絡進行通信，並在此L3 網絡之上，我們將構建虛擬L2 覆蓋網絡，虛擬機的流量將在其中運行。 您可以使用 GRE、Geneve 或 VxLAN 作為封裝。 現在讓我們專注於後者，儘管它並不是特別重要。
我們需要將 VTEP 定位在某個地方（我希望每個人都熟悉 VxLAN 術語）。 由於我們有一個直接來自伺服器的 L3 網絡，因此沒有什麼可以阻止我們將 VTEP 放置在伺服器本身上，而 OVS (OpenvSwitch) 非常擅長做到這一點。 結果，我們得到了這樣的設計：
由於虛擬機器之間的流量必須進行劃分，因此通往虛擬機器的連接埠將具有不同的 VLAN 編號。 標籤號碼僅在一個虛擬交換器中發揮作用，因為當封裝在 VxLAN 中時，我們可以輕鬆刪除它，因為我們將擁有 VNI。
現在我們可以毫無問題地為他們創建我們的機器和虛擬網路。
但是，如果客戶端有另一台計算機，但位於不同的網路上怎麼辦？ 我們需要在網路之間生根。 當使用集中式路由時，我們將看到一個簡單的選項 - 也就是說，流量透過特殊的專用網路節點進行路由（通常，它們與控制節點結合在一起，因此我們將擁有相同的東西）。
看起來沒什麼複雜的 - 我們在控制節點上創建一個橋接接口，將流量驅動到它，然後從那裡將其路由到我們需要的地方。 但問題是RED客戶端想要使用10.0.0.0/24網絡，而GREEN客戶端想要使用10.0.0.0/24網絡。 也就是說，我們開始交叉位址空間。 此外，客戶端不希望其他客戶端能夠路由到其內部網絡，這是有道理的。 為了分離網路和客戶端資料流量，我們將為它們分配一個單獨的命名空間。 命名空間實際上是Linux 網路堆疊的副本，也就是說，命名空間RED 中的客戶端與命名空間GREEN 中的客戶端完全隔離（好吧，這些客戶端網路之間的路由允許透過預設命名空間或在上游傳輸設備上進行）。
即我們得到下圖：
L2隧道從所有運算節點匯聚到控制節點。 這些網路的 L3 介面所在的節點，每個節點都位於專用的命名空間中以進行隔離。
然而，我們忘記了最重要的事。 虛擬機器必須向客戶端提供一項服務，即它必須至少有一個可以存取的外部介面。 也就是說，我們需要走出去，走進外面的世界。 這裡有不同的選擇。 讓我們做最簡單的選擇。 我們將為每個客戶端添加一個網絡，該網絡將在提供者的網絡中有效，並且不會與其他網絡重疊。 這些網路還可以交叉並查看提供者網路一側的不同 VRF。 網路資料也將存在於每個客戶端的命名空間中。 然而，他們仍然會透過一個實體（或紐帶，更符合邏輯）介面與外界聯繫。 為了分離客戶端流量，傳出的流量將使用分配給客戶端的 VLAN 標記進行標記。
結果我們得到了這樣的圖：
一個合理的問題是為什麼不在計算節點本身上設定網關？ 這不是一個大問題；而且，如果您打開分散式路由器（DVR），這將會起作用。 在這種情況下，我們正在考慮使用集中式網關最簡單的選項，Openstack 中預設使用該網關。 對於高負載功能，他們將同時使用分散式路由器和加速技術，例如 SR-IOV 和 Passthrough，但正如他們所說，這是一個完全不同的故事。 首先，讓我們處理基本部分，然後我們將討論細節。
實際上，我們的方案已經可行，但有一些細微差別：
- 我們需要以某種方式保護我們的機器，即在面向客戶端的交換器介面上放置一個過濾器。
- 讓虛擬機器能夠自動取得IP位址，這樣就不用每次都透過控制台登入並註冊位址了。
讓我們從機器保護開始。 為此，您可以使用普通的 iptables，為什麼不呢。
也就是說，現在我們的拓樸變得有點複雜了：
讓我們繼續。 我們需要新增一個 DHCP 伺服器。 為每個客戶端定位 DHCP 伺服器的最理想位置是上面已經提到的控制節點，命名空間位於其中：
然而，有一個小問題。 如果一切都重新啟動並且有關 DHCP 上租用地址的所有資訊都消失了怎麼辦？ 順理成章的是，機器將被賦予新的地址，但這不是很方便。 這裡有兩種方法 - 要么使用網域名稱並為每個客戶端添加一個DNS伺服器，那麼地址對我們來說就不會特別重要（類似於k8s中的網路部分） - 但外部網路存在問題，因為地址也可以透過DHCP 在其中發布- 您需要與雲端平台中的DNS 伺服器和外部DNS 伺服器同步，在我看來這不是很靈活，但很有可能。 或者第二個選項是使用元資料 - 即保存有關頒發給電腦的位址的信息，以便 DHCP 伺服器知道要向電腦頒發哪個位址（如果電腦已經收到位址）。 第二個選項更簡單、更靈活，因為它允許您保存有關汽車的附加資訊。 現在讓我們將代理元資料新增到圖中：
另一個值得討論的問題是所有客戶端都可以使用一個外部網絡，因為外部網絡如果必須在整個網絡中有效，將會很困難 - 您需要不斷地分配和控制這些網絡的分配。 在建立公有雲時，為所有客戶端使用單一外部預先配置網路的能力將非常有用。 這將使部署機器變得更容易，因為我們不必查閱地址資料庫並為每個客戶端的外部網路選擇唯一的位址空間。 此外，我們可以提前註冊外部網絡，在部署時我們只需要將外部位址與客戶端機器關聯起來。
NAT 在這裡為我們提供了幫助 - 我們將讓客戶端能夠使用 NAT 轉換透過預設命名空間存取外部世界。 嗯，這裡有個小問題。 如果客戶端伺服器充當客戶端而不是伺服器，那麼這很好 - 也就是說，它發起而不是接受連接。 但對我們來說，情況卻恰恰相反。 在這種情況下，我們需要進行目標 NAT，以便控制節點在接收流量時了解到該流量是發送給客戶端 A 的虛擬機 A，這意味著我們需要從外部位址（例如 100.1.1.1）進行 NAT 轉換. 10.0.0.1，到內部位址100。 在這種情況下，儘管所有客戶端都將使用相同的網絡，但內部隔離仍被完全保留。 即我們需要在控制節點上做dNAT和sNAT。 是否使用具有浮動位址的單一網路或外部網絡，或同時使用兩者，取決於您想要將什麼帶入雲端。 我們不會在圖中新增浮動位址，但會保留先前新增的外部網路 - 每個客戶端都有自己的外部網路（在圖中，它們在外部介面上表示為 vlan 200 和 XNUMX）。
結果，我們收到了一個有趣且同時經過深思熟慮的解決方案，它具有一定的靈活性，但尚未具備容錯機制。
首先，我們只有一個控制節點——它的故障將導致所有系統崩潰。 要解決此問題，您需要至少有 3 個節點組成法定人數。 讓我們將其添加到圖表中：
當然，所有節點都是同步的，當一個活動節點離開時，另一個節點將接管其職責。
下一個問題是虛擬機器磁碟。 目前，它們儲存在虛擬機器管理程式本身上，如果虛擬機管理程式出現問題，我們將丟失所有資料 - 如果我們遺失的不是磁碟而是整個伺服器，則 raid 的存在將無濟於事。 為此，我們需要創建一個服務來充當某種儲存的前端。 什麼樣的儲存對我們來說並不是特別重要，但它應該保護我們的資料免受磁碟和節點甚至整個機櫃故障的影響。 這裡有多種選擇 - 當然，還有帶有光纖通道的 SAN 網絡，但說實話 - FC 已經成為過去 - 傳輸中 E1 的類似物 - 是的，我同意，它仍在使用，但是只有在沒有它就絕對不可能的地方。 因此，我不會自願在 2020 年部署 FC 網絡，因為我知道還有其他更有趣的替代方案。 儘管對每個人來說，可能有些人相信 FC 及其所有限制就是我們所需要的 - 我不會爭論，每個人都有自己的看法。 然而，我認為最有趣的解決方案是使用 SDS，例如 Ceph。
Ceph 允許您使用一系列可能的備份選項來建立高度可用的資料儲存解決方案，從具有奇偶校驗檢查的程式碼（類似於raid 5 或6）開始，最後將完整資料複製到不同的磁碟，同時考慮到磁碟的位置伺服器、機櫃中的伺服器等
要建置 Ceph，您還需要 3 個節點。 與儲存的互動也將透過網路使用區塊、物件和文件儲存服務進行。 讓我們為架構添加儲存：
注意：您也可以製作超融合運算節點 - 這是在一個節點上組合多個功能的概念 - 例如，儲存+運算 - 無需專門用於 ceph 儲存的特殊節點。 我們將獲得相同的容錯方案 - 因為 SDS 將以我們指定的保留等級保留資料。 然而，超融合節點始終是一種妥協- 因為存儲節點並不像乍一看那樣只是加熱空氣（因為它上面沒有虛擬機） - 它花費CPU 資源來服務SDS（事實上，它做了所有的事情）節點、磁碟等故障後的複製與復原）。 也就是說，如果將運算節點與儲存結合起來，您將失去計算節點的一些功能。
所有這些東西都需要以某種方式進行管理 - 我們需要一些東西，透過它我們可以創建機器、網路、虛擬路由器等。為此，我們將向控制節點添加一個服務，該服務將充當儀表板 -客戶將能夠透過http/ https 連接到該入口網站並執行他需要的一切（好吧，幾乎）。
結果，我們現在有了一個容錯系統。 該基礎設施的所有元素都必須以某種方式進行管理。 前面已經描述過，Openstack 是一組項目，每個項目都提供特定的功能。 正如我們所看到的，有足夠的元素需要配置和控制。 今天我們來談談網路部分。
中子架構
在OpenStack中，Neutron負責將虛擬機器連接埠連接到公共L2網絡，確保位於不同L2網路的VM之間的流量路由，以及向外路由，提供NAT、Floating IP、DHCP等服務。
在較高的層面上，網路服務（基本部分）的操作可以描述如下。
啟動VM時，網路服務：
- 為給定的虛擬機器（或多個連接埠）建立一個連接埠並通知 DHCP 服務；
- 建立一個新的虛擬網路設備（透過 libvirt）；
- VM 連接到步驟 1 中建立的連接埠；
奇怪的是，Neutron 的工作是基於每個深入 Linux 的人都熟悉的標準機制——命名空間、iptables、linux 橋、openvswitch、conntrack 等。
需要立即澄清的是，Neutron 不是 SDN 控制器。
Neutron 由幾個互連的組件組成：
Openstack-neutron-伺服器 是一個透過 API 處理使用者請求的守護程式。 該惡魔不參與註冊任何網絡連接，但為其插件提供必要的信息，然後插件配置所需的網絡元素。 OpenStack 節點上的 Neutron 代理程式向 Neutron 伺服器註冊。
Neutron-server實際上是一個用python編寫的應用程序，由兩個部分組成：
- 休息服務
- Neutron 插件（核心/服務）
REST服務旨在接收來自其他元件的API呼叫（例如，提供某些資訊的請求等）
插件是在 API 請求期間呼叫的插件軟體元件/模組 - 也就是說，服務的歸屬是透過它們發生的。 插件分為兩種類型－服務插件和根插件。 一般來說，horse插件主要負責管理VM之間的位址空間和L2連接，服務插件已經提供了額外的功能，例如VPN或FW。
例如，可以查看今天可用的插件列表
服務插件可以有多個，但馬插件只能有一個。
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 插件的前身俱有整體結構，例如不允許在一次安裝中混合使用多種技術。 例如，您不能同時使用 openvswitch 和 linuxbridge - 無論是第一個還是第二個。 為此，創建了 ML2 外掛程式及其架構。
ML2 有兩個元件 - 兩種類型的驅動程式：類型驅動程式和機制驅動程式。
類型驅動程式 確定用於組織網路連線的技術，例如 VxLAN、VLAN、GRE。 同時，驅動程式允許使用不同的技術。 標準技術是覆蓋網路和vlan外部網路的VxLAN封裝。
類型驅動程式包括以下網路類型：
平 - 沒有標籤的網絡
VLAN - 標記網絡
當地 — 一體式安裝的特殊類型網路（開發人員或培訓都需要此類安裝）
GRE — 使用 GRE 隧道的覆蓋網絡
VxLAN — 使用 VxLAN 隧道的覆蓋網絡
機構驅動程式 定義確保類型驅動程式中指定的技術組織的工具 - 例如，openvswitch、sr-iov、opendaylight、OVN 等。
根據此驅動程式的實現，將使用由 Neutron 控制的代理，或使用與外部 SDN 控制器的連接，這會處理與組織 L2 網路、路由等相關的所有問題。
範例：如果我們將 ML2 與 OVS 一起使用，則在管理 OVS 的每個運算節點上安裝一個 L2 代理程式。 但是，如果我們使用例如 OVN 或 OpenDayLight，那麼 OVS 的控制權就在它們的管轄範圍內 - Neutron 透過根插件向控制器發出命令，並且它已經執行了所告知的操作。
讓我們溫習一下 Open vSwitch
目前，OpenStack 的關鍵元件之一是 Open vSwitch。
在沒有其他供應商 SDN（例如 Juniper Contrail 或 Nokia Nuage）的情況下安裝 OpenStack 時，OVS 是雲端網路的主要網路元件，與 iptables、conntrack、命名空間一起，讓您組織成熟的多租戶覆蓋網路。 當然，該元件可以被替換，例如，當使用第三方專有（供應商）SDN 解決方案時。
OVS 是一款開源軟體交換機，設計用於虛擬化環境中作為虛擬流量轉發器。
目前OVS擁有非常好的功能，包括QoS、LACP、VLAN、VxLAN、GENEVE、OpenFlow、DPDK等技術。
注意：OVS 最初並不是被設想為用於高負載電信功能的軟體交換機，而是更多地為頻寬需求較低的 IT 功能（例如 WEB 伺服器或郵件伺服器）而設計。 然而，OVS正在進一步發展，目前OVS的實現已經大大提高了其性能和能力，這使得它可以被具有高負載功能的電信運營商使用，例如，有支援DPDK加速的OVS實現。
您需要了解 OVS 的三個重要組件：
- 內核模塊 — 位於核心空間的元件，根據從控制元素接收的規則處理流量；
- 虛擬交換機 daemon（ovs-vswitchd）是一個在使用者空間啟動的進程，負責對核心模組進行程式設計－也就是說，它直接代表交換器的操作邏輯
- 數據庫服務器 - 位於每個執行 OVS 的主機上的本機資料庫，其中儲存配置。 SDN控制器可以使用OVSDB協定透過此模組進行通訊。
所有這些都伴隨著一組診斷和管理實用程序，例如 ovs-vsctl、ovs-appctl、ovs-ofctl 等。
目前，電信業者廣泛使用Openstack將網路功能遷移到其中，例如EPC、SBC、HLR等。有些功能可以在OVS上正常運行，但例如EPC處理用戶流量 - 然後它通過流量巨大（現在流量達到每秒數百吉比特）。 當然，透過核心空間驅動此類流量（因為轉發器預設位於此處）並不是最好的主意。 因此，OVS往往完全部署在用戶空間，利用DPDK加速技術，將流量從網路卡轉送到用戶空間，繞過核心。
注意：對於電信功能部署的雲，可以將流量從運算節點繞過 OVS 直接輸出到交換設備。 SR-IOV 和直通機制用於此目的。
這在實際佈局中如何運作？
好吧，現在讓我們進入實踐部分，看看它在實踐中是如何運作的。
首先，讓我們部署一個簡單的 Openstack 安裝。 由於我手邊沒有一套伺服器進行實驗，我們將透過虛擬機器在一台實體伺服器上組裝原型。 是的，當然，這樣的解決方案不適合商業用途，但看看 Openstack 中網路如何運作的範例，這樣的安裝就足夠養眼了。 此外，這樣的安裝對於訓練目的來說更有趣 - 因為你可以捕捉交通等。
由於我們只需要看到基本部分，因此我們不能使用多個網絡，而只能使用兩個網絡來提高所有內容，並且此佈局中的第二個網絡將專門用於訪問 undercloud 和 DNS 伺服器。 我們暫時不會涉及外部網路 - 這是另一篇大型文章的主題。
那麼，讓我們按順序開始吧。 首先，一點理論。 我們將使用 TripleO（Openstack on Openstack）安裝 Openstack。 TripleO的本質是我們一體式（即在一個節點上）安裝Openstack，稱為undercloud，然後利用已部署的Openstack的功能安裝用於運行的Openstack，稱為overcloud。 Undercloud 將利用其固有的管理實體伺服器（裸機）的能力（Ironic 專案）來配置虛擬機器管理程序，以執行運算、控制和儲存節點的角色。 也就是說，我們不使用任何第三方工具來部署Openstack——我們使用Openstack來部署Openstack。 隨著安裝的進行，它會變得更加清晰，所以我們不會就此止步並繼續前進。
注意：在本文中，為了簡單起見，我沒有對 Openstack 內部網路使用網路隔離，而是只使用一個網路來部署所有內容。 但是，網路隔離的存在或不存在並不影響解決方案的基本功能 - 一切都將與使用隔離時完全相同，但流量將在同一網路上流動。 對於商業安裝來說，自然需要使用不同vlan和介面進行隔離。 例如，ceph 儲存管理流量和資料流量本身（機器對磁碟的存取等）在隔離時使用不同的子網路（儲存管理和儲存），這允許您透過劃分此流量來使解決方案更具容錯性，例如，跨不同端口，或對不同流量使用不同的QoS 設定文件，以便資料流量不會擠壓信令流量。 在我們的例子中，它們將在同一個網路上運行，事實上這不會以任何方式限制我們。
注意：由於我們要在基於虛擬機的虛擬環境中執行虛擬機，所以首先需要啟用嵌套虛擬化。
您可以檢查巢狀虛擬化是否啟用，如下所示：
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#如果您看到字母 N，那麼我們會根據您在網路上找到的任何指南啟用對嵌套虛擬化的支持，例如 .
我們需要從虛擬機器組裝以下電路：
就我而言，為了連接未來安裝中的虛擬機（我有 7 個虛擬機，但如果您沒有大量資源，可以使用 4 個），我使用了 OpenvSwitch。 我創建了一個 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>這裡聲明了三個連接埠群組 - 兩個存取和一個中繼（DNS 伺服器需要後者，但您可以不使用它，或將其安裝在主機上 - 以對您來說更方便的方式）。 接下來，使用此模板，我們透過 virsh net-define 聲明我們的模板：
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 現在我們編輯虛擬機器管理程式連接埠配置：
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 注意：在這種情況下，連接埠 ovs-br1 上的位址將無法訪問，因為它沒有 vlan 標記。 要解決此問題，您需要發出命令 sudo ovs-vsctl set port ovs-br1 tag=100。 但是，重新啟動後，此標籤將消失（如果有人知道如何使其保持原位，我將非常感激）。 但這並不那麼重要，因為我們只在安裝過程中需要這個位址，而當Openstack完全部署時就不需要它了。
接下來，我們創建一個 undercloud 機器：
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0在安裝過程中，您設定了所有必要的參數，例如機器名稱，密碼，用戶，ntp伺服器等，您可以立即配置端口，但對於我個人來說，安裝後，透過以下方式登入機器更容易控制台並更正必要的文件。 如果您已經有現成的映像，則可以使用它，或執行我所做的操作 - 下載最小的 Centos 7 映像並使用它來安裝 VM。
安裝成功後，您應該有一個可以在其上安裝 undercloud 的虛擬機
[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
雲下安裝
我們創建一個 stack 用戶，設定密碼，將其添加到 sudoer 中，讓他能夠透過 sudo 執行 root 命令，而無需輸入密碼：
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack現在我們在主機檔案中指定完整的 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相關命令。 我使用了 Queens 版本，但你可以使用任何你喜歡的版本。
接下來，將 undercloud 設定檔複製到使用者的主目錄堆疊中：
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_主機名 — undercloud 伺服器的全名，必須與 DNS 伺服器上的項目相符
本地IP — 用於網路設定的本機 undercloud 位址
網路網關 — 相同的本機位址，在安裝 overcloud 節點期間將充當存取外界的網關，也與本地 ip 一致
undercloud_public_host — 外部 API 位址，指派來自設定網路的任何空閒位址
undercloud_admin_host 內部 API 位址，分配來自配置網路的任何空閒位址
undercloud_名稱伺服器 - DNS伺服器
產生服務證書 - 此行在目前範例中非常重要，因為如果不將其設為 false，您將在安裝過程中收到錯誤，該問題在 Red Hat bug tracker 上有描述
本機介面 網路配置中的介面。 此介面將在 undercloud 部署期間重新配置，因此您需要在 undercloud 上有兩個介面 - 一個用於存取它，第二個用於配置
本地_mtu — MTU。 由於我們有一個測試實驗室，並且我在OVS交換器的連接埠上的MTU為1500，因此需要將其設定為1450，以便封裝在VxLAN中的封包可以通過
網路位址 — 設定網路
假面舞會 — 使用NAT存取外部網絡
偽裝網絡 - 將進行 NAT 的網絡
dhcp_start — 位址池的起始位址，在 overcloud 部署期間，位址將從該位址指派給節點
dhcp_結束 — 位址池的最終位址，在 overcloud 部署期間，位址將從該位址指派給節點
檢查_iprange — 內省所需的地址池（不應與上述池重疊）
調度程序最大嘗試次數 — 嘗試安裝 overcloud 的最大次數（必須大於或等於節點數）
描述完檔案後，您可以發出部署 undercloud 的指令：
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.
#############################################################################此輸出表示您已成功安裝 undercloud，現在您可以檢查 undercloud 的狀態並繼續安裝 overcloud。
如果您查看 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現在將透過此介面進行 Overcloud 部署。
從下面的輸出您可以看到我們在一個節點上擁有所有服務：
(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網路部分的配置：
(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 ~]$Overcloud 安裝
目前我們只有 undercloud，也沒有足夠的節點來組裝 overcloud。 因此，首先我們來部署我們需要的虛擬機器。 在部署過程中，undercloud 本身會在overcloud 機器上安裝作業系統和必要的軟體- 也就是說，我們不需要完全部署機器，而只需為它創建一個磁碟（或多個磁碟）並確定其參數-即，事實上，我們得到的是一個沒有安裝作業系統的裸伺服器。
讓我們轉到包含虛擬機器磁碟的資料夾並建立所需大小的磁碟：
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G由於我們以 root 身分操作，因此我們需要更改這些磁碟的擁有者，以免出現權限問題：
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 注意：如果您不打算安裝 ceph 來研究它，那麼命令不會建立至少 3 個具有至少兩個磁碟的節點，但在範本中指示將使用虛擬磁碟 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如果您的作業系統找不到該包，請新增儲存庫：
yum install -y https://www.rdoproject.org/repos/rdo-release.rpm現在我們設定該實用程式。 這裡的一切都平庸到了恥辱的地步。 現在vbmc清單中沒有伺服器是合乎邏輯的
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# 為了讓它們出現，必須像這樣手動聲明它們：
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#我認為命令語法很清楚，無需解釋。 但是，目前我們所有的會話都處於「關閉」狀態。 為了讓它們轉換為 UP 狀態，您需要啟用它們：
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#最後一步 - 您需要修正防火牆規則（或完全停用它）：
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
現在讓我們轉到 undercloud 並檢查一切是否正常。 主機位址為192.168.255.200，在undercloud上我們在準備部署時加入了必要的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 ~]#下一步是檢查將安裝 overcloud 的節點。 為此，我們需要準備一個包含節點描述的 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注意：控制節點有兩個接口，但在這種情況下這並不重要，在本次安裝中一個就足夠了。
現在我們準備 json 檔。 我們需要指示將執行配置的連接埠的 poppy 位址、節點的參數、給它們命名並指示如何到達 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：
(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 ~]$還有一件事 - 您需要新增 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 ~]$如果一切正確，我們將發出部署 overcloud 的命令：
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemu在實際安裝中，自然會使用自訂模板，在我們的例子中，這將使過程變得非常複雜，因為模板中的每個編輯都必須解釋。 正如之前所寫，即使是簡單的安裝也足以讓我們了解它是如何運作的。
注意：在這種情況下 --libvirt-type qemu 變數是必要的，因為我們將使用巢狀虛擬化。 否則，您將無法運行虛擬機器。
現在你大約有一個小時，或者可能更多（取決於硬體的功能），你只能希望在這段時間之後你會看到以下訊息：
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$現在您已經有了一個幾乎成熟的 openstack 版本，您可以在上面進行學習、實驗等。
讓我們檢查一下一切是否正常。 在使用者的主目錄堆疊中，有兩個檔案 - 一個 stackrc（用於管理 undercloud）和第二個 overcloudrc（用於管理 overcloud）。 這些文件必須指定為來源，因為它們包含身份驗證所需的資訊。
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$我的安裝仍然需要一點小小的改動 - 在控制器上添加一條路由，因為我正在使用的機器位於不同的網路上。 為此，請前往 heat-admin 帳戶下的 control-1 並註冊路線
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254好吧，現在你可以進入地平線了。 所有資訊（地址、登入名稱和密碼）均位於檔案 /home/stack/overcloudrc 中。 最終的圖表如下所示：
順便說一句，在我們的安裝中，機器位址是透過 DHCP 發布的，正如您所看到的，它們是「隨機」發布的。 如果需要，您可以在範本中嚴格定義部署期間應將哪個位址附加到哪台電腦。
虛擬機器之間的流量如何流動？
在本文中，我們將介紹三種傳遞流量的選項
- 一個 L2 網路上的一個虛擬機器管理程式上的兩台機器
- 同一 L2 網路上不同虛擬機器管理程式上的兩台計算機
- 不同網路的兩台機器（跨網路生根）
透過外部網路存取外部的情況，使用浮動位址，以及分散式路由，我們下次會考慮，目前我們主要關注內部流量。
為了檢查一下，我們將下圖放在一起：
我們創建了 4 個虛擬機器 - 3 個位於一個 L2 網路 - net-1 上，另外 1 個位於 net-2 網路上
(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 ~]$ 路由器有兩個虛擬端口，充當網路網關：
(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 ~]$目前，該節點有三個 ovs 橋 - br-int、br-tun、br-ex。 正如我們所看到的，它們之間有一組介面。 為了便於理解，我們將所有這些介面繪製在圖表上，看看會發生什麼。
看看 VxLAN 隧道提升到的位址，可以看出，第一個隧道提升到了compute-1 (192.168.255.26)，第二個隧道提升到了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，vlan 3 中將不再有一個 L0 接口，而是多個接口。 然而，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 中所示輸出如上。
目前其他一切都與計算節點類似 - 相同的網橋，相同的隧道通往兩個計算節點。
在本文中我們不會考慮儲存節點，但為了理解，有必要說這些節點的網路部分是平庸到丟臉的地步。 在我們的例子中，只有一個分配有 IP 位址的實體連接埠 (eth0)，僅此而已。 沒有 VxLAN 隧道、隧道橋等 - 根本沒有 ovs，因為它沒有任何意義。 使用網路隔離時，該節點將有兩個介面（實體連接埠、bodny，或只是兩個VLAN - 沒關係- 這取決於你想要什麼） - 一個用於管理，第二個用於流量（寫入VM磁碟） ，從磁碟讀取等）
我們弄清楚了在沒有任何服務的情況下節點上有什麼。 現在讓我們啟動 4 個虛擬機，看看上面描述的方案如何變化——我們應該有連接埠、虛擬路由器等。
到目前為止，我們的網路如下所示：
我們在每個電腦節點上有兩台虛擬機器。 以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 ~]$ 這台機器只有一個虛擬介面 - 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 ~]$ 從輸出可以看到，網橋只有兩個介面 - tap95d96a75-a0 和 qvb95d96a75-a0。
這裡值得詳細介紹 OpenStack 中的虛擬網路設備類型：
vtap - 連接到實例 (VM) 的虛擬接口
qbr - Linux 橋接器
qvb 和 qvo - 連接到 Linux 橋和 Open vSwitch 橋的 vEth 對
br-int、br-tun、br-vlan — Open vSwitch 網橋
patch-, int-br-, phy-br- - 連接網橋的 Open vSwitch 補丁接口
qg、qr、ha、fg、sg - 虛擬設備用於連接 OVS 的開放 vSwitch 端口
正如你所理解的，如果我們在網橋中有一個 qvb95d96a75-a0 端口，它是一對 vEth，那麼某個地方就有它的對應端口，邏輯上應該稱為 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 在輸出中也可見。 這是第二個虛擬機器的連接埠。 結果，我們的圖表現在看起來像這樣：
細心的讀者應該會立即感興趣的問題 - 虛擬機器連接埠和 OVS 連接埠之間的 linux 橋是什麼？ 事實是，為了保護機器，使用了安全群組，這無非就是 iptables。 OVS 無法與 iptables 配合使用，因此發明了這個「拐杖」。 然而，它正在變得過時——在新版本中它被 conntrack 取代。
也就是說，最終該方案如下所示：
一個 L2 網路上的一個虛擬機器管理程式上的兩台機器
由於這兩台虛擬機器位於同一 L2 網路和同一管理程式上，因此它們之間的流量邏輯上將透過 br-int 在本地流動，因為兩台電腦將位於同一 VLAN 上：
[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 網路上不同虛擬機器管理程式上的兩台計算機
現在讓我們看看流量如何在同一 L2 網路上但位於不同虛擬機器管理程式上的兩台電腦之間傳輸。 老實說，不會有太大變化，只是虛擬機器管理程式之間的流量將通過 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 中有一個目標poppy：
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ 即收到的資料包會飛到連接埠3，連接埠00000003後面已經有一個虛擬機器實例-XNUMX。
部署 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*******************第一行顯示 Patek 從位址 10.0.1.85 傳送到位址 10.0.1.88（ICMP 流量），它被包裝在 vni 22 的 VxLAN 封包中，該封包從主機 192.168.255.19（compute-0）傳送到主機 192.168.255.26 .1（計算-XNUMX）。 我們可以檢查 VNI 是否與 ovs 中指定的 VNI 相符。
讓我們回到這一行 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2。 0x16 是十六進位數係統中的 vni。 我們將這個數字轉換為十進制：
16 = 6*16^0+1*16^1 = 6+16 = 22也就是說，vni對應現實。
第二行顯示返回流量，好吧，沒有必要解釋它，一切都清楚了。
不同網路的兩台機器（網間路由）
今天的最後一個案例是使用虛擬路由器在一個專案內的網路之間進行路由。 我們正在考慮沒有 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由於在這種情況下封包必須到達網關並路由到那裡，因此我們需要找出網關的 poppy 位址，為此我們查看實例中的 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 ~]$ 第三個連接埠是 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 ~]$ 流量已經到達控制節點，所以我們需要去控制節點看看路由會如何發生。
正如您所記得的，內部的控制節點看起來與計算節點完全相同 - 相同的三個網橋，只有 br-ex 有一個實體端口，節點可以透過該端口向外部發送流量。 實例的建立更改了計算節點上的配置 - Linux 橋接器、iptables 和介面被添加到節點。 網路和虛擬路由器的建立也在控制節點的配置上留下了印記。
由此可見，網關MAC位址一定在控制節點的br-int轉發表中。 讓我們檢查一下它是否存在以及它在哪裡：
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 從連接埠 qr-0c52b15f-8f 可以看到 Mac。 如果我們回到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 ~]$ 多達三份。 但從名字來看，你可以猜到每個人的用途。 稍後我們將傳回 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 ~]$ 這個命名空間包含我們先前創建的兩個內部命名空間。 兩個虛擬連接埠均已新增至 br-int 中。 讓我們檢查連接埠 qr-0c52b15f-8f 的 MAC 位址，因為根據目標 MAC 位址判斷，流量流向該介面。
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ 也就是說，在這種情況下，一切都按照標準路由的規律進行。 由於流量的目的地是主機 10.0.2.8，因此它必須透過第二個介面 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 ~]$ 一切順理成章，沒有什麼意外。 讓我們看看主機 10.0.2.8 的 poppy 位址在 br-int 哪裡可見：
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 正如預期的那樣，流量流向 br-tun，讓我們看看流量接下來進入哪個隧道：
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 流量進入隧道進行計算 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的隧道具有以下操作=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3。 讓我們將 0x16 轉換為十進位：
0x16 = 6*16^0+1*16^1 = 6+16 = 22到compute-1 的隧道具有以下VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2。 讓我們將 0x63 轉換為十進位：
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）的vxlan 封包，vni 22，其中封裝了從主機10.0.1.85 到主機10.0.2.8 資料的ICMP 資料的ICXNUMX包。 正如我們上面計算的，vni 與我們在輸出中看到的相符。
第二個封包是從主機192.168.255.15（control-1）到主機192.168.255.26（compute-1）的vxlan 封包，vni 99，其中封裝了從主機10.0.1.85 到主機10.0.2.8 的ICMP 資料包。 正如我們上面計算的，vni 與我們在輸出中看到的相符。
接下來的兩個資料包是從 10.0.2.8 而不是 10.0.1.85 返回的流量。
即最終我們得到如下的控制節點方案：
看起來就這樣了？ 我們忘了兩個命名空間：
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 當我們討論雲端平台的架構時，如果機器會自動從 DHCP 伺服器接收位址，那就太好了。 這是我們兩個網路 10.0.1.0/24 和 10.0.2.0/24 的兩個 DHCP 伺服器。
讓我們檢查一下這是否屬實。 在這個命名空間中只有一個位址 - 10.0.1.1 - DHCP 伺服器本身的位址，它也包含在 br-int 中：
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0讓我們看看控制節點上的名稱中是否有包含 qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 的進程：
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 有這樣一個過程，根據上面輸出中提供的信息，我們可以，例如，看看我們目前有什麼出租：
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$結果，我們在控制節點上得到以下一組服務：
好吧，請記住- 這只是4 台機器、2 個內部網絡和一個虛擬路由器...我們現在沒有外部網絡，一堆不同的項目，每個項目都有自己的網絡（重疊），並且我們有分散式路由器關閉，最後測試台上只有一個控制節點（為了容錯，必須有三個節點的法定人數）。 從邏輯上講，在商業中，一切都「有點」複雜，但在這個簡單的示例中，我們了解它應該如何工作- 無論您有3 個還是300 個命名空間當然很重要，但從整個操作的角度來看結構，沒有什麼會改變太多...儘管在你之前你不會插入一些供應商SDN。 但這是一個完全不同的故事。
我希望這很有趣。 如果您有任何評論/補充，或者我在某個地方完全撒了謊（我是人，我的意見總是主觀的） - 寫下需要糾正/添加的內容 - 我們將糾正/添加所有內容。
總而言之，我想談談 Openstack（包括普通版和供應商版）與 VMWare 雲端解決方案的比較 - 在過去的幾年裡，我經常被問到這個問題，坦白說，我已經厭倦了，但仍然如此。 在我看來，比較這兩種解決方案是非常困難的，但我們可以肯定地說，這兩種解決方案都有缺點，在選擇一種解決方案時需要權衡利弊。
如果OpenStack 是一個社區驅動的解決方案，那麼VMWare 就有權只做它想做的事（即對它有利可圖的事情），這是合乎邏輯的- 因為它是一家習慣於從客戶那裡賺錢的商業公司。 但有一個很大的問題 - 你可以擺脫 OpenStack，例如來自諾基亞，並且只需很少的費用即可切換到來自例如 Juniper（Contrail Cloud）的解決方案，但你不太可能擺脫 VMWare 。 對我來說，這兩個解決方案看起來像這樣——Openstack（供應商）是一個簡單的籠子，你被關在裡面，但你有一把鑰匙，你可以隨時離開。 VMWare是個金籠子，主人有籠子的鑰匙，要花很多錢。
我不會推銷第一個產品或第二個產品 - 您選擇您需要的產品。 但如果我有這樣的選擇，我會選擇兩種解決方案- 用於IT 雲端的VMWare（低負載、易於管理）、來自某個供應商的OpenStack（諾基亞和瞻博網路提供非常好的統包解決方案） - 用於電信雲端。 我不會將 Openstack 用於純粹的 IT - 這就像用大砲射麻雀，但除了冗餘之外，我沒有看到使用它的任何禁忌。 然而，在電信領域使用 VMWare 就像用福特猛禽拖運碎石 - 從外面看很漂亮，但駕駛員必須進行 10 趟而不是 XNUMX 趟。
在我看來，VMWare 最大的缺點是它的完全封閉性- 該公司不會向你提供任何有關其工作原理的信息，例如vSAN 或虛擬機管理程序內核中的內容- 它根本無法從中獲利-也就是說，你將永遠不會成為 VMWare 專家 - 如果沒有供應商支持，您就注定失敗（我經常遇到對瑣碎問題感到困惑的 VMWare 專家）。 對我來說，VMWare 正在購買引擎蓋被鎖定的汽車 - 是的，您可能有可以更換正時皮帶的專家，但只有向您出售此解決方案的人才能打開引擎蓋。 就我個人而言，我不喜歡我無法適應的解決方案。 您可能會說您可能不必深入了解。 是的，這是可能的，但是當你需要在雲端從20-30個虛擬機、40-50個網路組裝一個大型功能時，我會看看你，其中一半想要出去，另一半要求SR -IOV 加速，否則你將需要更多幾十輛這樣的汽車- 否則性能不夠。
還有其他觀點，因此只有您可以決定選擇什麼，最重要的是，您將為自己的選擇負責。 這只是我的觀點 - 一個至少見過和接觸過 4 個產品的人 - Nokia、Juniper、Red Hat 和 VMWare。 也就是說，我有可以比較的東西。
來源： www.habr.com