NutaNice Xperience

主にNutanix製品を検証したり触ったりした結果をつづっています。※このブログの内容は個人の見識や見解をもとに作成しています。参考にされる場合は自己責任でご活用ください。実際に製品を使用される場合は、メーカードキュメントの手順に従い実施してください。

Nutanix File Analytics の監査データ保持期間（v3.3.0時点）

Nutanix Filesのデータ分析や監査データの確認ツールとして使用可能な「File Analytics」の監査データ保持期間は最大1年間です。（v3.3.0時点）

1年間を超えるデータは、欲しいデータをCSVで定期的にエクスポートして保存するといった事を検討する必要があります。

以上。

 

Nutanix Moveで仮想マシンをAHVからAWS EC2へ移行してみる

AHV AOS AWS Nutanix Move

今回はNutanix AHV上の仮想マシンをAWS EC2へ移行してみます。

目次

今回の環境

4ノードのNutanix AHVクラスター
プラットフォーム: NX-1465-G5
AOS: 6.5.3.5 LTS
Move: 4.9.1
移行対象VM: Windows Server 2019

今回の作業イメージは以下の通りです。

1. 移行対象のVMに対する事前準備

仮想マシンをAWSへ移行するためにはいくつかの要件や事前準備項目があります。ドキュメントから抜粋したものを以下に示しました。（Move 4.9.1時点）

  • サポートされるOS
  • WinRM, RDP, SSH を有効化（Windowsの場合）
  • Nutanix Guest Tools（NGT）をインストール

※要件や制限事項の詳細は以下リンク先をご確認ください。
▽Migration Considerations
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v4_9:top-migration-considerations-ahv-aws-c.html

2. AWS側の準備

AWS EC側では、リージョンやアベイラビリティゾーン、移行先のネットワーク（VPC）などを事前に準備しておく必要があります。また、Moveへの環境登録時にはAWSアカウントの「アクセスキー ID」と「シークレットアクセスキー」が必要となります。

MoveからAWSに対して操作を実行しますので、登録時に使用するAWSアカウントには、IAMにて特定の権限（許可）を持たせておく必要があります。

多くの場合、管理者権限を持つアカウントであれば対応できるかと思いますが、Moveのドキュメントでは許可ポリシーで必要な権限のリストがJSONで公開されていますので、必要に応じてAWSユーザーに権限を持たせておきます。

▽許可ポリシー作成の画面

Nutanixで公開されているJSONは以下をご参照ください。
▽Requirements (AHV to AWS)
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v4_9:top-requirements-ahv-aws-r.html

3. Move VMのデプロイ

Nutanix Moveは仮想アプライアンスとして提供されており、移行元のAHVクラスター上に仮想マシンとしてデプロイして使用します。

Moveのデプロイ方法については以下記事をご参照ください。
Nutanix MoveをAHVへデプロイしてみる（Prism GUI編） - NutaNice Xperience

4. Moveへの環境登録

デプロイしたMoveのWebコンソール画面から移行元AHVと移行先AWSを登録します。

AHV環境の登録方法は以下記事をご参照ください。
MoveでのAHV環境の登録

AWS環境の登録方法は以下記事をご参照ください。
MoveでAWS環境の登録

5. 移行プランの作成

環境の登録ができたら移行プランを作成します。
▽Moveコンソールにて「Create a Migraton Plan」をクリックします。

▽移行プランに名前を付けて「Proceed」をクリックします。

▽以下のように設定していきます。

▽続いて移行対象の仮想マシンを選択します。今回は「MovetoAWS」という名前のWindows Server2019仮想マシンを選択しました。ちなみに、NGTが対象のVMにインストールされていない場合、この時点で仮想マシンを選択できない仕様となります。

▽次の画面で移行元AHVネットワークと移行先AWSネットワーク設定をします。移行先のAWSでは、ネットワークとサブネット、セキュリティグループを選択します。

▽続いて準備モードで今回は「Automatic」を選択します。

▽Windowsの管理者権限のあるアカウントのID／PWを入力します。※複数の仮想マシンでID／PWが異なる場合は「Change settings」から個別に入力することも可能です。

▽今回はプライオリティを「Medium」に設定します。AWS移行後にパブリックIPアドレスを持たせたい場合は「Create Public IP Address」にチェックを入れます。ちなみに「Schedule Data Seeding」では、移行対象の仮想マシンスナップショットのレプリケーションを開始する日時を指定することができます。

▽サマリ画面で設定内容を確認したら「Save and Start」でプランを実行します。すぐに実行したくない場合は「Save」でプランの保存のみも可能です。

6. Seeding（レプリケーション）の実行

