emc ストレージ使用 microsoft sql server · ホワイトペーパー. emc...

ホワイトペーパー

EMC ソリューション

要約

このホワイトペーパーでは、Microsoft SQL Server を EMC® VNX®ユニファイド

ストレージファミリ、EMC Symmetrix® VMAX®シリーズストレージ、EMC

XtremSF™/EMC XtremSW™ Cache 製品と組み合わせて使用する場合の計画

と展開に関するベストプラクティスと重要な意思決定ポイントについて説明し

ます。

2013 年 10 月

EMC ストレージ使用 Microsoft SQL Serverベストプラクティスおよび設計ガイドライン EMC VNX ファミリ、EMC Symmetrix VMAX システム、EMC Xtrem サーバー製品

• 設計とサイズ設定のベストプラクティス

• フラッシュテクノロジーによる SQL Server パフォーマンス向上

• 災害復旧と高可用性のベストプラクティス

2 EMC ストレージ使用 Microsoft SQL Server ベストプラクティスおよび設計ガイドライン EMC VNX シリーズ、EMC Symmetrix VMAX システム、EMC Xtrem サーバー製品

2

Copyright © 2013 EMC Corporation.All rights reserved.（不許複製・禁無断転載）

EMC は、この資料に記載される情報が、発行日時点で正確であるとみなしていま

す。この情報は予告なく変更されることがあります。

この資料に記載される情報は、「現状有姿」の条件で提供されています。EMC Corporation は、この資料に記載される情報に関する、どのような内容についても

表明保証条項を設けず、特に、商品性や特定の目的に対する適応性に対する黙

示の保証はいたしません。

この資料に記載されているいかなる EMC ソフトウェアの使用、複製、頒布にも、当

該ソフトウェアライセンスが必要です。

最新の EMC 製品名については、EMC の Web サイトで EMC Corporation の商標を

参照してください。

その他のすべての名称ならびに製品についての商標は、それぞれの所有者の商

標または登録商標です。

パーツ番号 H12341-J

3 Microsoft Exchange：

EMC ストレージ使用ストレージベストプラクティスおよび設計ガイドライン


目次

エグゼクティブサマリー ........................................................................................................................ 7

このホワイトペーパーの目的 .......................................................................................................... 7

対象読者 ......................................................................................................................................... 7

対象範囲 ......................................................................................................................................... 7

用語 ................................................................................................................................................. 8

Microsoft SQL Serverのコンポーネントとアーキテクチャ ...................................................................... 10

SQL Serverの概要 .......................................................................................................................... 10

SQL Serverの各リリース ............................................................................................................. 10

SQL Server 2012 ............................................................................................................................ 10

SQL Server 2012 のエディション ................................................................................................. 10

SQL Serverのコンポーネント ........................................................................................................... 11

Windows Server ............................................................................................................................. 11

Windowsボリュームのタイプ ...................................................................................................... 12

SMB 3.0 .................................................................................................................................... 13

SQL Serverのアーキテクチャ .......................................................................................................... 14

SQL Serverの論理コンポーネント .................................................................................................... 15

SQL Serverの物理的コンポーネント ................................................................................................ 16

ファイルタイプ ........................................................................................................................... 16

ページとエクステント .................................................................................................................. 16

トランザクションログ .................................................................................................................. 17

ファイルグループ ...................................................................................................................... 17

SQL ServerのI/Oおよび帯域幅特性 .................................................................................................... 18

概要 ............................................................................................................................................... 18

OLTP .............................................................................................................................................. 18

データウェアハウス/OLAPデータベース ......................................................................................... 19

ページ読み取り .............................................................................................................................. 20

ページ書き込み .............................................................................................................................. 20

ログマネージャー ........................................................................................................................... 21

Tempdbの使用 .............................................................................................................................. 21

I/Oのパターン ................................................................................................................................ 21

SQL Serverストレージのサイズ設定とプロビジョニングのベストプラクティス ........................................ 22

概要 ............................................................................................................................................... 22

SQL Serverストレージの一般的なベストプラクティス ....................................................................... 22

SQL Serverの基本的なベストプラクティス .................................................................................. 23

ストレージの基本的なベストプラクティス .................................................................................... 24

クラスタリングの考慮事項 .......................................................................................................... 25

以前のバージョンの考慮事項 .................................................................................................... 25

ストレージの一般的な考慮事項 ...................................................................................................... 25


4

パフォーマンスと容量の考慮事項 .............................................................................................. 25

ディスクタイプの選択 ................................................................................................................ 25

プールとRAIDタイプ .................................................................................................................... 27

ストレージの仮想プロビジョニングの考慮事項 ............................................................................... 29

シンLUNとシックLUNの違い ........................................................................................................ 29

ストレージのサイズ設定のベストプラクティス ................................................................................. 30

OLTPデータベースのサイズ設定の考慮事項 ................................................................................... 30

FAST VPのサイズ設定のベストプラクティス ................................................................................ 32

OLAPデータベースのサイズ設定の考慮事項 .................................................................................. 33

ハイパーバイザーストレージの考慮事項 ....................................................................................... 35

仮想化の一般的なガイドライン .................................................................................................. 35

VMware vSphere環境のベストプラクティス ................................................................................ 38

Microsoft Hyper-V ...................................................................................................................... 40

SQL Serverクラスタリングのストレージの考慮事項 ......................................................................... 41

Symmetrix VMAXストレージ設計ガイドライン ................................................................................... 41

VMAXシリーズハードウェア設計の考慮事項 ............................................................................. 42

仮想プロビジョニングの考慮事項とベストプラクティス ................................................................. 42

VMAXストレージシステムでのFAST VPの考慮事項とベストプラクティス ...................................... 42

VNXストレージ設計ガイドライン ....................................................................................................... 43

FAST Cacheの考慮事項とベストプラクティス .............................................................................. 43

FAST VPの考慮事項とベストプラクティス .................................................................................... 44

FAST CacheとFAST VPの違い ...................................................................................................... 45

サーバーフラッシュの考慮事項 ...................................................................................................... 46

XtremSFの概要 .......................................................................................................................... 46

XtremSFの設計のベストプラクティス .......................................................................................... 46

XtremSW Cacheの概要 .............................................................................................................. 46

XtremSW Cacheの設計のベストプラクティス .............................................................................. 47

仮想化環境におけるXtremSW Cacheの設計のベストプラクティス .............................................. 48

XtremSFとXtremSW Cacheのサイズ設定の考慮事項 .................................................................. 49

ESIによる自動化 ............................................................................................................................ 50

SQL Serverの保護 ............................................................................................................................... 51

概要 ............................................................................................................................................... 51

AlwaysOn可用性グループ .............................................................................................................. 51

SQL Serverのネイティブデータ保護 ................................................................................................ 52

リカバリ可能コピーと再開可能コピー ......................................................................................... 52

バックアップレプリケーションのVDIおよびVSSフレームワーク ..................................................... 53

SQL Server向けのEMC高可用性およびデータ保護製品 .................................................................. 53

レプリケーションテクノロジー ..................................................................................................... 55

レプリケーション管理ツール ....................................................................................................... 56

複数サイトの災害復旧 ................................................................................................................... 56

考慮事項 ................................................................................................................................... 56




複数サイトレプリケーションテクノロジー .................................................................................... 57

再開自動化ツール ..................................................................................................................... 58

仮想化インスタンス自動化ツール .............................................................................................. 59

SQL Server 2012 の災害復旧オプション ......................................................................................... 59

バックアップに関する追加の推奨事項 .......................................................................................... 59

HA/DRのためのAlwaysOn .............................................................................................................. 59

AlwaysOnとFAST Suite ............................................................................................................... 60

AlwaysOnとフラッシュXtremSW Cache/XtremSF ......................................................................... 60

まとめ ................................................................................................................................................. 61

サマリー ......................................................................................................................................... 61

関連情報 ....................................................................................................................................... 61

付録A： EMC Data Protection Advisor for Replication Analysis ............................................................ 62

概要 ............................................................................................................................................... 62

データコレクションウィザードと検出ウィザード ............................................................................... 62

データの検出と収集 ...................................................................................................................... 62

ストレージアレイの検出 ............................................................................................................ 62

Microsoft SQL Serverを監視するためのData Protection Advisorの構成 ...................................... 63

ギャップとリスクの表示とレポート ............................................................................................... 65

付録B： SQL Serverのパフォーマンス監視、チューニング、サイズ設定のためのツール ........................ 66

概要 ............................................................................................................................................... 66

アプリケーションレベルのツール ................................................................................................... 68

EMC DBclassify .......................................................................................................................... 68Perfcollect ................................................................................................................................. 69PAL ............................................................................................................................................ 69

SQL Serverデータベースレベルのツール ........................................................................................ 69

VSPEX SQL Serverサイジングツール .......................................................................................... 69

Transact-SQL ............................................................................................................................. 71SQL Server Profiler ..................................................................................................................... 71

SQL Serverデータベースエンジンチューニングアドバイザー ..................................................... 72

SQL Server動的管理ビュー ........................................................................................................ 72

Windowsホストレベルのツール ..................................................................................................... 72

Windowsパフォーマンスモニター（Perfmon） .............................................................................. 72

ハイパーバイサーレベルのツール ................................................................................................. 73

VMware ESXを監視するための主要メトリック .............................................................................. 73

Hyper-Vを監視するための主要メトリック ..................................................................................... 75

ストレージ/サーバーキャッシュレベルのツール ............................................................................. 76

Unisphere Analyzer ................................................................................................................... 76XtremSW Cache Performance Predictor ...................................................................................... 76EMC Storage Configuration Advisor ........................................................................................... 79


6

付録C： SQL Serverワークロード生成ツール ........................................................................................ 82

概要 ............................................................................................................................................... 82

ツールの概要 ................................................................................................................................. 82

SQL Server Profiler ..................................................................................................................... 82IOMeter ..................................................................................................................................... 83SQLIO ........................................................................................................................................ 83SQLIOSim .................................................................................................................................. 83

Quest Benchmarkファクトリ ........................................................................................................ 83

付録D：ストレージの設計例とリファレンスアーキテクチャ ................................................................... 84

概要 ............................................................................................................................................... 84

FAST VP搭載のVMAXでのMicrosoft SQL Serverストレージ設計 ....................................................... 84

フェーズ 1：ユーザー要件の収集 ............................................................................................... 84

フェーズ 2：ユーザー要件に基づくストレージアーキテクチャの設計 ........................................... 84

IOPSの計算 ............................................................................................................................... 85

容量計算 ................................................................................................................................... 85

データウェアハウスのためのビルディングブロック設計アプローチ ................................................. 87

ビルディングブロック設計の考慮事項 ....................................................................................... 87

ビルディングブロック設計の詳細 ............................................................................................... 88

ビルディングブロックの展開 ...................................................................................................... 90

SQL Server仮想マシンおよびLUNアロケーションの設計 .............................................................. 91

SQL Server保護ソリューション ........................................................................................................ 92

EMC RecoverPoint ..................................................................................................................... 92EMC Replication Manager ........................................................................................................ 100VMware vCenter SRM .............................................................................................................. 102




エグゼクティブサマリー

Microsoft SQL Server の導入の計画および設計フェーズでは、アプリケーションとス

トレージプラットフォームとの相互の影響を理解することが重要です。また、問題を

回避して高パフォーマンスを達成するためのストレージ設計のベストプラクティスを

知ることも欠かせません。

ストレージ設計では、Microsoft SQL Server のアプリケーションアーキテクチャと

ユーザープロファイルの特性を考慮して、SQL Server データベースのパフォーマン

ス、保護、拡張性を検討します。

このホワイトペーパーは、ソリューションの専門家が SQL Server ストレージのパ

フォーマンス、拡張性、可用性の要件を評価して対応するための手引きです。

• 現場から実際のデータを収集することが常に推奨されます。

• 実際のパフォーマンスデータが得られない場合は、妥当な前提条件を基に

標準的な環境を設計します。

• ストレージシステムの設計にあたっては、常に保護の要件を考慮します。

このホワイトペーパーでは、Microsoft SQL Server をサポートするストレージ設計に

関して現在 EMC が推奨するベストプラクティスについて説明します。ガイドラインは、

EMC® VNX®ファミリ、EMC Symmetrix® VMAX®

シリーズ、EMC Xtrem™ファミリで SQL Server を展開する場合のものです。物理環境と仮想環境の両方の SQL Server展開

ガイドラインが示されています。

このホワイトペーパーは、Microsoft SQL Server を使用したデータベース環境の実

装または SQL Server のバージョンアップを検討しているお客様、EMC パートナー様、

サービス担当者が対象です。読者に Microsoft SQL Server、EMC ストレージ製品

（VNX、Symmetrix VMAX、XtremSF™、XtremSW™ Cache など）、VMware または

Microsoft Hyper-V 仮想環境に関する知識があることを前提としています。

本書では、物理環境と仮想環境の両方において EMC VNX ストレージ、EMC Symmetrix VMAX ストレージ、XtremSF/XtremSW Cache で Microsoft SQL Server をホストするためのストレージ設計のEMC推奨ベストプラクティスについて説明します。

EMC の実証されたアプローチに基づくサイズ設定と設計の例も紹介します。エンドツーエンドの詳細な実装手順については、本書では説明しません。

このホワイトペーパーの目的

対象読者

対象範囲


8

このホワイトペーパーでは、次の用語が使用されています。

表 1. 用語

用語定義

AG（可用性グループ） SQL Server 2012 の HA（高可用性）および災害復旧機能。

ユーザーデータベースの可用性を最大化し、エンタープラ

イズクラスのオプションによるデータベースミラーリングを

可能にします。

可用性レプリカ特定の SQL Server インスタンスにホストされる可用性グ

ループのインスタンス。可用性グループに含まれる可用性

データベースのローカルコピーを保持します。可用性レプリ

カには、単一のプライマリレプリカ（本表の「プライマリレプリカ」を参照）と最大 4 つのセカンダリレプリカ（「読み取り可能セカンダリレプリカ」を参照）の 2 つのタイプがあります。

データ同期化プライマリデータベースに対する変更をセカンダリデータ

ベースにも適用するプロセス。

EMC XtremSF 薄型の単一サーバーフラッシュハードウェアカード。あら

ゆるラックマウント型サーバーの単一 PCIe スロットの電源

エンベロープ内に搭載でき、eMLC（エンタープライズマルチレベルセル）と SLC（シングルレベルセル）の幅広い処理

能力に対応します。

eMLC エンタープライズマルチレベルセル。マルチレベルセル

は、エラー率を低く抑えるように設計されたフラッシュメモリテクノロジーです。セルごとに複数のレベルを使用し、同じ

数のトランジスタでより多くのビットを格納できます。

FAST™ Cache FAST（Fully Automated Storage Tiering）Cache。さまざまなフ

ラッシュドライブ容量を追加して既存のキャッシュ容量を拡

張するための EMC ソフトウェアで、システム全体のパフォー

マンスを向上させます。現在の FAST Cache は、100 GB また

は 200 GB のフラッシュドライブを使用して拡張した容量構成

で提供されています。この追加構成は、VNX ストレージアレ

イでのみ使用できます。

FAST VP （ Fully Automated Storage Tiering for Virtual Pools）

データボリュームの識別を自動化する VNX ストレージアレ

イ機能。ストレージアレイ内の異なるパフォーマンス階層と

容量階層の間でのビジネスアプリケーションデータの割り

当て/再割り当てのために使用されます。

MLC（マルチレベルセル）フ

ラッシュセルごとに複数のレベルを使用するフラッシュメモリテクノ

ロジー。同じ数のトランジスタでより多くのビットを格納でき

ます。

NAND 不揮発性ストレージテクノロジーの一種。NAND フラッシュメモリはデータ保持のための電力を必要としません。

OLTP オンライントランザクション処理。代表的なアプリケーション

としては、データ入力や検索トランザクション処理などがあ

ります。

用語




用語定義

プライマリレプリカプライマリデータベースをクライアントからの読み取り/書き

込み接続に使用可能にする可用性レプリカ。各プライマリデータベースのトランザクションログレコードを各セカンダ

リレプリカに送信します。

RAID Redundant Array of Independent Disks。データを複数の

ディスクドライブに保存して、パフォーマンスとストレージ容

量を高め、冗長性とフォールトトレランスを提供します。

読み取り可能セカンダリレプリカ

クライアントの読み取り専用接続が可能なセカンダリレプリ

カデータベース。

再シーディングプライマリレプリカからセカンダリレプリカにデータベースを

コピーするプロセス。

SLC（シングルレベルセル）フラッシュ

SSD（ソリッドステートディスク）ストレージの一種。フラッ

シュメディアのセルごとに 1 ビットの情報を格納します。

SP ストレージプロセッサ。

SQL Server 2012 AlwaysOn SQL Server 2012 の包括的な高可用性および災害復旧ソ

リューション。特定データベースとインスタンス全体の両方

に利用可能な AlwaysOn の新機能と拡張機能により、さま

ざまな高可用性構成を柔軟にサポートできます。

ストレージプールデータのビジネス活動に応じて異なるストレージ階層で

データを動的に移動できる仮想構造。VNX および VMAX シ

ステムでは、ストレージプールは完全に自動化され、自動

管理されます。

シン LUN ストレージプールに作成される LUN のタイプ。割り当てられ

た物理スペースが、ホストサーバーで認識されるユーザー

容量よりも小さいことがあります。

シック LUN ストレージプールに作成される LUN のタイプ。割り当てられ

た物理スペースが、ホストサーバーで認識されるユーザー

容量と同一です。

VMDK VMware ESXi サーバーの仮想マシンディスクファイルフォーマット。

VHDX Windows Server 2012 Hyper-V の仮想ハードディスクフォーマット。


10

Microsoft SQL Serverのコンポーネントとアーキテクチャ Microsoft SQL Server は、Microsoft のリレーショナルデータベース管理および分析

システムです。日常業務やデータウェアハウジングのソリューションに使用されます。

現行バージョンは Microsoft SQL Server 2012 で、旧バージョンは Microsoft SQL Server 2008 R2、SQL Server 2008、SQL Server 2005、SQL Server 2000 などがあり

ます。

SQL Serverの各リリース

SQL Server 2000 のリリースでは、Microsoft は ETL（抽出、変換、ロード）ツール、レ

ポートサーバー、OLAP（オンライン分析処理）分析サービスなどのビジネスインテリ

ジェンス機能の開発を重視しました。

SQL Server 2005 では、XML データタイプ、DMVS（動的管理ビュー）によるサー

バー状態/パフォーマンスのモニタリングと診断、.NET Framework と統合するための

CLR（共通言語ランタイム）が導入されました。SQL Server 2005 SP1（Service Pack 1）では、データベースレベルでの冗長性とフェイルオーバー機能を実現するデータ

ベースミラーリングが追加されました。

SQL Server 2008 では、ダウンタイムを短縮するAlwaysOnテクノロジーが導入され、

データ管理の自己調整、自己構成、自己保守が可能になりました。SQL Server 2008 R2 では、マスターデータエンティティおよび階層を一元管理するマスターデータサービスと、複数の SQL Server インスタンスおよびサービスを一元管理する

マルチサーバー管理が追加されました。

SQL Server 2012 では、データベースの可用性を向上させる AlwaysOn SQL Serverフェイルオーバークラスターインスタンスと可用性グループが導入されました。また、

columnstore インデックスによってクエリーパフォーマンスが高まり、包含データ

ベースによってデータベースインスタンス間の移動が簡素化されているほか、メモ

リ管理が向上しています。

SQL Server の各バージョンで提供される各エディションは、製品機能のサブセットです。

どのエディションを実行しているかは、クエリー「select serverproperty (‘edition’)」で確認できます。メインストリームエディションは、Datacenter Edition、Enterprise Edition、Standard Edition、Web Edition、Business Intelligence Edition、Workgroup Edition、Express Edition などがあります。

SQL Server 2012は、Microsoft SQL Serverの最新バージョンです。AlwaysOnクラス

ターと高可用性グループによる高可用性と災害復旧、xVelocity インメモリストレー

ジによる高速のクエリーパフォーマンス、PowerView と Analysis Services の表形式

モデルによる高速のデータ検索、Data Quality Services による新しいデータ管理機

能が利用できます。

SQL Server 2012 のエディション

Microsoft SQL Server 2012 には、主に次のエディションがあります。

• SQL Server Standard Edition：基本データ管理とビジネスインテリジェンスレポート/分析機能が利用できます。最小限の IT リソースで効果的なデータ

ベース管理が行えます。

SQL Serverの概要

SQL Server 2012




• Business Intelligence Edition： SQL Server Standard Edition の全機能に加

え、拡張性に優れたセルフサービスのBIソリューションも利用できます。次の

ような特徴を備えています。

PowerView：迅速なデータリカバリを可能にする SQL Reporting Servicesのアドイン機能

PowerPivot：データへのアクセスと詳細な分析によってコラボレーションと

洞察の共有を容易にする機能

マスターデータサービス：組織構造全体のオブジェクトマッピング、参照

データ、メタデータ管理用のマスターデータの保守に使用

BI セマンティックモデル：マルチプラットフォームのデータソースに一貫

したビューを提供し、ユーザー作成アプリケーションを企業 BI ソリュー

ションに変換

• Enterprise Edition：包括的なハイエンドデータセンター機能が利用できます。

高負荷ワークロードを高速パフォーマンスで処理しながら、必要なアップタイ

ムとデータ保護を確保することが可能です。次のような特徴を備えています。

SQL Server AlwaysOn：統合された高可用性ソリューションにより、アップ

タイムを拡大、フェイルオーバーを迅速化、ハードウェアリソースの使

用を最適化

PowerView： PowerPivot ワークブックをベースにしたデータモデルのデー

タビューを作成して操作し、直感的なアドホックレポートを提供

xVelocity：メモリキャッシュ、高度な並列データスキャン、集約アルゴリ

ズムを使用したcolumnstoreストレージにより、データウェアハウジングと

ビジネスインテリジェンスのパフォーマンスを大きく向上

Data Quality Services：組織の知識およびサードパーティ参照データプロバイダーを使用してデータをプロファイリング、クレンジング、照合する

ことでデータ品質を向上

SQL Server は、次の主要コンポーネントで構成されます。

• SQL Server データベースエンジン：リレーショナルデータベースを作成して

駆動します。

• SSIS（SQL Server Integration Services）： ETL（抽出、変換、ロード）プロセ

スを実行して、ソースシステムの未フォーマットデータをクリーンアップおよ

びフォーマットし、データベースで使用可能な情報に変換します。

• SSAS（SQL Server Analysis Services）： OLAP キューブおよびデータマイ

ニングを作成するデータ分析コンポーネントです。

• SSRS（SQL Server Reporting Services）：表形式のグラフィカルレポートを

作成、管理、展開するためのレポートフレームワークを提供します。

データベースプラットフォームはオペレーティングシステムと密接に関連していま

す。Microsoft Windows Server は、SQL Serverに強固なインフラストラクチャを提供

します。

SQL Serverのコンポーネント

Windows Server


12

Windowsボリュームのタイプ

Windows ボリュームのパーティションスタイルには、MBR と GPT があります。

• MBR：従来のパーティションスタイル。最大 4 つのパーティションを使用でき

ます。パーティションテーブルはディスクの先頭にのみ保存されます。

• GPT： 2 TB 以上のパーティションを管理できるパーティションスタイル。パー

ティションテーブルは複数の場所に保存されます。いずれかのパーティション

が破損した場合でもリカバリが容易です。

次の 2 つのタイプのディスクモードがサポートされます。

• ベーシック：最も基本的なディスク。ベーシックディスクには、プライマリパー

ティションと必要に応じて拡張パーティションが含まれます。ベーシックモード

の機能は次のとおりです。

プライマリパーティション：標準のブート可能パーティション。

拡張パーティション：ブート不可のパーティション。これはベーシック MBRディスクの 4 番目のパーティションであり、論理パーティションが含まれる

ため、4 つ以上のパーティションの使用が可能になります。

論理パーティション：ベーシックディスクを拡張する拡張パーティションに

含まれるブート不可のパーティション。

EFI（拡張ファームウェアインターフェイス）： EFI 互換システムにブートファ

イルを保存するのに使用。

MSR（Microsoft System Reserved）： GPT ベーシックディスクでのみ使用

可能で、将来のスペースをリザーブするのに使用。

• ダイナミック：ネイティブのホストベースの論理ボリュームマネージャー。複

数のオプションでディスクを論理ボリュームに集約する役割をします。2 つの

パーティションが作成されます。一方はすべてのダイナミックボリュームを含

み、もう一方は隠しパーティションとして LDM（論理ディスクマネージャー）

データベースを含みます。このデータベースがシステムのすべてのダイナミッ

クディスクにレプリケートされることで、リカバリが可能になります。最大で

2,000 のダイナミックボリュームをホストできます（推奨は最大 32）。ダイナ

ミックモードの機能は次のとおりです。

シンプル：スタンドアロンボリューム

ストライプ： RAID 0 のように、データブロックを両方のディスクに書き込み。

この配置で統合されるボリュームは同じサイズである必要があります。

スパン： RAID 0 のように、ボリュームを連結。ディスクに障害が発生した

場合は、データの一部のみが失われます。ボリュームが同じサイズであ

る必要はありません。ストライプボリュームとディスク容量が同じ場合は、

ストライプボリュームよりもパフォーマンスが低下します。

ミラー： RAID 1

RAID： RAID 5




表 2 に、EMC ストレージに作成されて SQL Server 環境で使用される標準的なボ

リュームを示します。

表 2. EMC ストレージ向けの標準的な SQL Server 展開

ボリュームパーティション

ディスクボリューム割り当てサイズフォーマットオプション

MBR ベーシック NTFS 64 KB クイックフォーマット*

注： EMCアレイはストレージにRAID保護を提供するため、ダイナミックディスクは可能な限

り避けてください。ダイナミックディスクでは、ストレージ管理とローカル/リモート DR（災害

復旧）が複雑になります。シン LUN ではクイックフォーマットオプションが必須です。

SMB 3.0

SMB（Server Message Block）3.0 は、既存のネットワークファイル共有プロトコルの

新しいバージョンです。コンピューター上のアプリケーションによるファイルの読み取

り/書き込みと、コンピューターネットワーク上のサーバープログラムからのサービ

スの要求を可能にします。

SMB 3.0 は、Windows Server 2012 で導入され、SQL Server 2012 の RTM リリース

以降、データベース用の有効なストレージトポロジーとして SQL Server 2012 でサ

ポートされています。

SQL Server 2012 では、SMB 3.0 共有で直接ホストされる仮想化ディスク

（VHD/VHDX）とデータベースの両方がサポートされます。この共有は Windows Server 2012 または複数のクラスターサーバーで使用できます。

SMB 3.0 は、ファイルアクセスに影響するハードウェア障害への耐性を備えていま

す。EMCでは、SQL ServerのNFSストレージトポロジーとしてSMB3.0を完全サポー

トしています。

Windowsストレージの詳細については、「Storage Windows Server 2012」を参照し

てください。

http://download.microsoft.com/download/A/B/E/ABE02B78-BEC7-42B0-8504-C880A1144EE1/WS%202012%20White%20Paper_Storage.pdf�


14

図 1 に、SQL Server アーキテクチャの主なコンポーネントである SQL OS、ストレージエンジン、クエリープロセッサ、プロトコルレイヤーを示します。

図 1. SQL Server のアーキテクチャ

• SQL OS は、SQL Serverデータベースエンジンの最下層のアプリケーションレイヤーです。スケジューリング、デッドロックの検出、メモリ管理などの処理を

行います。

SQL Server はメモリリソースを動的に管理します。バッファープールは SQL Server の主要メモリコンポーネントです。他のメモリコンポーネントで使用さ

れないメモリはバッファープールに残され、ディスク上のデータベースファイ

ルから読み取られたページのデータキャッシュとして使用されます。メモリマネージャーは、データおよびインデックスページをデータキャッシュに保

存するディスク I/O 機能を管理して、データをユーザー間で共有できるよう

にします。

• ストレージエンジンは、トランザクションコマンドとバルク操作によってすべて

のデータアクセスを管理します。主な領域として、アクセス方法、ロック/トラン

