ネットワーク展開ガイド

このトピックでは、ネットワーク内でのゲートウェイの展開で可能なさまざまなシナリオについて説明します。 組織のセキュリティを向上させるため、CA Technologies では、サービス ネットワークを管理ネットワークから分離することをお勧めします。
gateway10
コンテナ Gateway ユーザ
このトピックは、アプライアンスベースの API Gateway ユーザを対象にしています。 執筆時点で、Kubernetes ポッドは、デフォルトでコンテナ ネットワーク インターフェース(CNI)を介して 1 つのネットワーク インターフェースに接続するようにセットアップされます。 複数のネットワーク インターフェース接続要件がある場合、拡張機能またはプラグイン(Multus CNI など)についてサードパーティのベンダーへの問い合わせが必要な場合があります。 Kubernetes に関連するその他のネットワーク情報については、こちらの Kubernetes ドキュメントを参照してください。
クラウドに展開されているコンテナ Gateway の参照アーキテクチャを探している場合は、この Techdocs トピックを参照してください。
2
このトピックでは、ネットワーク内での
Layer7 API Gateway
の展開で可能なさまざまなシナリオについて説明します。 組織のセキュリティを向上させるため、Layer7 Broadcom では、サービス ネットワークを管理ネットワークから分離することをお勧めします。
CentOS 7 およびネットワーク インターフェース ネーミング スキームの変更
CentOS/RHEL の以前のリリース(たとえば、6.x またはそれ以前)にインストールされた API Gateway の旧バージョンとは異なり、従来のカーネルベースのネットワーク インターフェース ネーミング スキーム(たとえば、eth0、eth1、eth2)はデフォルトの規則として適用されなくなりました。 ネットワーク インターフェースに対してネットワーク デバイス ネーミングの一貫性と予測可能性を高めるために、CentOS 7 では、主に、ファームウェアまたは BIOS がオンボード デバイスに提供するインデックス番号(たとえば、en1)または PCI Express ホットプラグ スロットのインデックス番号(たとえば、ens1)に基づいた名前と、ハードウェア コネクタの物理的な場所(たとえば、enp0)に基づいた名前を利用します。 これまでは、再起動前にデバイスが削除、追加、またはスワップされた場合、カーネルベースの名前が予期せず変更される可能性がありました。
Gateway バージョン 10.0+ の運用では、Gateway フォーム ファクタごとに一貫したネットワーク デバイス ネーミングが適用されます。 このページでネットワーク展開シナリオを見ていく前に、ネットワーク インターフェースを正しく識別していることを確認してください。そのカーネルベースの名前が変更されている(つまり、eth0 が ssg_eth0 になっている)可能性があるからです。 これが特に重要なのは、ハードウェア/仮想アプライアンス、AMI、および Azure フォーム ファクタの場合にのみ、CentOS 7 に Gateway バージョン 10.0 をインストールできるからです。
Oracle X8-2、X7-2、または X5-2 アプライアンスにインストールされた Gateway バージョン 10.0 への影響
X8-2、X7-2、または X5-2 アプライアンスで API Gateway を運用した場合、Gateway では「ssg_eth#」命名規則に従ってすべての既知のネットワーク インターフェースの名前がカスタマイズされます。 以下の表に、この名前のカスタマイズの概要を示します。
カーネルベースの名前(CentOS 7 以前)
一貫性のある名前(CentOS 7)
Gateway バージョン 10.0+ が付与する同等の名前
eth0
eno1
ssg_eth0
eth1
eno2
ssg_eth1
eth2
eno3d1
ssg_eth2
eth3
enp59s0f0
ssg_eth3
eth4
enp59s0f1
ssg_eth4
eth5
enp59s0f2
ssg_eth5
eth6
enp59s0f3
ssg_eth6
eth7
enp0s20f0u8u3c2 (ILOM)
ssg_usb0
上記の表はあくまで参考であり、ハードウェア アプライアンス Gateway に標準装備されている既知のネットワーク インターフェースに基づいています。
オープン仮想アプライアンス(OVA)にインストールされた Gateway バージョン 10.0 への影響
API Gateway の OVA フォーム ファクタの場合、プライマリ ネットワーク インターフェースは一貫性のある名前(たとえば、「ens160」)を採用するようになりました(以前の Gateway 8/9.x では「eth0」でした)。 OVA API Gateway バージョン 10.0+ の運用では、この一貫性のある名前が Gateway によって「ssg_eth0」に変更されています。
Amazon Machine Images (AMI)および Azure にインストールされた Gateway バージョン 10.0 への影響
単一のインターフェースを使用して Gateway バージョン 10.0+ を AMI で運用している場合にも、OVA API Gateway と同様に、同一の命名ロジックが適用されます。 「ens5」(以前の Gateway 8/9.x では「eth0」)ネットワーク インターフェースは、Gateway によって「ssg_eth0」に変更されています。
単一のインターフェースを使用して Gateway バージョン 10.0+ を Azure で運用している場合、「eth0」ネットワーク インターフェースは Gateway によって「ssg_eth0」に変更されています。
ファイアウォール ルールおよび API Gateway への影響
ネットワーク インターフェース名が従来の「eth#」から変更されているため、iptables/ip6tables にあるアプライアンスのファイアウォール ルールも、イメージの展開時に Gateway の「ssg_eth#」命名規則を使用するように更新されました。
追加のネットワーク インターフェースの命名方法
OVA、AMI、Azure のいずれかの Gateway に接続するために追加のネットワーク インターフェースが必要になった場合には、CentOS 7 の一貫した命名規則が引き続き適用されることに注意してください。 このような一貫性のある名前がどのように表示されるかは、接続しているデバイス タイプによって異なります。 追加のネットワーク インターフェースが必要な場合は、その一貫した名前を手動で追跡し、ファイアウォール ルールに合わせて必要に応じて iptables を変更する必要があります。
ネットワーク設定ファイルの命名方法
/etc/sysconfig/network-scripts/ にあるネットワーク設定ファイルでは、一貫性のある名前が保持されます(たとえば、「ifcg-ens160」)。 Gateway はネットワーク設定ファイル名を変更しません。ただし、以下のことを行います。
  • ネットワーク設定ファイルの NAME 属性と DEVICE 属性を新しい「ssg_eth#」名に変更します。
  • ネットワーク インターフェースの MAC アドレスを使用して、HWADDR 属性を追加します。
