2025年12月22日月曜日

NutanixObjectsとHYCUを用いたイミュータブルなバックアップソリューション

 Nutanix Advent Calendar 2025 22日目の記事になります。
 ※諸事情あり、当初担当していた
13日目の記事と交代させていただきました<(_ _)>shadowhatさん、感謝します。

Nutanix Advent Calendar 2025 

今回は私のブログでも何度か取り上げさせてもらったHYCUというバックアップ製品とNutanix Objectsを組み合わせ、イミュータブルなバックアップ環境を構築する方法について紹介させていただきます。

※機材の都合上、実際にはHYCU、Objects、バックアップ対象のVMは同じクラスターにて稼働している環境にて検証を行っています。

Nutanix Objectsの準備

本記事ではNutanix Objects(以降、Objectsと略します)の初期デプロイ方法については手順を割愛させていただきます。
なお、Objectsを含めた環境はワーカーVMが3台、ロードバランサーVMが2台の最小構成にて用意し、その内部にオブジェクトロックを有効化したバケットを作成します。
HYCUからはこのバケットをバックアップ先(ターゲット)として利用します。

まずはObjectsをデプロイ後、バケットの作成を行います。
バケット作成時、バージョニングおよびライフサイクルポリシーは無効にします。


作成したバケットのWORM(オブジェクトロック)を有効化します。


次にHYCUのバックアップ先として登録できるようにするため、Objects上でユーザーを作成し、バケットへアクセス権を付与する必要があるため、左側メニューの「Access Keys」からユーザーを作成します。
また、ここでは作成時に「Add people not in a directory service」を選択して、Objects内部でローカルユーザーを作成します。

画面を進めると、各種キーの発行が行えます。
ここで、シークレットキーに関してはこの画面以降は確認することができないため、必ず保管しておきましょう。

作成したバケットを選択した状態で「User Access」タブから「Edit User Access」をクリックし、作成したユーザーをFull Accessで登録します。

次にHYCUへ登録する際に必要となる、Objectsの証明書をダウンロードしておきます。
Objectsストアを選択した状態で「Manage FQDNs & SSL Certificates」から「Download CA Certificate」を選択することで、pemファイルをダウンロードします。

HYCU側の準備

まず初めに、先ほどダウンロードしたObjectsの証明書をインポートしておきます。
ここでインポートを行わない場合は、後のObjectsをターゲットに登録する際に失敗してしまいます。

Objects上に作成したバケットをHYCUからバックアップ先として登録します。
なお、過去の記事でも紹介していますが、HYCUではバックアップ先をターゲットと表現します。以降はバックアップ先をターゲットと表現します。
左側メニューから「ターゲット」を選択し、新たにターゲットを登録します。
ここで、登録する際にターゲットの種類は「Nutanix Objects」を選択し、次の画面にて「アーカイブに使用」へチェックを入れておきます。

次の画面にてサービスエンドポイントという項目が存在します。
ここに入力する値はObjectsの管理画面から確認することができます。
なお、FQDN名でアクセスがバランシングされるように指定することが推奨されていますが、HYCUから名前解決が可能な状態である必要があります。
(IPアドレスによる指定でも通常時は動作することを確認しています)

※サービスエンドポイントをFQDNで登録する場合は、HYCUが参照するDNSにロードバランサーVMのレコードを登録する必要があります。
以下の画像を参考に、レコードを事前に作成しておきましょう。

最後に各種キーを入力します。
キーの情報はObjectsにてユーザーを作成した際にダウンロードできるテキストファイルから確認できます。
正常に登録が完了すれば、健全性に緑色のチェックマークが表示されます。
また、イミュータブル関連の機能が有効なターゲットには名前の右に鍵のアイコンが表示されていることを確認しましょう。

最後にObjectsへバックアップを取得するためのアーカイブポリシーを作成し、保護対象の仮想マシンへ割り当てを行えば設定完了です。
アーカイブポリシーと仮想マシンの保護については、過去の記事をご覧ください。
Nutanix(AHV)上の仮想マシンをHYCUでクラウドバックアップ

なお、一部のバックアップデータ(ファイル)は永久増分方式を実現する都合上、HYCU側から保持期間を延長する動作が行われるため、Objects側で指定したWORMの保持期間が過ぎても上書き・削除が行えないデータが存在します。
そのため、Objects内部のバックアップデータでタイムスタンプ上は保持期間が過ぎていても削除できないものが存在することになりますが、この挙動は上記の仕様によるものです。

