Linux學習（第十五週）

阿新 • • 發佈：2019-01-14

第十五週學習內容：keepalived和varnish

第十五週作業：

1、簡述HA cluster原理。

叢集中存在著多個單點，如排程器、session server、NFS等，他們的宕機會導致整個叢集不可用。解決辦法就是高可用叢集（HA cluster），將多臺能夠提供相同服務的主機組成一個組，活動中的主機不停將自己還在服務的資訊以某種協議同步給備用主機。工作正常時相安無事，一旦活動主機發生故障，則會將活動主機提供服務所需的資源轉移到備用主機上，這個過程叫做失效轉移，也叫故障轉移。在開源領域，高可用叢集的解決方案有很多，keepalive、heartbeat、Corosync等。

keepalived在設計之初就是為lvs服務的，可為其提供高可用和健康監測，其工作原理是利用網路中的vrrp協議，建立一個虛擬IP地址，背後是真正的物理介面，多臺主機的多個物理介面共享同一個虛擬IP地址，主機中有主有被，通過優先順序來決定。虛擬IP地址一直在主伺服器上，有其向外提供服務，一旦主裝置發生故障，備機將會把虛擬IP地址搶佔過來，從而改由備機提供服務。在配置過程中還可以定義是否搶佔，主備，優先順序和優先順序懲罰等多種屬性。

heartbeat和Corosync是另外一種架構，基於分層的高可用叢集。最底層叫資源層也被稱為心跳層，用來確保各臺主機狀態是否正常，可以互相通訊傳遞心跳資訊。上面一層叫做資源管理層crm，用來配置策略，決定哪些資源被監控，當活動主機發生故障要傳遞哪些資源等，但這一層是無法在不同主機之間通訊的，也不能對主機作出具體的更改，算是中間層，決策層。再往上一層叫本地資源管理層lrm，通過ra資源代理呼叫一個個外部指令做出具體更改。

2、keepalived實現主從、主主架構。

keepalived是vrrp協議的具體實現，簡單來說就是可以做到地址流動，可以為虛擬IP地址所在節點生成ipvs規則，為後端real server做健康狀態檢測，還可以基於指令碼呼叫介面通過執行指令碼完成指令碼中定義的功能。keepalived就存在base倉庫，主配置檔案是/etc/keepalived/keepalived.conf，配置檔案可分為三部分：全域性配置、VRRP配置、LVS配置。

keepalived實現主從配置：主伺服器配置

從伺服器配置，主要區別在state、priority這兩個配置。

現在將兩臺主機的keepalived服務啟動起來，並準備兩張主頁且啟動http服務，嘗試訪問虛擬地址主頁。

發現訪問的是主裝置，現在把主裝置的http服務關閉了。

再去訪問該主頁，自動就切換到備機了。

keepalived實現主主配置：在主從設定中，大多數情況下是一臺主機一直處於活動，一臺主機一直處於閒置。為了避免浪費可以使用主主配置，就是再定義一個例項，加一個虛擬地址，將前一個例項中的主伺服器定義為備用，再將備用主機定義為主，再基於DNS實現域名的負載均衡。

主伺服器配置

備用伺服器配置

這樣基於兩個不同的地址，將訪問兩臺不同的主機。

當其中一臺主機發生宕機，則會兩個地址都去往同一臺可用主機。

3、簡述http協議快取原理及常用首部講解。

快取的名詞解釋為資料交換的緩衝區，快取能夠生效是因為程式的執行具有區域性性特徵：時間區域性性，一個數據被訪問過之後，可能很快再次訪問；空間侷限性：一個數據被訪問時，其周邊的資料也有可能被訪問到。

以web站點為例，快取的資料庫資料成為datacache，快取的PHP資源稱為opcode。快取的上線並不是立即生效的，是需要熱身，瞭解哪些是需要快取的，這一過程短則1,2個小時，長則1天。所以在生產環境中，會用線上資料去做壓測，將熱身過程在上線前完成，快取上線後即可立即生效。

快取空間肯定是小於實際儲存空間的，當快取空間滿了以後，可根據LRU（最近最少使用規則）清理快取。可自己定義快取保留時長，當過期後即使快取空間未滿也會清理。

