謝聲濤：金融行業的網絡應用分析
原創【51CTO.com獨家特稿】編者按：本文為2009年首屆網絡分析技術大會的現場實錄，演講嘉賓為資深網絡分析技術專家謝聲濤先生。謝先生在大會上為我們詳細講解了金融行業的網絡應用分析等問題。
金融行業在這幾年發展特別快，特別是隨著進瑞行業做數據大集中，相繼在上海和北京做了數據中心，網商銀行這個業務發展也是非常快的，相信在座各位都有使用過網上銀行或者網上交易相關的經驗，網商銀行現在是非常方便的，不用跑到營業場所排隊，站上一個小時，才能做相關的交易，網上銀行和證券、第三方存款、期貨等所有相關都是和銀行有密切的關系，新業務系統也是快速增加，以前最早的業務系統，大家知道在銀行存款和取款，沒有其他的業務。
除此之外關聯的業務系統有三百個，所有都是廣域網，都是B/S架構和C/S架構，都是非常復雜的，這是對網絡和業務系統非常有壓力，因為數據大集中之后，對廣域網或者說對所有的網絡穩定運行要求是非常高的，針對這個業務系統發生故障的時候，我們要有一個快速響應的辦法，同時要有一個實時的監控，對應用系統應用性能和實時監控有著有效的預警系統日趨緊迫。對網絡管理的要求也要求越來越高，而且現在管理越來越復雜，因為網絡規模是越來越大，中間有管理和分支機構，在數據中心也劃分了多個區域，比如說網銀區和外聯區域，比如和人行或者外管局、期貨商、證券商相關聯的業務系統等各個區域越來越大，關鍵的網絡應用也越來越多，現在有兩百多套應用系統，重要的系統只有三四十套，這些都關于銀行重要的生命線。網絡用戶越來越多，原來只是分行，包括網絡用戶，像大的銀行，網銀用戶一天大概有一百多玩火者說相關的交易量，數據量都是特別大的。像分支機構，我們經常可以碰到響應時間特別慢，不響應，過上一分鐘又恢復了，還有病毒攻擊等。我們內部采用比較復雜的應用結構，比如IP、三層架構，多層網絡拓撲下的應用性能做一個監控。廣域網上網銀對B2B和B2C的交易應用需要對應用性能進行監控，對帶寬管理和廣域網管理，我們需要有一個有效的規劃，因為現在銀行廣域網一些大的銀行向電信和網通租費都是五六億，降低成本，實行高精度化的管理，我們需要有效的利用廣域網能夠盡量節省帶寬，能夠降低一些無效的流量。
應用是多重數據，比如數據、語音、視頻，因為各個銀行業有好多電話銀行和呼叫中心，這些呼叫中心實際上并不是在一個地方，它可能是分散在多個地方，比如說像上海，有的可能在成都，有的在蘭州，有的人在蘇州，甚至是八個呼叫中心，但是后臺語音的管理系統只有一套，就在數據中心，所有的數據都走聚合廣域網線路，上到數據中心進行處理，這個就需要有一個非常有效的監控。IT故障業務，我們需要流量規劃、管理，從被動到主動的管理模式，以及我們需要IT和業務的架構適當改變，又要適應網絡的發展。最終的目標是要能夠保證性能能夠在客戶不被影響情況下快速解決問題，減少MTTR。
案例分析：網絡拓撲圖。實際上是兩個數據中心，桐城數據網，通過萬兆城域網進行關聯，在每一個數據中心里頭，分了多個區域，這只是其中一個區域，也是三層的架構，在每一層交換機之間都有防火墻，還有負載均衡設備，客戶端在另外一個數據中心。業務系統運行異常，服務器剛完成一次運維變更操作，交易成功率約為70%，并且失敗的交易都發生在同一服務器上，發生問題的地方：網絡設備、防火墻、均衡負載、服務器、系統配置，無法確認問題發生的所在。
我們還需要在服務器前端裝設備，也需要進行采集。首先先看AF防火墻和AP SW1之間，為什么抓這個數據，進行前端數據捕獲，到底異常是什么樣的異常？同時有三個數據包是異常的，這三個數據包都是針對前面的序列號做得對比。看到這個應用的時候，我不知道大家對均衡負載設備工作原理也有相當的了解，也就是說，所有客戶端，比如訪問到均衡負載設備，均衡負載設備把數據流做相應的算法處理，分給兩個服務器，服務器做了響應的響應之后，數據給負載均衡設備，負載均衡設備給客戶端做相互的處理，也就是說咱們在這個點上看到的數據，看到兩個地址，經常出現的102.10說明是有異常的，這個異常體現在幾個地方，我們就需要分析，有可能是負載均衡設備異常，數據并沒有做地址轉換，或者說我們的服務器交換機上面端口處理出現了問題，需要看看在服務器前端的數據。
大家一定要注意的目標源地址和FW1地址。我們再看一看正常的交易，和10正常的交易，并不是所有交易都失敗，是70%，即使在10失敗，也是50%的失敗率，肯定有正常的交易，正常交易的過程是什么樣子的，這時候我們可以對照交換機，我們和網管員對照。失敗交易地址是什么呢？我們查了一下，相當于服務器交換機網關，也就是說服務器配得末端網關，為什么會出現這個問題呢？正常情況下，所有數據都給F5設備，出現這個問題就出現在服務器配置，我們再聯系前面服務器操作重啟，導致配置的路由信息出現了異常，出現了雙路由的情況出現，最后我們讓系統管理員自己查主機的IP地址，最后確認確實因為最后一次變更重啟導致主機出現雙路由，正常的數據流進來客戶端到負載均衡再到服務器再到給均衡負載設備，然后再到客戶端，這是完整的過程。
因為108.10存在兩條，致使交易數據和路徑負載均衡，負載均衡到服務器，服務器直接由交換機網關傳給客戶端，導致這個鏈建立失敗，最后導致交易失敗，實際上這就是運維過程中配置信息管理不嚴格，導致重啟之后變更操作使交易失敗，最后把路由器改了，交易恢復正常。案例二現象描述。應用架構為WEB AP DB三層體系。高峰期時交易受到影響。WEB服務器上存在大量的CLOSE WAIT狀態的TCP會話，而AP服務器存在大量的FIN WAIT 2狀態的TCP會話。系統剛完成版本升級。發生問題的地方：服務器、系統配置。
我們也是看一下WEB和AP，防火墻控制時間是不是有一些限制，最后導致應用不正常。在TCP正常終止對應的狀態圖，在主動關閉這一端發出第一個命令時由1轉為2，接收端在收到時，轉到CLOESED狀態。接收端這邊收到之后，變成CLOSE WAT。WEB服務器存在大量的CLOSE WAIT狀態的TCP繪畫，而AP服務器存在大量的FIN WAIT 2狀態。TCP正常終止時的數據76.98，是Web服務器，7.92是AP服務器，異常的時候77.92由AP服務器發出，發生斷裂之前，IP服務器有一個主動的延遲31秒，我們問過應用部門，他們判斷說，由服務器在斷裂之前超過30秒沒有數據傳遞的話，將由AP服務器主動發起斷裂，客戶端Web服務器發出下一個命令的時候，中間間隔時間是200多毫秒，我們只原則其中一個鏈，最長四百多秒。兩百多秒導致AP服務器保持兩百多秒狀態，Web也保持了一定的時間。假設在業務量高峰期間，這個鏈正常可能是只有高低端只有十個用戶，代表AP服務器足夠資源給其他的連接分配，但是如果說是高峰期達到兩百甚至上千個用戶的時候，這個時候會導致AP服務器再也沒有足夠的資源供Web服務器使用，這就是交易量下降的原因。
最后再回到斷裂的異常，剛才我們看到的是，斷裂的時候由Web發出斷裂都是正常的結束，AP服務器發出斷裂的話，全部都是異常的，最后由應用部門主動追溯調用哪些程序，發現調用APR結束上面有一些問題，也就是說Web情況下不會發生斷裂，部分情況會發生斷裂，是由AP服務器發出斷裂，就會造成長時間掛在上面，最終他們修改了ATI接口，調整為Web服務器強制發起斷裂，這樣的話，所有的現象就全部消失了，業務恢復了正常。
案例三：利用Sniffer解決某銀行信用卡業務網絡故障。大家都有刷卡購物的經歷，也就是說大家拿著銀行卡在POS刷卡，最后付帳，我不知道大家對信用卡網絡有多少了解？商場POS機有建行、工行、農行，所有的POS都是通過電話線連到后面的POS PAD，可以看作POS的哈比，早期使用XL25網絡，通過這個網絡連到網控設備，網口設備也是比較特殊的，可以看成是路由器，上面有多塊管理網卡，簡稱CID卡，后面有LET卡。網控做什么網絡，把數據轉成以太網數據。
信用卡網絡故障描述：商場POS通過POS PAD連接X.25網絡。IBM主機通過以太網與網控連接，進入X.25網絡。銀行信用卡業務與貸計卡業務通過以上網絡進行處理。因更新POS程序，造成信用卡在商場刷卡時可以進行消費，但無法完成批上送消費結算。同時，貸計卡消費完全正常。有一筆應用完全正常，有一筆應用是失敗交易，我們采取兩個點來看，分別在網控前端和后端，廣域網和局域網都做數據捕獲，信用卡結算數據有可能是丟失，有可能數據到POS前端沒有發送，或者數據有可能在網控階段沒有往后臺IBM主機發送，也可能修改程序導致數據異常。
成功的交易，廣域網的數據，數據包108個字節，HDLC數據包頭2字節，X.25數據包頭3字節，PAD封裝交易數據105字節。貸計卡在后端130.25.1.193是LET的IP地址，目標是130.25.01.10是主機地址。信用卡成功的交易，因為信用卡交易并不是完全失敗，包頭是133個字節，PAD去掉2個字節，X.25包頭數據是3字節，PAD封裝交易數據是128個字節，里頭有一個偏移位，數據封裝分成兩個，交易數據總廠178個字節，大于128字節，X.25協議規定進行分組傳遞，這個協議規定128個字節包，超過128字節就必須分包，分成兩個包進行傳遞。信用卡交易失敗的數據，在廣域網數據是什么樣子的？133個字節，128個字節的封裝，在應用層看到，信用卡交易結算總包長就是128個字節，X.25網絡中正好是一個分組的數據，廣域網在以太網數據傳輸，數據到網控，并沒有往后臺以太網數據傳送，所以交易失敗了。只有交易包的長度128字節時才會出現問題，大于或者小于都是很正常的，我們更新了POS程序，信用卡交易批量傳輸長度是128個，該長度是固定的，不會隨交易金額變化而變化。可能故障的原因，X.25網絡規定大于128字節的數據應分組，如果說這個數據正好是128字節處于臨界值，X.25通信設備再處理上存在偏差。也就是說，POS PAD也就是說在收到POS傳送來的128字節長度數據包時，認為該數據不需要分組，直接組裝成一個X.25數據包往網控發送。網控收到POS PAD傳送來的128字節長度的數據包進行處理時，認為該數據包不符合規定，不向主機繼續傳送。解決方法：比較復雜的就是調整通信參數，找運營商調整參數，把峰值調整一下。再一個把程序修改一下，數據包增加填充位，使之大于128字節，強調數據包分組。最后我們采取的方法就是第一種簡單的方法，強制填充5、6位數據，讓它大于128，強制分組，使業務恢復正常。
前面幾個案例大概總結一下，現在的網絡越來越復雜，我們在做分析過程中，不僅僅對網絡拓撲結構有相當的了解，對應用架構也有一些基礎的知識，這樣的話在做分析過程中，才能夠舉重若輕，才能得心應手。
【51CTO.com獨家特稿，轉載請注明出處】
【編輯推薦】
