5 記憶域の準備

各エンタープライズ・デプロイメントには共有記憶域が必要です。さらに、各ホストにはいくつかのプライベート記憶域が必要です。

プライベート記憶域は、ローカル・ディスクまたはストレージ・エリア・ネットワーク(SAN)上のディスク・スペースと考えることができ、それは、ホストのみが排他的に使用できるようになります。SAN上でプライベート記憶域を使用する利点(ローカル・ディスクに対しての)は、SAN内で使用可能な組込みのストレージ冗長性と高速バックアップ・テクノロジを利用でき、管理が容易になることです。

Exalogicアプライアンスには、ZFS記憶域アプライアンスが組み込まれています。この章では、標準的なエンタープライズ・デプロイメントのZFS記憶域の設定と構成に関するベスト・プラクティスについて説明します。

ローカル・ディスクを使用する利点は、一般的にアクセスが高速なことです。これは、基礎となるローカル・フラッシュ・ディスクへの直接アクセスが可能な物理デプロイメントに当てはまります。仮想デプロイメントでは、ローカル・ディスクは単にZFSストレージ上の仮想ディスクです。

この項の内容は次のとおりです。

ZFSの概念
この項では、標準的なエンタープライズ・デプロイメントのためのZFS記憶域の設定と構成に関する概念的な情報を提供します。
デフォルトのストレージ構成について
Oracle Exalogicアプライアンスを稼働すると、ストレージは次のデフォルトの特性を持ちます。
エンタープライズ・デプロイメントの記憶域の概要
この項では、共有の要件、読取り/書込みの要件、およびアーティファクト特性を含むエンタープライズ・デプロイメントの記憶域に関する情報を提供します。
エンタープライズ・デプロイメントのディレクトリ構造の理解
各Oracle Fusion Middlewareエンタープライズ・デプロイメントは、同様のディレクトリ構造に基づいています。このディレクトリ構造は、バイナリ、構成、およびランタイム情報を分離するように設計されています。
共有記憶域の概念
この項では、共有記憶域の概念について説明します。
エンタープライズ・デプロイメントの記憶域設計の考慮事項
この項では、記憶域設計上の考慮事項に関する情報を提供します(デプロイメント・タイプに固有の記憶域要件については、該当する製品のエンタープライズ・デプロイメント・ガイドを参照してください)。
エンタープライズ・デプロイメントのためのExalogic記憶域の準備
NISでユーザーおよびグループを作成し、ストレージ・アプライアンスのBUIを使用してプロジェクトを作成し、BUIを使用してプロジェクト内のシェアを作成して、物理的なExalogicのデプロイメント用の記憶域を準備します。

親トピック:エンタープライズ・デプロイメントのためのExalogicの準備

5.1 ZFSの概念

この項では、標準的なエンタープライズ・デプロイメントのためのZFS記憶域の設定と構成に関する概念的な情報を提供します。

ストレージ・プールについて
ZFSストレージ内の物理ディスクはストレージ・プールに割り当てられます。
プロジェクトについて
プロジェクトでは、シェアを管理するための共通管理コントロール・ポイントが定義されます。プロジェクト内のすべてのシェアは共通の設定を共有でき、論理ユニットとしてバックアップできます。
シェアについて
シェアは、サポートされているデータ・プロトコルを使用してアプライアンスのクライアントにエクスポートされる、ファイル・システムおよびLUNです。

5.1.1 ストレージ・プールについて

ZFSストレージ内の物理ディスクはストレージ・プールに割り当てられます。

ストレージ・プール内の領域は、すべてのシェアの間で共有されます。

5.1.2 プロジェクトについて

プロジェクトでは、シェアを管理するための共通管理コントロール・ポイントが定義されます。プロジェクト内のすべてのシェアは共通の設定を共有でき、論理ユニットとしてバックアップできます。

すべてのファイル・システムおよびLUNは、プロジェクトにグループ化されます。また、シェア・レベルに加えてプロジェクト・レベルでもクォータを強制できます。プロジェクトはそれ単独でも、論理的に関連するシェアをまとめてグループ化するために使用でき、共通の属性(累積されたスペースや書込み頻度など)に単一のポイントからアクセスできます。

注意:

Exalogicでは、LUNまたはiSCSIの使用はサポートされていません。サポートされている唯一のZFSの使用は、NFS共有によるものです。

