高可用性のために複数のAzure Stack Hub リージョンで N 層アプリケーションを実行する

この参照アーキテクチャは、可用性と堅牢なディザスター リカバリー インフラストラクチャを実現するために、複数のAzure Stack Hub リージョンで N 層アプリケーションを実行するための一連の実証済みプラクティスを示しています。 このアーキテクチャでは、Azure Traffic Managerを使用して高可用性を実現します。 ただし、お使いの環境で Traffic Manager が推奨されない場合は、高可用性ロード バランサーのペアを置き換えることができます。

Note

Azureでは、次のアーキテクチャで使用される Traffic Manager を構成する必要があります。 Traffic Manager プロファイルの構成に使用するエンドポイントは、パブリックにルーティング可能な IP である必要があります。

Architecture

このアーキテクチャは、SQL Serverを使用した N 層アプリケーションに示されているアーキテクチャに基づいています。

Azure N 層アプリケーションの高可用性ネットワーク アーキテクチャを示す図。

  • プライマリ リージョンとセカンダリ リージョン。 高可用性を実現するには、2 つのリージョンを使用します。 1 つのリージョンがプライマリ リージョンです。 フェールオーバーにはもう一方のリージョンを使用します。

  • Azure Traffic Manager。 Traffic Manager は 、受信要求をいずれかのリージョンにルーティングします。 通常の操作中に、プライマリ リージョンに要求をルーティングします。 そのリージョンが使用できなくなった場合、Traffic Manager はセカンダリ リージョンにフェールオーバーします。 詳細については、「 Traffic Manager の構成」セクションを参照してください。

  • リソース グループ。 プライマリ リージョンとセカンダリ リージョンに個別の リソース グループ を作成します。 この方法により、リソースの 1 つのコレクションとして各リージョンを柔軟に管理できます。 たとえば、もう一方のリージョンをダウンさせずに、1 つのリージョンを再デプロイできます。 アプリケーションのすべてのリソースを一覧表示するクエリを実行できるように、リソース グループをリンクします。

  • 仮想ネットワーク。 リージョンごとに個別の仮想ネットワークを作成します。 アドレス空間が重複していないことを確認します。

  • SQL Server Always On アベイラビリティグループ。 SQL Serverを使用している場合は、高可用性のために SQL Always On 可用性グループを使用します。 両方のリージョンにSQL Server インスタンスを含む単一の可用性グループを作成します。

  • VNET 間 VPN 接続。 Azure Stack Hubで VNET ピアリングをまだ使用できないので、VNET 間 VPN 接続を使用して 2 つの VNET を接続します。 詳細については、Azure Stack Hubの VNET から VNET への接続を参照してください。

Recommendations

マルチリージョン アーキテクチャでは、1 つのリージョンにデプロイするよりも高い可用性を提供できます。 リージョンの障害がプライマリ リージョンに影響する場合は、 Traffic Manager を使用してセカンダリ リージョンにフェールオーバーできます。 このアーキテクチャは、アプリケーションの個々のサブシステムが失敗した場合にも役立ちます。

リージョン間で高可用性を実現するには、いくつかの一般的な方法があります。

  • ホット スタンバイを使用したアクティブ/パッシブ。 トラフィックは 1 つのリージョンに送信され、もう 1 つはホット スタンバイで待機します。 ホット スタンバイとは、セカンダリ リージョン内の VM が常に割り当てられ、実行されていることを意味します。

  • コールド スタンバイを使用したアクティブ/パッシブ。 トラフィックは 1 つのリージョンに送信され、もう 1 つはコールド スタンバイで待機します。 コールド スタンバイとは、セカンダリ リージョン内の VM がフェールオーバーに必要になるまで割り当てられないことを意味します。 この方法の実行コストは低くなりますが、通常、障害発生時にオンラインになるには時間がかかります。

  • アクティブ/アクティブ。 どちらのリージョンもアクティブであり、要求はそれらの間で負荷分散されます。 1 つのリージョンが使用できなくなった場合、そのリージョンはローテーションから除外されます。

この参照アーキテクチャでは、フェールオーバーに Traffic Manager を使用して、ホット スタンバイのアクティブ/パッシブに焦点を当てます。 ホット スタンバイ用に少数の VM をデプロイし、必要に応じてスケールアウトできます。

