【注意】Amazon Aurora(MySQL)でZero Downtime Patch実行時に不具合が発生するケースがある【AWS】

はじめに

先日、Amazon Aurora(MySQL)の必須アップデートの案内が来たのでアップデートの検証作業を実施しておりました。
Zero Downtime Patch(以下、ZDP)が実行され、ダウンタイム無しでアップデートが行われるはずが、不具合が発生してしまいました。

ググっても関連する情報が見つからなかったので、取り急ぎ分かっている情報について記録しておきます。

なお、対象のアップデートは下記のものになります。(Cluster Version 1.14)

Database Engine Updates 2017-08-07
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.20170807.html

ポイント(TL;DR)

重要なポイントは下記のとおりです。

Aurora(MySQL)に対し、DB Connection Poolを利用し、且つPrepared Statementを利用していると、Zero Downtime Patch実行時に不具合が発生する可能性が高い。
Aurora(MySQL)のアップデートを行う前に、アプリの構成・実装を調べた方が良い。

Zero Downtime Patch(ZDP)とは何か

Auroraを無停止(正確には5秒程度の遅延)でアップデートできる画期的な仕組みです。
アップデート処理中にも、クライアントからのDB接続は維持されます。

今回、Cluster Version 1.14へのアップデートとなりますが、本アップデートに関するドキュメントにも説明があります。
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.20170807.html

AuroraのCluster Version 1.10で初めて導入されたようです。
ZDPの内容について、下記ドキュメントにも記載があります。

Database Engine Updates 2016-12-14
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.20161214.html

こちらの記事も情報がまとまっていて参考になります。

Amazon Aurora のアップグレード
https://qiita.com/tonishy/items/542f7dd10cc43fd299ab

事象の内容

Aurora(MySQL)でClusterのアップデートが必要の旨の案内が来たため、AWS Management Consoleからアップデートを行いました。
AuroraのClusterアップデートは無事に完了しましたが、当該Auroraインスタンスを利用しているJavaアプリが軒並みエラーを吐き出し始めました。
その後Javaアプリを再起動し、復旧しました。

AWS Management Console上、WriterとなっているインスタンスのEventに下記のものが表示されました。
従って、Zero Downtime Patchが行われていたことは間違いありません。

The database was successfully patched with a zero downtime patch.

Javaアプリのログ上には、「Unknown prepared statement handler」といったエラーが多数出力されておりました。

事象の原因

当該JavaアプリはJDBC Connection Poolを利用し、DBとの接続を維持する構成になっています。
また、Prepared Statementを利用する実装になっております。

ZDP実行時、MySQLのクライアント(i.e. Javaアプリ)からの接続は維持されるようですが、Prepared Statementは維持されないことが原因のようでした。
時系列的に整理すると、下記のような状況になっていたようです。

  1. Javaアプリ起動時、Auroraに対して幾つかJDBC接続を確立する
  2. リクエストに応じて、JavaアプリからAuroraにクエリを発行する。この際、Prepareを発行してPrepared Statementを作る。
    Javaアプリは、同一のリクエストに対してはPrepared Statementを再利用する。
  3. AuroraのアップデートをZDPで行う。この際、JavaアプリからのJDBC接続は維持されるが、Prepared Statementは全てクリアされる。
  4. Javaアプリに対し、項番2と同様のリクエストを行う。Javaアプリは、コンパイル済みのPrepared Statementが存在しているという認識のまま、これを再利用しようとし、エラーとなる。

同一のアプリに対し、Prepared Statementを利用するもの/しないものを用意してAuroraのアップデートを実施しました。
結果、前者はエラーが発生し、後者はエラーが発生しませんでした。

なお上記の挙動は、独自に調査・検証したものとなります。
現在、AWSの公式見解・ドキュメント等の情報は見つけられておりません。
# 一応、Database Engine Updates 2016-12-14には以下の記載がありますが、これが該当するかどうかは不明です。
# Note that temporary data like that in the performance schema is reset during the upgrade process.

2017/9/26にAWSサポートへの問い合わせを行っておりますが、2017/10/19現在、回答待ちの状況です。

確認した環境・構成

上記事象は、下記構成のJavaアプリで確認しました。

  • Java 8 (Oracle JDK)
  • spring-boot-1.4.0.RELEASE
  • mybatis-spring-boot-starter 1.1.1
  • mariadb-java-client 1.5.5

