Transcript 高可用性実現テクノロジー

GOAL

本セッションではマイクロソフトプラットフォー
ムにおける高可用性を実現する為の設計の
ポイントを網羅的にご紹介します。
 高可用性を実現する為の




キーテクノロジー
設計のポイント
運用のポイント
セキュリティ対策設計（構成設計・パッチ管理運用）
Five9とは？
99.999
99.99
99.9
99
年間約5分のダウンタイム
年間約50分のダウンタイム
年間約9時間のダウンタイム
年間約3日半のダウンタイム
サーバ障害
ディスク障害
SAP
DB
どこまでの「９」を求めるのか？



コストとのトレードオフ
SLA
 求められるサービスレベルは？
0.01、0.001のために
 一般的運用管理項目の実施









運用方法論：ITIL、MOF
イベントログ監視
稼動監視
性能管理（リアルタイム、傾向監視）
ジョブスケジューリング
セキュリティ監視（Virus、アタック、、）
本セッション内容の実施
レビュー、レビュー、レビュー
テスト、テスト、テスト
AGENDA
1.
2.
3.
4.
5.
6.
高可用性実現テクノロジー
設計・実装のポイント
バックアップ・リストアのポイント
DBメンテナンス・監視のポイント
パフォーマンス維持のポイント
セキュア化のポイント
AGENDA
1.
2.
3.
4.
5.
6.
高可用性実現テクノロジー
設計・実装のポイント
バックアップ・リストアのポイント
DBメンテナンス・監視のポイント
パフォーマンス維持のポイント
セキュア化のポイント
１．高可用性実現テクノロジー

システム構成設計時に検討すべきテクノロ
ジーを説明いたします。
高可用性実現テクノロジー
DBサーバでの高可用性
 SQLServerでのHigh Availability構成
 MSCS（フェールオーバー・クラスター
 Log

）
Shipping（ログ配布）
バックアップ
<ログ シッピング>
<クラスタリング>
DB
DB
ログ
業務に接続
マシン障害発生
ログ
本番DB
待機DB
ログをリストア
高可用性実現テクノロジー
APサーバでの高可用性
 フェールオーバー・クラスター（MSCS） CI
 R/3ベーシス機能
ログオングループ
<クラスタリング>
CI
CI
シンクライアント
業務に接続
マシン障害発生
高可用性実現テクノロジー
その他
 サーバ

ロードバランサー




H/W（各ベンダー製品）
S/W（MS NLB）
FT（フォールトトレラント）機
ストレージ


例：EBPカタログサーバ
RAID
SAN
高可用性実現テクノロジー
その他
 ネットワーク


TeamingNIC
ネットワーク機器の冗長化
高可用性実現テクノロジー
その他
 ローカルDISK障害リカバリ

リカバリ手段の検討１

OSからの再セットアップ（スリップストリームの考慮）



Ntbackupによるリストア（ASRの考慮）



バックアップ：不要、但し変更管理、構成管理が必須
リストア：数時間、導入ソフト数に依存
バックアップ：数時間のサーバ停止が必要
リストア：数時間
3rdベンダー・ディザスタリカバリ製品


バックアップ：数時間のサーバ停止が必要
リストア：数時間
高可用性実現テクノロジー
その他
 ローカルDISK障害リカバリ
 リカバリ手段の検討２

DISKイメージソフト（オンライン、オフライン）

３ｒｄベンダー製オフラインバックアップ製品


バックアップ：MAX30分程度のサーバ停止、DISK使用容量に依存
リストア： MAX30分程度、DISK使用容量に依存
※手順は、非常にシンプル。但し、TIPSも必要

３ｒｄベンダー製オンラインバックアップ製品


バックアップ：MAX数分程度のサービス停止、起動サービスに依存
リストア： MAX30分程度、DISK使用容量に依存
※手順は、非常にシンプル。但し、事例は多くない

