2014年11月3日月曜日

今日の逸品

こんにちは。三連休の最終日、お天気は快晴で絶好の行楽日和となりましたね!

本当はどこかに出かけるか、外で思いっきりスポーツでもしたいところですが、某代理店さんからお借りしている最新の超高性能デバイスを本日中に返送しないといけないので、休日返上でブログを書きながらレポートしたいと思います(^^;)

まずは、写真をと。。。。じゃじゃーん!今日の逸品はこちらです!


IntelのPCI express typeのSSD DC P3700です。大きなヒートシンクに囲われていて、かっこいいですね!まあ、どんだけ熱くなるんだってお話もありますが。。。


裏面も、NANDチップがびっしりです。どんだけ大容量なんだ!


どうやら1.6TBのようです!!


こんな風に、サーバのPCIeスロットに装着します。ちょっと、見えづらいかも知れませんが、この1Uサイズのサーバは、PCIeスロットが二段になっていて、上段がP3700、下段がLSI RAIDカードとなっています。

インテル® Solid-State Drive DC P3700 シリーズのカタログスペックは、こんな感じです。
容量 Sequencial Read/Write  [MB/s]4KB Random Read / Write [IOPS]8KB Random Read / Write [IOPS]
400 GB2,700 / 1,080450,000 / 75,000275,000 / 32,000
800 GB2,800 / 1,900460,000 / 90,000285,000 / 45,000
1.6 TB2,800 / 1,900450,000 / 150,000290,000 / 75,000
2.0 TB2,800 / 2,000450,000 / 175,000295,000 / 90,000


シーケンシャルのリード/ライトが2.8GB/s、1.9GB/s、4KBのランダムリード/ライトが45万IOPS、15万IOPS !!

一気に眠気が吹き飛びます!!

ちなみに、7200rpmのSATA HDDの場合は、ざっくりとシーケンシャル100MB、ランダム100IOPS程度ですので、どれだけ高性能かおわかりいただけるでしょう。

ライバルは、もしかしてこれ?



使ってみたいですよね?それでは使ってみましょう。このカードは、PCIe SSDの新しい規格NVMe (http://en.wikipedia.org/wiki/NVM_Express)に対応していますので、Linuxカーネルでnvmeドライバがロードされている必要があります。

バニラカーネルをコンパイルする際には、CONFIG_BLK_DEV_NVME=m などとなるようにします。

うまく認識されると、/dev/nvmexxxとして、見えるようになります。
wheezy64:~# fdisk  -l /dev/nvme0n1
Disk /dev/nvme0n1: 1600.3 GB, 1600321314816 bytes
64 heads, 32 sectors/track, 1526185 cylinders, total 3125627568 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc55b79ff
        Device Boot      Start         End      Blocks   Id  System

fdiskでパーティション作成します。
wheezy64:~# fdisk /dev/nvme0n1
Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-3125627567, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-3125627567, default 3125627567):
Using default value 3125627567
Command (m for help): p
Disk /dev/nvme0n1: 1600.3 GB, 1600321314816 bytes
64 heads, 32 sectors/track, 1526185 cylinders, total 3125627568 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc55b79ff
        Device Boot      Start         End      Blocks   Id  System
/dev/nvme0n1p1            2048  3125627567  1562812760   83  Linux
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
ファイルシステム作ります。
wheezy64:~# time mkfs.ext4 /dev/nvme0n1p1
mke2fs 1.42.5 (29-Jul-2012)
Discarding device blocks: done                          
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
97681408 inodes, 390703190 blocks
19535159 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
11924 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848
Allocating group tables: done                          
Writing inode tables: done                          
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done     

