Archive for the ‘工作’ Category

李一諤高可用性系統(十一):MySQL與MariaDB伺服器

說到在HA中這部份,它可算是一個比較讓人頭痛的組件。有以下幾點:

第一,它是dynamic web 不可或缺的,但如果它掛掉了,所有用這些資料庫的網頁將全部出問題,偏偏它是很容易出問題的或突然會有很大的負載。

第二,我們一向也使用MySQL,它是很多開源系統的第一選擇,所以我們也慣性地選用它。不過早前它經歷一個大的轉捩點--給人收購了。可能它與開源可能越走越遠,未來可否免費使用亦未可知。

第三,是它多是以單伺服器的形式出現。要架成主從架構並無不可,但也有一定的難度,同時對伺服器的要求也不太低。但我們曾架設了一個主主的伺服器,兩台機一有更動就會通知對方更新。但不幸地玩了一年的時間,其中一部出了問題,只得另一部孤軍作戰,唯有每晚將database備份至其他主機,作兩手準備。

不過在電腦世界,問題不會長期出現或不出現。其他人已意識到上面的問題,已有一些替代品出現了。其中一個叫做MariaDB,是由原來部份的研究團隊分拆出來,製造成另一個開源的資料庫伺服器。正因如此,所以兼容性不成問題,甚至執行指令的名稱亦完全一樣。當然它可以與原版本完美過渡,連版本序數亦是連貫起來。我們用的是5.5版本,MariaDB亦有此版本。用起來一點問題也沒有,非常好用。期望在不久將來,它可以在FreeBSD內裝成db cluster,這樣單點故障將會在本校HA中永久消失了。

李一諤高可用性系統(十):LDAP的使用

在本校一貫的IT安排上,我們十分強調要用單一身份及密碼,因為不想令到學生、老師及家長記憶不同的身份,更不想太多的label紙把學生手冊都貼滿了。

以往在單伺服器已可進行此功能,那麼在HA中又怎可以做到呢?其實也沒甚麼特別,只需和以往一樣在每部網頁主機也加上一個LDAP伺服器,再加上它們是去Master 主機取得更動即可。

接著每個要認證的系統就可請求本機LDAP來幫忙,那就可以分散了工作,不會將所有的認證工作集中在一部Master,當然在每部機要安裝的軟件也多了幾個,不過這不是大問題。十年過去了,這安排也算經得起時間的考驗。現在HA內很多系統也用這機制作分散認證,例如:Moodle2ownCloudbooksfilesWordPresssitebarphpBB等。

李一諤高可用性系統(九):在HA內ZFS的使用

為何又說ZFS這話題?因為經過數年的使用,對它的理解多了,升級及更換硬碟也經歷過了,也算摸透它的特性,同時也有很多部ZFS建立了,應該可以說說它的好處。經過這幾年的使用,發覺它真有好處。所以它人仍然是我們最倚重的檔案系統。

但看到那幅結構圖,就會發覺最底層是可以用ZFS或MFS,當中的分工是怎樣的?試如早前所說,MFS給出來的讀寫效果並不令我們滿意。所以它是放在一些讀寫要求不高的場景中使用,不過它分佈性本質避免了單點故障,以致我們仍要使用它,甚至預見它可能是儲存方案的「未來」。

 

 

說回ZFS,它在本校的HA中仍然有一個舉足輕重的地位。因為它還利用在一些需要較多存取的系統,如Moodle、ownCloud、osTube等。出來的結果還是頗滿意,雖然是mount其他機的shared drive,但速度真的很快,就好像存取自己機內的硬碟一樣。同時,有很多部伺服器連接一部ZFS,還是可以有很高的throughput。大家可以看看以下的網站:

LYNMS osTube

這個網站是將網頁伺服器和儲存分開的,效果也相當理想呀!

李一諤高可用性系統(八):HA內的Apache與Nginx的安排

作為本校HA的底層及基本的應用,apache及Nginx負責將不同的網站呈現在使用者面前,而資料是儲存在一個共用的空間,它可以是ZFS或是MFS。

