Celerra iSCSI LUNからのiSCSIブート

(1)

VMware ESX Server上のMS SQL Serverの

EMCソリューション、

EMC CLARiX CX3シリーズFCP

ベスト・プラクティス

USホワイトペーパー翻訳版

(2)

Copyright © 2007 EMC Corporation.不許複製 2007 年 11 月発行 EMC Corporation は、この資料に記載される情報が、発効日時点で正確であるとみなしています。この情報は、予告なく変更されることがあります。この資料に記載される情報は、「現状有姿」の条件で提供されています。EMC Corporation は、この資料に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、商品性や特定の目的に対する適応性に対する黙示の保証はいたしません。この資料に記載される、いかなる EMC ソフトウェアの使用、複製、頒布も、当該ソフトウェア・ライセンスが必要です。

最新の EMC 製品名については、EMC.com で EMC Corporation の商標を参照してください。他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または登録商標です。パーツ番号H4069-J

(3)

このドキュメントについて...4

Chapter 1 SQL Serverベスト・プラクティス ... 5

全般的なパフォーマンス ... 5 推奨事項 1：ストレージ容量ではなく、パフォーマンスを考えて計画する... 5 推奨事項 2：クラスタまたはVMHAを使用して高可用性を確保する... 5 推奨事項 3：SQL ServerをActive Directoryのメンバサーバにする... 5 推奨事項 4：ページをメモリに保持できるようSQL Serverを設定する... 5 推奨事項 5：Windowsファイル高速初期化機能を有効にする... 6 推奨事項 6：データベース・ファイルとログ・ファイルで物理スピンドルを共有しない... 6 推奨事項 7：データベースのファイル・サイズと自動拡張単位を適切に設定する... 6 推奨事項 8：ワークロードに基づいてデータベースのファイルグループを計画する... 7 推奨事項 9：tempdbの場所、レイアウト、サイズを計画する... 7 推奨事項 10：プロセッサおよびメモリのデフォルト設定を使用する... 8 推奨事項 11：フェイルオーバー対応アプリケーションを使用する... 8 推奨事項 12：Microsoft SQL Server 2005 サーバでハイパースレッディングを無効にする ... 8 バックアップおよびリストア ... 8 推奨事項 13：ポイント・イン・タイム・リカバリのデータベース・ログ・バックアップを使用する ... 8 推奨事項 14：システム停止を最小限に抑えたバックアップスケジュールを計画する（可能な場合は必ず） ... 9 推奨事項 15：データベース・復旧・モデルの変更時にフル・バックアップを行う... 9 データ保護：データベース・ミラーリング ... 9 推奨事項 16：MSCSまたはVMHAをプリンシパルで使用する場合はウィットネス・サーバを使用しない ... 9 推奨事項 17：ミラー・サイトで高I/Oレベルを計画する ... 9 推奨事項 18：データベース間の一貫性は必要ない ... 9 推奨事項 19：他の方法を使用してSQL Serverオブジェクトと同期させる... 10 推奨事項 20：追加情報の資料を調べる ... 10

Chapter 2 ESX Server 上の Microsoft Windows Server 2003 のベスト・プラクティス ... 11

推奨事項 1：VMwareで承認されているハードウェアを使用する... 11

推奨事項 2：最新の検証済みドライバを使用する ... 11

推奨事項 3：MSCSを使用するときは時々パッシブ・ノードをリブートする... 11

推奨事項 4：クラスタ・ハートビート接続の専用VLANを使用する... 11

Chapter 3 ESXインフラストラクチャのベスト・プラクティス ... 12

推奨事項 1：Virtual Center Serverを使用する ... 12

推奨事項 2：VC Serverの可用性を高くする ... 12

Chapter 4 ネットワークのベスト・プラクティス ... 13

推奨事項 1：Gigabit EthernetスイッチをVLAN機能とともに使用する... 13 推奨事項 2：GbE接続にはCAT6 を使用する ... 13 推奨事項 3：ネットワークの速度と二重構成を設定する ... 13

Chapter 5 ストレージ・システムのベスト・プラクティス ... 14

推奨事項 1：容量ではなくパフォーマンスを考えてストレージ・レイアウトを計画する... 14 推奨事項 2：できるだけVMFSファイル・システムを使用する... 14 推奨事項 3：VIクライアントを使用して新しいVMFSボリュームを作成する... 14 推奨事項 4：最適なパフォーマンスを得るために、DISKPARTを使用してWindowsのボリュームを配置する .... 15 推奨事項 5：NTFSアロケーション・ユニットを 64 KBに設定する ... 16 推奨事項 6：LUNの使用率が 80%を上回らないようにする ... 16

Chapter 6 CLARiXのベスト・プラクティス ... 17

(4)

推奨事項 1：CLARiXプリフェッチの設定値を上げて、リストア・パフォーマンスを向上させる ... 17 推奨事項 2：バランスを考えてLUNを設計する ... 17 推奨事項 3：LUNに名前を付ける ... 17 推奨事項 4：最新の検証済みHBAドライバを使用する ... 17 推奨事項 5：物理サーバでEMC PowerPathを使用する ... 17

Appendix A

パフォーマンスの監視と調整 ...18

Windowsのパフォーマンス監視 ... 18

Appendix B

RAIDグループの計画... 22

RAIDレベルの属性 ... 22 必要なパフォーマンスの見積もり ... 24 ディスク・スピンドル要件の計算 ... 26 まとめ ... 27

Appendix C

ファイルグループ計画...29

Tempdb ... 29 ユーザー・データベース ... 29 ログ・ファイル ... 29

(5)

このドキュメントについて

このドキュメントでは、Microsoft SQL ServerをEMC CLARiXで使用するためのソリューション検証で確認されたベスト・プラクティスを概説します。目的このドキュメントの情報は、ソリューション構築、ホワイト・ペーパー、ベスト・プラクティス・ドキュメント、またはトレーニングの基盤として使用できます。また、テクニカル・サービスや販売店など他のEMC関連の企業がテクニカル・サービス・キットまたは販売キットを作成する際にも、使用することができます。 対象読者

このドキュメントは、EMC CLARiXシステムを使用してMicrosoft SQL Server 2005を実装することを考えているIT管理者、データベース管理者、データ設計者、システム・エンジニアなどを対象としています。

また、対象読者にMicrosoft SQL ServerとEMC CLARiXの機能および用語に関する一般的な知識があることを前提としています。

適用範囲

このドキュメントは、EMCコマーシャル・ソリューション実習で構築およびテストされたEMCソリューションに対する推奨事項のリソース・ガイドとして使用されます。実装方法やサイジングについては、このドキュメントでは取り上げていません。このソリューションで検証されたテストの詳細については、「EMC Solutions for Microsoft SQL Server 2005 on VMware ESX Server EMC CLARiiON CX3 Series FCP - Validation Test Report」を参照してください。

Microsoft SQLソリューションを考案するときは、適切なパフォーマンス、高可用性、効率的な災害復旧メカニズムを確保しながら、スケーラビリティをサポートするソリューションを計画することが重要です。このドキュメントはさまざまな状況に対応できます。また、EMC CLARiXでMicrosoft SQL Server 2005ストレージを構成するときの推奨事項のリソース・ガイドとして活用できるよう作成されています。 関連資料 詳細については、以下のドキュメントを参照してください。これらのドキュメントには、ログイン資格情報に応じてアクセスできます。アクセスできない場合は、EMC担当者にご連絡ください。 ♦ 「EMC Solutions for Microsoft SQL Server 2005 on VMware ESX Server EMC CLARiiON CX3 Series

