Azure Updateいろいろ (2014/08/01）

2014/08/022014/08/02 / buchizo / コメントする

8月ですね（白目

というわけでUpdateがいくつかありましたので簡単に紹介します。

Azure SQL Database introduces geo-restore, standard geo-replication, and auditing

Azure SQL Database adds new features
新しいTier（Basic/Standard/Premium）に機能が追加されました
Auditing (監査）

※プレビューポータルとAPIからのみ利用可
更新や問い合わせなどデータベースで発生するイベントについて監査ログをとることができます（ストレージに吐き出す感じ）
コンプライアンス対策などにいいですね
Basic/Standard/Premiumで使えます

Standard Geo-Replication

非同期にレプリケーションされるセカンダリデータベース
リージョンをまたぎます
StandardとPremiumのみで利用できます
セカンダリデータベースはプライマリデータベースの75%のコストが発生します（高いなぁ）

Geo-Restore

メインのデータセンターに障害が発生した際に任意のGEOへDBをリストアできるようです。
地理冗長BLOBストレージを使って毎日バックアップをとるようです
Basic/Standard/Premiumで利用できます

きっとSEの雑記の中の人こと金麦殿（ムッシュ）が詳しく…
表にするとこんな感じ（公式参照）

New regions for HDInsight: East Asia, North Central US and South Central US

HDInsightが東アジア、US中央北、US中央南で利用可能になりました
どうでもいいですけど、ポータル上でのHDInsightのアイコンがHadoopのアイコン（黄色い象）になりましたね…

Azure Scheduler available in Brazil South region

スケジューラーがブラジル南リージョンで利用可能になりました

Updated Notification Hubs pricing

9月1日から通知ハブの価格が改定されるようです
通知ハブの料金詳細
ちょっと機能的にもかわってる様子（料金表を見る限り）

バルクインポートとかスケジュールPushとかリッチな測定とか

FREEでのプッシュ可能数が100万までに増えましたがブロードキャストできるタグサイズとかにリミットついたり
月あたりのプッシュ数で追加料金かかるようです（そのかわり基本料が安くなったりいろいろ）
基本的には低価格化？

General Availability: Zone Redundant Storage

予告されていた通り、ストレージの冗長化にゾーン冗長化（ZRS）が増えました（GAしました）
ZRSはLRSと同様におなじリージョン内で3複製を持ちますが、LRSと異なり2～3の施設をまたいで冗長化します
なのでLRSよりは設備的に耐久性が高くなります（リージョンとしては同一）
料金も変わります（→ 料金詳細）
現状はBLOBのみ利用可能
作れるけど寂しい。
新ポータルだとまぁそれなりに
ZRSがBLOBだけということもあり、他の冗長化と気楽に変更したりはできなさそうですね（今のところ）
ちなみにAzure Storage Explorerとかだとエラーになって操作できず（QueueとかTableも見てるせい？）

Shared Cacheの終了

9月1日でSharedキャッシュが終了する予定です
Silverlightの旧ポータルも同時に終わる予定

Microsoft MVP for Microsoft Azure

2014/07/022014/07/02 / buchizo / コメントする

受賞できました。4年目です。

また1年間いろいろがんばりたいと思います。

※ Windows Azure から Microsoft Azureになりましたねそういえば。

Azure のネットワークACLの挙動

2014/07/012014/07/01 / buchizo / コメントする

こういうお話がありました。

Azure ACLの動きがおかしいのですが、ACLはLBに設定されるのか？ホストに設定されるのか？ご存知の方いますか？ #azurejp

— shunsaka (@shunsaka) June 30, 2014

結論からいうと、LBとかじゃなくてホストサーバー上の設定なのでVNET（特に拒否の設定）指定ができちゃいます。

とはいえちょっと気になったので見てみることにします。こんなVNET to VNETなネットワークをAzure上で組んでみました。

ca1-srv1-vnet1 なインスタンスにIISを入れてHTTP（tcp/80）なエンドポイントを定義します。（LBは省略しました）

ネットワークACL（エンドポイントACL）を何も設定しない際に各インスタンスで内部のIPアドレスと外部のFQDN（図だとca1.cloudapp.net）にブラウザで接続してIISの既定のページが見れることは確認済みな状態とします。（Azure外のクライアントも当然OK）

※ようは疎通できてる状態

さて、以下の表のような感じでACLを定義したときに、それぞれのインスタンスから内部IPとFQDNでアクセスしてどうなるかを見てみました。

ACLの状態	ca1-srv1-vnet1		ca1-srv2-vnet1		ca2-src1-vnet1		ca3-srv1-vnet2		外部PC
	内部IP	FQDN	内部IP	FQDN	内部IP	FQDN	内部IP	FQDN	FQDN
vnet1のみ許可	OK	OK	OK	OK	OK	NG	OK	NG	NG
vnet1のみ拒否	OK	OK	NG	OK	NG	OK	OK	OK	OK
vnet2のみ許可	OK	OK	OK	OK	OK	NG	OK	NG	NG
vnet2のみ拒否	OK	OK	OK	OK	OK	OK	NG	OK	OK
外部PCのみ許可	OK	OK	OK	OK	OK	NG	OK	NG	OK
外部PCのみ拒否	OK	OK	OK	OK	OK	OK	OK	OK	NG
ca1のGIPのみ許可	OK	OK	OK	OK	OK	NG	OK	NG	NG
ca1のGIPのみ拒否	OK	NG	OK	NG	OK	OK	OK	OK	NG
ca2のGIPのみ許可	OK	OK	OK	OK	OK	OK	OK	NG	NG
ca2のGIPのみ拒否	OK	OK	OK	OK	OK	NG	OK	OK	OK
ca3のGIPのみ許可	OK	OK	OK	OK	OK	NG	OK	OK	NG
ca3のGIPのみ拒否	OK	OK	OK	OK	OK	OK	OK	NG	OK

※クラウドサービスのグローバルIPアドレスは一応インスタンス上からインターネットにアクセスした際に使用されるIPアドレスを確認して設定

本来ネットワークACLは許可だけが設定されたらそのルールにマッチしないものは拒否になるはずですが、VNETを許可した場合はその辺うまく動作してない様子。

例えばvnet1だけ許可した場合だと、vnet2にいるインスタンスからもアクセスできてしまっています。（期待値としては拒否してほしい）

ただ拒否設定の場合は想定どおりになるようなので、何とも不可思議な挙動です。（表中で怪しいところをわかりやすくしようと思ったけど、面倒くさくなったので放置）

但し、ネットワークACLのドキュメントを見る限りでは

仮想ネットワークに対して ACL を指定したり、仮想ネットワーク内にある特定のサブネットに対して ACL を指定したりすることはできません。

とあるので今のところこのあたりの挙動は想定外なのかもです。今後に期待。

また、ネットワークACLのパケットフィルタ処理はホストノード上で実行されるようです。

ACL を作成して仮想マシンのエンドポイントに適用するとき、パケットフィルターが VM のホストノードで実行されます。これは、リモート IP アドレスからのトラフィックのフィルター処理が、VM 上ではなく、ホストノードによって実行され、ACL ルールとの照合が行われることを意味します。これにより、パケットフィルターの処理で VM が重要な CPU サイクルを消費するのを防ぐことができます。

上位のFWとかルータじゃなかったのねー。

まぁとりあえず現状はVNETに対するACLは微妙にノンサポートという感じですので、もし制限したい場合はご注意ください。（意図せず外部はOKになったりする可能性があります）

ブチザッキ

いわゆる雑記

Azure

Microsoft MVP for Microsoft Azure