ハードウェア要件
本番環境レベルの高可用性インフラストラクチャでは、次の最小ハードウェア要件を満たす必要があります。
次の動画は、インストール環境のサイズに関する全般的なガイダンスを示しています。
インストール トポロジで説明されているすべてのインストール シナリオについて、インストール コンポーネントの最小ハードウェア要件を次の表に示します。
上記の表では、ハードディスクの要件は、オペレーティング システムで必要なハードディスク容量とは別のものです。アプリケーションとネットワーク トラフィックによっては、インストールに必要なリソースが下記より多い場合と少ない場合があります。
インストール コンポーネント | 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 |
ルーター(スタンドアロン) | 16 GB | 8 コア | 100 GB |
分析 - 同一サーバー上の Postgres/Qpid | 16GB* | 8 コア* | 500 GB ~ 1 TB** ネットワーク ストレージ ***(1,000 IOPS 以上* をサポートする SSD バックエンドを推奨) |
分析 - Postgres マスターまたはスタンバイ(スタンドアロン) | 16GB* | 8 コア* | 500 GB ~ 1 TB** ネットワーク ストレージ ***(1,000 IOPS 以上* をサポートする SSD バックエンドを推奨) |
アナリティクス - Qpid スタンドアロン | 8 GB | 4 コア | 30 GB ~ 50 GB のローカル ストレージ(SSD)
デフォルトの Qpid キューサイズは 1 GB ですが、2 GB に増やすことができます。さらに容量が必要な場合は、Qpid ノードを追加します。 |
OpenLDAP/UI/Management Server | 8 GB | 4 コア | 60 GB |
UI/Management Server | 4 GB | 2 コア | 60 GB |
OpenLDAP(スタンドアロン) | 4 GB | 2 コア | 60 GB |
* スループットに基づいて Postgres のシステム要件を調整する
** Postgres のハードディスクの値は、Edge によって取り込まれた、すぐに使用できる分析に基づいています。 分析データにカスタム値を追加する場合は、それに応じて値を増やす必要があります。次の式を使用して、必要なストレージを見積もります。
次に例を示します。
*** ネットワーク ストレージが Postgresql データベースに推奨されている理由は次のとおりです。
|
さらに、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 バックエンドが望ましい)か、上記の表のルールを使用します。 |
分析 - Postgres マスターまたはスタンバイ スタンドアロン | 16 GB | 8 コア | 500 GB ~ 1 TB のネットワーク ストレージ(1,000 IOPS 以上をサポートする SSD バックエンドが望ましい)か、上記の表のルールを使用します。 |
アナリティクス - 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 コンポーネントのインストールと起動で Edge で問題が発生することがあります。必要に応じて、インストール時に SELinux を無効にするか、permissive モードに設定して、インストール後に再度有効にできます。詳細については、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.52.02.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
掲載ネットワークの設定
インストール前にネットワーク設定を確認することをおすすめします。インストーラは、すべてのマシンが固定 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 プロセスから特別な要件がある Edge ノード上のディレクトリを示します。
サービス | ディレクトリ | 説明 |
---|---|---|
ルーター | /etc/rc.d/init.d/functions |
Edge Router は Nginx ルーターを使用するため、 セキュリティ プロセスで 権限を 744 に設定すると、 |
Zookeeper | /dev/random |
Zookeeper クライアント ライブラリには、乱数ジェネレータ /dev/random への読み取りアクセス権が必要です。/dev/random の読み取りがブロックされている場合、Zookeeper サービスを起動できない可能性があります。 |
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 apigee soft nproc 32768 apigee hard nproc 65536
- Message Processor ノードでは、次のように
/etc/security/limits.d/90-apigee-edge-limits.conf
でオープン ファイル記述子の最大数を 64, 000 に設定します。apigee soft nofile 32768 apigee hard nofile 65536
必要に応じて、この上限を引き上げることができます。たとえば、一度に大量の一時ファイルを開いている場合などです。
Router または Message Processor の
system.log
で次のエラーが表示された場合は、ファイル記述子の上限が低すぎる可能性があります。"java.io.IOException: Too many open files"
ユーザー数の上限を確認するには、次のコマンドを実行します。
# su - apigee $ ulimit -n 100000
ファイル記述子の制限を
100000
に設定しても、オープン ファイルの制限に達する場合は、トラブルシューティングを続けるために Apigee Edge サポートでチケットを作成してください。
ネットワーク・セキュリティ・サービス(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 ソケット |
rpm2cpio |
useradd |
bash |
hostname |
ls |
sed |
wc |
bc |
id |
net-tools |
sudo |
wget |
curl |
リバイオ |
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 レプリケーションが必要です。
ファイアウォールと仮想ホスト
IT 分野では、virtual
という用語が過負荷になるのが一般的です。Apigee Edge for Private Cloud のデプロイや仮想ホストでは、virtual
という用語が使われがちです。明確にするために説明すると、virtual
という用語には、主に次の 2 つの用途があります。
- 仮想マシン(VM): 必須ではありませんが、一部のデプロイでは VM テクノロジーを使用して、Apigee コンポーネント用に分離されたサーバーを作成します。VM ホストには、物理ホストと同様に、ネットワーク インターフェースとファイアウォールを設定できます。
- 仮想ホスト: Apache 仮想ホストに似たウェブ エンドポイント。
VM 内のルーターは、複数の仮想ホストを公開できます(ただし、ホスト エイリアスまたはインターフェース ポートがそれぞれ異なる必要があります)。
例として、単一の物理サーバー 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 プロキシ バンドルは、ベースパスが異なる場合、エンドポイントを共有できます。たとえば、あるベースパスを http://api.mycompany.com:80/
と定義し、別のベースパスを 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
に mycompany
と testmycompany
の 2 つの API をデプロイできます。デプロイでベースパスを宣言しないと、ルーターは受信リクエストの送信先の API を認識しません。
ただし、ベース URL が /salesdemo
の API testmycompany
をデプロイすると、ユーザーは http://api.mycompany.com:80/salesdemo
を使用してその API にアクセスします。ベース URL を /
に設定して API mycompany をデプロイすると、ユーザーは URL http://api.mycompany.com:80/
で API にアクセスします。
ライセンス
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 セールスまでお問い合わせください。