k8s in 5 minutes for Windows 10

前一陣子看了 William 大的 k8s in 5 minutes 之後,才發現原來要在本機跑 Kubernetes 不用再裝 minikube 了,尤其是在 Windows 環境下,要玩 k8s 還得要有特別的安裝方法,這讓我們這些用 Windows 當成日常環境的人總有些不得其門而入的感覺,現在 docker for desktop (下載時可能會叫做 Docker for Windows) 原生支援 k8s (本機版)之後,對於想要很快的看看 k8s 是啥的 Windows 使用者算是個很好的入門磚。

其實 5 分鐘所有的步驟都和 William 大寫的差距很小,只有小部分 Windows 環境下該注意的事項,但小弟資質駑頓,記性太差,還是寫清楚些以便日後參考:

  1. 要先啟用你 Windows 下的 Hyper-V (對 Windows 家用版就別試了)
  2. Docker for Windows 版 (現在也沒有所謂的 Edge 版本了)
  3. 如果你之前有裝過 minikube 的話,記得把 Kubernetes 的環境從 minikube 改成 Docker for Windows
    01
    02
  4. 在我的機器上 kubectl.exe 看來沒有加到搜尋路徑下,請自行加入 (我的安裝路徑在 C:\Program Files\Docker\Docker\resources\bin),不然就切換到該目錄下:
    C:\> cd C:\Program Files\Docker\Docker\resources\bin
  5. 裝個 k8s dashboard (非必須)
    C:\> kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml
  6. 把 proxy 跑起來,跑起來之後不能關掉這個視窗,得另外開一個命令列視窗出來繼續,
    C:\> kubectl proxy
    Starting to serve on 127.0.0.1:8001
    ...

    跑起來之後你可以用瀏覽器開下列網址存取 dashboard 來:

    http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
  7. 開另外一個命令視窗把範例裡的 echo-server 裝起來:
    C:\> kubectl apply -f https://raw.githubusercontent.com/coder-society/kubernetes-with-telepresence/master/echo-server/echo-server.yaml
  8. 最後一個步驟和 William 大的不一樣,由於 telepresence 這個工具在 Windows 下執行會有問題,所以用瀏覽器透過 proxy 的方式來測試這個 echo-server (其實這裡我卡了很久… 因為第一次用 k8s,才發現 William 大用了這個 telepresence,而 Windows 下這東西目前又跑不起來)
    http://localhost:8001/api/v1/namespaces/default/services/http:echo-server:/proxy/

    由於我們沒有指定 echo-server 的 namespace,所以這個服務會被放在 default namespace 下,與剛剛的 kube-dashboard 的 namespace 不同,一開始我搞錯也是卡很久

  9. 這個 echo-server 的功能看起來很簡單,就是 show 出目前是從哪台 server (k8s 的術語叫 pod) 跑出來的,你每次 refresh 一次,就會換一台 pod 來跑
    03
  10. 也可以看一下 k8s-dashboard,網址在剛剛啟用 proxy 之後有 show:http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
    04

同事 J 問我說這個 Docker for Windows 是不是開一個 Windows node 出來,仔細看了一下應該不是,它會在你的 Hyper-V 下起一個 Linux VM,所以要試 Windows node 的還是得等等其他人的文章了

05

06

其實昨天剛好有和一位 Google 的業務員聊到天,她自己認為 k8s 改版的速度實在是太快了,有些舊東西淘汰了、新東西加進來之類的都沒人知道。例如這一本台灣有的翻譯書:Kubernetes 使用指南,用到的是 k8s 1.0,裡頭講到的 Replication Controller 在新版本裡都改用 Deployment 和 Replica Set 了,現在去 Google 開一個 k8s cluster 也預設是 1.9.7 了,照著書來做大概只會覺得常常都對不上台詞吧。就算去翻對岸的簡體紀念版:Kubernetes 权威指南(纪念版),出版時也只是 cover 到 1.6 版,更遑論 k8s 官方的網站上已經放了 1.12 版讓人下載了,所以要學這個除了得花時間之外,手腳還得快一點,現在(2018/11/07)拿著最新的簡體中文書可能還對得上環境,可能再過幾個月又得另外找書或文章來學了。

