Transcript と1 - IBM

SQLServerの日中バックアッ
プとインスタント・リストア
の適用
～測定結果レポート
2009/07/29(水)
Wikiをご覧になったお客様へのお断り
 当資料は、筆者が2009/07に特定の環境下で実際に実施したテストの結果をまとめ
たものです。皆様のキャパシティ・サイジングの際の「ご参考」になるかと考え、非公式に
公開させていただくものです。
 従いまして、お客様の環境で同じ結果、同じパフォーマンスが出ることを保証するもの
ではございません。
 当資料はIBMの正式なレビューを受けておりません。IBMとしての正式な資料でもござ
いません。
 上記、ご了解の上ご高覧頂きますよう、お願い申し上げます。
1
中堅・中小企業様のDBサーバーの現状
1日1回の夜間バックアップ
コールド・バックアップ
テープ主体の運用
ログを絡めた復旧運用なし
2
目標・お客様にとっての利点
目標
中堅・中小企業様のデータベース・サーバーをFastbackでデータ保護したい
お客様にとっての利点
3
1.
1日1回の夜間バックアップを日中毎時のオンライン増分バックアップにすればテープ運
用が不要になり、障害復旧時のデータ・ロスも最大1時間分に抑えることができる
(RPOが改善)
2.
回復時にインスタント・リストアを利用すれば業務復旧までの時間を大幅に短縮でき
る(RTOが改善)
3.
C:\ドライブも一緒にとればOSも同時に保護できるので一石二鳥
目標・課題
検証ポイント
1. 日中1時間毎にバックアップした場合、本番業務への影響はどの程度か?
(応答時間やシステムのリソース)
2. サーバー復旧時にインスタント・リストアは本当に使いものになるのか？
(戻しは可能なものの遅くて使いものにならない、などの事態を招かないか?)
3. リポジトリーのクリーンアップの負荷はどの程度か?
4
検証実施の想定と実施内容(サマリー)

環境～中堅中小企業向けの小規模DBサーバーを想定
►
DBサーバー、Fastbackサーバーとも Dual Core×1、メモリー2GBの環境で測定
►
日中はデータ･エントリー型の業務で、多くても1秒に1件程度の負荷(OLTP型)を想定
1. 増分バックアップが本番業務中へ与える影響
►
DB負荷ツール(JMETER)でアプリケーション負荷を再現
►
上記ツール実行中に10GBの増分スナップショットを実行
►
各々の単独実行時と同時実行時で様子を比較する
2. インスタント・リストア中のDB業務のレスポンス
►
DBの存在するドライブを初期化してインスタント・リストアを実行
►
DB負荷ツール(JMETER)でアプリケーション負荷を再現
►
上記を同時に実行してケース1.の単独実行時の結果と様子を比較する
3. リポジトリーのクリーンアップ
►
5
上記のテストで実行したスナップショットを削除してクリーンアップする
検証環境(サマリー)
FastBackサーバー機
お客様のDB機(※1)
1GB LAN
(※1)
①
Fastback
SQLServer
②
DB負荷ツール
製品+DB+LOG
約200GB
リポジトリー
1TB
事前の測定ではバックアップが
35～40MB/秒で採取できる環境
※1….msconfigでDual Core×1相当に制限
※2….msconfigで2GBに制限
6

2009/07/22(水),7/23(木) @ 渋谷SWCOCにて実施
検証環境(詳細)
1GB LAN
マシン仕様
Fastbackサーバー(Fastback 5.5.4)
マシン
x3650q3
IP
172.22.128.13
モデル
System x 3650(7979-P7D)
CPU
QuadCore Xeon x5460 3.16GHz 2way(※1)
ディスク
300GB SAS HDD ×6(5本でraid-5)
メモリ
16GB RAM(※2)
ネットワーク ギガビット　イーサ
ディスク構成
#1
OS
#2
#3
5本でRAID-5を構成
#4
#5
リポジトリー
#6
ソフトウエア構成
Windows2003 standard 32bit
Fastback 5.5.4
7
業務サーバー(SQLServer2005 Enterprise SP3 )
x3650q1
172.22.128.11
System x 3650(7979-P7D)
QuadCore Xeon x5460 3.16GHz 2way(※1)
300GB SAS HDD ×6(5本でraid-5)
16GB RAM(※2)
ギガビット　イーサ
OS
負荷サーバー(JMETER)
x32501
172.22.128.125
System x 3250
QuadCore Xeon x3220 2.4GHz 1way
73GB SAS HDD ×2 (RAIDなし)
4GB
ギガビット　イーサ
OS
ワーク
5本でRAID-5
データベース
Windows2003 standard 32bit
Fastback 5.5.4 client
SQLServer 2005 Enterprise SP3 32bit
Windows2003 standard 32bit
Apache JMETER
検証の結果・所見サマリー(1/2)


