Your SlideShare is downloading. ×
0
Scaling Splunk 101Quick Overview of Scaling Splunk with Commodity HardwareErik SwanOct, 09<br />** Slides intentionally ug...
Single Server InstallCommodity Architecture <br />Simplest Splunk install is a single server that functions as both indexe...
Improving Search and Indexing Performance<br />Splunk scales search and indexing performance horizontally by adding more i...
Adding a Search Head<br />By splitting out a Search Head, search performance is improved and load is taken off the indexer...
Adding a second Indexer<br />As volume goes up beyond 100G OR you want to improve search performance its best to add a sec...
Adding additional Indexers<br />For every new ~100G, or again to improve search performance add another indexer. <br />RUL...
Adding additional Indexers<br />For every new ~100G, or again to improve search performance add another indexer. <br />RUL...
Adding additional Search Heads<br />TBs/day from Splunk Forwarders and Syslog<br />Adding more Search Heads is a convenien...
Adding additional Search Heads<br />TBs/day from Splunk Forwarders and Syslog<br />Assuming a load of 1T p/day:<br />Use C...
Long term storage, add a SAN<br />TBs/day from Splunk Forwarders and Syslog<br />Long term storage can not be kept on loca...
Multi-datacenter or deployment<br />If you have multiple data centers, it is often best to leave the data local and use di...
Additional Scaling Topics<br />Summary Indexing – If your searches are slow consider using summary indexing: <br />video -...
Upcoming SlideShare
Loading in...5
×

Scale Splunk

7,455

Published on

Scaling splunk 101 - the easy slides

Published in: Technology
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,455
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
221
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

