インストール要件

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 としています。

シンボリック リンクを作成する前に、まず「apigee」というユーザーとグループを作成してください。このグループとユーザーは、Edge インストーラが作成するものと同じです。

シンボリック リンクを作成するには、次の手順を実施した後、bootstrap_4.18.05.sh ファイルをダウンロードします。これらの手順は、すべて root ユーザーで実施します。

  1. 「apigee」ユーザーと「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 モードに設定し、インストール後に再度 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

上記の値を設定するには:

  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 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 ルックアップを無効にするには:

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

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

Google Cloud Platform 上の RedHat 7 または CentOS 7 に Edge をインストールする場合、すべての Qpid ノードで IPv6 を無効にしてください。

IPv6 を無効にする手順については、お使いのバージョンの 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 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 にお問い合わせください。