5.1.3 シェアについて

シェアは、サポートされているデータ・プロトコルを使用してアプライアンスのクライアントにエクスポートされる、ファイル・システムおよびLUNです。

ファイル・システムでは、ファイル・ベースの階層がエクスポートされ、Exalogicマシンの場合、この階層にはIPoIB上のNFSを使用してアクセスできます。プロジェクト/シェア・タプルは、プール内のシェアに対する一意の識別子です。複数のプロジェクトには同じ名前の複数のシェアを格納できますが、単一のプロジェクトには同じ名前の複数のシェアを格納できません。単一のプロジェクトには、ファイル・システムとLUNを両方とも格納できます。これらは、同じ名前空間を共有します。

ファイル・システムは必要に応じて、動的に拡大または縮小できますが、シェア単位で領域制限を適用することもできます。プロジェクト内のすべてのシェアは論理ユニットとしてバックアップできます。

5.2 デフォルトのストレージ構成について

Oracle Exalogicアプライアンスを稼働すると、ストレージは次のデフォルトの特性を持ちます。

Sun ZFS Storage 7320アプライアンス上のストレージ・ディスクは、デフォルトでexalogicなどの単一のストレージ・プールに割り当てられます。Oracle Exalogicマシンのすべての計算ノードは、ストレージ・アプライアンスの両方のサーバー・ヘッドにアクセスできます。ストレージ・プールは、サーバー・ヘッドの1つを使用し、サーバー・ヘッドは、コントローラとも呼ばれます。サーバー・ヘッドは、アクティブ-パッシブのクラスタ構成を使用します。Exalogic計算ノードは、ストレージ・プールの分布に基づいて、サーバー・ヘッドおよびマウント・ポイントのホスト名またはIPアドレスにアクセスします。
アクティブのサーバー・ヘッドが故障すると、パッシブのサーバー・ヘッドがストレージ・プールをインポートしてサービスの提供を開始します。計算ノードで、稼働しているサーバー・ヘッドからストレージ・プールがサービスを開始するまで、ユーザーはサービスの一時停止を経験することがあります。ただし、この遅延はクライアントの動作には影響せず、ディスクI/Oにのみ影響します。
デフォルトでは、データはミラーリングされるので、システムの信頼性とパフォーマンスが向上します。デフォルトのストレージ構成は製造時に行われており、次のシェアが組み込まれています。
- Exalogicの計算ノードごとに2つの排他的なNFS共有(1つはクラッシュダンプ用、もう1つは汎用)があります。このシナリオでは、要件に基づいてこれらのシェアのアクセス制御を実装できます。
- すべての計算ノードからアクセスされる、2つの共通NFS共有(1つはパッチ用、もう1つは汎用)。

5.3 エンタープライズ・デプロイメントの記憶域の概要

この項では、共有の要件、読取り/書込みの要件、およびアーティファクト特性を含むエンタープライズ・デプロイメントの記憶域に関する情報を提供します。

共有記憶域を準備する方法を決定する場合は、次の点を考慮してください。

共有の要件

アーティファクトは、共有、非共有(非公開)、または使用可能のいずれかである必要があります。

共有: アーティファクトは共有記憶域にあり、すべてのクライアント・マシンから同時に表示およびアクセスできます。
使用可能: アーティファクトは共有記憶域にありますが、一度に1つのクライアント・マシンのみがアーティファクトを表示およびアクセスできます。このマシンに障害が発生すると、別のクライアント・マシンがアーティファクトにアクセスできます。
非共有: アーティファクトはローカル記憶域に置くことができ、他のマシンからアクセスできる必要はありません。

読取り/書込みの要件

アーティファクトには、特定の読取り/書込みの要件もあります。

読取り専用: このアーティファクトはまれにしか変更されませんが、実行時にのみ読み込まれます。
読取り-書込み: このアーティファクトは、実行時に読み書きされます。

アーティファクトの特性

前述の要件を踏まえ、標準的なエンタープライズ・デプロイメントでデプロイされるアーティファクトは、次のように分類できます。

アーティファクト・タイプ	共有	読取り/書込み
バイナリ - アプリケーション層	共有	読取り専用
バイナリ - Web層	プライベート	読取り専用
管理対象サーバー・ドメイン・ホーム	プライベート	読取り-書込み
管理サーバー・ドメイン・ホーム	使用可能	読取り-書込み
ランタイム・ファイル	使用可能	読取り-書込み
ノード・マネージャ構成	プライベート	読取り-書込み
アプリケーション固有ファイル	共有	読取り-書込み

