インフラストラクチャー・プロバイダーの計画

Satellite ロケーションの作成に使用するインフラストラクチャー・プロバイダーを選択します。

オンプレミス

既存のインフラが整備されたデータセンター、または最低限のハードウェア要件を満たすエッジ拠点（例えば、自社のローカルサイトにある3つのラックなど）を利用してください。

サポートされるベア・メタル・サーバー

クラシック用の IBM Cloud® Bare Metal Servers など、 Satellite のロケーションに接続されたホストとして、サポートされているベア・メタル・サーバーを使用できます。 詳細については、「 Bare Metal Server の要件 」を参照してください。

IBM 以外のクラウド・プロバイダー

Amazon Web Services （ AWS ）、 Google Cloud Platform （ GCP ）、 Microsoft Azure、 Alibaba Cloud など、お好みのクラウドプロバイダーをご利用いただけます。

IBM Cloud

IBM Cloud テスト目的でサポートされています。 本番環境において、サポートされている IBM Cloud インフラストラクチャは、 Red Hat CoreOS を実行している IBM Cloud® Bare Metal Servers for Classicのみです。 Virtual Servers for VPC など、その他の IBM Cloud 仮想サーバーは、テスト環境でのみサポートされています。

複数ゾーン・ロケーションの計画

インフラストラクチャー・プロバイダーで、遅延時間に関する要件を満たすマルチゾーン・ロケーションを指定します。

マルチゾーン

Satellite の1つのロケーションでは、 高可用性を確保するために ホストを均等に分散させるため、物理的に分離されたゾーンが少なくとも3つ必要です。 たとえば、クラウドプロバイダーが同一リージョン内に3つの異なるゾーンを提供している場合や、オンプレミス環境において、独立したネットワークおよび電源システムを備えた3つのラックを使用している場合などが挙げられます。

IBM Cloud とロケーションの間の待ち時間

Satellite のロケーションのコントロールプレーンに接続するホストは、 Satellite のロケーションが管理されている IBM Cloud リージョンへの往復時間（RTT）が200ミリ秒以下（<= 200ms ）の低遅延接続を備えている必要があります。 待ち時間が増えると、Satellite リンク・スループット、Satellite 対応 IBM Cloud サービス・プロビジョニング時間、ホスト障害リカバリー時間、および極端な場合には Satellite ロケーション・コントロール・プレーンで実行されるリソース (Red Hat OpenShift クラスター・マスターなど) の可用性など、パフォーマンスに影響が生じる可能性があります。 詳しくは、IBM Cloud と Satellite ロケーション・コントロール・プレーンのホストの間の待ち時間のテストを参照してください。

ロケーション内のホスト間の待ち時間

ホストインフラストラクチャのセットアップでは、 Satellite のロケーション制御プレーンワーカーノードとして使用されるホストと、そのロケーション内のクラスターや Satellite 対応の IBM Cloud サービス など、その他のリソースとして使用されるホストとの間で、往復時間（RTT）が100ミリ秒以下（<= 100ms ）の低遅延接続が確保されている必要があります。 例えば、AWS などのクラウド・プロバイダーでは、このセットアップは通常、Satellite ロケーション内のすべてのホストが同じクラウド・リージョン (us-east-1 など) からのものであることを意味します。 待ち時間が長くなると、プロビジョニングとリカバリー時間、クラスター内のワーカー・ノード数の減少、Satellite 対応 IBM Cloud サービスの機能低下、クラスター・アプリケーションの障害など、パフォーマンスへの影響が生じる可能性があります。

ホスト・システムの計画

インフラストラクチャー・プロバイダーの 3 つのゾーンのそれぞれに、互換性のあるホストを作成し、Satellite に追加するための計画を立てます。 インフラストラクチャ プロバイダー上のホスト インスタンスは、ロケーションのコントロールプレーンや、 Satellite ロケーションで実行されているサービスのコンピュート ホストとなり、 Red Hat OpenShift クラスターのワーカー ノードと同じ役割を果たします。

• 各ホストは、 Satelliteのホストに関する最低要件 を満たしている必要があります。
• ホストは、 Red Hat の公式認定を受けたハードウェア上で動作している必要があります。

必要なホストの台数を計算するには、Satellite ロケーションのサイズ設定を参照してください。

satellite-host-check スクリプトを使用して、アタッチメントを行う前にホストの設定を確認してください。 詳しくは、ホスト・セットアップの確認を参照してください。

ロケーションで Red Hat CoreOS サポートを有効にするかどうかの決定

ロケーションを作成する際、 Red Hat CoreOS のサポートを有効にするかどうかを選択します。 Red Hat CoreOS-enabled のロケーションでは、ダイレクトリンク、 OpenShift による仮想化、BYOK/KYOK暗号化など、より多くの機能が利用可能になりますが、より大規模なインフラストラクチャが必要となります。 Red Hat CoreOS をサポートしていない拠点では、利用できる機能は限られますが、設置スペースを削減でき、容量単位あたりのクラスタ数をより多くサポートできます。 詳細な比較については、「 Satellite のロケーションの規模決定 」をご覧ください。

