惠普公司已經坦言OpenStack項目中的網絡組件仍存有不足，因此整個技術社區都需要認真反思如何在未來的工作中推動其發展完善。
作為一家企業級IT廠商，惠普公司云業務首席運營官Saar Gillai在本周二接受采訪時指出，OpenStack的“Neutron”系統之所以引發諸多問題，是因為“我們將歸結于社區的失誤”。
Neutron是OpenStack項目中的“網絡即服務”技術，它的作用在于幫助管理員創建、配置并管理軟件定義網絡體系。
該技術屬于核心項目，其穩定性對于以OpenStack為基礎構建大型基礎設施即服務云而言無疑起到了至關重要的作用。
Neutron以Quantum技術為基礎，后者則源自Nicira的開發項目。隨著Nicira被VMware所收購，該公司的員工們也在新環境下繼續對這項技術開展研發。Quantum項目的很多早期用戶將其與Nicira的“NSX”插件配合使用，二者共同構建起了Nicira公司的軟件定義網絡技術方案。
遺憾的是，一旦拋開NSX插件而獨立運作，Neutron就會帶來多種嚴重問題。
“這是惟一一個我們要求配合第三方組件共同使用的項目，”紅帽公司虛擬化業務部門產品管理負責人Andrew Cathrow解釋道。“真正的挑戰在于，Neutron的發展過程緊緊圍繞著同一家供應商，因此當人們談論Neutron時、他們在談論的實際上也正是Nicira。”
惠普在利用OpenStack技術構建自家公有云服務時也遭遇了同樣的困局。經過Gillai的證實，由于問題太過嚴重、惠普不得不被迫對OpenStack的網絡組件進行重新編寫以保證其云方案能夠正常運作。“我們在公有云體系中遭遇Neutron難題，為此我們只能在很長一段時間內與OpenStack主干保持距離，”他解釋道。時至今日，在惠普Helion項目的幫助下，該公司正嘗試以主社區品牌為核心開發出一套對網絡組件進行過修復的OpenStack發行版。
Neutron最令人抓狂的問題在于，惠普所碰到的阻礙只在大型規模環境中才會出現，因此很多僅把OpenStack用于小規模生產部署環境的使用者對這一切毫無察覺。不過隨著這一技術方案越來越多地融入到生產部署流程當中，Neutron的弊端也將變得愈發明顯，這也正是用戶在本周一OpenStack峰會用戶交流環節中不斷發出抱怨之聲的根本原因。
“其實我們每個人對此都負有責任，”Gillai指出。“我認為社區的每一位參與者都很清楚，在未來十二個月中將有大量針對這一問題的修復努力陸續展開。我們在自己的公有云方案中著實被Neutron難題困擾了好一陣子。這是個有理由也有必要被解決的問題。供應商必須作出妥協，轉而從OpenStack的角度出發并遵循其處理方式。”
Neutron的問題一方面源自其自身設計思路，另一方面也與它所接入的軟件定義網絡系統密不可分。
“我們嘗試在Neutron中為大量商用軟件定義網絡方案提供支持，”Piston Cloud Computing公司首席技術官Joshua McKenty在接受采訪時解釋稱。“從理論角度講，‘難道單單只有Neutron中的開放vSwitch表現得糟糕透頂？’——事實上，即使是那些商用方案也并沒有達到原本的預期效果。”
問題在于，目前社區“主要著眼于網絡技術七層基礎結構中最為光鮮顯眼的四層”，McKenty表示。
“我認為在未來十二個月中，Neutron將變得越來越好，”Gillai斷言。“沒錯，我也同意Neutron存在巨大問題。從某種程度上講，大家甚至可以將其視為危害項目使用的罪魁禍首。經過一整天的討論，客戶已經提供了充足的反饋意見，而我們的任務則是將其修復。”
Gillai的觀點與紅帽的意見可謂不謀而合。“我們已經收集到生態系統內各家供應商對此作出的反饋，”紅帽公司的Cathrow指出。“我認為Neutron的未來發展形勢還是比較樂觀的。”
從各個角度來看，Neutron的失敗與復蘇計劃需要一大前提作為配合，即OpenStack項目必須被視為一個整體。由于該項目在起步階段作出了太多承諾，發展時期又高度依賴供應商的實際表現，因此只有當各主導方正視其薄弱環節時、問題才有可能得到解決。隨著OpenStack社區從實踐活動中逐步吸取經驗教訓，他們在技術方案中犯下的失誤也將越來越少，這一切最終將幫助各供應商拿出一套真正能夠吸引電信及其它企業用戶、且具備可行性的云操作系統。
“我們必須重新審視過去，并從項目發展軌道中積累經驗，我相信這些結論已經為各供應商所理解與采納，”Cathrow表示。“畢竟我們每個人都是決策后果的承擔者。”
京公網安備 11010502049343號