2021年12月20日月曜日

Nutanix CEでPrismのパスワード有効期限をなくしてみた

現時点で最新のNutanix CEバージョン5.18はデフォルトでPrismのadminユーザーのパスワードに有効期限が設定されています。
この制限がなかなか厳しく、60日の有効期限とパスワードは過去10回分は記憶されており、新しいパスワードに同じものは利用できないようになっています。

自宅の検証環境でこのパスワードポリシーを運用するのは面倒なので、有効期限を無効化してみました。

手順

CVMにSSHで接続し、以下のコマンドで現在のパスワードポリシーを確認します。

sudo chage -l admin

デフォルトの状態ではこのようなステータスが確認できます。

nutanix@NTNX-SGH950XPCX-A-CVM:192.168.38.133:~$ sudo chage -l admin
Last password change : Oct 20, 2021
Password expires : Dec 19, 2021
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

デフォルトでは有効期限が60日に設定されていることがわかります。

ここへ以下のコマンドを実行することで、無期限に変更することができます。

sudo chage -I -1 -m 0 -M 99999 -E -1 admin

再度パスワードポリシーを確認します。

nutanix@NTNX-SGH950XPCX-A-CVM:192.168.38.133:~$ sudo chage -l admin
Last password change : Oct 20, 2021
Password expires : never
Password inactive : never
Account expires : never
Minimum number of days between password change : -1
Maximum number of days between password change : 99999
Number of days of warning before password expires : 7

このようなステータスになっていれば、有効期限なしでパスワードを利用できます。

注意点

製品版のAOSのバージョン5.17あたりから、CEと同じようにPrismのパスワードに有効期限が設けられるようになりました。
ただし、製品版でパスワードポリシーを無効化することは推奨できないので、あくまでCEに限定してご利用ください。

2021年12月13日月曜日

Nutanix FilesのSmart Tieringを試したみた

Nutanix Advent Calendar 2021 12/13分の記事です。


以前とあるイベントでも紹介したFilesのSmart Tieringを紹介したいと思います。
Smart Tiering

Smart Tieringとは

Files内の長期間アクセスされていないコールドデータを、安価なオブジェクトストレージへ階層化することができる機能です。

Smart Tieringイメージ図


Smart Tieringを利用するには、予めコールドデータの退避先となるオブジェクトストレージを用意する必要があります。

AWS S3やNutanix Objectsなどが対応しており、今回の環境ではNutanix Objectsを予め準備しています。


利用手順

利用手順は以下の流れになります。
 1.オブジェクトストレージの準備(本記事では割愛)
 2.My Nutanixアカウントへ接続(本記事では割愛)
 3.Data Lensをアクティベート
 4.Data Lensへ対象のFilesを登録
 5.Smart Tieringの設定
 6.階層化の実行

①と②は本手順では省略させていただきます。

③のData LensのアクティベートはMy Nutanixに追加されている「Data Lens」をアクティベートすることで実施できます。
なお、Data LensはMy Nutanixから管理画面が提供される、SaaS系の機能として提供されています。

アクティベート後は「Launch」をクリックすることでData Lensの管理画面に移動します。


ダッシュボードでは、My Nutanixアカウント内のライセンス情報に紐づくFilesの一覧が表示されます。
(地図上ではなぜか中国に存在するように見えてしまいますが・・・)


一覧から管理対象のFilesを右の「︙」からEnableを選択します。
Files名の左に緑色の点が表示されれば、FilesをData Lensの管理対象として登録できた状態になります。
この状態でFilesをクリックします。

次の画面では、File Analyticsとよく似た画面が表示されます。
今回紹介するのはSmart Tieringだけですが、Data Lensでは複数のクラスターに存在するFilesに対して、File Analyticsと同等の分析機能を提供することができます。

File Analyticsと異なる点として、右の赤枠に「Smart Tiering Dashboard」と表示されたリンクが存在します。
こちらからSmart Tieringの設定を実施します。

Smart Tieringの設定画面では、中央から右側にFilesのストレージ状況が表示されています。
まだ、階層化の設定を実施していないため、すべてのデータはローカルの存在する状態です。
まずは左側の赤枠をそれぞれ設定する必要がありますので、「①.Add Tiering Location」からオブジェクトストレージの登録を行います。

今回は予めNutanix Objectsを用意しているので、そちらを登録します。
オブジェクトストレージはStore Typeから、任意のものを選択してください。
※オブジェクトストレージを利用する際の条件は以下のドキュメントを参照してください。
https://portal.nutanix.com/page/documents/details?targetId=Data-Lens:analytics-tiering-requirements-r.html

