Windows Azure

Virtual Machine名とホスト名とDNSの関係

image

 

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上のホスト名を変更しても、他の仮想マシンから変更後のホスト名では接続することができません。

/etc/resolv.conf ネームサーバーの設定

次のような感じで設定されています。

; generated by /sbin/dhclient-script
search 2d2eae9005.test.27672059.asiaeast.internal.cloudapp.net
nameserver 10.146.190.200

Linuxのイメージを作成する方法

1.初期化処理を実行する

Linuxのイメージを作成するには、WindowsのSysprep的な処理を実行する必要があります。
Linuxでは、Windows Azure Linux Agentが、その機能を提供しています。

次のコマンドを実行すると、必要な初期化をしてくれます。

sudo waagent –deprovision

コマンドを実行すると、次のような警告と処理継続の確認が表示されます。

image

  • waagentサービスは停止します
  • 全てのSSHホストキーのペアーは削除されます
  • /etc/resolv.conf ネームサーバーの設定を削除します
  • DHCPリースのキャッシュを削除します
  • rootのパスワードを無効化します。rootでログインできなくなります。

この処理をすることで、ホスト名が初期化されます。この処理を飛ばすとホスト名が初期化されないため、イメージから仮想マシンを作成する際にVirtual Machine名を指定したものにならず、同じホスト名のままになり、2つ以上作成できないという悲劇が待っています。

確認方法として、$ cat /etc/sysconfig/network を確認すると、hostname が localhost.localdomain に変更されていることが重要と思われます。補足として、/etc/sysconfig/network-scripts/ifcfg-eth0 や /etc/resolv.conf も書き換えられます。

2.仮想マシンを停止し、Captureを実行する

仮想マシンのコンソールから抜けて、仮想マシンをシャットダウンします。

image

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つ目以降は正常に作成が完了しません。

image

イメージから仮想マシーンを作成したときのユーザとパスワード

キャプチャーをしようとしている仮想マシンには、仮想マシンを作成する際に指定したユーザーが存在しています。このユーザーは、キャプチャーしてイメージを作成した際に削除されません。

そのためキャプチャーしたイメージから新たに仮想マシンを作成する際に、管理者アカウントに別のユーザーを指定すると、ユーザーが追加で削除され、新旧の管理者アカウントが残ります。

image

上の図で、gloopsとnoraというユーザーがいることがわかります。
gloopsはイメージを作成したときに使用した仮想マシンの管理者アカウントです。
noraは、キャプチャーしたイメージから新たに仮想マシンを作成するときに指定した管理者アカウントです。

仮想マシン名とDNS名

次の図のように、仮想マシンは、DNS名に紐づきます。
同じDNS名に登録されている仮想マシン間はVirtual Machine名で直接通信でき、エンドポイントの設定に関わらずすべてのポートと通信することができます。。別のDNSにある仮想マシン間では、直接通信できません。
test01から、test03に通信するにはDNS名(example.cloudapp.net)でグローバルから接続する必要があり、その際には、エンドポイントで指定したポートでのみ通信できます。

image

参考

How to Capture an Image of a Virtual Machine Running Linux

Windows Azure

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

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

VMの削除

image

.vhdをダウンロードする

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

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

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

image

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

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

image

サイズ変更した.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

Windows Azure

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 VMsの最大メモリ容量は14GB。
OS用のメモリとコネクション用に2~3GBと想定すると残り11GB。
必要なデータをメモリ内に格納できる範囲が性能限界点になるのかなぁと思います。

ストレージ

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

tempdb

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

image

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

データストア

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

image

Windows Azure

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

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

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

Windows Azure

Windows Azure Virtual Machinesの概要で紹介した、Windows Azure Virtual Machinesで死活監視をしながら、ロードバランシングする手順を実際にやってみました。
手順のインプット情報は、Automating Windows Azure Virtual Machines with PowerShellです。

Windows Azure PowerShellコマンドレットの入手

