Azure HPC Cache の前提条件

[アーティクル]
03/25/2023

新しい Azure HPC Cache を作成する前に、ご利用の環境がこれらの要件を満たしていることを確認します。

Azure サブスクリプション

有料サブスクリプションをお勧めします。

ネットワークインフラストラクチャ

キャッシュを使用するには、ネットワークに関連した次の前提条件を事前に設定しておく必要があります。

Azure HPC Cache インスタンスの専用サブネット
DNS サポート (キャッシュがストレージや他のリソースにアクセスできるようにするため)
サブネットから、NTP サーバーや Azure Queue Storage サービスなど、追加の Microsoft Azure インフラストラクチャサービスにアクセスします。

キャッシュのサブネット

Azure HPC Cache には、次の条件を満たした専用のサブネットが必要です。

サブネットには、使用できる IP アドレスが少なくとも 64 個必要です。
サブネット内の通信は無制限である必要があります。キャッシュサブネットにネットワークセキュリティグループを使用する場合は、内部 IP アドレス間のすべてのサービスが許可されることを確認します。
そのサブネットで他の VM をホストすることはできません。クライアントマシンなど、関連サービス用であっても同様です。
複数の Azure HPC Cache インスタンスを使用する場合、各インスタンスに独自のサブネットが必要です。

ベストプラクティスとして、キャッシュごとに新しいサブネットを作成することをお勧めします。キャッシュを作成する過程で新しい仮想ネットワークとサブネットを作成できます。

このサブネットを作成するときは、そのセキュリティ設定によって、このセクションで後ほど説明する必要なインフラストラクチャサービスへのアクセスが可能になることに注意してください。送信インターネット接続を制限できますが、ここに記載されている項目には例外があることを確認してください。

DNS アクセス

キャッシュからその仮想ネットワークの外部のリソースにアクセスするためには、DNS が必要です。使用するリソースによっては、カスタマイズした DNS サーバーをセットアップし、そのサーバーと Azure DNS サーバーとの間の転送を構成する必要がある可能性があります。

Azure Blob Storage のエンドポイントなど内部のリソースにアクセスするには、Azure ベースの DNS サーバーが必要です。
オンプレミスのストレージにアクセスするためには、ストレージのホスト名を解決できるカスタム DNS サーバーを構成する必要があります。キャッシュを作成する前に、これを実行する必要があります。

Blob Storage だけを使用するのであれば、Azure に用意されている既定の DNS サーバーをキャッシュに使用できます。一方、Azure 外部のストレージまたは他のリソースにアクセスする必要がある場合は、カスタム DNS サーバーを作成し、Azure 固有の解決要求は Azure DNS サーバーに転送するようそのカスタム DNS サーバーを構成する必要があります。

カスタム DNS サーバーを使用するには、キャッシュを作成する前に、次のセットアップ手順を行う必要があります。

Azure HPC Cache がホストされる仮想ネットワークを作成します。
DNS サーバーを作成します。
DNS サーバーをキャッシュの仮想ネットワークに追加します。

Azure portal の仮想ネットワークに DNS サーバーを追加するには、次の手順に従います。
1. Azure portal で仮想ネットワークを開きます。
2. サイドバーの [設定] メニューで [DNS サーバー] を選択します。
3. [カスタム] を選択します。
4. フィールドに DNS サーバーの IP アドレスを入力します。

単純な DNS サーバーを使用して、利用可能なすべてのキャッシュマウントポイント間でクライアント接続を負荷分散することもできます。

Azure 仮想ネットワークと DNS サーバーの構成について詳しくは、「Azure 仮想ネットワーク内のリソースの名前解決」を参照してください。

NTP アクセス

HPC Cache は、通常の運用のために NTP サーバーへのアクセスを必要とします。仮想ネットワークからの送信トラフィックを制限する場合は、少なくとも 1 つの NTP サーバーへのトラフィックを許可してください。既定のサーバーは time.windows.com で、キャッシュはこのサーバーに UDP ポート 123 で接続します。

NTP サーバーへの送信トラフィックを許可するルールをキャッシュネットワークのネットワークセキュリティグループに作成します。この規則では、単に UDP ポート 123 のすべての送信トラフィックを許可するか、またはより多くの制限を設定することができます。

この例では、IP アドレス 168.61.215.74 への送信トラフィックを明示的に開きます。これは、time.windows.com によって使用されるアドレスです。

優先順位	名前	[ポート]	プロトコル	ソース	Destination (公開先)	アクション
200	NTP	[任意]	UDP	[任意]	168.61.215.74	許可

