インストール要件

Edge for Private Cloud v4.18.05

ハードウェア要件

本番環境で高可用性インフラストラクチャを構築するには、次の最小ハードウェア要件を満たす必要があります。

次の動画では、インストールのサイジングに関する大まかなガイダンスを提供しています。

インストール トポロジで説明されているすべてのインストール シナリオについて、次の表にインストール コンポーネントの最小ハードウェア要件を示します。

これらの表のハードディスク要件は、オペレーティング システムに必要なハードディスク容量に加えて必要となるものです。アプリケーションとネットワーク トラフィックによっては、インストールに必要なリソースが以下のリストよりも多くなることも少なくなることもあります。

インストール コンポーネント RAM CPU 最小ハードディスク
Cassandra 16 GB 8 コア 250 GB のローカル ストレージ（SSD または高速 HDD、2,000 IOPS をサポート）
同じマシン上の Message Processor/Router 16 GB 8 コア 100 GB
Analytics - Postgres/Qpid（同一サーバー上） 16GB* 8 コア* 500 GB ～ 1 TB の**ネットワーク ストレージ***（SSD バックエンドが望ましい）、1,000 IOPS 以上をサポート*
Analytics - Postgres（スタンドアロン） 16GB* 8 コア* 500 GB ～ 1 TB の**ネットワーク ストレージ***（SSD バックエンドが望ましい）、1,000 IOPS 以上をサポート*
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 は、今日のほとんどの環境/ストレージ/ネットワーク サブシステムでオンザフライで調整できます。
  • ストレージ レベルのスナップショットは、バックアップと復元のソリューションの一部として有効にできます。

また、収益化サービスをインストールする場合は、次のハードウェア要件を満たす必要があります。

収益化コンポーネント RAM CPU ハードディスク
Management Server（Monetization Services を含む） 8 GB 4 コア 60 GB
Analytics - Postgres/Qpid（同一サーバー上） 16 GB 8 コア 500 GB ～ 1 TB のネットワーク ストレージ（SSD バックエンドが望ましい）。1,000 IOPS 以上をサポートするか、上記の表のルールを使用します。
Analytics - Postgres（スタンドアロン） 16 GB 8 コア 500 GB ～ 1 TB のネットワーク ストレージ（SSD バックエンドが望ましい）。1,000 IOPS 以上をサポートするか、上記の表のルールを使用します。
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」ユーザーとグループを作成します。
    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 モードに設定し、インストール後に再度有効にすることができます。詳細については、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 Wrappers は一部のポートの通信をブロックし、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 ルーターを使用しており、/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

これらの値を設定するには:

  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 および 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（ネームサービス キャッシュ デーモン）をインストールして有効にしている場合、メッセージ プロセッサは 2 つの DNS ルックアップ（IPv4 用と IPv6 用）を行います。NSCD を使用する場合は、IPv6 の DNS ルックアップを無効にする必要があります。

IPv6 の DNS ルックアップを無効にするには:

  1. すべての Message Processor ノードで、/etc/nscd.conf を編集します。
  2. 次のプロパティを設定します。
    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 のドキュメントをご覧ください。たとえば、次のようなことができます。

  1. エディタで /etc/hosts を開きます。
  2. 次の行の 1 列目に「#」文字を挿入して、コメントアウトします。
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. ファイルを保存します。

AWS AMI

Red Hat Enterprise Linux 7.x の AWS Amazon マシンイメージ（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
ディレクトリ名 libibverbs pwd uname  
エコー 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 ルーターが実行されている可能性があります。ルーターは、次の架空の例のように、仮想ホスト エンドポイントを公開します。

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 プロキシ バンドルは、ベースパスが異なる場合、エンドポイントを共有できます。たとえば、1 つのベースパスを 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 に送信すべきかわかりません。

ただし、ベース 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 セールスにお問い合わせください。