SANブート
高可用性実現テクノロジー
DBサーバでの高可用性
 SQLServerでのHigh Availability構成
 MSCS（フェールオーバー・クラスター
 Log

Shipping（ログ配布）
バックアップ
<クラスタリング>
DB
業務に接続
DB
マシン障害発生
）
MSCS構成（２ノードクラスタ例）

クラスタ化された１つのSQL Server（通常時）
共有DISK
\\SQLA
ネットワーク名:SQLA
IP Address:192.168.10.3
SQL ServerサービスA
SQLA DB
ﾛｰｶﾙDISK
ﾛｰｶﾙDISK
OS
SQLA Sys
コンピュータ名:NTSB
IP Address:
192.168.10.2
内部通信
パブリック用
クライアント PC
OS
SQLA Sys
コンピュータ名:NTSA
IP Address:
192.168.10.1
ＳＱＬAを仮想サーバー
としてクライアントから参照
MSCS構成（２ノードクラスタ例）

NTSBでSQL Serverが起動される（障害時）
\\SQLA
ネットワーク名:SQLA
IP Address:192.168.10.3
SQL ServerサービスA
共有DISK
SQLA DB
ﾛｰｶﾙDISK
ﾛｰｶﾙDISK
OS
SQLA Sys
コンピュータ名:NTSB
IP Address:
192.168.10.2
内部通信
パブリック用
クライアント PC
OS
SQLA Sys
コンピュータ名:NTSA
IP Address:
192.168.10.1
ＳＱＬAを仮想サーバー
としてクライアントから参照
高可用性実現テクノロジー
DBサーバでの高可用性
 SQLServerでのHigh Availability構成
 フェールオーバー・クラスター（MSCS）
 Log

Shipping（ログ配布）
バックアップ
<ログ シッピング>
ログ
ログ
本番DB
待機DB
ログをリストア
Log Shipping構成（正常時）
クライアント
アプリケーション ＤＢプライマリ
サーバ
サーバ
SAP
ＤＢセカンダリ
サーバ
Log-shipping
SAP
Log Shipping構成（障害発生）
クライアント
アプリケーション
サーバ
SAP
SAP
ＤＢプライマリ
サーバ
ＤＢセカンダリ
サーバ
Log Shipping構成（切替後）
クライアント
アプリケーション ＤＢプライマリ
サーバ
サーバ
SAP
SAP
ＤＢセカンダリ
サーバ
MSCSとLog Shippingの比較（1）
MSCS
プライマリSQLサーバ
セカンダリSQLサーバー
LogShipping
プライマリSQLサーバ
Transaction
Log
セカンダリSQLサーバー
Transaction
Log
データベース
（共有ディスク）
データベース
データベース
MSCSとLog Shippingの比較（2）
メリット
MSCS
自動的にフェールオーバー（数
Log
Shipping
Single
十秒から数分）
フェールオーバー時間が短い
Point of Failureがない
インストール、構成がシンプル
対災害（DR）対策として採用可
能
デメリット
共有ディスクがSingle
Point of
Failure（信頼性の高いSAN DISK
の考慮すると、、）
共有ディスク障害からの復旧に時
間がかかる
手動の切替（30分から１時間）
データロストの可能性あり
2005年中旬出荷予定のSQL Server 2005では、データベースミラーリング機能に
よりデータロストの可能性のない、短時間（3秒程度）のフェールオーバーを実現します。
高可用性実現テクノロジー
DBサーバでの高可用性
 SQLServerでのHigh Availability構成
 MSCS（フェールオーバー・クラスター
 Log

Shipping（ログ配布）
バックアップ
）
バックアップ
バックアップデバイス
 高速バックアップ
 オフサイトバックアップ（災害対策）

 オフライン・オフサイト
 オンライン・オフサイト
バックアップデバイス
デバイスの選択によっても、可用性は変わる。
※バックアップ時間、リストア時間等に影響
ディスク（DAS 、 NAS 、 SAN）
 テープ（DLT、LTO、AIT 、DAT、、、）

