なぜこれがすべて必要なのか
Elasticsearchクラスターをニーズに合わせて（特に、ログ記録およびメインデータベースとして）使用したすべての人は、高負荷下での一貫性とスケーラビリティの問題に直面していました。 Elasticsearchの負荷を並列化する必要がある場合、通常、静的ソリューションはNGINX + Elasticsearchタイプに適用されました。 これにより、負荷を並列化できますが、見た目はあまり柔軟ではありません。 特に、ノード自体がクラスターから脱落する可能性があり、単純なhelcheckがすべてが正常であることを示しますが、実際にはノードが過負荷であり、クラスターから除外されていることを考慮する場合。 いずれにせよ、クラスターの状態に関するデータを直接手に入れたいと思います。単純なチェックだけでは満足しません。
それでは、バランスの構築を始めましょう。
どうやってやる
この場合、強力なCAT APIの一部であるCATノードAPIを使用します 。これは、Elasticsearchクラスターによってヘッダーを検索するためのツールです。
Gobetweenと組み込みのElasticsearchメカニズムのみを使用して、書き込み/読み取りCRUD （DATA）ノードとクラスター内のノードの任意の数/ステータスのバランスを取ります。
プリセット
必要なもの：
Elasticsearchクライアントノード：
以来特に仲介者が必要 マルチマスター構成では、要求自体が正しいマスターノード（アクティブマスター）にリダイレクトされるため、データノード検出の正しい操作のためにクラスター内のルーターになります。
クライアントノードのelasticsearch.confで、次のように記述します。
node.master: false node.data: false
残りの設定はクラスター内のノードの設定と同じです。
発見のためのスクリプト：
ここで、APIを要求し、ノードのリストを返すスクリプトを作成します。
discovery_elasticsearch.shと呼びましょう：
#!/bin/bash curl -sS -XGET 'http://PI_OF_YOUR_CLIENT_NODE:9200/_cat/nodes?v&h=ip,r=d' |sed '1d'|tr -d ' '|sed 's/$/:9200/'
スクリプト出力は次のようになります。
10.0.0.51:9200 10.0.0.55:9200 10.0.0.53:9200 10.0.0.52:9200 10.0.0.54:9200 ...
この場合、スクリプトは各ノードの重みを返しません。その場合、重みはバランサーによって自動的に同じ「1」に設定されます。
これですべての準備が整い、バランサー自体のセットアップを開始できます。
バランサーのセットアップ
インストール後、 EXECディスカバリとラウンドロビンバランシングアルゴリズムを使用してバランシングを設定します。
この例は非常に単純で、このタイプのバランスの可能性を説明するのに役立ちます。 スクリプトを展開して、ノード（cpu、ioなど）をロードすることにより、各ノードの重みを動的に生成できます。
バランサーの設定は次のようになります。
[logging] level = "warn" # "debug" | "info" | "warn" | "error" output = "stdout" # "stdout" | "stderr" | "/path/to/gobetween.log" [defaults] max_connections = 0 client_idle_timeout = "0" backend_idle_timeout = "0" backend_connection_timeout = "0" [servers.sample3] bind = "100.100.1.5:9200" protocol = "tcp" balance = "weight" [servers.sample3.discovery] kind = "exec" exec_command = ["/etc/gobetween/discovery_elasticsearch.sh"] interval="1m" timeout = "10s" [servers.sample3.healthcheck] kind = "ping" interval = "20s" timeout = "2s" fails = 3 passes = 3
したがって、elasticsearchクラスターで柔軟なバランスを構築するための「魚」ソリューションがあります。
「戦闘」状態では、重みを動的に決定するより複雑な構成があります。
また、本番環境では、モニタリングAPIとElasticsearch自体にも関連付けられた複雑なhelcheckスクリプトを使用します。
次の記事-jsonディスカバリー、windockerサービスのディスカバリーとバランシング、Windows swarmサービスのディスカバリーとバランシング、バランシング（Windows + linux）Doker環境。