塔斯薰衣草小熊台灣漂流記

 

旅途,總是會有驚喜!
小編去年在澳洲爬爬走時,不經意的到了塔斯瑪尼亞島,
是個大台灣兩倍的島,人口卻只有50多萬人。

此塔島有一個非常有名的景點,
就是薰衣草莊園Bridestowe Lavender Estate,
這裡有很火紅的伴手禮:薰衣草小熊。
網路都還有代購:
http://www.pcstore.com.tw/haru/M15358522.htm
2016-06-30_132024

繼續閱讀「塔斯薰衣草小熊台灣漂流記」

企業級 SSD 這幾年來又有長進

由於最近又到了公司汰舊換新的時間點,這次我好奇了看了幾份廠商的報價單,意外的發現某張報價單上出了 SSD 的型號

1

最後面出現了 PX04SH 的字樣,再次好奇餵估狗看看,沒想到這規格還真是嚇人,4K random read 可以到 270K IOPS,對照一下之前從 RAMSAN 轉換到 SSD 的心得文,那時候使用 DDR2 的 RAMSAN 也才號稱 600K IOPS,沒想到過沒幾年,這樣子的一棵Toshiba SSD 也可以有 270K IOPS 的表現了,這意思豈不是說如果我拿 6 顆 PX04SH 做個 RAID 5 (RAID 5 不安全,這裡只是舉例),讀寫佔 70%  的話,計算出來就會超越過去的 RAMSAN 了?!

再繼續發揮我的估狗力,找了這幾年來我們可能用過的企業級 SSD 型號 (怎麼都是 Toshiba 的?!),發現這些還都有人測試過

型號 帳面速度 (4K IOPS) 實測報告 (4K IOPS) 實測報告 (8K IOPS) 參考
MKx001GRZB
(SLC)
讀: 90K
寫: 16K
讀: 95K
寫: 16.8K
26.3K 參考
PX02SM
(eMLC)
讀: 120K
寫: 30K
讀: 112.4K
寫: 28.4K
讀: 41.1K
寫: 28.4K
參考
PX04S
(eMLC)
讀: 270K
寫: 125K
讀: 306.8K
寫: 99.3K
讀: 211.8K
寫: 52.4K
參考
(9W mode)
  • 老實說, 8K 的測試方式我不是很懂,只看得出來用的方法不太一樣,請自行參照表格後的連結

Wow,比我們第一代用的 SSD 的 4K 讀寫都快了 3 倍以上,其中可能有些是來自於 SSD 本身速度的長進,絕大多數應該也是拜 SAS 12Gbps 所賜 (MKX001GRZB 時代只有 SAS 6Gbps)。只不過看到這個數據之後,突然想到我們之前還拿著兩種不同的 SSD 版本來混插,實在是一種把 LBJ 叫來和我們職籃一起打球的概念了,以後應該要針對這幾種不同的 SSD 版本做個明確標示,不然有了 NBA 球員卻只打國內籃球,多划不來。

  • SQL Server 預設應該是一次做 8k 的讀寫,而且不能自己修改,所以用 SQL Server 的人理論上要重視 8k 的讀寫 IOPS
  • Oracle 看起來可以自己調整,所以要請教一下你的 DBA 看你們通常是設定成多少

其實這幾年來,網路上一直有人在抱怨 SSD 的壽命越來越短,從可以 10 萬次讀寫的 SLC 變成最多 1 萬次存取的 MLC,現在又從 MLC 變成只有千次存取的 TLC,還有很多人跳出來證明說自己之前 SLC 用了多久都沒事,現在換 MLC 或 TLC 就人品爆發云云的,所以我本來也是一直對這一點很感冒,所以當廠商從去年提到現在已經不生產企業用的 SLC SSD 時,我們也是緊張了老半天,生怕這些 eMLC SSD 哪天不乖乖,我們就 GG 了。只不過後來拿了廠商的工具去看,卻發現這些三年前的 SLC SSD 個個都是 100% health:

2

