NetApp Closes Acquisition of Instaclustr Read the announcement
Service-Level Agreements

Effective Date: 28-Oct-2021

Cassandra Services

Instaclustr’s service standards are tiered based on the size of the Cassandra cluster that our customer is running. The tiers recognize that larger clusters are able to support more consistent levels of performance and availability.

Tier1Service Standards2Customer Requirements
Starter

Developer Nodes

  • No guaranteed availability4 (99.9% target)
  • No latency3 SLAs
  • Minimum replication of 2 on all keyspaces
  • Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Cassandra usage
Small
<=5 production nodes
  • 99.95% availability for LOCAL_QUORUM
  • No latency SLAs
  • 20% monthly fees at risk in total; 10% credit for each breach
  • Minimum replication factor of 3 on all keyspaces

(please ensure that cluster is initially configured with target RF of 3)

  • Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Cassandra usage
Enterprise
6+ production nodes
  • 99.99% availability for LOCAL_QUORUM consistency operations
  • 99% of read/write transactions to Instaclustr-maintained table in the cluster within specified latency threshold3
  • 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
  • Minimum replication factor of 3 on all keyspaces (please ensure that cluster is initially configured with target RF of 3)
  • Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Cassandra usage
Critical
12+ production nodes
  • 100% availability for LOCAL_QUORUM consistency operations
  • Custom latency SLA negotiable (or use medium SLA)3
  • 100% of monthly fees at risk in total; 30% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
  • Minimum replication factor of 5 on all keyspaces

(please ensure that cluster is initially configured with target RF of 5)

  • Separate testing and production clusters
  • Customer notifies that they wish to receive this SLA, commissions Instaclustr to review their application for best practice alignment and actions finding from that review
  • Instaclustr review prior to deploying changes that may impact latency SLA
  • Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Cassandra usage

For Enterprise and Critical level Cassandra clusters we also provide Recovery Point Objective SLA: The native replication of data in Cassandra means restoration of data from backups is very rarely required. However, we will maintain backups to allow restoration of data with less than 24 hours data loss for standard backups and less than 5 minutes data loss for our Continuous Back-ups option. Should we fail to meet this recovery point objective, you will be eligible for SLA credits at 100% of monthly fees for the relevant cluster.  If you have undertaken to restore testing of your cluster in the last 6 months (using our automated restore functionality) and can demonstrate that data loss during an emergency restore is outside target RPO and your verification testing, then you will be eligible for SLA credits at 500% of monthly fees.

Kafka Services

Instaclustr’s service standards are tiered based on the size of the Kafka cluster that our customer is running. The tiers recognize that larger clusters are able to support more consistent levels of performance and availability.

Tier1Service Standards2Customer Requirements
Starter11,18
Developer Nodes
  • No guaranteed availability4 (99.9% target)
  • No latency3 SLAs
  • Minimum replication of 2 on all topics
  • Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations as less than 80%
  • Comply with reasonable requests from Instaclustr to modify application for best practice Kafka usage
Small17
<=5 production nodes
  • 99.95% availability for writes with 2 replica consistency requirement and all reads
  • No latency SLAs
  • 20% monthly fees at risk in total; 10% credit for each breach
  • PrivateLink availability of 99.99%
  • Minimum replication of 3 on all topics
  • Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations as less than 80%
  • Comply with reasonable requests from Instaclustr to modify application for best practice Kafka usage
Enterprise17
6+ production nodes
  • 99.99% availability for writes with 2 replica consistency requirement and all reads
  • Availability SLA is increased to 99.999% when dedicated ZooKeeper nodes are used
  • 99% of read/write transactions to Instaclustr-maintained topic in the cluster within specified latency threshold3
  • 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
  • PrivateLink availability of 99.99%
  • Minimum replication factor of 3 on all topics
  • Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 80%
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Kafka usage
Critical17
12+ production nodes
  • 99.999% availability for writes with 2 replica consistency requirement and all reads
  • 99% of read/write transactions to Instaclustr-maintained topic in the cluster within specified latency threshold3
  • 100% of monthly fees at risk in total; 30% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
  • PrivateLink availability of 99.99%
  • Minimum replication factor of 3 on all topics
  • Separate testing and production clusters
  • Must use dedicated ZooKeeper nodes for production
  • Customer notifies that they wish to receive this SLA, commissions Instaclustr to review their application for best practice alignment and actions findings from that review
  • Instaclustr review prior to deploying changes that may impact latency SLA
  • Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 80%
  • Comply with reasonable requests from Instaclustr to modify application for best practice Kafka usage

Kafka Connect Services

Instaclustr’s service standards are tiered based on the size of the Kafka Connect cluster that our customer is running. The tiers recognize that production clusters are able to support more consistent levels of performance and availability.

Tier1Service Standards2Customer Requirements
Starter11 Developer Nodes
  • No guaranteed availability(99.9% target)
  • Add capacity as reasonably requested by Instalcustr to manage operational loads.
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Kafka Connect usage
Production Nodes
  • 99.99% availability8 to Instaclustr maintained synthetic transaction connector
  • 20% monthly fees at risk in total; 10% credit for each breach
  • Minimum of 3 nodes
  • Add capacity as reasonably requested by Instalcustr to manage operational loads.
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Kafka Connect usage

