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の組み合わせについては外部のサイトになりますが、こちらが参考になると思います。

2022年12月10日土曜日

Nutanix FilesのWORM(Write Once Read Many)機能について

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

今回はNutanix Files 4.1に追加されたWORM機能について、触ってみました。
WORMとはWrite Once Read Manyの略称であり、初回書き込み以降は上書き処理を禁止する特徴を持っています。
この特性から昨今ではランサムウェア対策やアーカイブ(長期保存)などの用途で利用されることが増えています。


Nutanix FilesのWORMはどのように動作するのか

WORMを利用する際は「クールオフタイマー」と「保持期間」の2つを指定します。
WORMオプションを有効にした共有フォルダ内のファイルが最後に更新されてから、クールオフタイマーで指定した時間が経過するとファイルは上書き不可の状態に変更されます。
上書き不可の状態から保持期間で指定した時間が経過すると、上書き不可状態が解除され削除が可能になります。


WORMの利用方法

FilesでWORMを利用するには、まずバージョンが4.1以降である必要があるため、それより古い場合はまずアップグレードを行ってください。

バージョン4.1以降であれば、SSHでFSVMに接続してコマンドにてWORMオプションが有効になった共有フォルダを作成できます。
nutanix@fsvm$ afs share.add "共有フォルダ名" worm_enabled=true
また、クールオフタイマーと保持期間は、共有フォルダ作成後に変更することができないため、デフォルト値から変更する場合は以下のオプションを付け加えます

・クールオフタイマー
worm_cooloff_interval=秒数で指定
・保持期間
worm_retention_period=秒数で指定

例えばクールオフタイマーを5分、保持期間を26週で設定される共有フォルダを作成するには、以下のコマンドを実行します。
nutanix@fsvm$ afs share.add worm-share4 worm_enabled=true worm_retention_period=15724800 worm_cooloff_interval=300
Files Consoleから確認すると共有フォルダが作成されていることが確認できます。
ただし、現在のFiles ConsoleからはWORMオプションの有効・無効状態を確認できないため、以下のコマンドにて確認を行います。
nutanix@fsvm$ afs worm.spec share_name="共有フォルダ名"
先程クールオフタイマーなどを変更して作成された共有フォルダのステータスが確認できます。
nutanix@fsvm:~$ afs worm.spec share_name=worm-share4
worm_type: kShareLevel
cooloff_interval: 300
retention_period: 15724800
autocommit: true

なお、余談ですが以下のコマンドでそもそもWORMオプションが有効化された共有フォルダであるか、確認することもできます。
nutanix@fsvm$ afs share.list sharename=worm-share3
Filtering the share list based on 'worm-share3'
Share name                              : worm-share3
Share UUID                              : c27f7f8a-019a-42a0-afad-bb6a87e454d4
File server name                        : omrisFiles01
Share type                              : GENERAL
Protocol type                           : SMB
Secondary Protocol type                 : None
Self-service Restore                    : DISABLED
Volume group set UUID                   : f4a1fb44-8151-4320-98d2-6d9d42a0b2e6
Share path                              : /worm-share3
File-Blocking patterns                  :
Share Workload Type                     : Default
SMB3 Encryption                         : DISABLED
Compression                             : DISABLED
Longname                                : DISABLED
Worm                                    : ENABLED
Files-at-root                           : NOT APPLICABLE
Continuous Availability                 : DISABLED
Status type                             : Available
色々とステータスの一覧が表示されていますが、Wormの設定が「ENABLED」になっていれば、正常にWORMオプションが有効化されています。
なお、Files Consoleなどから作成した共有フォルダはWormの項目がDisabledで表示されていますが、後からEnabled(有効)に変更することはできないため、WORM機能を利用する場合は先ほどのコマンドにて新たに作成する必要があります。


WORMオプションが有効になっている共有フォルダの動作

先程のイメージ図の通り、WROMが有効な共有フォルダ内に新規ファイルを作成し、クールオフタイマーで指定した時間以内であれば、上書きすることができます。
クールオフタイマーの時間を経過した後に、上書き保存しようとすると拒否される形になります。

クールオフタイマー経過後に改めてファイルを開くと上書き禁止状態になっていることも確認できます。

また、ファイルを直接削除しようとしても、拒否されます。


まとめ