NTP ルールの優先順位が、送信アクセスを幅広く拒否するルールよりも高いことを確認します。

NTP アクセスに関するその他のヒント:

HPC Cache と NTP サーバーの間にファイアウォールがある場合は、これらのファイアウォールでも NTP アクセスが許可されていることを確認してください。
ネットワーク ページで、HPC Cache で使用する NTP サーバーを構成できます。詳細については、「追加の設定の構成」を参照してください。

Azure Queue Storage のアクセス

キャッシュは Azure Queue Storage サービスに、その専用サブネット内から安全にアクセスできなければなりません。 Azure HPC Cache は、構成および状態情報を通信するときにキューサービスを使用します。

キャッシュがキューサービスにアクセスできない場合は、キャッシュを作成しているとき CacheConnectivityError メッセージが表示されることがあります。

アクセスを提供するには、次の 2 つの方法があります。

Azure Storage サービスエンドポイントをキャッシュサブネットに作成します。 Microsoft.Storage サービスエンドポイントを追加する手順については、「仮想ネットワークサブネットの追加」を参照してください。
ネットワークセキュリティグループまたは他のファイアウォールで Azure Storage キューサービスドメインへのアクセスを個別に構成します。

以下のポートへのアクセスを許可する規則を追加します。
- TCP ポート 443: ドメイン queue.core.windows.net (*.queue.core.windows.net) 内のあらゆるホストへのトラフィック保護。
- TCP ポート 80 - サーバー側証明書の検証に使用されます。これは、証明書失効リスト (CRL) チェックおよびオンライン証明書ステータスプロトコル (OCSP) 通信と呼ばれる場合があります。 *.queue.core.windows.net はすべてが同じ証明書を使用するため、同じ CRL/OCSP サーバーを使用します。ホスト名は、サーバー側の SSL 証明書に格納されます。
詳細については、「NTP アクセス」のセキュリティ規則のヒントを参照してください。

このコマンドは、アクセスの許可が必要な CRL サーバーと OSCP サーバーを一覧表示します。これらのサーバーは DNS で解決可能であり、キャッシュサブネットからポート 80 で到達可能でなければなりません。
```
openssl s_client -connect azure.queue.core.windows.net:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' | openssl x509 -noout -text -in /dev/stdin |egrep -i crl\|ocsp|grep URI
```
出力は次のようになり、SSL 証明書が更新された場合は変わる可能性があります。
```
OCSP - URI:http://ocsp.msocsp.com
CRL - URI:http://mscrl.microsoft.com/pki/mscorp/crl/Microsoft%20RSA%20TLS%20CA%2002.crl
CRL - URI:http://crl.microsoft.com/pki/mscorp/crl/Microsoft%20RSA%20TLS%20CA%2002.crl
```

サブネットの接続を確認するには、次のコマンドをサブネット内のテスト VM から使用します。

openssl s_client -connect azure.queue.core.windows.net:443 -status 2>&1 < /dev/null |grep "OCSP Response Status"

接続が成功すると、次の応答が返されます。

OCSP Response Status: successful (0x0)

イベントサーバーのアクセス

Azure HPC Cache では、Azure イベントサーバーエンドポイントを使用してキャッシュの正常性を監視し、診断情報を送信します。

キャッシュがドメイン events.data.microsoft.com 内のホストに安全にアクセスできることを確認します。つまり、*.events.data.microsoft.com へのトラフィック用に TCP ポート 443 を開きます。

アクセス許可

アクセス許可に関連したこれらの前提条件は、キャッシュの作成を始める前に確認しておいてください。

キャッシュインスタンスで仮想ネットワークインターフェイス (NIC) を作成できる必要があります。キャッシュを作成するユーザーは、NIC を作成できるだけの権限をサブスクリプションにおいて有している必要があります。
Blob Storage を使用する場合、Azure HPC Cache には、ストレージアカウントにアクセスするための承認が必要です。 Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、Blob Storage へのアクセス権をキャッシュに与えます。ストレージアカウント共同作成者とストレージ BLOB データ共同作成者の 2 つのロールが必要となります。

ロールを追加するには、ストレージターゲットを追加する手順に従ってください。

ストレージインフラストラクチャ

キャッシュは、Azure BLOB コンテナー、NFS ハードウェアストレージのエクスポート、および NFS でマウントされた ADLS BLOB コンテナーをサポートしています。キャッシュを作成した後で、ストレージターゲットを追加します。

ストレージの種類ごとに特定の前提条件があります。

Blob Storage の要件

