ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

[LES] Elasticsearch仮想マシンに関する考慮事項

導入

VMインフラストラクチャで実行されるElasticsearch*インスタンスは、特有の課題を抱える場合があります。この記事では、さまざまな仮想マシンソフトウェアで発生する可能性のある一般的な問題点について説明します。

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

CPUの問題

VMware仮想インフラストラクチャにおける主要なCPU問題は、CPUの過剰割り当てである。物理マシンには利用可能なコア数が一定数あり、各仮想マシンには一定数のvCPUが割り当てられます。そのホスト上の仮想マシンに割り当てられたvCPUの数が物理コアの数を超えると、他の仮想マシンがCPUを使用している間、仮想マシンシステムはサイクル要求の一部を待機させる必要が生じます。これはオーバーコミットと呼ばれ、CPUの応答速度が予想よりも遅くなる原因となる可能性があります。

システムに多数の仮想CPU（vCPU）が存在する場合、CPUリソースの過剰割り当ての問題はさらに深刻化する。 OSは処理に利用できるコアが多数あると認識しているため、処理が即座に完了することを前提として処理をスケジュールします。そのため、他のCPU上の処理は、並列実行されるはずだった多くの処理の結果に依存する可能性があります。物理ホスト上のスケジューラは、4つまたは8つのvCPUを処理するために、4つまたは8つのコア（例えば）が利用可能になるまで待機する必要がある場合があります。これは、コア数が少ない場合よりも時間がかかる可能性があります。多くの場合、これにより、割り当てられたvCPUの数が多いシステムの方が、vCPUの数が少ないシステムよりも動作が遅くなることがあります。 vSphereでは、管理者が仮想マシンごとにクロックティックを割り当てることができるため、一部の仮想マシンは一定の速度を超えないように制限し、他の仮想マシンは可能な限り高速で実行することができます。そのため、vCPUの数が少ない方が、vCPUの数が多いよりも高速に動作する場合があるのです。 2つのvCPUであれば、利用可能なクロックサイクルをいつでも取得できるが、4つまたは8つのvCPUでは、処理に必要なコアが十分に利用可能になるまで待機してしまう可能性がある。 Javaアプリケーションの場合、最低でも2つのvCPUを用意することをお勧めします。一方はガベージコレクション操作やその他のJVM管理を担当し、もう一方はアプリケーション処理の大部分を担当する。利用可能なvCPUが1つしかない場合、GCは通常の動作を必要以上にブロックする傾向があります。

記憶障害

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

ディスク使用率

物理ホスト上の物理ストレージは、仮想ディスクとして表示されます。メモリと同様に、ディスクが過剰に使用されている場合、ESノードのVM自体がディスクをそれほど使用していない場合でも、ディスクの応答が遅くなる可能性があります。

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

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

ネットワーク利用率

物理ホスト上でのネットワークの過剰利用は、ディスクの過剰利用と類似している。仮想マシン上でのネットワーク操作が、特に理由もなく遅くなる。

vMotionによる移行

vMotionを使用したVMのライブマイグレーションでは、VMは一定期間一時停止されます。 VMが一時停止している間は、実行中のElasticsearchノードは、ヘルスチェックを含むあらゆるリクエストに応答しません。ノードが一定期間ヘルスチェックに応答しない場合、そのノードは異常とみなされ、クラスタから削除されます。一時的に応答しなくなるノードによって発生する障害を回避するために、ローリング再起動の手順に従って、ノードが停止している間に VM の移行を実行することをお勧めします。

* Elastic、Elasticsearch、およびX-Packは、米国で登録されたElasticsearch BVの商標です。そして他の国々でも。