高速バックアップ
SQLServer標準の複数デバイスへのバック
アップ
 H/W（SAN製品）とSQLServer機能を組み合
わせたスナップショットバックアップ

複数バックアップデバイス

バックアップ操作や復元操作では複数のバック
アップ デバイスを使用可能

スピードアップが可能
TAPE
DB
Backup
TAPE
TAPE
※DLT装置32台使用による、650G/時間の検証結
果あり。
スナップショット バックアップ/リストア


数秒でバックアップが完了
フルバックアップの一つの方法


差分やログを使用してロールフォワード可能
ストレージシステムがサポートする、サードパーティ製の
VDI*アプリケーションが必要

Split mirror
Tape
Library
3-way Mirror
Split
Mirror
Backup / Passive
Production
Storage
* Virtual Device Interface for Backup
オフサイト保管/環境構築
オフライン・オフサイト
 遠隔地にバックアップメディアの保管
本番サイト
TAPE
TAPE
TAPE
バックアップサイト
オフサイト保管/環境構築
オンライン・オフサイト
 遠隔地logshipping構成
 遠隔地MSCS
遠隔地logshipping構成


MS R/3
Dream4Cプロジェクト


横浜>神戸間の遠隔地検証(約６００ｋｍ)
約30分でのフェールオーバー可能であることが
確認された。
本番サイト
バックアップサイト
遠隔地MSCS

ストレージベンダー提供のソリューション
本番サイト
バックアップサイト
内部通信
遠隔地 MSCS
AGENDA
1.
2.
3.
4.
5.
6.
高可用性実現テクノロジー
設計・実装のポイント
バックアップ・リストアのポイント
DBメンテナンス・監視のポイント
パフォーマンス維持のポイント
セキュア化のポイント
２．設計・実装ポイント
設計・実装時の忘れがちな実装ポイントを中心に
説明いたします。




インストール準備
Windows、SQL Serverの設定
DBサーバのDISK配置設計
拡張性を考慮したDBファイル設計
２．設計・実装のポイント




インストール準備
Windows 2000、SQL Server 2000の設定
DBサーバのDISK配置設計
拡張性を考慮したDBファイル設計
インストール準備

サイジング
 Quick
Sizer
 コンピテンスセンター
 負荷テスト、パフォーマンステスト
SAP R/3 インストールマニュアル
 最新SAPノートの確認
 Microsoft Knowledge Base（サポート
技術情報）の確認

２．設計・実装のポイント




インストール準備
Windows、SQL Serverの設定
DBサーバのDISK配置設計
拡張性を考慮したDBファイル設計
Windows、SQLServerの設定
R/3 インストールマニュアル
 WhitePaper
 SAP



Conversion to Microsoft Cluster Server ：MS
SQL Server
Installation of MS SQL Server 2000 in an SAP
Environment
。。。。。
 SAPノート

0209596,0327494,0353654,0030478。。。
２．設計・実装のポイント
インストール準備
 Windows、SQL Serverの設定
 DBサーバのDISK配置設計
 拡張性を考慮したDBファイル設計

DISK配置設計

I/O負荷分散の設計
最終的には、DBのI/Oネックとなる。設計により
極力予防することが可能である。
以下のDBファイルへのアクセス頻度が非常に高い。
これらを分散することがポイント。
 ユーザDBデータ
 ユーザDBトランザクションログ
 Tempdb
DISK配置設計のポイント

I/O負荷分散の設計



データファイルとトランザクションログファイルは別DISKに配
置する。
Tempdbはデータファイル、トランザクションログファイルと別
DISKに配置する。
データファイルは複数DISKに分散配置する。
DISK配置設計例
111.mdf
111.mdf
222.ndf 111.mdf
222.ndf
333.ndf 222.ndf
333.ndf
444.ndf 333.ndf
444.ndf
444.ndf
master
A111.ldf
tempdb
msdb
２．設計・実装のポイント
インストール準備
 Windows、SQL Serverの設定
 DBサーバのDISK配置設計
 拡張性を考慮したDBファイル設計