8
増分バックアップが本番のレスポンスやリソースに与える影響は、どうか?
►
OLTP型の処理であれば業務レスポンスへの影響は限定的。
高負荷でもSQLは10-20msのオーダーで返っており「使用に耐えない」レベルではない。
►
高負荷でもバックアップ時間は80%程度の悪化に抑えられる
►
(今回の負荷はSMBのOLTP系データ・エントリー業務としては多目と思われる)
インスタント・リストア中のDBは使用に耐えるか?
►
リストア中でもSQLServerの起動は15Sで完了
►
10多重の場合はSQLが平均40-50msで返っている。
無風状態の時は7msなので約7倍遅くなっているが、「使用に耐えない」レベルではない。
►
50多重の場合はSQLが平均360msで返っている。
無風状態の時は7msなので約50倍遅くなっており、同等の負荷レベルの場合はユーザーが遅さ
を体感する可能性がある。ただ、障害回復中であるのでユーザー数を絞って優先的に行うべき業
務のみを先行実施する、などの運用は可能と思われるし 「一切使えない」よりは明らかにマシと思
われる。
検証の結果・所見サマリー(2/2)

9
クリーンアップ中のリソースの使用状況は?
►
クリーンアップ中のFBサーバーのCPU負荷は50%前後で一定(今回は「高優先度」で実行)
►
クリーンアップはCPUを喰うしIOも多数発生するので、バックアップと競合する可能性がある
日中のスケジュールは望ましくない。
夜間利用しない業務であれば夜間、夜間もバッチ等が発生するならば週末、など
バックアップやDRの実行と重ならない時間帯に実行するのが望ましい。
►
ざっくり言って150GB前後のDBのクリーンアップで増分が実データの2-3倍程度であれば、Dual
Core×1のサーバーで１時間もあれば終わる、とも言える。
(もちろんDBの更新量によるのだが、実環境では今回ほどの更新量は発生しないのではないか?
とも思われる)
1. 日中バックアップ
10
検証の方式
①JMETERでSQLServerを10GB分更新する(増分バックアップのデータ生成)
②DB負荷ツールを使用してSQLServerに対して負荷をかける
③その状態でFastbackによりC:\ドライブ+ DB 10GBのバックアップを行う
→レスポンスへの影響は? システムリソースの状況は?
お客様のDB機
FastBackサーバー
機
1GB LAN
①&②
Fastback
リポジトリー
1TB
③
SQLServer
製品+DB+LOG
約200GB
※1….msconfigでDual Core×1相当に制限
※2….msconfigで2GBに制限
11
DB負荷ツール
テスト・ケース一覧
内容
12
1-(1)
無風状態で10GBのDB更新を行った直後にバック
アップ(増分バックアップ量=約5GB)
1-(2)
DBに対し軽めの負荷(10多重)をかける
1-(3)
1-(1)と1-(2)を同時に実行
1-(4)
DBに対し重めの負荷(50多重)をかける
1-(5)
1-(1)と1-(4)を同時に実行
比較のポイント
1-(1),(2)の結果と比較
1-(1),(4)の結果と比較
増分バックアップが本番業務中へ与える影響～所見


