SQL Server ベースの SAP システム

SQL Server ベースの SAP システム
における高可用性ソリューション
マイクロソフト株式会社
SAP/Microsoft コンピテンスセンター
ソリューション選択の前に…


本当にどこまで必要なのか？

ハードエラー、ソフトエラー、オペミスなど何を想定し
た可用性なのか？

３６５日×24時間なのか？

計画停止は可能なのか？

復旧作業に許される時間は？
運用体制、運用ポリシーの整備

障害発生の基準は？どのように監視するか？

障害時、復旧時の対応フローを検討しているか？

運用コストについての検討は？
データベースの冗長構成


ログシッピング（ログ配布）
クラスタ
ログシッピング（正常時）
クライアント
SAP アプリケーション
サーバ
本番
SQL Server
スタンバイ
SQL
Server
ログシッピング（障害発生）
クライアント
本番
SQL Server
アプリケーションサーバ
Down
スタンバイ
SQL
Server
ログシッピング（切り替え後）
クライアント
アプリケーションサーバ
本番
SQL Server
スタンバイ
SQL
Server
ログシッピングメカニズム
本番 SQL Server
Ｉｎｉｔｉａｌデータベース
スタンバイ SQL Server
X分毎のＴログ
ログ
ログ
SQL
Server2000の標準機能として提供
疎結合
スタンバイサーバとしての位置付け
障害時の対応は手動で行う
定期的にＴログをリストア
ログシッピングのメリット






スタンバイ機にトランザクションログをリストアするこ
とで本番機とほぼ同じ状態のサーバーを維持できる
疎結合の為、遠隔地にも設置可能
別システムとして存在する為、あらゆるソフト/ハー
ド障害に対応可能
論理的なデータ不整合にも手動にて対応可能
DBCC操作をスタンバイ側で処理することが可能
データ検索などReadの処理はスタンバイ側で可能
ログシッピング
デモ
ウィザードによる設定
サーバ切り替え
ログ
ログ
本番
SQL Server
スタンバイ
SQL Server
ログをリストア
ログシッピング
システムの構築


ユーザの要求、ユーザの環境に応じて柔軟な
システム構築が可能

待機DBの有効利用

必ずしも同一スペックのH/Wが必要ではない
R/3とは直接関係しない（SQL Server の範疇）


本稼動後に設定、解除なども可能
障害発生時の切り替えは手動を推奨
ログシッピング
クライアント
本番
SQL Server
SAP アプリケーション
サーバ
実際のユーザに切り替えに関する
処理をさせない場合、
DBサーバを切り替えるか、アプリケ
ーションサーバのプロファイルを切り
替えるかいずれかの処理を行う。
スタンバイ
SQL
Server
スタンバイサーバは、DBCCチェック
やデータ検索に利用できる
ログシッピング
クライアント
本番
SQL Server
SAP アプリケーション
サーバ
ユーザが障害時に切り替えが可能
スタンバイサーバを読み取り専用サ
ーバとして活用が可能（
）
スタンバイ
SQL
Server
障害発生時には、すべてのユーザが
（
）ラインに切り替える
スタンバイサーバ・リソースの有効利用
ログシッピング
クライアント
同一SIDでR/3環境を構築し、スタンバイ
サーバでは、R/3サービスを停止させ
SQL ServerのみActiveにする
本番 SAP
サーバ
+ SQL
Server
スタンバイ
SAP
サーバ
+ SQL
Server
ログシッピング復旧
クライアント
本番
SQL
Server
（スタンバイ）
SAP アプリケーション
サーバ
本番機とスタンバイ機は入れ替えが可能
障害復旧時に役割交代を行う
ただし、この場合同一スペックのサーバが
必要になる
スタンバイ
SQL
Server
（本番）
ログシッピングの事例



マイクロソフト
DB:1回/日ログ:1回/10分

バックアップ周期

DB size 約５００GB
A社
DB:1回/日ログ:1回/10分

バックアップ周期

DB size 約６００GB
B社
DB:1回/日ログ:1回/15分

バックアップ周期

DB size 約２５０GB
クラスタソリューション

システム構成

Windows 2000 Advanced Server以上のＯＳが
もつ標準の機能

ディスク共有型

自動フェイルオーバー

H/Wは、限定される（HCL）且つ特殊デバイスを利用
Active/Active構成による有効利用
DBとCIをクラスタの両サーバ上配置する
DB CI
CI DB
DB CI
障害発生
R/3上での推奨構成
CI DB
フェイルオ
ーバー
DB CI
CI DB
フェイルバ
ック
障害発生から、フェイルオーバー完了までにかかる時間は、
障害検知設定、フェイルオーバーさせるサービスに依存する
クラスタ構成例
Active/Active構成
DBサーバ＝MSCS
（クラスタ）構成
DBサーバ間N/W（ハートビート）
SQL Server
ＣＩ(Central Ｉｎｓｔａｎｃｅ）
データ
■
■
APサーバ（2台構
成）
■
■
クラスタリング

ローリングアップグレード


意図的にフェイルオーバー環境を作成し、Activeでな
いサーバに対してアップグレード、サービスパックを適
用する（但し、Windows2000以上）
ディスク共有型のソリューションである点に注意

フェイルオーバー時に必要なファイル、データ等は
共有ディスクに格納する

データバックアップについての運用を必ず検討する
クラスタとログシッピングの比較
メリット
デメリット
クラスタ
自動的にフェイルオーバー共有ディスクが
Single Point of
Active/Active構成
Failure
ローリングアップグレード
同一場所に設置
ログシッピング疎結合
手動切り替え
インストール、構成が単純 H/Wが2セット必要
災害時にも対応

Download Report