Nutanix FilesではWORM機能を利用することができます。
Nutanixを利用している環境であれば、わざわざWORM対応の専用ストレージ製品などを用意することなく、WORM機能を利用することができます。
(Nutanix FilesはAOSライセンスに1TBの無償利用枠がありますので、少しだけWORM機能が必要な要件があるみたいな状況でも活用できるのかなと思っています。)

また、設定は現状コマンドからのみになります。

なお、WORM機能を利用する際の細かな制限事項などは公式ドキュメントをご確認ください。
https://portal.nutanix.com/page/documents/details?targetId=Files-v4_2:fil-files-worm-shares-c.html

2022年11月30日水曜日

Nutanix Files SSRによるリストアポイント作成のタイミングについて

 Nutanix FilesはSelf-Service Restore(以降SSR)というファイル単位のリストアが行える機能を持っています。

なお、以前に説明していますが、Self-Service Restoreと呼ばれる機能はProtection Domainで保護した仮想マシンのバックアップイメージから、ファイル単位でリストアを行う機能もSelf-Service Restoreという名称で呼ばれます。

このことから、

Protection DomainのSelf-Service Restore = Nutanix FilesのSelf-Service Restore

間違えて認識されていることがあるので、改めてご注意ください。

デフォルトのリストアポイント作成のタイミング

まず改めてFilesのSSRの設定を見てみます。


例えば上記の毎時(hourly)設定では6時間ごとにリストアポイントを作成し、40世代保持するというスケジュールが設定されています。
このリストアポイントを作成するタイミングは毎時、日次、週次などいずれもAM9:00に作成する仕様になっています。

FilesのSSRはUTC 0:00(JST 9:00)を起点として、設定したスケジュールに合わせてリストアポイントを作成するため、日時でスケジュールを設定すると日本時間ではAM9:00にリストアポイントが毎日作成されます。

毎時のスケジュールが6時間毎に設定されている場合は9:00→15:00→:21:00→3:00・・・となるようにリストアポイントが繰り返して作成されることになります。


リストアポイント作成のタイミング変更方法

次にリストアポイントが作成されるタイミングを変更する方法を説明します。
なお、タイミングの変更は毎時(hourly)のタイミングのみで、日次、週次などのタイミングは変更できず、UTC 0:00に必ず作成されます。

毎時のタイミング変更はFSVMにSSHで接続し、以下のコマンドにて行います。

nutanix@fsvm$ afs snapshot.set_ssr_hourly_offset 1 - 23

末尾の数値を起点となるUTC 0:00から1時間単位で時間をずらす形で設定を行います。

例として、7時間ずらしてリストアポイントを作成する場合は以下のようにコマンドを実行します。
nutanix@fsvm$ afs snapshot.set_ssr_hourly_offset 7

この状態の場合、先程のように6時間ごとにリストアポイントを作成した場合、7時間ずれて16:00→22:00→4:00→10:00・・・と本来9:00を起点として作成されるリストアポイントが7時間時間ずれて取得される形になります。


設定値の確認方法

一度タイミングの変更を行うと、Files ConsoleなどのGUIからは設定値の確認はできません。
現在の設定値を確認するには以下のコマンドを実行します
nutanix@fsvm$ allssh cat /home/nutanix/config/minerva_ssr.config

実行すると、各FSVMごとに設定された値が出力されます。
================== FSVMのIPアドレス1 =================
START_HOUR_OFFSET=7
================== FSVMのIPアドレス2 =================
START_HOUR_OFFSET=7 ================== FSVMのIPアドレス3 =================
START_HOUR_OFFSET=7
※この方法はドキュメントに記載された確認方法ではないため、自己責任で利用をお願いします。


まとめ

FilesのSSRはUTC 0:00(JST:9:00)を起点にリストアポイントを作成します。

hourlyのみタイミングをずらしたい場合FSVMからコマンドに実行し、1時間単位でリストアポイントの作成タイミングを変更することができます。

FilesのSSRはこのように仮想マシンの保護で利用されるProtection Domainとは異なる管理・設定を行うため利用時は注意してください。

2022年7月7日木曜日

Nutanix FilesのマルチVLAN構成

Nutanix Filesバージョン4.1にて、クライアントネットワークのマルチVLANを構成を設定する機能が追加されました。

Multi-VLAN Network Management

詳細は上記のドキュメントをご覧ください。


これまでのFilesネットワーク構成について

Filesは各FSVMにクライアントネットワークとストレージネットワークの2つのネットワークが存在し、それぞれが異なるネットワークに所属するか、または両方のネットワークをまとめて一つのネットワークに所属するような構成を取っていました。