5.4 エンタープライズ・デプロイメントのディレクトリ構造の理解

各Oracle Fusion Middlewareエンタープライズ・デプロイメントは、同様のディレクトリ構造に基づきます。このディレクトリ構造は、バイナリ、構成、およびランタイム情報を分離するように設計されています。

バイナリは、Oracleソフトウェアのインストールとして定義されます。バイナリには、JDK、WebLogic Server、および使用されるOracle Fusion Middlewareソフトウェア(Oracle Identity and Access ManagementやWebCenterなど)などが含まれます。

サーバー・ドメイン・ホーム・ディレクトリは、実行時に読み書きされます。

実行時ディレクトリは、実行時に書き込まれ、JMSキュー・ファイルなどの情報が保持されます。サーバー・ドメイン・ホーム・ディレクトリは、実行時に読み書きされます。

この項の内容は次のとおりです。

共有バイナリ
すべてのマシンは、同じバイナリ・セットを使用してプロセスを実行します。バイナリは一度インストールされ、パッチ適用やアップグレード中にのみ変更されます。
プライベートまたは共有の管理対象サーバー・ドメイン・ホーム
管理対象サーバー・ドメイン・ホームは、ローカルのホスト・マシン上で管理対象サーバーを実行するために使用されます。
管理サーバーのドメイン・ホーム
管理サーバーが実行されるドメイン・ホームは、どのマシンにもマウントできる別のボリュームに含まれています。
共有ランタイム・ファイル
クラスタのすべてのメンバーが使用できる必要のあるファイルおよびディレクトリは、それぞれ独自のディレクトリに分かれています。
ローカルのノード・マネージャ・ディレクトリ
各クライアント・マシンには、それぞれ独自のノード・マネージャおよびノード・マネージャ構成ディレクトリがあります。
共有アプリケーション・ファイル
共有して同時にアクセス(読取り/書込み)する必要のあるファイルは、アプリケーションに依存します。
標準的なエンタープライズ・デプロイメントのディレクトリ構造図
次の図は、標準的なエンタープライズ・デプロイメントにおける、共有記憶域およびローカル記憶域の推奨される使用方法を示しています。

5.4.1 共有バイナリ

すべてのマシンは、同じバイナリ・セットを使用してプロセスを実行します。バイナリは一度インストールされ、パッチ適用やアップグレード中にのみ変更されます。

最大の可用性と保護のため、冗長バイナリを作成する(つまり、互いのミラーとなる2つの異なるシェアを作成する)ことをお薦めします。1つのシェアは奇数番号のホストにマウントされ、1つのシェアは偶数番号のホストにマウントされます。これは、1セットのバイナリの破損がシステム全体に影響を与えないようにするためです。

5.4.2 プライベートまたは共有の管理対象サーバー・ドメイン・ホーム

管理対象サーバー・ドメイン・ホームは、ローカルのホスト・マシン上で管理対象サーバーを実行するために使用されます。

パフォーマンス上の理由から、これらのドメイン・ホームは、ホスト・マシンにアタッチされたプライベート記憶域に置くことをお薦めします。

5.4.3 管理サーバーのドメイン・ホーム

管理サーバーが実行されるドメイン・ホームは、どのマシンにもマウントできる別のボリュームに含まれています。

これにより、管理サーバーをホストしていたマシンが故障したり、その他の理由で使用できない場合に、管理サーバーがすぐに使用できるようになります。

5.4.4 共有ランタイム・ファイル

クラスタのすべてのメンバーが使用できる必要のあるファイルおよびディレクトリは、それぞれ独自のディレクトリに分かれています。

これらは、JMSファイル、トランザクション・ログ、その他のアーティファクトなど、クラスタの1つのメンバー・マシンにのみ属していて、フェイルオーバーの際に他のマシンで使用可能にする必要のあるものです。

5.4.5 ローカルのノード・マネージャ・ディレクトリ

各クライアント・マシンには、それぞれ独自のノード・マネージャおよびノード・マネージャ構成ディレクトリがあります。

ノード・マネージャは1台の物理マシンに関連付けられており、オプションで、これらのディレクトリをプライベート記憶域に置くこともできます。

