不得不在 CentOS 6 上安裝上一代的 mysql 5.0.95,怎麼辦?

先不管是什麼原因非得在 CentOS 6 上捨 mysql 5.1 或 5.5 而是用 5.0 不管。其實這個問題很簡單,一般大家都會用 make 一般大家都會用 make 一般大家都會用 make(因為太普遍了所以要寫三次)。不過比較易於管理的方式,我還是建議自己用 rpmbuild 來生出套件安裝,未來要更新或移除也會乾淨許多。

方法很簡單:

  1. 去 vault.centos.org 中找出 CentOS 5.11 中的 .src.rpm 檔(很久以前是叫 srpm 檔),目錄是 http://vault.centos.org/5.11/os/SRPMS/ ,可以找到 mysql 5.0.95 的 .src.rpm,把它抓回來,執行 rpm install(指令是 rpm -i 這應該不用我教了吧⋯⋯)。
  2. 使用一般 user 來執行 rpmbuild。CentOS 6 預設會在 user home dir 下建立一個叫 rpmbuild 的目錄,剛剛用 rpm install 的 .src.rpm 檔的內容都會在此目錄下出現。這時就要到 ~/rpmbuild/SPECS/ 下,會看到 mysql.spec 這個專門給 rpmbuild 的規格檔。
  3. 在 SPECS 目錄下直接執行 rpmbuild -ba mysql.spec。很抱歉,這樣會有錯誤訊息,rpm檔會做不出來。要在 .spec 檔中修改某一行的一個設定:%{!?runselftest:%define runselftest 0} 把 1 改成紅字的 0 才行。其實這樣差不多就可以了,但對 .spec 檔比較有把握修改的人,就改 Name: mysql50 及修改一下 %setup -q 變成 %setup -q -n mysql-%{version},這樣產生出 mysql50-*.rpm 就可以減少(不是沒有喔)與 CentOS 6 附的 mysql 5.1 有太多的安裝衝突。最厲害的就是用 SCL 去搞,是最符合 Redhat 對同名但不同版本的套件的管理方式。但是這太麻煩了,那 .spec 檔得改寫太多地方,不符合經濟效益;本案件並不會同時執行 mysql 5.0 與 5.1,所以沒必要。
  4. 再來一次 rpmbuild -ba mysql.spec 吧,如果人品沒什麼問題,你應該會得到成功編譯完成的 rpm 檔,會在 ~/rpmbuild/RPMS/x86_64/ 看到所有的 rpm 檔。

當然,如果還是想用 make 的話,這當然還是很好很直觀的方法。但如果你有一百台 server 要 make 做一模一樣的事情,對地球的環保節能並不是一件好事。

你也可以有自己的 Dropbox — ownCloud

很久沒寫 blog 了, 手指打字也僵化了不少, 如果下面文句有什麼不通順的地方還請多多包涵~

最近幾年 Dropbox 一類的免費服務開始流行起來了, 我想從各個 smartphone 討論區裏看到固定會有一波又一波的 “Dropbox 互助區” 討論串, 就知道有多少人愛用這種雲端的儲存服務. 但也因為免費的空間有限, 大家就無所不用其極地想得到更多免費的空間. 學生的話也許可以有很多時間自己開一堆 email 及 mac address 來衝回饋獎勵; 但是討生活的上班族大概就沒那麼多力氣搞這種把戲了, 於是付費加大空間似乎就變成是唯一的選項. 不過對我們這種技術阿宅而言, 永遠有第三個選項: 自己架一個. 只是這個選項成立的條件, 必須等待所謂的 open source 出現, 以及必須擁有對應的技術知識.

在市場上其實有很多類似 Dropbox 的服務, 例如微軟的 SkyDrive, Google 的雲端硬碟, CX.com 等等, 但說穿了你為什麼需要這麼多的服務呢? 不外乎就是因為免費空間有限, 不想花錢申請加大, 只好 <分散> 放置於這些服務…想想也是很不方便. 所以呢, 如果你真的有能力架個網站, 包括管理 Linux, httpd, mysql, 手上又有足夠的頻寬及硬碟等資源, 其實是可以依靠自己架設自用的雲端儲存服務. 這次我們就來簡單介紹 ownCloud, 一套 open source 的雲端儲存套件.

ownCloud

ownCloud 5.0 Screenshot

(圖片源自官網首頁, 這代表我沒騙你, 真的有這種 open source 耶 XD)

因為 ownCloud 是一套用 php 撰寫的服務, 所以前提是你應該

1. 對 Linux 熟悉
2. 對 httpd 設定熟悉
3. 對 php 套件的架設熟悉
4. 對 mysql 的管理略懂

本文將就針對 CentOS 6.3 如何進行 ownCloud 4.5 的架設說一次簡單的說明…真的很簡單, 因為現在年紀漸漸大了, 非常不喜歡把事情搞複雜, 安裝步驟愈無腦愈好, 愈沒有艱澀的技術介入愈好…

CentOS 6.3 的安裝

如果你已經架好一台 CentOS 6 了的話, 那我就不多廢言了 XD
不過如果你還沒學會怎麼灌 Linux 我想也不必再往下看了 XDD
所以簡單來講就是我決定跳過這個章節 XDDD

ownCloud 4.5 的安裝

你不必真的拿 ownCloud 網站上的 tar.gz 套件來裝, 那太費工了. 最快的方法就是照 ownCloud 官網這一頁的方式, 利用 yum repo 來安裝在你的系統上, 就會直接把其他所需的 rpm 套件一併安裝進來. 有沒有簡單過頭了? 我就說過我不喜歡複雜嘛, 幹嘛記一堆需要先安裝什麼 rpm 檔再來安裝 ownCloud? 就算你一開始根本沒裝 httpd 及 php 這下也就全都裝進去了, 桌頂拈柑, 輕輕鬆鬆~

