AG VNN リスナー用に Azure ロード バランサーを構成する - Azure VM 上の SQL Server

  • [アーティクル]

適用対象:Azure VM 上の SQL Server

ヒント

可用性グループをデプロイする方法は多数あります。 デプロイを簡略化し、Always On 可用性グループに対して Azure Load Balancer または分散ネットワーク名 (DNN) を不要にするには、同じ Azure 仮想ネットワーク内の複数のサブネットに SQL Server 仮想マシン (VM) を作成します。 可用性グループを 1 つのサブネットに既に作成している場合は、マルチサブネット環境に移行できます。

Azure 仮想マシンでは、クラスターは、一度に 1 つのクラスター ノードに存在する必要がある IP アドレスを保持するためにロード バランサーを使用します。 このソリューションでは、SQL Server VM が 1 つのサブネット内にある場合に、Always On 可用性グループの仮想ネットワーク名 (VNN) リスナーの IP アドレスが、ロード バランサーによって保持されます。

この記事では、Azure Load Balancer サービスを使用してロード バランサーを構成する方法について説明します。 高可用性とディザスター リカバリー (HADR) を実現するために、ロード バランサーによって、Azure VM 上の SQL Server を使用する可用性グループ リスナーにトラフィックがルーティングされます。

SQL Server 2019 CU8 以降を使用しているお客様向けの代替の接続オプションとしては、代わりに分散ネットワーク名 (DNN) リスナーを検討してください。 DNN リスナーを使用すると、構成が簡素化され、フェールオーバーが改善されます。

前提条件

この記事の手順を完了するには、次のものが必要です。

ロード バランサーの作成

次のいずれかの種類のロード バランサーを作成できます。

  • 内部: 内部ロード バランサーは、ネットワークの内部にあるプライベート リソースからのみアクセスできます。 内部ロード バランサーとその規則を構成するときは、フロントエンド IP に、可用性グループ リスナーと同じ IP アドレスを使用します。

  • 外部: 外部ロード バランサーは、パブリック リソースから内部リソースへとトラフィックをルーティングすることができます。 外部ロード バランサーを構成するときは、可用性グループ リスナーと同じ IP アドレスは使用できません。リスナーの IP アドレスをパブリック IP アドレスにすることはできないためです。

    外部ロード バランサーを使用するには、可用性グループと同じサブネット内の IP アドレスのうち、他の IP アドレスと競合しないアドレスを論理的に割り当てます。 このアドレスを負荷分散規則のフロントエンド IP アドレスとして使用します。

重要

Azure Load Balancer の Basic SKU は、2025 年 9 月 30 日に廃止される予定です。 詳細については、公式告知を参照してください。 現在、Basic Load Balancer をお使いの場合は、廃止日前に Standard Load Balancer にアップグレードしてください。 ガイダンスについては、ロード バランサーのアップグレードに関するページをご確認ください。

ロード バランサーを作成するには、次の手順を実行します。

  1. Azure portal で、仮想マシンが含まれているリソース グループに移動します。

  2. [追加] を選択します。 Azure Marketplace で「ロード バランサー」を検索します。 [ロード バランサー] を選択します。

  3. ［作成］ を選択します

  4. [ロード バランサーの作成] の [基本] タブで、次の値を使用してロード バランサーを設定します。

    • サブスクリプション:Azure サブスクリプション。
    • [リソース グループ] :仮想マシンが含まれているリソース グループ。
    • Name:ロード バランサーを識別する名前。
    • [リージョン] :仮想マシンが含まれている Azure の場所。
    • [SKU]: Standard。
    • [種類]: パブリックまたは内部。 内部ロード バランサーには、仮想ネットワーク内からアクセスできます。 ほとんどの Azure アプリケーションで内部ロード バランサーを使用できます。 アプリケーションがインターネット経由で直接 SQL Server にアクセスする必要がある場合は、パブリック ロード バランサーを使用します。
    • [レベル]: リージョン。

    Screenshot of the Azure portal that shows the page for basic information about a load balancer.

  5. [次へ: フロントエンド IP 構成] を選びます。

  6. [フロントエンド IP 構成の追加] を選択します。

    Screenshot of the Azure portal that shows the button for adding a frontend IP configuration.

  7. 次の値を使用してフロントエンド IP アドレスを設定します。

    • [名前]: フロントエンド IP 構成を識別する名前。
    • 仮想ネットワーク:仮想マシンと同じネットワーク。
    • [サブネット]: 仮想マシンと同じサブネット。
    • [割り当て]: 静的。
    • [IP アドレス]: クラスター化されたネットワーク リソースに割り当てた IP アドレス。
    • [可用性ゾーン]: IP をデプロイするオプションの可用性ゾーンを選びます。

    Screenshot of the Azure portal that shows the page for configuring a frontend IP address.

  8. [追加] を選択してフロントエンド IP アドレスを作成します。

  9. [確認と作成] を選択して、ロード バランサーを作成します。

