寫在前面，出於保護客戶隱私和堅守網工的職業道德素養，本文不得出現的所有完整ip、客戶名稱、信息、以及詳細的業務模型闡述。最近確實走心的在分享案例，2017年5月21日在家裏寫了近四小時，女票已經暴走，請大家掩護我！！！！！

——————Allen

項目背景：

客戶要在國外上一套業務系統，並接入國內用戶，開展國內和國際的業務。

關鍵點1：因公司註冊地在海外，也就是說主體不在國內，無法完成國內網安備案這件事情

關鍵點2：即業務系統不可涉及到國內域名解析

關鍵點3：國內互聯網出口與國際互聯網出口的需從架構是進行剝離，意味著存在雙出口。這直接會導致web和DB的物理（這一點若大家不是很明白為何這樣講，歡迎大家建群討論，這裏不展開探討）

關鍵點4：國內一塊區域、國際一塊區域，中間訪問與傳輸如何解決？客戶要求必須達到企業級專線水準（丟包千分之三的水平）

關鍵點5：針對海外特殊的點，例如日本、新加坡、英國、美國進行特殊的路徑優化。

項目第一次邏輯網絡拓撲圖：

項目第一次討論提供的設備清單（和諧過）：

1. 思科防火墻（ASA-5515系列）

2. 華三交換機（S5500-EI系列）

3. 負載均衡（軟件級）

4. 服務器（惠普、戴爾都有）

5. 存儲（惠普），另外還有一臺磁帶機

6. 光纖交換機（Brocade）

項目經過：（希望大家感同身受的去感覺下我當時的狀態）

按照慣例，我作為架構師的角色兼任項目交付的PM角色前往客戶現場與客戶進行為期長達20+天的溝通與相關技術確認，期間也不得不出差到北京、深圳、香港。

這裏重點聊幾個裏程碑的事件。第一次與客戶的會面，我們在自己公司總部進行了長達兩個小時的會面與討論，包含但不僅限商務洽談、公司資質介紹、技術難點、最佳實踐案例分享。

在此次會議中，我是最後進入會議的一名“工程師”的角色參與的此次會議，（這是極其不禮貌的事情，不過我巧妙的化解了此次不禮貌的行為），因為即將會議結束，我就沒發名片直接進入了個人提問和展開的討論。提了四問：

哪四問？大家往下看。

第一問：您這邊對於高可用故障切換過程中，會話級層面的實時切換的控制到哪一個等級？有沒有針對TCP的長連接的會話保持要求？負載均衡在程序上做的是四層還是七層、還是四層+七層？

註釋：我這裏一上來問這些，主要是要分清在場會議中的客戶側有哪些角色，並哪些占主要？這樣有利於我直擊客戶的“痛點”，或者說是“興奮點”。

第二問：您提供的邏輯網絡拓撲，物理機櫃拓撲，我都看了，但根據以往的經驗和實踐的情況看，有存在不少資源上的空置情況，（隨後我走到投影區域，分別進行了講解）

第三問：您這邊提供的設備清單，我關註了下您的網絡設備選型以及在采購明細備註中的內容，因為您關註業務的連續性，那即意味著所有硬件節點均是高可用才是，但在您的采購清單中未看到firewall的高可用license和switch的專用堆疊電纜，往往這些license或可能比一臺設備都貴，您若已經選型定好，您勿忘叮囑采購的同事關註下，避免預算被打回重做。

第四問：我這裏有與您業務極其相似的客戶實踐案例（包括了售後運維的各個情況說明），我這裏投出來分享給各位，看看是否有哪些可以參考的地方？（隨後我把自己整理的一份最佳實踐的案例PPT分享給了客戶，此時客戶表示非常有興趣，也想看看自己的架構是不是可能存在什麽問題？）

隨後，我簡單的分享了一個我們具體做過的一個案例，然後就沒再多講（記住，做工程師並不是搞定對方技術主管這麽簡單，更重要的是要用一個非技術語言的方式闡述給對方的運營者去聽去理解，然後有點情商的去處理任何一個環節），然後我關閉了分享PPT，總結說：“因為是第一次溝通，我也是比較表面的去理解了您這邊的情況，所以有哪些地方說錯了，您這邊多體諒。”隨後我轉過頭來和此次會議的主持人（銷售）大聲的說：“我們下一次會議在什麽時候？”~~~~~~~~~~~~~~~~~~會議結束後，銷售給予我反饋，客戶對我分享的內容非常感興趣，下一次溝通我們定在下周三，地點北京（望京SOHO）。