Redis Services

Instaclustr’s service standards are tiered based on the class of the Redis cluster that our customer is running. The tiers recognise that production clusters are able to support more consistent levels of performance and availability.

Tier1 Service Standards2Customer Requirements
Starter

Developer Nodes

  • No guaranteed availability (99.9% target)
  • No latency3 SLAs
  • Add capacity as reasonably requested by Instalcustr to manage operational loads.
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Redis usage
Enterprise

6+ production nodes

  • 99.99% availability9 to Instaclustr maintained synthetic transaction
  • 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
  • The number of Redis Replica Nodes is greater than or equal to the number of Redis Master Nodes
  • Add capacity as reasonably requested by Instalcustr to manage operational loads.
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Redis usage

ZooKeeper Services

Instaclustr’s service standards are tiered based on the class of the Apache ZooKeeper cluster that our customer is running. The tiers recognise that production clusters are able to support more consistent levels of performance and availability.

Tier1 Service Standards2Customer Requirements
Starter

Developer Nodes

  • No guaranteed availability (99.9% target)
  • No latency3 SLAs
  • Add capacity as reasonably requested by Instalcustr to manage operational loads.
  • Comply with reasonable requests from Instaclustr to modify the application for best practice ZooKeeper usage
Enterprise

3 or more production nodes

  • 99.99% availability 10
  • No latency3 SLAs
  • 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
  • Add capacity as reasonably requested by Instalcustr to manage operational loads.
  • Comply with reasonable requests from Instaclustr to modify the application for best practice ZooKeeper usage

PostgreSQL Services

Instaclustr’s service standards for PostgreSQL are tiered based on the size, and number of nodes in the PostgreSQL cluster that our customer is running. The tiers recognize that production instances are able to support a more consistent level of performance and availability.

Tier Service StandardsCustomer Requirements
Starter

(Developer Nodes)

  • No guaranteed availability (targeting 99.95%^12)
  • No latency SLAs
  • Add capacity as reasonably requested by Instalcustr to manage operational loads.
  • Configure cluster replication and query settings which are appropriate for their data loss tolerance ^13
  • Comply with reasonable requests from Instaclustr to modify the application for best practice PostgreSQL usage
  • Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
Enterprise

2+ production nodes, or 3+ If utilising synchronous mode strict

  • 99.99%^12  availability for read and write operations
  • 99.9%^3 of read/write transactions to Instaclustr-maintained table in the cluster within specified latency threshold
  • 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
  • Add capacity as reasonably requested by Instalcustr to manage operational loads.
  • Comply with reasonable requests from Instaclustr to modify the application for best practice PostgreSQL usage
  • Configure cluster replication and query settings which are appropriate for their data loss tolerance ^13
  • Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%

**Availability uptime is not inclusive of one 30 minute scheduled maintenance window per month. Customers will be notified of scheduled maintenance at least 7 days in advance, and Instaclustr will make all reasonable attempts to minimise the impact to your availability. 

OpenSearch Services

Instaclustr’s service standards are tiered based on the size of the OpenSearch14 cluster that our customer is running. The tiers recognise that larger clusters are able to support more consistent levels of performance and availability.

Tier1 Service Standards2Customer Requirements
Starter

Developer Nodes

  • No guaranteed availability (99.9% target)
  • No latency3 SLAs
  • Minimum of one replica shard on all indices
  • Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
  • Comply with reasonable requests from Instaclustr to modify application and index settings for best practice OpenSearch usage
Small

<6 production nodes

  • 99.95% availability15 for search and index operations, where wait_for_active_shards is 2 or less
  • No latency SLAs
  • 20% monthly fees at risk in total; 10% credit for each breach
  • Minimum of 2 replica shards on all indices
  • Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
  • Comply with reasonable requests from Instaclustr to modify the application and index settings for best practice OpenSearch usage
Enterprise

6+ production nodes

  • 99.99% availability15 for search and index operations, where wait_for_active_shards is 2 or less
  • 95% of index/search operations to Instaclustr-maintained Index in the cluster within specified latency threshold3
  • 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing breach of latency SLA
  • Minimum of 2 replica shards on all indices
  • Use dedicated masters
  • Add capacity or adjust retention settings when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
  • Comply with reasonable requests from Instaclustr to modify the application and index settings for best practice OpenSearch usage
Critical

12+ production nodes

  • 99.999% availability15 for search and index operations, where wait_for_active_shards is 2 or less
  • 99% of index/search operations to Instaclustr-maintained index in the cluster within specified latency threshold3
  • 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing a breach of latency SLA
  • Minimum of 2 replica shards on all indices
  • Use dedicated masters
  • Separate testing and production clusters
  • Customer notifies that they wish to receive this SLA, commissions Instaclustr to review their application and index settings for best practice alignment and actions findings from that review
  • Instaclustr review prior to deploying changes that may impact latency SLA
  • Add capacity or remove data when requested by Instaclustr to maintain disk usage in normal operations at less than 70%
  • Comply with reasonable requests from Instaclustr to modify the application for best practice OpenSearch usage.

 

