テクニカルレポート ONTAP を使用した Microsoft SQL …テクニカルレポート...

テクニカルレポート

ONTAPを使用したMicrosoft SQL Serverのベストプラクティスガイドネットアップ、Pat Sinthusan 2019年 3月 | TR-4590

概要

このベストプラクティスガイドでは、ストレージ管理者とデータベース管理者がNetApp®ストレージに Microsoft SQL Serverを導入する方法について説明します。

目次

1 はじめに ........................................................................................................... 4 1.1 目的と対象範囲 .......................................................................................................... 4 1.2 対象読者 ................................................................................................................... 4

2 SQL Serverのワークロードの種類 ........................................................................ 4 2.1 ベンチマークのテスト.................................................................................................. 5

3 SQL Serverの設定............................................................................................. 5 3.1 共有インスタンスと専用インスタンス ............................................................................. 5 3.2 CPU構成 .................................................................................................................. 6 3.3 メモリ構成 ................................................................................................................ 8

4 データベースファイルとファイルグループ ............................................................ 12

5 データベースとストレージ .................................................................................. 16 5.1 アグリゲート ........................................................................................................... 16 5.2 ボリューム .............................................................................................................. 16 5.3 LUN....................................................................................................................... 17 5.4 SMB 共有 ............................................................................................................... 19 5.5 データストレージの設計 ............................................................................................ 20 5.6 仮想化 .................................................................................................................... 23

6 Storage Efficiencyと管理性 ............................................................................. 27 6.1 Snapshotコピー ...................................................................................................... 27 6.2 シンプロビジョニング................................................................................................ 28 6.3 スペースギャランティ............................................................................................... 28 6.4 スペース再生 ........................................................................................................... 29 6.5 フラクショナルリザーブ ............................................................................................ 29 6.6 NetApp FlexClone .................................................................................................... 30 6.7 圧縮、コンパクション、重複排除 ................................................................................. 30 6.8 NetApp SnapMirror .................................................................................................. 32

7 データファブリックと SQL Server ..................................................................... 33 7.1 はじめに ................................................................................................................. 33 7.2 Cloud Volumes ONTAP ............................................................................................. 34 7.3 Cloud Volumes Service ............................................................................................ 37

8 まとめ ............................................................................................................ 43

付録 .................................................................................................................... 43

詳細情報の入手方法 ................................................................................................ 49

2 ONTAPを使用した Microsoft SQL Serverのベストプラクティスガイド © 2020 NetApp, Inc. All rights reserved.

表一覧表 1）一般的な SQL Serverワークロード .................................................................................... 5 表 2）ボリュームギャランティが「なし」に設定されている .......................................................... 29 表 3）自動削除および自動拡張を使用したボリュームの設定 ........................................................... 30 表 4）IOPSが 1万 6,000のワークロードのクォータとサービスレベルの例 ...................................... 41

図一覧図 1）ログエントリは、SQL Serverの起動後に使用されているコアの数を示しています。 ..................... 7 図 2）SQL Server Management Studioを使用したサーバメモリの最小値と最大値の調整 .................... 9 図 3）SQL Server Management Studioを使用した最大ワーカースレッド数の設定 ........................... 10 図 4）SQL Server Management Studioを使用したインデックス作成メモリとクエリごとの最小メモリの

設定 ........................................................................................................................... 11 図 5) ファイルグループ ......................................................................................................... 13 図 6）SQL Serverのインストール時にボリュームメンテナンスタスクの実行権限を付与するオプション 15 図 7）SMSQLまたは SnapCenter向けネットアップストレージの基本的な SQL Serverデータベース設計21 図 8）SMSQLまたは SnapCenterを使用したネットアップストレージ用の SQL Serverデータベース設計22 図 9）SMSQLまたは SnapCenterを使用したネットアップストレージ用のサーバデータベース設計 ...... 23 図 10）VMFSデータストアまたは NFSデータストアを使用した VMDK上のシンプルなデータベース

レイアウトの例........................................................................................................... 26 図 11）VMFSデータストアまたは NFSデータストアを使用した VMDK上のデータベースレイアウトの例 27 図 12）ネットアップのデータファブリック：次世代データセンターへのシームレスな移行を支援する ...... 34 図 13）SQL Serverサービスアカウントへのフルアクセス権限の割り当て ........................................ 38 図 14）SMBプロトコルを使用した Cloud Volumes Serviceへの SQL Serverデータとログファイルの

導入例 ...................................................................................................................... 39 図 15）SQL Server Always On with Cloud Volumes Service。 .................................................... 42


1 はじめに SQL Serverは、Microsoftのデータプラットフォームの基盤であり、オンプレミスでもクラウドでも、メモリ内のテクノロジを使用してミッションクリティカルなパフォーマンスを実現し、あらゆるデータを迅速に分析できます。Microsoft SQL Serverは、ミッションクリティカルなアプリケーションに画期的なパフォーマンス、可用性、管理性を提供することで、以前のリリースで提供されていたミッションクリティカルな機能を基盤としています。ストレージシステムは、SQL Serverデータベースの全体的なパフォーマンスの重要な要素です。ネットアップは、SQL Serverデータベースでエンタープライズクラスのパフォーマンスを実現しながら、環境を管理するためのワールドクラスのツールを提供するための製品を複数提供しています。

1.1 目的と対象範囲このドキュメントでは、NetApp ONTAP®ソフトウェアを実行しているネットアップストレージシステムに SQL Serverを導入する際のベストプラクティスと設計上の考慮事項について説明します。効果的で効率的なストレージの導入とエンドツーエンドのデータ保護および保存計画を実現することを目的としています。このガイドの範囲は、SQL Serverの導入時にネットアップが推奨するストレージインフラの設計原則と推奨基準に基づいた技術設計ガイドラインに限定されます。エンドツーエンドの実装は、このレポートの範囲外です。このガイドで説明するベストプラクティスと推奨事項により、SQL Serverアーキテクトとネットアップストレージ管理者は、可用性が高く管理が容易な SQL Server環境を計画し、厳しい SLAを満たすことができます。ネットアップは、読者が次のことを理解していることを前提としています。 • NetApp ONTAPソフトウェア

− NetApp SnapCenter® ASバックアップソフトウェアには、次のものが含まれます。 − SnapCenter Plug-in for Microsoft Windows − SnapCenter Plug-In for SQL Server

− SnapManager® for SQL Serverをバックアップソフトウェアとして使用できます。ソフトウェアには以下が含まれています。 − SnapDrive for Windows − SnapManager for SQL Server

• Microsoft SQL Serverのアーキテクチャと管理ネットアップスタック全体での設定の互換性については、『NetApp Interoperability Matrix Tool（IMT）』を参照してください。

1.2 対象読者このテクニカルレポートは、お客様の環境に SQL Serverデータベースソリューションを導入する責任を負うネットアップのお客様、パートナー様、従業員、フィールド担当者を対象としています。ネットアップは、読者が前述のソリューションのさまざまなコンポーネントに精通していることを前提としています。

2 SQL Serverのワークロードの種類 SQL Serverデータベースプラットフォームでは、複数のアプリケーションをサポートできます。SQL Serverを導入する前に、SQL Serverインスタンスがサポートするアプリケーションのデータベースワークロード要件を理解しておく必要があります。各アプリケーションには、容量、パフォーマンス、可用性に関するさまざまな要件があるため、各データベースはこれらの要件を最適にサポートするように設計する必要があります。多くの組織では、アプリケーション要件を使用して SLAを定義し、データベースを複数の管理階層に分類しています。SQL Serverのワークロードは次のように記述できます。


http://mysupport.netapp.com/NOW/products/interoperability/http://mysupport.netapp.com/NOW/products/interoperability/

• OLTPデータベースは、多くの場合、組織で最も重要なデータベースです。これらのデータベースは通常、お客様向けのアプリケーションをバックアップし、企業の中核業務に不可欠と考えられています。ミッションクリティカルな OLTPデータベースとサポート対象のアプリケーションには、高レベルのパフォーマンスを必要とする SLAがあり、パフォーマンスの低下や可用性に影響を受けやすいものが多くあります。また、WindowsフェイルオーバークラスタまたはAlways-On可用性グループを使用したクラスタリングの候補になる場合もあります。これらのタイプのデータベースの I/O構成は、通常、ランダム読み取りが 75%～90%、書き込みが25%～10%という特徴を持っています。

