インストール要件

Edge for Private Cloud v4.18.01

ハードウェア要件

本番環境で高可用性インフラストラクチャを構築するには、次のハードウェアの最小要件を満たす必要があります。インストール トポロジで説明されているすべてのインストール シナリオについて、次の表にインストール コンポーネントの最小ハードウェア要件を示します。

これらの表のハードディスク要件は、オペレーティング システムに必要なハードディスク容量に加えて必要となるものです。アプリケーションとネットワーク トラフィックによっては、インストールに必要なリソースが以下のリストよりも多くなることも少なくなることもあります。

インストール コンポーネント RAM CPU 最小ハードディスク
Cassandra 16 GB 8 コア 250 GB のローカル ストレージ（SSD または高速 HDD、2,000 IOPS をサポート）
同じマシン上の Message Processor/Router 16 GB 8 コア 100 GB
分析 - 同じサーバー上の Postgres/Qpid（本番環境では推奨されません） 16GB* 8 コア* 500 GB ～ 1 TB の**ネットワーク ストレージ***（SSD バックエンドが望ましい）、1,000 IOPS 以上をサポート*
Analytics - Postgres（スタンドアロン） 16GB* 8 コア* 500 GB ～ 1 TB の**ネットワーク ストレージ***（SSD バックエンドが望ましい）、1,000 IOPS 以上をサポート*
Analytics - Qpid（スタンドアロン） 8 GB 4 コア 30 GB ～ 50 GB のローカル ストレージ（SSD または高速 HDD）

250 TPS を超えるインストールの場合、1, 000 IOPS をサポートするローカル ストレージを備えた HDD をおすすめします。

Qpid キューのデフォルトのサイズは 20 GB です。容量を追加する必要がある場合は、Qpid ノードを追加します。
その他（OpenLDAP、UI、Management Server） 4 GB 2 コア 60 GB

* スループットに基づいて Postgres のシステム要件を調整します。

  • 250 TPS 未満: 1, 000 IOPS 以上をサポートするマネージド ネットワーク ストレージ***で 8 GB、4 コアを検討できます。
  • 250 TPS より大きい場合: 16 GB、8 コア、1,000 IOPS 以上をサポートするマネージド ネットワーク ストレージ***
  • 1, 000 TPS より大きい場合: 16 GB、8 コア、2, 000 IOPS 以上をサポートするマネージド ネットワーク ストレージ***
  • 2, 000 TPS より大きい場合: 32 GB、16 コア、2, 000 IOPS 以上をサポートするマネージド ネットワーク ストレージ***
  • 4, 000 TPS を超える場合: 64 GB、32 コア、4, 000 IOPS 以上をサポートするマネージド ネットワーク ストレージ***

** Postgres のハードディスクの値は、Edge によってキャプチャされたデフォルトの分析に基づいています。分析データにカスタム値を追加する場合は、これらの値を適宜増やす必要があります。必要なストレージを推定するには、次の計算式を使用します。

