About Splunk Validated Architectures

Splunk Validated Architectures (SVAs) are trusted reference architectures for stable, efficient and repeatable Splunk software deployments. Many of Splunk's existing customers have experienced rapid adoption and expansion, leading to certain challenges as they attempt to scale. At the same time, new Splunk customers are increasingly looking for guidelines and vetted architectures to ensure that their initial deployment is built on a solid foundation. SVAs have been developed to help our customers with these growing needs.

Whether you are a new or existing Splunk customer, SVAs are helpful tools to assist you with building an environment that is easier to maintain and simpler to troubleshoot. SVAs are designed to assist you with achieving the best possible results while minimizing your total cost of ownership. Additionally, your entire Splunk Platform can be deployed in a repeatable manner to help you scale your deployment as your needs evolve over time. Validated Architectures are highly relevant to the concerns of decision makers and administrators. Enterprise architects, consultants, Splunk administrators and managed service providers should all be involved in the SVA selection process.

SVAs offer topology options that consider a wide array of organizational requirements, so you can easily understand and find a topology that is right for your requirements. The Splunk Validated Architectures selection process will help you match your specific requirements to the topology that best meets your organization's needs. If you are new to Splunk, we recommend implementing a Validated Architecture for your initial deployment. If you are an existing customer, we recommend that you explore the option of aligning with a Validated Architecture topology. Unless you have unique requirements that make it necessary to build a custom architecture, it is very likely that a Splunk Validated Architecture will fulfill your requirements while remaining cost effective.

It is always recommended that you involve Splunk or a trusted Splunk partner to ensure that the recommendations in this document meet your needs.

If you need assistance implementing a Splunk Validated Architecture, contact Splunk Professional Services.

What's new

Welcome to the new home of the Splunk Validated Architectures where you will find a growing catalog of modules that contain best practice architectures and approaches. Along with a new home and format, the SVA program has been relaunched with a renewed focus on making you successful in your Splunk journey.

In addition to the base Splunk Validated Architecture modules, some further Applied SVAs are now available. These are designed to build upon the SVAs to provide more complex examples of deployments or use cases using one or more SVAs. These can be used to further assist the building of systems based on best practices, and ensuring that they are implemented using the core Validated Architectures.

The SVA relaunch seeks to deliver all the benefits of the original SVAs and improve upon them in the following ways.

• Modular: Topics are self contained in modules that can be used on their own or pieced together to satisfy more complex requirements and use cases.
• Community Oriented: Docs feedback is now captured from the broader Splunk community for review and incorporation to help keep you up to date with the latest guidance.
• Expanded: New modules, architectures and approaches to help scale your Splunk deployment..
• Applied designs: New Applied SVAs giving broader solution focus encompassing one or more SVAs.

Reasons to use Splunk Validated Architectures

Implementing a validated architecture will empower you to design and deploy Splunk software more confidently. SVAs will help you solve some of the most common challenges that organizations face, including:

• Performance: Organizations want to see improvements in performance and stability.
• Complexity: Organizations sometimes run into the pitfalls of custom-built deployments, especially when they have grown too rapidly or organically. In such cases, unnecessary complexity may have been introduced into the environment. This complexity can become a serious barrier when attempting to scale.
• Efficiency: To derive the maximum benefits from the Splunk software deployment, organizations must improve the efficiency of operations and accelerate time to value.
• Cost: Organizations are seeking ways to reduce total cost of ownership (TCO), while fulfilling all of their requirements.
• Agility: Organizations will need to adapt to change as they scale and grow.
• Maintenance: Optimization of the environment is often necessary in order to reduce maintenance efforts.
• Scalability: Organizations must have the ability to scale efficiently and seamlessly.
• Verification: Stakeholders within the organization want the assurance that their Splunk software deployment is built on best practice.

What to expect from Splunk Validated Architectures

SVAs do not include deployment technologies or deployment sizing. The reasoning for this is as follows:

• Deployment technologies, such as operating systems and server hardware, are considered implementation choices in the context of SVAs. Different customers will have different choices, so a generalization is not easily possible.
• Deployment sizing requires an evaluation of data ingest volume, data types, search volumes and search use cases, which tend to be very customer-specific and generally have no bearing on the fundamental deployment topology. When you are ready, please reach out to Splunk for help with properly sizing your deployment based on your expected ingest and search workload profile.

Summary of current SVA Guidance

SVAs provide:

SVAs do not provide:

Clustered and non-clustered deployment options Diagrams of the reference architecture Guidelines to help you select the architecture that is right for you Tier-specific recommendations. Best practices for building out your Splunk deployment Best practices for connecting to Splunk Cloud

Implementation choices (OS, bare metal vs. virtual vs. Cloud etc.). Deployment sizing. A prescriptive approval of your architecture. Note: SVAs provide recommendations and guidelines, so you can ultimately make the right decision for your organization. A topology suggestion for every possible deployment scenario. In some cases, unique factors may require a custom architecture to be developed. Splunk experts are available to help with any custom solutions you need. If you are an existing customer, reach out to your Splunk Account Team. If you are new to Splunk, you can reach us here.

Pillars of Splunk Validated Architectures

Splunk Validated Architectures are built on the following foundational pillars. For more information on these design pillars, refer to the next section.

Availability	Performance	Scalability	Security	Manageability
The system is continuously operational and able to recover from planned and unplanned outages or disruptions.	The system can maintain an optimal level of service under varying usage patterns.	The system is designed to scale on all tiers, allowing you to handle increased workloads effectively.	The system is designed to protect data, configurations, and assets while continuing to deliver value.	The system is centrally operable and manageable across all tiers.

These pillars are in direct support of the Platform Management & Support Service in the Splunk Center Of Excellence model.

SVA pillars explained

Pillar	Description	Primary Goals / Design Principles
Availability	The ability to be continuously operational and able to recover from planned and unplanned outages or disruptions.	Eliminate single points of failure / add redundancy Detect planned and unplanned failures/outages Tolerate planned/unplanned outages, ideally automatically Plan for rolling upgrades
Performance	The ability to effectively use available resources to maintain optimal level of service under varying usage patterns.	Add hardware to improve performance; compute, storage, memory Eliminate bottlenecks 'from the bottom up' Exploit all means of concurrent processing Exploit locality (i.e. minimize distribution of components) Optimize for the common case (80/20 rule) Avoid unnecessary generality Time shift computation (pre-compute, lazily compute, share/batch compute) Trade certainty and accuracy for time (randomization, sampling)
Scalability	The ability to ensure that the system is designed to scale on all tiers and handle increased workloads effectively.	Scale vertically and horizontally Separate functional components that need to be scaled individually Minimize dependencies between components Design for known future growth as early as possible Introduce hierarchy in the overall system design
Security	The ability to ensure that the system is designed to protect data as well as configurations/assets while continuing to deliver value.	Design for a secure system from the start Employ state-of-the art protocols for all communications Allow for broad-level and granular access to event data Employ centralized authentication Implement auditing procedures Reduce attack or malicious use surface area
Manageability	The ability to ensure the system is designed to be centrally operable and manageable across all tiers.	Provide a centralized management function Manage configuration object lifecycle (source control) Measure and monitor/profile application (Splunk) usage Measure and monitor system health