image
https://www.windowsazure.com/en-us/manage/downloads/

から、Windows Azure PowerShellコマンドレットを入手して、インストールします。

Windows Azure Powershellを使用する方法

スタートメニューから、Windows Azure PoerShellをクリックする。

image

もしくは、モジュールをコマンドレットでインポートします。

Import-Module 'c:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Microsoft.WindowsAzure.Management.psd1'

サブスクリプションの設定

Windows Azureの操作をするための設定を一番簡単にする方法は、

https://windows.azure.com/download/publishprofile.aspx

にアクセスして、設定ファイルをダウンロードすることです。

ダウンロードした設定ファイルをインポートします。

Import-AzurePublishSettingsFile ‘c:\temp\mysub.publishsettings’

設定結果を確認したい場合は、次のコマンドを実行します。

Get-AzureSubscription

手動で、サブスクリプションの設定をしたい場合は、Set-AzureSubscriptionで、サブスクリプションIDと管理証明書を設定します。

$subid = ‘[YOUR-SUBSCRIPTION-ID]’

$cert = Get-Item Cert:\CurrentUser\My\YOURCERTTHUMBPRINT

Set-AzureSubscription -SubscriptionName ‘testsub1’ -SubscriptionId $subid -Certificate $cert

 

補足:インポートしたり、手動で設定したサブスクリプション情報は、次のディレクトリに格納されます。

C:\Users\user\AppData\Roaming\Windows Azure Powershell

image

ここにファイルが存在する場合、スクリプトごとにSet-AzureSubscriptionを実行する必要はありません。

コマンドレットは複数のサブスクリプションに対応しており、Select-AzureSubscriptionコマンドレットで、アクティブなサブスクリプションを切り替えて、処理を実行できます。

Virtual Machinesの設定変更

Windows Azure Virtual Machinesの設定変更をするには、「get-azurevm」で

変更したいVMを指定します。

パイプラインで設定変更処理を記述します。

処理を記述後、パイプラインで結んで「Update-Azure」を実行します。

VMの指定方法

次の例では、VM名が「ce03」と「ce01」が含まれたサービス名「eva」と、VM名「win01」を含んだサービス名「wino4」があります。

evaのce01を指定するには、

「Get-AzureVM -ServiceName "eva" -Name "ce01"」と指定します。

image

image

ロードバランシングの指定方法

ロードバランシングは、Windows Azure VMのエンドポイントで定義します。

次の図のように、ヘルスチェック機能を持っているので、特定ファイルにアクセスできるかどうかで、死活監視チェックができます。

エンドポイントを追加するには「Add-AzureEndpoint」コマンドレットを使用します。

Add-AzureEndpoint -Name "HttpIn" -Protocol "tcp" -Public

Port 80 -LocalPort 8080 -LBSetName "WebFarm" -ProbePort 80 -ProbeProtocol "http" -ProbePath "/health.txt"

このスクリプトを実行すると、Windows Azure PowerShellウィンドウ上に進行状況が表示されます。

image

処理が完了すると、次のように処理結果が表示されます。

image

Add-AzureEndPointで指定したプロパティName、Protocol、PublicPort、LocalPortと

Windows Azure管理ポータル上での表記の関係は次の通り。

ロードバランシングの部分は画面上に表示されません。

image

  • LBSetName

    ロードバランサーのエンドポイント名を定義します。

    クラウドサービス内にある複数の仮想マシンがロードバランサーのエンドポイントを使用できます。

  • ProbePort

    死活監視に使用するパブリックポートの指定。指定しない場合は、ロードバランサー用の

    ポートと同じポートを使用します。

  • ProbeProtocol

    死活監視に使用するプロトコルを使用します。「http」、「TCP」のどちらかのみ使用できます。

    「TCP」を指定すると、死活監視要求では「ACK」を受け取ります。

    「HTTP」を指定すると、死活監視用のURLから「200 OK」を受け取ります。

  • ProbePath

    ProbeProtocolに「http」を設定した場合、死活監視に使用するURIを指定します。