5.4.6 共有アプリケーション・ファイル

共有して同時にアクセス(読取り/書込み)する必要のあるファイルは、アプリケーションに依存します。

Oracle Fusion Middleware WebLogicインフラストラクチャに含まれるファイルにはこれを必要とするものはありませんが、一部のFusion Middleware製品(Oracle WebCenter Contentなど)およびカスタム・アプリケーションでは、ディスク上に共有ファイルを必要とする場合があります。

5.4.7 標準的なエンタープライズ・デプロイメントのディレクトリ構造図

次の図は、標準的なエンタープライズ・デプロイメントにおける、共有記憶域およびローカル記憶域の推奨される使用方法を示しています。

図5-1 推奨される共有記憶域のディレクトリ構造

図5-2 推奨されるプライベート記憶域のディレクトリ構造

図5-3 推奨されるプライベート・バイナリ記憶域のディレクトリ構造

「図5-3 推奨されるプライベート・バイナリ記憶域のディレクトリ構造」の説明

プライベート・バイナリ記憶域は、通常、Web層が別のホストに存在する場合(仮想デプロイメントなど)にのみ必要です。

5.5 共有記憶域の概念

この項では、共有記憶域の概念について説明します。

この項の内容は次のとおりです。

共有記憶域のプロトコルおよびデバイス
ZFSは、ブロック記憶域またはNFS共有として記憶域を提供できます。このドキュメントでは、ネットワーク・ファイル・システム(NFS)の設定について説明します。ZFSでは、NFSバージョン3(v3)およびNFSバージョン4(v4)がサポートされています。
NFSバージョン3
NFSバージョン3(v3)は、おそらく、リモートの共有ファイル・システムを必要とするUNIXクライアントで最も一般的な標準です。
NFSバージョン4
NFSバージョン4(v4)には、NFS v3を超えるいくつかの利点があります。1つの利点は、NISなどの認証プロトコルのサポートにより、UIDに依存せずにユーザー権限をマッピングすることです。もう1つの利点は、リースによるファイル・ロックの有効期限のサポートです。

5.5.1 共有記憶域のプロトコルおよびデバイス

ZFSは、ブロック記憶域またはNFS共有として記憶域を提供できます。このドキュメントでは、ネットワーク・ファイル・システム(NFS)の設定について説明します。ZFSでは、NFSバージョン3(v3)およびNFSバージョン4(v4)がサポートされています。

共有ファイル・システムとは、ファイル・システムと、複数の同時アクセスを管理するために使用される一連のプロトコルの両方です。これらのプロトコルの中で最も一般的なものは、UNIXクライアント用のNFSです。このソリューションは、ZFSやEXT3などのバックエンドのファイル・システムと、アクセスを管理および仲介するためのサーバー・プロセス(NFSDなど)で構成されています。

5.5.2 NFSバージョン3

NFSバージョン3(v3)は、おそらく、リモートの共有ファイル・システムを必要とするUNIXクライアントで最も一般的な標準です。

クライアント・マシンとストレージ・サーバー間の権限は、ユーザーのUIDを使用してマッピングされます。NFS v3は、ほとんどのデバイスで構成およびエクスポートできます。クライアント・マシンは、次に示すようなコマンドを使用してリモート・デバイスをローカルにマウントできます。

$ mount -t nfs storage_machine:/export/nfsshare /locmntddir -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsi ze=32768

このコマンドは、リモートのファイル・システムを/locmnntdirにマウントします。ここで指定した値のほとんどはデフォルトで、NFS v3デバイスを次のようにマウントすることもできます。

$ mount -t nfs storage_machine:/export/nfsshare /locmntddir -o nointr,timeo=300

rsize、wsizeおよびtimeoの適正な値は、クライアント・マシンとストレージ・サーバー間のネットワークの属性によって異なります。たとえば、タイムアウト値を大きくすると、タイムアウト・エラーを最小限に抑えることができます。

属性noacとactimeoは、ここでは使用していません。これらは属性のキャッシングを無効にするために使用し、NFS上にOracleデータ・ファイルなどのオブジェクトが置かれている場合に必要になることがあります。ただし、ほとんどのWebLogicアプリケーションや、SOA、WebCenter、BIなどのFusion Middlewareアプリケーションでは、これらは必要ありません。これらのパラメータを有効にすると、パフォーマンスの低下も起こります。