FCP - Reference Architecture」

♦ 「EMC Solutions for Microsoft SQL Server 2005 on VMware ESX Server EMC CLARiiON CX3 Series FCP - Validation Test Report」

(6)

Chapter 1 SQL Serverベスト・プラクティス

この章では、Windows Server 2003 で Microsoft SQL Server 2005 を構成する際の推奨事項を紹介します。

全般的なパフォーマンス

推奨事項 1：ストレージ容量ではなく、パフォーマンスを考えて計画する

Microsoft SQL Serverのストレージを計画するときの間違いで最も多いのが、パフォーマンス、つまり1 秒あたりのI/O（IOPS）ではなく、ストレージ容量を優先してしまうことです。ディスク・テクノロジーの進歩により、ディスク・ドライブのストレージ容量は、IOPSが向上するよりも格段に速いペースで（約1000倍）増加しています。ほとんどの場合、パフォーマンスを考えてシステムを計画すれば、ストレージ容量の要件を満たすことが出来ます。したがって、IOPS要件を満たすことはMicrosoft SQL Serverストレージ構成を計画する際の基準となります。ストレージ容量（GB）は、IOPS要件を満たした上で検討するようにしてください。

推奨事項 2：クラスタまたは VMHA を使用して高可用性を確保する

クラスタはノードと呼ばれるサーバのグループで、可用性に優れた単一のシステムを提供し、Microsoft SQL Server 2005などのアプリケーションをホストします。Microsoft Windows Server 2003 Enterprise Edition 64ビットR2は最大8ノードのクラスタをサポートします。ソリューションは2ノードのクラスタ構成で検証されました。

Microsoftクラスタは可用性の高い環境を提供し、ハードウェア、オペレーティング・システム、デバイス・ドライバ、またはアプリケーションによるMicrosoft SQL Server 2005サーバのFailを防ぎます。障害によってクラスタのノードのいずれかが使用できなくなると、サービスが他のノードにフェイルオーバーし、そのノードが障害ノードの代わりにサービスを提供し始めます。すべてのクラスタ構成が仮想マシンでサポートされているわけではないことに注意してください。このドキュメントが発行された時点では、VMwareがサポートするのは32ビットMicrosoftクラスタのみです。64ビットのクラスタについては、近い将来サポートされる予定です。その他の選択肢としては VMwareのもつVMHA機能があります。この機能を使用すると、Microsoftクラスタリングと同様のレベルの高可用性を実現できます。

推奨事項 3：SQL Server を Active Directory のメンバサーバにする

SQL Serverのセキュリティおよびアカウントは、Active Directoryドメインのユーザー・アカウントで統合セキュリティを使用して管理することをお勧めします。この方法を使用すると、複数のレベルでセキュリティが向上し、ユーザー管理も容易になります。 SQL Serverは、特別な場合を除き、ドメイン・コントローラにはしないでください。SQL Serverをドメイン・コントローラにするとオーバーヘッドが増加し、高い確率でSQL Serverのパフォーマンスに悪影響を及ぼします。

推奨事項 4：ページをメモリに保持できるよう SQL Server を設定する

Microsoft SQL Serverは、サーバの現在の状態に基づいてメモリの割り当てと解放を動的に行い、メモリ・プレッシャやスワップを防ごうとします。ただし、プロセスが大量のメモリを突然使用しようとすると、SQL Serverの反応が追いつかず、OSがSQL Serverのメモリの一部をディスクにスワップすることがあります。残念ながら、ディスクにスワップされたメモリには、新しく作成されたメモリ・プ

(7)

レッシャに応じてメモリの使用を減らすために、SQL Serverが解放しようとしているメモリの一部が含まれていることがよくあります。 SQL Serverをメモリスワップできないように設定することをお勧めします。この機能は「RAMでのページ・ロック」として知られています。この処理を実行するには、Microsoft SQL Serverサービスが実行されているアカウントに「メモリ内のページのロック」ユーザー権限が必要です。

推奨事項 5：Windows ファイル高速初期化機能を有効にする

Microsoft SQL Serverがファイルを作成または拡張するときは、そのファイルを初期化する必要があります。前のバージョンのSQL Serverにはオプションが1つしかなく、スペースにオール0を書き込むことでスペースを初期化していましたが、ファイルのサイズが大きくなると、これがパフォーマンスにかなりの影響を及ぼすことがありました。Microsoft SQL Server 2005にはファイル高速初期化機能が用意されており、ファイル・エンド・ポインタを設定するだけで初期化が完了します。この操作はほぼ瞬間的に行われ、本番システムに対するファイル拡大の影響を最小限に抑えられます。ファイル高速初期化機能はOSレベルで有効にします。この機能を有効にするには、Microsoft SQL Serverサービスが実行されているアカウントに「ボリューム・メンテナンス・タスクの実行」ユーザー権限が必要です。デフォルトでは、この権限は管理者に対して付与されています。

推奨事項 6：データベース・ファイルとログ・ファイルで物理スピンドルを共有しない

データベース・データ・ファイルとログ・ファイルが同じ物理スピンドルを共有しないようにすることを強くお勧めします。これは、複数ドライブが失われることによるデータ消失を防ぎ、また、パフォーマンスを向上させるのにも役立ちます。

推奨事項 7：データベースのファイル・サイズと自動拡張単位を適切に設定する

Microsoft SQL Server 2005では、データ・ファイルとログ・ファイルがいっぱいになったとき、両方とも自動的に拡張します。ただし、これはデータベースのサイズを変更する手段ではありません。ファイル・サイズを適切に設定し、システム使用率が低いときに計画的に手動での拡張がベスト･プラクティスです。自動拡張機能は、予期せぬデータ拡大が発生した場合に、ファイルがいっぱいにならないように、そしてデータベースが読み取り専用にならないようにするための安全策としてのみ使用するようにしてください。データベースのファイルが拡大すると、パフォーマンスに影響があります。この影響は、ファイル高速初期化機能で最小限に抑えられますがゼロにはなりません。また、自動拡張の単位は、パフォーマンスへの影響を最小限に抑えられるよう拡張時間を短く設定し、ファイルのフラグメンテーションが発生するような細かな割り当てが何回も行われないようにします。ファイル・サイズの増分単位を増やすと、通常は、データベースのパフォーマンスに影響を及ぼします。したがって、ファイルの拡張は、データベースのアクティビティが少ないときに手動で行うことをお勧めします。ログ・ファイルも問題を抱えています。物理ログ・ファイル内には仮想ログ・ファイルがあり、仮想ログ・ファイルは物理ログ・ファイルの拡張単位を超えることができないからです。したがって、ログ・ファイルが1 MB単位で拡張するように設定されている場合は、仮想ログ・ファイルの拡張単位も 1 MBを超えることができません。ファイルが拡張されると、前述したようにパフォーマンスに影響を及ぼします。また、この制限により、あるトランザクションを完了できない可能性もあります。パフォーマンスへの影響を考慮し、すべてのファイルの拡張単位をパーセンテージではなくMBまたは GB単位で指定することをお勧めします。これにより、ファイルのサイズ変更からファイル拡大を予測