real    0m13.304s
user    0m2.230s
sys     0m0.440s
マウントします。
wheezy64:~# mkdir /mnt/p3700
wheezy64:~# mount /dev/nvme0n1p1 /mnt/p3700/ 
wheezy64:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs           48G  510M   47G   2% /
tmpfs            48G  510M   47G   2% /
tmpfs           9.5G  228K  9.5G   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            10M     0   10M   0% /dev
tmpfs            19G     0   19G   0% /run/shm
/dev/nvme0n1p1  1.5T   70M  1.4T   1% /mnt/p3700 
とりあえず、100GB程度、読み書きしてみます。まずは、Write。
wheezy64:~# time dd if=/dev/zero of=/mnt/p3700/hello bs=100M count=1000 oflag=direct
1000+0 records in
1000+0 records out
104857600000 bytes (105 GB) copied, 77.9616 s, 1.3 GB/s
real    1m17.964s
user    0m0.000s
sys     0m45.700s 
そして、Read。
wheezy64:~# time dd of=/dev/null if=/mnt/p3700/hello bs=100M count=1000 iflag=direct
1000+0 records in
1000+0 records out
104857600000 bytes (105 GB) copied, 40.6814 s, 2.6 GB/s
real    0m40.684s
user    0m0.010s
sys     0m22.650s
カタログスペックには若干届かないですけど、爆速です!!

大事なのでもう一度、爆速です!!

ランダムIOを測ってみます。まずはrandomwrite。
wheezy64:~# fio --filename=/mnt/p3700/hello  --direct=1 --rw=randwrite --bs=4k --size=2G --numjobs=64 --runtime=180 --name=file1 --ioengine=aio --iodepth=512 --group_reporting
file1: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=512
...
file1: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=512
2.0.8
Starting 64 processes
Jobs: 1 (f=1): [____________________________________________________________w___] [98.4% done] [0K/833.5M /s] [0 /213K iops] [eta 00m:03s]s]
file1: (groupid=0, jobs=64): err= 0: pid=20537
  write: io=129218MB, bw=734950KB/s, iops=183737 , runt=180039msec
    slat (usec): min=3 , max=2162.1K, avg=322.56, stdev=12338.02
    clat (usec): min=12 , max=9825.2K, avg=166237.67, stdev=381829.66
     lat (usec): min=20 , max=9825.2K, avg=166560.46, stdev=382293.33
    clat percentiles (msec):
     |  1.00th=[    5],  5.00th=[    6], 10.00th=[    7], 20.00th=[    8],
     | 30.00th=[    9], 40.00th=[   11], 50.00th=[   13], 60.00th=[   22],
     | 70.00th=[   70], 80.00th=[  208], 90.00th=[  519], 95.00th=[  898],
     | 99.00th=[ 1844], 99.50th=[ 2343], 99.90th=[ 3458], 99.95th=[ 3884],
     | 99.99th=[ 5211]
    bw (KB/s)  : min=    0, max=310600, per=1.82%, avg=13395.80, stdev=22803.92
    lat (usec) : 20=0.01%, 50=0.01%, 100=0.01%, 250=0.01%, 500=0.01%
    lat (usec) : 750=0.01%, 1000=0.01%
    lat (msec) : 2=0.01%, 4=0.02%, 10=39.48%, 20=19.46%, 50=8.79%
    lat (msec) : 100=4.69%, 250=9.58%, 500=7.63%, 750=3.74%, 1000=2.47%
    lat (msec) : 2000=3.33%, >=2000=0.79%
  cpu          : usr=0.92%, sys=13.35%, ctx=29141732, majf=0, minf=3026598
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1%
     issued    : total=r=0/w=33079899/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
  WRITE: io=129218MB, aggrb=734949KB/s, minb=734949KB/s, maxb=734949KB/s, mint=180039msec, maxt=180039msec
Disk stats (read/write):
  nvme0n1: ios=0/33078988, merge=0/0, ticks=0/5930480, in_queue=5933370, util=99.60%