▽プランが検証されて、実行に移ると「In Progress」と表示されますので、「In Progress」をクリックしてタスクの実行状況を追跡します。

▽Moveコンソールでは、対象VMのスナップショットが取得され、AWSへレプリケーションされている様子が確認できます。また、AWS EC2のEBSにてレプリケーションされたスナップショットも確認できます。「移行」を実行するまで、最新のスナップショットがデフォルト10分間隔でレプリケーションされ続ける仕組みとなります。

7. Cutover（移行）の実行

移行先に仮想マシンを切り替えたいというタイミングで「Cutover」というボタンをクリックします。「Cutover」を実行すると、移行元の仮想マシンが停止して最後のスナップショットがレプリケーションされたのち、移行先のAWS EC2でインスタンスが作成されます。

リモートデスクトップで接続したところ、移行したWindowsにログインできました。

ちなみに、移行元の仮想マシンは停止しているだけですので、何かの事情で移行元の仮想マシンが必要となった場合はそのまま電源を入れて使用できます。

その他ナレッジ

AWS認証エラーについて

AWS環境の登録時や、移行プランの作成・検証でMoveがAWSにアクセスしているタイミングで以下のようなエラー画面が何度も出てきました。

AWS GetRegionNames failed with error: AuthFailure:~~~~~~~~~

AWSへのアクセス認証に失敗しており、提供されたアクセス情報を検証できないというエラーです。私の場合は、何度も再実行すると、認証が通ったりしましたので、何らかの原因で不安定な状態になっていたのかもしれません。

もし許可ポリシーなども正しく設定しているのに、認証エラーになるといった、同様の事象に遭遇している方がいれば参考にしてみてください。

サポート外のOSについて

Move 4.9.1時点で、ドキュメント上Windows Server 2022はサポート対象外ですが、実際に移行できるのかやってみたところ、移行プラン作成後にサポート対象外としてエラーとなりました。（※自動準備モードでエラーとなるなら、手動モードでスクリプトを準備すればいけるのかもですが...。）

Windows Server 2022はMoveの現行バージョンでは移行できませんので、将来バージョンのリリースを待つか、別の方法を考える必要があります。

移行後のAWSインスタンスタイプについて

移行元AHVでの仮想マシンのvCPUやメモリサイズに応じて、移行先AWSではどのインスタンスタイプが選択されるのかを3パターンに分けて検証したところ以下のようになりました。

移行後のOS側からも、インスタンスタイプ通りのリソースが確認できます。

上記の事から、移行元のvCPU、メモリサイズをカバーするようにAWS EC2側でインスタンスタイプが自動選択されていることが分かります。（移行元よりもリソースが少ないという状態にはならない。）

終わりに

今回はNutanix AHV上の仮想マシンをAWS EC2上へ移行する方法を紹介しました。このようにMoveではパブリッククラウドにも仮想マシンを移行することができますので、皆様の今後のハイブリッド・マルチクラウド戦略にぜひご活用いただければと思います。

<参考>
Move User Guide Ver 4.9.1 > AHV to AWS
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v4_9:top-ahv-to-aws-vm-migration-c.html

HYCU Backup Controllerをアップグレードしてみる【Nutanix AHV】

AHV HYCU アップグレード

この記事では、Nutanix AHV環境における、HYCU Backup Controllerのアップグレード方法を紹介します。

目次

今回の環境

AOS: 6.5.3.5 LTS
AHV: 20220304.420
HYCU Backup Controller 更新前: 4.7.1-183
HYCU Backup Controller 更新後: 4.8.0-3273

今回の作業イメージは以下の通りです。

ちなみに既存のHYCUバージョンは以下の通りです。今回は、このHYCUをアップグレードします。

HYCU Backup Controllerのアップグレード

▽はじめに、Nutanix AHV環境のPrism Webコンソールへログインし「イメージ設定」画面で、HYCUの新しいOSディスクイメージファイルをアップロードします。ディスクイメージファイルはHYCUのポータルサイトからダウンロードしてください。一点注意点ですが、イメージファイル名はアップロードするHYCUのバージョン名と必ず同じになるように名前を付けてください。（名前を間違えるとアップグレードに使えません）

イメージサービスへのアップロード方法は以下ドキュメントを参照ください。
https://portal.nutanix.com/page/documents/details?targetId=Web-Console-Guide-Prism-v6_5:wc-image-configure-acropolis-wc-t.html

https://download.hycu.com/ec/v4.7.1/help/ja/HYCU_UserGuide.pdf#page=23

▽続いてHYCUコンソールへログインし「電源オプション」画面を起動します。