以下の表は、 Red Hat CoreOS-enabled。 この表は、 Red Hat CoreOS-enabled の場所でこれらの機能をセットアップする際に使用できる、サポートされているホストタイプも示しています。

現在地がRed Hat CoreOS,で有効になっているかどうかを確認するには、「現在地Red Hat CoreOSで有効になっているか/span>がか」を参照してください。

「BYOK（Bring Your Own Key）」または「KYOK（Keep Your Own Key）」機能は、 Red Hat OpenShift on IBM Cloud 4.13 以降の RHCOS 対応環境において、RHEL および RHCOS ホストの両方でサポートされています。 この機能はクラスターのシークレットのみを暗号化するものであり、クラスターやワーカープールの作成時には利用できません。 クラスタまたはワーカープールの作成後、 ibmcloud oc kms enable コマンドを実行して有効にしてください。 この機能は、一度有効にすると無効にすることはできません。

AWS 資格情報

Amazon Web Services (AWS) クラウド内に Satellite リソースを自動的に作成するために、Satellite で使用できる AWS 資格情報を取得します。

1. テンプレートから「 Satellite 」ロケーションを作成するために必要な AWS アカウントの権限 が割り当てられていることを確認してください。
2. EC2 へのアクセス権限のみを持つ、独立したIAMユーザーを作成します。
3. IAMユーザーのアクセスキーIDとシークレットアクセスキーの認証情報を取得します。
4. オプション: Satellite ロケーションの作成中に資格情報を提供するには、JSON ファイルで資格情報をフォーマットします。 client_id はアクセス・キーの ID であり、client_secret は AWS で IAM ユーザー用に作成したシークレット・アクセス・キーです。

   {
       "client_id":"string",
       "client_secret": "string"
   }
   

Azure資格情報

Azure クラウド内に Satellite リソースを自動的に作成するために、Satellite で使用できる Microsoft Azure 資格情報を取得します。

1. テンプレートから「 Satellite 」ロケーションを作成するために必要な Azure アカウントの権限 が割り当てられていることを確認してください。
2. Azure アカウントにログインしてください コマンドラインから。

   az login
   

3. アカウントで使用可能なサブスクリプションをリストします。

   az account list
   

4. Azure リソースを作成するサブスクリプションを設定します。

   az account set --subscription="<subscription_ID>"
   

5. Contributor 役割 (有効範囲はサブスクリプション) を持つサービス・プリンシパル ID を作成します。 これらの資格情報は、Azure アカウントにリソースをプロビジョンするために IBM Cloud Satellite によって使用されます。 詳細については、『 Azure 』のドキュメントを参照してください。

   az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/<subscription_ID>" -n"<service_principal_name>"
   

6. 出力にある appID、password、および tenant のフィールドの値をメモします。

   {
   "appId": "<azure-client-id>",
   "displayName": "<service_principal_name>",
   "name": "http://<service_principal_name>",
   "password": "<azure-secret-key>",
   "tenant": "<tenant-id>"
   }
   

7. オプション: Satellite ロケーションの作成中に資格情報を提供するには、JSON ファイルで資格情報をフォーマットします。

   {
       "app_id":"string",
       "tenant_id":"string",
       "password": "string"
   }
   

GCP 資格情報

GCP クラウド内に Satellite リソースを自動的に作成するために、Satellite で使用できる Google Cloud Platform (GCP) 資格情報を取得します。

1. サービスアカウントとアカウントキーを作成する 少なくとも必要な GCP 権限 を備えていること。 サービス・アカウントの作成の一環として、JSON 鍵ファイルがローカル・マシンにダウンロードされます。
2. ローカル・マシンで JSON 鍵ファイルを開き、フォーマットが以下の例に一致することを確認します。 この JSON 鍵ファイルは、Satellite ロケーションの作成などのアクション用の GCP 資格情報として提供できます。

   {
       "type":"string",
       "project_id":"string",
       "private_key_id": "string",
       "private_key": "string",
       "client_email": "string",
       "client_id": "string",
       "auth_uri": "string",
       "token_uri": "string",
       "auth_provider_x509_cert_url": "string",
       "client_x509_cert_url": "string"
   }
   

VMWare 資格情報

VMWareクラウド上で、あなたに代わってリソース Satellite を作成 Satellite するために使用できるVMWareの認証情報を取得します。

1. テンプレートから「 Satellite 」ロケーションを作成するために必要な VMWare アカウントの権限 が割り当てられていることを確認してください。
2. 管理者 役割を持つ ユーザーを識別または作成 します。
3. ネットワーク情報 を見つけます。
4. VMware Cloud Director テンプレート にこの情報を指定します。