手順 1: デプロイの準備

  • [アーティクル]

HPC クラスターのデプロイの最初の手順は、ヘッド ノードの数の決定、クラスターのネットワーク トポロジの選択など、重要な決定を行することです。 次のタスクは、クラスターのデプロイの準備に役立ちます。

1.1: システム要件を確認する

まだ行っていない場合は、Microsoft HPC Pack 2019の システム要件を確認してください。 HPC Pack には、ノード ロールとデプロイ オプションごとに異なる要件があることに注意してください。 展開の決定を完了した後で、システム要件をもう一度確認できます。

1.2: 高可用性のためにヘッド ノードを構成するかどうかを決定する

ヘッド ノード コンピューター上のサービスで計画的または計画外の中断中に HPC ジョブを実行し続ける必要がある場合は、高可用性のためにヘッド ノードを構成することを計画できます。 そのためには、少なくとも 2 台のヘッド ノード コンピューターに HPC Pack をインストールする必要があります。

1.3: リモート データベースを使用してクラスターをデプロイするかどうかを決定する

HPC Pack 2019 では、Microsoft SQL Server 2014 以降のバージョンが必要であり、サポートされています。 HPC Pack では、5 つの異なる SQL Server データベースを使用して、クラスターの管理、ジョブのスケジュール設定、レポート、診断、監視データを格納します。 これらの 5 つの HPC データベースのうち 1 つ以上を、クラスターのヘッド ノードにインストールするのではなく、1 つ以上のリモート サーバーにインストールできます。 既定では、HPC Pack は SQL Server Express 2019 をヘッド ノードにインストールし、単一のヘッド ノードを選択した場合はヘッド ノードに HPC データベースを作成します。 3 つのヘッド ノードをデプロイする場合、HPC データベースを 1 つ以上のリモート サーバーにインストールする利点は、リソースをヘッド ノードに保存し、クラスターを効率的に管理できることです。

大事な

ヘッド ノードでの SQL Server 2019 Express の使用は、概念実証クラスターまたは開発クラスター、および小規模な運用クラスターに推奨されます。 クラスターに 256 を超えるノードがある場合、高可用性のためにヘッド ノードを構成する予定がある場合、またはジョブのスループットとレポートの要件が SQL Server 2019 Express の機能を超える可能性がある場合は、HPC データベースを 1 つ以上のリモート サーバーにインストールすることを検討する必要があります。

リモート サーバーに HPC データベースをインストールするには、そのサーバーが SQL Server 2008 R2 以降の Standard または Enterprise エディションを実行し、HPC Pack を操作するように構成されている必要があります。 リモート データベースを使用して HPC Pack をインストールする前に、データベース管理者に、セットアップ フォルダーで SetupHpcDatabase.ps1 スクリプトを実行するか、スクリプト内のタスクを手動で実行または変更するように依頼します。 このスクリプトでは、HPC Pack をインストールするアカウントと HPC サービスのマシン アカウントに必要なデータベースと SQL インスタンスログインとデータベース ユーザーが自動的に作成されます。 詳細については、「リモート データベースを使用した Windows HPC クラスターのデプロイ」ステップ バイ ステップ ガイドを参照してください。

1.4: クラスターに追加するノードの種類とノードの数を決定する

オンプレミス クラスターには、次の種類のノードを追加できます。

  • コンピューティング ノード - コンピューティング ノードはジョブの実行に使用されます。 この種類のノードは、再デプロイされずに別の種類のノード (つまりロールを変更) にすることはできません。
  • ブローカー ノード - Windows Communication Foundation (WCF) ブローカー ノードは、Service-Oriented アーキテクチャ (SOA) クライアントからクラスター内のノードで実行されている SOA サービスに WCF 呼び出しをルーティングするために使用されます。 この種類のノードでは、ロールを変更して、再デプロイせずにコンピューティング ノードにすることができます。
  • ワークステーション ノードと非管理対象サーバー ノード - ワークステーション ノードとアンマネージド サーバー ノードは、ジョブを実行できる組織内のコンピューターですが、専用のクラスター リソースではありません。 特定の時刻にジョブを実行できるようにスケジュールすることも、オンデマンドで使用できるようにすることもできます。 この種類のノードはロールを変更できません。
  • Microsoft Azure ノード - Microsoft Azure サブスクリプションをお持ちの場合は、必要に応じて Azure ノードを追加して、必要に応じてクラスターの容量を増やすことができます。 コンピューティング ノード、ワークステーション ノード、アンマネージド サーバー ノードと同様に、Azure ノードはジョブを実行できます。 Azure ノードを追加するときは、オンプレミスのヘッド ノードと Azure ノード間の通信を容易にするために、Azure デプロイで固定または可変数のプロキシ ノードも構成します。
  • Microsoft Azure IaaS ノード - Microsoft Azure サブスクリプションをお持ちの場合は、必要に応じて Microsoft Azure IaaS ノードを追加して、必要に応じてクラスターの容量を増やすことができます。