まとめ

Nutanix ObjectsとHYCUを組み合わせたイミュータブルなバックアップソリューションについて紹介させていただきました。
私のブログでは以前からHYCUについていくつか紹介する記事を掲載しておりましたが、直近の1年ほどでHYCUを使ったオブジェクトストレージへのバックアップに加え、イミュータブル用途でのバックアップに利用するシーンが非常に増えたと感じています。
Nutanix ObjectsとHYCUを組み合わせた利点としては、オンプレミス上にスケールアウトがしやすい統合バックアップ環境をNutanixのスナップショット用いた純正バックアップ機能よりも、ある程度安価に実現できる点だと考えています。
今回はHYCUと組み合わせるオブジェクトストレージとしてNutanix Objectsを紹介しましたが、これ以外にWasabiなどのパブリッククラウド上のオブジェクトストレージを利用するような構成も増えており、これからも注目のバックアップ製品かなと思います。


2024年12月18日水曜日

Files5.1から実装された共有フォルダのクローン機能

Nutanix Advent Calendar 2024 18日目の記事になります。

Nutanix Advent Calendar 2024 

先日Filesのバージョン5.1がリリースされました。

いくつかの機能が追加されており、本記事では共有フォルダのクローン機能について紹介します。


共有フォルダのクローン

共有フォルダのクローンはその名の通り、Files内に存在する共有フォルダをクローンする機能です。

まずは手順を紹介します。
FilesConsoleからクローンを行いたい共有フォルダ右の「︙」をクリックし、「Clone Share」を選択します。

クローンにて作成される共有フォルダ名を指定し、[Select a Snapshot]からクローン元となる日時を選択することができます。
ここで選択できるものとしては現時点の共有フォルダをクローンする、またはスナップショットをもとにクローンする2つの方法が選択できます。
なお、スナップショットと表記されていますが、SSRで指定したスケジュールでクローンできるポイントが選択できるようです。

クローンが完了すると、一覧に共有フォルダが表示されます。

実際にWindowsクライアントからクローンされた共有フォルダにアクセスしてみます。
クローンもとの共有フォルダに存在していた各種ファイルが存在することはもちろん、事前にNTFSアクセス権でフルコントロール設定していたユーザー権限についても、クローンした共有フォルダで同様の権限が付与されていることが確認できます。
クローン元でもUser01に対してフルコントロールを与えてました。

次にFiles側で設定できる各種項目も見ていきます。
先程の共有フォルダ以外にいくつかのオプションを加えた共有フォルダをいくつかクローンしてみました。
確認がしやすい編集画面を表示していますが、共有フォルダに対するクオータ設定、SSRや圧縮、ABEなどの各種オプションはクローン先でも同様に設定が反映されていることが確認できました。

◯ユーザーごとのクオータ設定
クローン元に設定は紹介していませんが、同様の設定であることが確認できました。
また、共有フォルダ側のクオータ設定についても引き継がれていました。

◯その他、各種オプション

こちらもそれぞれ、クローン元のオプションが引き継がれていまいた。


共有フォルダのクローン制限事項

共有フォルダのクローンにはいくつか制限事項が存在します。
まず、クローンした共有フォルダ自体を更にクローンすることはできないようです。
クローンを行おうとすると、グレーアウトして選択ができないようになっています。