對了, 至於 /etc/php.ini 你最好還要照一些其他人寫的安裝指南來修改, 例如把 php post & upload 允許值加大, 這兩個值也等於決定了你能上傳最大多大的檔案到你自己架的 ownCloud 服務裏. 當然, 你也可以用下面介紹的 [httpd 的設定] 相同的方法, 把這些本來放 php.ini 裏修改的設定值, 改在 virtual host 裏利用 php_admin_flag 或 php_flag 來做客製化宣告, 也可以. 關於大檔案的說明, 可參考 ownCloud 官網的說明

2013/04/12 補充:

其實, 如果你是 RHEL/CentOS 的使用者, 只要再加 epel 套件庫, 裏面就會有 owncloud 4.5 版可用. 但是它的相依性設定有點小問題, 如果你要用 mysql 當資料庫, 就要順便再加裝 php-pear-MDB2-Driver-mysql 這個套件才能讓 ownCloud (@epel) 正常運作.

目前我個人比較推薦使用 epel 裏的 ownCloud 4.5, 而不建議使用官方 isv:ownCloud:community.repo 來安裝 ownCloud (會變成 5.0 版), 說真的 5.0.x 真的是太多 bug 了! 自從 5.0 出來後, 一直都有災情傳出來. 以這兩天剛推出的 5.0.4 為例, 一升級馬上你的 ownCloud 就GG了, 永久進入維護模式. 雖然 5.0 版多了不少新功能, 我還是別冒險當白老鼠… 4.5 則是相對穩定很多的舊版本, 也許等等 5.1 出來再觀望大家口碑… 不過 epel 的 ownCloud 程式是放在 /usr/share/owncloud 下, 資料是放在 /var/lib/owncloud 下, 這和 isv:ownCloud:community 的放法不同. 以下的例子是我早先用 isv 時的路徑, 如果是用 epel 者請配合修改路徑…

httpd 的設定

在安裝完 ownCloud 後, 你可以在 /etc/httpd/conf.d/ 下看到一個 owncloud.conf 檔, 也會發現 /var/www/html/owncloud 下多了一堆 php 程式. 不過光這樣的話也太陽春了點, 我個人比較喜歡讓各服務擁有自己的 virtual host, 所以我在 /etc/httpd/conf.d/ 下新增了一個檔案來宣告 owncloud 自有的 virtual host:

<Directory /var/www/html/owncloud>
Options -Indexes
</Directory>

<VirtualHost *:80>
ServerName mybox.fruittea.net
DocumentRoot /var/www/html/owncloud
TransferLog /var/log/httpd/owncloud_access_log
ErrorLog /var/log/httpd/error_log
php_admin_flag output_buffering off
</VirtualHost>

加紅字的地方是官網沒特別提到的重點, 來我這兒總是會多學到一點 XD.

第一是 httpd 預設是有 auto index 的功能, 如果你不想使用者 (或不明人仕) 亂逛你網站的目錄下有什麼檔, 把 Indexes 從 Options 中拿掉是最常用的設法. (按: epel 版的在 owncloud.conf 中已經加了這行, 所以可以省略)

第二是當你在用 sync client 下載 ownCloud 的檔案時, 如果沒有把 php output_buffering 完全關掉, 則太大的檔案會吃光你 php memory limit 上限, 造成 php 記憶體不足就跑出 http 500 error 了, 最終你不是得把 php memory limit 加大到你單一檔案大小的限制, 不然就是索性像我一樣把 output_buffering 關掉, 因為我設 upload_max_filesize = 4G 所以一但我上傳過這麼大的檔案, 在下載時真的會吃光我所有的系統記憶體.
最後要提醒的是如果你想加 SSL 的服務, 那就要再安裝 mod_ssl 套件, 但這不在 ownCloud 套件的相依性必需清單內, 所以要再手動安裝進來, 然後你還需要自己產生一個憑證, 或是真的花錢去買一個.

mysql 的設定

這部份倒是不一定要做. 如果你只是自己夠宅或是想給家人用 ownCloud, 我想用 SQLite 就很夠了, 省點力氣管一大套 database 系統. 但如果可能會有很多使用者的話, 那麼用 mysql 或 postgresql 會比較好. 至於 mysql 設定倒也沒什麼特別的, 調校方面可以找找 tuning-primer.sh 這個工具協助; 對於 ownCloud 而言, 你只要先建好一個 ownCloud 專用的 database, 一個 ownCloud 專用的帳號密碼, 於 ownCloud 第一次執行時選用 (打開 advanced 選項) mysql 並指定好 dbname/dbhost/user/password 等設定, 讓 ownCloud 自己去產生 table 及資料就好啦! 有沒有很簡單? 我說的沒錯吧!

Linux 系統其他設置; 總結

哦, 以上雖然一直強調特別簡單好架, 你也別忘了用 chkconfig 將 httpd 及 mysqld 納入開機時自動啟動的服務. 對了, 最好你也把 ntpd 跑起來, 以提供系統服務最正確的參考時間.

