NDBダッシュボードのデータ使用量ウィジェットにある「従来のクローニングと比較した節約量」メトリックは、従来のフルコピークローニング方式と比較したNDBのクローニング技術の効率性を示しています。NDBは、Nutanixのほぼゼロバイトのクローニング機能を活用しており、ベースデータを共有し、変更点（差分）のみ​​を保存することで軽量クローンを作成します。このメトリックは、従来のクローニングのようにデータセット全体を複製するのではなく、これらの効率的なクローンを使用することで節約できるディスク容量を具体的に定量化しています。これは、データベースのプロビジョニングと管理におけるNDBのストレージ最適化を強調するものです。

NDB上のデータベースにPostgreSQLデータベースサーバーVMを登録するには、データベースのデータファイルとログファイルを、オペレーティングシステムおよびバイナリインストールとは別のマウントポイントに配置する必要があります。
これは、NDBがマウントポイントをデータベースサーバーVMとデータベースの識別子として使用するためです。データファイルとログファイルがオペレーティングシステムまたはバイナリインストールと同じマウントポイントにある場合、NDBはそれらを有効なデータベースサーバーVMまたはデータベースとして認識できません。したがって、管理者はデータファイルとログファイル用に別のマウントポイントを作成し、登録プロセス中にそれを指定する必要があります。

ストレッチ VLAN は、複数の Nutanix クラスタにまたがる仮想ネットワークであり、同じサブネットを使用する異なるクラスタ上の VM 間の通信を可能にします。ストレッチ VLAN を使用すると、どのクラスタからもアクセス可能な仮想 IP アドレス (VIP) を必要とする HAProxy VM などの NDB コンポーネントの高可用性と負荷分散を実現できます。NDB で 2 つのクラスタにまたがるストレッチ VLAN を追加するには、管理者は 2 つの前提条件を満たす必要があります。VLAN が静的であること、および両方のクラスタが NDB に登録されていることです。静的 VLAN は、NDB によって自動的に作成および管理される IPAM VLAN とは異なり、管理者が手動で作成および構成する VLAN です。静的 VLAN は NDB のストレッチ VLAN に追加できますが、IPAM VLAN は追加できません。NDB はクラスタとそのネットワークの情報とアクセス権を必要とするため、ストレッチ VLAN を追加する前に両方のクラスタを NDB に登録する必要があります。管理者は、Prism Element の詳細、エージェント ネットワーク構成、およびストレージ コンテナー情報を使用して、クラスタを NDB に登録できます。もう1つのオプションである Nutanix Cluster Management は、NDB でストレッチ VLAN を追加するための前提条件ではありません。Nutanix Cluster Management は、管理者が単一の NDB UI から複数の Nutanix クラスターを管理できる機能で、クラスターの作成や削除、ノードの追加や削除、クラスター操作の実行などが可能です。VLAN は NDB ではなく Prism Element で作成および構成されるため、ストレッチ VLAN を追加する際に Nutanix Cluster Management は必要ありません。

Nutanix Database Service (NDB) は、PostgreSQL のマイナーバージョンアップグレードの自動化をサポートしています。
パッチを適用する前に、管理者は新しいソフトウェアプロファイルを作成する必要があります。これは、ソフトウェアプロファイルにはデータベースエンジンのバイナリと、データベースエンジンを実行するために必要なその他のソフトウェアが含まれているためです。したがって、マイナーバージョンのアップグレードを適用するには、更新されたバイナリを含む新しいソフトウェアプロファイルを作成する必要があります。新しいソフトウェアプロファイルが作成されたら、それを使用してPostgreSQLデータベースにパッチを適用できます。

NDB HA は、NDB サービスとそのコンポーネントに高可用性と耐障害性を提供​​する機能です。NDB HA は、複数の Nutanix クラスタにまたがる API サーバー VM、リポジトリ VM、および HAProxy VM のクラスタを作成します。各コンポーネントには、同期されたリーダーとフォロワーのセットがあり、障害発生時にはフォロワーがリーダーの役割を引き継ぐことができます。NDB HA は、NDB コンポーネントの健全性と状態を監視し、可能な場合は自動フェイルオーバーとリカバリを実行します。ただし、一部の障害シナリオでは、NDB サービスを復旧するために管理者による手動介入が必要になる場合があります。そのようなシナリオの 1 つは、複数の API サーバー VM がダウンしている場合です。API サーバー VM は、NDB UI および CLI からのリクエストの処理、リポジトリ VM および HAProxy VM との通信を担当します。複数の API サーバー VM がダウンすると、NDB サービスが利用できなくなったり不安定になったりする可能性があり、管理者は影響を受ける API サーバー VM を手動で再起動または再デプロイする必要があります。その他のオプションについては、NDB HA が自動的に処理するため、復旧に手動操作は必要ありません。リポジトリVMが1つダウンした場合、NDB HAは最新のデータを持つ別のリポジトリVMにフェイルオーバーします。HAProxy VMが複数ダウンした場合、NDB HAは残りのHAProxy VMにトラフィックをルーティングします。NDBサーバープロセスがダウンした場合、NDB HAはプロセスを再起動するか、別のAPIサーバーVMにフェイルオーバーします。