このことから、クローンで作成した共有フォルダは通常の共有フォルダとは異なる状態で稼働しているものと思われます。
少し、CLIからも状態を見てみました。
まず通常の共有フォルダ
<afs> share.list sharename=share01
Filtering the share list based on 'share01'
Share name                              : share01
Share UUID                              : fb04e492-7a7a-4c02-a6f4-1c6a82713221
File server name                        : files01
Share type                              : GENERAL
Protocol type                           : SMB
Secondary Protocol type                 : None
Self-service Restore                    : ENABLED
Volume group set UUID                   : b0f09300-5e1a-4713-bab2-4f9247c47559
Share path                              : /share01
File-Blocking patterns                  :
Share Workload Type                     : Default
SMB3 Encryption                         : DISABLED
Compression                             : ENABLED
Longname                                : DISABLED
Worm                                    : DISABLED
Files-at-root                           : NOT APPLICABLE
Continuous Availability                 : DISABLED
Status type                             : Available
次にクローンした共有フォルダです。
<afs> share.list sharename=Clone20241218-01-Share01
Filtering the share list based on 'Clone20241218-01-Share01'
Share name                              : Clone20241218-01-Share01
Share UUID                              : af11b1bc-33c4-40d6-67e1-4ae066c21d09
File server name                        : files01
Share type                              : GENERAL
Protocol type                           : SMB
Secondary Protocol type                 : None
Self-service Restore                    : ENABLED
Volume group set UUID                   : b0f09300-5e1a-4713-bab2-4f9247c47559
Share path                              : /Clone20241218-01-Share01
File-Blocking patterns                  :
Share Workload Type                     : Default
SMB3 Encryption                         : DISABLED
Compression                             : ENABLED
Longname                                : DISABLED
Worm                                    : DISABLED
Files-at-root                           : NOT APPLICABLE
Continuous Availability                 : DISABLED
Status type                             : Available
Origin Share                            : share01 (fb04e492-7a7a-4c02-a6f4-1c6a82713221)
Origin Snapshot                         : afs-auto-snap_hourly-2024-12-18-1500 (99b9439f-ec09-4b1c-638a-928489538d07)
このようにクローン元の共有フォルダ情報を内部で持っているようです。

また、CLIを見ていると恐らく昔は存在しなかったクローン関連のコマンドが増えているようで、以下のコマンドにてクローンした共有フォルダと利用したスナップショット情報を表示できるようです。
<afs> share.clone_list share01
|--share01 ()
   |--Clone20241218-01-Share01 (afs-auto-snap_hourly-2024-12-18-1500)
   |--Clone20241218-Share01-03 (share-clone_470ab5d2-4f9a-446d-9233-300645d5e5e8_1734543254)
   |--Clone20241218-Share01-04 (share-clone_13f02c40-75e6-4596-ba2b-195c99625afb_1734543264)
   |--Clone20241218-Share01-05 (share-clone_ed6daf92-a107-4de4-9aa3-5a47b2588118_1734543274)
   |--Clone20241218-Share01-06 (share-clone_b1f6b9c3-4c83-417d-a16c-a1b6f8415270_1734543281)
   |--Clone20241218-Share01-07 (share-clone_3f4c6814-bd09-4b5c-98a1-43a3e1554227_1734543289)
   |--Clone20241218-Share01-08 (share-clone_a9055ee7-42b0-4f1a-8236-bce3f495f421_1734543298)
   |--Clone20241218-Share01-09 (share-clone_b90e1a85-881f-4269-9962-252edb43dd61_1734543305)
   |--Clone20241218-Share01-10 (share-clone_cfee606a-cddb-4507-b8b5-d663135c5df7_1734543317)
   |--Clone20241218-Share01-11 (share-clone_35ae5e7a-33ad-4af8-b5b9-a606322c29e3_1734543350)
<afs> share.clone_list share02
|--share02 ()
   |--Clone-share01 (afs-auto-snap_hourly-2024-12-18-0900)
   |--Clone20241218-Share02 (afs-auto-snap_hourly-2024-12-18-1500)
   |--Clone20241218-Share01-02 (share-clone_0f11c3d7-c67e-46af-ac79-dde422affedc_1734543244)
※適当に操作したので、いくつかクローン元と違う命名規則で作成してしまっていますね…

クローンした共有フォルダをクローンできない以外は以下のような制限が存在します。
以下公式ドキュメントを機械翻訳。[※]は検証時に判明した情報を記載しています。
------------------------------------------------------------------------------------------
・1つの共有は最大10個の共有クローンを持つことができます。
 ※10を超えてクローンするとエラーになってしまいました。
・共有のクローン作成では以下の操作がサポートされていません:
 →クローンを持つ共有元(親)共有の復元
 →階層化されたファイルを含む共有のクローン作成
・以下の機能が有効な場合、共有のクローン作成はサポートされていません:
 →ネストされた共有
  ※クローン元にネスト共有が存在する場合は、通常のフォルダとしてクローンされました。
 →書き込み不可・読み取り専用(WORM: Write Once, Read Many)共有
  (注)WORM共有はエンタープライズモードでクローン作成が可能です。
------------------------------------------------------------------------------------------
※エンタープライズモードなるものが存在するようですが、軽く調べてみても特に情報がなく、個人的に気になるところです。