そしてRandomRead。
wheezy64:~# fio --filename=/mnt/p3700/hello  --direct=1 --rw=randread --bs=4k --size=2G --numjobs=64 --runtime=180 --name=file1 --ioengine=aio --iodepth=512 --group_reporting
file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=512
...
file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=512
2.0.8
Starting 64 processes
Jobs: 12 (f=6): [r__r____r___r__r__________r_r_r_r________________________r_r_r__] [93.2% done] [1403M/0K /s] [359K/0  iops] [eta 00m:08s]]
file1: (groupid=0, jobs=64): err= 0: pid=21635
  read : io=131072MB, bw=1194.3MB/s, iops=305724 , runt=109754msec
    slat (usec): min=1 , max=104416 , avg=181.86, stdev=2273.95
    clat (usec): min=88 , max=1698.4K, avg=94142.32, stdev=89737.06
     lat (usec): min=102 , max=1698.5K, avg=94324.37, stdev=89854.71
    clat percentiles (msec):
     |  1.00th=[   17],  5.00th=[   27], 10.00th=[   32], 20.00th=[   37],
     | 30.00th=[   42], 40.00th=[   57], 50.00th=[   72], 60.00th=[   85],
     | 70.00th=[  102], 80.00th=[  131], 90.00th=[  180], 95.00th=[  241],
     | 99.00th=[  478], 99.50th=[  594], 99.90th=[  865], 99.95th=[  979],
     | 99.99th=[ 1270]
    bw (KB/s)  : min=    6, max=164272, per=1.77%, avg=21641.11, stdev=11545.90
    lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
    lat (msec) : 2=0.01%, 4=0.03%, 10=0.40%, 20=1.29%, 50=34.99%
    lat (msec) : 100=32.37%, 250=26.29%, 500=3.75%, 750=0.66%, 1000=0.15%
    lat (msec) : 2000=0.05%
  cpu          : usr=1.34%, sys=37.50%, ctx=2798932, majf=0, minf=1003485
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1%
     issued    : total=r=33554432/w=0/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
   READ: io=131072MB, aggrb=1194.3MB/s, minb=1194.3MB/s, maxb=1194.3MB/s, mint=109754msec, maxt=109754msec
Disk stats (read/write):
  nvme0n1: ios=33536051/4, merge=0/0, ticks=4207010/0, in_queue=4260150, util=100.00%
レポートから結果を抜粋してみると。 write 183,737iops、read 305,724iopsとこれも爆速です!!  

最後にざっくりとmysqlのベンチマークを実行してみます。

Intel SSD DC P3700の場合
MySQLバージョン: "5.5.38"
root@kvm3:~# time mysqlslap --concurrency=50 --iterations=1 --auto-generate-sql --engine=innodb --auto-generate-sql-load-type=write --number-of-queries=5000000  --port=3306 --host=197.3.o -proot
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 153.368 seconds
Minimum number of seconds to run all queries: 153.368 seconds
Maximum number of seconds to run all queries: 153.368 seconds
Number of clients running queries: 50
Average number of queries per client: 100000

real 2m33.485s
user 0m38.288s
sys 4m37.968s
5,000,000クエリーを213.485秒で処理したので、約23,420クエリー/秒の処理性能でした。

ちなみに、AWSのRDSの場合は以下の通りでした。

インスタンスタイプ: db.t2.medium
MySQLバージョン: "5.6.17"
ストレージサイズ: 10GB
root@aws2:~# time mysqlslap --concurrency=50 --iterations=1 --auto-generate-sql --engine=innodb --auto-generate-sql-load-type=write --number-of-queries=5000000  --port=3306 --host=test.hsjektsilal9.ap-northeast-1.rds.amazonaws.com -p -vv
Building Create Statements for Auto
Building Query Statements for Auto
Generating INSERT Statements for Auto
Parsing engines to use.
Starting Concurrency Test
Loading Pre-data
Generating primary key list
Generating stats
Benchmark
        Running for engine innodb
        Average number of seconds to run all queries: 1082.128 seconds
        Minimum number of seconds to run all queries: 1082.128 seconds
        Maximum number of seconds to run all queries: 1082.128 seconds
        Number of clients running queries: 50
        Average number of queries per client: 100000

real    18m2.874s
user    0m8.965s
sys     0m46.891s

5,000,000クエリーを1082.128秒で処理したので、約4,620クエリー/秒の処理性能でした。

これも爆速といえるでしょう!!

MySQL用のストレージとして、Intel DC P3700いかがでしょうか?

現場からは以上です!

2014年10月26日日曜日

今日のお仕事

こんにちは。昨日、今日と暖かく過ごしやすい週末でしたね。
とはいえ、弊社では、サーバの納期が迫っていたため、休日返上で準備に追われていました。

今回のサーバはこんなやつです。


3Uのシャーシに3.5インチのHDDベイが16個並んでいて、一見ストレージサーバのように見えます。しかし、背面をのぞいてみると...


こんな、1ソケットのXeonサーバボードが....