(8)

できます。また、自動縮小は有効にしないでください。やむを得ない場合を除き、ファイルは縮小するべきではありません。やむを得ない場合は手動で縮小してください。

推奨事項 8：ワークロードに基づいてデータベースのファイルグループを計画する

SQL Serverには、データベース・テーブルやディスク上の他の構造をレイアウトするためのデータ設計者向けオプションが多数用意されています。この動作を制御する主な構造がファイルグループです。データベース構造はファイルグループに割り当てられます。ファイルグループはディスク上にファイルに配置し、データを格納します。これらのデータ・ファイルの配置は、データベースのI/Oパフォーマンスには極めて重要です。どの方法でファイルグループを設定するのが最適であるかは、データベース・ワークロードによって異なります。さまざまなデータベース・ワークロードが物理ストレージ構造の選択に及ぼす影響については「付録B」を、ファイルグループを計画する方法については「付録C」を参照してください。

推奨事項 9：tempdb の場所、レイアウト、サイズを計画する

デフォルトでは、tempdbデータベースはかなり小さく、モデル・データベースの特徴を引き継いでいます。このtempdbは、Microsoft SQL Serverサービスを開始するたびに削除され、初期パラメータで再作成されます。したがって、tempdbが最初128 MBで、操作中に4 GBに自動拡張されたとしても、再起動すると128 MBに戻ります。tempdbは再度自動拡張されることになり、これはデータベースのパフォーマンスに影響を及ぼします。この影響を最小限に抑えるために、tempdbのサイズは環境に合わせて調整することをお勧めします。一番簡単なtempdbデータベースのサイズ調整方法を次に紹介します。 1. SQL Serverインスタンスにあるデータベースに対して妥当なサイズでtempdbを開始します。たとえば、1 GBのtempdbデータベースは10～100 GBの合計インスタンス・データベースに対しては妥当ですが、1 TBのデータベースには適していません。まずは、同一インスタンスのデータベースのサイズを合計した値の1～10%のサイズから開始するとよいでしょう。 2. 自動拡張単位を設定します。tempdbで深刻なフラグメンテーションを発生させずに拡張できる値を設定してください。tempdb初期サイズの10～20%の範囲内で自動拡張サイズを設定することをお勧めします。拡張パラメータのパーセンテージは使用せず、拡張パーセンテージに対応するMB値を計算し、自動拡張サイズとして設定します。また、ファイル高速初期化機能が有効になっていることを確認します。 3. tempdbデータベースのサイズと使用率を定期的にチェックして、このデータベースが大幅に拡大していないかどうかを確認します。 4. シャットダウン前のサイズに近い値でtempdbデータベースのサイズを再セットします。たとえばtempdbデータベースが1 GBから5 GBに拡大した場合は、5 GBから開始されるように値を再セットするとよいでしょう（このサイズが大きすぎない場合）。また、ユーザー・データベースの合計が10 GB、tempdbが15 GBの場合、このtempdbは大きすぎます。異常が重なり、tempdbが拡張した可能性があります。このような場合は、現在のサイズよりも小さなサイズから開始するように設定します。tempdbが想定したサイズよりも繰り返し大きくなる場合、そのサイズは単にワークロードに必要なサイズであると判断できます。ここから、データベース管理者は、データベースが大きくなりすぎている原因を診断し、それが妥当かどうか、または調整が必要かどうかを判断します。 tempdbとユーザー・データベース・アクティビティが互いに物理ディスク競合を引き起こさないよう、 tempdbは別のスピンドルに配置することをお勧めします。スピンドルの数は、ユーザー・データベースのストレージ設計に適用される原則に従って個別に決定されます。

(9)

推奨事項 10：プロセッサおよびメモリのデフォルト設定を使用する

Microsoft SQL Serverを最初にインストールすると、調整可能なパラメータのほとんどが自動に設定されます。SQL Server専用のサーバでは、これらのパラメータはデフォルト値である自動のままにしておきます。唯一変更する必要があるのは、他のワークロードが同じサーバで実行されている場合、またはデフォルト設定を使用すると問題が発生する場合です。デフォルトでは、SQL Serverは標準の優先度で実行され、システム内のすべてのプロセッサを使用可能にします。また、メモリ・プレッシャの生成開始を認識するまで、RAMを必要なだけ使用します。そして、他のプロセッサがメモリを消費し始めたら、それに従ってメモリの占有領域を減らし始め、スワップの可能性を減らします。

推奨事項 11：フェイルオーバー対応アプリケーションを使用する

MSCSクラスタリング、VMHA、データベース・ミラーリングなどのテクノロジーを使用して、Microsoft SQL Serverのフェイルオーバーが発生すると、すべてのデータベース接続が失われ、「処理中」のトランザクションがロール・バックされます。データ消失を最小限に抑えるため、再接続/再試行ロジックを持つフェイルオーバー対応アプリケーションを使用することをお勧めします。これにより、フェイルオーバーが発生するとアプリケーションが再接続を試みます。適切に再接続できると、前にロール・バックされたトランザクションが再試行されます。

推奨事項 12：Microsoft SQL Server 2005 サーバでハイパースレッディングを無効にする

Intelのハイパースレッディング・テクノロジーを使用すると、マルチスレッド・オペレーティング・システムから単一物理プロセッサが、2つの論理プロセッサのようにみえます。この機能が組み込まれているプロセッサは、複数スレッドでCPUリソースを共有します。理論上は、これによりエンタープライズ・サーバの応答時間を短縮し、CPU処理能力を追加することで、より大きなワークロードを処理できるようになるはずです。しかし、テストでは、ハイパースレッディング機能がMicrosoft SQL Server 2005ベース・プロセッサの負荷の多くに悪影響を及ぼすことを示しました。ハイパースレッディング機能は、特にMicrosoft SQL Server 2005ワークロードのパフォーマンスに役立つことが証明されていない限り、無効にすることをお勧めします。このハイパースレッディング機能は、プロセッサ・アフィニティのアプリケーションまたは他のソフトウェアではなく、ハードウェア（BIOS設定）レベルで無効にする必要があります。詳細については、「http://blogs.msdn.com/slavao/archive/005/11/12/492119.aspx」を参照してください。

バックアップおよびリストア

推奨事項 13：ポイント・イン・タイム・リカバリのデータベース・ログ・バックアップを使用す

る

一連のログ・バックアップに組み合わされたデータベース・バックアップを使用すると、トランザクションレベルで、データベースを指定ポイントにリストアできます。これは、Microsoft SQL Serverで実現できる最高レベルの細かい単位でのリストアです。フル・バックアップを取るのに、SQL Server ネイティブのバックアップ機能、サードパーティのツール、またはEMC® Replication Manager（RM）などのスナップショット・ツールが使用されている場合がありますが、RMは、トランザクション・ログ（SQL Server用語）のバックアップを実行できません。ポイント・イン・タイム・リカバリを実現するには、RMフル・バックアップとSQL Serverログ・バックアップを組み合わせる必要があります。

(10)

推奨事項 14：システム停止を最小限に抑えたバックアップスケジュールを計画する（可能な場合

は必ず）