至此，這裏第一次溝通結束了，在次日，我將基於第一次“過於表面”的理解的分析報告匯總成了PPT，發送給了甲方。以下，我展示幾頁有關於技術的。

結合如上的一些分析與之前客戶提供的拓撲，我進行了三個版本的visio的整合和梳理優化，這裏share給大家最終提供給客戶的拓撲（已和諧）：

寫在前面，除之前提到的問題全部優化妥善解決後。為客戶帶來的價值優勢新增如下：（首次分析重點，請大家仔細品位和研讀，我費了不少腦子，出於實際，技術完全可落地）

• 三個area完全環網並可以通過部署高敏捷檢測機制實現毫秒級切換實現應用服務備用網關尋址持續提供對外服務，並設置對應routing policy，並部署ipsec-vpn or P2P gre overipsec依托公網進行冗余線路部署，實現災難發生時的應對方案

• 前置area與APP area流量可經過內網墻也可以通過明細routing policy使不經過internal-firewall，避免流量數據多次被firewall拆解封裝影響，既而造成網內無用流量增多，應用轉發效率低下

• DB area 與 APP area實現完全分離的，若internal-firewall外掛特征庫查詢機制，可實現基於特征的調用級層的訪問控制。

• 新增monitor（基於KVM資源利用），完全獨立使用一套公網（BGP），實現內網應用、硬件、中間件、DB的明細監控與alert，並接入wechat企業賬號，實現告警完全移動化，減輕運維人力方面的投入，遠程運維團隊實時接收告警real-time響應

• 若IDC存在大量不可預見性的擴容，通過此次infra的架構部署優化，可以更好進行適應性部署，無需進行“大手術”，完全平行擴展。但建議邊界設備在項目首期上線前一定選擇基於當前業務量的3-5倍容量去選型，方可實現無縫升級

時間悄然的到了第二周去北京的路上，這裏還是要秀一下網工對時間重視，一路上，我們和倆位同事討論了很久此次項目上的問題，然後打開電腦記錄了許久，直至夜裏23:53分到達了北京。

次日，客戶如約到達了我們北京的分公司地點，我們開始了第二次的討論和對接，並在會議室接觸了客戶業務系統的軟件提供商。自此我們就確認了項目已八九成單了。

~~~技術討論這裏省略，不過應軟件商要求，我們再次對visio的網絡拓撲圖進行了修改，如下所示（已和諧）：

註釋：大家註意仔細觀察區域和區域之間為什麽都過了防火墻，至於為什麽這麽鏈接，一定是他的考慮。這裏就不詳細的闡述了。

這一次的整合拓撲發出後，我和軟件商側再次產生了很多架構設計上的分歧，討論了很久，這期間客戶也為我們協調了好幾次，不過最後結果是好的。大家都認同了這樣的部署，所以在看此文的讀者記住，技術討論不可涉及人情味道，一旦涉及，你就無法保證你的方案是完整、可擴展性強的。只有激烈的討論，技術的創新才能出來，這裏也吐槽一句，在國內做售前、做架構。很難純粹的做技術。相反國外就會好很多，我不是說國外的技術牛，我只是表達國內的關系型銷售越來越多的侵蝕著很多需要專註、專業、嚴肅的行業。

第二次的拓撲整合，我這裏不share給大家，因為涉及到了客戶信息，大家理解下。

項目的最關鍵的階段來了，設備選型的敲定和采購。我參與了此次網絡設備型號的推薦建議。並提交給了客戶。可是最後因為種種原因，我和軟件商提供的方案都打了極大的折扣，這意味著我們雙方的公司需要承擔甲方業務連續性-不可用的風險和責任。所以，這個時候我們站在技術的角度再次將打完折扣後的方案進行了完整的討論和風險告知！

