Overview

CloudCasa is a data protection and mobility solution for Kubernetes and cloud native appliations. It was originally developed as a SaaS-only offering, but it is now also available as a self-hosted option which can be installed on-prem or in customer cloud environments.

At a high level, a CloudCasa self-hosted system consists of a server, a database, agents installed on each client cluster, and external S3-compatible or Azure object storage used to store the backup data.

Server

All CloudCasa service components, with the exception of the database, are deployed in a single namespace on a Kubernetes cluster, usually “cloudcasa-server”.

Database

All of the catalog data is stored in a MongoDB database. By default, we install MongoDB in a separate namespace called “cloudcasa-mongo”. Data will be stored in a 16 GB PVC created using the storage class configured at install time. You can optionally use your own MongoDB (or compatible) database instance by configuring its URI at install time.

Agent

The CloudCasa agent runs on each client cluster to perform backup and restore operations.

When you register a client cluster via the UI, you are asked which type of agent you want. If you select the option “Manage an existing Velero instance”, you are opting for “CloudCasa for Velero”. Otherwise, “CC Pro” is selected. In both cases, you will see a “kubectl apply” command for installing the agent, which will be installed in the namespace “cloudcasa-io”. When the agent comes up, it connects to the CloudCasa service and you will see cluster state marked as “ACTIVE”. Anytime there is an issue with either the connection or the agent itself, the cluster state will change to “PENDING”.

There are two types of agents corresponding to “CC Pro” and “CC for Velero” functionality.

CC for Velero

The CC for Velero agent will not include CloudCasa’s embedded Velero version. it will only monitor a Velero instance that is already present on the cluster. When it comes up the first time, it will find all Velero resources (such as BSLs, backups, and restores) and sends them to the CloudCasa server. You will see all this information in the CloudCasa UI. From this time onward, the agent monitors Velero resources and whenever it sees a change (create, update, or delete), it will notify CloudCasa. In short, the information you will see in the CloudCasa UI is kept in sync with the state on the cluster.

You can continue to use Velero commands to create/update/delete Velero resources but you can also carry out the same operations from the CloudCasa UI. For example, you can define a backup from the CloudCasa UI which will result in Velero “Backup” or “Schedule” resource being created. We realize that the CloudCasa UI may not expose all the many options that Velero supports, so you will have a chance to edit the YAML before CloudCasa creates or updates a Velero resource.

To summarize CC for Velero, it is complementary to your Velero and you are in total control of managing your backups. CloudCasa will greatly simplify management by showing all of your Velero clusters in a single pane of glass. You are free to remove the agent at any time, and to re-install it again if needed. It will not impact your Velero backups at all.

CC Pro

The CC Pro agent includes our version of Velero. It is completely managed by CloudCasa, and you don’t need to worry about it. But since there can only be one CRD for a given group, kind, and version, we recommend that if you have Velero installed on a cluster, do not install the “CC Pro” agent on the same cluster. So you will either use your Velero instance for backups or “CC Pro”, but not both at the same time. We will remove this restriction in the future.

Some advantages of using CC Pro are:

  • Backups are implemented by reading data from PV snapshots. Velero generally reads directly from live PVs. Version 1.12 introduced backup from snapshots, but we have more than 2 years of experience with this approach.

  • Velero is a single cluster solution, so you will need to manage each cluster separately. For example, you will need to create BSLs on each cluster separately. If you need to restore a Velero backup to a different cluster, you will need to explicitly create BSL on the second cluster and import the backups. With CC Pro, you can create shared storage in a single place and can use it from multiple clusters seamlessly.

  • CC Pro has a special implementation for Azure Files. The Azure Files CSI driver supports CSI snapshots, but doesn’t support restore from snapshot. CC Pro uses integration with Azure APIs to work around this limitation.

  • CC Pro has great integration with Cloud providers (AWS, Azure, and GCP). Here are some cloud account integration features:

    • Automatic discovery of clusters.

    • Automatic installation of agent (on Azure and GKE).

    • Backup of cloud metadata (such as VPCs, load balancers, etc.) so that we can create a new cluster in the cloud automatically during restore.

Network Flow

Please see https://docs.cloudcasa.io/help/reference-network.html for more details.

Here are some things to note:

  • All agents connect to the CloudCasa server on port 443 (using the IP of the cluster service that is exposed to outside). This connection needs to be active all the time. Only control plane traffic travels over on this connection.

  • For backups and restores, the agent connects directly to the storage. For example, if AWS S3 is being used, the agent connects directly to S3 to read and write the data. Data traffic is not routed through the CloudCasa server.

  • The UI communicates with the CloudCasa server using a REST API.

  • When an agent is installed on a cluster, kubectl connects to the CloudCasa server and does a GET to fetch the agent YAML.

There is no connection whatsoever from a self-hosted installation of CloudCasa to the CloudCasa SaaS service or vice versa.