• Technical
Instaclustr: What’s New Feb 2016

After a little bit of a slow down over the Christmas period and summer holidays here in Australia, the Instaclustr development team was back in full swing in February. Some of the key changes that we released in the month were:

  • Improvements in column family information in our monitoring page: we now include disk space used by column family as well as rationalising the different set of data and providing the option to group by node. This is part of our project to fully replace OpsCenter now that Datastax have announced OpsCenter will not be available for open source Cassandra from 2.2 onwards.
  • Spark High Availability: Spark clusters are now automatically provisioned with multiple Spark Masters and we have a central Zookeeper cluster that manages the election process to choose a single master and fail-over when required. We were happy to go with a dependency on a central Zookeeper cluster as with 5 Zookeeper nodes we expect it to be very highly available and Zookeeper only impacts Spark service availability if it is unavailable during initial startup or failure of a Spark master.
  • Cassandra 2.2.5 now available with full production support: we have now been running Cassandra 2.2 for a couple of months and with the latest release are pleased to provide full SLAs and production support. Cassandra 2.2 is a significant change so we recommend complete regression testing in a non-production environment before upgrading.
  • Released Cassandra 2.1.12, 2.1.13
  • Upgraded our internal monitoring system to a horizontally scalable architecture: with the growth in our number of nodes under management, we have been working through our architecture ensure all components are horizontally scalable for high availability and to meet the needs of potential future growth. Look out for some interesting blog posts from this work in the coming weeks.
  • Repair enhancements: now we have been running incremental repairs with Cassandra 2.1 for a while, we’ve realised that more frequent, smaller repairs is the right strategy. As a result, we’ll be changing the default frequency for incremental repairs to daily (rather the the current weekly) and have the ability for our support staff to further tune the frequency of repairs if necessary.
  • Instaclustr through Heroku now available in Europe: Instaclustr’s development nodes are now available through Heroku in Eupore and for selected regions on Heroku’s private space offering. Our very popular EBS-based node sizes are also now available through Heroku.

The team is now back in full swing after the summer period so look out for some exciting new features in the coming weeks and months.