Cassandra Consolidation and Management Challenge
Low Utilization and Lack of Consolidation – Cassandra clusters are, typically, created per use case. In fact, the common practice is to give each team its own cluster. This would be an acceptable practice if clusters weren’t deployed on dedicated physical servers. To avoid performance issues, most enterprises stay away from virtual machines. This means that underlying hardware has to be sized for peak workloads, leaving large amounts of spare capacity and idle hardware due to varying load profiles.
Complex Cluster Lifecycle & Fault Tolerance – Given the need for physical infrastructure (compute, network and storage), provisioning Cassandra clusters on-premise can be time-consuming. The challenge here is estimating the read and write performance that will be delivered by the designed configuration, which will require extensive testing and experimentation.
The other key planning exercise is for node failures. Failures are the norm and have to be planned for from the get go. While Cassandra is designed to withstand temporary node failures, it still has to be resolved by adding replacement nodes, and it poses additional load on the remaining nodes for data rebalance – post failure and again post addition of new nodes.
Manual Backups and Restore – Unlike traditional databases such as Oracle, DB2, or SQL Server, newer databases like Cassandra are still limited in its tooling. For example, Cassandra does not come with utilities that automatically back up the database. It only offers backup in terms of snapshots and incremental copies, but they are quite limited in features and have to be done per node. Similarly, data recovery is fairly involved, and requires manual steps on every node of the cluster.
The other challenge with large databases is cloning them for dev and test use. Traditional techniques are time-consuming and require significant amounts of storage — thus restricting agility, which is increasingly becoming one of the key requirements for DevOps.
Costly Scaling – With Cassandra’s ability to scale linearly, most administrators are quite accustomed to adding nodes (or scale out) to expand the size of clusters. With each node you gain additional processing power and data capacity. But while node addition is good for steady increases in load, how does one deal with transient spikes? Administrators need the ability simply add and remove resources dynamically and at real time to their databases to deal with temporary load variations.
Simple application & data lifecycle management
Robin Application Virtualization Platform brings bare-metal-like performance, retains virtualization benefits, enables significant cost savings—all from the same management layer.
Robin is a container-based, application-centric, server and storage virtualization platform software which turns commodity hardware into a high-performance, elastic, and agile application/database consolidation platform. Robin is designed to cater to not just stateless, but also performance and data-centric applications such as databases and Big Data clusters.
Robin dramatically simplifies application and data lifecycle management with features such as one-click database deploy, snapshot, clone, time travel, dynamic IOPS control, and performance guarantees.
Apache cluster & Datastax OpsCenter on Robin
Users interact with Robin entirely at the application level and provision as well as manage the underlying infrastructure transparently.
Cassandra Consolidation Across Physical and Virtual Environments
Consolidation and Product Benefits – Partha Seetala, CTO
Robin’s container-based, application-aware, compute and storage platform liberates databases from servers, VMs, and storage limitations. The Robin software transforms commodity hardware into a compute, storage, and data continuum such that multiple databases can be deployed per machine, ensuring the best possible hardware utilization.
1-click, rapid, self-service Cassandra deployment
Provision Cassandra database
Robin platform enables users to deploy Cassandra with a single click, as opposed to the tedious deployment schedules currently required. Users can get out-of-the-box images for Cassandra and manage ten times faster deployment. Robin enables quick scale-up or scale-down by adding or removing extra resources. The platform also enables users to scale in/out across nodes.
Guaranteed Availability and App-to-Spindle Performance
Cassandra: App-to-Spindle QoS
Robin’s unique App-to-Spindle Quality-of-Service Guarantee ensures multi-tenant harmony and complete performance isolation for each Cassandra database. And by leveraging lightweight and portable container-based database packaging technology, Robin enables seamless database mobility across machines to cater to changing workload demands of the application.
Time Travel for Cassandra
Cassandra: Snapshots, Time Travel
Robin provides out of the box support for application time travel. Application snapshots at certain intervals can be really useful to restore back the entire application if anything goes wrong. Robin recommends admins to take snapshots before making any major application changes. If you are applying a Cassandra database patch or making a configuration change make sure to keep a snapshot. If anything goes wrong the application can be restored to the last known snapshot in a few minutes.