VMインフラストラクチャで実行されているElasticsearch*インスタンスは、独自の課題を提示することができます。 この記事では、異なるVMソフトウェアで見られるかもしれない共通の問題について説明しています。

ブイエムウェア

vSphere は非常に広く展開されている VM インフラストラクチャです。 VMware vSphere ESXi を実行する物理ホスト、vCenter を実行する管理システム、バックアップ、冗長データセンターへの VM のコピーの出荷、仮想インフラストラクチャ上でのソフトウェアの展開、物理マシンの仮想インスタンスへの変換などを処理する膨大な数の補助パッケージで構成されています。 すべてのストレージとネットワーク インフラストラクチャを vSphere 管理パッケージで管理できるので、データセンターの管理には非常に便利です。 管理者は、物理ノードにストレージとネットワークを割り当て、CPU、メモリ、ディスク、ネットワーク帯域幅を必要に応じて分割し、それぞれの割り当てを厳密に制御することができます。

CPU問題

VMwareの仮想インフラストラクチャ上の主なCPUの問題は、全体的な割り当てです。 物理マシンには一定数のコアが用意されており、各仮想マシンには一定数のvCPUが与えられています。 そのホスト上のVMに割り当てられたvCPUの数が物理コアの数を超える場合、VMシステムは他のVMがCPUを使用している間、いくつかのサイクルのための要求を待たなければなりません。 これはオーバーコミットと呼ばれ、CPUのレスポンスが予想以上に遅くなることがあります。

システムにvCPUが多いとCPUリソースのオーバーコミットの問題が悪化します。 OSはコア数が多いと思っているので、すぐに処理されることを前提にスケジューリングを行い、他のCPUでの他の操作は並列に実行されるはずだった多くの操作の結果に左右される可能性があります。 物理ホスト上のスケジューラは、4つまたは8つのvCPUの処理を行うために、4つまたは8つのコア(例えば)が利用可能になるまで待たなければならない場合があります。 少ないコア数を待つよりも時間がかかることがあります。 多くの場合、これにより、多くの vCPU が割り当てられているシステムでは、vCPU が少ないシステムよりも動作が遅くなることがあります。 vSphere では、管理者が VM ごとにクロックティックを割り当てることができるため、VM の速度を一定以上にしないように上限を設定したり、可能な限り高速に動作させることができます。 だからこそ、少ないvCPUの方が高速に動くこともあります。 2つのvCPUは、4つまたは8つのコアが仕事を処理するために利用できるようになるのを待っている間に、4つまたは8つがつまずく可能性がありますが、それらが利用可能なときはいつでもクロックサイクルをつかむことができます。 javaアプリケーションの場合、最低でも2つのvCPUを用意しておくと良いでしょう。 1つはガベージコレクション操作やその他のJVM管理を処理し、もう1つはアプリケーション処理の大部分を処理します。 利用可能なvCPUが1つしかない場合、GCは必要以上に通常の動作をブロックする傾向があります。

メモリの問題

メモリは物理ホスト上でオーバーコミットされることがあります。 これは、ホスト上で実行されているVMに割り当てられたメモリが、ホスト上で利用可能なメモリの総量を超えた場合に発生します。 これは、VMのすべてのオペレーティングシステムが物理ホスト上のすべての使用可能なメモリを主張するまでは、大きな問題ではありません。 メモリへの要求を処理するために、物理ホストはディスクへのページのスワップアウトを開始しなければなりません。 通常はメインメモリから引っ張ってくるはずの操作が、実際にはVMのOSが知らない間にディスクからデータを引っ張ってきていることを除けば、これはVMからは見えません。 一つの症状としては、トップの %sイースのCPU使用率が高いことが挙げられます。 OS自体がメモリをスワップアウトしていたら、高い %iowaitと高いスワップ使用率が表示されます。 スワッピングが物理ホストで行われている場合、これらのインジケータは表示されません。 このような場合、管理者は物理マシンからいくつかのVMを取り出すか、ESノードのメモリ予約を設定する必要があります。 メモリ予約は、システム上の他のVMを犠牲にしても、常にVMに利用可能な物理メモリがあることを保証し、それがスワップアウトされないことを保証します。

ディスク利用率

物理ホストからの物理ストレージは、仮想ディスクとして提示されます。 メモリと同様に、ディスクが過剰に使用されている場合、ESノードのVM自体があまり使用されていない場合、ディスクからのレスポンスが遅くなることがあります。

多くの仮想インフラストラクチャでは、大規模なストレージアレイを使用して、多くのVMに仮想ディスクを提供しています。 多数のESノードがデータパスに同じストレージアレイを使用している場合、これがすぐにボトルネックになる可能性があります。 仮想化されたElasticsearchインフラストラクチャを設計する際には、ストレージアーキテクチャを慎重に検討する必要があります。 これらの問題のいくつかは、Elasticsearchがバックエンドとして使用できる複数のストレージアレイを確保したり、VMware vSANや他のコンバージドインフラストラクチャソリューションのような仮想化ストレージアーキテクチャを使用することで回避することができます。

仮想化環境でElasticsearchのストレージ基盤を設計する際のもう一つの考慮点は、データ保護の影響です。 VM のスナップショットは推奨されません。 のドキュメントにあるように、Elasticsearch クラスタの全ノードのデータディレクトリをスナップショットするだけでは、Elasticsearch クラスタをバックアップすることはできません。 Elasticsearch は実行中にデータディレクトリの内容を変更している可能性があります。 このようなバックアップからクラスタを復元しようとすると、失敗してファイルの破損や欠落が報告されることがあります。 あるいは、無言でデータの一部を失ったが成功したように見えるかもしれない。 クラスタをバックアップする唯一の確実な方法は、 のスナップショットと の機能を使用してリストアすることです。

ネットワーク利用

物理ホストでのネットワークの過剰利用は、ディスクの過剰利用に似ています。 明らかな理由がないため、VM上のネットワーク操作が遅くなります。

vMotion での移行

vMotion を使用した VM のライブマイグレーションでは、VM を一定期間一時停止します。 VM が一時停止している間、実行中の Elasticsearch ノードはヘルスチェックを含むリクエストに応答しません。 ノードがヘルスチェックに十分な時間応答しない場合、そのノードは不健康とみなされ、クラスタから削除されます。 一時的に応答しないノードによる混乱を避けるために、 ローリングリスタート の手順に従って、ノードが停止している間にVMマイグレーションを実行することをお勧めします。

* Elastic、Elasticsearch、X-Packは、米国Elasticsearch BVの商標です。 と、他の国の方にも紹介されています。