我想, ownCloud 除了 clientsync 這個桌面端工具在即時性方面大遜於 Dropbox 的之外 (其實比起 CX.com 或 Box 已經是強太多了), 大致上已經能滿足各位 Dropbox 愛用者的需求了, 真的. 只要你家用的是光世代, 上傳 10M 以上, 又有固定 IP, 架一套 ownCloud 來玩玩絕對不會吃虧的… 阿宅們還可以好心發帳號給你想追的正妹, 教她用, 很快地你就可以開始蒐集她上傳的檔案了(大誤)… 開玩笑的, 接下來 ownCloud 5 版就會正式提供加密功能了, 使用者會更有信心使用它啦… 你想想你真的放心什麼狗屁倒灶的私人檔案都放上雲端存放嗎? 還是不覺得這有什麼風險? 嘿嘿, 這我就不在此討論了…

祝各位架站愉快~

nfs mount 新參數: nosharecache

就在剛剛操作 Linux 的 nfs mount 時, 發現不管怎麼弄都會得到該目錄 “is already mounted or busy” 的錯誤訊息.

因為是在 QNAP TS-459U 上, 我想針對 “Network Recycle Bin 1” 這個 nfs 分享 mount 到某台 Linux server 上. (天哪, 我文法好差, 這段用中文要怎麼寫才順啊?) 所以我一直以為是目錄中有空格的關係, 導致 mount 的語法有問題. 但在用 google 找了很多資料後, 發現:

Kernel 2.6.18 後, nfs mount 對於同一台 server 分享出來的目錄, 不能下不同的參數來 mount 它們. 由於之前我是用 autofs 已經先 mount 一個目錄了 (有加 wsize 與 rsize 參數), 然而我手動 mount 第二個目錄時, 並沒有指定一樣的參數, 所以發生了錯誤.

我還是把 case 實例解說一下好了
TS459U: 是一台 QNAP NAS server
ELFC61: 是一台普通的 Linux server

TS459U 有很多 nfs exports, 包括
/Public
/Network Recycle Bin 1

首先我在 ELFC61 已經先 mount TS459U 的 /Public 了, 有使用參數 wsize=16384 與 rsize=16384
然後我在 ELFC61 想要手動 mount 另一個目錄 /Network Recycle Bin 1 到 ELFC61 的 /mnt/recycle1
結果就發生了錯誤訊息, 無法成功 mount 該目錄: “/mnt/recycle1 is already mounted or busy”
起先我一直誤以為是因為 Network Recycle Bin 1 這個目錄名稱有很多空格的關係, 以致於 mount 語法有誤, 後來才發現這根本是錯誤的方向.

解決方法有二:

1. 臨時要手動 mount 的話, 可利用 -o nosharecache 這個新的參數 [mount(8) 手冊沒有提到], 可暫時避免這個問題, 但不建議使用 (原因見最後面的 nfs 手冊節錄).

mount -o nosharecache TS459U:’/Network Recycle Bin 1′ /mnt/recycle1

2. 最好就是使用當時 mount TS459U:/Public 一樣的參數.

以此例而言, 由於之前我 mount /Public 時是下了 wsize=16384,rsize=16384
所以我這次手動 mount ‘/Network Recycle Bin 1’ 也應該用一模一樣的參數, 即可成功.

關於 nosharecache 其實在 nfs(5) 手冊中是有提到的, 茲節錄如下:

nosharecache: As of kernel 2.6.18, it is no longer possible to mount the same same filesystem with different mount options to a new mountpoint. It was deemed unsafe to do so, since cached data cannot be shared between the two mountpoints. In consequence, files or directories that were common to both mountpoint subtrees could often be seen to be out of sync following an update. This option allows administrators to select the pre-2.6.18 behaviour, permitting the same filesystem to be mounted with different mount options.
Beware: Use of this option is not recommended unless you are certain that there are no hard links or subtrees of this mountpoint that are mounted elsewhere.

Windows NLB 倒底是什麼東西?

各位客倌您沒看錯, Windows NLB (Network Load Balance) 這篇文章居然被放在我 Linux 的分類下…

Windows NLB 架構

Windows NLB 架構

話說 NLB 的設定方法還真的很簡單, 在 Windows Server 的界面下, 只要點點 “新增叢集”, 設設 “叢集IP設定”, 選選 “叢集操作模式”, 就好了!

真的是這樣嗎?

不, Windows NLB 真的.不.好.上.手.又.難.懂, 不像 Linux Virtual Server 那麼容易搞懂運作原理與佈署方法. 在一個偶然的機會下, 我有幸觀摩到別人使用 NLB 來玩負載平衡…一種我心儀已久看起來好像很厲害又很方便的技術…

(這篇我做了一次 reader’s test, 某人看沒一半就點了視窗右上方的叉叉了… 所以客倌們非網路技術工程背景者, 建議您也不要服用本篇; 基本上沒什麼營養可言, 只是很大篇的抱怨文)

說 “觀摩” 是因為我對 Windows 真的一竅不通, 畢竟我是 Linux 基本教義派的… 好, 問題馬上就來了: What is multicast? 這個問題您問一百個資工資科的學生, 很多人都知道它叫 “多點傳送”, 但這多點傳送要怎麼運作? 其實翻翻教課書或網路上的文章很多都只有原理講解… 我想因為真正懂得 implementation 的人早就在靠此悶著頭賺大錢了, 哪還有時間把吃飯的傢伙寫出來分享?

Multicast 示意圖

Multicast 示意圖

