分類: Linux

php configure fast cgi

06/042011

php 與 apache 最常協同工作的方式是採用在 apache 上掛載 mod_php 模組，在執行 apache 的時候呼叫這個模組來編譯 php 網頁。所以接收工作與回應的模式大都是 apache 在控制(這邊指的是行程的數量…與生命週期等等)，預設情況 apache 會有一個 process pool 接到要求就從 pool 中叫一個起來工作，如果工作超過 pool 的 process 量的話則 fork 新 process 來處理，則會佔用大量的記憶體，尤其是 apache 是採用 process 不是 thread 的關係(一個 30M 200個 request 就需要 6G)。

common gateway interface 是一個讓網頁伺服器與程式銜接的介面，叫做 interface 就是代表各種語言只要實做了這個介面就能跟網頁伺服器溝通。而 fast cgi 則是 cgi 的擴展擁有許多更良好的特性，可以是一個不中斷程式持續的接收工作，而 apache 接到工作以後不是採用 php 模組的方式呼叫編譯，而是將要求轉送至已在運行的 fcgi 程式中。

透過 fast cgi 的方式運作與 spawn cgi 來管控數個設定如: php_cgi  行程的數量。透過管理 php_cgi 行程池，減低 apache 載入 php 模組所耗費的記憶體，應能加速 apache fork 行程的速度，因為少載入了一個肥大的 mod_php module。這樣的話假設實際環境使用者要求個網頁有 1個php 9個資源的情況，10個要求只有1個需要呼叫 php_cgi ，這樣 10 個 php_cgi 可以處理 100 個 apache process。

Continue reading…

CentOS 3rd party yum repos

05/252011

Linux 的作業系統都會自己維護一套軟體套件，像 CentOS 是用 yum 來安裝，

所以這些自己上網確認更新的套件都是 CentOS 官方再維護的，這些軟體的伺服器資訊都在 /etc/yum.repos.d/ 下面

但是有些軟體比較新不想要自己 make 跟維護關聯性，可以採用第三方的 repos 來安裝，

例如 ius、EPEL、rpmforge 還蠻常見的，裡面有一些 php , python 新版的套件，可以裝。

安裝方式　http://wiki.iuscommunity.org/Doc/ClientUsageGuide，以 ius 為例

root@linuxbox ~]#
   wget http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/i386/epel-release-5-4.noarch.rpm

root@linuxbox ~]#
   wget http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/i386/ius-release-1.0-8.ius.el5.noarch.rpm

root@linuxbox ~]#
   rpm -Uvh ius-release*.rpm epel-release*.rpm

如果路徑錯了可以自己去 http://dl.iuscommunity.org/pub/ius/stable/Redhat/ 裡面找自己要得版本，然後安裝好就能更新一些新的套件例如 php5.2


$ yum install php52

ldap install and linux users

05/242011

Name Service Switch 是 Linux 幫助查詢與統整各式資料的協定，例如帳號、群組、主機名稱～

PAM 則是帳號認證的模組，讓你可以動態的換掉認證的方式。

透過 Ldap 資料庫跟這兩個模組的合併，對伺服器帳號統整管理有很大的威力～

這文章主要在介紹大致上需要安裝的流程與相關設定檔，並簡介 ldap 相關概念。

Continue reading…

gearmand

05/212011

下載： http://gearman.org/index.php?id=download

作業系統：CentOS

前置作業：yum install libevent-devel , boost –with-program-options , yum libdrizzle-devel

drizzle 好像是一個 MySQL 的分支，是要處理擴展性跟底層修改測試部份的專案，所以他也可以跟原生的 MySQL 溝通，

要先裝好 libdirzzle-devel ，這樣在裝 gearmand 的時候 configuration 才會啟用 libdrizzle 可以把 job 的資料配合存進 MySQL 內的佇列。

但是在 0.20 的 gearmand 在這部份有些問題 自動建立表跟插入的 SQL 有錯，可以參考下面這個修正再重編譯，算是少兩個逗號吧 Create 跟 Insert 的地方

https://code.launchpad.net/~clint-fewbar/gearmand/fix-sql-regression/+merge/59064

後來 Woker 在處理 Queue 時出錯…，訊息如下：

ERROR [ proc ] snprintf(DELETE)(Success) -> libgearman-server/plugins/queue/drizzle/queue.cc:416
ERROR [ proc ] Remove from persistent queue(QUEUE_ERROR) -> libgearman-server/server.c:495

