Japan Azure IaaS Support Blog https://docs.microsoft.com/archive/blogs/jpaztech/feed.xml 日本マイクロソフトの Azure IaaS テクニカル サポート チームより、情報をお届けします！ Fri, 15 Mar 2019 02:10:01 GMT ja hourly 1 [重要] 本 Japan Azure IaaS Support Blog が終了し、新たなプラットフォームに移行します [ブックマーク変更をお願いします] https://docs.microsoft.com/archive/blogs/jpaztech/japan_iaas_support_blog_decom Wed, 13 Mar 2019 11:00:53 GMT http://blogs.technet.microsoft.com/jpaztech/?p=17115 Japan Azure IaaS and Networking Support Team (MSDN Forum) https://social.msdn.microsoft.com/Forums/ja-JP/home?forum=Jpaztech

 

RSS フィードはこちらです。 https://social.msdn.microsoft.com/Forums/ja-JP/Jpaztech/threads?outputAs=rss

  ※ 今後、万が一、さらなる URL 変更があった際も、常に Azure IaaS サポート部の最新の記事が参照いただけますよう、短縮 URL "http://aka.ms/jpaztech" を作成しましたので、ブックマークはこちらがお勧めです。  

<本 Blog のバックナンバーをアーカイブしております。いったん記事のメンテナンスは打ち切りとなり、2019/3/12 の次点のものとなりますが、ご参考といただけましたら幸いです。>

Japan Azure IaaS Support Team Blog のバックナンバー #1 Japan Azure IaaS Support Team Blog のバックナンバー #2

  これまで、多くのお客様に本 Blog をご参照いただき、誠にありがとうございました。 引き続き、次のプラットフォームにて、サポート部門から情報提供をさせていただきますので、よろしくお願いいたします。   日本マイクロソフト Azure IaaS Support チーム]]> Azure Support における Premier Field Engineer (PFE) のご紹介 https://docs.microsoft.com/archive/blogs/jpaztech/introducing_pfe Thu, 07 Mar 2019 15:31:49 GMT http://blogs.technet.microsoft.com/jpaztech/?p=17085 Premier Field Engineer(PFE) の紹介をさせて頂きます。 ※ちなみに、この動画の様に緊急オンサイトによる問題解決を支援することもありますが、後述するプロアクティブサポート支援の実施に伴い、その割合はかなり減ってきています。

プロアクティブサポートとは？

運用やサポートの一般的な概念として、リアクティブとプロアクティブ というキーワードがあります。 恐らく、皆さんが "サポート" と言われるとまず思い浮かべるのは リアクティブサポートではないでしょうか。IT 分野以外でも、テレビが壊れた！スマホを落としてしまった！という時に、購入店のサポートを使って修理をしてもらう、という経験をされたことがあると思います。このように、何か問題が発生した、という状態を正しい状態に直す対応を リアクティブサポートと言います。 一方で、プロアクティブサポートは、先手を打っておく対応です。家電であれば、週に一度お手入れをしたり、フィルターを交換したり、定期的なメンテナンスを行うと思います。また最近では、スマートフォンの使い方を教えてくれるキャリアもありますね。そういった "導入の支援をする・未然に問題を防ぐ" サポートのことをプロアクティブサポートと言います。 ちなみに、一般的にどういうことをしてくれるとプロアクティブなのか、というのを少し調べてみましたが、これはその企業や組織で位置付けが異なるため、一般的にこれをしているからプロアクティブサポートだ、ということがあまり明確になっていないのが現状の様です。 数年前に Google さんが Customer Reliability Engineering(CRE) というロールを提唱し話題になりましたが、CRE もプロアクティブサポートの一種 (もしくは派生形) と考えられます。 その後日本の特に自社サービスを展開している Web 系の企業で CRE というロールを新たに設けられるケースを見かけますが、プリセールスやアプリケーション改善のためのツール開発、ドキュメントの作成も CRE の担当範囲と定義している組織もありました。

Azure(Microsoft) のプロアクティブサポート

では、Azure のプロアクティブサポートではどのようなサポートをしてくれるのでしょうか。 その前に、Azure のサポートにどのようなものがあるのか見てみたいと思います。

Azure のサポート プランの比較 | Microsoft Azure https://azure.microsoft.com/ja-jp/support/plans/

こちらは、Azure のサポートプランのページです。サポートの対応時間や重要度に応じでいくつかのプランがあります。 この中で、最上位のサポートである、Premier サポートというプランの中で プロアクティブサポートが提供されます。もちろん、リアクティブサポートも Premier サポートの一つのサービスとして提供されます。 Microsoft のプロアクティブサポートとリアクティブサポート の関係の図   Premier サポート の説明はこちらにあります。

Azure サポート—Premier | Microsoft Azure https://azure.microsoft.com/ja-jp/support/plans/premier/

上記のページにあるように、Premier サポートでは、以下のようなシナリオに対して、プロアクティブサポート を活用することができます。
  •  移行
  •  デプロイ
  •  開発
  •  最適化
  •  設計と実装
  •  パフォーマンスチューニング
では例えば、オンプレミスから Azure IaaS へのサーバー移行では具体的にどのようなプロアクティブサポートがあるのでしょうか？ 一口に移行と言っても様々な作業があるためケースバイケースですが、以下のようなことを行うことがあります。
  • トレーニング お客様が Azure の基本や、使いたい Azure サービスのことをよくご存知でなければ、トレーニングを開催します。
  • アセスメント どの様なサーバーがあって何台あるのかがわからない場合は現環境のアセスメントを受けて頂いて環境の把握を行います。
  • 移行作業支援 お客様が作成された手順のレビューやアーキテクチャレビューを行います。
  • 運用支援 導入後に出てくる課題の整理や問題解決を行います。
このように、設計から運用までプロアクティブサポートの範囲は多岐にわたり、それを対応する専門のエンジニアが Premier Field Engineer (PFE) です。  

PFE の支援方法

  先ほどの移行プロジェクトの様な支援は、多くの場合、一人のエンジニアを専任でアサインする Designated Support Engineering (DSE) という体制で行います。 このような DSE を含め、PFE はおもに次の様な方法で支援を行います。  
  • ワンショットでのご支援 例えば、Azure の仮想ネットワークの構成をレビューしてほしい、監視の仕組みについてディスカッションしたい、と言ったスポットでの対応を行います。ワークショップもこの位置づけで行います。
  • 年間やプロジェクトを通したご支援(DSE) お客様の運用環境の改善やサービスの活用をサポートの立場からご支援します。前の章で紹介したような移行プロジェクトの様なある程度の規模の場合はこちらを選択されることがあります。 規模によっては、複数のエンジニアで対応することがあります。
  • 緊急時における対応 お客様や製品担当サポートエンジニアからの要請により、オンサイトをした方が調査が加速すると判断された場合にスポットで対応することがあります。