バックアップを開始すると、Microsoft SQL Server 2005はチェックポイントを行って、すべてのダーティ・ページをディスクにフラッシュします。大量のRAM（ほとんどがダーティ・ページ）があり、I/O 負荷が高いマシンでこの処理が実行されると、バックアップにかなりの時間が、場合によっては2～20 倍の時間がかかることがあります。バックアップは、システムの負荷が少ない時間に行うようスケジュールしてください。また、RAIDグループを設計するときはバックアップ・オーバーヘッドを考慮することをお勧めします。

推奨事項 15：データベース・復旧・モデルの変更時にフル・バックアップを行う

ユーザーがデータベースの復旧モデルをシンプルまたは一括ログに変更してから、フルに戻すことがあります。フルに対する変更は、フル・データベース・バックアップが実行されるまで有効になりません。したがって、復旧モデルの変更後ではなく変更前にバックアップを取ると、シンプルからフルに変更されたデータベースのデータが失われる可能性があります。データベースでは、フル・バックアップが行われるまでフル・リカバリ・モードでのログ保存が開始されません。また、ログ・チェーンを断つための処理が何も行われなければ、フル・リカバリ・モードは維持されます。たとえば、BACKUP LOG WITH TRUNCATE ONLYコマンドが発行されると、データベース・ログはフル・リカバリ・モードでは動作しなくなります。ログ・チェーンが断たれるからです。ログをフル･リカバリ・モードに戻すには、他のフル・データベース・バックアップを取得するしかありません。

データ保護：データベース・ミラーリング

推奨事項 16：MSCS または VMHA をプリンシパルで使用する場合はウィットネス・サーバを使用

しない

MSCSまたはVMHAで高可用性モードで実行されている場合（ウィットネスを使用して同期）、フェイルオーバーが発生すると、データベースは、クラスタのフェイルオーバーが完了する前にミラーにフェイルオーバーする可能性があります。したがって、MSCSまたはVMHAを使用している場合は、高度な保護モード（ウィットネスを使用せず同期）または高パフォーマンス・モード（非同期）を使用することをお勧めします。

推奨事項 17：ミラー・サイトで高 I/O レベルを計画する

データベース・ミラーリングがミラーでトランザクションをコミットすることにより発生する書き込みI/Oは、プリンシプルで発生する書き込みI/Oよりもかなり多いため、データ負荷によっては、プリンシパルよりもミラーの方が多くのストレージ・リソースを必要とする場合があります。一部のテストでも、ミラー・サイトがプリンシパル・サイトの4倍のI/Oを処理しなければならない可能性があることを示しました。したがって、ミラー・サイトでデータ保護およびリカバリ計画に影響を及ぼすかもしれないパフォーマンスのボトルネックを監視することをお勧めします。

推奨事項 18：データベース間の一貫性は必要ない

データベース・ミラーリングでは、データベース内での一貫性のみが維持されます。複数のデータベース間の一貫性を維持するためのメカニズムはありません。データベース間の一貫性がアプリケーションに必要な場合、その環境では、データベース・ミラーリング・テクノロジーを使用してデータを保護することはお勧めできません。

(11)

推奨事項 19：他の方法を使用して SQL Server オブジェクトと同期させる

データベース・ミラーリングは単一データベースの領域内でのみ動作し、masterdbのようなシステム・データベースでは使用できません。したがって、データベース・ミラーリングとは別の方法を使用して、データベース・レベルの上のユーザー・アカウント、ジョブ、セキュリティ設定、システム・データベースを、プリンシプルからミラー・システムに同期させる必要があります。これは、定期的に実行されるSQL Serverジョブ、またはこの処理のためのサードパーティ・ツールを使用して行うことができます。どちらの方法でも、関連するオブジェクトも同じように同期させる必要があることを認識することが重要です。

推奨事項 20：追加情報の資料を調べる

詳細については、ホワイト・ペーパー「Microsoft SQL Server Database Mirroring」を参照してください。

(12)

Chapter 2 ESX Server 上の Microsoft Windows Server 2003 のベス

ト・プラクティス

この章では、Microsoft SQL Serverインスタンス用にWindows Server 2003を構成する際の推奨事項を紹介します。

推奨事項 1：VMware で承認されているハードウェアを使用する

ハードウェア互換性リストに示されているハードウェアを使用すれば、互換性に関する問題が発生する可能性が減り、VMwareが提供するサポート・レベルが強化されます（万一問題が発生した場合）。ゲスト・オペレーティング・システムから見えるハードウェアは、仮想化された環境です。したがって、ホストのハードウェアは、ゲストOSではなくESXサーバで使用できるようVMwareによって承認されていることが重要です。

推奨事項 2：最新の検証済みドライバを使用する

最適なパフォーマンスと安定性を確保するため、ESXと使用する際の妥当性が検査されている最新のベンダー・ドライバをインストールすることをお勧めします。

推奨事項 3：MSCS を使用するときは時々パッシブ・ノードをリブートする

構成の変更、特にディスク構成の変更は、リブートが完了するまでパッシブ・ノードで検出されないことがあります。パッシブ・ノードがこれらの変更を検出しないと、クラスタ・フェイルオーバーが成功しない場合があります。

推奨事項 4：クラスタ・ハートビート接続の専用 VLAN を使用する

MSCSが使用されている場合は、クラスタ・ハートビート・ネットワークを他のネットワークから物理的に隔離することをお勧めします。たとえば、2重クラスタでは、2台のマシン間にはハートビート・ネットワークとしてクロス・ケーブルを使用するのが一般的です。 ESXでは、この設計は、専用仮想スイッチを作成し、クラスタに関連するVMを持つ各ホスト上の専用ハードウェアNICを使用することにより実現します。

(13)

Chapter 3 ESXインフラストラクチャのベスト・プラクティス

この章では、ESXインフラストラクチャを強化するためのコンポーネント使用に関する推奨事項を紹介します。

推奨事項 1：Virtual Center Server を使用する

Virtual Center Serverの機能が増え、仮想データ・センターの管理が容易になりました。VC Serverは、 VMHA、DRS、VMotionなどの複数のVM機能を適切に機能させるために重要です。また、VC Server を使用すると、次の機能が使用しやすくなります。 ♦ データ・センターを使用したVMテンプレートの作成と導入 ♦ 履歴およびリアルタイムでのESXホストおよびVMのパフォーマンス・トラッキング ♦ VMとホストのマッピングの追跡 ♦ VMFSボリュームの配列を含む、新しいストレージの初期化 ♦ その他多数の機能

推奨事項 2：VC Server の可用性を高くする

VMware ESX実装で最も重要なのはVirtual Centerサーバとライセンス・サーバ（組み合わせてVC Server と呼ばれます）の組み合わせです。通常は同じホストにインストールされているこの2つのコンポーネントがなければ、ESX機能（DRS、VMHA、VMotionなどを行う機能を含む）のほとんどが失われ、単にVMを起動するだけの存在になる可能性があります。したがって、VC Serverが可用性に優れていることが重要です。これを実現するための最も容易で、かつ安定性に優れた方法は、VC ServerをMSCS クラスタ内の物理マシンで実行することです。また、VC Serverが使用するMicrosoft SQL Serverデータベースが、高可用性を確保しながら実装されていることも重要です。

