Azureなう: 3月 2015

2015/03/31

Azure Data Factory

定期間隔でファイルを指定場所に格納とか、HULFTみたいなことも。

http://azure.microsoft.com/blog/2015/03/30/azure-data-factory-update-new-data-stores/

2015/03/30

・Azure Fabricでバックアップ（Azure VM Extensionを利用）するので、仮想マシンへの負荷が、ほぼゼロ
・BackupのためのVM ExtensionはAzure Fabricによって自動運用されるため、いわゆるBackup Agentをインストールしたり運用したりの負荷は無い。
・VSSで、仮想マシンをオンラインのまま、OSごとに以下の一貫性を保ってバックアップ
　・Windows：application level consistency
　・Linux：file level consistency
・最大30日間、毎日スケジュールした時刻に
・差分バックアップ（初回のイニシャルバックアップは、筆者環境では、激しく稼働している仮想マシンが、実容量15GBで35分でした）

http://azure.microsoft.com/blog/2015/03/26/azure-backup-announcing-support-for-backup-of-azure-iaas-vms

# virtual machines, backup

2015/03/25

Azure Storage の監視

■取得できる値　※きめ細かいデータが取れます。
ログ
https://msdn.microsoft.com/ja-jp/library/azure/hh343259.aspx
Metrics
https://msdn.microsoft.com/ja-jp/library/azure/hh343264.aspx

= 例 =
AverageE2ELatency
ストレージサービスまたは指定された API 操作に対して行われた成功した要求のエンドツーエンドの平均待機時間 (ミリ秒単位)。この値には、Azure ストレージ内での要求の読み取り、応答の送信、および応答の受信確認の受信に必要な処理時間が含まれます。

AverageServerLatency
成功した要求を処理するために Azure ストレージで使用される平均待機時間 (ミリ秒単位)。この値には、AverageE2ELatency で指定されたネットワーク待ち時間は含まれません。

====

■手順の要約（実際のデータを見てみる手順例）
まず、
ログ、Metrics、それぞれについて、storage account ごとにデータ生成を有効化します。

すると、
ログ：https://<accountname>.blob.core.windows.net/$logs
Metrics：https://<accountname>.table.core.windows.net/Tables("$MetricsTransactionsBlob")
に、データが書き込まれます。

ツールを使って、書き込まれたデータを読み込みます。

■解説
概要
http://azure.microsoft.com/en-us/documentation/articles/storage-monitor-storage-account/

詳細
https://msdn.microsoft.com/ja-jp/library/azure/hh343270.aspx

# monitor, monitoring, performance, metric, log, logging
# モニタリング、パフォーマンス、メトリック、ログ

Azure Storage の読み書き

Azure Storageは、REST APIでデータの読み書きを行います。

REST APIを使ってプログラムを自分で書かなくても、PowerShellのほか、たとえば以下のGUIツールを利用することもできます。
http://blogs.msdn.com/b/windowsazurestorage/archive/2014/03/11/windows-azure-storage-explorers-2014.aspx

その他、AzCopyという名前の、強力なコマンドラインツールもあります。
http://azure.microsoft.com/ja-jp/documentation/articles/storage-use-azcopy/

Azure Storage Table Design Guide

2015/03/23

Azure Websitesの負荷分散

vNet上の負荷分散とは（見かけ上）仕組みが異なり、IISのARR(Application Request Routing)を使います。

cookie(ARRaffinity cookie)を利用して、特定のブラウザからは常に同じサーバーにアクセスできるのが設定のデフォルト。いわゆる sticky session ですね。そのブラウザを閉じると、そのcookieは消去されます。

日本語
http://blogs.msdn.com/b/windowsazurej/archive/2013/11/25/blog-disabling-arrs-instance-affinity-in-windows-azure-web-sites.aspx

英語
http://azure.microsoft.com/blog/2013/11/18/disabling-arrs-instance-affinity-in-windows-azure-web-sites/

（見かけ上）とあえて書いたのは、いったん、Azure WebsitesのPublic IPで着信したパケットは、パブリック負荷分散のAzure Load Balancerで着信しているからです。そこから、複数台並んでいるARRに負荷分散されます。

※Azure Load BalancerもARRも、隠蔽されているので設定はおろか存在も確認できないようになっています。無論、ARRがいくつ並んでいても、Azure Websitesのインスタンス数（instance count）にはカウントされません。

ARRから、Azure Websitesの各インスタンスへの、セッション振り分けロジックは、
Inside Azure Websites
が詳しいです。記載年月が古いので、各情報の最新とは異なるでしょうけど、おおまかには。

Azure Cloud Services、DNSの逆引き