Windows HPC クラスターのノード ロールの詳細については、「Microsoft HPC Packのノード ロールについて」を参照してください。

HPC Pack をインストールすると、作成されるノードの種類に応じて、さまざまな機能がインストールされます。 これらの機能によって、ノードがクラスターで実行する役割が決まります。 ノードには、別のロールを実行するために必要な機能があるため、ロールを変更できる場合があります。 ロールを変更する機能は、クラスターに追加するノードの種類を決定するときに考慮する必要がある重要な側面です。

もう 1 つの重要な決定は、追加するノードの数です。 ブローカー ノードを追加する場合は、クラスターで使用できるブローカー ノードごとに追加するコンピューティング ノードの数も決定する必要があります。 ブローカー ノードとコンピューティング ノードの比率は、クラスターのパフォーマンスに影響する可能性があります。

Azure ノードを追加する予定の場合は、Azure にデプロイされたノードの数と、それらのノードで実行されるジョブに最適なプロキシ ノードの数を考慮する必要があります。 プロキシ ノードは、オンプレミスのヘッド ノードとの通信に必要であり、特定のクラスター サイズとワークロードのボトルネックになる可能性があります。

最後に、フェールオーバー クラスターでヘッド ノードまたはブローカー ノードを構成する場合は、構成するフェールオーバー クラスター ノードごとにコンピューターを 1 つ追加する必要があります。これにより、クラスターに追加できるコンピューティング ノードの数が減る可能性があります。

1.5: クラスターの Active Directory ドメインを選択する

HPC Pack 2016 on から、HPC Pack はドメインに参加していないコンピューターにインストールできますが、この機能は Azure の HPC クラスター専用に設計されています。 オンプレミスの HPC クラスターの場合は、Active Directory ドメインにクラスターを作成する必要があります。

オンプレミスの HPC クラスター内のノードは、Active Directory ドメインのメンバーになります。 オンプレミス クラスターをデプロイする前に、HPC クラスターに使用する Active Directory ドメインを選択します。

組織の Active Directory 環境によっては、HPC クラスターのメンバーになるコンピューター用に別の組織単位 (OU) を構成すると便利な場合があります。 別の OU を使用すると、必要に応じて、組織内の他のコンピューターとは異なるポリシーと設定をクラスター ノードに適用できます。

クラスターに参加できる Active Directory ドメインがない場合、または既存のドメインに参加したくない場合は、新しい Active Directory ドメインを作成できます。 Active Directory Domain Services ロールのインストールの詳細については、「エンタープライズでの Active Directory Domain Services (AD DS) の展開 」を参照してください。

その他の考慮事項

  • Microsoft Service Fabric で高可用性クラスターをインストールする予定の場合、HPC Pack 2019 ヘッド ノードをドメイン コントローラーにインストールすることはできません。 これは、Microsoft Service Fabric クラスターをドメイン コントローラーにデプロイできないためです。

  • ワークステーション ノードまたは非管理対象サーバー ノードを HPC クラスターに追加する予定の場合は、ヘッド ノードが参加しているドメインとの信頼関係が確立されている任意の Active Directory ドメインにそれらのコンピューターを参加させることができます。

1.6: ノードを追加するためのドメイン アカウントを選択する

ヘッド ノードに HPC Pack をインストールするには、ヘッド ノード コンピューターの Administrators グループのメンバーであるドメイン ユーザー アカウントでログオンしている必要があります。 さらに、HPC Pack のインストール後の HPC ヘッド ノードの構成プロセス中に、オンプレミス ノードの追加とそれらのノードのシステム構成に使用されるドメイン ユーザー アカウントの資格情報を指定する必要があります。 クラスターのデプロイを開始する前に、既存のアカウントを選択するか、新しいアカウントを作成する必要があります。

ユーザー アカウントの選択に関する考慮事項

  • 選択するユーザー アカウントは、ノードの Active Directory コンピューター アカウントを作成し、ノードをドメインに参加させるのに十分な特権を持つドメイン アカウントである必要があります。
  • 組織のポリシーによって、新しいコンピューターをドメインに追加できるドメイン アカウントの使用が制限されている場合は、ノードを展開する前に、Active Directory Domain Services でコンピューター オブジェクトを事前に作成するようにドメイン管理者に依頼する必要があります。 詳細については、「Active Directoryで事前に作成されたコンピューター オブジェクトを使用してノードを展開する」を参照してください。
  • 展開の一部でエンタープライズ ネットワーク上のリソースへのアクセスが必要な場合、ユーザー アカウントには、ネットワーク サーバーで使用できるインストール ファイルなど、それらのリソースにアクセスするために必要なアクセス許可が必要です。
  • HPC クラスター マネージャーを使用してノードをリモートで再起動する場合、アカウントはヘッド ノードのローカル Administrators グループのメンバーである必要があります。 この要件は、ノードをリモートで再起動するために使用できるスクリプト化された電源制御ツールがない場合にのみ必要です。