PS：大家在做售前咨詢的時候，一定要註意風險告知！！！這一點不說，就會成為未來甲方不認可你很重要的一個點。若讀者有同行的話，應該都明白，甲方很痛恨那種問題一次性不說清楚，遇到一個說一個的乙方。所以大家一定要謹記在心，我就入過坑。

項目中的方案折扣：

思科ASA的failover許可證不購買，采用雙物理防火墻，不同outside對外提供服務的方式部署

PS：oh myladygaga！！！！

好了，不扯其他的，接著說本文最最最最最最最精華的技術分析篇幅，大家別拿磚頭砸我，我只是想讓大家更好的進入角色，設身處地的去體會我在此次項目中扮演的角色和如何處理技術與非技術問題的應對行為，這樣大家即學到了技術，又get到了技能。又得到了一個技術案例，多耐心的讀一點何樂而不為呢？：）

方案遭遇了打折，技術遭遇了挑戰，這一點對於很多純售前工程師相當的頭疼，因為是當場提出來的挑戰，若沒有經歷幾年售後詳細的技術支持和心得總結，很難在這樣的情況下應對自如。恰好，這個就是我個人的優勢，我本身就是項目交付的主要負責人之一，那對於網絡的細節把控上還算是“及格”的，所以場面一度被我hold住，進行非常詳細技術細節討論，並在會議結束後，我輸出了這樣一份報告。

什麽報告呢？容我一一的上傳給大家解釋（已和諧），我的分析與考慮，往下看。

圖解：

紅色直線為此次項目中，正常流量的訪問路徑走向

綠色直線為此次項目中，failover後的訪問路徑走向

註意，我這裏的firewall是沒有HA部署，所以中間沒有直連線，但我曾考慮過，是否直連起來，內網跑個動態或者靜態，使故障的流量路徑有這樣的切換選擇。

分析：

當我把圖畫出來後，立刻就否定了這個方案，因為GW在交換機上，若要達到路徑繞行，上層就會涉及全路由環境。而對於故障側（左邊）防火墻來講，下遊的接入inside一定是掛了nat模式，若要強行這麽做，做nat 0豁免也是可以，但這一定程度上加大了配置設計的難度和維護難度，同樣對於右側的防火墻，就會有雙inside口，所以這樣做非常不理智。

補充一個前提：

這裏的firewall上聯故障後（被DDOS、網線損壞、硬件故障），切換都是在程序上做的，對於程序來講，他自身即可實現雙鏈路進入，即：程序上就有（主備）的概念，同時結合應用心跳的檢測機制，即完成了異常實時自動將用戶訪問重新reload即可，即：客戶重新login下即可。

分析：

目前在邊界firewall上沒有實現平滑HA高可用切換的話，遇到的挑戰非常大，但是我和我的團隊還是想到了解決辦法，雖然效果不理想，但結合程序和基本的路由檢測技術，完成因硬件故障導致的故障，且需要將路由進行人工或手工切換事情，全部都自動化了。

大家在我以往的文章中，都應該明白HA的檢測機制常見的都是檢測端口的up/down，好一點的帶源檢測一個IP，或者一個協議。但我們常見的做法都是檢測物理端口，因為你檢測GW，很有可能你的服務提供商把GW做了ICMP保護，延遲不定時丟。檢測某一個信任的IP地址，你又沒辦法保證，中間任一一個節點的割接升級優化不影響你。更狗血的是，對端若維護不通知你，那就尷尬了。

所以這裏想了一個辦法，利用思科一個非常老的技術，解決了此次方案中檢測和切換的問題——思科IOS IP SLA，如果大家需要了解，可以跳轉到鴻鵠，有一篇帖子講的非常詳細鏈接如下：

http://bbs.hh010.com/thread-109542-1-1.html

解決問題需要的技術：

1. IP SLA

2. 浮動靜態路由

備註：簡單的技術，靈活用，這才是網工存在的意義，不要天天喊大二層VPLS、MPLS、各種高端技術，能落地且使用的方案才是好方案！！！

接著講思路：

——通過三層交換機部署 IP SLA的技術檢測防火墻outside口的IP

