不得不在 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 做一模一樣的事情,對地球的環保節能並不是一件好事。

My Giulietta 領牌後的工程 – 隔熱紙

阿茱來貼隔熱紙

通常買新車貼隔熱紙這種事都是在交車前後由業務幫你處理到好的,但是因為我的阿茱是自辦進口,只好等正式領牌後自己找店家貼了。

我找的是已對於貼前兩輛 Giulietta 有經驗的「北極星」,而這家店在網路上也得到不少好評,所以也沒什麼好挑的了,剩下的就是要選什麼隔熱紙貼而已。大約四個小時完工。要說這家店有什麼缺點的話大概就是店裏菸味太重了,應該是老闆為了減少室外灰塵進到施工區,所以通風還蠻差的。除了菸味外,更重的味道其實是洗髮精,因為老闆為了追求施工品質,除了使用RO過濾水,更用上洗髮精代替一般店家使用傳統洗潔精(例如沙拉脫),所以完工後車上大概就這兩種味道好幾天甚至超過一個禮拜,然後車上(內裝)會有些地方黏黏的,只好等洗車時再來處理了。但就「貼隔熱紙」這件事本身的完工品質來說,確實不錯。

為彎道而生的藝術品 (2) – 車色篇

選車, 如果選好了車款, 最大的問題就在於顏色與配備, 尤其是顏色.

Alfa Romeo Giulietta 的車色其實不多, 主要分為黑/白/銀/灰/藍/紅, 打從一開始我想選的就是紅色, 但是, 當紅色有三種可以 “郵購” 的時候, 那就很頭大了 XD 你要怎麼相信人家的 DM 或照片, 甚至你的螢幕顏色正不正確?

紅色有哪三種呢?

  • Alfa Red: 這是最經典的 Alfa 紅色, 代號 289
  • Metallic Red: 所謂的鐵紅色, 代號 106, 其實比較像是粟紅色, 但因為烤漆比較特殊, 價格也就比 Alfa Red 貴了一點
  • 8C Red: 這個紅色要怎麼形容呢… 總之就是 Alfa Romeo 8C 主用的一種紅色, 價格是所有烤漆選項中最貴的 (另兩種紅色的三倍多), 代號 134.

這三種紅色各有各的特色, 但老實說放在網站上的照片, 幾乎很難分辨它們的差異. 我花了很多很多的時間在英國的 alfa owner 網站上看一堆車主拍的愛車照片, 包括各種燈光條件下的比較, 諸如大太陽底下, 路邊, 夜晚的戶外, 地下室停車場等等. 很有意思的是, 有時我會把 Alfa Red 與 8C Red 搞混, 但有時卻把 8C Red 與 Metallic Red 搞混. 在 Catalog PDF 檔裏看到的, 8C Red 是最淺的紅色, Metallic Red 則是最暗的. 但是在很多照片或影片中又覺得 8C Red 和 Metallic Red 一樣暗, 你看我會不會十分錯亂? XD 可能是因為太貴了, 8C Red 的車主可說是少之又少, 我在 alfa owner 上只找到過兩輛的照片, youtube 上也只看過幾輛的影片, 參考值真的很有限. 然而就是這份特殊性愈發引出我對它的興趣, 最後我在看了一張車主拍 Giulietta 停在地下室的照片後, 就立刻決定是 8C Red + SuperClassic 18″ 輪圈了, 因為那紅色的色澤真的是太銷魂了, 再加上經典的 SuperClassic (台灣 Alfa 車友們俗稱它 “五燈獎”) 輪圈, 我只能說我盯了那張照片好久啊!

再來就是選擇其他規格配備了, 相比之下可說是一點都不難: 我要選的是 1.4MA TCT, 十分確定; 再來凡是看到喜歡或覺得用得上的配備, 都選! 例如換檔快速撥片, 倒車雷達, HID 等等… 免得到手後總覺得少了什麼而在那邊後悔好幾年, 不值得省這種錢. 但真的用不到的就別選了, 例如天窗, 電動折疊後照鏡及座椅加熱功能都是我用不到的.

但是在逛了「郵購網站」(其實是德國的中古車網站)一整週下來, 發現根本找不到我合意的. 首先就是紅色車真是少之又少 (黑色及白色是最容易找到的), 更別提什麼 8C Red 了! 就算有紅色的出現, 其配備也和我要的差了不少 (例如換檔撥片及 QV-Sportiva Pack). 所以, 不等了. 2013/1/19 終於整理出我要的規格配備表, 寄給了力佑廠長請他直接幫我想辦法向原廠下單.

Alfa Romeo Giulietta

Alfa Romeo Giulietta @ 基隆海關

(待續)

PS: 事後證明, 在 mobile.de 上, 這半年來只出現過兩台配 8C Red 顏色的 Giulietta 1.4MA TCT, 而且一台沒照片 (不準), 另一台 99% 都符合我要的規格配備, 似乎是被秒殺了 XDD 所以當時我只等了一週就決定直接訂製, 是正確的決擇.

為彎道而生的藝術品 (1) 前言

哇, 好幾百年沒有新增文章了耶, 自從開始使用 FB 後, 幾乎就沒再在自己的 blog 上寫些什麼了.

但是 blog 還是有 blog 的好處, 那就是, 永遠都很容易找得到, 如果你是想寫點什麼日記之類的; 寫在 FB 上過沒幾天就很難 “回顧” 了, 更不用提過了一兩年後有多難找了.