バックエンド プールを構成する

  1. 仮想マシンが含まれている Azure リソース グループに戻り、新しいロード バランサーを探します。 リソース グループの表示を更新することが必要な場合もあります。 ロード バランサーを選択します。

  2. [バックエンド プール] を選んでから、[+ 追加] を選択します。

  3. [名前] で、バックエンド プールの名前を指定します。

  4. [バックエンド プールの構成] で [NIC] を選択します。

  5. [追加] を選択して、VM を含む可用性セットにバックエンド プールを関連付けます。

  6. [仮想マシン] で、クラスター ノードとして参加する仮想マシンを選びます。 必ず、可用性グループをホストするすべての仮想マシンを含めます。

    各 VM のプライマリ IP アドレスのみを追加します。 セカンダリ IP アドレスは追加しないでください。

  7. [追加] を選択して、仮想マシンをバックエンド プールに追加します。

  8. [保存] を選択して、バックエンド プールを作成します。

正常性プローブを構成する

  1. ロード バランサーのペインで、[正常性プローブ] を選択します。

  2. [正常性プローブの追加] ペインで、 の次のパラメーターを設定します。

  3. [追加] を選択します。

負荷分散規則を設定する

  1. ロード バランサーのペインで、[負荷分散規則] を選択します。

  2. [追加] を選択します。

  3. これらのパラメーターを設定します。

    • [名前]: 負荷分散規則の名前。
    • [フロントエンド IP アドレス]: フロントエンドを構成したときに設定した IP アドレス。
    • [バックエンド プール]: ロード バランサーを対象とする仮想マシンを含むバックエンド プール。
    • HA ポート: TCP と UDP プロトコル用のすべてのポートで負荷分散を有効にします。
    • [プロトコル]: TCP。
    • ポート:SQL Server の TCP ポート。 既定値は 1433 です。
    • [バックエンド ポート] : [フローティング IP (ダイレクト サーバー リターン)] を有効にしたときの [ポート] の値と同じポート。
    • [正常性プローブ] : 先ほど構成した正常性プローブ。
    • [セッション永続化]: なし。
    • [アイドル タイムアウト (分)]: 4。
    • [フローティング IP](ダイレクト サーバー リターン) : 有効。

  4. [保存] を選択します。

クラスターのプローブを構成する

PowerShell でクラスター プローブのポート パラメーターを設定します。

使用環境の値を使用して、次のスクリプトの変数を更新します。 スクリプトから山かっこ (< および >) を削除します。

$ClusterNetworkName = "<Cluster Network Name>"
$IPResourceName = "<AG Listener IP Address Resource Name>" 
$ILBIP = "<n.n.n.n>" 
[int]$ProbePort = <nnnnn>

Import-Module FailoverClusters

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}

次の表では、更新する必要がある値について説明します。

