Azureなう

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