こんな感じで、8ノード搭載されています!


IPMIも使えて、ssh経由のSMASH/CLPもなかなかグッドです。

WEBやキャッシュサーバなんかには、最適なんじゃないかと思います。

休日にも関わらず、出荷のお手伝いをしてくれたスタッフのMさん、ありがとう!

2014年8月27日水曜日

出荷を待つサーバたち

皆さんこんばんは。 今日は肌寒い一日でしたね。
季節の変り目には体調を崩しがちですので注意しましょうね。 

さて以下の写真は弊社で販売しているIntel IvyBridge Xeonプロセッサを2基搭載した、とっても高性能なサーバたちです。


メモリは、最大で512GB搭載可能で、最近は100GBを超えるものがよくご注文いただきます。LSIの高性能なRAIDカードが標準装備。8本のSSDと組み合わせることで、びっくりする位のIO性能をたたき出します。

オンラインゲームなどを支えるデータベースの高速化にぴったりです。 

お好みにより、10GBaseTのネットワークにも対応可能です。 商品紹介ページはこちら

一家に一台。奥さんいかがですか!

追記、開腹写真もありましたので、貼っておきます。



2014年8月11日月曜日

Intel SSDの保証とsmart情報について

こんにちは。暑い日が続きますね。

Intel SSDの保証期間について調べる機会がありましたので、 忘れないようにメモしておきます。

何のことはなくインテルの以下のページに、よくまとまってかかれています。
http://www.intel.com/jp/support/ssdc/hpssd/sb/CS-029645.htm

これによると、保証の条件は製品によって若干異なるようですが、大まかに言って、次の二つに大別されるようです。
  1. SSDのフラッシュメディアのWear out(摩耗)情報が取れるものに関しては、それが限度に達するか、5年または3年の保証。
  2. 上記に当てはまらないものは、5年または3年の保証。

SSDには書き込み寿命がありますので、保証期間内であっても、メディアが寿命を越えてしまった場合には、保証の対象外となってしまう場合があるようです。

手元に、Intel 520 SSD 240GBと、DC S3500 120GBがありましたので、詳しく調べてみました。

まず、Intel 520 SSD 240GBの場合。


以下のページを見ると、520は、"E9 メディア消耗指数 (Media Wear-Out Indicator) が利用できない"らしく、上述の保証条件の2番に当てはまりそうです。

http://www.intel.com/jp/support/ssdc/hpssd/sb/cs-032511.htm

なるほど、"Media Wear-Out Indicator"は取得できないのですね…確かめてみましょう。

手元のIntel 520 SSD 240GBと言うのは、実は、LSIのMegaraid 9266-8iという、それはそれは高性能なRAIDカードの配下にぶら下がっています。

Megaraid配下のドライブの"Media Wear-Out Indicator"情報を取得するには、RAIDのユーティリティ(megacli, storcli等)でドライブIDを特定し、smartctlでsmart情報を取得すれば良いようです。

まず、storcliでDriveIDを取得します。
# /opt/MegaRAID/storcli/storcli64 /c0 /eall /sall show
Controller = 0
Status = Success
Description = Show Drive Information Succeeded.
Drive Information :
=================
----------------------------------------------------------------------------
EID:Slt DID State DG       Size Intf Med SED PI SeSz Model               Sp
----------------------------------------------------------------------------
252:0     8 Onln   0 223.062 GB SATA SSD N   N  512B INTEL SSDSC2CW240A3 U
252:1    46 UBad   - 223.062 GB SATA SSD N   N  512B INTEL SSDSC2CW240A3 U
252:2    48 Onln   0 223.062 GB SATA SSD N   N  512B INTEL SSDSC2CW240A3 U
252:3     9 Onln   0 223.062 GB SATA SSD N   N  512B INTEL SSDSC2CW240A3 U
252:4    37 Onln   0 223.062 GB SATA SSD N   N  512B INTEL SSDSC2CW240A3 U
252:5    11 Onln   0 223.062 GB SATA SSD N   N  512B INTEL SSDSC2CW240A3 U
252:6    47 Onln   0 223.062 GB SATA SSD N   N  512B INTEL SSDSC2CW240A3 U
252:7    12 JBOD   - 232.375 GB SATA HDD N   N  512B ST9250421AS         U
----------------------------------------------------------------------------
EID-Enclosure Device ID|Slt-Slot No.|DID-Device ID|DG-DriveGroup
DHS-Dedicated Hot Spare|UGood-Unconfigured Good|GHS-Global Hotspare
UBad-Unconfigured Bad|Onln-Online|Offln-Offline|Intf-Interface
Med-Media Type|SED-Self Encryptive Drive|PI-Protection Info
SeSz-Sector Size|Sp-Spun|U-Up|D-Down|T-Transition|F-Foreign
この例では、{8,46,48,9,37,11,47,12}が各スロットにつながっているSSD/HDDのDriveIDとなります。