変数 Value
ClusterNetworkName ネットワークの Windows Server フェールオーバー クラスターの名前。 [フェールオーバー クラスター マネージャー]>[ネットワーク] で、ネットワークを右クリックして [プロパティ] を選択します。 正しい値は [全般] タブの [名前] にあります。
IPResourceName AG リスナーの IP アドレスのリソース名。 [フェールオーバー クラスター マネージャー]>[Roles](ロール) で、可用性グループ ロールの [サーバー名] の下にある IP アドレス リソースを右クリックして [プロパティ] を選択します。 正しい値は [全般] タブの [名前] にあります。
ILBIP 内部ロード バランサーの IP アドレス。 このアドレスは、Azure portal で内部ロード バランサーのフロントエンド アドレスとして構成されます。 これは可用性グループ リスナーと同じ IP アドレスです。 [フェールオーバー クラスター マネージャー] で IPResourceName の値があるのと同じプロパティ ページで見つけることができます。
ProbePort ロード バランサーの正常性プローブで構成したプローブ ポート。 未使用の TCP ポートが有効です。
SubnetMask クラスター パラメーターのサブネット マスク。 TCP/IP のブロードキャスト アドレス 255.255.255.255 である必要があります。

行った変更は、IP アドレス リソースがオフラインになって再びオンラインになるまで有効になりません。 この変更を有効にするには、可用性グループのフェールオーバーを実行します。 クラスターのプローブを設定したら、PowerShell ですべてのクラスター パラメーターを確認できます。 このスクリプトを実行します。

Get-ClusterResource $IPResourceName | Get-ClusterParameter

接続文字列を変更する

それをサポートするクライアントの場合は、MultiSubnetFailover=True を接続文字列に追加します。 MultiSubnetFailover 接続オプションは必須ではありませんが、サブネットのフェールオーバーが速くなるという利点があります。 これは、クライアント ドライバーが、各 IP アドレスの TCP ソケットを同時に開こうとするためです。 クライアント ドライバーは、最初の IP アドレスが正常に応答するまで待機します。 正常な応答があると、クライアント ドライバーはその IP アドレスを接続に使用します。

ご自身のクライアントで MultiSubnetFailover パラメーターがサポートされていない場合は、RegisterAllProvidersIP と HostRecordTTL の設定を変更して、フェールオーバー後の接続の遅延を防ぐことができます。

PowerShell を使用して RegisterAllProvidersIp と HostRecordTTL の設定を変更します。

Get-ClusterResource yourListenerName | Set-ClusterParameter RegisterAllProvidersIP 0  
Get-ClusterResource yourListenerName|Set-ClusterParameter HostRecordTTL 300

詳細については、SQL Server のリスナーの接続タイムアウトに関するドキュメントを参照してください。

ヒント

  • 1 つのサブネットの HADR ソリューションでも、接続文字列内で MultiSubnetFailover parameter を true に設定します。 この設定により、今後、接続文字列を更新することなく、複数のサブネットにまたがることができます。
  • 既定では、クライアントは 20 分間、クラスター DNS レコードをキャッシュします。 HostRecordTTL を小さくすることで、キャッシュされたレコードの有効期間 (TTL) を短縮できます。 そうするとレガシ クライアントはよりすばやく再接続できます。 このため、HostRecordTTL の設定を小さくすると、DNS サーバーへのトラフィックが増加する可能性があります。

[テスト フェールオーバー]

クラスター化されたリソースのフェールオーバーをテストして、クラスターの機能を検証します。

  1. SQL Server Management Studio を開き、可用性グループ リスナーに接続します。
  2. オブジェクト エクスプローラーで、[Always On 可用性グループ] を展開します。
  3. 可用性グループを右クリックして、 [フェールオーバー] を選択します。
  4. ウィザードの指示に従って、可用性グループをセカンダリ レプリカにフェールオーバーします。

レプリカのロールが切り替わり、両方が同期された場合、フェールオーバーは成功です。

接続をテストする

接続をテストするには、同じ仮想ネットワーク内の別の仮想マシンにサインインします。 SQL Server Management Studio を開き、可用性グループ リスナーに接続します。

Note

必要に応じて、SQL Server Management Studio をダウンロードできます。

次のステップ

VNN が作成されたら、SQL Server VM のクラスター設定を最適化することを検討してください。

詳細については、以下をご覧ください。