(14)

Chapter 4 ネットワークのベスト・プラクティス

この章では、Microsoft SQL Server 2005用にIPネットワークを構成する際の推奨事項を紹介します。

推奨事項 1：Gigabit Ethernet スイッチを VLAN 機能とともに使用する

最適なパフォーマンスを得るには、バーチャルLAN（VLAN）を設定して他の種類のトラフィックをセグメント化できるGbE（1 Gb/秒イーサネット）スイッチを使用します。

推奨事項 2：GbE 接続には CAT6 を使用する

CAT6ケーブルは、1000 Mb接続で使用したときにCAT5Eケーブルよりも優れた結果を示しています。したがって、最適なパフォーマンスと安定性を得るには、このCAT6ケーブルを使用することをお勧めします。

推奨事項 3：ネットワークの速度と二重構成を設定する

設定が完了し、インフラストラクチャがGbEを適切にサポートしていることが検証されたら、スイッチ・ポートとNICポートを1 Gb/秒および全二重に設定します。新しい環境ですべてが適切に動作するよう自動設定機能を使用して設定しなければならないかもしれませんが、速度と二重設定については、本番システムで手動設定する必要があります。

(15)

Chapter 5 ストレージ・システムのベスト・プラクティス

この章では、Microsoft SQL Server 2005用にEMCストレージ・システムを構成する際の推奨事項を紹介します。

推奨事項 1：容量ではなくパフォーマンスを考えてストレージ・レイアウトを計画する

Microsoft SQL Serverのストレージを計画するときの間違いで最も多いのが、パフォーマンス、つまり１秒あたりのI/O（IOPS）ではなく、ストレージ容量を優先しまうことです。ディスク・レイアウトを適切に計画するには、持続的に、ピークIOPSで、ピーク期間中にサポートする必要があるIOPS数を見積もる必要があります。お客様の多くはアプリケーション実行中にデータを収集し、90パーセンタイル（90番目の値）を使用して計画レベルを決定します。データベース・ストレージのスピンドル数を決定する際に使用するプライマリ変数は次の3つがあります。 ♦ IOPS（場合によってはMB/秒（シリアル・ワークロードの場合））

♦ RAIDレベル - パフォーマンスを考えて計画する場合、ストライプRAID 1（RAID 10）に必要なスピンドル数は、ほぼすべての読み取り/書き込みワークロードについてRAID 5よりも少なく、読み取り専用ワークロードに対する値とほぼ同じです。RAIDグループ計画の詳細については、「付録B」を参照してください。 ♦ レーテンシーに関する目標値：SQL Server 2005で良好なパフォーマンスを得るためのMicrosoftのガイドラインを次に示します。読み取り書き込み平均レーテンシー 20 ms 10 ms 最大レーテンシー 50 ms 50 ms ディスク・テクノロジーの進歩により、ディスク・ドライブのストレージ容量は、IOPSが向上するよりも格段に速いペースで（約1,000倍）増加しています。つまり、パフォーマンスを考えて計画されたシステムで、ワークロードのストレージ容量の要件を満たさないものはほとんどありません。したがって、IOPS容量はMicrosoft SQL Serverストレージ構成を計画する際の基準となります。ストレージ容量（GB）は、IOPS要件を満たした上で検討するようにしてください。

推奨事項 2：できるだけ VMFS ファイル・システムを使用する

VMFSは、特にVMware ESXで使用するために設計されています。したがって、他のホストで実行されているVMを、同じVMFSボリュームに配置できます。VMFSでは必要なロックが管理され、DRS、VMHA、 VMotionなどの高度な機能を使用できます。

推奨事項 3：VI クライアントを使用して新しい VMFS ボリュームを作成する

VMFS、NTFSなど、すべてのレイヤーの配置を調整する必要があります。VMFSの配置は、VIクライアントがボリュームを作成するときに自動的に調整されます。したがって、新しいVMFSはこの方法で作成することをお勧めします。NTFSボリュームの配置も、VMFSボリュームと同様に調整する必要があります。実際、スタック内のレイヤーの配置が間違っていると、パフォーマンスが低下します。詳細については、VMwareのホワイト・ペーパー「Recommendations for Aligning VMFS Partitions」を参照してください。

(16)

推奨事項 4：最適なパフォーマンスを得るために、DISKPART を使用して Windows のボリューム

を配置する

ディスク・パーティションを配置するときはDISKPARTを使用することをお勧めします。Windowsパーティションは64番目のセクタから作成されます。これによりパーティションと物理ディスクが誤って配置され、I/O動作がストライプ・エレメント境界をまたがり、パフォーマンスが大幅に低下することがあります。DISKPARTを使用してドライブのパーティションを作成し、ディスクを配置すると、パフォーマンスが最大40%向上することが認められました。 Note: ダイナミック・ディスクの使用時は DISKPART ではパーティションが適切に配置されません。この場合 は、DISKPAR（DISKPART の前のバージョン）を使用すればダイナミック・ディスク用にパーティションが配置されます。

DISKPARおよびDISKPARTを使用してWindows BasicとDynamic Disksでパーティションを配置する方法の詳細については、EMC Powerlink®_{をご覧ください。} 次のMicrosoft TechNetの記事も、このトピックについて説明しています。 http://www.microsoft.com/technet/prodtechnol/exchange/Guides/StoragePerformance/fa839f7d-f876-42c4-a335 -338a1eb04d89.mspx?mfr=true 本番システムでLUN作成プロセスが完了したら、アクティブなMSCSノードがLUNをrawボリュームとみなせるようになります。 Microsoftコマンド・ライン・ユーティリティDISKPARTを使用してLUNのパーティションを作成します。これにより、ALIGN=64スイッチを使用して確実にパーティションが作成されます。次の例は、ドライブ4に対してDISKPARTを使用しています。 C:¥>Diskpart

DISKPART> list disk

Disk ### Status Size Free Dyn Gpt --- --- --- --- --- ---

Disk 1 Online 136 GB 112 GB Disk 2 Online 267 GB 0 B Disk 3 Online 267 GB 0 B Disk 4 Online 600 GB 600 GB DISKPART> select disk 4

(17)

Disk 4 is now the selected disk.

DISKPART> create partition primary align=64 DISKPART succeeded in creating the specified partition.

Microsoft Disk Managerを使用して、LUNに関連づけるドライブ名またはマウント・ポイントを選択します。この情報を選択したら、データベースのデータ・ファイルとログ・ファイルについて、64kアロケーション・ユニット・サイズでドライブNTFSをフォーマットします。

推奨事項 5：NTFS アロケーション・ユニットを 64 KB に設定する

ディスク・アドミニストレータを使用して新しいドライブをフォーマットする場合、選択されたアロケーション・ユニット・サイズ（クラスタ・サイズ）がアプリケーションのパフォーマンスに影響を及ぼします。Microsoft SQL Server 2005の場合、Microsoftでは64kブロック・サイズを使用することを推奨しています。詳細については、「http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx」を参照してください。

推奨事項 6：LUN の使用率が 80%を上回らないようにする