拡張性の考慮

DB容量の拡張性を考慮した設計
設計時に考慮しておくと事が重要。拡張が必要に
なってからでは、対応は困難である。

データ量の増加に伴い、 DISKの追加が予想さ
れる場合は、一つのDISKに複数のデータファイ
ルを格納する

DISKの追加時に、データファイルを移動
データの比例配分（前提知識）

ファイル グループ内のすべてのファイルに各ファイル内の空
き領域に比例してデータが格納される
ファイルグループ
5GB
10GB
9GBの
データ
を追加
ファイルグループ
3GB
6GB
5GB
10GB
拡張性を考慮していない場合
増設前
User_DB
Log
Disk 0
拡張性を考慮していない場合
増設後
User_DB
増設したDisk1
に新規作成した
データファイルに
アクセスが集中する
空
Log
Disk 0
Disk 1
増設
拡張性を見込んだファイル配置
あらかじめ
拡張分を見越して
データファイルを
作成
増設前
初期状態
User_DB
Log
Disk 0
拡張性を見込んだファイル配置
増設したDisk1へ
ファイルを１つ移動し
それぞれのファイルを
拡張する。
Diskは、均等に使用される。
増設後
User_DB
空
Disk 0
空
Disk 1
増設
Log
AGENDA
1.
2.
3.
4.
5.
6.
高可用性実現テクノロジー
設計・実装のポイント
バックアップ・リストアのポイント
DBメンテナンス・監視のポイント
パフォーマンス維持のポイント
セキュア化のポイント
３．バックアップ・リストアのポイントリ
バックアップ・リストアの重要考慮点を
説明いたします。


バックアップ種類
バックアップ運用の検討
TAPE
DB
TAPE
TAPE
バックアップの種類
フルバックアップ
 差分バックアップ
 トランザクションログバックアップ
 ファイル/ファイルグループバックアップ

TAPE

スナップショットバックアップ

フルバックアップの一つの方法
DB
TAPE
TAPE
バックアップ運用の検討
バックアップ・リストアに対する要件
 許容されるデータのロスト


データの再作成に必要な時間、コスト
許容されるダウンタイム

復旧の時間




バックアップの種類（DB、ログ、差分、ファイル）
バックアップデバイス（DISK、DLT、DAT）
DBのサイズ
DB
TAPE
TAPE
運用スケジュール
TAPE
AGENDA
1.
2.
3.
4.
5.
6.
高可用性実現テクノロジー
設計・実装のポイント
バックアップ・リストアのポイント
DBメンテナンス・監視のポイント
パフォーマンス維持のポイント
セキュア化のポイント
4.DBメンテナンス・監視のポイント
非常に重要ではあるが、忘れがちなDB関連の
運用項目に関するポイントを説明します。


DBメンテナンス
DB使用率監視
DBメンテナンスの種類

整合性チェック



インデックス再構築




DBCC CHECKDB
DBCC CHECKCATALOG
DBCC INDEXDEFRG
DBCC DBREINDEX
DBCC SHOWCONTIG
統計情報の更新

UPDATE STATISTICS
DBメンテナンス一例



1回/日～週（フルバックアップの前に）
 DBCC CHECKDB
 DBCC CHECKCATALOG
１回/週～月（データの増加率、APの特性による）
 UPDATE STATISTICS
１回/3ヶ月～6ヶ月（データの増加率、APの特性による）
 DBCC DBREINDEX or DBCC INDEXDEFLAG
DB使用率監視
？なぜ監視が必要なのか？




DBファイルサイズの自動拡張を極力抑えるために
データファイル、トランザクションログファイルのサイ
ズは十分に大きくアローケーションする必要があり
ます。
実際のDISK使用率の傾向を把握するためには
データ、トランザクションログファイルの使用率の監
視が必要になります。
データ使用率の監視
 DBCC Showfilestats コマンド等