併せてMyBatisGeneratorも利用しています。
特別な理由がない限り、JavaアプリからはMyBatisGeneratorで生成されたMapperとClassを利用しています。

デフォルトでは、MyBatisGeneratorではPrepared Statementを利用するMapperを生成するようです。

回避策

回避策は概ね以下の3通りになると思います。

1.Prepared Statementを利用しないよう、アプリを変更する。

ソースコード/ORマッパーの改修・設定変更を行い、Prepared Statementを利用しないようにする方法です。
おそらく、この対応は難しいケースがほとんどだと思います。

2.MySQL接続ドライバの設定で、Prepared Statementを利用しないよう変更する。 

今回のケースでは、MariaDB Connector/Jを利用しており、オプションを指定することでPrepared Statementを利用しないように変更することができました。

useServerPrepStmtsオプションをfalseにすることで実現可能です。
ちなみに、1.6.0以降のバージョンはデフォルトでfalseになっているようですので、これ以降のバージョンを利用してる場合は、本件の影響を受けません。

About MariaDB Connector/J -> Optional URL parameters -> Essential options
https://mariadb.com/kb/en/library/about-mariadb-connector-j/

3.ZDPではない、通常のアップデートを実施する

Auroraインスタンスの再起動を伴う、通常のアップデートを実行することで、本件事象を回避することが可能と考えられます(※未検証)
20~30秒程度のダウンタイムが発生します。

下記に、ZDPにならないケースについて記載がありますので、このどれかを満たせば通常のアップデートになると推測できます(※未検証)

Database Engine Updates 2017-08-07 -> Zero-Downtime Patching
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.20170807.html

  • Long-running queries are in progress
  • Open long-running transactions exist
  • Binary logging is enabled
  • Binary log replication is running
  • Pending parameter changes exist
  • Temporary tables are in use
  • Table locks are in use
  • Open SSL connections exist

まとめ

DBへのConnection Poolを利用し、且つPrepared Statementを利用するようアプリを実装していると、不具合が発生する可能性が高いです。

経験的な感覚ですが、JavaアプリはConnection Poolを利用しているケースが多いかと思います。
Aurora(MySQL)を利用している場合は、チェックをした方が良いかと思います。

検証作業について

古いClusterバージョンのAuroraインスタンスを作ることはできません。AWSサポートにも聞いてみましたが無理なようでした。
従って、運良く過去に構築した古いAuroraインスタンスが存在していれば検証は可能ですが、それ以外のケースでは検証手段がありません。

続きを読む

AWSの用語と解説

AWS(Amazon Web Services)General_AWScloud.png

インフラ系のクラウドサービスを提供しているAWSは2006年3月から始まり、現在10周年。
アメリカでは政府機関が使っているほど高いセキュリティ

サービスや機能は800個以上あり、もはや中の人も何がいつリリースされたかわからないらしい

Region(リージョン)

AWSは世界中のデータセンターのサーバーで実行されており、サービスを開始する時はリージョンを選択する
リージョンは以下の通り

リージョン
米国東部(バージニア北部) us-east-1
米国西部(オレゴン) us-west-2
米国西部(北カリフォルニア) us-west-1
欧州(アイルランド) eu-west-1
欧州(フランクフルト) eu-central-1
アジアパシフィック (シンガポール) ap-southeast-1
アジアパシフィック(東京) ap-northeast-1
アジアパシフィック (ソウル) ap-northeast-2
アジアパシフィック(シドニー) ap-southeast-2
南米 (サンパウロ) sa-east-1
中国(北京) cn-north-1

アジアパシフィックを選んでおけば問題ないが、特定のリージョンにしかないマイナーなサービスがあったりするので注意が必要

AZ(アベイラビリティゾーン)

リージョン内のデータセンターのことで、
東京リージョンだと ap-northeast-1a ap-northeast-1b ap-northeast-1c のAZがある

EC2(Elastic Compute Cloud) Compute_AmazonEC2.png

仮想サーバ

ブラウザ上で何回かクリックするだけで、簡単にインスタンスが立ち上がる
利用料金はインスタンスタイプや性能にもよるが、最低スペックで 744円/月 くらい?

RDS(Relational Database Service) Database_AmazonRDS.png

リレーショナルデータベース

