For my specific situation it just seemed having one super hot server in action worked best, and the cold ones were in a separate data center than the primary web server, with the other two db/web servers, so they were more of a if sht hits the fan sort of set up while keeping one solr, one db, and one web keeping their caches going at full speed. When they did have to fail over to the other nodes it would take about 5/10 minutes for them to heat up but they were always ready.
Containers are great for developing and fast deployment but I would never put one in front of live users. Maybe it’s a trust issue? But I like metal > On Jul 17, 2022, at 11:49 AM, Walter Underwood <wun...@wunderwood.org> wrote: > > I’ve never understood paying for “cold” backup machines that don’t take > traffic. Keep them all hot. That way you know they work and you don’t have > cold cache slow startup problems when you put them into service. > > Yes, agree about containers. Containers are great for CPU-only applications. > They just aren’t designed for persistent data. > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > >> On Jul 17, 2022, at 7:58 AM, Dave <hastings.recurs...@gmail.com> wrote: >> >> Three nodes with nginx in front will handle well over 50k searches a day on >> a half terabyte index, but only one node is to serve the searches the rest >> are backups. I would never put solr in a container >> >>>> On Jul 17, 2022, at 10:44 AM, Shawn Heisey <apa...@elyograg.org> wrote: >>> >>> On 7/17/22 07:40, Ronen Nussbaum wrote: >>>> We are planning to migrate our Solr Cloud clusters to the cloud. >>>> Currently it is installed on-prem for each customer. >>>> It is already deployed as Docker containers. >>>> Instead of estimating in advance what is the number of shards needed, or >>>> the number of pods, we'd like to rely on EKS cluster autoscaler, K8S HPA >>>> and Solr autoscaling. >>>> Our main concern is the deprecation of the autoscaling feature since >>>> version 9.0. >>> >>> One thing I am not sure you're aware of: You can't add shards to a >>> collection unless it is using the implicit router, which is poorly named >>> because what it means is that sharding is 100% user-managed (manual). >>> >>> There is the shard splitting capability in the Collections API, but that >>> only works on a single shard, not the whole collection. If you wanted to >>> adjust from say 6 to 8 shards and still have the shards be approximately >>> equal in size, you would need to build a new collection and completely >>> reindex. >>> >>> There have been a number of issues filed for a rebalance feature, but it >>> has not been implemented because implementing it would involve a very large >>> amount of work, and making it stable would take even more work. And I am >>> not even sure the Lucene API has the capability to do it currently. >>> >>> https://issues.apache.org/jira/browse/SOLR-9241 >>> >>>> What is your recommendation? Should we start with 8.11? Will it be a >>>> substitute soon? >>> >>> I have no idea whether a substitute will be available. You can manually do >>> everything that the autoscaler would do with the Collections API. >>> >>> Thanks, >>> Shawn >>> >