PFE の支援方法の図     このように、お客様のプロジェクトの規模や、期限、緊急度に応じて柔軟に対応ができるのも PFE による支援のメリットです。

PFE に関する FAQ

 

 Q1. Azure のプラットフォーム以外のことも支援してくれるの？ A1. Azure 上の Microsoft 製品に関してはもちろん、オンプレミス環境への対応も可能です。

クラウド利用においては、クラウドプラットフォームのことだけではなく、そのクラウドの上でどの様な OS を動かすのか、どのようなアプリケーションを動かすのか、が重要になってきます。 Microsoft の場合は Windows OS を含めた、アプリケーションの実行環境やデータベースも提供しているため、Azure から各製品まで、ワンストップでの支援が可能です。 また、特にエンタープライズでは、オンプレミス環境とのハイブリッド構成を行うことがよくありますが、オンプレミスにある仮想基盤や認証基盤との連携等、複雑な構成になりがちです。そういった環境でも Premier サポートではクラウド・オンプレミス関係なく支援が可能です。 ※対象製品が複数に渡る場合、それぞれを担当する複数のエンジニアで対応することがあります。

Q2. Linux OS 等 Microsoft 製品以外の支援はしてくれるの？ A2. 可能な限りのことは行います。

Azure は Windows OS や Microsoft の製品だけが提供されているわけではなく、サードパーティー製品を含めると様々な製品を利用することができます。どこまでの範囲をどの程度というのはケースバイケースですが、Microsoft 製品を使っていないから一切関与しない、といったスタンスではありません。 ※基本的にサードパーティー製品のサポートは、サードパーティーベンダーへお問い合わせ頂ける体制を取っていただく必要はあります。  

 Q3. PFE が設計書を書いたりお客様の環境構築を代わりにやることはあるの？ A3. 基本的にありません。

PFE はあくまでもサポートの立場からご支援を行うエンジニアです。従って、お客様に代わって設計書を書いたり、環境構築をしたりすることはありません。ただし、設計書・手順のレビューやサンプルコードの提供、実環境のアセスメントの結果から実装のご支援をすることがあります。  

Q4. サポート対応を PFE 一人で全部できるの？ A4. TAM や製品担当サポートエンジニア、時には営業担当と連携して、チームで対応します。

  技術的な対応についてはもちろん PFE が担当しますが、お客様との調整や契約ごとについては、Technical Account Manager(TAM)が担当します。また、リアクティブな対応や実装レベルの動作確認については、製品担当サポートエンジニアと連携し、問題解決の交通整理や情報採取のヘルプを行います。PFE 一人で全ての対応をするわけではなく、協力して進めていきます。  

最後に

いかがでしたでしょうか？ "クラウドサポート" と聞くと、何かトラブルがあったときに解決をしてくれる "製品担当サポートエンジニア" が思い浮かんでくるかと思いますが、これまでご紹介した様な活動をするサポート エンジニアがいるということを少しでも知っていただけましたら幸いです。また機会がありましたら是非ご活用ください。 最後までお読み頂きありがとうございました。]]> [P2S VPN についての重要なお知らせ] 2019 年 3 月 13 日 にポイント対サイト VPN で接続できなくなった場合の対処方法 https://docs.microsoft.com/archive/blogs/jpaztech/update_p2s_certificate Thu, 07 Mar 2019 15:16:53 GMT http://blogs.technet.microsoft.com/jpaztech/?p=16905 正式なご案内は、以下の公開文書にございます。当ブログにおいても、通知漏れや見落としをできる限りケアできるように、以前のポストにおいて詳細をご案内させていただいておりました。

(公式情報) Transition from self-signed to public CA certificates for P2S gateways https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-point-to-site-gateway-public-ca

来る 2019 年 3 月 13 日、一部の対象となる VPN ゲートウェイにおいて、ポイント対サイト VPN が以下のエラーにて接続できなくなる事象が発生することが予想されます。  
「証明書のCN名が渡された値と一致しません。（エラー 0x800b010f）」
  （注意） 今回のメンテナンスで全てのお客様で影響が出る訳ではありません。 影響を受ける環境の確認方法や、実施されるメンテナンスの内容については以下のブログ エントリーもご参照下さい。 ポイント対サイト VPN に関する重要な通知について https://blogs.technet.microsoft.com/jpaztech/2019/02/14/important_information_p2s_cert/   本ブログでは、メンテナンス後、ポイント対サイト VPN が接続できなくなった際の対処方法について改めてご案内いたします。  

対処方法

 

リソース マネージャー デプロイ モデル環境

  1. Azure ポータルにサインインします。
  2. 該当の仮想ネットワーク ゲートウェイのリソースのページにアクセスし、[ポイント対サイトの構成]を開きます。
  3. 画面上部の [VPN クライアントのダウンロード] をクリックして VPN クライアント パッケージをダウンロードします。
  4. ダウンロードした VPN クライアントパッケージを展開し、OS の種類（64 ビット / 32 ビット）に合わせたバージョンをクライアント端末にインストールします。 VPN クライアント パッケージのインストールにはローカル管理者の権限が必要です。
 

クラシック デプロイ モデル環境

  1. Azure ポータルにサインインします。
  2. 該当のゲートウェイが作成されている仮想ネットワーク（クラシック）のページにアクセスします。
  3. [ポイント対サイト] の [クライアント] のアイコンをクリックします。
  4. 画面上部の [VPN クライアント (64 ビット)] をクリックして、VPN クライアント パッケージをダウンロードします。 32 ビット用の VPN クライアント パッケージが必要な場合は、[その他] をクリックして、[VPN クライアント (32 ビット)] をダウンロードして下さい。
  5. ダウンロードした VPN クライアント パッケージをクライアント端末にインストールします。 VPN クライアント パッケージのインストールにはローカル管理者の権限が必要です。
  （注意） 今回のメンテナンスは、VPN クライアント側で利用している認証用のクライアント証明書には影響を与えません。 このため、VPN クライアントにインストールした証明書や、仮想ネットワーク ゲートウェイにアップロードした証明書を変更する必要はありません。]]> ポイント対サイト VPN に関する重要な通知について https://docs.microsoft.com/archive/blogs/jpaztech/important_information_p2s_cert Thu, 14 Feb 2019 15:20:07 GMT http://blogs.technet.microsoft.com/jpaztech/?p=16715 VPN（P2S VPN）のサービスをご利用いただいているお客様に影響が出る可能性があるメンテナンスについて、弊社サイトにてアナウンスさせていただきました。   Transition from self-signed to public CA certificates for P2S gateways https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-point-to-site-gateway-public-ca   このメンテナンスの内容を正しく理解いただくため、今回のメンテナンスの技術的な背景や事前にご協力いただきたい作業について、本ブログにて補足させていただきます。  

背景

P2S VPN で利用される証明書について

