Hello, I am engaged in a planning exercise for the year 2021. We currently use Robinhood v3 to index our filesystems and perform queries against it, but don't do much with policies beyond alerts (this could change). I have looked at the LAD 19 presentation slides.
In the Robinhood v4 era, is it known whether the "1KB/entry" rule-of-thumb could still be accurate? I am trying to estimate flash storage capacity needs for this purpose. Our current implementation places the changelog reader and mariabd server on the same hardware resource. We have a relatively large CPU and RAM capacity on this resource (CPU for both changelog reading and mariadb, RAM largely for innodb buffer pool size). I would also like to know whether to expect CPU and/or RAM needs are expected to change with Robinhood v4. Is there any guidance in this area? I can scale our current Robinhood utilization by our anticipated client and core count changes (and thus changelog entry processing needs), but wonder if there is more to it than that. Note this will be a Lustre 2.12/2.14/later environment by that time, and we will be using DNE/DoM/PFL features (not in use today). I am not sure if this makes any difference in the capacity planning, but I thought I should mention it in case it matters for Robinhood. Thank you, Craig Prescott Research Computing University of Florida Information Technology
_______________________________________________ robinhood-support mailing list robinhood-support@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/robinhood-support