Project Honolulu 是個免錢又大碗的東西嗎?

前幾週聽了 Weithenn 大介紹的 Windows S2D 和 Docker 之後,對於他提到的微軟免費工具 – Project Honolulu 很感興趣,聽來是號稱 MS System Center 的免費版本,這立刻讓我腦海中想到了諸如自動化升級、VM服務自助化或是什麼工作流程自動化一類的,心裡想說微軟終於是佛心來著,便馬上填了些資料下載來玩。

下載和安裝本身並不複雜,雖然它有三種部署的方式,但由於我的目的只是看看這東西有什麼功能,所以變直接安裝在我的 Windows 10 NB 上,這部分的安裝過程沒什麼困難性,一下子也就完成了。

倒是準備要被 Project Honolulu 「管控」的機器還有些特殊需求,除了至少要是 Windows 2012 R2 以上的版本外,還得裝上 Windows Management Framework (WMF) 5.0 以上的版本(網站上給的安裝連結是 WMF 5.1),由於安裝完畢之後需要重開機,如果你的環境剛好沒有符合需求的機器,又不能輕易重開機的話,可能會跑不下去。安裝 WMF 5.1 的時候有個小插曲,就是我找了三台 Windows 2012 R2 ,每一台都告訴我這個安裝檔並不試用於我的環境,最後搞了老半天,原來我一直下載到的是一個叫做 W2K12-KB3191565-x64.msu 的安裝檔,但試用於 Windows 2012 R2 的安裝檔是叫做 Win8.1AndW2K12R2-KB3191564-x64.msu,這種蠢事我也是 Google 之後才發現的,顯然微軟這種命名方式騙到我這種蠢蛋了…

Project Honolulu 會在本機裡裝個小型的 Web server ,裝好之後直接點開始功能表就會把網頁給打開了,一打開來,我優先去點擊的這個功能:

01

嗯,Windows Update,怎麼這麼熟悉? 按下 Install Updates 按鈕之後跳到下個頁面:

02

嗯… 還是很熟悉的畫面… 什麼?! 這該不會就是 Project Honolulu 的功能吧? 完整的把本機上的系統管理功能、設定功能給搬到 Web 上讓我們可以「遠端 GUI」作業,真的是這樣子嗎?讓我再擷取幾個畫面看看:

03
這是我自己 NB 的監控畫面,這… 不就是工作管理員

04
看得出來可以管理四種標的,後面的 Faliover Cluster 和 Hyper-Converged Cluster 我目前沒有,選個 Server Manager 看看:

05
要檢視某一台 Server 之前,要先等系統跑一下子

06.jpg設定畫面,原本以為可以在這裡設定報警條件的,結果原來只能設定環境變數

07.jpgEvent viewer ?! 事件檢視器,一模一樣勒

08.jpg
防火牆設定,就是防火牆設定

09.jpg這個稍微有新意一點,Web 版本的遠端 Power Shell,有了這個就表示什麼功能都可以自己刻了吧?

10
放大絕了啦,Web 版的遠端桌面,Project Honolulu 還有什麼做不到的?

唯一的一點點小缺憾是目前沒有在 Project Honolulu 裡看到 IIS Management 的操作功能,不知道是還在製作中或是沒打算做(反正 Power Shell 都可以做到),除了 IIS 之外,其實還有許多 Windows Server 的管理功能沒有被實做上去,這篇 FAQ 裡有完整的支援/不支援清單。

所以簡單做個總結,Project Honolulu 像是個 Remote Desktop Manager + Computer Manager 的綜合升級版,其中一種部署方式是可以把 Server 部署在跳板機上,然後系統管理員便可以從真正的遠端透過瀏覽器進行系統管理。由於可以事先把受管理的 Server 清單建在系統上,機器多的時候要找也是方便了一點,所以要說是簡化了系統管理程序也未嘗不可啦,不過要說是像 System Center 一樣能簡化資料中心的管理嘛,倒是差了那麼一大截。唯一可以理解的是:Project Honolulu 所依賴的底層 WMP 5.1 應該已經可以含括到 Windows 系統管理的許多功能了,所以除了微軟自己的 System Center 之外,應該也可以期待會有 3rd party 開發出諸如自助化服務網站的功能出來,或是自己想辦法刻出來?