トランザクションログ使用率の監視
 DBCC Sqlperf コマンド等
AGENDA
1.
2.
3.
4.
5.
6.
高可用性実現テクノロジー
設計・実装のポイント
バックアップ・リストアのポイント
DBメンテナンス・監視のポイント
パフォーマンス維持のポイント
セキュア化のポイント
5．パフォーマンス維持のポイント
インフラ観点
 SAPノートにそった設定



NOTE番号：0327494
GLCの指示にそった設定
実環境でのパフォーマンステスト、負荷テスト
アプリケーション観点
 一般的な内容



OPENSQLの標準化
十分なソースレビュー
十分なテスト

SQLServerに特化した注意事項

処理特性の違うアプリケーションで同じABAPプログラム
使用には注意
NOTE番号：129385、159171、133381、 028667、
155413
例：



バッチとオンライン
引渡しパラメータ範囲が極端に違うケース（親会社、子会社）
複数クライアントでの運用
SQLServerでの高速化技術（ストアドプロシージャでのOPENSQL実装）が
仇となり、処理時間にぶれの出るケースがある。
標準化により、回避可能
パフォーマンス劣化  IO,CPUネックに見えるケースもあり

対策（ケースに応じて対策を検討）

リコンパイルヒントの使用（推奨）
%_hints mssqlnt ‘’. 但し、R/3 4.6A 以降
一定時間以上（１分以上など）の処理時間が想定される処理には、リコンパイ
ルヒントを追加を必須とする。リコンパイルのオーバーヘッドは、1秒以下であ
るため問題とはならない。


ケースに応じたIndex hintの使用

%_hints mssqlnt 'TABLE XXXX abindex(2)'.

コストベースの優位性の排除になる。
関連TABLEの統計情報の更新



SPの仕様として、統計情報更新後は必ずリコンパイルされる。
R/3 カーネルによる自動再コンパイル

プロファイルパラメータ rsdb/mssql/max_duration

全てのSPが再コンパイルされる。
Sp_recompileの使用

対象TABLEに対してロックを獲得するため、ブロッキングのリスクがある。
AGENDA
1.
2.
3.
4.
5.
6.
高可用性実現テクノロジー
設計・実装のポイント
バックアップ・リストアのポイント
DBメンテナンス・監視のポイント
パフォーマンス維持のポイント
セキュア化のポイント
６．セキュア化のポイント


外部からの攻撃（VIRUS等）に対するセキュリティ対策（設
計・運用）に関する概要を説明いたします。
 ハードニング
 パッチマネージメント（特にリスク評価）
この実装により、以下が実現可能です。
 セキュリティの強化
 高可用性の確保
 低い運用コスト
セキュアな設計・設定（ハードニング）
セキュアなNETWORK設計

FIREWALL、ROUTERにネットワークの分断
 サブネット設計
 パケットフィルタリング設計
WWW
電話回線など
FTP
Web
RAS
Router
RAS セグメント
DMZ セグメント
WWW
（社外用）
WWW
（社外用）
Fire
wall等
DNS
Mail
VPN
社内サーバーセグメント
Proxy
社内セグメント
File
WWW
WWW
（ITS
用)
（EP
WWW
WWW 用)
（ITS 用)
（EP 用)
Dire
ctory
DNS
Mail
ITS
EP
適切なサブネット設計
SAP
サーバー
セグメント
SAP
DB
・・・
パケットフィルタリング設計

SAP システムに不要な通信をブロックする為のパ
ケットフィルタリングを実施します。
 方法１：ファイアウォール、ルータ、レイヤ３スイッ
チ、SAP Router などの配備（各サブネット単
位）
 方法２：IPSec ポリシースクリプトの適用（各ホス
ト単位）
 方法３：サブネット単位、ホスト単位双方を組み
合わせにより、よりセキュアな環境に
セキュアな設計・設定（ハードニング）
セキュアなベースライン設計・設定



