目標

• Power Virtual Server ネットワーキングの背後にある概念を理解します。
• IBM Cloud Transit Gateway を使用して、 Power Virtual Server を VPC に接続します。
• VPC サイト間 VPN を介して Power Virtual Server トラフィックをオンプレミスにルーティングします。
• VPC 仮想プライベート・エンドポイント・ゲートウェイを介して Power Virtual Server インスタンスをサービスに接続します。
• DNS サービスのルーティングと転送のルールを使用して、アーキテクチャー的に健全なネーム・レゾリューション・システムを構築します。
• クラウド・サービスに安全にアクセスするには、VPC 仮想プライベート・エンドポイント・ゲートウェイを使用します。

開始前に

このチュートリアルには、Power Edge Routing (PER) をサポートする Power Virtual Server データ・センターが必要です。 ソリューションが使用可能なデータ・センターのリストなどの詳細については、 Power Edge Router の概要 を参照してください。

このチュートリアルでは、以下が必要です。

• TerraformはInfrastructure as Codeを使用してリソースをプロビジョニングする

• Python (オプションで pytest コマンドを実行する場合)

• コンパニオン GitHub リポジトリー の前提条件

  前提条件環境を構築するための Dockerfile を含むいくつかのオプションについては、 前提条件 を参照してください。

さらに、ユーザー権限があるかどうかを確認してください。 ご使用のユーザー・アカウントに、このチュートリアルのすべてのリソースを作成および管理するための十分な権限があることを確認してください。 以下のリストを参照してください。

• VPC に必要な権限。
• Transit Gatewayを作成するために必要な権限。
• Power Virtual Serverに必要な許可。

リソースのプロビジョン

1. コンパニオン GitHub Repository には、アーキテクチャーを実装するためのソース・ファイルがあります。 デスクトップ・シェルで、リポジトリーを複製します。

   git clone https://github.com/IBM-Cloud/vpc-transit
   cd vpc-transit
   

2. config_tf ディレクトリーには、ファイル terraform.tfvars が必要です。 このチュートリアルの開始点は、ファイル template.power.terraform.tfvars です。

   cp config_tf/template.power.terraform.tfvars config_tf/terraform.tfvars
   

3. config_tf/terraform.tfvars を編集します。 そのファイル内のコメントを参考にしてください。 既存の resource_group_name および basename の値を変更します。 以下のテキストのストリング $BASENAME は、ここで指定されたベース名を参照しています。

4. 一度に 1 つのレイヤーでアーキテクチャーをプロビジョニングすることができます。 レイヤーを順番にインストールするために、シェル・コマンド ./apply.sh が提供されています。 以下は、ヘルプを表示します。

   ./apply.sh
   

5. まだお持ちでない場合は、 プラットフォームAPIキー を取得し、Terraformで使用するためにAPIキーをエクスポートします

   export IBMCLOUD_API_KEY=YourAPIKEy
   

6. すべてのレイヤーをインストールします。 「:」文字は、最初と最後のレイヤーを表すために使用されます。

   ./apply.sh : :
   

ダイアグラムでリソースを作成するには、最大 30 分かかる場合があります。 企業は VPC を使用してシミュレートされます。

重複しない IP アドレス・レイアウトの確認

アドレス・レイアウトを以下に示します。 重複していないアドレスに注意してください。

注意:

• アベイラビリティー・ゾーン・アドレス・スペース 10.1.0.0/16 は、 dal10の VPC アベイラビリティー・ゾーン 1 および Power Virtual Server ワークスペースに使用されます。
• エンタープライズ、トランジット、および spoke0 のアドレス・スペースはオーバーラップしません。
• 中継 VPC のオンプレミス・アドレス接頭部は、 Transit Gatewayを介してエンタープライズ経路を公示するために使用されます。 オンプレミス接頭部からの中継 VPC にサブネットは作成されません。 これについては、以下の「 Transit Gatewayの調査」ステップで説明しています。

IBM Cloud コンソールでアーキテクチャーを探索します。

1. 「仮想プライベート・クラウド」 にナビゲートします。
2. メニューから地域を選択します。
3. エンタープライズ VPC を選択し、アドレス接頭部 192.168.0.0/24 を確認します。
4. 「仮想プライベート・クラウド」 にナビゲートします。
5. トランジット VPC と通知を選択します。
   • アドレス接頭部 10.1.15.0/24 は、中継 VPC ゾーン 1 を定義します。
   • on-prem address prefix、 192.168.0.0/24。