スロット0番のSSDのスマート情報を取得するには、例えば以下の様にすれば良いです。
# smartctl  -d megaraid,8  /dev/sdb -A
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.13.2-64kvmh01] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
/dev/sdb [megaraid_disk_08] [SAT]: Device open changed type from 'megaraid' to 'sat'
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   000   000   000    Old_age   Always       -       257801117878698
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       362
170 Unknown_Attribute       0x0033   100   100   010    Pre-fail  Always       -       0
171 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
172 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
174 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       353
184 End-to-End_Error        0x0033   100   100   090    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       353
225 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       1902970
226 Load-in_Time            0x0032   100   100   000    Old_age   Always       -       65535
227 Torq-amp_Count          0x0032   100   100   000    Old_age   Always       -       56
228 Power-off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       65535
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   097   097   000    Old_age   Always       -       0
241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       1902970
242 Total_LBAs_Read         0x0032   100   100   000    Old_age   Always       -       2432048
249 Unknown_Attribute       0x0013   100   100   000    Pre-fail  Always       -       50803
上記のsmart情報で、16進数でE9、すなわち233番がMedia_Wearout_Indicatorとなっていることが分かります。上記の場合、現在の値が97で、ワースト値が97、しきい値が0ということになります。

よく分からないので調べてみると、どうやら、新品のSSDはMedia_Wearout_Indicatorの値が100で、使用するにつれてだんだん減っていき、1になるともうダメと言うことのようです。
Media Wear-out Indicator は、正規化した (normalized) 値が 100 で (SSD が新規工場出荷時)、1 へと減少していきます。値が 1 になった時、それは消耗の限界に到達したことを意味し、データ消滅を防ぐためにその SSD を交換するか、バックアップを取ることが推奨されます。 
http://www.intel.com/jp/support/ssdc/hpssd/sb/CS-032510.htm
しきい値0と言うのは、smartの世界では、障害予測に用いないということを意味する、特別な値を示しているようです。
http://www.hdsentinel.com/smart/index.phphttp://www.easis.com/smart-value-interpretation.html 

インテルの保証のページには、520シリーズのSSDは"Media Wear-out Indicatorが取得できない"種類のSSDに大別されていましたが、どうやら取得できてしまうようですσ(^_^;)

どうせ壊れるんなら、保証期間内かつMedia Wear-out Indicatorが1になる前に壊れてくれることを祈りましょう。。。

ちなみにデータシートによると、241のTotal_LBAs_WrittenのRawValueは総書き込み量を32MByteで割ったもの、同じく242のTotal_LBAs_ReadのRawValueは総読み出し量を32MByteで割ったものであるようです。

したがって、この場合の書き込み総量は、60,895,040Mbyte = 約61Tbyte、読み出し総量は、77,825,536Mbyte = 約78TByteとなります。

かなり書き込んでるにも関わらず、Media Wear-out Indicatorが3しか減っていないと言うのはうれしいですね。(この割合で行くと仮定すると、あと1PB位は余裕で書けちゃいそうですね。)

次に、DC S3500 120GBの場合です。

以下のドキュメントによると、DC S3500シリーズのSSDは保証期間に加えて、Media Wear-out Indicatorも、保証の条件として考慮されるようです。
http://download.intel.com/support/ssdc/hpssd/sb/DC_S3500_Warranty_r0_Japanese.pdf
では、実際にMedia Wear-out Indicatorの値を確かめて見ましょう。