OSレベルのベースライン設定
RDBMSレベルのベースライン設定
WEBサーバレベルのベースライン設定
ベースライン設定（セキュリティテンプレート）

Windows Server 2003 セキュリティガイドと
添付のテンプレートを利用して効率よくハードニング

http://www.microsoft.com/downloads/details.aspx?FamilyId
=8A2643C1-0685-4D89-B655521EA6C7B4DB&displaylang=en#filelist
セキュリティー運用（パッチマネージメント）

パッチ適用運用（パッチマネージメント）

脆弱性に対するリスク評価



脆弱性情報の収集
リスク評価、対策の検討
パッチ適用運用

定期パッチ適用運用（6ヶ月～一年に一度程度）





1.適用フロー、プロセス明確化（検証環境 --> 本番環境）
2.承認ルートの明確化
3.適用時の検証手順・内容の明確化
4.展開手順の明確化・システム化
緊急時パッチ適用運用
セキュリティ維持のプロセス
実施項目
作業内容
情報収集
セキュリティ脆弱性情報収集
現状分析
自社での影響と緊急度の判定
パッチ展開
結果監視
展開の計画策定
ステージング環境によるテスト実施
本番適用とロールバック
全社のポリシー適用状況の監視
ポリシー違反のフードバックプロセス実施
情報収集＆現状分析


毎月第２水曜日（日本時間）に、「月間セキュリティ情報サイト」より脆弱性情報をチェック

http://www.microsoft.com/japan/technet/security/bulletin/monthly.asp
それぞれの脆弱性に対し、以下のポイントでリスクを評価します。

SAP システムのサーバー群に関与するか？

一般的な「最大深刻度」のレベルは？


ハーデニングは有効か？


ハードニングにより、リスクは低くなっている（リスクがない）可能性が高い。
お客様にとっての緊急度、深刻度は？


一般的は情報であり、お客様環境にとっての緊急度、深刻度とは一致しないことも多い。
お客様独自の適用判断基準に適合するのか？
「回避策」はあるか？
最大深刻度
定義
緊急 (Critical)
この脆弱性が悪用された場合、インターネット ワームがユーザーの操作なしで蔓延する可能性があります。
重要 (Important)
この脆弱性が悪用された場合、ユーザーのデータの機密性、完全性または可用性が侵害される可能性が
あります。または、処理中のリソースの完全性または可用性が侵害される可能性があります。
警告 (Moderate)
この脆弱性が悪用された場合、既定の構成、監査または悪用が困難であることなどの要素により、悪用さ
れる可能性は大幅に緩和されます。
注意 (Low)
この脆弱性の悪用は非常に困難です。または影響はわずかです。
リスク
高
低
現状分析（リスク評価＆適用判断）

それぞれの脆弱性に対して、アクションを決定

セキュリティ更新プログラムを適用しない

適用不要

SAP サーバーに関係ない、ハードニング等によりお客様に
とっての緊急度・深刻度が非常に低い、お客様基準の適用
対象外である

「回避策」、ハードニングを実装
※適用しない場合は、サービスパックで包括的に適用することを
※お勧めいたします。

セキュリティ更新プログラムを適用する

定期的（６ヶ月から一年間隔）スケジュール時に適用

ハードニング等によりお客様にとっての緊急度・深刻度が低
い、お客様基準の定期適用対象である

緊急適用

ハードニング等も有効でなく、お客様にとっての緊急度・深刻
度が高い、お客様基準の緊急適用対象である
リスク評価例（脆弱性評価マトリクス）


3.3.3.3 各企業別の緊急度判断
別紙
判断項目
影響を受けるのか？

影響を受けるOSがあるか？

影響を受ける機能、プロダクトがあるか？

匿名攻撃が可能か？（ポートが開いているだけで攻撃が可能）

特権取得可能か？（特権の昇格が可能）

有効な回避策がない

各企業におけるハードニングが有効でない？
※判断例 上記を全て満たす場合 緊急、それ以外は定期適用とする。

まとめ



