同じハードウェアで Azure Local に移行する

2025-07-07

適用対象: Azure Local 2311.2 以降。Azure Stack HCI バージョン 22H2;Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2008 R2

重要

Azure Stack HCI が Azure Local の一部になりました。ただし、古いバージョンの Azure Stack HCI (22H2 など) は引き続き Azure Stack HCI を参照し、名前の変更は反映されません。詳細情報。

このトピックでは、既存のマシンハードウェアを使用して Windows Server フェールオーバークラスターを Azure Local に移行する方法について説明します。このプロセスにより、Azure Local 用の新しいオペレーティングシステムがインストールされ、既存のシステム設定とストレージが保持され、仮想マシン (VM) がインポートされます。

次の図は、同じコンピューターハードウェアを使用して Windows Server クラスターをインプレースで移行する方法を示しています。システムをシャットダウンすると、Azure Local がインストールされ、ストレージが再アタッチされ、VM がインポートされ、高可用性 (HA) になります。

VM を新しい Azure Local ハードウェアに移行するには、「新しいハードウェアで Azure Local に移行するを参照してください。

注

この記事では、ストレッチクラスターの移行については取り扱っていません。

開始する前に

移行を始める前に、要件と考慮事項がいくつかあります。

すべての Windows PowerShell コマンドは、管理者として実行する必要があります。
Azure Local の管理者アクセス許可を持つドメイン資格情報が必要です。
ソースシステム上のすべての VM をバックアップします。すべてのアプリケーションとデータのクラッシュ整合バックアップ、およびすべてのデータベースのアプリケーション整合バックアップを完了します。 Azure にバックアップするには、「 Azure Backup の使用」を参照してください。
すべてのマシンとシステムの名前付け、ネットワーク構成、クラスター共有ボリューム (CSV) の回復性と容量、クォーラム監視のインベントリと構成を収集します。
システム VM、オフライン CSV、オフライン記憶域プール、およびシステムサービスをシャットダウンします。
クラスター名オブジェクト (CNO) を無効にします (後で再利用されます)。
- CNO に、その組織単位 (OU) に対するオブジェクトの作成権限が付与されていることを確認します
- OU でブロック継承ポリシーが設定されていることを確認する
- この OU で Azure Local に必要なポリシーを設定する

VM のバージョンのサポートと更新

同じハードウェア上のインプレース移行でサポートされている Windows Server OS バージョンとその VM バージョンを次の表に示します。

VM が実行されている OS バージョンに関係なく、Azure Local への移行でサポートされる VM の最小バージョンはバージョン 5.0 です。そのため、Windows Server 2016 以降のシステムでバージョン 2.0、3.0、または 4.0 で実行されている VM は、移行前にバージョン 5.0 に更新する必要があります。

OS バージョン	VM バージョン
Windows Server 2008 SP1	2.0
Windows Server 2008 R2	3.0
Windows Server 2012	4.0
Windows Server 2012 R2	5.0
Windows Server 2016	8.0
Windows Server 2019	9.0
Windows Server 2022
Azure ローカル	9.0

Windows Server 2008 SP1、Windows Server 2008 R2-SP1、および Windows 2012 システム上の VM の場合、Azure Local への直接移行はサポートされていません。このような場合は、次の 2 つのオプションがあります。

最初にこれらの VM を Windows Server 2012 R2 以降に移行し、VM のバージョンを更新してから、移行プロセスを開始します。
Robocopy を使用して、すべての VM VHD を Azure Local にコピーします。次に、新しい VM を作成し、コピーした VHD を Azure Local 内のそれぞれの VM にアタッチします。こうすることで、このような古い VM に対する VM バージョンの制限が回避されます。

VM バージョンの更新

1 つのノード上のすべての VM バージョンを表示するには、次のコマンドを使用します。

Get-VM * | Format-Table Name,Version

Windows Server クラスター上のすべてのノードのすべての VM バージョンを表示するには:

Get-VM –ComputerName (Get-ClusterNode)

すべての Windows Server ノード上のすべての VM を最新バージョンに更新するには:

Get-VM –ComputerName (Get-ClusterNode) | Update-VMVersion -Force

マシンとシステムの更新