11.jpg
目前我使用的 TP 版本是 1711,雖然我也只是玩一玩試一試,但可以感覺得出來這東西並沒有明顯的狀況或當機之類的問題,應該可以算是很成熟的東西了,只是我之前對它的期望太高,試用之後不免有些空虛就是了。

比威而鋼還威的 TCP BBR

前一陣子從 iThome 看到了 Google 要把 TCP BBR 應用在 Google Cloud Platform 的新聞, 才發現原來這東西這麼神,2700 倍的傳輸率,佇列延遲減少 25 倍,隨手翻了下網路上的部落格,沒想到有那麼浮誇的說法證明:下載從 84K/s 變成 3.9M/s,這立刻引起我的好奇心,找到了 Google 自己的部落格說明,原來是長久以來使用的 TCP 壅塞控制演算法有點笨,遇到有 packet loss 的狀況時,就會以比較保守的方式來傳遞接下來的封包,而新的 TCP BBR 則用了比較聰明的方法來處理 packet loss 的問題,整個示意圖就如下所示:


* Source

文中也特別拿了幾個國家為例子,說明在應用了 TCP BBR 之後,YouTube 的表現情形,不看還好,一看之下,沒想到 Google 也這麼浮誇寫實,YouTube 到 ID 的 Max Round-Trip time 竟然可以改善到 50% 以上,這讓我突然想到以前公司在進行某個網路直播專案時,那個爛 4G 網路讓我們驗收時吃了很多苦頭,所以我也來做個浮誇的測試好了。不過因為一來我很懶,二來也沒那個預算搭建回當初專案的原始架構,所以以下浮誇的測試只在我的本機上實驗。

  • 實驗環境 (都在同一台機器裡):
NB: OBS Studio 19.0.3 --> NB: clumsy-0.2 --> VM: SRS 2.0.242 + CentOS 6.9 --> NB: flv.js in Chrome
  • 實驗方法:
  1. 先以 Kernel 2.6.32-696.6.3 直接測試,擷取螢幕看直播視訊延遲
  2. 以 clumsy 加上 inbound & outbound 各 50ms 的延遲,並隨機 drop 10% 的封包
  3. 等個幾秒,擷取螢幕看直播視訊延遲
  4. 停止 clumsy,等個幾秒,擷取螢幕看直播視訊延遲
  5. 升級 Kernel 為 4.13.0-0.rc1,重複步驟 1~4
    * 我拿了一個 Firefox 開時鐘來讓 OBS 擷取螢幕畫面,所以測試畫面中會看到 Firefox
  • 實驗結果:
  1. 沒 TCP BBR,不啟用 clumsy,延遲大概 3 秒
    Without BBR - normal network
  2. 沒 TCP BBR,啟用 clumsy,稍等一下,延遲變為 13 秒,實測時這個延遲會迅速擴大,最差的狀況是影像會停掉
    Without BBR - bad network
  3. 沒 TCP BBR,把 clumsy 關掉,稍等一下,延遲回到 5 秒左右
    Without BBR - normal network again
  4. 有 TCP BBR ,不啟用 clumsy,延遲大概 2-3 秒,其實和沒 BBR 時差不多,這畫面看起來延遲只有 2 秒應該只是個測試誤差
    With BBR - normal network
  5. 有 TCP BBR,啟用 clumsy,稍等一下,延遲變為 4 秒
    With BBR - bad network
  6. 不信邪,再等一等,有 TCP BBR,啟用 clumsy,延遲還是維持 4 秒左右
    With BBR - bad network-2
  7. 恢復原狀,有 TCP BBR,不啟用 clumsy,延遲還是維持 4 秒不動
    With BBR - normal network again

總結來看,這個 TCP BBR 還真的神,在高延遲且掉包的網路上,在我的測試環境 1 個 client 對 1 個 server 的情境下就能有這麼好的表現,安裝的方法我就不特別提了,網路上隨便 google 都一堆,不過還是要提醒大家一下,再好的東西還是得先測試才能上正式環境,免得哪個不小心你就踩了坑了都不知道。