• 意思決定支援システム（DSS）データベースは、データウェアハウスとも呼ばれます。これらのデータベースは、ビジネスの分析に依存する多くの組織でミッションクリティカルです。これらのデータベースは、クエリの実行時に CPU使用率とディスクからの読み取り処理に影響されます。多くの組織では、DSSデータベースは、月、四半期、年末に最も重要なデータベースですこのワークロードは通常、100%の読み取り I/O構成です。

2.1 ベンチマークのテストトランザクション処理性能評議会（TPC）は、トランザクション処理とデータベースのベンチマークを定義し、検証可能で客観的な TPCパフォーマンスデータを業界に普及させるために設立された非営利団体です。TPCテストでは、ユーザがデータベースに対してトランザクションを実行する、完全なコンピューティング環境をシミュレートします。表 1に、一般的な SQL Serverのテストワークロードを示します。

表 1）一般的な SQL Serverワークロード

ワークロードタイプ TPCテスト読み取り/書き込み比率（%）

OLTP TPC-C ～75/25

TPC-E ～90/10

DSS TPC-H ～100/0

さまざまなワークロード生成オプションを利用できますが、通常は、トランザクションワークロードを処理する際の SQL Serverデータベースのパフォーマンスを測定し、Microsoftの TPC-Eツールの使用または HammerDB（HammerDB.com）を使用した TPC-Hに重点を置いています。これらの特定のベンチマークの使用方法の詳細については、このドキュメントでは説明しません。

3 SQL Serverの設定このセクションでは、SQL Serverのインストール前とインストール後に考慮する必要がある SQL Server設定の構成方法に関する一般的なガイダンスを提供します。

3.1 共有インスタンスと専用インスタンスアプリケーションに多数のスキーマ、ストアドプロシージャがある場合、SQL Serverインスタンスを共有するほかのアプリケーションに影響する可能性があります。インスタンスリソースが分割/ロックされる可能性があります。これにより、共有 SQL Serverインスタンスでホストされているデータベースを使用するほかのアプリケーションでパフォーマンスの問題が発生します。パフォーマンスの問題のトラブルシューティングは複雑になる可能性があります。どのインスタンスが根本的な原因かを特定する必要があるためです。この質問は、オペレーティングシステムと SQL Serverのライセンスのコストと比較して検討されます。アプリケーションのパフォーマンスを最優先する場合は、専用のインスタンスを使用することを強く推奨します。


http://www.hammerdb.com/document.html

Microsoftでは、SQL Serverのライセンスを、インスタンス単位ではなくコア単位のサーバレベルで提供しています。このため、データベース管理者は、サーバが処理できる数の SQL Serverインスタンスをインストールしてライセンスコストを削減しようとします。これにより、あとで大きなパフォーマンスの問題が発生する可能性があります。ネットアップのパフォーマンスを最適化するには、できるだけ専用の SQL Serverインスタンスを選択することを推奨します。

3.2 CPU構成

ハイパースレッディングハイパースレッディングは、Intel独自の同時マルチスレッド（SMT）実装で、x86マイクロプロセッサで実行される計算（マルチタスク）の並列化を改善します。ハイパースレッディングを使用するハードウェアでは、論理ハイパースレッド CPUを物理 CPUとしてオペレーティングシステムに認識できます。次に、SQL Serverは物理 CPUを認識します。物理 CPUは、オペレーティングシステムが提供するもので、ハイパースレッドプロセッサを使用できるものです。ここで注意すべき点は、SQL Serverの各バージョンには、使用可能な処理能力に関する独自の制限があることです。詳細については、『Compute Capacity Limits by Edition of SQL Server』を参照してください。 SQL Serverのライセンス供与には、基本的に 2つの主要な考え方があります。1つ目はサーバ+クライアントアクセスライセンス（CAL）モデルと呼ばれ、2つ目はプロセッサごとのコアモデルです。SQL Serverで利用可能なすべての製品機能には、サーバ+CAL戦略でアクセスできますが、ソケットあたりの CPUコア数はハードウェアで 20に制限されています。ソケットあたり 20個以上のCPUコアを搭載したサーバ用の SQL Server Enterprise Edition+CALがある場合でも、アプリケーションはインスタンスでコアをすべて同時に使用することはできません。図 1に、起動後の SQL Serverログメッセージを示します。このメッセージは、コア制限の適用を示しています。


https://msdn.microsoft.com/ja-jp/library/ms143760.aspx

図 1）ログエントリは、SQL Serverの起動後に使用されているコアの数を示しています。

したがって、すべての CPUを使用するには、プロセッサ単位のコアライセンスを使用する必要があります。SQL Serverのライセンスの詳細については、『SQL Server 2017 Editions』を参照してください。

非均一なメモリアクセス NUMA（Non-Uniform Memory Access）は、プロセッサバスの負荷を増やすことなくプロセッサ速度を向上させるメモリアクセス最適化方式です。SQL ServerがインストールされているサーバでNUMAを構成する場合は、SQL Serverが NUMAを認識し、NUMAハードウェアで十分に機能するため、追加の構成は必要ありません。

プロセッサアフィニティパフォーマンス上の問題が発生しない限り、プロセッサアフィニティのデフォルトを変更する必要はありませんが、その内容と動作を理解する価値があります。 SQL Serverは、次の 2つのオプションでプロセッサアフィニティをサポートします • CPUアフィニティマスク • アフィニティ I/Oマスク


https://www.microsoft.com/en-us/sql-server/sql-server-2017-editions

SQL Serverは、オペレーティングシステムから使用可能なすべての CPUを使用します（プロセッサ単位のコアライセンスが選択されている場合）。すべての CPUにスケジューラを作成し、特定のワークロードに対してリソースを最大限に活用します。マルチタスクを実行する場合、オペレーティングシステムやサーバ上のその他のアプリケーションは、プロセススレッドをプロセッサ間で切り替えることができます。SQL Serverはリソースを大量に消費するアプリケーションであるため、このような状況が発生するとパフォーマンスに影響を与える可能性があります。影響を最小限に抑えるために、すべての SQL Serverの負荷があらかじめ選択されたプロセッサグループに送られるようにプロセッサを構成できます。これは、CPUアフィニティマスクを使用することで実現されます。アフィニティ I/Oマスクオプションは、SQL Serverのディスク I/Oを CPUのサブセットにバインドします。SQL Server OLTP環境では、この拡張により、I/O処理を実行する SQL Serverスレッドのパフォーマンスを向上させることができます。

並列処理の最大レベル（MAXDOP）デフォルトでは、SQL Serverはクエリ実行時に使用可能なすべての CPUを使用します（プロセッサ単位のコアライセンスが選択されている場合）。これは大規模なクエリには適していますが、パフォーマンスの問題が発生し、同時実行性が制限される可能性があります。1つの CPUソケット内の物理コア数に並列処理を制限する方法が優れています。たとえば、1ソケットあたり 12コアの物理 CPUソケットが 2つあるサーバでは、ハイパースレッディングに関係なく、MAXDOPを 12に設定する必要があります。MAXDOPでは、使用する CPUを制限したり、指定したりすることはできません。代わりに、1つのバッチクエリで使用できる CPUの数を制限します。データウェアハウスなどの DSSの場合は、この設定を 50ぐらいにしてから、必要に応じて調整することを推奨します。アプリケーション内の重要なクエリを測定し、必要に応じて調整します。

3.3 メモリ構成

最大サーバメモリ最大サーバメモリオプションは、SQL Serverインスタンスが使用できるメモリの最大量を設定します。通常、SQL Serverが実行されている同じサーバ上で複数のアプリケーションが実行されている場合に、これらのアプリケーションが正常に機能するために十分なメモリを確保する必要があるときに使用されます。一部のアプリケーションでは、起動時に使用可能なメモリのみが使用され、必要に応じて要求されない場合があります。ここでは、サーバの最大メモリ設定が有効になります。複数の SQL Serverインスタンスを持つ SQL Serverクラスタでは、各インスタンスがリソースに対して競合する可能性があります。SQL Serverインスタンスごとにメモリ制限を設定すると、各インスタンスのパフォーマンスを最大限に高めることができます。パフォーマンスの問題を回避するために、オペレーティングシステムには最低 4GBから 6GBのRAMを残すことを推奨します。図 2はサーバの最小メモリと最大メモリの設定方法を表示します。


