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!

Splunk Enterprise Security 8.x: The Essential Upgrade for Threat Detection, ...

 Prepare to elevate your security operations with the powerful upgrade to Splunk Enterprise Security 8.x! This ...

Get Early Access to AI Playbook Authoring: Apply for the Alpha Private Preview ...

Passionate about security automation? Apply now to our AI Playbook Authoring Alpha private preview ...

Reduce and Transform Your Firewall Data with Splunk Data Management

Managing high-volume firewall data has always been a challenge. Noisy events and verbose traffic logs often ...