Operations

Operations

note

This page applies to BYOC deployments. To compare the plans, see Deployment models.

SubImage operates your BYOC deployment: upgrades, monitoring, and repairs. You keep ownership of the account and can see and limit every change.

Upgrades

SubImage releases a new version of the deployment once a week. Urgent fixes, such as security fixes, can ship between two weekly releases.

An upgrade replaces the application one part at a time, so the application stays available.

To allow changes only during windows you agree with SubImage, turn off agent_infrastructure_mutation_enabled outside those windows. See Access and security. While the setting is off, upgrades and repairs wait.

Monitoring and support

SubImage monitors the health of each deployment with metrics, logs, and error reports, and investigates problems. To report a problem, contact SubImage support.

Sizing

SubImage sizes the cluster and the databases for your deployment, and the cluster adds nodes when sync jobs need them.

With BYOC with Private Graph, you choose the size of the graph:

  • Graph memory is the memory of each of the three Neo4j servers, from 4 GB to 32 GB. A change applies to one server at a time, and the graph stays available.
  • Graph storage is the disk of each server, from 8 GB to 256 GB. Storage can only grow.

On Google Cloud, the speed of a disk grows with its size. A larger graph disk also gives faster reads and writes.

Backups

  • Graph. With BYOC, Neo4j AuraDB backs up the graph. With BYOC with Private Graph, the deployment backs up the graph every hour to a bucket in your account. Each backup is locked for 30 days.
  • PostgreSQL. The database runs on Amazon RDS or Cloud SQL, with their automated backups. A final backup is kept when you delete the deployment.

To restore data, contact SubImage support.

Offboarding

  1. In manage.subimage.io, delete the deployment. SubImage deletes the resources it created in your account. See Data protection for what stays.
  2. Wait until the portal shows the deployment as deleted.
  3. Then remove the cloud account from the portal. Do not remove it while the deployment is still deleting: the deletion needs the account access to finish.
  4. Remove the account access. On AWS, delete the AccountConfigSetup CloudFormation stack. If you used a Terraform file, run terraform destroy. On Google Cloud with the setup script, delete the project if it holds only the SubImage deployment.