Azure HPC Cache の前提条件
新しい 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 サーバーを追加するには、次の手順に従います。
- Azure portal で仮想ネットワークを開きます。
- サイドバーの [設定] メニューで [DNS サーバー] を選択します。
- [カスタム] を選択します。
- フィールドに 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 チームにお問い合わせください。
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 インスタンスを作成する