クラスターを作成する
このセクションでは、Windows Server Failover Cluster (WSFC) および可用性グループを作成するために必要なビルド・タスクについて順を追って説明します。
本書では、以下を前提としています。
- Windows 2019 および SQL Server 2019 を実行するサーバーを少なくとも 2 つクラスター化します。
- 外部インターネットにアクセスできる要塞ホストを用意します。
- Active Directory をデプロイしました。
Failover Clustering 機能のインストール
-
SQL Admins グループ・アカウントのユーザーを使用して最初の SQL サーバーに RDP を実行し、PowerShell セッションを開きます。
-
SQL Admins グループをローカル・リモート管理ユーザー・グループに追加して、このグループのユーザーがリモート・コマンドを実行できるようにします。
-
このポートは可用性グループのトラフィックに使用されるため、サーバーへのインバウンド TCP ポート 5022 を許可します。 Failover Clustering 機能をインストールしてから、サーバーを再始動します。
$domainnb = "<NB_Domain>" $group = $domainnb + "\SQLAdmins" Add-LocalGroupMember -Group "Remote Management Users" -Member $group New-NetFirewallRule -DisplayName 'SQL-AG-Inbound' -Profile Domain -Direction Inbound -Action Allow -Protocol TCP -LocalPort 5022 Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools Restart-Computer -Force
-
2 番目の SQL サーバーについて、この手順を繰り返します。
WSFC を作成し、SQL を常にオンにする
-
SQL Admins グループ・アカウントのユーザーを使用して最初の SQL サーバーに RDP を実行し、PowerShell セッションを開きます。
-
クラスター妥当性テストを実行します。 「ネットワーク・インターフェースの 1 つのペア」の警告は無視してください。これは、このデプロイメントでは正常です。
-
エラーがない場合は、
wsfc01
という名前の WSFC クラスターを作成します。これには、2 つの SQL サーバー<hostname1>
および<hostname2>
が含まれます。-ManagementPointNetworkType Distributed
オプションは、仮想サーバーのノード IP アドレスを使用します。これは、インターフェース上の 2 次 IP アドレッシングが不要であることを意味します。 このオプションは, 適切なクラスター資源にトラフィックを経路指定する分散ネットワーク名 (DNN) を作成します。 -
次に、 fs01でファイル共有を使用して、 Node およびディスク・マジョリティ用にクラスター・クォーラムを構成します。
\\fs01\clusterwitness-wsfc01
$sqldb01 = "<hostname1>" $sqldb02 = "<hostname2>" Test-Cluster -Node $sqldb01, $sqldb02 New-Cluster -Name wsfc01 -Node $sqldb01, $sqldb02 -ManagementPointNetworkType Distributed Set-ClusterQuorum -NodeAndFileShareMajority \\fs01\clusterwitness-wsfc01 Enable-SqlAlwaysOn -ServerInstance sqldb01, sqldb02 -Force
このアクティビティーは、2 番目のノードで繰り返す必要はありません。
エンドポイントの作成
-
SQL Admins グループ・アカウントのユーザーを使用して最初の SQL サーバーに RDP を実行し、PowerShell セッションを開きます。
-
Always On 可用性グループに参加するには、サーバー・インスタンスに独自のエンドポイントが必要です。このエンドポイントは、可用性レプリカをホストするサーバー・インスタンス間でトラフィックを送受信するために TCP ポート 5022 を使用します。
-
以下の PowerShell コマンドを使用して、これらのエンドポイントを構成します。
Hadr_endpoint
SQL サーバー上のデフォルトの SQL インスタンス (DEFAULT) で、<hostname1>`` and <hostname2>
エンドポイント間の暗号化を有効にします。$sqldb01 = "<hostname1>" $sqldb02 = "<hostname2>" $domainnb = "<NB_Domain>" $user = $domainnb + "\sqlsvc" $pathsqldb01 = "SQLSERVER:\SQL\" + $sqldb01 + "\DEFAULT" $pathsqldb01 = "SQLSERVER:\SQL\" + $sqldb02 + "\DEFAULT" $endpoint1 = New-SqlHadrEndpoint Hadr_endpoint -Port 5022 -Path $pathsqldb01 -Encryption Required -EncryptionAlgorithm Aes -Owner $user Set-SqlHadrEndpoint -InputObject $endpoint1 -State "Started" $endpoint2 = New-SqlHadrEndpoint Hadr_endpoint -Port 5022 -Path $pathsqldb02 -Encryption Required -EncryptionAlgorithm Aes -Owner $user Set-SqlHadrEndpoint -InputObject $endpoint2 -State "Started"
エンドポイントによって使用されるドメイン・サービスに接続権限を付与するには、以下の手順を実行する必要があります。 このステップを実行しないと、エンドポイント・ポートは開始されず、 netstat -a
リストに表示されません。
- プライマリー・レプリカ・ホスト上で SQL Server Management Studio (SSMS) を起動し、プライマリー・レプリカに接続します。
- 「セキュリティー」を展開し、「ログイン」を右クリックして「新規ログイン」を選択します。
- 「検索」をクリックし、ユーザー・アカウント ¥ sqlserver¥ sqlsvc を入力して、「OK」をクリックします。
- 作成されたログインを右クリックし、「プロパティー」を選択します。
- 「Securables」をクリックし、次に「検索」をクリックします。
- 「オブジェクトの追加」ダイアログで、「特定のオブジェクト」を選択し、「OK」をクリックします。
- 「オブジェクトの選択」ダイアログで、「オブジェクト・タイプ」をクリックし、「エンドポイント」を選択します。
- オブジェクト名を選択するには、「参照」をクリックします。
- 「Hadr_endpoint」を選択し、「OK」をクリックします。
- Hadr_endpoint の許可で、このオブジェクトに対する接続許可を明示的に付与します。
テスト・データベースの作成
可用性グループを構成するには、1 次ノードでデータベースが使用可能になっていて、2 次ノードでこのデータベースのコピーが使用可能になっている必要があります。 このタスクでは、テスト・データベースを作成し、ファイル共有を介してバックアップおよびリストア操作を使用して、データベースを 2 次ノードにコピーします。
-
SQL Admins グループ・アカウントのユーザーを使用して最初の SQL サーバーに RDP を実行し、PowerShell セッションを開きます。 可用性グループで使用されるデータベースの場合は、リカバリー・モードを
Full
に設定することが重要です。$sql = " CREATE DATABASE [TestDatabase] CONTAINMENT = NONE ON PRIMARY ( NAME = N'TestDatabase', FILENAME = N'D:\MSSQL15.MSSQLSERVER\MSSQL\DATA\TestDatabase.mdf' , SIZE = 1048576KB , FILEGROWTH = 262144KB ) LOG ON ( NAME = N'MyDatabase_log', FILENAME = N'E:\MSSQL15.MSSQLSERVER\MSSQL\Logs\TestDatabase_log.ldf' , SIZE = 524288KB , FILEGROWTH = 131072KB ) GO USE [master] GO ALTER DATABASE [TestDatabase] SET RECOVERY FULL GO ALTER AUTHORIZATION ON DATABASE::[TestDatabase] TO [sa] GO " Invoke-SqlCmd -ServerInstance sqldb01 -Query $sql
-
Backup-SqlDatabase
コマンドとRestore-SqlDatabase
コマンドを使用して 2 次データベースを準備し、1 次レプリカをホストする SQL Server インスタンスであるTempShare
on<hostname1>
on<file_share_host>
のTestDatabase
のバックアップを作成します。 2 次レプリカをホストする<hostname2>
にバックアップをリストアします。NoRecovery
リストア・パラメーターを使用する必要があります。$sqldb01 = "<hostname1>" $sqldb02 = "<hostname2>" $filesharehost = "<file_share_host>" $backupfiledata = "\\" + $filesharehost +"\TempShare\TestDatabase.bak" $backupfilelog = "\\" + $filesharehost +"\TempShare\TestDatabase.trn" Backup-SqlDatabase -Database "TestDatabase" -ServerInstance $sqldb01 -BackupFile $backupfiledata -CopyOnly Backup-SqlDatabase -Database "TestDatabase" -BackupFile $backupfilelog -ServerInstance $sqldb01 -BackupAction Log -CopyOnly Restore-SqlDatabase -Database "TestDatabase" -BackupFile $backupfiledata -ServerInstance $sqldb02 -NoRecovery Restore-SqlDatabase -Database "TestDatabase" -BackupFile $backupfilelog -ServerInstance $sqldb02 -RestoreAction Log -NoRecovery
新しい 2 次データベースは RESTORING 状態になっています。 可用性グループに結合されるまで、アクセスすることはできません。
可用性グループの作成
可用性グループに追加されたデータベースは、可用性データベースと呼ばれます。 データベースを追加する場合、そのデータベースはオンラインの読み取り/書き込みデータベースでなければならず、WSFC 内のプライマリー・レプリカをホストするサーバー・インスタンス上に存在していなければなりません。 追加されると、データベースは可用性グループに 1 次データベースとして結合され、クライアントは引き続き使用できます。 1 次データベースのバックアップが、2 次レプリカになるサーバー・インスタンスにリストアされるまで、2 次データベースは存在しません。 新しい 2 次データベースは、可用性グループに結合されるまで RESTORING 状態になります。 バックアップおよびリストア方式を使用しない場合は、 「Always On 可用性グループの 2 次レプリカを初期化するための自動シードの使用」 を参照してください。
-
SQL Admins グループ・アカウントのユーザーを使用して最初の SQL サーバーに RDP を実行し、PowerShell セッションを開きます。
-
パス・エラーが発生しないようにするには、
Invoke-SQLCmd
を使用します。これにより、PowerShell ドライブ・ツリーを介してアクセスできる SQL PowerShell ライブラリーが強制的にロードされます。 PowerShell は、 SQL Server 内のオブジェクトをディレクトリー内のファイルと同様に扱います。<hostname1>
を SQL Server のホスト名に置き換えます。invoke-sqlcmd cd SQLSERVER:\SQL\<hostname1>
-
可用性グループを作成するには、-AsTemplate パラメーターを指定した
New-SqlAvailabilityReplica
コマンドを使用して、可用性グループに組み込まれる 2 つの可用性レプリカのそれぞれに対してメモリー内の可用性レプリカ・オブジェクトを作成します。 次に、New-SqlAvailabilityGroup
コマンドを使用し、availability-replica オブジェクトを参照することで、可用性グループが作成されます。AutomatedBackupPreference Primary
は、バックアップが常にプライマリー・レプリカで行われるように指定するために使用されます。一方、-FailureConditionLevel OnCriticalServerErrors
は、クリティカル・サーバー・エラーが発生したときに自動フェイルオーバーがトリガーされるように指定します。-SeedingMode Automatic
オプションを使用して、直接シードを有効にすることができます。この方法では、1 次データベースのコピーのバックアップとリストアは必要ないためです。 SQL 2019 の場合、バージョン番号は 15 です。その他のパラメーターの説明については、 New-SqlAvailabilityGroup 資料を参照してください。
$sqldb01 = "<hostname1>" $sqldb02 = "<hostname2>" $sqldb01fqdn = "<fqdn1>" $sqldb02fqdn = "<fqdn2>" $endpointurl1 "TCP://" + $sqldb01fqdn + ":5022" $endpointurl2 "TCP://" + $sqldb02fqdn + ":5022" $pathsqldb01 = "SQLSERVER:\SQL\" + $sqldb01 +" \DEFAULT" $primaryReplica = New-SqlAvailabilityReplica -Name $sqldb01 -EndpointURL $endpointurl1 -AvailabilityMode "SynchronousCommit" -FailoverMode "Automatic" -Version 15 -AsTemplate $secondaryReplica = New-SqlAvailabilityReplica -Name $sqldb02 -EndpointURL $endpointurl2 -AvailabilityMode "SynchronousCommit" -FailoverMode "Automatic" -Version 15 -AsTemplate New-SqlAvailabilityGroup -Name "AG01" -Path $pathsqldb01 -AvailabilityReplica @($primaryReplica,$secondaryReplica) -Database "TestDatabase" -ClusterType WSFC -AutomatedBackupPreference Primary -FailureConditionLevel OnCriticalServerErrors
-
以下のコマンドを使用して、2 次レプリカを可用性グループに結合します。 結合すると、2 次データベースが ONLINE 状態になり、対応する 1 次データベースとのデータ同期が開始されます。 データ同期化は、1 次データベースに対する変更を 2 次データベースに複製するプロセスです。 データ同期化では、1 次データベースがトランザクション・ログ・レコードを 2 次データベースに送信します。
$sqldb02 = "<hostname2>" $pathsqldb02 = "SQLSERVER:\SQL\" + $sqldb02 + " \DEFAULT" Join-SqlAvailabilityGroup -Path $pathsqldb02 -Name "AG01" -ClusterType WSFC
-
各 2 次データベースを可用性グループに結合して、データ同期化を開始します。
$sqldb02 = "<hostname2>" $agpathsqldb02 = "SQLSERVER:\SQL\" + $sqldb02 + " \DEFAULT\AvailabilityGroups\AG01" Add-SqlAvailabilityDatabase -Path $agpathsqldb02 -Database "TestDatabase"
-
dir コマンドを使用して、新しい可用性グループの内容を確認します (例:
dir SQLSERVER:\SQL\sqldb01\DEFAULT\AvailabilityGroups\AG01
)。
可用性グループ分散ネットワーク名の作成
IBM Cloud VPC上の SQL Server では、分散ネットワーク名 (DNN) はトラフィックを適切なクラスター・リソースにルーティングします。 (DNN) リスナーは、「常にオン」可用性グループで使用される場合、従来の仮想ネットワーク名 (VNN) 可用性グループ・リスナーを置き換え、クラウド環境でのデプロイメントを簡素化します。
DNN リスナーは、固有のポートで listen するように設計されています。 リスナー名の DNS エントリーは、可用性グループ内のレプリカのすべての IP アドレスに解決されます。 SQL Server はポート 1433 で listen するため、ポート 1433 を DNN リスナーに使用することはできません。
SQL Admins グループ・アカウントのユーザーを使用して最初の SQL サーバーに RDP を実行し、PowerShell セッションを開き、以下のコマンドを使用します。 dnnlsnr-6789
という名前の DNN リソースを作成し、DNN リソースの AD DNS サーバーで DNS を構成し、DNN リソースを開始し、可用性グループ・リソースからの依存関係を DNN リソースに追加し、最後に可用性グループをリセットします。
$ag = "AG01"
$dns = "dnnlsnr"
$port = "6789"
Add-ClusterResource -Name $port -ResourceType "Distributed Network Name" -Group $ag
Get-ClusterResource -Name $port | Set-ClusterParameter -Name DnsName -Value $dns
Start-ClusterResource -Name $port
$Dep = Get-ClusterResourceDependency -Resource $ag
if ( $Dep.DependencyExpression -match '\s*\((.*)\)\s*' ) {$DepStr = "$($Matches.1) or [$port]"} else {$DepStr = "[$port]"}
Set-ClusterResourceDependency -Resource $ag -Dependency "$DepStr"
Stop-ClusterResource -Name $ag
Start-ClusterResource -Name $ag
Windows ファイアウォールを介して TCP 6789 を許可するには、以下のコマンドを使用します。
New-NetFirewallRule -DisplayName 'SQL-dnnlsnr-6789-Inbound' -Profile Domain -Direction Inbound -Action Allow -Protocol TCP -LocalPort 6789