Traffic Manager の構成

Traffic Manager を構成するときは、次の点を考慮してください。

  • ルーティング。 Traffic Manager では、いくつかの ルーティング アルゴリズムがサポートされています。 この記事で説明するシナリオでは、 優先順位 ルーティング (旧称フェールオーバー ルーティング) を使用 します 。 この設定では、プライマリ リージョンに到達できない場合を除き、Traffic Manager はすべての要求をプライマリ リージョンに送信します。 その時点で、セカンダリ リージョンに自動的にフェールオーバーされます。 フェールオーバー ルーティング方法の構成に関する記事を参照してください。

  • 正常性プローブ。 Traffic Manager では、HTTP (または HTTPS) プローブ を使用して、各リージョンの可用性を監視します。 プローブは、特定の URL パスの HTTP 200 応答をチェックします。 ベスト プラクティスとして、アプリケーションの全体的な正常性を報告するエンドポイントを作成し、正常性プローブにこのエンドポイントを使用します。 そうしないと、アプリケーションの重要な部分が実際に失敗したときに、プローブが正常なエンドポイントを報告する可能性があります。 詳細については、「正常性エンドポイントの監視パターン」を参照してください。

Traffic Manager がフェールオーバーすると、クライアントがアプリケーションに到達できない期間があります。 期間は、次の要因の影響を受けます。

  • 正常性プローブは、プライマリ リージョンに到達不能になったことを検出する必要があります。

  • DNS サーバーは、DNS の有効期間 (TTL) に応じて、IP アドレスのキャッシュされた DNS レコードを更新する必要があります。 TTL の既定値は 300 秒 (5 分) ですが、この値は、Traffic Manager プロファイルを作成するときに構成できます。

詳細については、「 Traffic Manager の監視について」を参照してください。

Traffic Manager がフェールオーバーする場合は、自動フェールバックを実装するのではなく、手動フェールバックを実行することをお勧めします。 それ以外の場合は、アプリケーションがリージョン間でやり取りする状況を作成できます。 フェールバックする前に、すべてのアプリケーション サブシステムが正常であることを確認します。

Traffic Manager は既定で自動的にフェールバックされることに注意してください。 これを回避するには、フェールオーバー イベントの後にプライマリ リージョンの優先順位を手動で下げてください。 たとえば、プライマリ リージョンが優先度 1 で、セカンダリが優先度 2 であるとします。 フェールオーバー後、プライマリ リージョンを優先度 3 に設定して、自動フェールバックを防ぎます。 切り替える準備ができたら、優先度を 1 に更新します。

次のAzure CLI コマンドは、優先度を更新します。

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --priority 3

もう 1 つの方法は、フェールバックの準備ができるまでエンドポイントを一時的に無効にすることです。

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --endpoint-status Disabled

フェールオーバーの原因によっては、リージョン内のリソースの再デプロイが必要になる場合があります。 フェールバックする前に、運用準備テストを実行します。 テストでは、次のようなことを確認する必要があります。

  • VM は正しく構成されています。 (必要なすべてのソフトウェアがインストールされ、IIS が実行されているなど)。

  • アプリケーション サブシステムは正常です。

  • 機能テスト。 (たとえば、データベース層は Web 層から到達可能です)。

Always On 可用性グループSQL Server構成する

Windows Server 2016する前に、Always On 可用性グループSQL Serverにはドメイン コントローラーが必要であり、可用性グループ内のすべてのノードが同じ Active Directory (AD) ドメインに存在する必要があります。

可用性グループを構成するには:

  • 少なくとも、各リージョンに 2 つのドメイン コントローラーを配置します。

  • 各ドメイン コントローラーに静的 IP アドレスを指定します。

  • 2 つの仮想ネットワーク間の通信を有効にする VPN を作成します。

  • 仮想ネットワークごとに、(両方のリージョンの) ドメイン コントローラーの IP アドレスを DNS サーバーの一覧に追加します。 次の CLI コマンドを使用できます。 詳細については、「DNS サーバーの変更」を参照してください。

    az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"

  • 両方のリージョンのSQL Server インスタンスを含むWindows Server フェールオーバー クラスタリング (WSFC) クラスターを作成します。

  • プライマリ リージョンとセカンダリ リージョンの両方のSQL Server インスタンスを含むSQL Server Always On 可用性グループを作成します。 手順については、「Always On 可用性グループをリモート Azure Datacenter (PowerShell) に拡張する」を参照してください。

    • プライマリ レプリカをプライマリ リージョンに配置します。

    • プライマリ リージョンに 1 つ以上のセカンダリ レプリカを配置します。 自動フェールオーバーで同期コミットを使用するようにこれらを構成します。

    • セカンダリ リージョンに 1 つ以上のセカンダリ レプリカを配置します。 パフォーマンス上の理由から、 非同期 コミットを使用するようにこれらを構成します。 (それ以外の場合、すべての T-SQL トランザクションは、ネットワーク経由でセカンダリ リージョンへのラウンド トリップを待機する必要があります)。

