インストールの要件

ハードウェア要件

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

次の動画で、インストールに関するサイジング ガイドの概要を示します。

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

この表のハードディスク要件は、オペレーティング システムが必要とするハードディスク容量とは別に必要となります。使用するアプリケーションとネットワーク トラフィックによっては、必要なリソースは下記より増減する場合があります。

インストール コンポーネント 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（同一サーバー上） 16GB* 8 コア* 500 GB ～ 1 TB** のネットワーク ストレージ***（1,000 IOPS 以上* をサポートする SSD バックエンドを推奨）
Analytics - Postgres マスターまたはスタンバイ（スタンドアロン） 16GB* 8 コア* 500 GB ～ 1 TB** のネットワーク ストレージ***（1,000 IOPS 以上* をサポートする SSD バックエンドを推奨）
Analytics - 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 のシステム要件を調整します。

  • 250 TPS 未満: 8 GB および 4 コアの使用を検討可能、1, 000 IOPS 以上をサポートするマネージド ネットワーク ストレージ***
  • 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 of storage needed

*** Postgresql データベースには次の理由からネットワーク ストレージが推奨されます。

  • 必要に応じて、ストレージ サイズを動的にスケールアップすることが可能。
  • ネットワーク IOPS は、近年の環境/ストレージ/ネットワーク サブシステムの多くで、稼働中に調整が可能。
  • バックアップおよびリカバリ ソリューションの一部として、ストレージ レベルのスナップショットを有効にすることが可能。

さらに、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 を推奨

Cassandra ネットワーク帯域幅の要件

Cassandra は Gossip プロトコルを使用して、ネットワーク トポロジに関する情報を他のノードと交換します。Gossip の使用と Cassandra の分散性（読み取り / 書き込みオペレーションのために複数のノードと通信する）により、ネットワークを介した大量のデータ転送が発生します。

Cassandra では、最小ネットワーク帯域幅がノードごとに 1 Gbps 必要です。本番環境にインストールする場合は、より高い帯域幅を使用することをおすすめします。

Cassandra の最大レイテンシまたは 99 パーセンタイルのレイテンシは 100 ミリ秒未満にする必要があります。

オペレーティング システムとサードパーティ ソフトウェアの要件

これらのインストール手順と提供されているインストール ファイルは、サポート対象ソフトウェアとサポート対象バージョンに示すオペレーティング システムとサードパーティ ソフトウェアを使用してテストされています。

前提条件: EPEL リポジトリを有効にする

インストールを続行する前に、EPEL（Extra Packages for Enterprise Linux）リポジトリが有効になっていることを確認します。オペレーティング システムのバージョンに応じて、次のコマンドを使用します。

  • Red Hat/CentOS/Oracle 8.X の場合: 
    wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
     
    sudo rpm -ivh epel-release-latest-8.noarch.rpm
  • Red Hat/CentOS/Oracle 9.X の場合: 
    wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
     
    sudo rpm -ivh epel-release-latest-9.noarch.rpm

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

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

シンボリック リンクを作成するには、bootstrap_4.53.00.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

掲載ネットワークの設定

インストール前にネットワーク設定を確認することを推奨します。インストーラは、すべてのマシンが固定 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

ディレクトリへのアクセス

次の表に、Edge プロセスの特別な要件がある Edge ノードのディレクトリを示します。

サービス ディレクトリ 説明
ルーター /etc/rc.d/init.d/functions

Edge Router は Nginx ルーターを使用しており、/etc/rc.d/init.d/functions への読み取りアクセス権が必要です。

自社のセキュリティ プロセスで /etc/rc.d/init.d/functions に対する権限の設定が義務付けられている場合、700 には設定しないでください。そうすると、Router は起動できません。

権限を 744 に設定すると、/etc/rc.d/init.d/functions への読み取りアクセスが許可されます。
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_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

Rocky 9.X の言語 / 地域の設定

Rocky 9.X を使用している場合は、システム全体のロケール設定で LANG=en_US.utf8 でシステムが構成されていることを確認します。これを構成するには、次のコマンドを実行します。

dnf -y -q install langpacks-en
localectl set-locale LANG=en_US.utf8
reboot

システム制限

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 サポートでチケットを開いてください。

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

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

RHEL 8 以降で IPv6 を無効にする

Google Cloud Platform 上の RHEL 8 以降のバージョンに Edge をインストールする場合は、すべての Qpid ノードで IPv6 を無効にする必要があります。

IPv6 を無効にする手順については、お使いの OS ベンダーのドキュメントをご覧ください。たとえば、Red Hat Enterprise Linux のドキュメントで関連情報を確認できます。

ツール

インストーラでは、次の 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 おいしい

date

 libdb-cxx

ps

uuid

chkconfig
ディレクトリ名 libibverbs pwd uname  
エコー librdmacm python    

時刻の同期

サーバーの時刻を同期させることをおすすめします。まだ構成していない場合は、ntpdate ユーティリティまたは同等のツールを使用して、サーバーの時刻が同期されているかどうかを確認します。たとえば、yum install ntp または同等のコマンドを使用してユーティリティをインストールできます。このコマンドは、OpenLDAP 設定をレプリケートする場合に特に役立ちます。サーバーのタイムゾーンは UTC に設定する必要があります。

openldap 2.4

オンプレミス インストールには OpenLDAP 2.4 が必要です。これは apigee-thirdparty-opdk リポジトリに含まれています。インストールを容易にするため、openldap-compat ライブラリを削除してください。

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」が仮想イーサネット インターフェースを公開し、VM 内で「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 Edge サポートに移行の詳細をお問い合わせください。

ライセンスをお持ちでない場合は、Apigee Sales にお問い合わせください。