快取的目的是為了加速訪問，而一直不被訪問就叫有效性很差，有效性的評估方法叫命中率：hit/（hit+miss），有頁面命中率、位元組命中率等。快取是有多級結構的，使用者本地快取叫做private cache，每一層的反代也都會有各自的快取叫做public cache。

快取伺服器也有兩種組織形式，最常見的就是反代，接收到使用者請求，查詢本地快取，沒找到在反代給後端伺服器，等待後端伺服器響應後自己也快取一份，web服務都是以這種形式組織的；還有一種叫做旁掛式快取，接收到使用者請求，查詢本地快取，沒找到就告訴使用者沒有快取，使用者再重新發請求找真正的後端伺服器，此種方式所有的選擇權都在使用者這邊，memcache就是這種架構。

http協議的快取機制：http1.0時代，通過響應報文首部Expires來控制，記錄的是絕對時間，表示給使用者的響應多久以後會過期，是單純的以時間為衡量標準，如果有時差的話會出現收到響應報文快取已經過期的情況，這樣的話快取根本無法發揮作用。到了http1.1時代，可以通過cache-control來進行控制了，該首部中記錄了很多內容，如maxage，也是過期時間，但用的是相對時間，以秒為單位，可用於所有快取，這樣就避免了收到即過期的情況；s-maxage，同樣是過期時間，僅用於公共快取，且會覆蓋maxage；no-cache表示即使被使用者快取，使用者在請求時也要做有效性驗證；no-store表示不能快取；public表示可用於所有快取；private表示僅用於私有快取等。除了基於時間作為控制快取的機制以外，http1.1還引入了條件式控制，Last-Modified定義了自從多久沒更新，會向後端伺服器發起驗證，驗證該快取是否依然可用，當響應碼為304時，表示可以繼續使用；當響應碼為200時，表示不可繼續使用同時新的響應資源會被送達；ETag定義了已快取檔案的校驗嗎作為判斷，兩種方式可結合起來使用。

4、簡述回源原理和CDN常見多級快取。

回源原理：回源是指瀏覽器在傳送請求報文時，響應該請求報文的是源站點的伺服器，而不是各節點上的快取伺服器，那麼這個過程相對於通過各節點上的快取伺服器來響應的話就稱作為回源。回源的請求或流量太多的話，有可能會讓源站點的伺服器承載著過大的訪問壓力，進而影響服務的正常訪問。

CDN：Content Delivery Network，內容分發網路，其搭建的思路是儘可能避開網際網路上有可能影響資料傳輸速度和穩定性的瓶頸和環節，儘量使內容傳輸的更快更穩定。CDN通過在網路邊緣部署邊緣伺服器，依靠CDN中心平臺的負載均衡、內容分發及排程等功能，使使用者就近獲取所需的內容，降低網路擁堵，提高使用者訪問響應速度和命中率。所以基本上CDN就是廣泛採用各種快取伺服器，使得使用者的請求直接由這些快取伺服器響應，加快了響應速度；只有在使用者請求的資源在快取伺服器上沒有找到或者請求訪問的資源在源站點伺服器上已經修改過的情況下，快取伺服器才會去訪問源站點伺服器以獲取最新的資源。

在CDN系統中，直接面向用戶，負責給使用者提供內容服務的的Cache裝置都部署在整個CDN網路的邊緣位置，所以將這一層稱為邊緣層。而中心層負責全域性的管理和控制，同時也儲存了最多的內容Cache。在邊緣層裝置未能命中Cache時，需要向中心層裝置請求；而中心層未能命中時，則需要向源站請求。不同的CDN系統設計存在差異，中心層可能具備使用者服務的能力，也可能只會向下一層提供服務。如果CDN系統比較龐大，邊緣層向中心層請求內容太多，會造成中心層負載壓力太大。此時，需要在中心層和邊緣層之間部署一個區域層，負責一個區域的管理和控制，也可以提供一些內容Cache供邊緣層訪問。

