![]() Splunk Reference Hardware is broken down into two categories. Many Splunk systems work very well when virtualized (such as search head cluster deployers and cluster masters), but others are better suited to being on bare-metal hardware or at least having firm resource reservations when virtualized (such as indexers and search heads). In order to increase server numbers without purchasing an equal amount of hardware, virtualization is frequently employed. In this example, I’m going to assume we are working with an on-prem Splunk deployment, where all of the indexers and search heads are systems under your control. Splunk Cloud is a great way to get all of the functionality you love about Splunk, without having to manage the servers yourself. You have a couple of options – the first would be Splunk Cloud. How do we keep the Splunk functionality we want while not dedicating half of the computing capacity in the datacenter to Splunk? As much as we love complicated multi-terabyte per day deployments, those are significantly less common than much smaller ones, in the 20-50GB/day range. Just don’t come to me crying when the hardware purchase doesn’t get approval.Īll kidding aside – a common situation I face when working with clients is effectively managing resources. Since a Splunk Enterprise license is sold based on data indexed per day, any Splunk Enterprise license includes all of these features – so if you want to design a 20gb/day environment to have the same redundancy and capacity as our 500gb/day example, go right ahead. ![]() I don’t have a 500gb/day license – why does any of this matter to me? In fact, many of these Splunk options integrate well into a smaller deployment with similar requirements, albeit at a lower usage level. However, not everyone has this level of Splunk usage but still wants to leverage many of the features outlined in this example. The possibilities are pretty much endless.įor a large organization, 29 servers to run a mission-critical application might not be that big of a deal. We also haven’t considered the possibility of spanning the Search Head Clusters across multiple sites (or having completely different SHCs for each site), both of which are options for adding search redundancy. And there are plenty of possible cases I haven’t even covered yet, such as having syslog at the DR site – we don’t have syslog receivers for that in the design currently. That brings our total to 29 servers for a 500gb/day Splunk environment running ES with a heavy search, alert, and user volume, and some room for future growth. So right off the bat, we’re already at 9 servers, just for data retention. For budgeting purposes, we decided to get an extra indexer up front to allow for some additional capacity. (For more on Splunk Enterprise system requirements check out the docs). With this number of indexers, you’ll likely be deploying some form of Splunk indexer replication clustering, which requires a cluster master. This means our 500gb/day environment will require 5-7 indexers, each exceeding the minimum system requirements, which at the time of writing this are 16 cores and 32gb of RAM per indexer. Regardless of what sizing number you look to use, you should never assume that any single indexer will be able to handle more than 100gb per day in an ES environment. Sizing the environmentĭepending on who you ask, an ES deployment recommends that a single indexer support no more than 75-100gb of data per day in order to handle incoming data and service the significant search volume with ES and its associated correlation searches and data models. They also have multiple sites and believe Splunk will need to support a failover to DR once it becomes a business critical application.Īfter a sizing exercise, this customer decided upon purchasing a modest 500gb/day Splunk license with Splunk Enterprise Security (ES), with the option of expanding this in the future if data ingestion increases. However, they also expect Splunk usage to take off once everyone sees how awesome of a tool it is, and want to have room for additional growth included in the original design. To get started, they want to be able to search their data and have security alerting, with a handful of Splunk users for each environment. This customer is looking to use Splunk for compliance and security purposes, and wants to use the Splunk Enterprise Security Suite (Splunk ES) in order to generate actionable security alerts from their log data. ![]() A sample Splunk deploymentįor the sake of example, let’s consider an imaginary new Splunk customer. While this is not actually true (conspiracy theorists aside), a typical distributed Splunk environment can result in quite a sprawl of systems to manage. When designing a Splunk deployment, especially a large distributed one, it can seem like Splunk was purely developed by hardware vendors to sell more servers.
0 Comments
Leave a Reply. |