Getting to production for Cloud Databases

Prework

• To ensure cloud-native alignment, complete your data modeling and architectural reviews. For help with data modeling and architecture, contact the IBM Garage.
• Determine the best method for your initial setup, including Terraform, API, CLI, or UI methods.
• Determine the hosting model and therefore the single- or multi-tenancy of your database.
• To manage your database's encryption key for data-at-rest, you must Bring your own encryption key (BYOK) when creating your database. This setup cannot be changed after your instance is provisioned.
• Make sure that IAM access policies and resource groups are set up correctly for your business protocols.
• Ensure that your account is VRF-enabled.
• Understand your database's high availability model. This is covered in the "High-Availability" section of each database's documentation.
• To ensure you receive messages, enroll in IBM Cloud notifications, specifically the "Resource Activity" notification. We directly notify you when your database version is approaching end of life. In addition, you can bookmark our Database version lifecycle policy, which is kept up to date with end of life dates and resources for all databases.

Sample "Getting to production" checklist

• Create a database with the required hosting model, disk, RAM, and virtual CPUs. While these scaling parameters can be changed after the initial provisioning, disks cannot be scaled down.

• If you would like hypervisor level isolation, or if you want to guarantee a number of vCPUs, ensure that you provision Isolated Compute instances.

• Add users. See the related documentation for your Cloud Databases instance.

• Change the Admin Password.

• Set up auto scaling policies, if appropriate. Default auto scaling logic is the suggested baseline. Tune these parameters to your budget and use case. The recommended disk space reflects the minimum amounts that are needed, but note that disk capacity cannot be scaled down without a backup and restore. RAM and virtual CPUs (vCPUs) can scale up and down. Memory auto scaling works based on disk I/O usage to optimize page cache performance. Databases will not auto-scale when in-use memory approaches 100%; this is often the desired state.

  For more information, see your Cloud Databases instance.

• Set up monitoring with IBM Cloud® Monitoring, IBM Cloud® Activity Tracker Event Routing, and IBM® Cloud Logs. At minimum, set alerts on:

  • IBM Cloud Monitoring - when disk usage is greater than 80% of provisioned capacity (we encourage you to use auto scaling for disk capacity). We also encourage you to use, understand, and alert on all provided metrics like disk I/O or CPU usage.
  • IBM Cloud Activity Tracker Event Routing audit events for control plane actions, such as failed backups, IP allowlist updates, and auto scaling.
  • IBM Cloud Logs - any particular database-specific logs you want to be notified about, such as slow query logs.
  • If available, turn on granular in-database auditing (only available for Databases for PostgreSQL and Databases for MongoDB Enterprise Edition).

• Set up context-based restrictions, which give account owners and administrators the ability to define and enforce access restrictions for IBM Cloud® resources based on the context of access requests. For more information, see Protecting Cloud Databases resources with context-based restrictions.

• Set Private endpoints. You might also choose to disable public endpoints (highly recommended if no connection is expected from outside IBM Cloud®).

• Make sure that your application uses TLS for connecting to the database. Insecure connections to Cloud Databases are not allowed.

• Thoroughly load test, and then load test again.

• Validate the application's reconnect logic. For some applications retry is not enough and you must reconnect. Review the article, "Unresponsive Redis Service" for an example of implementation on IBM Cloud® Databases for Redis.

• Set up development and testing environments as separate instances, then work through this checklist again. Depending on your requirements, you might not want to use Isolated Compute for these test environments. Not using Isolated Compute helps to keep costs lower.

• Complete Disaster recovery testing. Test restoring your application to a different IBM Cloud region. Ensure you are able to connect to a "restored" database with new connection details.

  • Understand your Recovery Point Objective (RPO) and Recovery Time Objective (RTO) requirements and ensure that you can meet them with your database's configuration.

To resolve a database's UUID, use the command ibmcloud resource search <UUID>. Other useful CLI commands are: ibmcloud cdb about and ibmcloud cdb cxn. For more information, see the CLI plug-in reference documentation.