Best Practices for Automated Mode AWS Environments¶
This section summarizes the best practices to consider when using the Automated Cloud Mode (AWS) of Solution Manager.
Maximizing Uptime and High Availability¶
Each cluster has its own Network Load Balancer allowing to distribute traffic among all instances for high availabilty.
When creating a production cluster, we recommend enabling the option Launch instances in Auto Scaling Group. With this feature, if a Denodo component of an instance stops responding, the cluster automatically will replace this instance with a new one.
AWS Infrastructure Deployment Considerations¶
When creating an environment, select a region that close to the location of the data sources. I.e. if most of the data sources to which Virtual DataPort connects are in a certain region, create the environment on that same region. This is to speed up the retrieval of data.
Consider creating each environment on a different region. This is to isolate each environment from infrastructure problems on a specific region.
If you create all the environments on the same region, if possible, the subnet of each cluster should be in different a different availability zone. Thus you provide fault tolerant from a failure on an availability zone.
The Solution Manager provides several mechanisms to check the health of your Denodo deployment:
Check the status of the clusters in Overview screen. Solution Manager pings periodically the servers running to keep the cluster status updated.
Additionally, you can also perform additional checks to see if the components are alive.
Use Denodo Monitor to obtain more details about the status of the Virtual DataPort servers.
Backup and Recovery¶
Follow these steps to perfom a system backup.
In case of instance failure:
If the product is configured to use an auto scaling group, unhealthy instances are detected and replaced by the network load balancer health checks and the auto scaling groups. You might get temporary performance issues but no data lost should happen nor admin intervention is required.
If the product cluster does not use an auto scaling group and you detect some kind of failure, restarting the cluster may solve the problem.
Regarding possible service limits reached, consider checking your AWS service quotas keeping an special eye in the Amazon EC2 service quotas. If you hit a service limit (for instance maximum of network load balancers reached if this was a shared account with other components), the way to solve it is contacting your administrator to either remove unused elements (if any) or increasing the limit of the affected resource. Once the limit problem is fixed, you can recreate the cluster in the Solution Manager Administration Tool to fix the cluster and keep it running again.
In case of Availability Zone failure:
In the configuration of the cluster, select a different Availability Zone.
If it is not possible to use a subnet of a different availability zone, wait until the used availability zone recovers.
To recover from a disaster, restore the latest backup. Follow these steps:
To restore the latest backup of the Solution Manager:
If you created an AMI for backup, use the last AMI to recreate the instance of the Solution Manager. To do this, follow the steps in the Launch Instance Wizard.
If instead of creating an AMI, you copied the files of the installation of the Solution Manager, do this:
On a new instance, install the Solution Manager.
Using the Solution Manager Web Tool, restore the license file (this is the file you copied from
If TLS was enabled, follow the steps of the page Enable SSL/TLS in the Solution Manager. Use the keystore file you copied when preparing the backup (e.g.
When using external database:
Restore the files of the directory
Configure Solution Manager again to use an external database. The content of the database should not have been lost because it is not located in the same instance as the Solution Manager.
Import the Solution Manager Configuration JSON file to restore metadata. Click here for more information.
When using embedded Derby database, revisions and promotions information are lost. To avoid this, use an external database.
The time to restore the Solution Manager depends on the storage requirements and the selected backup strategy:
Backup using AMIs: a <45-minutes recovery time objective (RTO) and <24 hour recovery point objective (RPO) are generally possible.
Backup without using AMIs: a <1-hour recovery time objective (RTO) and also <24 hour recovery point objective (RPO) are generally possible.
To restore the latest backup of the Denodo Platform components, recreate the cluster. Make sure you use the latest AMI for each instance.
The time to restore a cluster depends on the storage needs and the selected backup strategy; a <30-minutes recovery time objective (RTO) and <24 hour recovery point objective (RPO) are generally possible.
Rotate the access keys is a good practice for security reasons. There are two ways of doing this:
Install the latest update available. There are two options to install updates: