Windows Azure

AzCopyについては、MSエヴァの佐々木さんのBlog「azcopy – BLOB へファイルをやったり取ったり」や自分の過去の投稿「AzCopy–Windows Azure Blob用のファイルアップロード・ダウンロードツールがリリース」で紹介しています。

今回の投稿は、Windows Azure Storage Team Blogに投稿されたCTP2のリリースを知らせる「AzCopy – Using Cross Account Copy Blob」をざっくり意訳した投稿です。

AzCopy CTP2は、ここからダウンロードできます。参考用にAzCopy CTP1について説明したブログはここ（英語）です。

CTP2で追加された新機能

• アカウント間のBlobのコピーをサポートしました。
  AzCopyは同一ストレージアカウント間、異なるストレージアカウント間のBlobコピーを可能にします（アカウント間のBlobコピーの詳細については、このBlog（英語）を参照してください）。アカウントから別のアカウントへBlobを移動する際のコストと時間を効率的にします。ストレージサービスがデータ転送を実施するので、あなたが転送元からBlobをダウンロードし、転送先にアップロードする必要はありません。
  /Z を使用して、再開可能モードで転送することができます。
• /MOV を追加しました。
  このオプションは、コピー後、転送元から移動したファイルを削除します。
• /NC を追加しました。
  ネットワーク並列度を指定することができます。デフォルトでは、ローカルコンピューターからWindows Azure Storageにファイルをアップロードするとき、AzCopyは並列タスクを実行するためにコンピューターがもっているコア数の8倍をネットワーク並列処理に使用します。たとえば、4コアのPCの場合、AzCopyは32個のネットワーク並列処理を実行します。CPUやネットワーク帯域使用量を制限したい場合は、/NCを使用して制限することができます。
  この値は、絶対値を指定するもので、コアごとの使用数を指定するものではありません。上の例で半分にしたい場合は、/NC:16 を指定します。
• /SNAPSHOT を追加しました。
  スナップショットでBlobを転送できるようにします。
  AzCopy CTP1では、デフォルトでBlobのスナップショットを転送していました。今回のバージョンからは、Blobをコピーしている間、AzCopyはスナップショットを転送しません。
  /SNAPSHOTオプションを指定した場合のみ、AzCopyはBlobのスナップショットをすべて転送します。しかし、転送先ではオリジナルのBlobのスナップショットの代わりに複数のBlboに分かれています。転送されたBlobのスナップショットは次のような名前に変更されます。[blob名](スナップショット日時)[拡張子]。
  たとえば、転送しようとしたrename.txtファイルが3回スナップショットされていた場合、転送先では次のようなファイル名で格納されます。readme (2013-02-25 080757).txt / readme (2012-12-23 120657).txt / readme (2012-09-12 090521).txt
• /@:response-file: を追加しました。
  ファイルにパラメーターを格納し、コマンドラインで指定した場合、AzCopyによって実行されます。パラメーターファイルは、1パラメーターにつき1行で記載し、複数行記載することができます。

使用例

異なるストレージアカウントへのコピー

AzCopy https://<sourceaccount>.blob.core.windows.net/<sourcecontainer>/ https://<destaccount>.blob.core.windows.net/<destcontainer>/  /sourcekey:<key> /destkey:<key> /S

スナップショットをコピーする場合

AzCopy https://<sourceaccount>.blob.core.windows.net/<sourcecontainer>/ https://<destaccount>.blob.core.windows.net/<destcontainer>/  /sourcekey:<key> /destkey:<key> /S /SNAPSHOT

コピー元からファイルを消したい場合

AzCopy https://<sourceaccount>.blob.core.windows.net/<sourcecontainer>/ https://<destaccount>.blob.core.windows.net/<destcontainer>/  /sourcekey:<key> /destkey:<key> /MOV /S

次のような応答ファイル「myAzCopy.txt」を作成し、実行する場合。

#URI of Source Container
https://<sourceaccount>.blob.core.windows.net/<sourcecontainer>/
#URI of Destination Container
https://<destaccount>.blob.core.windows.net/<destcontainer>/

AzCopy /@:C:\myAzCopy.txt /sourcekey:<key> /destkey:<key> /MOV /S

あああ

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

使用手順

手順1 インストール

1. ダウンロードページ下部にあるリンクからWindows Azure PowerShellをダウンロードします。
   
2. Windows Azure PowerShellで、「Add」をクリックしインストールします。
3. Windows Azure用のPowerShellモジュールがインストールされます。
   

Windows Azure PowerShellの代わりに、Windows PowerShellを使用することもできます。

手順2 設定

1. Windows PowerShellを開き、提供されているWindows Azure PowerShellモジュールを確認します。

PS C:\> Get-Module –ListAvailable
Directory: C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell

ModuleType 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」をざっくり意訳した投稿です。

1. 仮想マシンが見えなくなったり、削除される

例えば、90日間のトライアルアカウントやMSDNサブスクリプションの月間使用量などで、アカウントの使用上限に達した場合、ストレージアカウントは読み取り専用（Read-Only）になり、仮想マシン用のVHDファイルはストレージアカウントに残り続けますが、デプロイしている仮想マシンは削除されます。
トライアルアカウントユーザーは、従量課金アカウントに移行することができます。MSDNサブスクリプションアカウントで月間上限に達している場合は、課金サイクルの翌月になり、次月分を使用できるようになったら、既存のVHDから仮想マシンをデプロイすることができます。

重要な補足

