This page applies to on-premise deployments.

Related pages:

このページでは、イベントサービスノードをホストするマシンを準備する方法と、その環境に対する全般的な要件について説明します。 

ネットワークとポートの設定

コントローラとイベントサービスは、同じローカルネットワーク上に配置されていて、内部ネットワークで通信できる必要があります。互いに関連していても、コントローラと Enterprise Console に関連していても、別のネットワークにあるノードにクラスタをデプロイしないでください。構成でクラスタホストを特定する場合は、そのホストの外部ルーティング対応の DNS 名ではなく、ホストの内部 DNS 名または IP アドレスを使用する必要があります。 

たとえば、AWS 展開の場合、ec2-34-201-129-89.us-west-2.compute.amazonaws.com などの公開 DNS ホスト名ではなく、172.31.2.19 などのプライベート IP アドレスを使用します。

各マシンで、以下のポートで外部（クラスタ外）のトラフィックにアクセスできる必要があります。

  • イベントサービスAPIストアのポート：9080
  • イベントサービスAPIストアの管理ポート：9081

クラスタについては、以下のポートがクラスタ内のマシン間の通信に対してオープンな状態であることを確認します。通常、以下のポートを開くには、各マシンでiptablesまたはOSレベルのファイアウォールソフトウェアを構成する必要があります。

  • 9300 ～ 9400

オペレーティングシステムのファイアウォールを構成するための iptables コマンドの例を次に示しています。

-A INPUT -m state --state NEW -m tcp -p tcp --dport 9080 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 9081 -j ACCEPT
-A INPUT -m state --state NEW -m multiport -p tcp --dports 9300:9400 -j ACCEPT
BASH

イベントサービスノードでポートがブロックされている場合、そのノードに対するイベントサービスのインストールコマンドは失敗し、Enterprise Consoleのコマンド出力とログに次のようなエラーメッセージがあります。

failed on host: <ip_address> with message: Uri [http://localhost:9080/_ping] is un-pingable.

このエラーが発生した場合は、このセクションで示しているポートが他のクラスタノードで利用可能であることを確認します。 

Linuxを実行するクラスタノードの構成

Linuxマシンにデプロイする場合は、イベントサービスのクラスタの各ノードで、次のように構成を変更します。

  1. テキストエディタで /etc/sysctl.conf を開いて、以下の項目を追加します。

    vm.max_map_count=262144

  2. /etc/security/limits.conf で、オープンファイル記述子の上限を次のように引き上げます。

    <username_running_eventsservice>     soft    nofile          96000
<username_running_eventsservice>     hard    nofile          96000
    BASH

    username_running_eventsservice をイベントサービスのプロセスを実行するユーザー名に置き換えます。分析をユーザー appduser として実行している場合は、最初のエントリでその名前を使用します。

パスワード不要のSSHログインの構成

Linux デプロイでは、Enterprise Console を使用してイベントサービスクラスタをデプロイおよび管理します。 

Enterprise Console は、埋め込み以外のイベントサービスに対して、パスワード不要の SSH を使用して各クラスタマシンにアクセスできる必要があります。始める前に、以下に説明しているように鍵ベースの SSH アクセスを有効にします。

このセットアップでは、Enterprise Console でキーペアを生成し、クラスタノードで公開鍵を認証キーとして追加することも必要です。以下の手順では、この例のシナリオに合わせた構成手順を示しています。そのため、使用している環境に合わせて手順を調整する必要があります。  

AWS で EC2 インスタンスを使用している場合は、以下の手順に従って、EC2 ホストをプロビジョニングする場合に対応できるようにします。そのときに、PEM ファイルが要求され、その PEM ファイルの公開鍵がホストの authorized_keys にコピーされます。この場合は、これらの手順をスキップできます。  

ホストマシンで以下の手順に従います。

  1. Enterprise Consoleホストマシンにログインするか、またはデプロイの実行に使用するユーザーに切り替えます。

    su - $USER

  2. SSHアーティファクトのディレクトリを作成し（存在しない場合）、次のようにディレクトリで権限を設定する。

    mkdir -p ~/.ssh 
chmod 700 ~/.ssh

  3. そのディレクトリに移動します。

    cd .ssh

  4. 公開鍵と秘密鍵のPEMファイルをRSA形式で生成します。

    ssh-keygen -t rsa -b 2048 -v -m pem
  5. 要求されたときに、キーを保存するファイルの名前を入力します（例：ppd-analytics）。

  6. キーファイルの名前を変更して .pem 拡張子を追加します。

    mv appd-analytics appd-analytics.pem
    BASH

    このファイルのパスは、「イベントサービスクラスタのデプロイ」で説明しているように、Enterprise Console の構成ファイルの sshKeyFile 設定として後で構成します。 

  7. 公開鍵をクラスタマシンにコピーします。たとえば、次のように scp を使用して転送を実行できます。

    scp ~/.ssh/myserver.pub host1:/tmp
scp ~/.ssh/myserver.pub host2:/tmp
scp ~/.ssh/myserver.pub host3:/tmp
    BASH

    例のとおりの名前を使用している場合、myserver は appd-analytics です。
    初めて接続するときに、接続を確認して、そのクラスタマシンを known_hosts のリストに追加し、ユーザーのパスワードを入力する必要があることがあります。 

  8. 各クラスタノード（host1、host2、host3）で、ユーザーのホームディレクトリに.sshディレクトリがなければ作成し、コピーした公開鍵を認証キーとして追加します。

    cat /tmp/appd-analytics.pub &gt;&gt; .ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
    BASH

  9. ホストマシンから ssh を使用してクラスタノードへのログインを試すことによって、構成をテストします。

    ssh host1
    BASH

    接続できない場合は、クラスタマシンに openssh-server パッケージがインストールされていて、SSH 接続を受け入れるようにオペレーティングシステムのファイアウォールルールを変更していることを確認します。正常に接続できれば、Enterprise Consoleを使用してプラットフォームをデプロイできます。

次のエラーが発生した場合は、このセクションの手順に従って、パスワード不要の SSH 構成を再度チェックしてください。

Copying JRE to the remote host failed on host: 172.31.57.204 with message: Failed to upload file: java.net.ConnectException: Connection timed out