1.7: クラスターのネットワーク トポロジを選択する

HPC Pack では、5 つのクラスター トポロジがサポートされています。 これらのトポロジは、クラスター内のノードが相互に接続され、エンタープライズ ネットワークに接続される方法によって区別されます。 サポートされている 5 つのクラスター トポロジは次のとおりです。

  • トポロジ 1: プライベート ネットワーク上に分離されたコンピューティング ノード
  • トポロジ 2: エンタープライズ ネットワークとプライベート ネットワーク上のすべてのノード
  • トポロジ 3: プライベート ネットワークとアプリケーション ネットワークで分離されたコンピューティング ノード
  • トポロジ 4: エンタープライズ、プライベート、およびアプリケーション ネットワーク上のすべてのノード
  • トポロジ 5: エンタープライズ ネットワーク上のすべてのノード

各ネットワーク トポロジと各 HPC クラスター ネットワークの詳細については、「付録 1: HPC クラスター ネットワーク」を参照してください。

ネットワーク トポロジを選択する場合は、既存のネットワーク インフラストラクチャと、クラスターに追加するノードの種類を考慮する必要があります。

  • 選択したトポロジ内のどのネットワークがエンタープライズ ネットワーク、プライベート ネットワーク、アプリケーション ネットワークとして機能するかを決定します。
  • 自動構成でヘッド ノード上のエンタープライズ ネットワークに接続されているネットワーク アダプターがない (つまり、そのアダプターの IP アドレスが 169.254 で始まらない)。 そのアダプターには、動的または手動で割り当てられた (静的) 有効な IP アドレスが必要です。
  • プライベート ネットワークを含むトポロジを選択し、ベア メタルからクラスターにノードを追加する予定の場合は、次の操作を行います。
    • プライベート ネットワークにプリブート実行環境 (PXE) サーバーがないことを確認します。
    • プライベート ネットワークに既存の DHCP サーバーを使用する場合は、ヘッド ノードをネットワーク内の PXE サーバーとして認識するように構成されていることを確認します。
  • プライベート ネットワークまたはアプリケーション ネットワークのヘッド ノードで DHCP サーバーを有効にし、それらのネットワークに接続されている他の DHCP サーバーがある場合は、それらの DHCP サーバーを無効にする必要があります。
  • 既存のドメイン ネーム システム (DNS) サーバーがクラスター内のノードと同じネットワークに接続されている場合、アクションは必要ありませんが、ノードはその DNS サーバーから自動的に登録解除されます。
  • グループ ポリシーを使用して、インターネット プロトコル セキュリティ (IPsec) がドメインに適用されているかどうかを確認するには、システム管理者に問い合わせてください。 グループ ポリシーを使用してドメインに IPsec が適用されている場合は、展開中に問題が発生する可能性があります。 回避策は、クラスター内の他のノードが PXE ブート中にヘッド ノードと通信できるように、ヘッド ノードを IPsec 境界サーバーにすることです。
  • ワークステーション ノードまたは非管理対象サーバー ノードをクラスターに追加する場合は、トポロジ 5 (エンタープライズ ネットワーク上のすべてのノード) が推奨トポロジですが、その他のトポロジがサポートされます。 他のトポロジにワークステーション ノードを追加する場合は、「Windows HPC クラスターへのワークステーション ノードの追加 に関するページの内容を参照してください。
  • ブローカー ノードをクラスターに追加する場合は、SOA セッションを開始しているクライアントが接続されているネットワーク (通常はエンタープライズ ネットワーク) と、SOA サービスを実行しているノードが接続されているネットワーク (クライアントが接続されているネットワークとは異なる場合) に接続されている必要があります。
  • クラスターに Azure ノードを追加する場合は、HPC Pack でサポートされている任意のクラスター ネットワーク トポロジで HPC クラスターを構成できます。 クラスターの管理に使用され、Azure への接続が必要なヘッド ノードとクライアント コンピューターは、インターネット経由で Azure サービスに接続できる必要があります。

1.8: HPC ノード間の通信をセキュリティで保護するために使用する証明書を準備する

