Edge for Private Cloud v4.18.01
ハードウェア要件
本番環境レベルの高可用性インフラストラクチャには、次の最小ハードウェア要件を満たす必要があります。インストール トポロジで説明されているすべてのインストール シナリオについて、インストール コンポーネントの最小ハードウェア要件を次の表に示します。
この表のハードディスク要件は、オペレーティング システムが必要とするハードディスク容量に加えてください。アプリケーションやネットワーク トラフィックによっては、インストールに必要なリソースが以下に示されている場合があります。
インストール コンポーネント | RAM | CPU | 最小ハードディスク |
---|---|---|---|
Cassandra | 16 GB | 8 コア | 250 GB のローカル ストレージ(2,000 IOPS をサポートする SSD または高速 HDD) |
同じマシン上の Message Processor/Router | 16 GB | 8 コア | 100 GB |
分析 - 同じサーバー上の Postgres/Qpid(本番環境には推奨されません) | 16GB* | 8 コア* | 500 GB ~ 1 TB**のネットワーク ストレージ***(1,000 IOPS 以上をサポートする SSD バックエンドが望ましい)* |
Analytics - Postgres スタンドアロン | 16GB* | 8 コア* | 500 GB ~ 1 TB**のネットワーク ストレージ***(1,000 IOPS 以上をサポートする SSD バックエンドが望ましい)* |
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 は、現在の環境/ストレージ/ネットワーク サブシステムのほとんどで、その場で調整できます。
- ストレージ レベルのスナップショットは、バックアップと復元のソリューションの一部として有効にできます。
さらに、Monetization Services をインストールする場合のハードウェア要件は次のとおりです。
収益化のコンポーネント | RAM | CPU | ハードディスク |
---|---|---|---|
Management Server(Monetization Services を使用) | 8 GB | 4 コア | 60 GB |
分析 - 同じサーバー上の Postgres/Qpid | 16 GB | 8 コア | 500 GB ~ 1 TB のネットワーク ストレージ(1,000 IOPS 以上をサポートする SSD バックエンドが推奨されます)か、上記の表のルールを使用します。 |
Analytics - Postgres スタンドアロン | 16 GB | 8 コア | 500 GB ~ 1 TB のネットワーク ストレージ(1,000 IOPS 以上をサポートする SSD バックエンドが推奨されます)か、上記の表のルールを使用します。 |
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 スタック* | 8 GB | 4 コア | 60 ~ 80 GB |
API BaaS ポータル | 1 GB | 2 コア | 20 GB |
Cassandra** | 16 GB | 8 コア | 250 GB のローカル ストレージ(2,000 IOPS をサポートする SSD または高速 HDD) |
* 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 ユーザーとして行う必要があります。
- 「apigee」ユーザーとグループを作成します。
groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
/opt/apigee
から目的のインストール ルートへのシンボリック リンクを作成します。ln -Ts /srv/myInstallDir /opt/apigee
ここで、/srv/myInstallDir は Edge ファイルの目的の場所です。
- インストール ルートとシンボリック リンクの所有権を「apigee」ユーザーに変更します。
chown -h apigee:apigee /srv/myInstallDir /opt/apigee
Java
インストールする前に、各マシンにサポートされているバージョンの Java 1.8 をインストールしておく必要があります。サポートされる JDK のリストについては、サポート対象ソフトウェアとサポート対象バージョンをご覧ください。
インストールを実行するユーザーの JDK のルートを JAVA_HOME
が指していることを確認します。
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 ラッパーは、一部のポートの通信をブロックする可能性があり、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 ポータルのノードは 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
これらの値を設定するには:
- postgresql.properties ファイルを編集します。
vi /opt/apigee/customer/application/postgresql.properties
ファイルが存在しない場合は作成します。
- 上記のプロパティを設定します。
- 編集内容を保存します。
- 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
「jsvc」は、API BaaS を使用するための前提条件です。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(ネームサービス キャッシュ デーモン)をインストールして有効にしている場合、Message Processor は IPv4 と IPv6 の 2 つの DNS ルックアップを行います。NSCD を使用する場合は、IPv6 の DNS ルックアップを無効にする必要があります。
IPv6 の DNS ルックアップを無効にするには:
- すべての Message Processor ノードで、
/etc/nscd.conf
を編集します。 - プロパティ
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 のドキュメントをご覧ください。たとえば、次のことができます。
- エディタで
/etc/hosts
を開きます。 - 次の行の 1 列に「#」文字を挿入し、コメントアウトします。
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
- ファイルを保存します。
AWS AMI
Red Hat Enterprise Linux 7.x の AWS Amazon Machine Image(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 |
dirname | libibverbs | pwd | uname | |
echo | 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 Router を実行しているとします。ルーターは、次の架空の例のように仮想ホストのエンドポイントを公開します。
VM1 の Apigee ルーターは、eth0 インターフェース(特定の IP アドレスを持つ)で api.mycompany.com:80
、api.mycompany.com:443
、test.mycompany.com:80
の 3 つの仮想ホストを公開します。
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/
として定義し、もう 1 つのベースパスを http://api.mycompany.com:80/salesdemo
として定義できます。
この場合、2 つの IP アドレス(VM1 の 111.111.111.111
と VM2 の 111.111.111.222
)間で http://api.mycompany.com:80/ トラフィックを分割する、なんらかの種類のロードバランサまたはトラフィック ディレクターが必要です。この関数は特定のインストールに固有のもので、ローカル ネットワーク グループによって構成されます。
ベースパスは、API をデプロイするときに設定します。上記の例では、api.mycompany.com
のホスト エイリアスとポートを 80
に設定した仮想ホストにより、組織 mycompany-org
に対して 2 つの API(mycompany
と testmycompany
)をデプロイできます。Deployment でベースパスを宣言しないと、ルーターは受信リクエストを送信する API を認識できません。
ただし、/salesdemo
のベース URL を使用して 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 を構成する場合、Router によるアクセスのために Message Processor のポート 8082 を開くだけで済みます。Router と Message Processor の間で TLS/SSL を構成していない場合、コンポーネントを管理するためにポート 8082 を Message Processor 上で開いておく必要がありますが、Router によるアクセスは必要ありません。
- 接頭辞「M」が付いたポートはコンポーネントの管理に使用するポートです。Management Server によるアクセスのためにコンポーネント上で開いておく必要があります。
- Router、Message Processor、UI、Postgres、Qpid のコンポーネントは、Management Server のポート 8080 にアクセスする必要があります。
- Message Processor で管理ポートとしてポート 4528 を開く必要があります。複数の Message Processor がある場合は、ポート 4528(Message Processor のポート 4528 については、上の図でループ矢印で示されています)を介して、すべてが相互にアクセスできるようにする必要があります。データセンターが複数ある場合は、すべてのデータセンターのすべての Message Processor からポートにアクセスできる必要があります。
- 必須ではありませんが、Router でポート 4527 を開いて Message Processor にアクセスできます。そうしないと、Message Processor のログファイルにエラー メッセージが表示されることがあります。
- Router は、管理ポートとしてポート 4527 を開く必要があります。複数の Router がある場合は、ポート 4527(Router のポート 4527 については、上の図のループ矢印で示されています)を介して、すべての Router が互いにアクセスできる必要があります。
- Edge UI は Trace ツールの [Send] ボタンをサポートするために、API プロキシによって公開されたポートで Router にアクセスする必要があります。
- Management Server は、Cassandra ノードの JMX ポートにアクセスする必要があります。
- JMX ポートへのアクセスは、ユーザー名とパスワードを要求するように構成できます。詳細については、モニタリング方法をご覧ください。
- 必要に応じて、特定の接続に対する TLS/SSL アクセスを構成できます。接続には、異なるポートを使用できます。詳細については、TLS/SSL をご覧ください。
- マスター / スタンバイ レプリケーションを使用するように 2 つの Postgres ノードを構成する場合は、SSH アクセス用に各ノードでポート 22 を開く必要があります。必要に応じて、個々のノードでポートを開いて SSH アクセスを許可できます。
- 外部の SMTP サーバー経由でメールを送信するように Management Server と Edge UI を構成できます。その場合は、Management Server と 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 は、この TLS / SSL を使用して Message Processor のヘルスチェックを行います。 |
|
1101 | JMX ポート | |
4528 | Message Processor 間の分散キャッシュと管理呼び出し、および Router と Management Server からの通信 | |
ルーター | 8081 | Router のデフォルト管理ポートで、Management Server によるアクセスのためにコンポーネント上で開いている必要があります。 |
4527 | 分散キャッシュと管理呼び出しの場合 | |
15999 |
ヘルスチェック ポート。ロードバランサは、このポートを使用して、Router が使用可能かどうかを判断します。 Router のステータスを取得するために、ロードバランサは Router のポート 15999 にリクエストを送信します。 curl -v http://routerIP:15999/v1/servers/self/reachable Router が到達可能な場合、リクエストは HTTP 200 を返します。 |
|
59001 | apigee-validate ユーティリティによる Edge インストールのテストに使用されるポート。
このユーティリティは、Router のポート 59001 にアクセスする必要があります。ポート 59001 の詳細については、インストールをテストするをご覧ください。 |
|
ZooKeeper | 2181 | Management Server、Router、Message Processor などの他のコンポーネントが使用 |
2888、3888 | ZooKeeper が ZooKeeper クラスタ(ZooKeeper アンサンブル)の通信のために内部的に使用 | |
Cassandra | 7000、9042、9160 | Cassandra ノード間の通信用と、他の Edge コンポーネントからのアクセス用の Apache Cassandra ポート。 |
7199 | JMX ポート。Management Server からアクセスできるように開く必要があります。 | |
Qpid | 5672 | Router と Message Processor から Qpid サーバーへの通信に使用されます。 |
8083 | Qpid サーバーのデフォルト管理ポートで、Management Server によるアクセスのためにコンポーネント上で開いている必要があります。 | |
1102 | JMX ポート | |
4529 | 分散キャッシュと管理呼び出しの場合 | |
Postgres | 5432 | Qpid/Management Server から Postgres への通信に使用 |
8084 | Postgres サーバーのデフォルト管理ポート。Management Server によるアクセスのためにコンポーネント上で開いている必要があります。 | |
1103 | JMX ポート | |
4530 | 分散キャッシュと管理呼び出しの場合 | |
22 | マスター / スタンバイ レプリケーションを使用するように 2 つの Postgres ノードを構成する場合は、SSH アクセス用に各ノードでポート 22 を開く必要があります。 | |
LDAP | 10389 | OpenLDAP |
SmartDocs | 59002 | SmartDocs ページのリクエストが送信される Edge Router のポート。 |
次の表に、同じポートを送信元コンポーネントと送信先コンポーネントとともに数字で示します。
ポート番号 | 目的 | ソース コンポーネント | 宛先コンポーネント |
---|---|---|---|
virtual_host_port | HTTP と、仮想ホスト API 呼び出しトラフィックに使用するその他のポート。通常はポート 80 と 443 が使用されます。Message Router は TLS 接続と SSL 接続を終端できます。 | 外部クライアント(またはロードバランサ) | Message Router のリスナー |
1099 ~ 1103 | JMX 管理 | JMX クライアント | Management Server(1099) Message Processor(1101) Qpid Server(1102) Postgres Server(1103) |
2181 | Zookeeper クライアントの通信 | Management Server Router Message Processor Qpid Server Postgres Server |
Zookeeper |
2888、3888 | Zookeeper のノード間管理 | Zookeeper | Zookeeper |
4526 | RPC Management ポート | 管理サーバー | 管理サーバー |
4527 | 分散キャッシュと管理呼び出し、および Router 間の通信用の RPC Management ポート | Management Server ルーター |
ルーター |
4528 | Message Processor 間の分散キャッシュ呼び出しと、Router からの通信 | Management Server Router Message Processor |
Message Processor |
4529 | 分散キャッシュと管理呼び出し用の RPC Management ポート | 管理サーバー | Qpid サーバー |
4530 | 分散キャッシュと管理呼び出し用の RPC Management ポート | 管理サーバー | Postgres サーバー |
5432 | Postgres クライアント | Qpid サーバー | Postgres |
5672 |
Router と Message Processor から Qpid にアナリティクスを送信するために使用されます。 |
Router Message Processor |
Qpid サーバー |
7000 | Cassandra のノード間通信 | Cassandra | 他の Cassandra ノード |
7199 | JMX 管理。Management Server から Cassandra ノードにアクセスするために開いている必要があります。 | JMX クライアント | Cassandra |
8080 | Management API ポート | Management API クライアント | 管理サーバー |
8081 ~ 8084 |
コンポーネント API ポート。個々のコンポーネントに直接 API リクエストを発行するために使用されます。各コンポーネントは異なるポートを開きます。使用される正確なポートは構成によって異なりますが、Management Server がアクセスするためにコンポーネント上で開いている必要があります。 |
Management API クライアント | Router(8081) Message Processor(8082) Qpid Server(8083) Postgres Server(8084) |
8998 | Router と Message Processor 間の通信 | ルーター | Message Processor |
9000 | デフォルトの Edge 管理 UI ポート | 参照者 | 管理 UI サーバー |
9042 | CQL ネイティブ トランスポート | Router Message Processor Management Server |
Cassandra |
9160 | Cassandra スリフト クライアント | Router Message Processor Management Server |
Cassandra |
10389 | LDAP ポート | 管理サーバー | OpenLDAP |
15999 | ヘルスチェック ポート。ロードバランサは、このポートを使用して、Router が使用可能かどうかを判断します。 | ロードバランサ | ルーター |
59001 | apigee-validate ユーティリティが Edge のインストールをテストするために使用するポート |
apigee-validate | ルーター |
59002 | SmartDocs ページのリクエストが送信されるルーターのポート | SmartDocs | ルーター |
Message Processor は、Cassandra に対して専用の接続プールを開いたままにします。これは、タイムアウトが発生しないように構成されています。ファイアウォールが Message Processor と Cassandra サーバーの間にあると、ファイアウォールが接続をタイムアウトすることがあります。ただし、Message Processor は Cassandra への接続を確立するようには設計されていません。
このような状況を回避するため、Cassandra サーバー、Message Processor、Router を同じサブネットに配置して、ファイアウォールがこれらのコンポーネントのデプロイに関与しないようにすることをおすすめします。
ファイアウォールが Router と Message Processor の間にあり、アイドル TCP タイムアウトが設定されている場合、次のようにすることをおすすめします。
- Linux OS の sysctl 設定で
net.ipv4.tcp_keepalive_time = 1800
を設定します。1800 はファイアウォールのアイドル tcp タイムアウトよりも小さくする必要があります。この設定では、ファイアウォールによって接続が切断されないように、接続が確立された状態を維持する必要があります。 - すべての Message Processor で、
/opt/apigee/customer/application/message-processor.properties
を編集して次のプロパティを追加します。ファイルが存在しない場合は作成します。conf_system_cassandra.maxconnecttimeinmillis=-1
- Message Processor を再起動します。
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- すべての Router で、
/opt/apigee/customer/application/router.properties
を編集して次のプロパティを追加します。ファイルが存在しない場合は作成します。conf_system_cassandra.maxconnecttimeinmillis=-1
- Router を再起動します。
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
2 つのデータセンターを使用して 12 ホストのクラスタ構成をインストールする場合は、2 つのデータセンターのノードが以下に示すポートを介して通信できることを確認します。
API BaaS ポートの要件
API BaaS のインストールを選択した場合、API BaaS Stack コンポーネントと API BaaS ポータル コンポーネントを追加します。これらのコンポーネントは、次の図に示すポートを使用します。
この図の注意事項:
- API BaaS ポータルから BaaS スタックノードに直接リクエストが行われることはありません。デベロッパーがポータルにログインすると、ポータルアプリがブラウザにダウンロードされます。ブラウザで実行されているポータル アプリが BaaS Stack ノードにリクエストを行います。
- API BaaS の本番環境インストールでは、API BaaS ポータルノードと API BaaS スタックノードの間でロードバランサを使用します。ポータルを構成するとき、および BaaS API 呼び出しを行うときに、スタックノードではなくロードバランサの IP アドレスまたは DNS 名を指定します。
- すべてのスタックノードは、他のすべてのスタックノードからアクセスするためにポート 2551 を開く必要があります(上の図でスタックノードのポート 2551 にはループ矢印で示されています)。複数のデータセンターがある場合は、すべてのデータセンター内のすべてのスタックノードからポートにアクセスできる必要があります。
- すべての Baas Stack ノードが、外部の SMTP サーバー経由でメールを送信するように構成する必要があります。非 TLS SMTP の場合、ポート番号は通常 25 です。TLS 対応の SMTP の場合、通常は 465 ですが、SMTP プロバイダに確認してください。
- Cassandra ノードは、API BaaS 専用にすることも、Edge と共有することもできます。
下の表は、ファイアウォールで開く必要があるデフォルトのポートをコンポーネント別に示しています。
コンポーネント | ポート | 説明 |
---|---|---|
API BaaS ポータル | 9000 | API BaaS UI のポート |
API BaaS スタック | 8080 | API リクエストを受信するポート |
2551 |
すべてのスタックノード間の通信用のポート。データキャンター内の他のすべてのスタックノードからアクセスできる必要があります。 複数のデータセンターがある場合は、すべてのデータセンター内のすべてのスタックノードからポートにアクセスできる必要があります。 |
|
ElasticSearch | 9,200 ~ 9,400 | API BaaS Stack との通信と ElasticSearch ノード間の通信用 |
ライセンス
Edge のインストールごとに、Apigee から取得した一意のライセンス ファイルが必要になります。Management Server をインストールする際に、ライセンス ファイルへのパス(/tmp/license.txt など)を指定する必要があります。
インストーラにより、ライセンス ファイルは /opt/apigee/customer/conf/license.txt
にコピーされます。
ライセンス ファイルが有効な場合、管理サーバーは有効期限と許可された Message Processor(MP)の数を検証します。いずれかのライセンス設定が期限切れの場合は、/opt/apigee/var/log/edge-management-server/logs
にあるログでそれを調べることができます。その場合は、Apigee Edge サポートに移行の詳細をお問い合わせください。
ライセンスをお持ちでない場合は、Apigee Sales にお問い合わせください。