SQL Server 2016 以降、ミラーリングの後継機能として、Standard Edition で構築可能な 基本的な Always On 可用性グループ機能が登場しました。
オンプレミス環境で構築された ミラーリング構成を、システム リプレイスなどのタイミングで Azure へ移行することを検討されている方もいるのではないでしょうか。
今回、自分の整理も兼ねて、ミラーリングの後継機能である SQL Server 基本的な Always On 可用性グループを Azure 上で構築する方法についてまとめてみようと思います。
[構成]
OS : Windows Server 2019
※ Azure Active Directory Domain Services (Azure AD DS) もしくは、Active Directory ドメインに参加し、Windows Server 2019 フェールオーバー クラスタリング (WSFC) を構成
クラウド監視 : Azure Blob Storage
※ ゾーン冗長ストレージ (ZRS)
Azure 仮想マシン 可用性オプション : Azure 可用性ゾーン
SQL Server : SQL Server 2019 Standard Edition
SQL Server Always On 可用性リスナー : Azure Load Balancer (内部 : ゾーン冗長)
- SQL Server 基本的な Always On 可用性グループについて
- Azure 仮想マシンのデプロイ (ゾーン冗長)
- フェールオーバー クラスター (WSFC) のクォーラム構成をクラウド監視に変更
- SQL Server 基本的な Always On 可用性グループの構築
- SQL Server 基本的な Always On 可用性リスナーの構築
- まとめ
SQL Server 基本的な Always On 可用性グループについて
SQL Server 基本的な Always On 可用性グループは、ミラーリングの後継機能として、SQL Server 2016 以降、Standard Edition で構築可能な機能となります。
しかしながら、SQL Server Always On 可用性グループ (SQL Server Enterprise Edition) と比較し、以下のような制限があるため、注意が必要です。
- 最大 2 レプリカ (プライマリ レプリカ/セカンダリ レプリカ のみ)
- 1つの可用性グループには、1つの可用性データベースしか追加できない。
※ 複数の可用性データベースを作成したい場合、複数の可用性グループを構築する必要がある。 - 読み取りレプリカ機能を利用できない (セカンダリ レプリカ側)
- セカンダリ レプリカ 側の可用性データベースをバックアップはできない。
- セカンダリ レプリカ 側の可用性データベースで整合性チェックはできない。
- SQL Server 基本的な Always On 可用性グループを SQL Server Always On 可用性グループへアップグレードすることは出来ない。
※ 基本的な可用性グループを削除後、SQL Server を Enterprise Edition へエディションのアップグレードを実施後、可用性グループを新規構築する必要がある。 - 基本的な可用性グループを分散型可用性グループに参加させることはできない。
Azure 仮想マシンのデプロイ (ゾーン冗長)
1) Azure 仮想マシンをデプロイする際、「可用性オプション」:「可用性ゾーン」を選択してデプロイし、プライマリ レプリカ、セカンダリ レプリカ を別の可用性ゾーンを指定してデプロイします。
[例]
プライマリ レプリカ 用 Azure 仮想マシン : 可用性ゾーン : Zone 1
セカンダリ レプリカ 用 Azure 仮想マシン : 可用性ゾーン : Zone 2
※ Azure 仮想マシンの既定の言語は「英語」となるため、必要に応じて日本語化します。日本語化された Windows OS を複数台デプロイする必要がある場合は、日本語化した Windows OS をベースにイメージ化することで、作業コストを軽減することができます。
Windows Server 2019 OS の日本語化、イメージ化の方法については、以下の URL を参照。
2) Azure 仮想マシンをデプロイ後、該当仮想マシン - ネットワーク - ネットワーク インターフェイス - IP 構成 - ネットワーク インターフェース名 を選択し、「割り当て」: 静的、「IP アドレス」: 固定したいプライベート IP アドレス を入力後、「保存」を選択します。
3) Azure 仮想マシンをドメイン (Azure AD DS もしくは Active Directory) に参加させます。
4) フェールオーバー クラスターを作成します。
※ プライマリ レプリカ 用 Azure 仮想マシン、セカンダリ レプリカ 用 Azure 仮想マシンの 2ノード でフェールオーバー クラスターを構成します。
フェールオーバー クラスター (WSFC) のクォーラム構成をクラウド監視に変更
フェールオーバー クラスター (WSFC) のクォーラム構成として、クラウド監視 : Azure Blob Storage (ゾーン冗長ストレージ (ZRS)) を構成します。
クラウド監視の構成方法については、以下の URL を参照
SQL Server 基本的な Always On 可用性グループの構築
1) SQL Server 基本的な Always On 可用性グループのプライマリ/セカンダリ レプリカ用の各Azure 仮想マシン上で SQL Server 2019 Standard Edition をインストールします。
2) SQL Server 2019 Standard Edition をインストールした各Azure 仮想マシン上で、「SQL Server Configuration Manager」を起動し、「Always On 可用性グループ」-「Always On 可用性グループを有効にする」にチェック後、「適用」ボタンを選択します。
その後、設定を反映させるため、SQL Server サービスの再起動を実施します。
3) SQL Server 2019 Standard Edition をインストールした各Azure 仮想マシン上で、SQL Server Management Studio (以下 SSMS) をダウンロードし、SSMS をインストールします。
SSMS については、以下の URL から 最新版 をダウンロードします。
3) SSMSを起動し、管理者権限(sysadmin)が付与されたログイン(saなど)で、SQL Server 基本的な可用性グループの プライマリ レプリカ用 SQL Server インスタンスに接続します。
4) 「新しい可用性グループ ウィザード」から SQL Server 可用性グループを構成します。
SQL Server 基本的な Always On 可用性グループの構築手順については、以下の URL を参照。
SSMSで SQL Server 基本的な Always On 可用性グループを構築する場合。※ SQL Server 2019 Standard Edition がインストールされた環境で 「新しい可用性グループ ウィザード」を実施することで、SQL Server 基本的な Always On 可用性グループとして構築されます。
5) 以下の URL を参考に SQL Server 基本的な Always On 可用性グループのオプション設定 (Lease Timeout、HealthCheckTimeout など) を変更します。
SQL Server 基本的な Always On 可用性リスナーの構築
以下の URL を参考に SQL Server 基本的な Always On 可用性リスナーを作成します。
※ SQL Server Always On 可用性リスナーと同じ手順で作成可能。
まとめ
今回は、ミラーリングの後継機能である SQL Server 基本的な Always On 可用性グループを Azure 上で構築する方法についてまとめてみました。
SQL Server Always On 可用性グループ と比較し、SQL Server 基本的な Always On 可用性グループには制約事項がありますが、制約事項を許容できる場合、より安価に SQL Server の高可用性構成を組むことができます。
また、ディザスタ リカバリ構成を Azure 東日本、西日本 間で構築する場合、SQL Server Standard Edition では 分散型可用性グループを構成することはできませんが、SQL Server 基本的な Always On 可用性グループ 間をレプリケーション (トランザクション レプリケーション) で同期させることは可能となるため、 要件に応じて柔軟に構成を検討されると良いかと思います。
関連 URL
※ 2022年2月 現在