企業級 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 給原廠了
  • 花這麼多時間,值得嗎?這又不是我們的核心競爭力

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

XenServer 7 發佈

應該是某個同學講的:沒錢又想用虛擬化的話,就用 XenServer 吧!

這樣子的一句話道出 XenServer 的價值所在,XenServer 從 2013 的 6.2 版開始變成 Open Source 之後,因為更新的不勤,本來我還以為他快要倒了,沒想到後來還陸續的推出了 6.5, 6.5sp1,現在也正式的發佈了 XenServer 7,看起來還是有一戰之力。

現在市面上前兩大的虛擬化產品都是 Hypervisor 免費,但管理工具要錢(還要很多錢…),如果你是個大公司的 MIS ,也許花個錢買個幾套 vSphere ,大概就可以跑上幾十個到幾百個 VM ,但如果你是個 hosting 公司,或因為各種原因管了一堆 Server 的話,上百上千套的授權大概就有你吃不消的 (除非談到個 site license 的好價錢)。而 XenServer 就是一套 Hypervisor 免費,管理工具也免費的一套虛擬化工具,當然你得要忍受一下 Open Source 潛在的不穩定性,和沒有「原廠」支援的不確定性 (XenServer 提供付費技術支援,但台灣似乎沒有)。

這次的第 7 版帶來哪些更新呢? 下面這些是我比較感興趣的幾個:

  1. 號稱是最重要的 NVIDIA GRID vGPU 的整合,比 6.5 版的效能快了 33%,但是我沒用過,也許一些研究單位會喜歡這個進步吧,另外就是 Citrix 自己的 XenApp 或 XenDesktop 上跑起 3D 來就可以更順了?
  2. XenTool 的更新整合到 Windows update 中,這個倒是挺重要的,雖然 XenTool 不常更新,但只要有更新就是為了解決大問題,為了要更新都要安排獨立的時間把機器分別下線進行維護,現在可好了,就每個月跟著 Windows update 一起做就可以了,方便許多
  3. MS SMB 支援,這應該是指說 XenServer 除了以往的 local disk,iSCSI,Hardware HBA (俗稱的外接磁碟陣列) 之外,也可以把 Virtual Disk 放在 SMB 裡頭了。我相信有用過 XenServer 的人都有碰到過 Virtual Disk failure 相關的慘劇,不知道把 Virtual Disk 放在 SMB 之後,遇到問題時把 Virtual Disk 「轉」到其他 server 上的機會會不會大一些
  4. Docker container 也支援 Windows Server 2016 了,Docker 是這幾年來呼聲很高的產品,但似乎用在正式環境上的人很少,XenServer 在 6.5sp1 開始其實就開始支援 Linux 的 docker 了,現在也要支援 Windows 的 docker 了,看來日後單一 server 上的 Virtual ‘Machine’ 的密度又可以提高很多了,其實 6.5sp1 的 docker 我沒用過,剛剛臨時看了個 YouTube 才知道是怎麼一回事
  5. 用了 CentOS 7,並且改了磁碟分割,其實用 CentOS 7 對我來說是沒什麼特別感覺,倒是以前總共 4GB 的磁碟分割讓我們吃了幾次 log 爆掉的苦頭 (雖然 log 爆掉是果,不是因),現在新的 7 版,光 log partition 就切了 4GB ,想來日後再發生一切奇怪事件時,我們會來得及趕在 log 爆掉時去處理他
  6. 快很多? 大概只有指 Shutdown storm 或 Boot storm,我只想到是不是以後做作業系統更新時,那個重開機的速度會會快很多
  7. 可以從 host 端去監控 guest 端的 memory ,以避免病毒或木馬危害? XenServer 和 Bitdefender 合作的成果,我猜是在 XenDesktop 的環境下,Endpoint 的防毒軟體很容易因為使用者的一些蠢行為而被自己或惡意程式給 disable 掉 (對,尤其是那些權限高的使用者),這時候如果可以從 host 去偵測並攔截這些惡意程式的話,效果會好非常多

當然官方的新功能列表還很多,上面只是列出我個人有興趣的幾點,改天還要找個時間玩玩看,也許還能發掘不少有趣的新功能

Centos 路由去回不同路解決方式

不知道大家有沒有在linux伺服器上有兩張網卡,且設有多段IP,但是卻如法在同網段ping通和tracert的經驗

本人我就遇過這樣的問題

如果你有兩張網卡 eth0與eth1

eth0的網段為10.10.1.0/24

eth1的網段為10.20.1.0/24

我們假設網段10.10.1.0/24的gateway是10.10.1.1

預定要讓預設的gateway裝置eth0回的話,解決的方式如下:

1.編輯iproute的規則名稱
[root@pandacentos ~]#vi /etc/iproute2/rt_tables
10     pandaroute #10為route table的值,pandaroute為route table名稱,都可自訂,但名稱請取服務名稱,方便辨識
2.重啟網路服務
[root@pandacentos ~]#service network restart
3.增加route的rule
[root@pandacentos ~]#ip route add default via 10.10.1.1 table pandaroute
[root@pandacentos ~]#ip rule add from 10.10.1.0/24 table pandaroute
以上的方式試一次性的解決方式,因為沒加到static route,所以在重開機後route就會消失,要如何避免這個問題,你可以在/etc/rc.d/rc.local上加上面這兩行制令,或用下面的static route 和rule的方式添加
[root@pandacentos ~]#vi /etc/sysconfig/network-script/route-eth0
default via 10.10.1.1 table pandaroute
[root@pandacentos ~]#vi /etc/sysconfig/netwrok-script/rule-eth0
from 10.10.1.0/24 table pandaroute
4.如果是加static route的方式,請在重起一次網路服務
[root@pandacentos ~]#service network restart

mRemoteNG 的新版本 mRemote3G -> mRemoteNG

mRemoteNG 是個把 RDP, SSH, Telnet, VNC… 等整合在一個視窗中,以 tab 分隔的免費應用程式,它的前身,沒記錯的話應該是叫 mRemote,後來因故中止了,我記得當時我花了些時間找到了另一個願意繼續維護它的專案 – mRemoteNG ,它不像其他類似的軟體會有 connection 數的上限或試用期之類的,繼續快樂的用了一陣子,這個版本雖然好用,但也是有一些小缺點,例如有時候按下 Alt+tab 鍵時無法順利切換視窗,偶而會莫名的 crash 等等 (1.73 Beta 1 很常掛)。

今天心血來潮去爬了一下 mRemoteNG 的論壇,竟發現有位老兄 (kaymer327) 留言說他已經另開 Github 專案去維護他自己的版本 – mRemote3G (大家喜歡改名字… 所以之前都沒 Google 到),而且到兩週前都還有更新,真是如獲至寶,目前試用的結果還算正常,原來的連線檔還是可以繼續使用,到目前也還沒 crash,VirusTotal 只有 360 掃出問題?! (HEUR/QVM03.0.Malware.Gen,我是選擇忽略 360 的結果,因為我都不把密碼存在 mRemoteNG 裡面的,哈哈)

整體看起來 UI 也改動了一點點配色的樣子,但還是一樣好用,有需要又不怕死的可以由上面連結去找嘍。

  • 2016/07/28 剛剛沒事又去逛了一下,沒想到 mRemote3G 又合併回去 mRemoteNG 了,在 Github 上可以找到最新的版本 1.75alpha,現在拿去 VirtualTotal 掃描,目前最新版的 mRemoteNG 已經都沒有病毒警告了(但之前的 mRemote3G 還是有一個?!),建議可以改用這版了

BIND 自 9.11.0 才會開始支援 EDNS Client Subnet

對 BIND (或 DNS) 稍有管理經驗的人,應該都知道 ACL 這個功能,他可以讓我們針對不同的 Resolver IP 回應不同的答案 (IP Address),所以諸如公司內網來查詢回內網IP,外網回 Internet IP 的設定,或特定來源 IP 回應特定的 IP ,甚至於 9.10 才開始加入的 geoip 功能,都是很好的 ACL 應用。

以往的使用者大多是會把 DNS Server 指到所屬的 ISP 提供的 DNS Server (大多數是不明不白的就用了 ISP 的 DNS Server),但是隨著越來越多的使用者用了 8.8.8.8 這個 Google DNS 當作第一選擇之後,之前我們使用 BIND + geoip 來做分流機制就不見得那麼準確了,加上 Google 又跑了 BGP,所以通常透過 Google DNS 來 query 的 IP 查出來都是屬於 – Mountain View, California, United States, North America,而非這些 IP 實際或相近的地理位置,導致於這個機制的運作效率越來越不好。

所幸 EDNS Client Subnet (ECS) 這個機制將要再 BIND 9.11.0 被支援了,雖然具體發佈的時間還不清楚,但至少讓人看到這問題被解決的曙光。有趣的是,從對岸網友那看來的消息是,這個 patch 早在 2014 年 8 月就已經 submit 進去了,所以有興趣玩的人也應該早就自己 patch 上去了。不過沒那個時間或自己沒能力 patch 的人還是等官方發佈比較妥當,免得到時候遇到非得更新不可的安全性問題時,還要自己生出 patch。

從 2014 年看到的 commit 說明裡,可以知道這個 ECS 支援會同時在 geoip 裡生效,也就是當你要使用 geoip 時,遇到有 ECS 的查詢時就會優先拿 ECS 來判斷而非來查詢的 DNS Server IP。所以,讓我們期待 9.11.0 的正式發佈吧。

  • 2016/06/27 更新,前幾天上去看,發現 BIND 的 9.11.0 已經出了 alpha 3 了,下載之後自己編譯了一下,看起來也可以正常的支援 EDNS + GeoIP,改天再來找個對外的 DNS 給弄上去,因為據說 Google 的 public DNS 早已經支援 EDNS 了,屆時 GeoDNS 的運作有效性相信又可以再回來了

