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をアップグレードするなど、追加の対応が必要になる点は考慮しておく必要がある点にご注意ください。

2022年12月17日土曜日

Nutanix(AHV)上の仮想マシンをHYCUでクラウドバックアップ

※Nutanix Advent Calendar 2022 17日目の記事になります。 

HYCUの新しいロゴの壁紙


以前にも紹介したHYCUというバックアップ製品が最近ちょくちょくと採用もされはじめてきたので、今回はNutanix上(AHV)の仮想マシンをクラウドへバックアップする方法を紹介します。

HYCUはAWSやAzure、Google Cloudと、大手どころのパブリッククラウドへのバックアップに対応しています。
今回はAzureのBLOBストレージに対してバックアップをしてみます。


HYCUのおさらいとクラウドへの永久増分バックアップ

HYCUの大まかな利用方法は以前の記事をご覧ください。
Nutanix CEの仮想マシンをHYCUでバックアップ(インストール編)
Nutanix CEの仮想マシンをHYCUでバックアップ(バックアップ・リストア編)

以前の記事はHYCUの少しバージョンが古くNutanix CE上に導入・設定した手順ですが、現時点最新バージョンのHYCUであっても画面が少し変わった程度で手順はほとんど同じです。
(むしろ正式に日本語化も対応し、画面はより使いやすくなった印象をもちます。)


以前のHYCUはフル+増分バックアップ方式しか選択ができず、定期的なフルバックアップ取得時にクラウドへの大容量データ送信が必要になるため、クラウドバックアップが必要というシーンでは採用しづらい傾向にありました。

しかし、HYCUのバージョン4.5.0か4.5.1からクラウドへの永久増分バックアップが利用可能になり、初回バックアップ以降は増分データのみ送信すればよくなったため、Nutanixでクラウドバックアップが必要な要件に対してHYCUの採用がかなりやりやすくなりました。
本記事ではクラウドバックアップを取得する手順を紹介いたします。


クラウドへの永久増分バックアップ設定方法

大まかな設定方法は基本的に通常の手順と変わりません。

・ターゲット作成

まずはじめに、バックアップターゲットに今回のバックアップ先として用意したAzure BLOBを登録します。
ここで登録時には「アーカイブに使用」を有効にします。

[タイプ]項目でAzureを選択し、今回は予めAzureで作成しているBlob Storageの各種情報を入力し、登録を完了します。
AWSなど、別のパブリッククラウドを利用する場合は適宜[タイプ]項目を変更してください。


・ポリシー作成

次はポリシーの作成を行いますが、ここが最も通常と異なる点となり永久増分方式にてバックアップを行う場合は、通常のポリシーに加えて「アーカイブポリシー」を作成する必要があります。
(アーカイブポリシーが正式な名称ではないっぽいですが・・・仮で呼称してます)
これは永久増分方式のバックアップは、HYCUではアーカイブ機能を組み合わせて実現しているためです。

とは言ってもややこしいことはなく、アーカイブポリシーの作成は非常に簡単です。
ポリシー画面から右上の「アーカイブ」を選択し、間隔やアーカイブ処理のタイミングなど用途に合わせたアーカイブポリシーを作成します。

[ターゲット]項目には先程作成したBlobを指定します。

アーカイブポリシー作成の後、通常のポリシーも作成します。
ポリシー作成時に「アーカイブ」にチェックを入れ、下部に先程作成したアーカイブポリシーを指定します。
なお、今回作成したポリシーはローカルにNutanixのスナップショットだけを取得し、クラウドへ直接バックアップデータを転送する設定にしております。

[バックアップターゲット]をターゲットに選択し、NASなどを指定すればNAS→クラウドのような2次バックアップ構成にすることもできます。
細かな調整の余地はありますが、今回ような設定を行えば直接Blob Storageにバックアップを行うことが可能です。


作成したポリシーでバックアップを取ってみる

作成したポリシーをバックアップ対象の仮想マシンに適用し、バックアップを取得してみます。
通常のバックアップタスクはバックアップウィンドウが指定されていなければ、ポリシー適用後に自動で実行されます。
バックアップ完了(今回の場合はNutanixのスナップショットだけ取得)後、アーカイブポリシーにて指定した時刻になるとBlob Storageにバックアップデータを転送します。
今回は右下の「アーカイブを実行」から手動で転送を行います。

Blob Storageへのデータ転送が完了すると、復元ポイントに[ARCH]アイコンが表示されます。


クラウド上のバックアップからリストア

Blob Storageに保存したバックアップから復元を行ってみます。
[復元元]は「アーカイブ」を指定しておきます。
(デフォルトだと、最も早く復元できるターゲットが選択されてしまいます。)

クラウドからのリストアになるため、データ量は10GB程度ですが数分かかりました。

当たり前ですが、普通に起動できました。


まとめ

今回はHYCUを使ってAHV上の仮想マシンをクラウド(Blob Storage)にバックアップを取ってみました。
HYCUのアーカイブ機能を利用することで、クラウドへの永久増分バックアップを取得することができます。

もともとHYCUはNutanixとシナジーの高いバックアップ製品として以前から注目していましたが、クラウドへのバックアップが要件に上がると以前までは永久増分方式が取れないことで、クラウドバックアップという点において提案がしづらいと感じていました。
しかし、本記事で紹介した様に最近のバージョンで永久増分方式が可能になり、更に今回設定したようにクラウド上のストレージを1次バックアップ先に指定ができます。

こういった特徴があるので、Nutanix + クラウドバックアップという組み合わせではよりオススメできる製品になったと思います。

ちなみにHYCUとNutanixの組み合わせについては外部のサイトになりますが、こちらが参考になると思います。