Cadence Services

Instaclustr’s service standards are tiered based on the size of the Cadence and dependent clusters that our customer is running. The tiers recognize that production clusters are able to support more consistent levels of performance and availability.

Tier Service StandardsCustomer Requirements
Starter

(Developer Size Nodes)

  • No guaranteed availability (99.9% target)
  • No latency SLAs
  • Add capacity as reasonably requested by Instalcustr to manage operational loads.
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Cadence usage.
  • Comply with requirements for Starter level SLAs for dependency services (Cassandra, Kafka, OpenSearch)
Production

3+ Production size nodes for each of Cadence and its dependency service clusters

  • 99.95% availability as measured by Instaclustr synthetic transaction monitoring
  • 30% of monthly fees at risk in total; 15% credit for each incident causing breach of availability SLA and 10% credit for each incident causing a breach of latency SLA
  • Add capacity as reasonably requested by Instalcustr to manage operational loads.
  • Comply with reasonable requests from Instaclustr to modify the application for best practice Cadence usage
  • Comply with requirements for at least Small level SLAs for dependency services (Cassandra, Kafka, OpenSearch)

 

  1. SLA tier is per-cluster and based on the number of nodes in the cluster. Customer credits are calculated based on the fees payable for the cluster or clusters impacted by the incident. SLAs credits apply to production clusters only.
  2. Service levels are measured on a monthly basis based on Instaclustr’s monitoring systems. All service levels exclude outages caused by non-availability of service at the underlying cloud provide region level or availability zone level in regions which only support two availability zones.
  3. Latency is measured at a minimum rate of one read/write pair per node per 20 second period. Latency SLA excludes incidents where the cause is determined to be changes to a customer’s application or unusually high loads on the cluster.
  4. Availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one read/write pair per node per 20 second period. A cluster is considered to be unavailable where read/write operations fail for a majority of nodes in the cluster in a given check-in period.
  5. Where a customer meets requirements for a tier based on cluster size but does not meet other requirements for a tier, the highest level of SLA where all requirements are met will apply.
  6. All SLAs exclude issues caused by customer actions including but not limited to attempting to operate a cluster beyond available processing or storage capacity.
  7. SLA credits must be claimed by customers within 14 days of the end of the relevant calendar month.
  8. For Kafka Connect, availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one Connector read or write operation per cluster per 20 second period. Excludes issues caused by BYO Kafka Connect Connectors due to the potential impact of user code on the availability of these environments.
  9. For Redis, availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one read or write operation per cluster per 20 second period. Excludes latency issues caused by the use of integrated Lua scripting (EVAL and EVALSHA). Excludes issues caused by customers executing commands marked as “dangerous” by the Redis project (turning on authentication will restrict access to these commands). Details of these commands can be found here.
  10. For ZooKeeper, availability is measured by establishing a connection with the ZooKeeper server on each node using a local ZooKeeper client, on a per node per 20 second basis.
  11. For preview versions of Kafka and Kafka Connect, only their respective “Starter” tier SLAs are valid. Production usage may be brought under an agreed SLA for the GA version after joint testing. Please contact us if you wish to discuss this option.
  12. PostgreSQL availability is measured by Instaclustr’s synthetic monitoring at a minimum rate of one read/write pair per node per 20 second period. A cluster is considered to be unavailable where read/write operations fail for all nodes in the cluster in a given check-in period.PostgreSQL SLAs exclude issues caused by customer actions including but not limited to; attempting to operate a cluster beyond available processing or storage capacity, modifications to application configuration, or customer initiated reloads or resizes.PostgreSQL uptime is not inclusive of one 30 minute scheduled maintenance window per month. Customers will be notified of scheduled maintenance at least 7 days in advance, and Instaclustr will make all reasonable attempts to minimise the impact to your availability.
  13. Client PostgreSQL applications should be configured in order to maintain high availability, and reestablish connections in the event of a master replica failure. For more information see Replication and High Availability
  14. OpenSearch SLA’s also apply to legacy OpenDistro for Elasticsearch clusters.
  15. The KNN plugin will use additional off heap memory. The default cache and selected node size may be inappropriate depending on the specific use of the plugin combined with other OpenSearch activities. This may result in cluster instability and customers need to be aware this could impact high availability of the cluster.
  16. Clusters created as “Bundled Use Only” are only covered by SLAs when used purely as a supporting service for another Instaclustr offering (ie no direct access).
  17. Enterprise Add-ons for Kafka (Schema Registry, REST Proxy, Karapace Schema Registry and Karapace REST Proxy) are excluded from availability and latency SLAs.
  18. For preview versions of Enterprise Features for Kafka, only the “Starter” tier SLAs are valid. Production usage may be brought under an agreed SLA for the GA version after joint testing. Please contact us if you wish to discuss this option.

Other Services

Instaclustr does not currently provide availability or latency SLAs for additional services such as Apache Spark. This is primarily due to the potential impact of user code on the availability of these environments. Should you require an SLA for a specific usage of these tools then please contact us via our support channels to discuss a custom SLA.