當然我也不清楚這是用的少的關係,還是廠商的工具有修修臉的功能,把健康度修美了(如果是這樣子的話我想我們就 GG 了),但如果我們實際上也用不少,廠商的工具也是正確的話,那這個 SSD 還真是太耐用了,比傳統硬碟都要耐用許多(第一次用是三年多以前,到現在全部都還在役,有少數 SSD 的健康度變為 96% 或 98%),也難怪廠商現在都要改推 eMLC 了,因為 SLC 根本就很難壞(企業級的 SSD 都會做所謂的 over provisioning 備用空間,這顆 200GB 的硬碟實際商應該是 256GB,不見的那一塊應該就是拿去做備用空間)。

不過也請大家別聽我在上面唬爛,以為企業用 SSD 真的就不容易壞,目前在沒有確實實證證據之下,還是請大家都能:

  1. 該更新 firmware 時就請安排測試並更新,消費級的 SSD 常聽說 firmware 寫不好導致壽命不佳的,我相信企業級的也該依此觀念做定期更新
  2. 自己訂一個健康度標準,並確實監控它,例如可以定 SSD 的健康度到了 80% 後,或使用滿 N 年之後,就移出關鍵應用(eg. DB) 之外

其實我在寫這篇文章之前,還真沒想到 SSD 在這幾年間還能有這麼大的進步,我一直以為儲存裝置下一次再有大規模的進展,會是在 Intel 和美光的 3D XPoint 市場普及化之後 (3D XPoint 據說年底或明年初上市,普及化不知道要多久),沒想到自己沒注意到 SAS 12Gbps 的出現,所以這顆去年就上市的 PX04S 一直到現在才被我看到,也說明了 SSD  在這幾年來都是高速的成長,不管是速度上還是價格上,如果你還在觀望是不是該採用 SSD 在關鍵應用上的話,看了我們用了三年以上的經驗後,是不是也應該要嘗試一下了?

註:企業級的 SSD 價格估計該是家用級的 10 倍以上,別跑去原價屋或 PCHome 上看到產品名稱上有個「企業級」三個字 就去買來用,到時候出狀況可別怪到這兒來啊

Elastix (Asterisk) 通話中偶發斷線的問題 – 工程師的心路歷程(慶祝工程師節)

今天是工程師節,為了紀念我上週六花了三個小時只改了一行設定,所以寫了很多廢話,如果只是想找解答的朋友,請直接翻到最後面就好

我們公司是個不愛用桌上型電話的公司,從最早開始我去新加坡上班時,就發現他們不是每個人都有一台電話,除了幾位必要的客服、或行政人員之外,其他人都是一個小區域裡共享一支到兩支桌上型電話,大家若要彼此聯絡時,首先用的是  Skype (以前是 MSN),再來就是直接打手機了,也許是公司業務特性,或者是新加坡的手機費率不貴的關係,才造成了這個景象。

所以當台北要設立辦公室時,我們就選擇了 IP-PBX 的方案,而且還不是用貴森森的 Cisco 或 Avaya 之類的,而是在拍賣上找了一台二萬出頭的 MyPBX ,沒想到剛過保一年他就壞了,剛好當時又聽說我們的某大客戶也是自己拿 PC 裝 Asterisk 來用,於是抱著輸人不輸陣的心態,去淘寶上買了些相容電話卡回來,開啟了我們 DIY 之旅。

老實說,這套 IP-PBX 的系統並不太受我們行政青睞,舉例來說,沒辦法像傳統交換機(我猜是小型的那種)可以一眼從話機上看到目前哪條外線正在佔線中,或要轉接他人時直接大喊:小林,你的電話在3 線,的這種「功能」,看起來整個就弱了很多。當然優點也是有,就是我們和新加坡互打時,由於是走網路過去,所以完全不用額外的費用,有時候我自己也會走這條路過去新加坡「下車」,省了不少國際電話錢。

SinoCard

