In a joyful way

ゆるーっと。ふわーっと。楽しくいきましょ。

Azure IaaS?復習的な

夏休みの宿題的なアレで、
やっと重い腰を上げてde:code 2016のセッションを拝見しております。(台風だし

1本目は、池田さんの「Azure IaaS 最新動向」
知ってる内容多めでも、再認識することが多く、タメになったのでご紹介。

channel9.msdn.com

特にAzure IaaS(AWS EC2も)を「えいやっ!」と見積もってるのが散見されるので、
営業やプリセールの方にはしっかりご理解いただきたいところですねっ★

そもそもAzureにも、EC2のT2/C3/M4/I2などのInstance Typeと同様に、
SKU Familyとして用途ごとにシリーズ展開しています。

  • Aシリーズ:
    A0〜7は汎用。とりあえず迷ったら、これ。A0(昔のXS)を除くインスタンスサイズでは物理コア占有になることも地味にEnterprise向きだと思っている。A8〜11はHPC向けなので、Nシリーズほどは使わないけど…な時にご利用ください。
  • D(DS / v2)シリーズ:
    Aシリーズは揮発性ローカルストレージ(EC2でいうところのInstance Store、Ephemeral Diskのこと)がHDDの一方で、D(DS)シリーズはSSDで構成されているのが大きな違い。頻繁にファイルへのRead/Writeが多いAPなどはローカルストレージで処理して、一定間隔で永続ストレージへ保存してちょ。
    また、積んでいるCPUがAシリーズよりも高性能なので、ACU(Azure Compute Unit)という指標では、Aよりも60%向上、Dv2は35%(Aに比べると約210%)向上となります。
  • F(Fs)シリーズ:
    こちらもDv2と同様に2.4 GHz Intel Xeon® E5-2673 v3 (Haswell)、Intel Turbo Boostも利用可能を積んでいるインスタンスとなります。D / Dv2と比べるとRAMとDiskサイズが小さめなのでバッチなどCPUぶん回す系でご利用いただければ。
  • G(GS)シリーズ:
    出た当時はGozillaとしてちょろっと有名になったGシリーズ。DよりもRAM 2倍、SSD 4倍ということで、超ハイスペックインスタンス。課金が怖すぎる。。。
  • N(NV / NC)シリーズ:
    GPUNVIDIA Tesla M60もしくはK80を搭載した)インスタンス。サーバ側でのレンダリング処理など用途。Nシリーズは先日Public Previewが始まったところ。

上記の説明中でもちょろっと出たACUですが、
リンク先にある通り、同じCPU / RAMを積んでいても全然異なるわけで。
これまでの仮想環境で「1コア / 2G割り当ててるから、そのまま」と見積もる前に、ぜひ一度ご参照ください。

azure.microsoft.com

 

あとは最近気になるのは、Fault Domain(障害ドメイン)とUpdate Domain(更新ドメイン)があまり普及してなさそう、だな、と。昔からある考え方なんですけどね。

  • Fault Domain(FD):
    物理HW・NW・電源障害など計画外メンテナンスに備えて、物理的に異なるラックにVMがデプロイされます。(最大3個。0〜2で表現)
  • Update Domain(UD):
    Cloud ServicesのAP更新や、可用性セット(Availability Set)を組んだIaaSにおいて計画メンテナンスなどに向けて、FD内に分散配置され、更新はUD1つずつ(同時実行なし)行われます。(最大20個。0〜19で表現)

ちなみに同じ機能のVMを何台立てていても、同一の可用性セットに入れていない限り、SLAが担保されず、Single Nodeとして起動しているのと同義なので、ご留意を。
この辺はFabric Controllerが制御している内容になるので、ユーザ側では制御できません。In-place Migrationなども適用されているので、計画的メンテナンスは減る、はずw

