SQL Azure と Cosmos DB をメインにWindows Azureの情報を発信
UbuntuにUbuntuデスクトップをインストールします。
apt-get install ubuntu-desktop
RDサーバーをインストールします。
apt-get install xrdp
Windows Azureエンドポイントを設定します。xrdpポートは、Windowsのリモートデスクトップと同じポート3389を私用するので、3389番のエンドポイントを設定します。
Bitwise Tunnelierでリモートデスクトップ接続します。
azurecoder’s blogに投稿された「Enabling Remote Desktop on Ubuntu in Windows Azure」をざっくり意訳した投稿です。
コマンドラインツールは、Rest APIとPowerShellを使用してプラットフォーム上のほとんどの操作を実施することができます。
ダウンロードページ：http://www.windowsazure.com/en-us/downloads/?fb=ja-jp
Windows Azure PowerShellの代わりに、Windows PowerShellを使用することもできます。
1. Windows PowerShellを開き、提供されているWindows Azure PowerShellモジュールを確認します。
PS C:\> Get-Module –ListAvailable
Directory: C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShellModuleType Name ExportedCommands
———- —- —————-
Binary Azure {Get-AzurePublishSettingsFile, Get-AzureSubscription, Import-AzurePub…
2. PowerShellでAzureモジュールをインポートします。
PS C:\> Import-Module Azure
3. PowerShellで操作をするためにAzurePublishSettingFileをインポートする必要があります。
PS C:\> Get-AzurePublishSettingsFile
このコマンドを実行すると、ブラウザが起動しLiveアカウントの認証画面が表示されます。認証が成功すると、.publishSettings拡張子のファイルがダウンロードされます。 
ダウンロードしたファイルをインポートします。
PS C:\> Import-AzurePublishSettingsFile "C:\Users\user1\Desktop\2-17-2013-credentials.publishsettings"
4. PowerShellでWindows Azureを使用できるか検証します。
PS C:\> Get-AzureSubscription
このコマンドを実行すると、次のような情報が表示されます。
Windows Azure Technical Support (WATS) Team Blogで公開されている「Windows Azure PowerShell – Getting Started」をざっくり意訳した投稿です。
Windows Azureで、環境設定をしたり、必要要件のソフトウェアをインストールするためにスタートアップタスクを使用した、サンプルデモンストレーション(CSAzureStartupTask)がMSDNのAll-In-One Code Frameworkの一環で公開されています。
最終更新日が2011/6/10で多少古めですが、スタートアップタスクを組む際の参考にはなると思います。
Windows Azure Virtual Machineを使用している場合に遭遇する一般的な問題について説明します。
Windows Azure Technical Support (WATS) Team Blog に投稿された「Windows Azure Virtual Machines – Common Issues」をざっくり意訳した投稿です。
例えば、90日間のトライアルアカウントやMSDNサブスクリプションの月間使用量などで、アカウントの使用上限に達した場合、ストレージアカウントは読み取り専用（Read-Only）になり、仮想マシン用のVHDファイルはストレージアカウントに残り続けますが、デプロイしている仮想マシンは削除されます。
トライアルアカウントユーザーは、従量課金アカウントに移行することができます。MSDNサブスクリプションアカウントで月間上限に達している場合は、課金サイクルの翌月になり、次月分を使用できるようになったら、既存のVHDから仮想マシンをデプロイすることができます。
90日のトライアルアカウントに提供されているリソースについては、このドキュメントを参照してください。
特定のリソースが使用制限に達すると、サブスクリプションが課金できるようになるまで関連サービスが使用できなくなります。トライアルサブスクリプションの使用量に依存して、90日前に使用量を使い切ることがあります。たとえば、90日トライアルアカウントは、750smallコンピュート時間提供されています。これは1つのSmall仮想マシンを750時間使えることを意味します。つまり、4つのExtra Large仮想マシンを作成した場合、仮想マシンは23時間ちょっとで削除されてしまいます。
Azure仮想マシン用のVHDファイルは、AzureストレージアカウントのBlobにディスクオブジェクトとして登録されていて、仮想マシンを作成したときにOSディスクとしてアタッチされたり、手動でデータディスクとしてアタッチしたりします。
仮想マシンを削除すると、仮想マシンだけが削除されて、ディスクオブジェクトは仮想マシンのアタッチから外れます。しかしディスクオブジェクトは、ストレージアカウントに物理VHDファイルとして残り続け、ストレージの課金対象となります。
仮想マシンに関連するリソースを削除するには、仮想マシンの削除、ディスクの削除、VHDの削除が必要です。
ディスクオブジェクトを削除するには、Windows Azure管理ポータルで、仮想マシンを選択し、DISKタブを選び、削除ボタンから「関連付けられているVHDの削除」と「関連付けられているVHDの保持」の2つのオプションから選択します。
ストレージアカウントのディスクオブジェクトと物理VHDの両方を削除するには、「関連付けられているVHDの削除」を選択します。
ディスクオブジェクトだけを削除し、物理VHDファイルを維持したい場合は、「関連付けられているVHDの保持」を選択します。
補足：VHDの削除はまれにエラーになることがあります。問題を解決するにはリースを破壊する必要があります。詳細は、7番を参照してください。
重要なデータをDドライブに格納している人もいますが、正しい選択ではありません。DドライブはTemporary Storageなのです。
Temporary Storage（Dドライブ）は、OSディスクやデータディスクのようにWindows Azureストレージでの永続化はされていません。ホストサーバーのアップデートやハードウェア障害で、仮想マシンが別のホストマシンに移動したときに、Dドライブ上にあるでデータは消失します。Dドライブは、一時ログや一時データベース（tempdb）のような、ドライブのTemporary Storageに配置してもいい一時データのみを格納するようにしてください。消失しては困るデータは、一時ディスクへ保存してはいけません。開発者が一時ディスクを使用することにメリットがあるのは、性能です。一時ディスクのI/O性能は、OSディスクやデータディスクよりもIO性能が高いです。その理由は、Windows Azureストレージで永続化されていないからです。
SQL TEMPDB用にDドライブを使用した場合、別のホストに仮想マシンが移動したときに対象フォルダーを再作成する必要があります。再作成しないと、SQLは起動できません。詳細は、Technet wikiの「Change TEMPDB to Temporary Drive on Azure SQL IaaS」を参照してください。
</P
Windows AzureストレージへVHDをアップロードする方法にはいくつかの選択肢があります。
Azure PowerShell 0.6.9以降のAdd-AzureVHDコマンドレットを使用するか、Azure SDKのCsupload.exe（1.7以降）を使用することをお勧めします。
Azure VM用に使用するVHDをアップロードする場合は、次のことを確認してください。
このフォーラムの投稿に、VHDをアップロードする際の一般的な問題について説明されています。また、いくつかのストレージツールの比較については、この記事を参照してください。
仮想マシンを削除しても、関連付けられていたCloud Srviceは自動的には削除されず、前の仮想マシンと同じDNS名を再利用することができません。DNS名を再利用するには、明示的に管理ポータルのCloud Serviceページでクラウドサービスを削除するか、Azure PowerShellのRemove-AzureServiceを使用するか、Azure CLIツールでAzureサービスを削除するか、Delete Hosted Service APIを使用します。
Cloud Serviceがわかりにくい？説明します。
Azure仮想マシンを作成すると、仮想マシンに設定したDNS名と共にクラウドサービスが自動的に作成されます。
今のところ、新しいHTML5の管理ポータルでは、1つの仮想マシンしか含んでいない場合、クラウドサービス配下にクラウドサービスが一覧表示されません。クラウドサービスに表示されるのは、複数の仮想マシンを含んでいるか、仮想マシンを含んでいないものだけです。Azure PowerShell Get-AzureServiceコマンドレットを使用することで確認できます。一つのクラウドサービスには最大で50この仮想マシンを登録することができます。
MSの佐々木さんのBlog「仮想マシン作成時に指定する二つの「名前」」も合わせて参照してみてください。
リモートデスクトップの接続問題は、顧客が遭遇するもっとも一般的な問題で、単純なクライアントのファイヤーウォールの問題からプラットフォームの問題まで原因が多岐にわたります。まず最初にクライアントサイドから問題切り分けを始めるべきです。
Windows Azure仮想マシン上のOSアクティベーションをする際に、エラーコード0xC004F074で、「A problem occurred when Windows tried to activate」とエラーメッセージが出るかもしれません。
Code:
0xC004F074
Description:
"The software licensing service reported that the computer could not be activated. No key management service could be contacted"
この問題に留意し、解決するために動いております。サーバー上でサービスを動かすにあたり、アクティベーションステータスは影響はありません。
詳細はフォーラムの投稿を参照してください。
SQL Serverでは、OS全体の待ち事象状況を確認するための動的管理ビューとして、「sys.dm_os_wait_stats」が提供されています。
Windows Azure SQL Databaseの場合、共有モデルで提供されているので、サーバー全体の待ち事象を確認できてもうれしいことが無いため、提供されていませんでした。
各データベースごとの待ち事象を確認できることは意味があるので、Windows Azure SQL Database用にデータベースの待ち事象を確認できるように、「sys.dm_db_wait_stats」が提供されるようになりました。
sys.dm_wait_stats では、既に終わった待機時間が示されます。この動的管理ビューでは、現在待機中の待機時間は示されません。
クエリ実行中に発生している待機時間の種類によって、クエリにボトルネックや機能停止ポイントがあるかどうかを判断できます。
| 列名 | 説明 |
|---|---|
| wait_type | 待機の種類の名前。 詳細については、このトピックの「待機の種類」を参照してください。 |
| waiting_tasks_count | この待機の種類における待機の数。 このカウンターは、待機が開始するたび増加します。 |
| wait_time_ms | この待機の種類における総待機時間 (ミリ秒単位)。 この時間には signal_wait_time_ms が含まれます。 |
| max_wait_time_ms | この待機の種類における最大待機時間。 |
| signal_wait_time_ms | 待機スレッドがシグナルを受け取ってから実行を開始するまでの時間。 |
DBCC SQLPERF (‘sys.dm_db_wait_stats’, CLEAR);
によるカウンターリセットには対応していません。