手元のDC 3500 120GBと言うのは、Adaptec 5805Zと言う、とっても高性能なRAIDコントローラーにぶら下がっています。

AdaptecのRAIDコントローラにぶら下がった、SSDやHDDのsmart情報を取得するには、次のようなコマンドを実行すれば良いはずです。
# smartctl -d sat /dev/sg3 -i
AdaptecのRAIDカードの場合、scsi genericドライバを読み込めば、/dev/sgXにデバイスファイルを作成してくれるので、それはそれは便利です。/dev/sgXのXの値が何になるかは、dmesgの出力を見て判別してもいいですが、/dev/sgXの数自体がそんなに多くなければ、順番にsmartctl -d sat /dev/sgX -iで調べていってもいいでしょう。

dmesgの出力例
# dmesg |grep scsi
scsi0 : aacraid
scsi 0:0:0:0: Direct-Access     Adaptec  1                V1.0 PQ: 0 ANSI: 2
scsi 0:0:1:0: Direct-Access     Adaptec  Device 1         V1.0 PQ: 0 ANSI: 2
scsi 0:1:0:0: Direct-Access     INTEL    SSDSC2BB12       D201 PQ: 1 ANSI: 5
scsi 0:1:1:0: Direct-Access     INTEL    SSDSC2CW24       400i PQ: 1 ANSI: 5
scsi 0:1:2:0: Direct-Access     INTEL    SSDSC2BB12       D201 PQ: 1 ANSI: 5
scsi 0:1:3:0: Direct-Access     INTEL    SSDSC2BB12       D201 PQ: 1 ANSI: 5
scsi 0:1:4:0: Direct-Access     INTEL    SSDSC2BB12       D201 PQ: 1 ANSI: 5
scsi 0:1:5:0: Direct-Access     INTEL    SSDSC2BB12       D201 PQ: 1 ANSI: 5
scsi 0:1:6:0: Direct-Access     INTEL    SSDSC2BB12       D201 PQ: 1 ANSI: 5
scsi 0:1:7:0: Direct-Access     INTEL    SSDSC2BB12       D201 PQ: 1 ANSI: 5
scsi 0:3:0:0: Enclosure         ADAPTEC  Virtual SGPIO  0 0001 PQ: 0 ANSI: 5
scsi 0:3:1:0: Enclosure         ADAPTEC  Virtual SGPIO  1 0001 PQ: 0 ANSI: 5
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:1:0: Attached scsi generic sg1 type 0
scsi 0:1:0:0: Attached scsi generic sg2 type 0
scsi 0:1:1:0: Attached scsi generic sg3 type 0
scsi 0:1:2:0: Attached scsi generic sg4 type 0
scsi 0:1:3:0: Attached scsi generic sg5 type 0
scsi 0:1:4:0: Attached scsi generic sg6 type 0
scsi 0:1:5:0: Attached scsi generic sg7 type 0
scsi 0:1:6:0: Attached scsi generic sg8 type 0
scsi 0:1:7:0: Attached scsi generic sg9 type 0
scsi 0:3:0:0: Attached scsi generic sg10 type 13
scsi 0:3:1:0: Attached scsi generic sg11 type 13
scsi1 : ata_piix
scsi2 : ata_piix
scsi3 : ata_piix
scsi4 : ata_piix
scsi 2:0:1:0: CD-ROM            TEAC     DV-28S-V         1.0B PQ: 0 ANSI: 5
scsi 2:0:1:0: Attached scsi generic sg12 type 5

/dev/sg2で試して見ます。
# smartctl -d sat /dev/sg2 -i
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.14.4-64kvmh01] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Device Model:     INTEL SSDSC2BB120G4
Serial Number:    BTWL40150AQK120LGN
LU WWN Device Id: 5 5cd2e4 04b5637db
Firmware Version: D2010370
User Capacity:    120,034,123,776 bytes [120 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ACS-2 revision 3
Local Time is:    Mon Aug 11 13:57:01 2014 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Media Wear-out Indicatorの値は、以下のように取得できます。

# smartctl -d sat /dev/sg2 -A
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.14.4-64kvmh01] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       798
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       14
170 Unknown_Attribute       0x0033   100   100   010    Pre-fail  Always       -       0
171 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
172 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
174 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       9
175 Program_Fail_Count_Chip 0x0033   100   100   010    Pre-fail  Always       -       17188520638
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   090    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   074   074   000    Old_age   Always       -       26 (Min/Max 23/27)
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       9
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       33
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       0
225 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       6850
226 Load-in_Time            0x0032   100   100   000    Old_age   Always       -       30
227 Torq-amp_Count          0x0032   100   100   000    Old_age   Always       -       76
228 Power-off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       47910
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   100   100   000    Old_age   Always       -       0
234 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       6850
242 Total_LBAs_Read         0x0032   100   100   000    Old_age   Always       -       21958

