アシアルブログ

アシアルの中の人が技術と想いのたけをつづるブログです

Netapp NAS - Asial's unsung hero

Hello, Anthony here.
My last couple of blogs have been about Zabbix, the enterprise network monitoring system that we recently installed. As I mentioned in my last piece after a few teething problems this is now working fine and I think we all sleep easier at night knowing that any problems will be picked up before they become critical. And if the worst does happen then we'll know about them immediately.

So this month I'd like to discuss something that Zabbix indirectly highlighted and has taken up quite a bit of my time over the last week or so. That is Netapp.

Now Asial maintains installations in a couple of data-centers but we don't go there more often than we have to. For a start almost everything that needs doing can be done remotely, secondly they're inconvenient to get to, and finally they are extraordinarily inconvenient to actually get into. Security is rigorous, you have to book in advance, take several forms of ID, be escorted into and out of the building, and, well to put it bluntly the data-centers do everything they can to discourage visitors. So while I was aware we had a Netapp server I'd had very little to do with it.

For the uninitiated a Netapp server can best be described as a large noisy box. It doesn't look particularly impressive, at least from the front, and anyone randomly wandering in off the street would guess it was fairly low down the digital pecking order. It certainly doesn't have all the flashing lights that, say a router has. And it has lots of clumsy chunks of plastic poking out of it, not at all the sleek lines of our HP Proliant servers. However the fact is our Netapp server is critically important to us, probably the single most important item on the rack, because it provides high availability, high redundancy storage.



All our servers have a certain storage capacity of course but all the really important stuff goes on Netapp. This means while the OS runs on the server, in many cases the data itself will be on Netapp. Why? Well behind each one of those chunks of plastic sits a hard drive, 14 of them in Asial's case, providing not just several terabytes of storage, but more importantly speed and reliability. Each hard drive is working with all the others to distribute load and maintain service. It can take snapshots of data at regular intervals so that recovering from an accidental deletion is trivial. Indeed the snapshot process is so fast and efficient that in many ways it renders traditional backups obsolete. Finally in addition to those 14 active hard drives there are a number of spares. If Netapp detects a problem with one of the active drives it will bring one of the spares online and deactivate the defective disk. In other words if a disk dies, service is unaffected.

My problem therefore is how to know when a disk has failed. There are no signs, no interruption in service, no complaints from users, just a seamless switching over from one disk to another. Well getting this information, and various other important details has been what I've been up to recently. I've had to do quite a bit of reading around the Netapp OS, checking the settings currently in use. Even if I don't know what they mean now they're still a useful benchmark for anything that might change in the future.

So what happens if Tokyo gets hit by a major earthquake and takes the entire Netapp installation out? Hmm... perhaps that's a topic for next month.

QNAP TS-209 Pro II で遊んでみた