https://bugs.launchpad.net/gearmand/+bug/778306

參考上面這篇的問題一樣改 queue.cc 裡面，維護者說已經修正過了，所以去找一下 build 版本的 source code

http://bazaar.launchpad.net/~gearman-developers/gearmand/build/view/head:/libgearman-server/plugins/queue/drizzle/queue.cc

所以改這段～

- if (query_size < 0 || query_size > (ssize_t)sizeof(query))
+ if (query_size < 0 || size_t(query_size)> query.size())

改完上面的好像跑來就ｏｋ了～可以測不開 Woker 只跑 client ，job 就會進 Queue 裡面了～

其他細節待續 ，…趕林揚…伺服器被打雷打掉了沒有細節了~

開伺服器的命令，主要指定 libdrizzle 的 host 跟 user 跟資料表還有 bug 不能指定 mysql 密碼…

vvv 是 log 顯示等級


$ gearmand -u apache --queue-type=libdrizzle --libdrizzle-host=antslab.tw --libdrizzle-user=assist --libdrizzle-db=assist --libdrizzle-table=global_gearman_queue --libdrizzle-mysql -vvv &

參考資料：

Server Load Balancing

04/282011

當伺服器負載過大時，需要透過幾台伺服器分散效能～通常都採用 Cluster 的架構，由一台中心伺服器來負責監控與分散要求，Web Server 與 Database 等 Server 蠻常在遇到瓶頸後採用這種方式來解決。

如果是網頁伺服器，可以採用 Apache or nginx 的 proxy 做 reverse proxy 來做。 reverse proxy 是由一台伺服器接收 url request 再由該 proxy server 向背後的伺服器農場(server farm) 發出請求(http request)，再將回傳的資料轉送至其他實際提供服務伺服器達成。所以所有要求都會經過該伺服器處理，所以雖然幫後端分散了一些負載，但是到最後負載可能會卡在 proxy server 上～

但如果是其他服務，例如 ftp , streaming , dns .. 等其他 tcp 的服務就沒辦法用以上的 reverse proxy server 處理，因為他算是 layer 7 的 load balance 不是單純再轉送封包而已，而是很 high level 的再轉送網頁內容而已，如果要處理 tcp 的 load balance 就要透過其他不單純再處理 Web Server 的 Load Blancing 軟體來處理囉。

有幾本書在討論這種軟體

平衡模式：

能夠達成負載平衡有幾種模式：

•  NAT Mode + HA

一台主伺服器負責接受要求，該伺服器再透過區網，將要求轉送給 private lan 內的其他處理伺服器，再由主伺服器轉送給 client，容易造成主伺服器過載。

•  Direct Routing Mode(DR)

主伺服器負責接受要求，再透過區網選擇出一台可以工作的伺服器，不修改也不封裝 IP 封包，而是將資料封包的 MAC 地址改為選出後端伺服器的 MAC 地址，再將修改後的資料封包在與後端伺服器組成的區域網路連結，因為資料封包的 MAC 地址是選出的後端伺服器，所以後端伺服器肯定可以收到該封包，該負責的伺服器在直接回應 client 不經過主伺服器。這樣效能比較不會卡在主伺服器上。

為什麼可以不用修改封包？因為  real server 的 ip 要設的跟 service server 一樣，並且關閉 arp，這樣 real server 再接收到封包的時候也不會覺得有奇怪，實際設定可以搜尋 lvs 的相關文章。

•  IP Tunneling Mode

連接分配和管理與 VS/NAT 中的一樣，只是它的封包轉送方法不同。 LBS 主機根據各個後端伺服器的負載情況，動態地選擇一台伺服器，將請求封包封裝在另一個 IP 封包中，再將封裝後的 IP 封包轉送給選出的後端伺服器。

後端伺服器收到封包後，先將封包解開獲得原來目標地址為 VIP 的封包，後端伺服器發現 VIP 位址被配置在本地的 IP 隧道設備上，所以就處理這個請求，然後依據路由表將回應封包直接返回給用戶端。

