This document provides an overview of the technical capabilities and constraints an Exalate node has when deployed on the Exalate Cloud.
The Exalate Cloud is a cloud infrastructure optimized for hosting Exalate Nodes. It ensures the high availability of the nodes and proper separation of the tenants.
Further information on the architecture of Exalate can be found in the Exalate Security and Architecture white paper (SAWP).
The terms of service are regarding the behavior of Exalate when deployed on the Exalate Cloud. It does not apply to configurations where one of the Exalate nodes is deployed "On Premise".
Furthermore, a number of factors can influence the provided terms, such as:
- Impact of connection configurations
Given the flexibility of Exalate and the capability to script its behavior, the terms apply to non-customized Exalate environments. When customizing the connection, it is always possible to introduce script constructs that have an impact on the overall stability and performance of the solution.
- Impact of underlying tracker behavior
The solution will only be fully operational if the underlying trackers (on both sides) are properly configured and available. Examples of misconfigurations are permissions not set correctly, slow performance of the tracker, and network path between the node and the tracker misconfigured.
- The overall behavior depends on the slowest component in the chain.
The performance of the integration between different environments depends on a lot of components. For instance, if a firewall is performing slowly, this can result in delays of the whole synchronization.
Resourcing of a Node Depends on the Service Level
Exalate is an application that is, by definition, single tenant. An exalate node is linked to a single tracker - this means that all different types of computing resources (cpu, memory, disk, networking) are dedicated to that specific environment. This is the basis of the increased information security profile that Exalate brings as this separation is done on the infrastructure level - avoiding information leaks due to misconfigurations and/or bugs in the software. Consider the exalate node running on a dedicated host in a dedicated network segment.
The resources dedicated to the Exalate node are scaled according to the contracted service level agreement.
- The standard service level (which comes with every active license) limits the CPU, Memory and Disk size to respectively 1 CPU, 640 MB of memory, 1 GB of disk.
- The premium service level (which comes with the cloud enhancement premium support option) limits these to 8 CPU, 32 GB of memory and unlimited disk space.
What to Expect from an Exalate Node with a Standard Level Resourcing?
As detailed in the Exalate performance - the ping pong test - a standard setup can process 300 synchronization transactions - or on average, 5 transactions per minute.
A transaction can be any of the following:
- An Exalate transaction
This creates a copy of an issue on the remote system according to the connection configuration.
- An update transaction
Whenever one side does an update (like changing one or more fields) or adds a comment.
In the case of an attachment synchronization, we assume that the attachments are less than 1MB in size and the number of attachments in the issue is less than 5.
- A connect operation
This allows for building a synchronization relation between two entities (issues/incidents ...).
- An unexalate or cleanup operation
This will remove the synchronization relationship between the two entities.
How to Request Additional Resources?
Exalate proposes a "premier support" option, which includes "cloud enhancements - enhanced resource profiles" allowing to increase the resource profiles. Please reach out to our sales to have more details on this option.