我的 VirtualSAN 讀寫測試

VMware 已於今年 3 月 12日正式推出 VSAN (VirtualSAN)。我相信這產品吸引不少人的注意。首先我的公司在虛擬化方面，現在是使用 VSphere 5.0 + 3 x HP P4300。這架構也用了好幾年，亦到了需要擴展的階段。所以對於 VSAN 這個產品，我們也抱著相當大的興趣，所以在較早前下載了 VSphere 5.5 回來測試一番，並與現在的架構於速度上，比較一下。

測試 VSAN 主機環境：
VSphere ESXi 5.5 主機共三台，該三台主機是安裝於 Dell M1000e Chassis，而每台配置如下：
DELL PowerEdge M620
    - Xeon X5650@2.67GHz 6 Cores x 2pcs
    - 64Gb RAM
    - Intel DC S3700 Series 100GB SSDSC2BA100G301 2.5" SATA 3 6Gb/s SSD
    - Dell  2.5" SAS 146G 6Gb/s 15krpm HDD
    - 4pcs x 1Gb Adaptor (on B & C slots)

網路環境：
Dell PowerConnect M6348 x 4pcs (B1, B2, C1, C2)

測試虛擬機的設定：
    OS: Windows XP
    VCPU: ( number of virtual sockets: 1; number of cores per socket: 8)
    Memory: 1Gb


為了要有一個清晰的比較，我除了找來現在Production的架構外，另外找來 HP BladeSystem + FC Storage，以及單台 PC 作比較。

現有 Production 的 P4300 環境：
VSphere ESXi 5.0 主機共三台，該三台主機是安裝於 Dell M1000e Chassis，而每台配置如下：
DELL PowerEdge M620
    - Xeon X5650@2.67GHz 6 Cores x 2pcs
    - 64Gb RAM
    - 4pcs x 1Gb Adaptor (on B & C slots)

網路環境：
Dell PowerConnect M6348 x 4pcs (B1, B2, C1, C2)

儲存裝置：
三台HP Lefthand P4300 G2 8T 組成的 HP Storage Cluster
HDD: 1Tb 7200rpm

測試虛擬機的設定：
    OS: Windows XP
    VCPU: ( number of virtual sockets: 1; number of cores per socket: 8)
    Memory: 1Gb

HP BladeSystem + FC Storage 環境：
硬件：
     HP BladeSystem
        - c7000 Enclosure G2
        - ProLiant BL460c Gen8
          (    Xeon E5-2680 x 2 processors, 16G RAM    )

        - HP B-series 8/12c SAN Switch BladeSystem c-Class
        - HP VC Flex-10 Enet Module

    HP Storage P2000 G3 FC MSA

OS: Windows 2008R2 64bit Enterprise Edition

測試軟件：iometer 板本：2006.07.27

測試項目：
    Disk Target:
        - 16000000 sectors (8G size)
        - 16 per target (no. of Outstanding I/Os)

    No. of workers: 8

    Access Specification:
        4K; 100% Read; 0% random
        4K; 100% Read; 80% random
        4K; 70% Read; 80% random
        4K; 50% Read; 80% random
        4K; 50% Read; 0% random

測試結果：

Target Type 說明：
P4300 - 是指 Production中的環境，即 ESXi 5.0 + HP Lefthand P4300 G2,其執行測試的虛擬機的 SCSI Controller 為 BusLogic Parallel.

VSAN SSD BL - 是指使用上述 VSAN 測試環境，其執行測試的虛擬機的 SCSI Controller 為 BusLogic Parallel.

VSAN SSD PVSCSI - 是指使用上述 VSAN 測試環境，其執行測試的虛擬機的 SCSI Controller 為 VMware Paravirtual.

VSAN SSD LSI SAS - 是指使用上述 VSAN 測試環境，其執行測試的虛擬機的 SCSI Controller 為 LSI Logic SAS.

HP MSA2000 - 是指使用上述的 HP BladeSystem + FC Storage 測試環境，其執行的操作系統為 Windows 2008R2 64bit Enterprise Edition.，由於此環境是沒有虛擬化，所以是使用 HPLpe1205A FC HBA.

