集約された名前空間を計画する

Azure HPC Cache を使用すると、バックエンド ストレージ システムの細部が見えないようにする仮想名前空間を通じて、クライアントはさまざまなストレージ システムにアクセスすることができます。

ストレージ ターゲットを追加したら、ストレージ ターゲットに対して 1 つまたは複数のクライアント側の名前空間パスを設定します。 クライアント コンピューターでは、このファイル パスをマウントし、ストレージ システムを直接マウントするのではなく、キャッシュに対してファイル読み取り要求を行うことができます。

この仮想ファイル システムは Azure HPC Cache によって管理されるため、クライアント側のパスを変更することなく、ストレージ ターゲットを変更できます。 たとえば、クライアント側のプロシージャを書き換えることなく、ハードウェア ストレージ システムをクラウド ストレージに置き換えることができます。

集約された名前空間の例

集約された名前空間を設計するにあたっては、クライアント マシンから必要な情報に手間なくアクセスできるように、また管理者やワークフロー エンジニアがパスを容易に識別できるようにしてください。

たとえば、Azure BLOB の格納データの処理に Azure HPC Cache インスタンスが使用されるシステムを考えてみます。 その分析には、オンプレミス データセンターに格納されたテンプレート ファイルが必要です。

テンプレート データはデータセンターに格納され、このジョブに必要な情報は次のサブディレクトリに格納されています。

• /goldline/templates/acme2017/sku798
• /goldline/templates/acme2017/sku980

データセンターのストレージ システムは、次のエクスポートを公開します。

• /
• /goldline
• /goldline/templates

分析の対象となるデータは、「Azure Blob Storage にデータを移動する」に概説されている NFS データ インポート手法を使用して、"sourcecollection" という名前の Azure BLOB ストレージ コンテナーにコピーされています。

キャッシュ経由で簡単にアクセスできるようにするために、次の仮想名前空間パスを使用してストレージ ターゲットを作成することを検討します。

それぞれが一意のエクスポート パスを参照している限り、1 つの NFS ストレージ ターゲットに複数の仮想名前空間パスを使用できます。 (1 つの NFS ストレージ ターゲットに複数の名前空間パスを使用する方法の詳細については、「NFS 名前空間パス」を参照してください。)

NFS ソース パスは同じエクスポートのサブディレクトリであるため、同じストレージ ターゲットから複数の名前空間パスを定義する必要があります。

クライアント アプリケーションでキャッシュをマウントして、集約された名前空間のファイル パス (/source、/templates/sku798、/templates/sku980) に容易にアクセスできます。

別のアプローチとして、親ディレクトリ acme2017 にリンクする /templates のような仮想パスを作成して、キャッシュのマウント後にクライアントを個々の sku798 および sku980 ディレクトリに移動させることもできます。 ただし、別の名前空間パスのサブディレクトリである名前空間パスを作成することはできません。 そのため、acme2017 ディレクトリへのパスを作成する場合、そのサブディレクトリに直接アクセスするための名前空間パスも作成することはできません。

Azure HPC Cache 名前空間設定ページには、クライアント側のファイルシステムが表示されるので、パスを追加または編集できます。 詳細については、「集約された名前空間を設定する」を参照してください。

次のステップ

仮想ファイル システムを設定する方法を決定したら、次の手順を実行してそれを作成します。

• ストレージ ターゲットを作成して、Azure HPC Cache にバックエンド ストレージ システムを追加します
• 名前空間のパスを追加して、クライアント コンピューターがファイルにアクセスするために使用する集約された名前空間を作成します