大和屋貴仁

既定で用意された仮想マシンのイメージでは、Cドライブが30GB になっています。
幾つかのソフトウェアはCドライブにしかインストールできないことがあります。その為、ソフトウェアをインストールしていくとディスクスペースが不足します。
Azure VMのOSディスクサイズを増やすことで対応することができます。

• VMを削除します
• .VHDをダウンロードします
• ダウンロードした.vhdのサイズを変更します
• blobストレージからオリジナルの.vhdを削除します
• サイズを変更した.vhdをアップロードします
• VMを再作成します
• Cドライブの未使用領域にアクセスするためにdiskpartを使用します

VMの削除

.vhdをダウンロードする

Cloud Storage Studio か Azure Storage Explorer を使用して（それ以外でも良いけどね）、.vhdファイルをダウンロードします。

ダウンロードした.VHDのサイズを変更します

.vhdファイルのサイズを変更するために、Hyper-Vマネージャを使用します。

VHDの拡張のために、VHD Resizer と呼ばれるツールを使用します。使用方法は、ここを参照してください。

blobストレージからオリジナルの.vhdを削除します

サイズ変更した.vhdをアップロードします

サイズ変更した.vhdをblobストレージにアップロードします。
Creating and Uploading a Virtual Hard Disk that Contains the Windows Server Operating Systemの手順5を参照してアップロードします。
csupload.exe コマンドラインのスイッチを次のように変更します。

csupload Add-Disk –Destination “<full blob url you want for your vhd>” –Label “<whatever you want>” –LiteralPath “<path to resized .vhd>” –OS Windows

VMの再作成

管理ポータル経由で新しいVMを作成します。
csuploadでアップロードした.vhdファイルを指定します。

Cドライブの未使用領域にアクセスするためにdiskpartを使用します

Windows Explorer上では、Cドライブでは古いサイズのまま表示されています。
コマンドプロンプトを開いて、次のコマンドを実行します。

diskpart
list disk
select disk=0
list partition
select partition=1
extend

元ネタ

http://blogs.msdn.com/b/devkeydet/archive/2012/07/05/resizing-an-azure-vm-vhd-file.aspx

SQL Azure改め、Windows Azure SQL Databaseに改称されたことで、
SQL Detabaseだけじゃなくて、Windows Azure platform全体を見るように東の方から
指令を受けたので、いろいろ検証していくよ！

SQL Server on Windows Azure VMs

2012年スプリングリリースを受けSQL ServerをWindows Azure上で、動作させられるようになりました。
それに伴い、SQL Server on Azure VMsとAzure SQL Databaseの比較をする機会がでてきます。
実際に、「データ シリーズ: Windows Azure 仮想マシン内の SQL Server と Windows Azure SQL データベースの比較」と言う記事が公開されました。

記事の中で、次のように唄っている箇所があります。

Windows Azure VM で実行される SQL Server では、データベース 1 つあたりのパフォーマンスは、
Windows Azure で実行可能な最大の仮想マシン イメージの制約を受けます。
これは、導入当初は
仮想 CPU 数 8 個、
RAM 容量 14 GB、
ストレージ容量 16 TB、
ネットワーク帯域幅 800 MB/秒
という構成の VM になる予定です。
ストレージはお客様の手でパフォーマンスに合わせて最適化および構成可能です。

これらについて、性能的にどうなのかを考察したいと思います。

注意事項

マイクロソフト ソフトウェア ライセンス条項
MICROSOFT SQL SERVER 2012 DEVELOPER
5.    ベンチマーク テスト。お客様は、マイクロソフトの事前の書面による許可がない場合、本ソフトウェアのベンチマーク テストの結果を第三者に開示することはできません。ただし、この制限はMicrosoft .NET Framework (以下を参照) には適用されません。

SQL Server のソフトウェアライセンス条項にベンチマークテストの公開を禁止する条項があります。
その為、今回の考察では具体的な評価結果を公表するのは控えようと思います。
SQLIOの結果であればストレージ性能評価なので、ライセンス条項に抵触しないとは思いますが。

メモリ

SQL Serverを始めとしたリレーショナルデータベースは、
データをメモリにキャッシュすることで物理I/Oを減らすことで性能を向上させます。

Windows Azure VMｓの最大メモリ容量は14GB。
OS用のメモリとコネクション用に2～3GBと想定すると残り11GB。
必要なデータをメモリ内に格納できる範囲が性能限界点になるのかなぁと思います。

ストレージ

ストレージ性能については、「ストレージはお客様の手でパフォーマンスに合わせて最適化および構成可能」となっています。

tempdb

Windows AzureのVirtual Machineは、Dドライブが非永続化領域のキャッシュ領域となっています。

図のように、Dドライブは、仮想マシンを動作させる物理マシーンのローカルストレージを使用しているので、性能を期待できると言われています。
Dドライブがtempdbの使用領域として第一候補でしょうか。

データストア

例えば、Windows Server 2012で提供が始まった記憶域プールを使用して
複数のVHDをひとまとめにしてデータを分散させることで、物理I/Oが分散できるので、
性能向上を期待できます？

SQL Server Management Studio や Visual Studio のサーバーエクスプローラーからWindows Azure SQL Database (SQL Azure)に接続するのに必要な点を説明します。

ソフトウェアのバージョンを確認する

SQL Server Management Studio

SQL Server Management Studioを使用する場合は、SQL Server Management Studio 2008 R2 SP1以降（SQL Server Management Studio 2012でもOK）を使用する必要があります。

Windows Azure SQL Database Federationを管理したいのなら、SQL Server Management Studio 2012を使用したほうが良いでしょう。

Visual Studio