Amazon Aurora  Oracle  Microsoft SQL Server  PostgreSQL  MySQL  MariaDB
からデータベースエンジンを選択可能

中でも MySQL5.6互換がある Amazon Auroraは1分あたり600万回のインサート、3000万件のセレクトが可能らしい。
下記のサイトによれば、DB性能向上が期待できそう?
http://dev.classmethod.jp/cloud/aws/wordpressdb-migrate-aurora/

Redshift  Database_AmazonRedshift.png

データウェアハウス

2TBから最大1.6PBまでスケール可能でログなどのビッグデータを保存するのによく使用される
カラムナー(列指向)と呼ばれるデータ格納方式が特徴

Redshift は、PostgreSQL 8.0.2 に基づいている。
なので、PostgreSQL 9系で追加されたクエリが使えなかったりする。

ElastiCache  Database_AmazonElasticCache.png

KVSのキャッシュサービス

Memcached・Redis から選べる
Elastic Cacheではなく ElastiCache(エラスティキャッシュ) という名前なので注意が必要

S3(Simple Storage Service) Storage_AmazonS3_bucket.png

オンラインストレージサービス

bucket(フォルダ)
object(ファイル)
という名称がある

1B ~ 5TBまでのオブジェクトを書き込み・読み込み・削除が可能
バケットに容量制限はない

・SLAは99.99%
・静的webサイトのホスティングが可能

CloudFront NetworkingContentDelivery_AmazonCloudFront.png

コンテンツデリバリネットワーク(CDN)

CDNはAkamaiなどがあるが、それに比べると割高

VPC(Virtual Private Cloud) General_virtualprivatecloud.png

仮想プライベートクラウド

Amazon VPCは、AWS上に利用者が占有可能な仮想プライベートネットワークを構築するためのサービス。
このVPCの内部にIPサブネットを作成し、その中に仮想サーバーの「EC2」やデータベースサーバーの「RDS」といったAWSのリソースを配置する。

・ユーザ側で使いたいIP空間(VPC) を作成
・VPCにユーザがサブネットを切ることができる
・サブネット単位で アクセスリストが設定できる

Route53 NetworkingContentDelivery_AmazonRoute53.png

DNSサーバ

DNSは通常マスターとスレーブ構成にすることが多く、2台で構成する場合が多いが
Route53では、4つのネームサーバーで構成され、全世界にDNSサーバーを設置しているので高可用性である
米国:20   欧州:16  アジア:12  オーストラリア:2   南米:2

・SLA100% (ほんとに?)
・DNSラウンドロビンでの負荷分散が可能
料金はかなり安い。

ホストゾーン
0.50 USD(ホストゾーンごと)/月 - 最初の25のホストゾーン
0.10 USD(ホストゾーンごと)/月 - それ以上のホストゾーン

標準的クエリ
0.400 USD(100 万クエリごと) - 最初の 10 億クエリ/月
0.200 USD(100 万クエリごと) - 10 億クエリ以上/月

1つのホストゾーンで、10億クエリ行かなければ、月1ドルかからない。

IAM(Identity and Access Management) SecurityIdentityCompliance_IAM.png

ユーザーの権限を管理できるサービス

ポリシーと呼ばれる権限をユーザーにアタッチすることで、該当ユーザーの操作できる範囲を限ることができる

ポリシーは自由に設定可能で、管理者が細かく設定可能で
例えば、とある管理者が s3-readonly-userを作成し S3の閲覧だけを許可するポリシーを作成してアタッチ。など

随時追加中…

続きを読む

AWSでElastic Stack

はじめに

Elastic Stackについて触る機会があったので、メモを残します。
2017/09月時点の作業です。

Elastic Stackはログの解析・可視化等ができるものなのですが、今回その説明は省かせてもらいますので、公式等をご確認下さい。

作りたい構成

AWSのVPC環境にElasticsearchを仮想マシン3台にインストールしクラスタ化します。
その後、どれか一台にkibanaをインストールしてクラスタの状態をブラウザから確認します。

今回作りたい構成は以下のようなイメージです。
ES01.jpeg

AWS側の設定について

AWS側の設定は以下のようにしました。

