先日投稿した、Azure VM で AD を使用しない AlwaysOn 可用性グループを Windows Server 2019 と SQL Server 2019 で構築する で、New high availability and disaster recovery benefits for SQL Server に触れました。
SQL Server 2019 では、SA の特典として、 DR 環境を Azure 上に構築することもサポートされており、これについては 新機能 のマトリクスにも記載されています。
(Failover servers for disaster recovery / Failover servers for disaster recovery in Azure が新しい特典となっていますので、Azure 以外でも DR 用のレプリカは得点を使用して作成できるはずです)
詳細な情報については、次の情報から確認することができます。
DR 環境については、次のように定義されています。
DR レプリカは、非同期レプリカのパッシブレプリカでありマニュアルフェールオーバーにより障害発生時に切り替えを行う環境であるとされています。
Disaster Recovery replica is defined as a passive replica setup as asynchronous replica with manual failover.
詳細については ライセンスガイド に記載されています。
A passive SQL Server replica is one that is not serving SQL Server data to clients or running active SQL Server workloads.
The passive failover instances can run on a separate server.
These may only be used to synchronize with the primary server and perform the following maintenance-related operations for the permitted passive fail-over Instances:
? Database consistency checks
? Log Back-ups
? Full Backups
? Monitoring resource usage data
Customer may also run primary and the corresponding disaster recovery replicas simultaneously for brief periods of disaster recovery testing every 90 days.
クライアントにアクティブなワークロードを提供することはできませんが、一部のメンテナンスに関連する作業については実施できる環境がパッシブレプリカとして定義されています。
DR レプリカを作成する際には、SQL Server の機能を用いて、データの複製を行うことになりますが、SQL Server のビジネス継続性を高めるための機能については ビジネス継続性とデータベースの復旧 – SQL Server で解説されているように、いくつかの機能を用いることが可能です。
同一ゾーン内の冗長構成については、同期レプリカで各レプリカが密結合となりますが、DR 用途のレプリカについては、遠隔地の DR 環境については疎結合で構築をしておいた方が、利便性が高いケースもあるのではないでしょうか。
そこで、今回は ログ配布 の構成を Azure Files を使用して実装したパターンをまとめてみたいと思います。
ログ配布は定期的にプライマリで取得されているバックアップを、セカンダリでリストアするという方式となり、AlwaysOn 可用性グループの同期レプリカと比較して、各環境には独立性があり疎結合なデータ同期環境として構築することができます。
今回の構成については、Windows Server 2019 の機能を使用していますので、使用可能な OS については限定されます。
なお、現時点で最新のバージョンである SQL Server 2019 では CU1 を適用しても、次のエラーが発生します。
- Log Shipping in SQLServer2019 error
- Log Shipping Agent Error Message
- Bug in SQL 2019 – Error writing Log Shipping job history
セカンダリでログ配布のリストアは実施されるのですが、ファイルのコピーやリストア時に、メッセージの記録でエラーになり、次のようなエラーが出力されるという現象が発生します。
(エラーが発生することでメッセージが記録されなくなり、セカンダリ側の過去ファイルの削除が行われないという状況が発生します)
2020-01-26 19:39:15.16 ----- START OF TRANSACTION LOG RESTORE ----- 2020-01-26 19:39:15.23 Starting transaction log restore. Secondary ID: '119eefbf-d7ad-49db-9a9c-894358d89154' 2020-01-26 19:39:15.24 *** Error: Could not log history/error message.(Microsoft.SqlServer.Management.LogShipping) *** 2020-01-26 19:39:15.24 *** Error: パラメーター値を SqlGuid から String に変換できませんでした。(System.Data) *** 2020-01-26 19:39:15.24 *** Error: オブジェクトは IConvertible を実装しなければなりません。(mscorlib) *** 2020-01-26 19:39:15.24 Retrieving restore settings. Secondary ID: '119eefbf-d7ad-49db-9a9c-894358d89154'
設定の妥当性を検証するため、2017 RTM でも試したのですが、2017 RTM では発生しませんでした。
SQL Server 2019 でログ配布を使用する場合は、既知の問題のようですので、以降の CU を待つとよいかと思います。
この問題は SQL Server 2019 CU2 で修正されているようですので、ログ配布を使用する場合は、CU2 の適用をお勧めします。
Windows で、Azure Files を使用するための情報については、Windows で Azure ファイル共有を使用する にまとめられています。
この中では、cmdkey コマンドを 使用して、資格情報の記録を行わせる処理を行っています。
Azure Virtual Machines で Premium ファイル共有を使用して SQL Server フェールオーバー クラスター インスタンスを構成する でも cmdkey を使用する方法は紹介されており、SQL Server のサービスアカウントで一度ログイン (または、サービスアカウントで実行したターミナル等) して、その状態で cmdkey を実行することで、SQL Server のサービスアカウントに、Azure Files への接続情報を記憶させるというものです。
他の方法としては、Windows Server 2019 であれば、New-SmbGlobalMapping を使用するという方法もあります。
(Windows 10 RS3 ベースの OS 以降であれば使用できるようになっており、残念ながら Windows Server 2016 では使用できなかったはずです)
このコマンドレットについては、次のドキュメントで情報が公開されています。
- Container Storage Support with Cluster Shared Volumes (CSV), Storage Spaces Direct (S2D), SMB Global Mapping
- コンテナー内の永続的なストレージ
コンテナー向けの永続化ストレージのマッピング用途で使用されるようですが、このコマンドレットは SQL Server とかなり相性がいいです。
SQL Server から共有ディレクトリに接続を行う場合、SQL Server のサービスアカウントに対して共有ディレクトリのアクセス許可を設定しておく必要があります。
デフォルトのサービスアカウントである 「NT Service\MSSQLSERVER」では、共有ディレクトリ向けの設定ができなかったため、サービスアカウントをユーザーアカウントに変更して、共有ディレクトリにアクセスを行うというような方法を Windows Server 2016 では行うことが多かったかと思います。
Windows Server 2019 の「New-SmbGlobalMapping」であれば、サーバー内の全体として設定することができるため、サービスアカウントに共有ディレクトリのアクセス権がなくても、共有にアクセスができるようにすることが可能となります。
この機能を使用することで、ログ配布で Azure Files を使用することもできるようになります。
具体的には次のようなコマンドをプライマリとセカンダリで実行して、SMB のグローバルマッピングを作成します。
$blobAccount = ""
$accessKey = ""
$cred = New-Object System.Management.Automation.PSCredential(("Azure\{0}" -f $blobAccount), ($accessKey | ConvertTo-SecureString -AsPlainText -Force))
New-SmbGlobalMapping -RemotePath ("\\{0}.file.core.windows.net\logship" -f $blobAccount) -Credential $cred -Persistent $true
次に、プライマリとセカンダリが名前解決ができ、SQL Server のポートで接続ができるようにしておきます。
今回は、東日本と東アジアに SQL Server を配置して構築を行っています。
(西日本を設定していないのは、私のサブスクリプションで西日本が使えないからという理由だけです)
今回の手順では、ログ配布を設定する際にはプライマリの SSMS から、セカンダリに接続してジョブの設定等を行いますので、VNET に関してはピアリングをしておきます。
名前解決についても同一の解決を行いたいので、セカンダリには、プライマリ DNS サフィックスを設定し、プライベート DNS ゾーンに仮想ネットワークリンクを設定しておきます。
(プライベート DNS ゾーンについては異なるリージョンの VNET にリンクすることができます)
これで、プライマリとセカンダリのネットワーク的な接続と名前解決ができるようにしておけば、事前準備は完了です。
今回はプライマリで起動した、SSMS から異なるリージョンのセカンダリに接続をしてクエリの実行を行っているため、ピアリングを行って、ネットワーク的な疎通を確保していますが、これは「SSMS からクエリを実行する環境がプライマリとセカンダリを名前解決でき、接続できる環境となっている」というのが正しい条件だと思います。
サーバー上で SSMS を起動せず、両サーバーに接続できる環境を用意できるのであれば、ピアリングをしなくても環境は構築できるかと。
ログ配布の設定を行う際に、Azure Files の UNC パスを設定するようにしておけば、Azure Files を使用したログ配布の設定が可能となります。
後の設定は通常のログ配布と変わりません。
New-SmbGlobalMapping により、Azure Files の資格情報が保存されていれば、SQL Server のデフォルトのサービスアカウントから Azure Files にバックアップが取得できます。
このような方法を使用することで、Azure Files を使用したログ配布の設定が可能です。
通常の共有ディレクトリのアクセスでも、New-SmbGlobalMapping は活用できますので、使用できる OS のバージョンとコマンドレットを覚えておくと、SQL Server のバックアップの取得先として共有ディレクトリを使用する際の活用の幅が広がるのではないでしょうか。