最適なパフォーマンスを得るには、使用されているドライブ（NTFSフォーマットされた）容量が80% を超えてはいけません。このしきい値を超えるとパフォーマンスに問題が発生する場合があります。 NTFSが効率的に動作するには追加のスペースが必要だからです。使用できるスペースがない場合、 NTFSはその能力を最大限に発揮できず、パフォーマンスが低下する可能性があります。また、これにより過度のディスク・フラグメンテーションが発生し、これがパフォーマンスの低下に拍車を掛けることもあります。

Microsoft SQL Server 2005にサービスを提供しているLUNの使用ドライブ容量が80%に達した場合は、次の1つ以上の操作を行います。 ♦ 不必要なデータをディスクから削除する ♦ データのいずれかを、より大きなスペースを持つディスクに移動する ♦ ディスク・スペースを追加するまた、この推奨事項に従うことで、データベースが予想外に拡大した場合に、アプリケーション障害に対する保護を提供します。

(18)

Chapter 6 CLARiXのベスト・プラクティス

ここでは、CLARiX®_{で推奨されるベスト・プラクティス、およびCLARiX CX3-20ストレージ・アレイでファイバ・}

チャネル接続を使用してバックアップおよびリストアする際に推奨されるベスト・プラクティスを紹介します。詳細については、ホワイト・ペーパー「EMC Best Practices for CLARiiON Fibre Channel Storage」を参照してください。

推奨事項 1：CLARiX プリフェッチの設定値を上げて、リストア・パフォーマンスを向上させる

LUNのデフォルトのプリフェッチ設定は変数プリフェッチで、4/4マルチプライアを使用しています。 LUNがバックアップを格納およびリストアするポイントとして使用されるとき、マルチプライアを 32/8に設定すると、速度が3倍以上速くなります。非シリアル・オペレーションが行われている場合は、プリフェッチを上げるとパフォーマンスが低下する可能性がありますが、バックアップLUNはシリアル・オペレーションでのみ使用されます。したがって、LUNからデータを読み取られる場合は必ず、悪影響を最小限に抑え大きなプラス効果をもたらすことができます。

推奨事項 2：バランスを考えて LUN を設計する

CLARiX CX3ファミリのストレージ・アレイには2つのSP（ストレージ・プロセッサ）があります。このSPの負荷のバランスを考えることをお勧めします。これにより、一方のSPがアイドルに近い状態なのに、一方のSPが過負荷になっている、という状態を確実に防ぐことができます。また、キャッシュを最大限に使用できるようになります。

推奨事項 3：LUN に名前を付ける

次の例のように、LUNの名前、サイズ、使用状況などの情報をすばやく確認できるようLUNに名前を付けます。

C:¥Program Files¥EMC¥Navisphere CLI>navicli -h 200.0.0.3 getlun 7 | Findstr "LUN

Capacity(Blocks)"

Name: LUN 20-TPCC_Data_1of2 LUN Capacity(Megabytes): 25600 LUN Capacity(Blocks): 52428800

推奨事項 4：最新の検証済み HBA ドライバを使用する

最適なパフォーマンスと安定性を確保するため、Windows 2003と使用する際の妥当性が検査されている最新のベンダーHBAドライバをインストールすることをお勧めします。

推奨事項 5：物理サーバで EMC PowerPath を使用する

CLARiX CX3-20ストレージ・プロセッサ（SP）は、障害が発生した場合の負荷の引き継ぎをすばやく行えるモードで実行されています。ただし、この障害によってパスが変更されます。EMC PowerPath® ソフトウェアを使用すると、これを検出し、I/Oの損失無しに修正できます。また、PowerPathは、ダイナミック・パス・ロード・バランシングで使用することもできます。これにより、1つのホスト負荷をSP上の使用可能なFCポートすべてに分散し、バランスをとることができます。

(19)

Appendix A パフォーマンスの監視と調整

Note: 一部の Windows カウンタは、仮想マシンでは正確ではないことがあります。仮想マシンがプロセッサ・リソースを共有する方法には、プロセッサ割り込みに基づいたタイミングに依存しているすべてのカウンタがスキューされるという性質があります。したがって、これらのカウンタは信頼できません。 SQL Serverストレージ・サブシステムに大きな影響を及ぼすアイテムは主に2つあります。1つはサーバ・メモリ、もう1つはI/Oサブシステムの設定（物理ディスク数、RAIDレベル、ストレージへのパスなど）です。サーバ・メモリは、SQL Serverのプライマリ・キャッシュとしての機能を果たします。一般的に、データベース・キャッシュで使用できるメモリが多くなるほど、ストレージ・サブシステムがサービスを提供しなければならない I/O動作は少なくなります。許容できるレーテンシーを超えずにデータベースが使用できる継続的なI/Oレートは、データベースのデータファイルおよびログファイルが格納される場所で使用される物理ディスク・ドライブ数およびRAIDレベルによって決まります。ストレージ接続の帯域幅を超えていなければ、一般的には、ドライブを追加するとI/Oレートが増加します。また、適切なRAIDレベルを使用すると、システムが処理できる継続的なI/O数にメリットをもたらします。さらに、ストレージ接続パスまたはストレージ・アレイを追加して、飽和状態のストレージ・コンポーネントの負荷を軽減することもできます。SQL Serverデータベース・インストールを監視および調整する作業は、業務の一環としてすべての環境で行う必要があります。

SQLTrace（SQL Server ProfilerはGUI）、DMV（Dynamic Management Views）、Perfmonなど、パフォーマンスの監視および調整に役立つツールおよび方法論は複数あります。この章の目的は、これらのツールや方法論を徹底的に説明することではありません。ここでは、最もよく使用されているPerfmonカウンタをいくつか取り上げて、詳しく説明しています。

Windows のパフォーマンス監視

Windows 2003 Performance Monitor（Perfmon）を使用すると、さまざまなオペレーティング・システム、 SQL Server、ハードウェア・コンポーネントに関するリアルタイムのパフォーマンス・カウンタ情報を表示または収集できます。表1では、カウンタについて簡単に説明しています。

表1： Windows Performance Monitorのカウンタカウンタ名パフォーマン

ス・オブジェクト

説明

% Processor Time Processor システム・プロセッサがどのくらいの時間ビジーかを示します。プロセッサが非常にビジーの場合、I/O システムはシステム・パフォーマンス全体に影響を与えません。ハイパースレッドがオンになっている Intel ベースのシステムでは、このカウンタは正確ではないことに注意してください。こうしたシステムでこのカウンタが 50%近くの値を示している場合、そのマシンは恐らくプロセッサ・バウンドになっています。

(20)

カウンタ名パフォーマン説明ス・オブジェクト

Pages / sec Memory オペレーティング・システム（OS）レベルのメモリ・プレッシャの重要なインジケータの 1 つです。ある程度のページングがたまに発生するのは珍しいことではありません。しかし、大量のページングが継続的に発生する場合、またはパフォーマンスが低下しているときにページングが発生する場合、これは高い可能性でメモリ不足を示しています。

% Idle time PhysicalDisk または LogicalDisk 指定されたディスク/ボリュームがどのくらいの時間ビジーではないかを示します。ほぼすべての時間がビジーの場合（ほぼ 0%）、ディスク/ボリュームがボトルネックになっている可能性があります。