その他のオプションとしてnoatimeがあり、読取り集中型のアプリケーションで、アクセス時間の書込みを省略して少しだけ性能を向上させます。

5.5.3 NFSバージョン4

NFSバージョン4(v4)には、NFS v3を超えるいくつかの利点があります。1つの利点は、NISなどの認証プロトコルのサポートにより、UIDに依存せずにユーザー権限をマッピングすることです。もう1つの利点は、リースによるファイル・ロックの有効期限のサポートです。

指定した時間が経過すると、ストレージ・サーバーは要求のないファイル・ロックを解放します。デフォルトのリース有効期限は、ストレージ・サーバーによって異なります。標準的な値は、45または120秒です。Sun ZFSシステムでは、デフォルトは90秒です。サーバーが障害を起こし、別のサーバーから障害の発生したサーバーが所有するファイルを要求またはアクセスする必要がある、というフェイルオーバーのシナリオでは、リースの有効期限が切れた後でそれを実行できます。この値は、新規サーバーがファイルに対するロックを正常に取得できるように、フェイルオーバー時間よりも短く設定する必要があります。たとえば、JMSファイル・ベースの永続性を使用するクラスタでは、サーバーの移行時間よりも短く設定する必要があります。

これは、ロックが無期限に保持されるNFS v3とは異なります。異常終了したプロセスが保持したままのロックは、NFS v3では手動で解放する必要があります。

NFS v3と同様に、NFS v4ファイル・システムをLinuxにマウントできます。

$ mount -t nfs4 storage_machine:/export/nfsv4share /locmntddir -o
nointr,timeo=300

5.6 エンタープライズ・デプロイメントの記憶域設計の考慮事項

この項では、記憶域設計上の考慮事項に関する情報を提供します(デプロイメント・タイプに固有の記憶域要件については、該当する製品のエンタープライズ・デプロイメント・ガイドを参照してください)。

「標準的なエンタープライズ・デプロイメントのディレクトリ構造図」で説明されている標準的なディレクトリ構造に基づいて、記憶域は次のように分類できます。

表5-1 エンタープライズ・デプロイメントの記憶域設計の考慮事項の概要

プロジェクト	シェア	マウント・ポイント
product_binaries	shared_binaries	`/u01/oracle/products`
	webhost1_local_binaries	`/u01/oracle/products`
	webhost2_local_binaries	`/u01/oracle/products`
product_config	shared_config	`/u01/oracle/config`
	host1_local_config	`/u02/private/oracle/config`
	host2_local_config	`/u02/private/oracle/config`
Runtime	shared-runtime	`/u01/oracle/runtime`

このモデルを使用すると、インストール後にすべてのバイナリを製品レベルで読取り専用に設定できます。構成情報は、引き続き読み書きできます。

プロジェクト・レベルでバックアップを取ることができます。ディザスタ・リカバリでは、プロジェクト・レベルでコンテンツをレプリケートでき、必要なときにのみバイナリをレプリケートし、構成/jmsキューをより頻繁にレプリケートできます。

5.7 エンタープライズ・デプロイメントのためのExalogic記憶域の準備

NISでユーザーおよびグループを作成し、ストレージ・アプライアンスのBUIを使用してプロジェクトを作成し、BUIを使用してプロジェクト内のシェアを作成して、物理的なExalogicのデプロイメント用の記憶域を準備します。

この項の内容は次のとおりです。

前もって必要なStorage Applianceの構成タスク
この項では、ストレージ・アプライアンスの前提条件について説明します。
NISでのユーザーおよびグループの作成
この手順はオプションです。オンボードのNISサーバーを使用する場合は、この項の手順を使用してユーザーおよびグループを作成できます。
ストレージ・アプライアンスのブラウザ・ユーザー・インタフェース(BUI)を使用したプロジェクトの作成
アプライアンスを推奨するディレクトリ構造に構成するには、Sun ZFS Storage 7320アプライアンスのブラウザ・ユーザー・インタフェース(BUI)を使用してカスタム・プロジェクトを作成します。
BUIを使用したプロジェクト内のシェアの作成
プロジェクトを作成したら、次はプロジェクト内で必要なシェアを作成します。
共有へのローカル・ルート・アクセスの許可
計算ノードまたは仮想マシンがZFSシェアにアクセスできるようにするには、そのためのNFS例外を追加する必要があります。

5.7.1 前もって必要なStorage Applianceの構成タスク