Target Type	Access Specification Name	IOps	Read IOps	Write IOps	MBps	Read MBps	Write MBps	Transactions per Second
P4300	4K; 100% Read; 0% random	12,212.127	12,212.127	0.000	47.704	47.704	0.000	12,212.127
VSAN SSD BL	4K; 100% Read; 0% random	4,740.406	4,740.406	0.000	18.517	18.517	0.000	4,740.406
VSAN SSD PVSCSI	4K; 100% Read; 0% random	16,056.946	16,056.946	0.000	62.722	62.722	0.000	16,056.946
VSAN SSD LSI SAS	4K; 100% Read; 0% random	9,600.117	9,600.117	0.000	37.500	37.500	0.000	9,600.117
HP MSA2000	4K; 100% Read; 0% random	8,299.105	8,299.105	0.000	32.418	32.418	0.000	8,299.105
Target Type	Access Specification Name	IOps	Read IOps	Write IOps	MBps	Read MBps	Write MBps	Transactions per Second
P4300	4K; 100% Read; 80% random	1,111.533	1,111.533	0.000	4.342	4.342	0.000	1,111.533
VSAN SSD BL	4K; 100% Read; 80% random	1,857.710	1,857.710	0.000	7.257	7.257	0.000	1,857.710
VSAN SSD PVSCSI	4K; 100% Read; 80% random	5,423.012	5,423.012	0.000	21.184	21.184	0.000	5,423.012
VSAN SSD LSI SAS	4K; 100% Read; 80% random	6,717.932	6,717.932	0.000	26.242	26.242	0.000	6,717.932
HP MSA2000	4K; 100% Read; 80% random	1,560.186	1,560.186	0.000	6.094	6.094	0.000	1,560.186
Target Type	Access Specification Name	IOps	Read IOps	Write IOps	MBps	Read MBps	Write MBps	Transactions per Second
P4300	4K; 70% Read; 80% random	988.997	692.521	296.476	3.863	2.705	1.158	988.997
VSAN SSD BL	4K; 70% Read; 80% random	1,319.366	921.783	397.583	5.154	3.601	1.553	1,319.366
VSAN SSD PVSCSI	4K; 70% Read; 80% random	6,376.888	4,462.153	1,914.736	24.910	17.430	7.479	6,376.888
VSAN SSD LSI SAS	4K; 70% Read; 80% random	5,266.276	3,686.681	1,579.595	20.571	14.401	6.170	5,266.276
HP MSA2000	4K; 70% Read; 80% random	1,081.348	757.498	323.850	4.224	2.959	1.265	1,081.348
Target Type	Access Specification Name	IOps	Read IOps	Write IOps	MBps	Read MBps	Write MBps	Transactions per Second
P4300	4K; 50% Read; 80% random	857.384	427.228	430.156	3.349	1.669	1.680	857.384
VSAN SSD BL	4K; 50% Read; 80% random	1,065.819	534.168	531.651	4.163	2.087	2.077	1,065.819
VSAN SSD PVSCSI	4K; 50% Read; 80% random	4,251.774	2,119.182	2,132.592	16.608	8.278	8.330	4,251.774
VSAN SSD LSI SAS	4K; 50% Read; 80% random	3,185.194	1,595.781	1,589.414	12.442	6.234	6.209	3,185.194
HP MSA2000	4K; 50% Read; 80% random	1,021.078	511.948	509.130	3.989	2.000	1.989	1,021.078
Target Type	Access Specification Name	IOps	Read IOps	Write IOps	MBps	Read MBps	Write MBps	Transactions per Second
P4300	4K; 50% Read; 0% random	1,121.322	559.546	561.776	4.380	2.186	2.194	1,121.322
VSAN SSD BL	4K; 50% Read; 0% random	1,295.807	645.841	649.966	5.062	2.523	2.539	1,295.807
VSAN SSD PVSCSI	4K; 50% Read; 0% random	4,625.646	2,313.626	2,312.020	18.069	9.038	9.031	4,625.646
VSAN SSD LSI SAS	4K; 50% Read; 0% random	7,770.314	3,887.471	3,882.842	30.353	15.185	15.167	7,770.314
HP MSA2000	4K; 50% Read; 0% random	3,537.858	1,765.679	1,772.179	13.820	6.897	6.923	3,537.858

總結：
據以上測試結果來看，VSAN 架構在隨機讀寫的情況下有明顯優勢。P4300 表現其實也算中等。唯獨是  HP BladeSystem + FC Storage 測試環境，不知是我的設定有問題，還是其他原因，以上 5 種不同的 situations 都沒有特別明顯的優勢。

向虛擬化出發(八) — Rich Client 前端客戶機

現在新出的PC價錢便宜，功能強大。如果祇將它 Configure 為 Thin Client，實在有點浪費了前端的運算能力。這時候Rich Client 慨念萌生，但是會遇到電腦病毒、和分散式管理上的問題。是否祇有向虛擬化出發(四) 的架構才可解決問題呢？答案顯然並非絕對。這篇文章正是來探討這個問題。