Avg. Disk Queue length PhysicalDisk または LogicalDisk サンプリング間隔におけるディスク/ボリューム上の未処理の読み取りおよび書き込み要求平均です。キューが大きかったりディスクのビジー時間が長かったりすると、ほとんどの場合、それはパフォーマンスのボトルネックを示します。RAID アレイを使用していると、この値が単一物理ディスク・ドライブの値をはるかに上回ることがあります。これは、RAID アレイが数多くの物理ディスクに支えられているからです。キュー長は、RAID アレイの各物理ディスクに対する値よりもできるだけ短くするようにするといくらか便利です。

Current Disk Queue length PhysicalDisk または LogicalDisk サンプリングを行った時点でのディスク上の未処理の要求数です。一時的に負荷が高くなっている部分（ホット・スポット）を確認するのに役立ちます。サンプリング間隔のディスク・キューが 0～128 のいずれかの場合、サンプル期間の平均が 16 であっても、このカウンタの値は 0～128 のいずれかの値になります。たとえば、サンプリング間隔におけるディスク・キュー長のサンプルが（0,0,0,128）の場合、ディスクのキュー長の平均は 32 になりますが、現在のディスク・キュー長の値は 128 です。したがって、ほとんどの状況で、このカウンタはあまり役に立ちません。

Avg. Disk sec / transfer PhysicalDisk または LogicalDisk ディスクの読み取りおよび書き込み処理に対するリスポンス･タイムの平均（ミリ秒（ms）単位）です。標準値が 10 ms を下回っていることが好ましく、常に 20 ms を上回っている場合は、何か問題があることを示していることがあります。

Avg. Disk sec / Read PhysicalDisk または LogicalDisk

読み取り処理に対するリスポンス・タイムの平均（ms）です。一般的なリスポンス・タイムの問題を切り分けるのに役立ちます。20 ms を下回る値が望ましい平均値です。

(21)

Avg. Disk sec / Write PhysicalDisk または LogicalDisk

書き込み処理に対するリスポンス・タイムの平均（ms）です。一般的なリスポンス・タイムの問題を切り分けるのに役立ちます。10 ms を下回る値が望ましい平均値です。

Disk Bytes / sec PhysicalDisk または LogicalDisk

ディスク/ボリュームで送受信される 1 秒あたりのバイト数です。

Disk Transfers/sec PhysicalDisk または LogicalDisk

ディスク/ボリュームにおける送受信回数です。転送サイズは関係ありません。IOPS として知られています。

Avg. Disk Bytes / Transfer PhysicalDisk または LogicalDisk システムの相対 I/O 構成の測定単位です。これは平均値ですが、データベースのデータファイルのみが含まれるディスク/ボリュームでは、この値はほとんどのランダム・データ・ワークロードに対して 8 KB になる傾向があります。8 KB を大幅に上回る場合は、ワークロードがもともとシーケンシャルで、追加キャッシュからメリットを得られる可能性があります。データベースのログファイルが含まれるディスク/ボリュームの場合、この値はワークロードに大きく左右されます。

Buffer Cache Hit Ratio SQLServer：Buffer Manager このオブジェクトは、SQL Server に十分な使用可能メモリがあるかどうかを判断するのに役立ちます。98%以上が望ましく、94%以上で許容範囲内、94%を下回っていると、メモリが足りないか、データ・ワークロードが極端にランダムです。バッファ・キャッシュ・ヒット率は（ページ検索/秒–ページ読み取り/秒）をページ検索/秒で割った数値です。先読みは、クエリー・プロセッサからすぐには要求されないためキャッシュ・ミスとはみなされません。しかし、ディスク読み取りであるため、これによりバッファ・キャッシュ・ヒット率が誤解を招く値に設定されます。たとえば、ディスクに必要なすべてのページが先読みマネージャによってプリフェッチされると、バッファ・キャッシュ・ヒット率は 100%またはそれに近い数値になりますが、この値は正しいとは言い切れません。100% のバッファ・キャッシュ・ヒット率は、物理読み取りがまったく行われていないことを示すからです。したがって、（ページ検索/秒–（ページ読み取り/秒+先読みページ/秒））をページ検索/秒で割って、先読みを計算することは珍しくはありません。

Page Life Expectancy SQLServer：Buffer Manager このオブジェクトも、SQL Server に十分な使用可能メモリがあるかどうかを判断するのに役立ちます。この値が 300（5 分）を下回っている場合は、通常、メモリ不足であることを示します。

(22)

Page Lookups / sec SQLServer：Buffer Manager バッファ・プールでのページ検索要求数です。このカウンタには、バッファ・プールから要求されたページ（見つかったページではありません）で、ディスクから読み取られたもの（ページ読み取り）が含まれます。

Page Reads / sec SQLServer：Buffer Manager

発行された物理データベースのページ読み取り数です。ページにクエリーを完了させるようにした直接の結果が、このカウンタのページ読み取り数です。

ReadAhead Pages / sec SQLServer：Buffer Manager 使用する予定のページ読み取り数です。これは ReadAhead マネージャよって行われ、プリフェッチとも呼ばれます。実際、SQL Server があるタイプの I/O アクティビティを見つけると、まずディスクからデータを取得しようとします。データが実際に要求されるのはその後です。たとえば、個々のページ（8 KB I/O）の読み取りではなくテーブルのシリアル・スキャンが行われると、ReadAhead マネージャはエクステント全体（64 KB I/O）または複数の連続したエクステント（128、256、512 KB など）に対して単一 I/O 要求としてプリフェッチを開始します。これにより、I/O サブシステムの効率性が向上し、クエリーのリスポンス・タイムが短縮されます。

(23)

Appendix B RAIDグループの計画

RAIDグループには、アプリケーション・ワークロードによって消費される重要な要素が2つあります。この2つの要素とは1つはストレージ容量、もう1つはパフォーマンス容量です。RAIDグループの容量（ギガバイト単位）が完全に使用されていても、パフォーマンス容量が十分に使用されていないことがありえます。しかし、それよりもはるかに多く見られるのは、ストレージ容量をほんの一部しか使用していないにもかかわらず、厳しいパフォーマンス・ロードにRAIDグループが置かれているという状況です。ディスク・スピンドルの容量は、そのパフォーマンスが向上するよりも格段に速いスピードで増加しています。そのため、SQL Serverを展開する際に最もよく見られる間違いの1つとして、RAIDグループがパフォーマンスではなく容量を考えて計画されている、という点が挙げられます。 RAIDグループを設計する場合は、まず、必要なパフォーマンス・レベルを検討し、その後で必要な容量が使用可能かどうかを検証します。ここで紹介するRAIDグループの設計方法は、RAIDグループ設計を従来の観点からとらえており、パフォーマンスを維持するためのキャッシュやプリフェッチなどの機能には依存していません。

RAID レベルの属性

