當前,隨著云計算技術的深入應用,企業對于混合云的應用也日漸廣泛,提到混合云,就不得不說虛擬私有云,虛擬私有云(VPC)提供了一個包含免費虛擬機(VM)使用時間的培訓項目,學生可以跟隨一位現場講師學習,而不需要花時間去安裝產品。
但是,大量的短暫存在亞馬遜云服務(AWS)虛擬機使我的主控機很難保持對它們的可靠控制。它們可能無法訪問我最喜歡的亞馬遜簡單隊列服務(SQS),使用幾百個這種服務會控制我的Elastic Compute Cloud(EC2)費用支出。
和許多很好的混合云一樣,VPC的私有地址空間已經通過AWS Direct Connect鏈接到我的數據中心,從而對外展現為單個內聚的網絡。問題是,雖然數據中心內所有系統都可以看到SQS正常工作,但是在亞馬遜EC2本身的虛擬機卻無法看到。似乎并沒有魔法般的虛擬機實例訪問權限組合可以做到這一點,盡管可以肯定它們可以自動獲得核心AWS服務的訪問權限。
這個解決方案最終會包含路由功能。在解決這個問題,我突然發現了云管理中有一個新的網絡復雜性問題。這個問題不僅存在于傳統云網絡中,也存在于現在所謂的混合加混合網絡(Hybrid-Hybrid Networks, HHN)。
混合加混合網絡(Hybrid-hybrid networks)指的是什么?
當前企業IT推崇的云應用主要是基礎架構即服務(IaaS)。實際上,IT正在將數據中心內物理機架上的服務器遷移到云中的虛擬機上。當然,我們需要保證Exchange服務器仍然能夠將授權請求轉發回到本地的Active Directory,這樣管理員才能使用AWS Direct Connect、Azure Virtual Network或其他技術創建持久鏈接。一旦完成了這一步,你就得到了一個純粹的混合云。
但是,如果你是一些真實云服務的早期采用者,如存儲、云數據庫、隊列、轉碼等,又會如何呢?如果是這樣,那么即使你的所有服務器仍然在機架中,你也已經進入云了。例如,如果你知道數據庫名稱,但是不能訪問它所在的主機,那么你只是其中一個用戶。一旦你開始將一些使用云服務的服務器遷移到云中虛擬機上,你就會遇到一種前所未有的網絡復雜性,從而制造出一些不同的東西:混合加混合云。
結果:網絡增加了而非減少了
對于早期采用者,IaaS應該不需要動太多腦筋。你的業務已經使用了很多的云服務,將大量系統遷移到混合云和IaaS上,可以更好地分配服務和用戶,從而提升服務交付質量。因此你只需要關注于最后的用戶接口問題。同時,服務器與后臺系統之間的繁重網絡流量也會得到很大的改進。可是,這個結果并不一定會如期出現。更壞的是,我們喜歡使用的調試工具可能并不支持IaaS基礎架構。(我在期盼著NetFlow的到來。)
云基礎架構的不透明性意味著你不會連接到虛擬交換機,也不會檢查訪問控制列表(ACL),而且你不會查看NetFlow或檢查防火墻配置中的原始ACL。你看不懂配置面板的內容,里面有繼承的JSON策略/角色塊和其他一些復雜信息。解決方法是回歸一下,回想以前初涉IT時候的場景。以前,高級管理員不會隨便給你root權限,因此你必須想一些辦法繞過這個問題。
首先,先記住因為所有來自同一個供應商的服務并一定位于同一個位置,否則網絡復雜性也不會成為一個問題。當這些使用云服務的應用部署在機架上時,它們會使用服務的地理路由前端。無論數據中心在什么位置,這個服務都會生成最高效的路由。如果現在決定將一個服務器遷移到位于悉尼的一個虛擬機上,那么它可能會對運行在弗吉尼亞的服務性能產生影響。確實,這里仍有一個意想不到的云網絡問題:你仍然必須用Visio畫出服務的拓撲圖。
其次,要使用手頭已有的工具。你可能無法訪問IaaS平臺的VSwitch,但是IaaS服務器仍然有操作系統和NIC,而且你可以安裝深度數據包檢測傳感器,從云服務器的角度觀察流量。
最后,你仍然在數據中心內保留VPC分界點的總體可見性,而且你想象不到的是,你會發現問題就出現在這個位置。
固化路由的一個特殊方法
在我的HHN中,我添加一些特殊的虛擬機實例角色限制,保護網絡安全性不受學生虛擬機的影響。也就是說,我將所有流量轉發回數據中心,然后我在這里通過信任的Palo Alto防火墻管理外出的互聯網請求。這通常不會成為一個問題,但是我還將AWS服務調用限制在數據中心一個特定子網中。防火墻會接收到來自這些服務的大量請求,但是它們卻來自于AWS VPC空間中一些不可信的新私有子網。防火墻會執行它的本職功能——阻擋流量。在EC2儀表析出現紅色警報之后,解決方法實際上是很簡單的。
D1Net評論:
在將虛擬機遷移到云的過程中,只需要記住關鍵點并不是考慮基礎架構。這里仍然有許多規劃和故障修復要做。固定的網絡和舊式檢測方法比以前更加重要,特別是在我們進入混合加混合加混合網絡之后。這個問題會在我們實現IPv6之前到來,同樣也不可忽視。