將新PC設定成唯讀模式
在購買原商機時，很多時其實已經附有 OEM XP，即其實這台PC已經不需要安裝其他 OS了。所以若將該 XP設定成唯讀的話，每次開機都是和最初所設定的一樣，這是一個不錯的避免電腦病毒的方法。至於如何將 XP 設定成唯讀模式，請參閱以下連結：http://victor8314.blogspot.com/2008/05/ewf.html


但當然在還未將使用者的工作站上的設定成唯讀模式前，必須要釐定出該Rich Client所需要執行應用程式的範圍。因為該 Rich Client可配向虛擬化出發(六) 自製的RemoteApp架構來將應用程式與工作站分開，因此可做出不同的配搭。

例子：使用者需要以Microsoft Internet Explorer瀏覽網頁，以Microsoft Outlook Express收發電子郵件。

 
在這個例子中的架構，其好處是：


1. 可有效地防止使用者的工作站感染電腦病毒，因為當工作站重新啟動之後，一切恢復原狀。

2. 使用VM來將 Outlook Express分開，所以這樣可解決Rich client 是唯讀的問題，讓Email 可保存下來。

3. 當電腦病毒是經由電子郵件傳入時，由於將收發郵件的應用程式分開，所以其影響範圍大大縮小。

4. 沒有向虛擬化出發(六) 所述的Network Load問題。

5. 由於Microsoft Internet Explorer是在Local的Rich client下執行，所以沒有Legacy問題。

虛擬化 UDP 解決方案

問題：
當我將公司的工作站台虛擬化時，由於不能即時一刀切地將整個網絡環境轉成完全虛擬化，即有部分工作站是已經虛擬化，而有部分是未虛擬化。然而虛擬化其中一個目的是想提高網絡上的安全性，另外一個原因是TCP/IP的Class C已經超出公司原先定下的範圍，所以亦有必要將網絡環境的TCP/IP升到Class B，因此在將工作站虛擬化時遇到的問題亦較多。其中一項便是 UDP，有些舊系統所廣播的UDP是 Hardcode定了廣播範圍，因此當虛擬化出來的工作站的TCP/IP為Class B時便收不到該UDP。

SKCC UDP Redirector正為解決此問題而生，它原理是從舊網絡聽取封包，即時由新網絡播放。因此可輕易地解決不同網絡的 UDP 封包問題。

大家可用以下連結下載：

http://space.uwants.com/html/13/1514813-382040.html

向虛擬化出發(七) — 建立 PXE 伺服器

PXE（Preboot Execution Environment，它是基於TCP/IP、DHCP、TFTP等Internet協議之上的擴展 網路協議）技術提供的從網路啟動機器的功能。因此使用PXE 伺服器，將向虛擬化出發(五) 中所述的 Thinstation 套用於現時的每一台工作站有以下好處：

1.        建立好 PXE 伺服器之後，每一台工作站都可以不用再安裝任何東西，祇需要將工作站設定為 PXE Boot便可。所以可以很快便完成每一個工作站的設定。之前安裝 Thinstation要5分鐘，現1分鐘也不用。

2.        使用 PXE伺服器之後，其相關工作站均無碟化（即工作站不再需要軟盤、硬盤、光盤…）。須知道有些使用者用了1X年電腦，關機時還是直接 power off的…硬盤還不提早收工…

3.        統一化 Thinstation 版本。

4.        中央管理 Thinstation 的使用者設定。還記得thinstation.conf.user檔嗎？它就是儲存著使用者的 Thinstation的設定值。當使用者的 Thinstation設定值須要更改時，在中央管理後，管理人員不用SSH到每一台工作站中修改，直接往 PXE Server裡找便可以了。（雖知道使用者的工作站有時會關掉吧…）

5.        即時獲悉 Thinstation是否真的能夠安裝到使用者的工作站中。如果每台工作站要真的安裝才知道有問題的話，那麼要還原時便很麻煩了。現在祇要在 BIOS轉一轉設定即可。

我的 PXE伺服器安裝步驟如下：

1.        準備一台機器作為 PXE Server，不用太快，VM亦可以。硬件需要：256MB RAM + 1G硬盤 + 1塊網卡(不用支援PXE的網卡也可以)。

2.        以最少安裝模式來安裝CentOS 5.3於兩台機器中，即可以不安裝 Virtualization和 Gnome、KDE等套件。當然要設定好網卡可連接 Internet啦。