図 2）SQL Server Management Studioを使用したサーバメモリの最小値と最大値の調整

SQL Server Management Studioを使用してサーバの最小メモリまたは最大メモリを調整するには、SQL Serverサービスを再起動する必要があります。次のコードを使用して、Transact SQL（T-SQL）を使用してサーバメモリを調整できます。

EXECUTE sp_configure 'show advanced options', 1 GO EXECUTE sp_configure 'min server memory (MB)', 2048 GO EXEC sp_configure 'max server memory (MB)', 120832 GO RECONFIGURE WITH OVERRIDE

ワーカースレッドの最大数ワーカースレッドの最大数オプションを使用すると、多数のクライアントが SQL Serverに接続されている場合にパフォーマンスを最適化できます。通常、クエリ要求ごとに別々のオペレーティングシステムスレッドが作成されます。SQL Serverへの同時接続数が数百の場合、クエリ要求ごとに 1つのスレッドが大量のシステムリソースを消費します。最大ワーカースレッド数のオプションを使用すると、SQL Serverでワーカースレッドのプールを作成して、より多くのクエリ要求を処理できるようになるため、パフォーマンスが向上します。デフォルト値は 0で、SQL Serverは起動時にワーカースレッド数を自動的に設定できます。これはほとんどのシステムで機能します。ワーカースレッドの最大数は高度なオプションなので、経験豊富なデータベース管理者（DBA）の支援なしに変更しないでください。


より多くのワーカースレッドを使用するように、SQL Serverを構成する必要があるのは、どのような場合でしょうか？各スケジューラの平均ワークキューの長さが 1を超える場合、システムにスレッドを追加することでメリットが得られることがあります。ただし、負荷が CPUに制限されていない場合や、ほかの長い待機時間が発生している場合に限ります。いずれかの状況が発生している場合、スレッドを追加しても、ほかのシステムボトルネックが発生するのを待たなければならないため、効果がありません。最大ワーカースレッド数の詳細については、「Configure the max worker threads Server Configuration Option」を参照してください。図 3は、最大ワーカースレッド数の調整方法を示します。

図 3）SQL Server Management Studioを使用した最大ワーカースレッド数の設定

次に、T-SQLを使用して、最大ワーカースレッド数のオプションを設定する方法を示します。

EXEC sp_configure 'show advanced options', 1; GO RECONFIGURE ; GO EXEC sp_configure 'max worker threads', 900 ; GO RECONFIGURE; GO


https://msdn.microsoft.com/ja-jp/library/ms190219.aspxhttps://msdn.microsoft.com/ja-jp/library/ms190219.aspx

インデックス作成メモリインデックス作成メモリオプションは、通常は変更しないもう 1つの詳細オプションです。インデックスの作成時に最初に割り当てられる RAMの最大容量を制御します。このオプションのデフォルト値は 0です。これは、SQL Serverによって自動的に管理されることを意味します。ただし、インデックスの作成で問題が発生した場合は、このオプションの値を増やすことを検討してください。

クエリあたりの最小メモリクエリを実行すると、SQL Serverは効率的に実行するために最適なメモリ容量を割り当てようとします。デフォルトでは、min memory per query 設定では、実行するクエリごとに 1024KB以上が割り当てられます。SQL Serverでインデックス作成処理に割り当てられたメモリ量を動的に管理できるようにするには、この設定をデフォルト値の 0のままにしておくことを推奨します。ただし、SQL Serverの RAM容量が効率的に実行するために必要な容量を超えている場合は、この設定を大きくすると、一部のクエリのパフォーマンスが向上することがあります。したがって、SQL Server、その他のアプリケーション、またはオペレーティングシステムで使用されていないサーバ上のメモリが使用可能であれば、この設定を強化することで SQL Serverの全体的なパフォーマンスを向上させることができます。空きメモリがない場合は、この設定を増やすと、全体的なパフォーマンスが低下する可能性があります。

図 4）SQL Server Management Studioを使用したインデックス作成メモリとクエリごとの最小メモリの設定


バッファプール拡張バッファプール拡張機能は、NVRAM拡張機能とデータベースエンジンのバッファプールをシームレスに統合して、I/Oスループットを大幅に向上させます。バッファプール拡張機能は、SQL Serverのエディションによっては使用できない場合があります。64ビットの SQL Server Standard、Business Intelligence、Enterprise Editionでのみ使用できます。バッファプール拡張機能は、不揮発性ストレージ（通常は SSD）を使用してバッファプールキャッシュを拡張します。この拡張機能により、バッファプールは大規模なデータベースワーキングセットに対応できるようになり、RAMと SSD間の I/Oのページングが強制され、小さなランダム I/Oがメカニカルディスクから SSDに効率的にオフロードされます。SSDのレイテンシが低く、ランダム I/Oパフォーマンスが高いため、バッファプールの拡張によって I/Oスループットが大幅に向上します。バッファプール拡張機能には、次の利点があります。 • ランダム I/Oスループットの向上 • I/Oレイテンシの削減 • トランザクションスループットの向上 • より大規模なハイブリッドバッファプールによる、読み取りパフォーマンスの向上 • 既存および将来の低コストメモリを活用できるキャッシュアーキテクチャバッファプールの拡張については、次のことを推奨します。 • バッファプール拡張ターゲットディスクとして使用できるように、SSDベースの LUN

（NetApp AFFなど）が SQL Serverホストに提供されていることを確認します。 • 拡張ファイルのサイズは、バッファプールと同じか、それより大きい必要があります。次に示すのは、バッファプールの拡張を 32GBに設定するための T-SQLコマンドです。 USE master GO ALTER SERVER CONFIGURATION SET BUFFER POOL EXTENSION ON (FILENAME = 'P:\BUFFER POOL EXTENSION\SQLServerCache.BUFFER POOL EXTENSION', SIZE = 32 GB); GO

4 データベースファイルとファイルグループ SQL Serverデータベースは、データの格納と操作を可能にするオブジェクトの集合です。理論的には、SQL Server（64ビット）ではインスタンスあたり 32,767個のデータベースと 524,272TBのデータベースサイズがサポートされますが、一般的なインストールでは複数のデータベースが使用されています。ただし、SQL Serverで処理できるデータベースの数は、負荷とハードウェアによって異なります。SQL Serverインスタンスでは、数十、数百、数千の小規模データベースをホストしていることは珍しくありません。各データベースは、1つ以上のデータファイルと 1つ以上のトランザクションログファイルで構成されます。トランザクションログには、データベーストランザクションに関する情報と、各セッションで行われたすべてのデータ変更が格納されます。データが変更されるたびに、SQL Serverはトランザクションログに十分な情報を格納し、アクションを元に戻す（ロールバックする）か、やり直す（リプレイする）かを指定します。SQL Serverのトランザクションログは、データの整合性と堅牢性に対する SQL Serverの評価に不可欠な要素です。トランザクションログは、SQL Serverの不可分性、整合性、分離、耐久性（ACID）機能に不可欠です。SQL Serverは、データページが変更されるとすぐにトランザクションログに書き込みます。すべてのデータ操作言語（DML）ステートメント（SELECT、INSERT、UPDATE、DELETEなど）は完全なトランザクションであり、トランザクションログによって、セットベースの操作全体が確実に実行され、トランザクションの不可分性が保証されます。各データベースには、プライマリデータファイルが 1つあります。デフォルトでは、.mdf拡張子が付いています。また、各データベースにはセカンダリデータベースファイルを含めることができます。デフォルトでは、これらのファイルには.ndf拡張子が付いています。


すべてのデータベースファイルは、ファイルグループにグループ化されます。ファイルグループは論理ユニットであり、データベースの管理を簡易化します。論理オブジェクトの配置と物理データベースファイルを分離できます。データベースオブジェクトテーブルを作成するときは、基になるデータファイルの構成を気にすることなく、配置するファイルグループを指定します。