SSH 鍵の検証

1. このプロビジョンでは、SSH に必要な鍵ペアのメンバーごとに 1 つずつ、2 つのファイルが作成されました。
   • config_tf/id_rsa-安全に保持する必要がある秘密鍵。
   • config_tf/id_rsa.pub-サード・パーティーに付与できる公開鍵。
2. 公開鍵は、クラウド内に 2 つの SSH 鍵を作成するために使用されました。
   • Power SSH 鍵。
   • VPC の SSH 鍵。
3. VPC SSH 鍵を見つけます。
   • VPC の SSH 鍵 にナビゲートします。
   • $BASENAME を使用して SSH 鍵を確認します。
4. 以下のように、Power SSH 鍵を見つけます。
   • 「Power SSH 鍵」 にナビゲートします。
   • 左側のナビゲーション・パネルで、$BASENAME を持つ Workspaces という語の下のドロップダウンからワークスペースを選択します。
   • $BASENAME を使用して SSH 鍵を確認します。

オプションで、クラウド SSH 鍵の内容が公開鍵ファイルの内容と一致することを確認します。

Power® Virtual Serverを開く

このプロビジョンでは、SSH 鍵とともに Power® Virtual Server ワークスペース、サブネット、およびインスタンスが作成されました。

• 「Power Virtual Server サブネット」 ページを開きます。
• 左側のナビゲーション・パネルで、$BASENAME を持つ Workspaces という語の下のドロップダウンからワークスペースを選択します。
• 左側の 「ネットワーキング」 メニューの 「サブネット」 をクリックし (必要な場合)、作成されたパブリック・サブネットとプライベート・サブネットに注目します。
• プライベート・サブネット名をクリックし、後でインスタンスの IP テーブル構成で参照される ゲートウェイ ・アドレスを確認します。
• パブリック・サブネット名をクリックし、後でインスタンスの IP テーブル構成で参照される ゲートウェイ ・アドレスを確認します。
• 左側の 「仮想サーバー・インスタンス」 をクリックし、パブリック IP アドレスおよびプライベート IP アドレスとともにプロビジョンされたインスタンスに注目します。

仮想サーバーの構成

Terraform 構成は Power Virtual Server Linux 仮想サーバー・インスタンスを作成しましたが、完全には構成できませんでした。 テストをサポートするために、IP 経路テーブルを構成し、NGINX サーバーをインストールできるようになりました。

cd power_tf; # should be in the .../vpc-transit/power_tf directory
terraform output fixpower

このエクスペリエンスは次のようになります。

% cd power_tf
% terraform output fixpower
[
  {
    "abc-spoke1" = <<-EOT
    # ssh -J root@52.116.131.48 root@10.1.2.31
    ssh -oProxyCommand="ssh -W %h:%p -i ../config_tf/id_rsa root@52.116.131.48" -i ../config_tf/id_rsa root@10.1.2.31
    ip route add 10.0.0.0/8 via 10.1.2.1 dev eth0
    ip route add 172.16.0.0/12 via 10.1.2.1 dev eth0
    ip route add 192.168.0.0/16 via 10.1.2.1 dev eth0
    ip route change default via 192.168.232.1 dev eth1
    exit
    # it is now possible to ssh directly to the public IP address
    ssh -i ../config_tf/id_rsa root@150.240.147.36
    # execute the rest of these commands to install nginx for testing
    zypper install -y nginx
    systemctl start nginx
    echo abc-spoke1 > /srv/www/htdocs/name
    sleep 10
    curl localhost/name


    EOT
  },
]

新しい端末ウィンドウで、コマンドを一度に 1 行ずつコピー・アンド・ペーストします。 以下に、何が起こっているかを示します。