13
影響は、どうか?
►
OLTP型の処理であれば業務レスポンスへの影響は限定的。
高負荷でもSQLは10-20msのオーダーで返っており「使用に耐えない」レベルではない。
►
高負荷でもバックアップ時間は80%程度の悪化に抑えられる
►
(今回の負荷はSMBのOLTP系データ・エントリー業務としては多目と思われる)
リソースは?
►
バックアップ中のDBサーバーのCPU負荷は15-6%増。
►
バックアップ中のFBサーバーのCPU負荷は40-50%。
CPU的にはジョブ2多重が限界か.(但しネットワークのボトルネックがあるのでリニアに伸びない)
►
Dual Core×1程度のマシンでも問題なし
►
ボトルネックは主にネットワークとIOとなる
►
メモリーは一定量で変化なし(DB機-1.8GB、FB機-500MB)
リソースの状況
CPU - DBサーバー、FBサーバーとも余裕あり
IO - 1-(3),(5)ともIO競合が発生すると100%を超える(※1)
ネットワーク – 40MByte/秒でありギガビット･イーサネットの上限に達していると言える
※1..%DiskTimeはWindowsのパフォーマンス･モニターでデータ採取したため100%を超える場合あり。
従って厳密な数字ではありません。ケース間の比較に於いて見ていただくのがよろしいかと思います。
後で調査したら 100%-(Idle time)で見るべき、との情報がありましたが、データを採取していませんでしたので
ご了承ください
14
バックアップ実行時間の変化
 今回のバックアップ量は増分10GBで
実行時間は約5分
►
1分で2GB相当。中堅中小企業の伝票
入力型アプリケーションでの日中1時間あた
りのデータベース更新量としてはかなり多目
と言える。
 当然ながら、アプリケーション稼動中に
バックアップをとるとIOの競合によりバック
アップ自体のパフォーマンスは低下する
 今回のケースでは10多重の場合は殆ど
変化なし(若干向上しているが誤差の範
囲内と思われる)
 50多重の場合は処理の効率が約80%
に低下したが、実運用で問題になるよう
な低下ではないものと考える
15
DB 10多重の場合の応答時間への影響
ケース比較
上=単独実行
下=バックアップと同時実行
結果
平均応答時間は7ms→9ms
スループットは89.0→87.3
KB/secは562.1→551.5
評価・所見
この程度の負荷なら、バックアップ
はアプリへの影響は殆ど影響なし
16
DB 50多重の場合の応答時間への影響
ケース比較
上=単独実行
下=バックアップと同時実行
結果
平均応答時間は9ms→15ms
スループットは418.6→397.9
KB/secは2643.2→2514.3
評価・所見
平均応答時間が60%増となって
いるが、平均15msであれば「遅く
て使用できない」レベルとは思われ
ない。(十分に早い)
17
資料) データベース(SQLServer)の構成
G:\ドライブ(300GB)
 製品、システムDB､ログ､ユーザー
DBすべてを同一のドライブに配置
(I/O分散的にはPoorな環境)
製品導入ディレクトリー
 大きいテーブル×1
システム・カタログ類
(Master等)
SQLServerログ
小さいテーブル×10
合計150GB
 テーブルのレイアウトは同一
 Primary Keyあり
dbo.Order1
(500万行=50GB)
 1行=1K
order2
order3
order4
order5
order6
order7
order8
order9
order
10
order
11
Order2～11 = 各100万行=10GB
18
資料) 負荷のパターン
1トランザクションの処理内容
•Order1～Order8までの8種類のテーブルから各々に対し結果セット10行取得(800行)
•Order9～Order11までの3テーブルに対して1行更新
•→1Trx合計 select=8回 update=3回
•利用するキーはランダムに選択。 (=バッファーヒットは限定的)
すべてプライマリ索引経由のアクセス(=テーブルの全スキャンなし)
19
多重度
説明
単独実行時の負荷目安
1 軽め
10
10台のPCから連続して上記のトラン
ザクションが継続的に投入されている
環境
1秒あたり6-7TRX
2 重め
50
50台のPCから連続して上記のトラン
ザクションが継続的に投入されている
環境
1秒あたり30-32TRX
※SMBのDBサーバーと
してはかなり重い負荷
資料) JMETERの例
多重度
設定可能
止めるまで
永久にループ
500万件からランダム
にキー選定
当該キーから10件分を
SELECT
100ms待機
ここは結果セットの確認用
なので今は意味なし
20
2. インスタント・リストアの業務への影響
21
検証の方式
①G:\ドライブをフォーマットし、その状態でFastbackによりインスタント・リストアを行う
②リストアの最中にDB負荷ツールを使用してSQLServerに対して負荷をかける
→レスポンスはどのくらい? システムリソースの状況は?
お客様のDB機
FastBackサーバー
機
1GB LAN
②
Fastback
リポジトリー
1TB
①
SQLServer
製品+DB+LOG
約200GB
※1….msconfigでDual Core×1相当に制限
※2….msconfigで2GBに制限
22
DB負荷ツール
テスト・ケース一覧
23
内容
比較のポイント
2-(1)
インスタント･リストア実行中にDBに対し軽めの負荷
(10多重)をかける
無風状態での状況(1-(2))と比
較
2-(2)
インスタント･リストア実行中にDBに対し重めの負荷
(50多重)をかける
無風状態での状況(1-(4))と比
較
インスタント･リストア中の本番業務は使用に耐えるか?～所見