本セションでは、外部からの攻撃（VIRUS等）に対するセキュ
リティ対策（設計・運用）に関してお話ししました。

ハーデニング

パッチマネージメント（特にリスク評価）
この実装により、以下が実現可能です。

セキュリティの強化

高可用性の確保

低い運用コスト
Microsoft はプラットフォームベンダーとして、Windows Server 他のセ
キュリティ強化、脆弱性解消に今後も努めていきます
再度：どこまでの「９」を求めるのか？



コストとのトレードオフ
SLA
 求められるサービスレベルは？
0.01、0.001のために
 一般的運用管理項目の実施









運用方法論：ITIL、MOF
イベントログ監視
稼動監視
性能管理（リアルタイム、傾向監視）
ジョブスケジューリング
セキュリティ監視（Virus、アタック、、）
本セッション内容の実施
レビュー、レビュー、レビュー
テスト、テスト、テスト
マイクロソフトが提供するサービス

コンサルティングサービス


http://www.microsoft.com/japan/consulting/def
ault.asp
サポートサービス

プロフェッショナル・サポート


http://support.microsoft.com/gp/prof_service
プレミア・サポート

http://support.microsoft.com/gp/premier
SAP関連コンサルティングメニュー
#
大分類
小分類
項目
詳細項目
想定成果物
1
高信頼性
高可用性
設計
DBサーバ冗長構成策
定
DBサーバ可用性要件定義支援
DBサーバ可用性要件定義案
DBサーバ冗長構成策定支援
DBサーバ冗長構成案
DBサーバ冗長構成設
計/構築
MSCS構成設計/構築支援
DBサーバ冗長構成設計案
DBサーバ冗長環境構築技術資
料
ディザスター対策設計
ディザスター対策設計支援
ディザスター対策設計案
想定障害ケース洗い
出し
想定障害ケース定義支援
想定障害ケース定義案
７
各想定ケースに対する
対策検討
障害復旧方式策定支援
障害復旧方式案
８
DBバックアップ/リスト
ア方式策定支
援
データ可用性要件定義支援
データ可用性要件定義案
DBバックアップ/リストア方式策定
支援
DBバックアップ/リストア方式案
DBバックアップ/リスト
ア設計支援
SQL Server標準バックアップ設
計支援
DBバックアップ/リストア設計案
運用ツール用サンプルスクリプト
2
3
4
５
６
障害リカ
バリ設計
９
10
11
12
13
ログ・シッピング構成設計/構築支
援
Snap Shotバックアップ設計支援
監視設計
監視項目策定
監視項目定義支援
監視項目定義案
監視方法制定
監視方式策定支援
監視方式案
SAP関連コンサルティングメニュー
#
大分類
小分類
項目
詳細項目
想定成果物
1
高パフォー
マンス
SQL
Server
SQL Server物理設計
ディスク配置設計支援
ディスク配置設計案
ファイル配置設計支援
ファイル配置設計案
整合性チェック実施方式策定支援
定常運用メンテナンス運用
設計案
2
３
メンテナンス運用設計
４
断片化対策実施方式策定支援
５
統計情報更新方式策定支援
チューニング
6
性能分析/チューニング支援
性能分析報告書、性能改善
対策案
パラメータ設計支援
パラメータ設計案
コーディング標準化
ABAP （Open SQL）
コーディング標準化・レビュー支援
ABAP （Open SQL）
コーディング標準化・レ
ビュー支援報告書
チューニング
パラメータ設計支援
サーバ性能設計案
7
8
9
10
Windows
Server
チューニング支援
SAP関連コンサルティングメニュー
#
大分類
小分類
1
セキュリティ
ポリシー
詳細項目
想定成果物
セキュリティポリシー策定支援
セキュリティポリシー案
ドメイン利用要件定義支援
ドメイン利用要件定義案
ドメイン構成策定支援
ドメイン構成案
ドメイン運用設計
ドメイン運用管理設計支援
ドメイン運用管理設計案
Windows Server
Windows Serverセキュリティ
ベースライン設定支援
Windows Serverセキュリティ
ベースライン設定内容案
６
SQL Server
SQL Serverセキュリティベース
ライン設定支援
SQL Serverセキュリティベー
スライン設定内容案
７
NETWORK
NETWORKセキュリティベース
ライン設定支援
NETWORKセキュリティベース
ライン設定内容案
2
Windowsドメイン
項目
ドメイン設計
3
4
5
セキュリティベース
ライン
８
パッチ管理
パッチ適用マネージメント方針
策定支援
パッチ適用マネージメント方
針案
９
プロジェクトのセキュリティ標準
開発プロジェクトセキュリティ標
準策定支援
開発プロジェクトセキュリティ
標準案
Go to MS/SAP Solution Site !!
http://www.microsoft.com/japan/business/sap/default.mspx
参考資料