VPC:192.100.0.0/24
VPC Subnet:192.100.0.0/27
仮想マシン:Amazon Linux
仮想マシンプラン:m4.large
仮想マシン台数:3台
srv1:192.100.0.4/EIP付き
srv2:192.100.0.5/EIP付き
srv3:192.100.0.6/EIP付き

セキュリティグループ
フルオープンはセキュリティ的に問題があるのである程度絞っています。
・仮想マシン操作用
SSH (22) TCP (6) 22 [sshアクセスするIPアドレス]
・Elasticsearchへのアクセス用
カスタム TCP ルール TCP (6) 9200 [ElasticsearchへアクセスするIPアドレス]
・Elasticsearchの内部通信用
カスタム TCP ルール TCP (6) 9300 192.100.0.0/27
・kibanaへのアクセス用
カスタム TCP ルール TCP (6) 5601 [kibanaへアクセスするIPアドレス]

それでは作ります。

構築作業

1.事前準備

1.1 java8(openJDK)のインストール(仮想マシン3台共通作業)

Amazon Linuxでインストールされているjavaのバージョンは1.7.0がインストールされていますので、1.7.0を削除し、1.8.0をインストールします。
デバッグは使うことは無いと思いますがお作法として入れておきます。

# yum -y remove java-1.7.0-openjdk
# yum -y install java-1.8.0-openjdk-devel
# yum -y install java-1.8.0-openjdk-debuginfo --enablerepo=*debug*

1.2 ElasticsearchをyumでインストールできるようにGPGキーのインポートと、リポジトリの作成(仮想マシン3台共通作業)

# rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
# vi /etc/yum.repos.d/elastic.repo
[elasticsearch-5.x]
name=Elasticsearch repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

2.Elasticsearchのインストールと起動

Elasticsearchをクラスターモードで起動します。

2-1.Elasticsearchのインストール(仮想マシン3台共通作業)

インストールはありがたいことにとても簡単です。

# yum install -y elasticsearch

インストール後のElasticsearchのディレクトリ状況は以下のような感じになっていました。

/var/run/elasticsearch
/var/log/elasticsearch
/var/lib/elasticsearch
/var/lib/yum/yumdb/e/e7a7bc22f961d4dd3889c0cac8f668512fe3d2c0-elasticsearch-5.6.2-1-noarch
/var/lib/yum/repos/x86_64/latest/elasticsearch-5.x
/var/cache/yum/x86_64/latest/elasticsearch-5.x
/etc/elasticsearch
/etc/elasticsearch/elasticsearch.yml
/etc/sysconfig/elasticsearch
/etc/rc.d/init.d/elasticsearch
/usr/lib/systemd/system/elasticsearch.service
/usr/lib/sysctl.d/elasticsearch.conf
/usr/lib/tmpfiles.d/elasticsearch.conf
/usr/share/elasticsearch
/usr/share/elasticsearch/lib/elasticsearch-5.6.2.jar
/usr/share/elasticsearch/modules/reindex/elasticsearch-rest-client-5.6.2.jar
/usr/share/elasticsearch/bin/elasticsearch
/usr/share/elasticsearch/bin/elasticsearch.in.sh
/usr/share/elasticsearch/bin/elasticsearch-keystore
/usr/share/elasticsearch/bin/elasticsearch-systemd-pre-exec
/usr/share/elasticsearch/bin/elasticsearch-translog
/usr/share/elasticsearch/bin/elasticsearch-plugin

2.2.elasticsearch.ymlの設定(仮想マシン毎の設定)

elasticsearch.ymlはデフォルトの設定は全てコメント化されていますので、
追加したい内容を追記すればOKでした。
追加する内容は以下です。

cluster.name [cluster-name]:クラスタ名。入力しないとデフォルトの名前になる。
node.name [node-name]:elasticsearchノードの名前。自身の識別に利用する。
discovery.zen.ping.unicast.hosts ["IPADDRESS","IPADDRESS","IPADDRESS"]:クラスタを構成する相手ホスト名をユニキャストで検索する。(3台構成なので3つ書く)
network.host: 0.0.0.0:通信許可設定。通信の制御はAWSのセキュリティグループで行う為、こちらは全許可で記載します。

上記の設定を各サーバのelasticsearch.ymlに記載します。