▲(図1)クライアントネットワークとストレージネットワークを分離した構成
▲(図2)クライアントネットワークとストレージネットワークをまとめた構成


このような構成において、実際にユーザーが利用する際にアクセスするクライアントネットワークをセキュリティの観点から分離したいといった要件がある場合、これまでのFilesはクライアントネットワークに複数のネットワークを持つことができなかったため、複数のFilesを展開するという手法を取る必要がありました。

▲(図3)従来のFilesでネットワークを分離するための構成
規模にもよりますが、複数セットのFilesを展開するこの手法は小規模環境において、余分なリソースが増加してしまう傾向がありました。


バージョン4.1で追加されたマルチVLAN構成

マルチVLAN構成が可能になったことで、1つのFilesで複数のネットワークにファイルサービスを提供することができるようになりました。

これにより、一つのFilesでネットワークを分離したいなどの要件に対して柔軟に対応することができるようになりました。

ただし、マルチVLAN構成を取るにはいくつか条件があるため、予め制限を把握しておく必要があります。
特に引っかかりそうな条件としては、初期の展開時に図2のようなクライアント、ストレージ両方のネットワークを一つのネットワークで構成した、いわゆるシングルネットワークの構成を取っているFilesを後からマルチVLAN構成に変更することはできないため注意が必要です。


設定方法

まずは上の方で説明した通り、クライアントとストレージのネットワークを分けたFilesを用意します。

Filesの新機能ははじめは大体CLIから設定できるパターンが多いです。
この機能も例に漏れず、まずはCLIからの設定方法のみ提供されています。

まずはSSHでFSVMに接続して、以下のコマンドで現在のクライアントネットワークを確認してみます。
※なお、はじめにafsコマンドのみを実行するとafsモードに切り替わるので、移行のコマンドは頭にあるafsの記述は不要です。
afs net.list_external

現在はvlan316(no ipam)というネットワークがクライアントネットワークとして構成されていることがわかります。
※ネットワーク名が変な名前ですが、AHVで作成する普通のVLANネットワークです。
UUID                                  Name              Virtual UUID                          Managed  Gateway      Netmask/Prefixlen  IPs                                                  Primary  Vlan
5467672e-31b3-40bd-a7fb-dba996a282df  vlan316(no ipam)  898963d1-a37a-4768-83bf-8adb77972486  No       172.17.16.1  255.255.255.0      [u'172.17.16.14', u'172.17.16.15', u'172.17.16.16']  No       -

このFilesに新たなクライアントネットワークを追加してみます。
公式ドキュメントを見ると、以下のコマンドで追加すると記載されています。
afs net.add_external <input-json-file-path>

後ろの<>内は追加するネットワーク情報を記載したjsonファイルを指定するのですが、このjsonファイルの作り方が非常にわかりづらいです。

一応jsonファイルの作り方は以下のコマンドで確認してくれと記載されていますが、

afs help net.add_external

このコマンドの実行結果が以下になります。

net.add_external:
  Add external networks.

  Usage: "net.add_external <input-json-file-path>"
  Input JSON file schema:
  [
    {
      "virtual_network_uuid": "<uuid>"
    },
    {
      "virtual_network_uuid": "<uuid>",
      "gateway_ip": "<gateway-ip-address>",
      "netmask_ip": "<netmask-ip-address>",
      "ip_list": [
        "<fsvm-ip-address>",
        "<fsvm-ip-address>",
        ...
      ]
    },
    ...
  ]

  1. Managed network entry only requires "virtual_network_uuid" field.
  2. Unmanaged network entry requires "virtual_network_uuid", "gateway_ip",
     "netmask_ip" and "ip_list" fields.

  Usage:
    net.add_external <json_file_path> [key=val ...]

  Required arguments:
    json_file_path (string): Input JSON file path

なんとなく、追加するネットワーク情報を記入してやれば良いのはわかりますが、正直わかりづらいと思います。

余計な記述を削っていき、最終的には以下のような形式でjsonファイルを作成します。

[
        {
          "virtual_network_uuid": "<追加するネットワークのUUID>",
          "gateway_ip": "<追加するネットワークのGW>",
          "netmask_ip": "<追加するネットワークのサブネットマスク>,
          "ip_list": [
            "<FSVMのクライアント側IPアドレス①>",
            "<FSVMのクライアント側IPアドレス②>",
"<FSVMのクライアント側IPアドレス③>"
] } ]