24
使用に耐えるか?
►
リストア中でもSQLServerの起動は15Sで完了
►
10多重の場合はSQLが平均40-50msで返っている。
無風状態の時は7msなので約7倍遅くなっているが、「使用に耐えない」レベルではない。
►
50多重の場合はSQLが平均360msで返っている。
無風状態の時は7msなので約50倍遅くなっており、同等の負荷レベルの場合はユーザーが遅さ
を体感する可能性がある。ただ、障害回復中であるのでユーザー数を絞って優先的に行うべき業
務のみを先行実施する、などの運用は可能と思われるし 「一切使えない」よりは明らかにマシと思
われる。
インスタント･リストア中の本番業務は使用に耐えるか?～所見

25
リソースは?
►
リストア中のDBサーバーのCPU負荷は10-14%増。
►
バックアップ中のFBサーバーのCPU負荷は数%程度。これはDBの細かいIOを優先して処理して
いるためと思われる。
►
JMETERを停止するとリストアのパフォーマンスが向上する動きが見られた。JMETERによるDBア
クセス中はリストアは中断状態になるため、リストア自体の完了は長期化する可能性がある。
ただし、リストアが進めば進むほどディスク上にデータが見つかるので業務のパフォーマンスはよくなる
はずであるし、業務的にDBが一定の応答時間で利用できている限り、インスタント・リストア自体
の全体完了時間が長期化しても何ら支障はないものと考える。
►
Dual Core×1程度のマシンでも問題なし
►
メモリーは一定量で変化なし(DB機-1.8GB、FB機-500MB)
リソース状況
26
DB 10多重の場合の応答時間への影響
ケース比較
上=単独実行
下=バックアップと同時実行
結果
平均応答時間は7ms→45ms
スループットは89.0→65.1
KB/secは562.1→410.9
評価・所見
27
DB 50多重の場合の応答時間への影響
ケース比較
上=単独実行
下=バックアップと同時実行
結果
平均応答時間は9ms→360ms
スループットは418.6→106.4
KB/secは2643.2→672.1
評価・所見
28
Lessons Learned
 DBの起動時間
►
インスタント・リストア開始直後にSQLServerを起動したが15sで起動した
►
同様にManagement Studioは30秒で起動した
 DB負荷をかけて必要なブロックを戻している間、元々のインスタント・リストアは中断してい
るように見受けられる。(DBリクエストを優先しているので正しい処理)
DBリクエストを停止するとリストアが再開され、リストアのパフォーマンスも急激に改善した。
左記はネットワークのパフォーマンス。
赤い矢印の時点でJMETERを停止して業務負荷をなくしたと
ころ、本来の40MB/秒の転送に戻っている
29
3. クリーンアップ処理
30
検証の方式
検証作業の過程で採取したバックアップをクリーンアップし、リソース状況と所要時間を測定
FastBackサーバー
機
お客様のDB機
対象外
Fastback
リポジトリー
1TB
※1….msconfigでDual Core×1相当に制限
※2….msconfigで2GBに制限
31
1GB LAN
クリーンアップの負荷は?～所見