但apache或Nginx網站是怎樣設定的呢?就是用virtual host及以ports的型式來架設。以owncloud為例,我們在HaProxy設定了一個以網址名稱來辨識的段落,並在裡面定義了幾部伺服器:
———————————————————
backend owncloud_back
balance roundrobin
cookie SERVERID insert indirect nocache
option forwardfor
option httpclose
option httpchk GET /check HTTP/1.0
server pc111 10.79.118.111:8002 cookie pc111 check inter 50000 maxconn 5000
server pc112 10.79.118.112:8002 cookie pc112 check inter 50000 maxconn 5000
server pc113 10.79.118.113:8002 cookie pc113 check inter 50000 maxconn 5000
……
———————————————————

之後便在每部伺服器中設定virtual host的部份:
———————————————————
server {
listen 10.79.118.111:8002;
server_name owncloud.lynms.edu.hk;
root /home/lynms.edu.hk/owncloud;
index index.html index.php index.htm;
……
———————————————————

這樣伺服器就會懂得回應相關的要求。如果要再加入伺服器只需在上面HaProxy設定部份再加入即可,當然為了易於管理,後端伺服器最好是用相同的軟件運行,否則除錯時就會引致問題或不能找出原因去對症下藥。

李一諤高可用性系統(七):歷久長青的Apache

Apache作為最受歡迎的網頁伺服器,本校當然亦是其中一位用家,而且是全面使用。有一段長時間,它是我們唯一使用的網頁服務器。嚴格來說,我們對它的表現也算滿意。只是本著精益求精的態度,在發覺Nginx的特性與好處時,便想去試試。

但綜觀使用它的經驗,其實沒有發生過甚麼旳大問題。只是在早期版本會偶然發生吃掉資源,令到要在swap裡讀寫的情況。那時用的是Linux系統,一出現這情況,便只能重啟它,因為系統並不能重回正常的狀態。相信這是由於當時的低硬件配置及Linux版本的問題而產生的,及後在換至FreeBSD平台及升級至Apache2.2後,問題已很少出現了。不過有時仍會出現loading太大的情況,但瞬間就會回復正常。

但它有甚麼好處讓我們繼續使用?答案就是它和PHP的結合了。在FreeBSD安裝這個組合是很容易的:

cd /usr/ports/www/apache22
make install clean;

cd /usr/ports/lang/php53
make install clean;

cd /usr/ports/lang/php53-extensions
make install clean;

當然要等待一段時間才可安裝好。之後便可以使用PHP及Apache了,這比Nginx夾PHP的難度少得多。同時,便可進入一個互動網頁的世界。

另外,說它歷久長青是因為它不斷在更新,現在已進入到Apache 2.4版本,一般使用並不會有大問題的。

李一諤高可用性系統(六):被邊緣化的Varnish(緩存伺服器)

在原先的設定裡,此軟件是運行在LB及HAProxy之上,希望所有網頁都經過緩存的過程(如可以緩存),藉此加快網頁開啟的速度。

 

 

但現在它已經被邊化,套用內地體育術語就是「板凳坐穿」。簡單來說就是被我們棄用了,因為它引起了很多問題。

最大的問題是它令很多網站不能登錄,因為這和cookies有關。首先我們要明白,很多網站或系統會產生cookies來紀錄瀏覽資料或登入戶口,瀏覽完畢就會清除。但Varnish看見cookies就不會緩存網頁,如果清除了cookies就會引起登入或瀏覽問題,這真是兩難的決定。

直至有一天我就恨心地移除了它,直接把工作交給HAProxy,所有登入的問題迅即解決。不用再擔心網頁開不到,或產生其他問題了。當然速度不會有提昇,不過亦可接受,並不算很慢。

示例:

ptme

tqdy

如果真是想用緩存,亦可要求小巧又強悍的Nginx代勞。

李一諤高可用性系統(五):小巧又強悍的Nginx(網頁伺服器)

今日要介紹一個小又美的網頁伺服器。作為本校HA一個重要部份,它的表現也頗令人滿意。雖然不能說十全十美,但確實又功能強大,效能亦很好。

它問世只有幾年,但巿佔率正節節上升。雖然我們一貫用開Apache,但本著精益求精的精神,亦想試一試它。

安裝它很容易,只需在ports中找到它,很快就可以安裝好了:

cd /usr/ports/www/nginx
make install clean;

之後就要先設定,才可使用。設定也不太難,功能亦頗強勁,大抵上Apache有的功能它亦有,不過就會用少些系統功能。我們在一些PIII機來運行亦沒有大問題。當然運行的網站只會是一些簡單的網頁吧!

 

 

其實它是十分穏定的,更新次數亦頻䌓。但是要找它的缺點,可能就是一些系統的支援不太完善。有些系統會很容易找到Apache設定的參考,但用在Nginx上的就會欠奉,例如Elgg的設定就很難找到。另外,它的Rewrite Rules的寫法亦與Apache不同,我們因此遲遲未能將全部系統移至它上面去跑。

不過情況是正好轉中,因為系統開發者都不能無視它的存在,畢竟有越來越多的網站正轉用它。

李一諤高可用性系統(四):負載均衡器間的uCARP(心跳裝置)

上一篇已講述了負載均衡器(LB)上的HaProxy,但大家看架構圖會發現有兩部LB。這其實不難理解,因為希望不會有single point of failure。不過在本校的設定上,我們希望兩部機也運行著,不是以某一部作主,亦另一部作備援,否則好像有點浪費,亦不能分擔流量。

要做到這樣的目的,只需在DNS做功夫,將一個hostname解作兩個true IP就可以了。所有的request就會輪流分發去兩個負載均衡器,達到分流的目的。

 

 

但問題又出現了,如果其中一個LB掛掉,一半的流量會出現問題。所以我們在兩個LB都安裝了uCARP--一個心跳的裝置。它會定時向其他電腦發送訊息,通知其他機器自己依然「健在」。但當其中一台機出現問題或當機,另一台機就會在短時間內取得出問題機器的IP。那部倖存的LB就會獨力扛起所有工作,而所有流量就只有一條路可行。

如果此情況出現,管理人員便應儘快檢查出事的機器,否則連僅餘的lb也出事,就全部網站也不能開啟了。不過相信這機會是比較少發生的,或者這樣說,在本校從未發生。

李一諤高可用性系統(三):負載均衡器上的HaProxy(Reverse Proxy)

作為負載均衡器(Load Balancer)上的靈魂,HaProxy是一個反向代理(Reverse Proxy),能將外面的request轉至backend servers,通常會用輪流分派的原則,同時亦可設定比重。結構圖如下:

 

當然如有backend server發生問題(下圖紅色部份),它會自動探測並將工作轉至其他的伺服器(下圖緑色部份)。這可大大減省管理者的工作壓力,因為這令救急的工作變得不太急迫,可以在有空閒時才處理。管理介面如下:

 

作為高可用性系統的靈魂,HaProxy能在一般配置的伺服器上工作,對硬件的要求並不高,同時它的穏定及安全性亦十分出眾。

除了既穏定又安全外,它亦對Cookies的處理十分周到,可以將登入的資料與某台伺服器連結,直至此次瀏覽網站的要求完結才會轉用下一個伺服器,確保登入資料不會出錯或外洩。

上面的優點當然是重要,但是在本校應用中它更有另一個好處,就是可以擴容,即是加大某些網站的處理能力。以Moodle2系統為例,我們現在有九部backend servers,如果老師們大力支持使用Moodle2作教學,可能會令致這幾部伺服器不能負荷,我們只需再加添多幾部伺服器,便可支持老師及同學長期使用Moodle2。這就是我們常說的終極目標,亦是我們推動全校eLearning的基礎。

李一諤高可用性系統(二):Moose File System(MFS)

作為最重要及最底層的部份,我們會用一個分佈式的檔案系統。用的就是這個:

MooseFS

最基本要求,就要一台伺服器作為主控(Master Server),另加一些資料伺服器(Chuck Servers)。

以本校為例,除了主控伺服器外,我們用了九部伺服器將剩餘的硬碟空間連合一起,變成一個大的硬碟,可以給其他伺服器mount來使用。而那些檔案就會分佈儲存在該九部(Chuck Servers)內,每一檔案都會儲存兩至三個備份(copies),這數字可由用戶自己設定。如果有一些伺服器出現問題,有效的文件份數就會減少,系統會儘快複製至要求的份數,令該些檔案恢復至「健康」狀態。

除了這個用法,亦可以用來加大容量。只需加入新的資料伺服器(Chuck Servers),容量便會自然加大了,非常方便。

下面是它的管理介面截屏:

這個系統有甚麼不足之處?就是它的throughput不太理想,要放置本校的影片庫就有些力不從心了。