Installation

Volume partitioning and smartstore

pBear
Explorer

We are running a  single Splunk Enterprise 8.1 instance on a Linux AWS EC2 instance. We are using smartstore backed by S3. We have /opt/splunk (including the index volume/cache) on a separate partition from the OS. 

I have not seen/found any documentation addressing OS level partitioning. 

Are there performance concerns with our current configuration? Would/could a spike in the size of non-index files on the splunk partition cause performance issues or caching abnormalities with smartstore?

Does it make sense to separate the indexes (./lib/) onto its own partition, separate from both the OS and splunk config/app/log and other transient files?

 

Labels (1)
0 Karma
1 Solution

pBear
Explorer

Thank you. 
It is as I expected. It makes perfect sense to me, regardless of smart-store or not. But I couldn't find any documentation I could point to in order to justify the architectural change to management. 

I guess they are just going to have to take our word for it. 🙂

View solution in original post

0 Karma

richgalloway
SplunkTrust
SplunkTrust

Yes!  $SPLUNK_HOME, $SPLUNK_DB, and the OS should be on separate partitions.

---
If this reply helps you, Karma would be appreciated.

pBear
Explorer

Thank you. 
It is as I expected. It makes perfect sense to me, regardless of smart-store or not. But I couldn't find any documentation I could point to in order to justify the architectural change to management. 

I guess they are just going to have to take our word for it. 🙂

0 Karma
Get Updates on the Splunk Community!

Automatic Discovery Part 1: What is Automatic Discovery in Splunk Observability Cloud ...

If you’ve ever deployed a new database cluster, spun up a caching layer, or added a load balancer, you know it ...

Real-Time Fraud Detection: How Splunk Dashboards Protect Financial Institutions

Financial fraud isn't slowing down. If anything, it's getting more sophisticated. Account takeovers, credit ...

Splunk + ThousandEyes: Correlate frontend, app, and network data to troubleshoot ...

 Are you tired of troubleshooting delays caused by siloed frontend, application, and network data? We've got a ...