Azure の仮想マシンで SQL Server を動作させる場合のデータベースのデータファイルのスケーリングについて考えてみたいと思います。
ログファイルのスケーリングについては、Azure VM で記憶域プールを使用した際の列数の影響について の考え方になるかと思います。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Azure の仮想マシンで SQL Server を動作させる場合のデータベースのデータファイルのスケーリングについて考えてみたいと思います。
ログファイルのスケーリングについては、Azure VM で記憶域プールを使用した際の列数の影響について の考え方になるかと思います。
先日、SQL Database の新しいエディションの特性を調べてみる (2014/7 版) という投稿をしました。
結果のサマリーとしては以下のようになっています。
■INSERT
| 処理時間 | 前回 | 今回 |
| Business | 1:53 | 2:03 |
| Basic | 9:19 | 2:08 |
| Standard/S1 | 4:35 | 1:56 |
| Standard/S2 | 3:03 | 1:58 |
■SELECT
| 前回 | 今回 | |||
| 処理時間 | エラー数 | 処理時間 | エラー数 | |
| Business | 00:07.3908 | 0 | 00:06.8152 | 0 |
| Basic | 01:57.4251 | 883 | 02:16.9123 | 0 |
| S1 | 02:28.5198 | 0 | 00:46.5336 | 0 |
| S2 | 00:27.2976 | 0 | 00:13.8427 | 0 |
| P1 | 00:08.8606 | 0 | ||
| P2 | 00:07.2884 | 0 | ||
INSERT については差がなく、SELECT については S2 を使用することで、現状の Business に近い処理時間にすることはできました。
以下は SQL Database の料金になります。
現状の SQL Database は DTU が設定されていないため、性能については一定の性能が保障されるわけではなくデータベースの使用量に応じて課金がされます。
新しいパフォーマンスレベルについては、現状はプレビュー料金のため 50% のプレビュー割引きとなっていますが、データベースのコストを抑えるためには S1 の利用が基本になってくるかなと思います。
S1 のスループットを現状のエディションに近づけるためにはどうすればよいかをメモとして。
INSERT の処理時間は同じだったため、本投稿では SELECT をターゲットとして検証しています。
INSERT も複数スレッドで実行した場合はトレンドが変わってくるはずなので、厳密には検証する必要があります。
SQL Server を Azure の仮想マシンで実行した際に、接続したディスクを効果的に使用するために記憶域プール (ストレージプール / 記憶域スペース) を使用することがあるかと思います。
SQL Server を Azure VM で動作させた場合のストレージに対しての考慮事項については、
Azure の仮想マシンにおける SQL Server のパフォーマンスに関する考慮事項
Microsoft Azure Universal Storage for SQL Server 2014
Scaling-out SQL Server disks and data files on Windows Azure Virtual Machines…a real-world example
Azure 仮想マシンにおける SQL Server のパフォーマンス ガイダンス
などで紹介されており、基本的な考え方としては「複数のディスクに I/O を分散させて、IOPS の上限を緩和させる」ことになるかと思います。
SQL Server AlwaysOn Availability Groups Supported between Microsoft Azure Regions をそろそろ試さないとな~とおもい、まずは VNET 間の接続を試してみました。
書いてある内容は以下の記事と同じですので、この投稿よりは下の記事を読んだ方がわかりやすいかと。
今回の私の投稿ではアフィニティグループは設定していません。
VNET 間接続: 異なるリージョン間での Azure Virtual Network の接続
VNet-to-VNet: Connecting Virtual Networks in Azure across Different Regions
Configure a VNet to VNet Connection
Azure の仮想マシンではエンドポイント経由でリモートデスクトップ接続をすることができます。
下の画像では 62888 としていますが、外部向けのエンドポイントに割り当てられているポート経由で、仮想マシンの 3389 に接続し、リモートデスクトップを使用することができます。
セキュリティの要件によっては、各仮想マシンの外部向けのエンドポイントでのリモートデスクトップの接続は許可せずに、内部 IP を使用したリモートデスクトップ接続のみ許可するという要件があるかもしれません。
このような場合は RD GW (リモートデスクトップゲートウェイ) を使用するとよいかと思います。
RD GW を使用することで、外部向けには RD GW の TCP 443 (HTTPS) のみを開放していれば仮想マシンに接続することができるようになります。
今回は以下のような RD GW と接続したい VM が同一となっている仮想ネットワークを作成して RD GW on Azure を構築してみたいと思います。
以前投稿した、カスタムスクリプトを使用して仮想マシンをギャラリーから展開時に日本語 UI を設定 で日本語化した VM を 2 台構築した状態から設定をしてみます。
ポータルから仮想マシンのイメージをキャプチャすることができますが、2 種類のキャプチャがありますので少しメモを。
PowerShell で操作した場合の方法については、PowerShell で VM イメージを扱う方法について が参考になります。Azure の PowerShell については http://azure.microsoft.com/en-us/downloads/ や Web Platform Installer (WebPI) からダウンロードすることができます。
先日のアップデートで仮想マシンでカスタムスクリプトを実行して展開ができるようになりました。
![]()
カスタムスクリプトでは PowerShell が実行できるようなので仮想マシンを作成する際に日本語 UI を同時に設定するスクリプトを実行してみたいと思います。
基本的な内容は Azure VM の日本語 UI を PowerShell で設定 と同じです。
私の投稿は荒いですが、ぎたぱそさんの投稿でとても詳しく解説して下さっていますのでこちらもご参照いただければと思います。
AWS や Azure の英語UI をPowerShellで日本語UIにする
Read the rest of this entry »