混合雲管理問題，你解決了麼？

騰訊織雲發表於2019-03-04

本文由黃浩宇發表於騰訊織雲公眾號

背景

近幾年隨著“網際網路+”,“雲+”等概念的出現，雲化服務日益成熟，市場上湧入大量的企業開始將自身的服務雲化，如中小型網際網路企業，傳統企業，金融企業等。但是完整的雲化不是一個短期就能快速實現的目標，特別對於一些龐大的傳統企業，或一些對資料安全高度敏感的金融企業，市場提出了一個新的需求：混合雲方案。

混合雲方案指融合公有云和私有云等多種雲環境的服務管理解決方案，包括管理多種公有云環境、自建的國內外IDC私有云環境。而混合雲管理平臺需要提供的能力包含統一CMDB資產管理、統一的伺服器密碼管理、統一的變更釋出、資料遷移、跨雲容災、監控等。

所有的操作類能力全都依賴於底層的平臺命令通道和雲廠商的介面對接，該文章將介紹織雲是如何建設和使用命令通道解決混合雲的伺服器管理問題。

混合雲管理的問題

“客戶虐我千百遍，我待客戶如初戀！”

TOB和TOC最大的不同在於TOB的客戶就是上帝，而且上帝有很多個性化的問題和需求。在織雲命令通道設計的時候參考了很多織雲實際客戶的問題和場景，總結下主要有以下幾點問題：

1. 網路複雜度

混合雲最大的問題之一就是網路複雜度，不同客戶可能購買了不同的公有云，有些搭建了自己的IDC，甚至有些在一個雲環境裡還搭建了多個私有子網，所以往往會遇到叢集網路不通，叢集之間網路不通，網路上行和下行只有一邊通，安全策略限制，通訊協議限制等。

2. 網路頻寬

有客戶搭建了海外IDC，海外IDC只能通過香港，走寬頻很小的公網訪問回國內，當客戶需要對目標叢集做資料遷移或釋出一個大的檔案包時，寬頻將是最大的限制。

3. 伺服器多樣性

有些傳統企業使用Windows 2000+ubuntu 12.04,14.04,16.04+定製的centos……由於客戶伺服器種類比較多，對底層通道的相容性要求非常高。

4. 需求靈活性

客戶往往有多種不同的個性化需求，例如有客戶需要監控tomcat，寫java的客戶需要定時監控java的gc，採集指定的業務日誌等，所以在設計底層通道的agent時，需要有足夠的靈活性。

解決方案

在設計方案之前，參考過比較熱門的開源軟體，如saltstack、ansible、puppet等；以及市場上同型別管理平臺。都非常優秀，而且各有優點，但無法滿足客戶和織雲的需求，在此不多做對比。

1. 網路複雜度

A) 使用Master+Proxy+Agent模型
Agent通過Proxy與Master通訊，使用者只需要給1~N臺能與Master通訊的伺服器即可，這是目前最有效且相容性最好的管理方式。當Agent啟動時Agent主動連線Master，握手成功之後與Master保持長連線，該方式對客戶的網路要求較低而且安全，只要Proxy能主動訪問公網Master即可。

B) Proxy支援橫向和縱向擴充套件

Proxy橫向擴充套件主要為了容災，當某Proxy連不上時，Agent嘗試使用剩餘Proxy；

縱向擴充套件解決使用者子網深度，例如海外客戶：泰國->香港->織雲。

C) 使用HTTP/HTTP2.0做為通訊協議

幾年前做運維的時候體驗過私有協議在某些使用者網路的相容性痛苦，深切認識到HTTP應該是目前相容性最高的應用層通訊協議。但為了安全起見，使用HTTP2.0（基於HTTPS）做為通訊協議。

協議相容性切換，當HTTP2.0連不上Master時，嘗試切換為HTTP短連線做輪詢。

D) 支援SSH協議下發

Proxy+Aent需要客戶環境到織雲Master的上行網路，但如果有客戶只支援下行網路，命令通道還需要支援Master通過SSH協議訪問到客戶叢集的Proxy（優先使用Proxy-Agent模式）

2. 網路頻寬

A) 採用“CDN”模型

做為混合雲管理，變更釋出是一項高頻操作，釋出本質上是檔案分發的問題，有著資源熱點的特性，所以採用CDN模型是比較合適的模型。

織雲CDN源節點能提供檔案分片能力，同時在Proxy節點上部署快取元件，任一檔案分片只要經過Proxy節點的快取將會在Proxy上快取一段時間，這樣釋出的資料檔案只會經過一次公網，大大節約了頻寬。

B) CDN+P2P架構

CDN方案解決了寬頻限制問題，但如果目標叢集有大量的伺服器且需要分發一個很大檔案包時，Proxy的寬頻將會是瓶頸。

思路是採用P2P模型做資料分享，提高檔案分發效率，P2P有幾種模型，如中心化拓撲模型，DHT網路模型，全分散式非結構化拓撲模型，半分散式拓撲模型。考慮到如果在客戶環境採用類DHT搜尋會給客戶網路造成大量的額外資料搜尋，織雲採用中心化拓撲模型，由Proxy做為源seeder和tracker，結合上上面的A方案，最終檔案分發模型類似如下：