C12 AlwaysOn 可用性グループとデータベースミラーリングのIO特製の比較 by...

18
1 AlwaysOn可用性グループと データベースミラーリングの IO特性の比較 Microsoft Corporation SQL Server Customer Advisory Team Principal Program Manager Yorihito Tada [email protected]

Transcript of C12 AlwaysOn 可用性グループとデータベースミラーリングのIO特製の比較 by...

1

AlwaysOn可用性グループと データベースミラーリングの

IO特性の比較

Microsoft Corporation SQL Server Customer Advisory Team Principal Program Manager Yorihito Tada [email protected]

2

SQLCAT (Customer Advisory Team)

お客様プロジェクトの成功 Bwin–ヨーロッパで最もポピュラーなアミューズメントサイト、

30,000 万トランザクション/秒、100 TB トータル ストレージ Temenos–銀行勘定系パッケージ ベンダー; 1 TB DB, 100 k

batch requests/sec プロダクトの改善

顧客プロジェクトへの深いかかわりから、プロダクトへのフィードバックを SQL Server 開発チームに伝えます

コミュニティへの貢献 http://sqlcat.com SEAS (SQL Server Enterprise Architecture Summit) の開催、

PASS Summit などへの貢献

SQL Server Customer Advisory Team (SQL CAT) は SQL Server の製品開発グループを代表して顧客プロジェクトを支援するチームです。SQLCAT はワールドワイドで大規模で複雑なプロジェクトに参加しています。

3

アジェンダ

SQL Server 2012 AlwaysOn AlwaysOn可用性グループとデータベースミラー

リング それぞれのIO特性 Appendix

4

SQL Server 2012 AlwaysOn

AlwaysOn 統合された管理環境 迅速なリカバリ ハードウエア利用効率の向上

Availability Groups (可用性グループ) データベース単位 共有ディスク無し 複数DBのフェールオーバー 複数のセカンダリーサーバ

Failover Cluster Instances インスタンス単位 共有ディスク 複数サイト(サブネット)でのクラスタリング

※Windows Server Failover Cluster上に実装

5

Availability Group で実現するシナリオ データセンター内での高可用性 同期レプリカ

ゼロ データ ロス 自動フェールオーバー

高速かつ柔軟なフェールオーバー リーダブルセカンダリ

ハードウエアリソースの有効活用

同期

非同期

6

Availability Group で実現するシナリオ ディザスタリカバリ 複数のレプリカ

同期レプリカは 2 つまで可能 非同期レプリカ

ネットワークの影響を最小化 マルチ サブネット

柔軟なネットワーク設計

同期

非同期

7

Availability Group 同期レプリカ

セカンダリ プライマリ

アプリケーション

SQL Server SQL Server

Log Data Log Data

1. コミット 要求

6. コミット 成功

2. ログ書込

3. ログ送信

5. ログ書込確認 4. ログ書込 2<. データ書込 4<. データ書込

Windows Server Failover Clustering

8

AlwaysOn可用性グループとデータベースミラーリング

可用性グループ ミラーリング 対象データベース 複数DB 単一DB セカンダリ 複数 (最大4) 単一 リーダブルセカンダリ 可能 不可能 自動フェイルオーバー 可能 可能 (Witness必要) 接続 リスナー クライアントコンポーネ

ント クラスター WSFC 独自

9

テストシステム構成 Windows Server Failover Cluster (Node and File Share Majority)

AG プライマリ セカンダリ

プリンシパル ミラー

DL380 G7 64GB Windows Server 2008 R2 SP1 H: Data File Fusion-io 640GB MLC E: TLOG RAID10 (8)

DL380 G7 64GB Windows Server 2008 R2 SP1 H: Data File Fusion-io 640GB MLC E: TLOG RAID10 (8)

10

データベースとワークロード

データベース サイズ:80GB 中 30GB使用中 データファイル:12個

Fusion-io 640GB MLC トランザクションログファイル:1個

RAID10 (8) ワークロード

OLTP型 ショートトランザクション 更新と参照の混合 同時接続1000クライアント

11

セカンダリでのページフラッシュの最適化

*TF 3499で書込をチェックポイントのみに抑制できるが、トレードオフとしてフェイルオーバー時間増大の可能性がある **フェイルオーバー時にはリストア中からオンラインへの切り替えが必要で、その際にはダーティーページが無いことが求められる

可用性グループ ミラーリング ページフラッシュ チェックポイント 連続(*) セカンダリのモード オンライン リストア中(**)

12

Disk Write Bytes/sec on secondary Disk Write Bytes/sec on primary

Availability Groups Database Mirroring

1 2 3 4 5 6 7 8 9 (min)

1000

500

(MB/s)

0 0

パフォーマンスカウンタ

プレゼンター
プレゼンテーションのノート
AG チェックポイントでの書きこみが定期的に発生 プライマリでもセカンダリでも同じ 500MB/sが短時間 平均63MB/s DBM プライマリ チェックポイントでの書きこみが定期的に発生 セカンダリ 定常的に書きこみが発生 平均200MB/s

13

IOの特徴

AG チェックポイントでの書きこみが定期的に発生

プライマリでもセカンダリでも同じ 500MB/sが短時間 平均63MB/s

DBM プライマリ

チェックポイントでの書きこみが定期的に発生 セカンダリ

定常的に書きこみが発生 平均200MB/s

AlwaysOn可用性グループの方がセカンダリの負荷が低い アクティブセカンダリとしてのキャパシティが高い

14

ログプールの追加による パフォーマンス向上

*ログプールはトランザクションログを読む必要のあるタスクのための、可変容量のキャッシュメカニズム **ログキャッシュは以前からある固定サイズのキャッシュメカニズム

可用性グループ ミラーリング ログプール*の利用 あり なし ログキャッシュ** あり(固定) あり(固定)

15

Primary

DB1 Log DB1 Data

SQL Server

Log Capture Log Capture Log Receive

Log Cache

Log Pool

Transaction Log Records

Secondary

DB1 Log DB1 Data

SQL Server

REDO Thread

REDO Pages Log Cache

可用性グループのログキャッシュ

16

Batch Requests/sec on primary Log write waits on primary

Availability Groups Database Mirroring

Disk Read Bytes/sec on primary

100

50

0 1 2 3 4 5 6 7 8 9 (min) 0

パフォーマンスカウンタ

17

パフォーマンス比較

AG Batch Requests/sec on primary 約5,000 batch/sec Log write waits on primary ほぼなし Disk Read Bytes/sec on primary 0-30MB/sec

DBM Batch Requests/sec on primary 約4,000 batch/sec Log write waits on primary 定常的に発生 Disk Read Bytes/sec on primary 50-100MB/sec

AlwaysOn可用性グループの方が高パフォーマンス

トランザクションログファイルへのRead IO負荷が低い

18

& &