srv1
# vi /etc/elasticsearch/elasticsearch.yml
cluster.name: my-cluster
node.name: node001
network.host: 0.0.0.0
discovery.zen.ping.unicast.hosts: ["192.100.0.4","192.100.0.5","192.100.0.6"]
srv2
# vi /etc/elasticsearch/elasticsearch.yml
cluster.name: my-cluster
node.name: node002
network.host: 0.0.0.0
discovery.zen.ping.unicast.hosts: ["192.100.0.4","192.100.0.5","192.100.0.6"]
srv3
# vi /etc/elasticsearch/elasticsearch.yml
cluster.name: my-cluster
node.name: node003
network.host: 0.0.0.0
discovery.zen.ping.unicast.hosts: ["192.100.0.4","192.100.0.5","192.100.0.6"]

2.3.Elasticsearchの起動(仮想マシン3台共通作業)

各サーバのElasticsearchサービスを起動します。この時同じタイミングで起動コマンドを打つと、ノードの認識がうまくいかない場合があります。サービスの起動完了を待ちながら1台ずつ起動します。

# /etc/init.d/elasticsearch start

2.4.クラスタ状態の確認

仮想マシン3台の内、どのサーバでも構いませんので以下コマンドを発行し、ノードの状態を確認します。

# curl localhost:9200/_cat/nodes
192.100.0.5 8 43 0 0.00 0.00 0.00 mdi - node002
192.100.0.6 7 43 0 0.00 0.02 0.00 mdi - node003
192.100.0.4 8 44 0 0.00 0.01 0.04 mdi * node001
※クラスタ化ができていない場合は自分のノード名しか表示されません。

クラスタ化がとても簡単に成功しました。
他にもログを確認することでノードが追加されたか確認することができます。
以下のようにログが出力されます。

/var/log/elasticsearch/my-cluster.log
[2017-xx-xxTxx:xx:xx,043][INFO ][o.e.g.GatewayService     ] [node001] recovered [0] indices into cluster_state
[2017-xx-xxTxx:xx:xx,815][INFO ][o.e.c.s.ClusterService   ] [node001] added {{node002}{UTINV4wuTd6UfgLByoG4gQ}{E5ptnPZ0SG-xc629ayXK_Q}{192.100.0.5}{192.100.0.5:9300},}, 
reason: zen-disco-node-join[{node002}{UTINV4wuTd6UfgLByoG4gQ}{E5ptnPZ0SG-xc629ayXK_Q}{192.100.0.5}{192.100.0.5:9300}]

2.5.自動起動設定(仮想マシン3台共通作業)

無事クラスタ化ができましたので、Elasticsearchサービスを自動起動するよう設定しておきます。

# chkconfig --add elasticsearch
# chkconfig --list elasticsearch
elasticsearch   0:off   1:off   2:on    3:on    4:on    5:on    6:off

3.Kibanaのインストールとx-packのインストール

次に可視化ツールのKibanaをインストールします。
また、クラスタの状態をモニタリングする為、x-packを導入します。
作業はsrv1で実施しました。

3.1.kibanaのインストール

Kibanaもインストールはとても簡単です。

# yum -y install kibana

3.2.kibana.ymlの編集

kibanaは5.0.0からリモートホストからのアクセスを受け入れない為、リモートホストからの接続が必要な場合は設定ファイル「/etc/kibana/kibana.yml」の「server.host」の修正が必要です。今回はブラウザから確認したいので、修正を行いました。

# vi /etc/kibana/kibana.yml
server.host: "0.0.0.0"

kibana.ymlもデフォルトの設定は全てコメント化されていますので、
追加したい内容を追記すればOKでした。

3.3.Kibanaの起動

# /etc/init.d/kibana start

3.4.kibanaへのアクセス

ブラウザから1号機のURLにアクセスしてみます。

http://[srv1のEIP]/5601

とりあえずはページが表示されれば問題ありません。本来の目的にはまだ届いていない為、画像は割愛します。

3.5.自動起動設定

kibanaも自動起動するようにしておきます。

# chkconfig --add kibana
# chkconfig --list kibana
kibana          0:off   1:off   2:on    3:on    4:on    5:on    6:off

3.6.x-packのインストール(仮想マシン3台共通作業)

今回の目的である、kibanaでクラスタの状態を確認する為にx-packプラグインをインストールしていきます。まずはelasticsearch用のx-packをインストールします。

kibanaを停止後、x-packインストールします。

# /etc/init.d/kibana stop
# /usr/share/elasticsearch/bin/elasticsearch-plugin install x-pack