P2S VPN は、SSL を利用した SSTP という VPN プロトコルを使って動作いたします。 このため、P2S VPN クライアントと仮想ネットワーク ゲートウェイ間で SSL を確立するための、サーバー証明書が仮想ネットワーク ゲートウェイ側に設定されます。   この証明書はお客様が作成するクライアントの認証で利用される証明書とは異なり、仮想ネットワーク ゲートウェイ作成時に自動的に構成されます。   このサーバー証明書は、自己署名された認証局によって署名されており、認証局も証明書も有効期間は 3 年で構成されていました。 また、自動的に生成されたサーバー証明書を P2S VPN クライアント側で正しく検証を行うため、VPN クライアントパッケージをインストールする際に自己署名した認証局の公開証明書をクライアントの証明書ストアに配置していました。   以前の仮想ネットワーク ゲートウェイの動作では、証明書の更新に伴いこの自己署名された認証局も更新されていました。 この結果、クライアントの証明書ストアに配置された認証局の公開証明書と仮想ネットワーク ゲートウェイが新たに利用する証明書が一致しなくなり、クライアント側で更新後の証明書を正しく検証することができなくなるため、P2S VPN の接続に失敗する事象が発生しておりました。 この事象が発生すると、VPN クライアント パッケージを再ダウンロードし、各クライアント端末にインストールするまでは P2S VPN 接続ができない動作になっておりました。    

サーバー証明書の有効期限について

上述のとおり、過去に作成された 仮想ネットワーク ゲートウェイでは、有効期間が 3 年の自己署名証明書が利用されておりました。 また、サーバー証明書に署名を行った認証局（自己署名した認証局）自身の有効期間も 3 年となっており、3 年ごとに証明書を更新する必要がございました。   有効期間切れによって証明書が失効することを防ぐため、仮想ネットワーク ゲートウェイの定期的なメンテナンスでは、ゲートウェイで利用されている証明書の有効期間が残り 6 ヶ月を下回ったことを検知すると証明書の更新を行うように動作していました。 つまり、仮想ネットワーク ゲートウェイを作成してから 2 年半を超えた時点でメンテナンスが実施されると証明書の更新が行われるようになっていました。   しかしながら、このような方法では、おおよそ 3 年ごとに証明書を更新する必要があり、その度に P2S VPN 接続が行えなくなるため、クライアントの再設定が必要になるという制約が生じておりました。   このため、2017 年 7 月頃以降に作成された仮想ネットワーク ゲートウェイでは、有効期間が長い公的証明機関によって署名されたサーバー証明書を利用するように仮想ネットワーク ゲートウェイの動作が変更されております。 動作変更後のゲートウェイにおいても、引き続き P2S VPN で利用されているサーバー証明書は 3 年ごとに更新されますが、その証明書に署名している認証局が有効期間の長い公的証明機関のものになっているため、2017 年 7 月頃以降に作成された仮想ネットワーク ゲートウェイでは証明書の更新によって P2S  VPN が接続できなくなる事象は発生いたしません。 （注：新規作成されたゲートウェイの証明書が公的証明機関によって署名されたものに変更された時期は、データセンターのリージョンなどによって前後するため、明確な日付をご案内することはできません）    

今回実施される更新について

現在、お客様にてご利用いただいている仮想ネットワーク ゲートウェイは以下の 3 つのタイプに分類されます。   A. 2017 年 7 月頃より前に作成され、その後の定期メンテナンスによって、公的証明機関の証明書に入れ替えが完了しているもの B. 2017 年 7 月頃より前に作成され、現在も自己署名証明書が利用されているもの C. 2017 年 7 月頃より後に作成されたもの（最初から公的証明機関の証明書が利用されているもの）   今回実施されるメンテナンスによって影響を受けるのは、B. のタイプの仮想ネットワーク ゲートウェイをご利用いただいているお客様になります。   現在、B. のタイプの仮想ネットワーク ゲートウェイをご利用いただいているお客様は 2019 年 3 月 13 日 3:00（日本時間）から開始されるメンテナンスによって、ゲートウェイが作成された時期にかかわらず、全て公的証明機関の証明書が利用されるように更新が行われます。 この更新によって、これまで利用いただいていた VPN クライアントでは P2S VPN が確立できなくなります。よって、メンテナンス後に、再度 Azure ポータルや PowerShell を介してP2S VPN クライアントパッケージをダウンロードし、全てのクライアント端末に再インストールしていただく必要がございます。   この変更は、2019 年 3 月 13 日から開始される仮想ネットワーク ゲートウェイのメンテナンスによって自動的に行われますが、3 月 13 日以降のどのタイミングでメンテナンスが行われるかを事前に把握したり、実施時期を指定することはできません。 もし、それ以前に期間を特定した形でメンテナンスを完了したいお客様に関しましては、サポート リクエストを通じてご要望いただくことで、以下のいずれかの日程で実施することも可能です（いずれも日本時間）。  
  1. 2019 年 2 月 25 日 15:00～
  2. 2019 年 2 月 26 日 3:00～
  3. 2019 年 3 月 1 日 15:00～
  4. 2019 年 3 月 2 日 3:00～
選択いただいた日時から順次メンテナンスをスタートし、数時間以内には完了することを予定しております。   尚、サポート リクエストを通じて上記日程でのメンテナンスを希望されるお客様は、お問い合わせ時に対象を仮想ネットワーク ゲートウェイを指定してお問い合わせをいただくか、対象の仮想ネットワーク ゲートウェイ名とそのサブスクリプション ID をお知らせ下さい。    

影響を受けるゲートウェイの確認方法について

現在、公的証明機関で署名された証明書を使って P2S VPN 接続を行っている環境では、既に証明書が更新されているため、今回のメンテナンスの影響を受けることはありません。 利用している環境が既に公的証明機関で署名された証明書を利用しているかは、VPN クライアントパッケージ内の構成ファイルを参照することで確認が可能です。  

（確認手順）

  1. Azure ポータルや PowerShell を使って、VPN クライアント パッケージをダウンロードします。
 
  1. ダウンロードしたファイルを展開します。
 
  1. 展開したファイルの “Generic” フォルダ内にある “VPNSettings.xml” をメモ帳などのアプリケーションで開きます。
 
  1. 以下の <ServerCertRootCn> と <ServerCertIssuerCn> タグの値を確認いただき、値が「DigiCert Global Root CA」になっている場合は、既に公的証明機関で署名された証明書を利用しているため、今回のメンテナンスの影響を受けません。<ServerCertRootCn>DigiCert Global Root CA</ServerCertRootCn> <ServerCertIssuerCn>DigiCert Global Root CA</ServerCertIssuerCn>
（注：クラシック デプロイモデルの仮想ネットワーク ゲートウェイを利用している場合の確認手順は、後述いたします FAQ の Q4 をご参照ください。）  

（参考情報）

