Are you one of our many customers who is transitioning from Splunk classic architecture to the new Splunk SmartStore? Or are you starting out as a new SmartStore user, ready to take advantage of all that it offers? Splunk and NetApp have completed official certification for multisite architectures based on Splunk SmartStore and NetApp® StorageGRID ® object storage. So no matter where you are in your journey, you can be sure that the solution will deliver an industry-leading object storage solution for your Remotestore tier.

Splunk SmartStore is a deployment architecture that delivers several important benefits. In addition to bringing data closer to compute on demand, it provides a high degree of compute/storage elasticity and makes it amazingly cost efficient to achieve longer data retention at scale. For full details, check out the Splunk SmartStore blog.

SmartStore leverages object storage to create Splunk's remote storage data repository. Splunk chose object storage because of its massive scale and global namespace capabilities. When you architect your SmartStore solution, it's important to keep these three design principles in mind:

  • Performance at scale.
  • Fast recovery at scale.
  • And most importantly, place content in the right location, at the right time, and on the right storage tier.

Although StorageGRID is not the only object storage solution supported for SmartStore, it has distinct advantages that work well with those three design principles:

  • True global name space with active/active multisite replication.
  • Powerful information lifecycle management (ILM) policy engine. Automatically place data in the selected media, data center, and/or protection scheme.
  • Unmatched durability. Achieve 15 nines of durability, leveraging dual-layered erasure coding.
  • Scalable architecture. Support up to 200 billion objects and more than 560PBs in a single namespace.

As part of our certification process, we evaluated the following use cases:

  • Remote object storage failure at site 1 and continuing operations on site 2 by ingesting and searching data and then recovering Remotestore at site 1.
  • Splunk site 1 failure and continuing operations on site 2 by ingesting and searching data and then recovering Splunk site 1.
  • Migrating from Splunk classic index to SmartStore index.

This is how our Splunk SmartStore test was configured:

  1. We set up a 2-site Splunk and StorageGRID architecture.
  2. We created a simple 2-site data protection policy on StorageGRID to ensure that we had one copy of our data at each site, no matter which site originally ingested the data.
  3. We ingested data (created using Splunk Eventgen) to Splunk indexes/hot tier.

Here are the key takeaways we learned through the process.

StorageGRID is fast

When it comes to ingest and search latency, a user with an architecture based on Splunk SmartStore and NetApp StorageGRID does not have to compromise on performance. StorageGRID is optimized for high-performance object storage workloads like Splunk.

StorageGRID is resilient

StorageGRID automatically replicates and ensures that data is protected on each site. Because both sites are active/-active, there's no waiting for the secondary site to be 'active.' And there's no reversing replication when resuming operations. All the management of the failure and recovery is handled automatically by StorageGRID. As one NetApp customer, Hyland, stated at NetApp INSIGHT® 2020, 'With StorageGRID you get DR for free.' Watch the video, Hyland Scales Ops, Simplifies DR: StorageGRID & Splunk SmartStore.

StorageGRID architecture is easy to scale

Scaling is simple for architectures based on Remotestore and StorageGRID. Whether it's scaling for improved performance, capacity, or bandwidth, adding new sites or more nodes to an existing site is completely nondisruptive to your Splunk workload.

For full information about the Splunk SmartStore solution, check out technical report TR-4869, NetApp StorageGRID with Splunk SmartStore. And see what Hyland says about using StorageGRID for SmartStore. Contact your NetApp team for a deep dive into this solution.

Attachments

  • Original document
  • Permalink

Disclaimer

NetApp Inc. published this content on 22 June 2021 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 22 June 2021 17:34:06 UTC.