backup_manifest を使用して ifcfg ファイルをバックアップする方法については、こちらを参照してください。
予測可能ネットワーク インターフェース名が引き続きネットワーク サービス ログに表示される理由
Gateway の「ssg_eth#」ネーミング スキームに従って名前が変更されているにもかかわらず、ネットワーク サービス ログに予測可能ネットワーク インターフェース名(たとえば、「ens160」)が表示されるので混乱するかもしれません。 実際のネットワーク インターフェース設定ファイル(ifcfg)ファイルでは CentOS 7 の予測可能インターフェース ネーミング スキームが保持されるため、以下のハードウェア アプライアンス Gateway の例に示すように、その名前がネットワーク サービス ログに引き続き表示される場合があります。
Dec 04 17:27:50 cpu-02.hello.broadcom.net systemd[1]: Starting LSB: Bring up/down networking... Dec 04 17:27:51 cpu-02.hello.broadcom.net network[3488]: Bringing up loopback interface: [ OK ] Dec 04 17:27:51 cpu-02.hello.broadcom.net network[3488]: Bringing up interface eno1: [ OK ] Dec 04 17:27:51 cpu-02.hello.broadcom.net network[3488]: Bringing up interface eno1: [ OK ] Dec 04 17:27:52 cpu-02.hello.broadcom.net network[3488]: Bringing up interface enp0s20f0u8u3c2: [ OK ] Dec 04 17:27:52 cpu-02.hello.broadcom.net network[3488]: Bringing up interface enp0s20f0u8u3c2: [ OK ]
これが Gateway の運用に影響を与えることはありません。
以下のネットワーク展開シナリオでは、Gateway バージョン 10.0 のハードウェア アプライアンス フォーム ファクタを使用しています。
Gateway の OVA、Azure、AMI のいずれかのフォーム ファクタを使用している場合、「ssg_eth0」のほかにネットワーク インターフェースを追加すると、そのインターフェースでは OS によって割り当てられた元の一貫したネットワーク インターフェース名が使用されます。
  • 単一ドメインのネットワーク:
    ネットワーク通信はすべて、内部管理 LAN (「ssg_eth0」)内で処理されます。
  • 2 つのドメインのネットワーク:
    以下の 2 つのネットワークが使用されます。
    • パブリック LAN を表すワイド エリア ネットワーク(「ssg_eth1」)
    • 2 つの内部サービス LAN (「ssg_eth2」および「ssg_eth3」)。
  • 3 つおよび 4 つのドメインのネットワーク:
    以下の 3 つ以上のネットワークが使用されます。
    • パブリック LAN のワイド エリア ネットワーク(「ssg_eth1」)
    • プライベート側の内部管理 LAN (「ssg_eth0」)
    • 1 つまたは 2 つの内部サービス LAN (「ssg_eth2」および「ssg_eth3」)。