但是自從我們的台中辦公室成立以來,常被台中的行政妹妹抱怨說這個電話常常通話到一半莫名其妙斷線,一開始我們也是找不出頭緒,直到半年前的某一天,因為我要幫公司的永豐銀行信用卡開卡,所以打了開卡電話 02-2528-7776按812,沒想到打完信用卡號之後,開卡系統會附誦卡號一次,卻每一次念到第五個數字 ‘5’ 時,電話就會被掛斷,登登登,看來讓我無意中發現了這個 reproduce 的方法,後來我們又發現了只要在輸入卡號處按 16 個 5 ,就總是會在附誦第 5 個 5 的時候斷線,原本我們以為我們就快脫離這個苦海了,沒想到找出了線索,卻破不了案,從一開始以為是某個 dial tone 造成的問題,一直到懷疑是電信公司搞得鬼,但卻始終沒有解決,而且當台中同事說了這個事實之後,台北這邊也是齊聲附和,看來已經是忍了很久了。

直到三月時因為我剛好得ITGirl出個長時間的差,心血來潮的出了個作業給我們 MIS 妹妹,讓她去弄了個備用的 IP-PBX 出來,加上這個
月我們台中行政妹妹又再次的跑來抱怨電話斷線的問題,上禮拜六我就在端午節補上班那天(因為那天補上班還蠻閒的,心態上很悠閒,實際上也沒啥會議),下午 4:30 左右
再次開始了我的 debug 之旅。

這次我拿了四支電話來測試,竟然被我發現其中兩支完全不會有斷線問題(對照組),所以我的腦筋就先動到電話的 firmware 上,我們用的 GrandStream GXP-1405 電話的 firmware 升級並沒有這麼 user friendly,既使有 Web GUI 可以用,但只能指定要用 tftp, http 或 https 的方式來升級,而且升級檔的檔案名稱是預設在電話系統中的,從 GUI 中你也看不出來,一開始我還以為是任意的檔案名稱就可以了,所以在這裡卡關了很久,最後從 tftp 的 log 中看到有「預設檔案名稱」這回事,但 tftp 不知道為啥傳到一半就會斷掉,所以就改用 http ,再改用 https (因為我把更新檔放在 Elastix server 上,它預設會 http overwrite 成 https) 才升級成功,由於那個電話重開機也慢,每次做完一次試驗就要花上不少時間,所以這件事情搞了我兩個多小時吧,這時候就已經晚上 6 點多了。

星期六嘛,原本以為這就是 happy ending 了,沒想到 firmware 更新完之後,竟然不如我預期的打完收工,試打了一下永豐銀的電話之後發現還是會斷,這讓我覺得很不甘心,所以接著我就開始去比對對照組的那兩支沒問題電話的設定內容,電話設定比對完了,發現沒問題,再繼續去比對分機號碼的設定內容,這時候卻發現我找不到這兩支對照組的電話設定…. 啊,原來這兩支對照組的電話是接到我們 MIS 妹妹上次弄的新交換機,很快的我就找到新的交換機,也對了電話分機的設定,發現也是一模一樣,但這時候我已經發現的曙光,再去找了兩支實驗組的電話(使用原本的交換機),發現還是有問題,所以這時候已經有很大把握能確定問題是發生在交換機身上。

一開始我是先從 sip.conf 開始著手,由於我們原本的交換機上有啟用視訊通話的功能,而 MIS 妹妹架設的沒有啟用,所以我就陸續的把幾個視訊通話相關的設定拿掉來測試看看,也幸虧這天剛好是週六補班,晚上六點多時大家也幾乎都走光了,沒人要用電話,所以我就可以肆無忌憚的改設定->重開,改設定->重開 (ps. Elastix 改完設定之後,最好是去 command line 下 amportal restart,偶而這指令會卡住就要重新開機),試過幾次之後,大概也花掉了一個小時吧,還是一無所獲。

後來又找了一下,發現我們的 Wiki 文件裡頭對於這機器的設定有個註解(不知道是以前的 V 大還是 I 兄留下來的筆記),大意是說因為交換機曾經有咬線的情況(另一方掛斷電話時系統偵測不到,而導致該分機一直呈現佔線中的狀態),所以在 /etc/asterisk/chan_dahdi.conf 中有這樣子的設定:

