搭建緩存服務器解流量問題（下）

文/趙永明

搭建緩存服務器解流量問題（下）

文/趙永明

第三次配置，實現集群化。全hash的集群是為解決超大規模的CDN設計的，因此只有在必要的情況下才需要啟用全Cluster集群模式，普通情況下采用Cluster集群模式來提高管理效率。

在搭建集群前，首先需要確認每個節點環境相同。

1.安裝的系統是相同的：

發行版本相同，如都是CentOS 5.5；

內核版本相同，如都是2.6.18-194.17.1.el5；

ARCH相同，如都是x86_64。

2.使用的TS版本是相同的，如用同一個rpm包安裝。

3.各個系統的硬件是相同的，避免因為單個機器的資源不均衡造成服務質量問題。

4.使用同一個交換機或在同一個交換網絡中。

為完成完全hash集群化，需要在各個機器上執行：

1.配置所有的機器使用同一個Cluster集群名字MyCluster：

2.配置啟用全cluster集群模式：

3.然后重啟服務：

TS服務重啟后，服務器將會在幾秒內加入到整個集群中，可以使用 traffic_line -r proxy.process.cluster. nodes 命令來查詢集群的機器書目。同時可以查看配置文件cluster.config，文件中列有各個機器的IP地址和端口的列表。

集群模式啟動后，traffic_line -x命令將可以影響所有的機器，在一個機器上修改的全局配置，執行traffic_line -x后會在集群內全部生效。

TS日常管理

TS的日常管理中，有很多與其他系統不同的地方，首先我們需要了解一個正常TS系統的表現情況。

在TS的正常情況下，會有3個程序運行：

其中，traffic_cop是以root用戶運行，但是traffic_manager與traffic_server是以nobody用戶運行。

在正常的運行系統中，TS需要監聽很多端口，下面是一個實際機器的例子：

其中的各個端口與對應關系如表1所表示。

TS運行中的日志會存儲在/usr/local/var/log/trafficserver的目錄中，其中traffic.out涉及到關鍵部分服務相關的錯誤信息，是服務器問題調試的關鍵日志文件。

TS的配置文件放在/usr/local/etc/trafficserver中，其中幾個關鍵的配置文件經常會被用到，我們在前面的配置中也有涉及。

1. records.config：主要記錄所有的系統配置參數，前面traffic_line -s所操作的所有參數，都存儲在這里。格式為：

例如：

records.config修改后，需要使用traffic_line -x使其生效。

2. storage.config：配置TS使用的磁盤、或目錄。

格式為：

或：

從上一節的配置中，我們看到了好幾種日常操作相關的命令。TS提供了多種日常管理工具，下面簡單介紹TS的主要命令的功能和主要使用方法。

TS的可執行程序包含三個主程序和五個工具，以及一個init腳本。

三個主程序：

1. traffic_cop:

負責啟動和管理traffic_manager進程的所謂“警察”程序，確保traffic_manager正確執行工作。

2. traffic_manager:

負責啟動和管理traffic_manager進程的所謂“主管”程序，主要功能有啟動并監控或重啟traffic_server進程、處理工具系統提交的管理指令。

3. traffic_server:

TS對用戶服務的主程序，主要負責監聽服務端口、完成用戶請求、完成Cluster資源和任務調度、執行manager程序的控制指令。

五個工具：

1. traffic_line

設置、查詢系統配置參數；

查詢系統中的統計數據；

重啟、重置服務器或集群所有機器等。

如啟用debug模式，可以使用如下命令：

2. traffic_logcat

用來將TS記錄的二進制的squid日志轉換為可讀形式。

3. traffic_logstats

顯示TS的訪問統計詳細數據。

4. traffic_shell

一個類似交換機配置界面的命令行管理工具。

5. traffic_sac

一個獨立的工具驗證工具。

在日常管理中，最常見的操作是配置相關參數，TS提供了很多修改系統參數方法，我們選擇常用的方法予以介紹，如假設我們需要修改 TS 到源服務的 tcp 長連接在沒有傳輸的情況下的超時是20 秒，相關參數是records. config中的proxy.config.http. keep_alive_no_activity_timeout_out

我們可以采用下述的任何方法完成這個任務：

1. 執行traffic_line -s proxy.config.http. keep_alive_no_activity_timeout_out -v 20

2. 修改 records 文件下的 CONFIG proxy.config.http. keep_alive_no_activity_timeout_out INT 30 行

改 30 為 20 ，保存后用 traffic_line -x 生效

3. 執行 traffic_shell，進如 enable 模式，執行 config: http inactive-timeout-out 20

4.將操作保存為批處理文件，執行 traffic_shell 批處理文件。

其他日常經常需使用的TS操作命令還有以下幾個：

1.啟動/停止/重啟動ts：trafficserver {start|stop|restart}

2. 清空cache： traffic_server -Cclear ( 該命令在TS停止時執行 )

3. 查看cache是否清空： traffic_line -r proxy.process. cache.bytes_used

4. 查看配置的cache大小： traffic_line -r proxy.process. cache.bytes_total

5. 查看集群中的節點數： traffic_line -r proxy.process. cluster.nodes

TS狀態統計與監控、訪問日志

