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

之前提到了說 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 上看到產品名稱上有個「企業級」三個字 就去買來用,到時候出狀況可別怪到這兒來啊