こんにちは。VMware グローバルサポート Newsletter 担当者です。
今回は、VMware NSX-T Data Center (以降、NSX-T)のバックアップとリストアに関する注意点についてです。
NSX-T に関してお問い合わせ頂く内容として、NSX-T のバックアップ方法に関するものがございます。
また、ストレージ障害等によって NSX Manager や NSX Edge が正常に動作しなくなったために、リストアを行う方法についてお問い合わせ頂くケースもございます。
そこで、本トピックでは、NSX-T におけるバックアップとリストアの方法や注意点についてご説明します。なお、本ケーススタディは NSX-T バージョン 3.1 を前提にしております。
１．NSX-T のバックアップ方法
NSX-T は、ファイルベースのバックアップをサポートしています。対応しているプロトコルは SFTP であるため、バックアップ用ファイルサーバとして、SFTP サーバが必要になります。
以下が、SFTP サーバとしてサポートされている OS 並びにテスト済のバージョンです。こちらを参考に SFTP サーバをご用意下さい。
| 現在サポートされている OS | テスト済みのバージョン | SFTP ソフトウェアのバージョン |
| CentOS | 7.7 | OpenSSH_7.4p1 |
| RHEL | 7.7 | OpenSSH_7.4p1 |
| Ubuntu | 18.04 | OpenSSH_7.6p1 |
| Windows | Windows Server 2019 Standard | OpenSSH_for_Windows_7.7p1 |
SFTP サーバの準備ができましたら、以下のドキュメントに記載されている手順に従ってバックアップの設定を行います。
NSX-T のバックアップを行う際は、VMware vSphere など NSX-T と連携している他の製品についても同時にバックアップを行うことを推奨しております。
バックアップを取得したタイミングが異なる場合、NSX-T のバックアップデータと連携している他の製品のデータの間に不整合が生じ、リストアした際に予期せぬ問題が発生する可能性がございます。
Windows Server を SFTP サーバとして使用する際の注意点
Windows Server を SFTP サーバとして使用されている環境において、よくお問い合わせ頂く事例についてご紹介します。
１．バックアップ実行時にエラーが発生する
「次のいずれかです: 1. ディレクトリ パスが無効である、2. SFTP サーバのディスクに空き容量がない。」というエラーメッセージとともに、バックアップに失敗するという事例がございます。
エラーメッセージに記載の通り、無効なディレクトリパスが指定されている、または SFTP サーバの空き容量がないことが原因である場合もございますが、それ以外に Windows におけるパスの最大長の制限が原因であるケースがございます。
Windows にはパスの長さは最大 260 文字という制限がございます。NSX-T のバックアップファイルの名前には UUID やバックアップ日時等が含まれているため、構成にもよりますが、自動で付与されるディレクトリ名とファイル名合計で 200 文字以上になる場合もあります。結果として最大 260 文字を超えた場合にはこの制限に該当しバックアップに失敗いたします。
この事象に対する対処法は、Windows ではなく Linux の SFTP サーバをご使用いただくか、Windows の設定で長いパスを有効化する方法になります。
長いパスを有効化する方法につきましては、以下の Microsoft 社のドキュメントをご参照ください。
パスの最大長の制限
https://docs.microsoft.com/ja-jp/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd
２．C ドライブ以外のフォルダにバックアップを保存する
D ドライブなど、C ドライブ以外の場所にバックアップ先となるフォルダが存在する場合に、ディレクトリパスの指定方法についてご質問頂くケースがございます。
NSX-T では、ディレクトリパスの名前に、ドライブ文字やスペースはサポートされていないため、C ドライブ以外の場所にあるフォルダについて直接指定することができません。
この場合、mklink コマンドを使用して C ドライブ上にバックアップ先となるフォルダへのシンボリックリンクを作成することで、シンボリックリンクを通して C ドライブ以外の場所にバックアップすることができます。
参考までに、「D:\backup」に NSX-T のバックアップを保存する手順を記載します。
A.管理者権限でコマンドプロンプトを起動します。
B.以下のコマンドを実行して、C ドライブ上に「D:\backup」へのシンボリックリンクを作成します。
> mklink /D C:\backup D:\backup
C.NSX-T のバックアップ設定において、「/backup」をディレクトリパスに指定します。
２．NSX-T のリストア方法について
NSX-T において障害が発生した場合、障害が発生した範囲に応じて復旧させる方法が異なります。ここでは、以下の 4 つの場合に分けてご説明いたします。
１．1 台の NSX Manager に障害が発生した場合
1 台の NSX Manager で障害が発生し、残り 2 台の NSX Manager が正常に動作している場合、バックアップデータを使用してリストアする必要はありません。
[システム] > [アプライアンス] から障害が発生した NSX Manager を削除し再デプロイすることで復旧させることができます。
なお、 NSX-T のユーザーインターフェイス操作ではなく OVA から NSX Manager 仮想マシンをデプロイした場合、 NSX-T の[システム] > [アプライアンス] から削除することができません。その場合は、正常に動作している NSX Manager 上で “detach node <障害が発生した NSX Manager のノード ID>” コマンドを実行して、手動で障害が発生した NSX Manager を接続解除し、NSX Manager 仮想マシンを vCenter のインベントリ上から削除します。NSX Manager のノード ID は、”get nodes” コマンドで確認できます。
２．2 台以上の NSX Manager に障害が発生した場合
2 台以上の NSX Manager で発生した場合は、以下のドキュメントに従って、新しい NSX Manager 仮想マシンをデプロイし、バックアップデータからリストアを行います。
もし、1 台のみ NSX Manager が正常に動作している状況で、有効なバックアップデータが無い場合、弊社サポート窓口までお問い合わせください。
以下の KB に記載の通り、バックアップデータからリストアする方法が公式にサポートされる手順ではございますが、残存している NSX Manager からクラスタを復旧することができる場合がございます。
Recovering an NSX-T cluster that has lost 2 nodes (74518)
https://kb.vmware.com/s/article/74518
３．NSX Edge に障害が発生した場合
NSX Edge に障害が発生した場合は、新しい Edge 仮想マシンをデプロイして、障害が発生した Edge を置き換える処理を行うことで復旧させます。
ユーザーインターフェイスから置き換える方法と API を使用して置き換える方法の 2 種類がございます。詳細な手順につきましては、以下のドキュメントをご参照ください。
NSX Edge クラスタでの NSX Edge トランスポート ノードの置き換え
https://docs.vmware.com/jp/VMware-NSX-T-Data-Center/3.1/administration/GUID-7CE8615E-37D3-4AF7-ACBF-FA373EF7A037.html
４．NSX をインストールした ESXi ホストに障害が発生した場合
NSX をインストールした ESXi ホストに障害が発生した場合は、vSphere 観点で復旧を試みます。NSX Manager との接続が正常に復旧しない場合は、トランスポートノードとして削除を行い、NSX を新規インストールします。アンインストールの詳細な手順は、以下のドキュメントをご参照ください。
vSphere クラスタ内のホストからの NSX-T Data Center のアンインストール
https://docs.vmware.com/jp/VMware-NSX-T-Data-Center/3.1/installation/GUID-52FA28CD-CB47-46C6-9D7B-F006916E3C87.html
新規インストールの際には、構築時に利用した手順などでのインストールをお願い致します。
３．終わりに
NSX-T の バックアップとリストアについて事例を交えて注意点をご紹介しましたが、 通常の運用では実施しない操作を SFTP サーバや vSphere 構成、物理ネットワーク構成を組み合わせた環境で実施するため、想定外の要因による問題が発生することもあります。いざという時に円滑に業務を回復できるよう、定期的なバックアップ取得とお客様環境でのリストア手順の検証による確認により、不測の障害に備えていただくことをお勧めいたします。