BBR Summary

玩一下 Google Compute Engine 要花很多錢嗎?

雖然身為一個 IT 人,也知道這一行要與時俱進不然就被淘汰的道理,但是我個人對於「在雲端上花錢」這件事情的態度算是偏向保守的那一派,像是 LINE Pay 已經出來半年了,我是為了貪那繳稅的回饋金才去辦卡且綁定了我的 LINE 帳號,Google Play 上就算有需要綁定過信用卡,也是用完之後就移掉,不然我自己會想像被他亂收錢。

這次之所以會想要在 GCE 上花錢,是因為看了某個對岸網友的文章,發現 Google 竟然直接在他的 GCE 上提供 Anycast IP + Global Load Balancer + CDN 的服務,因為這實在是太狂了,所以我忍不住就打破了自己的的風險規則,跑去把我的信用卡放上去。

我測試的東西也就是 Anycast IP –> With CDN –> Load Balancer –> 一台台灣 VM + 一台新加坡 VM 這樣子的架構,測試之前先在我自己電腦上的 VM 跑了一次,並且把安裝與設定步驟記錄了下來,所以去 Google 上開機器時,除了幾個 Google 自己的設定需要實驗多花了點時間之外,大致上可以說是沒幾個小時就做完相關的設定工作,然後就開始測試了。之後就放那邊放了兩天,端午節之前把 Anycast IP, CDN, Load Balancer 及新加坡機器關掉,只留下台灣這台 VM 給同事測試用 (對,我實際上的需求並沒有一定得要用 Anycast IP,只是拿來試試看功能而已),這樣子我一共花了多少錢呢? 才 US$1.96

1

而且 Google 也提供了一個預算管制的功能,當所花的錢超過你設定的預算時,就會發警示信出來。因為我拿來玩 GCE 的帳號就是我平常在用的 Google 帳號,也綁了我的 Android 手機,所以這功能讓我很安心的繼續用下去。

2

前一陣子不知道是哪位臉書上的心得,說是微軟 Azure 要和 Amazon AWS 或 Google GCE 對打還是走得很辛苦的。對照一下這幾年來看到 Google 在做的事情:Google 自建海纜、GCE、Anycast IP on GCE、Google CDN (如果 Google 要把他們在世界各個 ISP 放的 Google Global Cache 也拿來做 CDN 加速的話,那就更恐怖了),可以看到 Google 要做而且已經快做到的是「世界」的 IT Infrastructure – 全世界的中華電信、全世界的 Hinet,這意思是什麼呢?如果你今天只想做台灣的網站也就算了,如果你是想搞跨國的網路應用(電子商務、遊戲、社群、直播…),以後你也不用多想了,就直接放 Google 上就好了,如同幾年前的台灣一樣,大家想搞網路、搞遊戲,機房鐵定要選中華電信、專線一定得拉 Hinet,因為全台灣的使用者幾乎都是用 Hinet,想不接 Hinet 線路就是要讓使用者 lag 爆。這種事情以後就會反過來,大家要在全球佈局的話首選就會是 Google,因為最簡單速度又最快。

所以,學學這些 Public Cloud 的使用經驗看來就是未來 IT 人的必備技能,而且搞不好還比去學什麼 Server 安裝或 Cisco 設備操作要來得基本且必要,要練習這些東西很花錢嗎?你要練 Server 安裝、系統管理之類的可能要去買台機器或借個環境才能操作,想練網路我看很多人會花個幾千塊去網路上買二手設備來練習,但是想練 Google Public Cloud? 以我這次的例子來說,只要 1.96 鎂就好,可能比很多人一天的通勤費用還便宜些,好東西,不買嗎?

在 Windows 上使用支援 edns client subnet 的工具 – dig 9.11

2019/1/31 更新,大概是 2/1 是 DNS flag day 的關係,這篇略有相關的文章竟然也湧入了很多遊客,所以我也是 google 了一下相關文章,更新如下:

本文所提到的 edns client subnet 功能其實只能算是使用 edns 這個延伸協定中的一個項目,由於在古早的 DNS 協定中,一次 DNS query 的回應只規範了 512 bytes 的大小,由於當時網路速度慢,機器也不快,這樣子的設計也可以理解。但隨著網路越來越快,使用的情境越來越複雜時,512 bytes 大小的回應便顯得很難用了,最典型的狀況是:你最多只能有 13 個 DNS 權威伺服器,連 root DNS 也是一樣(a 到 m 共 13 個),原因是一個回應放不下,所以現在有了 edns 之後,理論上要可以到 4096 bytes,有人說這樣子可以回應出 236 個 DNS Servers,想來不久的相來可以看到 root DNS server 變多的情景了。

那為什麼很多網路上的文章寫說支持這個 DNS flag day 是為了更好更安全的網路環境呢? 這說是對也是對,說是硬湊也是可以。由於有個 DNSSEC 的協定被設計來避免 DNS poison 的安全性問題(很常見,對岸那邊尤其多),而這個 DNSSEC 協定卻依賴 edns 才有足夠的 payload 可以放這些資料,所以呢,你可以說這個 DNS flag day 是為了 DNSSEC 鋪路,因為他只測試你的 DNS Server 是不是支援 edns ,但說有 edns 相容性之後就可以提高安全性就有點超過了。(甚至於 payload 變高搞不好還可能被用來作為 DNS 放大攻擊)

那為什麼要這麼大聲量的宣傳這個東西? 其實 DNSSEC 協定推出了很久,各大的 DNS 供應商也都有支援了,只是 DNSSEC 這協定如果沒有「從最源頭到最底層」,也就是從 root DNS server 到 DNS client (eg. 你的 Windows NB) 都支援的話,那效果就不太顯著。講個例子好了,我想大家都可以理解一件事:IPv6 從 1994 年出現到現在一直都沒成為主流,就可以知道想在 Internet 上「全面」的推行一個新標準有多困難,由於要推行 DNSSEC 不只是所有的 DNS Server 都得全面更新,連可能經過的 firewall, load balancer 之類的設備也可能需要升級 (eg. 你的 F5 GTM 版本支援 EDNS 嗎?),所以先從這著手鋪路一下是個不錯的漸進手段。

和這篇文章的關係是? 其實我覺得要驗證是不是 edns 相容最好最快的方法就是用官方網站上的測試網頁了,如果真的想要手動測試的話,請參考下文去下載 Windows 下的 dig 程式 (BIND 9.11.0 之後),然後依照這個方法來手動測試。

啥? 那為什麼 Hinet 或 TWNIC 一直廣告說讓大家用他們的 DNS Server (168.95.1.1 或 101.101.101.101) 就不會有影響? 那顯然就是她們為了「體恤」那些還來不及做好相容性升級的域名管理者(或網站),所以選擇不加入這個「為網際網路安全」的下一步

———————————-以下是原文章 ————————————

之前提到了說 BIND 會從 9.11 開始支援 EDNS client-subnet,所以若你的 BIND 已經開始使用 GeoDNS 的功能,恰好你的 end user 用的 DNS server 也支援 EDNS client-subnet 的話 (eg. Google DNS 就支援),那恭喜你,你的 GeoDNS 的效果應該會變得更加顯著。

但實際把功能丟上去之後,你就會發現有事沒事的你會遇到使用者抱怨他連你的網站速度太慢,原因是因為你的 GeoDNS 回給他的結果和你預期的不同,原本你想要 GeoDNS 丟個離日本最近的 IP 給他,但他拿到的卻是個英國的 IP。這時候我們就需要個可以快速驗證 GeoDNS 設定是否正確的工具了。

這工具其實也很簡單,因為就是隨著 BIND 9.11 一起更新的 dig 命令,只是以前我笨笨的,以為 BIND 只有出 source code,自己又沒種花時間去 Windows 下建立編譯的環境,所以都是去抓別人編譯好的執行檔,自己都覺得有點不是挺安全的,不過剛剛仔細一瞧,原來 ISC 自己的官方網站上就放了 BIND 的 Windows 版,只要下載之後安裝也就可以用了…

01