3.        把 yum 先更新：

#yum update

4.        安裝 DHCP Server 套件

#yum install dhcp

5.        安裝 TFTP Server套件

#yum install tftp-server

6.        設定 DHCP Server的 /etc/dhcpd.conf檔：

ddns-update-style interim;

ignore client-updates;

not authoritative;

allow booting;

allow bootp;

option domain-name "thinclient.net";

option ip-forwarding false; # No IP forwarding

option mask-supplier false; # Don't respond to ICMP Mask req

default-lease-time    259200;

max-lease-time      518400;

subnet 123.123.123.0 netmask 255.255.255.0 {

    option subnet-mask 255.255.255.0;

    option broadcast-address 123.123.123.255;

    group {

        next-server 123.123.123.254;

        filename "pxelinux.0";

#Fixed IPs....

host TC001 { #Workstaion Name: TC001

hardware ethernet 00:12:34:56:78:9A;

fixed-address 123.123.123.1;

}

    }

}

7.        設定 TFTP Server 的/etc/xinetd.d/tftp 檔：

service tftp

{

socket_type  = dgram

protocol     = udp

wait         = yes

user         = root

server       = /usr/sbin/in.tftpd

server_args  = -s /tftpboot

disable      = no

per_source   = 11

cps          = 100 2

flags        = IPv4

}

8.        將向虛擬化出發(五) 中所述的 Thinstation所Build的輸出影像資料夾，即/opt/Thinstation-2.2.2/boot-images/PXE/ 裡的所有檔案抄出來，並放於 PXE server的 /tftpboot路徑下。

9.        將thinstation.conf.user檔針對該工作站作修改，並另存為 /tftpboot/thinstation.conf-IP，以本例子則為：/tftpboot/thinstation.conf-123.123.123.1檔。

10.     啟動服務：

#chkconfig dhcpd on

#chkconfig xinetd on

#service dhcpd restart

#service xinetd restart

11.     在使用者的工作站 BIOS 改成 PXE 為Primary Boot，試試能否成功…

當然，要能夠使用到 PXE伺服器來啟動使用者的工作站，除了需要建立好 PXE伺服器，在工作站端必需要有支援 PXE啟動的網絡卡。

向虛擬化出發(六) — 我的土炮RemoteApp version 1.0煉成

在我寫這篇日誌時 Microsoft Windows 2008已經出爐了，其中為世人津津樂道的是Microsoft的 RemoteApp。於是我亦研究了一下…發現它也是利用 Remote Desktop Client 去連接遠端的 Windows 2008 Terminal Service，然後呼叫安裝於 Windows 2008 的應用程式，並收執行畫面傳回來。在整個測試過程中，不難發現以下幾點：
1.    Remote Desktop Client 一定要版本 6.1 以上才可使用。在觀看其 ActiveX Control 可知一二。因為祇有6.1版本才有 AdvancedSettings7，而 RemoteProgram 等的 property 正正要在 AdvancedSettings7。

2.    在Microsoft的 Download Center中，Windows 2003的 Remote Desktop Client到目前為止，最高版本也祇是 6.0版本。

3.    遠端的操作系統一定要 Windows 2008，因為祇有 Windows 2008 的 Terminal Service 才支援。意思是你的遠端所有 Application Servers 一定要 Windows 2008。即 Windows XP 可以呼叫 Windows 2008 的 Application，但 Windows 2008 並不可以呼叫 Windows XP 的 Application。如果是這樣的話，那麼粗略地估計也衍生出另外一些問題：
3.1    Windows 2008 是否 100% 能兼容 Windows XP 的 Application？
3.2    Windows 2008 Standard Edition的License + Windows 2008 Terminal Service的 License所需之費用是否比 Windows XP 的 Remote Desktop License 便宜？

總括來說，我感覺是Windows 2008這個 RemoteApp有點不切實際。

OK…話說回來，雖說 Microsoft的諸多不是，但這次練成類似 RemoteApp這種效果，還是要用到 Remote Desktop Client的 ActiveX Control。在 Internet 上，我曾經試著找 seamless RDP、seamless application類的字眼，但此終找不到一個免費而完美的答案。不過也找到非常非常接近的連結：

http://www.cendio.com/seamlessrdp/ 就是 Cendio 的 SeamlessRDP。

http://www.codeproject.com/KB/IP/tswindowclipper.aspx 就是The Code Project的 Extending Microsoft’s Terminal Services Client To Provide Seamless Windows By Martin Wickett。

