圖 3.3: Ceph 與 OpenStack 關係圖
所有虛擬機與外部網路的流量，但這意味著一旦 nova-network 服務停止或機器離線維 修，所有使用者即與虛擬機立刻失去聯繫。High Availability(HA) Option 就是為了避免 單點錯誤 (SPOF) 即造成整個 OpenStack 的虛擬機網路完全癱瘓所設計的模式。由圖 3.4上的三個實體節點所示，每個運算節點 (Compute Worker) 除了安裝啟動虛擬機必要 的 nova-compute 服務之外，我們也安裝了 nova-network 服務來開啟 HA Option，讓每個 虛擬機的網路直接利用宿主機轉送出去，如此就不會因為一台機器的停擺而造成所有 虛擬機的網路中斷。另外，metadata-api 也是因應這種模式下而需要每一台運算節點都 安裝的服務，詳情請參考 4.3節的 Metadata API 子小節。
除此之外，為了提高系統安全性，以及實際使用情形的限制，我們建立了一種名為 部分 HA(PHA) 的網路模式。在此環境之下，我們延用了舊有的 HA 模式，並讓每一台 運算節點都只有私有 IP，讓使用者依照專案需求再動態的綁定公開 IP 到運算節點上，
若日後運算節點的數量一多，可以替單位裏原本就不夠多的 IPv4 省下可觀的消耗，也 避免了外部網路可以直接連線到運算節點的風險。
表 3.1顯示了三種虛擬機網路模式的優缺點。沒有使用 HA 模式的網路模式下，擁有 最多單點錯誤的風險，而傳統的 HA 模式又似乎已趨近完美，不但不需要額外的 NAT 主機，而且也避免了所有單點錯誤的情形，但唯一美中不足的是，他需要大量的公開 IP 供運算節點使用。相較之下，我們的 PHA 模式就符合大部分的使用者需求。
圖 3.5顯示了從專案角度來看待虛擬機的網路架構。一般來說，擁有公開 IP 的虛擬 機通常為整個專案 cluster 的進入點，也常常是專案裡負責對外提供服務的重要機器，
圖 3.4: 虛擬機網路互動關係圖 (Provider View)
在 PHA 模式下這種機器的流量可直接經由運算節點傳送到網路上的實體 Gateway，確 保高度可用性；另一方面，由於虛擬機與宿主機的網路卡互相以橋接 (bridge) 模式相 連，可視為在同一個實體網路下，所以同專案虛擬機之間的網路流量皆是經由實體交 換器來轉送，也不會有單點錯誤的問題；所以在我們的 PHA 模式下，我們節省了大量 的公開 IP，讓運算節點以及那些沒有公開 IP 的虛擬機一樣，在有對外連線需求時改用 NAT 主機，而這樣的需求通常是在更新系統套件，或是需要對外連線的時候，而這種 情形相較之下是比較不重要，也不常發生的。
此外，由於 OpenStack 在做虛擬機動態遷移時，需要儘量使來源端與目的端的 運算節點的相關設定保持一致，其中一點是必須讓運算節點上的 VNC 服務聆聽在 0.0.0.0(vncserver_listen=0.0.0.0)[8]，這樣做是為了避免虛擬機遷移之後，VNC 服務無法 使用原本的 IP 而造成遷移失敗。可是這樣的設定在傳統 HA 網路模式上會造成 VNC 服 務的暴露；反觀我們的 PHA 模式的網路架構，卻可以很好的支援這個需求。因為運算 節點上並沒有公開 IP，外部網路無法直接存取 VNC 服務，至於那些擁有浮動 IP 的運算 節點，所有存取浮動 IP 的連線皆會被導入虛擬機上，也無法存取到 VNC 服務，進而提 供了比傳統 HA 網路模式更好的安全性。
因此我們使用這種 PHA 模式，必要的時候也可以與傳統 HA 模式混合使用，以符合
SPOF Another NAT Server
Public IP per Host
Service Exposure
傳統 無 HA
fixed IP inner flow ! (dhcp flow)
V (Network Host) fixed IP outbound flow V
w/ floating IP V
傳統 HA
fixed IP inner flow
V V
fixed IP outbound flow w/ floating IP
PHA
fixed IP inner flow
fixed IP outbound flow V V w/ floating IP
Table 3.1: 傳統、傳統 HA 模式以及 PHA 模式的網路架構比較表
實際需求，具體做法會在 4.2.4小節－ Compute Worker 安裝步驟之後介紹。
圖 3.5: P-HA 網路模式下的三種使用情況：(1) 同專案的虛擬機之間的網路流量。(2) 沒有公開 IP 的虛擬機往 Internet 的流量需經過 NAT。(3) 有公開 IP 的虛擬機可直接與 Gateway 溝通。