ハードウェア要件
本番環境の高可用性インフラストラクチャでは、次の最小ハードウェア要件を満たしている必要があります。
インストールのサイジングについて概要を説明する次の動画をご覧ください。
インストール トポロジで説明されているすべてのインストール シナリオに適用される、インストール コンポーネントの最小ハードウェア要件を次の表に示します。
この表のハードディスク要件は、オペレーティング システムが必要とするハードディスク容量とは別に必要となります。使用するアプリケーションとネットワーク トラフィックによっては、必要なリソースは下記より増減する場合があります。
| インストール コンポーネント | RAM | CPU | 最小ハードディスク |
|---|---|---|---|
| Cassandra | 16 GB | 8 コア | 250 GB のローカル ストレージ（2,000 IOPS をサポートする SSD） |
| Message Processor / Router（同一マシン上） | 16 GB | 8 コア | 100 GB |
| Message Processor（スタンドアロン） | 16 GB | 8 コア | 100 GB |
| Router（スタンドアロン） | 16 GB | 8 コア | 100 GB |
| Analytics - 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 コア | 30 GB～50 GB のローカル ストレージ（SSD）
デフォルトの Qpid キューサイズは 20 GB です。容量を増やす場合は Qpid ノードを追加してください。 |
| OpenLDAP / UI / Management Server | 4 GB | 2 コア | 60 GB |
| UI / Management Server | 4 GB | 2 コア | 60 GB |
| OpenLDAP（スタンドアロン） | 4 GB | 2 コア | 60 GB |
|
* 次のスループットに基づいて Postgres のシステム要件を調整します。
** Postgres のハードディスクの値は、カスタム値なしの分析を Edge で取得する場合に基づきます。分析データにカスタム値を追加する場合は、それに応じてハードディスクのサイズを増やす必要があります。次の数式を使用して必要なストレージを計算します。
次に例を示します。
*** Postgresql データベースには次の理由からネットワーク ストレージが推奨されます。
|
|||
さらに、Monetization Services をインストールする場合のハードウェア要件を次に示します（Monetization Services はオールインワン インストールではサポートされません）。
| Monetization を使用するコンポーネント | RAM | CPU | ハードディスク |
|---|---|---|---|
| Management Server（Monetization Services を使用） | 8 GB | 4 コア | 60 GB |
| Analytics - 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 を推奨 |
オペレーティング システムとサードパーティ ソフトウェアの要件
これらのインストール手順と提供されているインストール ファイルは、サポート対象ソフトウェアとサポート対象バージョンに示すオペレーティング システムとサードパーティ ソフトウェアを使用してテストされています。
Java
インストール前に、サポート対象の Java 1.8 が各マシンにインストールされている必要があります。サポートされている JDK の一覧については、サポート対象ソフトウェアとサポート対象バージョンをご覧ください。
インストールを行うユーザーの JAVA_HOME 環境変数に JDK のルート ディレクトリが設定されていることを確認します。
SELinux
SELinux の設定によっては、Edge コンポーネントのインストールと起動で問題が発生することがあります。必要に応じて、インストール中に SELinux を無効にするか permissive モードに設定し、インストール後に再度 SELinux を有効にすることが可能です。詳細については、Edge apigee-setup ユーティリティのインストールをご覧ください。
「apigee」ユーザーの作成
インストール手順において、「apigee」という UNIX システムのユーザーが作成されます。Edge のディレクトリとファイルは、Edge プロセスと同じく、「apigee」が所有者となります。つまり、Edge コンポーネントは「apigee」ユーザーとして実行されます。必要に応じて、コンポーネントを別のユーザーとして実行することも可能です。
インストール ディレクトリ
デフォルトでは、インストーラはすべてのファイルを /opt/apigee ディレクトリに書き込みます。このディレクトリの場所は変更できません。このディレクトリは変更できませんが、/opt/apigee を別の場所にマップするシンボリック リンクを作成することは可能です。詳細については、/opt/apigee のシンボリック リンクの作成をご覧ください。
このガイドの手順では、インストール ディレクトリを /opt/apigee と記載しています。
/opt/apigee のシンボリック リンクの作成
シンボリック リンクを作成する前に、まず「apigee」というユーザーとグループを作成してください。このグループとユーザーは、Edge インストーラが作成するものと同じです。
シンボリック リンクを作成するには、bootstrap_4.19.06.sh ファイルをダウンロードする前に次の手順を実施します。これらの手順はすべて root ユーザーで行う必要があります。
- 「apigee」ユーザーと「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
ネットワーク設定
インストール前にネットワーク設定を確認することを推奨します。インストーラは、すべてのマシンが固定 IP アドレスを持つことを想定しています。次のコマンドを使用して設定を確認します。
hostnameはマシンの名前を返します。hostname -iは、他のマシンからアドレス参照できるホスト名の IP アドレスを返します。
オペレーティング システムの種類とバージョンによっては、ホスト名が正しく設定されていない場合に /etc/hosts と /etc/sysconfig/network を編集しなければならないことがあります。詳細については、使用しているオペレーティング システムのドキュメントをご覧ください。
サーバーに複数のインターフェース カードが搭載されている場合、「hostname -i」コマンドはスペースで区切られた IP アドレスのリストを返します。デフォルトでは、Edge インストーラは返ってきたリストの最初の IP アドレスを使用しますが、これが正しい 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 プロセスの特別な要件がある Edge ノードのディレクトリを示します。
| サービス | ディレクトリ | 説明 |
|---|---|---|
| Router | /etc/rc.d/init.d/functions |
Edge Router は Nginx ルーターを使用しており、 自社のセキュリティ プロセスで 権限を 744 に設定すると、 |
| Zookeeper | /dev/random |
Zookeeper クライアント ライブラリを機能させるため、乱数生成ツール /dev/random への読み取りアクセス権が必要です。/dev/random の読み取りがブロックされている場合、Zookeeper サービスは起動できません。 |
Cassandra
すべての Cassandra ノードが 1 つのリングに接続されている必要があります。Cassandra は、信頼度とフォールト トレランスを確保するため、複数のノードにデータレプリカを保持します。Edge キースペースごとのレプリケーション戦略によって、レプリカが配置される Cassandra ノードが決定されます。詳細については、Cassandra のレプリケーション係数と整合性レベルについてをご覧ください。
Cassandra は、使用可能なメモリに基づいて Java のヒープサイズを自動的に調整します。パフォーマンスの低下が見られる場合やメモリ消費量が多い場合は、Java リソースのチューニングをご覧ください。
Edge for Private Cloud をインストールした後、/opt/apigee/apigee-cassandra/conf/cassandra.yaml ファイルを調べて Cassandra が正しく構成されていることを確認できます。たとえば、Edge for Private Cloud インストール スクリプトによって次のプロパティが設定されたことを確認します。
cluster_nameinitial_tokenpartitionerseedslisten_addressrpc_addresssnitch
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
この上限は必要に応じて増やすことができます。たとえば、一度に大量の一時ファイルを開く場合はこの値を増やします。
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 によって、DNS ルックアップが 2 回（IPv4 と IPv6 について 1 回ずつ）行われます。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 を無効にする手順については、お使いのバージョンの 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
ツール
インストーラでは、次の UNIX ツール（EL5 または EL6 で提供されている標準バージョン）が使用されます。
|
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（from procps） |
tar |
xerces-c |
| cyrus-sasl | libdb4 | pgrep（from procps） | tr | yum |
|
date |
libdb-cxx |
ps |
uuid |
chkconfig |
| dirname | libibverbs | pwd | uname | |
| echo | librdmacm | python |
ntpdate
サーバーの時刻を同期させることをおすすめします。これには 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 レプリケーションが必須となります。
ファイアウォールと仮想ホスト
IT の世界では virtual（仮想）という用語が頻繁に使われており、これは Apigee Edge for Private Cloud のデプロイメントと仮想ホストにも当てはまります。より明確に言うと、virtual という用語は主に次の 2 つの用途で使われています。
- 仮想マシン（VM）: 必須ではありませんが、一部のデプロイメントでは VM 技術を使用して Apigee コンポーネント用のサーバーを分離します。VM ホストは、物理ホストのようにネットワーク インターフェースやファイアウォールを実装できます。
- 仮想ホスト: Apache 仮想ホストに類似したウェブ エンドポイント。
VM 上のルーターは複数の仮想ホストを公開できます（ただし、それらの仮想ホストのホスト エイリアスまたはインターフェース ポートが互いに異なる必要があります）。
たとえば、1 台の物理サーバー A で「VM1」、「VM2」という 2 つの VM を稼働できます。VM1 で仮想イーサネット インターフェースが公開されていると仮定します。このインターフェースには VM1 内で「eth0」という名前が付けられ、仮想化機構またはネットワークの DHCP サーバーによって IP アドレス 111.111.111.111 が割り当てられています。また、VM2 でも「eth0」という仮想イーサネット インターフェースが公開されており、IP アドレス 111.111.111.222 が割り当てられているとします。
この場合、2 つの VM のそれぞれで Apigee Router を稼働させることができます。この例では、これらのルーターは次のように仮想ホストのエンドポイントを公開します。
VM1 の Apigee Router は、その 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 プロキシ バンドルは、異なるベースパスを持つ場合に特定のエンドポイントを共有できます。たとえば、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 に送信すればよいかわかりません。
しかし、API testmycompany を /salesdemo というベース URL でデプロイすれば、ユーザーは http://api.mycompany.com:80/salesdemo を使用してこの API にアクセスできます。また、API mycompany を / というベース URL でデプロイすれば、ユーザーは URL http://api.mycompany.com:80/ によってこの API にアクセスできます。
ライセンス
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 サポートに移行の詳細をお問い合わせください。
ライセンスをお持ちでない場合は、Apigee Sales にお問い合わせください。