http://properjavardp.sourceforge.net/ 就是properJavaRDP 開放成源碼計畫。

而我的靈感也是從以上相關資訊產生的。然而以上三個 seamless 方法，也有著共通一個短點，就是不能同時於同一個遠端開啟多於一個 Application。最簡單，大家可參考Mr. Martin Wickett的方法，利用瀏覽器去呼叫 RDP Client的ActiveX Control來連接遠端的 Terminal Service並啟動某一特定應用程式（如：Internet Explorer）。試試能不能呼叫了這個 IE 後，再呼叫多一次？當然不可以，因為兩次呼叫都是同一個登入賬戶嘛祇有一個User Session…自然另外的一個就給踼走了。

然而我的RemoteApp版本 1.0所實現的方法是需要有相關編程經驗才能達成的，其原理如下：

RemoteApp-Server
在遠端機器中準備一支服務應用程式 (RemoteApp-Server)，該程式有以下特點：
1.    當程式一啟動就會將 Program Manager、Taskbar 隱藏。
2.    當程式一隱藏了Program Manager、Taskbar後，將底圖移走，將整個桌面顏色設為 Lime青檸色又或者自行決定用那種顏色。該顏色是作為Chroma Key的用途。
3.    接受遠端RemoteApp-Launcher連接。
4.    執行遠端RemoteApp-Launcher傳來要執行應用程式的指令。
5.    當對應的應用程式關閉時，要立即通知遠端RemoteApp-Launcher。
6.    當接到遠端RemoteApp-Launcher關閉指令，要立即關閉其對應的應用程式。


RemoteApp-Desktop
在使用者桌面上準備一支應用程式(RemoteApp-Desktop) ，該程式有以下特點：
1.    此程式沒有 Windows的Frame。
2.    內裡有著一個跟使用者桌面一樣大的 Remote Desktop Connection的ActiveX Control，使之重疊。
3.    當程式一開放，便根據預設值連接到遠端機器。
4.    該程式是 Always On Top模式。
5.    將RemoteApp-Desktop的主 Form的透明顏色設定成 RemoteApp-Server的Chroma Key 顏色，並設為定是使用透明模式。

RemoteApp-Launcher
在使用者桌面上準備另一支應用程式(RemoteApp-Launcher) ，該程式有以下特點：
1.    連接遠端的 RemoteApp-Server程式。
2.    傳送執行應用程式的指令到遠端的 RemoteApp-Server。
3.    當收到RemoteApp-Server發出的對應的應用程式關閉時，要立即關閉。
4.    當收到此應用程式關閉時，要立即通知遠端的 RemoteApp-Server。






實現了以幾個程式後，該軟體關係架構會變成這樣：

使用者從工作站登入的流程便會變成：
1.    Thin Client 利用 RDP 連接 Windows Server 的 Terminal Service。
2.    成功登入後，會產生一個 User Session。
3.    在這個 User Session建立後，該登入賬戶便會自動開啟 RemoteApp-Desktop。
4.    RemoteApp-Desktop根據預設的資訊，自動以 RDP連接到遠端的VM。但由於RemoteApp-Desktop設了透明，所以看不見的。
5.    遠端的VM被登入後，便自動開啟 RemoteApp-Server。
6.    RemoteApp-Server開啟後，會等待 RemoteApp-Launcher連接。

使用者從工作站開啟 Application 1的流程便會變成：
1.    使用者在其 User Session中，開啟Application 1的RemoteApp-Launcher。
2.    RemoteApp-Launcher連接到 RemoteApp-Server建立連接 Session，並要求RemoteApp-Server開啟 Application 1。
3.    RemoteApp-Server 收到指令後，執行 Application 1。由於Application 1並不是透明，所以從使用者的角度祇看到 Application 1 所顯示的畫面區域。從而達成 Seamless Application效果。

如果大家真的可以實作出來，應該感覺到不錯吧…真的很像 XenApp。這個Work Around的方法我也很滿意，一來不用重新編寫 Terminal Service、Protocol和RDP Client（即使要我寫我可能也不出來，這些東西不是一兩個人可以寫出來的，何妨我孤身一人！？）。二來這個方法也十分簡單，不用百行程式就可搞定的事。不過，這裡仍有一個很大的問題存在，這就是 Network Load…不信？看看你開啟 Application 1後，由 Windows Server的Terminal Service連接到 Thin Client之間的 Network Load…一塊 100Mbps連接的網絡，由原先的0.x%可即時高至18%…解決辦法，留待下一篇再說。