90日のトライアルアカウントに提供されているリソースについては、このドキュメントを参照してください。
特定のリソースが使用制限に達すると、サブスクリプションが課金できるようになるまで関連サービスが使用できなくなります。トライアルサブスクリプションの使用量に依存して、90日前に使用量を使い切ることがあります。たとえば、90日トライアルアカウントは、750smallコンピュート時間提供されています。これは1つのSmall仮想マシンを750時間使えることを意味します。つまり、4つのExtra Large仮想マシンを作成した場合、仮想マシンは23時間ちょっとで削除されてしまいます。

2. 仮想マシンを削除した時、VHDファイルが削除されない

Azure仮想マシン用のVHDファイルは、AzureストレージアカウントのBlobにディスクオブジェクトとして登録されていて、仮想マシンを作成したときにOSディスクとしてアタッチされたり、手動でデータディスクとしてアタッチしたりします。
仮想マシンを削除すると、仮想マシンだけが削除されて、ディスクオブジェクトは仮想マシンのアタッチから外れます。しかしディスクオブジェクトは、ストレージアカウントに物理VHDファイルとして残り続け、ストレージの課金対象となります。

仮想マシンに関連するリソースを削除するには、仮想マシンの削除、ディスクの削除、VHDの削除が必要です。

ディスクオブジェクトを削除するには、Windows Azure管理ポータルで、仮想マシンを選択し、DISKタブを選び、削除ボタンから「関連付けられているVHDの削除」と「関連付けられているVHDの保持」の2つのオプションから選択します。
ストレージアカウントのディスクオブジェクトと物理VHDの両方を削除するには、「関連付けられているVHDの削除」を選択します。
ディスクオブジェクトだけを削除し、物理VHDファイルを維持したい場合は、「関連付けられているVHDの保持」を選択します。

補足：VHDの削除はまれにエラーになることがあります。問題を解決するにはリースを破壊する必要があります。詳細は、7番を参照してください。

3. Temporary Diskの使用に注意する

重要なデータを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

4. 既存VHDのアップロード

Windows AzureストレージへVHDをアップロードする方法にはいくつかの選択肢があります。
Azure PowerShell 0.6.9以降のAdd-AzureVHDコマンドレットを使用するか、Azure SDKのCsupload.exe（1.7以降）を使用することをお勧めします。

Azure VM用に使用するVHDをアップロードする場合は、次のことを確認してください。

• 他の仮想マシンを作成するイメージとして使用するには、仮想マシンはgeneralizeしなければなりません。Windowsの場合、sysprepツールを使用してgeneralizeします。Linuxの場合は、Windows Azure Linux Agent（waagent）でgeneralizeします。generalizeしていないVHDをイメージとしてアップロードした場合、仮想マシンのプロビジョニングに失敗します。
• 他の仮想マシンのベースに使用せず、一個の仮想マシンのディスクとしてのみ使用する場合は、仮想マシンをgeneralizeしてはいけません。generalizeしたVHDをディスクとしてアップロードした場合、プロビジョニングに失敗します。
• サードパーティのストレージツールを使用する場合は、page BlobとしてVHDをアップロードしているか確認してください。block BlobでVHDをアップロードしているとプロビジョニングに失敗します。Add-AzureVHDとCsuploadは適切に対応します。
• 容量固定VHDのみをアップロードしてください。Windows Azure Virtual Machineは容量可変とVHDXフォーマットをサポートしていません。
  補足：CsuploadやAdd-AzureVHDを使用すると、容量可変VHDは自動的に容量固定に変換します。
• VHDの最大サイズは、127GBです。データディスクは最大1TBで、OSディスクは、127GB以下でなければなりません。
• 仮想マシンは、DHCPに設定されてなければならず、固定IPを設定してはいけません。Windows Azure Virtual Machinesは固定IPをサポートしていません。

このフォーラムの投稿に、VHDをアップロードする際の一般的な問題について説明されています。また、いくつかのストレージツールの比較については、この記事を参照してください。

5. 仮想マシンを削除しても、前の仮想マシンのDNS名を再利用できない

仮想マシンを削除しても、関連付けられていた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「仮想マシン作成時に指定する二つの「名前」」も合わせて参照してみてください。

6. リモートデスクトップの接続問題

リモートデスクトップの接続問題は、顧客が遭遇するもっとも一般的な問題で、単純なクライアントのファイヤーウォールの問題からプラットフォームの問題まで原因が多岐にわたります。まず最初にクライアントサイドから問題切り分けを始めるべきです。

• PsPingやPortQry、Telnet、Nmapのようなツールを使用して、リモートデスクトップエンドポイント用のTCPポートにピングを打って、クライアントサイドのファイヤーウォールの問題が無いか確認します。クライアントマシンがRDPエンドポイント（クラウドサービスに最初にデプロイした仮想マシンはポート3389番で、同じ仮想マシンに2つ目以降の仮想マシンをデプロイすると49152～65535の間のランダムな番号になります）とアウトバウンド通信できているかを見ます。
  通信ができない場合は、会社NWのファイヤーウォールで、3389や49152～65535番のポート通信をブロックしている可能性もあるので、自宅やモバイル通信など別のNWで試してみてください。
• Drew McDaniel さんが、フォーラムに証明書キャッシュやエンドポイント絡みの一般的な問題について投稿しています。
• 上記手順で問題が解決しない場合、仮想マシンの再起動やサイズ変更を試してみてください。問題が継続する場合は、サポートフォーラムを使用してください。

7. 仮想マシンのアクティベーション

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"

この問題に留意し、解決するために動いております。サーバー上でサービスを動かすにあたり、アクティベーションステータスは影響はありません。

詳細はフォーラムの投稿を参照してください。