よく取り上げられるRAIDレベルは主にRAID 1、RAID 5、ストライピング付きRAID 1（RAID 10）の3 つで、フォルト・トレランスを実現します。 Note: RAID 0 が取り上げられることもありますが、フォルト・トレランスを提供しないため推奨されることはめ ったにありません。RAID 0 グループでスピンドル障害が発生すると、グループ全体が使用できなくなります。 RAIDレベルは、通常、容量という基本的な用語で説明されますが、RAID 1と10は2n、つまり所定量の情報を格納するときに非RAID保護システムと比べると2倍のディスクが必要です。また、RAID 5は n+1となり、データを格納するディスク容量のほかに追加のスピンドルが1つ必要であることを示します。これらはすべて真実ですが、最も重要な部分についてはあまり説明されていません。前述したように、SQL Serverのディスク・アレイの制限事項として最も一般的なのはパフォーマンス容量です。ストレージ容量ではありません。各RAIDレベルのパフォーマンス・インパクトは、そのRAIDレベルが実装するフォルト・トレランスのタイプに基づきます。このパフォーマンス・インパクトが見られるのは、通常は、書き込み中だけに限られます。たとえば、RAID 1と10は両方ともミラーリングを使用します。したがって、指定スピンドルに書き込まれる情報はすべて、パートナー・ミラーにも書き込まれます。この理由から、ホスト・サーバによって発行される各論理I/Oは、ストレージ・アレイ内では2つの物理I/Oになるため、RAID 1と10は2倍のライト・ペナルティになります。 RAID 5はもう少し複雑です。RAID 5のストレージ容量にはn+1のオーバーヘッドがあります。これと同じようにライト・ペナルティもx+1と考えるかもしれませんが、RAID 5の実際のライト・ペナルティは4倍です。この計算の詳細情報についてはこのドキュメントでは触れませんが、信頼できるソースから簡単に入手できます。ホストからの論理I/Oは、事実上次の4つの物理I/Oに分類されます。 ♦ 書き込み対象となる読み取りデータ・ディスク ♦ ストライプ・パリティ値の読み取りパリティ・ディスク ♦ データ・ディスクに対する新しいデータの書き込み ♦ パリティ・ディスクに対する新しいストライプ・パリティの書き込み

(24)

RAID保護は、使用可能なストレージ容量と、ディスク・アレイのパフォーマンス容量に影響を及ぼします。この影響は、アレイに対して選択されたRAIDレベルによって決まります。書き込みの割合が0%（読み取り専用）から100%（書き込み専用）に上がると、RAID 1または10とRAID 5間のパフォーマンスの差が急速に広がります。次のグラフは、RAIDレベルが、書き込みまたは読み込みワークロードの各割合に対して与える影響を示しています。 0 100 10₉₀ 20 80 30₇₀ 40 60 50₅₀ 60 40 70₃₀ 80 20 90₁₀ 100 0 Logical Load

Physical Load RAID 5 0 50 100 150 200 250 300 350 400

RAID Overhead Effect for Random IO

Logical Load

Physical Load RAID 10 Physical Load RAID 5

% Write % Read 図1：ランダムI/Oに対するRAIDオーバーヘッドの影響表2は、この3つのRAIDレベルの特徴を示しています。表2： RAIDレベルのパフォーマンス特性 RAIDレベルランダムシリアル読み取り書き込み 11 適切1 _適切1 _適切1 _適切1 52 普通適切優良不良3 10 優良優良優良良好1 表の脚注 1 - RAID 1 グループはすべて 2 つのドライブに制限されています。これにより、パフォーマンスの上限が明確に設定されます。RAID 10 を使用すると、複数の RAID 1 グループにわたってデータをストライピングし、この制限を回避できます。 2 - RAID 5 では、ドライブ障害とそれに伴うドライブ交換の再構築中に、大きなパフォーマンス・インパクトがあります。したがって、計画するときは、これを考慮する必要があります。

(25)

3 - RAID 5 の書き込みパフォーマンスは 4x ペナルティのためよくありません。しかし、たまにですが、RAID 5 書き込みが RAID 1 または 10 のパフォーマンスを上回ることがあります。これは特別なケースで「フル・ストライプ書き込み」と呼ばれ、書き込みがストライプに合わせて配置され、フル・ストライプの幅とまったく同じになる場合に発生します。たとえば、各ディスクの各ストライプのサイズが 32 kB で、4+1 アレイが作成された場合、フル・ストライプ書き込みを 128 kB にして、複数のディスクに 1 つのフル・ストライプを作成するよう配置された場合です。このレベルのパフォーマンスは、特定のワークロードについては、テストによってほぼ例外なく発生していることが証明されない限り信頼するべきではありません。

必要なパフォーマンスの見積もり

Microsoft SQL Serverで最も誤解が多いのは、このMicrosoft SQL Serverはさまざまな種類のデータベースや属性が格納されている環境であり、アプリケーションではないという点です。データベースのパフォーマンス特性は、データベースごとにかなり異なる場合があります。したがって、すべてのワークロードを対象にMicrosoft SQL Serverの一般的なパフォーマンスを説明するのは不可能です。しかし、ワークロードの特性を定義したうえで指定データベースのパフォーマンスについて説明することはできます。データベースは、通常、オンライン・トランザクション処理（OLTP）とオンライン分析処理（OLAP）の2つのクラスに分類されます。表3 では、各データベース・タイプおよびtemp.dbと関係するI/Oパターンの通常属性について説明しています。表3： Microsoft SQL Serverのファイルの種類とパフォーマンス属性ファイルの種類パフォーマンス属性ユーザー・データベースのデータ・ファイル（OLTP）一般的な OLTP（オンライン・トランザクション処理）アプリケーションのデータベース・データ・ファイルの特性を次に示します。 • 小さなI/O • ランダムI/O • 読み取りに比べて書き込みの割合が高い • 通常はデータベースがそれほど大きくない（古くなったデータは通常はデータ・ウェアハウスにアーカイブされます）前述の特性に基づき、RAID 10 は、通常、所定数のスピンドルに対してベスト・パフォーマンスを提供します。つまり、RAID 10 を使用すると、普通は RAID5 よりも少ないスピンドル数で必要なパフォーマンスを実現できます。

(26)

ファイルの種類パフォーマンス属性ユーザー・データベースのデータ・ファイル（OLAP またはデータ・ウェアハウス）一般的な OLAP（オンライン分析処理）アプリケーションのデータベース・データ・ファイルの特性を次に示します。 • 大きなI/O • シリアルI/O • 読み取りに比べて書き込みの割合が低い（場合によっては読み取り専用） • 通常はデータベースが非常に大きい前述の特性に基づき、RAID 5 は、通常、所定数のスピンドルに対して適切なパフォーマンスとより大きな使用可能なスペースを提供します。データベース・ログ・ファイルすべてのデータベースのデータベース・ログ・ファイル特性を次に示します。 • 小さなI/O（512バイトがいくつか） • 高度なシリアルI/O • ほぼ書き込みのみ。大規模なロールバックまたはログ・バックアップ中にたまに読み取りが発生 • サイズは複数の要因に依存。データベース・ワークロードの詳細情報がなければサイズ予測は困難 • ログ・ファイルが、クラッシュまたはデータベース・リストアのいずれかからデータベースを復旧するための唯一の最重要情報 • データを変更するすべてのトランザクションがログ書き込みスピードで制限されるログ・ファイルはパフォーマンスおよび復旧可能性の両方の観点から見て非常に重要であるため、データベース・ログ用の標準としては RAID 10 をお勧めします。（フル･ストライプ書き込みにより）RAID 5 で十分なパフォーマンスを実現できることもありますが、ドライブの障害が発生すると、RAID 5 パフォーマンスは必要なレベルを下回る可能性があります。また、RAID 5 はダブル・ドライブ障害に対応できませんが、RAID 10 はこうした障害が発生しても復旧可能です。