• SSH コマンドは、先ほど作成した SSH 秘密鍵を使用して仮想サーバー・インスタンスにログインします。 中間トランジット VPC 仮想サーバーを ジャンプ する必要があります。 -oProxyCommand はジャンプサーバーを設定する。
• ip route コマンドは、 PowerLinux サーバー上で実行され、プライベート・サブネット (eth0) を介してすべての プライベート・ネットワーク CIDR ブロックを経路指定します。 これらには、 10.0.0.0 クラウド CIDR ブロックと 192.168.0.0 エンタープライズ CIDR ブロックの両方が含まれていることに注意してください。
• デフォルトでは、ワークステーションの IP アドレスを含む残りのアドレスがパブリック・サブネット (eth1) を介して経路指定されます。 これにより、テスト自動化は、将来、仮想サーバー・インスタンスのパブリック IP アドレスに直接 SSH で接続し、ジャンプ・サーバーを回避することができます。
• SSH セッションを終了します。
• SSH を使用して、パブリック IP アドレスを使用してインスタンスに直接ログインします。 これにより、iptable 構成が正しいことが検証されます。
• 最後のステップは、NGINX をインストールすることです。 NGINXは、 curl コマンドを使用して検証されるウェブページをホストする HTTP です。

このシェルは、将来のステップで使用できるようにしておくことができます。

ネットワーク接続のテスト

pytest テスト・スイートは、通信パスを徹底的にテストするために使用されます。

リーダーが pytest を使用して結果を検証する必要はありません。 以下に示すテスト結果を手書きで再現するのは簡単ですが、面倒なことです。 出力例の各行について、 IBM Cloud コンソールの 「リソース」 ビューでリソースを見つけ、左側のリソースにナビゲートして、SSH セッションのパブリック IP アドレスを見つけます。 クラウド・インスタンスのシェルを使用して、右側のインスタンスのプライベート IP アドレス curl A.B.C.D/name に対して curl コマンドを実行します。

README.mdで説明されているように、Python をインストールして使用するには、いくつかの方法があります。

各 pytest は、左側のインスタンスに対して SSH をテストし、右側のインスタンスに対して curl コマンドを実行するなどの接続テストを実行します。 左側のインスタンスへのログインには、デフォルトの SSH 環境が使用されます。 予期しないテスト結果が表示された場合は、 pytest troubleshooting セクションを試してください。

現行ディレクトリーが vpc-transit であることを確認してください。

cd ..
pwd; # .../vpc-transit

pytest を使用してネットワーク接続をテストします。

pytest

出力例:

(vpc-transit) IBM-Cloud/vpc-transit % pytest
============================================ test session starts =============================================
platform darwin -- Python 3.11.5, pytest-7.4.4, pluggy-1.3.0 -- /Users/powellquiring/github.com/IBM-Cloud/vpc-transit/venv/bin/python
cachedir: .pytest_cache
rootdir: /Users/powellquiring/github.com/IBM-Cloud/vpc-transit
configfile: pytest.ini
testpaths: py
plugins: xdist-3.5.0
collected 31 items