Note

非同期コミット レプリカでは、自動フェールオーバーはサポートされていません。

可用性に関する考慮事項

複雑な N 層アプリでは、セカンダリ リージョンでアプリケーション全体をレプリケートする必要がない場合があります。 代わりに、ビジネス継続性をサポートするために必要な重要なサブシステムをレプリケートするだけです。

Traffic Manager は、システムで発生する可能性のある障害ポイントです。 Traffic Manager サービスが失敗した場合、クライアントはダウンタイム中にアプリケーションにアクセスできません。 Traffic Manager の SLA を確認し、Traffic Manager のみを使用して高可用性のためのビジネス要件を満たしているかどうかを判断します。 そうでない場合は、フェールバックとして別のトラフィック管理ソリューションを追加することを検討してください。 Azure Traffic Manager サービスが失敗した場合は、DNS の CNAME レコードを変更して、他のトラフィック管理サービスを指すようにします。 (この手順は手動で実行する必要があり、DNS の変更が反映されるまでアプリケーションは使用できません)。

SQL Server クラスターでは、次の 2 つのフェールオーバー シナリオを考慮する必要があります。

  • プライマリ リージョン内のすべてのSQL Server データベース レプリカが失敗します。 たとえば、このエラーは、リージョンの停止中に発生する可能性があります。 その場合は、Traffic Manager がフロントエンドで自動的にフェールオーバーする場合でも、可用性グループを手動でフェールオーバーする必要があります。 SQL Server可用性グループの強制手動フェールオーバーの実行に関する記事の手順に従って、SQL Server Management Studio、Transact-SQL、または PowerShell を使用して 2016 年SQL Server強制フェールオーバーを実行する方法について説明します。

    Warning

    強制フェールオーバーでは、データ損失のリスクがあります。 プライマリ リージョンがオンラインに戻ったら、データベースのスナップショットを作成し、 tablediff を使用して相違点を見つけます。

  • Traffic Manager はセカンダリ リージョンにフェールオーバーしますが、プライマリ SQL Server データベース レプリカは引き続き使用できます。 たとえば、フロントエンド 層は、SQL Server VM に影響を与えずに失敗する可能性があります。 この場合、インターネット トラフィックはセカンダリ リージョンにルーティングされ、そのリージョンは引き続きプライマリ レプリカに接続できます。 ただし、SQL Server接続はリージョン間で行われるため、待機時間が長くなります。 このような場合は、次のように手動フェールオーバーを実行します。

    1. セカンダリ リージョンのSQL Server データベース レプリカを一時的に同期コミットに切り替えます。 この変更により、フェールオーバー中にデータが失われることがなくなります。

    2. そのレプリカにフェールオーバーします。

    3. プライマリ リージョンにフェールバックする場合は、非同期コミット設定を復元します。

管理容易性に関する考慮事項

デプロイを更新するときは、一度に 1 つのリージョンを更新して、正しくない構成またはアプリケーションのエラーによるグローバル障害の可能性を減らします。

障害に対するシステムの回復性をテストします。 テストする一般的な障害シナリオを次に示します。

  • VM インスタンスをシャットダウンします。

  • CPU やメモリなどのリソースに負荷をかけます。

  • ネットワークの切断または遅延。

  • クラッシュ プロセス。

  • 証明書の有効期限が切れます。

  • ハードウェア障害をシミュレートします。

  • ドメイン コントローラーで DNS サービスをシャットダウンします。

復旧時間を測定し、ビジネス要件を満たしていることを確認します。 障害モードの組み合わせもテストします。

次のステップ

  • Last updated on