この項では、ストレージ・アプライアンスの前提条件について説明します。

Sun ZFS Storage 7320 Applianceが設定されていて初期構成されていることが、このガイドの指示の前提になります。具体的には、『Oracle Exalogic Elastic Cloudマシン・オーナーズ・ガイド』の次の項を確認済であることが前提となります。

次の例は、標準的なエンタープライズ・デプロイメントの例です。インストールする製品用に作成する必要のあるシェアのリストについては、該当する製品のエンタープライズ・デプロイメント・ガイドを参照してください。

前提条件
スタート・ガイド
Sun ZFS Storage 7320 Applianceの概要
構成の概要
ネーミング・サービス

5.7.2 NISでのユーザーおよびグループの作成

次の手順はオプションです。オンボードのNISサーバーを使用する場合は、この項の手順を使用してユーザーおよびグループを作成できます。

まず、ストレージのBUIにログインして、NISサーバーの名前を決定します。例:

次のURLを使用してZFS記憶域アプライアンスにログインします。
```
https://exalogicsn01-priv:215
```
記憶域管理者のユーザー名(root)とパスワードを使用してBUIにログインします。
「Configuration」→「Services」に移動します。
「NIS」をクリックします。
実行中の場合は、その隣に緑色の点があります。実行されておらず、NISを構成する場合は、『Oracle Exalogic Elastic Cloudマシン・オーナーズ・ガイド』を参照してください
「NIS」をクリックします。名前付きNISサーバーが表示されます。NISサーバーの1つをメモします。
NISサーバーの名前がわかったら、rootでNISサーバーのターミナル・ウィンドウを開き、次の手順を実行します。
「NISでのユーザーおよびグループの作成」の説明に従って、NISマスター・サーバーでユーザーを作成します。
次の手順を実行して、ypにユーザーを追加します。
1. /var/ypディレクトリに移動します。
2. 次のコマンドを実行します。
```
make -C /var/yp
```
3. 必要に応じて、次のコマンドを使用してサービスを再起動します。
```
service ypserv start
service yppasswdd start
service rpcimapd start
service ypbind start
```
4. 次のコマンドを発行して、ユーザーおよびグループがNISに表示されることを検証します。
```
ypcat passwd
```
  および
```
ypcat group
```

5.7.3 ストレージ・アプライアンスのブラウザ・ユーザー・インタフェース(BUI)を使用したプロジェクトの作成

推奨ディレクトリ構造のアプライアンスを構成するには、Sun ZFS Storage 7320アプライアンスのブラウザ・ユーザー・インタフェース(BUI)を使用してカスタム・プロジェクトを作成します。

Sun ZFS Storage 7320 Applianceを設定して構成すると、アプライアンスにはデフォルトのプロジェクトと共有のセットがあります。詳細は、『Oracle Exalogic Elastic Cloudマシン・オーナーズ・ガイド』でデフォルトのストレージ構成に関する項を参照してください。

この項では、エンタープライズ・デプロイメント用に新規プロジェクトを作成する具体的な手順について説明します。BUIを使用してカスタム・プロジェクトを作成する方法の詳細は、『Oracle Exalogic Elastic Cloudマシン・オーナーズ・ガイド』でカスタム・プロジェクトの作成に関する項を参照してください。

Sun ZFS Storage 7320アプライアンスで、新規カスタム・プロジェクトを作成する手順は次のとおりです。

次のURLを使用してZFS記憶域アプライアンスにログインします。
```
https://exalogicsn01-priv:215
```
記憶域管理者のユーザー名(root)とパスワードを使用してBUIにログインします。
「Shares」タブ、「Projects」サブタブの順にクリックして、「Projects」ページに移動します。
BUIで「Project」パネルが表示されます。
「Projects」タイトルの横にある「Add」をクリックして、「Create Project」ウィンドウを表示します。
プロジェクトの名前を入力します。例: EDG_Binaries

「Apply」をクリックします。
新規に作成されたプロジェクトの横にある「Edit Entry」をクリックします。
プロジェクト・ページの「General」タブをクリックし、プロジェクトのプロパティを設定します。
次の値を更新します。
- Mountpoint: /export/EDG_Binariesに設定します
- 「Default Settings Filesystems」セクションで、次の値を設定します。
  - User: oracle
  - Group: oinstall
  - Permissions: RWX RWX R_X
