您好，我叫 Kostya Kramlikh，是 Yandex.Cloud 虛擬私有云部門的首席開發人員。 我是一名虛擬網絡人員，正如您可能猜到的那樣，在本文中我將總體討論虛擬私有云 (VPC) 設備，特別是虛擬網絡。 您還將了解為什麼我們（服務的開發人員）重視用戶的反饋。 但首先要說的是。
什麼是專有網絡？
如今，部署服務有多種選擇。 我確信有人仍然將服務器放在管理員辦公桌下，儘管我希望這樣的故事少一些。
現在服務都在嘗試走向公有云，這就是它們與VPC發生衝突的地方。 VPC 是公共雲的一部分，它將用戶、基礎設施、平台和其他功能連接在一起，無論它們位於我們的雲中還是雲外。 同時，VPC 允許您不必將這些容量暴露到 Internet，它們保留在您的隔離網絡中。
從外部看，虛擬網絡是什麼樣的？
對於VPC，我們主要指的是覆蓋網絡和網絡服務，例如VPNaaS、NATaas、LBaas等。所有這些都工作在容錯網絡基礎設施之上，該基礎設施已經 在這裡，關於哈布雷。
讓我們仔細看看虛擬網絡及其設備。
考慮兩個可用區。 我們提供一個虛擬網絡——我們稱之為VPC。 事實上，它定義了“灰色”地址的唯一性空間。 在每個虛擬網絡中，您可以完全控制可分配給計算資源的地址空間。
該網絡是全球性的。 同時，它以稱為子網的實體的形式投影到每個可用區域上。 對於每個子網，您分配一個大小為 16 或更小的 CIDR。 每個可用區中可以有多個這樣的實體，並且它們之間始終存在透明路由。 這意味著同一 VPC 中的所有資源都可以相互“對話”，即使它們位於不同的可用區。 無需訪問互聯網，通過我們的內部渠道進行“交流”，“認為”他們在同一個專用網絡內。
上圖顯示了一種典型情況：兩個 VPC 在地址中的某處相交。 兩者都可以是你的。 例如，一個用於開發，另一個用於測試。 可能只是有不同的用戶 - 在這種情況下這並不重要。 每個 VPC 中插入一台虛擬機。
讓我們讓這個計劃變得更糟。 您可以使一台虛擬機同時陷入多個子網。 不僅如此，而且在不同的虛擬網絡中。
同時，如果需要將機器暴露到互聯網上，可以通過API或UI來完成。 為此，您需要將“灰色”（內部地址）的 NAT 轉換配置為“白色”（公共）。 您不能選擇“白色”地址，它是從我們的地址池中隨機分配的。 一旦您停止使用外部 IP，它就會返回到池中。 您只需為使用“白色”地址的時間付費。
還可以使用 NAT 實例讓計算機訪問 Internet。 您可以通過靜態路由表將流量路由到實例。 我們提供了這樣一個案例，因為用戶有時需要它，我們也知道。 因此，我們的鏡像目錄包含一個專門配置的 NAT 鏡像。
但即使有現成的 NAT 映像，設置也可能很棘手。 我們知道，對於某些用戶來說，這不是最方便的選擇，因此最終我們可以一鍵為所需子網啟用 NAT。 此功能仍處於封閉預覽訪問狀態，在社區成員的幫助下進行測試。
從內部看虛擬網絡是如何安排的
用戶如何與虛擬網絡交互？ 網絡通過其 API 向外看。 用戶訪問 API 並使用目標狀態。 通過API，用戶可以看到一切應該如何安排和配置，同時他可以看到狀態，以及實際狀態與期望狀態的差異有多大。 這是用戶的照片。 裡面發生了什麼？
我們將所需的狀態寫入 Yandex 數據庫並配置 VPC 的不同部分。 Yandex.Cloud 中的覆蓋網絡基於 OpenContrail 的選定組件，最近被稱為 Tungsten Fabric。 網絡服務在單個 CloudGate 平台上實施。 在 CloudGate 中，我們還使用了許多開源組件：GoBGP（用於訪問控制信息）以及 VPP（用於實現在 DPDK 之上運行的數據路徑軟件路由器）。
Tungsten Fabric 通過 GoBGP 與 CloudGate 進行通信。 告訴覆蓋網絡中發生了什麼。 反過來，CloudGate 將覆蓋網絡相互連接並與互聯網連接。
現在讓我們看看虛擬網絡如何解決可擴展性和可用性問題。 讓我們考慮一個簡單的例子。 可用區XNUMX個，其中創建XNUMX個VPC。 我們部署了一個 Tungsten Fabric 實例，它拉動了數万個網絡。 網絡與 CloudGate 通信。 正如我們已經說過的，CloudGate 確保它們之間以及與互聯網的連接。
假設添加了第二個可用區。 它應該完全獨立於第一個而失敗。 因此，在第二個可用區中，我們必須安裝一個單獨的Tungsten Fabric實例。 這將是一個處理覆蓋層的獨立系統，並且對第一個系統知之甚少。 事實上，我們的虛擬網絡的全球可見性創建了我們的 VPC API。 這是他的任務。
如果可用區B中有資源推送到VPC1，則VPC1映射到可用區B。 如果可用區 B 中沒有來自 VPC2 的資源，我們不會在該可用區中物化 VPC2。 反過來，由於 VPC3 的資源僅存在於 B 區，因此 VPC3 不存在於 A 區。一切都很簡單，符合邏輯。
讓我們更深入地了解 Y.Cloud 中的特定主機是如何工作的。 我要注意的主要一點是所有主機的排列方式都是相同的。 我們確保只有必要的最少服務在硬件上運行，其餘所有服務都在虛擬機上運行。 我們在基礎設施服務的基礎上構建高階服務，同時也利用雲來解決一些工程問題，比如在持續集成的框架內。
如果我們查看特定的主機，我們可以看到主機操作系統上運行著三個組件：
- 計算——負責在主機上分配計算資源的部分。
- VRouter 是 Tungsten Fabric 的一部分，用於組織覆蓋層，也就是說，它通過底層隧道傳輸數據包。
- VDisk 是存儲虛擬化塊。
此外，在虛擬機中推出服務：雲基礎設施服務、平台服務和客戶能力。 客戶能力和平台服務始終通過VRouter進行疊加。
基礎設施服務可以嵌入覆蓋層，但基本上它們希望在底層工作。 在 SR-IOV 的幫助下，它們被插入墊層中。 事實上，我們把卡切割成虛擬網卡（虛擬功能），推入基礎設施虛擬機中，這樣就不會損失性能。 例如，相同的 CloudGate 作為這些基礎設施虛擬機之一啟動。
現在我們已經描述了虛擬網絡的全局任務和雲的基本組件的結構，讓我們看看虛擬網絡的不同部分到底是如何相互作用的。
我們在系統中區分了三個層：
- 配置平面 - 設置系統的目標狀態。 這是用戶通過 API 進行配置的內容。
- 控制平面 - 提供用戶定義的語義，即將數據平面狀態變為用戶在配置平面中描述的狀態。
- 數據平面——直接處理用戶的數據包。
正如我上面所說，這一切都始於用戶或內部平台服務來到 API 並描述某個目標狀態這一事實。
該狀態立即寫入 Yandex 數據庫，通過 API 返回異步操作 ID，並啟動我們的內部機制以返回用戶想要的狀態。 配置任務轉到 SDN 控制器並告訴 Tungsten Fabric 在覆蓋層中做什麼。 例如，它們保留端口、虛擬網絡等。
Tungsten Fabric 中的配置平面將所需的狀態發送到控制平面。 通過它，配置平面與主機進行通信，告訴它們很快將會運行什麼。
現在讓我們看看系統在主機上的樣子。 虛擬機有一個插入 VRouter 的網絡適配器。 VRouter 是一個核心 Tungsten Fabric 模塊，用於查看數據包。 如果某個包已經存在流程，則模塊將對其進行處理。 如果沒有流量，模塊會執行所謂的 punting，即將數據包發送到 usermod 進程。 該進程解析數據包並自行響應（如 DHCP 和 DNS），或者告訴 VRouter 如何處理它。 之後，VRouter 即可處理該數據包。
此外，同一虛擬網絡內的虛擬機之間的流量是透明的，不會定向到 CloudGate。 部署虛擬機的主機之間直接通信。 它們對流量進行隧道傳輸並通過底層相互轉發。
控制平面通過 BGP 在可用區域之間相互通信，就像與另一個路由器一樣。 它們告訴哪些機器在哪裡，以便一個區域中的虛擬機可以直接與其他虛擬機通信。
控制平面與 CloudGate 進行通信。 同樣，它報告虛擬機在何處、哪些虛擬機被啟動，以及它們擁有哪些地址。 這允許您將外部流量和來自平衡器的流量引導至它們。
離開 VPC 的流量到達 CloudGate，到達數據路徑，帶有我們插件的 VPP 很快就會被消耗殆盡。 然後，流量被發送到其他 VPC 或外部，發送到通過 CloudGate 本身的控制平面配置的邊界路由器。
近期計劃
如果我們用幾句話總結上面所說的一切，我們可以說 Yandex.Cloud 中的 VPC 解決了兩個重要任務：
- 提供不同客戶端之間的隔離。
- 將資源、基礎設施、平台服務、其他雲和本地部署整合到一個網絡中。
而為了很好地解決這些問題，就需要在內部架構層面提供可擴展性和容錯性，而VPC就是這麼做的。
逐漸地，VPC 獲得了功能，我們實現了新功能，我們嘗試在用戶便利性方面進行改進。 感謝我們社區的成員，一些想法得到了表達並被列入優先列表。
目前，我們近期的計劃清單如下：
- VPN 即服務。
- 私有 DNS 實例是用於通過預配置的 DNS 服務器快速設置虛擬機的映像。
- DNS 即服務。
- 內部負載平衡器。
- 添加“白色”IP 地址而不重新創建虛擬機。
應用戶的要求，平衡器和為已創建的虛擬機切換 IP 地址的功能已在此列表中。 老實說，如果沒有明確的反饋，我們可能會稍後才承擔這些功能。 所以我們已經在解決地址問題了。
最初，“白色”IP 地址只能在創建機器時添加。 如果用戶忘記執行此操作，則必須重新創建虛擬機。 同樣，如有必要，刪除外部 IP。 很快就可以打開和關閉公共 IP，而無需重新創建機器。
隨意表達你的 其他用戶。 您幫助我們改進云並更快地獲得重要且有用的功能！
來源： www.habr.com