このチュートリアルでは、パフォーマンスが最適化されている SQL Server で実行する Compute Engine VM インスタンスを作成する方法について説明します。このチュートリアルでは、インスタンスを作成してから、Google Cloud 上で最適なパフォーマンスが得られるように SQL Server を構成する手順について説明します。システムのパフォーマンスの調整に役立つ構成オプションについていくつか説明します。
このチュートリアルでは SQL Server Standard Edition 2014 を使用します。そのため、このガイドで示すすべての構成オプションがすべての人にとって動作するものではなく、すべてのワークロードにおいて顕著なパフォーマンス上の利点が得られるわけではありません。
目標
- Compute Engine インスタンスとディスクの設定。
- Windows オペレーティング システムの設定。
- SQL Server の設定。
料金
このチュートリアルでは、Google Cloud の課金対象となる以下のコンポーネントを使用します。
- Compute Engine ハイメモリ インスタンス
- Compute Engine SSD 永続ディスク ストレージ
- Compute Engine ローカル SSD ディスク ストレージ
- SQL Server Standard の事前設定されたイメージ
料金計算ツールは予想使用量に基づいて費用の見積もりを作成できます。このリンクは、このチュートリアルで使用されるプロダクトの費用の見積もりを示します。これは、1 時間あたり 4 米ドル以上および 1 か月あたり 3,000 ドル以上の費用がかかる可能性があります。
始める前に
- Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。
ディスクを持つ Compute Engine VM の作成
高パフォーマンスの SQL Server インスタンスを作成するには、まず SQL Server と 2 つの永続ディスクを持つ VM インスタンスを作成する必要があります。
永続ディスクに関する考慮事項
VM の永続ディスクの種類を選択する場合は、次の点を考慮してください。
ローカル SSD は、
tempdb
と Windows ページファイル向けのパフォーマンスの高いディスクです。ローカル SSD を使用する場合に注意すべき重要な考慮事項がいくつかあります。Windows からインスタンスをシャットダウンしたり、API を使用してリセットしたりすると、ローカル SSD は削除されます。このアクションによりインスタンスが起動できなくなります。マシンを再度実行するには、永続ディスクの接続を解除して、それらを使用して新しいインスタンスを作成してから、新しいローカル SSD を定義します。また、起動後に新しいディスクをフォーマットして再起動する必要もあります。したがって、重要なデータをローカル SSD に永続的に格納しないでください。または、ローカル SSD の再構築の準備ができてからインスタンスの電源をオフにしてください。
SSD 永続ディスクは、データベース ファイル向けの高パフォーマンスのストレージとなります。
SSD 永続ディスクのパフォーマンスは、計算で使用する CPU の数とディスクのサイズによって異なります。32 個の vCPU と 1 TB ディスクの場合、40,000 オペレーション/秒の読み取りまたは 30,000 オペレーション/秒の書き込みでパフォーマンスがピークになります。読み取りと書き込みの持続スループットの合計は、それぞれ 800 MB/秒と 400 MB/秒になります。これらの測定値は、仮想マシンに接続されるすべての永続ディスク(
C:\
ドライブを含む)の合計を表します。そのため、ページング ファイル、tempdb
、ステージング データ、バックアップに必要なすべての IOPS をオフロードするためにローカル SSD を作成する必要があります。
ディスク パフォーマンスの詳細については、パフォーマンス要件を満たすようにディスクを構成するをご覧ください。
ディスクを持つ Compute Engine VM の作成
Windows Server 2012 に SQL Server 2014 Standard がプリインストールされた VM を作成するには、次の操作を行います。
Google Cloud Console で、[インスタンスの作成] ページに移動します。
[名前] に「
ms-sql-server
」と入力します。[マシンの構成] セクションで、[汎用] を選択して次の操作を行います。
- [シリーズ] リストで、[N1] をクリックします。
- [マシンタイプ] リストで、[n1-highmem-16(16vCPU、104 GB メモリ)] をクリックします。
[ブートディスク] セクションで [変更] をクリックし、次の操作を行います。
- [公開イメージ] タブで、[OS] リストをクリックし、[SQL Server on Windows Server] を選択します。
- [バージョン] リストで [SQL Server 2014 Standard on Windows Server 2012 R2 Datacent] をクリックします。
- [ブートディスクの種類] プルダウン リストで、[標準永続ディスク] を選択します。
- [サイズ(GB)] セクションで、ブートディスクのサイズを 50 GB に設定します。
- ブートディスクの構成を保存するには、[選択] をクリックします。
[ネットワーク、ディスク、セキュリティ、管理、単一テナンシー] セクションを開き、次の操作を行います。
- [ディスク] セクションを開きます。
ローカル ディスクを作成するには、[ローカル SSD を追加] をクリックして次の操作を行います。
- [ローカル SSD の数] リストで、ローカル SSD の数を選択します。ローカル SSD は 24 台まで追加できます。
- このディスクの作成を終了するには、[保存] をクリックします。
追加のディスクを作成するには、[新しいディスクを追加] をクリックします。
- [名前] フィールドは変更せず、そのままにしておきます。
- [ソースのタイプ] リストで、[空のディスク] を選択します。
- [タイプ] リストで、[SSD 永続ディスク] を選択します。
- 2 つ目のディスクの作成を終了するには、[保存] をクリックします。
VM を作成するには、[作成] をクリックします。
Windows を構成する
これで SQL Server を実行するインスタンスが作成されたので、インスタンスに接続して Windows オペレーティング システムを設定します。この後の SQL Server の構成については、後のセクションで説明します。
インスタンスへの接続
Google Cloud Console で、[VM インスタンス] ページに移動します。
[名前] 列で、インスタンスの名前(
ms-sql-server
)をクリックします。インスタンスの詳細ページの上部で、[Windows パスワードを設定] ボタンをクリックします。
ユーザー名を指定します。
[設定] をクリックして、この Windows インスタンスの新しいパスワードを生成します。
インスタンスにログインできるように、ユーザー名とパスワードを記録しておきます。
RDP を使用してインスタンスに接続します。
ディスク ボリュームを設定する
ボリュームを作成してフォーマットします。
- [スタート] メニューで「サーバー管理」を検索して開きます。
[ファイル サービスと記憶域サービス]、[ディスク] の順に選択します。
ローカル SSD の名前は
Google EphemeralDisk
です。ローカル SSD と永続 SSD の両方に、次のようにUnknown
パーティションのマークが付けられます。「Google Ephemeral Disk」という名前の 375 GB のローカル SSD ディスクを右クリックして、[新しいボリューム] を選択します。
デフォルト値のまま続行して、ディスクラベルに P: を選択します。これは、ページング ファイルのディスクとなるためです。
ファイル システムを設定する際は、[アロケーション ユニット サイズ] を 8192 に変更して、[ボリューム ラベル] に「pagefile」と入力します。
2 番目の SSD 永続ディスクについても、次の 3 つの変更点を除いて同じ手順を繰り返します。
ドライブ文字に D: を選択します。
[アロケーション ユニット サイズ] を [
64k
] に設定します。アロケーション ユニット サイズの選択の詳細については、SQL Server インスタンスのベスト プラクティスをご覧ください。
[ボリューム ラベル] に「
sqldata
」と入力します。
Failed to mount path - Invalid Parameter
エラーを修正する
このエラーが発生した場合に行う手順は次のとおりです。
- [閉じる] をクリックします。
- 右上のディスクの更新アイコンをクリックします。
- リストで 500 GB の永続ディスクをクリックします。
[ボリューム] パネルで、ボリュームを右クリックして [ドライブ文字およびアクセス パスの管理] を選択します。
ドライブ文字に D: を選択します。
[OK] をクリックします。
Windows ページング ファイルを移動する
これで新しいボリュームが作成されマウントされたので、Windows ページング ファイルをローカル SSD に移動して、永続ディスク IOPS を解放し、仮想メモリのアクセス時間を短縮します。
- [スタート] メニューで [システムの詳細設定の表示] を検索してダイアログを開きます。
- [詳細] タブをクリックし、[パフォーマンス] セクションで [設定] をクリックします。
- [仮想メモリ] セクションで [変更] ボタンをクリックします。
- [すべてのドライブのページング ファイルのサイズを自動的に管理する] チェックボックスをオフにします。システムではページング ファイルが
C:\
ドライブ上にすでに設定されているため、これを移動する必要があります。 - C: をクリックし、[ページング ファイルなし] ラジオボタンをオンにします。
- [設定] ボタンをクリックします。
- 新しいページング ファイルを作成するには、P: ドライブをクリックして [システム管理サイズ] ラジオボタンをオンにします。
- [設定] ボタンをクリックします。
[OK] を 3 回クリックして、詳細設定のプロパティを終了します。
Microsoft Support は仮想メモリ設定の追加のヒントを公開しています。
電源プロファイルを設定する
電源プロファイルを Balanced
ではなく High-Performance
に設定します。
- [スタート] メニューで [電源プランの選択] を検索して、電源オプションを開きます。
- [高パフォーマンス] ラジオボタンをオンにします。
- ダイアログを終了します。
SQL Server を設定する
SQL Server Management Studio を使用して、大部分の管理タスクを実行します。SQL Server 2014 の事前構成されたイメージは、すでにインストールされている Management Studio に付属していますが、SQL Server 2016 イメージを使用している場合は、これを手動でダウンロードしてインストールする必要があります。インストール後に、Management Studio を起動して [接続] をクリックし、デフォルト データベースに接続します。
データとログファイルを移動する
SQL Server の事前構成されたイメージはすべて、システム データベースを含めて C:\
ドライブにインストールされています。設定を最適化するために、それらのファイルを作成した新しい D:\
ドライブに移動します。また、忘れずにすべての新しいデータベースを D:\
ドライブに作成してください。SSD 永続ディスクを使用しているため、データファイルとログファイルを別個のディスク パーティションに保存する必要はありません。
インストールを予備ディスクに移動するには、インストーラを使用するか、ファイルを手動で移動するかの 2 つの方法があります。
インストーラを使用する
インストーラを使用するには、c:\setup.exe
を実行して予備ディスク上の新しいインストール パスを選択します。
ファイルを手動で移動する
データとログファイルを同じボリュームに保存するために、システム データベースを移動して、SQL Server を構成します。
D:\SQLData
という名前の新しいフォルダを作成します。- コマンド ウィンドウを開きます。
次のコマンドを入力して、
NT Service\MSSQLSERVER
に完全アクセス権を付与します。icacls D:\SQLData /Grant "NT Service\MSSQLServer":(OI)(CI)F
Management Studio と次のガイドを使用して、システム データベースを移動し、新しいデータベースのデフォルトのファイル位置を変更します。
レポート サーバー機能を使用する予定の場合、ReportServer ファイルと ReportServerTempDB ファイルも移動します。
プライマリ構成のデータベースのファイルを移動して再起動した後、モデルと MSDB データベースの新しい場所を指すようにシステムを構成する必要があります。以下に、Management Studio で実行するヘルパー スクリプトを示します。
ALTER DATABASE model MODIFY FILE ( NAME = modeldev , FILENAME = 'D:\SQLData\model.mdf' ) ALTER DATABASE model MODIFY FILE ( NAME = modellog , FILENAME = 'D:\SQLData\modellog.ldf' ) ALTER DATABASE msdb MODIFY FILE ( NAME = MSDBData , FILENAME = 'D:\SQLData\MSDBData.mdf' ) ALTER DATABASE msdb MODIFY FILE ( NAME = MSDBlog , FILENAME = 'D:\SQLData\MSDBLog.ldf' )
これらのコマンドを実行してから、以下を行います。
services.msc
スナップインを使用して、SQL Server データベース サービスを停止します。- Windows エクスプローラーを使用して、物理ファイルを
Master
データベースが配置されているC:\
ドライブからD:\SQLData
ディレクトリに移動します。 - SQL Server データベース サービスを開始します。
システム権限を設定する
システム データベースを移動してから、設定をさらに変更して、作成された Windows ユーザー アカウントの権限を使用して NT Service\MSSQLSERVER
という名前の SQL Server プロセスを開始します。
Lock Pages in Memory
権限を付与する
グループ ポリシーの Lock Pages in Memory
権限により、Windows がページを物理メモリから仮想メモリに移動しないようにします。物理メモリを解放して整理するために、Windows は古く、ほとんど変更されないページをディスク上の仮想メモリ ページング ファイルにスワップしようとします。
SQL Server は、テーブル構造、実行プラン、キャッシュされたクエリなどの重要な情報をメモリに保存します。この情報の一部はほとんど変更されないため、ページング ファイルの対象となります。この情報がページング ファイルに移動されると、SQL Server のパフォーマンスが低下することがあります。SQL Server のサービス アカウントのグループ ポリシーの Lock
Pages in Memory
権限を付与し、このスワッピングが行われないようにします。
手順は次のとおりです。
- [スタート] メニューで「グループ ポリシーの編集」を検索してコンソールを開きます。
- [ローカル コンピュータ ポリシー] > [コンピュータの構成] > [Windows 設定] > [ローカル ポリシー] > [ユーザー権利の割り当て] の順に展開します。
- [メモリ内のページのロック] を検索してダブルクリックします。
- [ユーザーまたはグループの追加] をクリックします。
- 「NT Service\MSSQLSERVER」を検索します。
- 複数の名前が表示される場合、MSSQLSERVER の名前をダブルクリックします。
- [OK] を 2 回クリックします。
- [グループ ポリシー エディター] コンソールを開いたままにします。
Perform volume maintenance tasks
権限を付与する
デフォルトでは、アプリケーションが Windows のディスク スペースのスライスを要求すると、オペレーティング システムはディスク スペースの適切なサイズのチャンクを配置してから、それを処理してアプリケーションに戻す前にディスクのチャンク全体をゼロアウトします。SQL Server ではファイルが増大してディスク スペースを多く費やす傾向があるため、この動作は最適ではありません。
ディスク スペースをアプリケーションに割り当てるためには、多くの場合簡易ファイル初期化と呼ばれる別の API が用意されています。残念ながら、この設定が動作するのはデータファイルに対してのみです。ログファイルの増大については後のセクションで説明します。簡易ファイル初期化には、SQL Server プロセスを実行するサービス アカウントに Perform volume
maintenance tasks
という別のグループ ポリシー権限を付与する必要があります。
- グループ ポリシー エディターで、「ボリュームの保守タスクを実行」を検索します。
- 前のセクションで行ったように「NT Service\MSSQLSERVER」アカウントを追加します。
- SQL Server プロセスを再起動して、両方の設定を有効化します。
TempDB
を設定する
かつては、CPU 単位で 1 つの TempDB
ファイルを作成して、SQL Server の CPU 使用率を最適化することがベスト プラクティスでした。ただ、時間の経過とともに CPU の数が増えていくため、このガイドラインに従うことでパフォーマンスが低下する場合があります。まずは 4 つの TempDB
ファイルを使用します。システムのパフォーマンスを測定すると、まれに TempDB
ファイルの数を徐々に最大 8 まで増やすことが必要になる場合があります。
SQL Server Management Studio 内で Transact-SQL(T-SQL)スクリプトを実行して、TempDB ファイルを p: ドライブ内のフォルダに移動できます。
- ディレクトリ
p:\tempdb
を作成します。 セキュリティの全アクセス権を「NT Service\MSSQLSERVER」ユーザー アカウントに付与します。
icacls p:\tempdb /Grant "NT Service\MSSQLServer":(OI)(CI)F
次のスクリプトを SQL Server Management Studio 内部で実行して、TempDB データファイルとログファイルを移動します。
USE Master GO ALTER DATABASE [tempdb] MODIFY FILE (NAME = tempdev, FILENAME = 'p:\tempdb\tempdb.mdf') GO ALTER DATABASE [tempdb] MODIFY FILE (NAME = templog, FILENAME = 'p:\tempdb\templog.ldf') GO
SQL Server を再起動します。
次のスクリプトを実行して、ファイルサイズを変更して新しい
TempDB
に対して 3 つの追加データファイルを作成します。ALTER DATABASE [tempdb] MODIFY FILE (NAME = tempdev, FILENAME = 'p:\tempdb\tempdb.mdf', SIZE=8GB) ALTER DATABASE [tempdb] MODIFY FILE (NAME = templog, FILENAME = 'p:\tempdb\templog.ldf' , SIZE = 2GB) ALTER DATABASE [tempdb] ADD FILE (NAME = 'tempdev1', FILENAME = 'p:\tempdb\tempdev1.ndf' , SIZE = 8GB, FILEGROWTH = 0); ALTER DATABASE [tempdb] ADD FILE (NAME = 'tempdev2', FILENAME = 'p:\tempdb\tempdev2.ndf' , SIZE = 8GB, FILEGROWTH = 0); ALTER DATABASE [tempdb] ADD FILE (NAME = 'tempdev3', FILENAME = 'p:\tempdb\tempdev3.ndf' , SIZE = 8GB, FILEGROWTH = 0); GO
SQL Server 2016 を使用する場合、前のステップを行った後にさらに削除する
TempDB
ファイルが 3 つあります。ALTER DATABASE [tempdb] REMOVE FILE temp2; ALTER DATABASE [tempdb] REMOVE FILE temp3; ALTER DATABASE [tempdb] REMOVE FILE temp4;
SQL Server をもう一度再起動します。
C:\
ドライブ上の元の場所からmodel
、MSDB
、master
、tempdb
のファイルを削除します。
TempDB
ファイルをローカル SSD のパーティションに正常に移動しました。この移動により以前に説明したようないくつかのリスクを抱えますが、なんらかの理由でファイルが失われる場合は、SQL Server が TempDB
ファイルを再構築します。TempDB
の移動によりローカル SSD のパフォーマンスがさらに向上して、永続ディスク上で使用される IOPS が削減されます。
max degree of parallelism
を設定する
max degree of parallelism
の推奨されるデフォルト設定は、サーバーの CPU 数と同じ数にすることです。ただし、クエリを 16 個または 32 個の並列チャンクで実行するポイントがあり、結果をマージすると 1 つのプロセスでの実行よりさらに遅くなります。16 または 32 コアのインスタンスを使用している場合、次の T-SQL を使用して max degree of parallelism
値を 8 に設定できます。
USE Master GO EXEC sp_configure 'show advanced options', 1 GO RECONFIGURE WITH OVERRIDE GO EXEC sp_configure 'max degree of parallelism', 8 GO RECONFIGURE WITH OVERRIDE GO
max server memory
を設定する
この設定のデフォルトは非常に大きな値ですが、利用可能な物理 RAM からオペレーティング システムとオーバーヘッド用の数ギガバイトを引いたメガバイト数を指定する必要があります。次の T-SQL の例では、max server memory
が 100 GB に調整されます。これを変更してインスタンスに適合する値に調整します。詳細については、サーバーメモリ サーバー構成オプションのドキュメントをご覧ください。
EXEC sp_configure 'show advanced options', 1 GO RECONFIGURE WITH OVERRIDE GO exec sp_configure 'max server memory', 100000 GO RECONFIGURE WITH OVERRIDE GO
最終処理
インスタンスをもう一度再起動して、すべての新しい設定が有効になっていることを確認します。SQL Server システムの設定が完了し、独自のデータベースを作成して特定のワークロードのテストを開始する準備ができました。操作手順、その他のパフォーマンスの考慮事項、Enterprise Edition 機能の詳細については、SQL Server ベスト プラクティス ガイドを確認してください。
クリーンアップ
チュートリアルが終了したら、作成したリソースをクリーンアップして、割り当ての使用を停止し、課金されないようにできます。次のセクションで、リソースを削除または無効にする方法を説明します。
プロジェクトの削除
課金をなくす最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。
プロジェクトを削除するには:
- Google Cloud コンソールで、[リソースの管理] ページに移動します。
- プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
- ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。
インスタンスの削除
Compute Engine インスタンスを削除するには:
- Google Cloud コンソールで、[VM インスタンス] ページに移動します。
- 削除するインスタンスのチェックボックスを選択します。
- インスタンスを削除するには、 [その他の操作] をクリックし、[削除] をクリックしてから、指示に沿って操作します。
永続ディスクの削除
永続ディスクを削除する手順は次のとおりです。
Google Cloud Console で、[ディスク] ページに移動します。
削除するディスクの名前の横にあるチェックボックスをオンにします。
ページ上部にある [削除] ボタンをクリックします。
次のステップ
- SQL Server インスタンスの負荷テストを実行する。
- SQL Server ベスト プラクティス ガイドを確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud Architecture Center を確認します。