図 5) ファイルグループ

ファイルグループ内に複数のデータファイルを配置できるため、さまざまなストレージデバイスに負荷を分散できるため、システムの I/Oパフォーマンスが向上します。一方、SQL Serverはトランザクションログに順次書き込みを行うため、トランザクションログには複数のファイルを書き込むことはできません。ファイルグループ内の論理オブジェクトの配置と物理データベースファイルの配置を分離することで、データベースファイルのレイアウトを微調整し、ストレージサブシステムを最大限に活用できます。たとえば、異なる顧客に自社製品を導入している独立系ソフトウェアベンダ（ISV）は、基盤となる I/O構成と導入段階で予想されるデータ量に基づいてデータベースファイルの数を調整できます。これらの変更は、データベースファイルではなくファイルグループにデータベースオブジェクトを配置するアプリケーション開発者には透過的に行われます。一般に、システムオブジェクト以外のすべてのファイルグループにはプライマリファイルグループを使用しないことを推奨します。ユーザオブジェクト用に個別のファイルグループまたはファイルグループのセットを作成すると、データベース管理やディザスタリカバリが容易になります。特に大規模なデータベースの場合は、この作業が容易になります。データベースを作成するとき、または既存のデータベースに新しいファイルを追加するときに、初期ファイルサイズと自動拡張パラメータを指定できます。SQL Serverでは、データを書き込むデータファイルを選択するときに、Proportional Fill Algorithmを使用します。ファイルで使用可能な空きスペースに比例したデータ量を書き込みます。ファイル内の空きスペースが多いほど、処理される書き込み量も多くなります。単一ファイルグループ内のすべてのファイルに、同じ初期サイズと自動拡張パラメータを設定し、拡張サイズをパーセントではなくメガバイトで定義することを推奨します。これにより、Proportional Fill Algorithmは、データファイル間で書き込みアクティビティのバランスを均等に調整できます。 SQL Serverは、ファイルを拡張するたびに、新しく割り当てられたスペースをゼロで埋めます。このプロセスは、対応するファイルに書き込む必要があるすべてのセッションをブロックします。トランザクションログが増加した場合は、トランザクションログレコードを生成します。 SQL Serverは常にトランザクションログをゼロにします。この動作は変更できません。ただし、インスタントファイルの初期化を有効または無効にすることで、データファイルを初期化するかどうかを制御できます。インスタントファイルの初期化を有効にすると、データファイルの増加を高速化し、データベースの作成やリストアに必要な時間を短縮できます。


インスタントファイルの初期化には、セキュリティ上の小さなリスクが伴います。このオプションを有効にすると、データファイルの未割り当て部分に、以前に削除した OSファイルの情報を含めることができます。データベース管理者は、このようなデータを調べることができます。インスタントファイルの初期化を有効にするには、SQL Serverのスタートアップアカウントに「ボリュームメンテナンスタスクの実行」とも呼ばれる SA_Manage_Volume_name権限を追加します。これは、次の図に示すように、ローカルセキュリティポリシー管理アプリケーション（secpol.msc）で実行できます。「ボリュームメンテナンスタスクの実行」権限のプロパティを開き、SQL Serverスタートアップアカウントをユーザのリストに追加する必要があります。

権限が有効になっているかどうかを確認するには、次の例のコードを使用します。このコードは、SQL Serverがエラーログに追加情報を書き込み、小さなデータベースを作成し、ログの内容を読み取るように強制する 2つのトレースフラグを設定します。

DBCC TRACEON(3004,3605,-1) GO CREATE DATABASE DelMe GO EXECUTE sp_readerrorlog GO DROP DATABASE DelMe GO DBCC TRACEOFF(3004,3605,-1) GO

インスタントファイルの初期化が有効になっていない場合、次の例に示すように、SQL Serverのエラーログには、LDFログファイルの初期化に加えて、MDFデータファイルが初期化されていることが示されます。インスタントファイルの初期化を有効にすると、ログファイルの初期化のみが表示されます。


SQL Server 2016以降では、インストールプロセス中にオプションが提供されるため、ボリュームメンテナンスタスクの実行タスクが簡素化されます。図 6は、SQL Serverデータベースエンジンサービスにボリュームメンテナンスタスクを実行する権限を付与するオプションを表示します。

図 6）SQL Serverのインストール時にボリュームメンテナンスタスクの実行権限を付与するオプション

データベースファイルのサイズを制御するもう 1つの重要なデータベースオプションは、自動縮小です。このオプションを有効にすると、SQL Serverはデータベースファイルを定期的に縮小し、サイズを縮小し、オペレーティングシステムにスペースを解放します。この操作はリソースを大量に消費するため、システムに新しいデータが追加されたあとにデータベースファイルが再び拡張されるため、あまり有用ではありません。データベースで自動縮小を有効にすることはできません。


5 データベースとストレージネットアップのストレージソリューションと Microsoft SQL Serverを組み合わせることで、今日の最も要求の厳しいアプリケーション要件を満たすエンタープライズレベルのデータベースストレージ設計を作成できます。両方のテクノロジを最適化するには、SQL Serverの I/Oパターンと特性を理解することが重要です。SQL Serverデータベース用の適切に設計されたストレージレイアウトは、SQL Serverのパフォーマンスと SQL Serverインフラの管理をサポートします。また、ストレージのレイアウトを適切に設定すれば、初期導入を成功させ、ビジネスの成長に合わせて環境をスムーズに拡張できます。

5.1 アグリゲートアグリゲートは、ネットアップストレージ構成のプライマリストレージコンテナであり、データディスクとパリティディスクの両方で構成される 1つ以上の RAIDグループを含みます。ネットアップでは、共有アグリゲートと専用アグリゲートを使用し、データファイルとトランザクションログファイルを分離して、さまざまな I/Oワークロード特性評価テストを実施しています。このテストでは、1つの大規模なアグリゲートに複数の RAIDグループとスピンドルを追加することで、ストレージのパフォーマンスが最適化され、向上します。管理者は次の 2つの理由から管理が楽になります。 • 1つの大きなアグリゲートで、すべてのスピンドルの I/O機能をすべてのファイルで使用でき

ます。 • 1つの大きなアグリゲートで、最も効率的なディスクスペースを使用できます。 HA（高可用性）の場合は、SQL Server AlwaysOn 可用性グループのセカンダリ同期レプリカを、アグリゲート内の別のストレージ仮想マシン（SVM）に配置します。ディザスタリカバリのために、DRサイト内の別のストレージクラスタの一部であるアグリゲートに非同期レプリカを配置し、NetApp SnapMirror®テクノロジを使用してコンテンツをレプリケーションします。アグリゲートでは、ストレージのパフォーマンスを最適化するために、空きスペースを少なくとも10%確保することを推奨します。

5.2 ボリューム NetApp FlexVolがアグリゲート内に作成され、格納されます。1つのアグリゲートに多数のボリュームを作成でき、各ボリュームを拡張、縮小、またはアグリゲート間で移動できます。ユーザのダウンタイムは発生しません。

ボリューム設計に関する考慮事項データベースボリュームの設計を作成する前に、SQL Serverの I/Oパターンと特性がワークロードやバックアップとリカバリの要件によってどのように変化するかを理解することが重要です。フレキシブルボリュームには、次のようなネットアップの推奨事項があります。 • フレキシブルボリュームを使用して SQL Serverデータベースファイルを格納し、ホスト間で

ボリュームを共有しないようにします。 • ドライブレターではなく NTFSマウントポイントを使用して、Windowsのドライブレターの制

限（26文字）を排除します。ボリュームマウントポイントを使用する場合は、ボリュームラベルにマウントポイントと同じ名前を付けることを推奨します。

• 必要に応じて、ボリュームのオートサイズポリシーを設定して、スペース不足の状態を防止します。

• SQL Serverデータベースの I/Oプロファイルが、意思決定支援システムのワークロードなど、大部分がラージシーケンシャルリードで構成されている場合は、ボリュームで読み取りの再割り当てを有効にします。読み取りの再割り当ては、パフォーマンスを向上させるためにブロックを最適化します。