まとめ

共有フォルダのクローン機能について簡単に紹介させていただきました。
実は最近Filesを触ってなかったのですが、いろいろな機能が追加されているようで今回紹介した機能以外にも結構気になるものが増えているなと感じました。
※検証開始当初、このクローン機能を使えば共有フォルダレベルのリストアにも使えるなと考えていましたが、共有フォルダのリストアについては別でしっかり機能が用意されていました。すごい

全然関係のない話ですが、今回のAdvent Calendarに参加したことで来年からはFilesについて改めて検証したいと思える良い機会になったと思いました。

2023年7月18日火曜日

File Analyticsバージョン3.2.1で管理画面にアクセスできない原因と対処方法

備忘録のため記事しました。

File Analyticsを利用している環境にて、File Analytics VM(FAVM)が起動しているにも関わらずFile Analyticsの管理画面へのアクセスできないことがありました。

File Analyticsのバージョン3.2.1以上、3.3未満で発生する既知の不具合らしく、rootユーザーのパスワード有効期限に起因する問題のようです。

File Analytics - FA 3.2.1 may fail to start services after a reboot

なお、バージョン3.3で修正予定らしいです。


本事象の内容と改善方法

FAVMが起動している状態でFile Analyticsのコンソールに接続しようとすると、このように接続拒否されます。


FAVMへSSHで接続し、以下のコマンドでサービスの起動状態を確認します。
sudo systemctctl status docker.service
コマンドを実行するとdocker.serviceがfailed状態になっていることがわかります。
[nutanix@NTNX-192-168-45-129-FAVM home]$ sudo systemctctl status docker.service
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since Wed 2023-07-12 10:27:27 UTC; 19h ago
     Docs: https://docs.docker.com
  Process: 1485 ExecStartPre=/usr/lib/systemd/system/docker.service.d/mount_volume_group.sh (code=exited, status=1/FAILURE)


細かな仕組みはよく分かりませんが、failedになっている原因はFAVMがVolume Groupをマウントする際にroot権限を必要とするようで、デフォルト設定でrootのパスワード有効期限が60日に設定されており、有効期限が切れた後にFAVMを再起動すると起動時のマウント処理に失敗して上記の問題が発生してしまうみたいです。

そのため、rootのパスワード有効期限を延長することで解消できるみたいです。


FAVMで以下のコマンドを実行し、現在のrootユーザーの状態を確認します。

sudo change -l root

Password expiresの行を見てみると、すでに有効期限切れになっていることがわかります。

[nutanix@NTNX-192-168-45-129-FAVM home]$ sudo change -I root rootl root
Last password change					: Mar 03, 2023
Password expires					: May 02, 2023
Password inactive					: never
Account expires						: never
Minimum number of days between password change		: 1
Maximum number of days between password change		: 60
Number of days of warning before password expires	: 7

次に以下のコマンドで有効期限を再延長します。

sudo chage -d [現在の日付] root

再度rootユーザーの状態を確認すると、有効期限が延長されていることが確認できます。

[nutanix@NTNX-192-168-45-129-FAVM home]$ sudo chage -d 2023-0507-13 root
[nutanix@NTNX-192-168-45-129-FAVM home]$ sudo chage -l root
Last password change					: Jul 13, 2023
Password expires					: Sep 11, 2023
Password inactive					: never
Account expires						: never
Minimum number of days between password change		: 1
Maximum number of days between password change		: 60
Number of days of warning before password expires	: 7
※間違ってNutanixのKBに記載されている日付入れてしまってるけど、とりあえず有効期限は延長されてそう・・・

その後、rebootコマンドでFAVMを再起動後、ブラウザからアクセスするとFile Analyticsの画面が表示されます。

以上です。
File Analyticsが使えない事象なので、とりあえずNutanixのサポートポータルで調べたらすぐにヒットしそうですが、タイトルがサービスが起動しない的なタイトルだったため引っかかりづらい気もし、簡単に記事にまとめておきました。

なお、この対処方法はパスワード有効期限の再延長という対応なので、また60日後に同じ事象が発生すると思います。
次回も同様の対応をするか、今後提供される新バージョンで改善されるはずなのでFile Analyticsをアップグレードするなど、追加の対応が必要になる点は考慮しておく必要がある点にご注意ください。