Ansibleを使用して本番Elasticsearchクラスターをセットアップする方法
序章
このチュートリアルでは、構成管理ツールであるAnsibleを使用して、クラウドサーバー環境のUbuntu14.04またはCentOS7に本番Elasticsearchクラスターをインストールする方法を示します。 Ansible and Tinc VPNを使用してサーバーインフラストラクチャを保護する方法チュートリアルに基づいて、Elasticsearchノードが独自のネットワーク外のコンピューターから保護されるようにします。
Elasticsearchは、データのリアルタイム分散検索と分析に使用される人気のあるオープンソース検索サーバーです。 開発以外の目的で使用する場合、Elasticsearchは、最高のパフォーマンス、安定性、およびスケーラビリティーを実現するために、クラスターとして複数のサーバーにデプロイする必要があります。
前提条件
Elasticsearchクラスターには少なくとも3つのマスター適格ノードが必要であるため、このチュートリアルを完了するには、プライベートネットワークを備えた少なくとも3つのUbuntu14.04またはCentOS7サーバーが必要です。 専用のマスターノードとデータノードが必要な場合は、マスターノード用に少なくとも3台のサーバーと、データノード用に追加のサーバーが必要になります。 また、デフォルトのElasticsearchヒープサイズである2 GBを使用する場合は、サーバーに少なくとも4GBのメモリを割り当てる必要があることにも注意してください。
サーバーを取得したら、次のチュートリアルでメッシュVPNを使用するようにサーバーを構成します:AnsibleおよびTincVPNを使用してサーバーインフラストラクチャを保護する方法。 各サーバーに一意のAnsibleインベントリホスト名があることを確認してください。
DigitalOcean Private Networkingなどのプライベートネットワークを使用している場合、サーバーは同じ地域内の同じアカウントまたはチームの他のサーバーと安全に通信できます。 Elasticsearchを使用する場合、HTTPインターフェースにセキュリティが組み込まれていないため、これは特に重要です。
仮定
上記のリンク先のチュートリアルで説明されているように、Elasticsearchノードとして使用するすべてのサーバーに「tun0」という名前のVPNインターフェイスがあると想定します。 そうでない場合で、ESノードを別のインターフェイスでリッスンさせたい場合は、Playbookのsite.ymlファイルに適切な変更を加える必要があります。
また、Playbookは、ローカルコンピュータのホームディレクトリにあるansible-tincというディレクトリにあると想定します。
ansible-elasticsearchPlaybookをダウンロードする
Elasticは、Elasticsearchクラスターを簡単にセットアップするために使用できるAnsibleの役割を提供します。 これを使用するには、ansible-tincプレイブックに追加し、いくつかのホストグループを定義して、グループに適切な役割を割り当てる必要があります。 繰り返しになりますが、前提条件のVPNチュートリアルをまだ実行していない場合は、ここにあります。
まず、TincAnsiblePlaybookが置かれているディレクトリに移動します。
cd ~/ansible-tinc
次に、ElasticのGitHubアカウントで利用できるansible-elasticsearchの役割を、Playbookのrolesディレクトリに複製します。
cd roles git clone https://github.com/elastic/ansible-elasticsearch
ロールの名前を「elasticsearch」に変更します。
mv ansible-elasticsearch elasticsearch
site.ymlを更新します
マスターPlaybookファイルsite.ymlを編集して、3つの異なるElasticsearchロールを3つの異なるAnsibleホストグループにマップしてみましょう。 これにより、適切なグループにホストを追加するだけで、専用のマスター、専用データ、およびマスター適格/データElasticsearchノードを作成できます。
AnsiblePlaybookのディレクトリに戻ります。
cd ~/ansible-playbook
お気に入りのエディターで、elasticsearch.ymlという名前の新しいファイルを編集します。 viを使用します:
vi site.yml
Elasticsearch専用のマスターロールをグループにマッピングする
ファイルの下部で、次の行を追加して、専用マスターelasticsearchの役割をelasticsearch_master_nodesグループにマップします。
site.yml —専用のマスターノード
- hosts: elasticsearch_master_nodes
roles:
- { role: elasticsearch, es_instance_name: "node1", es_config: { discovery.zen.ping.unicast.hosts: "node01, node02, node03", network.host: "_tun0_, _local_", cluster.name: "production", discovery.zen.ping.multicast.enabled: false, http.port: 9200, transport.tcp.port: 9300, node.data: false, node.master: true, bootstrap.mlockall: true } }
vars:
es_major_version: "2.x"
es_version: "2.2.1"
es_heap_size: "2g"
es_cluster_name: "production"
この役割は、node.master: trueおよびnode.data: falseの値でノードを構成するため、専用のマスターノードを作成します。
discovery.zen.ping.unicast.hosts変数で強調表示されているホスト名を更新して、いくつかのElasticsearchサーバーのAnsibleインベントリホスト名(またはVPN IPアドレス)と一致させてください。 これにより、これらのノードがElasticsearchクラスターを検出できるようになります。 この例では、node01、node02、およびnode03を使用しています。これらは、前提条件のVPNチュートリアルで使用されたホスト名であるためです。 また、VPNインターフェースの名前が「tun0」以外の場合は、それに応じてnetwork.host変数を更新します。
別のバージョンのElasticsearchを使用する場合は、es_versionを更新してください。 古いバージョンはnetwork.host変数のコンマ区切りリストを受け入れないため、この構成は2.2より前のバージョンでは機能しないことに注意してください。
es_heap_sizeを、専用マスターサーバーの空きメモリの約半分の値に更新します。 たとえば、サーバーに約4 GBの空き容量がある場合は、ヒープサイズを「2g」に設定します。
これで、elasticsearch_master_nodes Ansibleホストグループに属するすべてのホストが、専用のマスターElasticsearchノードとして構成されます。
Elasticsearchマスター/データロールをグループにマッピングする
ファイルの下部で、次の行を追加して、マスター適格およびデータelasticsearchロールをelasticsearch_master_data_nodesグループにマップします。
site.yml —マスター適格/データノード
- hosts: elasticsearch_master_data_nodes
roles:
- { role: elasticsearch, es_instance_name: "node1", es_config: { discovery.zen.ping.unicast.hosts: "node01, node02, node03", network.host: "_tun0_, _local_", cluster.name: "production", discovery.zen.ping.multicast.enabled: false, http.port: 9200, transport.tcp.port: 9300, node.data: true, node.master: true, bootstrap.mlockall: true } }
vars:
es_major_version: "2.x"
es_version: "2.2.1"
es_heap_size: "2g"
es_cluster_name: "production"
この役割は、node.master: trueおよびnode.data: trueの値でノードを構成するため、マスター適格であるデータノードを作成します。
discovery.zen.ping.unicast.hosts変数で強調表示されているホスト名を更新して、いくつかのElasticsearchサーバーのAnsibleインベントリホスト名(またはVPN IPアドレス)と一致させてください。 また、VPNインターフェースの名前が「tun0」以外の場合は、それに応じてnetwork.host変数を更新します。
es_versionを、専用のマスターロールに使用したのと同じ値に設定します。
es_heap_sizeを、マスター適格/データサーバーの空きメモリの約半分の値に更新します。
これで、elasticsearch_master_data_nodes Ansibleホストグループに属するすべてのホストが、マスター適格のデータノードとして構成されます。
Elasticsearch専用データの役割をグループにマッピングする
ファイルの下部で、次の行を追加して、専用データelasticsearchの役割をelasticsearch_data_nodesグループにマップします。
site.yml —専用データノード
- hosts: elasticsearch_data_nodes
roles:
- { role: elasticsearch, es_instance_name: "node1", es_config: { discovery.zen.ping.unicast.hosts: "node01, node02, node03", network.host: "_tun0_, _local_", cluster.name: "production", discovery.zen.ping.multicast.enabled: false, http.port: 9200, transport.tcp.port: 9300, node.data: true, node.master: false, bootstrap.mlockall: true } }
vars:
es_major_version: "2.x"
es_version: "2.2.1"
es_heap_size: "2g"
es_cluster_name: "production"
この役割は、node.master: falseおよびnode.data: trueの値でノードを構成するため、専用のデータノードを作成します。
discovery.zen.ping.unicast.hosts変数で強調表示されているホスト名を更新して、いくつかのElasticsearchサーバーのAnsibleインベントリホスト名(またはVPN IPアドレス)と一致させてください。 また、VPNインターフェースの名前が「tun0」以外の場合は、それに応じてnetwork.host変数を更新します。
es_versionを前の役割で使用したのと同じ値に設定します。
es_heap_sizeを、専用データサーバーの空きメモリの約半分の値に更新します。
これで、elasticsearch_data_nodes Ansibleホストグループに属するすべてのホストが、専用データElasticsearchノードとして構成されます。
保存して終了
3つの役割を定義し、それらをホストグループにマップしたので、site.ymlを保存して終了できます。
後でElasticsearchの役割とホストグループのマッピングを自由に追加してください。
ホストインベントリファイルを更新する
新しいElasticsearchの役割がホストグループにマッピングされたので、適切なホストグループにホストを追加するだけで、さまざまなタイプのElasticsearchノードを作成できます。
Ansiblehostsインベントリファイルを編集します。
vi hosts
前提条件のチュートリアルに従った場合、ファイルは次のようになります(サーバーのホスト名とIPアドレスを含む)。
Ansibleホストインベントリ—元のファイル
[vpn] node01 vpn_ip=10.0.0.1 ansible_host=45.55.41.106 node02 vpn_ip=10.0.0.2 ansible_host=159.203.104.93 node03 vpn_ip=10.0.0.3 ansible_host=159.203.104.127 node04 vpn_ip=10.0.0.4 ansible_host=159.203.104.129 [removevpn]
次に、site.ymlで定義したマッピングに対応する3つのグループを追加します。
Ansibleホストインベントリ—Elasticsearchグループ
[elasticsearch_master_nodes] [elasticsearch_master_data_nodes] [elasticsearch_data_nodes]
次に、クラスターで構成するElasticsearchノードのタイプに応じて、Elasticsearchホストを新しいホストグループに分散します。 たとえば、3つの専用マスターノードと1つの専用データノードが必要な場合、インベントリファイルは次のようになります。
Ansibleホストインベントリ—完全な例
[vpn] node01 vpn_ip=10.0.0.1 ansible_host=45.55.41.106 node02 vpn_ip=10.0.0.2 ansible_host=159.203.104.93 node03 vpn_ip=10.0.0.3 ansible_host=159.203.104.127 node04 vpn_ip=10.0.0.4 ansible_host=159.203.104.129 [removevpn] [elasticsearch_master_nodes] node01 node02 node03 [elasticsearch_master_data_nodes] [elasticsearch_data_nodes] node04
注:すべてのノードがVPNを介して相互に通信できるように、各Elasticsearchノードも[vpn]ホストグループで定義する必要があります。 また、Elasticsearchクラスターに接続する必要のあるサーバーは、[vpn]ホストグループでも定義する必要があります。
インベントリファイルに目的のElasticsearch(およびVPN)セットアップが反映されたら、保存して終了します。
Elasticsearchクラスターを作成する
site.ymlとhostsがセットアップされたので、Playbookを実行してElasticsearchクラスターを作成する準備が整いました。
次のコマンドでPlaybookを実行します。
ansible-playbook site.yml
Playbookの実行が完了すると、Elasticsearchクラスターが稼働しているはずです。 次のステップは、すべてが正しく機能していることを確認することです。
Elasticsearchクラスターのステータスを確認する
いずれかのElasticsearchサーバーから、次のコマンドを実行してクラスターの状態を出力します。
curl -XGET 'http://localhost:9200/_cluster/state?pretty'
「production」という名前のクラスターが実行されていることを示す出力が表示されます。 また、構成したすべてのノードがメンバーであることを示す必要があります。
Cluster State:{
"cluster_name" : "production",
"version" : 8,
"state_uuid" : "SgTyn0vNTTu2rdKPrc6tkQ",
"master_node" : "OzqMzte9RYWSXS6OkGhveA",
"blocks" : { },
"nodes" : {
"OzqMzte9RYWSXS6OkGhveA" : {
"name" : "node02-node1",
"transport_address" : "10.0.0.2:9300",
"attributes" : {
"data" : "false",
"master" : "true"
}
},
"7bohaaYVTeeOHvSgBFp-2g" : {
"name" : "node04-node1",
"transport_address" : "10.0.0.4:9300",
"attributes" : {
"master" : "false"
}
},
"cBat9IgPQwKU_DPF8L3Y1g" : {
"name" : "node03-node1",
"transport_address" : "10.0.0.3:9300",
"attributes" : {
"master" : "false"
}
},
...
これに似た出力が表示された場合は、Elasticsearchクラスターが実行されています。 一部のノードが欠落している場合は、Ansible hostsインベントリを確認して、ホストグループが適切に定義されていることを確認してください。
トラブルシューティング
curl: (7) Failed to connect to localhost port 9200: Connection refusedを取得した場合、Elasticsearchはそのサーバーで実行されていません。 これは通常、誤ったnetwork.hostまたはdiscovery.zen.ping.unicast.hostsエントリなど、site.ymlファイルのElasticsearch構成エラーが原因で発生します。 そのファイルを確認するだけでなく、サーバー上のElasticsearchログ(/var/log/elasticsearch/node01-node1/production.log)で手がかりを確認してください。
このチュートリアルに従って作成されたPlaybookの例を確認するには、このGitHubリポジトリを確認してください。 これは、動作中のsite.ymlおよびhostsファイルがどのように見えるかを確認するのに役立ちます。
結論
Elasticsearchクラスターは正常な状態で実行され、いくつかの基本的な最適化で構成されている必要があります。
Elasticsearchには、インデックス、シャード、レプリケーション設定など、ここでは取り上げられていない他の多くの構成オプションがあります。 クラスターがニーズを満たすように構成されていることを確認するために、公式ドキュメントとともに後で構成を再検討することをお勧めします。