オブジェクトストレージの登録が正常に完了すると、緑色で「Verified」と表示されます。
次に「②Set a Capacity Thredhold」をクリックします。

ここでは、階層化を行うしきい値を設定します。
例えば、5TBのFilesに対して[Set a Capacity Threshold]に80%と指定すると、4TBを超えたデータが階層化の対象になります。
また、階層化を行うタイミングは手動、または登録したスケジュールによる自動のどちらかを指定できます。
※今回はデモのため、小さい値(1%)をしきい値として設定しています。

ダッシュボードに戻り、次は「③Define a Tiering Policy」をクリックし、階層化されるデータの条件を指定します。
条件は「最後にアクセスしてから経過した日数」と「ファイルのサイズ」の2つを指定できます。
また、「Exclude Shares」から階層化する共有フォルダを個別に指定することが可能です。
※こちらもデモのため、1日アクセスがないデータを階層化対象としています。

3つの項目の設定が完了すると、中央のグラフに赤枠の網掛けの領域が表示され、階層化対象のデータが確認できます。
デモ環境では先程設定した条件に当てはまるデータが2.42GiB存在することがわかります。
この状態で、右の「Tier Data」をクリックします。

右側のTiered  Dataの値が増加したことが確認できます。
また、先程網掛けで表示されたグラフがなくなり、Used Spaceの値が減少していることも確認できます。
※デモ環境では、「Tier Data」を実行してから数日間経過した画像のため、容量が異なっています…

まとめ

Smart Tieringを利用するにはData Lens経由する必要がありますが、Data Lensを利用するには別途ライセンスが必要になるようなので、運用初期から利用するというより、運用中に容量が不足した際の一つの改善策になるのではと考えています。

また、現時点ではData Lensは60日の無償トライアルが利用できますので、ちょっと触ってみたいという方も試すことができるようになっています。


2021年8月31日火曜日

NutanixのPrismから利用できる分析機能

今回はPrismから利用できる分析機能について紹介してみます。

分析(Analysis)

まず、今回紹介する機能はPrism左上のメニューから選択できる「分析」タブ(英語表記ではAnalysis)になります。
こちらは必須の機能ではありませんが、Nutanix全体のパフォーマンス状況を確認できたり、障害発生時の切り分けに利用できる場合があります。


何ができるのか?

Nutanix全体の各リソース使用状況を可視化することができます。

仮想マシン、またはクラスターをはじめ様々な対象のCPU、メモリ、DiskIOなどのリソース情報を時刻ごとにグラフ形式で表示することができます。

これを利用して、例えば特定の仮想マシンにて動作しているアプリケーションが不安定な状況が発生した場合、どのリソース不足が原因であるか特定することができると考えています。


チャートの作成

Prism左上のメニューから「分析」を選択します。

分析画面ダッシュボードは最初の状態では何も表示されておらず、ここにチャートを追加していく形になります。
今回は例としてクラスター全体のCPU使用率を表示するチャートを作成してみます。
チャートには「指標チャート」と「エンティティチャート」の2種類が存在し、「指標チャート」はCPUやメモリなどのリソースに焦点を当てチャートを作成し、「エンティティチャート」はホストや仮想マシンなどに焦点を当てチャートを作成します。
今回は指標チャートを作成を試してみるので、まずは左上の「新規 - Chart(指標チャートを新規作成)」をクリックします。

任意の名前を入力し、項目[指標]には「Hypervisor CPU Usage (%)」を選択します。
項目[エンティティタイプ]には「Cluster」を選択し、項目[エンティティ]には分析対象のクラスターを選択し、「保存」をクリックします。
 ※項目[指標]のテキストボックスに文字列を入力することで検索することができます。
  非常に多くの選択肢が存在しますので、検索機能を利用して条件を探すことをおすすめします。

分析ダッシュボードに作成したチャートが表示されます。

次に特定の仮想マシンCPU使用率のチャートを作成します。
先程と異なり、項目[エンティティタイプ]に「Virtual Machine」を選択して、項目[エンティティ]には分析対象の仮想マシンが選択されている状態で「保存」をクリックします。

分析ダッシュボードに作成した複数のチャートを並べて表示されます。

仮想マシン上のアプリで動作が不安定な状態となった場合、それが仮想マシンのCPUリソース不足が原因であるか、クラスター全体でリソース不足が発生している、どちらでもなければそれ以外の要因であるなどの状況を判断する一つの材料として活用することができます。