演算法：

  1. 輪詢（Round Robin）
    SLB 通過”輪詢”演算法將外部請求按順序輪流分配到集群中的真實伺服器上，它均等地對待每一台伺服器，而不管伺服器上實際的連接數和系統負載。
  2. 加權輪詢（Weighted Round Robin）
    SLB 通過”加權輪詢”調度算法根據真實伺服器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的伺服器處理更多的負載流量。SLB 可以自動詢問真實伺服器的負載情況，並動態地調整其加權值。由管理者來決定哪個機器要承受較重的負載，依此分配權重。
  3. 最少鏈接（Least Connections）
    SLB 通過”最少連接”演算法動態地將網路請求調度到已建立的鏈接數最少的伺服器上。如果 Cluster 的伺服器性能相似，採用”最小連接”演算法可以較好地均衡負載。依照當時要求的連線數分配，不考慮伺服器的差異，應該跟輪詢差不多。
  4. 加權最少鏈接（Weighted Least Connections）
    在 Cluster 中的伺服器性能差異較大的情況下，LBS 採用”加權最少鏈接”演算法負載均衡性能，具有較高權重的伺服器將承受較大比例的連接負載。LBS 可以自動詢問真實伺服器的負載情況，並動態地調整其權值。加權輪詢的輪詢改成看當時連接數最少的…應該是優先順序的差異吧！
  5. 基於局部性的最少鏈接（Locality-Based Least Connections）
    “基於局部性的最少鏈接” 演算法是針對目標 IP 地址的負載均衡，目前主要用於 Cache Cluster 。該演算法根據請求的目標 IP 地址找出該目標 IP 地址最近使用的伺服器，若該伺服器 是可用的且沒有超載，將請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則用”最少鏈接”的原則選出一個可用的伺服 器，將請求發送到該伺服器。
    這邊的情境是 Catch Server Cluster， 所以 Client 的要求都是告訴你他要查哪台伺服器的資料，所以才有目標 IP 這個變數，這演算法主要想控制每個伺服器分別處理特定的要求，例如Client 要求 Yahoo 的 IP 就固定給 a 處理，Google 的 IP 就給 b 處理，這樣就可以減少每台伺服器要處理的區域，可以節省一些 Catch 儲存空間。
  1. 帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication）
    “帶複製的基於局部性最少鏈接” 演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。它與LBLC算法的不同之處是它要維護從一個 目標IP地址到一組伺服器的對應，而LBLC 演算法維護從一個目標 IP 地址到一台伺服器的對應。該算法根據請求的目標IP地址找出該目標IP地址對應的伺服器組，按”最小連接”原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器，若伺服器超載；則按”最小連接”原則從這個集群中選出一 台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低複製的 程度。
    如同的局部性最少連接，只是這次處理的伺服器為一組為單位， a b c 一組都處理 client 對 yahoo 的要求，b c d 一組都處理 client 對 google 的要求，對於負載很大的情況一台機器處理不來，分組會在過載時的分配會有一些改善。
  2. 目地分佈（Destination Hashing）
    “目地分佈” 演算法根據請求的目標 IP 地址，作為 Hash Key 從靜態分配的 Hash Table 找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則回應無可用伺服器。
  3. 來源分佈（Source Hashing）
    “來源分佈” 演算法根據請求的來源 IP 地址，作為 Hash Key 從靜態分配的 Hash Table 找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則回應無可用伺服器。

另外介紹常用的幾款著名的 Open Source 軟體 SLB，

軟體：

  • HAProxy

支援 Session keep alive，由於 http 伺服器很多台，如果遇到像 php 內建的 session 實作將 session 實體放在該機器上，

則沒辦法跨數台伺服器共用 session ，可能造成一個使用者在 a 機器 登入重新整理過後突然轉到 b 機器 ，

b 機器沒有 session 造成伺服器不認識使用者的情況，所以如果是 LBS 原生支援這種 session 的存活，可以省去自己要解決這種問題的麻煩。

效能佳，接近硬體LBS，特色是支援 Direct Routing，DR 前提是 real server 都能連結到實體網路。

沒什麼可以調整的參數，所以配置好就不用理他就可以跑得很好了～


分層：

Layer-2 Load Balancing

就是把好幾張網卡 bonding 起來上網分流…port aggregation

Layer-4 Load Balancing

可以針對 port 進行導向，例如 80 就導到某台 Web 伺服器，21 就導到 ftp Server～

Layer-7 Load Balancing

http 層的 load balance，可以判定虛擬伺服器～依照 http 內容去做決定要導到那個伺服器。

參考資料