この度、社内用ファイルサーバーに QNAP TS-208 Pro II ( http://www.qnap.com/pro_detail_feature.asp?p_id=94 )を使用することになったので、せっかくなので遊んでみました。

インストールの作業自体は簡単で、

1・HDDを入れる(Seagate ST31000340AS 1TB x2)
2・接続する
3・電源入れる
4・起動したら、windowsPCにCD入れて、付属のソフトをインストール
5・起動するとネットワークに接続された機器の一覧が出るので、選択。
6・ウィザードにしたがって設定。(アドレスは固定、RAIDRAID-1に設定)

以上で初期設定は終了。

さて、とりあえずアクセス。
デフォルトではsshでログイン出来ます。

内部は完全にLinuxで、



[~] # uname  -a
Linux NASAD0A37 2.6.12.6-arm1 #25 Wed Apr 16 20:26:17 CST 2008 armv5tejl unknown
 
[~] # cat /proc/cpuinfo
Processor         : ARM926EJ-Sid(wb) rev 0 (v5l)
BogoMIPS          : 332.59
Features          : swp half thumb fastmult
CPU implementer   : 0x41
CPU architecture: 5TEJ
CPU variant       : 0x0
CPU part          : 0x926
CPU revision      : 0
Cache type        : write-back
Cache clean       : cp15 c7 ops
Cache lockdown    : format C
Cache format      : Harvard
I size              : 32768
I assoc               : 1
I line length         : 32
I sets                : 1024
D size                  : 32768
D assoc                   : 1
D line length             : 32
D sets                    : 1024
 
Hardware                  : MV-88fxx81
Revision                  : 0000
Serial                      : 0000000000000000
 
[~] # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/ram0                 9.7M      7.0M      2.7M  72% /
tmpfs                    16.0M     40.0k     16.0M   0% /tmp
/dev/sda4                62.0M     38.1M     23.9M  61% /mnt/ext
/dev/md9                509.5M    105.4M    404.1M  21% /mnt/HDA_ROOT
/dev/md0                915.8G    167.1M    915.7G   0% /share/MD0_DATA
/dev/ram0                 9.7M      7.0M      2.7M  72% /mnt/HDA_ROOT/rootfs_2_3_6/bin
/dev/ram0                 9.7M      7.0M      2.7M  72% /mnt/HDA_ROOT/rootfs_2_3_6/dev
/dev/md9                509.5M    105.4M    404.1M  21% /mnt/HDA_ROOT/rootfs_2_3_6/etc/config
/dev/md0                915.8G    167.1M    915.7G   0% /mnt/HDA_ROOT/rootfs_2_3_6/share/Qdownload
tmpfs                    16.0M     40.0k     16.0M   0% /mnt/HDA_ROOT/rootfs_2_3_6/tmp


こんな感じです。

では、早速計測してみます。

まずはローカルから、



cd /share/MD0_DATA/Public


とりあえず、ほぼ無無負荷状態の時にゼロを1GB読み書きしてみました。



[/share/MD0_DATA/Public] # time dd if=/dev/zero of=./hoge.img bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
 
real      1m46.655s
user      0m3.170s
sys       1m23.220s
 
[/share/MD0_DATA/Public] # time dd if=./hoge.img of=/dev/null bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
 
real      0m41.158s
user      0m2.020s
sys       0m29.410s


計算すると、

read 約24MB/s
write 約10MB/s

今度は、ネットワークから

クライアントのスペックは、
IBM Thinkpad G40
Debian GNU/Linux etch
100BASE-TX
いくつかハブを経由しているのでほとんどトラフィックのない夜と朝方にテストしました。

ftp



RETR /Public/fuga.img
150 Opening BINARY mode data connection for /Public/fuga.img (1073741824 bytes)
| [=====================================================================================================================================================] @ 11166.61KB/s

STOR /Public/bar.img
150 Opening BINARY mode data connection for /Public/bar.img
\ [=====================================================================================================================================================] @ 9661.95KB/ss


nfs



time dd if=/dev/zero of=/mnt/iso/fuga.img bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 142.73 s, 7.5 MB/s
dd if=/dev/zero of=/mnt/iso/fuga.img bs=1024 count=1048576  0.30s user 5.08s system 3% cpu 2:23.83 total

time dd if=/mnt/iso/fuga.img of=/dev/null bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 108.552 s, 9.9 MB/s
dd if=/mnt/iso/fuga.img of=/dev/null bs=1024 count=1048576  0.35s user 4.78s system 4% cpu 1:48.70 total


smbfs



time dd if=/dev/zero of=/mnt/iso/fuga.img bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 133.417 s, 8.0 MB/s
dd if=/dev/zero of=/mnt/iso/fuga.img bs=1024 count=1048576  0.18s user 3.62s system 2% cpu 2:13.57 total

time dd if=/mnt/iso/fuga.img of=/dev/null bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 177.035 s, 6.1 MB/s
dd if=/mnt/iso/fuga.img of=/dev/null bs=1024 count=1048576  0.36s user 5.74s system 3% cpu 2:57.65 total


以上です。
smbの読み込みが遅いのが気になるので、windows2000のマシンで試したところ、

read 8.6MB/s
write 8.5MB/s

社内ではLinuxからsmb使うことはほとんど無いので問題ないと言うことにしましょう。
まあ、それ以外は個人的には満足なスペックかと思います。

そのうちに時間があればTeraStation Pro との比較もしてみよう。