對于OpenStack用戶來說，隨著開源云平臺的持續演進，可擴展性仍然是一個大問題。Openstack的目標是啟用并且運維大規模的云集群，但是在實現這一愿景的過程中，仍然有一些不足之處。通常來說，在小型測試沙箱里正常工作的東西要想超越早期生產環境并且進入大規模運維時都會遇到很多的困難。

[[173413]]

增加Openstack的可擴展性并不容易。對于初學者，很多針對Openstack的供應商的插件和工具都不是可擴展的，而其他一些供應商能夠提供有助于可擴展性的合適工具，但是同時會引入供應商鎖死的風險。

分解OpenStack可擴展性難題

網絡似乎是OpenStack可擴展性問題的核心所在，OpenStack的Neutron模塊僅能夠擴展到30個左右的節點。公有云上的競爭對手已經能夠在數千臺服務器上運行成千上萬臺VM，這一限制對于考慮OpenStack的企業客戶而言是能不能繼續OpenStack方案的關鍵點。

Neutron問題的一部分在于OpenStack Nove核心模塊所支持的網絡模型。該模型限制了集群規模，并且給構建和銷毀VLAN增加了延時。這樣的結果對于沙箱來說足夠好，但是對于生產環境所需的擴展能力就是個大問題。

一些OpenStack的合作伙伴，包括Mirantis 和 Hewlett Packard Enterprise，已經提出了一些可能的方案。但是軟件定義網絡承諾將軟件價值添加到廉價的，使用普通硬件的白盒交換機上也是剛剛面世，提供了和Mirantis以及其他OpenStack合作伙伴競爭的解決方案。

如果你想購買更加復雜的平臺，比如供應商管理的OpenStack版本，一定要確保這個供應商有能力在很多服務器機架上擴展網絡。

垂直自擴展，或者使用更多VM——使用OpenStack Heat模塊進行擴展時也有很多問題。Ceilometer模塊監控VM里的工作負載，并且觸發Heat自動擴展或者調整VM的個數。不幸的是，有很多OpenStack的版本，還有更多的專有工具，并且在很多情況下，都丟失了一些主流模塊。通常沒有Ceilometer，而是使用自定義的監控引擎。OpenStack的廣泛用例幾乎可以保證這樣的交互一定有很多問題。這里唯一的解決方案是耐心，等到Ceilometer更大范圍部署之時。

負載均衡也有類似的問題。Neutron作為服務提供負載均衡，Heat全面支持這一點。但是，一些版本，沒有這個特性，需要考慮其他方案。GitHub上的開源的HAProxy項目是一種可能的解決方案。

[[173414]]

解決OpenStack網絡問題

當面臨OpenStack可擴展性時，有更多的高級網絡運維也都很困難。比如，連接虛擬網絡的功能會變成噩夢。驗證連接并不容易，在外部連接功能上，比如防火墻，則有可能會丟失鏈接。要想把一個新服務插入到服務鏈里也很困難;IT團隊需要銷毀服務鏈并且從頭重新構建。

啟動風暴——這個詞來源于VDI里的boot風暴，如果連接斷開隨后修復時可能就會發生。重新連接數千個節點，使用緩慢的加密流程以及分發代理，需要花費大量的時間。

當面臨OpenStack可擴展性時，這些來源于Nova，以及Keystone安全的網絡問題，可能會成為瓶頸。小心調優Nova能夠有效減少這樣的問題，并且加速網絡搭建的運維。比如，IT團隊能夠增加NOVA API和處理節點的數量來移除鏈接創建中的瓶頸。還可以使用OpenContrail來解決一些Neutron的問題，這是一個高效的，低消耗的分發網絡服務的平臺。

隨著OpenStack組件的演化，OpenStack的可擴展性和其他挑戰已經在持續升溫。閱讀博客和文章了解***狀態，并且記住開源云的總體優勢非常大，但是演進是一個大問題。