NFS またはその他の共有ストレージ ボリュームは、VMware Cloud Director サーバ グループ内のすべてのサーバからアクセスできるようにする必要があります。VMware Cloud Director は、転送サーバ ストレージを、アプライアンス クラスタの管理に使用するほか、アップロード、ダウンロード、および外部で公開またはサブスクライブされたカタログ アイテムの一時ストレージとして使用します。

重要： VMware Cloud Director アプライアンスは、NFS タイプの共有ストレージのみをサポートします。アプライアンスのデプロイ プロセスには、NFS 共有転送サーバ ストレージのマウントが含まれます。 VMware Cloud Director アプライアンスは、ディレクトリの権限と所有権など、デプロイ中に NFS 共有のほとんどの詳細も検証します。有効な NFS マウント ポイントが存在し、 VMware Cloud Director アプライアンス インスタンスにアクセスできることを確認する必要があります。
サーバ グループの各メンバーは、このボリュームを同じマウントポイント ( /opt/vmware/vcloud-director/data/transfer) にマウントします。このボリュームの領域は、次のような多くの方法で使用されます。
  • 転送中に、アップロードとダウンロードがこのストレージを占有します。転送が完了すると、アップロードとダウンロードはストレージから削除されます。60 分間進行のない転送は、期限切れとしてマーキングされ、システムによってクリーンアップされます。大きいイメージが転送される可能性があるため、この用途には少なくとも数百ギガバイトを割り当てることをお勧めします。
  • 外部に公開され、公開されたコンテンツのキャッシュが有効にされているカタログ内のカタログ アイテムが、このストレージを占有します。外部に公開されても、キャッシュを有効にしていないカタログ アイテムは、このストレージを占有しません。クラウド内の組織に対し、外部公開されるカタログの作成を許可すると、数百あるいは数千のカタログ アイテムがこのボリューム上の容量を必要とすると想定できます。各カタログ アイテムのサイズは、圧縮された OVF 形式の仮想マシン程度のサイズです。
  • VMware Cloud Director は、アプライアンス データベースのバックアップを転送共有の pgdb-backup ディレクトリに格納します。これらのバックアップ バンドルは、大きな容量を使用する場合があります。
  • 複数セルのログ バンドル コレクタは、この容量を占有します。
  • アプライアンス ノードのデータと response.properties ファイルはこの容量を占有します。
注： 転送サーバ ストレージのボリュームには、将来の拡張のための容量が必要です。
注： NFS のダウンタイムにより、 VMware Cloud Director アプライアンス クラスタの機能が誤動作することがあります。NFS が停止している場合、またはアクセスできない場合、アプライアンス管理ユーザー インターフェイスは応答しません。影響を受ける可能性のあるその他の機能として、障害が発生したプライマリ セルのフェンス、スイッチオーバー、スタンバイ セルの昇格などがあります。
注： NFS に Debian ベースの Linux ディストリビューションを使用している場合、データベース バックアップの作成が失敗する可能性があります。詳細と回避策については、 KB94755 を参照してください。

共有ストレージ オプション

従来の Linux ベースの NFS サーバやほかのソリューション（Microsoft Windows Server、 VMware vSAN File Service の NFS 機能など）では、共有ストレージを使用できます。 vSAN 7.0 以降では、 vSAN File Service 機能で NFS 3.0 および NFS 4.1 プロトコルを使用して、NFS 共有をエクスポートすることができます。
重要： vSAN を使用して NFS 共有をエクスポートする場合は、 vSAN のバージョン 7.0 U3 以降または 8.0 U1 以降を使用する必要があります。
vSAN File Service の詳細については、 VMware vSphere 製品のドキュメントの『 Administering VMware vSAN』ガイドを参照してください。

NFS サーバを構成するための要件

NFS サーバの構成には、 VMware Cloud Director が NFS ベースの転送サーバ ストレージの場所との間でファイルの読み書きができるようにするための特定の要件があります。これにより、 vcloud ユーザーは標準的なクラウド操作を実行でき、 root ユーザーは複数セルのログ収集を実行できます。
  • NFS サーバのエクスポート リストでは、VMware Cloud Director サーバ グループ内の各サーバ メンバーが、エクスポート リストで指定された共有の場所に対する読み取り/書き込みアクセス権を持つようにする必要があります。このアクセス権により、vcloud ユーザーは共有の場所との間でファイルの読み取りおよび書き込みを実行できます。
  • NFS サーバでは、VMware Cloud Director サーバ グループ内の各サーバ上の root システム アカウントによる共有場所への読み取り/書き込みアクセスを許可する必要があります。このアクセス権により、vmware-vcd-support スクリプトでマルチ セル オプションを使用することで 1 つのバンドル内のすべてのセルからのログを一度に収集できます。この要件は、この共有の場所の NFS エクスポート構成で no_root_squash を使用することで満たすことができます。

Linux NFS サーバの例

Linux NFS サーバに、 VMware Cloud Director サーバ グループ用の転送領域として /nfs/vCDspace の場所に vCDspace という名前のディレクトリがある場合、このディレクトリをエクスポートするには、その所有権と権限が root:root および 750 であることを確認する必要があります。 vCD-Cell1-IP、 vCD-Cell2-IP、 vCD-Cell3-IP という名前の 3 つのセルに共有場所への読み取り/書き込みアクセスを許可するメソッドは、 no_root_squash メソッドです。 /etc/exports ファイルに次の行を追加する必要があります。 
/nfs/vCDspace vCD_Cell1_IP_Address(rw,sync,no_subtree_check,no_root_squash) 
/nfs/vCDspace vCD_Cell2_IP_Address(rw,sync,no_subtree_check,no_root_squash)
/nfs/vCDspace vCD_Cell3_IP_Address(rw,sync,no_subtree_check,no_root_squash)

このエクスポート行で、セルの IP アドレスとその直後の左括弧との間には空白文字を置きません。セルから共有の場所にデータが書き込まれているときに NFS サーバを再起動した場合、エクスポート設定で sync オプションを使用していると共有場所のデータの破損を避けることができます。エクスポート設定で no_subtree_check オプションを使用すると、ファイル システムのサブディレクトリがエクスポートされるときの信頼性が向上します。

VMware Cloud Director サーバ グループ内のサーバのすべてがこの NFS 共有をマウントできるように、NFS サーバの /etc/exports ファイルに、これらのサーバに対応するエントリが必要になります。NFS サーバ上の /etc/exports ファイルに変更を加えた後、exportfs -a を実行して、すべての NFS 共有を再度エクスポートします。

次の操作

VMware Cloud Director アプライアンスのデプロイ準備の一環として、「VMware Cloud Director 用 NSX のインストールと構成」または「VMware Cloud Director 用 NSX Data Center for vSphere のインストールと構成」を参照することを推奨します。