• SQL Serverを SMB共有にインストールする場合は、フォルダを作成するために SMB/CIFSボリューム Unicodeが有効になっていることを確認します。


• snapshot copy reserve 運用上の観点から簡単に監視できるように、ボリューム内のネットアップの値をゼロに設定します。

• ストレージ Snapshot™コピーのスケジュールと保持ポリシーを無効にします。代わりに、SnapCenterまたは SnapManager for SQL Serverを使用して、SQL Serverデータボリュームの Snapshotコピーを調整します。

• SnapManager for SQL Serverの場合は、SQL Serverシステムデータベースを専用のボリュームまたは VMDKに配置します。これは、可用性グループデータベースを含むユーザデータベースとシステムデータベースを同じ場所に配置することで、ユーザデータベースの Snapshotバックアップを防止できるためです。システムデータベースのバックアップ先は SnapInfo LUNです。この LUNは、通常、Windowsオペレーティングシステムファイルと SQL Serverバイナリをホストするボリュームまたは VMDKであり、ランダムな読み取り/書き込みワークロードです。

• tempdbは、SQL Serverで一時的なワークスペースとして使用されるシステムデータベースです。特に、I/Oを大量に消費する DBCC CHECKDB操作に使用されます。したがって、このデータベースは、別のスピンドルセットを持つ専用ボリュームに配置します。ボリューム数が課題となる大規模な環境では、慎重に計画を立てたあと、tempdbを少数のボリュームに統合し、ほかのシステムデータベースと同じボリュームに格納できます。tempdbのデータ保護は、SQL Serverを再起動するたびに、このデータベースが再作成されるため、優先度が高くありません。

• ランダムな読み取り/書き込みワークロードであるため、ユーザデータファイル（.mdf）を別々のボリュームに配置します。トランザクションログバックアップは、データベースバックアップよりも頻繁に作成するのが一般的です。このため、トランザクションログファイル（.ldf）をデータファイルとは別のボリュームまたは VMDKに配置して、それぞれに個別のバックアップスケジュールを作成できるようにします。この分離により、ログファイルの順次書き込み I/Oがデータファイルのランダム読み込み/書き込み I/Oから分離され、SQL Serverのパフォーマンスが大幅に向上します。

• SnapManagerまたは SnapCenterがトランザクションログをコピーする専用の FlexVolに、ホストログディレクトリ（SnapCenterの場合）または SnapManager共有（SMSQLの場合）を作成します。

5.3 LUN

tempdbファイルディスクの断片化を回避するために、tempdbファイルを事前にフルサイズに拡張することを推奨します。ページ競合は、SQL Serverが新しいオブジェクトを割り当てるために特別なシステムページに書き込む必要がある場合に、Global Allocation Map （GAM）、Shared Global Allocation Map（SGAM）、または Page Free Space（PFS）ページで発生する可能性があります。ラッチがメモリ内のこれらのページを保護（ロック）します。ビジー状態の SQL Serverインスタンスでは、tempdbのシステムページでラッチを取得するのに時間がかかることがあります。これにより、クエリの実行時間が延長され、ラッチ競合と呼ばれます。tempdbデータファイルの作成には、次のような経験則が必要です。


• 8コア以下の場合：tempdbデータファイル = コア数 • 8コアを超える場合：8個の tempdbデータファイル次のスクリプトは 8つの tempdbファイルを作成して、tempdbを変更し、SQL Server 2012以降のマウントポイント C:\MSSQL/tempdbに移動します。

use master go -- Change logical tempdb file name first since SQL Server shipped with logical file name called tempdev alter database tempdb modify file (name = 'tempdev', newname = 'tempdev01'); -- Change location of tempdev01 and log file alter database tempdb modify file (name = 'tempdev01', filename = 'C:\MSSQL\tempdb\tempdev01.mdf'); alter database tempdb modify file (name = 'templog', filename = 'C:\MSSQL\tempdb\templog.ldf'); GO -- Assign proper size for tempdev01 ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev01', SIZE = 10GB ); ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'templog', SIZE = 10GB ); GO -- Add more tempdb files ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev02', FILENAME = N'C:\MSSQL\tempdb\tempdev02.ndf' , SIZE = 10GB , FILEGROWTH = 10%); ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev03', FILENAME = N'C:\MSSQL\tempdb\tempdev03.ndf' , SIZE = 10GB , FILEGROWTH = 10%); ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev04', FILENAME = N'C:\MSSQL\tempdb\tempdev04.ndf' , SIZE = 10GB , FILEGROWTH = 10%); ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev05', FILENAME = N'C:\MSSQL\tempdb\tempdev05.ndf' , SIZE = 10GB , FILEGROWTH = 10%); ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev06', FILENAME = N'C:\MSSQL\tempdb\tempdev06.ndf' , SIZE = 10GB , FILEGROWTH = 10%); ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev07', FILENAME = N'C:\MSSQL\tempdb\tempdev07.ndf' , SIZE = 10GB , FILEGROWTH = 10%); ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev08', FILENAME = N'C:\MSSQL\tempdb\tempdev08.ndf' , SIZE = 10GB , FILEGROWTH = 10%); GO

SQL Server 2016以降では、インストール時にオペレーティングシステムに認識される CPUコアの数が自動的に検出され、その数に基づいて、最適なパフォーマンスを得るために必要な tempdbファイルの数が計算され、設定されます。

SnapInfoディレクトリとホストログディレクトリ SnapManager for SQL Server（SMSQL）は、SnapInfoディレクトリをメインリポジトリとして使用し、ホストにインストールされている SMSQLインスタンスに関連するすべてのメタデータ（SnapManagerバックアップメタデータ、システムデータベースのストリームベースバックアップ、トランザクションログバックアップなど）を格納します。 SnapCenterはホストログディレクトリを使用して、トランザクションログバックアップデータを格納します。これはホストレベルとインスタンスレベルです。SnapCenterで使用する各 SQL Serverホストには、ログバックアップを実行するようにホストログディレクトリを設定する必要があります。SnapCenterにはデータベースリポジトリがあるため、バックアップ、リストア、クローニングの処理に関連するメタデータは中央のデータベースリポジトリに格納されます。 SnapInfo LUNおよびホストログディレクトリのサイズは、次のように計算されます。 SnapInfo LUNまたはホストログディレクトリのサイズ = （システムデータベースサイズ+（最大 DB LDFサイズ×日次ログ変更率%））×（Snapshotコピー保持率）÷（1LUN オーバーヘッドスペース%） SnapInfo LUNおよびホストログディレクトリのサイジングの計算式では、次のことを前提としています。 • ｔempdbデータベースを含まないシステムデータベースバックアップ • LUNオーバーヘッドスペースが 10% SMSQL SnapInfoディレクトリまたはホストログディレクトリを専用のボリュームまたは LUNに配置します。SnapInfoディレクトリまたはホストログディレクトリのデータ量は、バックアップ


のサイズとバックアップを保持する日数によって異なります。SnapInfoディレクトリは、設定ウィザードを実行していつでも設定できます。1つの SnapInfoディレクトリを使用すると複雑さが軽減されますが、別々の SnapInfoディレクトリを使用すると、データベースにさまざまな保存ポリシーとアーカイブポリシーを適用できる柔軟性が得られます。ホストログディレクトリは、[SnapCenter] > [ホスト] > [プラグインの構成]から設定できます。 SQL Serverデータベースを NetApp SnapVault®の場所にバックアップし、次の操作を実行できます。 • ボリューム内のすべての LUNをリストアします。 • ヴォールトから 1つの LUNをリストアします。 • また、SnapVaultから LUNの最新の Snapshotに直接アクセスすることもできます。 SnapInfoディレクトリおよびホストログディレクトリに関するネットアップの推奨事項は、次の

とおりです。 • SMSQL SnapInfo LUNまたは SnapCenterホストログディレクトリが、バックアップ

Snapshotコピーを破損する可能性のあるほかのタイプのデータと共有されていないことを確認します。

• マウントポイントをホストする LUNにユーザデータベースやシステムデータベースを配置しないでください。