MSCS 自習書
http://www.microsoft.com/japan/sql/techinfo/sqleval/Self_Doc.asp

LOGHISPPING 自習書
http://www.microsoft.com/japan/sql/techinfo/sqleval/Self_Doc.asp

SQL Server HOMEPAGE
http://www.microsoft.com/japan/sql/default.asp

NOTE番号：0327494
MOF
（Microsoft Operations Framework）
Microsoft Operations Framework
（MOF）


マイクロソフトプラットフォーム上でミッションクリ
ティカルシステムを実現するために、包括的な運
用ガイダンスを提供する
ゴール:




プロセス・人（組織）・技術に注目
IT運用にかかる時間や複雑性の軽減
マイクロソフト製品の運用に関する知識の拡充
アプローチ


業界のベストプラクティス（ITIL）に基づく
パートナー、カスタマーとの協調
MOF プロセスモデル
サービスレベル管理
キャパシティ管理
可用性管理
財務管理
サービス継続性管理
ワークフォース管理
リリース
承認レビュー
最適化
変更
リリース
レビュー
SLA
レビュー
サービスデスク
インシデント管理
問題管理
変更管理
構成管理
リリース管理
サポート
運用
運用
レビュー
システム管理
セキュリティ管理
ネットワーク管理
サービス監視/コントロール
ディレクトリサービス管理
ストレージ管理
ジョブスケジュール
印刷/出力管理
Windows Server 2003機能
システム復旧時間短縮の実現
Windows Server 2003機能
システム復旧時間短縮の実現
システム復旧時間の短縮
• ASR (Automatic System Recovery)
• VSS（ボリュームシャドーコピーサービス）
• SANブート
システム復旧時間比較

OSレベルの障害におけるシステム復旧
機能名称
高速
低速
追加S/W（サポートS/W)
概要
SANブート
ストレージベンダー提供のソフトが必要
OSバックアップを
SAN機能により
HDD上に複製す
る
ASR
OS標準機能（3rdベンダー製品でサポート
済)
復旧時にOS領域
を自動作成
基本
NTBackup
OS標準機能
従来通り
復旧時間
ASRによるシステムの復元

ASR (Automatic System Recovery)
システム復元FD
OSをバックアップ
•Veritas BackupExecV9
•NTBackup
バックアップメディア
従来のリストア手法との違い
・事前にディスクフォーマットは必要無し
・事前にOSセットアップは必要無し
 サーバ障害時には、
バックアップメディア
とシステム復元FDでリストア
SANブートとSANディスク複製機能に
よるシステム高速復元

”SANブート”（Windows 2003新機能）


Windows システムファイルをSANに配置
SANストレージ機能と連携し、高速復元が可能
OSシステム
ファイルを配置
FC
内蔵ディスク無し
主DISK
バックアップは
差分更新
バックアップDISK
サーバ障害時、主ディスク物理障害
／論理障害時はバックアップディスク
よりリストア
誤更新時にも数分で前の状態に復元
操作はSANストレージ機能で簡単操作
OSはシステム更新時にコールドバックアップ
SAN筐体