デフォルトでは1日の期間でグラフが表示されており、右上のプルダウンメニューから期間を変更することができ、最大で3ヶ月間の期間でチャートを表示することが可能です。

また、上部のバーをスライドさせることで、表示する期間を微調整することもできます。

このように複数の要素を過去に遡って確認、比較する場合に活用することができます。


チャートの編集

作成したチャートを修正することもできます。
チャート左上のチャート名をクリックし「Edit Chart」を選択します。

分析対象の仮想マシンを増やしてみます。

一つのチャートに複数の仮想マシンを含める形に編集することができました。


チャートの簡単な作成方法

上記で説明した手順も簡単ですが、仮想マシン一覧などからチャートを作成することもできます。
仮想マシン一覧から任意の仮想マシンを選択し、下部にあるリソースグラフ右上にカーソルを合わせて、「分析ページにチャートを追加」をクリックします。

選択した仮想マシンリソースのチャートが分析ダッシュボードに表示されます。
なお、この手順で作成したチャートは画面遷移後に削除されてしまうため、「Save Chart」をクリックすることで、恒久的にチャート残すことができます。


まとめ

Nutanixのメリットの一つに仮想基盤の運用コストが軽減できるというものがあります。
これはPrimsからハイパーバイザーや仮想マシン、ストレージを一元管理できることや様々なアップグレードが簡単にできることもそうですが、今回紹介した分析機能により仮想基盤の様々なリソース状況を可視化することで、全体像を把握しやすいという点も運用コストを軽減できる一つの要素になっていると考えています。

このような機能を追加コンポーネントや上位ライセンスが不要で利用できる点は、魅力的だと思いますので、このブログをご覧頂いた機会に是非利用してみてください。

2021年7月31日土曜日

Nutanix FilesのSmart DR機能について(フェイルオーバー・フェイルバック編)

前回に続けてSmart DRの紹介です。

前回作成したSmart DRの環境を使って、ファイルオーバーとフェイルバックの動きを見てみましょう。


フェイルオーバー(計画内)

前回はポリシー作成までが完了しポリシーができた直後はFilesはメイン側がActive状態、DR側がStandby状態です。(以下フロー図の赤枠の部分)

この状態でフェイルオーバーを実施してみましょう。

操作は前回と同様にすべてPrism Centralから行います。
[Data Protection - Protected File Servers]から保護しているFiles右の「Failover」をクリックします。



フェイルオーバーには計画内、または計画外の2種類の方法が存在します。
計画内のフェイルオーバーは事前にメイン側クラスターの障害発生を予測できている場合に利用されます。(法定点検など)

まずは計画内のフェイルオーバーから試して見たいと思いますので、「Planned Failover」を選択します。
このとき「Create a Reverse Replication Policy」にチェックを入れ、フェイルバック時に必要となるリバースレプリケーションポリシーも合わせて作成しておきます。

※フロー図の左下の部分です

フェイルオーバー時にActive DirectoryとDNSの情報を書き換えるため、ここで書き換え可能な管理者権限を持つユーザーを指定します。
「Failover」をクリックすることで、フェイルオーバーが開始されます。

処理は2分程度で完了します。
完了後はPrism Centralの画面でアイコンが変更されていることがわかります。
(FilesAがStandby、FilesA-DRがActiveというステータスになっています。)

DNSレコードを見てみると、メイン側FilesのIPアドレスがDR側FilesのIPアドレスと同じ値に変更されています。
これにより、クライアントからはメイン側Filesのホスト名で接続しようとすると、DR側のFilesに接続されるようになります。

また、Filesへの書込に関してもメイン側は書込不可の状態となり、DR側のみ変更が可能になります。(DNSレコードが切り替わるため、IPアドレスから直接Filesに接続してテスト)
フェイルバックのテスト用にフォルダを一つDR作成しておきます。

フェイルオーバーを実行するとこれらの変更が加わるため、クライアントからは意識せず短時間で切り替えることが可能になります。

フェイルバック(計画内)

次にフェイルバックにてもとの状態に戻してみます。
先程までの手順を実施すると、フロー図的には以下の赤枠に状態になります。

フェイルオーバー時にリバースレプリケーションポリシーは作成している状態なので、早速フェイルバックの手順から開始することができます。

フェイルオーバー時に変更を加えたDNSとADの情報をもとに戻す必要があるため、再度管理者権限を持つユーザー情報を入力します。

