Solr Cloud + Zookeeper + Kubernetes のセットアップ
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/1pbjhjk0xpoj7ptzznxs51335xc8rp8s into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
皆さんに感謝の気持ちを伝えたいです。皆さんはまるで、私が持ったことのない頼れる兄のようです。アメリカの皆さん、感謝祭おめでとうございます。
私の上司はとても高い要求をしてきており、これがそもそも可能かどうか確認したいです。私が扱っているのは非常に大きなコアで、2億件のドキュメントがあります。この状況では、ShardingのためにSolr Cloudが必要で、高可用性のためにZookeeperが必要です。そして、これらをKubernetes環境で実行する必要があります。これは可能でしょうか？チュートリアルでは、埋め込み型のZookeeperと外部のZookeeperの選択について述べられていますが、この状況ではどちらを使用すべきでしょうか？このセットアップを構築するためのハウツーガイドはありますか？
ありがとうございます！
はい、可能です。2億件のドキュメントに対して、いくつのシャードとレプリカを作成する予定でしょうか？これらはすべてインデックスのサイズ（格納フィールドの数など）に基づいて決まります。外部Zookeeperが最適です。Kubernetes環境でのSolrのセットアップも問題なく動作します。
ありがとうございます。
Ramesh
こんにちは、
SolrをKubernetes上で実行するための公式サポートについて、Solr Operator を確認してみてください。
また、こちらのサードパーティーのHelmチャートもよくメンテナンスされており、始めやすいかもしれません：
https://artifacthub.io/packages/helm/bitnami/solr
頑張ってください。
Jan
Zookeeperが必須の依存関係になっているのは面倒です。etcdがあるのに、Zookeeperのすべてのデータは簡単にConfigMapに収められるのにね。
同様に、Zookeeperの代わりにDynamoDBのようなマネージドサービスを使うのもありかもね :)
Rameshさん、
外部Zookeeperのインストールについて、もう少し詳しく教えてもらえますか？また、Solrをk8s（Kubernetes）で動かす方法についても教えてください。
ZK APIを利用しながら、すべてをetcdに保存する製品があると思います。また、こちらのリンクもチェックしてみてください：https://cwiki.apache.org/confluence/display/SOLR/SIP-18%3A+A+Solr+Kubernetes+Module+for+native+integration。これは、ConfigMapsをconfigSetファイルなどに使用できるようにする、よりクラウドネイティブな統合を目指した取り組みです。また、https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper も参照してみてください。もし注目を集めれば、ZKをSolrプロセスに組み込み、ユーザーが別途管理する必要のない実装の一部にする予定です。
Jan
Zookeeperを埋め込みやSolrと同じノードに配置することには根本的な欠点があります。多くのクエリが実行されているとき、Solrのレプリカが過負荷になると、ノード自体に影響を与え始めます（Solrが非常に忙しい場合、ノードにSSHさえできなくなることもあります）。これが同じノード上のZookeeperにも影響を与え、結果としてSolrのレプリカやZookeeperノードが次々とダウンし、クラスタ全体の可用性が低下する可能性があります。
高い読み取りや書き込みが必要なクラスタでは、Zookeeperを専用のマシンに配置する方が良いと思います。
-ufuk yilmaz
こんにちは、Vince。
こちらに外部ZK + Solrをk8sにインストールするためのチュートリアルがあります：
https://sematext.com/blog/solr-operator-autoscaling-tutorial/
参考になれば幸いです。
Radu
Sematext Cloud - Full Stack Observability
https://sematext.com/
現在: k8s環境では、ZKは別々のPODを持ちます（推奨されるHelmチャートの両方で）。PODはLinuxカーネルにフックして、同じk8sノード上のホットなSolr PODに資源を奪われないように保証します。そのため、別のマシンを用意する必要はなく、別のPODで問題ありません。
将来（現行のものではない）: SIP-14により、Solrは新しい「zookeeper」ノードロールを取得し、埋め込まれたZKをホスティングするだけのSolr Podを起動できるようになるかもしれません。
参考までにですが、1つのJVMで2つのものを動かすよりも、2つの別々のJVMを立ち上げた方がうまくいくことが多いです。私の経験では、LinuxはJVMよりもプロセススケジューリングが得意なようです。
それを1つのオペレーターにまとめることが改善になるかどうかは疑問です。もし別々のポッドで立ち上げるなら。
Dima
Kubernetes（k8s）ではすでにかなり簡単ですが、SIPが実装されると、手動インストールにも同様の運用上の利点が得られるでしょう。しかし、期待しすぎない方がいいかもしれません。実現しない可能性もあります。
Jan Høydahl
トピックへ返信するには、ログインが必要です。