busydetect=yes
busycount=3

而這個設定是 MIS 妹妹的機器上沒有的(這時候不知道該怪她作業不確實還是該感謝她了),於是我拿掉了這個設定,重開機之後…. 賓果,再打永豐銀的開卡專線就再也沒問題了。

但是你以為這樣子就沒事了嗎?之前的筆記明明寫說這個設定是為了解決「咬線」問題,那到底是什麼情況下會造成「咬線」?這可是大栽問了,所以我開始拿起手機,打了打台北辦公室的電話,疑,初步來看並不會咬線,接著我就打打台中辦公室的,我心理想著,這時候也快晚上 8 點了,萬一也不會咬線的話,那我豈不是就有測不完的 testing case,要測試到找出「咬線」的 pattern 為止。

幸好這時候打了台中電話後,因為已經都下班了沒人接聽,所以響了三聲之後我就掛斷了,這時候發現台中的電話還真的會「咬線」,從 Elastix 的 Operator Panel 中可以清楚看到某條外線 + 下班時間會共振的四台分機一直顯示通話中,非得重開機才能解開。

這時候雖然問題還沒有解決,但是我已經拿到重要的關鍵字了:busydetect + busycount + disconnect or 斷線 or 講電話講到一半斷線,接著直接餵給 Google,果然也不用靠英文,就有幾篇中文文件有提到這檔事情,有人的設定檔中的 busycount 設定得比較大(10 ~ 15),我試驗了一下,busycount 設定的大些可以讓斷線時間延後一點,也就是永豐銀附誦信用卡號時不會再第五個字斷線,而會在第 10 或第 16 個字斷線,另外有個人的設定檔中多了 busypattern=250,250 500,500 這個設定,丟進去之後,哈哈,果然就一切正常了,永豐銀的信用卡附誦不再斷線,也沒有咬線的問題了。    (* 2017/07/07 搬了辦公室之後,發現咬線問題又出現了,這次再改回 busypattern=250,250 之後就正常了….. 看來這個數值是搬個家就會不一樣的,好慘)

最後我計算了一下,我大概花了三個小時左右,真正的產出是下面的第三行

busydetect=yes
busycount=3
busypattern=500,500

如果以寫程式的角度來看,在 source code 中只會看到我改了這一行吧,花了三個小時的這一行…

而且老實說,也許電話講一半斷線的問題有許多 pattern ,我只解決了其中一種剛好可以被永豐銀開卡系統 reproduce 的那一種,也許我加上的這一行設定會導致另外一種未知的咬線問題,但是我沒發覺,也許要找到真正的 root cause 應該是要去研究一下台灣電話的各種頻率和 Elastix 之間的匹配問題…

但正所謂一日之所需,百工斯為備,既使是 IT 這個 domain,要靠一個人去瞭解所有的從底層一直到操作面上的各種觀念和技術是不可能的,甚至於是你要把問題往廠商那邊丟,也未必能得到滿意的答案。但是身為一個工程師,其實只要能掌握 try & error 這個心法,加上實驗與比較的精神,一樣可以取得一個滿意的解決對策(workaround)。

我猜應該也會有網友有其他的看法,以下是我這三個小時心路歷程中,心中曾經有過的 OS:

  • 遇到問題無法解決時:你看吧,早就叫你買 Cisco 或 Avaya 了
  • 有供應商時:怎麼不把問題丟給廠商呢?
  • 有供應商而且老闆在問時:這個問題廠商也說沒見過,已經開 case 給原廠了
  • 花這麼多時間,值得嗎?這又不是我們的核心競爭力

很多事情沒有真正的對錯,單看你要從那個角度來看,但今天是工程師節,我還是得承認這個結果雖然讓身為工程師的自己覺得很爽啦,但也是自己爽而已,只希望自己花了這三個小時的時間所解出的那一行,能幫助到網路上其他有這個問題的朋友,那我這三小時就也算花得值得多了。