▽「電源オプション」画面にて「すべて一時停止」を選択して「Save」をクリックします。これによって、バックアップポリシーでスケジュールされているジョブなどのアクティビティがすべて停止します。※すでに実行中のジョブはそのまま終わるまで実行されます。

▽アクティビティが停止されると以下のようにHYCUコンソールに表示されます。※すでに実行中のジョブについてはジョブ画面にて完了しているかご確認ください。

▽ここまできたら、HYCUコンソールにて「ソフトウェアのアップグレード」を起動します。

▽「ソフトウェアのアップグレード」画面の「利用可能なバージョン」に、イメージサービスで事前アップロード済みのHYCUのディスクイメージが選択できるようになっていますので、対象のイメージを選択して「ソフトウェアのアップグレード」をクリックします。

▽最終確認のダイアログにて「はい」をクリックします。

▽アップグレードが開始されるとHYCUのコンソールから自動ログアウトされ、以下のような画面表示になります。

▽アップグレードが実行されると、新ディスクイメージファイルをもとに新しいHYCU Backup Controllerが作成され、旧 Backup ControllerのデータディスクやIPアドレスなどを引き継ぎます。アップグレード後も旧 Backup Controllerは停止状態で残ります。

▽アップグレード完了後、HYCUのWebコンソールにログインします。

▽アップグレード後のHYCUもアクティビティが停止状態になっていますので「電源オプション」を起動します。

▽「再開」を選択して「Save」をクリックします。

▽アクティビティが再開されたことが確認できます。

▽HYCUも対象のバージョンにアップグレードされていることが確認できました。

※停止済みの旧Backup Controllerも不要でしたら様子を見て削除します。

おわりに

今回はHYCU Backup Controllerのアップグレード方法を紹介しました。ちなみに、セキュリティパッチなどの修正プログラムのアップデートについては、少しやり方が異なるので、また別の機会に紹介できればと思います。

▽参考
HYCUのアップグレード
https://download.hycu.com/ec/v4.7.1/help/ja/HYCU_UserGuide.pdf#page=238

HYCUのバックアップポリシーにおける「アーカイブ」とは【Nutanix AHV】

HYCU Nutanix

前回の記事では、Nutanix AHVにおけるHYCUの「Backup From Replica」について紹介しました。今回は「アーカイブ」について紹介します。

HYCUの「アーカイブ」の紹介

HYCUでは以下のように「アーカイブ」というバックアップオプションが提供されています。

このオプションは、メーカードキュメントでは以下のように紹介されています。

<アーカイブ>
長期保管目的でデータを保存できます。

<引用元>
HYCUユーザーガイド > カスタムポリシーの作成
https://download.hycu.com/ec/v4.7.1/help/ja/HYCU_UserGuide.pdf#page=59

長期保管目的ということが分かりましたが、実際どのように使うのか触ってみました。アーカイブのターゲットは色々と選べるのですが、パブリッククラウドのオブジェクトストレージが主なターゲットになるかと思います。構成例は以下の通りです。

▽1つ目の例としては、HYCUで外部にバックアップを取りつつ、クラウドのオブジェクトストレージにも長期保管目的でアーカイブを保管するというものです。監査対応など長期保管が必要なデータなどがある場合に、バックアップとアーカイブをうまく使い分けて利用するといったイメージです。

▽2つ目の例として、外部バックアップを取得せずに、ローカルスナップショットから直接クラウドストレージへアーカイブをすることも可能です。これは外部に物理的なバックアップ環境を持ちたくないが、長期保管が必要なデータがあるといったケースで使えそうですね。

ちなみにアーカイブから仮想マシンをリストアすることも可能となります。

バックアップとアーカイブの違い

アーカイブが長期保管目的の機能ということは分かりましたが、結局通常のバックアップと何が違うの？と感じる方もいらっしゃると思います。

これは筆者の見解ですが、アーカイブでは、通常のバックアップポリシーのスケジュールとは別で、独自のアーカイブスケジュールをターゲットに対して設定できることがポイントになるかと思います。

イメージとしては以下のような感じです。

▽画面で見ると、通常のバックアップスケジュールは以下のように、ポリシー画面で設定します。

▽それに対して、アーカイブのスケジュールは、別途設定画面があり、以下のようにアーカイブ先となるターゲットを指定して個別に設定することになります。

▽ターゲットを含むアーカイブスケジュールを作成したら、設定したアーカイブ名をポリシー画面で指定するといった具合です。

ちなみに、これまでの記事で説明してきた「Fast Restore」や「コピー」、「Backup From Replica」などでは、バックアップポリシーとは別にスケージュール（バックアップ頻度）を設定することはできません。

