使用ISCSI & Linux LVM2 搭建Report DB

有一臺Report DB，原先一直用本地磁碟，146G * 6 Raid 5。最近終於撐不住了，因為它的Production已經快到700GB。

現在的暫行策略是把Report也放到Production上做。

Production經過元旦期間的大調整，現時的表現非常之好。即使是把Report也放上去之後，OLTP Client也沒受到影響（主要是把Business搞得很透了，在元旦期間做的業務I/O分離很成功，這對IO Bound系統， 是個大利好）

但是AP的Leader還是不放心，決定還是要把最重的一部份Report單獨拿出來跑。

應對這樣的需求，像SAN這種貴重的物品自然是申請不到，何況還在經濟危機。所以，充分利用手頭資源就是最佳選擇。

[@more@]

我最後定的方案就是利用原有Server，採用ISCSI和LVM作儲存方案，來搭建這個Report DB。

資源：2U Server 3臺，1臺Core Xeon 8Core 做DB Server, 2臺舊型號2CPU P4 Xeon作ISCSI Storage.

Switch: Cisco 2970, Cisco 3750

下面紀錄下這搭建過程中的瑣事。

1． Network Bonding

因為方案中用到ISCSI，所以網路的Stable就很重要。沒有采用Multipath---我沒找到相應的Multipath軟體，但應該是有的，因此選擇了Bonding。

Bonding有7種Mode, 如果要作到Load Balance & Failover，有mode 0/2/4/5/6 可以選擇，其中Mode 0 round-robin是唯一一種對單TCP流也能做到分割的Mode,但實際效果很一般，而且一個網路卡斷開網路的時侯可能丟包，即使請Network Team在Switch上做了Etherchannel也不行。

最終的測試結果選擇了Mode 4---802.3AD。這種Mode 需要在Switch上做Etherchannel，然後再開啟LACP。對於Cisco的Switch，最好選擇Active Mode的LACP。其工作模式類似於一個網路卡收，一個網路卡發，這個特性從Ifconfig的RX/TX也能看出來，並且一個網路卡斷開後表現很穩固，沒有丟包。

期間有個齷齪事：DB server是Intel Pro1000, Storage Server是Broadcom, Broadcom的網路卡可以ifup/ifdown，但Pro1000 ifdown了後再也起不來(未作bonding前可以)…

2． ISCSI

中間又發生了件齷齪事：ietd.conf的一堆註釋中藏了2個安全選項，搞得我的Client死活找不到ISCSI儲存…這個浪費了我一小時的時間。

使用的是Enterprise ISCSI Target 0.4.16版。

3． LVM

RHEL4 自帶的LVM2。最終我建立了4個VG，把本地的PV和ISCSI的PV分開了。

開始我擔心以後ISCSI裝置多了，/dev/下的sdx編號會亂掉，所以用UDEV自定了RULES，結果發現做成VG後，LVM還是隻用/dev/的東西，忽視掉了Symbol link。不過又想到LVM用UUID去認Device的話，即使亂掉，也應該不影響LVM之上的Filesystem才對。

結果現在關機變得比較齷齪：LVM似乎是在Kernel中，搞不好起來得比ISCSI要早，而且為了防備ISCSI起不來的情況，/etc/fstab 自動mount是不敢用了。所以現在準備了mount/umount shell。關機之前需要先關Oracle, 再umount mount-point，然後inactive LV on ISCSI，最後service iscsi stop。

4． 系統的最終表現

我曾經很期待Bonding之後的千兆傳輸吞吐量，結果即使在最有利的Mode 0 RR模式下，單執行緒SCP只有37MB/S左右。Mode 4相比Mode 0的差異也很小。不過在多個SCP的測試下，還是比單網路卡要強大的。我相信這有助於提高ISCSI所提供的IOPS。

Storage Server的HDD是SCSI RPM15K 146GB，理論寫入能力在100M/S之上，這個37MB的瓶頸顯然在網路，我考慮下來，最大的可能就是MTU，因為Cisco的2970的內部傳輸高達16G，而且為了避免2臺Switch之間頻寬的限制，2臺Server接在了一臺Switch上。

目前我們的網路標準MTU=1500，那差不多寫一個8K的Block 需要6個Frames.

做成LV後（3個ISCSI PV組成了1個Striped LV）寫入速度在70~73M/S, 此時系統IOWAIT高達50%，我看了下，LV接受的IOPS每秒18000，但3個PV的IOPS每個到210就是峰值了。

讀取：

以Select count(*) from Table A(about 4.5億rows) 來看

遠端的ISCSI Target上HDD的IO能力表現：IOPS 大約230多，到頂，但Throughput只有10MB多些，我覺得是TCP/IP的frame限制使得IO Request fragment. 如果能啟用Jumbo Frame的話，應該能好不少。

LV上IOPS 大約等於3個PV的IOPS的和的一半，這令我比較詫異，是LV Stripe天生使然還是我Stripe Depth設定太差？我的Stripe Size是128KB。

此時ISCSI上的LV的svctm 平均是3.x, 不算很好。

測算下來，ISCSI LV stripe=3 的效能大約相當於Local Disk LV strip=3的40%左右。

對於不太要求即時性的Report DB而言，還算湊合，畢竟盤多了。

如何再提高ISCSI的能力，大概有這些方法：專用HBA，Multipath，Jumbo Frame。

專用HBA對目前來說不太可能，Multipath & Jumbo Frame 就原理來看應該作用會比較大。