Nutanix MoveでActive Directoryのドメインコントローラー（以下、DC）を移行したいのですが……というご相談を、ちらほらいただくことがあります。
Nutanix Moveを利用したDCの移行については、原則としてサポートされていません。これは、MicrosoftからActive Directory Domain Services（AD DS）の移行手順が正式に公開されているという背景があります。
（参考）Active Directory Domain Services の移行
https://learn.microsoft.com/ja-jp/training/modules/active-directory-domain-services-migration/
しかし、実際には「ADが稼働している仮想マシンを、そのまま別の仮想化基盤へ移行したい」という要望をいただくことがあります。
ADが稼働している仮想マシンをそのまま移行する際に、理解しておくべき仕組みの1つが「Generation ID」です。
本記事では、Generation IDの意味とNutanix AHV上での取り扱いについて紹介します。
Generation IDとは
Generation ID（VM-GenerationID）は、ハイパーバイザーから仮想マシンに提供されるIDです。Windows Server 2012以降のドメインコントローラーでは、このGeneration IDを利用して、仮想マシン上で稼働するDCの状態が過去の状態へ巻き戻された可能性があることを検知します。仮想化環境では、DCが稼働する仮想マシンを古いスナップショットへ戻すなどの操作を行うと、Active Directoryデータベースも過去の状態へ巻き戻る可能性があります。
このような状態を適切に検知できない場合、他のDCとのレプリケーションに不整合が発生する可能性があります。
このような問題を防ぐため、Windows Server 2012以降のAD DSでは、AD DS内部に保存されているGeneration IDと、現在ハイパーバイザーから仮想マシンに提供されているGeneration IDを比較します。スナップショットからの復元などによってGeneration IDの変更を検出すると、AD DSは仮想マシンの状態が過去へ戻された可能性があると判断し、Virtualization SafeguardsによるSafe Restoreの処理を行います。
この際、AD DSはInvocation IDを新しい値へ変更するとともに、現在保持しているRID Poolを破棄します。
また、正常にレプリケーション可能な他の書き込み可能なDCが存在する場合、そのDCから非AuthoritativeなInbound Replicationを行うことで、Active Directoryの情報を他のDCと整合した状態へ収束させます。
Generation IDに対応したハイパーバイザーでは、スナップショットからの復元など、仮想マシンを過去の状態へ戻す可能性のある特定の操作が行われた際に、仮想マシンへ提供するGeneration IDを変更します。ゲストOS上のAD DSは、ハイパーバイザーから提供されるGeneration IDとAD DS内部に保存されているGeneration IDを比較することで、仮想マシンの状態が巻き戻された可能性を検知し、必要に応じてVirtualization SafeguardsによるSafe Restoreを実行します。
Nutanix AHVにおけるGeneration ID
AHVにおけるVM-Generation IDのサポートは、AOS 6.6.1から提供されています。
（参考）VM-Generation ID support on AHV
https://portal.nutanix.com/kb/14470
既存のvSphereなどの環境からNutanix Moveを利用してAHVへDCの仮想マシンを移行し、その際にVM-Generation IDが変更された場合、前述の通りVirtualization SafeguardsによるSafe Restoreが実行されます。
Safe RestoreによってAD DSの状態を他のDCと収束させるためには、正常にレプリケーション可能な他の書き込み可能なDCが存在することが重要です。また、Moveによる移行後にAD DSでトラブルが発生した場合、その原因としてはレプリケーション、DNS、SYSVOL、FSMOロールなど、さまざまな要因が考えられます。
このような問題は仮想マシンの移行だけではなく、Active Directoryそのものの設計や運用に関係する問題となります。
そのため、DCの移行についてはMoveによる仮想マシン単位の移行ではなく、新しいDCの追加、FSMOロールの移行、旧DCの降格など、Microsoftが公開しているAD DSの移行手順に沿って実施することが基本的な考え方となります。
Windows Server上でGeneration IDを確認する
Windows Server OS上で、ハイパーバイザーから提供されているVM-Generation IDを確認する方法の一例として、以下のPowerShellを実行します。
Add-Type @"
using System;
using System.Runtime.InteropServices;
using Microsoft.Win32.SafeHandles;
public class VmGenerationId
{
[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
static extern SafeFileHandle CreateFile(
string lpFileName,
uint dwDesiredAccess,
uint dwShareMode,
IntPtr lpSecurityAttributes,
uint dwCreationDisposition,
uint dwFlagsAndAttributes,
IntPtr hTemplateFile);
[DllImport("kernel32.dll", SetLastError = true)]
static extern bool DeviceIoControl(
SafeFileHandle hDevice,
uint dwIoControlCode,
IntPtr lpInBuffer,
uint nInBufferSize,
byte[] lpOutBuffer,
uint nOutBufferSize,
out uint lpBytesReturned,
IntPtr lpOverlapped);
public static string Get()
{
const uint GENERIC_READ = 0x80000000;
const uint GENERIC_WRITE = 0x40000000;
const uint FILE_SHARE_READ = 0x00000001;
const uint FILE_SHARE_WRITE = 0x00000002;
const uint OPEN_EXISTING = 3;
const uint IOCTL_VMGENCOUNTER_READ = 0x0032C004;
using (SafeFileHandle h = CreateFile(
@"\\.\VmGenerationCounter",
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
IntPtr.Zero,
OPEN_EXISTING,
0,
IntPtr.Zero))
{
if (h.IsInvalid)
throw new System.ComponentModel.Win32Exception(
Marshal.GetLastWin32Error());
byte[] buffer = new byte[16];
uint returned;
if (!DeviceIoControl(
h,
IOCTL_VMGENCOUNTER_READ,
IntPtr.Zero,
0,
buffer,
(uint)buffer.Length,
out returned,
IntPtr.Zero))
{
throw new System.ComponentModel.Win32Exception(
Marshal.GetLastWin32Error());
}
return new Guid(buffer).ToString();
}
}
}
"@
[VmGenerationId]::Get()Generation IDに対応した環境であれば、ハイパーバイザーからゲストOSへ提供されているVM-Generation IDを確認できます。
AHV側からGeneration IDを確認する
AHV側では、ACLIを使用して仮想マシンに設定されているGeneration IDを確認できます。
AHV環境では、仮想マシンに対してVM-Generation IDが提供されます。
通常の仮想マシン作成・運用では、Generation IDを利用者が意識して設定する必要はありません。一方、物理サーバー上で稼働しているDCをAHV環境へ移行する場合など、移行元と移行先におけるGeneration IDの取り扱いについて確認が必要となるケースがあります。
AHVでは、仮想マシンの作成時に `generation_uuid` を指定することができます。
1.Generation IDを指定した仮想マシンの作成
2. Generation IDの確認
`generation_uuid` は仮想マシン作成時に指定するパラメーターであり、既に作成済みの仮想マシンに対して任意のGeneration IDへ変更する用途では使用できません。
Generation IDを意図的に一致させる場合の注意点
AD DSは、AD DS内部に保存されているGeneration IDと、ハイパーバイザーから現在提供されているGeneration IDを比較します。
両者が異なっていた場合、AD DSは仮想マシンが以前の状態へ戻された可能性があると判断し、Virtualization SafeguardsによるSafe Restoreを実行します。この際、Invocation IDの再生成やRID Poolの破棄などが行われ、正常にレプリケーション可能な他の書き込み可能なDCとのレプリケーションによってActive Directoryの状態を収束させます。
一方、Generation IDが一致している場合、Generation IDの不一致を契機とするVirtualization Safeguardsは実行されません。
このため、DCをイメージバックアップなどから別の仮想マシンへ復元する際にGeneration IDを意図的に一致させた場合、Generation IDの不一致を契機とするVirtualization Safeguardsが発動しないことになります。
ただし、Generation IDを一致させること自体が、Active Directoryの整合性を保証するものではありません。
Active Directoryでは、Generation IDだけではなく、Invocation IDやUSNなどを使用して、複数のDC間でレプリケーション状態を管理しています。そのため、移行元DCと移行先DCを同時に稼働させたり、バックアップ取得後に他のDCとの間で変更が発生したりすると、Generation IDが同一であってもActive Directoryのレプリケーションに問題を生じさせる可能性があります。
このため、Generation IDを意図的に維持してDCを移行する方法を、一般的なActive Directoryの移行・復元方法として使用することは推奨されません。
DCをバックアップから復元する場合は、原則としてAD DSに対応したバックアップおよび復元方法を使用し、Generation IDによるVirtualization Safeguardsが適切に機能する構成とすることが重要です。
まとめ
ADの移行においてGeneration IDは重要な役割を果たしますが、Generation IDを一致させることだけでActive Directory全体の整合性が保証されるわけではありません。
Active Directoryは、Generation IDだけではなく、Invocation IDやUSNなどの情報を利用して、複数のDC間でレプリケーションの状態を管理しています。
そのため、移行対象以外のDCが稼働し、ユーザーやコンピューター、パスワードなどの変更を受け付けている場合、それらの変更を各DC間で適切にレプリケーションし、整合性を維持する必要があります。
また、Generation IDによるVirtualization Safeguardsは、AD DSのバックアップそのものを代替する仕組みではありません。
このようなActive Directory特有の仕組みがあることから、DCの移行については、原則としてMoveによる仮想マシン単位の移行ではなく、新しいDCの追加、FSMOロールの移行、旧DCの降格など、Microsoftが公開しているAD DSの移行手順に沿って実施することが推奨されます。
どうしてもMoveを利用してDCを移行する場合は、製品のサポート可否を確認したうえで、移行対象外のDCが正常に稼働していることや、DC間で正常にレプリケーションできる状態であることなどを事前に確認してください。また、Generation IDの仕組みだけでActive Directoryの整合性や移行の安全性が保証されるわけではないため、十分な検証とバックアップを行ったうえで、慎重に移行を実施してください。
0 件のコメント:
コメントを投稿