ザクションサービス、ユーティリティコマンドがあります。

• クエリープロセッサ（リレーショナルエンジン）レイヤーは、T-SQL バッチを受

け入れて処理内容を判断します。T-SQL クエリーの要求を解析、コンパイル、

最適化し、バッチの実行プロセスを監視します。バッチが実行されると、デー

タ要求はストレージエンジンに渡されます。クエリープロセッサのコンポー

ネントは、クエリーオプティマイザーと Query Executor です。

SQL Serverのアーキテクチャ




クエリーオプティマイザー：最善の実行プランを決定

Query Executor：クエリーを実行

クエリープロセッサは、ストレージエンジンからデータを要求するクエリーの

実行も管理し、返された結果を処理します。OLE DB（Object Linking and Embedding Database）の行セットは、リレーショナルエンジンとストレージエンジンの間の通信チャネルです。

コマンドパーサーは、SQL Server インスタンスに送られた T-SQL 言語イベン

トを処理し、適切な構文であることを確認し、T-SQL コマンドをクエリーツリー

に変換します。クエリーオプティマイザーは、クエリーを取得すると、実行の

準備のために、コマンドバッチをコンパイルし、クエリーを最適化し、実行プ

ランでの最適な処理方法を探します。Query Executor は、実行プランを実行し、

実行プランの全コマンドのディスパッチャーの役割をします。

• プロトコルレイヤーは、ユーザーアプリケーションから要求を受け取り、こ

れをリレーショナルエンジンでの処理が可能な形に変換します。クエリー結果、

ステータス、エラーメッセージも、クライアントでの認識が可能な形式に変換し

ます。 Microsoft SQL Server には、次の主要な論理コンポーネントがあります。

• リレーショナルエンジン（クエリープロセッサ）：SQL ステートメントを検証し、

最も効率的なクエリーデータ検索方法を選択します。

• ストレージエンジン：物理 I/O 要求を実行し、リレーショナルエンジンで要求さ

れた行を返します。

これらのエンジンが連携して、SQL Server にデータの整合性を提供します。

SQL Serverの論理アーキテクチャは、データの論理的なグループ分けとユーザーへ

の提示方法を定義します。このアーキテクチャのコアコンポーネントには次のもの

があります。

• テーブル：テーブルは、論理的に集約されたデータページ（データの基本

形式）で構成されます。列と行が SQL Server テーブルの主要コンポーネン

トです。

• インデックス：インデックスは、テーブルの 1 つまたは複数の列に作成されま

す。テーブルまたはビューに関連づけられたインデックスにより、データ検索

が高速化します。クラスター化インデックスと非クラスター化インデックスがサ

ポートされます。テーブルにはクラスター化インデックスを 1 つだけ含めること

ができ、このインデックスはテーブルへのデータの保存順序を定義します。

ヒープテーブルは、インデックスなしのテーブルです。

• ビュー：ビューは、仮想テーブルまたはストアドクエリーにすることができます。

ビューから返されたデータは、選択したステートメントによってデータベースに

保存されます。

• ストアドプロシージャ：ストアドプロシージャは、単一の実行プランにコンパイ

ルされた Transact-SQL ステートメントのグループです。

• 制約、ルール、トリガー：テーブルのデータタイプとデータ整合性を維持する

ためのコンポーネントです。

SQL Serverの論理コンポーネント


16

• ユーザー定義関数：実行頻度の高いロジックをカプセル化するための関数

です。

• トリガー：トリガーは、ストアドプロシージャと似た働きをします。テーブルに接

続され、INSERT、UPDATE、DELETE コマンドでトリガーされたときだけ実行され

ます。

SQL Server の物理的コンポーネントにより、データをオペレーティングシステムの

ファイルシステムに保存する方法が決まります。データベースファイル、ページ、エ

クステント、トランザクションログファイルは、SQL Server のコア物理的コンポーネン

トです。

ファイルタイプ

SQL Server データベースには、次のファイルタイプがあります。

• プライマリデータファイル：拡張子は MDF です。データベースには少なくとも

1 つのプライマリデータファイルが必要です。

• セカンダリデータファイル：拡張子は NDF です。データベースでプライマリデータファイル以外のすべてのデータファイルは、セカンダリデータファイル

です。セカンダリデータファイルは必須でなく、データベースは多数のセカン

ダリファイルを持つことも、まったく持たないことも可能です。

• ログファイル：拡張子は LDF です。データベースのリカバリに必要なすべての

トランザクションログ情報が保存されます。各データベースは、データファイ

ルの数に関係なく、1 つのログファイルを持ちます。

データファイルには、データとインデックスの情報が保存されます。図 2 に、単一

データファイルオブジェクトの物理レイアウトでページとエクステントの関係を示し

ます。

図 2. データファイル、ページ、エクステント

ページとエクステント

SQL Server のページは、論理データストレージの基本単位です。ページサイズが

8 KB（メガバイトあたり128ページ）の場合は、各ページはページのシステム情報を

含む 96 バイトのヘッダーで始まります。

SQL Serverの物理的コンポーネント




プライマリデータファイル（.mdf）またはセカンダリデータファイル（.ndf）に割り当て

られたディスク領域は、論理的にページに分割されます。ディスク I/O 動作は、ペー

ジレベルで実行されます。

エクステントは、スペース管理の基本単位です。各エクステントは物理的に隣接す

るページを 8 つ含み、64 KB（メガバイトあたり 16 エクステント）です。テーブルまた

はインデックスの割り当てには、通常は混合エクステントのページが使用されます。

8 ページに達した後の割り当てには、単一エクステントが使用されます。

トランザクションログ

トランザクションログには、データファイル内でのトランザクションによる変更が保存

されます。これには、次のイベントに関する情報が含まれます。

• 各トランザクションと開始と終了

• データの変更

• エクステントとページの割り当てと割り当て解除

• テーブルまたはインデックスの作成と削除

トランザクションログは、システム障害が発生した場合にデータベースをリカバリす

るために欠かせません。

ログレコードは順次保存され、各レコードにはトランザクション ID が含まれます。単

一の物理トランザクションログは、内部の SQL Server アルゴリズムとトランザク

ションログの初期サイズに基づいて論理的に仮想ログにセグメント化されます。ト

ランザクションアクティビティが開始されると、物理ログファイル内の仮想ログがト

ランザクション情報を記録します。

ファイルグループ

SQL Server のファイルグループを使用すると、テーブルとインデックスのファイルを

分離して、これらをディスクレベルで選択して配置することができます。次のことが

可能です。

• テーブルとインデックスをディスクレベルで分離する。

• ページ割り当てレートが高いために多くのデータファイルを必要とするオブ

ジェクトを分離する。

SQL Server データベース管理者は次のことが行えます。

• ファイルグループまたはファイルレベルでバックアップを実行する。SQL Server では、特定のファイルグループに部分的に可用性を提供することが可

能です。他のファイルグループがオフラインであっても、プライマリファイルグループがオンラインであれば、特定のファイルグループをオンラインにでき

ます。ファイルグループのすべてのファイルが使用可能であれば、そのファイ

ルグループは使用可能です。

• テーブルとインデックスの行内データとラージオブジェクトデータに別のファ

イルグループを使用する。

• パーティション分割されたテーブルにファイルグループを使用する。

各パーティションはそれぞれのファイルグループ内に置くことが可能

アーカイブしやすいようにパーティションをテーブル内/外に切り替え可能


18

SQL ServerのI/Oおよび帯域幅特性 SQL Server の I/O のパターンと特性を理解することは、SQL Server アプリケーションの設計と展開にあたって非常に重要です。I/O サブシステムを適切に構成することで、SQL Server のパフォーマンスを最適化できます。

汎用 SQL Server データベースのワークロードには、OLTP とデータウェアハウス/OLAP の 2 つのタイプがあります。特定のユーザーデータベースでは、標準ベンチマークとは大きく異なる I/O ワークロードが発生することがあります。I/O パフォーマンスの要件を識別するには、標準的なロードでリアルタイムにデータベースを分析するのが唯一の方法です。

OLTP ワークロードでは、大量のランダム I/O 読み取り/書き込み（IOPS）を伴う多数の同時トランザクションが発生します。OLTP データベースは絶えず変更されます。ほとんどのアドホックアプリケーションで OLTP ワークロードが発生します。

Microsoftの「SQL Server Best Practices Article」によると、OLTPデータベースワークロードには次のパターンがあります。

• データファイルに実行される読み取りと書き込みは両方とも、一般にランダムの性質を持つ。

• 読み取りアクティビティは（ほとんどの場合）、一定した性質を持つ。

• データファイルの書き込みアクティビティは、チェックポイント操作（頻度はリカバリ間隔設定で決定）で発生する。

• ログ書き込みは、シーケンシャルの特性を持ち、ワークロードの性質によってサイズが異なる（セクター配列は最大 60 KB）。

• ログ読み取りは、シーケンシャルの性質を持つ（セクター配列は最大 120 KB）。

OLTP データベースは通常、多くの書き込みアクティビティが行われ、I/O サブシステムに負荷を与えます。特に、書き込みが最初にトランザクションログに行われるため、ログ LUN に負荷がかかります。

標準的な OLTP システム（航空機のオンライン予約システムなど）では、多数の同時接続によってデータがアクティブに追加および変更されます。OLTP システムではトランザクションログの頻繁なバックアップが必要で、I/O サブシステムへの負荷がさらに増します。

トランザクションレプリケーションを使用する構成では、最初のスナップショットの実行後は、それ以降のパブリッシャーでのデータ変更とスキーマ修正がサブスクライバーに送信されて、パブリッシャーデータベースのトランザクションログに対する読み取りアクティビティが増加します。

インデックスの使用も、I/O サブシステムに影響を与える要因です。大量のインデックスを含む OLTP システムは、大量の同時接続に低レーテンシーで対応して、ごくわずかな履歴データを含むデータセットから少数の行を取得できます。OLTP システムにおけるトランザクションの揮発性のため、インデックスの頻繁なメンテナンスが必要になり、I/O サブシステムに大量の読み取り/書き込み要求が行われる場合があります。

OLTP サブシステムでは通常、IOPS（秒あたりの I/O 動作）が非常に多くなります。ディスクドライブの数を増やすことで、IOPS 能力が高まります。

概要

OLTP

http://technet.microsoft.com/en-us/library/cc966412.aspx�




データウェアハウジングは、DSS（意思決定支援システム）やビジネスインテリ

ジェンスシステムのベースによく使用されています。この組織データリポジトリは、

レポートと分析のために大量のデータセットを使用する複雑な分析クエリーアクティ

ビティを容易にします。データウェアハウスデータベースは OLAP（オンライン分析

処理）タイプのデータベースであり、一般にデータウェアハウスに集約されたデー

タを基に複雑な分析を行います。

データウェアハウスシステムのデータは通常、シーケンシャルな読み取りによる静

的データであり、一般的なバッチ更新を除いて書き込みアクティビティはわずかです。

IOPS よりも I/O 帯域幅が重要になります。データウェアハウスの標準的なワーク

ロードは、大量のデータロードとインデックスビルド、ビューの作成、大量データの

クエリーといった操作による I/O 集中型のワークロードです。データウェアハウスの

基盤の I/O サブシステムは、これらの広帯域幅要件を満たす必要があります。

データウェアハウスの I/O 特性は次のとおりです。

• シーケンシャルな読み取りと書き込み（一般にテーブル/インデックススキャンの結果やバルク挿入操作による）

• 不揮発性のデータ、大量の履歴データセット

• ファクトテーブルの軽量インデックス

• 少ない同時接続

• 大量の Tempdb アクティビティ

• さまざまな I/O サイズ：通常は 8 KB超。先読みは 8 KB の倍数（最大512 KB）。バルクロード操作は 8 KB の倍数（最大 128 KB）

• columnstore インデックスを使用する場合、データベースファイル I/O サイズ

は 256 KB を大きく超える

効率的なDW（データウェアハウス）ストレージソリューションの設計における主な考

慮事項は、コンピューティング、ネットワーク、ストレージのレイヤー間で DW システ

ムの能力のバランスをとることです。

たとえば、コンピューティングレイヤーは、ストレージを快適に使用できる帯域幅

レートでデータを処理できることが求められます。また、コンピューティングレイヤー

とストレージレイヤーのネットワークは、これらのレイヤー間で最大可能なスルー

プットを維持できる必要があります。理想として、コストパフォーマンスに優れた DWソリューションのために、ソリューションの一要素に他の要素よりも過剰な能力を持

たせないようにします。

データウェアハウスの設計では、所定のサーバーと HBA（ホストバスアダプター）

カードで使用可能な I/O 帯域幅を見積もり、選択した I/O 構成でサーバー要件を満

たせるようにします。

適切に設計されたデータウェアハウスシステムでは、スキャンが集中する操作向

けにストレージシステムが最適化され、同一帯域幅でストレージが提供するデー

タをサーバーCPU が受け取って処理することが可能です。データウェアハウスのク

エリーではデータベースから数百万のレコードを取り出して処理するため、通常は

データが大きすぎてメモリに収まりません。適切なストレージ設計としては、プロセッ

サによる集約を実行できるようにデータをディスクから高速に検索して送信できるよ

うにする必要があります。

データウェアハウス/OLAPデータベース


20

SQL Server データベースエンジンからの I/O読み取りには、次のタイプがあります。

• 論理読み取り：データベースエンジンがバッファーキャッシュのページを要求すると発生します。

• 物理読み取り：ページがバッファーキャッシュに現在ない場合に、ページをディスクからキャッシュにコピーします。

読み取り要求は、リレーショナルエンジンによって制御され、ストレージエンジンによって最適化されます。先読みメカニズムでは、クエリー実行プランに必要なデータおよびインデックスページを予測して、それらのページをクエリーで使用される前にバッファーキャッシュに保存します。このメカニズムにより、処理と I/O をオーバーラップさせ、CPU とディスクを有効に活用してパフォーマンスを最適化できます。

データベースエンジンのインスタンスからの I/O 書き込みには、次のタイプがあります。

• 論理書き込み：バッファーキャッシュのページでデータが変更されると発生します。

• 物理書き込み：データがバッファーキャッシュからディスクに書き込まれると発生します。

ページ読み取りとページ書き込みは両方とも、バッファーキャッシュで発生します。バッファーキャッシュでページが変更されるたびに、ページは「ダーティー」とマークされます。ページには、ディスクへの物理書き込みの前に、複数の論理書き込みが行えます。ディスクへのログレコードの書き込みは、関連するダーティーページをディスクに書き込む前に行う必要があります。データの整合性を維持するために、SQL Server では先書きログを使用して、関連するログレコードがディスクに書き込まれる前にダーティーページが書き込まれるのを防止しています。

図 3 に、SQL Server でのページ書き込み処理を示します。

図 3. SQL Server でのページ書き込み処理

ダーティーページは次のいずれかの方法でディスクに書き込まれます。

• 遅延書き込み：使用頻度の少ないページをバッファーキャッシュから削除して空きバッファーを利用できるようにするシステムプロセスです。遅延書き込みでは最初にダーティーページをディスクに書き込みます。

• 一括書き込み：バルク挿入/選択などログに記録されない操作をダーティーページに書き込むシステムプロセスです。

• チェックポイント：チェックポイント操作では、定期的にバッファーキャッシュをスキャンしてデータベースページがないか確認し、すべてのダーティーページをディスクに書き込みます。

ページ読み取り

ページ書き込み




遅延書き込み、一括書き込み、チェックポイントのプロセスでは、非同期 I/O によってスレッドを呼び出して処理を継続しながら、バックグラウンドで I/O 動作を実行してCPU と I/O の両リソースを最大限に活用することでタスクを最適化します。

ログワークロードは、トランザクションログに対する I/O です。通常はシーケンシャル書き込みで、大規模なトランザクションワークロードのレーテンシーが低く済みます。トランザクションログファイルの書き込みは、所定のトランザクションに対して同期式になります。これは、ユーザースレッドが次のトランザクションを開始する前に、SQL Server がコミット済みトランザクションに関連するすべての更新をフラッシュするためです。

Tempdb は、SQL Server で一時ワークスペースとして使用されるシステムデータベースです。Tempdbの I/OパターンはOLTPのパターンと似ています。Tempdbは、ワークロードに応じて、（OLTP タイプのワークロードの）低アクティビティから、（DSSワークロードや OLAP ワークロードの）極めて高度なアクティビティに及びます。

表 3 に、各タイプのデータベースにおける I/O パターンをまとめます。

表 3. SQL Server データベースの各種ワークロードの I/O パターン

I/O のタイプと特徴

データベースファイル OLTP （オンライントランザクション処理）

意思決定支援システム（データウェアハウス、OLAP）

データファイル

• 小規模なランダム I/O（8～64 KB） • 書き込みよりも読み取りの比率が高い

（通常、90/10～70/30 の読み取り/書き込み比）

• 高パフォーマンスと保護を RAID 10 で達成可能。階層型ストレージでは RAID 5 または RAID 6 をストレージプールで使用することで十分なパフォーマンスが得られる

• 大規模なシーケンシャル I/O（ほとんどが 64 KB、columnstore インデックスを使用する場合は 256 KB 超）

• 読み取りよりも書き込みの比率が低

く、読み取り専用の場合もあり • 通常は RAID 5 で適切なパフォーマンス

が得られ、所定数のディスクの使用可能スペースがはるかに増す

データベースログファイル

• 小規模で高度にシーケンシャルな I/O（512 バイトの倍数）

• ほとんどが排他書き込みで、大量のロールバックやログバックアップの際に読み取り

が発生

• ログ用は RAID 1/0 を推奨。RAID 5 でも適切なパフォーマンスが得られる（フルストライプ書き込みによる）。ドライブ障害が発生するとパフォーマンスが低下する場合あり（フ

ラッシュドライブでは無視できる程度の低下）

Tempdbデータファイル

• 使用に応じてサイズが変動（通常は I/O が高め、一般に 64 KB を超えない） • シリアルまたはランダム I/O で、ワークロードによってはシーケンシャルになるが、同時

実行される多数のワークロードはランダム I/O として扱われる

• 通常は書き込み/読み取り比がほぼ 50/50

• Tempdb は予測不能の特性を持ち、通常は書き込みの比率が高いことから、RAID 1/0によって所定数のディスクで最適なパフォーマンスが得られる。ログファイルと同様に、RAID 5 でも（特にフラッシュドライブの使用時に）適切なパフォーマンスが得られる

• Tempdb のアクティビティは変動する

• 通常はあまりアクティブではなく、パ

フォーマンスの要求は低い

• 頻繁なレポートと大量のテーブル結合によって非常にアクティブになることがある

Tempdb は、XtremSF などのサーバーサイドフラッシュストレージを必要とする高パフォーマンスが要求されることがある

ログマネージャー

Tempdbの使用

I/Oのパターン


22

SQL Serverストレージのサイズ設定とプロビジョニングのベストプラクティス

ストレージ設計は、Microsoft SQL Server の展開を成功させるために極めて重要な

要素です。信頼性、パフォーマンス、コスト、使いやすさの点で最適なストレージ設

計を行うには、推奨されるストレージガイドラインに従います。

このセクションでは、Symmetrix VMAX シリーズストレージ、VNX ユニファイドスト

レージ、XtremSF、XtremSW Cache などの EMC ストレージで SQL Server を展開する

ための一般的なベストプラクティスと、SQL Server を使用する特定の EMC ストレー

ジアレイ機能の推奨事項について説明します。

SQL Server 環境の仮想化には特定の考慮事項があるため、このセクションではこ

の点についても説明します。

SQL Serverの設計は、図 4に示すように、5つの LUNで始めて、アプリケーションパフォーマンス要件に基づいて拡張することをお勧めします。

図 4. SQL Server の構成

SQL Server の構成では、まず次の基本要件を考慮します。

• OS/SQL Server のバイナリ

SQL Server の標準的な導入では、サーバーを SQL Server 専用にして、OS と

同じ LUN にバイナリを配置します。Microsoft の推奨する OS タイプと SQL Server バージョンに従い、サーバーにインストールするアプリケーションの

オーバーヘッドを考慮に入れます。

OS/SQL Serverバイナリ/システムデータベースの標準的な LUNは 60～120 GBです。一般に、RAID 5 ストレージプールの大容量/低パフォーマンスディスクで

この要件に対応できます。

概要

SQL Serverストレージの一般的なベストプラクティス




• システムデータベース

ほとんどの環境では、システムデータベースは頻繁に変更されることはなく、

OS と同じ LUN に置くことができます。

• ユーザーデータベースのログ

ユーザーデータベースのログでは、ほとんどの場合、必要な IOPS は低くなり

ます（ほとんどがシーケンシャル書き込み）。AAG（AlwaysOn 可用性グループ）

などのレプリケーションを使用する場合でも、これらの LUN で必要な IOPS は

一般にあまり大きくありません。このため、ログ LUN は通常は FC（ファイバーチャネル）ディスクで構成され（ストレージプール内、FC 階層に固定可能）、最

低 10%の追加スペースで容量の要件を満たすことができます。

• Tempdb

OLTP 環境では、Tempdb の I/O 要求はあまり大きくなく、ログと同じ設計原則

に従うことができます。この場合、通常は SQL Server データベースログ LUNと同じプールに置くことができます。

スケジュール設定したレポートやアドホックレポートまたは大規模なテーブル

結合を実行する場合は、Tempdb の使用量が大きく増えることがあります。

Tempdb の使用量を決めるには、SQL システムの要件を計測する必要があり

ます。

データウェアハウスや OLAP ワークロードの Tempdb は一般に I/O 要求が非

常に大きく、これらの環境では特別に注意しなければなりません。これら環境

の Tempdb の設計では、必要に応じてデータベース設計におけるサイズ設定

と配置の原則に従ってください。

• ユーザーデータベース

ユーザーデータベース LUN は一般にストレージ設計の主な焦点です。LUN タ

イプは、パフォーマンスと容量の要件やワークロードのタイプによって異なり

ます。

Microsoft TechNetに掲載されているSQL Serverストレージの一般的なベストプラク

ティスに従ってください。重要なポイントを以下で紹介します。

SQL Serverの基本的なベストプラクティス

SQL Server の基本的なベストプラクティスをいくつか挙げます。

• SQL Server の起動アカウントに Lock Pages In Memory ポリシーを選択して、

SQL Server のメモリスワップを防止します。

• データファイルを事前に割り当てて、ピーク時の自動拡張を回避します。

• データとログファイルの自動圧縮をオフにします。

• 同じデータベース内のデータファイルを同じサイズにします。SQL Server では、

スペースの大きさに比例してデータを書き込むアルゴリズムが使用されてい

るため、空き領域の大きいファイルにより多くのデータが割り当てられます。

• インデックスの再構築や再構成を行う日常のメンテナンスは dbcc checkdbコマンドで実行します。

http://technet.microsoft.com/en-us/library/cc966534.aspx�


24

ファイルグループとファイルの考慮事項

SQL Server のファイルグループに関する考慮事項を挙げます。

• ファイルグループには並列アクセスが可能です。異なるディスク/ストレージプールにファイルグループを配置すると、パフォーマンスを向上できます。

• データベースを設計するときに、パフォーマンスや保護の要件が似た SQL Server データファイルをファイルグループにまとめます。

• Tempdb などの高負荷のデータベースの割り当てでは、必要に応じて各 CPUにつきファイルグループあたり 0.25～1 個のデータファイルを作成します。

• 開始時はデータファイルを少数にします。必要に応じて増やします。

• 標準的な環境ではログファイルは1つ作成します。ログファイルを増やしても

パフォーマンスは向上しません。

詳細については、Microsoft MSDNライブラリで「Using Files and Filegroups」を参照

してください。

ストレージの基本的なベストプラクティス

ストレージ設計の基本的なベストプラクティスをいくつか簡潔に挙げます。詳細につ

いては、「ストレージの一般的な考慮事項」を参照してください。

• パフォーマンス、容量、保護を計画します。表 4 に、データファイルとログファイルのレスポンスタイムを示します。

表 4. データファイルとログファイルのレスポンスタイム

I/O 応答時間データファイルログ

非常に良い 10 ミリ秒未満 5 ミリ秒未満

許容範囲 10～20 ミリ秒 5～15 ミリ秒

調査と改善が必要 20 ミリ秒超 15 ミリ秒超

• Windows のボリュームを作成するときに、SQL Server のデータベース LUN と

ログ LUN の Windows アロケーションユニットを 64 K に設定します。

• 予測可能なサービスレベルでの最適なパフォーマンスのために、Tempdb、データ、ログファイルを別々の LUN に置きます。

• データの増加に対応できるように、データベースファイルの LUN は容量が

80%を超えないようにします。

• データファイルの LUN は高速ドライブに配置するか自動階層化を有効にし

ます。

• ログファイルの LUN は自動階層化が無効な SAS または FC ドライブに配置し

ます。

• メーカー推奨の最新 HBA ドライバーを使用します。

• ストレージアレイのファームウェアが最新であることを確認します。

• 可用性/冗長性とスループット最適化のためにマルチパス機能を使用するこ

とを検討します（特に iSCSI/ファイルベースの構成の場合）。

http://msdn.microsoft.com/�




クラスタリングの考慮事項

SQL Server の Tempdb には保護が必要です。Tempdb ファイルは、SQL Server イン

スタンスが起動するごとに再作成されます。XtremSF、VPLEX、CE（Cluster Enabler）環境では、可能な場合は非共有ディスクパーティションを SQL Server 2012 FCI クラ

スターの Tempdb に使用してコストと帯域幅を削減できます。

以前のバージョンの考慮事項

以前のバージョンのSQL ServerとWindowsを使用する場合は、次の点を考慮してく

ださい。

• SQL Server 2005 以前のバージョンでは、SQL Server の起動アカウントに権

限を付与して、Windows のファイルの瞬時初期化権限を有効化します。

• Windows 2008 よりも前のバージョンでは、セクター配置設定が正しいことを確

認します。Windows 2008 以降では、デフォルトでセクターが配置されます。

パフォーマンスと容量の考慮事項

Microsoft SQL Server の展開では常に、パフォーマンス、保護、容量の要件を考慮

します。

一般的な OLTP ワークロードでは、データベースファイルとログファイルについてほ

とんどの場合に IOPS のスループット測定値が容量の要件よりも重視されます。

Tempdb ファイルは、ワークロードの I/O 特性が低いことから、通常は容量を中心に

考慮します。

OLAP 環境では、データベースファイルについては帯域幅の測定値（メガバイトまた

はギガバイト）が支配的で、Tempdb ファイルには高いスループット（IOPS）が必要な

傾向にあります。

ユーザーデータベースファイルとログファイルは、データ消失を防ぐために十分な

保護が必要です。Tempdb ファイルは一時データのみを含み、SQL Server の起動時

に再作成されることから、Tempdbの保護の優先度は高くありません。Tempdbのパ

フォーマンスが重視される場合は（OLAP 環境など）、Tempdb に XtremSF などの

サーバーフラッシュドライブを使用してストレージのレーテンシーを最小化するのが

理想的です。

さまざまなタイプのワークロード向けのストレージを設計する場合は、ワークロード

のタイプを考慮し、データベース、ログ、Tempdb のファイルの標準的な I/O パ

ターンを考慮します。パフォーマンスと容量の要件を両方とも満たせるように計算し

てください。

ディスクタイプの選択

SQL Server のストレージ設計で最初に行う重要な決定に、要件に最も適したディス

クタイプの選択があります。SQL Server の展開に適したディスクタイプは、データ

ベースサイズや IOPS の要件などいくつかの要因で決まります。

ストレージの一般的な考慮事項


26

表 5 に、VNX ユニファイドストレージファミリと Symmetrix VMAX シリーズストレージ

で EMC が提供しているディスクタイプを示します。フラッシュは XtremSF および

XtremSW Cache としても使用されます。

表 5. EMC が提供しているディスクタイプ

ディスクタイプ特徴選択の考慮事項

FC（ファイバーチャネル）

読み取り/書き込みが高速

で信頼性の高いディスクドライブ。

高 I/O 要件に理想的。大容量要件には

必ずしも適さない。

SAS（シリアル

接続 SCSI）従来の SCSI ドライブの改良