そういった意味でも、アーカイブは通常のバックアップとは別にアーカイブ独自のスケジュールを設定して長期保管を取得する、といった使い分けができるようにHYCUでは設計されているものだとお考えいただくとよさそうです。

以上、今回は「アーカイブ」の紹介でした。

HYCUのバックアップポリシーにおける「Backup From Replica」とは【Nutanix AHV】

HYCU Nutanix

※このブログの内容は個人の見識や見解をもとに作成しています。参考にされる場合は自己責任でご活用ください。また、このブログで紹介している製品や機能を実際に使用される場合は、メーカードキュメントの手順に従い実施することを推奨します。

前回の記事で、Nutanix AHVにおけるHYCUの「コピー」について紹介しました。今回は「Backup From Replica」について紹介します。

HYCUでは以下のように「Backup From Replica」というバックアップオプションが提供されています。

このオプションは、メーカードキュメントでは以下のように紹介されています。

<Backup from replica>
Nutanixクラスターにのみ使用できます。リモートオフィス/ブランチオフィス( ROBO) 環境のレプリカから仮想マシンおよびボリュームグループをバックアップできます。
<引用元>
HYCUユーザーガイド > カスタムポリシーの作成
https://download.hycu.com/ec/v4.7.1/help/ja/HYCU_UserGuide.pdf#page=60

[BACKUP FROM REPLICA]
Nutanix 保護ドメインを活用し、Nutanix リモートクラスタ上のVM からバックアップをする場合、ローカルにレプリケートされたレプリカからバックアップを実行します。 
<引用元>
HYCU 簡易手順書 > ポリシー設定
https://download.hycu.com/docs/misc/downloadarea/HYCU/release/4.8.0/JPN/Evaluation_guide_for_vm_v4.8.0.pdf#page=35

これをはじめに読んだときに、リモートのVMからのバックアップってどういう意味？と思ったのですが、色々調べてみたところ以下のように理解しました。

つまり、プライマリサイトでもリモート拠点でも表現は何でもよいが、Nutanixの本番環境のクラスターから、Async DRで別のNutanixクラスターへレプリケーションされてきた仮想マシンなどのスナップショットを用いて別のターゲットにさらにバックアップを取得するということです。レプリケーションされてきたレプリカからバックアップを取得するので、Backup From Replicaと呼ばれるのですね。この場合、HYCU Backup Controllerはレプリケーション先のクラスター上に存在することになります。

NutanixのAsync DRではレプリケーション先のクラスターの事をリモートサイトと呼ぶ傾向があるので、レプリケーション元の環境をHYCUでリモート拠点と表現されてしまうと、少し混乱してしまう方もいらっしゃるのではないかと思います。

ちなみにこの機能ですが、HYCUの管理下でプライマリサイトでもリモートサイトでも自由なところに仮想マシンをリストアできるといった特長もあります。

HYCUがリモート拠点やROBO環境からのバックアップと呼んでいることからも、この機能は複数拠点からのレプリケーションを想定している機能であるとも考えられそうです。

例えば以下のようなイメージです。

このように、複数拠点からレプリケーションされたスナップショットを一か所に集約し、HYCUでさらに外部バックアップを取りつつ、DRリストアも管理するといったような、HYCUによるバックアップDRの統合管理的な側面をもった機能としても使えそうですね。これはあくまで筆者の見解ではありますが、いづれにせよ少し規模大きめの環境に適用できそうな気がしました。

以上、今回はBackup From Replicaの紹介でした。

次回は「アーカイブ」について書いてみたいと思います。

HYCUのバックアップポリシーにおける「コピー」とは【Nutanix AHV】

AHV HYCU Nutanix

※このブログの内容は個人の見識や見解をもとに作成しています。参考にされる場合は自己責任でご活用ください。また、このブログで紹介している製品や機能を実際に使用される場合は、メーカードキュメントの手順に従い実施することを推奨します。

以前の記事で、Nutanix AHVにおけるHYCUの「FAST RESTORE」について紹介しました。今回は「コピー」について紹介します。

HYCUでは以下のように「コピー」というバックアップオプションが提供されています。

大体想像がつくかもしれませんが、このコピーというオプションは1次バックアップ先から、さらに別のターゲットとなるファイルサーバーなどにバックアップデータをコピー転送できる機能です。

▽実際に設定する際は、HYCUのBackup Controllerに最低2つのターゲットを登録します。

▽そしてポリシー画面にて、コピー先を指定するイメージです。

▽仮想マシンにポリシーを割り当てて、ポリシーが実行されると、復旧ポイントやジョブレポートからコピーが実行されていることが分かります。

今回はこの辺で。

次回: HYCUのバックアップポリシーにおける「Backup From Replica」とは