Mixing workloads in a cluster

Organize nodes that run different workloads into virtual data centers. Put analytic nodes in one data center, search nodes in another, and Cassandra real-time transactional nodes in another data center.

A common question is how to use the following types of nodes in the same cluster:
  • Real-time Cassandra,
  • DSE Hadoop, which is integrated Hadoop
  • External Hadoop in the bring your own Hadoop (BYOH) model
  • Spark
  • DSE Search nodes

The answer is to organize the nodes running different workloads into virtual data centers: analytics workloads (either DSE Hadoop, Spark, or BYOH) nodes in one data center, search nodes in another, and Cassandra real-time nodes in another data center.

DataStax supports a data center that contains one or more nodes running in dual Spark/DSE Hadoop mode. Dual Spark/DSE Hadoop mode means you started the node using the -k and -t options on tarball or Installer-No Services installations, or set the startup options HADOOP_ENABLED=1 and SPARK_ENABLED=1 on package or Installer-Services installations.

Spark workloads

In light Spark workloads, you can run real-time workloads in a Spark datacenter. However, if Spark jobs are resource intensive, use a dedicated data center for Spark. Spark jobs consume resources that can affect the latency and throughput of Cassandra jobs or Hadoop jobs. When you run a node in Spark mode, Cassandra runs an Analytics workload. An integrated DSE SearchAnalytics cluster allows analytics jobs to be performed using search queries.

BYOH workloads

BYOH nodes need to be isolated from Cloudera or Hortonworks masters.

DSE Search workloads

The batch needs of Hadoop and the interactive needs of DSE Search are incompatible from a performance perspective, so these workloads need to be segregated.

Cassandra workloads

To keep Cassandra write throughout at the maximum performance, segregate Cassandra workloads and DSE Search workloads.

Creating a virtual data center 

When you create a keyspace using CQL, Cassandra creates a virtual data center for a cluster, even a one-node cluster, automatically. You assign nodes that run the same type of workload to the same data center. The separate, virtual data centers for different types of nodes segregate workloads running Solr from those running other workload types. Segregating workloads ensures that only one type of workload is active per data center.

Workload segregation 

Separating nodes running a sequential data load, from nodes running any other type of workload is a best practice. In the following diagram, nodes in separate data centers run a mix of:
  • Real-time queries (Cassandra and no other services)
  • Analytics (either DSE Hadoop, Spark, or dual mode DSE Hadoop/Spark)
  • Solr
  • External Hadoop system (BYOH)


In a cluster having BYOH and DSE Hadoop nodes, the DSE Hadoop nodes would have priority with regard to start up. Start up seed nodes in the BYOH data center after starting up DSE Hadoop data centers.

Occasionally, there is a use case for keeping DSE Hadoop and Cassandra nodes in the same data center. You do not have to have one or more additional replication factors when these nodes are in the same data center.

To deploy a mixed workload cluster, see "Multiple data center deployment."

In this diagram, nodes in data centers 1 and 2 (DC 1 and DC 2) run a mix of:
  • Real-time queries (Cassandra and no other services)
  • Analytics (Cassandra and integrated Hadoop)
Data centers 3 and 4 (DC 3 and DC 4) are dedicated to search.


This diagram shows DSE Hadoop analytics, Cassandra, and DSE Search nodes in separate data centers. In separate data centers, some DSE nodes handle search while others handle MapReduce, or just act as real-time Cassandra nodes. Cassandra ingests the data, Solr indexes the data, and you run MapReduce against that data in one cluster without performing manual extract, transform, and load (ETL) operations. Cassandra handles the replication and isolation of resources. The DSE Search nodes run HTTP and hold the indexes for the Cassandra table data. If a DSE Search node goes down, the commit log replays the Cassandra inserts, which correspond to Solr inserts, and the node is restored automatically.

Restrictions 

  • Do not create the keyspace using SimpleStrategy for production use or for use with mixed workloads.
  • Within the same data center, do not run Solr workloads on some nodes and other types of workloads on other nodes.
  • Do not run DSE Search and DSE Hadoop on the same node in either production or development environments.
  • Do not run some nodes in DSE Hadoop mode and some in Spark mode in the same data center.

    You can run all the nodes in Spark mode, all the nodes in Hadoop mode or all the nodes in Spark/DSE Hadoop mode.

Recommendations

Run the CQL or Thrift inserts on a DSE Search node in its own data center.

NetworkTopologyStrategy is highly recommended for most deployments because it is much easier to expand to multiple data centers when required by future expansion.

Getting cluster workload information 

You can query the Cassandra system.peers table to get the types of workloads running on cluster nodes except the coordinator. The different workloads are:
  • Analytics
  • Cassandra
  • Search
An Analytics workload is either DSE Hadoop, Spark, or dual mode DSE Hadoop/Spark. A Cassandra workload is Cassandra and no other services. A Search workload is DSE Search.
You can also query the system.local table to get the type of workload running on any local node. This tables has a column of workload data that Cassandra does not include in the output when you select all the data. You need to explicitly query the workload column.
SELECT workload FROM system.local;

The output looks something like this:

 workload 
----------
 Analytics
Using the DESCRIBE FULL schema command reveals the definitions of all the columns. For example:
DESCRIBE FULL schema
The output shows the system and other table schemas. For example, the peers table schema is:
CREATE TABLE peers (
  peer inet,
  data_center text,
  host_id uuid,
  preferred_ip inet,
  rack text,
  release_version text,
  rpc_address inet,
  schema_version uuid,
  tokens set<text>,
  workload text,
  PRIMARY KEY ((peer))
) WITH
  . . .;

Replicating data across data centers 

You set up replication by creating a keyspace. You can change the replication of a keyspace after creating it.