型である SAS ディスクでは

大容量と適度な I/O 速度が

得られる。

高 IOPS 要件の SQL Server 環境に非常

に適している。

SATA I/O 速度の要求が低い大容

量ディスク。 I/O 要件の低い大規模データベースに

適している。データウェアハウスや

SharePoint コンテンツデータベースに

最適。

NL-SAS （ニアライン SAS）

SATA ディスクと同様に、

NL-SAS ディスクは I/O 要件

の低い大容量要件に適して

いる。

NL-SAS ディスクは大規模データベー

スを比較的低コストでサポート可能。一

般に、低 I/Oプロファイルの大規模デー

タベースに最適。

フラッシュフラッシュドライブは最速の

I/O 速度で低電力消費。フラッシュドライブの一般的な用途は

次のとおり。

• ストレージアレイの自動ストレージ

階層化機能の一部として使用（EMC FAST VP や FAST Cache で予期しな

い I/O 急増に対応する場合など）

• サーバー上の XtremSF/XtremSW Cache として使用

EMC では、極めて要求の高い SQL Server 環境向けにフラッシュのみのア

レイである XtremIO™も提供。

ディスクタイプの選択では、次の一般的な規則に従います。

• 要件が低 IOPS、許容可能なディスクレーテンシー、大容量データベースの場

合は、SATA または NL-SAS ディスクを使用します。

• 要件が高 IOPS、低ディスクレーテンシー、大容量データベースの場合は、大

容量の FC または SAS ディスクを使用します。

• 要件が高 IOPS、非常に低いディスクレーテンシー、小容量データベースの場

合は、ストレージ階層化でフラッシュドライブを使用するか、FAST Cache を使

用します。

• 要件が最も高要求の IOPS とディスクレーテンシーで小容量データベースの

場合は、XtremSF または XtremSW Cache を使用します。




ディスクタイプが異なると、同じレーテンシー要件でもサポートする IOPS が異なりま

す。ご使用の環境のディスク要件を計算する場合は、この点を考慮してください。次

の表に、EMC VNXおよびVMAXストレージ上の最新の SQL Serverで検証したランダ

ムディスク IOPS データを示します。これらの結果は、将来のテストに基づいて変更

される可能性があります。

注： VNX/VMAX ストレージアレイでの SQL Server の展開における IOPS 要件の計算には、

表 6 の値を使用することを強くお勧めします。これらの値は、表 4 に示した一般に許容可

能なパフォーマンスのベースラインになります。より高いパフォーマンスを要求するアプリ

ケーションの場合は、ディスク数を増やすか、FAST Cache などのアレイキャッシュや

XtremSW Cache などのサーバーキャッシュを使用します。

表 6. EMCストレージアレイの各ディスクタイプにおける 8 KBランダム読み取り I/Oの IOPS

ディスクタイプディスクあたりの IOPS

15 K rpm SAS 180

10 K rpm SAS 140

7.2 K rpm NL/SAS 70

SSD（ソリッドステートディスク） 3,500

表 7 に、サーバーフラッシュの IOPS を示します。

表 7. XtremSF モデルの SQL Server IOPS

ランダム8K IOPS

XSF550 MLC *

XSF550 MLC *

XSF2200 MLC *

XSF2200 MLC *

XSF320 SLC

XSF700 SLC

読み取り 131,795 128,207 258,838 256,887 376,072 395,906

書き込み 23,592 16,235 53,713 35,654 67,635 133,593

読み取り/書き込み

（70/30）

56,255 42,471 120,162 93,848 171,666 191,169

*パフォーマンスモードの場合。デフォルトの容量モードの構成の場合は、IOPS は低くなる。

プールとRAIDタイプ

使用環境に適したRAIDタイプの選択も、SQL Serverの実装を成功させるために行う

重要な決定です。I/Oおよびストレージ容量の要件に十分に対応できるディスクであ

れば、どの RAIDタイプでも使用できます。一般に、RAIDタイプの決定は所定の要件

に基づきます。使用環境に適した RAID タイプを選択するには、パフォーマンス、容

量、高可用性の特定の要件を考慮します。


28

EMC ストレージシステムは、RAID 1/0、RAID 5、RAID 6 をサポートし、フラッシュ、FC、SAS、NL-SAS、SATAドライブを使用できます。これらのRAIDタイプは、それぞれ異な

るパフォーマンス、容量、保護レベルを提供します。

• RAID 1/0 では、データを別のディスクにミラーリングすることによってデータを

保護します。パフォーマンスが向上し、ディスク障害が発生した場合のパ

フォーマンスインパクトはほとんどまたはまったくありません。一般に、RAID 1/0 は、特に SATA ドライブや NL/SAS ドライブを使用する場合に SQL Serverに最適な選択です。

• RAID 5 では、データが大きなストライプサイズで複数のディスクにストライ

ピングされます。パリティ情報がすべてのディスクに格納されるため、データ

の再構築が可能になります。これにより、単一ディスク障害から保護できます。

ライトペナルティが大きい RAID 5 は、ほとんどが読み取り I/O の大規模デー

タベースを展開する環境に最適です。SSD フラッシュドライブを使用する場合

は、このパフォーマンスの影響はなくなります。フラッシュドライブを使用する

ほとんどの環境は、RAID 5 の構成により、高 IO 要件に対応し、ディスクレー

テンシーを非常に低くすることができます。

• RAID 6でも、データが大きなストライプサイズで複数のディスクにストライピン

グされます。ただし、必要に応じてデータを再構築できるように、2 セットのパ

リティ情報がすべてのディスクに格納されます。RAID 6 では、データを失うこと

なく 2 台のディスクの同時障害に対応できます。

表 8に、それぞれのRAIDタイプのRAIDオーバーヘッド、パフォーマンス、ストレージ

使用率に関する情報を示します。

注： RAID オーバーヘッドの値は、必要数のディスクの I/O を計算する際に重要になります。

RAID 5と RAID 6では、ドライブ障害が発生して再構築が必要な場合にパフォーマンスに影

響が出ます。表 8 でのパフォーマンスの比較には、RAID 構成の同じタイプのディスクを同

数使用しています。ストレージ使用率の比較には、RAID 構成の同じディスクタイプを同じ

IOPS と近似レーテンシーで使用しています。

表 8. RAID レベルのパフォーマンス特性

RAID レベル

ランダム読み取り

ランダム書

き込みシーケン

シャル読み

取り

シーケン

シャル書

き込み

RAID 書き込

みオーバー

ヘッド値

ストレージ

使用率

RAID 1/0

極めて良好極めて良好極めて良好極めて良好

2 低

RAID 5 極めて良好適度良好適度 4 高

RAID 6 良好低い良好適度 6 中

ストレージプールは、データのビジネス活動に応じて異なるドライブ階層間（高パ

フォーマンスドライブと低コスト/大容量ドライブ）でデータを動的に移動できる仮想

構造です。VNX および VMAX システムでは、ストレージプールは完全に自動化され、

自動管理されます。

ストレージプールを使用すると、ストレージのプロビジョニングが容易になります。

プールベースのプロビジョニングでは、複数のドライブにストライピングされた

metaLUN と同様のメリットが得られますが、metaLUN とは異なり、ストレージプール

のプランニングと管理は最小限で済みます。




ストレージプールでは、RAID グループと同じ RAID 保護レベル（RAID 5、RAID 6、RAID 1/0）がサポートされます。RAID やディスクのタイプが異なる複数階層プールを

同じストレージプールに含めることができます。ストレージプールでも、FAST VP、圧縮、重複排除、データ保護オプション（VNX スナップショットなど）のような高度なデー

タサービスが利用できます。

ほとんどの SQL Server データベース環境は、ストレージプールベースの構成によ

るメリットがあります。

EMC VMAX/VNX システムが提供する仮想プロビジョニングは、業界では一般にシンプロビジョニングと呼ばれるものです。シンプロビジョニング（仮想プロビジョニング）

は、ストレージ管理を簡素化し、SQL Server の多くの用途で容量使用率を下げてス

トレージコストを削減します。

仮想プロビジョニングを利用すると、SQL Server で物理的に割り当てられている容

量よりも多くの容量を利用できます。物理ストレージは、必要に応じて共有プールか

ら「オンデマンド」でデータベースに割り当てられます。

物理ストレージ容量は、シック LUNの場合は LUNの作成時に完全に割り当てられま

す。シン LUN の場合は最初に割り当てられる物理ストレージはこれよりも少なくなり

ますが、必要に応じてストレージプールが実際の物理ストレージを提供してシン

LUN の割り当てをサポートします。物理ストレージは、新しいデータブロックがシン

LUN に書き込まれるときにのみ自動的に割り当てられます。

シック LUN でもシン LUN でも、あらゆる SQL Server ワークロードに必要なパフォー

マンス特性が得られます。

シンLUNとシックLUNの違い

データの書き込み先となる実ストレージ領域はデータデバイスから提供されるため、

シンデバイスは構成されている容量よりも大きな容量で作成できます。ホストオペ

レーティングシステムに対して、シンデバイスは標準デバイスと同じ構成容量を持

ち、ホストとのやりとりは標準デバイスの場合と同じように行われます。

シン LUN は、特に FAST VP（VNX と VMAX）や FAST Cache（VNX）とともに、ほとんど

の環境で適度なパフォーマンスを実現できます。

シン LUN に関連した主なパフォーマンス考慮事項は次のとおりです。

• シン LUN では、ストレージを大幅に節約し、将来の拡張に対応できます。

• LUN を拡張した場合は、書き込みへの対応にわずかなパフォーマンスオー

バーヘッドが生じます。

まとめると、ストレージプール、シン LUN、シック LUN、RAID のどの LUN 構成を使用

するかを決める際は、次の点を考慮します。

• ストレージプールは、データ効率性サービス（FAST VPなど）、圧縮、重複排除、

その他プールベースのオプションを活用する場合に使用します。

• シン LUN は、プールのセットアップと管理を容易にし、スペースの効率性を最

適化し、電力と容量を節約し、データベース容量を柔軟に長期間使用する場

合に選びます。

ストレージの仮想プロビジョニングの考慮事項


30

• シック LUN は、容量の要件が予測可能なデータベースに使用します。

• RAID グループとトランザクション LUN は、データベースのサイズやパフォー

マンスの要件が長期間変更されない場合、物理ドライブに論理データオブ

ジェクトを正確に配置する場合、データを物理的に分離する場合に使用し

ます。 SQL Serverのパフォーマンス特性は、アプリケーションによって環境ごとに大きく変わ

る場合があります。これらの特性は大きく分けて 2 種類あります。OLTP は、ほとんど

がランダムの読み取りワークロードです。データウェアハウスは、ほとんどがシー

ケンシャルな読み取りワークロードです（表 9 を参照）。OLTP 環境では、読み取り/書き込み IOPS（IO/秒）を使用してストレージのサイズ設定を行います。データウェアハ

ウス環境では、帯域幅（MB/秒）を使用してストレージのサイズ設定を行います。

パフォーマンスを正確に予測するために、できるだけ「実際の環境」に近い条件でテ

ストしてください。テストでは、パフォーマンスモニターログを使用して、データベー

スファイルを保存するボリュームの特性（IOPS の読み取り/秒と書き込み/秒、帯域

幅の MB/秒など）を取得します。

注：

• IOPS カウンターの期間内の平均をストレージ設計のベースに使用しないでください。

IOPS サンプルで 90 パーセンタイル値のものを特定し、そのパフォーマンスレベルに

合わせて設計することをお勧めします。これにより、負荷の急増にオンデマンドで対

応できます。

• RAID グループの IOPS 要件は、読み取りと書き込みで別々に計算する必要があります。

パフォーマンスのサイズ設定

次の式を使用して、パフォーマンスに必要なディスク数を計算します。

𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑖𝑠𝑘𝑠

=𝑅𝑒𝑎𝑑 𝐼𝑂𝑃𝑆 + (𝑊𝑟𝑖𝑡𝑒 𝐼𝑂𝑃𝑆 × 𝑅𝐴𝐼𝐷 𝑝𝑒𝑟𝑓𝑜𝑟𝑚𝑎𝑛𝑐𝑒 𝑜𝑣𝑒𝑟ℎ𝑒𝑎𝑑)

𝐼𝑂𝑃𝑆 𝑝𝑒𝑟 𝑑𝑖𝑠𝑘

ディスク数

読み取り IOPS +（書き込み IOPS×RAID パフォーマンスオーバーヘッド）

ディスクあたりの IOPS

注：選択した RAID レベルの要件に合わせてディスク数の調整が必要になる場合がありま

す。たとえば、7台のディスクによるRAID 1/0セットは構成できません。この場合は、8台の

ディスクの RAID 1/0 セットが必要です。

ディスクあたりの IOPS は、選択したドライブタイプの IOPS 値です。

「ディスクタイプの選択」の表 6 に、RAID 構成と階層型ストレージ構成に必要な

ディスクの計算に推奨される各ディスクタイプのディスクあたりの IOPSが示されて

います。

ストレージのサイズ設定のベストプラクティス

OLTPデータベースのサイズ設定の考慮事項




階層型ストレージ構成では、異なる階層の容量要件も計算する必要があります。次

のツールが階層型ストレージの設計に役立ちます。

• EMC Storage Configuration Advisor（サイズ設定用）

ストレージアレイの履歴パフォーマンスデータが必要です。詳細について

は、EMCのWebサイトを参照してください。

• ワークロードパフォーマンス評価ツール

Mitrendとも呼ばれます。FAST VPのヒートマップを表示します。詳細について

は、https://emc.mitrend.comを参照してください。

• VSPEX サイジングツール（VNX）

詳細について

は、http://japan.emc.com/microsites/vspex-ebook/vspex-solutions.htmを参照してください。

容量のサイズ設定

パフォーマンスのサイズ設定を終えたら、ストレージの容量要件を検討します。標準

的な OLTP データベースのサイズ設定はパフォーマンスを中心に検討しますが、最

終設計を終える前に容量要件を確認してください。

容量のサイズ設定は、表 9 の構成に基づいて計算します。

表 9. 容量のサイズ設定

RAIDタイプ

容量の

RAID オー

バーヘッド

パフォーマンスの

RAID オーバーヘッド（ライトペナルティ）

最小ドラ

イブ数 LUN サイズに必要な最小ドライブ数

1/0 1/2 2 4 2×LUN サイズ

5 4/5 4 3 5/4×LUN サイズ

6 4/6 6 4 6/4×LUN サイズ

次の式を使用して、容量に必要なディスク数を計算します。

𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑖𝑠𝑘𝑠 = 𝑇𝑜𝑡𝑎𝑙 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦 𝑛𝑒𝑒𝑑

𝑅𝐴𝐼𝐷 𝑜𝑣𝑒𝑟ℎ𝑒𝑎𝑑 𝑓𝑜𝑟 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦

ディスク数

必要な総容量

容量の RAID オーバーヘッド

注： LUN サイズを計算する際は、データベースサイズの将来の増大を考慮してください。

データベースファイル LUN に少なくとも 10%の容量をリザーブすることをお勧めします。

最終設計

大きい方の値を、パフォーマンス要件と容量要件の両方を満たす最終的なサイズ

設定として使用します。

http://japan.emc.com/data-center-management/storage-configuration-advisor.htm�

https://emc.mitrend.com/�

http://japan.emc.com/microsites/vspex-ebook/vspex-solutions.htm�


32

FAST VPのサイズ設定のベストプラクティス

使用容量全体のごく一部でデータベースの I/O アクティビティの大部分に対応して

いることがよくあります。これはワークロードスキューと呼ばれます。I/O プロファイ

ルを分析すると、ボリュームに対する I/O の 85%が容量の 15%しか使用していない

場合があります。分析結果から判明したアクティブな容量をワーキングセットと呼び

ます。FAST VP や FAST Cache などのソフトウェアでは、ワーキングセットを最高パ

フォーマンスの階層に維持することができます。

FAST VP のサイズ設定のベストプラクティスをいくつか挙げます。

• 理想としては、ワーキングセットを最上位の階層（FC/SAS/フラッシュ）に置き

ます。OLTP ワークロードの標準的なワーキングセットは、データベースファイ

ルの 10～30%です。FAST VP の最上位の階層は、ワーキングセットを最高パ

フォーマンスの階層に移動できるようにサイズ設定します。

• FAST VP パフォーマンス階層ドライブは、さまざまな I/O プロファイルに対応で

きる汎用性を備えています。このため、各プールにパフォーマンス階層ドライ

ブを置くことをお勧めします。

• 大容量ドライブを使用すると、TCO を最適化できます。これは多くの場合、

プール容量の60～80%を占めます。ギガバイトあたりの IOPSが低いプロファ

イルや、シーケンシャルワークロードでは、下位の階層で多数の大容量ドラ

イブを使用できます。

• FAST VP 階層のサイズ設定の前に、I/O スキューを判定することが重要です。

SQL のスキューは変動し、実際の SQL Server プロファイルに依存します。

• ほとんどの VNX サイズ設定タスクでは、パフォーマンス階層（FC/SAS/フラッ

シュ）と容量階層（SATA/NL-SAS）のみを使用します。OLTP ワークロードのス

キューが 85/15 であることを前提に、実際の環境に応じて調整します。

パフォーマンス階層（FC/SAS/フラッシュ）では 85%の I/O と 15%の容量

容量階層（SATA/NL-SAS）では 15%の I/O と 85%のデータ

• VMAX では最大 3 つの階層を置くことができます。OLTP ワークロードの I/Oのホット/ウォーム/コールドスキューが 75/15/10 であることを前提に、実

際の環境に応じて調整します。

SATA では 10%の I/O と 75%の容量

FC では 15%の I/O と 15%の容量

フラッシュでは 75%の I/O と 10%の容量

• 階層とプールを適切にサイズ設定して投資を最大限に活かすためのサポー

トを、EMC プロフェッショナルサービスと認定パートナーが提供します。ツール

と専門技術を活用して、既存の I/O プロファイルを基に階層を構成できるよう

に具体的な提案を行います。




パフォーマンスのサイズ設定 IOPS とディスクの計算は、スキューを含めた RAID グループの場合と同じです。

𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐷𝑖𝑠𝑘𝑠 𝑓𝑜𝑟 𝑡𝑖𝑒𝑟 =

𝑅𝑒𝑎𝑑 𝐼𝑂𝑃𝑆 + (𝑊𝑟𝑖𝑡𝑒 𝐼𝑂𝑃𝑆 × 𝑅𝐴𝐼𝐷 𝑝𝑒𝑟𝑓𝑜𝑟𝑚𝑎𝑛𝑐𝑒 𝑜𝑣𝑒𝑟ℎ𝑒𝑎𝑑) 𝐼𝑂𝑃𝑆 𝑝𝑒𝑟 𝑑𝑖𝑠𝑘

× 𝐼/𝑂 𝑠𝑘𝑒𝑤 𝑓𝑜𝑟 𝑡𝑖𝑒𝑟

階層のディスク数

読み取り IOPS +（書き込み IOPS×RAID パフォーマンスオーバーヘッド）

ディスクあたりの IOPS

×階層の I/O スキュー

注：各階層とも、特定の RAID タイプで近似の論理ドライブ数に切り上げる必要があります。

たとえば、RAID 5（4+1）の場合は、7 台のディスクセットでなく、10 台のディスクセットにし

ます。

容量ベースの計算

次の式を使用して、各階層の容量に基づきディスク数を計算します。

𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑖𝑠𝑘𝑠 𝑓𝑜𝑟 𝑡𝑖𝑒𝑟 = 𝑇𝑜𝑡𝑎𝑙 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦 × 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦 𝑠𝑘𝑒𝑤 𝑓𝑜𝑟 𝑡𝑖𝑒𝑟

𝑅𝐴𝐼𝐷 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦 𝑜𝑣𝑒𝑟ℎ𝑒𝑎𝑑


総容量×階層の容量スキュー

RAID 容量オーバーヘッド

最終設計

各階層の大きい方の値を、パフォーマンス要件と容量要件の両方を満たす最終的

なサイズ設定として使用します。

FAST VP 階層のサイズ設定の詳細については、「EMC Virtual Infrastructure for MS Applications enabled by Symmetrix VMAX and MS Hyper-V White Paper」を参照し

てください。

予測可能な帯域幅性能を得るために、EMC では次の点を考慮したビルディングブロックアプローチを推奨しています。

• ターゲットの帯域幅

• メモリ消費量

• CPU 数

• データベースのサイズ設定

• Tempdb のサイズ設定

OLAPデータベースのサイズ設定の考慮事項


34

設計の原則は次のとおりです。

• 設計では、帯域幅を考慮してからデータベース容量を考慮します。

OLAP データベースの場合は、タイムリーなレポート生成のためにすべてのク

エリーを完了する目標を達成できるように、必要な帯域幅を満たすストレージ

設計にします。

• ディスクパフォーマンスをチェックします。

大量のシーケンシャル読み取り専用 I/O（通常は 64K 以上）のワークロードで

は、IOPS に基づいて所定の I/O サイズの帯域幅を計算します。

𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑖𝑠𝑘𝑠 𝑓𝑜𝑟 𝑡𝑖𝑒𝑟 = 𝐴𝑣𝑒𝑟𝑎𝑔𝑒 𝐼/𝑂 𝑠𝑖𝑧𝑒 𝑥 𝑟𝑒𝑎𝑑 𝑜𝑛𝑙𝑦 𝐼𝑂𝑃𝑆


平均 I/O サイズ×読み取り専用 IOPS

• データベースファイルのストレージ要件を計算します。

次の式を使用して、パフォーマンスに必要なディスク数を計算します。

𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑖𝑠𝑘𝑠 𝑓𝑜𝑟 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦 =𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑑 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦


パフォーマンスのディスク数

必要な帯域幅

ディスクあたりの帯域幅

次の式を使用して、容量に必要なディスク数を計算します。

𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑖𝑠𝑘𝑠 𝑓𝑜𝑟 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦 =𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑑 𝑐𝑎𝑝𝑎𝑐𝑖𝑡𝑦


容量のディスク数

必要な容量

容量の RAID オーバーヘッド

前掲の各計算結果を、特定のRAIDタイプで近似の論理ドライブ数に切り上げ

ます。

階層型ストレージの場合は、スキューに基づき OLTP ワークロードの階層ス

トレージ要件を計算します（「FAST VP のサイズ設定のベストプラクティス」を

参照）。

• Tempdb サイズに推奨比率の 1:5 を使用します。

EMC では、OLAP 環境のすべての 500 GB データベースファイルに 100 GB の

Tempdb を推奨しています。実際の Tempdb サイズは、固有の環境によって

異なります。

OLTP ビルディングブロック設計の詳細については、「データウェアハウスのための

ビルディングブロック設計アプローチ」を参照してください。また、「SQL SERVER 2012 DATA WAREHOUSE EMC VNX5500 HB, VMware vSphere 5, Windows 2012 White Paper」も参考になります。




現在のサーバーテクノロジーでは処理能力のコストが急速に下がっており、ほとん

どの物理サーバー環境は使用率が低下しています。それでも、SQL Server アプリ

ケーションを正しく動作させるには、一部の機能を別のサーバーに置く必要がありま

す。仮想化は、サーバーリソースをわずかな物理サーバーに統合することで、デー

タセンターのリソースを最適化します。これにより、電力消費を削減し、スペースを

節約し、ROI（投資収益率）を向上させ、管理性と柔軟性を高めながら、新しい高可

用性オプションを導入することができます。

Windows SVVP（サーバー仮想化検証プログラム）（MicrosoftのWebサイトから利用

可能）では、SQL Server環境の仮想化でサポートされるEMCストレージに関する情

報が提供されています。

SQL Server 環境の仮想化には、固有のストレージ設計ベストプラクティスがいくつ

か求められます。

EMC VNX ファミリまたは Symmetrix VMAX シリーズストレージでホストされる SQL Server 環境を仮想化すると、VMware vMotion や Microsoft Hyper-V のライブ移行

ツールなどの機能が使用可能になります。これらの機能により、アプリケーションを

停止させることなく、異なるサーバーハードウェアプラットフォーム間で仮想サー

バーを移動できます。

仮想化の一般的なガイドライン

Microsoft SQL Server の仮想化に適用される一般的なガイドラインを挙げます。

• SQL Server の一般的な設計原則に従います。

パフォーマンス、信頼性、容量を考慮して設計します。

ユーザープロファイル（OLTP や OLAP など）を考慮して設計します。

SQL Serverの役割（SAPまたはSharePointの一部）に応じて仮想マシンを

サイズ設定します。

物理的なサイズ設定は、ディスク数や FAST VPの計算にも適用されます。

ロードバランシング、パス管理、I/O パス障害検出用に、Hyper-V または

VMware ESX の物理ホストに PowerPath をインストールすることをお勧め

します。

• 仮想マシンシステムリソースの考慮事項は次のとおりです。

ゲスト数に対応できるように物理サーバーをサイズ設定します。

物理コアと vCPU の数を 1:1 の比率で維持します。

− CPU のオーバーコミットが生じていないことを確認します。

− 仮想マシンのサイズ設定は、物理サーバー上のNUMAノードのサイ

ズを超えないようにします。詳細については、「Using NUMA Systems with ESX/ESXi」を参照してください。

メモリバルーニングを避けるために、SQL Server 仮想マシン用に RAM を

完全にリザーブします。

ハイパーバイザーの制限を理解します（Hyper-V、VMware）。

− 最大メモリ： 1 TB（VMware ESXi 5.1、Windows 2012 Hyper-V）

ハイパーバイザーストレージの考慮事項

http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpwizard.htm�

http://support.microsoft.com/?id=956893�

http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp#using_numa_systems_with_esx_esxi/c_using_numa_systems_with_esx_esxi.html�

http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp#using_numa_systems_with_esx_esxi/c_using_numa_systems_with_esx_esxi.html�

http://technet.microsoft.com/en-us/library/jj680093.aspx�

http://www.vmware.com/pdf/vsphere5/r51/vsphere-51-configuration-maximums.pdf�


36

− 仮想マシンあたりの SCSI LUN の数： 256（VMware ESXi 5.1、Windows 2012 Hyper-V）

− プロセッサの制限

− VMware vSphere 5.1： 32 の vCPU

− Windows 2012 Hyper-V： 64 の vCPU

パフォーマンス向上のために、専用の 64 ビットSQL Serverでゲストに

ラージページを使用（SQL Serverの起動にトレースフラグT834 を使用）

します。

SQL ServerサービスアカウントのLock Pages in Memory権限を有効化し

ます。

• AlwaysOn 可用性グループの考慮事項は次のとおりです。

AlwaysOn 可用性グループのレプリカを複数の物理ホストに分散させて、

物理サーバーに問題が発生した場合の潜在的なダウンタイムを最小限

に抑えます。

AlwaysOn 可用性グループ内の SQL Server 仮想マシンがハイパーバイ

ザーホストベースのフェイルオーバークラスタリングおよび移行テクノロ

ジーの一部である場合は、仮想マシンの移動またはオフライン時に状態

がディスク上に保存/復元されないように構成します。

• VMware では SQL サーバークラスターがサポートされます。

http://support.microsoft.com/kb/920093�


http://technet.microsoft.com/en-us/library/ms190730.aspx�




VMware での FCI クラスタリングと AAG クラスタリングには、表 10 に示す制限

があります。

表 10. Microsoft SQL Server クラスターでの VMware の制限

機能共有ディスク非共有ディスク

VMware 上の Microsoft クラ

スタリング MSCS と共有ディスク

SQL クラスタ

リング SQL AlwaysOn フェイルオー

バークラスターインスタンス

ネットワークロードバラン

シング

SQL AlwaysOn 可用性グループ

vSphere サポートありありありありあり

VMware HA サポートあり1 あり

1 あり1 あり

1 あり1

vMotion DRS サポートなしなしなしありあり

Storage vMotion サポートなしなしなしありあり

MSCS ノードの制限 2（5.1） 5（5.5）

2（5.1） 5（5.5）

2（5.1） 5（5.5）

OS/アプリケー

ションと同じ OS/ アプリケー

ションと同じ

ストレージプロトコルサポート

FC ありありありありあり

ゲスト内 OS iSCSI

