在向SDDC轉移的時候，要把你的傳統設備搬上大臺，需要花費大量的時間和仔細的研究。在移動數據中心時，要記住哪些策略呢?
SDDC: 是對數據中心所有的物理、硬件的資源進行虛擬化、軟件化的一種技術。SDDC依賴于虛擬化和云計算技術， SDDC的目標是虛擬化數據中心的一切物理資源，通過虛擬化的技術，構建一個由虛擬資源組成的資源池，不僅是對服務器進行虛擬化，還包括存儲虛擬化和網絡虛擬化等。不僅可以簡化服務器更改、存儲更改、網絡配置的難度，更使得對服務器、存儲、網絡的管理和配置操作具備可重復性和持續性。
SDDC使硬件資源可以通過軟件進行配置和調度，提高了靈活性和敏捷性，帶來的一個顯著優勢就是大大降低了數據中心的成本。通過SDDC提供的集中式的軟件管理層，管理變得更簡單。同時SDDC讓軟件來管理網絡，讓網絡成為數據中心的一部分，專有的網絡可以大幅提高硬件的效率，由此可見軟件的重要性不可小視。軟件定義的數據中心，將成為數據中心演進的一個新的方向和趨勢。
因此，當你已經決定著手構建或向SDDC(軟件定義的數據中心)過度的時候，你需要考慮一些問題。例如，當你此刻走在數據中心的熱通道上，也許會讓你感到沮喪。你應該如何處理數據中心內現有的設備以及運行在它們上面的應用程序呢?唯一的回答就是：就像信息技術中的大多數東西一樣——是“這要看當時的情況”。
對于移動數據中心，要考慮兩個基本的模型:第一,在某種形式的轉換階段中,并行地運行舊的和新的，或者將您現有設備與新的SDDC集成在一起。第二，將現有網絡設備集成到獨立數據中心內，錯了，不是集中到一個，是兩個，要么集成在pod層，要么集成在現有設備內運行SDDC的頂層。
第一模型，是并行地運行舊的和新的數據中心，這個看起來可能更簡單，甚至是這樣理想的情況。但即使是在理想情況下，也有一些問題需要解決。工作負載是否會在數據中心之間進行轉換?如果是這樣，這將如何發生?當然，這個問題的答案很大程度上取決于應用本身。在這個領域有還幾個重要的問題要問。
新的數據中心架構如何滿足每個特定應用程序的要求? 考慮通常考慮的問題是重要的，例如帶寬利用率、延遲、抖動(Jitter是由確定性內容和高斯(隨機)內容組成的。所謂jitter就是一種抖動。具體如何解釋呢?其定義延遲從來源地址將要發送到目標地址，會發生不一樣的延遲，這樣的延遲變動是jitter。)等需求。 但考慮到域名系統，大象流量的動態管理，安全域的創建，覆蓋網絡等因素的存在也是很重要的。
備注：大象流量 (elephant flows)：在計算機網絡中，大象流量是通過在網絡鏈路上測量的TCP(或其他協議)流量建立的非常大的(總字節數)連續流量。大象流量雖然不是很多，但在一段時間內可占據總帶寬的不成比例的份額。目前還不清楚是誰創造了“大象流”，但是這個詞在2001年發表的互聯網網絡研究中開始發生，當時觀察到，少量流量承載大部分互聯網流量，剩余流量包含大量流量這些網絡流量很小(鼠標流量)。例如，研究人員Mori et al，研究了幾個日本大學和研究網絡的交通流量。在WIDE網絡中，他們發現大象流量僅占所有流量的4.7%，但在這段時間內占據了所有數據傳輸量的41.3%。
大象流量對互聯網流量的實際影響仍然是一個研究和爭論的領域。一些研究表明，大象流量可能與交通高峰和其他大象流量高度相關。大象流量在研究人員中有不同的定義，包括流量在一段時間內占據總流量的1%以上，測量流量的持續時間，并觀察流量的大小大于平均值加上在此期間交通的標準偏差。大象流研究的主要目標之一是開發更高效的帶寬管理工具和互聯網的預測模型。例如，研究人員專注于通過對大象流量進行優先排序來為小尺寸(小流量)的流量提供更好的服務質量。
即使在最初的設計階段，最好能夠避免一些與數據中心提供后期服務相關的技術層面的問題，事實上，在這個過程中，總還是會有一些遺漏的問題。
由于有很少應用程序開發人員知道應用程序都在依賴哪些服務，或者在執行此類清單過程中做出無效假設，因此，起碼，他們都不會有完整的庫存。因此，當你第1天開始著手規劃移動數據中心時，就需要制定明確的行動計劃。
假設在新數據中心里，能提供各種所需服務，但如果將這項標準作為制定計劃的基準，則很容易導致非常糟糕的結果。 假設應用程序開發人員需要修改或更新應用程序來解決其中的一些問題的時候，而不能將問題的全部重點放在網絡工程團隊上，而是需要放在解決應用程序本身的問題上。
應用程序將決定數據中心連接方式
在兩種架構并行運行的時候，需要在它們之間建立某種形式的連接 - 數據中心互連(DCI)。 應用需求將決定一些DCI的方式，比如是否需要進行以太網上連接，或者更簡單的支持IP或路由連接。
DCI (data center interconnect)互聯方式：分為三層互聯，也稱為數據中心前端網絡互聯，所謂“前端網絡”是指數據中心面向企業園區網或企業廣域網的出口。不同數據中心(主中心、災備中心)的前端網絡通過IP技術實現互聯，園區或分支的客戶端通過前端網絡訪問各數據中心。當主數據中心發生災難時，前端網絡將實現快速收斂，客戶端通過訪問災備中心以保障業務連續性;網絡二層互聯。也稱為數據中心服務器網絡互聯。在不同的數據中心服務器網絡接入層，構建一個跨數據中心的大二層網絡(VLAN)，以滿足服務器集群或虛擬機動態遷移等場景對二層網絡接入的需求; SAN互聯。也稱為后端存儲網絡互聯。借助傳輸技術(DWDM、SDH等)實現主中心和災備中心間磁盤陣列的數據復制。
這里面臨的挑戰與其他任何數據中心面臨的DCI挑戰是相似的，SDDC系統將能支持之前更多的限制與期望。
第二種解決方案是將SDDC和現有設備集成在POD層，這是一項不同的挑戰。 這個想法如下所示。
將SDDC設備集成在原有設備
如果不需要為了提高系統的恢復能力，連接數據中心，(事實上，在大多數現代網絡中不可能)，這種類型的解決方案可以從上面的列表中刪除一個挑戰：DCI。
另一個優點是它允許您使用canaries探測 - 即模擬 - 隨著時間的推移測試針對單個應用程序的SDDC設計方法。 在這種情況下，探測技術將涉及并行運行兩個基礎設施，將應用程序從遺留基礎轉移到SDDC來評估它們，如果它們在新環境中正常運行則將其留在那里。
備注：Canaries，要監測對函數棧的破壞，需要修改函數棧的組織，在緩沖區和控制信息(如EBP等)間插入一個canaryword。這樣，當緩沖區被溢出時，組返回地址被覆蓋之前canaryword會首先被覆蓋。通過檢查canary word的值是否被修改，就可以判斷是否發生了溢出攻擊。
這實際上是大多數超級、或網絡規模的運營商向新基礎設施過渡的方式。
然而，它增加了復雜性的一個新的要素：SDDC如何控制系統與對現有的控制如何相互影響? 事實上，流量必須從較新的SDDC POD中抽取到舊式硬件設備中，然后再返回。
如果沒有什么流量工程、安全和其他政策需求，這可能就像在兩個控制層之間重新分配路由信息一樣簡單。如果移動數據中心需要包含跨越兩個域的安全區域，或者某種形式的動態流量塑造，那么這里的問題可能非常復雜。
備注：流量工程是指根據各種數據業務流量的特性選取傳輸路徑的處理過程。流量工程用于平衡網絡中的不同交換機、路由器以及鏈路之間的負載。流量工程在復雜的網絡環境中，控制不同的業務流走不同的路徑，關鍵的業務走可靠的路徑并保證服務質量，并且在某段網絡擁塞的情況下，動態調整路由，整個網絡如同一個“可控的城市交通系統”。流量工程理念在上世紀90年代末提出，最初起源于互聯網。其原理是在MPLS環境中，充分利用標簽交換系統來為不同的業務流著色，通過LDP來傳遞LSP中間鏈路網絡狀態，不同顏色的業務流，根據不同的網絡中間狀態，動態地在網絡中間傳遞，并且LSP能夠傳遞RSVP網絡控制信令，因此可以實現端到端的QoS或Diff-Service服務。流量工程用于平衡網絡中的不同交換機、路由器以及鏈路之間的負載。ISP通過流量工程可以在保證網絡運行高效、可靠的同時，對網絡資源的利用率與流量特性加以優化，從而便于對網絡實施有效的監測管理措施。應該說，流量工程早就該進入主流應用階段了。但可惜的是，國內電信部門互聯網采用流量工程的寥寥無幾，行業和企業網中應用更是一片空白。究其原因，實際網絡環境達不到其要求的理想環境，實施復雜。
最可能的情況是某種形式的再分配，以及在兩個操作區域之間沿邊緣的手動或自動調整。
這樣的安排往往是簡單的開始，但也往往會結束復雜的，比預期耗費更多的資源。 如果這是選擇的遷移路徑，最好是將應用程序從一個環境推送到另一個環境。 這種方法降低了兩個環境之間交互表面的深度與廣度。
將SDDC作為覆蓋網絡運行
本文開頭提到的最后一個選項是將SDDC集成到現有設備之上運行。這可能是由SDDC供應商銷售的最常見的策略，因為它允許SDDC將現有設備用于其控制和管理平面。 這也可以看起來是一個簡單的答案，但是復雜性往往可以很快地發揮出來。
SDDC作為疊加
一般的想法是使用SDDC的強大功能來替換舊設備，隨著時間的推移，使用現有設備作為SDDC的物理層的功能。
這種情況應該與SDDC環境中隨著時間的推移正常的設備生命周期沒有什么不同。 為此，相同的工具和流程應該從第1天開始適用，直到SDDC正在替換的傳統設備從服務中移除。 但是最初的設備組合不能像SDDC的要求那樣匹配任何未來的采購，可能導致幾個問題。
在物理層，設備是否支持SDDC所需的南向接口? 例如，如果SDDC要求某個級別的OpenFlowsupport(如1.3)正常運行，那么所有現有的傳統設備是否都支持此級別的操作? 如果供應商聲稱支持，它是否已經過測試? 要知道，現有的所有設備必須在新的環境下重新驗證。
在控制層上，SDDC覆蓋將如何與現有的控制平面相互作用，將現有的設備連接在一起，并將流量從一個部分傳輸到另一個部分? 現有控制層的所有功能(包括哪些工具和功能已建成)都可以集成到SDDC疊加層中?
如果現有的控制層是某種旨在向網絡提供API的結構覆蓋而不是運行更傳統的分布式協議的設備(例如IS-IS或邊界網關協議。)
管理方法增加復雜性
系統從控制到管理方面，問題都不少。 現有網絡中的每個設備都被設計為以特定方式進行管理。 有的可能只有管理信息庫接口; 其他人可能只有命令行界面; 其他人可能使用一組YANG模型的RESTful接口; 而且，其他人可能通過GRPC界面進行最好的管理。
SDDC能否從所有設備中獲取信息，并將配置推到這個范圍廣泛的接口中?你會得到什么數據，你會失去什么?這是另一個需要廣泛測試和驗證的領域，特別是針對未來的需求。永遠不要指望“在我們需要這個功能之前，硬件將會被取代”。考慮一下你的應用程序在未來可能遇到的有限功能的障礙，以及這對你的業務意味著什么。
一個并行的問題是能夠快速故障排除和解決問題的能力——修復網絡的平均時間與總體可用性直接相關，這是網絡在支持業務方面的有效性的關鍵度量。
在這種情況下，允許您查看網絡狀況，以便在問題影響操作之前解決問題，并快速發現影響操作的問題。 檢查當前用于快速恢復服務的流程與SDDC疊加的功能是非常重要的，以確定哪里可能存在差距。
也許通過SDDC轉換最難管理的傳統設備之一是基于設備的防火墻。 雖然廣泛部署以在架構內創建安全區域，并將架構內的區域與無區域隔離，但基于設備的防火墻很可能是有效管理的最困難的設備。
在現有設備之上疊加SDDC將挑戰基于設備的防火墻，其中包括隧道封裝，動態策略和其他難以解決的問題。 在覆蓋模型中，安全需要完全重新考慮，包括將安全區從現有的基于設備的防火墻遷移到由SDDC系統本身提供的其他技術。
將數據中心移動到一個SDDC可以隨著時間的推移建立一個更清潔的網絡，并有許多新的選擇來構建和管理一個滿足業務需要的網絡。然而，將現有設備轉換為SDDC環境所需要的中間步驟可能是復雜的。在移動數據中心時，網絡運營商需要考慮這些挑戰，并仔細規劃它們
京公網安備 11010502049343號