最後の確認画面では、フェイルオーバー時に作成したリバースレプリケーションポリシーが削除される旨の内容が表示されます。
(Smart DRの仕様で、リバースレプリケーションポリシーはフェイルバック時に削除されます)
「Failback」をクリックするとフェイルバックが開始されます。

フェイルバックも数分で完了し、Prism Centralからもとの状態に戻っていることが確認できます。

完了すると、メイン側のFilesにファイルオーバー時にDR側で作成したフォルダが存在することが確認できます。

DNSレコードももとに戻っていることが確認できます。
以降は通常通り、Filesを利用することができます。

フェイルオーバー(計画外)

次に計画外フェイルオーバーの動作を見てみます。
計画外のフェイルオーバーは火災や自然災害などで突如メイン側のFilesが利用できなくなった場合に実施します。
先程と同様にPrism Centralから対象のFilesで「Failover」をクリックします。

計画外では「Unplland Failover」を選択します。

DNSとADの情報を書き換える動作は同じです。
こちらも管理者権限を持つユーザー情報を入力し、「Failover」をクリックします。

計画外のフェイルオーバーも2分程度で完了し、完了後Prism Centralではこのようにメイン側とDR側両方のFilesがActiveの状態になります。

両方がActiveの状態のため、メイン側にも書込が可能な状態になっています。
これは計画外のフェイルオーバーが、メイン側Filesが操作不可能な状態に陥っている場合を想定した機能となっているため、メイン側に対しては一切の変更が加えられないという仕様になっています。

DNSレコードが書き換えられている点は同じです。
クライアントがホスト名で接続してきた場合には、DR側のFilesに接続されることになります。

フェイルバック(計画外)

それでは計画外フェイルオーバーからもとの状態に戻してみましょう。
計画外フェイルオーバーからフェイルバックでもとの状態に戻してみましょう。
なお、フロー図で見ると現在は赤枠の状態です。

この後の操作ではフロー図の通り、2種類どちらかのオペレーションを選択することになります。

Prism Centralの画面から「Resume Replication」をクリックします。

ここでは、両方Active状態のFilesをどちらに寄せるか選択します。
左の青枠を選択すると、メイン側のFilesをStandbyに変更しDR側のみで利用を継続します。
このとき、先程の計画内フェイルオーバーと同様にリバースレプリケーションポリシーを作成できます。
後の動作は計画内のフェイルバックと同様になります。

右の赤枠を選択すると、メイン側に移行し、DR側をStandby状態に変更します。
(注意:赤枠を選択するとフェイルオーバー時にDR側で作成したファイルは削除されるため、原則青枠でのフェイルバックを行うことになると思います)


まとめ

前回の設定編も簡単でしたが、実際にフェイルオーバーとフェイルバックを行う操作も非常に簡単です。
特に短い時間でDR側に切り替えることができるのは、非常にメリットのある機能だと感じました。
Prism Centralさえあれば、追加のライセンスなど必要なく利用できる機能になりますので、DR環境に短いダウンタイムで切り替えを行えるファイルサーバーとして提案もしやすいのではないかと思います。

2021年6月21日月曜日

Nutanix FilesのSmart DR機能について(概要紹介・設定編)

 Nutanix Filesバージョン3.8から追加された新機能である、Smart DRについて紹介します。


Nutanix Filesの保護について

Smart DRの前にNutanix Filesの保護(バックアップなど含む)について、おさらいしてみます。

Nutanix FilesはNutanixの堅牢な分散アーキテクチャー上動作するため、仮想基盤のトラブルに引っ張られる形でFilesに影響が及びにくく、Filesに関しても高可用性を持ったアーキテクチャーで動作しており、物理的・論理的な要因によってデータロストしてしまうことは非常に稀だと考えています。

ただし100%安全なシステムは存在しないので、いざというときの備えは必要になります。
その備えとしてProtection DomainのAsync DRにてスナップショットを取得することで、Files全体の復元またはファイル/フォルダ単位の復元が必要なシチュエーションではSSR(Self Service Restore)を利用できるため非常に使い勝手がよいです。
このスナップショットをレプリケーションすることで、バックアップ用途としても非常に多く利用されています。


自然災害等で拠点そのものが利用できない状態で稼働をしたい場合には、DR側サイトでFilesを復旧して稼働させることが必要になります。

そのような場合もAsync DRのレプリケーション機能を利用すればDRサイト側で稼働させることはできます。
ただし、Async DRではスナップショットをもとにNutanix Filesのクローンを1から展開する仕組みのため、数十分ほどの時間を要していました。


過去の記事でNutanix Filesの保護について紹介しているので、詳しくはそちらをご覧ください。


