Azure HPC Cache の前提条件

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

Azure サブスクリプション

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

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

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

  • Azure HPC Cache インスタンスの専用サブネット
  • キャッシュがストレージやその他のリソースにアクセスできるように DNS サポート
  • サブネットから、NTP サーバーや Azure Queue Storage サービスを含む追加の Microsoft Azure インフラストラクチャ サービスへのアクセス。

キャッシュ サブネット

Azure HPC Cache には、次の特性を備えた専用サブネットが必要です。

  • サブネットには、少なくとも 64 個の IP アドレスが必要です。
  • サブネット内の通信は無制限である必要があります。 キャッシュ サブネットにネットワーク セキュリティ グループを使用する場合は、内部 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 サーバーを使用するには、キャッシュを作成する前に、次のセットアップ手順を実行する必要があります。

  • Azure HPC Cache をホストする仮想ネットワークを作成します。

  • DNS サーバーを作成します。

  • キャッシュの仮想ネットワークに DNS サーバーを追加します。

    Azure portal で仮想ネットワークに DNS サーバーを追加するには、次の手順に従います。

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

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

Azure 仮想ネットワークと DNS サーバー構成の詳細については、Name resolution for resources in Azure virtual networksをご覧ください。

NTP アクセス

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

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

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

Priority 名前 港 / ポート プロトコル Source 行き先 アクション
200 NTP Any UDP Any 168.61.215.74 許可する

送信アクセスを広く拒否する規則よりも NTP 規則の優先度が高いことを確認します。

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

  • HPC キャッシュと NTP サーバーの間にファイアウォールがある場合は、これらのファイアウォールで NTP アクセスも許可されていることを確認します。

  • HPC Cache で使用する NTP サーバーは、[ ネットワーク ] ページで構成できます。 詳細については 、「追加設定の構成 」を参照してください。

Azure Queue Storage へのアクセス

キャッシュは、専用サブネット内から Azure Queue Storage サービス に安全にアクセスできる必要があります。 Azure HPC Cache は、構成と状態の情報を通信するときにキュー サービスを使用します。

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

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

  • キャッシュ サブネットに Azure Storage サービス エンドポイントを作成します。 Microsoft.Storage サービス エンドポイントを追加する手順については、「仮想ネットワーク サブネットの追加」を参照してください。

  • ネットワーク セキュリティ グループまたはその他のファイアウォール内の Azure ストレージ キュー サービス ドメインへのアクセスを個別に構成します。

    これらのポートへのアクセスを許可する規則を追加します。

    • ドメイン queue.core.windows.net (*.queue.core.windows.net) 内の任意のホストへのトラフィックをセキュリティで保護するための TCP ポート 443。

    • TCP ポート 80 - サーバー側証明書の検証に使用されます。 これは、証明書失効リスト (CRL) チェックおよびオンライン証明書状態プロトコル (OCSP) 通信と呼ばれることもあります。 *.queue.core.windows.net はすべて同じ証明書を使用するため、同じ CRL/OCSP サーバーが使用されます。 ホスト名は、サーバー側の SSL 証明書に格納されます。

    詳細については、 NTP アクセス のセキュリティ規則のヒントを参照してください。

    このコマンドは、アクセスを許可する必要がある CRL および OCSP サーバーを一覧表示します。 これらのサーバーは 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 ストレージの要件

キャッシュで Azure Blob Storage を使用する場合は、「データを Azure Blob Storage に 移動する」の説明に従って、互換性のあるストレージ アカウントと、空の BLOB コンテナーまたは Azure HPC Cache 形式のデータが設定されたコンテナーが必要です。

Note

NFS マウント BLOB ストレージには、さまざまな要件が適用されます。 詳細については、ストレージ要件ADLS-NFS 参照してください。

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

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

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

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

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

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

また、上記の 「アクセス許可」で説明したように、キャッシュ アプリケーションに Azure ストレージ アカウントへのアクセス権を付与する必要があります。 「ストレージ ターゲットの追加」の手順に従って、キャッシュに必要なアクセス ロールを付与します。 ストレージ アカウントの所有者でない場合は、所有者にこの手順を実行してもらう必要があります。

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 コマンドを使用できない場合は、次の一般的に使用されるポートで受信トラフィックと送信トラフィックが許可されていることを確認してください。

      プロトコル 港 / ポート Service
      TCP/UDP 111 rpcbind
      TCP/UDP 2049 NFS
      TCP/UDP 4045 nlockmgr
      TCP/UDP 4046 マウントd
      TCP/UDP 4047 状態

      一部のシステムでは、これらのサービスに異なるポート番号が使用されます。ストレージ システムのドキュメントを確認してください。

    • ファイアウォール設定を確認して、これらの必要なすべてのポートでトラフィックが許可されていることを確認します。 Azure で使用されているファイアウォールと、データ センター内のオンプレミスのファイアウォールを確認してください。

  • NFS バックエンド ストレージは、互換性のあるハードウェア/ソフトウェア プラットフォームである必要があります。 ストレージは NFS バージョン 3 (NFSv3) をサポートしている必要があります。 詳細については、Azure HPC Cache チームにお問い合わせください。

NFS マウント BLOB (ADLS-NFS) ストレージの要件

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

Azure Blob Storage での NFS 3.0 プロトコルサポートのこの機能の詳細を確認してください。

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

これは、手順の一般的な概要です。 これらの手順は変更される可能性があるため、現在の詳細については 必ずADLS-NFS の手順 を参照してください。

  1. 必要な機能が、作業する予定のリージョンで使用できることを確認します。

  2. サブスクリプションの NFS プロトコル機能を有効にします。 ストレージ アカウントを作成する 前に 、これを行います。

  3. ストレージ アカウントのセキュリティで保護された仮想ネットワーク (VNet) を作成します。 NFS 対応ストレージ アカウントと Azure HPC Cache に同じ仮想ネットワークを使用する必要があります。 (キャッシュと同じサブネットを使用しないでください)。

  4. ストレージ アカウントを作成します。

    • Standard BLOB ストレージ アカウントの設定を使うのではなく、ハウツー ドキュメントに記載された手順を参照してください。 サポートされるストレージ アカウントの種類は、Azure リージョンによって異なる場合があります。

    • [ネットワーク] セクションで、作成したセキュリティで保護された仮想ネットワーク内のプライベート エンドポイント (推奨) を選択するか、セキュリティで保護された VNet からのアクセスが制限されたパブリック エンドポイントを選択します。

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

    • NFS アクセスを有効にする [詳細設定] セクションを忘れないでください。

    • 上記の 「アクセス許可」で説明したように、キャッシュ アプリケーションに Azure ストレージ アカウントへのアクセス権を付与します。 これは、ストレージ ターゲットを初めて作成するときに行うことができます。 「ストレージ ターゲットの追加」の手順に従って、キャッシュに必要なアクセス ロールを付与します。

      ストレージ アカウントの所有者でない場合は、所有者にこの手順を実行してもらう必要があります。

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

プライベート エンドポイントを操作する

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

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

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

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

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

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

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

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

次のステップ

  • Last updated on