拓撲：
拓撲說明：
兩臺服務器配置Keepalived+Nginx做雙主模型的Load Balance，主機名爲lb1和lb2
兩臺服務器配置lamp，用於處理動態資源請求，主機名爲lamp1和lamp2
兩臺服務器配置varnish作爲靜態資源緩存服務器，主機名爲varnish1和varnish2
兩臺服務器配置Nginx用於處理靜態資源請求
額外需要一臺服務器安裝ansible，使用ansible批量管理所有服務器
關鍵技術點：
1. Keepalived配置了郵件報警腳本，當節點的狀態發生改變時，會發送報警郵件（腳本中的郵箱需修改）
2. Load Balance部分使用Nginx進行動靜分離
3. 調度動態資源流量時，爲了綁定session會話，使用的是ip_hash算法，如果使用sticky方式調度，需要調整緩存規則，否則訪問靜態資源時由於擁有cookie信息，資源無法被緩
4. 調度靜態資源流量時，爲了提高緩存命中率，使用的是ip_hash算法。可以考慮使用consistent_hash算法（一致性哈希）。但經過測試，Nginx使用consistent_hash算法時，無法實現對後端服務器的健康狀態監測以及故障轉移。因此，如果需要使用consistent_hash算法，建議使用Tengine
5. 關於靜態資源緩存部分，使用的是多層級緩存。前端LB上，Nginx配置了proxy_cache，用於存放少部分熱點數據，後端Varnish上存放經常被訪問的數據。由於測試用，前端LB上緩存的時間很短
6. 所有web服務每天會分割一次access_log
7. 在響應報文中添加自定義Hearder，可顯示相應資源是從哪臺服務器上獲取的，便於以後排錯
還可以進一步改進的地方：
1. 實驗配置中的緩存策略可以進一步修改和優化
2. varnish的日誌服務還未配置
3. 可以使用Tengine替代Nginx，使用consistent_hash算法提高緩存命中率的同時，分散緩存的存儲位置
4. 關於ansible的安全隱患:
由於使用密鑰方式進行通信，因此一旦ansible server被非法登錄，其他被管理節點也存在被篡改的風險。因此，可考慮專門創建一個ansible用戶用於和其他被管理節點使用密鑰方式進行ssh通信，其他用戶如果需要使用ansible來管理服務器，需要sudo至ansible用戶來執行ansible命令，這樣在日誌中會有相應的記錄
實驗環境：
所有服務器ssh端口號: 2222
ansibleserver與被管理節點的通信方式: 使用密鑰方式進行ssh通信，remote_user爲root
所有服務器使用hosts來解析主機名,因此所有服務器的hosts需要保持一致
ansible_server Centos7.2
192.168.1.200
lb1 Centos 7.2
192.168.1.202
llb2 Centos 7.2
192.168.1.203
varnish1 Centos 7.2
192.168.1.208
varnish2 Centos 7.2
192.168.1.209
lamp1 Centos 6.5
192.168.1.101
lamp2 Centos 6.5
192.168.1.102
static_server1 Centos 7.2
192.168.1.205
static_server2 Centos 7.2
192.168.1.206
最終效果：
附件爲ansible所需的所有配置文件，包含了實驗中所需的所有角色，一共是兩個壓縮分卷。感興趣的可以下載測試