py/test_transit.py::test_ping[l-spoke0        -> r-spoke0] PASSED                                      [  3%]
py/test_transit.py::test_ping[l-spoke0        -> r-enterprise-z1-worker] PASSED                        [  6%]
py/test_transit.py::test_ping[l-spoke0        -> r-transit-z1-worker] PASSED                           [  9%]
py/test_transit.py::test_ping[l-enterprise-z1-worker -> r-spoke0] PASSED                               [ 12%]
py/test_transit.py::test_ping[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                 [ 16%]
py/test_transit.py::test_ping[l-enterprise-z1-worker -> r-transit-z1-worker] PASSED                    [ 19%]
py/test_transit.py::test_ping[l-transit-z1-worker -> r-spoke0] PASSED                                  [ 22%]
py/test_transit.py::test_ping[l-transit-z1-worker -> r-enterprise-z1-worker] PASSED                    [ 25%]
py/test_transit.py::test_ping[l-transit-z1-worker -> r-transit-z1-worker] PASSED                       [ 29%]
py/test_transit.py::test_curl[l-spoke0        -> r-spoke0] PASSED                                      [ 32%]
py/test_transit.py::test_curl[l-spoke0        -> r-enterprise-z1-worker] PASSED                        [ 35%]
py/test_transit.py::test_curl[l-spoke0        -> r-transit-z1-worker] PASSED                           [ 38%]
py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0] PASSED                               [ 41%]
py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                 [ 45%]
py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] PASSED                    [ 48%]
py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke0] PASSED                                  [ 51%]
py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] PASSED                    [ 54%]
py/test_transit.py::test_curl[l-transit-z1-worker -> r-transit-z1-worker] PASSED                       [ 58%]
py/test_transit.py::test_curl_dns[l-spoke0        -> r-abc-enterprise-z1-worker.abc-enterprise.example.com] PASSED [ 61%]
py/test_transit.py::test_curl_dns[l-spoke0        -> r-abc-transit-z1-worker.abc-transit.example.com] PASSED [ 64%]
py/test_transit.py::test_curl_dns[l-enterprise-z1-worker -> r-abc-enterprise-z1-worker.abc-enterprise.example.com] PASSED [ 67%]
py/test_transit.py::test_curl_dns[l-enterprise-z1-worker -> r-abc-transit-z1-worker.abc-transit.example.com] PASSED [ 70%]
py/test_transit.py::test_curl_dns[l-transit-z1-worker -> r-abc-enterprise-z1-worker.abc-enterprise.example.com] PASSED [ 74%]
py/test_transit.py::test_curl_dns[l-transit-z1-worker -> r-abc-transit-z1-worker.abc-transit.example.com] PASSED [ 77%]
py/test_transit.py::test_vpe_dns_resolution[cos spoke0 -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 80%]
py/test_transit.py::test_vpe_dns_resolution[cos enterprise-z1-worker -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 83%]
py/test_transit.py::test_vpe_dns_resolution[cos transit-z1-worker -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 87%]
py/test_transit.py::test_vpe[cos spoke0 -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 90%]
py/test_transit.py::test_vpe[cos enterprise-z1-worker -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 93%]
py/test_transit.py::test_vpe[cos transit-z1-worker -> transit s3.direct.us-south.cloud-object-storage.appdomain.cloud] PASSED [ 96%]
py/test_transit.py::test_lb[lb0] SKIPPED (got empty parameter set ['lb'], function test_lb at /Use...) [100%]

======================================= 30 passed, 1 skipped in 42.36s =======================================

矢印「->」の左側のインスタンスに対する各テスト SSH は、以下の方法で矢印の右側にアクセスします。

• test_ping-IP アドレスを ping します。
• test_curl- Curl IP アドレス。
• test_curl_dns- Curl DNS 名。
• test_vpe_dns_resolution-VPC 仮想プライベート・エンドポイント (VPE) 名の DNS 名がクラウドの CIDR ブロック内の IP アドレスに解決されることを確認します (このテストでは、実際には右側にアクセスしません)。
• test_vpe-必要に応じて、DNS 名とリソース固有のツールを使用してリソースを演習します。

この構成ではスキップされるロード・バランサー (lb) テストを除き、すべてのテストに合格する必要があります。

Transit Gateway の調査

この図には、Power インスタンスからエンタープライズ・インスタンスへのトラフィック・パスを示す緑色の線があります。

トランジット Transit Gatewayを検査します。

• 「Transit gateway」 を開き、 $BASENAME-tgw を選択します。
• 以下の 2 つの接続があります。
  1. トランジット VPC。
  2. Spoke0 (Power Systems Virtual Server).
• 「BGP」 をクリックし、 「レポートの生成」 をクリックします。 エンタープライズ CIDR である 192.168.0.0/24 は、中継 VPC によって広告されます。

トランジット VPC を介したエンタープライズ・データ・パスへのパワーを理解する

前のステップでは、 Transit Gateway が、 192.168.0.4 などのエンタープライズ IP アドレスに送信する際に、Power インスタンスが中継 VPC に到達するために必要なエンタープライズ経路をどのように確認したかを示しました。 中継 VPC での VPC Ingress ルーティングは、トラフィックを VPN インスタンスに直接ルーティングします。

1. 仮想プライベート・クラウドにナビゲートします。
2. 左側の 「VPC」 をクリックします。
3. トランジット VPC をクリックします。
4. スクロールダウンして、 「ルーティング・テーブルの管理」 をクリックします。
5. vpn-ingress ルーティング・テーブルをクリックします。

「トラフィック (Traffic)」 ボックスで、 「 からの経路の受け入れ (Accepts routes from)」は、 VPN ゲートウェイを示します。 この構成により、VPN ゲートウェイはこのルーティング・テーブルに経路を自動的に作成し、必要に応じて経路のネクスト・ホップ・アドレスを調整することができます。