http://blogs.msdn.com/b/windowsazurej/archive/2014/08/01/blog-announcing-reverse-dns-for-azure-cloud-services.aspx

# Reverse DNS

2015/03/17

トラフィックの、ポリシングとシェーピング

http://www.infraexpert.com/study/qos20.htm

# traffic, QoS, Policing, Shaping

2015/03/14

vNet間通信を使って、大陸をまたがる自社ネットワークを構築

###編集中

■vNet間 IPsecVPN接続、SharedKey設定
※4拠点のvNetが、メッシュ接続されるのでIPsecVPNが6本。対向で設定するので計12行の設定になる。
※対向となる、A地点からB地点、B地点からA地点へのSharedKeyは共通にする。
PS> Set-AzureVNetGatewayKey -VNetName japan-vnet -LocalNetworkSiteName us-vnet-local -SharedKey AAAAAAAA
PS> Set-AzureVNetGatewayKey -VNetName us-vnet -LocalNetworkSiteName japan-vnet-local -SharedKey AAAAAAAA

PS> Set-AzureVNetGatewayKey -VNetName japan-vnet -LocalNetworkSiteName europe-vnet-local -SharedKey BBBBBBBB
PS> Set-AzureVNetGatewayKey -VNetName europe-vnet -LocalNetworkSiteName japan-vnet-local -SharedKey BBBBBBBB
PS> Set-AzureVNetGatewayKey -VNetName japan-vnet -LocalNetworkSiteName asia-vnet-local -SharedKey CCCCCCCC
PS> Set-AzureVNetGatewayKey -VNetName asia-vnet -LocalNetworkSiteName japan-vnet-local -SharedKey CCCCCCCC

PS> Set-AzureVNetGatewayKey -VNetName us-vnet -LocalNetworkSiteName europe-vnet-local -SharedKey DDDDDDDD

PS> Set-AzureVNetGatewayKey -VNetName europe-vnet -LocalNetworkSiteName us-vnet-local -SharedKey DDDDDDDD
PS> Set-AzureVNetGatewayKey -VNetName us-vnet -LocalNetworkSiteName asia-vnet-local -SharedKey EEEEEEEE

PS> Set-AzureVNetGatewayKey -VNetName asia-vnet -LocalNetworkSiteName us-vnet-local -SharedKey EEEEEEEE

PS> Set-AzureVNetGatewayKey -VNetName europe-vnet -LocalNetworkSiteName asia-vnet-local -SharedKey FFFFFFFF

PS> Set-AzureVNetGatewayKey -VNetName asia-vnet -LocalNetworkSiteName europe-vnet-local -SharedKey FFFFFFFF

■vNetから見たIPsecVPN接続の確認
PS> Get-AzureVNetConnection -VNetName japan-vnet

2015/03/11

仮想マシン・オブジェクトに含まれる情報一覧、出し方の例

以下の例では、値がオブジェクトのもの以外は、値を消しています。

まずは、一層目の一覧を出します。

===
PS> $test = get-azurevm -ServiceName hogehoge -name sampleVM
PS> $test

DeploymentName :
Name :
Label :
VM : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVM
InstanceStatus :
IpAddress :
InstanceStateDetails :
PowerState :
InstanceErrorCode :
InstanceFaultDomain :
InstanceName :
InstanceUpgradeDomain :
InstanceSize :
HostName :
AvailabilitySetName :
DNSName :
Status :
GuestAgentStatus : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.GuestAgentStatus
ResourceExtensionStatusList : {}
PublicIPAddress :
PublicIPName :
NetworkInterfaces : {}
VirtualNetworkName :
ServiceName :
OperationDescription :
OperationId :
OperationStatus :

オブジェクトのなかでドリルダウンを続けます。

■入れ子になっている".VM"オブジェクトのなか

PS> $test.VM

AvailabilitySetName :

ConfigurationSets : {Microsoft.WindowsAzure.Commands.ServiceManagement.Model.NetworkConfigurationSet}

DataVirtualHardDisks : {}

Label :

OSVirtualHardDisk : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.OSVirtualHardDisk

RoleName :

RoleSize :

RoleType :

WinRMCertificate :

X509Certificates :

NoExportPrivateKey :

NoRDPEndpoint :

NoSSHEndpoint :

DefaultWinRmCertificateThumbprint :

ProvisionGuestAgent :

ResourceExtensionReferences : {}

DataVirtualHardDisksToBeDeleted :

PS> $test.vm.ConfigurationSets

ConfigurationSetType :

InputEndpoints : {}

SubnetNames : {}

VirtualIPGroups :