bytes of storage needed =

  (# bytes of analytics data/request) *

  (requests/second) *

  (seconds/hour) *

  (hours of peak usage/day) *

  (days/month) *

  (months of data retention)

次に例を示します。

(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.4 GB

*** Postgresql データベースにはネットワーク ストレージが推奨されます。理由は次のとおりです。

  • 必要に応じてストレージ サイズを動的にスケールアップできます。
  • ネットワーク IOPS は、今日のほとんどの環境/ストレージ/ネットワーク サブシステムでオンザフライで調整できます。
  • ストレージ レベルのスナップショットは、バックアップと復元のソリューションの一部として有効にできます。

また、収益化サービスをインストールする場合は、次のハードウェア要件を満たす必要があります。

収益化コンポーネント RAM CPU ハードディスク
Management Server（Monetization Services を含む） 8 GB 4 コア 60 GB
Analytics - Postgres/Qpid（同一サーバー上） 16 GB 8 コア 500 GB ～ 1 TB のネットワーク ストレージ（SSD バックエンドが望ましい）。1,000 IOPS 以上をサポートするか、上記の表のルールを使用します。
Analytics - Postgres（スタンドアロン） 16 GB 8 コア 500 GB ～ 1 TB のネットワーク ストレージ（SSD バックエンドが望ましい）。1,000 IOPS 以上をサポートするか、上記の表のルールを使用します。
Analytics - Qpid（スタンドアロン） 8 GB 4 コア 40 GB ～ 500 GB のローカル ストレージ（SSD または高速 HDD）

250 TPS を超えるインストールの場合、1, 000 IOPS をサポートするローカル ストレージを備えた HDD をおすすめします。

API BaaS をインストールする場合のハードウェア要件は次のとおりです。

API BaaS コンポーネント RAM CPU ハードディスク
ElasticSearch* 8 GB 4 コア 60 ～ 80 GB
API BaaS Stack* 8 GB 4 コア 60 ～ 80 GB
API BaaS Portal 1 GB 2 コア 20 GB
Cassandra** 16 GB 8 コア 250 GB のローカル ストレージ（SSD または高速 HDD、2,000 IOPS をサポート）

* ElasticSearch と API BaaS Stack は同じノードにインストールできます。その場合は、4 GB のメモリ（デフォルト）を使用するように ElasticSearch を構成します。ElasticSearch が独自のノードにインストールされている場合は、6 GB のメモリを使用するように構成します。

** 省略可。通常、Edge サービスと API BaaS サービスの両方に同じ Cassandra クラスタを使用します。

オペレーティング システムとサードパーティ ソフトウェアの要件

このインストール手順と付属のインストール ファイルは、サポートされているソフトウェアとサポートされているバージョンに記載されているオペレーティング システムとサードパーティ ソフトウェアでテストされています。

apigee ユーザーの作成

インストール手順では、「apigee」という名前の Unix システム ユーザーが作成されます。Edge ディレクトリとファイルは、Edge プロセスと同様に「apigee」が所有しています。つまり、Edge コンポーネントは「apigee」ユーザーとして実行されます。必要に応じて、別のユーザーとしてコンポーネントを実行できます。

インストール ディレクトリ

デフォルトでは、インストーラはすべてのファイルを /opt/apigee ディレクトリに書き込みます。このディレクトリの場所は変更できません。このディレクトリは変更できませんが、以下で説明するように、/opt/apigee を別の場所にマッピングするシンボリック リンクを作成できます。

このガイドの手順では、インストール ディレクトリを /opt/apigee と表記しています。

/opt/apigee のシンボリック リンクの作成

シンボリック リンクを作成する前に、まず「apigee」という名前のユーザーとグループを作成する必要があります。これは、Edge インストーラによって作成されたグループとユーザーと同じです。

シンボリック リンクを作成するには、bootstrap_4.18.01.sh ファイルをダウンロードする前に次の操作を行います。これらの手順はすべて root として実行する必要があります。

  1. 「apigee」ユーザーとグループを作成します。
    groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
  2. /opt/apigee から目的のインストール ルートへのシンボリック リンクを作成します。
    ln -Ts /srv/myInstallDir /opt/apigee

    ここで、/srv/myInstallDir は Edge ファイルの目的の場所です。

  3. インストール ルートとシンボリック リンクの所有権を「apigee」ユーザーに変更します。
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

インストールする前に、各マシンにサポートされているバージョンの Java 1.8 をインストールする必要があります。サポートされている JDK は、サポートされているソフトウェアとサポートされているバージョンに記載されています。

JAVA_HOME が、インストールを実行するユーザーの JDK のルートを指していることを確認します。

SELinux

SELinux の設定によっては、Edge コンポーネントのインストールと起動で問題が発生する可能性があります。必要に応じて、インストール中に SELinux を無効にするか、permissive モードに設定し、インストール後に再度有効にすることができます。詳細については、Edge apigee-setup ユーティリティのインストールをご覧ください。

ネットワーク設定

インストール前にネットワーク設定を確認することをおすすめします。インストーラは、すべてのマシンに固定 IP アドレスが設定されていることを想定しています。次のコマンドを使用して、設定を検証します。

  • hostname はマシンの名前を返します
  • hostname -i は、他のマシンからアドレス指定できるホスト名の IP アドレスを返します。

オペレーティング システムの種類とバージョンによっては、ホスト名が正しく設定されていない場合に /etc/hosts と /etc/sysconfig/network の編集が必要になることがあります。詳細については、ご使用のオペレーティング システムのドキュメントをご覧ください。

サーバーに複数のインターフェース カードがある場合、「hostname -i」コマンドは IP アドレスのスペース区切りのリストを返します。デフォルトでは、Edge インストーラは返された最初の IP アドレスを使用しますが、これはすべての状況で正しいとは限りません。別の方法として、インストール構成ファイルで次のプロパティを設定することもできます。

ENABLE_DYNAMIC_HOSTIP=y

このプロパティを「y」に設定すると、インストーラによって、インストールの一部として使用する IP アドレスを選択するよう求められます。デフォルト値は「n」です。詳細については、Edge 構成ファイル リファレンスをご覧ください。

TCP ラッパー

TCP Wrappers は一部のポートの通信をブロックし、OpenLDAP、Postgres、Cassandra のインストールに影響する可能性があります。これらのノードで /etc/hosts.allow と /etc/hosts.deny を確認し、必要な OpenLDAP、Postgres、Cassandra のポートにポート制限がないことを確認します。

iptables

必要な Edge ポートでノード間の接続を妨げる iptables ポリシーがないことを確認します。必要に応じて、次のコマンドを使用してインストール中に iptables を停止できます。

sudo/etc/init.d/iptables stop

CentOS 7.x の場合:

systemctl stop firewalld

Edge Router が /etc/rc.d/init.d/functions にアクセスできることを確認します。

Edge Router ノードと BaaS Portal ノードは Nginx ルーターを使用しており、/etc/rc.d/init.d/functions への読み取りアクセス権が必要です。

自社のセキュリティ プロセスで /etc/rc.d/init.d/functions に対する権限の設定が義務付けられている場合、700 には設定しないでください。そうすると、ルーターは起動できません。権限を 744 に設定すると、/etc/rc.d/init.d/functions への読み取りアクセスが許可されます。

Cassandra

すべての Cassandra ノードがリングに接続されている必要があります。Cassandra は、信頼性とフォールト トレランスを確保するために、複数のノードにデータ レプリカを保存します。各 Edge キースペースのレプリケーション戦略によって、レプリカが配置される Cassandra ノードが決まります。詳細については、Cassandra のレプリケーション係数と整合性レベルについてをご覧ください。

Cassandra は、使用可能なメモリに基づいて Java ヒープサイズを自動的に調整します。詳細については、Java リソースのチューニングをご覧ください。パフォーマンスの低下やメモリ使用量の増加が発生した場合。

Edge for Private Cloud をインストールした後、/opt/apigee/apigee-cassandra/conf/cassandra.yaml ファイルを調べて、Cassandra が正しく構成されていることを確認できます。たとえば、Edge for Private Cloud のインストール スクリプトで次のプロパティが設定されていることを確認します。

  • cluster_name
  • initial_token
  • partitioner
  • seeds
  • listen_address
  • rpc_address
  • snitch

PostgreSQL データベース

Edge をインストールしたら、システムで使用可能な RAM の量に基づいて、次の PostgreSQL データベース設定を調整できます。

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

これらの値を設定するには:

  1. postgresql.properties ファイルを編集します。
    vi /opt/apigee/customer/application/postgresql.properties

    ファイルが存在しない場合は作成します。

  2. 上記のプロパティを設定します。
  3. 編集内容を保存します。
  4. PostgreSQL データベースを再起動します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

システム制限

Cassandra ノードと Message Processor ノードに次のシステム上限が設定されていることを確認します。

  • Cassandra ノードでは、/etc/security/limits.d/90-apigee-edge-limits.conf でインストール ユーザー（デフォルトは「apigee」）に対して soft および hard の memlock、nofile、アドレス空間（as）の制限を設定します。次に例を示します。
    apigee soft memlock unlimited
apigee hard memlock unlimited
apigee soft nofile 32768
apigee hard nofile 65536
apigee soft as unlimited
apigee hard as unlimited
  • Message Processor ノードでは、/etc/security/limits.d/90-apigee-edge-limits.conf でオープン ファイル記述子の最大数を 64, 000 に設定します。次に例を示します。
    apigee soft nofile 32768
apigee hard nofile 65536

    必要に応じて、この上限を引き上げることができます。たとえば、一度に多数の一時ファイルを開いている場合などです。

jsvc

API BaaS を使用するには、「jsvc」が前提条件となります。API BaaS をインストールすると、バージョン 1.0.15-dev がインストールされます。

Network Security Services（NSS）

Network Security Services（NSS）は、セキュリティ対応のクライアント アプリケーションとサーバー アプリケーションの開発をサポートするライブラリのセットです。NSS v3.19 以降がインストールされていることを確認してください。

現在のバージョンを確認するには:

yum info nss

NSS を更新するには:

yum update nss

詳しくは、RedHat のこちらの記事をご覧ください。

NSCD（ネームサービス キャッシュ デーモン）を使用する場合の IPv6 の DNS ルックアップを無効にする

NSCD（ネームサービス キャッシュ デーモン）をインストールして有効にしている場合、メッセージ プロセッサは 2 つの DNS ルックアップ（IPv4 用と IPv6 用）を行います。NSCD を使用する場合は、IPv6 の DNS ルックアップを無効にする必要があります。

IPv6 の DNS ルックアップを無効にするには:

  1. すべての Message Processor ノードで、/etc/nscd.conf を編集します。
  2. 次のプロパティを設定します。
    enable-cache hosts no

Google Cloud Platform 上の RedHat/CentOS 7 で IPv6 を無効にする

Google Cloud Platform 上の RedHat 7 または CentOS 7 に Edge をインストールする場合は、すべての Qpid ノードで IPv6 を無効にする必要があります。

IPv6 を無効にする手順については、特定の OS バージョンの RedHat または CentOS のドキュメントをご覧ください。たとえば、次のようなことができます。

  1. エディタで /etc/hosts を開きます。
  2. 次の行の 1 列目に「#」文字を挿入して、コメントアウトします。
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. ファイルを保存します。

AWS AMI

Red Hat Enterprise Linux 7.x の AWS Amazon マシンイメージ（AMI）に Edge をインストールする場合は、最初に次のコマンドを実行する必要があります。

yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

ツール

インストーラは、EL5 または EL6 で提供される標準バージョンの次の UNIX ツールを使用します。

awk

expr

libxslt

rpm

unzip

basename

grep

lua-socket

rpm2cpio

useradd

bash

 hostname

ls

sed

wc

bc

id

net-tools

sudo

wget

curl

libaio

perl（procps から）

tar

xerces-c
cyrus-sasl libdb4 pgrep（procps から） tr おいしい

date

 libdb-cxx

ps

uuid

chkconfig
ディレクトリ名 libibverbs pwd uname  
エコー librdmacm python    

ntpdate

サーバーの時刻を同期させることをおすすめします。まだ構成されていない場合は、ntpdate ユーティリティを使用して、サーバーの時刻が同期されているかどうかを確認できます。yum install ntp を使用してユーティリティをインストールできます。これは、OpenLDAP の設定を複製する場合に特に便利です。サーバーのタイムゾーンは UTC で設定します。

openldap 2.4

オンプレミス インストールには OpenLDAP 2.4 が必要です。サーバーがインターネットに接続されている場合、Edge インストール スクリプトは OpenLDAP をダウンロードしてインストールします。サーバーがインターネットに接続されていない場合は、Edge インストール スクリプトを実行する前に OpenLDAP がインストールされていることを確認する必要があります。RHEL/CentOS では、yum install openldap-clients openldap-servers を実行して OpenLDAP をインストールできます。

13 ホストのインストールと、2 つのデータセンターがある 12 ホストのインストールでは、OpenLDAP をホストするノードが複数あるため、OpenLDAP レプリケーションが必要です。

ファイアウォールと仮想ホスト

virtual という用語は IT 分野でよくオーバーロードされます。Apigee Edge for Private Cloud のデプロイと仮想ホストも同様です。明確にするために、virtual という用語には主に次の 2 つの用途があります。

  • 仮想マシン（VM）: 必須ではありませんが、一部のデプロイでは VM テクノロジーを使用して Apigee コンポーネント用の分離されたサーバーを作成します。VM ホストには、物理ホストと同様に、ネットワーク インターフェースとファイアウォールを設定できます。
  • 仮想ホスト: Apache 仮想ホストに類似したウェブ エンドポイント。

VM 内のルーターは、複数の仮想ホストを公開できます（ホスト エイリアスまたはインターフェース ポートが互いに異なる場合）。

名前付けの例として、1 台の物理サーバー A で「VM1」と「VM2」という 2 つの VM が実行されている場合があります。「VM1」が仮想イーサネット インターフェースを公開し、VM 内で「eth0」という名前が付けられ、仮想化機構またはネットワーク DHCP サーバーによって IP アドレス 111.111.111.111 が割り当てられているとします。また、VM2 が「eth0」という名前の仮想イーサネット インターフェースを公開し、IP アドレス 111.111.111.222 が割り当てられているとします。

2 つの VM のそれぞれで Apigee ルーターが実行されている可能性があります。ルーターは、次の架空の例のように、仮想ホスト エンドポイントを公開します。

VM1 の Apigee ルーターは、eth0 インターフェース（特定の IP アドレスを持つ）で 3 つの仮想ホスト（api.mycompany.com:80、api.mycompany.com:443、test.mycompany.com:80）を公開します。

VM2 のルーターは api.mycompany.com:80 を公開します（VM1 が公開する名前とポートと同じ）。

物理ホストのオペレーティング システムにネットワーク ファイアウォールがある場合は、仮想化インターフェース（111.111.111.111:{80, 443} と 111.111.111.222:80）で公開されているポート宛ての TCP トラフィックを通過するようにファイアウォールを構成する必要があります。また、各 VM のオペレーティング システムが eth0 インターフェースに独自のファイアウォールを提供している場合もあります。この場合も、ポート 80 と 443 のトラフィックが接続できるようにする必要があります。

ベースパスは、デプロイした可能性のあるさまざまな API プロキシに API 呼び出しをルーティングする際に使用される 3 番目のコンポーネントです。API プロキシ バンドルは、ベースパスが異なる場合、エンドポイントを共有できます。たとえば、1 つのベースパスを http://api.mycompany.com:80/ として定義し、別のベースパスを http://api.mycompany.com:80/salesdemo として定義できます。

この場合、http://api.mycompany.com:80/ トラフィックを 2 つの IP アドレス（VM1 の 111.111.111.111 と VM2 の 111.111.111.222）間で分割するロードバランサまたはトラフィック ディレクタが必要です。この関数は特定のインストールに固有のもので、ローカル ネットワーキング グループによって構成されます。

ベースパスは、API のデプロイ時に設定されます。上記の例では、ホスト エイリアスが api.mycompany.com でポートが 80 に設定されている仮想ホストを使用して、組織 mycompany-org に 2 つの API（mycompany と testmycompany）をデプロイできます。デプロイでベースパスを宣言しない場合、ルーターは受信リクエストをどの API に送信すべきかわかりません。

ただし、ベース URL が /salesdemo の API testmycompany をデプロイすると、ユーザーは http://api.mycompany.com:80/salesdemo を使用してその API にアクセスします。ベース URL が / の API mycompany をデプロイすると、ユーザーは URL http://api.mycompany.com:80/ で API にアクセスします。

Edge ポートの要件

ファイアウォールの管理は仮想ホストだけではありません。VM と物理ホストの両方のファイアウォールで、コンポーネントが相互に通信するために必要なポートのトラフィックを許可する必要があります。

次の図は、各 Edge コンポーネントのポート要件を示しています。

この図に関する注意事項:

  • * Router と Message Processor 間の TLS/SSL を構成する場合は、Message Processor のポート 8082 は Router からアクセスできるように開いておく必要があります。Router と Message Processor 間の TLS/SSL を構成しない場合、コンポーネントを管理するために Message Processor でデフォルト構成のポート 8082 を開く必要がありますが、Router はこのポートにアクセスする必要はありません。
  • 「M」で始まるポートは、コンポーネントの管理に使用されるポートです。コンポーネントで開いて、Management Server からアクセスできるようにする必要があります。
  • 次のコンポーネントは、Management Server のポート 8080 にアクセスする必要があります。Router、Message Processor、UI、Postgres、Qpid。
  • メッセージ プロセッサは、管理ポートとしてポート 4528 を開く必要があります。複数の Message Processor がある場合は、それらすべてがポート 4528 を介して相互にアクセスできる必要があります（上の図の Message Processor のポート 4528 のループ矢印で示されています）。複数のデータセンターがある場合は、すべてのデータセンターのすべての Message Processor からポートにアクセスできる必要があります。
  • 必須ではありませんが、任意の Message Processor からアクセスできるように、Router でポート 4527 を開くことができます。そうしないと、Message Processor のログファイルにエラー メッセージが表示されることがあります。
  • ルーターは、管理ポートとしてポート 4527 を開く必要があります。複数のルーターがある場合は、すべてのルーターがポート 4527 経由で相互にアクセスできる必要があります（上の図のルーターのポート 4527 のループ矢印で示されています）。
  • Edge UI では、トレースツールの [送信] ボタンをサポートするために、API プロキシによって公開されたポートで Router へのアクセスが必要です。
  • 管理サーバーには、Cassandra ノードの JMX ポートへのアクセスが必要です。
  • JMX ポートへのアクセスは、ユーザー名とパスワードを要求するように構成できます。詳細については、モニタリング方法をご覧ください。
  • 必要に応じて、特定の接続に対して TLS/SSL アクセスを構成できます。この接続では、異なるポートを使用できます。詳しくは、TLS/SSL をご覧ください。
  • マスター スタンバイ レプリケーションを使用するように 2 つの Postgres ノードを構成する場合は、ssh アクセス用に各ノードでポート 22 を開く必要があります。必要に応じて、個々のノードでポートを開いて SSH アクセスを許可できます。
  • 外部 SMTP サーバー経由でメールを送信するように、管理サーバーと Edge UI を構成できます。その場合は、管理サーバーと UI が SMTP サーバーの必要なポートにアクセスできることを確認する必要があります。TLS 以外の SMTP の場合、ポート番号は通常 25 です。TLS 対応の SMTP の場合、通常は 465 ですが、SMTP プロバイダに確認してください。

次の表に、Edge コンポーネントごとにファイアウォールで開く必要のあるポートを示します。

コンポーネント ポート 説明
標準の HTTP ポート 80、443 HTTP と仮想ホストに使用するほかのポート
管理サーバー 8080 Edge Management API 呼び出しのポート。これらのコンポーネント（Router、Message Processor、UI、Postgres、Qpid）は、Management Server のポート 8080 へのアクセスを必要とします。
1099 JMX ポート
4526 分散キャッシュと管理呼び出しの場合
管理 UI 9000 管理 UI へのブラウザ アクセス用のポート
Message Processor 8998 Router からの通信用の Message Processor ポート
8082

Message Processor のデフォルトの管理ポート。Management Server がアクセスできるように、コンポーネントで開いている必要があります。

Router と Message Processor の間で TLS/SSL を構成する場合。Router はこれを使用して Message Processor のヘルスチェックを行います。
1101 JMX ポート
4528 Message Processor 間の分散キャッシュと管理呼び出し、および Router と Management Server からの通信の場合
ルーター 8081 ルーターのデフォルトの管理ポート。Management Server からアクセスできるように、コンポーネントで開いている必要があります。
4527 分散キャッシュと管理呼び出しの場合
15999

ヘルスチェック ポート。ロードバランサは、このポートを使用して、ルーターが使用可能かどうかを判断します。

ルーターのステータスを取得するために、ロードバランサはルーターのポート 15999 にリクエストを送信します。

curl -v http://routerIP:15999/v1/servers/self/reachable

Router に到達できる場合、リクエストは HTTP 200 を返します。
59001 apigee-validate ユーティリティによる Edge インストールのテストに使用されるポート。このユーティリティを使用するには、ルーターのポート 59001 へのアクセスが必要です。ポート 59001 の詳細については、インストールをテストするをご覧ください。
ZooKeeper 2181 Management Server、Router、Message Processor などの他のコンポーネントで使用されます。
2888、3888 ZooKeeper クラスタ（ZooKeeper アンサンブルとも呼ばれます）の通信に ZooKeeper によって内部的に使用されます。
Cassandra 7000、9042、9160 Cassandra ノード間の通信と、他の Edge コンポーネントによるアクセスに使用される Apache Cassandra ポート。
7199 JMX ポート。管理サーバーがアクセスできるように開いている必要があります。
Qpid 5672 Router と Message Processor から Qpid サーバーへの通信に使用されます
8083 Qpid サーバーのデフォルトの管理ポート。Management Server がアクセスできるように、コンポーネントで開いている必要があります。
1102 JMX ポート
4529 分散キャッシュと管理呼び出しの場合
Postgres 5432 Qpid/管理サーバーから Postgres への通信に使用されます
8084 Postgres サーバーのデフォルトの管理ポート。Management Server がアクセスできるように、コンポーネントで開いている必要があります。
1103 JMX ポート
4530 分散キャッシュと管理呼び出しの場合
22 マスター スタンバイ レプリケーションを使用するように 2 つの Postgres ノードを構成する場合は、ssh アクセス用に各ノードでポート 22 を開く必要があります。
LDAP 10389 OpenLDAP
SmartDocs 59002 SmartDocs ページ リクエストが送信される Edge ルーターのポート。

次の表は、同じポートを数値順に示し、送信元コンポーネントと宛先コンポーネントを示しています。

ポート番号 目的 ソース コンポーネント 宛先コンポーネント
virtual_host_port HTTP と仮想ホスト API 呼び出しトラフィックに使用するほかのポート。ポート 80 と 443 が最も一般的に使用されます。Message Router は TLS/SSL 接続を終了できます。 外部クライアント（またはロードバランサ） メッセージ ルーターのリスナー
1099 ～ 1103 JMX 管理 JMX クライアント 管理サーバー（1099）
メッセージ プロセッサ（1101）
Qpid サーバー（1102）
Postgres サーバー（1103）
2181 Zookeeper クライアント通信 Management Server
Router
Message Processor
Qpid Server
Postgres Server 		Zookeeper
2888 と 3888 Zookeeper ノード間の管理 Zookeeper Zookeeper
4526 RPC 管理ポート 管理サーバー 管理サーバー
4527 分散キャッシュと管理呼び出し、ルーター間の通信用の RPC 管理ポート 管理サーバー
ルーター		 ルーター
4528 Message Processor 間の分散キャッシュ呼び出しと、Router からの通信の場合 Management Server
Router
Message Processor 		Message Processor
4529 分散キャッシュと管理呼び出し用の RPC 管理ポート 管理サーバー Qpid サーバー
4530 分散キャッシュと管理呼び出し用の RPC 管理ポート 管理サーバー Postgres サーバー
5432 Postgres クライアント Qpid サーバー Postgres
5672

Router と Message Processor から Qpid に分析情報を送信するために使用されます

 Router
Message Processor 		Qpid サーバー
7,000 Cassandra ノード間の通信 Cassandra 他の Cassandra ノード
7199 JMX 管理。管理サーバーが Cassandra ノードにアクセスできるように開いている必要があります。 JMX クライアント Cassandra
8080 Management API ポート Management API クライアント 管理サーバー
8081 ～ 8084

コンポーネント API ポート。個々のコンポーネントに API リクエストを直接発行するために使用されます。各コンポーネントは異なるポートを開きます。使用されるポートは構成によって異なりますが、Management Server がアクセスできるようにコンポーネントで開いている必要があります。

 Management API クライアント ルーター（8081）
メッセージ プロセッサ（8082）
Qpid サーバー（8083）
Postgres サーバー（8084）
8998 Router と Message Processor 間の通信 ルーター Message Processor
9000 デフォルトの Edge 管理 UI ポート ブラウザ 管理 UI サーバー
9042 CQL ネイティブ トランスポート Router
Message Processor
Management Server 		Cassandra
9160 Cassandra thrift クライアント Router
Message Processor
Management Server 		Cassandra
10389 LDAP ポート 管理サーバー OpenLDAP
15999 ヘルスチェック ポート。ロードバランサは、このポートを使用して、ルーターが使用可能かどうかを判断します。 ロードバランサ ルーター
59001 apigee-validate ユーティリティが Edge のインストールをテストするために使用するポート apigee-validate ルーター
59002 SmartDocs ページ リクエストが送信されるルーターポート SmartDocs ルーター

メッセージ プロセッサは、タイムアウトしないように構成された Cassandra への専用の接続プールを開いたままにします。メッセージ プロセッサと Cassandra サーバーの間にファイアウォールがある場合、ファイアウォールで接続がタイムアウトになることがあります。ただし、メッセージ プロセッサは Cassandra への接続を再確立するように設計されていません。

この状況を防ぐため、Apigee では、Cassandra サーバー、Message Processor、Router を同じサブネットに配置して、これらのコンポーネントのデプロイにファイアウォールが関与しないようにすることをおすすめします。

ルーターと Message Processor の間にファイアウォールがあり、アイドル状態の TCP タイムアウトが設定されている場合は、次のことをおすすめします。

  1. Linux OS の sysctl 設定で net.ipv4.tcp_keepalive_time = 1800 を設定します。ここで、1800 はファイアウォールのアイドル状態の TCP タイムアウトよりも小さくする必要があります。この設定により、接続が確立された状態に維持され、ファイアウォールが接続を切断しないようにします。
  2. すべてのメッセージ プロセッサで、/opt/apigee/customer/application/message-processor.properties を編集して次のプロパティを追加します。ファイルが存在しない場合は作成します。
    conf_system_cassandra.maxconnecttimeinmillis=-1
  3. Message Processor を再起動します。
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. すべてのルーターで、/opt/apigee/customer/application/router.properties を編集して次のプロパティを追加します。ファイルが存在しない場合は作成します。
    conf_system_cassandra.maxconnecttimeinmillis=-1
  5. ルーターを再起動します。 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart

2 つのデータセンターで 12 ホスト クラスタ構成をインストールする場合は、2 つのデータセンターのノードが次のポートで通信できることを確認してください。

API BaaS のポート要件

API BaaS をインストールする場合は、API BaaS Stack コンポーネントと API BaaS Portal コンポーネントを追加します。これらのコンポーネントは、次の図に示すポートを使用します。

この図に関する注意事項:

  • API BaaS Portal は、BaaS Stack ノードに直接リクエストを送信することはありません。デベロッパーがポータルにログインすると、ポータルアプリがブラウザにダウンロードされます。ブラウザで実行されている Portal アプリが BaaS Stack ノードにリクエストを送信します。
  • API BaaS の本番環境インストールでは、API BaaS Portal ノードと API BaaS Stack ノードの間にロードバランサを使用します。ポータルを構成するとき、および BaaS API 呼び出しを行うときは、Stack ノードではなく、ロードバランサの IP アドレスまたは DNS 名を指定します。
  • すべての Stack ノードは、他のすべての Stack ノードからのアクセス用にポート 2551 を開く必要があります（上の図の Stack ノードのポート 2551 のループ矢印で示されています）。複数のデータセンターがある場合は、すべてのデータセンターのすべての Stack ノードからポートにアクセスできる必要があります。
  • 外部 SMTP サーバー経由でメールを送信するように、すべての Baas Stack ノードを構成する必要があります。TLS 以外の SMTP の場合、通常はポート番号 25 が使用されます。TLS 対応の SMTP の場合、通常は 465 ですが、SMTP プロバイダに確認してください。
  • Cassandra ノードは API BaaS 専用にすることも、Edge と共有することもできます。

次の表に、コンポーネントごとにファイアウォールで開く必要があるデフォルトのポートを示します。

コンポーネント ポート 説明
API BaaS Portal 9000 API BaaS UI のポート
API BaaS スタック 8080 API リクエストを受信するポート
2551

すべての Stack ノード間の通信に使用するポート。データセンター内の他のすべての Stack ノードからアクセスできる必要があります。

複数のデータセンターがある場合、ポートはすべてのデータセンターのすべての Stack ノードからアクセスできる必要があります。
ElasticSearch 9,200 ～ 9,400 API BaaS Stack との通信、ElasticSearch ノード間の通信

ライセンス

Edge のインストールごとに、Apigee から取得した一意のライセンス ファイルが必要です。管理サーバーのインストール時に、ライセンス ファイルのパス（/tmp/license.txt など）を指定する必要があります。

インストーラは、ライセンス ファイルを /opt/apigee/customer/conf/license.txt にコピーします。

ライセンス ファイルが有効な場合、管理サーバーは有効期限と許可された Message Processor（MP）の数を検証します。いずれかのライセンス設定が期限切れの場合は、/opt/apigee/var/log/edge-management-server/logs にあるログでそれを調べることができます。その場合は、Apigee Edge サポートに移行の詳細をお問い合わせください。

ライセンスをお持ちでない場合は、Apigee セールスにお問い合わせください。