Cybozu Garoon × ioDrive2 Duo × LifeKeeper 性能検証

Cybozu Garoon
×
ioDrive2 Duo
×
LifeKeeper
サイオステクノロジー株式会社
サイボウズ株式会社
Copyright © 2014 Cybozu
目次
▌検証の目的
▌サーバー構成
▌ベンチマークソフト
▌結果
▌補足
Copyright © 2014 Cybozu
2
検証の目的
Copyright © 2014 Cybozu
3
検証の目的
▌目的1
▌LifeKeeperによる冗長化を行った環境でも性能劣化が起きないのかを
ベンチマークソフトで評価する
▌目的2
▌Garoon 単体構成 と ioDrive2 Duo 2.4TB の構成でどこまでスケールする
かをベンチマークソフトで評価する
• 現在、GaroonはローカルHDDだと1台で5000名が最大(Linux OS)
Copyright © 2014 Cybozu
4
サーバー構成
Copyright © 2014 Cybozu
5
ハードウェア構成
10GbE
Garoon 単体/Active サーバー
Garoon Standby サーバー
サーバー：HP製 ProLiant DL380p Gen8
サーバー：HP製 ProLiant DL380p Gen8
CPU：E5-2690 2.9 GHz (8Core) * 2
CPU：E5-2690 2.9 GHz (8Core) * 2
MEM：160GB
MEM：160GB
HDD：SAS 900GB 10000RPM * 6
HDD：HDD：SAS 900GB 10000RPM * 6
追加NIC：10GbE * 2
追加NIC：10GbE * 2
ioDrive：ioDrive2 Duo 2.4TB
ベンチマークサーバー(ScaleBench)/メールサーバー(※)
ioDrive：ioDrive2 Duo 2.4TB
サーバー：HP製 ProLiant DL380p Gen8
CPU：E5-2690 2.9 GHz (8Core) * 2
MEM：160GB
HDD：SAS 900GB 10000RPM * 6
※：VMware ESXi 5.5 上に仮想マシンを2つ作成
Copyright © 2014 Cybozu
6
ioDrive2 Duo
ioDrive2 Duo(以下、ioDrive2)はNADN型フラッシュメモリのストレー
ジでPCIeに装着することで、OS上からローカルデバイスとして認識
させることが可能な大容量・高速ストレージである。
モデル名
ioDrive2 Duo 2.4TB
NANDタイプ
MLC(Multi Level Cell)
読み取り帯域幅(1MB)
3.0GB/秒
書き込み帯域幅(1MB)
2.5GB/秒
ランダム読み取りIOPS(512B)
540,000
ランダム書込みIOPS(512B)
1,100,000
※Fusion-IO社のHPより一部引用
http://www.fusionio.com/jp/images/datasheets/iodrive-two-datasheet-jp.pdf
Copyright © 2014 Cybozu
7
ソフトウェア構成(Garoon ActiveおよびStandby)
Real time
Data
Garoon/MySQL 5.5
LifeKeeper
ARK(DR,IP,FS)&GenericARK
Garoon/MySQL 5.5
Repication
LifeKeeper
ARK(DR,IP,FS)&GenericARK
LifeKeeper for Linux v8.2
LifeKeeper for Linux v8.2
ext4
ext4
ext4
Red Hat Enterprise Linux 6.4 64bit
ioDrive2
ext4
Red Hat Enterprise Linux 6.4 64bit
HDD
ioDrive2
Copyright © 2014 Cybozu
HDD
8
ScaleBench
ベンチマークソフト
Copyright © 2014 Cybozu
9
ベンチマークソフト
▌検証は弊社のベンチマークソフトScaleBenchを利用
▌仮想的なユーザー(VU：Virtual User)でGaroonへとアクセス
• HTTPリクエストを送信しブラウザアクセス時と同じ状況を再現
• アクセスするVUを徐々に増やし負荷をかける
▌負荷をシナリオ(scenario)で調整
▌運用規模に併せてデータを用意
• 10000名規模のデータを用意
• 容量は約2TB
Copyright © 2014 Cybozu
10
性能評価方法
▌Garoonの性能評価の方法は応答秒数が平均4秒を超えた時点でア
クセスしているVUの数を10倍し算出する
▌算出方法
• 例えば応答秒数が4秒を超えた時点でVUが300の場合
• VU：300 * 10 = 3000
• 上記より3000ユーザー相当まで耐えることができる、と評価
ScaleBench
Copyright © 2014 Cybozu
11
補足(ScaleBench/メールサーバーのOS)
▌VMware ESXi 5.5を利用し、ゲストOSを2つ作成
▌メールサーバー用
• Red Hat Enterprise Server 6.4 64bit
▌ScaleBench用
• Cent OS 5.8 64bit
Copyright © 2014 Cybozu
12
結果
Copyright © 2014 Cybozu
13
検証の順番
各検証でボトルネックおよび ioDrive2がそのボトルネックに対する
解となるかを確認する
1. 単体構成(※) + HDD
2. 単体構成 + ioDrive2
3. LifeKeeper(ミラーリング) + 単体構成 + ioDrive2
※複数台ではなく1台のサーバーにGaroonをインストールすることを指す
Copyright © 2014 Cybozu
14
各検証での応答秒数・ボトルネック
Response Time/ミリ秒
CPUがボトルネック
LifeKeeper(ミラー)+ioDrive2
4秒時点：29分～30分
VU：807->8070名相当
単体構成+HDD
4秒時点：17分～18分
VU：473->4730名相当
ディスクI/Oがボトルネック
CPUがボトルネック
単体構成+ioDrive2
4秒時点：29分～30分
VU：807->8070名相当
実行時間
Copyright © 2014 Cybozu
15
リソース状況(1)
▌単体 + HDD/ioDrive2 のCPU・ディスクリソース
ディスクI/Oの使用率が100%付近で推移
・CPU使用率が90%付近で推移
・残り10%はOSが利用している
Copyright © 2014 Cybozu
16
リソース状況(2)
▌LifeKeeper(DataReplication) + ioDrive2 でCPU/ディスクリソース
・CPU使用率が90%付近で推移
・残り10%はOSが利用している
Copyright © 2014 Cybozu
17
補足
▌チューニングを実施した箇所
▌LifeKeeper
▌ネットワーク
▌MySQL 5.5
Copyright © 2014 Cybozu
18
チューニングポイント(1)
▌LifeKeeperのチューニングポイント（1/2）
▌データレプリケーションのビットマップファイルをioDrive2上に作成
• データレプリケーションのビットマップファイル用にfdiskコマンドで
100MB程度のパーティションをioDrive2上に作成
• 上記パーティションにファイルシステム作成、マウント
• ミラー作成時、ビットマップファイルの配置先に指定
デフォルトでは内蔵HDDに配置されパフォーマンス低下の原因になる
Copyright © 2014 Cybozu
19
チューニングポイント(1)
▌LifeKeeperのチューニングポイント（2/2）
▌ ミラー作成前に/etc/default/LifeKeeperファイルに以下のパラメーターを設定
（注）これらの値は推奨値であり使用している環境によって異なる場合がある
• LKDR_CHUNK_SIZE=4096
メモリ上で更新された情報をファイルシステムに書き戻す際の大きさ（単位KB/s）
デフォルト値：64
• LKDR_SPEED_LIMIT=1500000
再同期に使用する最大帯域幅（単位KB/s）
可能な最大速度で再同期が実行されるように十分高い値に設定する必要がある
デフォルト値：50000
• LKDR_SPEED_LIMIT_MIN=200000
同時に他の I/O が実行されているときに許可する再同期の速度（単位KB/s）
ドライブの最大書き込みスループットの半分以下に設定する必要がある
デフォルト値：20000
Copyright © 2014 Cybozu
20
チューニングポイント(2)
▌ネットワークのチューニングポイント（1/2）
▌ 10Gbps NICの使用を推奨
▌ ジャンボフレームを有効にする
• /etc/sysconfig/network-scripts/ifcfg-<interface_name>ファイルに「MTU=9000」を追加
▌ NIC の転送キュー長を変更
• /etc/rc.localファイルに
/sbin/ifconfig <interface_name> txqueuelen 10000
を追加
▌ NIC の netdev_max_backlog を変更
• /etc/sysctl.confファイルに
net.core.netdev_max_backlog = 100000
を設定
Copyright © 2014 Cybozu
21
チューニングポイント(2)
▌ネットワークのチューニングポイント（2/2）
▌ TCP/IPの調整
• /etc/sysctl.confファイルに以下のパラメーターを設定
（注）これらの値は推奨値であり使用している環境によって異なる場合がある
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 0
net.core.optmem_max = 16777216
net.ipv4.tcp_congestion_control=htcp
Copyright © 2014 Cybozu
22
チューニングポイント(3)
▌MySQL 5.5ではioDrive2利用想定の設定変更
▌my.iniに追記
• 先読みページ読み込みの値を変更
• innodb_random_read_ahead = OFF
• 先読みページ読み込みの値を変更
• innodb_read_ahead_threshold = 0
Copyright © 2014 Cybozu
23
まとめ
▌ioDrive2を用いることでユーザー数が約8000名までスケールアウ
トすることが確認できた
▌ioDrive2 + LifeKeeper(データレプリケーション)の構成でもパ
フォーマンスの劣化は見られなかった
▌ioDrive2を使用するとディスクI/OではなくCPU等他のリソースが
ボトルネックとなり得るため、導入時にそれらがボトルネックと
ならない対策をとる必要がある
Copyright © 2014 Cybozu
24