Smart DR(Disaster Recovery)とは

今回紹介するNutanix Filesバージョン3.8から追加された機能であるSmart DRはFilesのDR環境構築において、さらなるメリットを提供することができます。
Smart DRを利用することにより、FilesをDR側サイトで復旧を行う際、より短いRTO(復旧目標時間)で利用を可能にし、フォルダ単位の細かな保護を実現できます。

Smart DRはメイン側に存在する任意の共有フォルダを指定して、一定時間ごと(最短10分)にDR側のNutanix Filesへレプリケーションを行います。
DR側のFilesはAsyncDRと異なり常時稼働(ただし、DR側は書込不可)している状態のため、クローンによる再展開が不要になり、数クリックの操作と僅かな時間(1~2分)でDR側サイトでFilesを利用可能にします。


なお、この機能を利用するにはPrism Centralが必要になり、Nutanix Filesが展開されているメイン側、DR側双方のクラスターをPrism Centralで管理している状態にする必要があります。
Prism Centralについては以下の記事をご覧ください。

Smart DRの設定方法

では、実際にSmart DR設定を行ってみます。
 ※今回は用意できる環境の都合上、同じクラスター内のFiles同士でSmart DRを設定してみます。

Smart DRはすべてPrism Centralから設定・操作を行います。
予めNutanix Filesを双方のクラスターで展開し、展開されているクラスターをPrism Centralから管理できる状態にしてください。

なお、Smart DRの設定と各操作の実行は以下の流れで行います。

はじめは左上の保護ポリシーを作成する作業から行い、それぞれのフローに従って設定やフェイルオーバーを行っていきます。

まずはPrism Centralに接続し、左側のメニューから[Services - Files]を選択します。

左側のメニューから[Data Protection - Policies]を選択し、「+New Policy」をクリックします。

まずは左側の項目にてSmart DRで保護対象のFilesを選択し、「Edit」をクリックします。

Files内の共有フォルダ一覧が表示されるので、保護対象の共有フォルダにチェックを入れます。
合わせて下部のチェックボックスにチェックを入れることで、今後Filesで作成された共有フォルダを自動的に保護対象に含めることが可能になります。
保護対象を選択後、「Done」をクリックします。

もとの画面に戻り、中央からレプリケーション間隔と右にはDR側クラスターに存在するレプリケーション先のFilesを指定します。
なお、レプリケーション間隔(RPO)は最短10分から指定が可能です。

また、初回のレプリケーションを即時またはスケジュールを指定して実行することが可能です。
今回作成したポリシーは、メイン側クラスターに存在する「FilesA」のという名前のFiles内に存在する全ての共有フォルダを、DR側クラスターの「FilesA-DR」というFilesへ10分毎にレプリケーションするように設定されたポリシーになります。

最後に任意のポリシー名を指定して、ポリシーの作成を完了します。

ポリシー作成後

ポリシーが正常に作成されると、一覧に作成したポリシーが表示されます。

左側メニューの[Protected File Servers]を選択すると、作成したポリシーに対応するFilesのステータスが表示されます。
アイコンの状態からメイン側クラスターに存在する[FilesA]がActiveとなり、DR側クラスターに存在する[FilesA-DR]がStandbyのステータスであることが確認できます。

左側メニューの[Replication jobs]からポリシーで設定された共有フォルダごとのレプリケーションのタスクが確認できます。
ポリシーにて設定したRPOを満たせていない場合は、[RPO Compliance]列が赤文字の✕が表示されます。

それぞれのタスクをクリックすると、詳細が確認できます。


共有フォルダの状態

レプリケーションが完了すると、双方のFilesで同じフォルダが存在しDR側には書込不可を表すアイコンが表示されます。

クライアントからも同様にフォルダとファイルが存在することが確認できます。

スタンバイ状態であるDR側のFilesに書込を実施しようとすると、不整合な状態にならないように拒否されるようになっています。

Filesのルート共有フォルダのNTFSアクセスを確認すると、スタンバイ状態のFilesには書込ができないように調整されていることがわかります。


概要・設定編のまとめ

今回はSmart DRの設定周りをメインに紹介させていただきました。
色々と説明しましたが、全体を通して見てみるとSmart DRの設定方法はPrism Centralから保護ポリシーを作成するだけのため、とても簡単に設定することができます。

次回はSmart DRによるフェイルオーバー時の動きなどを紹介させていただきます。
詳しくは次回の記事をご覧いただければと思いますが、フェイルオーバーなどの実施についても非常に簡単に実施することができます。