システムを安定稼働させつつ、新ドメインへの移行をスムーズに行うためには、事前準備と段階的な手順が不可欠です。本記事では、SQLマルチノードクラスターとAlways On可用性グループの移行に焦点を当て、ダウンタイムを極力抑えるための具体策や注意点を分かりやすく解説します。
SQLマルチノードクラスターとAlways Onを異なるドメインへ移行する背景
クラスター構成のSQL Server環境を運用していると、組織のセキュリティ要件や事業統合などの理由で、ドメインを変更しなければならない場面に遭遇することがあります。特にWindows フェールオーバークラスターとSQL ServerのAlways On可用性グループ(AG)を組み合わせた構成では、複数のノードがクラスターに参加しているため、ドメイン移行の手順を誤ると可用性に深刻な影響が及ぶ可能性があります。
ドメイン移行によるリスクを最小化しながら、新たなドメイン環境でスムーズに運用を継続するためには、移行前の準備とノードを順番に移行していくローリングアップグレードに似たアプローチが有効です。
移行前に知っておきたい事前準備のポイント
ドメイン間のトラスト(信頼関係)の構築
異なるドメイン間でノードやサービスアカウントをスムーズに移行するためには、事前に新旧ドメイン間のトラストを設定しておくことが望ましいです。多くの場合、双方向のトラストを構築することで、移行作業時に認証エラーが発生しにくくなります。
- 双方向のトラストを設定する場合は、双方のドメインコントローラーにおけるDNSとネットワーク疎通が重要
- 一方向のトラストで十分なケースもあるが、権限周りの設定を見落とすとエラーが発生しやすい
新ドメイン上でのサービスアカウント準備
SQL ServerサービスやWindowsクラスタサービスを実行するためのドメインアカウント、あるいはグループ管理サービスアカウント(gMSA)を事前に新ドメインで用意しておきましょう。これらのアカウントには、該当するサーバーへのログオン権限やサービス起動権限など、必要十分な権限を割り当てておく必要があります。
- サービスアカウントは紐付けているポリシーが適切か(ログオン権限、パスワード期限など)
- SQL Serverインスタンスのサービスだけでなく、SQLエージェントやブラウザサービスのアカウントも確認
ネットワーク設定とDNSの確認
ドメインをまたいでクラスターを運用する上で、ネットワークの整合性とDNSの名前解決は極めて重要です。特にAlways On可用性グループのリスナーを使用している場合、接続先ホスト名の解決ができなくなるとアプリケーションのサービス停止につながります。
| 項目 | 確認内容 |
|---|---|
| DNSレコード | AレコードやCNAMEなど、クラスターやリスナー用のレコードが正しく登録されているか |
| ネットワーク疎通 | 旧ドメインから新ドメインに移行後のノード間通信(ポート開放状況)を確認 |
| ファイアウォール | 1433/TCPやクラスター関連のポート(3343/UDPなど)が許可されているか |
SQLマルチノードクラスターとAlways Onを移行する手順概要
1. 現行クラスターとAlways Onの状態確認
まずは、移行作業を始める前に現在のクラスターとAlways On可用性グループの状態をチェックします。フェールオーバークラスター マネージャーやSQL Server Management Studio(SSMS)の「可用性グループダッシュボード」を使って、以下の点を確認しましょう。
- 各可用性グループ(AG)が正常に同期されているか
- すべてのノードがクラスターに正しく参加しているか
- 自動/手動フェールオーバーの設定が想定通りになっているか
トラブルシューティングに時間を割かないためにも、移行前に「現状が健全な状態である」ことを確実にしておくのがポイントです。
2. ローリング方式でのノード移行
ダウンタイムを最小限に抑えるため、クラスターを構成するノードを1台ずつ段階的に移行する手法がおすすめです。以下に大まかな流れを示します。
ステップA: 移行対象ノードのAGレプリカを他ノードへ切り替え
移行を開始するノードがプライマリレプリカを担っている場合は、事前に別のノードへ手動フェールオーバーを行います。セカンダリレプリカの場合も、念のため読み取り負荷やバックアップジョブなどを別のノードへ移しておくと安全です。
ステップB: クラスターからノードを除外
フェールオーバークラスター マネージャーまたはPowerShellコマンドを利用して、一時的にノードをクラスターから削除(または停止状態)にします。PowerShell例としては、以下のようなイメージです。
# クラスター名やノード名は環境に合わせて適宜変更
Remove-ClusterNode -Name "NodeToBeMigrated"
ステップC: ノードを新ドメインへ参加
旧ドメインからワークグループへ抜き、続いて新ドメインに参加させます。Windows ServerのGUIやコマンドを利用します。以下はnetdomコマンドを用いたイメージです(実際にはGUIで操作するケースが多いです)。
REM まずはドメインを抜けてワークグループへ
netdom remove %COMPUTERNAME% /Domain:abc.local /UserD:user@abc.local /PasswordD:*
REM 新ドメインへの参加
netdom join %COMPUTERNAME% /Domain:xyz.local /UserD:user@xyz.local /PasswordD:*
このステップでサーバーの再起動が発生するため、移行タイミングの見極めが重要です。なお、新ドメインで利用するアカウントは必要な権限(ドメイン参加を行う管理者権限)を持つものを使用してください。
ステップD: 新ドメイン下でのクラスター再参加
ノードが新ドメインに所属した状態で、再度Windows フェールオーバークラスターに追加します。PowerShellを例にすれば以下のようなコマンドを用いることが多いです。
Add-ClusterNode -Name "NodeToBeMigrated" -Cluster "YourClusterName"
また、SQL Serverのサービスアカウントを新ドメインのアカウントに切り替える作業も必要です。SQL Server Configuration Managerやサービスコントロールマネージャを用いて、ログオンアカウントに指定します。
ステップE: Always On可用性グループのレプリカ設定を再構成
新ドメインに移行したノード上のSQL Serverインスタンスで、Always On可用性グループが有効になっているか確認します。再度レプリカとしてクラスターに参加し、同期状態が「正常」になるまで待ちます。SSMSから可用性グループダッシュボードを開き、ステータスが「同期済み」もしくは「同期中」で問題ないことを確認しましょう。
3. 残りのノードへ同様の手順を適用
クラスター全体の移行作業は、上記のA～Eを各ノードに対して繰り返し行うことになります。すべてのノードが新ドメイン側に移行し終わったら、改めてクラスター全体の動作とAGのフェールオーバーが問題なく行えるか確認します。
移行時に注意すべきポイント
ドメインアカウント・クラスター名オブジェクト(CNO)の権限
新ドメインにおけるクラスター名オブジェクト(CNO)やバーチャルコンピューターオブジェクト(VCO)を作成する権限を確保しておくことが必要です。これらのオブジェクトが適切に作成・更新されないと、SQL Serverクラスタのリソースをオンラインにできません。
サービスSPN(サービスプリンシパル名)の更新
Kerberos認証を利用する場合、SQL Serverインスタンスに割り当てているSPN(サービスプリンシパル名)を新ドメインで再登録する必要があります。SPNが正しく設定されていないと、クライアントがKerberos認証で接続できず、NTLMフォールバックや認証エラーが発生する可能性があります。SPNの登録は基本的に以下のように「setspn」コマンドを用いて行います。
setspn -s MSSQLSvc/サーバー名:ポート 新ドメイン\SQLServiceAccount
ファイアウォールとネットワークポート
新ドメイン側のポリシーによっては、従来のポートがブロックされるケースがあります。フェールオーバークラスター用のポートやSQL Serverのポート(デフォルト:1433/TCP)、可用性レプリカのエンドポイント用ポート(デフォルト:5022/TCP)などが適切に許可されているかを再度確認します。
ダウンタイムを最小化する具体的なコツ
SQLマルチノードクラスターとAlways On可用性グループは、高可用性を確保する仕組みです。移行作業中でも極力サービス停止を回避できるよう、以下のポイントを意識しましょう。
- プライマリレプリカの切り替えタイミングを最適化する
プライマリレプリカを移行する前に、あらかじめ他のノードへフェールオーバーさせておくことで、ユーザーへの影響を最小限に抑えられます。 - 夜間や負荷の低い時間帯に作業する
システム全体のパフォーマンスに余裕がある時間帯に作業をすることで、再同期やネットワーク切り替え時の影響を低減できます。 - テスト環境で十分なリハーサルを実施
本番環境に近い構成のテストクラスターを用意できる場合は、必ず手順を検証してから本番移行に臨むと安心です。
移行後の最終確認手順
1. クラスターとAGのステータス確認
すべてのノードが新ドメインに移行したら、クラスターマネージャーやSSMS上でAGの状態を確認します。同期が「正常」、レプリカがすべて表示されており、警告やエラーがないことを確かめます。
2. フェールオーバーテスト
実際にプライマリレプリカを別ノードへ手動でフェールオーバーさせ、データベースへのアクセスが継続できるかテストを行います。クラスターが正常に機能していれば、数秒から数十秒程度の切り替え時間でサービス再開が可能です。
3. アプリケーション接続テスト
Always Onリスナー経由でアプリケーションが正しく接続できるか、トランザクション処理に問題が発生しないかを確認します。特に名前解決の問題やKerberos認証のトラブルがないか、イベントビューアやSQL Serverエラーログをチェックしましょう。
移行に役立つ補足情報
PowerShellによるクラスター操作の例
Windows フェールオーバークラスターの操作は、フェールオーバークラスター マネージャーからのGUI操作以外にも、PowerShellコマンドレットを活用して実行できます。大規模環境や自動化シナリオではPowerShellが有効です。 以下に、代表的なコマンドレットの一覧と簡単な説明を示します。
| コマンドレット | 概要 |
|---|---|
| Get-Cluster | 現在のクラスター情報を取得 |
| Get-ClusterNode | クラスターに参加しているノードの一覧を取得 |
| Add-ClusterNode | ノードをクラスターに追加 |
| Remove-ClusterNode | ノードをクラスターから削除 |
| Get-ClusterResource | クラスターに登録されているリソースを確認 |
SQL Server構成の変更に伴う注意点
ドメイン移行後は、SQL Serverのエージェントジョブや接続文字列に新ドメインでのアカウント情報を使用するケースが生じるかもしれません。また、リンクサーバーやジョブステップで外部アクセスを行っている場合には、ログイン情報を再構成する必要があります。
まとめ: 最小限のダウンタイムで移行を成功させるために
SQL ServerのマルチノードクラスターとAlways On可用性グループの移行は、一見複雑に思われがちです。しかし、ローリング方式でノードを一台ずつ切り離して新ドメインに移行し、再度クラスターに参加させる手順を踏めば、システム全体を一斉停止する必要はありません。 事前準備として、トラスト関係の設定、サービスアカウントの権限付与、DNSとネットワーク疎通の確認をしっかり行っておけば、移行中のトラブルを大きく減らせます。また、移行後のテストは手を抜かず、フェールオーバーテストやアプリケーション接続テストを行うことで、本番サービスの継続性を担保することが可能です。 新たなドメイン下で安定したSQL Server環境を構築するためには、包括的な計画と実践的な手順が重要です。本記事のポイントを押さえて、安全かつスムーズにドメイン移行を成功させてください。
コメント