詳細は、Add-AzureEndpointのリファレンスを参照してください。

更新の実行

最後に、更新処理を実行するための「Update-AzureVM」をパイプラインでつなげればOK。

Update-AzureVM

サンプルスクリプト

死活チェック付エンドポイントの追加

get-azurevm -ServiceName "win04" -Name "win01" | Add-AzureEndpoint -Name "HttpIn"

-Protocol "tcp" -PublicPort 80 -LocalPort 80 -LBSetName "WebFarm" -ProbePort 80 -ProbeProtocol "http" -ProbePath "/" | Update-AzureVM

死活チェック付エンドポイントの更新

get-azurevm -ServiceName "win04" -Name "win01" | Set-AzureEndpoint -Name "HttpIn" -Protocol "tcp" -PublicPort 80 -LocalPort 80 -LBSetName "WebFarm" -ProbePort 80 -ProbeProtocol "http" -ProbePath "/" | Update-AzureVM

特定VMのエンドポイントの確認

get-azurevm -ServiceName "eva" -Name "ce03" |get-AzureEndpoint

特定VMの特定エンドポイントの確認

get-azurevm -ServiceName "eva" -Name "ce03" |get-AzureEndpoint -Name "HttpIn"

 

検証確認

Win2012 & IIS のVM2つ

特に問題なく、10分ほどで死活チェック付のロードバランシング構築完了。

死活チェックは15秒に1回実施されているので、15秒ほどで切り替わることを確認できた。

IISのログには次のような記録が残っている。

2012-06-12 20:12:53 10.146.154.34 GET / – 80 – 10.146.154.190 Load+Balancer+Agent – 200 0 0 2

2012-06-12 20:13:08 10.146.154.34 GET / – 80 – 10.146.154.190 Load+Balancer+Agent – 200 0 0 0

2012-06-12 20:13:23 10.146.154.34 GET / – 80 – 10.146.154.190 Load+Balancer+Agent – 200 0 0 0

2012-06-12 20:13:38 10.146.154.34 GET / – 80 – 10.146.154.190 Load+Balancer+Agent – 200 0 0 1

2012-06-12 20:13:53 10.146.154.34 GET / – 80 – 10.146.154.190 Load+Balancer+Agent – 200 0 0 2

image

CentOS & nginx のVM2つ

上手くロードバランシングさせられず。。。。

VMそれぞれでエンドポイントを追加して接続すると、両方のVMのnginx HellowWorldを確認。

死活チェック無しのロードバランシングを組むと、正常に動作していることを確認。

死活チェック有り(パスは「/」)だと、両方ダウンしていて接続できない・・・・・・。

nginxのアクセスログは次の通り「200」を返しているのだけど。。。。

10.24.202.190 – – [12/Jun/2012:20:18:47 +0000] "GET / HTTP/1.1" 200 155 "-" "Load Balancer Agent" "-"

10.24.202.190 – – [12/Jun/2012:20:19:02 +0000] "GET / HTTP/1.1" 200 155 "-" "Load Balancer Agent" "-"

10.24.202.190 – – [12/Jun/2012:20:19:17 +0000] "GET / HTTP/1.1" 200 155 "-" "Load Balancer Agent" "-"

10.24.202.190 – – [12/Jun/2012:20:19:32 +0000] "GET / HTTP/1.1" 200 155 "-" "Load Balancer Agent" "-"

10.24.202.190 – – [12/Jun/2012:20:19:47 +0000] "GET / HTTP/1.1" 200 155 "-" "Load Balancer Agent" "-"

10.24.202.190 – – [12/Jun/2012:20:20:02 +0000] "GET / HTTP/1.1" 200 155 "-" "Load Balancer Agent" "-"

ちなみにロードバランシングさせるために使用したPowerShellコマンドは、Windowsの名前とサービス名を変更しただけなので、設定ミスではないと思われ。。。