TS的日志統計系統功能強大，其中最有特色的功能由traffic_logstats命令提供，這個命令能夠統計所有的訪問情況，并根據各種情況進行合并統計，可以分別對提供服務的域名（以remap文件中的源服務器為統計目標）統計如下計數：

按照域名分別統計；

請求結果；

返回碼；

回源統計；

HTTP Methods；

Content Types；

表1 各個端口與對應關系

響應時間；

狀態統計與監控。

統計以上所有的流量相關數據的請求數、字節數絕對值和百分比，以及命中率的最小值、最大值、平均值、標準差值。在生產運行中，具有非常實用的參考價值。

為提高效率，TS的請求日志訪問默認采用squid binary格式，由于二進制無法直接cat等，因此需要使用traffic_logcat才可以顯示出結果。TS有專用的配置來控制請求日志的格式、大小、保存數量等。

proxy.config.log2.logging_enabled：控制是否啟用log2格式（即目前TS使用的格式）的日志。

proxy.config.log2.xml_logs_config：是否使用XML格式的日志格式控制系統，XML格式的日志管理系統允許就日志的記錄方式進行高度自由定制，其中squid格式的日志即為log2+xml定義出的。

分別控制是否啟用squid各個格式的日志，*_is_ascii控制是否采用文本模式存儲日志，ascii方式會增大日志文件，同時會影響性能，因此TS默認采用二進制方式存儲。

TS支持郵件報警接口，詳情參考records.config:CONFIG proxy.config.alarm*

其他TS很有趣的功能還有待大家開發。

緩存內容后臺自動更新機制；

長連接與read while writing功能；

多端口多SSL證書機制；

透明代理功能；

Cluster CDN實施；

使用 trafficserver構建cluster平臺；

提高可管理性、運維效率；

流量管理；

Cluster Proxy實施；

7層路由；

連接管理；

SLA管理。

TS的開發與支持

TS是由Inktomi的科學家們在2000之前完成了絕大部分的設計與開發。其中的很多都是赫赫有名的業內專家：

Dirk Grunwald: 現為知名教授,當年為TS寫底層代碼。

Brian Totty : 著有《HTTP: The Definitive Guide》一書。

John Plevyak：至今仍在開發TS，負責TS的多個核心模塊。

目前在Leif Hedstro帶領下，世界各地有30多個active的開發者和貢獻者，負責核心代碼的開發。我們的4人小團隊是國內系統研究代碼、翻譯文檔的團隊，并已經把多個代碼提交到官方代碼中。

TS是一個由C++語言從底層構建出的一個完整的proxy系統，實現了一套獨特的事務處理機制和過程控制機制，對學習如何用C++構建一個大型系統具有非常好的參考價值。目前的TS開發正在一個逐步加速的過程中，很多增強功能、性能改進、代碼優化都在進行中，我們非常期望更多的C++開發者和TS用戶參與到TS的開發建設中來。

(作者單位為淘寶網)

后記：

本文從初學者的角度介紹了TS的特性和使用方法，是CDN管理員了解和使用TS的第一扇窗。TS是一個非常好的企業級proxy系統，利于企業化大規模運維，它具有優秀的設計，方便二次開發等后續擴展。

處理TS的問題中常用的方法

1. 如何啟用debug模式？

修改records.config的如下3行，啟用TS的debug模式調試模塊：

CONFIG proxy.config.diags.debug.enabled INT 0

CONFIG proxy.config.diags.debug.tags STRING cache.*|cluster.*|chan.*

如改為：

CONFIG proxy.config.diags.debug.enabled INT 1

CONFIG proxy.config.diags.debug.tags STRING dns.*

即可調試DNS相關模塊的情況。

debug.tags到底包含有多少模塊？它包括很多模塊，在TS的源代碼目錄里執行： grep -ioR 'Debug([a-zA-Z_-"]*,' * | awk -F ( ' {print $2}' | sed 's/[",]//g' | sort -u 可以看到，debug.tags支持正則表述。

Debug信息會打入日志目錄的traffic.out文件中。

2. 如何確定文件是被TS緩存？

分析TS的返回頭密碼：

TS返回給用戶的header中，含有如：Via: HTTP/1.1 localhost.localdomain (ApacheTrafficServer/ 2.1.3-unstable [cHs f ])的內容，其中方括號中的部分內容是TS的cache狀態密碼。

A. 詳細參考http://trafficserver.apache.org/ docs/v2/admin/trouble.htm#interpret_via_header

B. 返回via密碼中含有cH即為緩存命中。

分析squid.blog中TCP_HIT與TCP_MISS

網絡分析：

A. 使用兩臺機子ts1和ts2。在ts1上配置apache，并在/var/www.html/上編輯得到文件如b.html，test.jpg等。之后使用tcpdump監聽ts1 80端口的tcp通訊。在ts2配置ts，清空cache并以反向代理模式啟動ts，配置remap. config文件，添加規則“map ts1_url ts1_url”(ts1_url代表ts1提供的外部訪問的鏈接)。

B. 配置客戶端，編輯hosts文件，添加一條記錄使得對ts1的訪問轉向ts2，并保證瀏覽器不使用緩存。

C. 使用客戶端瀏覽器訪問ts1上的文件b. html兩次，通過wireshark分析tcpdump從ts1上抓的包。如果ts2只從ts1上取了一次b.html，則說明文件被ts2緩存。