ネイティブ Azure 証明書認証の P2S 構成のための VPN クライアント構成ファイルを作成およびインストールする https://docs.microsoft.com/ja-jp/azure/vpn-gateway/point-to-site-vpn-client-configuration-azure-cert    

メンテナンス後の対応について

メンテナンスが実行され、ゲートウェイが利用する証明書が公的証明機関のものに更新されると、これまで利用していた VPN クライアントでは接続できなります。 この場合、改めて Azure ポータルや PowerShell を使って、VPN クライアントパッケージをダウンロードし、各クライアント端末にインストールする必要があります。   今回のメンテナンスよって影響を受けるお客様にはご迷惑をおかけして申し訳ございませんが、ご理解のほどよろしくお願い申し上げます。  

FAQ

Q1. メンテナンスの期間が長すぎるため、その中でもメンテナンスが起こる時間をさらに特定することはできないか。 A1. 恐れ入りますが、メンテナンス期間中のどのタイミングで実際にメンテナンスが発生するかは、指定することはできません。厳密にタイミングをコントロールする必要がある場合は、ゲートウェイをいったん削除し、再作成していただければ、そのゲートウェイでは公的証明機関によって署名された証明書が利用された状態になります。ただし、ゲートウェイの再作成に伴って、ゲートウェイのパブリック IPアドレスが変更になるため、同じゲートウェイでサイト間 VPN をご利用いただいていた場合は、IP アドレスの変更に伴う設定変更が必要になります。     Q2. ポイント体サイト VPN を利用しているかどうかを確認するためには、どうすればよいか。 A2. 一例ではありますが、以下の手順で確認することができます。   - リソース マネージャー モデルをご利用の場合
  1. Azure ポータル (https://portal.azure.com/) を開きます。
  2. [仮想ネットワーク ゲートウェイ] を開きます。
  3. ゲートウェイを開き、[ポイント体サイトの構成] を開きます。
  4. 「ポイント対サイトが構成されていません」と表示される場合は、そのゲートウェイでポイント対サイト VPNは利用されていません。
  - クラシック モデルをご利用の場合
  1. Azure ポータル (https://portal.azure.com/) を開きます。
  2. [仮想ネットワーク (クラシック)] を開きます。
  3. [ポイント対サイト] の [クライアント] のアイコンをクリックします。
  4. [証明書の管理] をクリックします。
  1. 「証明書がありません」と表示される場合は、そのゲートウェイでポイント対サイト VPNは利用されていません。
    Q3. 仮想ネットワーク ゲートウェイに構成した ”ルート証明書” や “失効した証明書” は影響を受けますか。 A3. 今回の変更で “ルート証明書” や “失効した証明書” が影響を受けることはありません。   Q4. メンテナンスの対象かどうかを確認するために、クラシック デプロイ モデルの環境で VPN クライアント パッケージをダウンロードし展開してみましたが、"Generic" フォルダが見つかりません。 A4. ご案内が不十分で申し訳ございません。 クラシック デプロイ モデルでは以下の手順で確認が可能です。
  1. Azure ポータルの仮想ネットワーク（クラシック）から該当の仮想ネットワークを選択します。
  2. [ポイント対サイト] の [クライアント] のアイコンをクリックします。
  3. [VPN クライアント (64 ビット)] をクリックし、VPN クライアント パッケージをダウンロードします。
  4. ダウンロードした VPN クライアントパッケージの拡張子を .exe から .zip に変更して展開します。
  5. 展開したファイルに含まれる拡張子 .cer のファイルを Windows OS で開き、証明書のプロパティを表示します。
  6. 証明書のプロパティの全般タブにて、"発行者" の値が「DigiCert Global Root CA」になっている場合は、既に公的証明機関で署名された証明書を利用しているため、今回のメンテナンスの影響を受けません。
]]> Application Gateway の構成について https://docs.microsoft.com/archive/blogs/jpaztech/about-application-gateway Thu, 07 Feb 2019 15:07:52 GMT http://blogs.technet.microsoft.com/jpaztech/?p=16595 2019/2/27 追記 Application Gateway で EV 証明書がサポートされるようになりましたので、FAQ の内容を更新しております。
こんにちは、Azure サポートチームの檜山です。 今回は Application Gateway の構成についてご紹介させていただきます。 また、下部に Application Gateway の FAQ もまとめてますので、ご参照ください。 Application Gateway はレイヤー 7 のロードバランサーで Web トラフィックを負荷分散することができますが、構成によっては設定が多岐にわたる場合があり、設定項目と実際の動作がイメージしにくいことがございます。 そのような時にはこちらのブログをご一読いただけますと幸いです。
Application Gateway の設定項目の概要と代表的な構成を以下に記載します。
  1. 設定項目の概要
  2. Basic 構成
  3. マルチサイト
  4. パスベースでの振り分け
  5. マルチサイト&パスベース
  6. リダイレクト
 
  • FAQ

    • 設定項目の概要

    Application Gateway には主に以下の 7 つの設定項目があります。  
      1. 構成
        2. Application Gateway の SKU サイズ、インスタンス数を指定可能です。 運用環境においては SKU サイズ M 以上、インスタンス数 2 以上が推奨となります。 インスタンス数が 1 の場合、メンテナンスや障害等で予期せず停止する場合がございますので、ご注意ください。
      2. Web アプリケーション ファイアウォール
        3. WAF の設定を行います。ファイアウォールのモードやルールの設定が可能です。 WAF については以下もご参照ください。
        • Application Gateway (WAF) での脆弱性検知について
        https://blogs.technet.microsoft.com/jpaztech/2018/10/30/application-gateway-waf-vulnerability/
      3. バックエンドプール
        4. リクエストを振り分ける先となるバックエンドの Web サーバーを設定します。 仮想マシン、IP アドレス、FQDN 等を指定することができます。 IP アドレス、FQDN については Azure 外部の Web サイトを設定することもできます。
      4. HTTP 設定
        5. バックエンドプールに接続する際のパラメーターを設定します。 バックエンドに接続するポートやプロトコル (http/https) 、カスタム プローブの指定などを行います。
      5. フロントエンド IP 構成
        6. Application Gateway がクライアントからリクエストを受け付けるためのパブリック IP アドレスまたはプライベート IP アドレスを設定します。 フロントエンド IP アドレスはパブリック IP, プライベート IP 共に最大 1 つずつです。
      6. リスナー
        7. Application Gateway がクライアントからリクエストを受け付けるためのフロントエンド IP の指定とフロントエンドのポート、プロトコル (http/https) を設定します。 https の場合、証明書の設定も行います。 マルチサイト リスナーを構成することでリクエストのホストヘッダに応じて負荷分散を行うことが可能です。
      7. ルール
        8. 上記の "リスナー"、"バックエンドプール"、"HTTP 設定" の紐づけを行います。 パスベースのルールを構成することで、URL のパスに応じてバックエンド プールと HTTP 設定を変えることも可能です。 また、URL のリダイレクトを構成することもできます。
      8. 正常性プローブ
        9. 既定のプローブ以外のカスタム プローブを使用する場合に設定を行います。 カスタム プローブを構成することで、正常性プローブのホストヘッダやパスを指定することができます。

      Basic 構成

      Azure Portal から作成した際の初期設定は Basic 構成となります。 このままでも利用可能ですが、次の項目に記載するマルチサイトやパスベース、リダイレクトの要件があった場合、ルールを追加または変更する必要があります。 以下の例は 2 つのルールが構成されています。 ルール 1 : https (443) で受け付けたリクエストを http (80) に SSL オフロードするルール ルール 2 : http (80) で受け付けたリクエストをそのまま転送するルール

      マルチサイト

      マルチサイト リスナーを構成することで、クライアントがアクセスする URL のホスト名 (HTTP のホストヘッダ) に応じて振り分け先を変えることができます。 以下の例の動作をご説明します。 クライアントが "https://www.contoso.com" にアクセスした場合、http (80) で Site1 にアクセスします。 クライアントが "https://www.fabrikam.com" にアクセスした場合、 https (443) で Site2 にアクセスします。 なお、ルールが複数構成されている場合、ルールは上から順 (先に作成されたもの順) に照合されます。 マルチサイト リスナーが含まれるルールと Basic リスナーが含まれるルールを両方構成する場合、マルチサイト リスナーが含まれるルールを先に作成することを推奨します。 Basic リスナーを含むルールを先に作成すると、マルチサイト リスナーが想定したとおりに動作しない可能性があります。  

      パスベースでの振り分け

      パスベースのルールを作成することで URL のパスに応じて HTTP 設定やバックエンドを変更することができます。 以下の例の動作をご説明します。 クライアントが "https://xxxxx/" にアクセスした場合、http (80) で Site1 にアクセスします。 クライアントが "https://xxxxx/video/" にアクセスした場合、http (8080) で Site1 にアクセスします。 クライアントが "https://xxxxx/images/" にアクセスした場合、https (443) で Site2 にアクセスします。  

      マルチサイト&パスベース

      以下の様にマルチサイト リスナーとパスベースのルールを組み合わせて、URL のホスト名とパスに応じて HTTP 設定、バックエンドを変更することもできます。 以下の例の動作をご説明します。 クライアントが "https://www.contoso.com/" にアクセスした場合、http (80) で Site1 にアクセスします。 クライアントが "https://www.contoso.com/video/" にアクセスした場合、http (8080) で Site2 にアクセスします。 クライアントが "https://www.fabrikam.com/" にアクセスした場合、https (443) で Site3 にアクセスします。  

      リダイレクト

      Application Gateway は受け取ったリクエストを他のリスナーや外部サイトにリダイレクトすることができます。 例えば http で受け付けたリクエストを https にリダイレクトすることも可能です。 以下の例の動作をご説明します。 【リダイレクトがリスナー 1 向けに構成されている場合】 クライアントが http (80) でアクセスしたリクエストを https (443) へリダイレクトします。 【リダイレクトが外部サイト向けに構成されている場合】 クライアントが http (80) でアクセスしたリクエストを "https://www.fabrikam.com" へリダイレクトします。  

      FAQ

      以下の FAQ は V2 SKU ではない SKU (Standard, WAF) のApplication Gateway を対象に記載しておりますのでご留意ください。
      • Application Gateway のフロントエンド IP アドレス (パブリック) を固定 IP にできますか。
        • フロントエンドのパブリック IP アドレスは動的な IP アドレスのみがサポートされております。 パブリック IP アドレスが変更されるタイミングは、Application Gateway を停止、再起動した場合、および Application Gateway 自体を削除し、再作成したタイミングとなります。 Azure 側のメンテナンス等で変更されることは想定されておりません。 パブリック IP アドレスの変更に対応する方法としては、フロントエンド IP アドレスに割り当たる DNS 名 (xxxx.cloudapp.azure.com) の CNAME エイリアスを構成することを推奨しております。 パブリック IP に割り当てられる DNS 名は、Application Gateway を停止、起動しても変更されることはございません。
      • Application Gateway へ接続する接続元を制限することができますか。
        • Application Gateway を配置する仮想ネットワークのサブネットにネットワーク セキュリティ グループ (NSG) を適用し、接続元を制限することができます。 NSG は FQDN での制限や地理的リージョンでの IP アドレス制限には対応しておりませんので、ご留意ください。 NSG のルールは以下を参照ください。 ネットワーク セキュリティ グループはアプリケーション ゲートウェイ サブネットでサポートされますか? https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-faq#are-network-security-groups-supported-on-the-application-gateway-subnet
      • Application Gateway へ接続すると 502 エラーが表示されます。
        • 以下にも関連情報がございますので、ご確認ください。 Application Gateway における 502 Error について https://blogs.technet.microsoft.com/jpaztech/2018/03/16/application-gateway-502-error-info/
      • ラウンドロビンでの負荷分散は可能でしょうか。
        • Application Gateway は既定でラウンドロビンで負荷分散が行われます。 ユーザーセッションを維持したい場合は HTTP 設定にて Cookie ベースのセッション アフィニティを有効化する必要があります。
      • Sorry ページを構成することは可能でしょうか。
        • 以下のエラーページについてはカスタムのエラーページを構成することができます。 - HTTP 502（Bad Gateway) - HTTP 403（Forbidden） Application Gateway のカスタム エラー ページを作成する https://docs.microsoft.com/ja-jp/azure/application-gateway/custom-error ただし、カスタムエラーページは BLOB に配置された静的なサイトのみがサポートされています。
      • EV 証明書を利用できますか。
        • Application Gateway で EV 証明書はサポートされております。 What certificates are supported on Application Gateway? https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-faq#what-certificates-are-supported-on-application-gateway
        以上、参考になれば幸いです。 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。
    ]]>         Azure ロードバランサー利用時の注意点 https://docs.microsoft.com/archive/blogs/jpaztech/azurelb-tips Tue, 29 Jan 2019 16:16:51 GMT http://blogs.technet.microsoft.com/jpaztech/?p=16415 Azure ロードバランサー利用時に想定した動作ができないといった時に制限事項にあてはまっている場合がございますので、そのような時はご一読いただけますと幸いです。 また、Azure ロードバランサーを経由した通信のトラブルシューティングについては以下もご参照ください。
    • ロードバランサー経由での通信ができない場合のチェックポイント
    https://blogs.technet.microsoft.com/jpaztech/2016/11/23/loadbalancer-troubleshooting/

    Azure ロードバランサー (内部 [プライベートIP] / 外部 [パブリック IP]) 利用時のよくあるお問合せ

    Azure ロードバランサー利用時のよくあるお問合せとして以下のようなものがあります。
    1. ロードバランサーのバックエンドプールに VM を追加できない
    2. ロードバランサーのバックエンドプールに追加したら外部へ接続できなくなった
    3. バックエンドプールに所属した VM からロードバランサーのフロントエンド IP アドレスにアクセスできない
    4. Standard SKU の外部ロードバランサーで正常性プローブは成功するが、負荷分散ができない
    5. ロードバランサーのフロントエンド IP アドレスの送信元 NAT (SNAT) による外部接続ができない
    それぞれについて以下に詳細を記載します。

    ロードバランサーのバックエンドプールに VM を追加できない

    こちらの事象についてよくある原因としては以下があります。
    1. 1 台の VM を複数のロードバランサーに追加しようとしている
    2. ロードバランサーと VM に付与されているパブリック IP アドレスの SKU が異なる
    1 についてですが、Azure ロードバランサーは 1 台の VM を複数の外部ロードバランサーまたは複数の内部ロードバランサーに追加することができません。 Azure ロードバランサーに複数のフロントエンド IP アドレスを設定することで回避できる場合がありますので、ご検討ください。 また、1 台 の VM を 1 つの外部ロードバランサーと 1 つの内部ロードバランサーに所属し、負荷分散することはできます。(LB の SKU は合わせる必要があります)   2 についてですが、VM のパブリック IP アドレスが Basic SKU であった場合、Standard SKU のロードバランサーのバックエンドには追加することができません (SKU が反対の場合も同様)。 そのため、そのような構成であった場合、どちらかの SKU を変更し、SKU を合わせる必要があります。

    ロードバランサーのバックエンドプールに追加したら外部へ接続できなくなった

    こちらの事象についてよくある原因としては以下があります。
    1. Standard SKU の内部ロードバランサーのバックエンドプールに所属している
    Standard SKU の内部ロードバランサーの場合、以下のどちらかの設定を行いパブリック IP アドレス経由で外部と通信できるようにする必要があります。
    1. VM にパブリック IP アドレスを付与する
    2. VM を外部ロードバランサーにも追加する
     

    バックエンドプールに所属した VM からロードバランサーのフロントエンド IP アドレスにアクセスできない

    こちらの事象についてよくある原因としては以下があります。
    1. 内部ロードバランサーのバックエンドに所属している VM から、その VM が所属しているロードバランサーのフロントエンド IP アドレスにアクセスしている
    内部ロードバランサーの動作として、自分自身がバックエンドプールとして所属するロードバランサーのフロントエンド IP アドレスに接続した際は、送信パケットと受信パケットで不一致が発生し、自ノードへはアクセスできない動作となります。 このような要件があった場合、Proxy を経由させる等で回避できる場合がございますのでご検討ください。    

    Standard SKU の外部ロードバランサーで正常性プローブは成功するが、負荷分散ができない

    こちらの事象についてよくある原因としては以下があります。
    1. NIC またはサブネットに NSG を適用していない
    Standard SKU の外部ロードバランサーでは NSG の受信規則によって、負荷分散用のポートを許可しない限り、トラフィックがホワイトリストとして登録されず負荷分散の通信が許可されません。 ただし、正常性プローブについては NSG が適用されていなくても成功する動作となります。 メトリック等で確認した際に正常性プローブは成功しているが、負荷分散がきないといった事象の場合、NSG の受信規則によって、負荷分散用のポートを許可して事象が改善するかをご確認ください。

    ロードバランサーのフロントエンド IP アドレスの送信元 NAT (SNAT) による外部接続ができない

    こちらの事象についてよくある原因としては以下があります。
    1. VM が所属するバックエンドプールが負荷分散規則に紐づけられていない
    2. VM にパブリック IP アドレスが付与されている
    3. 外部ロードバランサーではなく内部ロードバランサーを利用している
    1 についてですが、外部への送信接続時の SNAT はバックエンドプールを負荷分散規則に紐づけていないと利用することができません。 Standard SKU の場合は、アウトバウンド規則を利用することもできます。
    • Load Balancer のアウトバウンド規則
    https://docs.microsoft.com/ja-jp/azure/load-balancer/load-balancer-outbound-rules-overview 2 についてですが、VM にパブリック IP アドレスが付与されている場合はそのパブリック IP アドレスにて SNAT されるため、ロードバランサーのフロントエンド IP アドレスでは SNAT されません。 3 についてですが、内部ロードバランサーの場合は送信接続時にフロントエンド IP アドレスで SNAT されない動作となります。   以上、参考になれば幸いです。 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。]]>         詳説 Azure ExpressRoute – Part5: ExpressRoute の増速やプロバイダー変更について https://docs.microsoft.com/archive/blogs/jpaztech/expressroute-deep-dive-part5 Tue, 25 Dec 2018 13:32:05 GMT http://blogs.technet.microsoft.com/jpaztech/?p=16325
  • Part1: ExpressRoute を導入する前に
  • Part2: ExpressRoute のルーティング制御について
  • Part3: ExpressRoute の導入手順について
  • Part4: ExpressRoute の冗長構成について
  • Part5: ExpressRoute の増速やプロバイダー変更について

    • ExpressRoute 回線を増速される場合

    例えば、ExpressRoute 回線を 50 Mbps でご契約いただいている状況から、Azure の本格利用に伴って帯域使用率が逼迫してきたため、200 Mbps 等へ増速されたいといった状況があるかと思います。何らかの理由で ExpressRoute 回線の増速を検討される場合、Azure とプロバイダー様の双方で変更が必要となりますので、それぞれ以下のような点にご留意をいただければと思います。

    Azure 側での変更作業

    Azure としてはドキュメントに記載のある通りダウンタイム無しで設定変更をいただけますので、特に考慮事項はなく Azure Portal 等で速度を変更いただくのみで作業は完了となります。 ※ 警告メッセージや、上記ドキュメントの [重要] にも記載のある通り、増速は可能ですが減速は出来ません。(また、従量制課金を無制限に変更した場合に、戻すことは出来ません) 誤って設定をされた場合は、ExpressRoute 回線を新規に構築しなおす必要が生じますので、十分ご注意ください。

    プロバイダー様での変更作業

    一方で、プロバイダー様でもルーターの構成変更などが必要になることが見込まれます。(Azure とプロバイダー様間の ExpressRoute の部分に加え、プロバイダー様とオンプレミス間のアクセス回線も増速が必要になる場合もあるかと存じます) プロバイダー様によっては、サービス仕様や料金計算の都合でそのまま増速いただくことが出来ず、新規に ExpressRoute 回線を作り直す必要がある場合もございますので、ご契約いただいているプロバイダー様へも事前にご確認をいただけますようお願いいたします。 なお、前述のドキュメントにも「既存のポートの容量が不十分な場合、ExpressRoute 回線の再作成が必要になる可能性があります。 その場所に使用可能な追加の容量がない場合、回路をアップグレードすることはできません。」と記載がある通り、Azure とプロバイダー様をつなぐ回線に帯域幅の余裕がない場合は増速いただけません。Azure とプロバイダー様のエッジルーター間は物理的には 10 Gbps などの回線で接続されておりますが、その中に複数のお客様の ExpressRoute 回線が収容されておりますので、例えば既存のお客様で合計 9 Gbps 以上を使用している状況下で、50 Mbps の回線を 1 Gbps などに増速されようとしても、帯域の余裕がなく増速ができないといったことも極まれに発生する可能性があります。こうした点についても、念のため事前にプロバイダー様までご確認いただけましたら幸いでございます。

    ExpressRoute 回線のプロバイダー様を変更される場合

    次に、ExpressRoute 回線のプロバイダー様を切り替える場合についてご紹介します。 ExpressRoute 回線は、以下の図のようにリソース作成時にプロバイダー様や接続場所を指定いただく必要があるため、プロバイダー様が変更になる場合は新規に再作成いただく必要がございます。したがって旧回線とは別に、新しく ExpressRoute 回線リソースを作成いただき、新しく採番されたサービス キーを使って、移行後のプロバイダー様に 2 回線目をご契約いただくことになります。 プロバイダー様の切り替えに伴うネットワークのダウンタイムを最小化したい場合は、まずは旧回線を残したままの状態で、新回線のプロバイダー様と開通作業を完了ください。(以下の図のように、VNET との接続を行う手前の段階までは既存の環境に影響を及ぼさずにご実施いただけるかと思います。) なお、新旧のプロバイダー様で PE ルーターから Azure 側に広報する経路情報に差異がございますと、切り替えの前後でトラブルになる場合がございます。Part2: ExpressRoute のルーティング制御についてもご参考にいただき、新旧のプロバイダー様で PE ルーターから BGP で広報する経路に差異が生じないか事前に新旧の両プロバイダー様へご確認いただくことを推奨いたします。   上記のように、新旧 2 つの ExpressRoute 回線が用意できましたら、夜間や週末などの業務影響のない時間帯で、旧 ExpressRoute 回線と VNET Gateway 間の接続リソースを削除して切断し (赤線部分)、改めて新 ExpressRoute 回線との接続を行っていただければと思います。(切り替え後に何らか問題が発生した場合は、旧回線への切り戻しもご検討ください)   なお、上記はあくまでも ExpressRoute 回線のプロバイダー様を変更される場合を想定しております。ExpressRoute のプロバイダー様からオンプレミスの拠点間の接続部分 (アクセス回線のキャリア様)  を変更される場合は、Azure としては特に差異は生じませんので、切り替え手順や影響の有無は ExpressRoute ならびにアクセス回線のプロバイダー様へご確認・ご相談いただければと思います。   以上、ご参考になりましたら幸いです。 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。]]>         Load Balancer と Application Gateway の通信の違い https://docs.microsoft.com/archive/blogs/jpaztech/lb_appgw_traffic_different Mon, 26 Nov 2018 19:29:19 GMT http://blogs.technet.microsoft.com/jpaztech/?p=16165 こんにちは、Azure サポートチームの山崎です。
    今回は Load Balancer と Application Gateway の通信の違いについてご紹介します。

    Load Balancer の場合

    Load Balancer を経由する通信は宛先 NAT され、バックエンドのサーバへ転送されます。 [行きの通信] １．クライアントから Load Balancer への通信

    送信元：クライアントの IP 宛先　：Load Balancer のフロントエンド IP

    ２．Load Balancer からサーバへの通信

    送信元：クライアントの IP 宛先　：サーバの IP （宛先 NAT）

      [戻りの通信] ３．サーバから Load Balancer への通信

    送信元：サーバの IP 宛先　：クライアントの IP

    ４．Load Balancer からクライアントへの通信

    送信元：Load Balancer のフロントエンド  IP 宛先　：クライアントの IP

    Application Gateway の場合

    Application Gateway はリバースプロキシとして動作するため、クライアントとApplication Gateway 間、Application Gateway とサーバ間で異なるセッションが作成されます。 [行きの通信] １．クライアントから Application Gateway への通信

    送信元：クライアントの IP 宛先　：Application Gateway のフロントエンド IP

    ２．Application Gateway からサーバへの通信

    送信元：Application Gateway の内部 IP （通信するインスタンスの IP） 宛先　：サーバの IP

    [戻りの通信] ３．サーバから Application Gateway への通信

    送信元：サーバの IP 宛先　：Application Gateway の内部 IP

    ４．Application Gateway からクライアントへの通信

    送信元：Application Gateway のフロントエンド  IP 宛先　：クライアントの IP

     

    よくあるお問い合わせ

    • Application Gateway 経由時にクライアント証明書認証できない
    サーバ側でクライアント証明書の認証を行っており、Application Gateway 経由に変更したタイミングで認証が出来なくなるとのお問い合わせをいただきます。Application Gateway の場合、クライアントとApplication Gateway 間、Application Gateway とサーバ間の通信は異なりますので、クライアントからの証明書がサーバ側に届かないため、クライアント証明書認証はできません。Load Balancer の場合は Load Balancer 自体が通信を終端するわけではなく通信を転送するため、クライアント証明書がサーバまで届きますのでクライアント証明書認証が可能です。  
    • Traffic Manager との違い
    Traffic Manager については DNS で負荷分散を行います。 [DNS 通信] １．クライアントが Traffic Manager の名前解決を行う

    test.trafficmanager.net

    ２．Traffic Manager が負荷分散先の情報を返信

     test01.japaneast.cloudapp.azure.com: 1.1.1.1 (A レコード)

    [エンドポイントとの通信] ３．名前解決後はエンドポイントと直接通信を行います。（Traffic Manager を経由しない）

    送信元：クライアントの IP 宛先　：サーバの IP

     
    クライアント側で DNS キャッシュが残っている場合は Traffic Manager を経由せず、そのまま継続してエンドポイントと通信を行います。DNS キャッシュがなくなったタイミングで再度名前解決を行い、Traffic Manager がどのエンドポイントと通信するか決定します。
     

    正常性プローブの違い

    プローブの送信元についても、Load Balancer と Application Gateway で違いがあります。 Load Balancer の場合、プローブの送信元は "168.63.129.16" という IP アドレスになります。 Application Gateway の場合、プローブの送信元はそれぞれのインスタンスの内部 IP アドレスになります。そのため、インスタンスが 2 つの場合、以下のようにそれぞれからプローブが行われています。 Traffic Manager の場合、プローブの送信元は probe-ip-ranges にある IP アドレスのいずれかが利用されます。   以上、ご参考になれば幸いです。]]>         詳説 Azure ExpressRoute – Part4: ExpressRoute の冗長構成について https://docs.microsoft.com/archive/blogs/jpaztech/expressroute-deep-dive-part4 Tue, 20 Nov 2018 13:15:42 GMT http://blogs.technet.microsoft.com/jpaztech/?p=16075
  • Part1: ExpressRoute を導入する前に
  • Part2: ExpressRoute のルーティング制御について
  • Part3: ExpressRoute の導入手順について
  • Part4: ExpressRoute の冗長構成について
  • Part5: ExpressRoute の増速やプロバイダー変更について

    • 単一の ExpressRoute 回線を契約した場合

    まず初めに、シンプルに 1 回線だけ契約された場合からご説明します。 ExpressRoute を東京でご契約いただいた場合、既定 (Premium Add-on なし) の状態で、以下の図のように東日本・西日本リージョンの仮想ネットワークに接続が可能です。

    ExpressRoute 回線を複数契約された場合

    次に、ExpressRoute 回線を東京で 2 回線ご契約される場合を考えてみます。 (システム毎に回線を分離したい場合や、キャリア冗長としたい場合など) 以下のドキュメントに記載がある通り、1 つの仮想ネットワークには最大で 4 つまで ExpressRoute 回線を接続出来ますが、いずれも別の場所 (東京・大阪など) でご契約いただいた ExpressRoute が必要になります。つまり、2 回線ともに東京でご契約いただいた場合、1 つの仮想ネットワークに東京の 2 つの ExpressRoute 回線を接続していただくことができません。 
    はい。 1 つの仮想ネットワークを最大 4 つの ExpressRoute 回線に接続できます。