ありありありありあり

ネイティブ iSCSI

あり2 あり

2 あり2 ありあり

ゲスト内 OS SMB

あり3 あり

3 あり3 該当せず該当せず

共有ディスク

FCoE あり4 あり

4 あり4 ありあり

RDM ありありあり該当せず該当せず

VMFS あり5 あり

5 あり5 該当せず該当せず

Microsoft製品でのVMwareの制限の詳細については、VMwareのナレッジベースを参照してください。

• HA/DR の考慮事項：状態を保存して移行する移行テクノロジーを無効化しま

す。常にライブ移行するか、仮想マシンを完全にシャットダウンします。

• ハイパーバイザーベースの自動チューニング機能を無効化します。

1 DRS 親和性/非親和性規則を使用する場合。 2 vSphere 5.5 のみ。 3 Windows Server 2012 フェイルオーバークラスタリングのみ。 4 vSphere 5.5 ではネイティブ FCoE をサポート。vSphere 5.1 Update 1 および 5.0 Update 3では、Cisco CNA カード（VIC 1240/1280）による 2 ノードクラスター構成とドライバーバー

ジョン 1.5.0.8 が Windows 2008 R2 SP1 64 ビットゲスト OS でサポートされる。詳細につい

ては、VMware ハードウェア互換性ガイドで Cisco UCS VIC1240 と Cisco UCS VIC1280 を

参照。 5 CIB（Cluster in a Box）構成でのみサポート。詳細については、VMwareのナレッジベースの

記事で「Considerations for Shared Storage Clustering」セクションを参照。

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=103795�

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=103795�

http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=21077�

http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=21080�

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1037959#consid�


38

Tier 1 のミッションクリティカルな SQL Server インスタンスで最適なパフォーマンスを

得るには、次のガイドラインに従います。

• 物理環境と同じガイドラインに従って、データの LUN とログの LUN を分離し

ます。

• 各VMware ESXiまたはHyper-Vサーバーにストレージへのパスが少なくとも4つ（HBA が 2 つ）とポートが合計 4 つあることを確認します。VNX の両方の SPまたは VMAX の複数のフロントエンドダイレクターにストレージアレイへの接

続があることを確認します。

• SQL Server 用のストレージは、ゲスト OS（VHD/VHDXS または VMDK）用の物

理ストレージとは別のディスクに配置します。

Tier 2 以下のサービスレベルインスタンスで許容できるパフォーマンスを得るには、

次のガイドラインに従います。

• 導入のしやすさが主な焦点で、パフォーマンスは二次的である場合は、VM OS LUN の仮想ハードドライブが LUN をハイパーバイザーレベルで共有でき

（vSphere のデータストアまたは Hyper-V の VHD/ VHDX のホストレベル LUN）、SQL Server のデータベース LUN とログ LUN が使用可能です。

• HA/DR が特定の環境で許容可能なレベルである場合は、複数の仮想マシン

またはデータベースが LUN をハイパーバイザーレベルで共有できます

（vSphereのデータストアまたはHyper-VのVHD/VHDXのホストレベルLUN）。

Microsoft では、SQL Server の仮想化に関して追加情報と推奨事項を提供してい

ます。

VMware vSphere環境のベストプラクティス

SQL Serverを VMware VSphere仮想環境に導入する際の一般的なベストプラクティ

スをいくつか挙げます。

• アプリケーション仮想マシンを共有ストレージに展開します。これにより、

vMotion、HA、DRS などの vSphere 機能を使用できます。

• パーティション配置を確実に行うために、vCenter から VMFS ファイルシステ

ムを作成します。

• ハイパーバイザーのオーバーヘッドを考慮して CPU要件に5%を加算します。

• データストレージに VMFS を使用する場合は、 VMDK ファイルを

eagerzeroedthick としてフォーマットします（データベースファイルおよびロ

グファイル用）。

• 複数の PVSCSI アダプターを使用し、ターゲットデバイスを均等に分散させ

ます。

VMware PVSCSI（準仮想化 SCSI）アダプターは、スループットを高めて CPU の

使用を抑える高性能ストレージドライバーです。PVSCSI アダプターは、ハード

ウェアまたはアプリケーションで高 I/O スループットを必要とする SAN 環境に

最適です。




図 5 に、ドライバーの効率性を高めるために SCSI コントローラータイプを準

仮想化に変更した例を示します。デフォルトの SCSI コントローラードライバー

は LSI Logic SAS です。すべての使用可能な SCSI ドライバーに LUN が分散さ

れます。

図 5. SCSI コントローラー

• VMware ESXi サーバーの HBA のキューの深さを大きくすると、VMware ESXiサーバー上の HBA カードのスループットが向上します。HBA のキューの深さを64 に設定することで向上が見られます（デフォルトは VMware ESXi 5.0 では 32、VMware ESXi 5.1 では 64）。結果は環境によって異なる場合があります。

注：

• 関連する LUN に専用の VMware ESXi サーバーポートがある場合は、HBA ポートに構成可能な最高のキューの深さは VMware ESXi 5.0 で 128、VMware ESXi 5.1 で

256 です。 • 複数の仮想マシンを含む VMware ESXi 5.0 サーバーの場合は、VMware の高度なオ

プションのDisk.SchedNumReqOutstanding 値をキューの深さと同じにする必要があります。

VMware ESXiサーバー構成の詳細については、VMwareのナレッジベースのWebサイトと「VMware ESX Scalable Storage Performance」マニュアルを参照してください。

VMFS と RDM の比較 VMFSとRDMのパフォーマンスは概してほぼ同等ですが、RDMが若干上回ります。VMFSは、クラスタリングとスナップショットレプリケーションに固有の要件がなければ、ほとんどの環境で使用できます。詳細については、VMwareのWebサイトを参照してください。

表 11 に、SQL Server の VMware 環境での VMFS と RDM の比較を示します。

表 11. VMFS と RDM の比較

VMFS RDM

ストレージ統合に優れる。VMFS LUN ごとに複数の仮想ディスクと仮想マシンを使用できるが、LUN ごとに単一の仮想マシンもサ

ポート

仮想マシンと LUN の 1:1 のマッピングを強制

LUN の仮想マシンを統合。VMware ESX のLUN 制限の 255 に達することはまずない

VMware ESX の LUN 制限の 255に達する可能性が高い

パフォーマンスの管理： LUN 内の全仮想マシンの合計 IOPS は LUN の IOPS レーティン

グよりも低くなる

他の仮想マシンの IOPS の影響を受けない

LUN サイズに制限がある（vSphere 5.1 は 2 TB、vSphere 5.5 は 62 TB）

LUN サイズに制限がない

http://kb.vmware.com/kb/1267�

http://kb.vmware.com/kb/1267�

http://www.vmware.com/files/pdf/scalable_storage_performance.pdf�

http://www.vmware.com/files/pdf/performance_char_vmfs_rdm.pdf�


40

VMFS RDM

RDM（raw デバイスマッピング）を必要とする場合を除き、ほとんどの環境で良好に機能

SQL フェイルオーバークラスタリングなどのクラスタリングに必要（定数ディスク）

バックアップやスナップショットなどの SAN管理タスクに必要

Microsoft Hyper-V

SQL Server のストレージオプション VHDX は、Windows Server 2012 Hyper-V で導入された新しい仮想ハードディスクフォーマットです。ストレージ容量とデータ保護が向上しています。

VHD は、Windows Server 2008 Hyper-V の仮想ハードディスクです。Windows Server 2012 Hyper-V の VHDX に変換が可能です。

SQL Server のデータベースファイルとログファイルは、VHD または VHDX に置くこと

ができます。VHDX を CSV（クラスター共有ボリューム）に置くと、Hyper-V の HA/DR機能を利用できます。

CSV は、フェイルオーバークラスタリングの機能です。Windows Server 2008 R2 で

Hyper-V 用に初めて導入されました。CSV は NTFS（NT ファイルシステム）ボリュー

ムを含む共有ディスクであり、Windows Server フェイルオーバークラスター内のす

べてのノードによる読み取り/書き込み操作でアクセスが可能です。

パススルーディスクは、ハイパーバイザーレイヤーをバイパスすることができ、基

盤となるディスクのパフォーマンスを最大化します。

NPIV（N_Port ID 仮想化）は、Windows 2012 で導入された Hyper-V 仮想ファイバーチャネル機能です。仮想マシンからファイバーチャネルストレージへの接続を可能

にします。NPIV により、仮想化ワークロードで既存のファイバーチャネルへの投

資を活かすことができます。また、仮想 SAN、ライブ移行、MPIO（マルチパス I/O）など多くの関連機能もサポートしています。

この機能は、Hyper-V レベルの保護と容易な移行により、パススルーディスクに近

いパフォーマンスを提供します。

Hyper-V の仮想ファイバーチャネルにより、ゲスト OS は仮想マシンに関連づけられ

た標準の WWN（World Wide Name）を使用することで仲介なしで SAN にアクセスが

可能です。Hyper-V ユーザーは、ファイバーチャネル SAN を使用して、SAN LUN へ

の直接アクセスを必要とするワークロードを仮想化できるようになりました。ファイ

バーチャネル SAN では、共有ファイバーチャネルストレージに接続された仮想マ

シンのゲスト OS 内でフェイルオーバークラスタリング機能を使用するなど、新しい

シナリオでの運用も可能です。

EMCストレージアレイの高度なストレージ機能により、一部の管理タスクをホストか

らSANにオフロードできます。仮想ファイバーチャネルは、Windowsソフトウェア仮

想ハードディスクスタックへの代替のハードウェアベースI/Oパスを提供します。こ

のため、ハードウェアスナップショットなどの高度な機能をHyper-V仮想マシンから

直接使用することが可能です。Hyper-V仮想ファイバーチャネルの詳細について

は、Microsoft TechNetを参照してください。

http://en.wikipedia.org/wiki/Failover_Clustering�

http://en.wikipedia.org/wiki/Windows_Server_2008_R2�

http://en.wikipedia.org/wiki/Hyper-V�

http://technet.microsoft.com/en-us/library/hh831413.aspx�




SQL Server 2012 で導入された高可用性および災害復旧機能である AAG（AlwaysOn 可用性グループ）では、WSFC（Windows Server フェイルオーバークラスタリング）を必要とします。AlwaysOn 可用性グループは、SQL Server FCI（フェイルオーバークラスタリングインスタンス）には依存しません。

SQL Server FCI（フェイルオーバークラスタリングインスタンス）では、SQL Server のデータベースファイルとログファイルはクラスター内のすべてのノードで共有されるため、これらのファイルをホストするストレージ LUN はすべてのノードからアクセス可能である必要があります。そのためには、すべての LUN を構成し、同時にクラスター内のノードへのゾーニングを行います。特定のデータベース LUN またはログLUN には、SQL Server インスタンスをアクティブに実行しているノードからのみアクセスできます。

データベースのプライマリコピーとセカンダリコピーは AAG（AlwaysOn 可用性グループ）内のストレージを共有しませんが、クラスター内の各ノードには独自のストレージの構成とゾーニングが必要です。AlwaysOn 可用性グループのセカンダリノード上のデータベースコピーがプライマリコピーから独立した「読み取り可能コピー」として構成されている場合は、そのコピーへのアクセスが可能です。これを利用することで、セカンダリコピーのレポート機能をプライマリコピーからオフロードできます。

図 6 に、FCI と AAG の違いを示します。

図 6. FCI と AAG の違い

VMware 環境での SQL Server クラスタリングサポートの制限については、表 10 を

参照してください。

EMC Symmetrix VMAX シリーズは、データセンター向けのハイエンドストレージです。

このシステムは、2 PBに拡張可能で、他のアレイに比べてはるかに小さな設置面積

でより多くのワークロードを統合できます。EMC Symmetrix Virtual Matrix アーキテク

チャは、パフォーマンス、容量、接続性をオンデマンドでシームレスに拡張して、す

べてのアプリケーション要件に対応します。このシステムは、フラッシュドライブ、

ファイバーチャネル、SATA ドライブに加えて、FAST VP による最適化された自動階

層化をサポートします。また、オープンシステム、メインフレーム、IBM i サーバーホストを含む仮想サーバーと物理サーバーもサポートします。

SQL Serverクラスタリングのストレージの考慮事項

Symmetrix VMAXストレージ設計ガイドライン


42

VMAXシリーズハードウェア設計の考慮事項

VMAX 上の SQL Server の設計にあたり、最も重要な考慮事項は次のとおりです。

• LUN を作成する場合は、大容量のハイパーボリュームを使用してその数を減らすことで、パフォーマンスを向上できます。

• サーバーごとに少なくとも 2 つの HBA を使用します。それぞれの HBA は、（可能であれば複数の VMAX エンジンにわたって）少なくとも 2 つのダイレクターポートに接続します。

• シック LUN とシン LUN の場合は、ストライピングされたメタボリュームを使用します。

仮想プロビジョニングの考慮事項とベストプラクティス

Microsoft Windowsの「シンフレンドリー」なNTFSフォーマット機能と、Microsoft SQL Server のファイルの瞬時初期化メカニズムにより、SQL Server は EMC Symmetrix の仮想プロビジョニングのメリットを最大限に活かすことができます。このため、Symmetrix VMAX 上の SQL Server にはシン LUN プールの使用をお勧めします。VMAX 上ではシンデバイスのパフォーマンスは通常の（シック）デバイスのパフォーマンスと同等であり、シンプールを使用することにより、初期ストレージ要件を引き下げることができます。

EMC Symmetrix VMAX で仮想プロビジョニングを使用する Microsoft SQL Server の構成のベストプラクティスを次にまとめます。

• システムでストレージの過剰な割り当てが多い場合は、仮想プロビジョニングを使用します。

• 時間とともに急激な増加が予測されてもダウンタイムが限定的である場合は、仮想プロビジョニングを使用します。

• ファイルの瞬時初期化を使用して SQL Server データベースを構成します（SQL Server 2012 のデフォルト）。

• シンプールがスペース不足にならないようにプールを監視するために、シンプール使用率閾値ツールの使用を検討します。

次の環境では、仮想プロビジョニングを避けます。

• シンデバイスの共通プールからの共有割り当てがお客様の要件を満たさないシステム。

• 大量の削除済みスペースを回収できないシステム。

• 初期化されていないブロックへの書き込みのために時々発生するレスポンスタイムの増加（約 1 ミリ秒）を許容できないシステム。

VMAXストレージシステムでのFAST VPの考慮事項とベストプラクティス

FAST VP を使用すると、SQL Server の管理を軽減し、容量と I/O の問題を迅速に解決することができます。特にOLTPワークロードの場合、FAST VPはストレージ使用を効率化し、アクセス頻度の最も高いデータを最上位のパフォーマンス階層に移動します。

FAST VP を使用する場合の考慮事項とベストプラクティスをいくつか挙げます。

• ログの書き込みはほとんどがシーケンシャル書き込みで、フラッシュデバイスのメリットがないため、ログ LUN をフラッシュ階層に置くのは避けます。

• FAST VP では最初にデータベース LUN を FC 階層に固定し、ホットデータを上位の階層に移動する必要がある場合に対応できる十分なストレージ容量を準備します。




• FAST VP を AlwaysOn 可用性グループとともに使用する場合は、同じデータベースの可用性グループのコピーを異なるプールに置くことで可用性を高めます。

• ログは、データファイル LUN と同じストレージプールに配置する場合に特定の階層に固定可能です。

• サイズ設定は「FAST VP のサイズ設定のベストプラクティス」に従って行います。

注：スキュー比は、特定の SQL Server プロファイルに応じて変わります。

EMC VNXファミリは、業界をリードする革新技術とエンタープライズ機能をファイルおよびブロックストレージ向けに使いやすく拡張性に優れたソリューションで提供します。この次世代ストレージプラットフォームは、強力で柔軟性の高いハードウェアと高度な効率性、管理、保護ソフトウェアを組み合わせて、現代の企業の厳しいニーズに対応します。

VNX ファミリには、エントリーレベル環境の IT 管理者向けの VNXe シリーズと、中堅企業および大企業の高パフォーマンスおよび高拡張要件を満たすように設計された VNX シリーズがあります。

EMC FAST Suite は、SQL Server 環境で増大するパフォーマンスと容量の要件を柔軟に管理できるようにする高度なソフトウェア機能です。EMC FAST Suiteでは、SSDドライブ、SAS、NL-SASストレージ構成を使用して、パフォーマンスとストレージの要件にバランスよく対応できます。FAST Suite には、FAST Cache と FAST VP が含まれます。

アプリケーションプロテクションスイートは、アプリケーションコンシステントコピーを自動で作成し、定義済みのサービスレベルへのリカバリを可能にします。ユーザーの役割により、すべてのアプリケーションリカバリポイントに対する可視性を向上させつつ、セルフサービスのコピー管理を実現できます。アラートが自動的に生成されるため、リカバリギャップを迅速に解決できます。統合されているレポート作成機能により、保護ポリシーへの準拠を確認することができます。サポートされるアプリケーションは、Oracle、Microsoft SQL Server、SQL Server、SharePoint、VMware、Hyper-V などです。アプリケーションプロテクションスイートには、次のソフトウェアが含まれます。

• VNX シリーズ向け： Replication Manager、AppSync、Data Protection Advisor for Replication Analysis

• VNXe シリーズ向け： Replication Manager

FAST Cacheの考慮事項とベストプラクティス

EMC FAST Cache は、アクセス頻度の高いデータを SSD にマッピングして DRAMキャッシュの機能を拡張することで、ストレージシステムキャッシュを拡大します。FAST Cache の容量は 73 GB から 2 TB までサポートされ、既存のストレージシステムで使用できる DRAM キャッシュよりもはるかに大容量です。ユーザーアプリケーションが特定のデータチャンクに頻繁にアクセスする場合は、そのチャンクがハードディスクドライブからフラッシュドライブにコピーされて FAST Cache に自動的にプロモートされます。同じデータチャンクへの以降のアクセスはフラッシュドライブのレスポンスタイムで処理されるため、ストレージシステムのパフォーマンスが大きく向上します。

VNXストレージ設計ガイドライン


44

FAST Cache は、ワーキングセットが小規模で I/O が集中するランダムワークロード

に最も適しています。この種のプロファイルの標準的な OLTP データベースは、FAST Cache を使用することでパフォーマンスとレスポンスタイムを大きく改善できます。

SQL Server データベースファイルグループを監視し、このようなデータが置かれた

非常にアクティブなストレージプールに対して FAST Cache を有効にしてください。

FAST Cache の設計概念や計画/使用ガイドラインの詳細については、EMC オンラ

インサポート Web サイトにある「EMC FAST Cache: a Detailed Review」を参照してく

ださい。

テストの結果では、FAST Cache の導入により、バックエンドで同数のハードディスクドライブを使用した場合に、SQL OLTP ワークロードの TPS（秒あたりのトランザク

ション）が 300%向上しています。

EMC FAST Cache を使用したソリューションの構築方法の詳細については、EMC FAST Cache を使用したソリューションの構築方法の詳細については、EMC オンラインサポートにある「EMC Unified Storage for Microsoft SQL Server 2008: Enabled by EMC CLARiiON and EMC FAST Cache Reference Architecture」を参照してください。

FAST Cache を使用する場合は、キャッシュをフル活用できるように、キャッシュの

ウォームアップに十分な時間をかけます。OLTP ワークロードを使用して EMC が行っ

たテストでは、FAST Cache のウォームアップに 1～2 時間かかりました。

ウォームアップ時間は、バックエンドハードディスクドライブのタイプと数、FAST Cache のサイズ、ワーキングセットのサイズによって異なります。EMC Unisphere に

は監視のための FAST Cache カウンターがいくつかあり、これらを使用して最適な使

用率とウォームアップ時間を知ることができます。詳細については、EMC の Web サ

イトにある「EMC CLARiiON, Celerra Unified, and VNX FAST Cache White Paper」を参

照してください。

FAST VPの考慮事項とベストプラクティス

業界アナリストによると、運用データベースデータの 60～80%は非アクティブに

なっており、この値はデータベースサイズの拡大とともに増加します。低コストで大

容量の回転ドライブは非アクティブデータに理想的な選択で、アクセス頻度の高い

データには高パフォーマンスドライブが適しています。手動でデータを分類して適切

な階層に保存するのは複雑で困難な作業であり、通常はデータの移動にダウンタ

イムが必要になります。

EMC FAST VP は自動的に、アクセス頻度の高いデータをプール内の高速な物理スト

レージに移動し、アクセス頻度の低いデータをプール内の低コストの物理ストレージ

に移動します。

FAST VP を使用すると、次のことが可能になります。

• システム使用率が高くなることが分かっている期間のホスト I/O 要求への影

響を抑えるために、データを FAST VP で移動できるタイミングを制御する。

• 高パフォーマンスの物理ドライブに新たに投資することなく、システム全体の

パフォーマンスを高める。

• FAST VP をストレージシステム上の任意またはすべてのプールベースデータ

ベース LUN に適用する。




• ログ LUN をデータベース LUN と同じプールに配置する必要がある場合に、こ

れらの LUN を SAS 階層に固定して、これらの LUN のデータ再配置を無効に

する。

• OLTP ワークロードの場合に、Tempdb を SAS 階層に固定して、これらの LUNのデータ再配置を無効にする。

• FASTポリシーを［上位階層の次に自動階層を開始］（デフォルト）に設定する。

SQL Server での FAST VP の使用の詳細については、EMC オンラインサポート Webサイトにある「 Understanding Microsoft SQL Server OLTP Performance Characterization for EMC VNX Series」を参照してください。

LUN がオンラインであり、ホストアクセスが可能な状態にある間は、FAST VP はバッ

クグラウンドで動作します。データ移動速度を制御することで、システム全体のパ

フォーマンスへの影響を最小限に抑えられます（再配置レートは、高、中、低に設定

可能）。

FAST CacheとFAST VPの違い

FAST Cache はランダムアクセスパターンやバーストしやすいデータのパフォーマン

スを直ちに向上させるのに対し、FAST VP はストレージシステムで非アクティブな

データを低コストのストレージ階層に移動させます。FAST Cache の動作は 64 KB 単

位で、FAST VP の動作は 1 GB チャンクです。FAST VP では、シンメタデータとアクセ

ス頻度の最も高いユーザーデータの両方を上位階層にプロモートできます。一方、

FAST Cache では、メタデータをプロモートすることでシン LUN のパフォーマンスを向

上させます。

FAST Cache と FAST VP をともに SQL Server データベースで機能させると、パフォー

マンスを改善し、容量使用率を高め、電力と冷却の要件を下げることができます。

FAST Cache と FAST VP を使用する場合のベストプラクティスを挙げます。

• 使用可能なフラッシュドライブの数が限られている場合は、フラッシュドライ

ブを使用して最初に FAST Cache を作成します。

FAST Cache はグローバルキャッシュであり、ストレージシステム内の複

数のプールにメリットがあります。

FAST Cache で使用するのが 64 KB チャンクであるのに対し、FAST VP は 1 GB チャンクを使用するため、変化する使用パターンに対応してパフォー

マンスを向上させ応答時間を短縮できます。

• 特定のプールに対してフラッシュドライブを使用して FAST VP パフォーマンス

階層を作成することで、ミッションクリティカルデータのパフォーマンスを向上

させます。FAST VP 階層はストレージプール専用であり、同じストレージアレ

イ内の他のストレージプールには共有されません。


46

XtremSFの概要

XtremSF は、薄型の単一サーバーフラッシュハードウェアカードです。あらゆる

ラックマウント型サーバーの単一PCIeスロットの電源エンベロープ内に搭載でき、

eMLC と SLC の幅広い処理能力に対応します。導入方法としては次の方法があり

ます。

• 高パフォーマンスを提供するサーバー内のローカルストレージとして導入する

• XtremSW Cacheサーバーキャッシュソフトウェアと組み合わせて導入し、ネッ

トワークストレージアレイのパフォーマンスを改善するとともに、重要なアプリ

ケーション環境で必要とされる保護レベルを維持する

XtremSFの設計のベストプラクティス

MLC および SLC NAND の XtremSF は、ビットコストを抑えて高パフォーマンスを実

現する場合（MLC）と、より高いパフォーマンスと持続性を追求しコストはそれほど

重視しない場合（SLC）という、異なるタイプのアプリケーションに対応する機能を

提供します。

要求の高いデータウェアハウスまたは OLAP 環境と、場合によっては Tempdb の使

用量が大きいOLTP環境では、XtremSFを Tempdbストレージとして使用することで、

Tempdb の競合を減らして、帯域幅を向上できます。

XtremSFは、読み取り/書き込み比が70～90%でSQL Serverレベルのデータ保護を

備えた SQL Server データベースに最適です。容量の大きい XtremSF カードでは、

データベース全体を単一の XtremSF カードに保存できます。

ローカル XtremSF を活用できる用途については、「EMC XtremSF Performance Acceleration for Microsoft SQL Server 2012 White Paper」を参照してください。

XtremSW Cacheの概要

XtremSW Cache は、フラッシュ PCIe カード用の EMC サーバーキャッシュソフトウェ

アです。XtremSF にデータを保存してキャッシュとして使用できるようにします。

XtremSW Cache は、次の基本原則に従って設計されています。

• パフォーマンス：レーテンシーの短縮とスループットの向上によって、アプリ

ケーションパフォーマンスを大幅に向上させる。

• インテリジェンス： FAST アレイベースのテクノロジーをサーバー内にまで拡張

することで、インテリジェンスの新たな階層を追加する。

• 保護： EMC ネットワークストレージの高可用性と災害復旧機能を活用し、優

れたパフォーマンスと保護機能を実現する。

XtremSW Cache の効果が最も大きい SQL Server ワークロードは、次のとおりです。

• 読み取り/書き込みワークロード比が高いアプリケーション。同じチャンクの

データが頻繁に読み取られて書き込みはほとんどない場合に、最大の効果

が得られます。

• ワーキングセットが小規模なアプリケーション。最大限のパフォーマンス向上

が可能です。

サーバーフラッシュの考慮事項




• 主にランダム読み取りワークロードのアプリケーション。使用可能な XtremSW Cache サイズに対してアクティブデータセットが非常に大きい傾向があるシー

ケンシャルワークロード（データウェアハウジングなど）では、XtremSW Cache の効果はほとんどありません。

• I/O の並行性が高い（複数の I/O スレッドを使用する）アプリケーション。

• 元の I/Oサイズは小さく（8 KB以下）、生成する I/Oサイズは大きいアプリケー

ション。XtremSW Cache ソフトウェアでは、ページサイズや最大 I/O サイズな

どの機能を調整できるため、このような環境で特定の I/O を高速化してその

他（バックアップ読み取り I/O など）は無視することができます。

XtremSW Cache は読み取り処理を高速化しますが、すべての書き込み処理はスト

レージアレイに書き込まれ、XtremSW Cache の影響を受けません。多くの場合、

XtremSW Cache が読み取り処理をオフロードすると、副次効果としてアレイがより多

くの書き込み処理に対応できるようになり、書き込みスループットのパフォーマンス

が向上します。XtremSW Cache は、データウェアハウジング、ストリーミングメディ

ア、ビッグデータアプリケーションなどの書き込み集中型アプリケーションやシー

ケンシャルアプリケーションには適さない場合があります。

まとめると、XtremSF は読み取りと書き込みの高速化、一時データ、大規模なワー

キングセット向けのローカルストレージとして使用でき、XtremSF と XtremSW Cache を併用すると、データ保護を必要とする小規模なワーキングセットのミッ

ションクリティカルデータの読み取りを高速化できます。

XtremSW Cacheの設計のベストプラクティス

ベースのストレージ構成に基づいて、XtremSW Cache による高速化を必要とする

SQL Server を決めます。

標準的な SQL Server OLTP 環境では次のようになります。

• キャッシュに収まる小規模なワーキングセットのミッションクリティカルデータ

の読み取りを高速化するには、XtremSF と XtremSW Cache を併用します。

• SQL Server での XtremSW Cache による初期メリットの分析には、XtremSW Cache Performance Predictor を使用します。

• 読み取りの多いデータベースデータファイルの LUN は通常、ワークロードが

大きく、高い読み取りスキューが発生するため、XtremSW Cache に適してい