在了解原理後 (說真的我還是不了解! 容後再述), 我對於 NLB 利用 multicast 這招真的有點嚇到. 其實這真的是一種反向的運用. 以往在書上看到的 multicast 的應用都是在 voice/video 方面的. 早期若是要線上收看 video, 相同內容的封包, 丟給N個特定的 clients (同時收看), 就得佔用N倍的骨幹流量, 這我們叫 unicast; “使用 multicast, 則可以節省網路骨幹的流量使用”, 既然內容相同, 何不只丟一份封包於骨幹上, 到某個分岐點後, 再散佈給特定的 clients 呢? 多棒的概念啊! 好吧, 這個概念打從 IPv4 有 Class D (RFC988, 1986年) 以來, 到今天 2010 年, 各位網民們您實際上網路生活中真的用到過嗎? 為什麼這樣難看到? 因為啊, multicast 在實用上, client 及一層一層的 switch/router 都要用到 IGMP (Internet Group Management Protocol, 網際網路群組管理協定) 來加入 multicast group, 問題是您上層 router 誰會相信您要加入某一群組的合法性? 且各個不同 ISP 彼此之間的 IGMP 是否可信任? 且 IGMP 據測非常耗 router 的 CPU 資源? 加上太多的商業因素 (講好聽是 “安全性考量”), 均使得這個超棒的概念一點都不切實際. 台灣少數(可能也是唯一)的應用例就是 “中華電信MOD” 這種封閉式 (單一ISP內) 的服務.

扯太遠了, 回題. NLB 用到的 multicast 完全不是基於這樣的精神; 上一段”經文”講的其實是指 IP Multicast, 而微軟用的是 Ethernet Multicast. 叢集 IP 仍屬於 unicast IP 的範圍 (因為此一 Virtual IP 會和您實際 servers 處在同一網段…; 但事實上 NLB 在使用 IGMP 時仍然會在 LAN 內宣告一個 class D 的 multicast IP 才能依 IGMP 加入 multicast group, 在此不加詳述), 所以 router 之間不用管 IGMP 的問題, 把從 Internet 來的 client 端丟來的單一封包 (通常應用上就是指 tcp connection request, 通常就是 port 80…) 不斷地丟丟丟, 最後只需在 server 所在網段的 LAN 內, (通常應該)由 switch 負責散發, 同時丟給叢集內所有的 servers. 這些 servers 再基於相同但官方語焉不詳的演算法來決定是哪台 server 要回應這個封包以回應這位特定 client 的 connection, 而其他台 server(s) 則會丟棄這個封包不理. 這種類似”對號入座”的過程, 都在每台主機的 kernel space 的 wlbs.sys (intermediate NDIS driver) 內完成, 唯有需要回應的 server 其封包才會正式上達一般的 TCP/IP 層級… 好像是這樣的原理. Orz. 好複雜的東西… 之所以說 “反向的運用”, 是說上一段”經文”是讓 client 加入 multicast group, 而微軟的 NLB 則是讓 server 加入 multicast group. 不管怎樣, 目的是達到了, 確實是做到了 “負載平衡” 這樣的需求. 但很快地, 又有問題來了.

NLB stack

NLB stack

2010/11/21註: 有台灣 NLB 大師 (同時也是獲微軟MVP獎項之高人) 來訊指出, 我寫 wlbs.sys 是錯字, 應為 nlb.sys 才對. 不過我把之前在 微軟 TechNet 找的資料翻出來看後 (請先看一下右圖)… 我想我文內 “intermediate NDIS driver”, 指的正是 NLB driver 那一層, 而依該資料內的某張表中的說法即是指 Wlbs.sys… 所以應該是微軟 TechNet 此份資料太舊, 或是有留一手, 試圖誤導我這種門外漢 :p

(OK, 如果再往下走, 您必須了解 layer-3 即 IP 層的 routing 方式, 不然恐怕會一知半解, 看不到問題在哪)

什麼樣的問題呢?

第一, 雖然微軟這招是用了 unicast IP 來玩 multicast: “叢集 IP” 仍屬於 class A~C 的範圍, 看來在各 router 間不會有什麼狀況嘛… 非也非也. 其實 ethernet multicast 用到的 mac address 是有個特徵可資辨識的: “第一個位元組的最後一個位元” (在寫繞口令嗎? 其實就是第一個Byte為奇數咩) 如果是 1 的話, 則這個 mac address 即屬於 multicast 封包. 事實上我們看到叢集 IP 產生的 multicast mac address 會是 01:00:5E 開頭的 (for IGMP), 好回應人家的 ARP query, 作法完全合乎規範, 但壞就壞在這裏了. 雖然各個 router 間在處理 unicast IP 是不會有問題的, 即使兩顆 router 間有用到 arp, 但也是以 router 他們自己的 mac address 來回應, 絕非叢集產生的那個 multicast mac address (01:00:5E開頭的). 很不幸, 問題就出在 “last router” 上. 依照 RFC1812, “A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address”, 所以從 Internet 來的封包, 到了最後一顆 router 上時, router 用了 arp 問說 LAN 內是這 IP 是誰在用呀? 叢集回應了, 但就因為它不能相信叢集回應的 multicast mac address, 也就不會註冊在動態的 arp table 中, 接下來它根本不知道要把這個 dest IP 丟到 Ethernet LAN 裏的哪個 mac address? 自然就在 router 內 “往生” 了… 結論就是您得說服您的 ISP/IDC 管這顆 router 的負責人, 新增一筆靜態對應 (IP 對應 mac address), 或是為您打開 “他們認為政策上很不安全的” IGMP, 這樣這個封包才會通到您的 LAN 內. 至此才打通第一道難關.

2010/10/18註: 之前在 CISCO 網站上不小心又看到這一段.
Note: Ensure that you use the multicast mode on the NLB cluster. Cisco recommends that you DO NOT use multicast MAC addresses that begin with 01 because they are known to have a conflict with the IGMP setup.
似乎微軟那邊也開始改用 03:BF:(Your IPv4 address, 剛好四碼) 當成你 NLB 的 multicast mac address, 不再是用 01:00:5E 開頭了… 此資訊供 NLB 使用者參考. 不過若 mac address 改來改去的, 我想管上層 router 的人可能會被煩死 囧rz