FSVMのIPアドレスはFSVMの台数に合わせて追加してください。

行の始め辺りにある「virtual_network_uuid」はPrimsのNetwork Configから対象のネットワークを編集する際に確認することができます。

今回はこのVLAN300というネットワークを追加することにします。


この内容にて任意の名前で拡張子を[.json]で保存し、以下のコマンドを実行します。

afs net.add_external <作成したjsonファイル>

※コマンド実行時にjsonファイルのパスを指定しない場合は、home直下が参照されます。


以下のように結果が表示されれば、正常にコマンドが実行できています。

Created network-add task: d3c723bf-8b0a-4a0c-ae7e-798eea768c0e

再度クライアントネットワークの一覧を確認すると、クライアントネットワークが2つに追加されていることがわかります。

UUID                                  Name              Virtual UUID                          Managed  Gateway      Netmask/Prefixlen  IPs                                                  Primary  Vlan
eb047398-594a-45f3-97e8-4fdb169ae48f  VLAN.300          8e803826-495d-4d61-ac49-f37217510471  No       172.17.0.1   255.255.255.0      [u'172.17.0.91', u'172.17.0.92', u'172.17.0.93']     No       300
5467672e-31b3-40bd-a7fb-dba996a282df  vlan316(no ipam)  898963d1-a37a-4768-83bf-8adb77972486  No       172.17.16.1  255.255.255.0      [u'172.17.16.14', u'172.17.16.15', u'172.17.16.16']  Yes      316


Files Consoleから構成情報を確認すると、クライアントネットワーク情報あたりに「+ 1 more」と表示されていますので、クリックします。


追加したVLAN300がクライアントネットワークが認識されていることが確認できます。

なお、Filesを展開する際に選択したクライアントネットワークには「Primary」と表示されます。
本手順で追加したネットワークは削除することができますが、プライマリネットワークは削除できないことに留意してください。


クライアントユーザーから接続時の注意点

マルチVLANの設定は完了しましたが、実際にマルチVLANのFilesを利用するにはいくつか注意点があります。

・ホスト名による接続

マルチVLANの設定ができると、FSVMはクライアントネットワーク側に各ネットワークごとのIPアドレスを持つことになります。
ただし、Filesのホスト名は展開時に指定した一つしか設定できないため、各ネットワークで同一のDNSを参照する場合は名前解決によって、異なるネットワークごとに正確なIPアドレスを取得することができません。
※Filesは直接FSVMのIPアドレスからも接続することは可能ですが、バランシングの仕組み上、FQDNでアクセスすることが推奨されます。

回避策として、DNSのレコードに異なるホスト名を手動で登録し、クライアント側IPアドレスと関連付けを行います。

これにより、プライマリネットワークと異なるネットワークでは、対応する異なるホスト名を指定することで、名前解決によって疎通可能なIPアドレスを取得することができます。


ただし、この方法は公式ドキュメントに記載された方法ではないため、あくまで自己責任となることをご留意ください。
※一応DNSレコード追加方法は以下のURLに記載されていますが、用意されている方法がよくわからないので、手動で入れてしまってもいい気がします。

https://portal.nutanix.com/page/documents/details?targetId=Files-v4_1:fil-fs-manage-dns-server-t.html



FilesのマルチVLAN機能の紹介は以上です。

一部課題もありますが、Filesで提供できる構成が増える、注目の新機能になりますので、活用できるシチュエーションがありましたら、ぜひお試しください。 

2022年3月29日火曜日

Nutanixの試験が無料で受験できるバウチャーコード(2022/5/15まで有効)

以下のバウチャーコードを入力することで、Nutanixの試験NCA(初級)・NCP(中級)・NCM(上級)が無料で受けることができますので、この機会に興味のある方は是非受験してみてください。

NTXRF22J


本来は199ドルの試験なので、かなりお得だと思います。
現在はAOS 5.20ベースの問題に刷新されていますので、過去に合格された方もこの機会にアップデートしてみてください。
なお、以前は日本語対応されていない試験もありましたが、現在はほとんどの試験が日本語化されています

期限は2022/5/15まで利用可能です。
また、申込時に1ヶ月後までのスケジュールを予約できるので、6月中頃まで猶予があります。
とりあえず5/15までに予約けしておいて、それから準備するようなこともできます。