単一ドメインのネットワーク
単一ネットワーク構成は、メッセージおよびバック エンド トラフィックから管理を分離する必要のないシナリオで使用します。 たとえば、Gateway は概念実証、開発、テスト設定、または ESB の展開で使用されます。 この構成では、すべてのネットワーク通信が内部管理 LAN (ssg_eth0)で発生します。
単一ネットワーク構成は単純で簡単ですが、一般的な実稼働の展開ではありません。
以下の図は、単一ネットワーク構成内のコンポーネントを示しています。
ネットワーク展開: 単一ドメインのネットワーク
Network deploymentsingle domain network
2 つのドメインのネットワーク
2 つのドメインのネットワークは、より複雑な構成で使用されます。ここでは、サービス コンシューマは Gateway クラスタによって保護されたサービスと分離されています。 この構成では、サービスおよびリソースは内部サービス LAN (ssg_eth2、ssg_eth3)
に接続され、「公開側」は WAN (ssg_eth1)に接続されます。
この構成は、公開側のワークステーションによる管理機能へのアクセスが許可されていないと仮定しています。 負荷分散および高可用性のために、パブリック側でロード バランサを使用できます。
以下の図は、2 つのドメインのネットワーク構成内のコンポーネントを示しています。
ネットワーク展開: 2 つのドメインのネットワーク
Network deploymenttwo domain network
3 つおよび 4 つのドメインのネットワーク
高セキュリティ環境では、管理ワークステーションがサービス ネットワークから分離されます。 このマルチネットワーク設定では、「公開側」はロード バランサのある WAN (ssg_eth1)上にあると想定されています。
管理ネットワークは内部管理 LAN (ssg_eth0)上にあります。 サービス ネットワークは内部サービス LAN (ssg_eth2、ssg_eth3)上にあります。 このため、管理ノードからサービス システムへは直接アクセスされず、必ず Gateway クラスタを経由することになります。
以下の図は、4 つのネットワーク インターフェースをすべて使用して、経営資源から Web サービスを分離する方法を示しています。
ネットワーク展開: 3 つおよび 4 つのドメインのネットワーク
Network deployment three and four domain network
CentOS 7 上の既存の Gateway 10.x アプライアンスへの追加のネットワーク インターフェースのインストール
CentOS 7 マシンに Gateway バージョン 10.x を正常にインストールし、インストール時に SSG 設定メニューを使用して必要なネットワーク インターフェースを設定した後、後で 1 つ以上のネットワーク インターフェースの追加が必要になる場合があります。 Gateway 設定で「ssg_eth#」ネーミング スキームを使用して新しいネットワーク インターフェースを検出するには、以下の手順に従います。
  1. Gateway マシンの ディレクトリ
    /etc/sysconfig/network-scripts
    に移動します。
  2. 追加するネットワーク インターフェースに最適な名前でネットワーク設定ファイルを作成します。
    たとえば、「ifcfg-ssg_eth#」(# は追加するネットワーク インターフェースの連番を表します)という名前でファイルを作成できます。 1 つのネットワーク インターフェース(ssg_eth0)がすでにインストールされていて、さらに追加する場合は、ファイル名は「ifcfg-ssg_eth1」となります。 同様に、既存の 3 つのインターフェース セットアップ(ssg_eth0、ssg_eth1、ssg_eth2)にインターフェースを追加する場合、ファイル名は「ifcfg-ssg_eth3」となります。 あるいは、デフォルトの一貫性のある名前を使用して、ディレクトリ内の他の同様のネットワーク設定ファイルの命名パターン(「ifcfg-ens#」など)を繰り返すことができます。
  3. 以下のコマンドを使用して新しい ifcfg ファイルの権限を変更します(「ifcfg-ssg_eth1」は選択した ifcfg ファイル名で置き換えます)。
    chmod 644 ifcfg-ssg_eth1
  4. 以下のコマンドを使用して ifcfg ファイルの UUID を生成します(「ifcfg-ssg_eth1」は選択した ifcfg ファイル名で置き換えます)。
    uuidgen ifcfg-ssg_eth1
  5. 以下の手順では、既存の 1 インターフェース セットアップにインターフェースを追加することを前提にしています。 必要に応じて変更します。インターフェースの NAME 値と DEVICE 値は同じにし、Gateway の「ssg_eth#」命名規則に従う必要があります。
    ファイルに以下の行を追加します。
    HWADDR= [Enter your the hardware address of your new network interface] TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=ssg_eth1 [Replace with appropriate ssg_eth# name] UUID= [Enter the UUID for your new network interface. See Step 4.] DEVICE=ssg_eth1 [Replace with appropriate ssg_eth# name] ONBOOT=yes AUTOCONNECT_PRIORITY=999
  6. アプライアンスを再起動し、SSG 設定メニューにもう一度移動して、新しいネットワーク インターフェースを設定します。 API Gateway によって、名前が「ssg_eth#」の新しいインターフェースが検出されるようになりました。