ます。

• SQL Server OLTP データファイルは、ランダムリードが常に発生し、全体的な

トランザクション時間に影響します。また、データファイルでは、チェックポイン

ト操作の間に書き込みアクティビティの突発的な増加も常時発生します。

XtremSW Cache を使用して読み取りをキャッシュし、EMC アレイで I/O ワーク

ロードが発生しないようにすると、アレイは書き込みの突発的な増加を迅速に

処理でき、トランザクションの読み取りの遅延を防ぐことができます。

• OLTP データベースのログ LUN と Tempdb LUN は書き込みが多く、通常は

XtremSW Cache によるメリットはありません。

• SQL Server AlwaysOn 環境では、特定のパフォーマンス要件で XtremSW Cache を使用するメリットがない限り、セカンダリデータベースを高速化する

必要はありません。


48

• SQL Serverデータベースの大量の I/Oに対応するために、XtremSW Cacheのページサイズを 64 KB に設定します。

• XtremSW Cache を導入した後でワークロードが増加しないと予想される場合

は、メモリや CPU などの追加システムリソースは必要ありません。

• 冗長性が必要な場合は、サーバーインフラストラクチャ内に XtremSF カードを

少なくとも 2 つ配置します。

• 重複排除は一般に SQL Server の I/O パターンにメリットはありません。

仮想化環境におけるXtremSW Cacheの設計のベストプラクティス

仮想化環境での XtremSW Cache の設計のベストプラクティスをいくつか挙げます。

• 冗長性が必要な場合は、ハイパーバイザーサーバーインフラストラクチャ内

に XtremSF カードを少なくとも 2 つ配置します。

• vMotionが必要な場合は、vMotion の動作時に残りのサーバーと XtremSF の容量ですべての仮想マシンの XtremSW Cache 設定に対応できるように、

XtremSF の容量と配置を決定します。

たとえば、10 台の仮想マシンで 100 GB の XtremSW Cache を使用して合計 1 TB の XtremSW Cache 容量を必要とする構成の場合は、vMotion の動作時に、

XtremSW Cache を使用する仮想化クラスター内の残りのサーバーは少なくと

も 1 TB のキャッシュ容量で動作できる必要があります。

• アプリケーションが各仮想マシンの XtremSF カード容量をわずかしか必要とし

ない場合は、そのアプリケーションを実行する仮想マシン間で同じ物理カー

ドを共有でき、同じ VMware ESXi ホストまたは Hyper-V ホストに配置するのが

最適です。

• 特定のアプリケーションが XtremSF カードの使用可能容量をすべて必要とす

る場合は、ホストでそのカードを仮想マシン専用にする必要があります。

• 必要に応じて複数の XtremSF カードを同じサーバーにインストールできます。

• 複数の XtremSFカードを同じハイパーバイザーに構成することで、仮想マシン

用の複数のキャッシュデバイスを作成できます。

• スプリットカード機能を使用するように選択したアプリケーションワークロード

では、カードの一部を仮想マシンのキャッシュ用に構成し、他の部分を一時

データストア用の XtremSF ストレージとして構成できます（Tempdb ストレージ

領域などに使用）。

• この構成では、仮想マシンはそのサーバーのローカルストレージに依存する

ため、仮想化環境における仮想マシンの移植性に関する追加の考慮事項が

発生します。

• フラッシュキャッシュの高速化が必要な仮想マシンの XtremSW Cache vDiskの最小サイズは 20 GB です。

• XtremSW Cache による高速化が必要な VHDX のみを、XtremSW Cache で構

成された LUN に配置します。XtremSW Cache で構成された LUN 上のすべて

の VHDX が高速化されます。




XtremSFとXtremSW Cacheのサイズ設定の考慮事項

サイズ設定に関する推奨事項は、アプリケーションのタイプごとに異なります。環境

が異なるため、実装も異なります。次に挙げるのは、一般的なデータベースワーク

ロードとアプリケーションワークロードを使用して行われたテストに基づく各アプリ

ケーションの推奨最小構成です。ほとんどの場合、キャッシュのサイズがワーキン

グセットのサイズ以上になるまでは、XtremSW Cache を追加することでパフォー

マンスが向上します。

特定のアプリケーションと環境に最も適したサイズ設定を行うには、要求されるパ

フォーマンスレベルとコストの両方を考慮してください。

表 12 に、各アプリケーションに推奨されるXtremSW Cacheの構成を示します。

キャッシュ/ストレージ比 6

表 12. 各アプリケーションに推奨されるキャッシュ

は、データベースのアクティブワーキングセットに大きく依

存し、実際の使用状況に応じて変わります。これらの推奨事項は、制御された環境

でのテストに基づいています。これらの推奨事項は、制御された環境でのテストに

基づいています。

アプリケー

ションデータベースタイプ

読み取り/ 書き込み比

推奨される XtremCache/ストレージ比

率

SQL Server OLTP 90:10 1:10

SQL Server OLTP 70:30 1:5

SharePoint コンテンツ/ クロール

100%読み取り 1:5

SQL Server OLAP 100%読み取り 1:5（XtremSF の Tempdb 対データベースサイズ）

データウェアハウス環境のような SQL Server OLAP アプリケーションでは、（単独ま

たはスプリットカードモードの）eMLC XtremSF を Tempdb として使用することでクエ

リーのパフォーマンスを向上できます。1 TB のデータベーススペースごとに少なくと

も 200 GB の Tempdb スペースを検討してください。

XtremSF と XtremSW Cache の設計と構成に関するすべてのベストプラクティスにつ

いては、「EMC VSPEX 環境での EMC XtremSF と EMC XtremSW Cache 設計ガイド」を参照してください。この文書は VSPEX 用ですが、設計の原則とベストプラクティスは

ほとんどの環境に適用できます。

6 XtremSW Cache/ストレージ比は、キャッシュとデータベースストレージのサイズの比率。こ

の比率が 1:10 の場合は、10 GB のデータごとに少なくとも 1 GB の XtremSW Cache を用意

する。


50

ESI（EMC Storage Integrator）for Windows Suite は、Microsoft Windows および

Microsoft アプリケーション管理者用のツールセットです。これには、ESI for Windows、ESI PowerShell Toolkit、ESI Service、ESI Management Packs for SCOM（System Center Operations Manager）、ESI Service PowerShell Toolkit が含まれて

います。

• ESI for Windows

Microsoft Windows のブロックおよびファイルストレージの表示、プロビジョ

ニング、監視、管理ができます。ESI は、EMC Symmetrix VMAX シリーズと

EMC VNX シリーズをサポートします。また、Microsoft Hyper-V、Citrix XenServer、VMware vSphere で実行される Windows 仮想マシンのストレージプロビジョニングと検出もサポートします。

ESIは、図 7に示すように、Windowsのストレージ管理を簡素化し、ストレージ

構成にベストプラクティスを自動的に適用して Windows のストレージ導入を

容易にします。

図 7. ESI for Windows によるストレージ管理

• ESI Management Packs for SCOM 2012

ストレージインフラストラクチャを単一のユーザーインターフェイスで管理でき

ます。SCOM 2012 の統合により、Windows 管理者は System Center 2012 か

ら構成可能なパラメーター閾値を使用して、ストレージ資産の検出、物理オブ

ジェクトと論理オブジェクトのマップ、アラートの管理、稼働状態のロールアッ

プを行えます。

• EMC PSToolkit（PowerShell Toolkit）

Windows 管理者およびユーザーがストレージシステムの管理に利用できる

強力なユーティリティです。ストレージシステム管理者は PSToolkit のコマンド

レットを使用して、ストレージシステム情報を確認し、ストレージプール、スト

レージグループ、ストレージボリュームの作成と削除や利用可能なホストサーバーへのマップとマスクを行えます。このツールキットにより、管理者は

自動化スクリプトを効率的に作成して、仮想マシンをユーザーのニーズに応じ

て動的に作成/削除できます。

ESIによる自動化




SQL Serverの保護 Microsoft は、SQL Server 2012 で AlwaysOn 可用性グループ機能を導入して、SQL Serverのネイティブな高可用性およびデータ保護機能をデータベースレベルで強化

しました。EMC では、AG を補完して SQL Server 環境でのデータベース、サーバー、

サイト全体の消失の防止を強化するデータ保護製品およびオプションを多数用意し

ています。このセクションでは、SQL Server 2012 のさまざまな高可用性および災害

復旧オプションについて説明します。

EMC ストレージシステムには、SQL Server のデータベース保護と高可用性のための

多様な機能があります。EMC の TimeFinder®、SRDF、VNX スナップ/クローンなどのレ

プリケーションテクノロジーは、業界最高クラスのデータ保護を可能にします。継続

的な保護を提供するRecoverPointと、AppSyncや Replication Managerなどのレプリ

ケーション管理ツールは、SQL Server をアプリケーションレベルで保護します。

EMCテクノロジーを活用した SQL Serverのバックアッププロセスでは、次のことが可

能です。

• バックアッププロセスにおける本番システムへの影響を減らす。

• 整合性のあるバックアップイメージを作成する。

• SQL Server のバックアップ/リカバリプロセスを統合する。

ハードウェア障害やソフトウェア障害の発生時には、AlwaysOn 可用性グループ内

の複数のデータベースコピーが迅速なフェイルオーバーとデータ消失防止を可能

にして高可用性を実現します。これにより、ディスクやテープから過去のポイントインタイムバックアップをリカバリする場合に大きなコストとなるエンドユーザーダウンタイムがなくなります（図 8 を参照）。AlwaysOn 可用性グループは複数のサイト

に拡張でき、データセンターの障害に対する復元力が得られます。自動フェイル

オーバーによるデータベースレベルのレプリケーションが利用できます。

図 8. SQL Server の AlwaysOn 可用性グループ

概要

AlwaysOn可用性グループ


52

データベースの過去のポイントインタイムコピーが必要な場合は、SQL Server を使用して AG 環境に遅延コピーを作成できます。この機能は、論理的な破損がAlwaysOn 可用性グループ内のデータベースにレプリケートされたためにデータベースを以前の時点に戻す必要がある場合に役立ちます。また、管理者がユーザーデータを誤って削除した場合にも利用できます。EMC 製品によるスナップショットは、これまで以上の保護レベルをより少ないストレージで実現します。

リカバリ可能コピーと再開可能コピー

EMC のレプリケーションテクノロジーで作成できるデータベースコピーのタイプには、リカバリ可能コピーと再開可能コピーがあります。バックアップの RPO やその他要件に応じて、いずれかまたは両方を利用できます。

リカバリ可能データベースコピーリカバリ可能データベースコピーは、データベースにログが適用されてデータベースコピー作成後の任意の時点にロールフォワードするタイプのバックアップです。本番データベースで障害が発生した場合に、データベースを前回のバックアップの時点にリカバリできるだけでなく、以降のトランザクションを障害発生の時点までロールフォワードできます。これは、SQL Server データベースや他の多くのビジネス要件にとって非常に重要な機能です。表 13 に、SQL Server データベースのリカバリ可能コピーを作成する 3 通りの方法を示します。

表 13. SQL Server におけるリカバリ可能データベースコピーの作成方法

バックアップ方法説明サポート

ストリームバックアップ

T-SQL ステートメントまたはネイティブSQL Server バック

アップ

ネイティブ SQL バックアップ、

NetWorker®

VDI サードパーティソフトウェア用の仮想デバイスインターフェイス

VMAX/VNX/VNXe

Networker、Replication Manager、AppSync、RecoverPoint

VSS サードパーティソフトウェア用のボリュームシャドウコピーサービス

VMAX/VNX/VNXe

Networker、Replication Manager、AppSync、RecoverPoint

これらのバックアップはいずれのタイプも SQL Server と統合され、ホットバックアップとみなされます。SQL Server は、バックアップの実行時にバックアップを記録します。

再開可能データベースコピーデータベースレベルの統合なしにストレージレベルでデータベースコピーが作成されると、SQL Server でそのデータベースコピーを使用してクラッシュのリカバリを実行し、コピーが作成された時点までデータベースを戻すことができます。これは、再開可能データベースコピーとみなされます。

この場合は、コミットされてトランザクションログに書き込まれた時点で記録されたすべてのトランザクション（およびデータファイルに書き込まれた対応するデータページ）がロールフォワードされます（やり直し）。次に SQL Serverは、記録されたがコミットされていない変更（遅延書き込みによってフラッシュされたダーティーページなど）をロールバックします（元に戻す）。

SQL Serverのネイティブデータ保護




これにより、データベースはトランザクション的に整合性のある時点の状態になりま

す。追加のトランザクションログバックアップはこの状態のデータベースには適用で

きないため、データベースはバックアップの時点までしかリカバリされません。

再開可能データベースコピーは、データベースのコールドコピーとみなされます。

SQL Server にバックアップは記録されていません。

EMC コンシステンシテクノロジーを使用して、ソース SQL Server データベースの再

開可能コピーを作成できます。このタイプのテクノロジーは、本番データベースの動

作を妨げるものではなく、すべてストレージアレイレベルで実行されます。再開可

能イメージは、コンシステンシグループ内で定義されているすべての関連オブジェ

クトの依存書き込み整合性イメージを表します。

バックアップレプリケーションのVDIおよびVSSフレームワーク

EMC VMAX、VNX、VNXe は、VDI スナップショットテクノロジーおよび VSS フレーム

ワークと統合されたコンシステンシテクノロジーを実装しており、リカバリ可能データ

ベースコピーを作成できます。

EMC RecoverPoint、Replication Manager、AppSync は、これらのテクノロジーを

ベースに構築されており、さまざまな環境に合わせてデータ保護を提供します。

SQL Serve のネイティブのデータ保護機能は一部の環境では十分ですが、多くの環

境ではSQL Serverデータベースのフルバックアップおよびリストア機能を必要としま

す。EMC では、SQL Server に高可用性とデータ保護を提供するさまざまなオプ

ションを用意しています。付録 D の「SQL Server 保護ソリューション」では、ソリュー

ションの詳細について説明し、SQL Server での保護機能についてまとめています。

表 14 は、SQL Server データベースのオプションの一覧です。

表 14. EMC 高可用性およびデータ保護オプション

カテゴリーツール/システム機能説明

継続的な可用性

RecoverPoint CDP • 同期的

• ローカルのリカバリ保護

CRR • 非同期的

• 継続的なリモートレプリケーション

CLR • ローカルデータとリモートデータの同時

保護

• CDP と CRR の組み合わせ

VMAX/VNX （組み込み型

RecoverPoint スプリッター搭載）

CDP/CRR/CLR ネイティブの継続的な可能性として機能する組み込み型 RecoverPoint スプリッターの

オプションを VMAX と VNX の両方のアレイに

搭載

VMAX SRDF 継続的なレプリケーション

SQL Server向けのEMC高可用性およびデータ保護製品


54

カテゴリーツール/システム機能説明

ポイントインタイムの迅速

なレプリケー

ションリカバリ

AppSync VNX でのスナッ

プショットのみ

のレプリケー

ション

• SLA（Service Level Agreement）主導の

シンプルなセルフサービスデータ保護、

SQL Server のストレージ管理

• VNX 上の RecoverPoint とも連携

• エージェントは不要

Replication Manager

VMAX と VNX の

スナップショット/クローン、SAN コピー

• 包括的なデータ保護ソフトウェア

• SQL Server へのエージェントのインストー

ルが必要

VMAX TimeFinder

ミラー BCV（ビジネス継続性ボリューム）の一般的

な監視および制御操作

CG コンシステンシグループ

クローンクローンセッションは一般に同じサイズの本

番 LUN を消費するが、作成後は影響はない

スナップショットスナップショットは消費スペースはクローンよ

りも小さいが、本番 LUN上でデータが頻繁に

変更されるとそのLUNへの影響が大きくなる

VNX クローンクローンセッションは一般に同じサイズの本

番 LUN を消費するが、作成後は影響はない

スナップショットスナップショットは消費スペースはクローンよ

りも小さいが、本番 LUN上でデータが頻繁に

変更されるとそのLUNへの影響が大きくなる

ポイントインタイムの効率

的なバックアッ

プとリストア

EMC Avamar® 包括的なソフト

ウェアおよび

ハードウェアソリューション

可変長重複排除により、その日に変更され

たデータのみを保存してバックアップ時間を

大幅に短縮するとともに、毎日のフルバック

アップも維持、ワンステップで即座にリストア

可能

EMC NetWorker 従来のバック

アップおよびリ

ストアソフトウェ

アソリュー

ション

さまざまなデータ保護オプションにより、デー

タのバックアップ/リカバリを一元化、自動

化、高速化

各製品には、それぞれ独自のメリットと考慮事項があります。各用途のサービスレベル要件に従って決定してください。

EMC のハードウェアベースのスナップおよびクローン製品は、何年にもわたって

Microsoft VDIおよびVSSテクノロジーと統合されてきました。Symmetrix TimeFinderと VNX SnapView（またはその後のバージョンの高度なスナップ）により、バックアッ

プ/リカバリ操作用にローカルのポイントインタイムスナップショットとデータクローンを作成できます。これらの製品は、データベースとログの省ディスクスペース

型スナップショットまたは完全なブロック単位クローンコピーによって、単純で非破

壊的なバックアップ操作を可能にします。これらの製品を使用すると、バックアップ

およびリストアを数秒で実行できます。




EMC Replication Manager では、一元化された管理コンソールを使用して、SQL Server の EMC ポイントインタイムレプリケーションテクノロジーを管理できます。Replication Manager は、データレプリケーションプロセス全体（検出や構成から、複数のアプリケーションコンシステントなディスクベースレプリカの管理まで）を調整します。レプリケーションのスケジュール、記録、カタログ、自動有効期限設定の効率的な管理により、データベースを自動的に検出できます。

EMC は、SQL Server データベースの迅速なバックアップおよびリストアを可能にする堅牢な方法を強くお勧めします。EMC Replication Manager、EMC Avamar、EMC NetWorker は、ログのトランケート機能および代替ホストへのデータベースのマウント機能を備えています。

Microsoft SQL Server 2012のネイティブのAAGを使用する場合でも、論理的な破損に備えて信頼性の高い代替のポイントインタイム SQL Server データ保護戦略を使用することを強くお勧めします。

レプリケーションテクノロジー

SQL Server では、専用のシステムリソースが必要です。保護メカニズムが SQL 環境に実装されている場合は、それに伴う SQL Server へのパフォーマンスインパクトを考慮してください。

EMC RecoverPoint RecoverPoint は、SQL Server 環境を災害から保護するためにデータをレプリケートします。次のオプションがあります。

• CDP（ローカルのリカバリ保護）：データベースのすべてのトランザクションを収集して同時にそれをセカンダリストレージロケーションに書き込むことで、同期保護を可能にします。

• CRR（継続的なリモートレプリケーション）：距離に関係なくデータをレプリケートできる非同期保護です。

• CLR（ローカルデータとリモートデータの同時保護）：CDP と CRR のレプリケーション方法を組み合わせて、SQL Server 環境にローカルとリモートの保護を提供します。

RecoverPoint は、拡張性に優れ、非常に大規模な SQL Server 環境に実装できます。ほとんどすべてのポイントインタイムに、継続的な再開可能ユーザーデータベースコピーとログファイルを提供します。

最新の VNX および VMAX アレイには、RecoverPoint スプリッターが組み込まれています。詳細については、EMC オンラインサポート Web サイトにある「EMC RecoverPoint Replicating Microsoft SQL Server Technical Notes」を参照してください。

EMC TimeFinder EMC TimeFinder は、次の機能により、ローカルレプリケーション環境内のデバイスペアでの制御操作を可能にするビジネス継続性機能です。

• TimeFinder/Mirror：BCV（ビジネス継続性ボリューム）の一般的な監視および制御操作

• TimeFinder/CG：コンシステンシグループ

• TimeFinder/Clone：クローンコピーセッション

• TimeFinder/Snap：スナップコピーセッション


56

これらの機能は、ストレージマネージャーで使用できます。また、他のデータレプリケーションソフトウェアと組み合わせることで、SQL Server でスナップとクローンの統合 VDI または VSS コピーも可能です。

VNX クローン/スナップローカルプロテクションスイートでは、ブロックベースストレージのビジネス継続性のために、DVR 方式のロールバック機能を使用したポイントインタイムリカバリによるスナップショットとクローンを組み合わせて、データ消失を最小限に抑えて本番アプリケーションのリカバリを行うことができます。

アプリケーション所有者は、データの重要度に基づいて RPO（目標復旧時点）を調整でき、またセルフサービス機能を使用してより高速なリカバリを実行できます。本番データのコピーは、開発、テスト、意思決定支援ツール、レポート作成、バックアップの高速化に使用できます。

• SnapView

• SnapSure™

• RecoverPoint/SE の CDP（継続的なデータ保護）

レプリケーション管理ツール

アプリケーションプロテクションスイートは、アプリケーションコンシステントな再開可能データベースコピーの作成を自動化して、SQL Server データベースを定義済みサービスレベルにリカバリできるようにします。リカバリ可能データベースコピーの場合は、SQL Server のトランザクションログを個別にバックアップする必要があります。

• VNX シリーズ向け：Replication Manager/AppSync と Data Protection Advisor for Replication Analysis が含まれます。

• VNXe シリーズ向け：Replication Manager/AppSync が含まれます。

• VMAX シリーズ向け：Replication Manager/AppSync が含まれます。

Replication Manager または AppSync のポイントインタイム復旧可能性を達成するには、スナップショットまたはクローンで実行されるフルバックアップを SQL Server ログバックアップと組み合わせる必要があります。

ポイントインタイムリカバリの詳細については、Microsoft MSDNライブラリで「バックアップ内の特定の時点へのデータベースの復元」を参照してください。

考慮事項

SLA（Service Level Agreement）を一般に満たす複数サイト災害復旧ソリューションを実装するための最も重要な要件は次のとおりです。

• RTO（目標復旧時間）： SQL Server のエンドユーザーがサービスの中断を許容できる時間の長さ。

• RPO（目標復旧時点）：許容可能なデータ消失量。

• コスト： SLA（Service Level Agreement）を満たせるようにするためのソリューションのコスト。

同期レプリケーションソリューションでは、リモートサイトのデータがコミットされた場合にのみデータの ACK が送信されます。

• メリット： 0 RPO（データ消失ゼロ）を常時実現します。

• デメリット：長距離の低速リンクにより、本番環境で速度が低下する可能性があります。200 km を超える距離では、同期レプリケーションを実行できない場合があります。

複数サイトの災害復旧

http://msdn.microsoft.com/zh-cn/�




非同期レプリケーションソリューションでは、リモートサイトが ACK を送信する前に

データがコミットされるため、距離の制限はありません。

• メリット：レプリケーションの距離に制限がありません。

• デメリット：データ消失の可能性があります。

保護されるデータ/ボリュームの量も、複数サイト保護設計の考慮事項です。

• すべてのデータがレプリケートされます。

フェイルオーバーが必要な場合に自動的に開始して即座に RTO を提供す

るように、リモートサイトで設定できます。

ネットワークでのデータ転送が増えると、本番環境のパフォーマンスが低

下する可能性があります。

• レプリケートするユーザーデータベースおよびログファイルのみを選択します。

ネットワークでのデータ転送が減ると、本番環境のパフォーマンスが向上

し、データ消失が減少します。

コンシステンシグループ内のデータが減ると、リカバリ手順および時間が

延びる可能性があります（RTO の長期化）。

最高レベルの RTO および RPO の場合は、同期ソリューションを選択します。可能で

あれば、地理的に分散させたクラスタリング製品を使用すると、ほとんどのプロセス

が自動化されて RTO が極めて短いデータ消失ゼロのソリューションが実現します

（VMAX SRDF/CE）。これには、サイト間の高速リンクへの投資が必要になります。

上位レベルの RTO および RPO の場合は、リモートサイトでマルチプラットフォーム

のアレイを使用すると、VPLEX で同様の結果を得ることができます。

RecoverPoint、Replicator、その他 EMC の複数サイトレプリケーションテクノロジー

はすべて、非常に優れた RTO と RPO を実現します。災害復旧が必要な場合でも、

最小限のユーザー介入でリモートサイトを復旧できます。

複数サイトレプリケーションテクノロジー

EMCでは、単一サイトのWindowsフェイルオーバークラスター構成の機能を拡張し、

追加の複数サイト保護を実現するために、次のソリューションを提供しています。

• VMAX SRDF/Cluster Enabler for MSCS：地理的に分散させたクラスタリング製

品です。

• RecoverPoint：同期および非同期のリモート保護を提供します。非同期保護

では、距離に関係なくデータをレプリケートできます。

• VPLEX：さまざまな場所でデータの単一コピーに同時にアクセスし、データセン

ター間で実行中仮想マシンの透過的移行を可能にします。

• VNX リモートプロテクションスイート： Replicator 、 MirrorView ™ 、

RecoverPoint/SE CRR（継続的なリモートレプリケーション）による保護を提供

します。

• VNXe Replicator：iSCSI および NAS にリモート保護を提供します。


58

VNX リモートプロテクションスイート VNX リモートプロテクションスイートは、ブロックとファイルのレプリケーションを統合

し、NAS および SAN の両方の環境の災害復旧を実現します。特定の時点に迅速に

DVR 方式のロールバックを行い、妥協することなく、あらゆるホストとアプリケー

ションに災害復旧保護を提供します。機能として、WAN 帯域幅を削減するための圧

縮と重複排除、アプリケーション固有の RPO（目標復旧時点）、1 対多構成のレプリ

ケーションオプションなどがあります。

• VNX シリーズ向けのこのスイートには、 Replicator 、 MirrorView/A 、

MirrorView/S、RecoverPoint/SE CRR（継続的なリモートレプリケーション）が

含まれます。

• VNXe シリーズ向けのこのスイートには、Replicator（iSCSI と NAS）が含まれ

ます。

MirrorView は、SQL Server データベース LUN を災害復旧用のリモートの場所にレプ

リケートします。MirrorView レプリケーションは、ホストに透過的です。本番ホストま

たは本番ストレージシステムに障害が発生した場合は、リモートレプリケーションに

より、セカンダリミラーイメージにフェイルオーバーできます。

MirrorView ソフトウェアには、補完的なミラーリング製品が 2 つ用意されています。

• MirrorView/S では、本番ホスト LUN のデータイメージをリモートサイトのセカン

ダリストレージにリアルタイムで同期的にミラーリングすることができます。これ

により、本番サイトに障害が発生した場合のデータ消失ゼロを実現します。

• MirrorView/A では、定期的な増分更新モデルに基づく遠距離レプリケー

ションが可能です。データのリモートコピーが定期的に更新されて、前回の更

新以降にローカルコピーに加えられたすべての変更が適用されます。この方

法では、本番サイトに障害が発生した場合にデータ消失が発生する可能性

があります。

MirrorView は、小規模から中規模の SQL Server 環境に適しています。MirrorViewの詳細については、EMC の Web サイトで「EMC Business Continuity for Microsoft SQL Server 2008 Enabled by EMC CLARiiON and EMC MirrorView /A White Paper」を参照してください。

再開自動化ツール

Microsoft FCI（フェイルオーバークラスタリングインスタンス）は、プライマリサイト

のサーバーが停止した場合にセカンダリサイトを自動的に起動することで再開を自

動化します。

VMAX SRDF/CE for MSCS は、地理的に分散されたクラスタリングソリューションです。

さまざまなサイトの SQL Server の災害復旧でデータ消失ゼロと極めて短い RTO を

インスタンスレベルで実現する高レベルの自動化を備えています。

Microsoft AlwaysOn 可用性グループは、複数サイトのサーバーの災害復旧を可能

にします。プライマリデータベースが停止した場合に、データベースレベルで自動

フェイルオーバーを選択できます。




仮想化インスタンス自動化ツール

vCenter SRM（Site Recovery Manager）は、災害復旧を自動化して SQL Server など

のクリティカルアプリケーションを迅速かつ効率的にリカバリできるように、リカバ

リを簡素化し、プロセスから人為的ミスを排除します。SRM 構成の詳細については、

「vCenter SRM ソリューション保護」で設計例とリファレンスアーキテクチャを参照し

てください。