StaticVirtualNetworkIPAddress :

PublicIPs : {}

NetworkSecurityGroup :

NetworkInterfaces : {}

ExtensionData :

PS> $test.vm.DataVirtualHardDisks

HostCaching :

DiskLabel :

DiskName :

Lun :

LogicalDiskSizeInGB :

MediaLink :

SourceMediaLink :

IOType :

ExtensionData :

PS> $test.vm.OSVirtualHardDisk

HostCaching :

DiskLabel :

DiskName :

MediaLink :

SourceImageName :

OS :

IOType :

ExtensionData :

PS> $test.vm.ResourceExtensionReferences

ReferenceName :

Publisher :

Name :

Version :

ResourceExtensionParameterValues :

State :

ExtensionData :

■入れ子になっている".GuestAgentStatus"のなか

PS> $test.GuestAgentStatus

ProtocolVersion :

TimestampUtc :

GuestAgentVersion :

Status :

Code :

Message :

FormattedMessage : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.GuestAgentFormattedMessage

ExtensionData :

PS> $test.GuestAgentStatus.FormattedMessage

Language Message ExtensionData

■入れ子になっている".ResourceExtensionStatusList"のなか

PS> $test.ResourceExtensionStatusList

HandlerName :

Version :

Status :

Code :

Message :

FormattedMessage :

ExtensionSettingStatus :

ExtensionData :

2015/03/04

負荷分散、まとめ

■最初におさえるべきルール
エンドポイントのルール
負荷分散セットのルール

■パケットの流れの例

■内部負荷分散セット

■おまけ

Azure Load Balancer、負荷分散装置、のアルゴリズム（詳細）

以下、各種パラメータについて。重要な順に。

■Probe方法(負荷分散する場合の、各エンドポイントの死活監視)
◇Probeしない
-NoProbe
◇パラメータ指定なしのProbe

-DefaultProbe

◇パラメータ指定ありのProbe
-ProbeProtocol (http or tcp)

◇-ProbeProtocol利用時に、追加で指定できるパラメータ
-ProbePort
デフォルト：LocalPortで指定したポート番号
-ProbeIntervalInSeconds
デフォルト：15（秒）
-ProbeTimeoutInSeconds

デフォルト：31（秒）

-ProbePath　※HTTP Probeのときのみ。

■負荷分散アルゴリズムの指定に関わるパラメータ
-LoadBalancerDistribution
デフォルト：none（送信元IP、送信元ポート、送信先IP、送信先ポート、プロトコル、を元にしたハッシュ）

■アイドルタイムアウトのパラメータ
-IdleTimeoutInMinutes
デフォルト：4（分）
最大：30（分）

■SQL Server AlwaysOnのためのパラメータ
https://msdn.microsoft.com/ja-jp/library/azure/dn469417.aspx
※あとから設定変更できないので、注意
-DirectServerReturn

デフォルト：false
SQL Server AlwaysOnで利用する場合：true

このパラメータを true にした場合のパケットの流れは、筆者は未調査ですが、おそらく、
http://nosa.cocolog-nifty.com/sanonosa/2004/11/l4dsr.html
に Direct Server Return で記載されているような流れになると推測します。

負荷分散先の死活監視

たとえば、
Add-AzureEndpoint
で、下記パラメータを指定した場合。

-ProbeProtocol http -ProbePath /probe.htm -ProbePort 80

負荷分散先の Web Server(IIS) のログは、例えばこんな感じでした。
=== Web Server(IIS) の IPアドレス：172.19.1.4
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2015-03-04 05:08:04 172.19.1.4 GET /probe.htm - 80 - 168.63.129.16 Load+Balancer+Agent - 200 0 0 32
2015-03-04 05:08:19 172.19.1.4 GET /probe.htm - 80 - 168.63.129.16 Load+Balancer+Agent - 200 0 0 19
2015-03-04 05:08:34 172.19.1.4 GET /probe.htm - 80 - 168.63.129.16 Load+Balancer+Agent - 200 0 0 15
2015-03-04 05:08:49 172.19.1.4 GET /probe.htm - 80 - 168.63.129.16 Load+Balancer+Agent - 200 0 0 22

===

ここでの 168.63.129.16 は、Azure datacenter のIPアドレスで、ここから正常性Probe(health probes)が発信されます。

なお、"168.63.129.16"は筆者環境下におけるものです。このIPアドレスは環境により、変動します。

Network Security Groups における、AZURE_LOADBALANCER デフォルトタグ(default tag)は、このIPアドレスに変換されます。

負荷分散、まとめ
http://taleofazure.blogspot.jp/2015/03/blog-post_4.html