Deploying Splunk on Windows

Deploying Splunk on Windows

You can integrate Splunk into your Windows environment in any number of ways. This topic discusses some of those scenarios and offers guidelines on how to best adapt your Splunk for Windows deployment to your enterprise.

While this topic is geared more toward deploying Splunk in a Windows environment, Splunk itself also has distributed deployment capabilities that you should be aware of, even as you integrate it into your Windows enterprise. The Distributed Deployment Manual has lots of information on spreading Splunk services across a number of computers.

When deploying Splunk on Windows on a large scale, you can rely completely on your own deployment utilities (such as System Center Configuration Manager or Tivoli/BigFix) to place both Splunk and its configurations on the machines in your enterprise. Or, you can integrate Splunk into system images and then deploy Splunk configurations and apps using Splunk's deployment server.

Concepts

When you deploy Splunk into your Windows network, it captures data from the machines and stores it centrally. Once the data is there, you can search and create reports and dashboards based on the indexed data. More importantly, for system administrators, Splunk can send alerts to let you know what is happening as the data arrives.

In a typical deployment, you dedicate some hardware to Splunk for indexing purposes, and then use a combination of universal forwarders and Windows Management Instrumentation (WMI) to collect data from other machines in the enterprise.

Considerations

Deploying Splunk in a Windows enterprise requires a number of planning steps.

First, you must inventory your enterprise, beginning at the physical network, and leading up to how the machines on that network are individually configured. This includes, but is not limited to:

• Counting the number of machines in your environment and defining a subset of those which need Splunk installed. Doing this defines the initial framework of your Splunk topology.
• Calculating your network bandwidth, both in your main site and at any remote or external sites. Doing this determines where you will install your main Splunk instance, and where and how you will use Splunk forwarders.
• Assessing the current health of your network, particularly in areas where networks are separated. Making sure your edge routers and switches are functioning properly will allow you to set a baseline for network performance both during and after the deployment.

Then, you must answer a number of questions prior to starting the deployment, including:

• What data on your machines needs indexing? What part of this data do you want to search, report, or alert across? This is probably the most important consideration to review. The answers to these questions determine how you address every other consideration. It determines where to install Splunk, and what types of Splunk you use in those installations. It also determines how much computing and network bandwidth Splunk will potentially use.

• How is the network laid out? How are any external site links configured? What security is present on those links? Fully understanding your network topology helps determine which machines you should install Splunk on, and what types of Splunk (indexers or forwarders) you should install on those machines from a networking standpoint.

A site with thin LAN or WAN links makes it necessary to consider how much Splunk data should be transferred between sites. For example, if you have a hub-and-spoke type of network, with a central site connected to branch sites, it might be a better idea to deploy forwarders on machines in the branch sites, which send data to an intermediate forwarder in each branch. Then, the intermediate forwarder would send data back to the central site. This is a less costly move than having all machines in a branch site forward their data to an indexer in the central site.

If you have external sites that have file, print or database services, you'll need to account for that traffic as well.

• How is your Active Directory (AD) configured? How are the operations masters roles on your domain controllers (DCs) defined? Are all domain controllers centrally located, or do you have controllers located in satellite sites? If your AD is distributed, are your bridgehead servers configured properly? Is your Inter-site Topology Generator (ISTG)-role server functioning correctly? If you are running Windows Server 2008 R2, do you have read-only domain controllers (RODCs) in your branch sites? If so, then you have to consider the impact of AD replication traffic as well as Splunk and other network traffic.

• What other roles are the servers in your network playing? Splunk indexers need resources to run at peak performance, and sharing servers with other resource-intensive applications or services (such as Microsoft Exchange, SQL Server and even Active Directory itself) can potentially lead to problems with Splunk on those machines. For additional information on sharing server resources with Splunk indexers, see "Hardware capacity planning for a larger Splunk deployment" in the Installation Manual.

• How will you communicate the deployment to your users? A Splunk installation means the environment is changing. Depending on how Splunk is rolled out, some machines will get new software installed. Users might incorrectly link these new installs to perceived problems or slowness on their individual machine. You should keep your user base informed of any changes to reduce the number of support calls related to the deployment.

Prepare your Splunk on Windows deployment

How you deploy Splunk into your existing environment depends on the needs you have for Splunk, balanced with the available computing resources you have, your physical and network layouts, and your corporate infrastructure. As there is no one specific way to deploy Splunk, there are no step-by-step instructions to follow. There are, however, some general guidelines to observe.

For a more successful Splunk deployment:

• Prepare your network. Before integrating Splunk into your environment:
  • Make sure that your network is functioning properly, and that all switches, routers and cabling are correctly configured.
  • Replace any broken or failing equipment.
  • Ensure any virtual LANs (VLANs) are properly set up.
  • Test network throughput, particularly between sites with thin network links.

• Prepare your Active Directory. While AD is not a requirement to run Splunk, it's a good idea to ensure that it is functioning properly prior to your deployment. This includes but is not limited to:
  • Identifying all of your domain controllers, and the operations master roles any of them might perform. If you have RODCs at your branch sites, make sure that they have the fastest connections as possible to operations masters DCs.
  • Ensuring that AD replication is functioning correctly, and that all site links have a DC with a copy of the global catalog.
  • If your forest is divided into multiple sites, make sure your ISTG role server is functioning properly, or that you have assigned at least two bridgehead servers in your site (one primary, one backup).
  • Ensuring that your DNS infrastructure is working properly.

You might need to place DCs on different subnets on your network, and seize flexible single master operations (FSMO, or operations master) roles as necessary to ensure peak AD operation and replication performance during the deployment.

• Define your Splunk deployment. Once your Windows network is properly prepared, you must now determine where Splunk will go in the network. Consider the following:
  • Determine the set(s) of data that you want Splunk to index on each machine, and whether or not you need for Splunk to send alerts on any collected data.
  • Dedicate one or more machines in each network segment to handle Splunk indexing, if possible. For additional information on capacity planning for a distributed Splunk deployment, review "Hardware capacity planning for a larger Splunk deployment" in the Installation Manual.
  • Don't install full Splunk on machines that run resource-intensive services like AD (in particular, DCs that hold FSMO roles), any version of Exchange, SQL Server, or machine virtualization product such as Hyper-V or VMWare. Instead, use a universal forwarder, or connect to those machines using WMI.
  • If you're running Windows Server 2008/2008 R2 Core, remember that you'll have no GUI available to make changes using Splunk Web when you install Splunk on those machines.
  • Arrange your Splunk layout so that it uses minimal network resources, particularly across thin WAN links. Universal forwarders greatly reduce the amount of Splunk-related traffic sent over the wire.

• Communicate your deployment plans to your users. It's important to advise your users about the status of the deployment, throughout the course of it. This will significantly reduce the amount of support calls you receive later.

• Was this topic useful?
• Post a comment