お使いのキャッシュで Azure Blob Storage の使用を希望する場合、互換性のあるストレージアカウントに加え、空の BLOB コンテナーか、Azure HPC Cache フォーマットのデータが事前設定されたコンテナーが必要です (Azure Blob Storage にデータを移動する方法を参照)。

Note

NFS でマウントされた Blob Storage には、異なる要件が適用されます。詳細については、ADLS-NFS ストレージの要件に関するセクションを参照してください。

ストレージターゲットを追加する前にアカウントを作成してください。ターゲットを追加するときに、新しいコンテナーを作成できます。

互換性のあるストレージアカウントを作成するには、次のいずれかの組み合わせを使用します。

パフォーマンス	Type	レプリケーション	アクセス層
Standard	StorageV2 (汎用 v2)	ローカル冗長ストレージ (LRS) またはゾーン冗長ストレージ (ZRS)	ホット
Premium	ブロック BLOB	ローカル冗長ストレージ (LRS)	ホット

ストレージアカウントは、キャッシュのプライベートサブネットからアクセスできる必要があります。アカウントでプライベートエンドポイントまたは特定の仮想ネットワークに制限されているパブリックエンドポイントを使用している場合は、キャッシュのサブネットからのアクセスを有効にする必要があります。 (オープンなパブリックエンドポイントは推奨されません。)

HPC Cache ストレージターゲットでのプライベートエンドポイントの使用に関するヒントについては、「プライベートエンドポイントの使用」を参照してください。

キャッシュと同じ Azure リージョンにあるストレージアカウントの使用をお勧めします。

また、「アクセス許可」で前述のように、キャッシュアプリケーションには、Azure Storage アカウントへのアクセス権を与える必要があります。「ストレージターゲットの追加」の手順に従い、必要なアクセスロールをキャッシュに与えます。ストレージアカウント所有者でない場合は、所有者にこの手順を実行させてください。

NFS ストレージの要件

NFS ストレージシステム (たとえば、オンプレミスのハードウェア NAS システム) を使用している場合は、次の要件を満たしていることを確認します。これらの設定を確認するには、ストレージシステム (またはデータセンター) のネットワーク管理者またはファイアウォールマネージャーとの協力が必要な場合があります。

Note

キャッシュが NFS ストレージシステムに対して十分なアクセス権を持っていない場合、ストレージターゲットの作成は失敗します。

詳細については「 NAS 構成と NFS ストレージターゲットの問題のトラブルシューティング」をご参照ください。

ネットワーク接続: Azure HPC Cache には、キャッシュサブネットと NFS システムのデータセンター間の高帯域幅ネットワークアクセスが必要です。 ExpressRoute または同様のアクセスが推奨されます。 VPN を使用している場合は、TCP MSS を 1350 でクランプして大きなパケットがブロックされないように構成する必要があります。 VPN 設定のトラブルシューティングについて詳しくは、VPN のパケットサイズの制限に関する追加ヘルプをご覧ください。
ポートアクセス: キャッシュには、ストレージシステム上の特定の TCP/UDP ポートへのアクセスが必要です。ストレージの種類によってポート要件は異なります。

ストレージシステムの設定を確認するには、次の手順を実行します。
- ストレージシステムに rpcinfo コマンドを発行して、必要なポートを確認します。次のコマンドを使って、ポートを一覧表示し、関連する結果の書式を設定します (<storage_IP> という表現の部分にはシステムの IP アドレスを使用してください)。
  
  このコマンドは、NFS インフラストラクチャがインストールされている任意の Linux クライアントから発行できます。クラスターサブネット内のクライアントを使用する場合は、サブネットとストレージシステム間の接続を検証するためにも役立ちます。
```
rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t
```
rpcinfo クエリによって返されるすべてのポートで、Azure HPC Cache のサブネットからの無制限のトラフィックが許可されていることを確認します。
- rpcinfo コマンドを使用できない場合は、次の一般的に使用されるポートで受信および送信トラフィックが許可されていることを確認します。
  
  プロトコル [ポート] サービス
  
  TCP/UDP 111 rpcbind
  
  TCP/UDP 2049 NFS
  
  TCP/UDP 4045 nlockmgr
  
  TCP/UDP 4046 mountd
  
  TCP/UDP 4047 status
  
  一部のシステムでは、これらのサービスに別のポート番号を使用しています。確認するには、ストレージシステムのドキュメントを参照してください。
- ファイアウォール設定で、これらのすべての必要なポートでトラフィックが許可されていることを確認します。 Azure で使用されているファイアウォールとデータセンターのオンプレミスファイアウォールを必ず確認してください。
NFS バックエンドストレージは、互換性のあるハードウェアプラットフォームおよびソフトウェアプラットフォームである必要があります。ストレージは NFS バージョン 3 (NFSv3) をサポートする必要があります。詳細については、Azure HPC Cache チームにお問い合わせください。