• データベースを有効な場所に格納できるように、SMSQLまたは SnapCenterの設定ウィザードを使用してデータベースを NetAppストレージに移行し、SMSQLまたは SnapCenterのバックアップ/リストア処理を正常に実行できるようにします。移行プロセスは中断を伴うため、移行の進行中にデータベースがオフラインになる可能性があることに注意してください。

• SQL Serverのフェイルオーバークラスタインスタンス（FCIS）には、次の条件が設定されている必要があります。 − フェイルオーバークラスタインスタンスを使用する場合、SnapInfoまたは SnapCenter

ホストログディレクトリ LUNは、SnapManagerでバックアップする SQL Serverインスタンスと同じクラスタグループ内のクラスタディスクリソースでなければなりません。

− フェイルオーバークラスタインスタンスを使用する場合、ユーザデータベースは、SQL Serverインスタンスに関連付けられたクラスタグループに割り当てられた物理ディスククラスタリソースである共有 LUNに配置する必要があります。

• ユーザデータベースと SnapInfoまたはホストログディレクトリが別々のボリュームにあることを確認し、SnapVaultテクノロジで使用されている Snapshotコピーが保持ポリシーによって上書きされないようにします。

• SQL Serverデータベースが、フルテキスト検索関連ファイルなど、データベース以外のファイルを持つ LUNとは別の LUNに存在することを確認します。

• データベースのセカンダリファイルを（ファイルグループの一部として）別のボリュームに配置すると、SQL Serverデータベースのパフォーマンスが向上します。この分離は、データベースの.mdfファイルが LUNをほかの.mdfファイルと共有していない場合にのみ有効です。

• データベースファイルグループが LUNを共有している場合は、すべてのデータベースでデータベースレイアウトが同一である必要があります。ただし、Unrestricted Database Layout（UDL）オプションが有効な場合は、この制限は適用されません。

• 可能な場合は、SnapCenter Plug-in for Microsoft Windowsを使用して LUNを作成します。DiskManagerなどのツールを使用して LUNを作成する場合は、LUNのフォーマット時に、パーティションの割り当てユニットサイズが 64Kに設定されていることを確認します。

5.4 SMB 共有 SMSQLでは、SMB共有上のデータベースは、ONTAP上の SQL Server 2012以降でのみサポートされます。SnapCenterは現在、SMB共有上のデータベースのバックアップ、リストア、クローニングをサポートしていません。次の表に示すように、レイアウトを推奨します。


内容 SMB 共有

SQL Serverバイナリとシステムデータベース \\systemdb

ユーザデータベースファイル \\\userdb_data

ユーザログファイル \\\userdb_log

SnapInfo \\\SnapInfo SMSQLと SMB共有上のデータベースに関するネットアップの推奨事項は次のとおりです。 • SnapCenter Plug-in for Microsoft Windowsのトランスポートプロトコル設定ダイアログボッ

クスで、SVMに接続するための情報（SVM IPアドレス、ユーザ名、パスワード）を設定して、CIFS サーバ上のすべての SMB共有を表示します。この情報は、SnapManager for SQL Serverで表示されます。

• SnapCenter Plug-in for Microsoft Windowsで設定した Snapshotコピーの自動スケジュール設定を無効にします。

• SnapManagerでデータベースファイルパスをネットアップストレージでホストされている有効なファイルパスとして認識できるようにするには、管理 LIFまたはその他のデータ LIFの IPアドレスではなく、SMB共有パス内のストレージシステム上の CIFSサーバ名を使用する必要があります。パスの形式は\\\です。データベースで共有名に IPアドレスが使用されている場合は、SMB共有パスを使用して、共有名に CIFSサーバ名が含まれているデータベースを手動で切断して接続します。

• SMB環境用にボリュームをプロビジョニングする場合は、NTFSセキュリティ形式のボリュームとしてボリュームを作成する必要があります。

• すべてのデータベースファイル（トランザクションログファイルに加えてデータファイル）が、LUNや SMB共有に配置されるのではなく、SMB共有に存在することを確認します。

• 遅延によるトランザクションの失敗を防ぐために、SQL Serverデータが格納されている SMB共有または CIFS共有でアンチウイルススキャンが実行されていないことを確認してください。

• SQL Serverデータが格納されている SMBまたは CIFS共有で、キャッシュによる破損を防ぐために、Windowsホストキャッシュが無効になっていることを確認します。

• 可用性グループを使用すると、すべてのレプリカからアクセスできる SnapManager SMB共有の共有ネットワークにトランザクションログがストリーミングされます。そのため、この CIFS共有がトランザクションログに対応するサイズになっていることを確認します。

5.5 データストレージの設計ここでは、ネットアップストレージ用の SQL Server設計の例と、SnapManager for SQL Serverと SnapCenterを使用する環境の考慮事項について説明します。

設計例 1 この構成は、基本的なパフォーマンスを必要とし、複数の小規模データベースを含む SQL Server インスタンスに使用できます。データベースストレージの設計には、次の特性があります。 • SQL Serverインスタンス用のアグリゲートが 1つ含まれます。 • SQL Serverシステムデータベース（tempdbデータベースを含む）に専用のボリュームと

LUNを使用します。 • データベースごとに専用の LUNを使用します。 • データとログの両方に 1つのボリュームを使用します。 • データとログの両方に専用の SMB共有を使用します（バックアップに SMSQLを使用している

場合）。 • データとログが同じボリュームに存在するため、RTO（Recovery Time Objective：目標復旧時

間）が比較的短くなります。 • 中～低パフォーマンスで十分な小規模データベースに適しています。


図 7）SMSQLまたは SnapCenter向けネットアップストレージの基本的な SQL Serverデータベース設計

tempdbデータベースを含むシステムデータベースは同じボリュームに存在するため、データベースのバックアップはネイティブ SQL Serverを使用して実行されますが、SMSQLや SnapCenterは使用されません。

設計例 2 この構成は、基本的なパフォーマンスを必要とし、SMSQLまたは SnapCenterを使用してバックアップされる複数のデータベースを含む SQL Serverインスタンスに使用されるように設計されています。データベースストレージの設計には、次の特性があります。 • SQL Serverインスタンス用のアグリゲートが 1つ含まれます。 • SQL Serverシステムデータベースに専用のボリュームと LUNを使用します。 • tempdbデータベースに専用のボリュームと LUNを使用します。 • データベースごとに専用の LUNを使用します。 • データとログの両方に 1つのボリュームを使用します。 • データとログの両方に専用の SMB共有を使用します（バックアップに SMSQLを使用している

場合）。 • データとログが同じボリュームに存在するため、RTOが低～中程度になります。 • 中程度のパフォーマンスが必要な中規模のデータベースに適しています。


図 8）SMSQLまたは SnapCenterを使用したネットアップストレージ用の SQL Serverデータベース設計

設計例 3 この構成は、パフォーマンスが高く、SMSQLまたは SnapCenterを使用してバックアップされるデータベースがいくつか含まれている SQL Serverインスタンスで使用されるように設計されています。データベースストレージの設計には、次の特性があります。 • SQL Serverインスタンス用のアグリゲートが 1つ含まれます。 • SQL Serverシステムデータベースに専用のボリュームと LUNを使用します。 • tempdbデータベースに専用のボリュームと LUNを使用します。 • ユーザデータベースごとに専用の LUNを使用します。 • プライマリおよびセカンダリのデータファイルとログファイルに専用ボリュームを使用します。 • データとログが別々のボリュームに存在するため、RTOが比較的高くなります。 • 高パフォーマンスを必要とする中規模から大規模のデータベースに適しています。


図 9）SMSQLまたは SnapCenterを使用したネットアップストレージ用のサーバデータベース設計

5.6 仮想化 SQL Serverの仮想化により、統合が可能になり、効率性が向上します。最近の開発では、大容量を管理し、データベース環境のプロビジョニングを高速化できる、非常に強力な仮想マシンが導入されました。また、SQL Serverの仮想化は、コスト効率が高く便利です。SQL Serverを仮想化する際に考慮すべき点は、ディスクスループット、メモリ、プロセッサの 3つです。このドキュメントでは、ディスクのみに焦点を当てています。SQL Serverの仮想化に一般的に使用される 2つの主要なハイパーバイザーは、Hyper-Vと VMwareです。各ハイパーバイザーについては、次のセクションで説明します。