CDN邊緣節點快取策略因服務商不同而不同，但一般都會遵循http標準協議，通過http響應頭中的Cache-control: max-age的欄位來設定CDN邊緣節點資料快取時間。當客戶端向CDN節點請求資料時，CDN節點會判斷快取資料是否過期，若快取資料並沒有過期，則直接將快取資料返回給客戶端；否則，CDN節點就會向源站發出回源請求，從源站拉取最新資料，更新本地快取，並將最新資料返回給客戶端。

這一段完全靠百度......

5、varnish實現快取物件及反代後端主機。

varnish是一款高效能、開源的反向代理伺服器和快取伺服器。Varnish使用記憶體快取檔案來減少響應時間和網路頻寬消耗。由於varnish先進的設計理念，效能要比古老的快取伺服器squid高上許多，varnish還可以通過埠進行管理，使用正則語句做到清除指定快取的功能，這些squid都做不到。但是varnish在高併發的情況下，資源消耗較高，而且varnish服務程序一旦崩潰，重啟，記憶體中的快取資料將全部丟失。

VCL：是一種專用的配置語言，在報文到達使用者空間後也會有一道道的關卡，被稱為狀態引擎，可以用iptables中的鏈去類比思考，在每個狀態引擎上可以配置各種快取規則，並且要在最後使用return()函式指明下一個狀態引擎，引擎之間是彼此隔離的，但又存在相關性。在配置檔案中每個狀態引擎對應一個配置段，叫subroutine，子例程。預設配置檔案中看不到任何配置，但在varnishadm命令列介面中使用vcl.show -v即可檢視到有些已經做得隱藏配置並且是不能修改的。

狀態引擎：從收到使用者請求開始，先經過vcl_recv，如果可檢視快取則送往vcl_hash，如果是根本不認識的METHOD，根本不理解此請求報文則送往vcl_pipe作其它處理，如果METHOD是PURGE（修剪）則送往vcl_purge，再經過vcl_synth，將響應碼與響應內容合成以後響應給客戶。而可查快取內容到達vcl_hash之後，檢視hash表，命中則送往vcl_hit，未命中則送往vcl_miss。正常情況下vcl_hit會將快取內容通過vcl_deliver響應給使用者，但如果快取檔案過期或者設有條件式控制機制則會將報文傳送至vcl_pass，而vcl_miss的下一步也是vcl_pass。vcl_pass會將報文送到專門的後臺工作執行緒vcl_backend_fetch，不可響應的分到vcl_backend_error，可響應的分到vcl_backend_response，最終送達vcl_deliver，結束！除此之外，還有兩個特殊的狀態引擎：vcl_int，在處理任何請求之前先執行的vcl程式碼，用於初始化；vcl_finl，在所有請求處理完畢後用於清理。

內建函式和變數：return()，指明下一步到哪個引擎上；hash_data()，指明對哪個資料做雜湊運算。varnish一般會接觸到四種報文，分別為使用者發來的請求，後端伺服器的響應以及自己發給使用者的響應和發給後端伺服器的請求，只有後兩種報文可以進行修改。req.*表示由客戶端發來的請求報文相關屬性值；bereq.*表示自己發往後端伺服器的請求報文相關屬性值；beresp.*表示後端主機發給我的響應報文相關屬性值；resp.*表示由我發給客戶端的響應報文相關屬性值；obj.*表示儲存在本地快取空間的快取物件的屬性；server.*表示varnish伺服器的屬性；client.*表示使用者的相關屬性。而在這些分類中經常會用到的變數有bereq.和req.request：請求方法；bereq.url：請求的url；bereq.proto：請求的協議版本；bereq.backend：指明要呼叫的後端主機；req.url:請求的url；req.http.Cookie：客戶端的請求報文中Cookie首部的值； req.http.User-Agent：瀏覽器型別；beresp.和resp.status：響應的狀態碼；reresp.proto：協議版本；beresp.backend.name：BE主機的主機名；beresp.ttl：BE主機響應的內容的餘下的可快取時長；obj.hits：此物件從快取中命中的次數；obj.ttl：物件的ttl值；server.ip和client.ip：主機和客戶端IP地址。

varnish實現快取物件及反代後端主機：

在default.vcl中定義一個內建變數obj.hits，用於儲存某快取項的從快取中命中與否，為了之後的顯示更直觀。