使用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 就原理来看应该作用会比较大。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10856805/viewspace-1016353/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10856805/viewspace-1016353/