Microsoft NLB from CISCO

Microsoft NLB from CISCO

(OK, 如果再往下走, 您必須了解 ethernet 的 switching 方式, 不然恐怕也會一知半解, 看不到問題在哪)

第二, multicast mac address 在 LAN 很容易造成 flooding. 什麼? 問題又來了? 沒錯, 正因為 switch 的特性! 回想 switch 的工作原理, 它是在每個 port 上面記錄 “會出現在這個 port 的 mac address”, 記在所謂的 mac address table, 這樣 switch backplane 電路才會知道 switching path, 把 ethernet 封包準確地轉丟到某一個 port 去. 這是 “一對一” 的 table, 每個不同的 mac address 都只能對應到一個 port 上面. 而這是指面對 unicast mac address (00或其他偶數開頭的) 來講的. 各廠牌的 switch 對於 multicast mac address 的處理方式, 似乎都是以 broadcast 的方式來實作, 除非有 IGMP snooping 的功能 (例如一些帶有網管功能的中階 switch), 或是能直接寫死 mac-address table (一個 multicast mac address 能同時對到兩個以上的 ports 的高階 switch, 例如 CISCO 2950 系列似乎還不能直接這樣寫, 不管自動或寫死的都一定要用 IGMP 的方式…), 例如像上上圖裏 cisco switch 把某一 multicast mac-address 寫死對應到 fa2/3 與 fa2/4, 才會真正做到 “多點轉送” 而非 “塞死人不償命的廣播” 方式. 幸好若以 web server 的 traffic pattern 而言是極不對稱的流量: inbound(流入) 比 outbound(流出) 我的經驗大約是 1 比 10 左右; Flooding 是發生在 inbound, 雖然無形中增加了非叢集內其他 server(s) 的 garbage packet loading, 但還不致於造成太大的負擔. 但, 即使 flooding 的問題有解決或問題不大, 在此您可能已經又看到一個問題了: 對於叢集內的 servers 而言, 這仍然是 flooding! 這樣的 multicast 應用, 站在單一主機的角度來看, 當您叢集內的主機愈多, 真正該它服務的 connection request 比例會愈來愈低, 其他不需要它服務的封包收了都是垃圾要丟掉! 叢集愈大, 每一台 server 的 overhead 也跟著變大. 那, 如果 NLB 裏有10台的 web servers 呢? 這時若從 switch 的角度來看, 這些 server 的 inbound 與 outbound 流量已經差不多高了.

NLB Switch Setup

NLB Switch Setup

不只是我在抱怨, 隨便像國外的網路廠商也在幹樵: “看…這就是微軟的搞法…把一台好好的 switch 搞成 hub 了!”

(PS: 以上看不懂的話, 要嘛就是我寫得太爛, 要嘛就是您得先上上 CCNA 之類的課… 其他疑問的話不妨按 “上一頁” 或直接關掉 browser 最快, 因為您可能不是吃這行飯的…)

寫到這裏, 我真的愈來愈糊塗了! 為什麼要弄得這麼複雜, 這麼麻煩, 製造這麼多新奇古怪的問題? 以我近年來最常使用且最 low-tech 的 吃飯傢伙要保密吃飯傢伙要保密 而言, 單台古董級 DELL PowerEdge 1850 (Dual P4 Xeon 2.4GHz) 拿來做 load balance 前導機 (透露一下: 使用 NAT 架構, 這樣我可以順便拿它當防火牆; 現在不妨給它起個綽號叫”小玩意兒”好了), 可以達到 250 418 Mbps (2010年11月的記錄) 的流量; 且這還只是未開 jumbo frame 的效能ㄛ (因為我是個很懶得調校效能的人 XD), concurrent connection 數高達好幾萬, 可以記超過 10 萬筆 connection status, 完全沒用到什麼 multicast, heartbeat, IGMP…blahblah 的艱澀技術, 群內各 web server 不必只是為了叢集問題而刻意多加網卡, 不必多加 driver, 不必多吃 mac address 不必多加 IP, 更不會造成 router/switch 或其他 server 的額外負擔, 更不用去找您的上層 router 求管理者加 static arp entry (通常這已經有點違反他們的安全政策了); 而分配 loading 的演算法也多達八九種, 完全透明公開任君挑選. 重點是也不用管屁股後面的 server 用的是什麼 OS 什麼 AP, 您愛用 WS2008 或 RHEL5 或 IIS7 或 Apache 都隨便您啦…有本事您可以養兩個 team 寫兩套平台: URL schema 一模一樣但一套是 IIS/ASP 另一套是 Apache/PHP 的 heterogeneous/hybrid/whatever architecture 出來, 我照樣給您搞出 load balance! 而我這些 “小玩意兒” 之間更可以做到雙機間 failover (一台上線搭一台備用), 甚至多機間 failover (例如兩台上線搭一台備用, 甚至兩台以上上線同時也互為彼此間的備用).

