Azureリソース内部の冗長構成
Azure SQLはAzure Service Fabric 上に構築されています。アプリケーションは最初から直接SQL Serverのインスタンスに接続するのではなく、制御リングに接続します。
Azureの外からのアクセスの場合は、制御リングがプロキシとなって、SQL Serverのインスタンスに接続します。Azureの内部からのアクセスの場合（これはパブリックIPでのアクセスも含みます）、制御リングからSQL Serverのインスタンスが指定され、アプリケーションは指定された先のSQL Server インスタンスにリダイレクトして直接接続します。
DTU モデルのBasicとStandardはGeneral Purposeと同じ、PremiumはBusiness Criticalと同じです。
General Purpose
- tempdbはローカルに接続されている SSDです。
- データ ファイルはLRSのAzure Premium Storageです。
- ログ ファイルはLRSのAzure Premium Storageです。
- バックアップ ファイルは Azure Standard Storage に格納され、既定はRA-GRSです。
- General PurposeはまだAvailability Zoneの利用がGAになっていません。
冗長構成を図にしたものが下記です。
Azure Service Fabric によってフェールオーバーが必要と判断された場合、Service Fabricは、新しいSQL Server インスタンスが起動し、データベース ファイルが接続され、復旧が実行されます。この時ゲートウェイも、アプリケーションが新しいノードに向かうように更新されます。
Business Critical
- tempdbはローカルに接続されている SSDです。
- データ ファイルはローカルに接続されている SSDです。
- ログ ファイルはローカルに接続されている SSDです。
- バックアップ ファイルは Azure Standard Storage に格納され、既定はRA-GRSです。
- Business CriticalはAvailability Zoneの利用がGAになっています。
- トランザクションでは、少なくとも 1 つのセカンダリ レプリカによってトランザクション ログの変更が書き込まれたときに、コミットを完了できます。
Always On 可用性グループをデプロイした状態になっており、3 つのセカンダリ レプリカがあります。 そのうちの 1 つをリードレプリカとして使用できます。
アプリケーションが読み取り/書き込みセッションを使用してデータを書き込み、読み取り専用セッションを使用してすぐに読み取る場合、レプリカに最新の更新がすぐに表示されない可能性があります。これはトランザクションログの配布まででコミットの応答を返しており、REDOが完了した状態であることは保証されていないためです。
Service Fabric による、セカンダリ レプリカへのフェールオーバーはGeneral Purposeと比べて高速に行われ、フェールオーバー後も、接続はゲートウェイによってプライマリにリダイレクトされます。
Hyperscale
- バックアップにスナップショットを使用しており、サイズに関係なく瞬時にバックアップされ、数分で完了します。 Business Criticalだと数時間かかります…
- セカンダリ レプリカは、ユーザーが0-4を指定して構成でき、すべてリードレプリカに使用できます。
自動フェールオーバーは、Service Fabric で必要と判断された場合に行われ、セカンダリレプリカがあるとBussiness Criticalのような動きになり、セカンダリレプリカがないと、General Purposeのような動きになります。
Geoレプリケーション
複数のリージョンを使った冗長化もできます。Geoレプリケーションという仕組みです。
Geoレプリケーションを使ったレプリケーションの状態を監視するには以下を使います。
- sys.geo_replication_links 各データベースの既存のレプリケーション リンクの情報を返します。
- sys.dm_geo_replication_link_status レプリケーションの遅延を確認するのに使います。
以下を使うとコミットされたすべてのトランザクションがレプリケートされ、アクティブ セカンダリ データベースによって認識されるまで、アプリケーションが待機状態にすることもできます。
- sp_wait_for_database_copy_sync
Geoレプリケーションには以下の制約があります。
- 一つのデータベースに対して、最大で 4 つのセカンダリ データベースを作成できます。
- セカンダリにプライマリを切り替えることができますが、アプリケーションは宛先を自分でセカンダリに書き換えなければなりません。
- セカンダリはプライマリと同じかそれ以上のサイジングにしておくことが推奨されています。
フェイルオーバーグループ
Geoレプリケーションの応用編というか発展形として、フェイルオーバーグループという仕組みもあります。
以下はフェイルオーバーグループを使った場合の構成例です。
アプリケーションはDBに直接接続するのではなく、フェイルオーバーグループのリスナーに対して接続することができるようになります。
フェールオーバーの舞台裏で DNS が更新されるため、クライアントは抽象化されたリスナー名を指すことができ、他に何も知る必要はありません。
これによってフェイルオーバーグループのプライマリとセカンダリを切り替えても、アプリケーションはフェイルオーバーグループを宛先にしたままで良くなります。
フェイルオーバーグループはGeoレプリケーションとは異なり、以下の制約があります。
- 一つのデータベースに対いて一つしか設定することができません。
- フェイルオーバーグループにはService Endpoint経由でアクセスできません。Private EndpointもしくはパブリックIPでアクセスする必要があります。
- 同じリージョンにある論理SQL Serverにフェイルオーバーグループを構成することはできません。
Managed Instanceの場合はGeoレプリケーションを構成することができませんが、フェイルオーバーグループは構成することができます。