The possibility of scale and high availability for a Cassandra database in an HCI 2.0 configuration brings greater potential for cost savings and management simplicity over a bare metal configuration.  

The well-known and well-understood scale-out database, named Cassandra, is today a common application run by many enterprises, large and small.  It is one of the Apache Software Foundation open-source software offerings, and as such, has been widely adopted.

Cassandra, like several other Apache offerings, was originally conceived and designed to run across a collection of servers (or ‘nodes’) each with its own storage (disks), using clustering methods to distribute the data and guard against failures.  Hadoop, another well-known Apache offering, began over a decade ago this way as well.  However, very few enterprises have dared to attempt to run Cassandra on HCI infrastructure, especially with virtual machines, for very good reason.  It has been extremely difficult to get Cassandra to either scale or realize high availability on HCI – which, after all, are the two main reasons to adopt Cassandra in the first place.  Scalability and availability have always been primary rationales for Cassandra implementations, compared to other databases.  In addition, performance on HCI has not been adequate, relative to the ‘traditional’ implementation of scale-out bare-metal servers.  So, Cassandra has been relegated to the domain of rack(s) of bare-metal servers, with additional performance only being realized by adding yet more servers.

HCI 2.0

HCI 2.0 is the missing link for Cassandra

However, today there is an HCI approach that’s not only delivering the scalability and high availability inherent in the Cassandra approach (which this blog will not detail; see the aforementioned website for a ‘Cassandra 101’ tutorial), but also is architected for maximum performance as seen by Cassandra users.  For transactions, which are the primary operation in the database, this means low average and low ‘tail’ (defined as high percentile, such as 99%) latencies, high system throughput, and high transactions/second rates (both read and write).  This approach is known as HCI 2.0, or second-generation HCI, fundamental to which is the opposite approach to traditional Apache design.  In that, large collections of relatively low-end servers with a handful of disks each are tied together, using LAN technology and software clustering/scale-out techniques, such as sharding.

This approach is used by many industries today, such as telecom, retail, content delivery, and several others, all of which have databases which are growing and under 24×7 operations.  However, the cost and complexity of scaling out traditional bare-metal Cassandra clusters rises non-linearly with node count, forcing a self-limiting implementation.  These industries also often add auxiliary servers to the cluster, for example running memcached in an attempt to reduce query latency.  Again, this forces more cost and complexity than is optimal.

HCI 2.0 takes the opposite approach – instead of large (high node count) clusters of mediocre servers connected by low-bandwidth networks, there are small (low node count) clusters of powerful, dense servers with high core counts and high-bandwidth networks.  In addition, and most importantly, these servers have very high storage density – which is the key to ensuring Cassandra maintains its capability of high scalability and availability, while also delivering maximum performance for database operations, both transactions and ‘managerial’ (non-transactional) operations such as key-space cleanup, compaction, compression, and the like.

At this point, rather than embark on a long discussion of what comprises such dense servers, it’s best to refer to the “HCI Buyers Guide” which is a comprehensive description of what a proper HCI 2.0 server must contain in order to deliver on the promise of efficient Cassandra implementations.  In the second part of this blog, we’ll discover why Cassandra runs much more efficiently on HCI 2.0 than on traditional bare-metal scale-out, and why it’s time to move Cassandra to its rightful place as an application perfectly amenable to running on virtual machines.

In the meantime, check out our whitepaper, “How to Reduce the Cost of HCI,” to learn how to eliminate escalating costs and why hardware in HCI matters!




We use cookies to offer you a better browsing experience. By using our site, you consent to the use of cookies. Learn more about how we use cookies in our privacy policy.