SQL Azure と Cosmos DB をメインにWindows Azureの情報を発信
Windwos Virtual Machineが、反応無くなったり、ディスクが読み取り専用になった時、
ポータルもしくはスクリプトで仮想マシンを再起動します。
大抵の場合、これで問題が解決し、仮想マシンは健全な状態に戻ります。
仮想マシンを再起動しても、仮想マシンが「Stopping」のまま止まり続けていることがあります。
この場合は、仮想マシンを削除し（ポータルで、「Delete」ボタンをクリックします）、
使用していたのと同じVHDディスクを使用して再度デプロイします。
さらに同じDNS名を使用したい場合は、前のDNS名を解放するために
仮想マシンで使用していたDNS名をポータルでクラウドサービスから削除する必要があります。 
Virtual Machineを作成する際に、Virtual Machine Nameを指定します。
ここで指定したVirtual Machine NameがLinux上のホスト名に登録されます。Linux上で、「> hostname」とコマンドを打って返ってくる文字列となります。
AzureのインターナルのDNSにも登録され同じDNS名に登録された仮想マシン間であれば、直接通信できます。DNSが名前解決してくれるので、Virtual Machine名で通信できます。
仮想マシン作成直後は、
Virtual Machine Name＝ホスト名＝DNS登録名
となっています。しかし、手動でホスト名を変更しても自動では、Virtual Machine Nameに反映されないため、ズレが発生してしまいます。
今のところ、仮想マシンを作成した後にVirtual Machine名を変更する術が提供されていないようなので、
後から変更はできないようです。
そのため、後からLinux上のホスト名を変更しても、他の仮想マシンから変更後のホスト名では接続することができません。
次のような感じで設定されています。
; generated by /sbin/dhclient-script
search 2d2eae9005.test.27672059.asiaeast.internal.cloudapp.net
nameserver 10.146.190.200
1．初期化処理を実行する
Linuxのイメージを作成するには、WindowsのSysprep的な処理を実行する必要があります。
Linuxでは、Windows Azure Linux Agentが、その機能を提供しています。
次のコマンドを実行すると、必要な初期化をしてくれます。
sudo waagent –deprovision
コマンドを実行すると、次のような警告と処理継続の確認が表示されます。
この処理をすることで、ホスト名が初期化されます。この処理を飛ばすとホスト名が初期化されないため、イメージから仮想マシンを作成する際にVirtual Machine名を指定したものにならず、同じホスト名のままになり、2つ以上作成できないという悲劇が待っています。
確認方法として、$ cat /etc/sysconfig/network を確認すると、hostname が localhost.localdomain に変更されていることが重要と思われます。補足として、/etc/sysconfig/network-scripts/ifcfg-eth0 や /etc/resolv.conf も書き換えられます。
2．仮想マシンを停止し、Captureを実行する
仮想マシンのコンソールから抜けて、仮想マシンをシャットダウンします。
Captureボタンをクリックします。
ダイアログが表示されるので、「I have run the de-provision command on the virtual machine」にチェックを入れ、イメージ名を指定します。
「I have run the de-provision command on the virtual machine」のチェックは必須になっており、チェックを入れずにクリックしてもバリデーションチェックに引っかかります。
ちなみに、手順1をすっ飛ばして、ここのダイアログでチェックを入れてイメージを作成してもイメージは作成されます。しかし、初期化処理が不十分なため、イメージから2つ目以降の仮想マシンを作成しようとしても2つ目以降は正常に作成が完了しません。
キャプチャーをしようとしている仮想マシンには、仮想マシンを作成する際に指定したユーザーが存在しています。このユーザーは、キャプチャーしてイメージを作成した際に削除されません。
そのためキャプチャーしたイメージから新たに仮想マシンを作成する際に、管理者アカウントに別のユーザーを指定すると、ユーザーが追加で削除され、新旧の管理者アカウントが残ります。
上の図で、gloopsとnoraというユーザーがいることがわかります。
gloopsはイメージを作成したときに使用した仮想マシンの管理者アカウントです。
noraは、キャプチャーしたイメージから新たに仮想マシンを作成するときに指定した管理者アカウントです。
次の図のように、仮想マシンは、DNS名に紐づきます。
同じDNS名に登録されている仮想マシン間はVirtual Machine名で直接通信でき、エンドポイントの設定に関わらずすべてのポートと通信することができます。。別のDNSにある仮想マシン間では、直接通信できません。
test01から、test03に通信するにはDNS名（example.cloudapp.net）でグローバルから接続する必要があり、その際には、エンドポイントで指定したポートでのみ通信できます。
高い可用性をもったWebアプリケーションやサービスを構築する必要がありますか？
柔軟に簡単にスケールアウトさせたいですか？
スキーマーフリーのリッチなオブジェクトに対して複雑なクエリが必要ですか？
もし、これらの質問にYesっという回答であれば、MongoDB on Windows Azure をお勧めします。
MongoDB Installer for Windows Azure のリリースによってセットアップ、デプロイがとても快適になります。
MongoDBは、とても有名なNoSQLデータベースです。
Node.jsまたはJavaScriptの経験があるのであれば、学習するのはとても簡単です。
データベース管理用のJavaScriptベースのShellは、データ更新やクエリはJSON形式で、
サーバー上で、JavaScriptベースのmap/reduce操作をすることができます。
MangoDBを学習するには、「Quickstart guides on MongoDB.org」、「MongoDB.org tutorial」を参照するのがお勧めです。
MongoDB Installer for Windows Azure は、Windows Azure Virtual Machine上にMongoDBのレプリカのデプロイとプロビジョニングを自動的に実施するWindows PowerShellスクリプトのコマンドラインツールです。
DNSプレフィックスとノードをなどいくつかの指定をすると、インストーラーはVirtual Machineをプロビジョニングし、MongoDBをデプロイし設定をします。
「How to deploy a PHP application using MongoDB on Windows Azure」で、使用方法を学んでください。PHP開発者でMongoDBを使用する人は、「MongoDB tutorial on php.net」を参照してください。
Microsoft Open Technologiesチームは、Windows Azure上でのMongoDB開発経験の改善をし続けます。
既定で用意された仮想マシンのイメージでは、Cドライブが30GB になっています。
幾つかのソフトウェアはCドライブにしかインストールできないことがあります。その為、ソフトウェアをインストールしていくとディスクスペースが不足します。
Azure VMのOSディスクサイズを増やすことで対応することができます。
Cloud Storage Studio か Azure Storage Explorer を使用して（それ以外でも良いけどね）、.vhdファイルをダウンロードします。
.vhdファイルのサイズを変更するために、Hyper-Vマネージャを使用します。
VHDの拡張のために、VHD Resizer と呼ばれるツールを使用します。使用方法は、ここを参照してください。
サイズ変更した.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を作成します。
csuploadでアップロードした.vhdファイルを指定します。
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全体を見るように東の方から
指令を受けたので、いろいろ検証していくよ！
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。
必要なデータをメモリ内に格納できる範囲が性能限界点になるのかなぁと思います。
ストレージ性能については、「ストレージはお客様の手でパフォーマンスに合わせて最適化および構成可能」となっています。
Windows AzureのVirtual Machineは、Dドライブが非永続化領域のキャッシュ領域となっています。
図のように、Dドライブは、仮想マシンを動作させる物理マシーンのローカルストレージを使用しているので、性能を期待できると言われています。
Dドライブがtempdbの使用領域として第一候補でしょうか。
例えば、Windows Server 2012で提供が始まった記憶域プールを使用して
複数のVHDをひとまとめにしてデータを分散させることで、物理I/Oが分散できるので、
性能向上を期待できます？