プロトコル	[ポート]	サービス
TCP/UDP	111	rpcbind
TCP/UDP	2049	NFS
TCP/UDP	4045	nlockmgr
TCP/UDP	4046	mountd
TCP/UDP	4047	status

NFS でマウントされた Blob (ADLS-NFS) Storage の要件

Azure HPC Cache では、NFS プロトコルでマウントされた BLOB コンテナーをストレージターゲットとして使用することもできます。

この機能の詳細については、Azure Blob Storage での NFS 3.0 プロトコルのサポートに関するページを参照してください。

ストレージアカウントの要件は、ADLS-NFS Blob Storage ターゲットと標準 Blob Storage ターゲットで異なります。ネットワークファイルシステム (NFS) 3.0 プロトコルを使用した Blob Storage のマウントに関するページの手順に従って、NFS 対応のストレージアカウントを作成および構成します。

ここでは、手順の概要について説明します。これらの手順は変更される可能性があるため、現在の詳細については、常に ADLS-NFS の手順に関するページを参照してください。

必要な機能が、作業を予定しているリージョンで利用できることを確認します。
サブスクリプションに対して NFS プロトコル機能を有効にします。ストレージアカウントを作成する前に、この手順を実行します。
ストレージアカウント用のセキュリティで保護された仮想ネットワーク (VNet) を作成します。 NFS が有効なストレージアカウントと Azure HPC Cache には、同じ仮想ネットワークを使用する必要があります。 (キャッシュと同じサブネットは使用しないでください。)
ストレージアカウントを作成します。
- 標準 Blob Storage アカウント用のストレージアカウント設定を使用する代わりに、操作方法に関するドキュメントに記載されている手順に従ってください。サポートされているストレージアカウントの種類は、Azure リージョンによって異なる場合があります。
- [ネットワーク] セクションで、作成したセキュリティで保護された仮想ネットワーク内のプライベートエンドポイントを選択します (推奨)。または、セキュリティで保護された VNet からのアクセスが制限されているパブリックエンドポイントを選択します。
  
  HPC Cache ストレージターゲットでのプライベートエンドポイントの使用に関するヒントについては、「プライベートエンドポイントの使用」を参照してください。
- 必ず [詳細設定] セクションを完了してください。そこで NFS アクセスを有効にします。
- 「アクセス許可」で前述のように、キャッシュアプリケーションには、Azure Storage アカウントへのアクセス権を与えます。ストレージターゲットを初めて作成するときに、この操作を行うことができます。「ストレージターゲットの追加」の手順に従い、必要なアクセスロールをキャッシュに与えます。
  
  ストレージアカウント所有者ではない場合は、この手順の実行を所有者に依頼してください。

Azure HPC Cache での ADLS-NFS ストレージターゲットの使用の詳細については、Azure HPC Cache での NFS でマウントされた BLOB ストレージの使用に関する記事を参照してください。

プライベートエンドポイントの使用

Azure Storage では、セキュリティで保護されたデータアクセスを可能にするためのプライベートエンドポイントをサポートしています。プライベートエンドポイントは、Azure BLOB または NFS でマウントされた BLOB ストレージターゲットで使用できます。

プライベートエンドポイントの詳細

プライベートエンドポイントによって、HPC Cache が、バックエンドストレージシステムと通信するために使用する特定の IP アドレスが提供されます。その IP アドレスが変更された場合、キャッシュではストレージとの接続を自動的に再確立できません。

プライベートエンドポイントの構成を変更する必要がある場合は、次の手順に従って、ストレージと HPC Cache 間の通信の問題を回避します。

ストレージターゲット (またはこのプライベートエンドポイントを使用するすべてのストレージターゲット) を中断させます。
プライベートエンドポイントに変更を加え、それらの変更を保存します。
"resume" コマンドを使用して、ストレージターゲットをサービスに戻します。
ストレージターゲットの DNS 設定を更新します。

ストレージターゲットの DNS を中断、再開、更新する方法については、「ストレージターゲットの表示と管理」を参照してください。

Azure CLI アクセスを設定する (省略可能)

Azure CLI から Azure HPC Cache を作成または管理したい場合は、Azure CLI と hpc-cache 拡張機能をインストールする必要があります。「Azure HPC Cache 向けに Azure CLI を設定する」の手順に従います。

次のステップ

Azure portal から Azure HPC Cache インスタンスを作成する