可能唯一的缺點就是這 “小玩意兒” 因為是 NAT 架構, 本身會變成是 bottleneck? 不過, 看, 這種規格的”小玩意兒”賣到市場上每台單價少說也是上百萬等級的, 您試試看拿一台 DELL 1850 的錢去買不管買到什麼鬼東西, 保證流量或session數不到一半甚至只要十分之一有的就馬上變趴趴熊了! 如果真的想提高流量瓶頸限制, 方法實在是很多, 不管是買台更暴力的機器, 或是分散成好幾台…都是很容易的; 我腦袋裏已經存有很多種 configurations 都可以辦到, 只是要看實際整體網站的大架構來加以運用. 我在海峽兩岸不同的機房都有佈置這”小玩意兒”, 其中一地的”小玩意兒”背後放了三四十台 servers (至少2/3都是對外的 web servers), 另一地的”小玩意兒”更特別的是接了五條 uplinks 走不同的路由, 以服務來自不同ISP的上網使用者 (感謝 Cisco C3750G 的加持, 完全不用多加網卡), 當然背後也是有超過 20 台的 servers 在支撐兩三百M的流量… 各位要不要想像一下同時20台30台 web servers 加入 Microsoft NLB 同一叢集的”盛況”呢? 就一顆 24 port 的 switch 而言, 不管有沒有開 IGMP snooping, 都等同於當 hub 在用了 (multicast 等於 broadcast 了!) 而且因為20台30台的關係, 你會在 switch 上看到各埠的流出流量 (即 web server 的 inbound) 比流入流量 (即 web server 的 outbound) 高出許多!

(拷, 我若一年賣一台這個”小玩意兒”的話…我也能年薪百萬ㄟ…一年賣兩台就年薪兩百萬了… 無奈老闆們沒看到牌子沒人會信, 要掛上 CISCO 或 Microsoft 才有說服力 orz)

其他例如 Piranha 或 Ultra Monkey 相信也都是 Linux 界人仕耳熟能詳的叢集工具. 當然, 您也可以土法鍊鋼直接玩 LVS: Linux Virtual Server NAT/TUN/DR 模式等等, 但不免需要親自做一些比較繁雜的設定, 甚至還要自己在每台 server 上把什麼 arp reply 的功能關掉等等… 但以上可能都比 Microsoft NLB 簡單多了 (不過在我來看 UltraMonkey 也差不多是天書了)

至於 Windows NLB 倒底是什麼東西? 工作原理是什麼? 一開始我真的很想了解, 而且我真的開始了解了, 但在了解之後我又不太想花時間再深入了解了… 我是個很討厭不求甚解的人, 我花了很多時間 google 關於 NLB 的東西, 得到的幾乎都是文宣等級或教科書似的文章. 微軟陣營的論壇或民間討論區, 沒找到有誰或哪篇文章主動把問題點出來, 更別提分享解法的了. 最後還是在 CISCO 陣營, 不管是官方文件, 或是討論區裏, 都有點出 NLB 的問題與 “workaround”, 多可愛啊.

後記: 後來我又找了一堆資料, 加上實地的觀摩與嚐試, 上述一些觀念多少有些需要修正與進一步細述的地方, 尤其是問題處理方面, 我已經得到十足正確的解答了; 總之, 我的結論還是, stay on Linux :p

筆記: CentOS 5.2 編譯 pttbbs source code 的竅門

話說果茶的 bbs source code 已有十年之久, 若是要在 CentOS 5.2 上 compile, 只會得到一堆 error message. 如此一來就面臨了兩難的狀況: 倒底果茶系統要怎麼升級呢? 是要放棄安裝 CentOS, 還是要放棄 BBS?

怎麼可以這麼快就放棄? 所以又再花了些時間, 發現只是不夠有毅力去解決問題…

讀完 bbs 的 README or INSTALL, 步驟什麼都照做, 像是 libhz 也裝了, 還是有問題?

其實之所以 compile 不出來, 實在是因為 CentOS 5.2 少了好幾根筋:

  • pttbbs 酷愛 pmake, 但 CentOS 5 沒有這東西. 最快的解決方法就是去抓 CentOS 4 的 pmake 1.45-16 rpm 來裝. 因在 CentOS 5 上似乎無法靠自己 build 這個 rpm…
  • CentOS 的 pmake 套件中還少了一項 lorder.sh, 這是 pmake 的 bsd.lib.mk 中指定要用的 shell script 工具, 少了它就無法正確 ar 出能用的 lib .a 檔. 這可以去找 ALTLinux 的 src rpm pmake-1.45-alt4.src.rpm 抓下來 install 後, 可在 /usr/src/redhat/SOURCES 裏找到 lorder.tar 及 lorder-alt-tmp.patch, 解開 tar 並運用該 patch 檔, 就可以得到正確可用的 lorder.sh, 再把它 cp 到 /usr/local/bin/lorder 並使它可執行.
  • ccache 套件也要安裝

如此一來就能順利 compile 出來了. 接下來就只是大苦功: 把舊 BBS 的資料想辦法轉換到新 BBS 上, 理論上這只需要參照兩邊的 data structure 就可以解決才對, 寫寫 C 的小程式還可以吧.

CACTI 研究筆記 – 0.8.7c 無法 export graph to csv?

是這樣的, 其實並不是 CACTI 0.8.7c 的問題, 而是我在某 CentOS 5.2 的機器上安裝 rpmforge 提供的 CACTI rpm 套件, 目前是 0.8.7c 版. 但安裝後才發現, 對它的統計圖按 export to csv 後下載到的表格沒有任何一筆流量資料, 只有時間起迄都是 1970 年.

到 CACTI 官方討論區找到有兩位網友也遇到這問題但無人出面解答. 這害我不得不開始自己 debug. PHP 我還OK, 可是看到一堆程式碼我就暈了… (也沒有下決定真的要 debug), 於是我先拿 0.8.7b 的碼蓋掉, 無用! 想了很久, 還是乖乖看程式碼吧. 在 debug 一陣之後, 發現 rrdtool 並沒有真的把資料餵進某隻 php 程式裏的 function, 以致於整個流量的 array 是空的. 最後我才懷疑到 rrdtool 的版本問題. rpmforge 現下提供的 1.2.29-1, 我挖出 1.2.27 的來 downgrade, 果然! 正中要害.

