Does Bonsai Provide CORS Support?
Yes! CORS is enabled for all clusters by default. Users will not need to perform any additional configuration on their clusters in order to set it up.
Does Bonsai Support Groovy Scripting?
The Groovy scripting language was introduced in Elasticsearch in version 1.4 as a replacement for MVEL. This replacement was supposed to address a number of security vulnerabilities in MVEL (among other things). However, Groovy also introduced some serious vulnerabilities that led to some high profile attacks.
While those specific vulnerabilities were ultimately patched, the decision was made that Groovy was not a safe option for multitenant configurations. As a result, Groovy scripting is only enabled for single tenant plans.
Groovy Errors
If your app returns errors, containing ExpressionScriptCompilationException, it’s likely that you need Groovy Scripting enabled on your cluster. This is a feature available on Dedicated and Enterprise plans.
Users with a Business or Enterprise plan should contact us to get groovy enabled. Users on our multitenant plans can still use dynamic scripting with the faster (but somewhat limited) Lucene Expressions language.
Does Bonsai Support HTTP Pipelining?
No. HTTP Pipelining is not supported by Bonsai's platform, and instead Bonsai supports HTTP 2 instead.
Does Bonsai Support HTTP/2?
Yes.
When upgrading a Bonsai cluster’s Elasticsearch or OpenSearch major version, what is the likely impact to availability of the system and what are the possible recovery steps?
There are 2 options for a major version upgrade.
Option 1 - Enterprise Plans
Schedule a time with our team for us to perform a snapshot-restore process to upgrade a major version. During the process, you can expect a short period (depending on your cluster’s disk capacity) of read-only mode. In most cases it takes a few seconds.
TitanIAM users will find that it handles retries, so as far as their application is concerned, this would be close to zero-downtime.
The read-only mode would end with an atomic update to the routing layer, sending incoming traffic to the new hardware. This gives our team a fallback path if something goes awry. However, any writes applied between the routing update and fallback are simply lost.
Option 2 - Non-Enterprise Plans
Check out our documentation on Upgrading Major Versions. By following our recommended variation of a blue-green strategy outlined in the documentation and assuming you can pause or buffer your updates:
- version upgrades happen instantaneously
- can be performed with zero downtime
- offers recovery steps depending on your use case’s approach
When upgrading a Bonsai cluster’s Elasticsearch or OpenSearch minor version, what is the likely impact to availability of the system and what are the possible recovery steps?
There are 2 options for a minor version upgrade.
Option 1 - Enterprise Plans
Bonsai clusters on Enterprise plans can send in a request to support@bonsai.io for our team to perform an in-place minor version upgrade on your behalf. The impact of an in-place minor version upgrade is the same as a rolling restart: there will be a few minutes of read-only mode as it restarts.
Option 2 - Non-Enterprise Plans
Check out our documentation on Upgrading Major Versions that we also recommend for minor version upgrades. By following our variation of a blue-green strategy outlined in the documentation and assuming you can pause or buffer your updates:
- version upgrades happen instantaneously
- can be performed with zero downtime
- offers recovery steps depending on your use case’s approach
When increasing disk capacity by adding new nodes or changing an instance type on a Bonsai cluster, what is the likely impact to availability of the system and what are the possible recovery steps?
The Bonsai cluster’s availability will not be impacted by these two changes. Ideally, these are scheduled during off-peak hours for your cluster. Our operators are notified if something were to go awry during the process.
When a single node on a Bonsai cluster falters for some reason, what is the likely impact to availability of the system and what are the possible recovery steps?
All production Bonsai Clusters are deployed to minimum of three nodes for redundancy and to prevent stalemates in leadership election. Each node in the cluster will be deployed to a separate AWS Availability Zone, giving us data center isolation as well.
A Bonsai cluster could experience a complete loss of one AWS data center, and the cluster will still continue to operate. This makes Bonsai clusters extremely fault-tolerant.
When a Bonsai cluster does experience a node loss, Elasticsearch and OpenSearch will automatically reroute the primary and replica shards to machines that are up and running. In the background, AWS Auto Scaling Groups will immediately begin spinning up the replacement instance that will auto-bootstrap into your configured Elasticsearch or OpenSearch configuration and version. Once the node has successfully provisioned, it will join the cluster, and then Elasticsearch or OpenSearch will offload the relocated shards back to the empty machine.
An event like this is handled as a Severity 1 incident.
When multiple nodes across different Availability Zones for a Bonsai cluster falters for some reason, what is the likely impact to availability of the system and what are the possible recovery steps?
All production Bonsai Clusters are deployed to minimum of three nodes for redundancy and to prevent stalemates in leadership election. Each node in the cluster will be deployed to a separate AWS Availability Zone, giving us data center isolation as well.
When a Bonsai cluster does experience a node loss, Elasticsearch and OpenSearch will automatically reroute the primary and replica shards to machines that are up and running. In the background, AWS Auto Scaling Groups will immediately begin spinning up the replacement instance that will auto-bootstrap into your configured Elasticsearch or OpenSearch configuration and version. Once the node has successfully provisioned, it will join the cluster, and then Elasticsearch or OpenSearch will offload the relocated shards back to the empty machine.
An event like this is handled as a Severity 1 incident.
A Bonsai cluster that experiences a complete loss of two AWS data centers does represent downtime for a cluster until the primary shards are restored on the last remaining node. To mitigate this downtime on an Enterprise cluster, we can discuss a setup that includes multi-region deployment.
When an entire Bonsai cluster fails to come up (for example with 5 TB of disk usage), how does Bonsai restore the cluster from a backup and how much time will it take?
In the off chance that Bonsai (and much of the internet with it) experiences an entire loss of an AWS EC2 region, all of your cluster’s data is maintained in AWS’s S3 system, which has a reliability guarantee of 99.99% uptime and 99.999999999% durability.
If such a failure happens, Bonsai’s staff will work with your team to understand where you will be relocating your application and can then initiate a restore process into a cluster in the same AWS Region while maintaining your existing DNS connections. Alternatively, clusters on an Enterprise plan have the option to re-provision to a nearby AWS Region.
An event like this is handled as a Severity 1 incident.
How much time will it take to restore?
There are several factors to calculate the time to restore: lead time for a support request or Bonsai’s internal alerting system to our Platform team, plus primary data restoration time from the AWS S3 system.
For example, recovering 1 TB of primary data at 1,000 MB/second would take just over two hours. Performance may vary. With 5 TB of primary data, that can approximately take over 10 hours to restore.