EMC では、SQL Server 2012 向けにさまざまな災害復旧オプションを用意しています。

表 15 は、頻繁に使用されるオプションの説明です。これらのオプションには、それ

ぞれ長所と短所があります。環境の災害復旧要件によって、その環境に最適なオ

プションが決まります。

表 15. SQL Server 向けの EMC 災害復旧オプション

オプションレプリケーション方法説明

AlwaysOn 可用

性グループ SQL Server のネイティブ

の継続的なレプリケー

ション

高可用性と災害復旧を実現するために

SQL Server 2012 に組み込まれている。

データベース

の移植性 EMC RecoverPoint SQL Server データのみがレプリケートされ

る。セカンダリレプリカへのフェイルオー

バー時に DNS の変更が必要。 EMC VPLEX

サーバー/ サイトの移動

EMC RecoverPoint OS と SQL Server の両方のデータがレプリ

ケートされ、フェイルオーバーにはサー

バーの起動、IP の変更、DNS の更新が含

まれる。

EMC VPLEX

EMC VMAX SRDF/Cluster Enabler

EMC Replicator

SQL Server バックアップでパフォーマンスの低下を軽減するには、次の追加の推奨

事項に従います。

• 中～高ワークロードでは、バックアップを本番SQL Serverから直接実行しない

でください。代わりに、ポイントインタイムスナップショットまたはクローンを別

のサーバーにマウントしてそのサーバーからバックアップを実行するか、

AlwaysOn 可用性グループ内のセカンダリコピーを使用します。

• できる限り、業務時間外にバックアップを実行するようスケジュール設定し

ます。

AlwaysOn 可用性グループは、Microsoft SQL Server のネイティブの継続的なレプリ

ケーションソリューションです。高可用性と災害復旧を実現するために SQL Server 2012 に組み込まれています。AlwaysOn 可用性グループ向けの実装は、FAST VP、FAST Cache、フラッシュ XtremSW Cache、XtremSF などの EMC フラッシュベースソリューションにシームレスに適合します。

SQL Server 2012の災害復旧オプション

バックアップに関する追加の推奨事項

HA/DRのためのAlwaysOn


60

AlwaysOnとFAST Suite

SQL Server データベースの高可用性および災害復旧計画の一部として AlwaysOn可用性グループを構成する場合は、AlwaysOn 可用性グループのセカンダリコピー

の設計に関するベストプラクティスは次のとおりです。

• セカンダリコピーで大規模なレポートワークロードをサポートする必要がなく、

フェイルオーバーの発生時に必要なワークロードを十分にサポートできる場

合は、セカンダリコピーを下位階層のストレージに配置できます。

• FAST VP または FAST Cache をセカンダリコピーに対して有効にすると、読み

取り専用のワークロードを向上できます。セカンダリコピーとプライマリコピー

がプールを共有しない場合は、プライマリサイトへの影響はありません。これ

により、フェイルオーバーでセカンダリコピーが必要な場合に、最高レベルの

パフォーマンスが得られます。

• 設計例、リファレンスアーキテクチャ、その他実装の詳細については、「EMC Mission Critical Infrastructure for Microsoft SQL Server 2012 White Paper」を参照してください。

AlwaysOnとフラッシュXtremSW Cache/XtremSF

サーバーサイドフラッシュが実装されている場合は、SQL Server ワークロードのパ

フォーマンス向上により、非常に高いパフォーマンスを極めて低いレーテンシーで実

現できます。XtremSW Cache と XtremSF のベストプラクティスと設計の考慮事項は

次のとおりです。

• セカンダリサイトで読み取り専用ワークロードのパフォーマンス向上を必要と

していたり（ワークロードがランダムな場合のみ）、セカンダリサイトへのフェイ

ルオーバーでより高いパフォーマンスを必要としていたりする場合を除き、通

常は XtremSW Cache はプライマリサイトで構成するだけで済みます。

• AlwaysOn 可用性グループ内のセカンダリコピーに高速ネットワークと短距

離の XtremSF もある場合は、フェイルオーバーの発生時に、本番サーバー

への影響とデータ消失を最小限に抑えながら、同期化されたコピーを実行

できます。

• 高速ネットワークリンクを備えたプライマリサイトとセカンダリサイトの両方で

XtremSF が使用されている場合は、AlwaysOn 可用性グループの複数のセ

カンダリコピーにより、本番サーバーへの影響が軽減されます。

• XtremSW Cache を EMC ストレージの FAST Suite と併用することで、SQL Server のパフォーマンスをさらに向上できます。

XtremSF の設計と実装の詳細については、「EMC XtremSF Acceleration for Microsoft SQL Server 2012 White Paper」を参照してください。

XtremSW Cache の設計と実装の詳細については、「EMC Infrastructure for High Performance Microsoft and Oracle Database System White Paper」を参照してくだ

さい。




まとめ本書は、EMC ストレージシステムを使用した Microsoft SQL Server の展開を計画す

る際の重要な意思決定ポイントを示しています。複数の構成オプションがあるため、

ほとんどの環境に対応できます。EMC ストレージおよびデータ管理製品は、ビジネ

スニーズに的確に合わせて SQL Server 環境を柔軟に管理できるように設計されて

います。

SQL Server ストレージの設計に関するベストプラクティスは常に変化しています。ス

トレージテクノロジーは急速に向上しているため、従来のベストプラクティスを適用

できない構成もあります。本書では、EMC VNXユニファイドストレージファミリまたは

EMC Symmetrix VMAX ストレージシリーズを使用した SQL Server の展開に関して

EMC が推奨する現在のベストプラクティスを取り上げています。これらのガイドラ

インに従うことで、効率、パフォーマンス、可用性に優れ、要件を満たす SQL Server環境を実現できます。

本書では、次のことを可能にするための概念、原則、式を説明しています。

• SQL Server の I/O および帯域幅特性を理解する。

• SQL Server および VNX または VMAX ストレージシリーズのベストプラクティ

スを適用する。

• SQL Server ストレージビルディングブロックを利用する。

• ストレージの I/O、容量、帯域幅要件を計算する。

• 全体的なストレージ設計を検証する。

• SQL Server 向けのさまざまなデータ保護オプションを理解する。

Microsoft SQL ServerとEMC VNXファミリまたはEMC Symmetrix VMAXストレージシリーズの導入に関する追加のガイダンスについては、最寄りの EMC の SQL Server担当者にお問い合わせください。

サマリー

関連情報


62

付録A： EMC Data Protection Advisor for Replication Analysis EMC DPA/RA（Data Protection Advisor for Replication Analysis）は、アプリケー

ション、ホスト、アレイからのデータの収集を自動化し、リスクを常時監視し、SLA の

未達成または保護目標とのギャップの可能性がある場合にアラートを送信します。

デバイスとアプリケーションの監視は、データコレクションウィザードと検出ウィ

ザードを使用して自動化できます。これらのウィザードでは、監視対象のデバイスま

たはアプリケーションに関する質問形式の一連の手順に従って DPA/RA を構成しま

す。ウィザードでデバイスまたはアプリケーションを定義すると、ノードが自動的に

［構成］ビューに追加され、コレクターの起動時にデータ監視が実行されます。

この例では、VNX アレイがリモートで検出され、DPA/RA サーバーで実行中のコレク

ターから監視されます。VNX システムは、復旧可能性と分析レポート用に監視され

ます。

DPA/RAでストレージアレイを検出するには、EMC Solutions Enablerがインストール

されている必要があります。Solutions Enabler をインストールするには、次の手順

に従います。

1. Solutions Enabler を DPA/RA サーバーにインストールします。

2. テキストファイルを作成し、アレイごとに 1 行を使用してアレイの情報を含め

ます（この例のファイル名は Clar.txt）。

3. DPA/RA サーバーで次のコマンドを実行して、VNX を登録します。

4. 次のコマンドを実行して、VNX が正常に追加されたことを確認します。

ストレージアレイの検出

DPA/RA でストレージアレイを検出するには、次の手順に従います。

1. DPA/RA のツールバーで［ツール］を選択し、［検出ウィザード］を選択し

ます。

2. ［ストレージアレイ］を選択し、［Import Source（インポートソース）］パネル

に進み、［次へ］をクリックします。検出ウィザードにすべてのストレージアレ

イのリストが表示されます。インポートするストレージアレイを選択し、［次

へ］をクリックします。

概要

データコレクションウィザードと検出ウィザード

データの検出と収集




3. ［スケジュール］で復旧可能性データ収集リクエストのスケジュールを選択し、

［終了］をクリックします。

Microsoft SQL Serverを監視するためのData Protection Advisorの構成

DPA/RA で SQL Server を監視するように構成するには、次の手順に従います。

1. DPA/RA のツールバーで［ツール］を選択し、［データコレクションウィザー

ド］を選択します。

2. ［ホスト］をクリックし、［次へ］をクリックします。［ホストの詳細］パネルが表

示されます。

図 9. データコレクションウィザード

3. ホストの名前、説明、OS タイプを入力します。

4. ［Collector Location（コレクターの場所）］（Figure 10）で［Is there or will there be a Collector installed on the Host?（ホストにインストールされている

コレクターがありますか？）］の［はい］を選択します。

図 10. コレクターの場所


64

5. CPU パフォーマンスとメモリ使用率のデータを OS から収集するには、［デー

タ収集］で次のように選択します。

a. ［Do you want to gather system information?（システム情報を収集

しますか？）］で［はい］を選択します。

b. ［Do you want to monitor applications on this host?（このホストで

アプリケーションを監視しますか？）］で［はい］を選択します。

c. ［Microsoft SQL Server］のチェックボックスをオンにします（図 11 を

参照）。

図 11. データ収集

6. SQL Serverインスタンスを追加するには、［データ収集］パネルで［追加］をク

リックします。［Add SQL Server Instance（SQL Server インスタンスの追加）］ダイアログボックスが表示されます。適切な SQL Server 認証情報を入力し、ダイアログボックスを閉じます。

図 12 は、SQL Server が DPA/RA 構成に正常に追加されたことを示してい

ます。

図 12. DPA/RA データベースサーバービュー




ギャップとリスクの表示とレポート

DPA/RA には、ホストとストレージの関係を分かりやすく示すグラフィカルマップが用

意されています。DPA/RA のレポートとビューを使用して、修復可能性ギャップとリス

クを表示し、問題を解決します。DPA/RA では、多数のレプリケーションエラー状

態を監視できます。

図 13 に、スケジュールレポートを設定する構成を示します。図 14 は、SQL Serverのリスク情報です。ストレージは、RecoverPoint にマップされてから、VMware ESX ク

ラスター上にある SQL Server 仮想マシンにマップされています。

図 13. 監視対象の SQL Server システムを示すスケジュールレポートエディター

図 14. SQL Server のリスク情報

DPA/RA は、この情報から、構成にアプリケーションボリュームがなく、レプリカが不

完全で、アプリケーションをリカバリできない可能性があることを検出しています。構

成を確認して、必要に応じて修正してください。


66

付録B： SQL Serverのパフォーマンス監視、チューニング、サイズ設定の

ためのツール SQL Server の監視は、さまざまなレベルで行えます。上から順に見ると、トランザクションに SQL Server を使用するアプリケーション、SQL Server データベース、SQL Server をホストする Windows ホスト、ハイパーバイザー（仮想化されている場合）、すべてのデータが存在するストレージレイヤーなどがあります。

本番ワークロードの実行中にパフォーマンスデータを収集することをお勧めします。ワークロードの特性は定期的に変わる場合があります（たとえば、システムが日中に OLTP を実行し、夕方に ETL とレポートを実行し、夜間にバックアップを実行する場合など）。この場合は、その日のすべてのフェーズを収集してください。これにより、本番のすべてのフェーズに対応できるようにシステムをサイズ設定することが可能になります。

Windows フェイルオーバークラスターを実行している場合は、すべてのノードから同時にデータを収集することをお勧めします。これにより、クラスターフェイルオーバー中でもパフォーマンスデータが収集されます。

また、物理および仮想マシンのメモリと CPU の負荷はストレージのパフォーマンスに影響を与えるため、これらの要素を示すカウンターの収集と分析もお勧めします。たとえば、サーバーにメモリを追加するとストレージ I/O が大幅に減少し、CPU のボトルネックを解消するとストレージ I/O が大幅に増加することがあります。表 16 は、各レベルで使用するツールの一覧です。

表 16. SQL Server のパフォーマンス監視、チューニング、サイズ設定に使用するツール

レベルツールソース/リンク説明

アプリケーション DBclassify EMC（http://japan.emc.com/domains/ zettapoint/index.htm）

データを常時監視し、パターンと過去の挙動情報を学習し、ビジネスの優先度

に従って分類および移動。

Perfcollect EMC（http://emc.ms/Perfcollect） SQL Server 関連のパフォーマンスデータコレクションを自動化。主にストレージと仮想環境のサイ

ズ設定に使用。

EMC ワークロードパフォーマンス評価

EMC（https://emc.mitrend.com）別名「Mitrend」。サイズ設定に関係する重要なパフォーマンス情報を関連づけて表示する自動オンラインワークロードパフォー

マンス評価ツール。

PAL Performance Analyzer of Logs：オープンソース

（http://www.codeplex.com/PAL）

パフォーマンス問題のトラブルシューティングに役立つ。

SQL Server データベース

VSPEX SQL サイジングツール

EMC（http://express.salire.com/go/emc）

仮想化 SQL Server に推奨される VSPEX 実証済みインフラストラクチャをユーザー要件に基づいて決定

するのに使用可能。

概要

http://japan.emc.com/domains/zettapoint/index.htm�


http://emc.ms/Perfcollect�

https://emc.mitrend.com/�

http://www.codeplex.com/PAL�

http://express.salire.com/go/emc�




レベルツールソース/リンク説明

T-SQL Microsoft（SQL Server インストールに付属）

SQL Server データベースエンジンのインスタンスにトレースを作成するためのTransact-SQL システムスト

アドプロシージャを提供。

SQL Server Profiler

Microsoft （SQL Server Analysis Services）

SQL トレースの収集と再生をグラフィカルユーザーインターフェイスで提供。

SQL DTA（データベースチューニングアドバイ

サー）


インデックス作成やパーティション分割など SQL Server のチューニング案を提供。

DMV （動的管理ビュー）


ローカルのサーバー操作とサーバー稼働状態に関する情報を公開するクエ

リー構造。

Windows ホスト Perfmon Windows パフォーマンスモニター（Windows Server インストールに付属）

SQL Server ワークロードのパフォーマンス特性を追跡

可能。

ハイパーバイザー

VMware vSphere Client GUIインターフェイス

vSphere Client GUI VMware ESX/ESXi ホストのパフォーマンスの追跡とデータの構成のための主要ツール。

Resxtop/Esxtop

VMware ESX/ESXi パフォーマンスマトリックスを提供（root アクセスが必要）。

Hyper-V Perfmon Windows パフォーマンスモニター Hyper-V および仮想マシンのパフォーマンスマトリッ

クスを提供。

ストレージ/サーバーキャッシュ

Unisphere Analyzer

EMC ストレージシステムに付属 EMC ストレージシステムのパフォーマンス監視を提供。

XtremSW Cache Performance Predictorツール

https://support.emc.com/search/ ?product_id=25208&text=predictor

EMC XtremSW Cache のパフォーマンス予測ツールを提供。XtremSW Cache のSQL Server環境にアクセス

して評価。

EMC Storage Configuration Advisor

EMC プリセールスおよびポストセールスから入手可能

既存環境の階層化ポリシーを定義するのに利用。Tier Advisor が I/O を監視して推奨の階層化ポリシー設定を提示。

https://support.emc.com/search/%0b?product_id=25208&text=predictor�

https://support.emc.com/search/%0b?product_id=25208&text=predictor�


68

EMC DBclassify

EMC DBclassify™は、データベースストレージの総所有コストを削減しながらビジネ

スアプリケーションのパフォーマンスを向上させるデータベース最適化ソリュー

ションです。DBclassify は、データを常時監視し、パターンと過去の挙動情報を学習

し、ビジネスの優先度に従ってデータを分類および移動します。DBclassify は、デー

タベースの複雑化に伴う管理、パフォーマンス、予算上の課題に直面している IT 組

織に最適です。

DBclassify は、データベースの実際の使用を完全に可視化できるように、構造化さ

れたデータを分析して識別します。DBclassify では、包括的な分析プロセスにより、

すべてのデータベースオブジェクト（テーブル、インデックス、パーティション）をアク

セス頻度や I/O 待機情報に基づいて自動的に追跡しランクづけします。また、すべ

てのデータベースオブジェクトを実際の使用状況に基づいてユーザーおよびアプリ

ケーションと関連づけます。

DBclassify で開発された独自のランキング計算式を使用することで、企業全体の

データベースに最適なストレージ階層化ソリューションが実現します。DBclassify は、

オブジェクト、テーブルスペース、ファイルレベルの階層化に関する推奨事項を提

示し、EMC FAST テクノロジーのポリシーエンジンとしても機能します。

SQL Server環境では、監視対象のサーバーベースのエージェントではなく、リモートデータベース接続を使用してデータが収集されます。コレクタープロセスは

DBclassify リポジトリサーバーで実行され、監視対象のデータベースから情報を収

集します。図 15 に、SQL Server の DBclassify アーキテクチャを示します。

図 15. SQL Server の DBclassify アーキテクチャ

アプリケーションレベルのツール




DBclassify を使用する場合のベストプラクティスは次のとおりです。

• メジャーアップグレード/移行の前に DBclassify を導入して、現在の I/O プロ

ファイルをベンチマークします。

• 詳細な I/O 分析用にピークワークロードを収集します。

• さまざまなレベルの閾値パーセンテージと階層型ストレージ容量に基づいて

FAST VP ポリシーを生成します。

• お客様のワークロードとプロセスを反映するビジネスフィルターを作成します。

• ビジネスフィルターに基づいて使用率データを分析します。

• 使用率データをホット、ウォーム、コールドのカテゴリーに分類します。

• 全データベースの全階層の I/O アクティビティをプロファイルおよびベンチ

マークします。

• 重要度に基づいてデータベースをグループ化して分類します。

• データベースの分類別にストレージ階層化容量をプロファイルおよびベンチ

マークします。

DBclassifyの詳細については、DBclassifyのWebサイトを参照してください。

このツールは、リセラーまたは EMC プリセールスシステムエンジニアから入手でき

ます。

Perfcollect

EMC では、Perfcollect という名前の自動ツールセットを提供しています（無料）。

Perfcollect は、SQL Server、ストレージ、メモリ、CPU カウンターなど、ストレージと仮

想環境のサイズ設定に役立つ構成情報を自動で収集します。このツールは、

Windows 2003 以降のサーバーで実行できます。

パフォーマンス監視情報は、Windows パフォーマンスモニターを使用して手動で分

析できます。

EMC ワークロードパフォーマンス評価ツール

EMC ワークロードパフォーマンス評価ツールは、EMC パートナーが利用できます。

この自動オンラインツールは、サイズ設定に関係する重要なパフォーマンス情報を

関連づけて表示します。このツールは、リセラーまたは EMC プリセールスシステムエンジニアから入手できます。

PAL

オープンソースのPAL（Performance Analyzer of Logs）ツールを使用すると、（移行

のサイズ設定に対する）パフォーマンス問題をトラブルシューティングできます。

Perfcollectで収集したデータをPALツールで使用することが可能です。このツール

は、CodePlexのWebサイトからダウンロードできます。

VSPEX SQL Serverサイジングツール

VSPEX SQL Server サイジングツールでは、仮想化 SQL Server 2012 向け VSPEX 実

証済みインフラストラクチャをユーザー要件に基づいてサイズ設定できます。サイズ

設定の見積もりは、EMC VNX ストレージのその他の仮想化環境にも使用できます。

SQL Serverデータベースレベルのツール


http://www.codeplex.com/PAL�


70

図 16～図 20 は、RVM（リファレンス仮想マシン）を備えた VNX5400 システムの

500 GB OLTP データベース（最大 4,000 IOPS、年間増加率 10%）のサイズ設定の

出力例です。

図 16. VSPEX の構成

図 17. VSPEX のディスク要件

図 18. SQL Server 2012 の入力（インスタンス番号 1）

図 19. SQL Server 2012 のリソース要件

図 20. SQL Server のディスク要件




Transact-SQL

Microsoft SQL Server では、SQL Server データベースエンジンのインスタンスにト

レースを作成するための Transact-SQL システムストアドプロシージャを提供してい

ます。これらのシステムストアドプロシージャを各アプリケーション内で使用すると、

SQL Server Profiler を使用せずに、トレースを手動で作成できます。これにより、企

業のニーズに合わせたカスタムアプリケーションの作成が可能になります。表 17は、SQL Server データベースエンジンのインスタンスをトレースするためのストアドプロシージャの一覧です。

表 17. SQL Server トレース用の Transact-SQL ストアドプロシージャ

ストアドプロシージャ実行されるタスク

fn_trace_geteventinfo（Transact-SQL）トレースに含まれるイベントの情報を返す。

fn_trace_getinfo（Transact-SQL）指定されたトレースまたはすべての既存トレー

スの情報を返す。

sp_trace_create（Transact-SQL）トレース定義を作成する。新しいトレースは停止状態になる。

sp_trace_generateevent（Transact-SQL）

ユーザー定義のイベントを作成する。

sp_trace_setevent（Transact-SQL）イベントクラスまたはデータ列をトレースに追加/トレースから削除する。

sp_trace_setstatus（Transact-SQL）トレースを開始/停止/終了する。

fn_trace_getfilterinfo（Transact-SQL）トレースに適用されたフィルターの情報を返す。

sp_trace_setfilter（Transact-SQL）新しいフィルターまたは変更されたフィル

ターをトレースに適用する。

詳細については、「SQLトレースの概要」を参照してください。

SQL Server Profiler

SQL Server Profiler は、トレースの作成/管理やトレース結果の分析/再生を行うた

めの機能豊富なインターフェイスです。イベントはトレースファイルに保存され、そ

のファイルは後で問題を診断する際に特定の一連のステップを再生するために分

析または使用できます。

SQL Server Profiler は、次のタスクに使用できます。

• 問題のクエリーを順にたどって原因を特定する。

• 実行が遅いクエリーを特定して診断する。

• 問題につながる一連の Transact-SQL ステートメントを収集する。

• 保存されているトレースを再生して、テストサーバーの問題を診断する。

• SQL Server のパフォーマンスを監視して、ワークロードをチューニングする。

• パフォーマンスカウンターを問題の診断に関連づける。

詳細については、「SQL Server Profiler」を参照してください。

http://technet.microsoft.com/en-us/library/ms179870(v=sql.105).aspx�










http://technet.microsoft.com/en-us/library/ms181091.aspx�


72

SQL Serverデータベースエンジンチューニングアドバイザー

Microsoft DTA（データベースエンジンチューニングアドバイザー）は、データベー

スを分析して、クエリーパフォーマンスを最適化するための推奨事項を提示します。

DTA を使用すると、データベースの構造や SQL Server の内部に関する専門知識が

なくても、インデックス、インデックス付きビュー、テーブルパーティションの最適な

セットを選択して作成できます。

DTA により、次のタスクを実行できます。

• 問題のある特定のクエリーのパフォーマンスをトラブルシューティングする

• データベースに対するクエリーの大規模なセットをチューニングする

• 物理設計の変更の可能性がある場合に、What-If 分析の調査を実行する

• ストレージ領域を管理する

データベースワークロードのための物理データベース設計のチューニングの詳細に

ついては、「データベースエンジンチューニングアドバイザー」を参照してください。

SQL Server動的管理ビュー

SQL Server DMV（動的管理ビュー）は、ローカルのサーバー操作とサーバー稼働状

態に関する情報を公開するクエリー構造です。クエリー構造には、メタデータを返す

行セットをスキーマして Analysis Service インスタンスの情報を監視するためのイン

ターフェイスが含まれます。

Windowsパフォーマンスモニター（Perfmon）

Windows Perfmon は、物理/仮想マシンおよび Hyper-V を実行するワークロードの

パフォーマンス特性を追跡します。このツールを使用して、現在のパフォーマンスを

リアルタイムで表示できます。また、後で表示および処理できるように、パフォー

マンスデータのログをファイルに記録するように構成することもできます。アプリ

ケーションと同じ動作環境からデータを収集するため、パフォーマンスモニターには

アプリケーションから見た場合に最も近いパフォーマンスが反映されます。

表 18 は、ブロック（ファイバーチャネル、iSCSI、SAS）環境にあるストレージのアク

ティビティとパフォーマンスの評価に役立つカウンターの一覧です。これらは、

PhysicalDisk または LogicalDisk カウンターセットから表示できます。

表 18. SAN 環境のストレージパフォーマンスの評価に役立つカウンター

カウンター測定される機能

Avg disk sec/transfer 全体のストレージレーテンシー

Avg disk sec/read 読み取りレーテンシー

Avg disk sec/write 書き込みレーテンシー

Avg disk bytes/transfer I/O サイズ

Disk bytes/sec スループット

Disk reads/sec 秒あたりの読み取り I/O

Disk writes/sec 秒あたりの書き込み I/O

Windowsホストレベルのツール

http://technet.microsoft.com/en-us/library/hh231122.aspx�




SQL Server では、データベースおよびトランザクションログ用の SMB プロトコルも

サポートしています。これには、SMB クライアント共有カウンターセットが必要です

（表 19 を参照）。

表 19. NAS 環境のストレージパフォーマンスの評価に役立つカウンター

カウンター測定される機能

Average data request per second

全体のストレージレーテンシー

Average read per second 読み取りレーテンシー

Average write per second 書き込みレーテンシー

Average data bytes per request

I/O サイズ

Data requests per second スループット

Read requests per second 秒あたりの読み取り I/O

Write requests per second 秒あたりの書き込み I/O

Microsoft では、一般に許容されるストレージレーテンシーを定義しています。表 20は、追加調査のためのガイドラインです。低レーテンシーのメリットを得られるアプリ

ケーションや、高レーテンシーを許容できるアプリケーションなどがあります。

表 20. SQL Server OLTP 環境でのデータストレージのレーテンシーのガイドライン

ワークロード平均レーテンシーピークレーテンシー

データベース 20 ミリ秒未満の読み取り 50 ミリ秒未満の読み取り

トランザクションログ 10 ミリ秒未満の書き込み 50 ミリ秒未満の書き込み

システム/ページパーティ

ション 10 ミリ秒未満の読み取り/書き込み

10 ミリ秒未満の読み取り/書き込み

PLE（ページの予測保持期間）カウンターを確認すると、メモリ負荷が分かります（最

小 300 ミリ秒）。

SQL Serverとストレージに関連するパフォーマンスモニターカウンターの詳細につ

いては、SQL Serverパフォーマンス監視に関する記事を参照してください。

VMware ESXを監視するための主要メトリック

VMware環境では、VMware ESX/ESXi のパフォーマンスを監視する方法は 2つがあ

ります。

• vSphere Client GUI インターフェイス：

VMware ESX/ESXi ホストのパフォーマンスの観察とデータの構成のため

の主要ツール。

高レベルのデータアクセス権限が不要

ハイパーバイサーレベルのツール

http://blogs.technet.com/b/josebda/archive/2013/03/28/sqlio-powershell-and-storage-performance-measuring-iops-throughput-and-latency-for-both-local-disks-and-smb-file-shares.aspx�


74

• Resxtop/Esxtop：

VMware ESX/ESXi ホストの詳細なパフォーマンスデータにアクセス

大量のパフォーマンスメトリックに高速アクセス

root レベルのアクセスが必要

対話モード、バッチモード、再生モードで実行

表 21 に、VMware ESXi 環境でホストと仮想マシンの両方を監視するための主要メト

リックを示します。

表 21. VMware ESXi のホストおよび仮想マシンを監視するための主要メトリック

リソースメトリック説明

CPU %USED コレクションインターバルでの CPU 使用率

（%）

%RDY Ready 状態で使用された CPU 時間（仮想マ

シンのみ）

%SYS VMware ESX サーバー仮想マシンカーネル

で使用された時間の割合（%）

メモリ Swapin、Swapout