また、「AWSだとEC2の再起動によりパッチ適用済みのホストに移動してくれる(Instance stop)から、メンテナンスがある程度コントロール可能だけどAzureはできない」という話がありますが、Azureでも同じことはできるようです。(でも可用性セットから一度外すっていうのは、なんとも微妙ではあるけど…

azure.microsoft.com

 

最終的に違う話になりましたが、備忘録的にご活用いただければ幸いです。

Microsoft MVPを再受賞しました

Microsoft MVP for Microsoft Azureを再受賞させていただきました。

ということで遅まきながら再受賞のご報告です。
今回はいつも以上に下期は勉強会開催回数が少な目だったりして、
どうなることやら…と心配しておりましたが、再受賞させていただけました。

この1年はまた初心忘れるべからず、として、
女性向けの勉強会や初心者向けの皆さんへ新機能紹介などなどを
広くご紹介・ご案内していただけたらと思います。

至らない点も多々ありますが、何かありましたらお気軽にご相談くださいませ。

f:id:sao_a:20160403212936p:plain

JAZUGやMS社員の皆様、友人の皆様に深く、大きな感謝を。
ありがとうございました。引き続き宜しくお願いします♡

…ちなみにBlogをWordpressからはてなに移行しました、えへっ

Network Gateway

会社で先輩に「Local network gatewayとVirtual network gatewayの違いって何よ?」って聞かれて、即答できなかったので備忘録。

NW周りは全然使ってないのでしっくりきてなくて、ダメっすな。

まずはAzure Portalに書いてある概要から。

Virtual network gateway

A virtual network gateway is the software VPN device for your Azure virtual network. Use this with aconnection to set up a site-to-site VPN connection between an Azure virtual network and your local network, or a VNet-to-VNet VPN connection between two Azure virtual networks. It can also be used to connect a virtual network to an ExpressRoute circuit. Microsoft Azure provides a 99.9% uptime SLA for virtual network gateways.

勘のいい方(てか英語が読める方)なら、これでもう解決ですね。 Site to SiteでVPNをはろうとする時に、Azure側のGWとしてVirtual network gateway、オンプレ・プライベートクラウド側に擬似的に置くGWとしてLocal network gatewayが必要です、という話でした。ちなみにLocal network gatewayは作成した後にHW or SWのVPN装置と紐付ける必要があるので、お忘れなく。

簡易でお試ししてみようという方には、「Azure自習書」にある「ローカルネットワークとの VPN 接続」がStep by stepで書いてあるので、非常に分かりやすいです。ぜひお試しあれ★ 自習書では、仮想マシンを社内NW内にあるPC 兼 SW VPN装置(Windows ServerのRRAS およびルーティング機能)として構成しています。

Traffic ManagerにExternal Endpointを追加してみた

さて、GoAzureの現実逃避を兼ねて、 直前で、Traffic ManagerにExternal Endpointが追加したい件というのを 2、3年ぶりにBlog postしていて、その後触れていなかったので、備忘録も兼ねて、検証結果をpostしときます。

続きを読む

Traffic ManagerにExternal Endpointが追加したい件

TechEd NAで発表になっていた、 Traffic Managerに外部エンドポイントが追加可能というのを試したくて、 ズルズルと触れずに終わっていた訳ですが、現実逃避もかねて遊んでみました。

…が、結果から言うと、Traffic Manager様が遊んでくれませんでした(・×・)

この辺りの公式Blogを参考にPowerShellでExternal Endpointを追加してみたワケですが、 下図のかんじでExternal EndpointのStatusが「低下」と表示されて、 ラウンドロビン設定してるにも関わらず、全くラウンドしないという・笑

手元に使える環境がないからって、sample通りMSサイトを試しに登録したことは責めるべからず。

スクリーンショット 2015-01-12 1.39.20

ちなみにExternal Endpointだけ登録というのも可能には可能でした。 が、どっちのサイトにもルーティングされず、悲しい気持ちになりました。

GoAzure 2015が終わったら、もうちょっとまじめに遊んでみたいと思います。 現実逃避おわり。

公開ラブレターのお返事

昨年、@ayakomuro さんに公開ラブレターを頂いて、 JAWS-UGクラウド女子会さんと合同勉強会を開催させてもらったわけですが、 はたっとそのお返事を書いてないことに気づき、 1年越しでラブレターのお返事をしたためようかと思って、このEntryを書いてみました。

2012/6/7のUpdateWindows AzureVirtual MachineでIaaS Likeなことが出来るようになりましたし、 一方でAWSBeanstalkでの.NETサポートの発表もあり、 PaaSっぽい側面も強まってきたのかな、と個人的には思ったり。

という感じで、昨年やった合同勉強会から、 Windows AzureAWSも大きく変わってきたと思います。 なので、ここいらいで第2回JAWS-UGクラウド女子会×JAZUG女子部合同勉強会開催しませんか? 福岡にお住まいなので、なかなか日程等難しいと思いますが、ご検討頂けますと幸いです♡

p.s. 第2回もぜひ@shin135 さんと@KenTamagawa さんにぜひ女子向けプレゼンをお願いしたく! お二人にも追ってご協力依頼させてくださいませ♪

Active Directory on AWSのドメインにWeb Roleを参加させてみよう

クリスマス目前! ということで、そろそろWindows Azure Advent Calendar jp: 2011にJoinさせてもらいます! 今回のテーマは、タイトルにもあるように、AWS(Amazon Web Service)上に立てた Active DirectoryにWeb Roleを参加させてみようと思います。

思い起こせばこのネタ、Developers Summit 2011にて、 ConnectのLive Demoで魔物に取りつかれておもっきり失敗し、 その後どこでもお話する場がなかったので、約1年越しでようやくお披露目することが出来ました。 # その節は、ご迷惑をおかけしました! > 関係者各位 …とまぁ、前振りが長すぎてもなので、早速本題行ってみましょう! 

1. AD用のインスタンスAWS上で立ち上げる AWS Management Console(Azure Portalと同じかんじ)から、AMIを選択し、EC2インスタンスを立ち上げます。 今回の検証に利用したAMIとセキュリティグループは下記の通りです。 AMI:Microsoft Windows Server 2008 R2 Base (AMI Id: ami-78e65179) セキュリティグループ: Inbound 3389(RDP)のみ許可 Windows Azure Connectは、Outbound 443さえ許可されていれば、 通信可能なので、Inboundは適宜必要なものだけ開放してください。

2. Active Directoryをインストール インスタンスが起動出来たら、RDPでログインし、 役割の追加から「Active Directoryドメインサービス」をインストールします。 今回は簡易検証なので、ローカルストレージにインストールしましたが、 永続化が必要な場合には、Amazonさんが出しているこのあたりの資料を読んで頂いて、 EBS(Azure Driveに似た機能)で永続化を図ってください。 ちなみにIPアドレスDHCPによって割り振られているので、下記の警告が出ますが、「はい」を選択 してください。

 

3. Windows Azure Connect ローカルエンドポイントをインストール Active Directoryのインストール→再起動が終わったら、 Azure Portalにアクセスし、Connectのローカルエンドポイントをインストールしましょう! 正しくインストールできた場合には、下図のIPアドレス欄に「2a01:」で始まるIPv6アドレスが追加されているはずです。 このIPv6アドレスを使ってConnectが通信を行います。  

4. Webロールをデプロイ! デプロイ前にロールの設定から下記の項目を設定しておきましょう。 パスワードはリモートデスクトップのパスワードと同様に暗号化する必要があります。 CSEncryptコマンドパスワードを暗号化するか、リモートデスクトップのパスワード暗号化を使って、 暗号化された文字列をゲットしてください。また、任意となっている項目は必要に応じて適宜設定してください。 設定が完了したら、みんな大好き「デプローイ!」をAzureに対してしてください。 

Microsoft.WindowsAzure.Plugins.Connect.ActivationToken Connectのライセンス認証トークン 例:12345678-9abc-def1-abcd-123456789abc
Microsoft.WindowsAzure.Plugins.Connect.Refresh 設定不可
Microsoft.WindowsAzure.Plugins.Connect.WaitForConnectivity 任意
Microsoft.WindowsAzure.Plugins.Connect.Upgrade 設定不可
Microsoft.WindowsAzure.Plugins.Connect.EnableDomainJoin true
Microsoft.WindowsAzure.Plugins.Connect.DomainFQDN ドメインFQDN 例: jazgirls.local
Microsoft.WindowsAzure.Plugins.Connect.DomainControllerFQDN ドメインコントローラのFQDN 例:ip-0A96B178.jazgirls.local
Microsoft.WindowsAzure.Plugins.Connect.DomainAccountName ドメインユーザ 例:jazgirls\Administrator
Microsoft.WindowsAzure.Plugins.Connect.DomainPassword 暗号化されたパスワード
Microsoft.WindowsAzure.Plugins.Connect.DomainOU 任意
Microsoft.WindowsAzure.Plugins.Connect.Administrators 任意
Microsoft.WindowsAzure.Plugins.Connect.DomainSiteName 任意

5. ドメイン参加完了! デプロイが完了し、Roleがドメイン参加出来ているかを確認しましょう。 AWS上のADから確認するには、下図のように「Active Directoryユーザーとコンピューター」から、 「Computers」を選択し、Webロール(RDではじまるコンピュータ名)が追加されていれば成功です。 Webロール側から確認するには、「システムのプロパティ」から簡単に確認できます。 ドメインにうまく参加出来ていない場合には、 %PROGRAMFILES%\Windows Azure Connect\Endpoint\Logs\Integrator.Logを確認してください。 ドメイン参加が成功していれば下記のようなログがあるはずです。  12/18/2011 1:25:57 AM : NetJoinDomain succeeded. Target domain: jazgirls.local\ip-0A96B178.jazgirls.local 12/18/2011 1:25:57 AM : Domain join completed successfully

ということで以上、Windows Azure Advent Calendar 23日目、AWS上のADにWebロールを参加させてみよう♪でした。 今年もあと僅かですが、体調には気を付けてみなさまナイスデプロイを!