Transcript of "Scale Splunk"

  1. 1. Scaling Splunk 101Quick Overview of Scaling Splunk with Commodity HardwareErik SwanOct, 09<br />** Slides intentionally ugly, no designers were harmed during construction<br />
  2. 2. Single Server InstallCommodity Architecture <br />Simplest Splunk install is a single server that functions as both indexer and search head.<br />A single box can easily index 100-200G per day, BUT for fast searching its best to use more than one box.<br />Data from Splunk Forwarders, Syslog, Files, etc.<br />Splunk (all in one)<br />Users<br />
  3. 3. Improving Search and Indexing Performance<br />Splunk scales search and indexing performance horizontally by adding more indexers and in some cases scaling out a search tier. <br />By spreading the incoming load across more indexers you index faster. <br />Perhaps more importantly, by spreading the indexed data across more indexers your search performance improves linearly as well.<br />Consider that every doubling of hardware will double your index and search performance and don’t be shy of adding 10’s of servers.<br />RULE #1 – If your searches are slow, add another box!<br />
  4. 4. Adding a Search Head<br />By splitting out a Search Head, search performance is improved and load is taken off the indexer for faster indexing.<br />Best to add sooner than later.<br />Best for volumes between 5-100G p/day<br />1 Indexer<br />1 Search Head<br />Data from Splunk Forwarders, Syslog, Files, etc.<br />Spunk Indexer<br />Splunk Search Head<br />Users<br />
  5. 5. Adding a second Indexer<br />As volume goes up beyond 100G OR you want to improve search performance its best to add a second Indexer. <br />**Remember adding indexers improves search performance linearly as well.<br />Best for volumes 20-200G p/day<br />2 Indexers<br />1 Search Head<br />Data from Splunk Forwarders, Syslog, Files, etc.<br />Spunk Indexer<br />Spunk Indexer<br />Splunk Search Head<br />Users<br />
  6. 6. Adding additional Indexers<br />For every new ~100G, or again to improve search performance add another indexer. <br />RULE #1: If searches are slow, add an another indexer.<br />For volumes from 200G-1T p/day<br />TBs/day from Splunk Forwarders and Syslog<br />Spunk Indexer<br />Spunk Indexer<br />Spunk Indexer<br />(n) Indexers <br />Splunk Search Head<br />Users<br />
  7. 7. Adding additional Indexers<br />For every new ~100G, or again to improve search performance add another indexer. <br />RULE #1: If searches are slow, add an another indexer.<br />For volumes from 200G-1T p/day<br />TBs/day from Splunk Forwarders and Syslog<br />Assume 100G p/day:<br />Use Case : Log archival and some periodic troubleshooting<br /> 1 Commodity Server<br />Use Case #2 : Archival, troubleshooting and summary reporting<br /> 1 Index Server, 1 Search Server<br />Use Case #3: Archival, Trouble Shooting, and Reporting<br /> 2 Index Servers, 1 Search Server<br />Use Case #4: Many ( &gt;2 ) users doing constant use<br /> 3+ Index Servers, 1 Search Server <br />Spunk Indexer<br />Spunk Indexer<br />Spunk Indexer<br />(n) Indexers <br />Splunk Search Head<br />Users<br />
  8. 8. Adding additional Search Heads<br />TBs/day from Splunk Forwarders and Syslog<br />Adding more Search Heads is a convenient way to improve search performance <br />Add an additional Search Heads when:<br />It makes sense to partition users.<br />Too offload summary or scheduled searches. <br />Spunk Indexer<br />Spunk Indexer<br />Spunk Indexer<br />(n) Indexers <br />Splunk Search Head<br />Splunk Search Head<br />(n) Search Heads<br />1~ 4T each p/day<br />Load Bal.<br />Users<br />
  9. 9. Adding additional Search Heads<br />TBs/day from Splunk Forwarders and Syslog<br />Assuming a load of 1T p/day:<br />Use Case #1: Log archival and some periodic troubleshooting<br /> 4 Index Servers, 1 Search Server<br />Use Case #2: Archival, trouble shooting and some summary reporting<br /> 8+ Index Server, 1 Search Server<br />Use Case #3: Archival, Trouble Shooting, and Reporting<br /> 16+ Index Servers, 1 Search Server<br />Use Case #4: Many ( &gt;2 ) users doing constant use<br /> 20+ Index Servers, 1 Search Server <br />For every new ~TB p/day, add another search head.<br />For volumes &gt; 2T p/day<br />(n) Indexers each &lt;100G p/day<br />(m) Search Heads for every ~1T p/day<br />Spunk Indexer<br />Spunk Indexer<br />Spunk Indexer<br />(n) Indexers <br />Splunk Search Head<br />Splunk Search Head<br />(n) Search Heads<br />1~ 4T each p/day<br />Load Bal.<br />Users<br />
  10. 10. Long term storage, add a SAN<br />TBs/day from Splunk Forwarders and Syslog<br />Long term storage can not be kept on local commodity IO.<br />If wanting to keep more than can be kept on local indexer disk, splunk can be configured to use SAN or other storage device.<br />Best for keeping &gt;30 day – multi year data.<br />Spunk Indexer<br />Spunk Indexer<br />Spunk Indexer<br />(n) Indexers <br />Tier 1 SAN<br />Splunk Search Head<br />Splunk Search Head<br />Load Bal.<br />Users<br />
  11. 11. Multi-datacenter or deployment<br />If you have multiple data centers, it is often best to leave the data local and use distributed search between two deployments.<br />If you have data that naturally partitions such that users would rarely search across the data, partitioning entire deployments can help.<br />Obviously for DR as well.<br />
  12. 12. Additional Scaling Topics<br />Summary Indexing – If your searches are slow consider using summary indexing: <br />video - http://www.splunk.com/view/SP-CAAACZW<br />docs - http://www.splunk.com/base/Documentation/4.0.5/User/UseSummaryIndexingForIncreasedReportingEfficiency<br />Routing High Volume data to Separate Index – If you are searching or reporting on a source that is dwarfed by the volume of another source, you can partition data such that the high volume source is in its own index: <br />docs - http://www.splunk.com/base/Documentation/latest/Admin/Setupmultipleindexes#Why_have_multiple_indexes.3F<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×