Altinity.Cloud Anywhere 101
Introduction and benefits
Altinity.Cloud Anywhere provides the convenient cloud management of Altinity.Cloud but allows users to keep data within their own cloud VPCs and private data centers, all while running managed ClickHouse® in their own Kubernetes clusters. We sometimes call this Open Cloud for ClickHouse. The Kubernetes clusters that contain ClickHouse clusters are Altinity.Cloud Anywhere environments.
Altinity.Cloud Anywhere offers several important benefits for users.
- Compliance - Retain full control of data (including backups) as well as the operating environment and impose your policies for security, privacy, and data sovereignty.
- Cost - Optimize infrastructure costs by running in your accounts.
- Location - Place ClickHouse clusters close to data sources and applications.
- No vendor lock-in - Disconnect the control plane at any time and continue operating ClickHouse using open-source components.
The rest of this document explains Altinity.Cloud Anywhere and its benefits.
The Altinity Cloud Manager UI manages Altinity.Cloud Anywhere environments just like fully hosted Altinity.Cloud environments. Users can control multiple environments from the same Altinity.Cloud account and can mix and match environment types. No matter what environment you’re in, ClickHouse management works the same way.
Open-source analytic stack
Altinity.Cloud Anywhere uses open-source software for the analytic stack and selected management services–the Altinity Kubernetes Operator for ClickHouse, Loki, Prometheus, and Grafana. The following diagram shows how the principal components map to resources in AWS. (GCP is essentially identical.) Open-source components are in dark blue rectangles.
Users can terminate the service, disconnect the Altinity.Cloud Anywhere environment from Altinity.Cloud, and run ClickHouse services themselves. There is no migration, since all data, software, and support services are already in the user’s Kubernetes cluster. The only component not in the Kubernetes cluster is the management plane.
Service architecture
The Altinity.Cloud service architecture consists of a shared management plane that serves as a single point of management for all tenants and a data plane that consists of isolated environments for each tenant.
The key component is the Altinity Connector. Altinity Connector is a secure management channel between Altinity.Cloud and the managed environment. It is deployed inside Kubernetes, dials back to the management plane and enables Altinity Cloud to manage ClickHouse and infrastructure components. An important property of Altinity Connector is that it only establishes an outbound connection, which pleases corporate Infosec teams.
We’ll discuss two variations of this architecture:
- Bring Your Own Kubernetes (BYOK) - You manage your own Kubernetes environment, Altinity runs ClickHouse clusters inside it
- Bring Your Own Cloud (BYOC) - You provide your cloud account, Altinity builds a Kubernetes cluster inside it, then Altinity runs ClickHouse clusters inside the Kubernetes cluster.
Bring Your Own Kubernetes (BYOK)
The following diagram shows the management plane and data plane relationships.
Each environment is a dedicated Kubernetes cluster. In the case of Altinity.Cloud environments, Kubernetes clusters run on Altinity’s cloud accounts and are completely hidden from users. For Altinity.Cloud Anywhere, Kubernetes clusters run in the user’s cloud account or data center. For example, the user may run an EKS cluster within a VPC belonging to the user’s AWS cloud account. Altinity.Cloud Anywhere environments can also use on-prem Kubernetes clusters. They can even use development versions of Kubernetes running on a user’s PC or laptop.
Connectivity model
Altinity.Cloud Anywhere environments use the Altinity Connector to establish a management connection from the user’s Kubernetes cluster to Altinity.Cloud. The Altinity Connector establishes an outbound HTTPS connection to a management endpoint secured by certificates. This allows management commands and monitoring data to move securely between locations.
Users connect an Altinity.Cloud Anywhere environment to Altinity.Cloud in three simple steps:
- Download the Altinity Connector executable program (
altinitycloud-connect). - Run and register Altinity Connector with Altinity.Cloud Manager.
- If Altinity Connector is installed on a separate VM, it may run provisioning of the Kubernetes cluster (EKS or GKE). This process deploys a new instance of Altinity Connector into the provisioned Kubernetes cluster as well.
- When Altinity Connector is installed directly in Kubernetes, it runs the provisioning of Kubernetes resources.
- Complete registration in the Altinity.Cloud Manager.
Altinity.Cloud Anywhere environments run all services in two namespaces:
- The
altinity-cloud-systemnamespace contains system services including the Altinity Connector. - The
altinity-cloud-managed-clickhousenamespace contains ClickHouse and ZooKeeper. Users can run services in other namespaces as long as they do not make changes to the Altinity-managed namespaces.
Users should not create any resources in either of the Altinity namespaces.
Preparing your Kubernetes cluster
If you manage the Kubernetes cluster, you are responsible for setting up the Kubernetes cluster properly and deploying the Altinity Connector. We provide guidelines to do that properly, but still it requires the expertise and resources of the user’s IT team, not to mention knowledge of Kubernetes administration.
We cover the requirements for a user-managed Kubernetes cluster in a later section, but at a high level, your Kubernetes cluster must:
- Configure storage classes that can allocate block storage on-demand
- Enable auto-scaling
- Enable Kubernetes pods to connect to S3-compatible object storage.
Bring Your Own Cloud (BYOC)
To make it easier for users, Altinity.Cloud Anywhere can also provision and manage the Kubernetes infrastructure, building the full stack in the user’s cloud account. This is the Bring Your Own Cloud (BYOC) model. With BYOC, the user grants Altinity.Cloud permissions to manage cloud resources directly. This access can be provided in two different ways: via a separate VM running Altinity Connector, or directly, depending on the cloud provider’s security model.
The basic model looks like this:
Altinity.Cloud uses a VM-based approach on AWS. It provides the best isolation between Altinity and user account, with the VM serving as a secure bridge between two. It can be deployed using a CloudFormation template that sets an EC2 instance up and sets up the Altinity Connector. Altinity.Cloud does not have direct access to the user’s account in this case; all management operations are routed via this EC2 instance.
Here’s the architecture diagram for AWS:
The other approach requires users to grant an Altinity Cloud service account direct access to the user’s cloud infrastructure. It works well in GCP, where it is easy to create a dedicated new project and manage security on the project level.
Here’s the architecture diagram for GCP:
The Altinity Responsibility Model
With Altinity.Cloud Anywhere, you assume some of the responsibilities that Altinity.Cloud would handle for you. Exactly what you need to do depends on whether you’re provisioning Kubernetes yourself (Bring Your Own Kubernetes) or providing a cloud environment and giving Altinity permission to provision Kubernetes inside it (Bring Your Own Cloud). This figure shows the division of responsibilities for all three scenarios:
Note that even though the base Kubernetes environment used by Altinity.Cloud Anywhere is technically managed by the user, in many cases Altinity.Cloud Anywhere can provision Kubernetes resources in your cluster for you.