關於openstack的部署架構的一點兒疑問？

在open stack的官網當中看到的是Networking Option 1: Provider networks和Networking Option 2: Self-service networks這兩種模式，這兩種都是計算、控制、存儲三類節點

但是在實際我看到網路上的相關說法都說流行的部署模式是將network作為單獨的節點，很想知道這三者那一類部署效果比較好，目前沒有看明白？

按照OpenStack文檔和實際的經驗來看，一般是將節點分為四類，控制（controller node），網路（network node），計算（compute node），存儲（storage node）。這四類節點並沒有排他性，也就是說可以將四類節點部署在不同的伺服器上，也可以將四類節點部署在一個伺服器上。這裡的節點（node），可以理解成服務的集合，服務可以理解成提供功能的一個個進程。例如圖中的一個個小方塊。四類節點只是對OpenStack的所有進程做了一個分類。至於實際部署時，哪個伺服器要部署什麼進程，成為什麼節點，完全取決於你的部署規模和實際的環境。比如：

• 在我的開發環境，我是將控制，網路，計算，存儲都部署在一個虛擬機上，通常成為all-in-one。這種模式下，能部署的虛機數完全取決於我的虛機性能。
• 在微型環境，為了部署更多的虛機，會將計算節點分出去，這樣環境中就有兩類伺服器，控制節點伺服器和計算節點伺服器。這裡的控制節伺服器點包含了controller+network+storage。但是，network和storage都是數據層面的服務，它們帶來的負載本身是不可預期的，它們可能會給伺服器帶來高的負載甚至造成宕機。將它們與控制層面的controller服務放在一起，不論是佔用伺服器的資源還是宕機，都有影響controller服務的可能。而controller作為整個openstack的核心，應當儘可能保證其不受影響。題主的兩個圖都屬於controller+network的部署模式，雖然storage被分出去了，但是仍然存在上面的問題。這種部署模式只適用於前期模型驗證（POC）。
• 中小型環境，為了降低各類節點間的影響，會進一步分離，一般是將controller，network，storage，compute都單獨部署在不同的伺服器上（還會配合keepalived或者pacemaker實現一定的HA，這個就不展開了）。這個時候避免了2中的問題，數據層面的network，storage，自己負載高，那就高了，Controller仍然可以安穩掌握全局。

但是這麼做就沒問題了嗎？不一定。因為集中的網路節點帶來了單點故障（SPOF）和發卡流量（hair-pin）。如果想繼續擴大openstack集群的規模，還需要進一步改進。

• 在大型環境，單點故障和發卡流量帶來的問題尤其嚴重。為了解決這些問題，會將一部分network node功能下發到compute node伺服器。例如下圖中，採用了DVR的network node只有一個SNAT服務。其他的L3，DHCP，Metadata都放在了計算節點。在一些其他項目，例如Dragonflow，甚至可以去掉network node。VMware NSX在配合OpenStack工作的時候，也沒有network node的概念。

說了這麼多，該不該有network node，取決於部署規模和環境。所謂的流行的將network作為單獨節點部署，也只是適用於中小環境。現在的趨勢是分散式部署network服務。