Media_Wearout_Indicatorの値は100です。つまり、新品同様です。

Total_LBAs_WrittenやTotal_LBAs_Readで見ても、それぞれ、219,200Mbyte、702,656Mbyte相当となりますので、まだまだたくさん使えそうです。

まとめ

Intel SSDの保証とsmart情報について調べて見ました。保証の条件は製品により異なりますが、Media Wearout Indicatorの値が取得できるとされる製品とそうでないものに大別され、前者の場合、Media Wearout Indicatorが1になってしまうと、保証交換が受けられないと考えられます。Media Wearout Indicatorはsmartctlコマンドで取得できます。手元にあったIntel 520とDC S3500は両方とも値が取得できました。SMART情報には、他にもTotal LBA WrittenなどSSDの使用状況を確認するのにちょうど良い値が記録されているので、いろいろ調べてみると良いでしょう。




2014年4月16日水曜日

Lineのインフラセミナーに参加してきました。

昨日、LINE Developer Conference(テーマ:インフラ)に参加してきましたので、備忘録的にメモ。

1. Systemのお話し(講演の途中から参加)

  • 年末年始の障害、redisのレスポンスが悪化し、コネクションバースト。redisの処理とNIC割り込みを同じコアで処理していた。/proc/interruptをwatchして発見し、tasksetで解決。
2. データベースのお話し
  • Lineツムツムのデータベースのお話し。multimasterのmysql replication。PerconaのMMM Managerを使用。write VIPとread VIPをMMMが管理。Failover時にVIPを移動。
  • Shardの自動追加。すべてのUIDに対しハッシュ関数を通しグループIDを発行。グループIDに対しshardを割り当てる。
  • MMMはカスタマイズして使っている。主に障害判断の部分。
  • shardの追加時には、移動するグループに対しselect/insert(update?)を複数回に分けて実行する。更新時刻でソートして実行しているので、マイグレーション中に更新されたデータも、もれなく移動することができる。
3.ネットワークのお話し
  • 内部ネットワーク。Core-Pod-Edgeの3階層。unknown unicast flooding により、ギガビット大半の帯域を消費していた。Pod当たり数千台のサーバ。L2セグメントはPod単位だったのを、L2セグメントをEdge単位にした。
  • ロードバランサL3DSR採用。L2セグメントを小さくしたので必要になった。DSCP方式。Tosフィールドのdscp=1などを設定し、それに応じてソースアドレスをリアルサーバで付け替える。
  • ラックは24kVA 51U。スイッチは背面設置。サーバの排熱を避けるためにスイッチ3台を囲えるダクトを作成。
  • 海外拠点はアメリカ、アジア3ヶ所、ヨーロッパ。リングトポロジー。専用線を節約し、冗長性を確保。MPLSでPseudo Wire。出来るだけルーティングに関与せずに、拠点間接続。
  • サーバ間接続とユーザーエッジへの接続を、別々のネットワークにした。ユーザーがどの拠点に接続するか、登録時のユーザー情報をもとにスタティックにマッピング。クライアント側で実装。
  • TCPコネクションはりっぱなし。ロードバランサのセッション、コネクションテーブルサイズがボトルネックになっていた。→ Stateless SLB ハッシュテーブルに基づいて、リクエストを分散。ソースIPをキーにハッシュ値計算すればいい。サーバが落ちるとハッシュ再計算。
  • ハッシュの再計算を部分的に行うタイプの機器で、Stateless SLBを実現。今年一月から。
  • 箱物のロードバランサを使っているらしい。LVSとかじゃダメなのかな?

お土産までいただきました。ありがとうございます!