これらは、4 つの異なる ExpressRoute の場所で注文する必要があります。

    大規模災害時などの疎通性の考え方

    最後に、災害時の DR を考慮する際の留意点についてご説明します。 まず大前提として、Azure のリージョン (東日本・西日本リージョン) と、ExpressRoute の接続場所 (東京・大阪) は、必ずしも同一のデータセンター内とは限りません。(海外ですと、Azure リージョンが存在しない地域でも ExpressRoute の接続場所が用意されている場合がございます。) これを踏まえ、大規模災害時などに東京の ExpressRoute 回線経由で西日本リージョンの仮想ネットワークへ接続出来るのかという点ですが、どこが被災したかによって状況が異なりますので、以下にそれぞれご紹介できればと思います。

    Azure のデータセンターが被災した場合

    データセンター側が被災したものの、ExpressRoute の接続場所 (MSEE) は無事という場合は、以下の図のように ExpressRoute 経由で西日本リージョンへ接続が可能と想定されます。

    ExpressRoute の接続場所 (MSEE) が被災した場合

    一方で、ExpressRoute の接続場所が被災した場合は、以下の図のように MSEE 経由で西日本リージョンへ通信を行うことができなくなることが想定されます。

    ExpressRoute 回線自体も DR 対策を検討される場合

    上記のような大規模災害時を想定し、ExpressRoute 回線の冗長化を検討される場合は、東京・大阪で 1 回線ずつご契約いただき、東日本・西日本リージョンの仮想ネットワークに対してメッシュでの接続をご検討ください。 この時、Azure とオンプレミス間は 2 つの経路で接続できる状態になりますが、既定の状態では等コストですので、アクティブ / アクティブな状態となり、両経路とも利用されることになります。 意図的に一方の経路を優先させたい (通常時は東京側を利用したい) という場合には、Azure からオンプレミスと、オンプレミスから Azure の双方向で、以下のように経路制御をいただければと思います。

    ・Azure -> オンプレミス方向の経路制御

    Azure としては、プロバイダー様の PE ルーターから広報される BGP の経路情報に基づいてルーティングを行っています。 意図的に東京側を優先してオンプレミスへルーティングしたいという場合は、AS Path プリペンドでの経路制御をご検討ください。 具体的には、大阪の PE ルーターから広報する経路情報に AS Path を追加して、遠回りの経路と見せかけることで制御できますので、プロバイダー様 (L2 プロバイダー様の場合は、PE ルーターの管理者様) までご相談をいただければと思います。

    ・オンプレミス -> Azure 方向の経路制御

    オンプレミス側で、東京・大阪のどちらの ExpressRoute 回線へルーティングするかは、お客様のネットワーク構成に依存します。 Azure 側からは制御できませんので、お手数ですがオンプレミス側のネットワーク管理者様や、プロバイダー様までご相談ください。   以上、ご参考になりましたら幸いです。 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。]]>         Linux ディストリビューションにおける、Azure 上の動作保証と Azure Site Recovery に関する注意事項 https://docs.microsoft.com/archive/blogs/jpaztech/asr Fri, 09 Nov 2018 22:27:09 GMT http://blogs.technet.microsoft.com/jpaztech/?p=16005 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

    公開情報

    ブログ公開に至った事の発端は、下記の公開情報に記載されている各ディストリビューションの OS バージョンがそれぞれ異なるため、どのように解釈すればよいのかお問合せをいただいたためでした。   Azure で動作保証済みの Linux ディストリビューション https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/endorsed-distros VMware および物理サーバーの Azure へのレプリケーションのサポート マトリックス https://docs.microsoft.com/ja-jp/azure/site-recovery/vmware-physical-azure-support-matrix   以下に抜粋して比較してみましょう。  

    エディションの比較

    たとえば、Red Hat Enterprise Linux (RHEL) においては、Azure で動作保証済みの OS バージョンは 6.7 以降、7.1 以降と記載されています。 一方、ASR のレプリケートでサポートされている OS バージョンは 5.2 ~ 5.11、6.1 ~ 6.10、7.0 ~ 7.5 と記載されています。   うーん。これはたしかに迷ってしまいますね。   RHEL 5.2 ~ 5.11、6.1 ~ 6.10、7.0 ~ 7.5 は、現時点での ASR での保護可能なバージョンとなります。 ただし、上記バージョンは、ASR による保護は行えますが、Azure 上での挙動に関しては、動作保証バージョンとして記載されている 6.7 以降、7.1 以降 のみとなります。 これは、ASR のサポート対象は、あくまで保護のみが可能なだけであって、その後の動作においてなんらかの問題が発生した場合は、弊社よりサポートのご提供ができない場合があるため、お客様側で動作をご確認いただく必要がございます。 上記比較表に記載されている、その他のディストリビューションも同様となります。 なお、この動作保証外の Linux ディストリビューションをどうしても Azure に移行しなければならない要件がございましたら、まずは下記の参考情報をご確認のうえ、十分な動作検証と慎重なご検討をいただけますようお願いいたします。  

    参考情報

    動作保証外のディストリビューションに関する情報 https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/create-upload-generic   上述しましたように、本記事はお客様のお問合せを契機に掲載に至りました。 貴重なご指摘をくださいましたお客様には深くお礼を申し上げます。   なお、コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。]]>