この経路の現在の状況は、 「経路」 テーブルで確認できます。 これは、 192.168.0.0/24 にアドレス指定されたトラフィックが VPC 内の ネクスト・ホップ ・アドレスに転送されることを示します。 ネクスト・ホップの IP アドレスをメモします。 これは VPC VPN サービスにあります。

1. 「VPN」 にナビゲートし、中継 VPN ゲートウェイを選択します。
2. 「ゲートウェイ・メンバー」 セクションを調べます。 アクティブ IP の プライベート IP は、前述の ネクスト・ホップ と一致する必要があります。

高可用性を確保するために、VPN サービスは、 ネクスト・ホップ IP アドレスと、使用可能な VPN リソースのアクティブ IP アドレスとの整合性を保ちます。

Power DNS 解決の検証

この図には、 Power® Virtual Server インスタンスで使用される DNS 解決順方向チェーンを示す青い線があります。

以下に示す $BASENAME は abc です。ユーザー自身の $BASENAME に置き換えてください。 Power® Virtual Server インスタンス・シェルで、以下を実行します。

abc-spoke0:~ # BASENAME=abc
abc-spoke0:~ # dig  abc-enterprise-z1-worker.$BASENAME-enterprise.com

; <<>> DiG 9.16.44 <<>> abc-enterprise-z1-worker.abc-enterprise.com
;; global options: +cmd
;; Got answer:
...
;; ANSWER SECTION:
abc-enterprise-z1-worker.abc-enterprise.com. 2454 IN A 192.168.0.4
...

curl コマンドは、エンタープライズからデータを返します。

curl $BASENAME-enterprise-z1-worker.$BASENAME-enterprise.com/name

例:

abc-spoke0:~ # curl $BASENAME-enterprise-z1-worker.$BASENAME-enterprise.com/name
abc-enterprise-z1-worker

青い線に示されている DNS 転送パスを確認することができます。 最初に、アドレスを解決している DNS サーバーを見つけます。

1. Power Systems Virtual Server にナビゲートし、ワークスペースを選択します。
2. 左側の 「サブネット」 をクリックします。
3. プライベート・サブネットをクリックします。
4. 「DNS サーバー」 の 1 つが 10.1.15.xy です。 正確な IP をメモします。

これは、 DNS Services カスタム・リゾルバー のアドレスです。 アドレスの初期ビット 10.1.15 は、それが転送 VPC 内にあることを示します。 DNS インスタンスとカスタム・リゾルバーを見つけます。

1. リソース・リストにナビゲートします。
2. 「ネットワーキング」 セクションを開き、DNS サービスの中継インスタンスをクリックします。
3. Transit DNS インスタンスで、左側の 「カスタム・リゾルバー」 をクリックします。
4. カスタムリゾルバをクリックすると、詳細ページが開きます。

前述の DNS サーバーの IP アドレス (Power プライベート・サブネット内にあります) を 「リゾルバーの場所」 の IP アドレスと突き合わせます。

この図は、この DNS リゾルバーからエンタープライズ・ネットワークへの矢印を示しています。 以下の転送規則に従って、これを確認します。

1. 上部にある 「転送ルール」 タブをクリックします。
2. $BASENAME-enterprise.com サブドメインの転送規則は、 192.168.0.xy アドレスを持つエンタープライズ・リゾルバーに転送されることに注意してください。 これらは、企業内の DNS リゾルバーの IP アドレスです。 これらを確認するには、「リソース」リストでエンタープライズの DNS サービスを見つけます。

VPC 仮想プライベート・エンドポイント・ゲートウェイの理解

IBM Cloud VPE for VPC を使用すると、VPC ネットワークから、VPC 内のサブネットから割り当てられた任意の IP アドレスを使用して、サポートされている IBM Cloud サービスに接続することができます。 Object Storage がプロビジョンされました。 Object Storage の VPE for VPC がプロビジョンされたときに、DNS サービスで DNS レコードが作成されました。 中継 VPC で Object Storage の DNS 名を見つけます。

1. VPC 仮想プライベート・エンドポイント・ゲートウェイ にナビゲートします。
2. $BASENAME-transit-cos VPC 仮想プライベート・エンドポイント・ゲートウェイを選択します。

• 接続されているリソースの IP アドレスをメモします。 これは、輸送 VPC ゾーン 1 の 10.1.15.x です。
• サービス・エンドポイントをメモします。 リージョン固有です ( s3.direct.us-south.cloud-object-storage.appdomain.cloud)。