移行は、お使いの VM とストレージをそのまま使用してクリーン OS インストールを行う Windows Server デプロイで Azure ローカルセットアップを実行して構成されます。これにより、現在のオペレーティングシステムが Azure Local に置き換えられます。詳細については、「 Azure Local 用 OS のデプロイ」を参照してください。その後、新しい Azure ローカルインスタンスを作成し、ストレージを再アタッチして VM をインポートします。

既存のシステム VM、オフライン CSV、オフライン記憶域プール、およびシステムサービスをシャットダウンします。
Azure ローカルビットをダウンロードした場所に移動し、各 Windows Server ノードで Azure ローカルセットアップを実行します。
セットアップ中に、カスタム: Azure Local の新しいバージョンのみをインストールする (詳細設定) を選択します。各サーバーに対してこの手順を繰り返します。
新しい Azure ローカルインスタンスを作成します。次のセクションに示すように、このタスクには Windows Admin Center または Windows PowerShell を使用できます。

重要

Hyper-V 仮想スイッチ (VMSwitch) 名は、システム構成インベントリでキャプチャされた同じ名前である必要があります。 VM をインポートする前に、Azure Local インスタンスで使用される仮想スイッチ名が元のソース仮想スイッチ名と一致していることを確認します。

注

新しい VM を作成する前に、Azure ローカルインスタンスを Azure に登録する必要があります。詳細については、Azure への登録に関するページを参照してください。

Windows Admin Center を使用する

Windows Admin Center を使用して Azure ローカルインスタンスを作成する場合、クラスターの作成ウィザードでは、必要なすべての役割と機能が各マシンに自動的にインストールされます。

システムを作成する方法の詳細については、「 Windows Admin Center を使用して Azure ローカルインスタンスを作成するを参照してください。

重要

システムの作成ウィザードの手順 4.1 ドライブのクリーンアップ をスキップします。それ以外の場合は、既存の VM とストレージを削除します。

クラスターの作成ウィザードを開始します。. Step 4: Storage にアクセスすると:
ステップ [4.1 Clean drives]$4.1 ドライブのクリーニング$ をスキップします。この操作は行わないでください。
ウィザードから離れます。
PowerShell を開き、次のコマンドレットを実行して新しい Storagesubsystem Object ID を作成し、すべての記憶域エンクロージャを再検出し、SES ドライブ番号を割り当てます。
```
Enable-ClusterS2D -Verbose
```
Windows Server 2016 から移行する場合、これにより新しい ClusterperformanceHistory ReFS ボリュームも作成され、SDDC クラスターリソースグループに割り当てられます。

Windows Server 2019 から移行する場合、これにより既存の ClusterperformanceHistory ReFS ボリュームも追加され、SDDC クラスターリソースグループに割り当てられます。
ウィザードに戻ります。ステップ [4.2 Verify drives]$4.2 ドライブの確認$で、すべてのドライブがアラートやエラーなしで一覧表示されていることを確認します。
ウィザードを完了します。

Windows PowerShell を使用する

PowerShell を使用して Azure Local インスタンスを作成する場合は、このコマンドレットを使用して、各 Azure ローカルコンピューターに次のロールと機能をインストールする必要があります。

Install-WindowsFeature -Name Hyper-V, Failover-Clustering, FS-Data-Deduplication, Bitlocker, Data-Center-Bridging, RSAT-AD-PowerShell -IncludeAllSubFeature -IncludeManagementTools -Verbose

PowerShell を使用してシステムを作成する方法の詳細については、「 Windows PowerShell を使用して Azure ローカルインスタンスを作成するを参照してください。

注

以前に無効にしたクラスター名オブジェクトに同じ名前を再利用します。

コマンドレットを実行してシステムを作成します。

New-cluster –name "systemname" –server Server01,Server02 –staticaddress xx.xx.xx.xx –nostorage

コマンドレットを実行して新しい Storagesubsystem Object ID を作成し、すべてのストレージエンクロージャを再検出し、SES ドライブ番号を割り当てます。
```
Enable-ClusterS2D -Verbose
```
Windows Server 2016 から移行する場合、これにより新しい ClusterperformanceHistory ReFS ボリュームも作成され、SDDC クラスターリソースグループに割り当てられます。

注