安裝的時候只要選擇「Tools Only」就好,我想大家也不想在自己的電腦裡裝個用不著的 BIND Server

02

裝好之後,如果你像我一樣對自己用的系統有一點潔癖的話,可以把目錄下的這些檔案(除 BINDInstall之外)拷貝到你喜歡的目錄,剩下的東西則可以全部移除。

03

dig + EDNS client-subnet 的使用方法也很簡單,就是

dig [domain name you want to query] @[DNS Server] +subnet=[addr]

http://www.google.com 為例,如果我是個位於美國的使用者,IP 是 128.32.203.137 (我隨便抓了個柏克萊大學的 IP 來測試),解析出來的會是 172.217.5.100

04

那如果我是個台大的學生,IP 是 140.112.8.116 的話,解析出來的會是 163.28.18.30 (左右…)

05

我自己現在用的是遠傳的網路,從 ping 的結果看來,Google 應該也是有應用 GeoDNS 來加快網站的速度(當然也用了 BGP anycast,但不在此文討論範圍)

06

最後,更笨的是,如果你什麼都不想裝,就用別人放在雲端上的服務就好了…

https://tools.keycdn.com/dig

OpenStack – Failed to connect to server (code: 1006) issue

最近在OpenStack的lab遇到了無法使用console的問題

情況如下,當環境中只架設一台controller node時,console 可以正常使用

不過當controller node增加到2台以上時,console就會無法使用

以下為錯誤畫面

Failed to connect to server (code: 1006)

2016-11-01_001459

後來問過Google大神才知道,當架設多台controller node時會因為每台controller node對instance的token都不同造成驗證失敗,使得console無法使用

解決的方法就是在nova.conf中設定memcache servers來存放token

設定如下:

[cache]

backend = oslo_cache.memcache_pool

enabled = true

memcache_servers = controller1IP:11211,controller2IP:11211,controller3IP:11211

3台controller node都設定完並重啟nova-consoleauth service,就可以正常使用console了

RAID Scrubbing / Data Scrubbing

最近因為追某個錯誤,追到了辦公室的 Synology NAS 上,才發現這個名詞:「RAID Scrubbing」,標準的叫法應該是「Data Scrubbing」,查了幾份文件 (1)(2) 之後,都說這是使用 RAID 時的必要的定期維護工作,還提到而家用硬碟建議每週都做一次,而資料中心用的 RAID 建議每月都做一次,不然可能會有資料遺失的風險?!

乍看之下我嚇了一跳,因為印象中我們從來沒做過這個動作,當時我立刻覺得公司的資料正陷入極高度的風險中,不過稍微看了一下 Wiki 上的介紹之後,發現 Dell 的 RAID card 本身就支援所謂的 patrol read 功能,效用等同於 Data Scrubbing,頓時讓我鬆了一口氣,但身為一個工程師, 就是要追根究底一下,不然還真不能百分百的放心,而且還可以藉此練一下肖喂:

  1. 關於 Dell 的 RAID card 部分:
    • 根據 Wiki 下方的註解,Dell PERC 6 或 PERC 6i 有個叫做 Patrol Read 的功能,效用相等於 Data Scrubbing
    • Dell 網站上也提到這功能預設是開啟的,而且每七天會跑一次
    • 對照一下正在使用的 Dell R720 (使用 PERC H710 RAID Card),在 BIOS 當中的確有這個選項,且預設值是 Auto,所以這裡算是可以安心了
      1
  2. 關於 Synology,還的確得要做 RAID Scrubbing,但是,這個動作要花費的時間真的非常久(不知道和 Soft RAID 有沒有直接關係),像我花了三天時間對一個 22TB 的 RAID 6 做,目前的進度也才 45.3%
    2

Dell 對於 Patrol Read 的說明上有個補充項目,意思是這功能不會對 SSD 執行,我猜想是 SSD 本身的控制器就已經自帶 error detection / error correction 的功能,所以就不用靠 Data scrubbing 這個動作來預防可能有硬碟壞軌或 RAID 寫入不完全的錯誤。

企業級 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 去偵測並攔截這些惡意程式的話,效果會好非常多

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