yum update memory error (CentOS 4)

也是筆記一則
遇到一次很麻煩… 遇到第二次叫健忘, 這時就只好靠自己的日誌了

yum 其實有用到 python 及 sqlite 套件
但它的 rpm 檔卻沒有正確設好版本上的相依性
如果你在 CentOS 4.x 或 Fedora 舊一點的版本上要獨立升級 yum 套件 (有些人有先升級 yum 的奇怪習慣)
就會發現, 怎麼 yum 再來就跑不動了, 會冒出 memory error 的錯誤訊息
再利用 top 指令觀察記憶體使用變化, 會發現記憶體就真的一點一滴地耗盡到乾
這下 yum update 再也不能用了, 怎麼辦??上網找了一堆, 發現大家只點出 sqlite 版本也要跟著升級
我照著做了, 把 CentOS 4.7 裏的 sqlite rpm 檔挖出來手動更新
結果還是 memory error

原來是漏了 python-sqlite2 也要一併升到對的版本
所以連帶整個 python 套件也要一併升級才對

CACTI 研究筆記 (前言)

CACTI

CACTI

之所以開始研究起 CACTI 並非我自己工作上的需要, 我都偷懶用老古董 MRTG 來畫流量圖. 但我哥他卻十分需要 CACTI 的流量合併 (aggregate) 功能, 無奈他認識的工程師全都 囧rz 於這種比較進階的用法. 最後他上 SourceForge 找到一個提供 CACTI 管理咨詢的外國阿宅, 費用是 US$50. 雖然不多, 但我想來想去怎麼都不需要花這個錢… CACTI 真的有這麼難學嗎??

於是我開始在自己的環境裏先灌了一套 CACTI 0.8.7b 來用 (需搭配 PHP & MySQL), 發現還蠻簡單的… 而 Aggregate 的功能可以利用一套 (就叫 aggregate) plugin 來幫助你輕輕鬆鬆勾選數張流量圖合併為一張總圖. 玩了一兩天, 就開始覺得奇怪了, 明明都這麼簡單, CACTI 倒底有什麼難的??

果然, 玩了幾天問題慢慢都跑出來了…難是難在接下來的部份

1. 這 0.8.7b 版還有不少 bug, 包括 graph export to excel 的問題, graph export to static page 的問題, browser 相容性問題

2. aggregate 的功能僅止於合併(堆疊), 不另外幫你顯示 “總合” 這些數據

3. Weekly, Monthly, Yearly 沒有留存舊時間點的五分鐘平均, 無法拿來用於 IDC 計價

4. 尚未支援 RRDTOOL 1.3

針對這些問題, 對應的答案如下:

1. 基本上 CACTI 的 release 非常慢, 大概半年才一次. 若要處理 bug 的問題, 可能只能先去挖人家的 svn 看有沒有新版的單隻程式, 再不然就請自己 debug 囉.

2. 不管是總合或是其他數據上的功能, 你要自行熟悉 CACTI 及 RRDTOOL 裏的一些細節, 包括 CDEF, RRA 的定義新增, 更重要的是 “變數” 的運用

3. 這是在考驗你對 RRA 的觀念是否正確.

4. 如果你的 Linux 上的 RRDTOOL 為 1.3 版, 必須要降版本為 1.2

其實如果是有心要靠自己學好 CACTI 的看倌, 我想上述這些問答已經夠用了. 這幾個禮拜找資料找得有夠痛苦… “CACTI 中文研究站” 沒有什麼資訊, 連 CACTI 官網的手冊都十分地陽春; 我也是最近N個晚上花超多時間翻閱官網的討論區 (痛苦的是大家的英文都不太好), 漸漸得到解決問題的答案或提示, 但後來發現其實你該知道的都在那超陽春的手冊裏面…

我想這一份研究筆記的每一次點擊應該也值 US$50 吧 XD

VMware Server 2.0

VMware Server 2.0 推出了, 做了不少改變, 但是我都不喜歡.

上個禮拜分別在 Windows 及 Linux 上安裝了新推出的 VMware Server 2.0, 哇, 光是下載就花了不少時間, 因為每個安裝檔都有500MB以上. 好肥大.

可能唯一的優點 (但我認為是缺點) 就是捨棄專屬的 VMware console 軟體, 全心全意改走 web 界面 (VI Web Access), 而 virtual console 也是開 browser 加 plugin, 感覺上和 DELL DRAC4/5 很像. 1.0.x 版的 console 無法管理 2.0 版的 virtual server 了, 所以如果你還有 1.0.x 版的要管理可能就得留著用. 這樣一來, 你的 firewall 不只要開 port 902, 一定還得加開 (我記得是) 8222/8333 好走 http/https protocol…

在 Windows 上安裝還遇到一件鳥事. VMware Server 2.0 有一個物件, 會把 “切換使用者” 的系統功能關掉, 而且還不准你打開. 對於有習慣 “長時間離開電腦時會切換使用者” 的我而言, 唯一的選項就是 uninstall VMware Server 2.0 囉.

所以我又用回 1.0.7 了, 好歹瘦多了, 安裝選擇彈性大, 不一定要灌 mui, 不用像 2.0 一大包你也不知道有哪些玩意兒就都灌進去了.

HostRAID sucks

最近遇到 server 內建 ICH9R 的 HostRAID 還真是機車…

(非網管與Linux阿宅者可以按上一頁回去了, 這篇是純技術的日誌)