Allen：我們檢測該outside的接口ip，相當於實現了HA中檢測端口UP/DOWN，因為接口donw了，接口協議就down了，ip自然就ping不通了。

——通過寫浮動靜態路由，優先級低的先指到右邊的主角色-firewall上，優先級高的指到右邊備角色-firewall上，配合IP SLA + TRACK

Allen：通過在優先級低路由後面掛Track聯動IP SLA檢測，我們就可以實現非直連鏈路的檢測和切換，這樣就成功的化解了此次技術的挑戰。

不過這裏要多嘮叨一句，高可用部署並非像我上面利用簡單的技術解決而達到的效果，這裏切記，高可用實現的不是僅僅是切換聯動，還有RTO會話的和session狀態的同步，HA在整個拓撲設計上，在上層是一個整體，並非兩臺獨立的物理形式存在。

所以，你在遇到我這樣的類似的案例的時候，切記，如果你核心交換機與防火墻對接你沒用浮動靜態，而是等價路由，就會出現如下問題：

分析：

服務器向上的流量，就會被均分到上聯兩臺防火墻上，（交換機不維持會話，且防火墻並沒有部署HA，RTO沒有會話保存），所以路由層面的等價後，這樣就會導致，TCP三次握手出現問題，當恰好走到備角色上後，防火墻一定作Drop的action處理，因為它就沒有會話，怎麽會得到一個ACK+1的會話呢！！。雖然在客戶使用的程序上做了主備訪問的路徑處理，但是GW它就是不管，所以大家還是要註意下，這樣類似源進源出的問題。

思科配置截圖如下：

Lab_R2811_rack1(config)#iproute 0.0.0.0 0.0.0.0 10.19.1.1 ?

<1-255> Distance metric for this route

name Specify name of the next hop

permanent permanent route

tag Set tag for this route

track Install route depending on tracked item

<cr>

華為配置截圖如下：

[Lab_2204S_rack1]iproute-static 0.0.0.0 0.0.0.0 10.19.1.1 track ?

bfd-session Specify BFD session

efm-state Specify tracked ETHOAM state interface

nqa Specify NQA test instance

備註：實現檢測的技術並聯動路由有很多（BFD/TRACK/IP SLA），大家多看看技術手冊，多學習！！詳細的配置我就不曬了，大家多花點時間去理解原理，去由衷的探討，這才是我的希望大家做的。

寫在最後，這個案例我在本文中只寫了網絡部分，當然也有相當多的存儲和光纖以及虛擬化的技術挑戰，因為這一塊畢竟不是自己的想法，我搬出來寫就相當於抄襲，所以我在本文中只寫了自己的思考和總結，當然，我個人的能力是有限的，其實回過頭來看看，漏洞也是有的，不過這就是博客的有意義的地方，等過了三五個月，我再回來看的時候，我就知道我的成長在哪裏了。

近期我個人接觸了很多代理商的負責人，因為個人工作的關系，我們對每一個產商的產品線以及特色產品都需要非常的了解，所以這就迎來了很多測試樣機。後面我會用用戶體驗的角度去分析目前送過來的樣機體驗分享文章，希望大家期待一下。我也趁這個機會，平行的對比下各個產商的產品的特點，加油！

雖然這個項目是我（PM）全棧負責完成，但各個我不懂的部分都是同事傾力幫忙分析和提出的解決方案。所以這裏贊一下我的同事：

小雞（尚未開通）、登鋒（http://2183517.blog.51cto.com/）、文浩（尚未開通）

PS：未來他們也會在CTO上更多去描述自己的所負責的案例中的Part，本著專業的職業操守和信息保護的狀態。祝大家521歡樂

對於這篇文章，僅代表我個人觀點，若存在問題，大家及時回復即可。

我的初心一直是這樣，我在嘗試著真誠地描述自己遇到的問題和解決經歷。

——————來自一個正處於人生轉折點的網工Allen

QQ:549675970

QZONE:http://user.qzone.qq.com/549675970

E-mail：

[email protected]

[email protected]

人生格言：越努力、越幸運

本文出自 “Allen在路上-從零到壹” 博客，轉載請與作者聯系！

記一次完整的安全技術解決方案遭遇成本考驗後的“退步與博弈”