VMware ESX ホストがディスクからスワップインまたはディスクにスワップアウトするメ

モリ（仮想マシン単位またはホストで累積）

MCTLSZ（MB）バルーンニングによってリソースプールか

ら再利用されたメモリの量

ディスク Reads/s、Writes/s

コレクションインターバルで実行された読み

取りと書き込み

DAVG/cmd デバイス（LUN）の平均レーテンシー（ミリ秒）

KAVG/cmd 仮想マシンカーネルの平均レーテンシー

（ミリ秒）（別名：キューイング時間）

GAVG/cmd ゲストの平均レーテンシー（ミリ秒）。 GAVG = DAVG + KAVG

ネット

ワーク MbRX/s、MbTX/s

秒あたりの転送データ量

PKTRX/s、PKTTX/s

秒あたりの転送パケット

%DRPRX、%DRPTX

秒あたりのドロップされたパケット




Hyper-Vを監視するための主要メトリック

Hyper-Vのパフォーマンスは、Perfmonで監視できます。表 22に、Hyper-V環境でホ

ストと仮想マシンの両方を監視するための主要メトリックを示します。

表 22. Hyper-V のホストおよび仮想マシンを監視するための主要メトリック

リソースメトリック説明

CPU ¥Processor(*)¥% Processor Time

¥Hyper-V Hypervisor Logical Processor(_Total)¥% Total Run Time

ビジー状態の CPU 時間

消費量が 60%未満=正常

消費量が 60～89% =監視または注意

消費量が 90～100% =重大、パフォーマンスに悪影響

メモリ ¥Memory¥Available Mbytes

Hyper-V ホストで使用可能な物理メモリの量

空きメモリが 50%以上=正常

空きメモリが 25% =監視

空きメモリが 10% =警告

空きメモリが 5%未満=重大、パフォー

マンスに悪影響

¥Memory¥Pages/sec ハードページフォールトを解決する

ために、ディスクとのページの読み取

り/書き込みのレートを測定。

500 未満=正常

500～1000 =監視または注意

1000 超=重大、パフォーマンスに悪影響

ディスク ¥Logical Disk(*)¥Avg. sec/Read,

¥Logical Disk(*)¥Avg. sec/Write

読み取り/書き込みレーテンシー

1～15 ミリ秒=正常

15～25 ミリ秒=警告または監視

26 ミリ秒以上=重大、パフォーマンス

に悪影響

ネットワーク

¥Network Interface(*)¥Bytes Total/sec

ネットワークの使用率（%）

消費されるインターフェイスが 40% 未満=正常

消費されるインターフェイスが 41～64% =監視または注意

消費されるインターフェイスが 65～100% =重大、パフォーマンスに悪影響

Network Interface(*)¥Output Queue Length

待機中のスレッドの数を出力キュー

の長さで測定

ネットワークアダプター0 =正常

1～2 =監視または注意

2 超=重大、パフォーマンスに悪影響


76

Hyper-V の実装の詳細については、「Virtualizing SQL Server 2008 using EMC VNX Series and Microsoft SQL Server 2008 R2 Hyper-V White Paper」を参照して

ください。

Unisphere Analyzer

Unisphere Analyzer は、EMC ストレージアレイ用のパフォーマンス監視ツールです。

このツールは、ストレージ固有のパフォーマンスを表示するだけでなく、一部のサー

バーおよび仮想マシンレベルのパフォーマンス情報を収集および表示します。

詳細については、「EMC Unisphere Unified Storage Management Solution White Paper」を参照してください。

XtremSW Cache Performance Predictor

EMC XtremSW Cache Performance Predictor は、XtremSW Cache を特定の環境に

実装した場合のメリットの見積もりに使用できるツールです。

ツールは 2 つのステップで実行されます。

1. 一般的なトレース収集ツールを使用してホスト側のデータを収集する。

2. システム要件を満たすホストまたは任意のラップトップのトレースを分析す

る。ツールは XtremSW Cache の動作をシミュレートし、PDF 出力ファイルを

生成します。

このツールは無料で、カードやソフトウェアを購入する必要はなく、XtremSW Cacheでサポートされるすべてのオペレーティングシステム（Windows および Linux）で実

行できます。表とグラフのセットを作成して、XtremSW Cache が環境に適しているか

どうかを表示し、次の情報に基づいてパフォーマンスの向上を見積もります。

• 実際のホストのレスポンスタイム

• ホストによって使用される容量

• スキューレベル

ストレージ/サーバーキャッシュレベルのツール




図 21 は、ツールの PDF 出力例のパフォーマンス収集とキャッシュ構成を示してい

ます。

図 21. XtremCache Performance Predictor の出力例：パフォーマンスデータの収集


78

図 22 は、ディスクの I/O の分布に関するツール出力を示しています。必要に応じて、

この情報を使用して実際の XtremSW Cache のページサイズと最大 I/O サイズを設定

し、パフォーマンスを向上させることができます（デフォルトのページサイズは 8 KB、最大 I/O サイズは 64 KB）。

図 22. XtremCache Performance Predictor の出力例： I/O サイズの分散

図 23 は、キャッシュ読み取り分析を示しています。非常に高いキャッシュヒット率が

ツールで示されている場合は、ロードのかかっているこのデバイスが XtremSW Cache 高速化に適した対象になります。

図 23. XtremCache Performance Predictor の出力例：キャッシュヒットの予測




図 24は、XtremSW Cache高速化によってディスクで得られるパフォーマンス向上の

見積もりを示しています。これはシミュレートされた結果であり、XtremSW Cache 高

速化によってアプリケーションがどのくらいメリットを得られるかを確認するために役

立ちます。

図 24. XtremCache Performance Predictor の出力例：ディスクレーテンシーの予測

XtremSW Cache Performance Predictor は、最適なパフォーマンスが得られるように

XtremSW Cache を設計する際のプランニングツールとして使用してください。

EMC Storage Configuration Advisor

EMC Storage Configuration Advisor は、最新の EMC SRM（Storage Resource Management）Suite として、業界で最も包括的なアプリケーション/ストレージ間管

理を実現します。お客様はクラウドインフラストラクチャを構築する場合に、サービ

スレベル管理、優先度、タスクを全般的に把握できます。

SRM Suite は、 EMC ProSphere 、 EMC Storage Configuration Advisor 、 EMC Watch4net（最近買収）を、使いやすい単一の監視/レポート作成パッケージにまと

めたものです。このパッケージでは、必要に応じたパフォーマンス、容量、構成管

理を EMC 製品に提供し、ファイルとブロックの両方でサードパーティのストレージアレイを選択できます。

Storage Configuration Advisor には、次のメリットがあります。

• ベストプラクティスのポリシーの管理

Storage Configuration Advisor では、一般的な業界ベストプラクティスに対応

した組み込み型テンプレートを提供しており、運用要件に合わせてポリシー

の定義や変更が可能です。


80

• 変更の追跡

Storage Configuration Advisor は、継続的な変更追跡と構成検証により、サー

ビスレベルを危険にさらす問題が発生した場合にアラートを表示します。

• 構成の分析

Storage Configuration Advisor は、インフラストラクチャが組織のポリシーと業

界のベストプラクティスに準拠しているかどうかを検証して、構成の問題と関

連の変更をリンクさせます。

• EMC サポートマトリックスによる検証

Storage Configuration Advisor は、EMC サポートマトリックスを自動的にダ

ウンロードし、SANがEMC E-Labの推奨事項に準拠しているかどうかを確認し

ます。

図 25 は、Storage Configuration Advisor のダッシュボードです。

図 25. Storage Configuration Advisor のインターフェイス




Storage Configuration Advisor のダッシュボードには、環境への変更に関する数値

と影響を示す概要スナップショットが表示されます（図 26 を参照）。

図 26. EMC Storage Configuration Advisor のダッシュボード


82

付録C： SQL Serverワークロード生成ツール本番ワークロードを移行する前に、新しいコンピューティング、ネットワーク、ストレー

ジプラットフォームでワークロードをテストすることをお勧めします。表 23 は、SQL Server のストレージサブシステムの検証に一般に使用されるツールの概要です。

注：表 23 に記載されている SQL 専用またはストレージ専用のツールセットを選択する前

に、アプリケーション固有のツールセットを確認してください。たとえば、Microsoft VSTS（Visual Studio Team Test System）を使用すると、SQL Server コンポーネントを含む

SharePoint ワークロードをエンドツーエンドでシミュレートできます。

表 23. SQL Server ストレージサブシステム検証用の一般的なツール

ツール長所短所

SQL Profiler • SQL ワークロードを正確に複製

• スキューをシミュレート

• CPU とメモリに適切な負荷がか

かる

• 比較的複雑

• 実行には DBA の専門知識が

必要

• SQL 管理権限が必要

IOMeter • セットアップが簡単

• チューニング可能

• ランダム/シーケンシャル

• 読み取り/書き込み比

• DBA の専門知識は不要

• 非 SQL ワークロードをオーバー

レイ可能（バックアップなど）

• スキューのレプリケートが困難

• シーケンシャルな測定が困難

• CPU に正確な負荷がかから

ない

SQLIO • セットアップが簡単

• インフラストラクチャの制限を迅

速に解除

• 本番ワークロードの概算は不可

• CPU に正確な負荷がかから

ない

SQLIOSim I/O 安定性をテストディスクサブシステムのパフォー

マンスの検証は不可

Quest BenchMarkファクトリ

• TPCC、TPCE、TPCHタイプのワー

クロードをシミュレート可能

• 商用サポートされている包括的

なツール、テクニカルサポート

も提供

• すべてのシステムリソースがテ

ストされるように SQL Server と

連携するシミュレートされた

ワークロード

• ライセンス料金が高額

• ツールのセットアップと構成に

時間がかかる

• テスト対象のサーバーに SQL Server のインストールが必要

SQL Server Profiler

SQL Server Profiler は、ワークロードのレプリケートに使用できる最も正確な方法で

す。データベース管理者は、SQL Server Profiler を使用してトレースを収集し、これら

のトレースを自立したシステムで再生できます。主な短所は、レイヤードワークロー

ドが SQL Server のコンテキスト外（バックアップなど）で発生することです。

概要

ツールの概要




Microsoft SQL Server Profilerを使用すると、SQL Serverに送信されるTransact-SQLステートメントと、これらのステートメントのSQL Server結果セットを収集できます。

SQL Server Profilerの使用方法については、Microsoft MSDNのWebサイトで「SQL Server Profiler」を参照してください。

IOMeter

IOMeterは、ディスクI/Oパフォーマンスを測定するためのオープンソースツールで

す。管理者はIOMeterを使用すると、カスタムワークロードをシミュレートするワー

カーを迅速に作成できます。一般に、ワークロードはパフォーマンスモニターまたは

アレイベースのツールで測定されます。短所は、ストレージパフォーマンスの特性

（スキューなど）とシーケンシャルで過負荷のサーバーサイドコンポーネント（CPUやメモリなど）の測定およびレプリケートが難しいことです。詳細については、IOMeterのWebサイトを参照してください。

SQLIO

SQLIO ツールは、特定の構成の I/O 容量を評価するために、Microsoft によって開

発されました。ツールの名前が示すように、SQLIO は、SQL Server パフォーマンスへ

のファイルシステム I/O の影響を測定するのに役立ちます。

SQLIO は、ディスクサブシステムの読み取りと書き込みの制限を迅速に確認するた

めの便利なツールです。SQLIOの短所は IOMeterとほぼ同じですが、構成機能に制

限があります。SQLIO は、シーケンシャルまたはランダム I/O、大小のブロック I/O、読み取りまたは書き込み I/O の作成を実行できますが、これらを同時には実行でき

ません。たとえば、IOMeter では読み取り/書き込み比が 75:25 で 80%ランダムの

32 KB の I/O を生成するデータベースワークロードを再作成することは簡単ですが、

SQLIO で同じ操作を実行することはできません。

SQLIOは、http://go.microsoft.com/fwlink/?LinkId=115176からダウンロードでき

ます。

SQLIOSim

SQLIOSim は、I/O サブシステムのパフォーマンスではなく安定性を確認するために

設計されたツールです。このツールは、ディスクサブシステムまたはストレージネッ

トワークの障害が疑われる場合に、展開前後にエンドツーエンドの接続と安定性を

確認するのに便利です。

SQLIOSim の詳細とダウンロードについては、 Microsoft の Web サイト

（ http://support.microsoft.com/kb/231619）を参照してください。

Quest Benchmarkファクトリ

Quest Benchmark ファクトリでは、SQL Server データベースなどのデータベースと

データベースワークロードを生成できます。このツールでは、TPCC、TPCE、TPCHワークロードに、実行中の特定ワークロードのパフォーマンス記録を提供します。テ

クニカルサポートは、ライセンスを購入すると利用できます。

http://msdn.microsoft.com/en-us/library/ms181091.aspx�

http://msdn.microsoft.com/en-us/library/ms181091.aspx�

http://www.iometer.org/�

http://www.iometer.org/�

http://go.microsoft.com/fwlink/?LinkId=115176�



84

付録D：ストレージの設計例とリファレンスアーキテクチャ SQL Server の本番展開前フェーズの最終ステップでは、ストレージが適切に構成さ

れていてサポートされるロードに対応できることを検証します。

SQL Serverストレージ設計に関するEMCリファレンスアーキテクチャおよびホワイ

トペーパーについては、EMCのWebサイトとMicrosoftのWebサイトを参照してくだ

さい。

この例では、VMAX ストレージシステムおよびその他のアプリケーションでの大規模

なクラウド環境におけるSQL Server OLTPワークロードの複数階層ストレージの詳細

な設計について示します。詳細については、「EMC Virtual Infrastructure for Microsoft Applications White Paper」を参照してください。

リカバリの柔軟性、パフォーマンス、精度を維持するには、SQL Server のストレージ

のサイズ設定とバックエンドの構成を最適にします。このセクションでは、FAST VP構

成での SQL Server のサイズ設定について説明します。

フェーズ 1：ユーザー要件の収集

表 24 は、ユーザー要件を満たす SQL 構成の一覧です。

表 24. SQL 構成のユーザー要件

項目ユーザー装備

ユーザーの総数 100,000

各サーバーのデータベースユーザー

20,000、30,000、50,000

合計 IOPS 6,000

データベースの数 3

データベースのプロファイルホット/ウォーム/コールド

RPO リモート 5 分未満、ローカル 6 時間

RTO 60 分

読み取り/書き込み比 85:15

バックアップ/リストアの必要性必要（ハードウェア VSS）

フェーズ 2：ユーザー要件に基づくストレージアーキテクチャの設計

I/O 要件を満たす SQL Server のディスク数を計算してから、スペース要件を計算す

ることをお勧めします。このソリューションのサイズ設定の計算は次のとおりです。

概要

FAST VP搭載のVMAXでのMicrosoft SQL Serverストレージ設計

http://japan.emc.com/SQL%20Server�

http://www.microsoft.com/emc�




IOPSの計算

IOPS は次のように計算します。

• 225,00 ユーザーの合計 I/O は、6000 + 20% = 6000 + 1200 = 7200 IOPS

• 各階層の FAST VP ポリシー要件のバックエンド I/O を計算します。この例では、

FAST VP のサイズ設定のベースになる I/O スキューは、SATA 75%、FC 15%、

フラッシュ 10%です。

RAID 1/0 の SATA の合計バックエンド I/O =（7,200 の 10%）= （720×0.85）+ 2（720×0.15）= 828

RAID 5 の FC の合計 I/O = 7,200 の 15% =（1080×0.85）+ 4（1080×0.15）= 1,566

RAID 5 のフラッシュの合計 I/O=（7200 の 75%）=（5040×0.85）+ 4（5040×0.15）= 7,308

バックエンド I/O の総計= 10,224

• RAID 1/0 構成で 808 I/O を処理するのに必要な SATA ディスク数は、828÷50 =約 17（RAID 1/0 の場合は 18 に切り上げ）

• RAID 5 構成で 2,088 I/O を処理するのに必要な FC ディスクは、1566÷130 =約 12

• RAID 5 構成で 7308 I/O を処理するのに必要なフラッシュディスク数は、

7308÷1800 =約 4

注：パフォーマンスを計算する場合は、最高速の階層で最大数の I/O を処理する必要が

あります。

• I/O のサイズ設定の観点から、前述のポリシー設定を使用すると、環境に必

要なディスク数は次のようになります。

7.2K 2 TB SATA ドライブ 18 台

10K 600 GB FC ドライブ 12 台

200 GB フラッシュドライブ 4 台

容量計算

• ユーザーデータベースのサイズ

ホットは、200 GB

ウォームは、300 GB

コールドは、600 GB

• ユーザーデータベースのサイズに基づいてデータベース LUN のサイズを計

算します。

データベース LUN サイズ=データベースサイズ+空き領域割合要件（20%）

ホットは、300 + 20% = 360 GB

ウォームは、400 + 20% = 480 GB

コールドは、700 + 20% = 840 GB


86

• 各データベースの Tempdb およびログ LUN のサイズを計算します。ログおよ

び Tempdb のサイズはデータベースサイズの 20%として算出されます。

ログおよび Tempdb のサイズ

ホットデータベースは、300 の 20% = 60 GB

ウォームデータベースは、400 の 20% = 80 GB

コールドデータベースは、700 の 20% = 140 GB

ユーザーデータベースのログと Tempdb は、データベースごとに個別の LUN にあり

ます。これに基づいて、ログ LUN は 120 GB（ホットおよびウォームデータベース）と

140 GB（コールドデータベース）でサイズ設定されます。

• データベースサイズの合計は、データベースの総計 = 2448 GB

• 2 TB SATA ドライブあたりの有効容量は、1754 GB

• 600 GB 10K FC ドライブあたりの有効容量は、536 GB

• 使用される FASTポリシースキューは、SATA 75%、FC 15%、フラッシュ10%の

合計

• 各階層の容量：

SATA = 2448×0.75 = 1836 GB

FC = 2448×0.15 = 368 GB

フラッシュ = 2448×0.1 = 245 GB

• ディスク要件は、合計容量÷有効容量

• 各階層に必要なディスク数：

SATA（ミラー化）= 4

FC（RAID5 3+1）= 4

フラッシュ（RAID5 3+1）= 4

注：容量を計算する場合は、最も遅い階層でデータの大部分をホストする必要があります。

• 容量のサイズ設定の観点から、前述のポリシー設定を使用すると、環境に必

要なディスク数は次のようになります。

7.2K 2 TB SATA ドライブ 4 台






最適な構成は、I/O 要件と容量要件の両方に基づきます（表 25 を参照）。

表 25. I/O 要件と容量要件の両方に基づく最適な容量

1 TB（200 GB、300 GB、500 GB）SQL Server データ

ベース

I/O と容量の両方満たすために必

要なディスク数 7.2K 2 TB SATA ドライブ 18 台



シン LUN のサイズ（データベース）ホットは 360 GB

ウォームは 480 GB

コールドは 840 GB

シン LUN のサイズ（ログ）ホットは 120 GB

ウォームは 120 GB

コールドは 140 GB

このソリューションでは、柔軟性とパフォーマンスの拡張性のためのデータウェアハ

ウスのビルディングブロック設計ストレージについて説明します。詳細については、

「SQL Server 2012 Data Warehouse White Paper」を参照してください。

ビルディングブロック設計の考慮事項

データウェアハウスをサポートするサーバー、ネットワーク、ストレージ、アプリケー

ションなどのインフラストラクチャは、堅牢かつ強力で柔軟なソリューションを提供す

る必要があります。

この設計は、予測可能なパフォーマンスを提供する仮想化環境のデータウェアハ

ウス向けです。この設計では、次の基準を考慮する必要があります。

比例および予測帯域幅

• データベース容量ではなく帯域幅を考慮して設計します。この例では、12～14 時間のウィンドウでテストスイートのすべての DSS クエリーを完了するた

めに必要な帯域幅は、500 GB データベースで 100 MB/秒、1 TB データベー

スで 200MB/秒、2 TB データベースで 400 MB です。

• ディスクパフォーマンスをチェックします。シーケンシャル 64K 読み取り専用

I/O の DSS ワークロードの場合は、この例で使用される 10K 600 GB SAS ディ

スクには平均で 320 の IOPS とディスクあたり 20 MB の帯域幅が必要です。

帯域幅は、対象の I/O サイズと IOPS で次のように計算できます。

帯域幅=平均 I/O サイズ×IOPS

• ビルディングブロックストレージ要件を計算します。RAID 5（4+1）での読み取

り専用 I/O の DSS ワークロード構成の場合は、必要な 10K 600 GB SAS ディ

スク数は次のように求めます。

ディスク数=必要な帯域幅÷ディスクあたりの帯域幅

帯域幅 100 MB/秒の 500 GB ビルディングブロックの場合は、10K 600 GB SAS ディスクが 5 台必要です。

帯域幅 200 MB/秒の 1 TB データベースビルディングブロックの場合は、

ディスクが 10 台必要です。

データウェアハウスのためのビルディングブロック設計アプローチ


88

帯域幅 400 MB/秒の 2 TB ビルディングブロックの場合は、ディスクが 20台

必要です。

仮想マシンの拡張性

仮想マシンの拡張要件は次のとおりです。

• vCPU およびメモリアロケーションを含む仮想マシンリソースがビルディングブロックの一部になるようにします。

• パフォーマンスの低下を最小限に抑えながら、ビルディングブロックをすべ

てスケールアップ（ビルディングブロックを同じ仮想マシンに追加）およびス

ケールアウト（ビルディングブロックを別の仮想マシンに追加）できるように

します。

十分なリソース

ディスクとメモリのビルディングブロック設計が十分に使用されていることを次のよ

うに確認します。

• ディスク使用率：ディスクリソースを十分に活用しながら、潜在的なピークディスクアクティビティのための余裕を残します。

• システムメモリ使用率：予測したピークロードアクティビティを使用して、設計

したワークロードをサポートします。

• vCPU プロセッサ使用率：予測したピークロードアクティビティを使用して、設

計したワークロードをサポートします。

• Tempdb 設計：データベースのクエリーワークロードをサポートするのに十分

な容量とパフォーマンスを確保します。DSS ワークロードでは、Tempdb の需

要が比較的高くなります。

バランスのとれたディスク使用率

不均衡なワークロードを回避するために、できるだけ多くのバスでデータベース

LUN を構築します。このアロケーションにより、高可用性のメリットが得られる可能性

があります。

ビルディングブロック設計の詳細

ここに挙げたビルディングブロックは、次のように設計されています。

• ターゲットの帯域幅は、LUN あたり 100 MB/秒（R5 4+1 10K 600 GB SAS ディ

スク）です。より広い帯域幅が必要な場合は、ビルディングブロックに使用す

るディスクを増やします。

• この例では、LUN（R5 4+1）ごとに拡張されるデータベースのサイズは 500 GBです。1 TB データベースの場合は、2 つの LUN（ディスク 10 台）がデータベー

スファイルに作成されます。2 TB データベースの場合は、4 つの LUN（ディス

ク 20 台）が作成されます。

• ターゲットの帯域幅（LUN あたり 100 MB/秒）をサポートするには、ビルディン

グブロックに応じて、少なくとも 2 個の vCPU と 8 GB のメモリを割り当てます。

または、帯域幅50 MB/秒あたり1個のvCPUと4 GBのメモリを割り当てます。




図 27 は、この設計原則に基づいてこの例で使用されている 3 つのビルディングブロックです。表 26 に、各ビルディングブロックの詳細を示します。

図 27. テストされた 3 つのビルディングブロック

表 26. ビルディングブロックの構成

構成 500 GB ビルディン

グブロック 1 TB ビルディングブロック

2 TB ビルディングブロック

データベースのサイズ

500 GB 1 TB 2 TB

ターゲットの帯域幅

（MB/秒） 100 200 400

データベース LUNの設計

2 TB データ LUN×1

80 GB データファイル×8





ログの設計ログ LUN（5 GB ログファイル）×1

ログ LUN（12 GB ログファイルサイズ）×1

ログ LUN（12 GB ログファイルサイズ）×1

Tempdb の設計データ LUN（100 GBデータファイル×1）×1

ログ LUN（2 GB ログファイル）×1

データ LUN（100 GBデータファイル×2）×1


データ LUN（100 GBデータファイル×4）×1


ディスク構成 SAS ディスク 5 台 SAS ディスク 10 台 SAS ディスク 20 台

メモリ（GB） 8 16 32

vCPU（2.4 GHz） 2 4 8

注：データウェアハウス環境のログ LUNの使用率は高くないため、同一のログ LUNを同じ

仮想マシン上の複数のビルディングブロックが共有する可能性があります。


90

表 27 では、この例のビルディングブロックと仮想マシンの最小要件を定義してい

ます。

表 27. ビルディングブロック設計

仮想マシンごとメモリ（GB） CPU（コア） RAID 5（4+1）ディ

スクの数

最小 16 4 5

TB あたり 16 4 10

100 MB/秒あたり 8 2 5

500 GB（100 MB/秒） 8 2 5

1 TB（200 MB/秒） 16 4 10

2 TB（400 MB/秒） 32 8 20

4 TB（800 MB/秒） 64 16 40

6 TB（800 MB/秒） 96 24 60

ビルディングブロックの展開

図 28 に、ビルディングブロックを展開するための次の 2 つの方法を示します。

• ビルディングブロックを同じ仮想マシンに配置するスケールアップ設計。

• 各ビルディングブロックを異なる仮想マシンに配置するスケールアウト設計。

図 28. ビルディングブロックのスケールアップとスケールアウト




スケールアップ設計

スケールアップ設計では、OS のライセンスコストを節約できる可能性があります。

vCPU およびメモリリソースはビルディングブロック設計に組み込まれているため、

これらのリソースは、このビルディングブロックのサポートに必要な同じ仮想マシン

でのビルディングブロックの展開に比例して増加します。

スケールアウト設計

ビルディングブロックのスケールアウト展開では、必要なビルディングブロック数を

サポートできるように VMware ESXi サーバーの vCPU およびメモリ容量を考慮する

必要があります。

vCPU やメモリなどのシステムリソースは、ビルディングブロック内にあります。ビル

ディングブロックをスケールアップで（同じ仮想マシンに）追加したり、スケールアウ

トで（個別の仮想マシンに）追加したりする場合は、仮想マシンの最小要件を下回ら

ない限り、同じリソースが必要です。このため、小規模のビルディングブロック（帯域

幅200 MB/秒の1 TB未満のデータベースなど）では、スケールアップモデルを使用

して仮想マシンのシステムリソース（メモリや CPU など）の無駄を減らす方法がアプ

ローチな場合もあります。

このソリューションのような中規模の環境では、どのアプローチが最適かを注意深く

検討してください。

SQL Server仮想マシンおよびLUNアロケーションの設計

表 28 と図 29 は、この例で使用されるさまざまなデータベースの仮想マシン構成と

ディスク割り当てを示しています。EMC では、妥当なパフォーマンスでビルディングブロックを設計および展開するさまざまな方法を試行しました。

図 29. ソリューションのビルディングブロックの展開

注： 1 台の仮想マシンでサイズと帯域幅の要件が異なる 5 台のデータベースがすべて同

時に大規模なワークロードを実行すると、ピーク時にリソースの奪い合いが発生して競合

が発生します。このような場合でも、仮想マシンの SQL Server は良好なパフォーマンスを

維持できます。


92

表 28. 仮想マシンおよび VMware ESXi サーバーでのソリューションのビルディングブロックの展開

ホストアロケー

ション CPU （コア）

メモリ

（GB）データ

ベースの

サイズ

（TB）

ディスク数帯域幅

（MB/秒）

VMware ESXi 01（40 コア、256 GB RAM）

VM1 16 64 2 20 400

VM2 8 32 2 20 400

VMware ESXi 02（80 コア、512 GB RAM）

VM3 24 96 2 20 400

2 20 400

1 10 200

0.5 5 100

0.5 5 100

VM4 24 96 2 20 400

合計 4 台の仮

想マシン 72 288 18 180 3600

このソリューションでは、EMC RecoverPoint、Replication Manager、vCenter SRM を

使用して、SQL Server の継続的な保護を実装しています。詳細については、