這次我就在自己的 blog 上聊聊車子的事吧!

Alfa Romeo Giulietta

Alfa Romeo Giulietta @ 基隆海關

2012年末, 因為我看到不少 Toyota 86 路上滿街跑, 難免心癢癢的, 所以 2012/12/31 一邊等著倒數, 我在 FB 上就聊起了 Toyota 86 與 Subaru BRZ 之間的差異, 同時調侃一下 VW 的 DSG 閃死問題, 也順便抱怨 Peugeot 這幾年的車款愈做愈沒趣 (那時還沒看到 208 不予置評), 沒想到這個討論串居然演變成勸敗文…大家以為我要換車了, 就熱心推薦了不少車款給我參考, 也包括了某人很喜歡的 VW Scirocco

當中有一篇某遊藝館網友的推薦, 著實有些破天荒 (或者說意外), 因為, 一來該汽車品牌在台灣早就沒有總代理了, 保固及維修問題恐怕是每一位買新車的準車主最介意的事. 不過就在我深入了解該車款的各項規格後, 我開始心動了. 它的帳面規格並不如 Toyota 86 或其他新款日系跑車來得亮眼與平價, 也沒有德國雙B或是VAG小剛砲那麼猛烈, 但是, 它, 不, 應該說, 她, 很漂亮, Alfa Romeo Giulietta. 但這種感覺就有點像要娶個外籍新娘, 卻只能先從照片及身高體重三圍來決定是她, 不像那些車 (例如雙B/A3/Golf/Scirocco/86) 在台灣早就滿街跑了, 高矮胖瘦美醜膚色多少心裏有譜. 就在心中猶豫之時, 我在 2013/1/10 和力佑汽車保養廠廠長聯絡上了, 更找到了全台灣第一位以 “郵購下單” 買了一台鐵灰色 Giulietta 的車主 L 先生, 讓我得以一睹 Giulietta 實車的樣貌.

說到 L 先生, 我一定要先大力感謝他, 因為他不但很熱情地把 Giulietta 開來給我們看, 而且還很大方地要我們自己開開看, 然後還會在旁邊叫: “怕什麼, 油門踩到底啦!” “吼! 這個彎可以再快一點, 你開太小心了” 你聽聽, 碰到這麼好的試車(誤)機會, 我還能客氣嗎? 就這樣我和某人輪流各飆了半小時的快速道路…

試完回來的當下, 我和某人就暗下決心非她不可了, 哦, 當然不是指 L 先生的啦, 而是自己再到相同的 “郵購網站” 去挑選自己合意的 “新娘”. L 先生自己不知有多麼愛他的 Giulietta, 才剛買沒半年怎可能賣呢! 不過 L 先生敢這樣 “郵購” 也是因為他工作常跑歐洲, 早就看過實車了. 拜 L 先生之賜, 我和某人也有幸看過且開過實車了. 唯一的問題是, 鐵灰色並非我們家的菜 (回頭看看我家的藍色 206 及綠色 307 就知道了), 所以如果要挑選其他顏色來訂, 那一樣也是 “郵購” 的意思 XD 而就在我試車的同時, 也已經有一台白色的 Giulietta 坐在開往台灣的貨船上囉, 而白色 Giulietta 的車主 T 先生…就是在開過 L 先生的 Giulietta 後, 毫無懸念地放棄了 M-Benz A-Class 或 BMW 1-series 的選擇了~ XDD 你看看 Alfa Romeo 應該要給 L 先生多少業務獎金啊!

於是, 我就開始在 suchen.mobile.de 這個德國購車網站上開始我的尋車之旅…

PS: 所謂 “郵購” 呢, 就是看看 DM 或網頁, 就下單了 XDD

(待續)

你也可以有自己的 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 版就會正式提供加密功能了, 使用者會更有信心使用它啦… 你想想你真的放心什麼狗屁倒灶的私人檔案都放上雲端存放嗎? 還是不覺得這有什麼風險? 嘿嘿, 這我就不在此討論了…

祝各位架站愉快~

EZLINK = EZDEAD

EZLINK 全系列產品大概都是地雷無誤, 不管是 SLC/MLC 猛操一陣後都很容易死機, 最後就是送修重新 reset firmware (不知道是不是 cell 的 error rate 太高, 累積爆表後 firmware 就鎖死了==>待送修 orz)

送修的同事看過 EZLINK 工程師的”修法” 似乎就是重灌 firmware 的樣子…是要 reset counter 嗎 XD

總之, 目前累計”成績”如下; 以下這些 EZLINK 產品都是我親手買的
EZLINK SSD SLC 64GB: 買六顆送修過兩顆
EZLINK SSD MLC 64GB: 買三顆送修過兩顆
EZLINK BlackHawk USB3.0 SLC 隨身碟 16G/32G: 共買三隻, 全都要送修

回修率是多少我已經懶得算了, 至少有 50% 有吧 (怒)

看, 支持 MIT 有屁用, 這什麼鬼東西還有臉要我們支持!? 大家直接把 EZLINK 列為拒絕往來戶吧. 主控晶片再強有屁用, 強調有 SLC 有屁用, 結果還不是用沒幾下就掛掉一大堆, 那倒底是死在爛 flash 還是鳥 firmware 就不得而知了

我用過一堆 flash 類的產品, 從來沒遇過回修率這麼高的牌子.

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, 果然! 正中要害.