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に限定してご利用ください。

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を予め準備しています。

利用手順

利用手順は以下の流れになります。
　１．オブジェクトストレージの準備（本記事では割愛）

　２．My Nutanixアカウントへ接続（本記事では割愛）

　３．Data Lensをアクティベート

　４．Data Lensへ対象のFilesを登録

　５．Smart Tieringの設定

　６．階層化の実行

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

③の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」をクリックし、階層化されるデータの条件を指定します。
条件は「最後にアクセスしてから経過した日数」と「ファイルのサイズ」の２つを指定できます。
また、「Exclude Shares」から階層化する共有フォルダを個別に指定することが可能です。

※こちらもデモのため、1日アクセスがないデータを階層化対象としています。

３つの項目の設定が完了すると、中央のグラフに赤枠の網掛けの領域が表示され、階層化対象のデータが確認できます。

デモ環境では先程設定した条件に当てはまるデータが2.42GiB存在することがわかります。

この状態で、右の「Tier Data」をクリックします。

右側のTiered  Dataの値が増加したことが確認できます。
また、先程網掛けで表示されたグラフがなくなり、Used Spaceの値が減少していることも確認できます。

※デモ環境では、「Tier Data」を実行してから数日間経過した画像のため、容量が異なっています…

まとめ

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

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

Nutanix（ESXi）からNutanix（AHV）への仮想マシン移行（Move編）

Nutanixが多くの企業で利用されるようになってから数年がたち、最近Nutanixのリプレースに関するお話を頂くことが増えて来ているように感じます。

私が対応している案件ではNutanixから他の環境（クラウドや他のHCI、3Tier）に移行したいという話は一つも聞くことがなく、再度Nutanixを調達されるということがほとんどのように感じています。

この際、同じハイパーバイザー間で移行、例えばESXi→ESXi、AHV→AHVという形であれば仮想マシンの移行作業作業は必要なく、既存クラスターに新しいノードを拡張し、古いノードを撤去するだけで簡単に機器を入れ替えることがです。

ただし、ESXi→AHVというように新しいNutanixで異なるハイパーバイザーを利用する場合は仮想マシンの移行について考えなければいけません。

今回は移行元のNutanixでESXi、移行先のNutanixでAHVを利用する場合の仮想マシン移行方法について、私なりの方法をまとめてみました。

移行方法

移行方法はNutanixから提供されているNutanix Moveと呼ばれる移行ツール、またはNutanixに標準で備わっているAsync DRとレプリケーション機能を組み合わせて利用するかのどちらか２つの方法を選択することになるかと思います。

この記事ではNutanix Moveで移行したパターンを紹介します。

Nutanix Moveで移行

Nutanix MoveはNutanixから提供される無償の移行ツールです。

Moveについては、以下のブログで詳しく紹介されています。

少し古い記事ですが、現在の最新バージョン4.1とそこまで大きな違いはありません。

・インフラ屋とアプリ屋のあいだ（AHVへの引っ越しは、Nutanix Moveで（その１））

Moveの使い方や特徴は本記事では割愛させていただきますが、構築、設定含め簡単に使えるツールとなっているのに加え、移行時のダウンタイムが非常に小さいなどのメリットがあります。

よくあるパターンとしては、3TierのESXi→AHVというような感じの移行を行う場合に利用されます。

移行元がNutanixの場合でも、ESXiまたはvCenterを指定して仮想マシンを移行することが可能です。

まず、移行先がAHVの場合はWindows仮想マシンへVirtIOドライバーがインストールされていないとまともに動かないので、VirtIOドライバーを導入する必要がありますが、Moveは移行時にVirtIOドライバーを自動的にインストールしてくれる機能が備わっています。

・移行元のESXi上で仮想マシン（Windows Server 2016）

移行元の仮想マシンでは固定IPを設定し、VMware Tools以外は特にインストールされていません。

この仮想マシンをMoveに登録し、移行の準備を行います。

これはMoveの設定画面の一部ですが、ここでVirtIOドライバーの自動インストールや移行先でMACアドレスを引き継ぐなどのオプションが設定できます。
今回はIPアドレスを移行先で引き継ぐオプションを選択してみます。

