Edge for Private Cloud v4.18.05
ハードウェア要件
本番環境での高可用性インフラストラクチャでは、次の最小ハードウェア要件を満たす必要があります。
次の動画で、インストールに関するサイジング ガイドの概要を示します。
インストール トポロジで説明されているインストール シナリオについて、インストール コンポーネントの最小ハードウェア要件を次の表に示します。
この表のハードディスク要件は、オペレーティング システムが必要とするハードディスク容量とは別に必要となります。アプリケーションとネットワーク トラフィックによっては、以下の記載より必要なリソースが増減する場合があります。
インストール コンポーネント | RAM | CPU | 最小ハードディスク |
---|---|---|---|
Cassandra | 16 GB | 8 コア | 250 GB のローカル ストレージ(SSD または 2,000 IOPS をサポートする高速 HDD) |
Message Processor / 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 または高速 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 をインストールする場合のハードウェア要件を次に示します。
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 を推奨 |
オペレーティング システムとサードパーティ ソフトウェアの要件
次のインストール手順と提供されるインストール ファイルは、サポート対象のソフトウェアおよびサポート対象のバージョンに記載されているオペレーティング システムとサードパーティ ソフトウェアでテストされています。
「apigee」ユーザーの作成
インストール手順において、「apigee」という Unix システムのユーザーが作成されます。Edge のディレクトリとファイルは、Edge プロセスと同じく、「apigee」が所有者となります。つまり、Edge コンポーネントは「apigee」ユーザーとして実行されます。必要に応じて、コンポーネントを別のユーザーとして実行することも可能です。
インストール ディレクトリ
デフォルトでは、インストーラはすべてのファイルを /opt/apigee
ディレクトリに保存します。このディレクトリの場所は変更できません。ディレクトリを変更する代わりに、/opt/apigee のシンボリック リンクの作成で説明している方法で、シンボリック リンクを作成し /opt/apigee
を別の場所にマッピングすることはできます。
このガイドの説明では、インストール ディレクトリは /opt/apigee
としています。
/opt/apigee のシンボリック リンクの作成
シンボリック リンクを作成する前に、まず「apigee」というユーザーとグループを作成してください。このグループとユーザーは、Edge インストーラが作成するものと同じです。
シンボリック リンクを作成するには、次の手順を実施した後、bootstrap_4.18.05.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
Java
インストール前に、サポート対象の Java 1.8 が各マシンにインストールされている必要があります。サポート対象の JDK は、サポート対象のソフトウェアおよびサポート対象のバージョンに記載されています。
JAVA_HOME
環境変数にインストールを行うユーザーの JDK のルートを指定していることを確認します。
SELinux
SELinux の設定によっては、Edge コンポーネントのインストールと起動で問題が発生することがあります。必要に応じて、インストール中に SELinux を無効にするか permissive モードに設定し、インストール後に再度 SELinux を有効にすることが可能です。詳細については、Edge apigee-setup ユーティリティをインストールするをご覧ください。
ネットワーク設定
インストール前にネットワーク設定を確認することを推奨します。インストーラは、すべてのマシンが固定 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 Router が /etc/rc.d/init.d/functions にアクセスできることを確認する
Edge Router は Nginx Router を使用し、/etc/rc.d/init.d/functions
への読み取りアクセスを要求します。
セキュリティ プロセスで /etc/rc.d/init.d/functions
の権限の設定を求められた場合、権限に 700 は設定できません。700 に設定するとルーターの起動が失敗します。権限を 744 に設定することで、/etc/rc.d/init.d/functions
への読み取りアクセスが許可されます。
Cassandra
すべての Cassandra ノードは、1 つのリングに接続される必要があります。Cassandra は、複数のノードにデータレプリカを格納して、信頼性とフォールト トレランスを確保します。Edge キー空間ごとのレプリケーション戦略によって、レプリカが配置される Cassandra ノードが決定されます。詳細については、Cassandra のレプリケーション係数と整合性レベルについてをご覧ください。
Cassandra は、使用可能なメモリに基づいて Java のヒープサイズを自動的に調整します。パフォーマンス低下または高メモリ消費の場合、詳細については、Tuning Java resources をご覧ください。
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 memlock、hard memlock、soft nofile、hard nofile、soft address space(as)、hard address space(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 は IPv4 と IPv6 で二度の DNS ルックアップを行います。NSCD を使用する場合は、IPv6 の DNS ルックアップを無効にしてください。
IPv6 の DNS ルックアップを無効にするには:
- すべての Message Processor ノードで
/etc/nscd.conf
を編集します。 - 次のプロパティを設定します。
enable-cache hosts no
RedHat / CentOS 7 の Google Cloud Platform で 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
ツール
EL5 または EL6 で提供されている標準バージョンでは、インストーラは次の UNIX ツールを使用します。
awk |
expr |
lua-socket |
rpm |
unzip |
basename |
grep |
ls |
rpm2cpio |
useradd |
bash |
hostname |
net-tools |
sed |
wc |
bc |
id |
perl(from procps) |
sudo |
wget |
curl |
libaio |
pgrep(from procps) |
tar |
xerces-c |
cyrus-sasl | libdb-cxx | ps | tr | yum |
date |
libibverbs |
pwd |
uuid |
chkconfig |
dirname | librdmacm | python | uname | |
echo | libxslt |
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 内のルーターは、複数の仮想ホストを(ホスト エイリアスまたはインターフェース ポートで互いに異なる場合)公開できます。
命名例として、単一の物理サーバー A
が実行している 2 つの VM を、「VM1」と「VM2」とします。「VM1」は VM 内で「eth0」という仮想イーサネット インターフェースを公開し、仮想マシンまたはネットワーク DHCP サーバーによって IP アドレス 111.111.111.111
が割り当てられていると仮定します。VM2 も「eth0」という名前の仮想イーサネット インターフェースを公開し、こちらは IP アドレス 111.111.111.222
が割り当てられていると仮定します。
2 つの VM 内それぞれで Apigee Router が存在している可能性があります。次の仮定の例のようにルーターは仮想ホストのエンドポイントを公開します。
VM1 の Apigee Router は、eth0 インターフェース(特定の IP アドレスを持つ)で 3 つの仮想ホスト api.mycompany.com:80
、api.mycompany.com:443
、test.mycompany.com:80
を公開します。
VM2 の Apigee ルーターは、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 をデプロイする際にベースパスが設定されます。上記の例から、組織 mycompany-org
の 2 つの API である mycompany
と testmycompany
をデプロイできます。それらの API は api.mycompany.com
のホスト エイリアスと 80
に設定されたポートを持つ仮想ホストを使用します。デプロイでベースパスを宣言しないと、ルーターは受信リクエストを送信する API を認識できません。
ただし、ベース URL を /salesdemo
にして API の testmycompany
をデプロイした場合、ユーザーは http://api.mycompany.com:80/salesdemo
を使用して API にアクセスします。ベース URL を /
にして API の mycompany をデプロイした場合、ユーザーは URL の http://api.mycompany.com:80/
を使用して API にアクセスします。
ライセンス
Edge をインストールするたびに、Apigee から取得した固有のライセンス ファイルが必要になります。Management Server をインストールするときは、ライセンス ファイルへのパスを指定してください(例: /tmp/license.txt)。
インストーラはライセンス ファイルを /opt/apigee/customer/conf/license.txt
にコピーします。
ライセンス ファイルが有効な場合、有効期限と、許可された Message Processor(MP)数が、Management Server によって検証されます。いずれかのライセンス設定が期限切れになっている場合は、/opt/apigee/var/log/edge-management-server/logs
でログを確認できます。この場合、移行の詳細について、Apigee サポートにお問い合わせください。
ライセンスをお持ちでない場合は、Apigee Sales にお問い合わせください。