受験はテストセンター、またはオンライン試験のどちらかを選択できます。
このご時世なので、私はオンライン試験を利用しています。
オンライン試験は一定条件を満たした試験環境(静かで余計なものが置かれてない部屋、監視用カメラなど)を準備する必要があり、試験開始前のやり取りで英語によるチャットのやり取りがありますが、活用してみてください。

なお、受験までの手順および試験の種類についてはshadowhatさんがわかりやすく纏めてくれているので、そちらを参考にしてくださいm(_ _)m




2022年1月4日火曜日

Nutanix FilesのSMB CA(継続的可用性)共有を試してみた

Filesのバージョン3.7ごろに追加された機能、SMB CA(継続的可用性)共有を試してみました。
https://portal.nutanix.com/page/documents/details?targetId=Files-v4_0:fil-fs-persistent-handles-c.html

この機能はFSVMがノード障害などにより停止した場合に、フェイルオーバーが完了するまでの間、クライアントとFiles間の接続を切断することなく維持することができます。
ファイルサーバーがアプリケーションと連動している場合に利用することが想定された機能です。

なお、SMB CA自体はSMB3から提供されたMicrosoftの技術であり、それをFilesでも利用できるようになった形です。(名前の通りSMBプロトコルのみ対応)


SMB CA無効時の挙動

SMB CAはFilesに作成した共有フォルダに対して設定を行います。

まずは作成直後の共有フォルダのステータス確認してみます。
FSVMにて以下のコマンドを実行します。(以降、コマンドはすべてFSVMから実行します)

afs share.list sharename="{共有フォルダ名}"

◆実行結果(「CA Test」という共有フォルダに対して実行した例)

nutanix@NTNX-192-168-45-125-A-FSVM:~$ afs share.list sharename="CA Test"
Filtering the share list based on 'CA Test'
Share name: CA Test
Share UUID: 1fe8e2c2-8bff-4f65-823e-f2302cd4fd87
File server name: omrisFiles01
Share type: GENERAL
Protocol type: SMB
Secondary Protocol type: None
Self-service Restore: ENABLED
Volume group set UUID: 84ffa0cc-76f8-4f12-a80e-074fb446bd9b
Share path: /CA Test
File-Blocking patterns:
Share Workload Type: Default
SMB3 Encryption: DISABLED
Compression : ENABLED
Files-at-root : NOT APPLICABLE
Continuous Availability: DISABLED
Status type: Available
下から2行目に「Continuous Availability: DISABLED」と記載がありますが、作成直後はSMB CAが無効であることがわかります。

この状態でファイルコピーを実施していた共有フォルダに紐付いたFSVMを強制停止すると、コピー処理は停止され再実行を求めるウィンドウが表示されてしまいます。



SMB CAを有効化

先程の共有フォルダに対して、SMB CAを有効化してみます。
共有フォルダに以下のコマンドを実行します。
afs share.edit "{共有フォルダ名}" continuous_availability=true
コマンド実行後に改めて共有フォルダのステータスを確認してみます。
nutanix@NTNX-192-168-45-125-A-FSVM:~$ afs share.list sharename="CA Test"
Filtering the share list based on 'CA Test'
Share name: CA Test
Share UUID: 1fe8e2c2-8bff-4f65-823e-f2302cd4fd87
File server name: omrisFiles01
Share type: GENERAL
Protocol type: SMB
Secondary Protocol type: None
Self-service Restore: ENABLED
Volume group set UUID: 84ffa0cc-76f8-4f12-a80e-074fb446bd9b
Share path: /CA Test
File-Blocking patterns:
Share Workload Type: Default
SMB3 Encryption: DISABLED
Compression : ENABLED
Files-at-root : NOT APPLICABLE
Continuous Availability: ENABLED
Status type: Available
「Continuous Availability」の項目がENABLEDに変更されていれば、設定完了です。

この状態で先程のようにコピー処理の途中にFSVMを停止させてみます。
一時的にコピー処理が止まりますが・・・

数十秒するとコピー処理が再開されました。


このようにSMB CAを利用することで予期しないノード障害によって、FSVMが停止してしまった場合に処理を中断することなく、ファイルサーバーを利用することが可能になります。

通常用途の共有フォルダとして利用するなら単純にコピーの再実行をすれば良いですが、アプリケーションなどと連携して利用するなど、処理の中断が許されない用途で利用する場合に活用できる機能になります。