Microsoft HPC Pack 2016 (以降) クラスターでは、X.509 証明書を使用して HPC ノード間の通信をセキュリティで保護します。 すべての HPC ノードで同じ証明書を 1 つ使用することも、2 つの異なる証明書を使用することもできます。

  • ヘッド ノードの証明書 - この証明書は、Service Fabric クラスター (HA に使用される場合) と HPC ノード間の通信をセキュリティで保護するために、ヘッド ノード (またはヘッド ノード) にインストールされます。 また、証明書が自己署名されている場合は、Burst を使用して Azure IaaS VM 機能を使用して Azure IaaS コンピューティング ノードをデプロイする予定の場合は、それを Azure Key Vault 証明書にもインポートする必要があります。
  • 他のノードの証明書 - この証明書は、HPC ノード間の通信をセキュリティで保護するために、ヘッド ノード (またはヘッド ノード) 以外の HPC ノードにインストールされます。 すべての HPC ノードで同じ証明書を 1 つ使用することを選択した場合、これはヘッド ノードの証明書 同じ証明書です。

証明書は、次の要件を満たしている必要があります。

  • キー交換が可能な秘密キー があります。
  • キーの使用法には、デジタル署名、キー暗号化、キー契約、および証明書署名が含まれます。
  • 拡張キー使用法には、クライアント認証 と サーバー認証が含まれます。
  • 2 つの異なる証明書を使用する場合は、同じサブジェクト名 必要があります。

Service Fabric クラスター セキュリティで保護するために証明書を使用する場合は、次の 追加要件満たす必要があります。

  1. 証明書のプロバイダーは、Microsoft Enhanced RSA および AES Cryptographic Providerする必要があります。
  2. RSA キーの長さは、2048 ビット 必要があります。

これらの要件を満たす証明書がまだない場合は、証明機関に証明書を要求することも、自己署名証明書を使用することもできます。 自己署名証明書を生成するために、HPC Pack インストール メディアのセットアップ フォルダーに証明書を CreateHpcCertificate.ps1 PowerShell スクリプト ツールを提供します。

.\CreateHpcCertificate.ps1 -CommonName "HPCPackNodeCommunication" -Path "d:\hpccomm.pfx" -Password (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force)

証明機関 (CA) 署名付き証明書または既存の自己署名証明書を使用している場合は、次のコマンドを実行し、KeySpec、サブジェクト、キー使用法、拡張キー使用法、公開キーの長さ、、および プロバイダーの値を確認できます。

CertUtil.exe -p "<password>" -v -dump <path-of-pfxFile>

  • サブジェクト、キー使用法、拡張キー使用法、または公開キーの長さ の値が一致しない場合は、証明書を生成し直す必要があります。

  • KeySpec の値 ("1 -- AT_KEYEXCHANGE") または Provider が一致しない場合は、 証明書を生成し直す必要はありません。次のコマンドを実行して、KeySpec 値とプロバイダー値 変更 証明書をインポートしてから、certlm.msc 実行して、要件を満たす新しい PFX ファイルに証明書 (秘密キーを含む) をエクスポートします。

    CertUtil.exe -f -p "<password>" -csp "Microsoft Enhanced RSA and AES Cryptographic Provider" -importpfx "<path-of-pfxFile>" AT_KEYEXCHANGE

手順 1.2 で 1 つのヘッド ノードを使用し、自己署名証明書を使用する場合は、ヘッド ノードのインストール時にセットアップ ウィザードで自己署名証明書を生成することもできます。

他のノードに自己署名証明書を使用する場合は、このガイドの後半の手順 3.4で HPC Cluster Manager で自己署名証明書 生成できます。

1.9: スクリプト化された電源制御ツールの統合を準備する (省略可能)

クラスター管理コンソール (HPC クラスター マネージャー) には、ノードをリモートで開始、シャットダウン、再起動するためのアクションが含まれています。 これらのアクションは、オペレーティング システム コマンドを使用してこれらの電源制御操作を実行するスクリプト ファイル (CcpPower.cmd) にリンクされます。 そのスクリプト ファイル内の既定のオペレーティング システム コマンドを、クラスター ソリューションのベンダーによって提供されるインテリジェント プラットフォーム管理インターフェイス (IPMI) スクリプトなどの独自の電源制御スクリプトに置き換えることができます。

この統合の準備として、必要なすべてのスクリプト、.dll ファイル、および電源制御ツールのその他のコンポーネントを取得する必要があります。 必要なすべてのコンポーネントを取得したら、個別にテストし、クラスター内のノードとして展開するコンピューターで意図したとおりに動作することを確認します。

独自のスクリプト化された電源制御ツールを統合するようにCcpPower.cmdを変更する方法については、「付録 5: スクリプト化された Power Control Tools」このガイドの後半を参照してください。

次の手順