Visual Studio 2010から直接接続したい場合は、Visual Studio 2010 SP1を使用する必要があります。
さらに、最新のWindows Azure SDKがインストールされているかを確認してください。
Visual Studio 2010からWindows Azure SQL Databaseに接続する場合、Azure SDK内に含まれているコンポーネントが接続をフックし、データベースへの接続を確立します。

SQL Server Native Client の設定を確認する

名前パイプに関するエラーが発生する場合、SQLクライアントのネットワークプロトコルの設定が、名前パイプを使用するように設定されている可能性があります。
Windows Azure SQL Database に接続するには、TCP/IP接続を有効にする必要があります。

ローカル側のファイヤーウォールの設定確認

ポート1433を使用して、接続します。
1433が使用できるか確認してください。
ローカルマシンのファイヤーウォール、ネットワーク上のファイヤーウォールそれぞれで確認する必要があります。

SQL Azureのファイヤーウォールのルール

SQL Azureのファイヤーウォールは、接続を許可するIPを設定します。
既定では、すべてのIPからの接続を拒否するようになっていますので、接続元IPから接続できるように設定する必要があります。

SQLCATのBlogに投稿された「Running SQL Server in Windows Azure Virtual Machine – Performance Guidelines for Preview」を元にした投稿です。

基本的には、オンプレミスのSQL Serverと同じ考え方でパフォーマンスチューニングが効く。

• VMのサイズは大きければ大きいほど性能改善に役立つ
  CPU、メモリがボトルネックの間は、大きくすればするほど性能が改善する。
  通常のプロダクション環境では、MediumからLargeを推奨するが、最高なのはえｘｔらLarge
• SQL Serverの最大メモリは規定値
  随時負荷に応じてVMサイズを変更する運用をするなら、動的にメモリ調整をSQL Serverが
  できるように最大メモリは固定しない方が良い。
• Dataディスクを必要なIOに合わせて追加する
  データベース数が複数ある場合でIOがきついなら、DataDiskを複数くっつけて分散させる
  （個人的な感想）Win2012からは記憶域プールが使えるようになるので素敵なことになるのかな？？
• Diskキャッシュ
  Dataディスクは既定でオフになっているので、そのままWriteキャッシュは無効にしておくと良い。
  OSディスクはWriteキャッシュがONになっているので、OSディスクにデータファイル置くなら
  OFFにしたほうがいい
• Dドライブにtempdb置いた方がいい？（個人的感想）
  Dドライブは、Azureストレージじゃなく、VMと同じ物理ラックに置かれた非永続化領域なので
  速いのかな？

SQL Azure Data Sync改めSQL Data Syncは、クラウドとオンプレミスのデータ同期にも対応しています。
データ同期をするために、オンプレミス環境にSQL Data Sync Agentをインストールする必要があります。
SQL Data Syncは、Agentを介してAzure SQL Detabaseに配置されたハブデータベースと
同期をとります。

Question

オンプレとWindows Azure SQL DatabaseをData Syncで同期する場合、
その通信ってどうなってるのでしょう？
知りたいことは、ポート何番を開ければいいのか？Proxyなどがあっても平気か？
その他、気にしなきゃいけないことは？

検証

その答えを探し求めるのに最適な環境が、Win2008R2+SQL2012 on Azureな環境です。
多少時間はかかりますが、数クリックと簡単な入力をして放置しておけば、
クラウド上に素敵な評価環境ができあがります。
// 懸念点は、Azure内なので通信がすかすかじゃないか・・・という事ですが（^^;
// きっと大丈夫！きっと。

そんなこんなでできたSQL2012 on Azureな環境のエンドポイントは、次のような定義がされています。
リモートデスクトップ以外は空いていないことが確認できます。

そこにSQL Data Sync Agentをインストールします。
インストール時に次のようなメッセージが表示されています。

This account must have network access to reach Microsoft SQL Data Sync Service through your network’s proxy.

ネットワークプロキシを通過してSQL Data Syncサービスにネットワーク越しにアクセスできるアカウントを設定してね！と書いてます。
つまり、ネットワークプロキシの認証を気にする必要があるってことですね。
残念ながら環境が無いので、未検証。

インストールが完了すると、Microsoft SQL Data Syncというサービスが起動します。サービスの実行ユーザは、インストール時に指定したユーザになっています。

インストール時に、FireWallの設定を変更するのかな？っと思い、FireWallのルールを確認してみました。
特にSQL Data Sync専用と思えるポートは空いてないですね。

TCPViewでポートの使用状況を確認してみましょう。
PIDから上の2つがSQL Data Syncサービスが使用しているものと分かります。

ネットワークキャプチャーを見てみると、SSL通信をしていることがわかります。

ためしに443通信をWindows Firewallでブロックしてみます。

ブロックすると、TCPViewでもNetwork MonitorでもSQL Data Syncの通信を確認できなくなりました。
その状態で、ポータルで確認すると・・・。

まとめ

• Agentの実行ユーザは、ネットワークプロキシのユーザー認証を通過できるアカウントであること
• ユーザーアカウントなどを使用してしまうと
  定期パスワード変更などを実施すると、SQL Data Syncの設定も変更しないと同期できなくなる
• 通信として、サーバーから外への443通信は必須
  それ以外は・・・・うーん、今のところ気づかない。
• Preview版で、未だマイクロソフトはサポートの提供を開始していないので、
  本番運用での利用はお勧めできない。何かあった時に自力解決することが必要。
  SLAも提供されて・・・ないはずなので。
• データ同期の為に複数のテーブルが追加される。
  また差分をトレースするために同期対象テーブルにトリガーが生成されたりする。
  なので、設計書な世界で生きている人は大変かも？
  本番DBのスキーマが微妙に変わるので覚悟して臨むと良い。