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