32
リソースは?
►
クリーンアップ中のFBサーバーのCPU負荷は50%前後で一定(今回は「高優先度」で実行)
►
クリーンアップはCPUを喰うしIOも多数発生するので、バックアップと競合する可能性がある
日中のスケジュールは望ましくない。
夜間利用しない業務であれば夜間、夜間もバッチ等が発生するならば週末、など
バックアップやDRの実行と重ならない時間帯に実行するのが望ましい。
►
メモリーは一定量で変化なし(FB機-500MB)
►
今回は40JOB,372GBの解放に42分かかった。今回はC:ドライブとG:ドライブを同一のポリシーに
含めて同時に実行している.(ゆえにジョブ数は各々20) 。ログによればC:ドライブのクリーンアップは
増分の累積 約20GBが2分で完了した。同様にG:ドライブの増分の累積 370GBが40分であり、
約20倍とほぼ比例関係にあるように見受けられる。ゆえに世代数、ジョブ数などはクリーンアップ実
行時間にあまり関係がなく、クリーンアップする(累積した)増分データ量が主要因と思われる。
►
逆の表現をすれば、ざっくり言って150GB前後のDBのクリーンアップで増分が実データの2-3倍程
度であれば、Dual Core×1のサーバーで１時間もあれば終わる、とも言える。
(もちろんDBの更新量によるのだが、実環境では今回ほどの更新量は発生しないのではないか?
とも思われる)
クリーンアップ実行結果
 [2009/07/23 20:15:36]-> FBSS1516I
[2009/07/23
[2009/07/23
[2009/07/23
[2009/07/23
20:17:39]->
20:17:44]->
20:57:38]->
20:57:44]->
FBSS1517I
FBSS1516I
FBSS1517I
FBSS1520I
ポリシー: ‘MSSQL’ ボリューム: C オン x3650q1 上でクリーンアップが開始されました。
ポリシー: ‘MSSQL’ ボリューム: C オン x3650q1 上でのクリーンアップが正常に終了しました。
ポリシー: ‘MSSQL’ ボリューム: G オン x3650q1 上でクリーンアップが開始されました。
ポリシー: ‘MSSQL’ ボリューム: G オン x3650q1 上でのクリーンアップが正常に終了しました。
クリーンアップが終了し、リポジトリーから [372,800] M バイトが解放されました。
Windowsの「イベント・モニター」に出力す
るので監視＆後から確認可能
33
実行前リポジトリー状況
20世代40JOB分
34
実行後リポジトリー状況
5世代10JOB分
35
Lessons Learned
 クリーンアップの途中でリポジトリーの使用率が上昇する動きがみられた
►
お掃除のためのワークエリアを使っているため
►
リポジトリーに余裕がない状況ではクリーンアップ自体ができなくなる可能性?-今回は未検証
►
リポジトリーの使用率のしきい値警告を若干低めに設定して、ワークの分の余裕が常に確保できる
ようにする運用が望ましい
実行前
実行中
実行後
36
参考資料
37
マシンのディスク(ドライブ)構成
DBサーバー
Fastbackサーバー
38
1-(1) 無風状態のバックアップ ～CPUとディスクIOの様子
CPU%
% Disk Time
※1..%DiskTimeは
Windowsのパフォーマン
ス･モニターでデータ採取し
たため100%を超える場合
あり。従って厳密な数字で
はありません。ケース間の
比較に於いて見ていただく
のがよろしいかと思います。
39
1-(1)
DBサーバー
40
Fastbackサーバー
1-(2) 10多重のDB操作 ～CPUとディスクIOの様子
41
1-(2)
DBサーバー
42
1-(3) バックアップ+10多重のDB操作を同時に実行
43
1-(3)
DBサーバー
44
Fastbackサーバー
1-(4) 50多重のDB操作 ～CPUとディスクIOの様子
この1分間のCPU
は異常値?
45
1-(4)
DBサーバー
46
1-(5) バックアップ+50多重のDB操作を同時に実行
47
1-(5)
DBサーバー
48
Fastbackサーバー
2-(1) インスタント・リストア中のDB10多重
49
2-(2) インスタント・リストア中のDB50多重
50
3-(1) クリーンアップ
51
ご参考) CPUやメモリーを絞る方法 - msconfig
当ツールで設定してリブートすれば
マシンに上限を設定可能
X365 Quad Core×2way=8CPUのマシンが
DualCore(2CPU)×1wayに見える
(メモリーも同様に2GBと見えている)
52