其實我一直都很怕碰到 HostRAID 這種 “偽” RAID. 因為我對 RAID 是從玩 DPT SCSI RAID Controller 開始熟悉起來的; HostRAID 與 Hardware RAID 兩者等級真是差太多了. 無奈因為老哥的客戶為了省錢, 只好挑這種東西賭一把. 結果當然是賭錯了, 賠掉的是 deployment time (=cost).

這次遇到的 HostRAID 是 Intel ICH9R. 它在 RHEL4 的 Linux Kernel 2.6 來講並不是沒有支援, 而是視為 ICH9 (non-RAID), 用的是 ahci driver. 所以不管你在 BIOS 裏選了用 Intel 或 Adaptec 模式開 RAID, 也在 RAID 管理界面中建好一個 RAID volume 了, 但一跑進 Linux 看到的還是分開的一顆顆硬碟… 真是太ㄅㄧㄤˋ了!

Well, 照 server 官網的下載來看, 必須改用 adpahci (Adaptec AHCI?) 來驅動 ICH9R. 這東西有沒有 open source 呢? 其實是有的, Adaptec 自己有 release 一個詭異的 OpenBuild 套件. 但這世界上有多少 ppm (哈哈, 時下用語耶) 的網管能像我一樣把 kernel 沒有的 driver 硬塞一個新的進去呢? 其實本人也老了, 沒力氣做這些 “年輕就是本錢” 在做的苦工(練功夫)…

找了 Adaptec 或 server 官網, 甚至也跑到其他廠牌 (例如HP) 找也是使用 ICH9R 的 driver download, 都只有零星地為一些 Linux distribution 出 driver module, 十分不完整, 例如只出 RHEL4 (up to u4 only, 現在人家都已經 u7 了呀!!). 而且也只出給安裝CD時附的 Kernel 版本, 一但跑過像 yum 這類的更新工具後, kernel 版本一升級, 就又出包了.

在此不禁要對 server 廠商的 PM 大大抱怨一番. 有膽拉這種 HostRAID 進主機板來降低成本, 就要有擔當地把各式 driver 版本準備地整整齊齊的給 user download. 凡是這些主流的 distribution 一有新的版本, 它們的 kernel 一有新的版本, 就要乖乖地生一份 driver (kernel module) 出來. 不然你就挑那些 kernel 本來就內建 driver 的 hardware 來用, 別自找麻煩也好. 說”內建”事實上這只是 hardware vendor 和 linux kernel development 有著很好的配合, 例如 3ware. Adaptec 的 driver 並非沒有放進 kernel source code distribution 中, 但放進去的是具有歷史的 aic7xxx 這個老牌 driver. 你知道光是 aic7xxx 我們玩 Linux/FreeBSD 的人為它奮鬥多久了嗎? 至少十幾年了吧, 從 AHA-1520(ISA)/2842(EISA)/2940(PCI) 一路玩到現在的 (其中也經歷了 Quantum SCSI HD 的 Tagged Queue Command 掛點事件). 而 Adaptec 自己出的 adpahci OpenBuild 說是寫了 shell script 來幫你建你要的 driver, 但它並不符合我們對 Linux 套件的管理精神 (rpm, deb), 變成回到十幾年前自己努力 compile kernel 的時代 …我扯遠了…

雪上加霜的是, Frak, 我遇到的這台 server 板子上唯一的 IDE 晶片居然是 ITE Tech 的 (PCI VendorID:DeviceID 為 1283:8213). ITE這家的IDE晶片幾年來明顯一直都沒被放入 Linux kernel 中的標準 IDE/ATA 支援, 連 Windows 幾代了也都懶得內建它的驅動程式, 原因是什麼在此不多加猜測. 更 Orz 的是, 這台 server 的光碟機就接在這個晶片提供的 IDE 埠上. 利用OS安裝光碟開機 boot 完後的第一件糗事就是 “找不到光碟”, 請問是要怎麼繼續安裝呢? 改用 USB 光碟當然就沒這問題了, 那這 server (1U的) 內建光碟是建心酸的嗎? 還是要透過軟碟把 ITE 的 driver 載入呢? 但, Frak, 這台 1U 的 server 並沒有內建軟碟機啊! 我又要罵 PM 了, 真是沒腦袋的設計, 東西設計出來有 sample 後你都沒親自下手灌過OS嗎? 搞兩個一點都不實用的 hardware components 在 server board 上, 給 IT 人員找麻煩, 別指望人家下次還會買你家的東西…

後記: 唯一能讓 HostRAID 有作用的工具是 dmraid, 但您可能要查一下你所使用的 Linux 套件是否有提供, 以及它提供的 dmraid 對您的 RAID level 是否有支援. 總之是一整個麻煩, 唯一的好處就只有省點小錢而已. 以筆者目前在用的 CentOS 5.4 提供了以下支援性:

asr : Adaptec HostRAID ASR (0,1,10)
ddf1 : SNIA DDF1 (0,1,4,5,linear)
hpt37x : Highpoint HPT37X (S,0,1,10,01)
hpt45x : Highpoint HPT45X (S,0,1,10)
isw : Intel Software RAID (0,1,5,01)
jmicron : JMicron ATARAID (S,0,1)
lsi : LSI Logic MegaRAID (0,1,10)
nvidia : NVidia RAID (S,0,1,10,5)
pdc : Promise FastTrack (S,0,1,10)
sil : Silicon Image(tm) Medley(tm) (0,1,10)
via : VIA Software RAID (S,0,1,10)
dos : DOS partitions on SW RAIDs

所以你的 HostRAID 有支援的 RAID level, 在 dmraid 上沒支援到的話也是枉然哦