途中y(yes)の入力が必要な為、全文を乗せておきます。

-> Downloading x-pack from elastic
[=================================================] 100%??
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@     WARNING: plugin requires additional permissions     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
* java.io.FilePermission \.pipe* read,write
* java.lang.RuntimePermission accessClassInPackage.com.sun.activation.registries
* java.lang.RuntimePermission getClassLoader
* java.lang.RuntimePermission setContextClassLoader
* java.lang.RuntimePermission setFactory
* java.security.SecurityPermission createPolicy.JavaPolicy
* java.security.SecurityPermission getPolicy
* java.security.SecurityPermission putProviderProperty.BC
* java.security.SecurityPermission setPolicy
* java.util.PropertyPermission * read,write
* java.util.PropertyPermission sun.nio.ch.bugLevel write
* javax.net.ssl.SSLPermission setHostnameVerifier
See http://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html
for descriptions of what these permissions allow and the associated risks.

Continue with installation? [y/N]y
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@        WARNING: plugin forks a native controller        @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
This plugin launches a native controller that is not subject to the Java
security manager nor to system call filters.

Continue with installation? [y/N]y
-> Installed x-pack

3.7.elasticsearchのx-packのsecurityを無効化する。(仮想マシン3台共通作業)

x-packには様々な機能が付属しており、securityが有効だとちゃんと設定を行わないとKibanaが起動できません。今回の目的には関係が無い為、securityを無効化することで回避します。

# vi /etc/elasticsearch/elasticsearch.yml
xpack.security.enabled: false
※上記を最下行に追記

追記後Elasticsearchを再起動して反映
# /etc/init.d/elasticsearch restart

3.8.kibanaのx-packのインストール

Kibana用x-packをインストールします。

# /usr/share/kibana/bin/kibana-plugin install x-pack
Attempting to transfer from x-pack
Attempting to transfer from https://artifacts.elastic.co/downloads/kibana-plugins/x-pack/x-pack-5.6.2.zip
Transferring 119528829 bytes....................
Transfer complete
Retrieving metadata from plugin archive
Extracting plugin archive
Extraction complete
Optimizing and caching browser bundles...
Plugin installation complete

途中止まっちゃったかな?と思いたくなるような反応が無い時間がありましたが、気にせず放置しておけば大丈夫です。

3.9.Kibanaの起動

設定が完了しましたのでKibanaを起動します。

# /etc/init.d/kibana start

設定後のプラグインの状態とライセンスの状態がどうなっているかメモしておきます。
コマンドは3台のいずれかのサーバで実行すれば確認できます。

プラグイン状態
# curl -XGET -u elastic:changeme 'http://localhost:9200/_cat/plugins?v'
name    component         version
node003 analysis-kuromoji 5.6.2
node003 x-pack            5.6.2
node002 analysis-kuromoji 5.6.2
node002 x-pack            5.6.2
node001 analysis-kuromoji 5.6.2
node001 x-pack            5.6.2
ライセンス状態
# curl -XGET -u elastic:changeme 'http://localhost:9200/_xpack/license'
{
  "license" : {
    "status" : "active",
    "uid" : "7977deb4-d253-4ef4-8fd1-bf01e1d86315",
    "type" : "trial",
    "issue_date" : "2017-xx-xxTxx:xx:xx.537Z",
    "issue_date_in_millis" : 1506590395537,
    "expiry_date" : "2017-xx-xxTxx:xx:xx.537Z",
    "expiry_date_in_millis" : 1509182395537,
    "max_nodes" : 1000,
    "issued_to" : "my-cluster",
    "issuer" : "elasticsearch",
    "start_date_in_millis" : -1
  }
}

4.kibanaからクラスタ状態を確認

それでは最後にkibanaの画面を確認します。

ブラウザから1号機のURLにアクセスします。
http://[srv1のEIP]:5601

表示された画面の左ペインにある、Monitoringを選択します。
es-monitoring.png

遷移後の画面の真ん中にある、Noedsを選択します。
es-monitoring2.png

Kibanaの画面上からクラスタの状態が確認できました。
es-monitoring3.png

Kibanaの画面上から確認できるようになると、すごくできた感があります。
次回は肝心のログデータの取り込みなんかをメモしたいと思います。

続きを読む