Power® Virtual Server インスタンス・シェルで、DNS 名を指定した dig コマンドを使用して IP アドレスを見つけます。 以下に例（省略）を示す

abc-spoke0:~ # dig s3.direct.us-south.cloud-object-storage.appdomain.cloud

; <<>> DiG 9.16.44 <<>> s3.direct.us-south.cloud-object-storage.appdomain.cloud
...
;; ANSWER SECTION:
s3.direct.us-south.cloud-object-storage.appdomain.cloud. 900 IN	A 10.1.15.132
...

この場合、 10.1.15.132 は、仮想プライベート・エンドポイント・ゲートウェイを介した Object Storage の IP アドレスです。

VPC セキュリティーの実施

VPC には、サブネットのネットワーク・アクセス制御リスト (ACL)] (/docs/vpc?topic=vpc-using-acls) と、ネットワーク・リソースへのアクセスを制限するように構成できるネットワーク・インターフェースの セキュリティー・グループ があります。

Power Virtual Server インスタンスのみから VPC 仮想プライベート・エンドポイント・ゲートウェイへのアクセスを制限するセキュリティー・グループ・ルールを導入します。

Power® Virtual Server インスタンス・シェルで、 curl コマンドを使用して、中継 VPC 内の VPC インスタンスにアクセスします。

BASENAME=abc
curl $BASENAME-transit-z1-worker.$BASENAME-transit.com/name

セキュリティー・グループを見つけて、ルールを強化します。

• VPC の仮想サーバー・インスタンス にナビゲートします。
• Transit インスタンスをクリックします。
• 「ネットワーク・インターフェース」 までスクロールダウンし、 「セキュリティー・グループ」 の項目をクリックします。
• 「セキュリティー・グループ」 プロパティー・ページの 「ルール」 タブをクリックします。
• 10.0.0.0/8 ソースを見つけます。 右側のハンバーガー・メニューをクリックし、 「編集」 をクリックします。
• CIDR を一時的に 10.0.0.0/32 に変更します。

Power® Virtual Server インスタンス・シェルに戻り、 curl コマンドを繰り返します。 コマンドは完了しません。

curl $BASENAME-transit-z1-s0.$BASENAME-transit.com/name

シェル内の IP アドレスを判別します。

hostname -I

例:

abc-spoke0:~ # hostname -I
10.1.0.37 192.168.230.234

最初の 10.1.0.x 番号はプライベート IP アドレスです。 ブラウザーの「VPC セキュリティー・グループ」タブに戻り、セキュリティー・グループ・ルールを編集して address/32 に変更します (例えば、 10.1.0.37/32)。

curl を再試行すると、機能するはずです。

curl $BASENAME-transit-z1-s0.$BASENAME-transit.com/name

セキュリティー・グループ・ルールに戻り、CIDR ブロックを元の値 10.0.0.0/8 に戻します。

リソースを削除する

./apply.sh コマンドを使用して、すべてのディレクトリーで terraform destroy を逆の順序で実行します。

./apply.sh -d : :

チュートリアルを発展させる

ご使用のアーキテクチャーは、示されているものと同じではない可能性がありますが、ここで説明する基本コンポーネントから構成される可能性があります。 このチュートリアルを展開するためのアイデア:

• VPCロードバランサーを使用して](/docs/openshift?topic=openshift-vpclb-about)、複数の Power Virtual Serverンス間のトラフィックを分散します。
• IBM Cloud® Internet Services を使用して、着信パブリック・インターネット・アクセスを統合します。
• トランジットに Flow Logs for VPC キャプチャー を追加します。
• 各スポークを エンタープライズ 内の別個のアカウントに配置します。

関連コンテンツ

• 既に Power Virtual Server ワークスペースがあり、サイト VPN に VPC サイトをインストールするだけでよいですか? 「 PowerVPN サイト間」を参照してください。
• 金融サービス向け IBM Cloud
• 複数のロケーションおよびリージョンにわたって分離されたワークロードをデプロイする方法
• 仮想プライベート・クラウド内のパブリック・フロントエンドとプライベート・バックエンド、
• 透過的な VNF およびスポーク・ツー・スポーク・トラフィックを使用するプライベート・ハブおよびスポーク