エンタープライズ・デプロイメントの目的で、残りのプロジェクト・プロパティのデフォルトを受け入れることができます。
ここで設定可能なプロパティの詳細は、『Oracle Exalogic Elastic Cloudマシン・オーナーズ・ガイド』でプロジェクト設定に関する表を参照してください。
「General」タブで「Apply」をクリックしてプロジェクトを作成します。
作成するプロジェクトごとに、この手順を繰り返します。

5.7.4 BUIを使用したプロジェクト内のシェアの作成

プロジェクトを作成したら、次はプロジェクト内で必要なシェアを作成します。

BUIを使用してカスタム共有を作成する方法の詳細は、『Oracle Exalogic Elastic Cloudマシン・オーナーズ・ガイド』でカスタム共有の作成に関する項を参照してください。

それぞれのシェアを作成するには、表5-1に示すように、名前と権限を置き換えて、次の手順を実行します。

次のURLを使用して、記憶域システムBUIにログインします。
```
https://exalogicsn01-priv:215
```
「Shares」タブ、「Projects」サブタブの順にクリックして、「Projects」ページに移動します。
「Project」パネルで、シェアを追加するプロジェクトを選択します。例: EDG_Binaries。
ファイル・システムを追加するために、「Filesystems」の横にあるプラス(+)ボタンをクリックします。
「Create Filesystems」画面が表示されます。
「Create Filesystems」画面で、「Project」プルダウン・メニューから新規プロジェクトを選択します。
「Name」フィールドに、共有の名前を入力します。
たとえば、shared_binariesです。
「Data migration source」プルダウン・メニューで、「None」を選択します。
表示されるユーザーおよびグループが、ファイル・システムを所有するために作成したNISのユーザーおよびグループと同じであることを確認してください。そうでない場合は、そうなるように変更します。
「Permissions」オプションを選択し、各共有の権限を設定します。
「Inherit Mountpoint」オプションを選択します。
注意:
最初はこれらは読取り/書込みになりますが、製品のインストール後、「アーティファクト特性表」の説明に従って変更できます。
ファイル・システム内のすべてのファイルおよびディレクトリに対してUTF-8エンコーディングを強制するには、「Reject non UTF-8」オプションを選択します。
「Case sensitivity」プルダウン・メニューで、「Mixed」を選択します。
「Normalization」プルダウン・メニューで、「None」を選択します。
「Apply」をクリックして、共有を作成します。

表5-1に示されているシェアごとに、この手順を繰り返します。

5.7.5 共有へのローカル・ルート・アクセスの許可

計算ノードまたは仮想マシンがZFSシェアにアクセスできるようにするには、そのためのNFS例外を追加する必要があります。

個別、共有またはプロジェクト・レベルのいずれかで、例外を作成できます。さらに、コマンドを実行したり、シェアのディレクトリをルート・ユーザーとしてトラバースする場合は、有効にすべきオプションがあります。

単純にするために、この例ではプロジェクト・レベルで例外を作成します。

プロジェクト・レベルでNFSの例外を作成するには、次を実行します。

ブラウザ・ユーザー・インタフェース(BUI)で、「Shares」→「Projects」とクリックしてプロジェクトのユーザー・インタフェースにアクセスします。
プロジェクト・パネルが表示されます。
「Project」パネルで、変更するプロジェクトの横にある「Edit」をクリックします。
「Protocols」タブを選択します。
NFS例外の横にある+記号をクリックします。
Type: networkを選択します。
「Entity」フィールドに、計算ノードまたは仮想マシンのIPアドレスをCIDR形式で入力します。例: 物理ラック上のExalogicの計算ノードのInfiniband CIDRとして192.168.8.0/22。
仮想ラック上のExalogicのIPoIB仮想共有記憶域ネットワークのInfiniband CIDRとして172.17.0.0/16。

注意:
これらの範囲は、インストールのプリファレンスによって異なる場合があります。どのNFS例外を定義するかを判断するには、/sbin/ip addr|grep inetの結果、完成したExalogic構成のスプレッドシート、およびZFS BUIの構成やサービスおよびネットワークの画面を分析する必要があります。
「Access Mode」を「Read/Write」に設定し、ルート・アクセスを確認します。
「Apply」をクリックします。
ZFSアプライアンスにアクセスする各計算ノードまたはvServerに対して、この手順を繰り返します。