記憶域プールに少数ディスクエラー (クラスターマネージャーで表示可能) が表示されている場合は、Enable-ClusterS2D -verbose コマンドレットを再実行します。
クラスターマネージャーを使用して、ReFS ボリュームである ClusterperformanceHistory ボリュームを除くすべての CSV を有効にします (これが ReFS CSV ではないことを確認してください)。
Windows Server 2019 から移行する場合は、Enable-ClusterS2D -verbose コマンドレットを再実行します。これにより、 ClusterperformanceHistory ReFS ボリュームが SDDC クラスターリソースグループに関連付けられます。
コマンドレットを実行して、現在の記憶域プールの名前とバージョンを確認します。
```
Get-StoragePool | ? IsPrimordial -eq $false | ft FriendlyName,Version
```
次に、新しい記憶域プールの名前とバージョンを確認します。
```
Get-StoragePool | ? IsPrimordial -eq $false | ft FriendlyName,Version
```
クォーラム監視を作成します。方法については、「システム監視を設定する」を参照してください。
次のコマンドレットを使用して、ストレージ修復ジョブが完了したことを確認します。
```
Get-StorageJob
```
注

アップグレード中に実行される VM の数によっては、かなりの時間がかかることがあります。
すべてのディスクが正常であることを確認します。
```
Get-VirtualDisk
```
ClusterFunctionalLevelとClusterUpgradeVersionを表示するマシンのバージョンを決定します。コマンドレットを実行してこれを取得します。
```
Get-ClusterNodeSupportedVersion
```
注

ClusterFunctionalLevel は自動的に 10 に設定され、オペレーティングシステムとクラスターの新規作成のために更新する必要はありません。
記憶域プールを次のように更新します。
```
Get-StoragePool | Update-StoragePool
```

ReFS ボリューム

Windows Server 2016 から移行する場合、Resilient File System (ReFS) ボリュームがサポートされますが、このようなボリュームでは、ミラーアクセラレータパリティ (MAP) ボリュームを使用した Azure Local でのパフォーマンスの向上のメリットはありません。この機能強化には、PowerShell の New-Volume コマンドレットを使用して作成する新しい ReFS ボリュームが必要です。

Windows Server 2016 MAP ボリュームの場合、ReFS 圧縮は使用できなかったため、これらのボリュームの再アタッチは問題ありませんが、Azure ローカルインスタンスに新しい MAP ボリュームを作成する場合と比べてパフォーマンスは低下します。

VM をインポートする

ベストプラクティスは、マシンごとに少なくとも 1 つのクラスター共有ボリューム (CSV) を作成して、VM ワークロードの回復性、パフォーマンス、スケールを向上させるために、CSV 所有者ごとに VM の均等なバランスを確保することです。既定では、この残高は 5 分ごとに自動的に発生するため、移行元と移行先のマシンの間で Robocopy を使用して、ソースと宛先の CSV 所有者が一致するようにして、最適な転送パスと速度を提供する場合に考慮する必要があります。

Azure Local インスタンスで次の手順を実行して、VM をインポートし、高可用性を実現し、起動します。

コマンドレットを実行して、すべての CSV 所有者ノードを表示します。
```
Get-ClusterSharedVolume
```
各マシンについて、 C:\Clusterstorage\Volume に移動し、 C:\Clusterstorage\volume01など、すべての VM のパスを設定します。
各 CSV 所有者マシンでコマンドレットを実行し、VM のインポート前にボリュームごとにすべての VMCX ファイルへのパスを表示します。環境に合わせてパスを変更します。
```
Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vmcx" -Recurse
```
各マシンのコマンドレットを実行して、すべての VM をインポートして登録し、各 CSV 所有者ノードで高可用性を実現します。これにより、プロセッサとメモリの割り当てが最適になるように VM が均等に分散されます。
```
Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vmcx" -Recurse | Import-VM -Register | Get-VM | Add-ClusterVirtualMachineRole
```
各マシンで各宛先 VM を起動します。
```
Start-VM -Name
```
ログインし、すべての VM が実行されていること、およびすべてのアプリとデータが存在することを確認します。
```
Get-VM -ComputerName Server01 | Where-Object {$_.State -eq 'Running'}
```
最後に、すべての進歩を活用するために、VM を最新の Azure ローカルバージョンに更新します。
```
Get-VM | Update-VMVersion -Force
```

次のステップ

移行後にシステムを検証します。 Azure ローカルインスタンス検証するを参照してください。
Windows Server VM を新しい Azure ローカルハードウェアに移行するには、「新しいハードウェアで Azure Local に移行するを参照してください。