Hyper-V Windows Server 2012 Hyper-Vの機能強化と仮想マシン機能の拡張により、仮想環境のパフォーマンスに関連するほとんどの制限が排除されました。Windows Server 2016 Hyper-Vでは、従来より複雑で、リソースを飽和状態にしてほかのシステムリソースやストレージに対処する傾向があるワークロードの統合が改善されています。 SQL Server 2016とWindows Server 2016には、これまで仮想化を検討していなかったオンライントランザクション処理/分析（OLTP/OLTA）、データウェアハウジング、ビジネスインテリジェンスなど、要求の厳しい複雑なデータベースワークロードを効果的に仮想化するために使用できる多数の新機能が用意されています。 VHD（仮想ハードディスク）はすべてファイルのみです。Hyper-Vやその他のオペレーティングシステムでデータを保存または取得するためにマウントできる特殊な形式を使用していますが、ファイル以外の形式ではありません。VMで使用できる VHDには 3つの基本タイプがあります。これらは、固定 VHD、動的 VHD、パススルーディスクです。 • 固定 VHD。固定 VHDを作成する場合、オペレーティングシステムは、基盤となる物理メディ

アに指定されたスペースの 100%を割り当てます。考慮する必要があるブロック割り当てテーブルがないため、パススルーディスクの上に余分な I/O負荷がかかるのは、仮想化スタック内だけです。固定 VHDのメリットは次のとおりです。 − 最速の VHDメカニズム − オーバーコミットメント競合の発生の可能性はありません − 作成時と常に同じフラグメンテーションレベル固定 VHDの欠点は次のとおりです。 − VMレベルのバックアップでは、未使用でも、すべてのスペースがキャプチャされます。


− サイズを大きくすると、携帯性が妨げられます。実際には、VHDをコピーまたは移動する必要がある場合に、このシステムの最大の問題が発生します。VHD自体はどのブロックが空かを認識しないため、100%をコピーする必要があります。バックアップソフトウェアやコピーソフトウェアで圧縮を使用している場合でも、空のブロックは必ずしもデータを保持しているわけではありません。ゲストのファイルシステムでは、ファイルを「削除」すると、ファイル割り当てテーブル内の参照が削除されるだけです。ブロック自体とその中のデータは、別のファイルのデータが上書き保存されるまで変更されません。

• 動的 VHD。動的 VHDのサイズは最大ですが、初期状態では小さくなります。ゲスト OSは、最大値で示されるサイズの通常のハードディスクだけであると考えています。ディスクにデータが追加されると、基盤となる VHDファイルが拡張されます。この手法では、最終的にリソースの使用量が大幅に増加する可能性がある部分のみを割り当てることが一般的にシンプロビジョニングと呼ばれています。動的 VHDの利点は次のとおりです。 − スペースの迅速な割り当て新しい動的 VHDにはヘッダーとフッターの情報しか含まれない

ため、非常に小さく、すぐに作成できます。 − VMレベルのバックアップのためのスペースの使用量を最小限に抑えます。VMをキャプチャ

するバックアップユーティリティは、VHDレベルで動作し、何があっても完全にバックアップします。VHDが小さいほど、バックアップは小さく（高速に）なります。

− ハードドライブリソースのオーバーコミットメント。500Gbの空きスペースしかないハードドライブアレイには、40GBのブート VHDを持つ 20台の仮想マシンを作成できます。

• パススルーディスクこれらは仮想化されているわけではありませんが、仮想マシンからホストマシンのディスクまたはディスクアレイに直接 I/Oを渡します。これは、ホストマシンの内部ディスク、または FCまたは iSCSIで接続された外部システムの LUNです。このメカニズムは、可能な限り高速なディスクパフォーマンスを提供しますが、いくつかの制限的な欠点があります。パススルーディスクには、次のような利点があります。 − Hyper-Vゲスト向けの最速のディスクシステム。 − 基盤となるディスクストレージシステムが（アレイにドライブを追加するなどして）拡張

し、仮想マシンのオペレーティングシステムでディスクの動的な拡張が可能な場合、ゲスト内でドライブをダウンタイムなしで拡張できます。

パススルーディスクにはいくつかの欠点があります。 − パススルーディスクを使用する VMのライブマイグレーションは著しく遅いため、多くの場

合、サービスの中断が含まれます。パススルーディスクはクラスタリソースではないため、所有権の移動中に一時的にオフラインにする必要があります。

− Hyper-Vの VSSライターはパススルーディスクを処理できません。つまり、VMレベルのバックアップソフトウェアでは、バックアップ中に仮想マシンをオフラインにする必要があります。

− パススルーディスク上のボリュームは移動できません。これは、VHDとは対照的に理解しやすいものです。VHDはある場所から別の場所にコピーでき、同じように機能します。パススルーボリューム上のデータは、どのような方法でもカプセル化されません。

Hyper-Vゲスト上の SQL Server用ディスクストレージに関するネットアップの推奨事項は次のとおりです。 • Exchangeや SQL Serverなどの高 I/Oアプリケーションには、常に固定 VHDを使用してくだ

さい。これらのアプリケーションを処理するように設計されているため、負荷がそれほどかからない場合でも、これらのアプリケーションは常に大量の I/Oを必要とするように動作し、ドライブスペースを自由に使用できます。スペースに問題がある場合は、まず小規模な固定 VHDを使用します。必要に応じて容量を拡張できます。

• 確信がない場合は、固定を使用する理由を挙げてください。できない場合は、動的を使用します。あとで間違った選択を行ったと判断した場合でも、あとでいつでもドライブを変換できます。これには時間がかかりますが（ハードウェアと VHDのサイズによって異なります）、変換の必要がなくなります。

• 1台の仮想マシンに複数の VHDを配置でき、VHDの種類を混在させて組み合わせることもできます。仮想化された SQL Serverでは、CドライブにWindowsを格納する動的 VHDと、Dドライブに SQL Serverデータを格納する固定 VHDを保持できます。


• オーバーコミット状態で動的ドライブを使用する場合は、監視システムまたはスケジュールを設定して、物理的なスペースの使用状況を監視します。ドライブの空きスペースが 20%未満になると、VSSライターがアクティブ化されず、VMレベルのバックアップで問題が発生する可能性があります。スペースが完全に消費されると、Hyper-Vはそのドライブ上でアクティブな VHDを持つすべての仮想マシンを一時停止します。

• 高パフォーマンスの本番環境の仮想 SQL Serverインスタンスでは、OSファイル、データファイル、ログファイルを異なる VHDまたはパススルーディスクに配置することが重要です。共有ストレージソリューションを使用している場合は、物理ディスクの実装に注意し、SQL Serverログファイルに使用されるディスクが SQL Serverデータファイルに使用されるディスクとは別のディスクであることを確認することも重要です。

VMware VMware仮想マシンには、通常、VMFS（Virtual Machine File System）または RDM（Raw Device Mapping）のいずれかの形式のファイルセットが含まれています。どちらの形式でも、仮想マシンのディスク（VMDK）にアクセスできますが、ストレージへのアプローチは異なります。VMwareでは、ほとんどの VMに VMFSを使用することを推奨しています。VMFSでは、VMDKファイルにもデータが保持されますが、RDMでは、データは Hyper-Vパススルーディスクと同様の外部ディスクシステムに格納されます。VMFSは複数の VMからのディスクデータを保持しますが、RDMは保持しません。 VMFSは、仮想化をサポートするように特別に設計されています。RDMは I/O負荷の高い処理に推奨されることもありますが、VMFSでは、ストレージボリュームは 1つまたは複数の VMをサポートできます。このボリュームは、ネットワーク操作に影響を与えることなく変更できます。ストレージボリュームを共有するため、VMの管理が容易になり、リソースの使用率が高くなります。さまざまな ESXiサーバは、ブロックレベルで情報を格納するため、ファイルシステムに対して同時に読み取りと書き込みを行うことができます。 VMDKに関するネットアップの推奨事項は次のとおりです。 • プライマリ（.mdf）ファイルとログ（.ldf）ファイルには、ユーザデータベース用に別々の

