軟體定義資料中心設計應集中於可擴充套件性和整合性

通過軟體來控制任何東西的能力是軟體定義資料中心吸引人的地方，不過，可擴充套件性、整合性和其他的考慮因素也應該成為設計SDDC(Software-Defined Data Center)的一部分。

當在設計一個軟體定義資料中心時，企業需要考慮的因素很多，包含整合和自動化。在部署的每一步都需要對業務的需求有深入的瞭解，並且知道需要克服哪些財務的障礙。

有一些企業可能會想通過一個供應商來完成軟體定義資料中心(SDDC)的搭建，但這是不可能的。但是如果去考察其他企業的SDDC架構——特別是大型雲服務供應商——對決定你的需求程度和決定最有利的基礎架構型別是有一定的幫助的。

SDDC設計所考慮的軟體

SDDC的關鍵特徵是通過軟體來控制各個方面的能力。這相比物理的基礎架構變更或者手動控制流程更加靈活。SDDC可以讓負載工作在物理基礎架構之上獨立地執行。它還允許將基礎架構管理和負載管理進行分離，兩個平面都可以通過程式進行控制，而不是人為的直接操作。比如說一個負載策略可以在現有的web伺服器超過一定閾值後增加web伺服器的數量來平衡負載。基礎架構策略可以是對一個感染的hypervisors部署一個安全補丁。這些策略以及一些自動化的工具的推出，推動著SDDC的發展。

人們容易認為整個SDDC——或者至少從軟體方面——應該都來自一個單一的廠商。事實上沒有一個廠家能夠提供SDDC中的所有部件，並且也肯定不會有統一的產品。舉個例子，VMware`s vRealize Automation (vRA) 套件包含了很多基礎架構的元件，但是卻沒有能力成為持續整合/持續開發(CI/CD)的工具。如果你去問你的程式設計師，他們會告訴你CI/CD系統是SDDC架構裡面很關鍵的一部分。VRA也不是設計來更新你物理伺服器的韌體或者儲存陣列內固態硬碟的微碼的。這就是SDDC是由不同的廠商組成的原因。這並不是一件壞的事情，不過這會讓SDDC的設計變得更加複雜。

SDDC設計的整合關鍵

觀察一下大規模的雲提供商，你會發現要建立包羅永珍的SDDC是可以達成的。這些雲提供商不會從單一廠家購買他們的基礎架構，他們會從不同的廠家處購買部件並且進行組裝來滿足自己的需求。大多數大型雲提供商都有自己的開發團隊來做不同元件的整合。想象一下如果所有元件都做了整合，那麼你可以在數分鐘內部署一個VM例項，並且將其連線到正確的內部和外部網路中去——這些都可以從自服務的入口網站、一些指令碼命令或者一些應用程式程式設計介面(API)呼叫來達成。從財務的角度想象一下要建立這種級別的SDDC需要多少成本，建立一個大型SDDC架構費用是高昂的，但是回報也會非常大。

對於一個企業來說，這種規模的整合並不一定是必須的。首先，很多產品都內建了自動化的工具，你只需要簡單地將他們整合在一起就可以了。大多數企業公司有自己的基礎架構標準，因此他們不需要對不同的元件進行整合。而且，你的SDDC規模也不會像公有云提供商一樣那麼大。企業可以指定某一些整合方式來滿足自己的商業需求。而云提供商在這方面則要支援客戶所需要的所有整合的場景。

在設計SDDC的時候，你會期待將一些元件進行整合，例如終端使用者的門戶、伺服器硬體、軟體定義網路和軟體定義儲存。這也是API發揮作用的地方，它會讓一個SDDC元件與另一個元件進行整合。可以使用流行的Rest API來將一些指令碼繫結到你經常使用的指令碼語言中。可以為你的產品尋找一些有API、繫結或者理想的整合模板。

在設計SDDC中一個比較關鍵的考慮因素是去定義你的視野範圍。通常來說SDDC最有價值的地方在於能快速變化你的環境(比方說生產環境和測試環境)。你可以將首次部署排除生產環境來減少一些風險。一旦開發/測試環境已經被驗證並且學到了相關的經驗，那麼可以讓生產環境介入。如果你的企業不是通過敏捷或者DevOps方法來進行軟體開發的話，那麼CI/CD系統是沒有價值的，這種情況下部署自服務、非生產的VM平臺就足夠了。

本文作者：Alastair Cooke

來源：51CTO