Indexer Cluster and Search Head Cluster with Datamodel Acceleration

[pedromvieira]

Hello There.

Even if all the docs and certifications, it's not clear how is the best (or only way) of doing Datamodel Acceleration in a Full Clustered Environment.

We have a Indexer Cluster with 3 Indexers and a Search Head Cluster with 3 Search Heads connected.
They all have the last Splunk version.

Currently, a few datamodel accelerations are not working as intended.

We have them both configured (json) and accelerated (datamodels.conf) in Indexer Cluster and in Search Head Cluster.

In Indexers, all working with their primary copy of the data. In Search Head Cluster it stuck in "Building", and from time to time it stop updating.

All users and searches are done in the Search Head Cluster (99% with a virtual IP).

Regarding Datamodel Acceleration and tstats/pivot accelerated searchs, whats the best practice.

Do we need to declare datamodel (json) in both indexer cluster and search head cluster?
Do we need to accelerate it (datamodels.conf) in both indexer cluster and search head cluster?
Where the data will reside? Only at indexer?

Is it best to schedule update or do it automatically?

Thanks.

[Steve_G_]

Also, see this topic regarding data model acceleration and indexer clusters:

http://docs.splunk.com/Documentation/Splunk/6.5.0/Indexer/Clustersandsummaryreplication

[mikaelbje]

Hi,

1. Do not enable acceleration on any Indexer. In general apps that have data models defined should not be deployed to Indexers
2. Deploy apps/TAs with acceleration ONLY to Search Head Cluster Peers. The peers will make sure that the acceleration isn't done multiple times
3. All Search Head Cluster Peers should be set up with an outputs.conf that forwards all data to indexers. This is very important, otherwise the accelerated Data Models will be local to each Search Head Cluster Peer. You can deploy this outputs.conf file through an app in the shcluster/apps folder.

If you are building custom apps with your own DMs, make sure you split them into two apps. An "app" part with views, dashboards and the data model. The other is the TA (Technology Add-on) part which includes index time transforms and also field extractions. The first should only be deployed to Search Heads, the latter should reside on both Indexers and Search Heads.
For an example, take a look at my Cisco Networks app and Cisco Networks Technology Add-on, available at Splunkbase.

[rjthibod]

^ everything he said. Here is another link to back it up. http://docs.splunk.com/Documentation/Splunk/6.5.0/DistSearch/Forwardsearchheaddata

[mwk1000]

Summary indexing would require an outputs.conf but persistent data model acceleration actually does not since nothing is indexed. The data model buckets are built via the scheduled search so having them as search peers is enough to get the buckets built. ( Lab setups etc ) In general a complete setup would do both but it's not necessary for simply building the accelerations on the indexers.

[mwk1000]

-- This was confirmed in a lab by pointing the outputs to lab indexers while using a different set of indexers as search peers. All DM buckets are built fine on search peers and are usable for pivot searches. All DM buckets are segregated by search head group (GUID) so the are isolated from impacting other search clusters you just add up more storage for each search group ( standalone/pool/cluster) and more running searches on your search peers.