移行プラン作成後、自動的にVirtIOドライバーがインストールされていることが確認できます。（自動インストールにはVMware Toolsがインストールされていて、UACが無効化されている必要があります）

このタイミングで移行元の基盤でスナップショットを取得して、移行先に転送します。

Move画面からCutoverを選択することで、移行元の仮想マシン停止と移行先で仮想マシンを自動起動します。（一度再起動が行われます）

青枠には移行にかかる時間が表示される。

移行先のAHVで自動機能

移行先のNutanixで自動起動後、IPアドレスも移行元の環境と同様の設定が行われていることが確認できます。

このようにIPアドレス設定を保持した状態で、簡単に仮想マシンを移行することが可能です。

注意点

移行元の仮想マシンのNICタイプがVMXNET3が選択されている場合、移行先でうまくIPアドレスを引き継ぐことができず、DHCPから取得される設定になっていました。
現在のvSphere 7ではデフォルトがE1000になっていますが、VMXNET3のほうがパフォーマンスに優れるため、利用している環境は少なくないと想定されるので、環境によっては移行後の仮想マシンにて手動でIPアドレスを設定する必要が出てくると思われます。

ざっとNutanix Moveの制限事項を確認しましたが、VMXNET3だとIPアドレスが引き継げないという記載は見当たらなかったので、何かしら手を加えればできるかもしれませんが今回はこのような結果になりました。
移行元の環境でE1000を利用している場合は、移行先でIPアドレスを個別に設定する必要がないため、移行対象の仮想マシン台数が多い場合にはMoveでの移行も検討の余地があるかと思います。

次回はAsync DRを使った仮想マシンの移行について紹介してみます。

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

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

分析（Analysis）

まず、今回紹介する機能はPrism左上のメニューから選択できる「分析」タブ（英語表記ではAnalysis）になります。

こちらは必須の機能ではありませんが、Nutanix全体のパフォーマンス状況を確認できたり、障害発生時の切り分けに利用できる場合があります。

何ができるのか？

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

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

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

チャートの作成

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

分析画面ダッシュボードは最初の状態では何も表示されておらず、ここにチャートを追加していく形になります。

今回は例としてクラスター全体のCPU使用率を表示するチャートを作成してみます。

チャートには「指標チャート」と「エンティティチャート」の２種類が存在し、「指標チャート」はCPUやメモリなどのリソースに焦点を当てチャートを作成し、「エンティティチャート」はホストや仮想マシンなどに焦点を当てチャートを作成します。

今回は指標チャートを作成を試してみるので、まずは左上の「新規 - Chart(指標チャートを新規作成)」をクリックします。

任意の名前を入力し、項目[指標]には「Hypervisor CPU Usage (%)」を選択します。

項目[エンティティタイプ]には「Cluster」を選択し、項目[エンティティ]には分析対象のクラスターを選択し、「保存」をクリックします。

　※項目[指標]のテキストボックスに文字列を入力することで検索することができます。

　　非常に多くの選択肢が存在しますので、検索機能を利用して条件を探すことをおすすめします。

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

次に特定の仮想マシンCPU使用率のチャートを作成します。

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

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

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

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

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

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

チャートの編集

作成したチャートを修正することもできます。

チャート左上のチャート名をクリックし「Edit Chart」を選択します。

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

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

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

上記で説明した手順も簡単ですが、仮想マシン一覧などからチャートを作成することもできます。

仮想マシン一覧から任意の仮想マシンを選択し、下部にあるリソースグラフ右上にカーソルを合わせて、「分析ページにチャートを追加」をクリックします。

選択した仮想マシンリソースのチャートが分析ダッシュボードに表示されます。

なお、この手順で作成したチャートは画面遷移後に削除されてしまうため、「Save Chart」をクリックすることで、恒久的にチャート残すことができます。

まとめ

Nutanixのメリットの一つに仮想基盤の運用コストが軽減できるというものがあります。

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

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

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環境に短いダウンタイムで切り替えを行えるファイルサーバーとして提案もしやすいのではないかと思います。