HDD, SSD & RAMSAN

首先先來談談 RAMSAN 這個歷史產物好了。這間客戶應該是在多年前(七年以前)開始使用 RAMSAN 這個產品,遙想一下當年的歷史背景,HDD 不夠快,SSD 不成熟又貴 (可靠度應該不怎麼樣),所以就引進了 RAMSAN 這樣子的產品。真要認真分類的話,RAMSAN 應該算是 SSD 的一種,只是 SSD 是以 Flash memory 作為儲存空間,而 RAMSAN 則是以 RAM 作為儲存空間 (不過近年來他也有 SSD 的產品線,所以 RAMSAN 是專指 RAM 或 Flash 的 SSD Storage 要深究也沒什麼特別意義了,不過本文中提到的 RAMSAN 就專指這類用 RAM 堆起來的 SAN)。

一台典型的 RAMSAN 長得像這個樣子:

1

也許你有看到前面有四個硬碟插槽,不過那只是備份用的。一台 RAMSAN 的主要元件有:記憶體、電池 (鉛酸電池)、主機板、Power Supply 和 Fiber channel card。看到電池兩個字,大家可能就想到了,這個 RAMSAN 是要靠電池來維持安全的,身為一台昂貴且號稱是企業級應用的硬體,一旦斷電時,RAMSAN 就可以靠電池供電來把記憶體內的資料儲存當前面板的四台硬碟中,想當然爾,RAMSAN 開機時就會把這硬碟裡的資料寫回到記憶體裡頭。所以儘管是正常的開機關機,RAMSAN 所耗費的時間也要比一般的伺服器要來得長很多。

由於出品 RAMSAN 的這間 Texas Memory Systems 公司已於 2012 年被 IBM 併購,對 RAMSAN 這產品有進一步興趣的 (至少人家還有繼續在出 SSD 的機種),可以自己去 Google 看看。

稍微有點 IT 背景的人應該都知道,RAM 再怎麼慢還是比 Flash 快上一大截,那為何又說 RAMSAN 是個歷史的產物呢?讓我們先看一份資料:

Type HDD Mix HDD & SSD SAS SSD RAMSAN Flash SSD RAMSAN RAM SSD
Config 14 HDDsRAID 10 14 RAID 101 SAS SSD CacheCade 4 SLC SSDRAID 10 RamSan-720SLC RamSan 440DDR2
IOPS 5.5K IOPS 20.45K IOPS 76.27K IOPS 500K R/W IOPS 600K R/W IOPS
Capacity ~ ~ ~ 6-12TB 512GB (maximum)

猛一看,哇,RAMSAN 的 RAM 機種真是強大啊,IOPS 可以到 600K (600,000),用 4 個 SLC SSD 做 RAID 10 也才只能到 76.27K IOPS,用 14 顆硬碟去做 RAID 10 才只有 5.5K,真的是 xx 比雞腿,但仔細看一下他的容量,啥,最大只能到 512GB,有沒有搞錯?現在我連隨身硬碟也就已經是 1TB 起跳的年代了,512GB 是要拿來裝什麼。

沒錯,這就是他的致命傷了,你也不要小看他只有 512GB 的容量,他的身價可能要超過他的 SSD 同門小弟 – RAMSAN 720。這麼貴,容量又小,那唯一可以看的就是速度了吧?對,沒錯,就是速度上快了一截,但… 各位有幹過 DBA 的去 monitor 一下貴公司資料庫硬碟的  IOPS 看看好了,誰需要這麼快的速度?就連我們自己去監控客戶線上 RAMSAN 的速度,也離極限有很大的距離。

在當年那個 SSD 又貴又沒有可靠度的環境下,當 HDD 的速度跟不上的時候,用 RAMSAN 大概是個明智的抉擇,不過隨著 SSD 的不斷進步,價格不斷的下降,RAMSAN 這個原本就存活於利基市場的產品的市場就越來越小了。君不見連他自己現在都不產 RAM 做的 RAMSAN 了,就可以知道目前的的市場需求有多小了。

除了市場需求面太小之外,現在也跑出很多類似功能的的解決方案出來,例如 SQL Server 2014 的 In-Memory OLTP,或是 SAP HANA,更別說是現在的 Non-relational database 這種根本不同型態的資料庫應用,雖然都或少或多的需要針對應用系統進行修改,但從價格/效益比來看,只能說 RAMSAN 真是時代的眼淚了(至少 2015 年的現在看起來是這樣子)。