VMDKを使用します。システムデータベースとオペレーティングシステムの VMDKを含むボリュームとは別のボリュームに配置されたデータストアに、これらの VMDKが存在することを確認します。

• システムデータベース（マスター、モデル、msdb）には、別々の VMDKを使用します。これらの VMDKが、ユーザデータベースとオペレーティングシステムの VMDKを含むボリュームとは別のボリュームに配置されたデータストアに格納されていることを確認します。

• tempdbデータベースには別々の VMDKを使用します。 • VMware vSphere用の NetApp Virtual Storage Console（VSC）を使用して、VMDKをプロビ

ジョニングします。 • VSCでプロビジョニングされた VMDKにユーザデータベースを直接作成します。 • データファイル（テーブルとインデックス）は、SQL Serverストレージエンジンで使用され

るプライマリファイルです。各データベースには複数のファイルが存在し、複数の VMDKに分散されることがあります。

• 可能であれば、異なるWindows Serverマシン間でボリュームとデータストアを共有しないでください。

ESXiは、NASサーバ上の指定された NFSボリュームにアクセスし、ボリュームをマウントして、ストレージのニーズに使用できます。NFSボリュームを使用して、VMFSデータストアと同じ方法で仮想マシンを格納およびブートできます。ESXiは、NFSボリューム上で次の共有ストレージ機能をサポートします。 • vMotion • VMware DRSと VMware HA • ISOイメージは、仮想マシンに CD-ROMとして提供されます • 仮想マシンのスナップショット


ESX 5.0以降では、最大 256個の NFSデータストアがサポートされます。デフォルト値は 8ですが、この値は、使用する ESXまたは ESXiのバージョンに固有の最大数まで増やすことができます。NFSデータストアに関するネットアップの推奨事項は次のとおりです。 • NFSデータストアとして使用される各 NFSエクスポートが、そのボリュームに存在することを

確認します。 • 複数のインスタンスからの複数のシステムデータベースには、1つの NFSデータストアを使用

します。 • ユーザデータベースとユーザログごとに 1つの NFSデータストアを使用します。または、ユー

ザデータベースとユーザログインを別々の NFSデータストアに分けます。 • NFSストレージネットワークのデフォルトゲートウェイを定義しないでください。 • 各 ESXサーバまたは ESXiサーバで同じネットアップのターゲット IPアドレスを使用して、各

NFSデータストアが各 ESXサーバまたは ESXiサーバから 1回だけ接続されていることを確認します。

図 10は、非常に低い（1ミリ秒未満の）レイテンシを必要としない、小規模なデータベース（200GB未満）向けのシンプルなレイアウトです。このレイアウトでは、データストアとフレキシブルボリュームを簡単に管理できます。

図 10）VMFSデータストアまたは NFSデータストアを使用した VMDK上のシンプルなデータベースレイアウトの例

図 11は、VMFSデータストアまたは NFSデータストアで VMDKを使用する VMwareのデータベースレイアウトの例を示しています。データベースストレージの設計には、次の特性があります。 • ユーザが NFSデータストアにある VMDKに単一のデータベースをリストアする場合、SMSQL

または SnapCenterは、選択した Snapshotコピーからフレキシブルボリュームを作成し、Single File SnapRestore®（SFSR）を実行してデータファイルとログをリカバリします。したがって、ボリューム SnapRestoreを使用する場合よりもリカバリ時間が少し長くなります。


• 複数のデータベースファイルとログを同じ VMDKに配置する場合、I/Oが競合する可能性があり、パフォーマンスが専用の VMDKほど高くない可能性があります。

図 11）VMFSデータストアまたは NFSデータストアを使用した VMDK上のデータベースレイアウトの例

RDMを使用すると、VMは専用のストレージ LUNを使用して、SANに直接接続されます。ESXiホストから認識できる LUNの合計数は 256に制限され、最大 32台の ESXiサーバのクラスタ全体で同じ LUNが認識されます。RDMは、仮想マシンが SAN対応である場合など、いくつかの特定の状況で推奨されます。仮想マシンで RDM LUNを使用する場合は、Microsoft Windows用SnapCenterプラグインを使用することを推奨します。ネットアップは、次のいずれかの理由でRDMを使用することを推奨しています。 • サイズが 2TBを超えるファイルが必要な場合。VMDKファイルのサイズが 2TBに制限されてい

るためです • クラスタ化されたデータとクォーラムディスクを使用する必要がある場合（仮想クラスタから

仮想クラスタへ、物理クラスタから仮想クラスタへの両方に適用）

6 Storage Efficiencyと管理性 Storage Efficiencyとは、システム全体のパフォーマンスにほとんど影響を与えずに、最小限のストレージスペースを消費する方法で、SQL Serverデータを格納および管理できる機能です。Storage Efficiencyは、データ重複排除にとどまらず、RAID、プロビジョニング（全体的なレイアウトと利用率）、ミラーリング、その他のデータ保護テクノロジを組み合わせたものです。次のネットアップのテクノロジは、インフラ内の既存のストレージを最適化し、将来のストレージ支出を先送りまたは回避することで、ストレージ効率を実現し、コスト削減のメリットを享受します。これらのテクノロジを組み合わせて使用するほど、コストが大きくなります。

6.1 Snapshotコピー NetApp Snapshotテクノロジは、ONTAPアーキテクチャのWAFL®整合ポイントを作成することで、ファイルシステム（ボリューム）や LUNのバックアップであるポイントインタイムコピーを、コストをかけずに短時間で作成します。NetApp SnapCenterまたは SnapManagerを SQL Server仮想デバイスインターフェイス（VDI）と統合することで、本番 SQL Serverデータベースのアプリケーション整合性のある Snapshotコピーを作成できます。本番データベースのダウンタイムは発生しません。


Snapshotは、データを退避させるタイプのほかのテクノロジとは異なり、データの移動が発生しないため、コピーの作成がパフォーマンスに影響することがありません。Snapshotコピーのコストは、ミラーコピーのようにバックアップごとに 100%発生するのではなく、ブロックレベルで変更のあった割合だけ発生します。Snapshotテクノロジを使用すると、バックアップやリストアのためのストレージコストを削減し、数多くの効率的なデータ管理機能を使用できるようになります。データベースで同じボリューム上の複数の LUNを使用する場合、Snapshotコピーはボリュームベースであるため、これらの LUNのすべての Snapshotコピーが同時に作成されます。SnapManager for SQL Server（SMSQL）または SnapCenterのクローン処理では、SMSQLまたは SnapCenterの検証処理中に書き込み可能な Snapshotコピーを使用して、Snapshotコピーから LUNをリストアし、一時的な読み取り/書き込みアクセスを可能にします。

6.2 シンプロビジョニングシンプロビジョニングは、使用可能なストレージスペースの使用を最適化する方法です。この方法では、従来の方法のようにすべてのブロックを事前に割り当てるのではなく、データブロックをオンデマンドで割り当てます。この方法により、ほぼすべての空白スペースが取り除かれ、低い利用率を改善できます。 FlexVolは、ネットアップのシンプロビジョニングを支えるテクノロジであり、ONTAPの仮想化レイヤと考えることができます。LUNが作成されると、ボリュームから特定のデータブロックを、LUN自体またコピー専用にすることはありません。代わりに、データが実際に書き込まれるときにネットアップアグリゲートのブロックを割り当てます。この割り当て方法を使用すると、管理者は、ストレージシステムで物理的�

テクニカルレポート ONTAP を使用した Microsoft SQL …テクニカルレポート...

Documents

Transcript of テクニカルレポート ONTAP を使用した Microsoft SQL …テクニカルレポート...

テクニカル レポート ONTAP を使用した Microsoft SQL …テクニカル レポート...

Documents

Transcript of テクニカル レポート ONTAP を使用した Microsoft SQL …テクニカル レポート...

テクニカルレポート ONTAP を使用した Microsoft SQL …テクニカルレポート...

Transcript of テクニカルレポート ONTAP を使用した Microsoft SQL …テクニカルレポート...