月別アーカイブ: 2014年7月

Microsoft Worldwide Partner Conference 2014 Day1

/ buchizo / コメントする

今年も始まりましたMicrosoft Worldwide Partner Conference 2014。事前の予告通り、Redis Cacheが来たりいろいろUpdateが予定されてるので楽しみです。

まぁ結果だけいうとそんなに言うほど技術寄りな話はでず。（そりゃそうだ）

Azure的には新ポータルでIaaS他触れるようになったよとか新しいパートナープログラムの話とかです。※WPCなので全体的に市場はこうだよMS的にこういうのが伸びたよ今期こうだよって話がメインです。パートナー向けに説明する会だし。

とりあえずDay1を適当にまとめました。画像でも見て気分を味わいましょう。

続きを読む →

IIJと日本マイクロソフト、マルチクラウドサービスで協業

/ buchizo / コメントする

早い話がAzure ExpressRouteの日本国内対応ベンダーの一社目がIIJさんになりましたというNewsです。

対応時期は今年度順次対応予定ということですが、閉域網接続を望んでた企業にとっては朗報ですね。

ま、検証しようがないので中の人や興味ある人は頑張って試してみてください～☆

Windows 8.1の自動メンテナンスをとめる

/ buchizo / コメントする

デスクトップPCとかだと全然意識してなかったのですが、タブレットだったりSSDだったりするといろいろ影響があるらしい自動メンテナンス。

image

※ちゃんと見てないけどSSDでデフラグしちゃうとかなんとか

で、オフにするのはなかなか難易度が高かったのですが、一応止めることができたっぽいので。自己責任で。

  1. 管理ツールのタスクスケジューラーを起動する
  2. タスクスケジューラー ライブラリーのMicrosoft\Windows\TaskScheduler を開く
  3. Regular Maintenance のプロパティ内のトリガー「Daily」（毎日）を無効にする
    image
  4. ついでにConditionsのアイドル時に開始するチェックも外せばいいんじゃないでしょうか

単にタスクを無効にしただけだとMaintenance Configuratorがまた有効にしたりするっぽいので注意しましょう。

今のところ大丈夫そうです。

止めることによる弊害は…よくわかりません。Windows Updateが自動で降りてこない…ことはないと思いますが要注意ですね。まぁ止めようと思う人はその辺大丈夫でしょう。。。何か影響あっても当方は知りません。

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

/ buchizo / コメントする

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

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

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

image

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になったりする可能性があります）