SQL Server ベースの SAP システム における高可用性ソリューション

Presentation on theme: "SQL Server ベースの SAP システム における高可用性ソリューション"— Presentation transcript:

1 SQL Server ベースの SAP システム における高可用性ソリューション
マイクロソフト株式会社 SAP/Microsoft コンピテンスセンター

2 ソリューション選択の前に… 本当にどこまで必要なのか？ 運用体制、運用ポリシーの整備
ハードエラー、ソフトエラー、オペミスなど何を想定した可用性なのか？ ３６５日×24時間なのか？ 計画停止は可能なのか？ 復旧作業に許される時間は？ 運用体制、運用ポリシーの整備 障害発生の基準は？　どのように監視するか？ 障害時、復旧時の対応フローを検討しているか？ 運用コストについての検討は？

3 データベースの冗長構成 ログシッピング（ログ配布） クラスタ

4 ログシッピング（正常時） 本番 SQL Server SAP アプリケーション サーバ クライアント スタンバイ SQL Server

5 ログシッピング（障害発生）　 本番 SQL Server アプリケーションサーバ クライアント Down スタンバイ SQL Server

6 ログシッピング（切り替え後） 本番 SQL Server アプリケーションサーバ クライアント スタンバイ SQL Server

7 ログシッピングメカニズム Ｉｎｉｔｉａｌデータベース X分毎のＴログ SQL Server2000の標準機能として提供
疎結合　スタンバイサーバとしての位置付け 障害時の対応は手動で行う 定期的にＴログをリストア

8 ログシッピングのメリット スタンバイ機にトランザクションログをリストアすることで本番機とほぼ同じ状態のサーバーを維持できる
疎結合の為、遠隔地にも設置可能 別システムとして存在する為、あらゆるソフト/ハード障害に対応可能 論理的なデータ不整合にも手動にて対応可能 DBCC操作をスタンバイ側で処理することが可能 データ検索などReadの処理はスタンバイ側で可能

9 ログシッピング デモ ウィザードによる設定 サーバ切り替え ログをリストア 本番 SQL Server スタンバイ SQL Server

10 ログシッピング システムの構築 ユーザの要求、ユーザの環境に応じて柔軟な システム構築が可能
ユーザの要求、ユーザの環境に応じて柔軟な　　システム構築が可能 待機DBの有効利用 必ずしも同一スペックのH/Wが必要ではない R/3とは直接関係しない（SQL Server の範疇） 本稼動後に設定、解除なども可能 障害発生時の切り替えは手動を推奨

11 ログシッピング 本番 SQL Server スタンバイ SQL Server 実際のユーザに切り替えに関する 処理をさせない場合、
ログシッピング　 クライアント 本番 SQL Server SAP アプリケーション サーバ 実際のユーザに切り替えに関する　　　処理をさせない場合、 DBサーバを切り替えるか、アプリケーションサーバのプロファイルを切り替えるかいずれかの処理を行う。 スタンバイ SQL Server スタンバイサーバは、DBCCチェックやデータ検索に利用できる

12 ログシッピング 本番 SQL Server スタンバイ SQL Server ユーザが障害時に切り替えが可能
ログシッピング　 クライアント 本番 SQL Server SAP アプリケーション サーバ スタンバイ SQL Server ユーザが障害時に切り替えが可能　　　 スタンバイサーバを読み取り専用サーバとして活用が可能（　　　　　　　） 障害発生時には、すべてのユーザが（　　　　　　）ラインに切り替える スタンバイサーバ・リソースの有効利用

13 ログシッピング 同一SIDでR/3環境を構築し、スタンバイサーバでは、R/3サービスを停止させSQL ServerのみActiveにする
ログシッピング　 クライアント 本番 SAP サーバ + SQL Server スタンバイSAP サーバ + SQL Server 同一SIDでR/3環境を構築し、スタンバイサーバでは、R/3サービスを停止させSQL ServerのみActiveにする

14 ログシッピング 復旧 本番 SQL Server （スタンバイ） スタンバイ SQL Server （本番）
ログシッピング　復旧 本番 SQL Server （スタンバイ） クライアント SAP アプリケーション サーバ スタンバイ SQL Server （本番） 本番機とスタンバイ機は入れ替えが可能 障害復旧時に役割交代を行う ただし、この場合同一スペックのサーバが必要になる

15 ログシッピングの事例 マイクロソフト A社 B社 バックアップ周期 DB:1回/日 ログ:1回/10分 DB size 約５００GB

16 クラスタ ソリューション システム構成 Windows 2000 Advanced Server以上のＯＳが もつ標準の機能 ディスク共有型
クラスタ　ソリューション システム構成 Windows 2000 Advanced Server以上のＯＳが　もつ標準の機能 ディスク共有型　 自動フェイルオーバー H/Wは、限定される（HCL）且つ特殊デバイスを利用

17 Active/Active構成による有効利用
　　DBとCIをクラスタの両サーバ上配置する DB CI CI DB DB CI CI DB DB CI CI DB 障害発生 フェイルオーバー フェイルバック R/3上での推奨構成 障害発生から、フェイルオーバー完了までにかかる時間は、　　　　　　　　　　　　障害検知設定、フェイルオーバーさせるサービスに依存する

18 クラスタ構成例 Active/Active構成
DBサーバ＝MSCS（クラスタ）構成 DBサーバ間N/W（ハートビート） SQL　Server ＣＩ(Central　Ｉｎｓｔａｎｃｅ） ■ ■ APサーバ（2台構成） ■ ■

19 クラスタリング ローリングアップグレード ディスク共有型のソリューションである点に注意
意図的にフェイルオーバー環境を作成し、Activeでないサーバに対してアップグレード、サービスパックを適用する（但し、Windows2000以上） ディスク共有型のソリューションである点に注意 フェイルオーバー時に必要なファイル、データ等は　　共有ディスクに格納する データバックアップについての運用を必ず検討する

20 クラスタとログシッピングの比較 メリット デメリット クラスタ 自動的にフェイルオーバー Active/Active構成
ローリングアップグレード 共有ディスクがSingle　Point　of Failure 同一場所に設置 ログシッピング 疎結合 インストール、構成が単純 災害時にも対応 手動切り替え H/Wが2セット必要

21