「 Continuous Data Protection for Microsoft SQL Server Enabled by EMC RecoverPoint, EMC Replication Manager, and VMware White Paper」を参照してくだ

さい。

EMC RecoverPoint

このセクションでは、保護を実装する際に EMC RecoverPointに必要な構成について

説明します。

ローカルレプリケーションプロセス（CDP）

図 30 は、RecoverPoint CDP（継続的なデータ保護）プロセスを示しています。このプ

ロセスでは、データを本番（ソース）ボリュームからローカルターゲットボリュームに

同期的にレプリケートする一方で、ジャーナルストレージを使用して元に戻すことが

可能なリカバリを維持します。

SQL Server保護ソリューション




図 30. EMC RecoverPoint のローカルレプリケーション（CDP）のデータフロー

リモートレプリケーションプロセス（CRR）

表 22 は、RecoverPoint CRR（継続的なリモートレプリケーション）プロセスを示して

います。このプロセスでは、データのブロックをリモートサイトのストレージアレイに

レプリケートします。データは、最大 200 km/4 ミリ秒のファイバーチャネル接続で

同期的にレプリケートされるか、IP 接続で非同期的にレプリケートされます。この例

では、最大 64 ミリ秒/6,400 km のラウンドトリップをテストしています。

図 31は、リモートRecoverPointレプリケーションでのCDPプロセスとCRRプロセスを

比較したものです。

図 31. RecoverPoint リモートレプリケーション（CRR）のデータフロー


94

表 29. RecoverPoint ローカルおよびリモートレプリケーションの CDP プロセスと CRRプロセス

操作 CDP（EMC RecoverPointローカルレプリケー

ション）のデータフロー

CRR（EMC RecoverPoint リモートレプリケーション）のデータフロー

RecoverPointで保護されて

いる LUN へ

の書き込み

RecoverPoint スプリッター

によって書き込みがイン

ターセプトされる。

RecoverPoint スプリッターによって書き込

みがインターセプトされる。

スプリッター

による書き込

みの分割

書き込みが本番ボリュー

ムとローカル RPA に同期

的に送信される。

書き込みが本番ボリュームとローカル RPAに同期的に送信される。

確認書き込みの ACK（確認）が

RPA と本番 LUN から即座

に返される。

非同期レプリケーション：書き込みの ACK（確認）が RPA と本番 LUN から即座に返さ

れる。

同期リモートレプリケーション：書き込みが

リモートサイトで受信されると、ACK（確認）

が返される。

ジャーナルへ

のタイムスタンプとブッ

クマークの書

き込み

RPA がデータをタイムスタンプおよびブックマークメタデータとともにジャー

ナルボリュームに書き

込む。

ローカル RPA が書き込みとその他の書き

込み、シーケンス、書き込みのタイムスタンプをバンドルする。このパッケージは圧

縮されて、デリバリのチェックサムとともに

IP 経由でリモート RPA に転送される。

該当なしリモート RPA がパッケージを受信し、チェッ

クサムを調べて転送中の破損がないこ

とを確認してから、データを解凍する。

該当なしリモート RPA がデータをジャーナルボリュームに書き込む。

完了データがジャーナルに安

全に保存されると、書き込

み順序の整合性が維持さ

れたデータがローカルレプリカに配信される。

データがジャーナルボリュームに書き込ま

れると、そのデータがリモートボリュームに

配信される。この配信では書き込み順序

が維持される。

コンシステンシグループ

コンシステンシグループとは、RecoverPoint 内の論理コンテナーです。コンシステン

シグループ内のすべてのデバイスは、相互に整合性（書き込み順序の忠実性）を

維持しています。RecoverPoint バージョン 3.3 では、最大 128 のコンシステンシグループをサポートします。

SQL Server 仮想マシンでは、リソース割り当ての優先度ポリシーはボリューム要件

に基づいて定義されます。

• OS/ページファイル：自然な関係のオペレーティングシステムとページファイ

ルボリュームがまとめられます。変更率が非常に低い場合は、リソース割り

当ての優先度は［通常］に設定されます。




• Tempdb/Systemdbs：Tempdb と Systemdb がレプリケートされて、リモートサイトのすべての仮想マシンを起動します。Systemdb はあまり変更されず、

TempdbはSQL Serverインスタンスの再起動のたびに再作成されることから、

これは使い捨て型になります。そのため、リソース割り当ての優先度は［低］

に設定されます。

• データ/ログ：ユーザーデータは環境内で最も重要であるため、リソース割り

当ての優先度は［重大］に設定されます。

図 32 は、Windows NTFS ボリューム、関連するコンシステンシグループ、ローカルポリシーとリモートポリシーの両方に定義されたコンシステンシグループポリシー設定の関係を示しています。

図 32. Windows ボリュームと RecoverPoint コンシステンシグループのマッピング

コンシステンシグループごとに CLR を使用する場合は、3 つのジャーナル（2 つはCDP と CRR をサポートする本番サイト用、1 つは CRR のリカバリサイト用）が設定されます。

グループセット RecoverPointのグループセット機能では、複数のコンシステンシグループ間で整合性のあるブックマーキングが可能です。グループセットには、1 台の仮想マシンの複数のコンシステンシグループを含めることができます。

レプリケートされたデータのコピーにアクセスするには、必要な時間に各コンシステンシグループのイメージアクセス有効にします（図 33）。3 つのコンシステンシグループはすべて同じターゲットイメージにロールバックされます。これにより、災害復旧サイトのボリュームが完全に整合性のある TPCE1仮想マシンになり、クラッシュコンシステント状態でサーバーを再起動できます。


96

図 33. RecoverPoint 管理コンソール：コンシステンシグループ

ジャーナルのサイズ設定：保護ウィンドウ

RecoverPoint ジャーナルのサイズ設定は重要な考慮事項です。書き込みパフォー

マンス全体を処理し、保護対象の LUN のすべての書き込みを保存できるように、パ

フォーマンスと容量の両方の特性をジャーナルのサイズ設定に含める必要がありま

す。最も重要な確認事項は次のとおりです。

• ソース LUN が生成する変更率

• 必要な保存期間の長さ

ジャーナル容量を計算するために、変更率は本番 LUN で測定する必要があります。

Perfmon カウンターを各 SQL Server に設定して、書き込み帯域幅（MB/秒）を確認し

ます。秒あたりのデータは Unisphere Analyzer で確認でき、［Stats（統計）］タブのポ

イントインタイムウィンドウに各ストレージプロセッサの処理内容が表示されます。

ジャーナルボリュームのサイズ設定の計算式は次のとおりです。

Journal size = (data per second) × (required rollback time in seconds)

(1 − target side log size) x 1.05

ジャーナルサイズ

秒あたりのデータ

必要なロールバック時間（秒単位）

1 - ターゲット側のログサイズ

ジャーナルの 20%をターゲット側のログ用に、5%を内部システム用に予約しておく

必要があります。

たとえば、コンシステンシグループ内のレプリケーションボリュームへの新しいデー

タ書き込みが5 Mbit/秒で、24時間のロールバック要件（86,400秒）をサポートする

には、計算は次のようになります。

5 × 86,400(1 − 0.2) x 1.05

= 567,000 Mb = 69.213 GB (~70 GB)




567,000 MB

69.213 GB

約 70 GB

このソリューションでは、RecoverPoint で少なくとも 7 日間ロールバックできるように

すべてのジャーナルがサイズ設定されています。

RecoverPoint と VMware vCenter の統合

vCenter Server ビューには、vCenter Server からのデータが RecoverPoint GUI（グラ

フィカルユーザーインターフェイス）で表示されます。vCenter Server には、VMware ESX サーバーとそのすべての仮想マシン、データストア、RDM ドライブに加えて、各

ボリュームのレプリケーションステータスも表示されます。各仮想マシンの保護ス

テータスは、1 時間に複数回測定されます。このウィンドウは、新しい仮想マシンが

作成されるか、仮想マシンの保護ステータスが変更されると更新されます。vCenter Server ビューは監視専用（読み取り専用）です。

たとえば、図 34 の RecoverPoint Management Application には、TPCE1 および

TPCH2 のすべての関連ボリュームが正常にレプリケートされていることが表示され

ています。それぞれのコンシステンシグループ、レプリケートされているコピー、関

連するレプリケーションセットも Figure 34 に示されています。

図 34. RecoverPoint Management Application の vCenter Server ビュー

RecoverPoint フェイルオーバー

仮想マシンがクラッシュした場合は、RecoverPointフェイルオーバープロセスを使用

してフェイルオーバーし、災害復旧サイトを起動できます。


98

図 35. RecoverPoint フェイルオーバープロセス

このシナリオ（図 35 を参照）では、本番サイトの仮想マシンがクラッシュした場合に、

表 30 の手順でフェイルオーバーを行います。

表 30. フェイルオーバーの手順

RecoverPoint フェイルオーバープロセス詳細

最新のブックマークへのイメージアクセ

スを有効にする。リモート VMware ESX サーバーに CRR コ

ピーの読み取り/書き込みイメージアクセ

スを実行して、リモート vCenter に VMFS ボ

リュームをマウントできるようにする。

フェイルオーバーがリモートレプリカに設定されていることを確認する。

RecoverPoint Management Application また

は Unisphere 管理コンソールで、［failover to the remote replica（リモートレプリカへ

のフェイルオーバー）］を選択する。

リモートストレージからVMware ESXサーバー

に完全にアクセスできることを確認する。リモート VMware ESX サーバー上のすべて

のストレージをリモート vCenter コンソール

から再スキャンする。

リモートサイトの仮想マシンを登録する。 OS LUN VMFS データストアの VMX ファイ

ルを右クリックして仮想マシンを登録し、

［Inventory the virtual machine（仮想マ

シンのインベントリ）］を選択する。

仮想マシンを起動する。 vNIC をネットワークに接続し、仮想マシンと

データベースへの IP アクセスを再度有効

化する。




リモートサイトの仮想マシンを停止し、前述の手順を本番サイトで繰り返すことで、

フェイルバックを実行できます。

このソリューションでは、SQL Server インスタンスをサイト間で完全に移植できます。

異なるサブネット

異なるサブネット（例：10.10.10.x～10.20.20.x）上の vSphere クラスターに仮想マ

シンがフェイルオーバーされている場合は、災害復旧サイトの実際の分散仮想ス

イッチと同じ優先度で、分散スイッチを本番 VMware ESX クラスターに作成する必要

があります。異なるサブネットへのフェイルオーバーを構成するには、ダミースイッ

チ上の vNIC を本番の SQL Server 仮想マシンに割り当てます。

ダミースイッチは、図 36 に示すように、本番サイトの vCenter Server で作成されま

す。仮想マシンには、ダミーの仮想災害復旧スイッチの2 つ目の vNIC が構成されま

す。これにより、仮想マシンをリモートサイトにシームレスにフェイルオーバーできま

す。災害復旧サイトに追加のネットワーク構成は必要ありません。

図 36. vNIC の構成と接続

仮想マシンが災害復旧サイトにフェイルオーバーされると、この NIC は指定された

（sqluce1.com）ネットワークに接続されます（図 37 を参照）。災害復旧サイトで構成

された本番スイッチは構成のみが目的であり、ネットワーク上で稼働していないため、

本番サイトの vNIC には不明なネットワークとして表示されます。

ダミーの災害復旧スイッ

チの 2 つ目の NIC が仮想

マシンに構成されると、災

害復旧側の異なるサブ

ネットにフェイルオーバー

できるようになります。物

理NICはこのスイッチには

接続されません。


100

図 37. sqluce1.com ネットワークに接続される災害復旧サイト

EMC Replication Manager

このセクションでは、保護を実装する際に Replication Manager に必要な構成につ

いて説明します。

Replication Manager と SQL Server の統合

SQL Server をサポートするために、Replication Manager は SQL Server VDI（仮想デバ

イスインターフェイス）スナップショット API を使用して、エンタープライズクラスの非常

にアクティブな SQL Server データベースのアプリケーションコンシステントスナップ

ショットをオンラインで迅速に作成します（ホストのオーバーヘッドの考慮は不要）。

Replication Manager では、シンプルなウィザード方式のインターフェイスで次のタス

クを実行できます。

• レプリケートするインスタンス、データベース、対応ファイルグループを指定

する。

• データを安全かつ迅速にレプリケートする。

• レプリカの作成後にデータベースを通常の動作に戻す。

• データベースを他の操作（テスト、レポート、データマイニングなど）用に別の

ホストにマウントまたはリカバリする。

• データが破損した場合に、本番ホストでデータベースを迅速にリカバリする。

Microsoft SQL Server 用のアプリケーションセットおよびジョブ

Replication Manager では、アプリケーションセットをコンテナーとする概念を使用し

て、保護するデータ（Database 1 など）と、そのデータを保護する方法であるジョブ

（RecoverPoint ブックマークイメージなど）を定義します。

sqluce1.com ネットワーク：

これは、物理 NIC が災害復旧サイ

トの災害復旧スイッチに接続され

ているためです。PCE1 仮想マシン

が災害復旧サイトにフェイルオー

バーされると、災害復旧サイトの

NIC経由で sqluce1.comドメインに

接続されます。




Microsoft SQL Server アプリケーションの整合性

この例では、Replication Manager ジョブは SQL Server ユーザーデータベースを保

護するように構成されています（［Replica Type（レプリカの種類）］オプションを［Full, Online with advanced recovery using VDI（VDI を使用したオンラインの高度な完

全リカバリ）］に設定）。このオプションでは、データベースおよびトランザクションログ全体をレプリケートします。このレプリカタイプは主に、レプリカをデータベースの

バックアップとみなす場合、またはサードパーティ製品でデータベースのバックアッ

プを作成するためにレプリカをマウントする場合に使用します。

このレプリカタイプでは、トランザクションログがバックアップされていれば、トランザ

クションログをリストアして、データベースをレプリカよりも新しい時点の内容に復元

できます。

Replication Manager は、VDI 対応スナップショットを使用して、このレプリカタイプを

作成し、アプリケーションコンシステントデータを生成します。

注：システムデータベース（マスター、MSDB、モデル）を、ユーザーデータベースと同じボ

リュームに配置しないでください。Microsoft SQL Server は、システムデータベースのリスト

アにおいて VDI とスナップショットテクノロジーをサポートしていません。

Replication Manager と vCenter および RecoverPoint との通信の構成

Replication Manager では、LUN レベルで VMFS データストアをレプリケート、マウン

ト、リストアできます。Replication Manager ソフトウェアまたはエージェントを

VMware ESXi サーバーまたは仮想マシンにインストールする必要はありません。す

べての操作は、vCenter と Replication Manager の VMware プロキシホスト（物理ホ

ストまたは仮想ホストのいずれか）経由で実行されます。プロキシホストには、

vCenter 管理の認証情報で Replication Manager サーバーを登録する必要がありま

す。Replication Manager の VMware プロキシホストは、ポート 443 経由で vCenterと通信します。Replication Manager では、関連する VMFS ボリュームを LUN にマッ

プできます。

この例では、プロキシホストはReplication Manager Serverと同じ仮想マシンを共有

しています。Replication Manager では、RecoverPoint によってレプリケートされた

LUN を検出することもできます。RecoverPoint との通信は、本番にインストールされ

た Replication Manager エージェントと、マウントされた仮想マシンを経由して実行さ

れます。

論理ボリュームマネージャーの再署名

VMFS レプリケーションでは、本番とマウントの両方の VMware ESX サーバーで LVM（論理ボリュームマネージャー）の再署名を有効にする必要があります。LVM 再署

名により、必要に応じて VMware で新しい署名を LUN に書き込むことができます。レ

プリケートされた LUN 上で VMFS が VMware ESX サーバーに認識されるようにする

には、Replication Manager に対してこのスイッチが有効でなければなりません。任

意の時期に本番 VMware ESX サーバーにリストアすることを考えている場合は、そ

の VMware ESX サーバー上でもこの設定を有効にする必要があります。

レプリカのマウントに使用される VMware ESX サーバーで、次のコマンドを実行します。

esxcfg-advcfg -s 1 /LVM/EnableResignature

このトピックの詳細については、「EMC Replication Manager 管理者ガイド」の

「VMware のセットアップ」セクションを参照してください。


102

RecoverPoint アプライアンスおよびストレージアレイの検出

このソリューションでは、ストレージ RecoverPoint スプリッターを使用します。このス

プリッターでは、Replication Manager 内の RecoverPoint ストレージをストレージアレイで検出できます。この検出タスクを完了するには、ストレージ認証情報を入力す

る必要があります。

認証情報を少なくとも1つのReplication Managerホストエージェントで構成すると、

ストレージアレイの検出操作で RecoverPoint スプリッターも検出されます。

SQL Server ユーザーデータベースのリカバリ

この例では、EMC は運用中の本番データベースの災害をシミュレートし、特定の時

点までリカバリしてソリューションをテストしました。

テストでは、OLTP データベースのテーブルが 14:16:00 に削除されました。これは

データベースの機能にとって重要なアカウント権限テーブルです。このテーブルが

ないとユーザーがデータにアクセスできないため、データベースを使用する業務が

14:16:00 に停止しました。次に、人為的ミスをシミュレートするためにデータベース

全体が削除され、14:16:15 にデータベース全体が失われています。

データベースのリカバリに必要なインターフェイスは、Replication Managerだけで済

みます。Replication Manager は、SQL Server、Windows Server、VMware、EMC スト

レージ、RecoverPoint など、あらゆるレベルのソリューションスタックのすべての操

作を連携させて、リカバリプロセスをまとめることができます。ウィザード方式のイン

ターフェイスは、ビジネスクリティカルなトランザクションデータベースをリカバリする

場合に便利です。このインターフェイスにより、すべてのベストプラクティスに従って

リストアを正常に実行できます。このソリューションでは、リモートサイトから CRR コ

ピーを使用してユーザーデータベースを効果的にリストアし、時計を災害発生の 1秒前（14:15:59）に戻しました。

Replication Manager は指定時刻どおりにデータベースのイメージにアクセスして

データベースをリカバリしたため、RPO は 1 秒でした。EMC はデータベースのすべて

のファイルとファイルグループをリカバリするように選択しました。

Replication Managerでリカバリプロセスの終了までにかかった時間は3分 26秒で

す。データベースは接続解除されているため、データベース管理者は完全性を確保

した状態でデータベースを接続してからユーザーアクセスを許可できます。

データベースが接続されると、オンラインユーザーが 14:21:45 にデータにアクセス

できるようになり、ビジネスユニットがバックアップされました。

このソリューションでは、1 秒の RPO と 4 分未満の RTO が実現しました。リカバリの

レベルが非常に強力なため、厳密な SLA（Service Level Agreement）へのコミットが

可能になります。そのため、ビジネスクリティカルで高度なトランザクション型 OLTPデータベースを最小限の手順で簡単かつ迅速にリカバリできます。

VMware vCenter SRM

このセクションでは、保護を実装する際に VMware vCenter SRM に必要な構成につ

いて説明します。




vCenter SRM と RecoverPoint の統合

vCenter SRM では、災害復旧の RTO を短縮し、ブロックベースのレプリケーションを

利用して災害復旧の RPOを縮小します。RecoverPoint SRA は、vCenter SRM要求を

適切な RecoverPoint アクションにマップするのに使用されます。

vCenter SRMと RecoverPointは、仮想マシンのリカバリプロセスを自動化して、ワンタッチ程度にシンプルにします。ユーザーは RecoverPoint コンソールを操作する必

要はありません。vCenter SRM によってフェイルオーバープロセス全体が自動化さ

れます。RecoverPoint と vCenter SRM の統合は、RecoverPoint SRA（Storage Replication Adapter）によって制御されます。

RecoverPoint は、災害復旧サイトで本番 LUN からリモートレプリカにすべての変

更をレプリケートします。RecoverPoint SRA は、本番サイトと災害復旧サイトで

vCenter Server と vCenter SRM プラグインを実行している同じサーバーにインストー

ルされます。RecoverPoint SRA は、レプリケーションに RecoverPoint を使用すること

で、フェイルオーバーやフェイルオーバーテストなどの vCenter SRM 機能をサポート

します。

vCenter SRM によって管理されるコンシステンシグループの構成

コンシステンシグループを作成し、vCenter SRM をインストールしたら、vCenter SRMによって管理されるようにコンシステンシグループを構成する必要があります。こ

れを行うには、図 38 に示されているように、 RecoverPoint Management Application のポリシー設定を使用します。

図 38. vCenter SRM によって管理されるコンシステンシグループの構成


104

vCenter SRM ソリューション保護

この例では、vCenter SRM が SQL Server 仮想マシンを保護しています。Replication Manager は、本番サイトでのローカル保護、マウント、リストアに必要です。災害復

旧サイトには、それぞれ独自の vCenter および Active Directory 仮想サーバーがあ

るため、これらをレプリケートするための要件はありません。

図 39 は、vCenter SRM が SQL Server をどのように保護するかを示しています

（RecoverPoint 統合を使用し、必要な手順を自動化）。

図 39. 本番サイトでの vCenter SRM による保護処理手順

vCenter SRM は、本番サイトとリカバリサイトの両方に構成する必要があります。

本番サイトには、次の構成が必要です。

• vCenter Server 間の vCenter SRM 通信を確立するための接続

• レプリケートされたデバイスを検出するためのアレイマネージャー

• サイト固有のフォルダー、ネットワーク、リソースマッピングのためのインベン

トリマッピング

• リカバリ用の各データストアに仮想マシンを編成するための保護グループ

リカバリサイトでは、リカバリプロセスの自動ランブックを作成して、リカバリプランを構成する必要があります。

vCenter SRM 保護グループの構成

RecoverPoint コンシステンシグループは、本番サイトと災害復旧サイトにある SAN接続型ストレージボリュームのデータセットです。vCenter SRM 保護グループは、

（テストおよび実際のフェイルオーバー中に）一緒にフェイルオーバーする仮想マ

シンのグループです。




フェイルオーバーの実行時に、vCenter SRM は保護グループ内のすべての仮想マ

シンの LUN での操作を RecoverPoint に指示しますが、RecoverPoint は一緒にレプ

リケートされる LUN のグループの定義にコンシステンシグループを使用します。

接続、アレイマネージャー、インベントリマッピングを適切に構成したら保護グルー

プを構成する必要があります（図 40 を参照）。

図 40. vSphere Client での保護グループの構成

このソリューションでは、4 つの保護グループが作成されています。2 つが各 TPCE仮想マシン用で、2 つが TPCH 仮想マシン用です。各保護グループ内では、仮想マ

シンごとにリカバリの優先度を指定できます。

仮想マシンの起動の優先度の変更

リカバリですべての仮想マシンを同時に再起動しない場合を想定し、EMC は、業務

に最も重要な TPCE 仮想マシンの優先度を高く設定し、TPCH 仮想マシンの優先度を

低く設定しました（図 41 を参照）。

図 41. 仮想マシンのリカバリの優先度の選択


106

リカバリサイトの IP アドレスのカスタマイズ

別のデータセンターにフェイルオーバーする場合に、インフラストラクチャが異なる

ためにホスト IP 設定の調整が必要になることがあります。構成全体をフェイルオー

バーする場合は、複数の仮想マシンの設定更新も必要になることがあります。

vCenter SRM には、リカバリされた仮想マシンの IP 設定を自動的に更新するための

一括 IP カスタマイズユーティリティ（dr-ip-customizer.exe）が用意されています。こ

のユーティリティは、vCenter SRM フェイルオーバーの対象として構成されたすべて

の仮想マシンの IP 設定が含まれる CSV ファイルを生成します。このファイルを編集

してリカバリサイトの IP設定を指定し、ユーティリティを再度実行して、新しい設定を

リカバリサイトの vCenter Server にアップロードできます。

このソリューションでは、次のようにユーティリティを使用してリカバリサイトの IP 設

定を更新しました。

1. リカバリサイトの vCenter Server にログオンします。

2. 次に示すように、CSV ファイルの名前と場所を指定して、

dr-ip-customizer.exe ユーティリティを実行します。

3. CSV ファイルを編集して、リカバリサイトの仮想マシンの IP 設定を指定しま

す。次の図は、このソリューションで編集されたファイルを示しています。

4. 次に示すように、ユーティリティを実行して新しい設定をリカバリサイトの

vCenter Server にアップロードします。

注：保護グループを削除または再作成した場合は、このプロセスを繰り返して IP のカスタ

マイズを再適用する必要があります。

vCenter SRM リカバリプランの構成

リカバリプランは、リカバリサイトにあり、仮想マシンのリカバリ手順を定義します。

vCenter SRM リカバリプランでは、RecoverPoint イメージアクセス機能を使用して、

フェイルオーバープロセスを無停止でテストできます。これにより、セカンダリイメー

ジの整合性と有効性が確保されます。

災害復旧計画のテストは、リカバリの信頼性を確保するために不可欠です。従来は、

複雑で時間がかかり、コストもかかる作業でした。vCenter SRM を使用することで、

これらの障害の克服が可能になりました。リカバリプランを実際に何回もテストし、

リカバリ中のエラーの一般的な原因を排除できます。

複数の保護グループを単一のリカバリプランに含めると、関連するすべての仮想マ

シンをそのリカバリプランの一部としてリカバリできます。図 42 は、リカバリプラン

の実行の最初の手順を示しています。




図 42. リカバリプランの実行

優先度の高い仮想マシンは、図 43に示すように、同じリカバリプランの他の仮想マ

シンよりも先にリカバリ（再起動）されています。

図 43. 仮想マシンのリカバリの優先順位づけ

フェイルオーバープロセスが終了すると、vCenter SRMにリカバリのサマリーレポー

トが表示されます（図 44 を参照）。


108

図 44. フェイルオーバーのサマリーレポート

RecoverPoint CLR を使用した vCenter SRM フェイルオーバーの構成

vCenter SRM がリカバリプランを正常に完了し、すべてのシステムが再稼働したら、

手動による次の手順を完了して、災害復旧サイトから本番サイトへのフル CRR レプ

リケーションを再開します。

1. グループがメンテナンスモードになっており、RecoverPoint で管理され、

SRM で監視されていることを確認します。

2. RecoverPoint リモートレプリカコピーを災害復旧サイトに本番として設定し

ます（図 45 を参照）。

図 45. 本番コピーとしての RecoverPoint リモートレプリカコピーの設定

3. CDP はフェイルオーバー前に本番サイトにもあったため、図 46 に示すよう

に、本番サイトのレプリカデータコピーのいずれかを削除します。




図 46. ローカルレプリカの削除

CRR コピーを本番コピーとして設定すると、本番サイトで削除するデータのコピーを

選択するように求められます。CCR の対象として本番コピーを使用するか CDP コ

ピーを使用するかを決定し、不要なコピーを削除します（図 47 を参照）。

図 47. データの不要なコピーの削除

RecoverPoint CLR 構成の一部として、本番サイトは本番と CDP の両方のデータコピーをホストしていました。この新しい RecoverPoint レプリケーション構成は CRR で

あるため、本番サイトに維持できるデータのターゲットコピーは 1 つのみです。

これらの設定は、災害復旧サイトの仮想マシンのリカバリには影響を与えません。

これらはRecoverPointに固有で、新しいCRR関係を本番サイトに構成するのに必要

です。

災害によって本番サイトにアクセスできなくなった場合は、本番サイトとの通信がリ

ストアされるまでは、これらの手順は不要です。

リカバリ後も本番サイトと通信が可能な場合は、これらの手順をRecoverPoint CLIでスクリプト化できます。管理されたフェイルオーバーの一環で、これらのコマンドをポ

ストスクリプト操作として vCenter SRM リカバリプランに含めることができます。

コンシステンシグループの再構成の結果は、図 48 に示すように、災害復旧サイト

から本番サイトへの簡単な RecoverPoint CRR レプリケーションになります。


110

図 48. コンシステンシグループの再構成

フェイルバックが完了すると、本番サイトが稼働を再開し、CDP コピーの完全な再構

成と再同期が必要になります。

注：必要に応じて、CDP を災害復旧サイトで構成し、この構成で維持できます。

emc ストレージ使用 microsoft sql server · ホワイト ペーパー. emc...

Documents

emc ストレージ使用 microsoft sql server · ホワイトペーパー. emc...